CVE-2026-98095: af_packet: Don't cast tpacket_hdr.tp_len to int in tpacket_parse_header().
In the Linux kernel, the following vulnerability has been resolved:
afpacket: Don't cast tpackethdr.tplen to int in tpacketparseheader().
syzbot reported BUG() in socksendmsgnosec(). [0]
The problem is that tpacketparseheader() casts user-provided tpackethdr.tplen, which is u32, to int.
If the length is larger than INTMAX, the following condition in tpacketparseheader() passes,
if (unlikely(tplen > sizemax))
and any negative value can be returned to the caller, up to socksendmsgnosec().
The repro set tpackethdr.tplen to 0xfffffdef, which is cast to -EIOCBQUEUED (-529), triggering BUG() in socksendmsgnosec().
(uint64t)0x200000000008 = 0xfffffdef; ... syscall(NRwrite, /fd=/r[0], /buf=/0x200000000000ul, /count=/1ul);
Let's define the local tplen as u32 in tpacketparseheader().
[0]: kernel BUG at net/socket.c:803! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 5628 Comm: syz-executor176 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/24/2026 RIP: 0010:socksendmsgnosec+0x145/0x180 net/socket.c:803 Code: 06 67 48 0f b9 3a eb 95 e8 e8 3a 22 f8 48 89 df 4c 89 f6 4c 89 e2 4d 89 fb 2e e8 32 a5 5c 16 e9 51 ff ff ff e8 cc 3a 22 f8 90 <0f> 0b e8 c4 3a 22 f8 48 83 c3 18 48 89 d8 48 c1 e8 03 42 80 3c 28 RSP: 0018:ffffc90003aefb48 EFLAGS: 00010293 RAX: ffffffff89a578d4 RBX: ffff8880764c67c0 RCX: ffff88807fb23e80 RDX: 0000000000000000 RSI: 00000000fffffdef RDI: 00000000fffffdef RBP: 00000000fffffdef R08: ffffc90003aef747 R09: 1ffff9200075dee8 R10: dffffc0000000000 R11: fffff5200075dee9 R12: 0000000000000001 R13: dffffc0000000000 R14: ffffc90003aefbc0 R15: ffffffff8aac4310 FS: 000055559101b400(0000) GS:ffff888124ce0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000000210 CR3: 0000000073dca000 CR4: 00000000003526f0 Call Trace: <TASK> socksendmsg net/socket.c:815 [inline] sockwriteiter+0x2de/0x3e0 net/socket.c:1266 newsyncwrite fs/readwrite.c:595 [inline] vfswrite+0x612/0xba0 fs/readwrite.c:687 ksyswrite+0x150/0x270 fs/readwrite.c:739 dosyscallx64 arch/x86/entry/syscall64.c:61 [inline] dosyscall64+0x166/0x520 arch/x86/entry/syscall64.c:84 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f173130ecb9 Code: c0 79 93 eb d5 48 8d 7c 1d 00 eb 99 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 d8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffd67e44248 EFLAGS: 00000246 ORIGRAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000200000000000 RCX: 00007f173130ecb9 RDX: 0000000000000001 RSI: 0000200000000000 RDI: 0000000000000003 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffd67e44388 R13: 0000000000000002 R14: 00002000000000c0 R15: 0000000000000002 </TASK>
Affected Software
Event History
Frequently Asked Questions
What does an attacker need to do to trigger the failure?
They need to supply a crafted tpacket_hdr.tp_len value larger than INT_MAX through the af_packet path. The reported reproducer used 0xfffffdef, which becomes a negative integer value after the unsafe cast.
What is the observed impact of successful triggering?
The crafted length can propagate as a negative return value to sock_sendmsg_nosec(), where it triggered a kernel BUG at net/socket.c:803. The report shows an invalid-opcode kernel oops.
How can I tell whether a system is exhibiting this issue?
Look for kernel BUG or invalid-opcode oops reports involving sock_sendmsg_nosec at net/socket.c:803, particularly where af_packet processing and a negative value such as -EIOCBQUEUED are present in the failure path.