The Linux Kernel, the operating system core itself.

Security Fix(es):

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

ksmbd: fix out of bounds in initsmb2rsp_hdr()

If client send smb2 negotiate request and then send smb1 negotiate request, initsmb2rsphdr is called for smb1 negotiate request since needneg is set to false. This patch ignore smb1 packets after ->need_neg is set to false.(CVE-2023-52441)

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

drm: Don't unref the same fb many times by mistake due to deadlock handling

If we get a deadlock after the fb lookup in drmmodepageflipioctl() we proceed to unref the fb and then retry the whole thing from the top. But we forget to reset the fb pointer back to NULL, and so if we then get another error during the retry, before the fb lookup, we proceed the unref the same fb again without having gotten another reference. The end result is that the fb will (eventually) end up being freed while it's still in use.

Reset fb to NULL once we've unreffed it to avoid doing it again until we've done another fb lookup.

This turned out to be pretty easy to hit on a DG2 when doing async flips (and CONFIGDEBUGWWMUTEXSLOWPATH=y). The first symptom I saw that drm_closefb() simply got stuck in a busy loop while walking the framebuffer list. Fortunately I was able to convince it to oops instead, and from there it was easier to track down the culprit.(CVE-2023-52486)

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

media: mtk-jpeg: Fix use after free bug due to error path handling in mtkjpegdecdevicerun

In mtkjpegprobe, &jpeg->jobtimeoutwork is bound with mtkjpegjobtimeoutwork.

In mtkjpegdecdevicerun, if error happens in mtkjpegsetdecdst, it will finally start the worker while mark the job as finished by invoking v4l2m2mjob_finish.

There are two methods to trigger the bug. If we remove the module, it which will call mtkjpegremove to make cleanup. The possible sequence is as follows, which will cause a use-after-free bug.

CPU0 CPU1 mtkjpegdec... | start worker | |mtkjpegjobtimeoutwork mtkjpegremove | v4l2m2mrelease | kfree(m2mdev); | | | v4l2m2mgetcurrpriv | m2mdev->currctx //use

If we close the file descriptor, which will call mtkjpegrelease, it will have a similar sequence.

Fix this bug by starting timeout worker only if started jpegdec worker successfully. Then v4l2m2mjobfinish will only be called in either mtkjpegjobtimeoutwork or mtkjpegdecdevice_run.(CVE-2023-52491)

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

dmaengine: fix NULL pointer in channel unregistration function

_dmaasyncdevicechannelregister() can fail. In case of failure, chan->local is freed (with freepercpu()), and chan->local is nullified. When dmaasyncdeviceunregister() is called (because of managed API or intentionally by DMA controller driver), channels are unconditionally unregistered, leading to this NULL pointer: [ 1.318693] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0 [...] [ 1.484499] Call trace: [ 1.486930] devicedel+0x40/0x394 [ 1.490314] deviceunregister+0x20/0x7c [ 1.494220] _dmaasyncdevicechannelunregister+0x68/0xc0

Look at dmaasyncdevice_register() function error path, channel device unregistration is done only if chan->local is not NULL.

Then add the same condition at the beginning of _dmaasyncdevicechannel_unregister() function, to avoid NULL pointer issue whatever the API used to reach this function.(CVE-2023-52492)

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

bus: mhi: host: Drop chan lock before queuing buffers

Ensure read and write locks for the channel are not taken in succession by dropping the read lock from parsexferevent() such that a callback given to client can potentially queue buffers and acquire the write lock in that process. Any queueing of buffers should be done without channel read lock acquired as it can result in multiple locks and a soft lockup.

mani: added fixes tag and cc'ed stable

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

bus: mhi: host: Add alignment check for event ring read pointer

Though we do check the event ring read pointer by "isvalidringptr" to make sure it is in the buffer range, but there is another risk the pointer may be not aligned. Since we are expecting event ring elements are 128 bits(struct mhiring_element) aligned, an unaligned read pointer could lead to multiple issues like DoS or ring buffer memory corruption.

So add a alignment check for event ring read pointer.(CVE-2023-52494)

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

PM: sleep: Fix possible deadlocks in core system-wide PM code

