OESA-2025-1080

The Linux Kernel, the operating system core itself.

Security Fix(es):

A race condition was found in the Linux kernel's net/bluetooth in {conn,adv}{min,max}interval_set() function. This can result in I2cap connection or broadcast abnormality issue, possibly leading to denial of service.

(CVE-2024-24858)

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

vfio/platform: Create persistent IRQ handlers

The vfio-platform SET_IRQS ioctl currently allows loopback triggering of an interrupt before a signaling eventfd has been configured by the user, which thereby allows a NULL pointer dereference.

Rather than register the IRQ relative to a valid trigger, register all IRQs in a disabled state in the device open path. This allows mask operations on the IRQ to nest within the overall enable state governed by a valid eventfd signal. This decouples @masked, protected by the @locked spinlock from @trigger, protected via the @igate mutex.

In doing so, it's guaranteed that changes to @trigger cannot race the IRQ handlers because the IRQ handler is synchronously disabled before modifying the trigger, and loopback triggering of the IRQ via ioctl is safe due to serialization with trigger changes via igate.

For compatibility, requestirq() failures are maintained to be local to the SETIRQS ioctl rather than a fatal error in the open device path. This allows, for example, a userspace driver with polling mode support to continue to work regardless of moving the requestirq() call site. This necessarily blocks all SETIRQS access to the failed index.(CVE-2024-26813)

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

geneve: make sure to pull inner header in geneve_rx()

syzbot triggered a bug in geneve_rx() [1]

Issue is similar to the one I fixed in commit 8d975c15c0cd ("ip6tunnel: make sure to pull inner header in _ip6tnlrcv()")

We have to save skb->networkheader in a temporary variable in order to be able to recompute the networkheader pointer after a pskbinetmay_pull() call.

pskbinetmay_pull() makes sure the needed headers are in skb->head.

[1] BUG: KMSAN: uninit-value in IPECNdecapsulate include/net/inetecn.h:302 [inline] BUG: KMSAN: uninit-value in geneverx drivers/net/geneve.c:279 [inline] BUG: KMSAN: uninit-value in geneveudpencaprecv+0x36f9/0x3c10 drivers/net/geneve.c:391 IPECNdecapsulate include/net/inetecn.h:302 [inline] geneverx drivers/net/geneve.c:279 [inline] geneveudpencaprecv+0x36f9/0x3c10 drivers/net/geneve.c:391 udpqueuercvoneskb+0x1d39/0x1f20 net/ipv4/udp.c:2108 udpqueuercvskb+0x6ae/0x6e0 net/ipv4/udp.c:2186 udpunicastrcvskb+0x184/0x4b0 net/ipv4/udp.c:2346 _udp4librcv+0x1c6b/0x3010 net/ipv4/udp.c:2422 udprcv+0x7d/0xa0 net/ipv4/udp.c:2604 ipprotocoldeliverrcu+0x264/0x1300 net/ipv4/ipinput.c:205 iplocaldeliverfinish+0x2b8/0x440 net/ipv4/ipinput.c:233 NFHOOK include/linux/netfilter.h:314 [inline] iplocaldeliver+0x21f/0x490 net/ipv4/ipinput.c:254 dstinput include/net/dst.h:461 [inline] iprcvfinish net/ipv4/ipinput.c:449 [inline] NFHOOK include/linux/netfilter.h:314 [inline] iprcv+0x46f/0x760 net/ipv4/ipinput.c:569 _netifreceiveskbonecore net/core/dev.c:5534 [inline] _netifreceiveskb+0x1a6/0x5a0 net/core/dev.c:5648 processbacklog+0x480/0x8b0 net/core/dev.c:5976 _napipoll+0xe3/0x980 net/core/dev.c:6576 napipoll net/core/dev.c:6645 [inline] netrxaction+0x8b8/0x1870 net/core/dev.c:6778 _dosoftirq+0x1b7/0x7c5 kernel/softirq.c:553 dosoftirq+0x9a/0xf0 kernel/softirq.c:454 _localbhenableip+0x9b/0xa0 kernel/softirq.c:381 localbhenable include/linux/bottomhalf.h:33 [inline] rcureadunlockbh include/linux/rcupdate.h:820 [inline] _devqueuexmit+0x2768/0x51c0 net/core/dev.c:4378 devqueuexmit include/linux/netdevice.h:3171 [inline] packetxmit+0x9c/0x6b0 net/packet/afpacket.c:276 packetsnd net/packet/afpacket.c:3081 [inline] packetsendmsg+0x8aef/0x9f10 net/packet/afpacket.c:3113 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg net/socket.c:745 [inline] _syssendto+0x735/0xa10 net/socket.c:2191 _dosyssendto net/socket.c:2203 [inline] _sesyssendto net/socket.c:2199 [inline] _x64syssendto+0x125/0x1c0 net/socket.c:2199 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcf/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b

