CVE-2026-23343
published 2026-03-25CVE-2026-23343: In the Linux kernel, the following vulnerability has been resolved: xdp: produce a warning when calculated tailroom is negative Many ethernet drivers report…
PriorityP340high7.8CVSS 3.1
AVLACLPRLUINSUCHIHAH
EPSS
0.13%
2.9th percentile
In the Linux kernel, the following vulnerability has been resolved:
xdp: produce a warning when calculated tailroom is negative
Many ethernet drivers report xdp Rx queue frag size as being the same as
DMA write size. However, the only user of this field, namely
bpf_xdp_frags_increase_tail(), clearly expects a truesize.
Such difference leads to unspecific memory corruption issues under certain
circumstances, e.g. in ixgbevf maximum DMA write size is 3 KB, so when
running xskxceiver's XDP_ADJUST_TAIL_GROW_MULTI_BUFF, 6K packet fully uses
all DMA-writable space in 2 buffers. This would be fine, if only
rxq->frag_size was properly set to 4K, but value of 3K results in a
negative tailroom, because there is a non-zero page offset.
We are supposed to return -EINVAL and be done with it in such case, but due
to tailroom being stored as an unsigned int, it is reported to be somewhere
near UINT_MAX, resulting in a tail being grown, even if the requested
offset is too much (it is around 2K in the abovementioned test). This later
leads to all kinds of unspecific calltraces.
[ 7340.337579] xskxceiver[1440]: segfault at 1da718 ip 00007f4161aeac9d sp 00007f41615a6a00 error 6
[ 7340.338040] xskxceiver[1441]: segfault at 7f410000000b ip 00000000004042b5 sp 00007f415bffecf0 error 4
[ 7340.338179] in libc.so.6[61c9d,7f4161aaf000+160000]
[ 7340.339230] in xskxceiver[42b5,400000+69000]
[ 7340.340300] likely on CPU 6 (core 0, socket 6)
[ 7340.340302] Code: ff ff 01 e9 f4 fe ff ff 0f 1f 44 00 00 4c 39 f0 74 73 31 c0 ba 01 00 00 00 f0 0f b1 17 0f 85 ba 00 00 00 49 8b 87 88 00 00 00 89 70 08 eb cc 0f 1f 44 00 00 48 8d bd f0 fe ff ff 89 85 ec fe
[ 7340.340888] likely on CPU 3 (core 0, socket 3)
[ 7340.345088] Code: 00 00 00 ba 00 00 00 00 be 00 00 00 00 89 c7 e8 31 ca ff ff 89 45 ec 8b 45 ec 85 c0 78 07 b8 00 00 00 00 eb 46 e8 0b c8 ff ff 00 83 f8 69 74 24 e8 ff c7 ff ff 8b 00 83 f8 0b 74 18 e8 f3 c7
[ 7340.404334] Oops: general protection fault, probably for non-canonical address 0x6d25
Affected
28 ranges· showing 25
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.19.8-1 (forky) | linux 6.19.8-1 (forky) |
| linux | linux | — | — |
| linux | linux | >= bf25146a5595269810b1f47d048f114c5ff9f544 < 01379540452a02bbc52f639d45dd365cd3624efb | 01379540452a02bbc52f639d45dd365cd3624efb |
| linux | linux | >= bf25146a5595269810b1f47d048f114c5ff9f544 < a0fb59f527d03c60b2cd547cfae4a842ad84670f | a0fb59f527d03c60b2cd547cfae4a842ad84670f |
| linux | linux | >= bf25146a5595269810b1f47d048f114c5ff9f544 < c7c790a07697148c41e2d03eb28efe132adda749 | c7c790a07697148c41e2d03eb28efe132adda749 |
| linux | linux | >= bf25146a5595269810b1f47d048f114c5ff9f544 < 98cd8b4d0b836d3edf70161f40efd9cbb8c8f252 | 98cd8b4d0b836d3edf70161f40efd9cbb8c8f252 |
| linux | linux | >= bf25146a5595269810b1f47d048f114c5ff9f544 < 94b9da7e9f958cb3d115b21eff824ecd8c3217aa | 94b9da7e9f958cb3d115b21eff824ecd8c3217aa |
| linux | linux | >= bf25146a5595269810b1f47d048f114c5ff9f544 < 8821e857759be9db3cde337ad328b71fe5c8a55f | 8821e857759be9db3cde337ad328b71fe5c8a55f |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 6.19.8-1 | 6.19.8-1 |
| linux | linux_kernel | >= 5.18.0 < 6.1.167 | 6.1.167 |
| linux | linux_kernel | >= 5.18.1 < 6.1.167 | 6.1.167 |
| linux | linux_kernel | >= 6.13 < 6.18.17 | 6.18.17 |
| linux | linux_kernel | >= 6.13.0 < 6.18.17 | 6.18.17 |
| linux | linux_kernel | >= 6.19 < 6.19.7 | 6.19.7 |
| linux | linux_kernel | >= 6.19.0 < 6.19.7 | 6.19.7 |
| linux | linux_kernel | >= 6.2 < 6.6.130 | 6.6.130 |
| linux | linux_kernel | >= 6.2.0 < 6.6.130 | 6.6.130 |
CVSS provenance
nvdv3.17.8HIGHCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
vendor_msrc7.1HIGH
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
VulDB
Linux Kernel up to 7.0-rc2 xdp bpf_xdp_frags_increase_tail memory corruption (Nessus ID 311783)
vuldb·2026-05-04·CVSS 7.8
CVE-2026-23343 [HIGH] Linux Kernel up to 7.0-rc2 xdp bpf_xdp_frags_increase_tail memory corruption (Nessus ID 311783)
A vulnerability marked as critical has been reported in Linux Kernel up to 7.0-rc2. This affects the function bpf_xdp_frags_increase_tail of the component xdp. Performing a manipulation results in memory corruption.
This vulnerability is identified as CVE-2026-23343. The attack can only be performed from the local network. There is not any exploit available.
It is suggested to upgrade the affected component.
GHSA
GHSA-rqf2-6q66-wgpp: In the Linux kernel, the following vulnerability has been resolved:
xdp: produce a warning when calculated tailroom is negative
Many ethernet driver
ghsa_unreviewed·2026-03-25
CVE-2026-23343 GHSA-rqf2-6q66-wgpp: In the Linux kernel, the following vulnerability has been resolved:
xdp: produce a warning when calculated tailroom is negative
Many ethernet driver
In the Linux kernel, the following vulnerability has been resolved:
xdp: produce a warning when calculated tailroom is negative
Many ethernet drivers report xdp Rx queue frag size as being the same as
DMA write size. However, the only user of this field, namely
bpf_xdp_frags_increase_tail(), clearly expects a truesize.
Such difference leads to unspecific memory corruption issues under certain
circumstances, e.g. in ixgbevf maximum DMA write size is 3 KB, so when
running xskxceiver's XDP_ADJUST_TAIL_GROW_MULTI_BUFF, 6K packet fully uses
all DMA-writable space in 2 buffers. This would be fine, if only
rxq->frag_size was properly set to 4K, but value of 3K results in a
negative tailroom, because there is a non-zero page offset.
We are supposed to return -EINVAL and be done with it in such
OSV
CVE-2026-23343: In the Linux kernel, the following vulnerability has been resolved: xdp: produce a warning when calculated tailroom is negative Many ethernet drivers
osv·2026-03-25
CVE-2026-23343 CVE-2026-23343: In the Linux kernel, the following vulnerability has been resolved: xdp: produce a warning when calculated tailroom is negative Many ethernet drivers
In the Linux kernel, the following vulnerability has been resolved: xdp: produce a warning when calculated tailroom is negative Many ethernet drivers report xdp Rx queue frag size as being the same as DMA write size. However, the only user of this field, namely bpf_xdp_frags_increase_tail(), clearly expects a truesize. Such difference leads to unspecific memory corruption issues under certain circumstances, e.g. in ixgbevf maximum DMA write size is 3 KB, so when running xskxceiver's XDP_ADJUST_TAIL_GROW_MULTI_BUFF, 6K packet fully uses all DMA-writable space in 2 buffers. This would be fine, if only rxq->frag_size was properly set to 4K, but value of 3K results in a negative tailroom, because there is a non-zero page offset. We are supposed to return -EINVAL and be done with it in such cas
OSV
xdp: produce a warning when calculated tailroom is negative
osv·2026-03-25
CVE-2026-23343 xdp: produce a warning when calculated tailroom is negative
xdp: produce a warning when calculated tailroom is negative
In the Linux kernel, the following vulnerability has been resolved:
xdp: produce a warning when calculated tailroom is negative
Many ethernet drivers report xdp Rx queue frag size as being the same as
DMA write size. However, the only user of this field, namely
bpf_xdp_frags_increase_tail(), clearly expects a truesize.
Such difference leads to unspecific memory corruption issues under certain
circumstances, e.g. in ixgbevf maximum DMA write size is 3 KB, so when
running xskxceiver's XDP_ADJUST_TAIL_GROW_MULTI_BUFF, 6K packet fully uses
all DMA-writable space in 2 buffers. This would be fine, if only
rxq->frag_size was properly set to 4K, but value of 3K results in a
negative tailroom, because there is a non-zero page offset.
Red Hat
kernel: xdp: produce a warning when calculated tailroom is negative
vendor_redhat·2026-03-25·CVSS 5.5
CVE-2026-23343 [MEDIUM] CWE-190 kernel: xdp: produce a warning when calculated tailroom is negative
kernel: xdp: produce a warning when calculated tailroom is negative
In the Linux kernel, the following vulnerability has been resolved:
xdp: produce a warning when calculated tailroom is negative
Many ethernet drivers report xdp Rx queue frag size as being the same as
DMA write size. However, the only user of this field, namely
bpf_xdp_frags_increase_tail(), clearly expects a truesize.
Such difference leads to unspecific memory corruption issues under certain
circumstances, e.g. in ixgbevf maximum DMA write size is 3 KB, so when
running xskxceiver's XDP_ADJUST_TAIL_GROW_MULTI_BUFF, 6K packet fully uses
all DMA-writable space in 2 buffers. This would be fine, if only
rxq->frag_size was properly set to 4K, but value of 3K results in a
negative tailroom, because there is a non-zero page offs
Microsoft
xdp: produce a warning when calculated tailroom is negative
vendor_msrc·2026-03-10·CVSS 7.1
CVE-2026-23343 [HIGH] xdp: produce a warning when calculated tailroom is negative
xdp: produce a warning when calculated tailroom is negative
Mariner: Mariner
Linux: Linux
Customer Action Required: Yes
Remediation: CBL-Mariner Releases
Reference: https://learn.microsoft.com/en-us/azure/azure-linux/tutorial-azure-linux-upgrade
Debian
CVE-2026-23343: linux - In the Linux kernel, the following vulnerability has been resolved: xdp: produc...
vendor_debian·2026
CVE-2026-23343 CVE-2026-23343: linux - In the Linux kernel, the following vulnerability has been resolved: xdp: produc...
In the Linux kernel, the following vulnerability has been resolved: xdp: produce a warning when calculated tailroom is negative Many ethernet drivers report xdp Rx queue frag size as being the same as DMA write size. However, the only user of this field, namely bpf_xdp_frags_increase_tail(), clearly expects a truesize. Such difference leads to unspecific memory corruption issues under certain circumstances, e.g. in ixgbevf maximum DMA write size is 3 KB, so when running xskxceiver's XDP_ADJUST_TAIL_GROW_MULTI_BUFF, 6K packet fully uses all DMA-writable space in 2 buffers. This would be fine, if only rxq->frag_size was properly set to 4K, but value of 3K results in a negative tailroom, because there is a non-zero page offset. We are supposed to return -EINVAL and be done with it in such cas
No detection rules found.
No public exploits indexed.
Wiz
CVE-2026-23343 Impact, Exploitability, and Mitigation Steps | Wiz
blogs_wiz
CVE-2026-23343 CVE-2026-23343 Impact, Exploitability, and Mitigation Steps | Wiz
## CVE-2026-23343 :
Linux Kernel vulnerability analysis and mitigation
In the Linux kernel, the following vulnerability has been resolved:
xdp: produce a warning when calculated tailroom is negative
Many ethernet drivers report xdp Rx queue frag size as being the same as
DMA write size. However, the only user of this field, namely
bpf_xdp_frags_increase_tail(), clearly expects a truesize.
Such difference leads to unspecific memory corruption issues under certain
circumstances, e.g. in ixgbevf maximum DMA write size is 3 KB, so when
running xskxceiver's XDP_ADJUST_TAIL_GROW_MULTI_BUFF, 6K packet fully uses
all DMA-writable space in 2 buffers. This would be fine, if only
rxq->frag_size was properly set to 4K, but value of 3K results in a
negative tailroom, because there is a non-zero pa
Bugzilla
CVE-2026-23343 kernel: xdp: produce a warning when calculated tailroom is negative
bugzilla·2026-03-25·CVSS 7.8
CVE-2026-23343 [HIGH] CVE-2026-23343 kernel: xdp: produce a warning when calculated tailroom is negative
CVE-2026-23343 kernel: xdp: produce a warning when calculated tailroom is negative
In the Linux kernel, the following vulnerability has been resolved:
xdp: produce a warning when calculated tailroom is negative
Many ethernet drivers report xdp Rx queue frag size as being the same as
DMA write size. However, the only user of this field, namely
bpf_xdp_frags_increase_tail(), clearly expects a truesize.
Such difference leads to unspecific memory corruption issues under certain
circumstances, e.g. in ixgbevf maximum DMA write size is 3 KB, so when
running xskxceiver's XDP_ADJUST_TAIL_GROW_MULTI_BUFF, 6K packet fully uses
all DMA-writable space in 2 buffers. This would be fine, if only
rxq->frag_size was properly set to 4K, but value of 3K results in a
negative tailroom, because there is a
https://git.kernel.org/stable/c/01379540452a02bbc52f639d45dd365cd3624efbhttps://git.kernel.org/stable/c/8821e857759be9db3cde337ad328b71fe5c8a55fhttps://git.kernel.org/stable/c/94b9da7e9f958cb3d115b21eff824ecd8c3217aahttps://git.kernel.org/stable/c/98cd8b4d0b836d3edf70161f40efd9cbb8c8f252https://git.kernel.org/stable/c/a0fb59f527d03c60b2cd547cfae4a842ad84670fhttps://git.kernel.org/stable/c/c7c790a07697148c41e2d03eb28efe132adda749https://cert-portal.siemens.com/productcert/html/ssa-019113.htmlhttps://cert-portal.siemens.com/productcert/html/ssa-082556.html
2026-03-25
Published