It is reported that in low-memory situations the system-wide resume core code deadlocks, because asyncscheduledev() executes its argument function synchronously if it cannot allocate memory (and not only in that case) and that function attempts to acquire a mutex that is already held. Executing the argument function synchronously from within dpmasyncfn() may also be problematic for ordering reasons (it may cause a consumer device's resume callback to be invoked before a requisite supplier device's one, for example).

Address this by changing the code in question to use asyncscheduledevnocall() for scheduling the asynchronous execution of device suspend and resume functions and to directly run them synchronously if asyncscheduledevnocall() returns false.(CVE-2023-52498)

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

tee: amdtee: fix use-after-free vulnerability in amdteeclosesession

There is a potential race condition in amdteeclosesession that may cause use-after-free in amdteeopensession. For instance, if a session has refcount == 1, and one thread tries to free this session via:

kref_put(&sess->refcount, destroy_session);

the reference count will get decremented, and the next step would be to call destroysession(). However, if in another thread, amdteeopensession() is called before destroysession() has completed execution, allocsession() may return 'sess' that will be freed up later in destroysession() leading to use-after-free in amdteeopensession.

To fix this issue, treat decrement of sess->refcount and removal of 'sess' from session list in destroy_session() as a critical section, so that it is executed atomically.(CVE-2023-52503)

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

x86/alternatives: Disable KASAN in apply_alternatives()

Fei has reported that KASAN triggers during apply_alternatives() on a 5-level paging machine:

BUG: KASAN: out-of-bounds in rcu_is_watching()
Read of size 4 at addr ff110003ee6419a0 by task swapper/0/0
...
__asan_load4()
rcu_is_watching()
trace_hardirqs_on()
text_poke_early()
apply_alternatives()
...

On machines with 5-level paging, cpufeatureenabled(X86FEATURELA57) gets patched. It includes KASAN code, where KASANSHADOWSTART depends on _VIRTUALMASKSHIFT, which is defined with cpufeature_enabled().

KASAN gets confused when applyalternatives() patches the KASANSHADOWSTART users. A test patch that makes KASANSHADOWSTART static, by replacing _VIRTUALMASKSHIFT with 56, works around the issue.

Fix it for real by disabling KASAN while the kernel is patching alternatives.

mingo: updated the changelog

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

net: nfc: llcp: Add lock when modifying device list

The device list needs its associated lock held when modifying it, or the list could become corrupted, as syzbot discovered.(CVE-2023-52524)

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

team: fix null-ptr-deref when team device type is changed

Get a null-ptr-deref bug as follows with reproducer [1].

BUG: kernel NULL pointer dereference, address: 0000000000000228 ... RIP: 0010:vlandevhardheader+0x35/0x140 [8021q] ... Call Trace: <TASK> ? _die+0x24/0x70 ? pagefaultoops+0x82/0x150 ? excpagefault+0x69/0x150 ? asmexcpagefault+0x26/0x30 ? vlandevhardheader+0x35/0x140 [8021q] ? vlandevhardheader+0x8e/0x140 [8021q] neighconnectedoutput+0xb2/0x100 ip6finishoutput2+0x1cb/0x520 ? nfhookslow+0x43/0xc0 ? ip6mtu+0x46/0x80 ip6finishoutput+0x2a/0xb0 mldsendpack+0x18f/0x250 mldifcwork+0x39/0x160 processonework+0x1e6/0x3f0 workerthread+0x4d/0x2f0 ? _pfxworkerthread+0x10/0x10 kthread+0xe5/0x120 ? _pfxkthread+0x10/0x10 retfromfork+0x34/0x50 ? _pfxkthread+0x10/0x10 retfromforkasm+0x1b/0x30

[1] $ teamd -t team0 -d -c '{"runner": {"name": "loadbalance"}}' $ ip link add name t-dummy type dummy $ ip link add link t-dummy name t-dummy.100 type vlan id 100 $ ip link add name t-nlmon type nlmon $ ip link set t-nlmon master team0 $ ip link set t-nlmon nomaster $ ip link set t-dummy up $ ip link set team0 up $ ip link set t-dummy.100 down $ ip link set t-dummy.100 master team0

