GCPnts_UniformAbscissa/QuasiUniformAbscissa: two unpatched kernel defects behind #501's buffer-overflow fix (unbounded NbPoints(), degenerate-count SIGSEGV)

[gsdali]

#501/#544 fixed a heap buffer overflow and an uncatchable SIGSEGV reachable through four bridge functions, by guarding the bridge layer (occtSamplerKept/occtSamplerIndex/occtValidSampleCount in OCCTBridge_Internal.h). That fix is bridge-only: no Scripts/patches/*.patch was carried, OCCT.xcframework was not rebuilt, and neither defect is filed upstream against Open-Cascade-SAS/OCCT. The two underlying kernel bugs still exist in the pinned source (verified directly in Libraries/occt-src) — this issue tracks patching and filing them properly, following this project's usual practice for confirmed kernel-level memory-safety defects (e.g. #310, #317, #318, #341).

Defect 1: GCPnts_UniformAbscissa::NbPoints() is not bounded by the requested count

GCPnts_UniformAbscissa::initialize (ModelingData/TKGeomBase/GCPnts/GCPnts_UniformAbscissa.cxx:515) sizes its internal parameter array at theNbPoints + 5:

const int aSize = theNbPoints + 5;
...
myParams = new NCollection_HArray1<double>(1, aSize);

but the arc-length walk (Perform/PerformLengthParametrized, same file) fills the array as far as it runs and sets myNbPoints = anIndex (:155, :217) with no clamp against the original theNbPoints. NbPoints() (GCPnts_UniformAbscissa.hxx:216-219) just returns myNbPoints directly — so any caller that sizes its own output buffer from the requested count rather than the actual NbPoints() after construction can be handed more points than it asked for, bounded only by the +5 padding.

GCPnts_QuasiUniformAbscissa::initialize (GCPnts_QuasiUniformAbscissa.cxx:117-120) inherits this for every curve that is not Bezier/BSpline, since it forwards straight to GCPnts_UniformAbscissa:

if (theC.GetType() != GeomAbs_BezierCurve && theC.GetType() != GeomAbs_BSplineCurve)
{
  GCPnts_UniformAbscissa aUA(theC, theNbPoints, theU1, theU2);
  myNbPoints = aUA.NbPoints();
  ...
}

Reproduced: on an ellipse with major radius 1e6 and minor radius 1e-3, the arc-length walk lands roughly 1.6e-8 short of the end parameter — far outside the sampler's own local epsilon (Resolution(1e-7), about 1e-13 there) — so it takes one extra step and snaps that step to the true end parameter. 22 of the first 59 requested point counts overshoot the request by exactly one. Full measured tables at Scripts/repro/501-quasiuniform-buffer-overflow/.

This is a real footgun for any OCCT consumer (not just OCCTSwift) that follows the documented contract of "allocate theNbPoints slots, call Parameter(i) for i in 1...theNbPoints" — the class does not actually guarantee that bound.

Defect 2: degenerate point count SIGSEGVs the Bezier/BSpline branch

GCPnts_QuasiUniformAbscissa::initialize's Bezier/BSpline branch (GCPnts_QuasiUniformAbscissa.cxx:128-158) guards theNbPoints <= 1 with:

Standard_ConstructionError_Raise_if(
    theNbPoints <= 1,
    "GCPnts_QuasiUniformAbscissa::Initialize(), number of points should be >= 2");

*_Raise_if macros compile to nothing under No_Exception, which is how this project's pinned Release OCCT.xcframework is built (see #487). With that guard neutralized and theNbPoints == 0:

• aLP is constructed as NCollection_Array1<gp_Pnt2d>(1, 2*theNbPoints) = (1, 0), an empty range — harmless on its own, since the fill loop (for (i = 0; i < 2*theNbPoints; ++i)) never executes.
• aLength stays 0.0, so the IsEqual(aLength, 0.0) branch is taken.
• myParams = new NCollection_HArray1<double>(1, theNbPoints) = (1, 0), also an empty range.
• The very next line, unconditional: myParams->SetValue(1, theU1); — writes index 1 into an array whose valid range is empty. Uncatchable out-of-bounds store; SIGSEGVs.

Reproduced on a 4-pole Bezier, an all-coincident-pole Bezier, and an 8-point BSpline fit, all with nbPoints = 0. (On non-Bezier/BSpline curves — a line, circle, ellipse — nbPoints = 0 does not crash; it silently returns IsDone() with 5 points, a separate but less severe misbehavior of the same missing precondition.)

Status

• OCCTSwift's own bridge functions are already guarded (occtValidSampleCount, OCCT Class Cross-Reference Index (OCCTBridge.h:19-525) is systemically stale — points to non-existent symbols and hides an orphaned duplicate GCPnts_QuasiUniformAbscissa bridge function #501/fix(#501): the orphaned quasi-uniform duplicate, and the buffer overflow it was hiding #544) — no OCCTSwift-reachable code path hits either defect anymore.
• The kernel source itself is unpatched. Any other direct consumer of GCPnts_UniformAbscissa/GCPnts_QuasiUniformAbscissa — including OCCT's own Draw commands or a future OCCTSwift bridge function that forgets the guard — remains exposed.
• Not yet filed upstream against Open-Cascade-SAS/OCCT.

Suggested fix

Following the pattern already carried in Scripts/patches/:

• Defect 1: clamp myNbPoints (or anIndex) to theNbPoints in GCPnts_UniformAbscissa::Perform/PerformLengthParametrized, or document/enforce the true upper bound (theNbPoints + 5) so callers can size correctly instead of being surprised.
• Defect 2: an explicit, always-enforced range check before SetValue(1, theU1) in the Bezier/BSpline branch of GCPnts_QuasiUniformAbscissa::initialize — not reliant on Raise_if compiling in.

