CVE-2026-99030
Beschrijving NL
In de Linux kernel is de volgende kwetsbaarheid verholpen:
net: skbuff: laat geen verouderde bytes achter in skb_copy_AND_csum_bits()
Wanneer skb_copy_AND_csum_bits() onleesbare fragmenten bereikt, geeft het 0 terug
na het kopiëren van alleen het lineaire deel en de rest van de buffer van de beller
wordt gelaten zoals het was. De bellers kopiëren naar een buffer die op het punt staat te gaan
op de draad: een ICMP-fout die het overtredende pakket citeert, of een
tX-bouncebuffer van de bestuurder in skb_copy_and_csum_dev(). Geen van beide buffers
wordt van tevoren op nul gezet, dus alles wat zich daar in het geheugen bevond, wordt verzonden. Zet het deel van de buffer dat we niet hebben gevuld op nul. De checksum meestal
De gegevens komen niet meer overeen, dus de ontvanger zal het bericht meestal weggooien.
pakket, maar hoe dan ook, het bevat niets meer wat het niet zou moeten bevatten. Alleen nul voor een positieve @len, een negatieve van een defecte beller moet
niet uitgroeien tot een enorme memset().
Origineel (Engels) tonen
In the Linux kernel, the following vulnerability has been resolved:
net: skbuff: don't leave stale bytes in skb_copy_and_csum_bits()
When skb_copy_and_csum_bits() reaches unreadable frags it returns 0
after copying only the linear part, and the rest of the caller's buffer
is left as it was. The callers copy into a buffer that is about to go
out on the wire: an ICMP error quoting the offending packet, or a
driver's TX bounce buffer in skb_copy_and_csum_dev(). Neither buffer
is zeroed beforehand, so whatever was in memory there gets sent.
Zero the part of the buffer we didn't fill. The checksum usually
won't match the data any more, so the receiver will usually drop the
packet, but either way it no longer carries anything it shouldn't.
Only zero for a positive @len, a negative one from a broken caller must
not turn into a huge memset().