The Linux Kernel, the operating system core itself.

Security Fix(es):

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

misc: tifm: fix possible memory leak in tifm7xx1switch_media()

If deviceregister() returns error in tifm7xx1switchmedia(), name of kobject which is allocated in devsetname() called in device_add() is leaked.

Never directly free @dev after calling deviceregister(), even if it returned an error! Always use putdevice() to give up the reference initialized.(CVE-2022-50349)

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

net: hns: fix possible memory leak in hnaeaeregister()

Inject fault while probing module, if deviceregister() fails, but the refcount of kobject is not decreased to 0, the name allocated in devsetname() is leaked. Fix this by calling putdevice(), so that name can be freed in callback function kobject_cleanup().

unreferenced object 0xffff00c01aba2100 (size 128): comm "systemd-udevd", pid 1259, jiffies 4294903284 (age 294.152s) hex dump (first 32 bytes): 68 6e 61 65 30 00 00 00 18 21 ba 1a c0 00 ff ff hnae0....!...... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000034783f26>] slabpostallochook+0xa0/0x3e0 [<00000000748188f2>] _kmemcacheallocnode+0x164/0x2b0 [<00000000ab0743e8>] _kmallocnodetrackcaller+0x6c/0x390 [<000000006c0ffb13>] kvasprintf+0x8c/0x118 [<00000000fa27bfe1>] kvasprintfconst+0x60/0xc8 [<0000000083e10ed7>] kobjectsetnamevargs+0x3c/0xc0 [<000000000b87affc>] devsetname+0x7c/0xa0 [<000000003fd8fe26>] hnaeaeregister+0xcc/0x190 [hnae] [<00000000fe97edc9>] hnsdsafaeinit+0x9c/0x108 [hnsdsaf] [<00000000c36ff1eb>] hnsdsafprobe+0x548/0x748 hnsdsaf

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

ext4: avoid crash when inline data creation follows DIO write

When inode is created and written to using direct IO, there is nothing to clear the EXT4STATEMAYINLINEDATA flag. Thus when inode gets truncated later to say 1 byte and written using normal write, we will try to store the data as inline data. This confuses the code later because the inode now has both normal block and inline data allocated and the confusion manifests for example as:

kernel BUG at fs/ext4/inode.c:2721! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 359 Comm: repro Not tainted 5.19.0-rc8-00001-g31ba1e3b8305-dirty #15 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014 RIP: 0010:ext4writepages+0x363d/0x3660 RSP: 0018:ffffc90000ccf260 EFLAGS: 00010293 RAX: ffffffff81e1abcd RBX: 0000008000000000 RCX: ffff88810842a180 RDX: 0000000000000000 RSI: 0000008000000000 RDI: 0000000000000000 RBP: ffffc90000ccf650 R08: ffffffff81e17d58 R09: ffffed10222c680b R10: dfffe910222c680c R11: 1ffff110222c680a R12: ffff888111634128 R13: ffffc90000ccf880 R14: 0000008410000000 R15: 0000000000000001 FS: 00007f72635d2640(0000) GS:ffff88811b000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000565243379180 CR3: 000000010aa74000 CR4: 0000000000150eb0 Call Trace: <TASK> dowritepages+0x397/0x640 filemapfdatawritewbc+0x151/0x1b0 filewriteandwaitrange+0x1c9/0x2b0 ext4syncfile+0x19e/0xa00 vfsfsyncrange+0x17b/0x190 ext4bufferedwriteiter+0x488/0x530 ext4filewriteiter+0x449/0x1b90 vfswrite+0xbcd/0xf40 ksyswrite+0x198/0x2c0 _x64syswrite+0x7b/0x90 dosyscall64+0x3d/0x90 entrySYSCALL64after_hwframe+0x63/0xcd </TASK>

Fix the problem by clearing EXT4STATEMAYINLINEDATA when we are doing direct IO write to a file.(CVE-2022-50435)

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

iommu/vt-d: Clean up sidomain in the initdmars() error path

A splat from kmemcachedestroy() was seen with a kernel prior to commit ee2653bbe89d ("iommu/vt-d: Remove domain and devinfo mempool") when there was a failure in initdmars(), because the iommudomain cache still had objects. While the mempool code is now gone, there still is a leak of the sidomain memory if initdmars() fails. So clean up sidomain in the initdmars() error path.(CVE-2022-50482)

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

ALSA: usb-audio: Fix potential memory leaks

When the driver hits -ENOMEM at allocating a URB or a buffer, it aborts and goes to the error path that releases the all previously allocated resources. However, when -ENOMEM hits at the middle of the sync EP URB allocation loop, the partially allocated URBs might be left without released, because ep->nurbs is still zero at that point.

Fix it by setting ep->nurbs at first, so that the error handler loops over the full URB list.(CVE-2022-50484)

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

drm/mipi-dsi: Detach devices when removing the host

Whenever the MIPI-DSI host is unregistered, the code of mipidsihost_unregister() loops over every device currently found on that bus and will unregister it.

