OESA-2025-1095

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

ksmbd: fix race condition between session lookup and expire

Thread A + Thread B ksmbdsessionlookup | smb2sesssetup sess = xaload | | | xaerase(&conn->sessions, sess->id); | | ksmbdsessiondestroy(sess) --> kfree(sess) | // UAF! | sess->last_active = jiffies | +

This patch add rwsem to fix race condition between ksmbdsessionlookup and ksmbdexpiresession.(CVE-2023-52480)

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

RDMA/siw: Fix connection failure handling

In case immediate MPA request processing fails, the newly created endpoint unlinks the listening endpoint and is ready to be dropped. This special case was not handled correctly by the code handling the later TCP socket close, causing a NULL dereference crash in siwcmwork_handler() when dereferencing a NULL listener. We now also cancel the useless MPA timeout, if immediate MPA request processing fails.

This patch furthermore simplifies MPA processing in general: Scheduling a useless TCP socket read in skdataready() upcall is now surpressed, if the socket is already moved out of TCP_ESTABLISHED state.(CVE-2023-52513)

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

PM / devfreq: Fix buffer overflow in transstatshow

Fix buffer overflow in transstatshow().

Convert simple snprintf to the more secure scnprintf with size of PAGE_SIZE.

Add condition checking if we are exceeding PAGESIZE and exit early from loop. Also add at the end a warning that we exceeded PAGESIZE and that stats is disabled.

Return -EFBIG in the case where we don't have enough space to write the full transition table.

Also document in the ABI that this function can return -EFBIG error.(CVE-2023-52614)

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

iio: adc: ad7091r: Allow users to configure device events

AD7091R-5 devices are supported by the ad7091r-5 driver together with the ad7091r-base driver. Those drivers declared iio events for notifying user space when ADC readings fall bellow the thresholds of low limit registers or above the values set in high limit registers. However, to configure iio events and their thresholds, a set of callback functions must be implemented and those were not present until now. The consequence of trying to configure ad7091r-5 events without the proper callback functions was a null pointer dereference in the kernel because the pointers to the callback functions were not set.

Implement event configuration callbacks allowing users to read/write event thresholds and enable/disable event generation.

Since the event spec structs are generic to AD7091R devices, also move those from the ad7091r-5 driver the base driver so they can be reused when support for ad7091r-2/-4/-8 be added.(CVE-2023-52627)

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

drm/i915: Fix potential context UAFs

gemcontextregister() makes the context visible to userspace, and which point a separate thread can trigger the I915GEMCONTEXTDESTROY ioctl. So we need to ensure that nothing uses the ctx ptr after this. And we need to ensure that adding the ctx to the xarray is the *last* thing that gemcontext_register() does with the ctx pointer.

[tursulin: Stable and fixes tags add/tidy.] (cherry picked from commit bed4b455cf5374e68879be56971c1da563bcd90c)(CVE-2023-52913)

A race condition was found in the Linux kernel's net/bluetooth device driver in conninfo{min,max}ageset() function. This can result in integrity overflow issue, possibly leading to bluetooth connection abnormality or denial of service.

(CVE-2024-24857)

A race condition was found in the Linux kernel's net/bluetooth in sniff{min,max}interval_set() function. This can result in a bluetooth sniffing exception issue, possibly leading denial of service.

(CVE-2024-24859)

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

xhci: handle isoc Babble and Buffer Overrun events properly

xHCI 4.9 explicitly forbids assuming that the xHC has released its ownership of a multi-TRB TD when it reports an error on one of the early TRBs. Yet the driver makes such assumption and releases the TD, allowing the remaining TRBs to be freed or overwritten by new TDs.

The xHC should also report completion of the final TRB due to its IOC flag being set by us, regardless of prior errors. This event cannot be recognized if the TD has already been freed earlier, resulting in "Transfer event TRB DMA ptr not part of current TD" error message.

Fix this by reusing the logic for processing isoc Transaction Errors. This also handles hosts which fail to report the final completion.

Fix transfer length reporting on Babble errors. They may be caused by device malfunction, no guarantee that the buffer has been filled.(CVE-2024-26659)

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

hwmon: (coretemp) Fix out-of-bounds memory access

Fix a bug that pdata->cpu_map[] is set before out-of-bounds check. The problem might be triggered on systems with more than 128 cores per package.(CVE-2024-26664)

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

netfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectations

• Disallow families other than NFPROTO_{IPV4,IPV6,INET}.
• Disallow layer 4 protocol with no ports, since destination port is a mandatory attribute for this object.(CVE-2024-26673)

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

usb: roles: fix NULL pointer issue when put module's reference

In current design, usb role class driver will get usbroleswitch parent's module reference after the user get usbroleswitch device and put the reference after the user put the usbroleswitch device. However, the parent device of usbroleswitch may be removed before the user put the usbroleswitch. If so, then, NULL pointer issue will be met when the user put the parent module's reference.

This will save the module pointer in structure of usbroleswitch. Then, we don't need to find module by iterating long relations.(CVE-2024-26747)

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

usb: cdns3: fix memory double free when handle zero packet

829 if (request->complete) { 830 spinunlock(&privdev->lock); 831 usbgadgetgivebackrequest(&privep->endpoint, 832 request); 833 spinlock(&privdev->lock); 834 } 835 836 if (request->buf == privdev->zlpbuf) 837 cdns3gadgetepfreerequest(&priv_ep->endpoint, request);

Driver append an additional zero packet request when queue a packet, which length mod max packet size is 0. When transfer complete, run to line 831, usbgadgetgivebackrequest() will free this requestion. 836 condition is true, so cdns3gadgetepfree_request() free this request again.

Log:

[ 1920.140696][ T150] BUG: KFENCE: use-after-free read in cdns3gadgetgiveback+0x134/0x2c0 [cdns3] [ 1920.140696][ T150] [ 1920.151837][ T150] Use-after-free read at 0x000000003d1cd10b (in kfence-#36): [ 1920.159082][ T150] cdns3gadgetgiveback+0x134/0x2c0 [cdns3] [ 1920.164988][ T150] cdns3transfercompleted+0x438/0x5f8 [cdns3]

Add check at line 829, skip call usbgadgetgivebackrequest() if it is additional zero length packet request. Needn't call usbgadgetgivebackrequest() because it is allocated in this driver.(CVE-2024-26748)

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

usb: cdns3: fixed memory use after free at cdns3gadgetep_disable()

... cdns3gadgetepfreerequest(&privep->endpoint, &privreq->request); listdelinit(&priv_req->list); ...

'privreq' actually free at cdns3gadgetepfreerequest(). But listdelinit() use privreq->list after it.

[ 1542.642868][ T534] BUG: KFENCE: use-after-free read in _listdelentryvalid+0x10/0xd4 [ 1542.642868][ T534] [ 1542.653162][ T534] Use-after-free read at 0x000000009ed0ba99 (in kfence-#3): [ 1542.660311][ T534] _listdelentryvalid+0x10/0xd4 [ 1542.665375][ T534] cdns3gadgetepdisable+0x1f8/0x388 [cdns3] [ 1542.671571][ T534] usbepdisable+0x44/0xe4 [ 1542.675948][ T534] ffsfuncepsdisable+0x64/0xc8 [ 1542.680839][ T534] ffsfuncsetalt+0x74/0x368 [ 1542.685478][ T534] ffsfunc_disable+0x18/0x28

Move listdelinit() before cdns3gadgetepfreerequest() to resolve this problem.(CVE-2024-26749)

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

crypto: virtio/akcipher - Fix stack overflow on memcpy

sizeof(struct virtiocryptoakciphersessionpara) is less than sizeof(struct virtiocryptoopctrlreq::u), copying more bytes from stack variable leads stack overflow. Clang reports this issue by commands: make -j CC=clang-14 mrproper >/dev/null 2>&1 make -j O=/tmp/crypto-build CC=clang-14 allmodconfig >/dev/null 2>&1 make -j O=/tmp/crypto-build W=1 CC=clang-14 drivers/crypto/virtio/ virtiocryptoakcipher_algs.o(CVE-2024-26753)

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

mptcp: fix possible deadlock in subflow diag

Syzbot and Eric reported a lockdep splat in the subflow diag:

WARNING: possible circular locking dependency detected 6.8.0-rc4-syzkaller-00212-g40b9385dd8e6 #0 Not tainted

syz-executor.2/24141 is trying to acquire lock: ffff888045870130 (k-sklock-AFINET6){+.+.}-{0:0}, at: tcpdiagputulp net/ipv4/tcpdiag.c:100 [inline] ffff888045870130 (k-sklock-AFINET6){+.+.}-{0:0}, at: tcpdiaggetaux+0x738/0x830 net/ipv4/tcpdiag.c:137

but task is already holding lock: ffffc9000135e488 (&h->lhash2[i].lock){+.+.}-{2:2}, at: spinlock include/linux/spinlock.h:351 [inline] ffffc9000135e488 (&h->lhash2[i].lock){+.+.}-{2:2}, at: inetdiagdumpicsk+0x39f/0x1f80 net/ipv4/inet_diag.c:1038

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (&h->lhash2[i].lock){+.+.}-{2:2}: lockacquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 _rawspinlock include/linux/spinlockapismp.h:133 [inline] rawspinlock+0x2e/0x40 kernel/locking/spinlock.c:154 spinlock include/linux/spinlock.h:351 [inline] _inethash+0x335/0xbe0 net/ipv4/inethashtables.c:743 inetcsklistenstart+0x23a/0x320 net/ipv4/inetconnectionsock.c:1261 _inetlistensk+0x2a2/0x770 net/ipv4/afinet.c:217 inetlisten+0xa3/0x110 net/ipv4/afinet.c:239 rdstcplisteninit+0x3fd/0x5a0 net/rds/tcplisten.c:316 rdstcpinitnet+0x141/0x320 net/rds/tcp.c:577 opsinit+0x352/0x610 net/core/netnamespace.c:136 _registerpernetoperations net/core/netnamespace.c:1214 [inline] registerpernetoperations+0x2cb/0x660 net/core/netnamespace.c:1283 registerpernetdevice+0x33/0x80 net/core/netnamespace.c:1370 rdstcpinit+0x62/0xd0 net/rds/tcp.c:735 dooneinitcall+0x238/0x830 init/main.c:1236 doinitcalllevel+0x157/0x210 init/main.c:1298 doinitcalls+0x3f/0x80 init/main.c:1314 kernelinitfreeable+0x42f/0x5d0 init/main.c:1551 kernelinit+0x1d/0x2a0 init/main.c:1441 retfromfork+0x4b/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1b/0x30 arch/x86/entry/entry_64.S:242

-> #0 (k-sklock-AFINET6){+.+.}-{0:0}: checkprevadd kernel/locking/lockdep.c:3134 [inline] checkprevsadd kernel/locking/lockdep.c:3253 [inline] validatechain+0x18ca/0x58e0 kernel/locking/lockdep.c:3869 lockacquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137 lockacquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 locksockfast include/net/sock.h:1723 [inline] subflowgetinfo+0x166/0xd20 net/mptcp/diag.c:28 tcpdiagputulp net/ipv4/tcpdiag.c:100 [inline] tcpdiaggetaux+0x738/0x830 net/ipv4/tcpdiag.c:137 inetskdiagfill+0x10ed/0x1e00 net/ipv4/inetdiag.c:345 inetdiagdumpicsk+0x55b/0x1f80 net/ipv4/inetdiag.c:1061 _inetdiagdump+0x211/0x3a0 net/ipv4/inetdiag.c:1263 inetdiagdumpcompat+0x1c1/0x2d0 net/ipv4/inetdiag.c:1371 netlinkdump+0x59b/0xc80 net/netlink/afnetlink.c:2264 _netlinkdumpstart+0x5df/0x790 net/netlink/afnetlink.c:2370 netlinkdumpstart include/linux/netlink.h:338 [inline] inetdiagrcvmsgcompat+0x209/0x4c0 net/ipv4/inetdiag.c:1405 sockdiagrcvmsg+0xe7/0x410 netlinkrcvskb+0x1e3/0x430 net/netlink/afnetlink.c:2543 sockdiagrcv+0x2a/0x40 net/core/sockdiag.c:280 netlinkunicastkernel net/netlink/afnetlink.c:1341 [inline] netlinkunicast+0x7ea/0x980 net/netlink/afnetlink.c:1367 netlinksendmsg+0xa3b/0xd70 net/netlink/afnetlink.c:1908 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg+0x221/0x270 net/socket.c:745 syssendmsg+0x525/0x7d0 net/socket.c:2584 _syssendmsg net/socket.c:2638 [inline] _syssendmsg+0x2b0/0x3a0 net/socket.c:2667 dosyscall64+0xf9/0x240 entrySYSCALL64afterhwframe+0x6f/0x77

As noted by Eric we can break the lock dependency chain avoid dumping ---truncated---(CVE-2024-26781)

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

dmaengine: fsl-qdma: fix SoC may hang on 16 byte unaligned read

There is chip (ls1028a) errata:

The SoC may hang on 16 byte unaligned read transactions by QDMA.

Unaligned read transactions initiated by QDMA may stall in the NOC (Network On-Chip), causing a deadlock condition. Stalled transactions will trigger completion timeouts in PCIe controller.

Workaround: Enable prefetch by setting the source descriptor prefetchable bit ( SD[PF] = 1 ).

Implement this workaround.(CVE-2024-26790)

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

gtp: fix use-after-free and null-ptr-deref in gtp_newlink()

The gtplinkops operations structure for the subsystem must be registered after registering the gtpnetops pernet operations structure.

Syzkaller hit 'general protection fault in gtpgenldump_pdp' bug:

[ 1010.702740] gtp: GTP module unloaded [ 1010.715877] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI [ 1010.715888] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] [ 1010.715895] CPU: 1 PID: 128616 Comm: a.out Not tainted 6.8.0-rc6-std-def-alt1 #1 [ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014 [ 1010.715908] RIP: 0010:gtpnewlink+0x4d7/0x9c0 [gtp] [ 1010.715915] Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00 [ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203 [ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000000 [ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282 [ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000 [ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80 [ 1010.715947] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000400 [ 1010.715953] FS: 00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000 [ 1010.715958] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0 [ 1010.715968] PKRU: 55555554 [ 1010.715972] Call Trace: [ 1010.715985] ? diebody.cold+0x1a/0x1f [ 1010.715995] ? dieaddr+0x43/0x70 [ 1010.716002] ? excgeneralprotection+0x199/0x2f0 [ 1010.716016] ? asmexcgeneralprotection+0x1e/0x30 [ 1010.716026] ? gtpnewlink+0x4d7/0x9c0 [gtp] [ 1010.716034] ? gtpnetexit+0x150/0x150 [gtp] [ 1010.716042] _rtnlnewlink+0x1063/0x1700 [ 1010.716051] ? rtnlsetlink+0x3c0/0x3c0 [ 1010.716063] ? isbpftextaddress+0xc0/0x1f0 [ 1010.716070] ? kerneltextaddress.part.0+0xbb/0xd0 [ 1010.716076] ? _kerneltextaddress+0x56/0xa0 [ 1010.716084] ? unwindgetreturnaddress+0x5a/0xa0 [ 1010.716091] ? createprofcpumask+0x30/0x30 [ 1010.716098] ? archstackwalk+0x9e/0xf0 [ 1010.716106] ? stacktracesave+0x91/0xd0 [ 1010.716113] ? stacktraceconsumeentry+0x170/0x170 [ 1010.716121] ? _lockacquire+0x15c5/0x5380 [ 1010.716139] ? markheldlocks+0x9e/0xe0 [ 1010.716148] ? kmemcachealloctrace+0x35f/0x3c0 [ 1010.716155] ? _rtnlnewlink+0x1700/0x1700 [ 1010.716160] rtnlnewlink+0x69/0xa0 [ 1010.716166] rtnetlinkrcvmsg+0x43b/0xc50 [ 1010.716172] ? rtnlfdbdump+0x9f0/0x9f0 [ 1010.716179] ? lockacquire+0x1fe/0x560 [ 1010.716188] ? netlinkdelivertap+0x12f/0xd50 [ 1010.716196] netlinkrcvskb+0x14d/0x440 [ 1010.716202] ? rtnlfdbdump+0x9f0/0x9f0 [ 1010.716208] ? netlinkack+0xab0/0xab0 [ 1010.716213] ? netlinkdelivertap+0x202/0xd50 [ 1010.716220] ? netlinkdelivertap+0x218/0xd50 [ 1010.716226] ? _virtaddrvalid+0x30b/0x590 [ 1010.716233] netlinkunicast+0x54b/0x800 [ 1010.716240] ? netlinkattachskb+0x870/0x870 [ 1010.716248] ? _checkobjectsize+0x2de/0x3b0 [ 1010.716254] netlinksendmsg+0x938/0xe40 [ 1010.716261] ? netlinkunicast+0x800/0x800 [ 1010.716269] ? _importiovec+0x292/0x510 [ 1010.716276] ? netlinkunicast+0x800/0x800 [ 1010.716284] _socksendmsg+0x159/0x190 [ 1010.716290] syssendmsg+0x712/0x880 [ 1010.716297] ? sockwriteiter+0x3d0/0x3d0 [ 1010.716304] ? ia32sysrecvmmsg+0x270/0x270 [ 1010.716309] ? lockacquire+0x1fe/0x560 [ 1010.716315] ? drainarraylocked+0x90/0x90 [ 1010.716324] syssendmsg+0xf8/0x170 [ 1010.716331] ? sendmsgcopymsghdr+0x170/0x170 [ 1010.716337] ? lockdepinitmap ---truncated---(CVE-2024-26793)

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

ksmbd: fix potencial out-of-bounds when buffer offset is invalid

I found potencial out-of-bounds when buffer offset fields of a few requests is invalid. This patch set the minimum value of buffer offset field to ->Buffer offset to validate buffer length.(CVE-2024-26952)

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

clk: Get runtime PM before walking tree during disable_unused

Doug reported [1] the following hung task:

INFO: task swapper/0:1 blocked for more than 122 seconds. Not tainted 5.15.149-21875-gf795ebc40eb8 #1 "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. task:swapper/0 state:D stack: 0 pid: 1 ppid: 0 flags:0x00000008 Call trace: _switchto+0xf4/0x1f4 _schedule+0x418/0xb80 schedule+0x5c/0x10c rpmresume+0xe0/0x52c rpmresume+0x178/0x52c _pmruntimeresume+0x58/0x98 clkpmruntimeget+0x30/0xb0 clkdisableunusedsubtree+0x58/0x208 clkdisableunusedsubtree+0x38/0x208 clkdisableunusedsubtree+0x38/0x208 clkdisableunusedsubtree+0x38/0x208 clkdisableunusedsubtree+0x38/0x208 clkdisableunused+0x4c/0xe4 dooneinitcall+0xcc/0x2d8 doinitcalllevel+0xa4/0x148 doinitcalls+0x5c/0x9c dobasicsetup+0x24/0x30 kernelinitfreeable+0xec/0x164 kernelinit+0x28/0x120 retfromfork+0x10/0x20 INFO: task kworker/u16:0:9 blocked for more than 122 seconds. Not tainted 5.15.149-21875-gf795ebc40eb8 #1 "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. task:kworker/u16:0 state:D stack: 0 pid: 9 ppid: 2 flags:0x00000008 Workqueue: eventsunbound deferredprobeworkfunc Call trace: _switchto+0xf4/0x1f4 _schedule+0x418/0xb80 schedule+0x5c/0x10c schedulepreemptdisabled+0x2c/0x48 _mutexlock+0x238/0x488 _mutexlockslowpath+0x1c/0x28 mutexlock+0x50/0x74 clkpreparelock+0x7c/0x9c clkcorepreparelock+0x20/0x44 clkprepare+0x24/0x30 clkbulkprepare+0x40/0xb0 mdssruntimeresume+0x54/0x1c8 pmgenericruntimeresume+0x30/0x44 _genpdruntimeresume+0x68/0x7c genpdruntimeresume+0x108/0x1f4 _rpmcallback+0x84/0x144 rpmcallback+0x30/0x88 rpmresume+0x1f4/0x52c rpmresume+0x178/0x52c _pmruntimeresume+0x58/0x98 _deviceattach+0xe0/0x170 deviceinitialprobe+0x1c/0x28 busprobedevice+0x3c/0x9c deviceadd+0x644/0x814 mipidsideviceregisterfull+0xe4/0x170 devmmipidsideviceregisterfull+0x28/0x70 tisnbridgeprobe+0x1dc/0x2c0 auxiliarybusprobe+0x4c/0x94 reallyprobe+0xcc/0x2c8 _driverprobedevice+0xa8/0x130 driverprobedevice+0x48/0x110 _deviceattachdriver+0xa4/0xcc busforeachdrv+0x8c/0xd8 _deviceattach+0xf8/0x170 deviceinitialprobe+0x1c/0x28 busprobedevice+0x3c/0x9c deferredprobeworkfunc+0x9c/0xd8 processonework+0x148/0x518 workerthread+0x138/0x350 kthread+0x138/0x1e0 retfromfork+0x10/0x20

The first thread is walking the clk tree and calling clkpmruntimeget() to power on devices required to read the clk hardware via struct clkops::isenabled(). This thread holds the clk preparelock, and is trying to runtime PM resume a device, when it finds that the device is in the process of resuming so the thread schedule()s away waiting for the device to finish resuming before continuing. The second thread is runtime PM resuming the same device, but the runtime resume callback is calling clkprepare(), trying to grab the preparelock waiting on the first thread.

This is a classic ABBA deadlock. To properly fix the deadlock, we must never runtime PM resume or suspend a device with the clk preparelock held. Actually doing that is near impossible today because the global preparelock would have to be dropped in the middle of the tree, the device runtime PM resumed/suspended, and then the prepare_lock grabbed again to ensure consistency of the clk tree topology. If anything changes with the clk tree in the meantime, we've lost and will need to start the operation all over again.

Luckily, most of the time we're simply incrementing or decrementing the runtime PM count on an active device, so we don't have the chance to schedule away with the prepare_lock held. Let's fix this immediate problem that can be ---truncated---(CVE-2024-27004)

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

fpga: bridge: add owner module and take its refcount

The current implementation of the fpga bridge assumes that the low-level module registers a driver for the parent device and uses its owner pointer to take the module's refcount. This approach is problematic since it can lead to a null pointer dereference while attempting to get the bridge if the parent device does not have a driver.

To address this problem, add a module owner pointer to the fpga_bridge struct and use it to take the module's refcount. Modify the function for registering a bridge to take an additional owner module parameter and rename it to avoid conflicts. Use the old function name for a helper macro that automatically sets the module that registers the bridge as the owner. This ensures compatibility with existing low-level control modules and reduces the chances of registering a bridge without setting the owner.

Also, update the documentation to keep it consistent with the new interface for registering an fpga bridge.

Other changes: opportunistically move putdevice() from _fpgabridgeget() to fpgabridgeget() and offpgabridge_get() to improve code clarity since the bridge device is taken in these functions.(CVE-2024-36479)

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

net: relax socket state check at accept time.

Christoph reported the following splat:

WARNING: CPU: 1 PID: 772 at net/ipv4/afinet.c:761 inetaccept+0x1f4/0x4a0 Modules linked in: CPU: 1 PID: 772 Comm: syz-executor510 Not tainted 6.9.0-rc7-g7da7119fe22b #56 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 RIP: 0010:inetaccept+0x1f4/0x4a0 net/ipv4/afinet.c:759 Code: 04 38 84 c0 0f 85 87 00 00 00 41 c7 04 24 03 00 00 00 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ec b7 da fd <0f> 0b e9 7f fe ff ff e8 e0 b7 da fd 0f 0b e9 fe fe ff ff 89 d9 80 RSP: 0018:ffffc90000c2fc58 EFLAGS: 00010293 RAX: ffffffff836bdd14 RBX: 0000000000000000 RCX: ffff888104668000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: dffffc0000000000 R08: ffffffff836bdb89 R09: fffff52000185f64 R10: dffffc0000000000 R11: fffff52000185f64 R12: dffffc0000000000 R13: 1ffff92000185f98 R14: ffff88810754d880 R15: ffff8881007b7800 FS: 000000001c772880(0000) GS:ffff88811b280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb9fcf2e178 CR3: 00000001045d2002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> inetaccept+0x138/0x1d0 net/ipv4/afinet.c:786 doaccept+0x435/0x620 net/socket.c:1929 _sysaccept4file net/socket.c:1969 [inline] _sysaccept4+0x9b/0x110 net/socket.c:1999 _dosysaccept net/socket.c:2016 [inline] _sesysaccept net/socket.c:2013 [inline] _x64sysaccept+0x7d/0x90 net/socket.c:2013 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x58/0x100 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x76/0x7e RIP: 0033:0x4315f9 Code: fd ff 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 ab b4 fd ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007ffdb26d9c78 EFLAGS: 00000246 ORIGRAX: 000000000000002b RAX: ffffffffffffffda RBX: 0000000000400300 RCX: 00000000004315f9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000004 RBP: 00000000006e1018 R08: 0000000000400300 R09: 0000000000400300 R10: 0000000000400300 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000040cdf0 R14: 000000000040ce80 R15: 0000000000000055 </TASK>

The reproducer invokes shutdown() before entering the listener status. After commit 94062790aedb ("tcp: defer shutdown(SENDSHUTDOWN) for TCPSYNRECV sockets"), the above causes the child to reach the accept syscall in FINWAIT1 status.

Eric noted we can relax the existing assertion in _inetaccept()(CVE-2024-36484)

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

fpga: manager: add owner module and take its refcount

The current implementation of the fpga manager assumes that the low-level module registers a driver for the parent device and uses its owner pointer to take the module's refcount. This approach is problematic since it can lead to a null pointer dereference while attempting to get the manager if the parent device does not have a driver.

To address this problem, add a module owner pointer to the fpga_manager struct and use it to take the module's refcount. Modify the functions for registering the manager to take an additional owner module parameter and rename them to avoid conflicts. Use the old function names for helper macros that automatically set the module that registers the manager as the owner. This ensures compatibility with existing low-level control modules and reduces the chances of registering a manager without setting the owner.

Also, update the documentation to keep it consistent with the new interface for registering an fpga manager.

Other changes: opportunistically move putdevice() from _fpgamgrget() to fpgamgrget() and offpgamgr_get() to improve code clarity since the manager device is taken in these functions.(CVE-2024-37021)

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

i2c: lpi2c: Avoid calling clkgetrate during transfer

Instead of repeatedly calling clkgetrate for each transfer, lock the clock rate and cache the value. A deadlock has been observed while adding tlv320aic32x4 audio codec to the system. When this clock provider adds its clock, the clk mutex is locked already, it needs to access i2c, which in return needs the mutex for clkgetrate as well.(CVE-2024-40965)

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

arm64: probes: Fix uprobes for big-endian kernels

The arm64 uprobes code is broken for big-endian kernels as it doesn't convert the in-memory instruction encoding (which is always little-endian) into the kernel's native endianness before analyzing and simulating instructions. This may result in a few distinct problems:

• The kernel may may erroneously reject probing an instruction which can safely be probed.

• The kernel may erroneously erroneously permit stepping an instruction out-of-line when that instruction cannot be stepped out-of-line safely.

• The kernel may erroneously simulate instruction incorrectly dur to interpretting the byte-swapped encoding.

The endianness mismatch isn't caught by the compiler or sparse because:

• The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so the compiler and sparse have no idea these contain a little-endian 32-bit value. The core uprobes code populates these with a memcpy() which similarly does not handle endianness.

• While the uprobeopcodet type is an alias for _le32, both archuprobeanalyzeinsn() and archuprobeskipsstep() cast from u8[] to the similarly-named probeopcode_t, which is an alias for u32. Hence there is no endianness conversion warning.

Fix this by changing the archuprobe::{insn,ixol} fields to _le32 and adding the appropriate _le32to_cpu() conversions prior to consuming the instruction encoding. The core uprobes copies these fields as opaque ranges of bytes, and so is unaffected by this change.

At the same time, remove MAXUINSNBYTES and consistently use AARCH64INSNSIZE for clarity.

Tested with the following:

| #include <stdio.h> | #include <stdbool.h> | | #define noinline attribute((noinline)) | | static noinline void *adrpself(void) | { | void *addr; | | asm volatile( | " adrp %x0, adrpself\n" | " add %x0, %x0, :lo12:adrpself\n" | : "=r" (addr)); | } | | | int main(int argc, char *argv) | { | void *ptr = adrpself(); | bool equal = (ptr == adrpself); | | printf("adrpself => %p\n" | "adrpself() => %p\n" | "%s\n", | adrpself, ptr, equal ? "EQUAL" : "NOT EQUAL"); | | return 0; | }

.... where the adrp_self() function was compiled to:

| 00000000004007e0 <adrpself>: | 4007e0: 90000000 adrp x0, 400000 <ehdrstart> | 4007e4: 911f8000 add x0, x0, #0x7e0 | 4007e8: d65f03c0 ret

Before this patch, the ADRP is not recognized, and is assumed to be steppable, resulting in corruption of the result:

| # ./adrp-self | adrpself => 0x4007e0 | adrpself() => 0x4007e0 | EQUAL | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobeevents | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrpself => 0x4007e0 | adrp_self() => 0xffffffffff7e0 | NOT EQUAL

After this patch, the ADRP is correctly recognized and simulated:

| # ./adrp-self | adrpself => 0x4007e0 | adrpself() => 0x4007e0 | EQUAL | # | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobeevents | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrpself => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL(CVE-2024-50194)

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

dm cache: fix flushing uninitialized delayedwork on cachectr error

An unexpected WARNON from flushwork() may occur when cache creation fails, caused by destroying the uninitialized delayedwork waker in the error path of cachecreate(). For example, the warning appears on the superblock checksum error.

Reproduce steps:

dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dd if=/dev/urandom of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"

Kernel logs:

(snip) WARNING: CPU: 0 PID: 84 at kernel/workqueue.c:4178 _flushwork+0x5d4/0x890

Fix by pulling out the canceldelayedworksync() from the constructor's error path. This patch doesn't affect the use-after-free fix for concurrent dmresume and dmdestroy (commit 6a459d8edbdb ("dm cache: Fix UAF in destroy()")) as cachedtr is not changed.(CVE-2024-50280)

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

nilfs2: fix null-ptr-deref in blocktouchbuffer tracepoint

Patch series "nilfs2: fix null-ptr-deref bugs on block tracepoints".

This series fixes null pointer dereference bugs that occur when using nilfs2 and two block-related tracepoints.

This patch (of 2):

It has been reported that when using "block:blocktouchbuffer" tracepoint, touchbuffer() called from _nilfsgetfolio_block() causes a NULL pointer dereference, or a general protection fault when KASAN is enabled.

This happens because since the tracepoint was added in touchbuffer(), it references the devt member bh->bbdev->bddev regardless of whether the buffer head has a pointer to a blockdevice structure. In the current implementation, the blockdevice structure is set after the function returns to the caller.

Here, touchbuffer() is used to mark the folio/page that owns the buffer head as accessed, but the common search helper for folio/page used by the caller function was optimized to mark the folio/page as accessed when it was reimplemented a long time ago, eliminating the need to call touchbuffer() here in the first place.

So this solves the issue by eliminating the touch_buffer() call itself.(CVE-2024-53131)

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

um: net: Do not use drvdata in release

The drvdata is not available in release. Let's just use containerof() to get the umlnet instance. Otherwise, removing a network device will result in a crash:

RIP: 0033:netdevicerelease+0x10/0x6f RSP: 00000000e20c7c40 EFLAGS: 00010206 RAX: 000000006002e4e7 RBX: 00000000600f1baf RCX: 00000000624074e0 RDX: 0000000062778000 RSI: 0000000060551c80 RDI: 00000000627af028 RBP: 00000000e20c7c50 R08: 00000000603ad594 R09: 00000000e20c7b70 R10: 000000000000135a R11: 00000000603ad422 R12: 0000000000000000 R13: 0000000062c7af00 R14: 0000000062406d60 R15: 00000000627700b6 Kernel panic - not syncing: Segfault with no mm CPU: 0 UID: 0 PID: 29 Comm: kworker/0:2 Not tainted 6.12.0-rc6-g59b723cd2adb #1 Workqueue: events mcworkproc Stack: 627af028 62c7af00 e20c7c80 60276fcd 62778000 603f5820 627af028 00000000 e20c7cb0 603a2bcd 627af000 62770010 Call Trace: [<60276fcd>] devicerelease+0x70/0xba [<603a2bcd>] kobjectput+0xba/0xe7 [<60277265>] putdevice+0x19/0x1c [<60281266>] platformdeviceput+0x26/0x29 [<60281e5f>] platformdeviceunregister+0x2c/0x2e [<6002ec9c>] netremove+0x63/0x69 [<60031316>] ? mconsolereply+0x0/0x50 [<600310c8>] mconsoleremove+0x160/0x1cc [<60087d40>] ? _removehrtimer+0x38/0x74 [<60087ff8>] ? hrtimertrytocancel+0x8c/0x98 [<6006b3cf>] ? dlserverstop+0x3f/0x48 [<6006b390>] ? dlserverstop+0x0/0x48 [<600672e8>] ? dequeueentities+0x327/0x390 [<60038fa6>] ? umsetsignals+0x0/0x43 [<6003070c>] mcworkproc+0x77/0x91 [<60057664>] processscheduledworks+0x1b3/0x2dd [<60055f32>] ? assignwork+0x0/0x58 [<60057f0a>] workerthread+0x1e9/0x293 [<6005406f>] ? setpfworker+0x0/0x64 [<6005d65d>] ? archlocalirqsave+0x0/0x2d [<6005d748>] ? kthreadexit+0x0/0x3a [<60057d21>] ? workerthread+0x0/0x293 [<6005dbf1>] kthread+0x126/0x12b [<600219c5>] newthread_handler+0x85/0xb6(CVE-2024-53183)

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

xen: Fix the issue of resource not being properly released in xenbusdevprobe()

This patch fixes an issue in the function xenbusdevprobe(). In the xenbusdevprobe() function, within the if (err) branch at line 313, the program incorrectly returns err directly without releasing the resources allocated by err = drv->probe(dev, id). As the return value is non-zero, the upper layers assume the processing logic has failed. However, the probe operation was performed earlier without a corresponding remove operation. Since the probe actually allocates resources, failing to perform the remove operation could lead to problems.

To fix this issue, we followed the resource release logic of the xenbusdevremove() function by adding a new block failremove before the failput block. After entering the branch if (err) at line 313, the function will use a goto statement to jump to the fail_remove block, ensuring that the previously acquired resources are correctly released, thus preventing the reference count leak.

This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and detecting potential issues where resources are not properly managed. In this case, the tool flagged the missing release operation as a potential problem, which led to the development of this patch.(CVE-2024-53198)

In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix null check for pipectx->planestate in dcn20programpipeThis commit addresses a null pointer dereference issue indcn20programpipe(). Previously, commit 8e4ed3cf1642 ( drm/amd/display:Add null check for pipectx->planestate in dcn20programpipe )partially fixed the null pointer dereference issue. However, indcn20updatedchubpdpp(), the variable pipectx is passed in, andplanestate is accessed again through pipectx. Multiple if statementsdirectly call attributes of plane_state, leading to potential nullpointer dereference issues. This patch adds necessary null checks toensure stability.(CVE-2024-53201)

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

wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiexconfigscan()

Replace one-element array with a flexible-array member in struct mwifiex_ie_types_wildcard_ssid_params to fix the following warning on a MT8173 Chromebook (mt8173-elm-hana):

[ 356.775250] ------------[ cut here ]------------ [ 356.784543] memcpy: detected field-spanning write (size 6) of single field "wildcardssidtlv->ssid" at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1) [ 356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiexscannetworks+0x4fc/0xf28 [mwifiex]

The "(size 6)" above is exactly the length of the SSID of the network this device was connected to. The source of the warning looks like:

ssid_len = user_scan_in->ssid_list[i].ssid_len;
[...]
memcpy(wildcard_ssid_tlv->ssid,
       user_scan_in->ssid_list[i].ssid, ssid_len);

There is a #define WILDCARDSSIDTLVMAXSIZE that uses sizeof() on this struct, but it already didn't account for the size of the one-element array, so it doesn't need to be changed.(CVE-2024-56539)

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

media: uvcvideo: Require entities to have a non-zero unique ID

Per UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero unique ID.

Each Unit and Terminal within the video function is assigned a unique
identification number, the Unit ID (UID) or Terminal ID (TID), contained in
the bUnitID or bTerminalID field of the descriptor. The value 0x00 is
reserved for undefined ID,

So, deny allocating an entity with ID 0 or an ID that belongs to a unit that is already added to the list of entities.

This also prevents some syzkaller reproducers from triggering warnings due to a chain of entities referring to themselves. In one particular case, an Output Unit is connected to an Input Unit, both with the same ID of 1. But when looking up for the source ID of the Output Unit, that same entity is found instead of the input entity, which leads to such warnings.

In another case, a backward chain was considered finished as the source ID was 0. Later on, that entity was found, but its pads were not valid.

Here is a sample stack trace for one of those cases.

[ 20.650953] usb 1-1: new high-speed USB device number 2 using dummyhcd [ 20.830206] usb 1-1: Using ep0 maxpacket: 8 [ 20.833501] usb 1-1: config 0 descriptor?? [ 21.038518] usb 1-1: string descriptor 0 read error: -71 [ 21.038893] usb 1-1: Found UVC 0.00 device <unnamed> (2833:0201) [ 21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized! [ 21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized! [ 21.042218] ------------[ cut here ]------------ [ 21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 mediacreatepadlink+0x2c4/0x2e0 [ 21.043195] Modules linked in: [ 21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444 [ 21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 21.044639] Workqueue: usbhubwq hubevent [ 21.045100] RIP: 0010:mediacreatepadlink+0x2c4/0x2e0 [ 21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 <0f> 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00 [ 21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246 [ 21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1 [ 21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290 [ 21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000 [ 21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003 [ 21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000 [ 21.049648] FS: 0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000 [ 21.050271] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0 [ 21.051136] PKRU: 55555554 [ 21.051331] Call Trace: [ 21.051480] <TASK> [ 21.051611] ? _warn+0xc4/0x210 [ 21.051861] ? mediacreatepadlink+0x2c4/0x2e0 [ 21.052252] ? reportbug+0x11b/0x1a0 [ 21.052540] ? tracehardirqson+0x31/0x40 [ 21.052901] ? handlebug+0x3d/0x70 [ 21.053197] ? excinvalidop+0x1a/0x50 [ 21.053511] ? asmexcinvalidop+0x1a/0x20 [ 21.053924] ? mediacreatepadlink+0x91/0x2e0 [ 21.054364] ? mediacreatepadlink+0x2c4/0x2e0 [ 21.054834] ? mediacreatepadlink+0x91/0x2e0 [ 21.055131] ? rawspinunlock+0x1e/0x40 [ 21.055441] ? _v4l2deviceregistersubdev+0x202/0x210 [ 21.055837] uvcmcregisterentities+0x358/0x400 [ 21.056144] uvcregisterchains+0x1fd/0x290 [ 21.056413] uvcprobe+0x380e/0x3dc0 [ 21.056676] ? _lockacquire+0x5aa/0x26e0 [ 21.056946] ? findheldlock+0x33/0xa0 [ 21.057196] ? kernfsactivate+0x70/0x80 [ 21.057533] ? usbmatchdy ---truncated---(CVE-2024-56571)

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

scsi: hisi_sas: Create all dump files during debugfs initialization

For the current debugfs of hisi_sas, after user triggers dump, the driver allocate memory space to save the register information and create debugfs files to display the saved information. In this process, the debugfs files created after each dump.

Therefore, when the dump is triggered while the driver is unbind, the following hang occurs:

[67840.853907] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0 [67840.862947] Mem abort info: [67840.865855] ESR = 0x0000000096000004 [67840.869713] EC = 0x25: DABT (current EL), IL = 32 bits [67840.875125] SET = 0, FnV = 0 [67840.878291] EA = 0, S1PTW = 0 [67840.881545] FSC = 0x04: level 0 translation fault [67840.886528] Data abort info: [67840.889524] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [67840.895117] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [67840.900284] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [67840.905709] user pgtable: 4k pages, 48-bit VAs, pgdp=0000002803a1f000 [67840.912263] [00000000000000a0] pgd=0000000000000000, p4d=0000000000000000 [67840.919177] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [67840.996435] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [67841.003628] pc : downwrite+0x30/0x98 [67841.007546] lr : startcreating.part.0+0x60/0x198 [67841.012495] sp : ffff8000b979ba20 [67841.016046] x29: ffff8000b979ba20 x28: 0000000000000010 x27: 0000000000024b40 [67841.023412] x26: 0000000000000012 x25: ffff20202b355ae8 x24: ffff20202b35a8c8 [67841.030779] x23: ffffa36877928208 x22: ffffa368b4972240 x21: ffff8000b979bb18 [67841.038147] x20: ffff00281dc1e3c0 x19: fffffffffffffffe x18: 0000000000000020 [67841.045515] x17: 0000000000000000 x16: ffffa368b128a530 x15: ffffffffffffffff [67841.052888] x14: ffff8000b979bc18 x13: ffffffffffffffff x12: ffff8000b979bb18 [67841.060263] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa368b1289b18 [67841.067640] x8 : 0000000000000012 x7 : 0000000000000000 x6 : 00000000000003a9 [67841.075014] x5 : 0000000000000000 x4 : ffff002818c5cb00 x3 : 0000000000000001 [67841.082388] x2 : 0000000000000000 x1 : ffff002818c5cb00 x0 : 00000000000000a0 [67841.089759] Call trace: [67841.092456] downwrite+0x30/0x98 [67841.096017] startcreating.part.0+0x60/0x198 [67841.100613] debugfscreatedir+0x48/0x1f8 [67841.104950] debugfscreatefilesv3hw+0x88/0x348 [hisisasv3hw] [67841.111447] debugfssnapshotregsv3hw+0x708/0x798 [hisisasv3hw] [67841.118111] debugfstriggerdumpv3hwwrite+0x9c/0x120 [hisisasv3hw] [67841.125115] fullproxywrite+0x68/0xc8 [67841.129175] vfswrite+0xd8/0x3f0 [67841.132708] ksyswrite+0x70/0x108 [67841.136317] _arm64syswrite+0x24/0x38 [67841.140440] invokesyscall+0x50/0x128 [67841.144385] el0svccommon.constprop.0+0xc8/0xf0 [67841.149273] doel0svc+0x24/0x38 [67841.152773] el0svc+0x38/0xd8 [67841.156009] el0t64synchandler+0xc0/0xc8 [67841.160361] el0t64sync+0x1a4/0x1a8 [67841.164189] Code: b9000882 d2800002 d2800023 f9800011 (c85ffc05) [67841.170443] ---[ end trace 0000000000000000 ]---

To fix this issue, create all directories and files during debugfs initialization. In this way, the driver only needs to allocate memory space to save information each time the user triggers dumping.(CVE-2024-56588)

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

kcsan: Turn reportfilterlistlock into a raw_spinlock

Ran Xiaokai reports that with a KCSAN-enabled PREEMPT_RT kernel, we can see splats like:

| BUG: sleeping function called from invalid context at kernel/locking/spinlockrt.c:48 | inatomic(): 1, irqsdisabled(): 1, nonblock: 0, pid: 0, name: swapper/1 | preemptcount: 10002, expected: 0 | RCU nest depth: 0, expected: 0 | no locks held by swapper/1/0. | irq event stamp: 156674 | hardirqs last enabled at (156673): [<ffffffff81130bd9>] doidle+0x1f9/0x240 | hardirqs last disabled at (156674): [<ffffffff82254f84>] sysvecapictimerinterrupt+0x14/0xc0 | softirqs last enabled at (0): [<ffffffff81099f47>] copyprocess+0xfc7/0x4b60 | softirqs last disabled at (0): [<0000000000000000>] 0x0 | Preemption disabled at: | [<ffffffff814a3e2a>] paintptr+0x2a/0x90 | CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.11.0+ #3 | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014 | Call Trace: | <IRQ> | dumpstacklvl+0x7e/0xc0 | dumpstack+0x1d/0x30 | _mightresched+0x1a2/0x270 | rtspinlock+0x68/0x170 | kcsanskipreportdebugfs+0x43/0xe0 | printreport+0xb5/0x590 | kcsanreportknownorigin+0x1b1/0x1d0 | kcsansetupwatchpoint+0x348/0x650 | _tsanunalignedwrite1+0x16d/0x1d0 | hrtimerinterrupt+0x3d6/0x430 | _sysvecapictimerinterrupt+0xe8/0x3a0 | sysvecapictimerinterrupt+0x97/0xc0 | </IRQ>

On a detected data race, KCSAN's reporting logic checks if it should filter the report. That list is protected by the reportfilterlistlock non-raw spinlock which may sleep on RT kernels.

Since KCSAN may report data races in any context, convert it to a raw_spinlock.

This requires being careful about when to allocate memory for the filter list itself which can be done via KCSAN's debugfs interface. Concurrent modification of the filter list via debugfs should be rare: the chosen strategy is to optimistically pre-allocate memory before the critical section and discard if unused.(CVE-2024-56610)

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

mm/mempolicy: fix migratetonode() assuming there is at least one VMA in a MM

We currently assume that there is at least one VMA in a MM, which isn't true.

So we might end up having findvma() return NULL, to then de-reference NULL. So properly handle findvma() returning NULL.

This fixes the report:

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 6021 Comm: syz-executor284 Not tainted 6.12.0-rc7-syzkaller-00187-gf868cd251776 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 RIP: 0010:migratetonode mm/mempolicy.c:1090 [inline] RIP: 0010:domigratepages+0x403/0x6f0 mm/mempolicy.c:1194 Code: ... RSP: 0018:ffffc9000375fd08 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffc9000375fd78 RCX: 0000000000000000 RDX: ffff88807e171300 RSI: dffffc0000000000 RDI: ffff88803390c044 RBP: ffff88807e171428 R08: 0000000000000014 R09: fffffbfff2039ef1 R10: ffffffff901cf78f R11: 0000000000000000 R12: 0000000000000003 R13: ffffc9000375fe90 R14: ffffc9000375fe98 R15: ffffc9000375fdf8 FS: 00005555919e1380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005555919e1ca8 CR3: 000000007f12a000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> kernelmigratepages+0x5b2/0x750 mm/mempolicy.c:1709 _dosysmigratepages mm/mempolicy.c:1727 [inline] _sesysmigratepages mm/mempolicy.c:1723 [inline] _x64sysmigratepages+0x96/0x100 mm/mempolicy.c:1723 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x250 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

akpm@linux-foundation.org: add unlikely()

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

scsi: qla2xxx: Fix use after free on unload

System crash is observed with stack trace warning of use after free. There are 2 signals to tell dpcthread to terminate (UNLOADING flag and kthreadstop).

On setting the UNLOADING flag when dpcthread happens to run at the time and sees the flag, this causes dpcthread to exit and clean up itself. When kthread_stop is called for final cleanup, this causes use after free.

Remove UNLOADING signal to terminate dpcthread. Use the kthreadstop as the main signal to exit dpc_thread.

[596663.812935] kernel BUG at mm/slub.c:294! [596663.812950] invalid opcode: 0000 [#1] SMP PTI [596663.812957] CPU: 13 PID: 1475935 Comm: rmmod Kdump: loaded Tainted: G IOE --------- - - 4.18.0-240.el8.x8664 #1 [596663.812960] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 08/20/2012 [596663.812974] RIP: 0010:slabfree+0x17d/0x360

... [596663.813008] Call Trace: [596663.813022] ? _dentrykill+0x121/0x170 [596663.813030] ? condresched+0x15/0x30 [596663.813034] ? condresched+0x15/0x30 [596663.813039] ? waitforcompletion+0x35/0x190 [596663.813048] ? trytowakeup+0x63/0x540 [596663.813055] freetask+0x5a/0x60 [596663.813061] kthreadstop+0xf3/0x100 [596663.813103] qla2x00remove_one+0x284/0x440 qla2xxx

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

sunrpc: clear XPRTSOCKUPD_TIMEOUT when reset transport

Since transport->sock has been set to NULL during reset transport, XPRTSOCKUPDTIMEOUT also needs to be cleared. Otherwise, the xstcpsetsockettimeouts() may be triggered in xstcpsendrequest() to dereference the transport->sock that has been set to NULL.(CVE-2024-56688)

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

9p/xen: fix release of IRQ

Kernel logs indicate an IRQ was double-freed.

Pass correct device ID during IRQ release.

Dominique: remove confusing variable reset to 0

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

ionic: Fix netdev notifier unregister on failure

If registernetdev() fails, then the driver leaks the netdev notifier. Fix this by calling ioniclifunregister() on registernetdev() failure. This will also call ioniclifunregister_phc() if it has already been registered.(CVE-2024-56715)

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

fbdev: sh7760fb: Fix a possible memory leak in sh7760fballocmem()

When information such as info->screenbase is not ready, calling sh7760fbfreemem() does not release memory correctly. Call dmafree_coherent() instead.(CVE-2024-56746)

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

ocfs2: fix slab-use-after-free due to dangling pointer dqi_priv

When mounting ocfs2 and then remounting it as read-only, a slab-use-after-free occurs after the user uses a syscall to quotagetnextquota. Specifically, sbdqinfo(sb, type)->dqi_priv is the dangling pointer.

During the remounting process, the pointer dqipriv is freed but is never set as null leaving it to be accessed. Additionally, the read-only option for remounting sets the DQUOTSUSPENDED flag instead of setting the DQUOTUSAGEENABLED flags. Moreover, later in the process of getting the next quota, the function ocfs2getnext_id is called and only checks the quota usage flags and not the quota suspended flags.

To fix this, I set dqipriv to null when it is freed after remounting with read-only and put a check for DQUOTSUSPENDED in ocfs2getnext_id.

akpm@linux-foundation.org: coding-style cleanups