Uninit was created at: slabpostallochook mm/slub.c:3819 [inline] slaballocnode mm/slub.c:3860 [inline] kmemcacheallocnode+0x5cb/0xbc0 mm/slub.c:3903 kmallocreserve+0x13d/0x4a0 net/core/skbuff.c:560 _allocskb+0x352/0x790 net/core/skbuff.c:651 allocskb include/linux/skbuff.h:1296 [inline] allocskbwithfrags+0xc8/0xbd0 net/core/skbuff.c:6394 sockallocsendpskb+0xa80/0xbf0 net/core/sock.c:2783 packetallocskb net/packet/afpacket.c:2930 [inline] packetsnd net/packet/afpacket.c:3024 [inline] packetsendmsg+0x70c2/0x9f10 net/packet/afpacket.c:3113 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg net/socket.c:745 [inline] _syssendto+0x735/0xa10 net/socket.c:2191 _dosyssendto net/socket.c:2203 [inline] _sesyssendto net/socket.c:2199 [inline] _x64syssendto+0x125/0x1c0 net/socket.c:2199 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcf/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b(CVE-2024-26857)

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

nilfs2: fix failure to detect DAT corruption in btree and direct mappings

Patch series "nilfs2: fix kernel bug at submitbhwbc()".

This resolves a kernel BUG reported by syzbot. Since there are two flaws involved, I've made each one a separate patch.

The first patch alone resolves the syzbot-reported bug, but I think both fixes should be sent to stable, so I've tagged them as such.

This patch (of 2):

Syzbot has reported a kernel bug in submitbhwbc() when writing file data to a nilfs2 file system whose metadata is corrupted.

There are two flaws involved in this issue.

The first flaw is that when nilfsgetblock() locates a data block using btree or direct mapping, if the disk address translation routine nilfsdattranslate() fails with internal code -ENOENT due to DAT metadata corruption, it can be passed back to nilfsgetblock(). This causes nilfsgetblock() to misidentify an existing block as non-existent, causing both data block lookup and insertion to fail inconsistently.

The second flaw is that nilfsgetblock() returns a successful status in this inconsistent state. This causes the caller _blockwritebeginint() or others to request a read even though the buffer is not mapped, resulting in a BUGON check for the BHMapped flag in submitbhwbc() failing.

This fixes the first issue by changing the return value to code -EINVAL when a conversion using DAT fails with code -ENOENT, avoiding the conflicting condition that leads to the kernel bug described above. Here, code -EINVAL indicates that metadata corruption was detected during the block lookup, which will be properly handled as a file system error and converted to -EIO when passing through the nilfs2 bmap layer.(CVE-2024-26956)

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

clk: qcom: mmcc-apq8084: fix terminating of frequency table arrays

The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcomfindfreq() or qcomfindfreq_floor().

Only compile tested.(CVE-2024-26966)

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

clk: qcom: gcc-ipq8074: fix terminating of frequency table arrays

The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcomfindfreq() or qcomfindfreq_floor().

Only compile tested.(CVE-2024-26969)

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

crypto: qat - resolve race condition during AER recovery

During the PCI AER system's error recovery process, the kernel driver may encounter a race condition with freeing the resetdata structure's memory. If the device restart will take more than 10 seconds the function scheduling that restart will exit due to a timeout, and the resetdata structure will be freed. However, this data structure is used for completion notification after the restart is completed, which leads to a UAF bug.

This results in a KFENCE bug notice.

