src: ccm cipher update with zero-length dataView

[mertcanaltin]

added fallback stack_storage for null scenario

for:#62342

[codecov]

Codecov Report

❌ Patch coverage is 75.00000% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 89.68%. Comparing base (0998c37) to head (88f8f03).

Files with missing lines	Patch %	Lines
src/util-inl.h	75.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #62343      +/-   ##
==========================================
- Coverage   91.60%   89.68%   -1.92%     
==========================================
  Files         337      676     +339     
  Lines      140741   206692   +65951     
  Branches    21797    39585   +17788     
==========================================
+ Hits       128923   185378   +56455     
- Misses      11594    13445    +1851     
- Partials      224     7869    +7645     

Files with missing lines	Coverage Δ
src/util-inl.h	82.69% <75.00%> (ø)

... and 458 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[panva]

With ArrayBufferViewContents being used broadly throughout node's codebase I wonder if we can be sure this is entirely without side effects. I cannot assess that.

That being said, it does fix the particular node:crypto issue reported.

[mertcanaltin]

With ArrayBufferViewContents being used broadly throughout node's codebase I wonder if we can be sure this is entirely without side effects. I cannot assess that.

That being said, it does fix the particular node:crypto issue reported.

I went through all 19 files that use ArrayBufferViewContents, every usage passes data() alongside length(), and none dereferences the pointer when length is 0. Currently data_ can already be null in this scenario, this fix just ensures it's a valid pointer instead, so it's strictly safer than the current behavior.

[panva]

I went through all 19 files that use ArrayBufferViewContents, every usage passes data() alongside length(), and none dereferences the pointer when length is 0. Currently data_ can already be null in this scenario, this fix just ensures it's a valid pointer instead, so it's strictly safer than the current behavior.

Very well, can you update the commit message to src: handle null backing store in ArrayBufferViewContents::Read?