OESA-2025-2805

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

sctp: handle the error returned from sctpauthasocinitactive_key

When it returns an error from sctpauthasocinitactivekey(), the activekey is actually not updated. The old sh_key will be freeed while it's still used as active key in asoc. Then an use-after-free will be triggered when sending patckets, as found by syzbot:

sctpauthshkeyhold+0x22/0xa0 net/sctp/auth.c:112 sctpsetownerw net/sctp/socket.c:132 [inline] sctpsendmsgtoasoc+0xbd5/0x1a20 net/sctp/socket.c:1863 sctpsendmsg+0x1053/0x1d50 net/sctp/socket.c:2025 inetsendmsg+0x99/0xe0 net/ipv4/afinet.c:819 socksendmsgnosec net/socket.c:714 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:734

This patch is to fix it by not replacing the shkey when it returns errors from sctpauthasocinitactivekey() in sctpauthsetkey(). For sctpauthsetactivekey(), old activekeyid will be set back to asoc->activekey_id when the same thing happens.(CVE-2022-50243)

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

igb: Do not free q_vector unless new one was allocated

Avoid potential use-after-free condition under memory pressure. If the kzalloc() fails, qvector will be freed but left in the original adapter->qvector[v_idx] array position.(CVE-2022-50252)

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

wifi: brcmfmac: Fix potential stack-out-of-bounds in brcmfcpreinit_dcmds()

This patch fixes a stack-out-of-bounds read in brcmfmac that occurs when 'buf' that is not null-terminated is passed as an argument of strsep() in brcmfcpreinitdcmds(). This buffer is filled with a firmware version string by memcpy() in brcmffiliovardata_get(). The patch ensures buf is null-terminated.

Found by a modified version of syzkaller.