BUG: KFENCE: use-after-free read in adfdeviceresetworker+0x38/0xa0 [intelqat] Use-after-free read at 0x00000000bc56fddf (in kfence-#142): adfdeviceresetworker+0x38/0xa0 [intelqat] processonework+0x173/0x340

To resolve this race condition, the memory associated to the container of the workstruct is freed on the worker if the timeout expired, otherwise on the function that schedules the worker. The timeout detection can be done by checking if the caller is still waiting for completion or not by using completiondone() function.(CVE-2024-26974)

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

nilfs2: fix OOB in nilfssetde_type

The size of the nilfstypebymode array in the fs/nilfs2/dir.c file is defined as "SIFMT >> SSHIFT", but the nilfssetdetype() function, which uses this array, specifies the index to read from the array in the same way as "(mode & SIFMT) >> SSHIFT".

static void nilfssetdetype(struct nilfsdirentry *de, struct inode *inode) { umodet mode = inode->i_mode;

de->file_type = nilfs_type_by_mode[(mode & S_IFMT)>>S_SHIFT]; // oob

}

However, when the index is determined this way, an out-of-bounds (OOB) error occurs by referring to an index that is 1 larger than the array size when the condition "mode & SIFMT == SIFMT" is satisfied. Therefore, a patch to resize the nilfstypeby_mode array should be applied to prevent OOB errors.(CVE-2024-26981)

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

usb: gadget: f_ncm: Fix UAF ncm object at re-bind after usb ep transport error

When ncm function is working and then stop usb0 interface for link down, ethstop() is called. At this piont, accidentally if usb transport error should happen in usbepenable(), 'inep' and/or 'out_ep' may not be enabled.

After that, ncmdisable() is called to disable for ncm unbind but getherdisconnect() is never called since 'in_ep' is not enabled.

As the result, ncm object is released in ncm unbind but 'dev->port_usb' associated to 'ncm->port' is not NULL.

And when ncm bind again to recover netdev, ncm object is reallocated but usb0 interface is already associated to previous released ncm object.

Therefore, once usb0 interface is up and ethstartxmit() is called, released ncm object is dereferrenced and it might cause use-after-free memory.

[function unlink via configfs] usb0: ethstop dev->portusb=ffffff9b179c3200 --> error happens in usbepenable(). NCM: ncmdisable: ncm=ffffff9b179c3200 --> no getherdisconnect() since ncm->port.inep->enabled is false. NCM: ncmunbind: ncm unbind ncm=ffffff9b179c3200 NCM: ncm_free: ncm free ncm=ffffff9b179c3200 <-- released ncm

[function link via configfs] NCM: ncmalloc: ncm alloc ncm=ffffff9ac4f8a000 NCM: ncmbind: ncm bind ncm=ffffff9ac4f8a000 NCM: ncmsetalt: ncm=ffffff9ac4f8a000 alt=0 usb0: ethopen dev->portusb=ffffff9b179c3200 <-- previous released ncm usb0: ethstart dev->portusb=ffffff9b179c3200 <-- ethstartxmit() --> dev->wrap() Unable to handle kernel paging request at virtual address dead00000000014f

This patch addresses the issue by checking if 'ncm->netdev' is not NULL at ncmdisable() to call getherdisconnect() to deassociate 'dev->portusb'. It's more reasonable to check 'ncm->netdev' to call getherconnect/disconnect rather than check 'ncm->port.in_ep->enabled' since it might not be enabled but the gether connection might be established.(CVE-2024-26996)

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

comedi: vmk80xx: fix incomplete endpoint checking

While vmk80xx does have endpoint checking implemented, some things can fall through the cracks. Depending on the hardware model, URBs can have either bulk or interrupt type, and current version of vmk80xxfindusbendpoints() function does not take that fully into account. While this warning does not seem to be too harmful, at the very least it will crash systems with 'panicon_warn' set on them.

Fix the issue found by Syzkaller [1] by somewhat simplifying the endpoint checking process with usbfindcommon_endpoints() and ensuring that only expected endpoint types are present.

This patch has not been tested on real hardware.

[1] Syzkaller report: usb 1-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 0 PID: 781 at drivers/usb/core/urb.c:504 usbsubmiturb+0xc4e/0x18c0 drivers/usb/core/urb.c:503 ... Call Trace: <TASK> usbstartwaiturb+0x113/0x520 drivers/usb/core/message.c:59 vmk80xxresetdevice drivers/comedi/drivers/vmk80xx.c:227 [inline] vmk80xxautoattach+0xa1c/0x1a40 drivers/comedi/drivers/vmk80xx.c:818 comediautoconfig+0x238/0x380 drivers/comedi/drivers.c:1067 usbprobe_interface+0x5cd/0xb00 drivers/usb/core/driver.c:399 ...

Similar issue also found by Syzkaller:(CVE-2024-27001)

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

s390/sclp: Prevent release of buffer in I/O

When a task waiting for completion of a Store Data operation is interrupted, an attempt is made to halt this operation. If this attempt fails due to a hardware or firmware problem, there is a chance that the SCLP facility might store data into buffers referenced by the original operation at a later time.

Handle this situation by not releasing the referenced data buffers if the halt attempt fails. For current use cases, this might result in a leak of few pages of memory in case of a rare hardware/firmware malfunction.(CVE-2024-44969)

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

dm cache: fix out-of-bounds access to the dirty bitset when resizing

dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access.

Reproduce steps:

1. create a cache device of 1024 cache blocks (128 bytes dirty bitset)

dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dd if=/dev/zero 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"

2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80)