However, it doesn't detach it from the bus first, which leads to all kind of resource leaks if the host wants to perform some clean up whenever a device is detached.(CVE-2022-50489)

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

drm/radeon: Fix PCI device refcount leak in radeonatrmget_bios()

As comment of pcigetclass() says, it returns a pci_device with its refcount increased and decreased the refcount for the input parameter @from if it is not NULL.

If we break the loop in radeonatrmgetbios() with 'pdev' not NULL, we need to call pcidevput() to decrease the refcount. Add the missing pcidev_put() to avoid refcount leak.(CVE-2022-50520)

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

tipc: fix an information leak in tipctopsrvkern_subscr

Use a 8-byte write to initialize sub.usrhandle in tipctopsrvkernsubscr(), otherwise four bytes remain uninitialized when issuing setsockopt(..., SOL_TIPC, ...). This resulted in an infoleak reported by KMSAN when the packet was received:

===================================================== BUG: KMSAN: kernel-infoleak in copyout+0xbc/0x100 lib/ioviter.c:169 instrumentcopytouser ./include/linux/instrumented.h:121 copyout+0xbc/0x100 lib/ioviter.c:169 _copytoiter+0x5c0/0x20a0 lib/ioviter.c:527 copytoiter ./include/linux/uio.h:176 simplecopytoiter+0x64/0xa0 net/core/datagram.c:513 skbdatagramiter+0x123/0xdc0 net/core/datagram.c:419 skbcopydatagramiter+0x58/0x200 net/core/datagram.c:527 skbcopydatagrammsg ./include/linux/skbuff.h:3903 packetrecvmsg+0x521/0x1e70 net/packet/afpacket.c:3469 _sysrecvmsg+0x2c4/0x810 net/socket.c:? _sysrecvmsg+0x217/0x840 net/socket.c:2743 _sysrecvmsg net/socket.c:2773 _dosysrecvmsg net/socket.c:2783 _sesysrecvmsg net/socket.c:2780 _x64sysrecvmsg+0x364/0x540 net/socket.c:2780 dosyscallx64 arch/x86/entry/common.c:50 dosyscall64+0x3d/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd arch/x86/entry/entry64.S:120

...

Uninit was stored to memory at: tipcsubsubscribe+0x42d/0xb50 net/tipc/subscr.c:156 tipcconnrcvsub+0x246/0x620 net/tipc/topsrv.c:375 tipctopsrvkernsubscr+0x2e8/0x400 net/tipc/topsrv.c:579 tipcgroupcreate+0x4e7/0x7d0 net/tipc/group.c:190 tipcskjoin+0x2a8/0x770 net/tipc/socket.c:3084 tipcsetsockopt+0xae5/0xe40 net/tipc/socket.c:3201 _syssetsockopt+0x87f/0xdc0 net/socket.c:2252 _dosyssetsockopt net/socket.c:2263 _sesyssetsockopt net/socket.c:2260 _x64syssetsockopt+0xe0/0x160 net/socket.c:2260 dosyscallx64 arch/x86/entry/common.c:50 dosyscall64+0x3d/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd arch/x86/entry/entry_64.S:120

Local variable sub created at: tipctopsrvkernsubscr+0x57/0x400 net/tipc/topsrv.c:562 tipcgroup_create+0x4e7/0x7d0 net/tipc/group.c:190

Bytes 84-87 of 88 are uninitialized Memory access of size 88 starts at ffff88801ed57cd0 Data copied to user address 0000000020000400 ... =====================================================(CVE-2022-50531)

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

wifi: brcmfmac: Fix potential shift-out-of-bounds in brcmffwalloc_request()

This patch fixes a shift-out-of-bounds in brcmfmac that occurs in BIT(chiprev) when a 'chiprev' provided by the device is too large. It should also not be equal to or greater than BITSPERTYPE(u32) as we do bitwise AND with a u32 variable and BIT(chiprev). The patch adds a check that makes the function return NULL if that is the case. Note that the NULL case is later handled by the bus-specific caller, brcmfusbprobecb() or brcmfusbresetresume(), for example.

Found by a modified version of syzkaller.

