[fabwa]

Summary

checkECParts (pkg/services/policer/ec.go) reassembles/restores an EC object's parent header from a part received from another EC container member. The parent header's declared PayloadSize is used, completely unchecked, to size a buffer allocation:

parentHdr = *ph
partLen = (parentHdr.PayloadSize() + uint64(rule.DataPartNum) - 1) / uint64(rule.DataPartNum)
...
buf := make([]byte, int(partLen)*totalParts)

ph comes from hdr.Parent(), where hdr is a part object header received via HEAD from another container member (local or remote, depending on routing) - the PayloadSize field is just an integer in that response, never checked against anything before it drives an allocation. Another member of the same EC container (or an attacker who has placed themselves as a member of the same container as the victim) can declare an arbitrarily large payload size there to force a huge allocation on the node checking that container's EC parts, regardless of what it actually stores - up to an OOM kill or a makeslice panic above the runtime's allocation threshold. The same partLen also sizes the buffer in fetchObjectFromECRule (needLen := int(partLen) * totalParts), reached from the same parentHdr.

Fix

Add a MaxSizeSource to Policer, mirroring the existing MaxSizeSource/WithMaxSizeSource shape already used by the put service for the exact same purpose, and reject the declared parent payload size against it immediately when the parent header is first established - before computing partLen or allocating anything. A single check at that one point covers both downstream allocations, since they're both deterministic functions of the same parentHdr. Wired cmd/neofs-node/object.go to share the same cached max-object-size source the put service already uses, rather than creating a second, redundant cache instance.

Test plan

• Added TestPolicer_checkECParts_RejectsOversizedParentPayload (pkg/services/policer/ec_internal_test.go), calling checkECParts directly against a crafted remote header whose parent declares a payload size far beyond a configured maximum, asserting the rejection happens (via its log entry) rather than falling through to the allocation.
• Confirmed it fails (the rejection log entry is absent) against the unpatched code by temporarily removing just the new check's call site, then restored the fix.
• Updated the existing TestPolicer_Run_EC/parts_restoration test, which exercises this same code path with a legitimate parent size, to supply a MaxSizeSource - it had none previously and would otherwise now be rejected by the new check.
• go build ./..., go vet ./... clean; go test ./pkg/services/policer/... ./cmd/neofs-node/... passes in full.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 32.82%. Comparing base (fd6e171) to head (e6a59be).
⚠️ Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4287      +/-   ##
==========================================
+ Coverage   32.78%   32.82%   +0.04%     
==========================================
  Files         673      673              
  Lines       41707    41727      +20     
==========================================
+ Hits        13673    13698      +25     
+ Misses      28034    28029       -5     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[carpawell]

in PUT service, it looks expected, but this is a validate-after-PUT check, what if max object size was bigger in the past?

[carpawell]

could be a historic Neo call i think. but not this PR's responsibility

[fabwa]

Agreed, and MaxObjectSize is gone from this PR entirely - the bound is now derived from the EC part this node already holds, so no config history is involved.

[carpawell]

there is a duality then, we think our local part is the true part size and calculate maxParentSz based on it, but then recalculate partLen based on the parent just received (but we already know part size and believe in it). i would expect that they should never differ.

not critical

[fabwa]

They can differ, because parts are padded: maxParentSz is only an upper bound, so any parent size from localPartLen*(DataPartNum-1)+1 up to localPartLen*DataPartNum passes it. With localPartLen=10, DataPartNum=2 a declared 11 is in bounds but yields partLen=6. The existing partLen equality check rejects that, including against our own local part, so I left it as the single place that pins the exact size.

[End-rey]

Conflicts.

[roman-khimov]

Seems unnecessary now.