[ 47.569679][ T1897] brcmfmac: brcmffwallocrequest: using brcm/brcmfmac43236b for chip BCM43236/3 [ 47.582839][ T1897] brcmfmac: brcmfcprocessclmblob: no clmblob available (err=-2), device may have limited channels available [ 47.601565][ T1897] ================================================================== [ 47.602574][ T1897] BUG: KASAN: stack-out-of-bounds in strsep+0x1b2/0x1f0 [ 47.603447][ T1897] Read of size 1 at addr ffffc90001f6f000 by task kworker/0:2/1897 [ 47.604336][ T1897] [ 47.604621][ T1897] CPU: 0 PID: 1897 Comm: kworker/0:2 Tainted: G O 5.14.0+ #131 [ 47.605617][ T1897] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 [ 47.606907][ T1897] Workqueue: usbhubwq hubevent [ 47.607453][ T1897] Call Trace: [ 47.607801][ T1897] dumpstacklvl+0x8e/0xd1 [ 47.608295][ T1897] printaddressdescription.constprop.0.cold+0xf/0x334 [ 47.609009][ T1897] ? strsep+0x1b2/0x1f0 [ 47.609434][ T1897] ? strsep+0x1b2/0x1f0 [ 47.609863][ T1897] kasanreport.cold+0x83/0xdf [ 47.610366][ T1897] ? strsep+0x1b2/0x1f0 [ 47.610882][ T1897] strsep+0x1b2/0x1f0 [ 47.611300][ T1897] ? brcmffiliovardataget+0x3a/0xf0 [ 47.611883][ T1897] brcmfcpreinitdcmds+0x995/0xc40 [ 47.612434][ T1897] ? brcmfcsetjoinprefdefault+0x100/0x100 [ 47.613078][ T1897] ? rcureadlockschedheld+0xa1/0xd0 [ 47.613662][ T1897] ? rcureadlockbhheld+0xb0/0xb0 [ 47.614208][ T1897] ? lockacquire+0x19d/0x4e0 [ 47.614704][ T1897] ? findheldlock+0x2d/0x110 [ 47.615236][ T1897] ? brcmfusbdeq+0x1a7/0x260 [ 47.615741][ T1897] ? brcmfusbrxfillall+0x5a/0xf0 [ 47.616288][ T1897] brcmfattach+0x246/0xd40 [ 47.616758][ T1897] ? wiphynewnm+0x1703/0x1dd0 [ 47.617280][ T1897] ? kmemdup+0x43/0x50 [ 47.617720][ T1897] brcmfusbprobe+0x12de/0x1690 [ 47.618244][ T1897] ? brcmfusbdevqinit.constprop.0+0x470/0x470 [ 47.618901][ T1897] usbprobeinterface+0x2aa/0x760 [ 47.619429][ T1897] ? usbprobedevice+0x250/0x250 [ 47.619950][ T1897] reallyprobe+0x205/0xb70 [ 47.620435][ T1897] ? driverallowsasyncprobing+0x130/0x130 [ 47.621048][ T1897] _driverprobedevice+0x311/0x4b0 [ 47.621595][ T1897] ? driverallowsasyncprobing+0x130/0x130 [ 47.622209][ T1897] driverprobedevice+0x4e/0x150 [ 47.622739][ T1897] _deviceattachdriver+0x1cc/0x2a0 [ 47.623287][ T1897] busforeachdrv+0x156/0x1d0 [ 47.623796][ T1897] ? busrescandevices+0x30/0x30 [ 47.624309][ T1897] ? lockdephardirqsonprepare+0x273/0x3e0 [ 47.624907][ T1897] ? tracehardirqson+0x46/0x160 [ 47.625437][ T1897] _deviceattach+0x23f/0x3a0 [ 47.625924][ T1897] ? devicebinddriver+0xd0/0xd0 [ 47.626433][ T1897] ? kobjectueventenv+0x287/0x14b0 [ 47.627057][ T1897] busprobedevice+0x1da/0x290 [ 47.627557][ T1897] deviceadd+0xb7b/0x1eb0 [ 47.628027][ T1897] ? waitforcompletion+0x290/0x290 [ 47.628593][ T1897] ? _fwdevlinklinktosuppliers+0x5a0/0x5a0 [ 47.629249][ T1897] usbsetconfiguration+0xf59/0x16f0 [ 47.629829][ T1897] usbgenericdriverprobe+0x82/0xa0 [ 47.630385][ T1897] usbprobedevice+0xbb/0x250 [ 47.630927][ T1897] ? usbsuspend+0x590/0x590 [ 47.631397][ T1897] reallyprobe+0x205/0xb70 [ 47.631855][ T1897] ? driverallowsasyncprobing+0x130/0x130 [ 47.632469][ T1897] _driverprobe_device+0x311/0x4b0 [ 47.633002][ ---truncated---(CVE-2022-50258)

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

wifi: brcmfmac: fix potential memory leak in brcmfnetdevstart_xmit()

The brcmfnetdevstartxmit() returns NETDEVTXOK without freeing skb in case of pskbexpandhead() fails, add devkfree_skb() to fix it. Compile tested only.(CVE-2022-50321)

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

tipc: fix a null-ptr-deref in tipctopsrvaccept

syzbot found a crash in tipctopsrvaccept:

KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] Workqueue: tipcrcv tipctopsrvaccept RIP: 0010:kernelaccept+0x22d/0x350 net/socket.c:3487 Call Trace: <TASK> tipctopsrvaccept+0x197/0x280 net/tipc/topsrv.c:460 processonework+0x991/0x1610 kernel/workqueue.c:2289 workerthread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e4/0x3a0 kernel/kthread.c:376 retfromfork+0x1f/0x30 arch/x86/entry/entry64.S:306

It was caused by srv->listener that might be set to null by tipctopsrvstop() in net .exit whereas it's still used in tipctopsrvaccept() worker.

srv->listener is protected by srv->idrlock in tipctopsrvstop(), so add a check for srv->listener under srv->idrlock in tipctopsrvaccept() to avoid the null-ptr-deref. To ensure the lsock is not released during the tipctopsrvaccept(), move sockrelease() after tipctopsrvworkstop() where it's waiting until the tipctopsrvaccept worker to be done.

Note that skcallbacklock is used to protect sk->skuserdata instead of srv->listener, and it should check srv in tipctopsrvlistenerdataready() instead. This also ensures that no more tipctopsrvaccept worker will be started after tipcconnclose() is called in tipctopsrvstop() where it sets sk->skuserdata to null.(CVE-2022-50555)

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