UBSAN: shift-out-of-bounds in drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c shift exponent 151055786 is too large for 64-bit type 'long unsigned int' CPU: 0 PID: 1885 Comm: kworker/0:2 Tainted: G O 5.14.0+ #132 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 Workqueue: usbhubwq hubevent Call Trace: dumpstacklvl+0x57/0x7d ubsanepilogue+0x5/0x40 _ubsanhandleshiftoutofbounds.cold+0x53/0xdb ? lockchaincount+0x20/0x20 brcmffwallocrequest.cold+0x19/0x3ea ? brcmffwgetfirmwares+0x250/0x250 ? brcmfusbioctlrespwait+0x1a7/0x1f0 brcmfusbgetfwname+0x114/0x1a0 ? brcmfusbresetresume+0x120/0x120 ? number+0x6c4/0x9a0 brcmfcprocessclmblob+0x168/0x590 ? putdec+0x90/0x90 ? enableptrkeyworkfn+0x20/0x20 ? brcmfcommonpdremove+0x50/0x50 ? rcureadlockschedheld+0xa1/0xd0 brcmfcpreinitdcmds+0x673/0xc40 ? brcmfcsetjoinprefdefault+0x100/0x100 ? rcureadlockschedheld+0xa1/0xd0 ? rcureadlockbhheld+0xb0/0xb0 ? lockacquire+0x19d/0x4e0 ? findheldlock+0x2d/0x110 ? brcmfusbdeq+0x1cc/0x260 ? markheldlocks+0x9f/0xe0 ? lockdephardirqsonprepare+0x273/0x3e0 ? rawspinunlockirqrestore+0x47/0x50 ? tracehardirqson+0x1c/0x120 ? brcmfusbdeq+0x1a7/0x260 ? brcmfusbrxfillall+0x5a/0xf0 brcmfattach+0x246/0xd40 ? wiphynewnm+0x1476/0x1d50 ? kmemdup+0x30/0x40 brcmfusbprobe+0x12de/0x1690 ? brcmfusbdevqinit.constprop.0+0x470/0x470 usbprobeinterface+0x25f/0x710 reallyprobe+0x1be/0xa90 _driverprobedevice+0x2ab/0x460 ? usbmatchid.part.0+0x88/0xc0 driverprobedevice+0x49/0x120 _deviceattachdriver+0x18a/0x250 ? driverallowsasyncprobing+0x120/0x120 busforeachdrv+0x123/0x1a0 ? busrescandevices+0x20/0x20 ? lockdephardirqsonprepare+0x273/0x3e0 ? tracehardirqson+0x1c/0x120 _deviceattach+0x207/0x330 ? devicebinddriver+0xb0/0xb0 ? kobjectueventenv+0x230/0x12c0 busprobedevice+0x1a2/0x260 deviceadd+0xa61/0x1ce0 ? _mutexunlockslowpath+0xe7/0x660 ? _fwdevlinklinktosuppliers+0x550/0x550 usbsetconfiguration+0x984/0x1770 ? kernfscreatelink+0x175/0x230 usbgenericdriverprobe+0x69/0x90 usbprobedevice+0x9c/0x220 reallyprobe+0x1be/0xa90 _driverprobedevice+0x2ab/0x460 driverprobedevice+0x49/0x120 _deviceattachdriver+0x18a/0x250 ? driverallowsasyncprobing+0x120/0x120 busforeachdrv+0x123/0x1a0 ? busrescandevices+0x20/0x20 ? lockdephardirqsonprepare+0x273/0x3e0 ? tracehardirqson+0x1c/0x120 _deviceattach+0x207/0x330 ? devicebinddriver+0xb0/0xb0 ? kobjectueventenv+0x230/0x12c0 busprobedevice+0x1a2/0x260 deviceadd+0xa61/0x1ce0 ? _fwdevlinklinktosuppliers+0x550/0x550 usbnewdevice.cold+0x463/0xf66 ? hubdisconnect+0x400/0x400 ? rawspinunlockirq+0x24/0x30 hubevent+0x10d5/0x3330 ? hubportdebounce+0x280/0x280 ? _lockacquire+0x1671/0x5790 ? wqcalcnodecpumask+0x170/0x2a0 ? lockrelease+0x640/0x640 ? rcureadlockschedheld+0xa1/0xd0 ? rcureadlockbhheld+0xb0/0xb0 ? lockdephardirqsonprepare+0x273/0x3e0 processonework+0x873/0x13e0 ? lockrelease+0x640/0x640 ? pwqdecnrinflight+0x320/0x320 ? rwlockbug.part.0+0x90/0x90 workerthread+0x8b/0xd10 ? _kthread_parkme+0xd9/0x1d0 ? pr ---truncated---(CVE-2022-50551)

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

blk-mq: use quiesced elevator switch when reinitializing queues

The hctx's run_work may be racing with the elevator switch when reinitializing hardware queues. The queue is merely frozen in this context, but that only prevents requests from allocating and doesn't stop the hctx work from running. The work may get an elevator pointer that's being torn down, and can result in use-after-free errors and kernel panics (example below). Use the quiesced elevator switch instead, and make the previous one static since it is now only used locally.

nvme nvme0: resetting controller nvme nvme0: 32/0/0 default/read/poll queues BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 80000020c8861067 P4D 80000020c8861067 PUD 250f8c8067 PMD 0 Oops: 0000 [#1] SMP PTI Workqueue: kblockd blkmqrunworkfn RIP: 0010:kyberhas_work+0x29/0x70

...

Call Trace: _blkmqdodispatchsched+0x83/0x2b0 _blkmqscheddispatchrequests+0x12e/0x170 blkmqscheddispatchrequests+0x30/0x60 _blkmqrunhwqueue+0x2b/0x50 processonework+0x1ef/0x380 workerthread+0x2d/0x3e0(CVE-2022-50552)

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

wifi: ath9k: don't allow to overwrite ENDPOINT0 attributes

A bad USB device is able to construct a service connection response message with target endpoint being ENDPOINT0 which is reserved for HTCCTRLRSVD_SVC and should not be modified to be used for any other services.

Reject such service connection responses.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2023-53185)

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

