CVE-2026-23343
Received Received - Intake
Integer Overflow in Linux Kernel XDP Fragment Tailroom Causes Memory Corruption

Publication date: 2026-03-25

Last updated on: 2026-04-23

Assigner: kernel.org

Description
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 <4c> 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 <8b> 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 0x6d255010bdffc: 0000 [#1] SMP NOPTI [ 7340.405972] CPU: 7 UID: 0 PID: 1439 Comm: xskxceiver Not tainted 6.19.0-rc1+ #21 PREEMPT(lazy) [ 7340.408006] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014 [ 7340.409716] RIP: 0010:lookup_swap_cgroup_id+0x44/0x80 [ 7340.410455] Code: 83 f8 1c 73 39 48 ba ff ff ff ff ff ff ff 03 48 8b 04 c5 20 55 fa bd 48 21 d1 48 89 ca 83 e1 01 48 d1 ea c1 e1 04 48 8d 04 90 <8b> 00 48 83 c4 10 d3 e8 c3 cc cc cc cc 31 c0 e9 98 b7 dd 00 48 89 [ 7340.412787] RSP: 0018:ffffcc5c04f7f6d0 EFLAGS: 00010202 [ 7340.413494] RAX: 0006d255010bdffc RBX: ffff891f477895a8 RCX: 0000000000000010 [ 7340.414431] RDX: 0001c17e3fffffff RSI: 00fa070000000000 RDI: 000382fc7fffffff [ 7340.415354] RBP: 00fa070000000000 R08: ffffcc5c04f7f8f8 R09: ffffcc5c04f7f7d0 [ 7340.416283] R10: ffff891f4c1a7000 R11: ffffcc5c04f7f9c8 R12: ffffcc5c04f7f7d0 [ 7340.417218] R13: 03ffffffffffffff R14: 00fa06fffffffe00 R15: ffff891f47789500 [ 7340.418229] FS: 0000000000000000(0000) GS:ffff891ffdfaa000(0000) knlGS:0000000000000000 [ 7340.419489] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 7340.420286] CR2: 00007f415bfffd58 CR3: 0000000103f03002 CR4: 0000000000772ef0 [ 7340.421237] PKRU: 55555554 [ 7340.421623] Call Trace: [ 7340.421987] <TASK> [ 7340.422309] ? softleaf_from_pte+0x77/0xa0 [ 7340.422855] swap_pte_batch+0xa7/0x290 [ 7340.423363] zap_nonpresent_ptes.constprop.0.isra.0+0xd1/0x270 [ 7340.424102] zap_pte_range+0x281/0x580 [ 7340.424607] zap_pmd_range.isra.0+0xc9/0x240 [ 7340.425177] unmap_page_range+0x24d/0x420 [ 7340.425714] unmap_vmas+0xa1/0x180 [ 7340.426185] exit_mmap+0xe1/0x3b0 [ 7340.426644] __mmput+0x41/0x150 [ 7340.427098] exit_mm+0xb1/0x110 [ 7340.427539] do_exit+0x1b2/0x460 [ 7340.427992] do_group_exit+0x2d/0xc0 [ 7340.428477] get_signal+0x79d/0x7e0 [ 7340.428957] arch_do_signal_or_restart+0x34/0x100 [ 7340.429571] exit_to_user_mode_loop+0x8e/0x4c0 [ 7340.430159] do_syscall_64+0x188/ ---truncated---
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-25
Last Modified
2026-04-23
Generated
2026-05-07
AI Q&A
2026-03-25
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 13 associated CPEs
Vendor Product Version / Range
linux linux_kernel 5.18
linux linux_kernel From 6.19 (inc) to 6.19.7 (exc)
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel From 6.13 (inc) to 6.18.17 (exc)
linux linux_kernel From 6.2 (inc) to 6.6.130 (exc)
linux linux_kernel From 6.7 (inc) to 6.12.77 (exc)
linux linux_kernel From 5.18.1 (inc) to 6.1.167 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-787 The product writes data past the end, or before the beginning, of the intended buffer.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's XDP (Express Data Path) implementation. It arises because many ethernet drivers report the XDP receive queue fragment size as the same as the DMA write size, but the function bpf_xdp_frags_increase_tail() expects a true size instead.

Due to this mismatch, under certain conditions, such as with the ixgbevf driver where the maximum DMA write size is 3 KB, the reported fragment size is incorrect (3 KB instead of the expected 4 KB). This causes the calculated tailroom (space left at the end of a buffer) to become negative.

Because tailroom is stored as an unsigned integer, a negative value is interpreted as a very large positive number, leading to the system attempting to grow the tail beyond the buffer's actual capacity. This results in memory corruption and various unpredictable crashes or call traces.


How can this vulnerability impact me? :

This vulnerability can lead to unspecific memory corruption issues in the Linux kernel when using affected ethernet drivers and XDP features. The memory corruption can cause system instability, including segmentation faults and general protection faults, potentially crashing processes or the entire system.

Such crashes and memory corruption can disrupt network operations, degrade system reliability, and may be exploited to cause denial of service or other unpredictable behavior.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability manifests as unspecific memory corruption issues and can cause kernel crashes or segfaults related to XDP (Express Data Path) operations, especially when using xskxceiver with certain ethernet drivers like ixgbevf.

Detection can involve monitoring kernel logs for specific error messages such as segfaults in xskxceiver, general protection faults, or unusual call traces related to XDP tailroom calculations.

You can check kernel logs using commands like:

  • dmesg | grep -i xskxceiver
  • journalctl -k | grep -i 'general protection fault'
  • journalctl -k | grep -i segfault

Additionally, monitoring for unusual crashes or faults in network-related processes or drivers can help detect this issue.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability is resolved by ensuring that the Linux kernel properly warns when the calculated tailroom is negative and avoids memory corruption by returning an error instead of allowing tail growth.

Immediate mitigation steps include:

  • Update the Linux kernel to a version that includes the fix for this vulnerability.
  • Avoid running workloads or applications that use xskxceiver with XDP_ADJUST_TAIL_GROW_MULTI_BUFF on affected ethernet drivers until the kernel is updated.
  • Monitor kernel logs for signs of the issue and restart affected services or systems if crashes occur.

Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart