OESA-2026-1276

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

ipv6: ensure sane device mtu in tunnels

Another syzbot report [1] with no reproducer hints at a bug in ip6_gre tunnel (dev:ip6gretap0)

Since ipv6 mcast code makes sure to read dev->mtu once and applies a sanity check on it (see commit b9b312a7a451 "ipv6: mcast: better catch silly mtu values"), a remaining possibility is that a layer is able to set dev->mtu to an underflowed value (high order bit set).

This could happen indeed in ip6gretnllinkconfigroute(), ip6tnllinkconfig() and ipip6tunnelbinddev()

Make sure to sanitize mtu value in a local variable before it is written once on dev->mtu, as lockless readers could catch wrong temporary value.

[1] skbuff: skboverpanic: text:ffff80000b7a2f38 len:40 put:40 head:ffff000149dcf200 data:ffff000149dcf2b0 tail:0xd8 end:0xc0 dev:ip6gretap0 ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:120 Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 1 PID: 10241 Comm: kworker/1:1 Not tainted 6.0.0-rc7-syzkaller-18095-gbbed346d5a96 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/30/2022 Workqueue: mld mldifcwork pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skbpanic+0x4c/0x50 net/core/skbuff.c:116 lr : skbpanic+0x4c/0x50 net/core/skbuff.c:116 sp : ffff800020dd3b60 x29: ffff800020dd3b70 x28: 0000000000000000 x27: ffff00010df2a800 x26: 00000000000000c0 x25: 00000000000000b0 x24: ffff000149dcf200 x23: 00000000000000c0 x22: 00000000000000d8 x21: ffff80000b7a2f38 x20: ffff00014c2f7800 x19: 0000000000000028 x18: 00000000000001a9 x17: 0000000000000000 x16: ffff80000db49158 x15: ffff000113bf1a80 x14: 0000000000000000 x13: 00000000ffffffff x12: ffff000113bf1a80 x11: ff808000081c0d5c x10: 0000000000000000 x9 : 73f125dc5c63ba00 x8 : 73f125dc5c63ba00 x7 : ffff800008161d1c x6 : 0000000000000000 x5 : 0000000000000080 x4 : 0000000000000001 x3 : 0000000000000000 x2 : ffff0001fefddcd0 x1 : 0000000100000000 x0 : 0000000000000089 Call trace: skbpanic+0x4c/0x50 net/core/skbuff.c:116 skboverpanic net/core/skbuff.c:125 [inline] skbput+0xd4/0xdc net/core/skbuff.c:2049 ip6mchdr net/ipv6/mcast.c:1714 [inline] mldnewpack+0x14c/0x270 net/ipv6/mcast.c:1765 addgrhead net/ipv6/mcast.c:1851 [inline] addgrec+0xa20/0xae0 net/ipv6/mcast.c:1989 mldsendcr+0x438/0x5a8 net/ipv6/mcast.c:2115 mldifcwork+0x38/0x290 net/ipv6/mcast.c:2653 processonework+0x2d8/0x504 kernel/workqueue.c:2289 workerthread+0x340/0x610 kernel/workqueue.c:2436 kthread+0x12c/0x158 kernel/kthread.c:376 retfromfork+0x10/0x20 arch/arm64/kernel/entry.S:860 Code: 91011400 aa0803e1 a90027ea 94373093 (d4210000)(CVE-2022-50816)

In the Linux kernel, the following vulnerability has been resolved:

tpm: tpmtis: Add the missed acpiput_table() to fix memory leak

In checkacpitpm2(), we get the TPM2 table just to make sure the table is there, not used after the init, so the acpiputtable() should be added to release the ACPI memory.(CVE-2022-50824)

In the Linux kernel, the following vulnerability has been resolved:

mmc: via-sdmmc: fix return value check of mmcaddhost()

mmcaddhost() may return error, if we ignore its return value, it will lead two issues: 1. The memory that allocated in mmcallochost() is leaked. 2. In the remove() path, mmcremovehost() will be called to delete device, but it's not added yet, it will lead a kernel crash because of null-ptr-deref in device_del().

Fix this by checking the return value and goto error path which will call mmcfreehost().(CVE-2022-50846)

In the Linux kernel, the following vulnerability has been resolved:

scsi: ipr: Fix WARNING in ipr_init()

iprinit() will not call unregisterrebootnotifier() when pciregisterdriver() fails, which causes a WARNING. Call unregisterrebootnotifier() when pciregister_driver() fails.

notifier callback iprhalt [ipr] already registered WARNING: CPU: 3 PID: 299 at kernel/notifier.c:29 notifierchainregister+0x16d/0x230 Modules linked in: ipr(+) xhcipcirenesas xhcihcd ehcihcd usbcore ledclass gpusched drmbuddy video wmi drmttmhelper ttm drmdisplayhelper drmkmshelper drm drmpanelorientationquirks agpgart cfbft CPU: 3 PID: 299 Comm: modprobe Tainted: G W 6.1.0-rc1-00190-g39508d23b672-dirty #332 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 RIP: 0010:notifierchainregister+0x16d/0x230 Call Trace: <TASK> _blockingnotifierchainregister+0x73/0xb0 iprinit+0x30/0x1000 [ipr] dooneinitcall+0xdb/0x480 doinitmodule+0x1cf/0x680 loadmodule+0x6a50/0x70a0 _dosysfinitmodule+0x12f/0x1c0 dosyscall64+0x3f/0x90 entrySYSCALL64after_hwframe+0x63/0xcd(CVE-2022-50850)

In the Linux kernel, the following vulnerability has been resolved:

RDMA/rxe: Fix NULL-ptr-deref in rxeqpdo_cleanup() when socket create failed

There is a null-ptr-deref when mount.cifs over rdma:

BUG: KASAN: null-ptr-deref in rxeqpdocleanup+0x2f3/0x360 [rdmarxe] Read of size 8 at addr 0000000000000018 by task mount.cifs/3046

CPU: 2 PID: 3046 Comm: mount.cifs Not tainted 6.1.0-rc5+ #62 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc3 Call Trace: <TASK> dumpstacklvl+0x34/0x44 kasanreport+0xad/0x130 rxeqpdocleanup+0x2f3/0x360 [rdmarxe] executeinprocesscontext+0x25/0x90 _rxecleanup+0x101/0x1d0 [rdmarxe] rxecreateqp+0x16a/0x180 [rdmarxe] createqp.part.0+0x27d/0x340 ibcreateqpkernel+0x73/0x160 rdmacreateqp+0x100/0x230 smbdgetconnection+0x752/0x20f0 smbdgetconnection+0x21/0x40 cifsgettcpsession+0x8ef/0xda0 mountgetconns+0x60/0x750 cifsmount+0x103/0xd00 cifssmb3domount+0x1dd/0xcb0 smb3gettree+0x1d5/0x300 vfsgettree+0x41/0xf0 pathmount+0x9b3/0xdd0 _x64sysmount+0x190/0x1d0 dosyscall64+0x35/0x80 entrySYSCALL64afterhwframe+0x46/0xb0

The root cause of the issue is the socket create failed in rxeqpinit_req().

So move the reset rxeqpdo_cleanup() after the NULL ptr check.(CVE-2022-50885)

In the Linux kernel, the following vulnerability has been resolved:

ubi: Fix possible null-ptr-deref in ubifreevolume()

It willl cause null-ptr-deref in the following case:

uifinit() ubiaddvolume() cdevadd() -> if it fails, call killvolumes() deviceregister()

killvolumes() -> if ubiaddvolume() fails call this function ubifreevolume() cdevdel() device_unregister() -> trying to delete a not added device, it causes null-ptr-deref

So in ubifreevolume(), it delete devices whether they are added or not, it will causes null-ptr-deref.

Handle the error case whlie calling ubiaddvolume() to fix this problem. If add volume fails, set the corresponding vol to null, so it can not be accessed in killvolumes() and release the resource in ubiadd_volume() error path.(CVE-2023-54087)

In the Linux kernel, the following vulnerability has been resolved:

usb: rndishost: Secure rndisquery check against int overflow

Variables off and len typed as uint32 in rndisquery function are controlled by incoming RNDIS response message thus their value may be manipulated. Setting off to a unexpectetly large value will cause the sum with len and 8 to overflow and pass the implemented validation step. Consequently the response pointer will be referring to a location past the expected buffer boundaries allowing information leakage e.g. via RNDISOID8023PERMANENTADDRESS OID.(CVE-2023-54110)

In the Linux kernel, the following vulnerability has been resolved:

scsi: qla2xxx: Array index may go out of bound

Klocwork reports array 'vha->host_str' of size 16 may use index value(s) 16..19. Use snprintf() instead of sprintf().(CVE-2023-54179)

In the Linux kernel, the following vulnerability has been resolved:

net: Fix load-tearing on sk->skstamp in sockrecv_cmsgs().

KCSAN found a data race in sockrecvcmsgs() where the read access to sk->skstamp needs READONCE().

BUG: KCSAN: data-race in packetrecvmsg / packetrecvmsg

write (marked) to 0xffff88803c81f258 of 8 bytes by task 19171 on cpu 0: sockwritetimestamp include/net/sock.h:2670 [inline] sockrecvcmsgs include/net/sock.h:2722 [inline] packetrecvmsg+0xb97/0xd00 net/packet/afpacket.c:3489 sockrecvmsgnosec net/socket.c:1019 [inline] sockrecvmsg+0x11a/0x130 net/socket.c:1040 sockreaditer+0x176/0x220 net/socket.c:1118 callreaditer include/linux/fs.h:1845 [inline] newsyncread fs/readwrite.c:389 [inline] vfsread+0x5e0/0x630 fs/readwrite.c:470 ksysread+0x163/0x1a0 fs/readwrite.c:613 _dosysread fs/readwrite.c:623 [inline] _sesysread fs/readwrite.c:621 [inline] _x64sysread+0x41/0x50 fs/readwrite.c:621 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x3b/0x90 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x72/0xdc

read to 0xffff88803c81f258 of 8 bytes by task 19183 on cpu 1: sockrecvcmsgs include/net/sock.h:2721 [inline] packetrecvmsg+0xb64/0xd00 net/packet/afpacket.c:3489 sockrecvmsgnosec net/socket.c:1019 [inline] sockrecvmsg+0x11a/0x130 net/socket.c:1040 sockreaditer+0x176/0x220 net/socket.c:1118 callreaditer include/linux/fs.h:1845 [inline] newsyncread fs/readwrite.c:389 [inline] vfsread+0x5e0/0x630 fs/readwrite.c:470 ksysread+0x163/0x1a0 fs/readwrite.c:613 _dosysread fs/readwrite.c:623 [inline] _sesysread fs/readwrite.c:621 [inline] _x64sysread+0x41/0x50 fs/readwrite.c:621 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x3b/0x90 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x72/0xdc

value changed: 0xffffffffc4653600 -> 0x0000000000000000

Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 19183 Comm: syz-executor.5 Not tainted 6.3.0-rc7-02330-gca6270c12e20 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014(CVE-2023-54218)

In the Linux kernel, the following vulnerability has been resolved:

bpf: Address KCSAN report on bpflrulist

KCSAN reported a data-race when accessing node->ref. Although node->ref does not have to be accurate, take this chance to use a more common READONCE() and WRITEONCE() pattern instead of data_race().

There is an existing bpflrunodeisref() and bpflrunodesetref(). This patch also adds bpflrunodeclearref() to do the WRITE_ONCE(node->ref, 0) also.

================================================================== BUG: KCSAN: data-race in _bpflrulistrotate / _htablrupercpumapupdateelem

write to 0xffff888137038deb of 1 bytes by task 11240 on cpu 1: _bpflrunodemove kernel/bpf/bpflrulist.c:113 [inline] _bpflrulistrotateactive kernel/bpf/bpflrulist.c:149 [inline] _bpflrulistrotate+0x1bf/0x750 kernel/bpf/bpflrulist.c:240 bpflrulistpopfreetolocal kernel/bpf/bpflrulist.c:329 [inline] bpfcommonlrupopfree kernel/bpf/bpflrulist.c:447 [inline] bpflrupopfree+0x638/0xe20 kernel/bpf/bpflrulist.c:499 prealloclrupop kernel/bpf/hashtab.c:290 [inline] _htablrupercpumapupdateelem+0xe7/0x820 kernel/bpf/hashtab.c:1316 bpfpercpuhashupdate+0x5e/0x90 kernel/bpf/hashtab.c:2313 bpfmapupdatevalue+0x2a9/0x370 kernel/bpf/syscall.c:200 genericmapupdatebatch+0x3ae/0x4f0 kernel/bpf/syscall.c:1687 bpfmapdobatch+0x2d9/0x3d0 kernel/bpf/syscall.c:4534 _sysbpf+0x338/0x810 _dosysbpf kernel/bpf/syscall.c:5096 [inline] _sesysbpf kernel/bpf/syscall.c:5094 [inline] _x64sysbpf+0x43/0x50 kernel/bpf/syscall.c:5094 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x41/0xc0 arch/x86/entry/common.c:80 entrySYSCALL64after_hwframe+0x63/0xcd