Carry both as a kernel patch (Scripts/patches/0018-* or next available number), rebuild OCCT.xcframework, and file upstream as a repro + fix PR, matching the project's established practice for confirmed kernel-level memory-safety defects.

[gsdali]

Both defects patched as Scripts/patches/0018-GCPnts-degenerate-count-and-duplicate-end-point-555.patch, in #519 (which carries the rebuild, so the kernel binary already has it). Not merged, not filed upstream yet.

Both reproduce as described. Verified against the pinned source before writing anything: 22 of counts 2..60 over-request by exactly one on the 1e6 x 1e-3 ellipse, for both classes, and nbPoints = 0 SIGSEGVs GCPnts_QuasiUniformAbscissa on a 4-pole Bezier and an 8-point BSpline fit.

One measured fact changes the fix for defect 1. The issue offers "clamp myNbPoints to theNbPoints" as the first option. Measuring the surplus point shows it is a duplicate: at n=4 the last two parameters differ by 1.557e-08 and the two 3D points by 1.175e-10. Clamping would therefore discard the exact end parameter and leave the distribution stopping short of the curve, which is exactly the defect #501 found in OCCTGCPntsQuasiUniform, the one bridge function that already clamped. So the patch does not clamp.

Instead it fixes what causes the extra step. Perform terminates on abs(aUi - aUU2) <= theEPSILON, where theEPSILON comes from Resolution(), which converts a 3D tolerance to a parametric one using the curve's largest derivative. On that ellipse it yields about 1e-13, while the local derivative at the end is 1e-3, so the parametric tolerance actually corresponding to 1e-7 in 3D is about 1e-4. The test is around nine orders of magnitude too tight there. Perform now also accepts a point that coincides with the end in 3D within the caller's tolerance: the 3D tolerance is threaded in beside the parametric one, the end point is evaluated once outside the walk, and the distance test sits behind a cheap aUU2 - aUi < aDelta gate so it costs one extra evaluation per call rather than per step.

Defect 2 is fixed as the issue suggests, with an ordinary if after each Raise_if. Applied to both classes, since GCPnts_UniformAbscissa has the same missing precondition without the crash: it answered a request for zero points with five.

Verification, all against the rebuilt kernel with no override-linked TUs:

• 17 curve types x counts 2..200 x both classes, 6766 configurations: 232 lines change and they are exactly the 232 that were over-requesting. Everything else is byte-identical, and on the changed lines the last parameter is still exactly the end.
• Over-request 22 counts to 0. Every degenerate count on every curve now returns IsDone() == false for both classes, replacing a SIGSEGV, a 5-point answer or a 1-point answer depending on which curve and class you called.
• clang-format clean against OCCT's own config; full swift test clean at 4842 tests / 1346 suites, which includes fix(#501): the orphaned quasi-uniform duplicate, and the buffer overflow it was hiding #544's new tests now that it has merged.

Reproducers and the full writeup: Scripts/repro/555-gcpnts-count-contract/. They record a trap that cost me a confusing run: building the override-linked TUs without -DNo_Exception brings the Raise_if back, so the degenerate cases abort with an uncaught Standard_ConstructionError instead of crashing or returning not-done. That looks like a broken patch and is really a measurement of a kernel nobody ships.

Also cross-referenced 0018 from #501's reproducer README: its "before: 48 overflowing calls" numbers now need a kernel without this patch to reproduce, because the sampler no longer over-requests. #544's bridge guards stay regardless, since they are what makes the bridge correct against an unpatched kernel.

Still open: filing upstream as a repro issue plus a fix PR. That is outward-facing so I have left it for a go-ahead.

[gsdali]

Filed upstream as Open-Cascade-SAS/OCCT#1417, a fix PR with no companion reproducer issue, per the current upstream practice.

The issue's "Suggested fix" section asks for a repro plus a fix PR, matching what we did for #348 (OCCT#1391 and OCCT#1392), #349 (OCCT#1393 and OCCT#1394) and the rest. That is no longer what upstream wants, so this is a PR on its own with the mechanism, the measurements and a link to Scripts/repro/555-gcpnts-count-contract/ carried in the description instead. I have written the rule into okf/policies/upstream-occt-style.md, which did not have it: a standalone issue is now only for a reproducer we cannot offer a fix with.

Branched from current master b8f597c6, having first confirmed both touched files are byte-identical between upstream master and our V8_0_0_p1 pin, so the patch is the same change on both trees. clang-format and the non-ASCII check pass locally against OCCT's own config; the build and regression jobs are running.

The local half was already complete: patch 0018 carried, OCCT.xcframework rebuilt (checksum 2ed5ec7f..., patches 0001-0018), swift test clean at 4842 tests / 1346 suites, all in #519.

[gsdali]

Upstream CI on OCCT#1417 is fully green: 17 pass, 1 skipping (Build Documentation), nothing failed.

All four platform builds (Ubuntu Clang, Ubuntu GCC no-PCH, Windows MSVC, macOS Clang), all three regression suites, all four GTest jobs, the three Test on ... jobs, and both the Check code formatting and Check for non-ASCII characters gates. The regression and GTest suites passing matters more here than on our thread-safety patches: 0018 changes what GCPnts_UniformAbscissa returns on a curve where the walk previously over-stepped, and those samplers feed meshing and discretization throughout the kernel. Nothing upstream depended on the duplicate end point.

PR is MERGEABLE, BLOCKED on review, no reviews yet. Nothing further from our side unless a maintainer comes back.