When enslave a vlan device to team device and team device type is changed from non-ether to ether, headerops of team device is changed to vlanheaderops. That is incorrect and will trigger null-ptr-deref for vlan->realdev in vlandevhard_header() because team device is not a vlan device.

Cache ethheaderops in teamsetup(), then assign cached headerops to header_ops of team net device when its type is changed from non-ether to ether to fix the bug.(CVE-2023-52574)

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

powerpc/mm: Fix null-pointer dereference in pgtablecacheadd

kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity.(CVE-2023-52607)

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

firmware: arm_scmi: Check mailbox/SMT channel for consistency

On reception of a completion interrupt the shared memory area is accessed to retrieve the message header at first and then, if the message sequence number identifies a transaction which is still pending, the related payload is fetched too.

When an SCMI command times out the channel ownership remains with the platform until eventually a late reply is received and, as a consequence, any further transmission attempt remains pending, waiting for the channel to be relinquished by the platform.

Once that late reply is received the channel ownership is given back to the agent and any pending request is then allowed to proceed and overwrite the SMT area of the just delivered late reply; then the wait for the reply to the new request starts.

It has been observed that the spurious IRQ related to the late reply can be wrongly associated with the freshly enqueued request: when that happens the SCMI stack in-flight lookup procedure is fooled by the fact that the message header now present in the SMT area is related to the new pending transaction, even though the real reply has still to arrive.

This race-condition on the A2P channel can be detected by looking at the channel status bits: a genuine reply from the platform will have set the channel free bit before triggering the completion IRQ.

Add a consistency check to validate such condition in the A2P ISR.(CVE-2023-52608)

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

PCI: switchtec: Fix stdev_release() crash after surprise hot remove

A PCI device hot removal may occur while stdev->cdev is held open. The call to stdevrelease() then happens during close or exit, at a point way past switchtecpciremove(). Otherwise the last ref would vanish with the trailing putdevice(), just before return.

At that later point in time, the devm cleanup has already removed the stdev->mmiomrpc mapping. Also, the stdev->pdev reference was not a counted one. Therefore, in DMA mode, the iowrite32() in stdevrelease() will cause a fatal page fault, and the subsequent dmafreecoherent(), if reached, would pass a stale &stdev->pdev->dev pointer.

Fix by moving MRPC DMA shutdown into switchtecpciremove(), after stdev_kill(). Counting the stdev->pdev ref is now optional, but may prevent future accidents.

Reproducible via the script at https://lore.kernel.org/r/20231113212150.96410-1-dns@arista.com(CVE-2023-52617)

A null pointer dereference vulnerability was found in ath10kwmitlvoppullmgmttxcomplev() in drivers/net/wireless/ath/ath10k/wmi-tlv.c in the Linux kernel. This issue could be exploited to trigger a denial of service.(CVE-2023-7042)

A race condition was found in the Linux kernel's media/xc4000 device driver in xc4000 xc4000getfrequency() function. This can result in return value overflow issue, possibly leading to malfunction or denial of service issue.

(CVE-2024-24861)

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

ksmbd: fix global oob in ksmbdnlpolicy