igb: Fix igb_down hung on surprise removal

In a setup where a Thunderbolt hub connects to Ethernet and a display through USB Type-C, users may experience a hung task timeout when they remove the cable between the PC and the Thunderbolt hub. This is because the igbdown function is called multiple times when the Thunderbolt hub is unplugged. For example, the igbioerrordetected triggers the first call, and the igbremove triggers the second call. The second call to igbdown will block at napisynchronize. Here's the call trace: _schedule+0x3b0/0xddb ? _modtimer+0x164/0x5d3 schedule+0x44/0xa8 scheduletimeout+0xb2/0x2a4 ? runlocaltimers+0x4e/0x4e msleep+0x31/0x38 igbdown+0x12c/0x22a [igb 6615058754948bfde0bf01429257eb59f13030d4] _igbclose+0x6f/0x9c [igb 6615058754948bfde0bf01429257eb59f13030d4] igbclose+0x23/0x2b [igb 6615058754948bfde0bf01429257eb59f13030d4] _devclosemany+0x95/0xec devclosemany+0x6e/0x103 unregisternetdevicemany+0x105/0x5b1 unregisternetdevicequeue+0xc2/0x10d unregisternetdev+0x1c/0x23 igbremove+0xa7/0x11c [igb 6615058754948bfde0bf01429257eb59f13030d4] pcideviceremove+0x3f/0x9c devicereleasedriverinternal+0xfe/0x1b4 pcistopbusdevice+0x5b/0x7f pcistopbusdevice+0x30/0x7f pcistopbusdevice+0x30/0x7f pcistopandremovebusdevice+0x12/0x19 pciehpunconfiguredevice+0x76/0xe9 pciehpdisableslot+0x6e/0x131 pciehphandlepresenceorlinkchange+0x7a/0x3f7 pciehpist+0xbe/0x194 irqthreadfn+0x22/0x4d ? irqthread+0x1fd/0x1fd irqthread+0x17b/0x1fd ? irqforcedthreadfn+0x5f/0x5f kthread+0x142/0x153 ? _irqgetirqchipstate+0x46/0x46 ? kthreadassociateblkcg+0x71/0x71 retfromfork+0x1f/0x30

In this case, igbioerror_detected detaches the network interface and requests a PCIE slot reset, however, the PCIE reset callback is not being invoked and thus the Ethernet connection breaks down. As the PCIE error in this case is a non-fatal one, requesting a slot reset can be avoided. This patch fixes the task hung issue and preserves Ethernet connection by ignoring non-fatal PCIE errors.(CVE-2023-53148)

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

wifi: cfg80211: Fix use after free for wext

Key information in wext.connect is not reset on (re)connect and can hold data from a previous connection.

Reset key data to avoid that drivers or mac80211 incorrectly detect a WEP connection request and access the freed or already reused memory.

Additionally optimize cfg80211smeconnect() and avoid an useless schedule of conn_work.(CVE-2023-53153)

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

jfs: jfsdmap: Validate dbl2nbperpage while mounting

In jfsdmap.c at line 381, BLKTODMAP is used to get a logical block number inside dbFree(). dbl2nbperpage, which is the log2 number of blocks per page, is passed as an argument to BLKTODMAP which uses it for shifting.

Syzbot reported a shift out-of-bounds crash because db_l2nbperpage is too big. This happens because the large value is set without any validation in dbMount() at line 181.

Thus, make sure that db_l2nbperpage is correct while mounting.

Max number of blocks per page = Page size / Min block size => log2(Max num_block per page) = log2(Page size / Min block size) = log2(Page size) - log2(Min block size)

=> Max db_l2nbperpage = L2PSIZE - L2MINBLOCKSIZE(CVE-2023-53222)

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

net: vlan: fix VLAN 0 refcount imbalance of toggling filtering during runtime

Assuming the "rx-vlan-filter" feature is enabled on a net device, the 8021q module will automatically add or remove VLAN 0 when the net device is put administratively up or down, respectively. There are a couple of problems with the above scheme.

The first problem is a memory leak that can happen if the "rx-vlan-filter" feature is disabled while the device is running:

