In the Linux kernel, the following vulnerability has been resolved:
dm log: fix out-of-bounds write due to regioncount overflow
The local variable regioncount in createlogcontext() is declared as unsigned int (32-bit), but dmsectordivup() returns sectort (64-bit). When a device-mapper target has a sufficiently large ti->len with a small regionsize, the division result can exceed UINTMAX. The truncated value is then used to calculate bitsetsize, causing cleanbits, syncbits, and recoveringbits to be allocated far smaller than needed for the actual number of regions.
Subsequent log operations (logsetbit, logclearbit, logtestbit) use region indices derived from the full untruncated region space, causing out-of-bounds writes to kernel heap memory allocated by vmalloc.
This can be reproduced by creating a mirror target whose regioncount overflows 32 bits:
dmsetup create bigzero --table '0 8589934594 zero' dmsetup create mymirror --table '0 8589934594 mirror \ core 2 2 nosync 2 /dev/mapper/bigzero 0 \ /dev/mapper/bigzero 0'
The status output confirms the truncation (synccount=1 instead of 4294967297, because 0x100000001 was truncated to 1):
$ dmsetup status mymirror 0 8589934594 mirror 2 254:1 254:1 1/4294967297 ...
This leads to a kernel crash in coreinsync:
BUG: scheduling while atomic: (udev-worker)/9150/0x00000000 RIP: 0010:coreinsync+0x14/0x30 [dmlog] CR2: 0000000000000008 Fixing recursive fault but reboot is needed!
Fix by widening the local regioncount to sectort and adding an explicit overflow check before the value is assigned to lc->regioncount.
In the Linux kernel, the following vulnerability has been resolved:
slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd
When the remoteproc starts in parallel with the NGD driver being probed, or the remoteproc is already up when the PDR lookup is being registered, or in the theoretical event that we get an interrupt from the hardware, these callbacks will operate on uninitialized data. This result in issues to boot the affected boards.
One such example can be seen in the following fault, where qcomslimngdssrpdrnotify() schedules work on the NULL ngdupwork.
[ 21.858578] ------------[ cut here ]------------ [ 21.858745] WARNING: kernel/workqueue.c:2338 at queuework+0x5e0/0x790, CPU#2: kworker/2:2/116 ... [ 21.859251] Call trace: [ 21.859255] queuework+0x5e0/0x790 (P) [ 21.859265] queueworkon+0x6c/0xf0 [ 21.859273] qcomslimngdssrpdrnotify+0x110/0x150 [slimqcomngdctrl] [ 21.859304] qcomslimngdssrnotify+0x24/0x40 [slimqcomngdctrl] [ 21.859318] notifiercallchain+0xa4/0x230 [ 21.859329] srcunotifiercallchain+0x64/0xb8 [ 21.859338] ssrnotifystart+0x40/0x78 [qcomcommon] [ 21.859355] rprocstart+0x130/0x230 [ 21.859367] rprocboot+0x3d4/0x518 ...
Move the enablement of interrupts, and the registration of SSR and PDR until after the NGD device has been registered.
This could be further refined by moving initialization to the control driver probe and by removing the platform driver model from the picture.
In the Linux kernel, the following vulnerability has been resolved:
nfsd: Initialize ssc before laundromatwork to prevent NULL dereference
In nfs4statestartnet(), laundromatwork may access nfsdssc through nfs4laundromat -> nfsd4sscexpireumount. If nfsdssc isn't initialized, this can cause NULL pointer dereference.
Normally the delayed start of laundromatwork allows sufficient time for nfsdssc initialization to complete. However, when the kernel waits too long for userspace responses (e.g. in nfs4statestartnet -> nfsd4endgrace -> nfsd4recordgracedone -> nfsd4cldgracedone -> cldpipeupcall -> cldpipeupcall -> waitforcompletion path), the delayed work may start before nfsdssc initialization finishes.
Fix this by moving nfsdssc initialization before starting laundromatwork.
ice: fix NULL pointer dereference in iceresetallvfs()
In the Linux kernel, the following vulnerability has been resolved:
md: fix mddev uaf while iterating allmddevs list
While iterating allmddevs list from mdnotifyreboot() and mdexit(), listforeachentrysafe is used, and this can race with deletint the next mddev, causing UAF:
t1: spinlock //listforeachentrysafe(mddev, n, ...) mddevget(mddev1) // assume mddev2 is the next entry spinunlock t2: //remove mddev2 ... mddevfree spinlock listdel spinunlock kfree(mddev2) mddevput(mddev1) spinlock //continue dereference mddev2->allmddevs
The old helper foreachmddev() actually grab the reference of mddev2 while holding the lock, to prevent from being freed. This problem can be fixed the same way, however, the code will be complex.
Hence switch to use listforeachentry, in this case mddevput() can free the mddev1 and it's not safe as well. Refer to mdseqshow(), also factor out a helper mddevputlocked() to fix this problem.
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: Fix slab-use-after-free Read in mgmtremoveadvmonitorsync
This fixes the following crash:
================================================================== BUG: KASAN: slab-use-after-free in mgmtremoveadvmonitorsync+0x3a/0xd0 net/bluetooth/mgmt.c:5543 Read of size 8 at addr ffff88814128f898 by task kworker/u9:4/5961
CPU: 1 UID: 0 PID: 5961 Comm: kworker/u9:4 Not tainted 6.12.0-syzkaller-10684-gf1cd565ce577 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: hci0 hcicmdsyncwork Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0x169/0x550 mm/kasan/report.c:489 kasanreport+0x143/0x180 mm/kasan/report.c:602 mgmtremoveadvmonitorsync+0x3a/0xd0 net/bluetooth/mgmt.c:5543 hcicmdsyncwork+0x22b/0x400 net/bluetooth/hcisync.c:332 processonework kernel/workqueue.c:3229 [inline] processscheduledworks+0xa63/0x1850 kernel/workqueue.c:3310 workerthread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 retfromfork+0x4b/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:244 </TASK>
Allocated by task 16026: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3f/0x80 mm/kasan/common.c:68 poisonkmallocredzone mm/kasan/common.c:377 [inline] kasankmalloc+0x98/0xb0 mm/kasan/common.c:394 kasankmalloc include/linux/kasan.h:260 [inline] kmalloccachenoprof+0x243/0x390 mm/slub.c:4314 kmallocnoprof include/linux/slab.h:901 [inline] kzallocnoprof include/linux/slab.h:1037 [inline] mgmtpendingnew+0x65/0x250 net/bluetooth/mgmtutil.c:269 mgmtpendingadd+0x36/0x120 net/bluetooth/mgmtutil.c:296 removeadvmonitor+0x102/0x1b0 net/bluetooth/mgmt.c:5568 hcimgmtcmd+0xc47/0x11d0 net/bluetooth/hcisock.c:1712 hcisocksendmsg+0x7b8/0x11c0 net/bluetooth/hcisock.c:1832 socksendmsgnosec net/socket.c:711 [inline] socksendmsg+0x221/0x270 net/socket.c:726 sockwriteiter+0x2d7/0x3f0 net/socket.c:1147 newsyncwrite fs/readwrite.c:586 [inline] vfswrite+0xaeb/0xd30 fs/readwrite.c:679 ksyswrite+0x18f/0x2b0 fs/readwrite.c:731 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f
Freed by task 16022: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3f/0x80 mm/kasan/common.c:68 kasansavefreeinfo+0x40/0x50 mm/kasan/generic.c:582 poisonslabobject mm/kasan/common.c:247 [inline] kasanslabfree+0x59/0x70 mm/kasan/common.c:264 kasanslabfree include/linux/kasan.h:233 [inline] slabfreehook mm/slub.c:2338 [inline] slabfree mm/slub.c:4598 [inline] kfree+0x196/0x420 mm/slub.c:4746 mgmtpendingforeach+0xd1/0x130 net/bluetooth/mgmtutil.c:259 mgmtpoweroff+0x183/0x430 net/bluetooth/mgmt.c:9550 hcidevclosesync+0x6c4/0x11c0 net/bluetooth/hcisync.c:5208 hcidevdoclose net/bluetooth/hcicore.c:483 [inline] hcidevclose+0x112/0x210 net/bluetooth/hcicore.c:508 sockdoioctl+0x158/0x460 net/socket.c:1209 sockioctl+0x626/0x8e0 net/socket.c:1328 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:906 [inline] sesysioctl+0xf5/0x170 fs/ioctl.c:892 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f
In the Linux kernel, the following vulnerability has been resolved:
memcg: fix soft lockup in the OOM process
A soft lockup issue was found in the product with about 56,000 tasks were in the OOM cgroup, it was traversing them when the soft lockup was triggered.
watchdog: BUG: soft lockup - CPU#2 stuck for 23s! [VM Thread:1503066] CPU: 2 PID: 1503066 Comm: VM Thread Kdump: loaded Tainted: G Hardware name: Huawei Cloud OpenStack Nova, BIOS RIP: 0010:consoleunlock+0x343/0x540 RSP: 0000:ffffb751447db9a0 EFLAGS: 00000247 ORIGRAX: ffffffffffffff13 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 00000000ffffffff RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000247 RBP: ffffffffafc71f90 R08: 0000000000000000 R09: 0000000000000040 R10: 0000000000000080 R11: 0000000000000000 R12: ffffffffafc74bd0 R13: ffffffffaf60a220 R14: 0000000000000247 R15: 0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2fe6ad91f0 CR3: 00000004b2076003 CR4: 0000000000360ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: vprintkemit+0x193/0x280 printk+0x52/0x6e dumptask+0x114/0x130 memcgroupscantasks+0x76/0x100 dumpheader+0x1fe/0x210 oomkillprocess+0xd1/0x100 outofmemory+0x125/0x570 memcgroupoutofmemory+0xb5/0xd0 trycharge+0x720/0x770 memcgrouptrycharge+0x86/0x180 memcgrouptrychargedelay+0x1c/0x40 doanonymouspage+0xb5/0x390 handlemmfault+0xc4/0x1f0
This is because thousands of processes are in the OOM cgroup, it takes a long time to traverse all of them. As a result, this lead to soft lockup in the OOM process.
To fix this issue, call 'condresched' in the 'memcgroupscantasks' function per 1000 iterations. For global OOM, call 'touchsoftlockupwatchdog' per 1000 iterations to avoid this issue.
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: class: Fix NULL pointer access
Concurrent calls to typecpartnerunlinkdevice can lead to a NULL pointer dereference. This patch adds a mutex to protect USB device pointers and prevent this issue. The same mutex protects both the device pointers and the partner device registration.