read to 0xffff888137038deb of 1 bytes by task 11241 on cpu 0: bpflrunodesetref kernel/bpf/bpflrulist.h:70 [inline] _htablrupercpumapupdateelem+0x2f1/0x820 kernel/bpf/hashtab.c:1332 bpfpercpuhashupdate+0x5e/0x90 kernel/bpf/hashtab.c:2313 bpfmapupdatevalue+0x2a9/0x370 kernel/bpf/syscall.c:200 genericmapupdatebatch+0x3ae/0x4f0 kernel/bpf/syscall.c:1687 bpfmapdobatch+0x2d9/0x3d0 kernel/bpf/syscall.c:4534 _sysbpf+0x338/0x810 _dosysbpf kernel/bpf/syscall.c:5096 [inline] _sesysbpf kernel/bpf/syscall.c:5094 [inline] _x64sysbpf+0x43/0x50 kernel/bpf/syscall.c:5094 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x41/0xc0 arch/x86/entry/common.c:80 entrySYSCALL64after_hwframe+0x63/0xcd

value changed: 0x01 -> 0x00

Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 11241 Comm: syz-executor.3 Not tainted 6.3.0-rc7-syzkaller-00136-g6a66fdd29ea1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/30/2023 ==================================================================(CVE-2023-54283)

In the Linux kernel, the following vulnerability has been resolved:

ipv4: route: Prevent rtbindexception() from rebinding stale fnhe

The sit driver's packet transmission path calls: sittunnelxmit() -> updateorcreatefnhe(), which lead to fnheremoveoldest() being called to delete entries exceeding FNHERECLAIM_DEPTH+random.

The race window is between fnheremoveoldest() selecting fnheX for deletion and the subsequent kfreercu(). During this time, the concurrent path's _mkrouteoutput() -> findexception() can fetch the soon-to-be-deleted fnheX, and rtbindexception() then binds it with a new dst using a dst_hold(). When the original fnheX is freed via RCU, the dst reference remains permanently leaked.

CPU 0 CPU 1 _mkrouteoutput() findexception() [fnheX] updateorcreatefnhe() fnheremoveoldest() [fnheX] rtbindexception() [bind dst] RCU callback [fnheX freed, dst leak]

This issue manifests as a device reference count leak and a warning in dmesg when unregistering the net device:

unregister_netdevice: waiting for sitX to become free. Usage count = N

Ido Schimmel provided the simple test validation method [1].

The fix clears 'oldest->fnhedaddr' before calling fnheflushroutes(). Since rtbind_exception() checks this field, setting it to zero prevents the stale fnhe from being reused and bound to a new dst just before it is freed.

[1] ip netns add ns1 ip -n ns1 link set dev lo up ip -n ns1 address add 192.0.2.1/32 dev lo ip -n ns1 link add name dummy1 up type dummy ip -n ns1 route add 192.0.2.2/32 dev dummy1 ip -n ns1 link add name gretap1 up arp off type gretap \ local 192.0.2.1 remote 192.0.2.2 ip -n ns1 route add 198.51.0.0/16 dev gretap1 taskset -c 0 ip netns exec ns1 mausezahn gretap1 \ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q & taskset -c 2 ip netns exec ns1 mausezahn gretap1 \ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q & sleep 10 ip netns pids ns1 | xargs kill ip netns del ns1(CVE-2025-68241)

In the Linux kernel, a buffer overflow vulnerability exists in the e1000 network driver's e1000tbishouldaccept() function. The function reads the last byte of the frame via 'data[length - 1]' to evaluate the TBI (Tunnel Bypass Identifier) 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). The root cause is that the TBI check unconditionally dereferences the last byte without validating the reported length first. The fix rejects the frame early if the length is zero or exceeds adapter->rxbufferlen, preserving the TBI workaround semantics for valid frames and preventing touching memory beyond the RX buffer.(CVE-2025-71093)