In the Linux kernel, the following vulnerability has been resolved:
e1000: fix OOB in e1000tbishould_accept()
In e1000tbishouldaccept() we read the last byte of the frame via 'data[length - 1]' to evaluate the TBI workaround. If the descriptor- reported length is zero or larger than the actual RX buffer size, this read goes out of bounds and can hit unrelated slab objects. The issue is observed from the NAPI receive path (e1000cleanrxirq):
================================================================== BUG: KASAN: slab-out-of-bounds in e1000tbishould_accept+0x610/0x790 Read of size 1 at addr ffff888014114e54 by task sshd/363
CPU: 0 PID: 363 Comm: sshd Not tainted 5.18.0-rc1 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 Call Trace: <IRQ> dumpstacklvl+0x5a/0x74 printaddressdescription+0x7b/0x440 printreport+0x101/0x200 kasanreport+0xc1/0xf0 e1000tbishouldaccept+0x610/0x790 e1000cleanrxirq+0xa8c/0x1110 e1000clean+0xde2/0x3c10 _napipoll+0x98/0x380 netrxaction+0x491/0xa20 _dosoftirq+0x2c9/0x61d dosoftirq+0xd1/0x120 </IRQ> <TASK> _localbhenableip+0xfe/0x130 ipfinishoutput2+0x7d5/0xb00 _ipqueuexmit+0xe24/0x1ab0 _tcptransmitskb+0x1bcb/0x3340 tcpwritexmit+0x175d/0x6bd0 _tcppushpendingframes+0x7b/0x280 tcpsendmsglocked+0x2e4f/0x32d0 tcpsendmsg+0x24/0x40 sockwriteiter+0x322/0x430 vfswrite+0x56c/0xa60 ksyswrite+0xd1/0x190 dosyscall64+0x43/0x90 entrySYSCALL64afterhwframe+0x44/0xae RIP: 0033:0x7f511b476b10 Code: 73 01 c3 48 8b 0d 88 d3 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d f9 2b 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 8e 9b 01 00 48 89 04 24 RSP: 002b:00007ffc9211d4e8 EFLAGS: 00000246 ORIGRAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000004024 RCX: 00007f511b476b10 RDX: 0000000000004024 RSI: 0000559a9385962c RDI: 0000000000000003 RBP: 0000559a9383a400 R08: fffffffffffffff0 R09: 0000000000004f00 R10: 0000000000000070 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffc9211d57f R14: 0000559a9347bde7 R15: 0000000000000003 </TASK> Allocated by task 1: _kasankrealloc+0x131/0x1c0 krealloc+0x90/0xc0 addsysfsparam+0xcb/0x8a0 kerneladdsysfsparam+0x81/0xd4 paramsysfsbuiltin+0x138/0x1a6 paramsysfsinit+0x57/0x5b dooneinitcall+0x104/0x250 doinitcalllevel+0x102/0x132 doinitcalls+0x46/0x74 kernelinitfreeable+0x28f/0x393 kernelinit+0x14/0x1a0 retfromfork+0x22/0x30 The buggy address belongs to the object at ffff888014114000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 1620 bytes to the right of 2048-byte region [ffff888014114000, ffff888014114800] The buggy address belongs to the physical page: page:ffffea0000504400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14110 head:ffffea0000504400 order:3 compoundmapcount:0 compound_pincount:0 flags: 0x100000000010200(slab|head|node=0|zone=1) raw: 0100000000010200 0000000000000000 dead000000000001 ffff888013442000 raw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000
This happens because the TBI check unconditionally dereferences the last byte without validating the reported length first:
u8 last_byte = *(data + length - 1);
Fix by rejecting the frame early if the length is zero, or if it exceeds adapter->rxbufferlen. This preserves the TBI workaround semantics for valid frames and prevents touching memory beyond the RX buffer.
{
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/71xxx/CVE-2025-71093.json",
"cna_assigner": "Linux"
}