# ip link add bond1 up type bond mode 0 # ethtool -K bond1 rx-vlan-filter off # ip link del dev bond1

When the device is put administratively down the "rx-vlan-filter" feature is disabled, so the 8021q module will not remove VLAN 0 and the memory will be leaked [1].

Another problem that can happen is that the kernel can automatically delete VLAN 0 when the device is put administratively down despite not adding it when the device was put administratively up since during that time the "rx-vlan-filter" feature was disabled. null-ptr-unref or bugon[2] will be triggered by unregistervlan_dev() for refcount imbalance if toggling filtering during runtime:

$ ip link add bond0 type bond mode 0 $ ip link add link bond0 name vlan0 type vlan id 0 protocol 802.1q $ ethtool -K bond0 rx-vlan-filter off $ ifconfig bond0 up $ ethtool -K bond0 rx-vlan-filter on $ ifconfig bond0 down $ ip link del vlan0

Root cause is as below: step1: add vlan0 for realdev, such as bond, team. registervlandev vlanvidadd(realdev,htons(ETHP8021Q),0) //refcnt=1 step2: disable vlan filter feature and enable realdev step3: change filter from 0 to 1 vlandeviceevent vlanfilterpushvids ndovlanrxaddvid //No refcnt added to realdev vlan0 step4: realdev down vlandeviceevent vlanviddel(dev, htons(ETHP8021Q), 0); //refcnt=0 vlaninforcufree //free vlan0 step5: delete vlan0 unregistervlandev BUGON(!vlaninfo); //vlaninfo is null

Fix both problems by noting in the VLAN info whether VLAN 0 was automatically added upon NETDEVUP and based on that decide whether it should be deleted upon NETDEVDOWN, regardless of the state of the "rx-vlan-filter" feature.

[1] unreferenced object 0xffff8880068e3100 (size 256): comm "ip", pid 384, jiffies 4296130254 hex dump (first 32 bytes): 00 20 30 0d 80 88 ff ff 00 00 00 00 00 00 00 00 . 0............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 81ce31fa): kmalloccachenoprof+0x2b5/0x340 vlanvidadd+0x434/0x940 vlandeviceevent.cold+0x75/0xa8 notifiercallchain+0xca/0x150 _devnotifyflags+0xe3/0x250 rtnlconfigurelink+0x193/0x260 rtnlnewlinkcreate+0x383/0x8e0 _rtnlnewlink+0x22c/0xa40 rtnlnewlink+0x627/0xb00 rtnetlinkrcvmsg+0x6fb/0xb70 netlinkrcvskb+0x11f/0x350 netlinkunicast+0x426/0x710 netlinksendmsg+0x75a/0xc20 _socksendmsg+0xc1/0x150 syssendmsg+0x5aa/0x7b0 _syssendmsg+0xfc/0x180

[2] kernel BUG at net/8021q/vlan.c:99! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 382 Comm: ip Not tainted 6.16.0-rc3 #61 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:unregistervlandev (net/8021q/vlan.c:99 (discriminator 1)) RSP: 0018:ffff88810badf310 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88810da84000 RCX: ffffffffb47ceb9a RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88810e8b43c8 RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6cefe80 R10: ffffffffb677f407 R11: ffff88810badf3c0 R12: ffff88810e8b4000 R13: 0000000000000000 R14: ffff88810642a5c0 R15: 000000000000017e FS: 00007f1ff68c20c0(0000) GS:ffff888163a24000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1ff5dad240 CR3: 0000000107e56000 CR4: 00000000000006f0 Call Trace: <TASK ---truncated---(CVE-2025-38470)

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

net/packet: fix a race in packetsetring() and packet_notifier()

When packetsetring() releases po->bindlock, another thread can run packetnotifier() and process an NETDEV_UP event.

This race and the fix are both similar to that of commit 15fe076edea7 ("net/packet: fix a race in packetbind() and packetnotifier()").

There too the packetnotifier NETDEVUP event managed to run while a po->bind_lock critical section had to be temporarily released. And the fix was similarly to temporarily set po->num to zero to keep the socket unhooked until the lock is retaken.

The po->bindlock in packetsetring and packetnotifier precede the introduction of git history.(CVE-2025-38617)