wifi: ath9k: hifusb: clean up skbs if ath9khifusbrx_stream() fails

Syzkaller detected a memory leak of skbs in ath9khifusbrxstream(). While processing skbs in ath9khifusbrxstream(), the already allocated skbs in skbpool are not freed if ath9khifusbrxstream() fails. If we have an incorrect pktlen or pkttag, the input skb is considered invalid and dropped. All the associated packets already in skbpool should be dropped and freed. Added a comment describing this issue.

The patch also makes remainskb NULL after being processed so that it cannot be referenced after potential free. The initialization of hifdev fields which are associated with remainskb (rxremainlen, rxtransferlen and rxpadlen) is moved after a new remainskb is allocated.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2023-53199)

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

can: bcm: bcmtxsetup(): fix KMSAN uninit-value in vfs_write

Syzkaller reported the following issue:

===================================================== BUG: KMSAN: uninit-value in aiorwdone fs/aio.c:1520 [inline] BUG: KMSAN: uninit-value in aiowrite+0x899/0x950 fs/aio.c:1600 aiorwdone fs/aio.c:1520 [inline] aiowrite+0x899/0x950 fs/aio.c:1600 iosubmitone+0x1d1c/0x3bf0 fs/aio.c:2019 _dosysiosubmit fs/aio.c:2078 [inline] _sesysiosubmit+0x293/0x770 fs/aio.c:2048 _x64sysiosubmit+0x92/0xd0 fs/aio.c:2048 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x3d/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd

Uninit was created at: slabpostallochook mm/slab.h:766 [inline] slaballocnode mm/slub.c:3452 [inline] _kmemcacheallocnode+0x71f/0xce0 mm/slub.c:3491 _dokmallocnode mm/slabcommon.c:967 [inline] _kmalloc+0x11d/0x3b0 mm/slabcommon.c:981 kmallocarray include/linux/slab.h:636 [inline] bcmtxsetup+0x80e/0x29d0 net/can/bcm.c:930 bcmsendmsg+0x3a2/0xce0 net/can/bcm.c:1351 socksendmsgnosec net/socket.c:714 [inline] socksendmsg net/socket.c:734 [inline] sockwriteiter+0x495/0x5e0 net/socket.c:1108 callwriteiter include/linux/fs.h:2189 [inline] aiowrite+0x63a/0x950 fs/aio.c:1600 iosubmitone+0x1d1c/0x3bf0 fs/aio.c:2019 _dosysiosubmit fs/aio.c:2078 [inline] _sesysiosubmit+0x293/0x770 fs/aio.c:2048 _x64sysiosubmit+0x92/0xd0 fs/aio.c:2048 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x3d/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64after_hwframe+0x63/0xcd

CPU: 1 PID: 5034 Comm: syz-executor350 Not tainted 6.2.0-rc6-syzkaller-80422-geda666ff2276 #0

Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023

We can follow the call chain and find that 'bcmtxsetup' function calls 'memcpyfrommsg' to copy some content to the newly allocated frame of 'op->frames'. After that the 'len' field of copied structure being compared with some constant value (64 or 8). However, if 'memcpyfrommsg' returns an error, we will compare some uninitialized memory. This triggers 'uninit-value' issue.

This patch will add 'memcpyfrommsg' possible errors processing to avoid uninit-value issue.

Tested via syzkaller(CVE-2023-53344)

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

cifs: Fix warning and UAF when destroy the MR list

If the MR allocate failed, the MR recovery work not initialized and list not cleared. Then will be warning and UAF when release the MR:

WARNING: CPU: 4 PID: 824 at kernel/workqueue.c:3066 flushwork.isra.0+0xf7/0x110 CPU: 4 PID: 824 Comm: mount.cifs Not tainted 6.1.0-rc5+ #82 RIP: 0010:flushwork.isra.0+0xf7/0x110 Call Trace: <TASK> _cancelworktimer+0x2ba/0x2e0 smbddestroy+0x4e1/0x990 smbdgetconnection+0x1cbd/0x2110 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

BUG: KASAN: use-after-free in smbddestroy+0x4fc/0x990 Read of size 8 at addr ffff88810b156a08 by task mount.cifs/824 CPU: 4 PID: 824 Comm: mount.cifs Tainted: G W 6.1.0-rc5+ #82 Call Trace: dumpstacklvl+0x34/0x44 printreport+0x171/0x472 kasanreport+0xad/0x130 smbddestroy+0x4fc/0x990 smbdgetconnection+0x1cbd/0x2110 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

Allocated by task 824: kasansavestack+0x1e/0x40 kasansettrack+0x21/0x30 _kasankmalloc+0x7a/0x90 smbdgetconnection+0x1b6f/0x2110 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