dmsetup suspend cache dmsetup reload cdata --table "0 65536 linear /dev/sdc 8192" dmsetup resume cdata dmsetup resume cache

KASAN reports:

BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131

(...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0

(...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8

Fix by making the index post-incremented.(CVE-2024-50279)

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

drm/i915/hdcp: Add encoder check in hdcp2getcapability

Add encoder check in intelhdcp2get_capability to avoid null pointer error.(CVE-2024-53050)

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

RDMA/hns: Fix NULL pointer derefernce in hnsrocemapmrsg()

ibmapmrsg() allows ULPs to specify NULL as the sgoffset argument. The driver needs to check whether it is a NULL pointer before dereferencing it.(CVE-2024-53226)

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

cachefiles: Fix NULL pointer dereference in object->file

At present, the object->file has the NULL pointer dereference problem in ondemand-mode. The root cause is that the allocated fd and object->file lifetime are inconsistent, and the user-space invocation to anon_fd uses object->file. Following is the process that triggers the issue:

  [write fd]                [umount]

cachefilesondemandfdwriteiter fscachecookiestatemachine cachefileswithdrawcookie if (!file) return -ENOBUFS cachefilescleanupobject cachefilesunmarkinodeinuse fput(object->file) object->file = NULL // file NULL pointer dereference! _cachefileswrite(..., file, ...)

Fix this issue by add an additional reference count to the object->file before write/llseek, and decrement after it finished.(CVE-2024-56549)

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

ksmbd: fix Out-of-Bounds Write in ksmbdvfsstream_write

An offset from client could be a negative value, It could allows to write data outside the bounds of the allocated buffer. Note that this issue is coming when setting 'vfs objects = streams_xattr parameter' in ksmbd.conf..(CVE-2024-56626)

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

net: hsr: avoid potential out-of-bound access in fillframeinfo()

syzbot is able to feed a packet with 14 bytes, pretending it is a vlan one.

Since fillframeinfo() is relying on skb->mac_len already, extend the check to cover this case.

BUG: KMSAN: uninit-value in fillframeinfo net/hsr/hsrforward.c:709 [inline] BUG: KMSAN: uninit-value in hsrforwardskb+0x9ee/0x3b10 net/hsr/hsrforward.c:724 fillframeinfo net/hsr/hsrforward.c:709 [inline] hsrforwardskb+0x9ee/0x3b10 net/hsr/hsrforward.c:724 hsrdevxmit+0x2f0/0x350 net/hsr/hsrdevice.c:235 _netdevstartxmit include/linux/netdevice.h:5002 [inline] netdevstartxmit include/linux/netdevice.h:5011 [inline] xmitone net/core/dev.c:3590 [inline] devhardstartxmit+0x247/0xa20 net/core/dev.c:3606 _devqueuexmit+0x366a/0x57d0 net/core/dev.c:4434 devqueuexmit include/linux/netdevice.h:3168 [inline] packetxmit+0x9c/0x6c0 net/packet/afpacket.c:276 packetsnd net/packet/afpacket.c:3146 [inline] packetsendmsg+0x91ae/0xa6f0 net/packet/afpacket.c:3178 socksendmsgnosec net/socket.c:711 [inline] _socksendmsg+0x30f/0x380 net/socket.c:726 _syssendto+0x594/0x750 net/socket.c:2197 _dosyssendto net/socket.c:2204 [inline] _sesyssendto net/socket.c:2200 [inline] _x64syssendto+0x125/0x1d0 net/socket.c:2200 x64syscall+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls64.h:45 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f

Uninit was created at: slabpostallochook mm/slub.c:4091 [inline] slaballocnode mm/slub.c:4134 [inline] kmemcacheallocnodenoprof+0x6bf/0xb80 mm/slub.c:4186 kmallocreserve+0x13d/0x4a0 net/core/skbuff.c:587 _allocskb+0x363/0x7b0 net/core/skbuff.c:678 allocskb include/linux/skbuff.h:1323 [inline] allocskbwithfrags+0xc8/0xd00 net/core/skbuff.c:6612 sockallocsendpskb+0xa81/0xbf0 net/core/sock.c:2881 packetallocskb net/packet/afpacket.c:2995 [inline] packetsnd net/packet/afpacket.c:3089 [inline] packetsendmsg+0x74c6/0xa6f0 net/packet/afpacket.c:3178 socksendmsgnosec net/socket.c:711 [inline] _socksendmsg+0x30f/0x380 net/socket.c:726 _syssendto+0x594/0x750 net/socket.c:2197 _dosyssendto net/socket.c:2204 [inline] _sesyssendto net/socket.c:2200 [inline] _x64syssendto+0x125/0x1d0 net/socket.c:2200 x64syscall+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls64.h:45 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f(CVE-2024-56648)

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

crypto: pcrypt - Call crypto layer directly when padatadoparallel() return -EBUSY

Since commit 8f4f68e788c3 ("crypto: pcrypt - Fix hungtask for PADATARESET"), the pcrypt encryption and decryption operations return -EAGAIN when the CPU goes online or offline. In algtest(), a WARN is generated when pcryptaeaddecrypt() or pcryptaeadencrypt() returns -EAGAIN, the unnecessary panic will occur when paniconwarn set 1. Fix this issue by calling crypto layer directly without parallelization in that case.(CVE-2024-56690)

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

octeontx2-pf: handle otx2mboxgetrsp errors in otx2ethtool.c

Add error pointer check after calling otx2mboxget_rsp().(CVE-2024-56728)

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

btrfs: check folio mapping after unlock in relocateonefolio()

When we call btrfsreadfolio() to bring a folio uptodate, we unlock the folio. The result of that is that a different thread can modify the mapping (like remove it with invalidate) before we call folio_lock(). This results in an invalid page and we need to try again.

In particular, if we are relocating concurrently with aborting a transaction, this can result in a crash like the following:

BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] SMP CPU: 76 PID: 1411631 Comm: kworker/u322:5 Workqueue: eventsunbound btrfsreclaimbgswork RIP: 0010:setpageextentmapped+0x20/0xb0 RSP: 0018:ffffc900516a7be8 EFLAGS: 00010246 RAX: ffffea009e851d08 RBX: ffffea009e0b1880 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffc900516a7b90 RDI: ffffea009e0b1880 RBP: 0000000003573000 R08: 0000000000000001 R09: ffff88c07fd2f3f0 R10: 0000000000000000 R11: 0000194754b575be R12: 0000000003572000 R13: 0000000003572fff R14: 0000000000100cca R15: 0000000005582fff FS: 0000000000000000(0000) GS:ffff88c07fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000407d00f002 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? _die+0x78/0xc0 ? pagefaultoops+0x2a8/0x3a0 ? _switchto+0x133/0x530 ? wqworkerrunning+0xa/0x40 ? excpagefault+0x63/0x130 ? asmexcpagefault+0x22/0x30 ? setpageextentmapped+0x20/0xb0 relocatefileextentcluster+0x1a7/0x940 relocatedataextent+0xaf/0x120 relocateblockgroup+0x20f/0x480 btrfsrelocateblockgroup+0x152/0x320 btrfsrelocatechunk+0x3d/0x120 btrfsreclaimbgswork+0x2ae/0x4e0 processscheduledworks+0x184/0x370 workerthread+0xc6/0x3e0 ? blkaddtimer+0xb0/0xb0 kthread+0xae/0xe0 ? flushtlbkernelrange+0x90/0x90 retfromfork+0x2f/0x40 ? flushtlbkernelrange+0x90/0x90 retfromfork_asm+0x11/0x20 </TASK>

This occurs because cleanuponetransaction() calls destroydelallocinodes() which calls invalidateinodepages2() which takes the foliolock before setting mapping to NULL. We fail to check this, and subsequently call setextent_mapping(), which assumes that mapping != NULL (in fact it asserts that in debug mode)

Note that the "fixes" patch here is not the one that introduced the race (the very first iteration of this code from 2009) but a more recent change that made this particular crash happen in practice.(CVE-2024-56758)