Similar to a reported issue (check the commit b33fb5b801c6 ("net: qualcomm: rmnet: fix global oob in rmnetpolicy"), my local fuzzer finds another global out-of-bounds read for policy ksmbdnl_policy. See bug trace below:

================================================================== BUG: KASAN: global-out-of-bounds in validatenla lib/nlattr.c:386 [inline] BUG: KASAN: global-out-of-bounds in _nlavalidateparse+0x24af/0x2750 lib/nlattr.c:600 Read of size 1 at addr ffffffff8f24b100 by task syz-executor.1/62810

CPU: 0 PID: 62810 Comm: syz-executor.1 Tainted: G N 6.1.0 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x8b/0xb3 lib/dumpstack.c:106 printaddressdescription mm/kasan/report.c:284 [inline] printreport+0x172/0x475 mm/kasan/report.c:395 kasanreport+0xbb/0x1c0 mm/kasan/report.c:495 validatenla lib/nlattr.c:386 [inline] _nlavalidateparse+0x24af/0x2750 lib/nlattr.c:600 _nlaparse+0x3e/0x50 lib/nlattr.c:697 _nlmsgparse include/net/netlink.h:748 [inline] genlfamilyrcvmsgattrsparse.constprop.0+0x1b0/0x290 net/netlink/genetlink.c:565 genlfamilyrcvmsgdoit+0xda/0x330 net/netlink/genetlink.c:734 genlfamilyrcvmsg net/netlink/genetlink.c:833 [inline] genlrcvmsg+0x441/0x780 net/netlink/genetlink.c:850 netlinkrcvskb+0x14f/0x410 net/netlink/afnetlink.c:2540 genlrcv+0x24/0x40 net/netlink/genetlink.c:861 netlinkunicastkernel net/netlink/afnetlink.c:1319 [inline] netlinkunicast+0x54e/0x800 net/netlink/afnetlink.c:1345 netlinksendmsg+0x930/0xe50 net/netlink/afnetlink.c:1921 socksendmsgnosec net/socket.c:714 [inline] socksendmsg+0x154/0x190 net/socket.c:734 _syssendmsg+0x6df/0x840 net/socket.c:2482 _syssendmsg+0x110/0x1b0 net/socket.c:2536 _syssendmsg+0xf3/0x1c0 net/socket.c:2565 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x3b/0x90 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd RIP: 0033:0x7fdd66a8f359 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 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 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fdd65e00168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007fdd66bbcf80 RCX: 00007fdd66a8f359 RDX: 0000000000000000 RSI: 0000000020000500 RDI: 0000000000000003 RBP: 00007fdd66ada493 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffc84b81aff R14: 00007fdd65e00300 R15: 0000000000022000 </TASK>

The buggy address belongs to the variable: ksmbdnlpolicy+0x100/0xa80

The buggy address belongs to the physical page: page:0000000034f47940 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1ccc4b flags: 0x200000000001000(reserved|node=0|zone=2) raw: 0200000000001000 ffffea00073312c8 ffffea00073312c8 0000000000000000 raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected

Memory state around the buggy address: ffffffff8f24b000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffff8f24b080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffffff8f24b100: f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 00 00 07 f9 ^ ffffffff8f24b180: f9 f9 f9 f9 00 05 f9 f9 f9 f9 f9 f9 00 00 00 05

ffffffff8f24b200: f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9 00 00 04 f9

To fix it, add a placeholder named _KSMBDEVENTMAX and let KSMBDEVENTMAX to be its original value - 1 according to what other netlink families do. Also change two sites that refer the KSMBDEVENT_MAX to correct value.(CVE-2024-26608)

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

net/smc: fix illegal rmb_desc access in SMC-D connection dump

A crash was found when dumping SMC-D connections. It can be reproduced by following steps:

• run nginx/wrk test: smcrun nginx smcrun wrk -t 16 -c 1000 -d <duration> -H 'Connection: Close' <URL>

• continuously dump SMC-D connections in parallel: watch -n 1 'smcss -D'

  BUG: kernel NULL pointer dereference, address: 0000000000000030 CPU: 2 PID: 7204 Comm: smcss Kdump: loaded Tainted: G E 6.7.0+ #55 RIP: 0010:smcdiagdump.constprop.0+0x5e5/0x620 [smcdiag] Call Trace: <TASK> ? _die+0x24/0x70 ? pagefaultoops+0x66/0x150 ? excpagefault+0x69/0x140 ? asmexcpagefault+0x26/0x30 ? _smcdiagdump.constprop.0+0x5e5/0x620 [smcdiag] ? _kmallocnodetrackcaller+0x35d/0x430 ? _allocskb+0x77/0x170 smcdiagdumpproto+0xd0/0xf0 [smcdiag] smcdiagdump+0x26/0x60 [smcdiag] netlinkdump+0x19f/0x320 _netlinkdumpstart+0x1dc/0x300 smcdiaghandlerdump+0x6a/0x80 [smcdiag] ? _pfxsmcdiagdump+0x10/0x10 [smcdiag] sockdiagrcvmsg+0x121/0x140 ? _pfxsockdiagrcvmsg+0x10/0x10 netlinkrcvskb+0x5a/0x110 sockdiagrcv+0x28/0x40 netlinkunicast+0x22a/0x330 netlinksendmsg+0x1f8/0x420 _socksendmsg+0xb0/0xc0 _syssendmsg+0x24e/0x300 ? copymsghdrfromuser+0x62/0x80 _syssendmsg+0x7c/0xd0 ? _dofault+0x34/0x160 ? doreadfault+0x5f/0x100 ? dofault+0xb0/0x110 ? _handlemmfault+0x2b0/0x6c0 _syssendmsg+0x4d/0x80 dosyscall64+0x69/0x180 entrySYSCALL64after_hwframe+0x6e/0x76

It is possible that the connection is in process of being established when we dump it. Assumed that the connection has been registered in a link group by smcconncreate() but the rmbdesc has not yet been initialized by smcbufcreate(), thus causing the illegal access to conn->rmbdesc. So fix it by checking before dump.(CVE-2024-26615)

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

ALSA: sh: aica: reorder cleanup operations to avoid UAF bugs

The dreamcastcard->timer could schedule the spudmawork and the spudmawork could also arm the dreamcastcard->timer.

When the sndpcmsubstream is closing, the aicachannel will be deallocated. But it could still be dereferenced in the worker thread. The reason is that deltimer() will return directly regardless of whether the timer handler is running or not and the worker could be rescheduled in the timer handler. As a result, the UAF bug will happen. The racy situation is shown below:

  (Thread 1)                 |      (Thread 2)

sndaicapcmpcmclose() | ... | runspudma() //worker | modtimer() flushwork() | deltimer() | aicaperiodelapsed() //timer kfree(dreamcastcard->channel) | schedulework() | runspu_dma() //worker ... | dreamcastcard->channel-> //USE

In order to mitigate this bug and other possible corner cases, call modtimer() conditionally in runspudma(), then implement PCM syncstop op to cancel both the timer and worker. The sync_stop op will be called from PCM core appropriately when needed.(CVE-2024-26654)

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

drm/amdgpu: fix use-after-free bug

The bug can be triggered by sending a single amdgpugemuserptr_ioctl to the AMDGPU DRM driver on any ASICs with an invalid address and size. The bug was reported by Joonkyo Jung <joonkyoj@yonsei.ac.kr>. For example the following code:

static void Syzkaller1(int fd) { struct drmamdgpugem_userptr arg; int ret;

arg.addr = 0xffffffffffff0000;
arg.size = 0x80000000; /*2 Gb*/
arg.flags = 0x7;
ret = drmIoctl(fd, 0xc1186451/*amdgpu_gem_userptr_ioctl*/, &arg);

}

Due to the address and size are not valid there is a failure in amdgpuhmmregister->mmuintervalnotifierinsert->mmuintervalnotifierinsert-> checkshloverflow, but we even the amdgpuhmmregister failure we still call amdgpuhmmunregister into amdgpugemobject_free which causes access to a bad address. The following stack is below when the issue is reproduced when Kazan is enabled:

[ +0.000014] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020 [ +0.000009] RIP: 0010:mmuintervalnotifierremove+0x327/0x340 [ +0.000017] Code: ff ff 49 89 44 24 08 48 b8 00 01 00 00 00 00 ad de 4c 89 f7 49 89 47 40 48 83 c0 22 49 89 47 48 e8 ce d1 2d 01 e9 32 ff ff ff <0f> 0b e9 16 ff ff ff 4c 89 ef e8 fa 14 b3 ff e9 36 ff ff ff e8 80 [ +0.000014] RSP: 0018:ffffc90002657988 EFLAGS: 00010246 [ +0.000013] RAX: 0000000000000000 RBX: 1ffff920004caf35 RCX: ffffffff8160565b [ +0.000011] RDX: dffffc0000000000 RSI: 0000000000000004 RDI: ffff8881a9f78260 [ +0.000010] RBP: ffffc90002657a70 R08: 0000000000000001 R09: fffff520004caf25 [ +0.000010] R10: 0000000000000003 R11: ffffffff8161d1d6 R12: ffff88810e988c00 [ +0.000010] R13: ffff888126fb5a00 R14: ffff88810e988c0c R15: ffff8881a9f78260 [ +0.000011] FS: 00007ff9ec848540(0000) GS:ffff8883cc880000(0000) knlGS:0000000000000000 [ +0.000012] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0.000010] CR2: 000055b3f7e14328 CR3: 00000001b5770000 CR4: 0000000000350ef0 [ +0.000010] Call Trace: [ +0.000006] <TASK> [ +0.000007] ? showregs+0x6a/0x80 [ +0.000018] ? _warn+0xa5/0x1b0 [ +0.000019] ? mmuintervalnotifierremove+0x327/0x340 [ +0.000018] ? reportbug+0x24a/0x290 [ +0.000022] ? handlebug+0x46/0x90 [ +0.000015] ? excinvalidop+0x19/0x50 [ +0.000016] ? asmexcinvalidop+0x1b/0x20 [ +0.000017] ? kasansavestack+0x26/0x50 [ +0.000017] ? mmuintervalnotifierremove+0x23b/0x340 [ +0.000019] ? mmuintervalnotifierremove+0x327/0x340 [ +0.000019] ? mmuintervalnotifierremove+0x23b/0x340 [ +0.000020] ? _pfxmmuintervalnotifierremove+0x10/0x10 [ +0.000017] ? kasansaveallocinfo+0x1e/0x30 [ +0.000018] ? srsoreturnthunk+0x5/0x5f [ +0.000014] ? _kasankmalloc+0xb1/0xc0 [ +0.000018] ? srsoreturnthunk+0x5/0x5f [ +0.000013] ? _kasancheckread+0x11/0x20 [ +0.000020] amdgpuhmmunregister+0x34/0x50 [amdgpu] [ +0.004695] amdgpugemobjectfree+0x66/0xa0 [amdgpu] [ +0.004534] ? _pfxamdgpugemobjectfree+0x10/0x10 [amdgpu] [ +0.004291] ? dosyscall64+0x5f/0xe0 [ +0.000023] ? srsoreturnthunk+0x5/0x5f [ +0.000017] drmgemobjectfree+0x3b/0x50 [drm] [ +0.000489] amdgpugemuserptrioctl+0x306/0x500 [amdgpu] [ +0.004295] ? _pfxamdgpugemuserptrioctl+0x10/0x10 [amdgpu] [ +0.004270] ? srsoreturnthunk+0x5/0x5f [ +0.000014] ? _thiscpupreemptcheck+0x13/0x20 [ +0.000015] ? srsoreturnthunk+0x5/0x5f [ +0.000013] ? sysvecapictimerinterrupt+0x57/0xc0 [ +0.000020] ? srsoreturnthunk+0x5/0x5f [ +0.000014] ? asmsysvecapictimerinterrupt+0x1b/0x20 [ +0.000022] ? drmioctlkernel+0x17b/0x1f0 [drm] [ +0.000496] ? _pfxamdgpugemuserptrioctl+0x10/0x10 [amdgpu] [ +0.004272] ? drmioctlkernel+0x190/0x1f0 [drm] [ +0.000492] drmioctlkernel+0x140/0x1f0 [drm] [ +0.000497] ? _pfxamdgpugemuserptrioctl+0x10/0x10 [amdgpu] [ +0.004297] ? _pfxdrmioctl_kernel+0x10/0x10 [d ---truncated---(CVE-2024-26656)

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

nilfs2: fix hang in nilfslookupdirtydatabuffers()

Syzbot reported a hang issue in migratepagesbatch() called by mbind() and nilfslookupdirtydatabuffers() called in the log writer of nilfs2.

While migratepagesbatch() locks a folio and waits for the writeback to complete, the log writer thread that should bring the writeback to completion picks up the folio being written back in nilfslookupdirtydatabuffers() that it calls for subsequent log creation and was trying to lock the folio. Thus causing a deadlock.

In the first place, it is unexpected that folios/pages in the middle of writeback will be updated and become dirty. Nilfs2 adds a checksum to verify the validity of the log being written and uses it for recovery at mount, so data changes during writeback are suppressed. Since this is broken, an unclean shutdown could potentially cause recovery to fail.

Investigation revealed that the root cause is that the wait for writeback completion in nilfspagemkwrite() is conditional, and if the backing device does not require stable writes, data may be modified without waiting.

Fix these issues by making nilfspagemkwrite() wait for writeback to finish regardless of the stable write requirement of the backing device.(CVE-2024-26696)