Freed by task 824: kasansavestack+0x1e/0x40 kasansettrack+0x21/0x30 kasansavefreeinfo+0x2a/0x40 __kasanslabfree+0x143/0x1b0 _kmemcachefree+0xc8/0x330 smbdgetconnection+0x1c6a/0x2110 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

Let's initialize the MR recovery work before MR allocate to prevent the warning, remove the MRs from the list to prevent the UAF.(CVE-2023-53427)

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

PCI/ASPM: Disable ASPM on MFD function removal to avoid use-after-free

Struct pcielinkstate->downstream is a pointer to the pci_dev of function 0. Previously we retained that pointer when removing function 0, and subsequent ASPM policy changes dereferenced it, resulting in a use-after-free warning from KASAN, e.g.:

# echo 1 > /sys/bus/pci/devices/0000:03:00.0/remove # echo powersave > /sys/module/pcie_aspm/parameters/policy

BUG: KASAN: slab-use-after-free in pcieconfigaspmlink+0x42d/0x500 Call Trace: kasanreport+0xae/0xe0 pcieconfigaspmlink+0x42d/0x500 pcieaspmsetpolicy+0x8e/0x1a0 paramattrstore+0x162/0x2c0 moduleattrstore+0x3e/0x80

PCIe spec r6.0, sec 7.5.3.7, recommends that software program the same ASPM Control value in all functions of multi-function devices.

Disable ASPM and free the pcielinkstate when any child function is removed so we can discard the dangling pcielinkstate->downstream pointer and maintain the same ASPM Control configuration for all functions.

bhelgaas: commit log and comment

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

HID: multitouch: Correct devm device reference for hidinput input_dev name

Reference the HID device rather than the input device for the devm allocation of the inputdev name. Referencing the inputdev would lead to a use-after-free when the input_dev was unregistered and subsequently fires a uevent that depends on the name. At the point of firing the uevent, the name would be freed by devres management.

Use devmkasprintf to simplify the logic for allocating memory and formatting the inputdev name string.(CVE-2023-53454)

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

xfrm: fix slab-use-after-free in decode_session6

When the xfrm device is set to the qdisc of the sfb type, the cb field of the sent skb may be modified during enqueuing. Then, slab-use-after-free may occur when the xfrm device sends IPv6 packets.

The stack information is as follows: BUG: KASAN: slab-use-after-free in decodesession6+0x103f/0x1890 Read of size 1 at addr ffff8881111458ef by task swapper/3/0 CPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.4.0-next-20230707 #409 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014 Call Trace: <IRQ> dumpstacklvl+0xd9/0x150 printaddressdescription.constprop.0+0x2c/0x3c0 kasanreport+0x11d/0x130 decodesession6+0x103f/0x1890 _xfrmdecodesession+0x54/0xb0 xfrmixmit+0x173/0x1ca0 devhardstartxmit+0x187/0x700 schdirectxmit+0x1a3/0xc30 _qdiscrun+0x510/0x17a0 _devqueuexmit+0x2215/0x3b10 neighconnectedoutput+0x3c2/0x550 ip6finishoutput2+0x55a/0x1550 ip6finishoutput+0x6b9/0x1270 ip6output+0x1f1/0x540 ndiscsendskb+0xa63/0x1890 ndiscsendrs+0x132/0x6f0 addrconfrstimer+0x3f1/0x870 calltimerfn+0x1a0/0x580 expiretimers+0x29b/0x4b0 runtimersoftirq+0x326/0x910 _dosoftirq+0x1d4/0x905 irqexitrcu+0xb7/0x120 sysvecapictimerinterrupt+0x97/0xc0 </IRQ> <TASK> asmsysvecapictimerinterrupt+0x1a/0x20 RIP: 0010:intelidlehlt+0x23/0x30 Code: 1f 84 00 00 00 00 00 f3 0f 1e fa 41 54 41 89 d4 0f 1f 44 00 00 66 90 0f 1f 44 00 00 0f 00 2d c4 9f ab 00 0f 1f 44 00 00 fb f4 <fa> 44 89 e0 41 5c c3 66 0f 1f 44 00 00 f3 0f 1e fa 41 54 41 89 d4 RSP: 0018:ffffc90000197d78 EFLAGS: 00000246 RAX: 00000000000a83c3 RBX: ffffe8ffffd09c50 RCX: ffffffff8a22d8e5 RDX: 0000000000000001 RSI: ffffffff8d3f8080 RDI: ffffe8ffffd09c50 RBP: ffffffff8d3f8080 R08: 0000000000000001 R09: ffffed1026ba6d9d R10: ffff888135d36ceb R11: 0000000000000001 R12: 0000000000000001 R13: ffffffff8d3f8100 R14: 0000000000000001 R15: 0000000000000000 cpuidleenterstate+0xd3/0x6f0 cpuidleenter+0x4e/0xa0 doidle+0x2fe/0x3c0 cpustartupentry+0x18/0x20 startsecondary+0x200/0x290 secondarystartup64noverify+0x167/0x16b </TASK> Allocated by task 939: kasansavestack+0x22/0x40 kasansettrack+0x25/0x30 _kasanslaballoc+0x7f/0x90 kmemcacheallocnode+0x1cd/0x410 kmallocreserve+0x165/0x270 _allocskb+0x129/0x330 inet6ifanotify+0x118/0x230 _ipv6ifanotify+0x177/0xbe0 addrconfdadcompleted+0x133/0xe00 addrconfdadwork+0x764/0x1390 processonework+0xa32/0x16f0 workerthread+0x67d/0x10c0 kthread+0x344/0x440 retfromfork+0x1f/0x30 The buggy address belongs to the object at ffff888111145800 which belongs to the cache skbuffsmallhead of size 640 The buggy address is located 239 bytes inside of freed 640-byte region [ffff888111145800, ffff888111145a80)

