---
id: CVE-2026-99030
title: 'net: skbuff: don''t leave stale bytes in skb_copy_and_csum_bits()'
summary: |-
  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…
severity: high
cvss: 7.5
cvssVector: 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N'
cvssSource: cna
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= 65249feb6b3df9e17bab5911ee56fa7b0971e231 <
    5f19b9cfff79508e8cb09be40d014cb0807f3854
  - >-
    Linux >= 65249feb6b3df9e17bab5911ee56fa7b0971e231 <
    5551399751e2c9f31e4f3428040985a07e79d9c2
  - >-
    Linux >= 65249feb6b3df9e17bab5911ee56fa7b0971e231 <
    39d1a6b601831237c6038b5e3ac8dbb883c1700a
  - >-
    Linux >= 65249feb6b3df9e17bab5911ee56fa7b0971e231 <
    ab9414ed70bd783e902a85c350620dee269bcb2b
  - Linux 6.12
published: '2026-10-23'
updated: '2026-10-24'
sourceUpdated: '2026-10-24T14:10:06.982Z'
source: CVEORG
sourceUrl: 'https://www.cve.org/CVERecord?id=CVE-2026-99030'
references:
  - url: 'https://git.kernel.org/stable/c/5f19b9cfff79508e8cb09be40d014cb0807f3854'
  - url: 'https://git.kernel.org/stable/c/5551399751e2c9f31e4f3428040985a07e79d9c2'
  - url: 'https://git.kernel.org/stable/c/39d1a6b601831237c6038b5e3ac8dbb883c1700a'
  - url: 'https://git.kernel.org/stable/c/ab9414ed70bd783e902a85c350620dee269bcb2b'
tags:
  - cve.org
epss: 0.00209
epssPercentile: 0.10515
ingestedAt: '2026-10-23T13:24:55.530Z'
---

## Overview

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().

## Affected

- `Linux >= 65249feb6b3df9e17bab5911ee56fa7b0971e231 < 5f19b9cfff79508e8cb09be40d014cb0807f3854`
- `Linux >= 65249feb6b3df9e17bab5911ee56fa7b0971e231 < 5551399751e2c9f31e4f3428040985a07e79d9c2`
- `Linux >= 65249feb6b3df9e17bab5911ee56fa7b0971e231 < 39d1a6b601831237c6038b5e3ac8dbb883c1700a`
- `Linux >= 65249feb6b3df9e17bab5911ee56fa7b0971e231 < ab9414ed70bd783e902a85c350620dee269bcb2b`
- `Linux 6.12`

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.