As commit f855691975bb ("xfrm6: Fix the nexthdr offset in decodesession6.") showed, xfrmdecodesession was originally intended only for the receive path. IP6CB(skb)->nhoff is not set during transmission. Therefore, set the cb field in the skb to 0 before sending packets.(CVE-2023-53500)

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

wifi: brcmfmac: ensure CLM version is null-terminated to prevent stack-out-of-bounds

Fix a stack-out-of-bounds read in brcmfmac that occurs when 'buf' that is not null-terminated is passed as an argument of strreplace() in brcmfcpreinitdcmds(). This buffer is filled with a CLM version string by memcpy() in brcmffiliovardata_get(). Ensure buf is null-terminated.

Found by a modified version of syzkaller.

[ 33.004414][ T1896] brcmfmac: brcmfcprocessclmblob: no clmblob available (err=-2), device may have limited channels available [ 33.013486][ T1896] brcmfmac: brcmfcpreinitdcmds: Firmware: BCM43236/3 wl0: Nov 30 2011 17:33:42 version 5.90.188.22 [ 33.021554][ T1896] ================================================================== [ 33.022379][ T1896] BUG: KASAN: stack-out-of-bounds in strreplace+0xf2/0x110 [ 33.023122][ T1896] Read of size 1 at addr ffffc90001d6efc8 by task kworker/0:2/1896 [ 33.023852][ T1896] [ 33.024096][ T1896] CPU: 0 PID: 1896 Comm: kworker/0:2 Tainted: G O 5.14.0+ #132 [ 33.024927][ T1896] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 [ 33.026065][ T1896] Workqueue: usbhubwq hubevent [ 33.026581][ T1896] Call Trace: [ 33.026896][ T1896] dumpstacklvl+0x57/0x7d [ 33.027372][ T1896] printaddressdescription.constprop.0.cold+0xf/0x334 [ 33.028037][ T1896] ? strreplace+0xf2/0x110 [ 33.028403][ T1896] ? strreplace+0xf2/0x110 [ 33.028807][ T1896] kasanreport.cold+0x83/0xdf [ 33.029283][ T1896] ? strreplace+0xf2/0x110 [ 33.029666][ T1896] strreplace+0xf2/0x110 [ 33.029966][ T1896] brcmfcpreinitdcmds+0xab1/0xc40 [ 33.030351][ T1896] ? brcmfcsetjoinprefdefault+0x100/0x100 [ 33.030787][ T1896] ? rcureadlockschedheld+0xa1/0xd0 [ 33.031223][ T1896] ? rcureadlockbhheld+0xb0/0xb0 [ 33.031661][ T1896] ? lockacquire+0x19d/0x4e0 [ 33.032091][ T1896] ? findheldlock+0x2d/0x110 [ 33.032605][ T1896] ? brcmfusbdeq+0x1a7/0x260 [ 33.033087][ T1896] ? brcmfusbrxfillall+0x5a/0xf0 [ 33.033582][ T1896] brcmfattach+0x246/0xd40 [ 33.034022][ T1896] ? wiphynewnm+0x1476/0x1d50 [ 33.034383][ T1896] ? kmemdup+0x30/0x40 [ 33.034722][ T1896] brcmfusbprobe+0x12de/0x1690 [ 33.035223][ T1896] ? brcmfusbdevqinit.constprop.0+0x470/0x470 [ 33.035833][ T1896] usbprobeinterface+0x25f/0x710 [ 33.036315][ T1896] reallyprobe+0x1be/0xa90 [ 33.036656][ T1896] _driverprobedevice+0x2ab/0x460 [ 33.037026][ T1896] ? usbmatchid.part.0+0x88/0xc0 [ 33.037383][ T1896] driverprobedevice+0x49/0x120 [ 33.037790][ T1896] _deviceattachdriver+0x18a/0x250 [ 33.038300][ T1896] ? driverallowsasyncprobing+0x120/0x120 [ 33.038986][ T1896] busforeachdrv+0x123/0x1a0 [ 33.039906][ T1896] ? busrescandevices+0x20/0x20 [ 33.041412][ T1896] ? lockdephardirqsonprepare+0x273/0x3e0 [ 33.041861][ T1896] ? tracehardirqson+0x1c/0x120 [ 33.042330][ T1896] _deviceattach+0x207/0x330 [ 33.042664][ T1896] ? devicebinddriver+0xb0/0xb0 [ 33.043026][ T1896] ? kobjectueventenv+0x230/0x12c0 [ 33.043515][ T1896] busprobedevice+0x1a2/0x260 [ 33.043914][ T1896] deviceadd+0xa61/0x1ce0 [ 33.044227][ T1896] ? _mutexunlockslowpath+0xe7/0x660 [ 33.044891][ T1896] ? _fwdevlinklinktosuppliers+0x550/0x550 [ 33.045531][ T1896] usbsetconfiguration+0x984/0x1770 [ 33.046051][ T1896] ? kernfscreatelink+0x175/0x230 [ 33.046548][ T1896] usbgenericdriverprobe+0x69/0x90 [ 33.046931][ T1896] usbprobedevice+0x9c/0x220 [ 33.047434][ T1896] reallyprobe+0x1be/0xa90 [ 33.047760][ T1896] _driverprobedevice+0x2ab/0x460 [ 33.048134][ T1896] driverprobedevice+0x49/0x120 [ 33.048516][ T1896] _deviceattachdriver+0x18a/0x250 [ 33.048910][ T1896] ? driverallowsasync_probing+0x120/0x120 ---truncated---(CVE-2023-53582)

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

wifi: ath9k: hifusb: fix memory leak of remainskbs

hifdev->remainskb is allocated and used exclusively in ath9khifusbrxstream(). It is implied that an allocated remainskb is processed and subsequently freed (in error paths) only during the next call of ath9khifusbrx_stream().

So, if the urbs are deallocated between those two calls due to the device deinitialization or suspend, it is possible that ath9khifusbrxstream() is not called next time and the allocated remain_skb is leaked. Our local Syzkaller instance was able to trigger that.

remainskb makes sense when receiving two consecutive urbs which are logically linked together, i.e. a specific data field from the first skb indicates a cached skb to be allocated, memcpy'd with some data and subsequently processed in the next call to ath9khifusbrx_stream(). Urbs deallocation supposedly makes that link irrelevant so we need to free the cached skb in those cases.

Fix the leak by introducing a function to explicitly free remainskb (if it is not NULL) when the rx urbs have been deallocated. remainskb is NULL when it has not been allocated at all (hifdev struct is kzalloced) or when it has been processed in next call to ath9khifusbrx_stream().

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2023-53641)

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

scsi: ses: Fix possible desc_ptr out-of-bounds accesses

Sanitize possible descptr out-of-bounds accesses in sesenclosuredataprocess().(CVE-2023-53675)

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

scsi: target: iscsi: Fix buffer overflow in liotargetnaclinfoshow()

The function liotargetnaclinfoshow() uses sprintf() in a loop to print details for every iSCSI connection in a session without checking for the buffer length. With enough iSCSI connections it's possible to overflow the buffer provided by configfs and corrupt the memory.

This patch replaces sprintf() with sysfsemitat() that checks for buffer boundries.(CVE-2023-53676)

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

wifi: ath9k: Fix potential stack-out-of-bounds write in ath9kwmirsp_callback()

Fix a stack-out-of-bounds write that occurs in a WMI response callback function that is called after a timeout occurs in ath9kwmicmd(). The callback writes to wmi->cmdrspbuf, a stack-allocated buffer that could no longer be valid when a timeout occurs. Set wmi->lastseqid to 0 when a timeout occurred.

Found by a modified version of syzkaller.

BUG: KASAN: stack-out-of-bounds in ath9kwmictrlrx Write of size 4 Call Trace: memcpy ath9kwmictrlrx ath9khtcrxmsg ath9khifusbregincb _usbhcdgivebackurb usbhcdgivebackurb dummytimer calltimerfn runtimersoftirq _dosoftirq irqexitrcu sysvecapictimer_interrupt(CVE-2023-53717)

In the Linux kernel, a resource management vulnerability exists in the clsu32 network scheduler component. When the u32replacehwknode operation fails, the system fails to properly undo the tcfbindfilter operation previously performed via u32setparms, potentially leading to resource leaks or privilege escalation.(CVE-2023-53733)

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

mm/vmscan: fix hwpoisoned large folio handling in shrinkfoliolist

In shrinkfoliolist(), the hwpoisoned folio may be large folio, which can't be handled by unmappoisonedfolio(). For THP, trytounmapone() must be passed with TTUSPLITHUGEPMD to split huge PMD first and then retry. Without TTUSPLITHUGEPMD, we will trigger null-ptr deref of pvmw.pte. Even we passed TTUSPLITHUGEPMD, we will trigger a WARNONONCE due to the page isn't in swapcache.

Since UCE is rare in real world, and race with reclaimation is more rare, just skipping the hwpoisoned large folio is enough. memory_failure() will handle it if the UCE is triggered again.

This happens when memory reclaim for large folio races with memory_failure(), and will lead to kernel panic. The race is as follows:

cpu0 cpu1 shrinkfoliolist memoryfailure TestSetPageHWPoison unmappoisonedfolio --> trigger BUGON due to unmappoisonedfolio couldn't handle large folio

[(CVE-2025-39725)

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

jbd2: prevent softlockup in jbd2logdo_checkpoint()

Both jbd2logdocheckpoint() and jbd2journalshrinkcheckpointlist() periodically release jlistlock after processing a batch of buffers to avoid long hold times on the jlistlock. However, since both functions contend for jlist_lock, the combined time spent waiting and processing can be significant.

jbd2journalshrinkcheckpointlist() explicitly calls condresched() when needresched() is true to avoid softlockups during prolonged operations. But jbd2logdocheckpoint() only exits its loop when needresched() is true, relying on potentially sleeping functions like _flushbatch() or waitonbuffer() to trigger rescheduling. If those functions do not sleep, the kernel may hit a softlockup.

watchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373] CPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10 Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017 Workqueue: writeback wbworkfn (flush-7:2) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : nativequeuedspinlockslowpath+0x358/0x418 lr : jbd2logdocheckpoint+0x31c/0x438 [jbd2] Call trace: nativequeuedspinlockslowpath+0x358/0x418 jbd2logdocheckpoint+0x31c/0x438 [jbd2] jbd2logwaitforspace+0xfc/0x2f8 [jbd2] addtransactioncredits+0x3bc/0x418 [jbd2] startthishandle+0xf8/0x560 [jbd2] jbd2journalstart+0x118/0x228 [jbd2] _ext4journalstartsb+0x110/0x188 [ext4] ext4dowritepages+0x3dc/0x740 [ext4] ext4writepages+0xa4/0x190 [ext4] dowritepages+0x94/0x228 _writebacksingleinode+0x48/0x318 writebacksbinodes+0x204/0x590 _writebackinodeswb+0x54/0xf8 wbwriteback+0x2cc/0x3d8 wbdowriteback+0x2e0/0x2f8 wbworkfn+0x80/0x2a8 processonework+0x178/0x3e8 workerthread+0x234/0x3b8 kthread+0xf0/0x108 retfrom_fork+0x10/0x20

So explicitly call condresched() in jbd2logdocheckpoint() to avoid softlockup.(CVE-2025-39782)

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

i40e: add validation for ring_len param

The ring_len parameter provided by the virtual function (VF) is assigned directly to the hardware memory context (HMC) without any validation.

To address this, introduce an upper boundary check for both Tx and Rx queue lengths. The maximum number of descriptors supported by the hardware is 8k-32. Additionally, enforce alignment constraints: Tx rings must be a multiple of 8, and Rx rings must be a multiple of 32.(CVE-2025-39973)

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

fs: udf: fix OOB read in lengthAllocDescs handling

When parsing Allocation Extent Descriptor, lengthAllocDescs comes from on-disk data and must be validated against the block size. Crafted or corrupted images may set lengthAllocDescs so that the total descriptor length (sizeof(allocExtDesc) + lengthAllocDescs) exceeds the buffer, leading udfupdatetag() to call crcitut() on out-of-bounds memory and trigger a KASAN use-after-free read.

BUG: KASAN: use-after-free in crcitut+0x1d5/0x2b0 lib/crc-itu-t.c:60 Read of size 1 at addr ffff888041e7d000 by task syz-executor317/5309

CPU: 0 UID: 0 PID: 5309 Comm: syz-executor317 Not tainted 6.12.0-rc4-syzkaller-00261-g850925a8133c #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0x169/0x550 mm/kasan/report.c:488 kasanreport+0x143/0x180 mm/kasan/report.c:601 crcitut+0x1d5/0x2b0 lib/crc-itu-t.c:60 udfupdatetag+0x70/0x6a0 fs/udf/misc.c:261 udfwriteaext+0x4d8/0x7b0 fs/udf/inode.c:2179 extenttrunc+0x2f7/0x4a0 fs/udf/truncate.c:46 udftruncatetailextent+0x527/0x7e0 fs/udf/truncate.c:106 udfreleasefile+0xc1/0x120 fs/udf/file.c:185 _fput+0x23f/0x880 fs/filetable.c:431 taskworkrun+0x24f/0x310 kernel/taskwork.c:239 exittaskwork include/linux/taskwork.h:43 [inline] doexit+0xa2f/0x28e0 kernel/exit.c:939 dogroupexit+0x207/0x2c0 kernel/exit.c:1088 _dosysexitgroup kernel/exit.c:1099 [inline] _sesysexitgroup kernel/exit.c:1097 [inline] _x64sysexitgroup+0x3f/0x40 kernel/exit.c:1097 x64syscall+0x2634/0x2640 arch/x86/include/generated/asm/syscalls64.h:232 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f </TASK>

Validate the computed total length against epos->bh->b_size.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-40044)