OESA-2024-1652

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

s390/dasd: fix Oops in dasdaliasgetstartdev due to missing pavgroup

Fix Oops in dasdaliasgetstartdev() function caused by the pavgroup pointer being NULL.

The pavgroup pointer is checked on the entrance of the function but without the lcu->lock being held. Therefore there is a race window between dasdaliasgetstartdev() and lcuupdate() which sets pavgroup to NULL with the lcu->lock held.

Fix by checking the pavgroup pointer with lcu->lock held.(CVE-2022-48636)

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

btrfs: fix hang during unmount when stopping a space reclaim worker

Often when running generic/562 from fstests we can hang during unmount, resulting in a trace like this:

Sep 07 11:52:00 debian9 unknown: run fstests generic/562 at 2022-09-07 11:52:00 Sep 07 11:55:32 debian9 kernel: INFO: task umount:49438 blocked for more than 120 seconds. Sep 07 11:55:32 debian9 kernel: Not tainted 6.0.0-rc2-btrfs-next-122 #1 Sep 07 11:55:32 debian9 kernel: "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. Sep 07 11:55:32 debian9 kernel: task:umount state:D stack: 0 pid:49438 ppid: 25683 flags:0x00004000 Sep 07 11:55:32 debian9 kernel: Call Trace: Sep 07 11:55:32 debian9 kernel: <TASK> Sep 07 11:55:32 debian9 kernel: _schedule+0x3c8/0xec0 Sep 07 11:55:32 debian9 kernel: ? rcureadlockschedheld+0x12/0x70 Sep 07 11:55:32 debian9 kernel: schedule+0x5d/0xf0 Sep 07 11:55:32 debian9 kernel: scheduletimeout+0xf1/0x130 Sep 07 11:55:32 debian9 kernel: ? lockrelease+0x224/0x4a0 Sep 07 11:55:32 debian9 kernel: ? lockacquired+0x1a0/0x420 Sep 07 11:55:32 debian9 kernel: ? tracehardirqson+0x2c/0xd0 Sep 07 11:55:32 debian9 kernel: _waitforcommon+0xac/0x200 Sep 07 11:55:32 debian9 kernel: ? usleeprangestate+0xb0/0xb0 Sep 07 11:55:32 debian9 kernel: _flushwork+0x26d/0x530 Sep 07 11:55:32 debian9 kernel: ? flushworkqueuepreppwqs+0x140/0x140 Sep 07 11:55:32 debian9 kernel: ? traceclocklocal+0xc/0x30 Sep 07 11:55:32 debian9 kernel: _cancelworktimer+0x11f/0x1b0 Sep 07 11:55:32 debian9 kernel: ? closectree+0x12b/0x5b3 [btrfs] Sep 07 11:55:32 debian9 kernel: ? _tracebputs+0x10b/0x170 Sep 07 11:55:32 debian9 kernel: closectree+0x152/0x5b3 [btrfs] Sep 07 11:55:32 debian9 kernel: ? evictinodes+0x166/0x1c0 Sep 07 11:55:32 debian9 kernel: genericshutdownsuper+0x71/0x120 Sep 07 11:55:32 debian9 kernel: killanonsuper+0x14/0x30 Sep 07 11:55:32 debian9 kernel: btrfskillsuper+0x12/0x20 [btrfs] Sep 07 11:55:32 debian9 kernel: deactivatelockedsuper+0x2e/0xa0 Sep 07 11:55:32 debian9 kernel: cleanupmnt+0x100/0x160 Sep 07 11:55:32 debian9 kernel: taskworkrun+0x59/0xa0 Sep 07 11:55:32 debian9 kernel: exittousermodeprepare+0x1a6/0x1b0 Sep 07 11:55:32 debian9 kernel: syscallexittousermode+0x16/0x40 Sep 07 11:55:32 debian9 kernel: dosyscall64+0x48/0x90 Sep 07 11:55:32 debian9 kernel: entrySYSCALL64afterhwframe+0x63/0xcd Sep 07 11:55:32 debian9 kernel: RIP: 0033:0x7fcde59a57a7 Sep 07 11:55:32 debian9 kernel: RSP: 002b:00007ffe914217c8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 Sep 07 11:55:32 debian9 kernel: RAX: 0000000000000000 RBX: 00007fcde5ae8264 RCX: 00007fcde59a57a7 Sep 07 11:55:32 debian9 kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000055b57556cdd0 Sep 07 11:55:32 debian9 kernel: RBP: 000055b57556cba0 R08: 0000000000000000 R09: 00007ffe91420570 Sep 07 11:55:32 debian9 kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 Sep 07 11:55:32 debian9 kernel: R13: 000055b57556cdd0 R14: 000055b57556ccb8 R15: 0000000000000000 Sep 07 11:55:32 debian9 kernel: </TASK>

What happens is the following:

1) The cleaner kthread tries to start a transaction to delete an unused block group, but the metadata reservation can not be satisfied right away, so a reservation ticket is created and it starts the async metadata reclaim task (fsinfo->asyncreclaim_work);

2) Writeback for all the filler inodes with an isize of 2K starts (generic/562 creates a lot of 2K files with the goal of filling metadata space). We try to create an inline extent for them, but we fail when trying to insert the inline extent with -ENOSPC (at cowfilerangeinline()) - since this is not critical, we fallback to non-inline mode (back to cowfilerange()), reserve extents ---truncated---(CVE-2022-48664)

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

powerpc/imc-pmu: Add a null pointer check in updateeventsin_group()

kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure.(CVE-2023-52675)

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

nfc: nci: free rxdatareassembly skb on NCI device cleanup

rxdatareassembly skb is stored during NCI data exchange for processing fragmented packets. It is dropped only when the last fragment is processed or when an NTF packet with NCIOPRFDEACTIVATENTF opcode is received. However, the NCI device may be deallocated before that which leads to skb leak.

As by design the rxdatareassembly skb is bound to the NCI device and nothing prevents the device to be freed before the skb is processed in some way and cleaned, free it on the NCI device cleanup.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2024-26825)

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

netfilter: nfconntrackh323: Add protection for bmp length out of range

UBSAN load reports an exception of BRK#5515 SHIFT_ISSUE:Bitwise shifts that are out of bounds for their data type.

vmlinux getbitmap(b=75) + 712 <net/netfilter/nfconntrackh323asn1.c:0> vmlinux decodeseq(bs=0xFFFFFFD008037000, f=0xFFFFFFD008037018, level=134443100) + 1956 <net/netfilter/nfconntrackh323asn1.c:592> vmlinux decodechoice(base=0xFFFFFFD0080370F0, level=23843636) + 1216 <net/netfilter/nfconntrackh323asn1.c:814> vmlinux decodeseq(f=0xFFFFFFD0080371A8, level=134443500) + 812 <net/netfilter/nfconntrackh323asn1.c:576> vmlinux decodechoice(base=0xFFFFFFD008037280, level=0) + 1216 <net/netfilter/nfconntrackh323asn1.c:814> vmlinux DecodeRasMessage() + 304 <net/netfilter/nfconntrackh323asn1.c:833> vmlinux rashelp() + 684 <net/netfilter/nfconntrackh323main.c:1728> vmlinux nfconfirm() + 188 <net/netfilter/nfconntrackproto.c:137>

Due to abnormal data in skb->data, the extension bitmap length exceeds 32 when decoding ras message then uses the length to make a shift operation. It will change into negative after several loop. UBSAN load could detect a negative shift as an undefined behaviour and reports exception. So we add the protection to avoid the length exceeding 32. Or else it will return out of range error and stop decoding.(CVE-2024-26851)

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

rds: tcp: Fix use-after-free of net in reqsktimerhandler().

syzkaller reported a warning of netns tracker [0] followed by KASAN splat [1] and another ref tracker warning [1].

syzkaller could not find a repro, but in the log, the only suspicious sequence was as follows:

18:26:22 executing program 1: r0 = socket$inet6_mptcp(0xa, 0x1, 0x106) ... connect$inet6(r0, &(0x7f0000000080)={0xa, 0x4001, 0x0, @loopback}, 0x1c) (async)

The notable thing here is 0x4001 in connect(), which is RDSTCPPORT.

So, the scenario would be:

1. unshare(CLONENEWNET) creates a per netns tcp listener in rdstcplisteninit().
2. syz-executor connect()s to it and creates a reqsk.
3. syz-executor exit()s immediately.
4. netns is dismantled. [0]
5. reqsk timer is fired, and UAF happens while freeing reqsk. [1]
6. listener is freed after RCU grace period. [2]

Basically, reqsk assumes that the listener guarantees netns safety until all reqsk timers are expired by holding the listener's refcount. However, this was not the case for kernel sockets.

Commit 740ea3c4a0b2 ("tcp: Clean up kernel listener's reqsk in inettwskpurge()") fixed this issue only for per-netns ehash.

Let's apply the same fix for the global ehash.

 sk_alloc (./include/net/net_namespace.h:337 net/core/sock.c:2146)
 inet6_create (net/ipv6/af_inet6.c:192 net/ipv6/af_inet6.c:119)
 __sock_create (net/socket.c:1572)
 rds_tcp_listen_init (net/rds/tcp_listen.c:279)
 rds_tcp_init_net (net/rds/tcp.c:577)
 ops_init (net/core/net_namespace.c:137)
 setup_net (net/core/net_namespace.c:340)
 copy_net_ns (net/core/net_namespace.c:497)
 create_new_namespaces (kernel/nsproxy.c:110)
 unshare_nsproxy_namespaces (kernel/nsproxy.c:228 (discriminator 4))
 ksys_unshare (kernel/fork.c:3429)
 __x64_sys_unshare (kernel/fork.c:3496)
 do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
 entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)

... WARNING: CPU: 0 PID: 27 at lib/reftracker.c:179 reftrackerdirexit (lib/ref_tracker.c:179)

Read of size 8 at addr ffff88801b370400 by task swapper/0/0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Call Trace: <IRQ> dumpstacklvl (lib/dumpstack.c:107 (discriminator 1)) printreport (mm/kasan/report.c:378 mm/kasan/report.c:488) kasanreport (mm/kasan/report.c:603) inetcskreqskqueuedrop (./include/net/inethashtables.h:180 net/ipv4/inetconnectionsock.c:952 net/ipv4/inetconnectionsock.c:966) reqsktimerhandler (net/ipv4/inetconnectionsock.c:979 net/ipv4/inetconnectionsock.c:1092) calltimerfn (./arch/x86/include/asm/jumplabel.h:27 ./include/linux/jumplabel.h:207 ./include/trace/events/timer.h:127 kernel/time/timer.c:1701) _runtimers.part.0 (kernel/time/timer.c:1752 kernel/time/timer.c:2038) runtimersoftirq (kernel/time/timer.c:2053) _dosoftirq (./arch/x86/include/asm/jumplabel.h:27 ./include/linux/jumplabel.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:554) irqexitrcu (kernel/softirq.c:427 kernel/softirq.c:632 kernel/softirq.c:644) sysvecapictimer_interrupt (arch/x86/kernel/apic/apic.c:1076 (discriminator 14)) </IRQ>

Allocated by task 258 on cpu 0 at 83.612050s: kasansavestack (mm/kasan/common.c:48) kasansavetrack (mm/kasan/common.c:68) _kasanslaballoc (mm/kasan/common.c:343) kmemcachealloc (mm/slub.c:3813 mm/slub.c:3860 mm/slub.c:3867) copynetns (./include/linux/slab.h:701 net/core/netnamespace.c:421 net/core/netnamespace.c:480) createnewnamespaces (kernel/nsproxy.c:110) unsharensproxy_name ---truncated---(CVE-2024-26865)

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

dosysnametohandle(): use kzalloc() to fix kernel-infoleak

syzbot identified a kernel information leak vulnerability in dosysnametohandle() and issued the following report [1].

[1] "BUG: KMSAN: kernel-infoleak in instrumentcopytouser include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copytouser+0xbc/0x100 lib/usercopy.c:40 instrumentcopytouser include/linux/instrumented.h:114 [inline] copytouser+0xbc/0x100 lib/usercopy.c:40 copytouser include/linux/uaccess.h:191 [inline] dosysnametohandle fs/fhandle.c:73 [inline] _dosysnametohandleat fs/fhandle.c:112 [inline] _sesysnametohandleat+0x949/0xb10 fs/fhandle.c:94 _x64sysnametohandle_at+0xe4/0x140 fs/fhandle.c:94 ...

Uninit was created at: slabpostallochook+0x129/0xa70 mm/slab.h:768 slaballocnode mm/slub.c:3478 [inline] _kmemcacheallocnode+0x5c9/0x970 mm/slub.c:3517 _dokmallocnode mm/slabcommon.c:1006 [inline] _kmalloc+0x121/0x3c0 mm/slabcommon.c:1020 kmalloc include/linux/slab.h:604 [inline] dosysnametohandle fs/fhandle.c:39 [inline] _dosysnametohandleat fs/fhandle.c:112 [inline] _sesysnametohandleat+0x441/0xb10 fs/fhandle.c:94 _x64sysnametohandle_at+0xe4/0x140 fs/fhandle.c:94 ...

Bytes 18-19 of 20 are uninitialized Memory access of size 20 starts at ffff888128a46380 Data copied to user address 0000000020000240"

Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() to solve the problem.(CVE-2024-26901)

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

Bluetooth: rfcomm: Fix null-ptr-deref in rfcommchecksecurity

During our fuzz testing of the connection and disconnection process at the RFCOMM layer, we discovered this bug. By comparing the packets from a normal connection and disconnection process with the testcase that triggered a KASAN report. We analyzed the cause of this bug as follows:

1. In the packets captured during a normal connection, the host sends a Read Encryption Key Size type of HCI_CMD packet (Command Opcode: 0x1408) to the controller to inquire the length of encryption key.After receiving this packet, the controller immediately replies with a Command Completepacket (Event Code: 0x0e) to return the Encryption Key Size.

2. In our fuzz test case, the timing of the controller's response to this packet was delayed to an unexpected point: after the RFCOMM and L2CAP layers had disconnected but before the HCI layer had disconnected.

3. After receiving the Encryption Key Size Response at the time described in point 2, the host still called the rfcommchecksecurity function. However, by this time struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn; had already been released, and when the function executed return hci_conn_security(conn->hcon, d->sec_level, auth_type, d->out);, specifically when accessing conn->hcon, a null-ptr-deref error occurred.

To fix this bug, check if sk->sk_state is BTCLOSED before calling rfcommrecvframe in rfcommprocess_rx.(CVE-2024-26903)

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-26908)

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

inet: inet_defrag: prevent sk release while still in use

iplocalout() and other functions can pass skb->sk as function argument.

If the skb is a fragment and reassembly happens before such function call returns, the sk must not be released.

This affects skb fragments reassembled via netfilter or similar modules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline.

Eric Dumazet made an initial analysis of this bug. Quoting Eric: Calling ipdefrag() in output path is also implying skborphan(), which is buggy because output path relies on sk not disappearing.

A relevant old patch about the issue was : 8282f27449bf ("inet: frag: Always orphan skbs inside ip_defrag()")

[..]

net/ipv4/ip_output.c depends on skb->sk being set, and probably to an inet socket, not an arbitrary one.

If we orphan the packet in ipvlan, then downstream things like FQ packet scheduler will not work properly.

We need to change ipdefrag() to only use skborphan() when really needed, ie whenever frag_list is going to be used.

Eric suggested to stash sk in fragment queue and made an initial patch. However there is a problem with this:

If skb is refragmented again right after, ipdofragment() will copy head->sk to the new fragments, and sets up destructor to sockwfree. IOW, we have no choice but to fix up skwmem accouting to reflect the fully reassembled skb, else wmem will underflow.

This change moves the orphan down into the core, to last possible moment. As ipdefragoffset is aliased with skbuff->sk member, we must move the offset into the FRAGCB, else skb->sk gets clobbered.

This allows to delay the orphaning long enough to learn if the skb has to be queued or if the skb is completing the reasm queue.

In the former case, things work as before, skb is orphaned. This is safe because skb gets queued/stolen and won't continue past reasm engine.

In the latter case, we will steal the skb->sk reference, reattach it to the head skb, and fix up wmem accouting when inet_frag inflates truesize.(CVE-2024-26921)

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

af_unix: Fix garbage collector racing against connect()

Garbage collector does not take into account the risk of embryo getting enqueued during the garbage collection. If such embryo has a peer that carries SCMRIGHTS, two consecutive passes of scanchildren() may see a different set of children. Leading to an incorrectly elevated inflight count, and then a dangling pointer within the gcinflightlist.

sockets are AFUNIX/SOCKSTREAM S is an unconnected socket L is a listening in-flight socket bound to addr, not in fdtable V's fd will be passed via sendmsg(), gets inflight count bumped

connect(S, addr) sendmsg(S, [V]); close(V) _unixgc() ---------------- ------------------------- -----------

NS = unixcreate1() skb1 = sockwmalloc(NS) L = unixfindother(addr) unixstatelock(L) unix_peer(S) = NS // V count=1 inflight=0

        NS = unix_peer(S)
        skb2 = sock_alloc()
        skb_queue_tail(NS, skb2[V])

        // V became in-flight
        // V count=2 inflight=1

        close(V)

        // V count=1 inflight=1
        // GC candidate condition met

                    for u in gc_inflight_list:
                      if (total_refs == inflight_refs)
                        add u to gc_candidates

                    // gc_candidates={L, V}

                    for u in gc_candidates:
                      scan_children(u, dec_inflight)

                    // embryo (skb1) was not
                    // reachable from L yet, so V's
                    // inflight remains unchanged

_skbqueuetail(L, skb1) unixstateunlock(L) for u in gccandidates: if (u.inflight) scanchildren(u, incinflightmovetail)

                    // V count=1 inflight=2 (!)

If there is a GC-candidate listening socket, lock/unlock its state. This makes GC wait until the end of any ongoing connect() to that socket. After flipping the lock, a possibly SCM-laden embryo is already enqueued. And if there is another embryo coming, it can not possibly carry SCMRIGHTS. At this point, unixinflight() can not happen because unixgclock is already taken. Inflight graph remains unaffected.(CVE-2024-26923)

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

binder: check offset alignment in bindergetobject()

Commit 6d98eb95b450 ("binder: avoid potential data leakage when copying txn") introduced changes to how binder objects are copied. In doing so, it unintentionally removed an offset alignment check done through calls to binderalloccopyfrombuffer() -> check_buffer().

These calls were replaced in bindergetobject() with copyfromuser(), so now an explicit offset alignment check is needed here. This avoids later complications when unwinding the objects gets harder.

It is worth noting this check existed prior to commit 7a67a39320df ("binder: add function to copy binder object from buffer"), likely removed due to redundancy at the time.(CVE-2024-26926)

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

net: openvswitch: Fix Use-After-Free in ovsctexit

Since kfreercu, which is called in the hlistforeachentryrcu traversal of ovsctlimitexit, is not part of the RCU read critical section, it is possible that the RCU grace period will pass during the traversal and the key will be free.

To prevent this, it should be changed to hlistforeachentrysafe.(CVE-2024-27395)

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

net: gtp: Fix Use-After-Free in gtp_dellink

Since callrcu, which is called in the hlistforeachentryrcu traversal of gtpdellink, is not part of the RCU read critical section, it is possible that the RCU grace period will pass during the traversal and the key will be free.

To prevent this, it should be changed to hlistforeachentrysafe.(CVE-2024-27396)

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

Bluetooth: Fix use-after-free bugs caused by scosocktimeout

When the sco connection is established and then, the sco socket is releasing, timeoutwork will be scheduled to judge whether the sco disconnection is timeout. The sock will be deallocated later, but it is dereferenced again in scosock_timeout. As a result, the use-after-free bugs will happen. The root cause is shown below:

Cleanup Thread               |      Worker Thread

scosockrelease | scosockclose | _scosockclose | scosocksettimer | scheduledelayedwork | scosockkill | (wait a time) sockput(sk) //FREE | scosocktimeout | sockhold(sk) //USE

The KASAN report triggered by POC is shown below:

[ 95.890016] ================================================================== [ 95.890496] BUG: KASAN: slab-use-after-free in scosocktimeout+0x5e/0x1c0 [ 95.890755] Write of size 4 at addr ffff88800c388080 by task kworker/0:0/7 ... [ 95.890755] Workqueue: events scosocktimeout [ 95.890755] Call Trace: [ 95.890755] <TASK> [ 95.890755] dumpstacklvl+0x45/0x110 [ 95.890755] printaddressdescription+0x78/0x390 [ 95.890755] printreport+0x11b/0x250 [ 95.890755] ? _virtaddrvalid+0xbe/0xf0 [ 95.890755] ? scosocktimeout+0x5e/0x1c0 [ 95.890755] kasanreport+0x139/0x170 [ 95.890755] ? updateloadavg+0xe5/0x9f0 [ 95.890755] ? scosocktimeout+0x5e/0x1c0 [ 95.890755] kasancheckrange+0x2c3/0x2e0 [ 95.890755] scosocktimeout+0x5e/0x1c0 [ 95.890755] processonework+0x561/0xc50 [ 95.890755] workerthread+0xab2/0x13c0 [ 95.890755] ? prcontwork+0x490/0x490 [ 95.890755] kthread+0x279/0x300 [ 95.890755] ? prcontwork+0x490/0x490 [ 95.890755] ? kthreadblkcg+0xa0/0xa0 [ 95.890755] retfromfork+0x34/0x60 [ 95.890755] ? kthreadblkcg+0xa0/0xa0 [ 95.890755] retfromforkasm+0x11/0x20 [ 95.890755] </TASK> [ 95.890755] [ 95.890755] Allocated by task 506: [ 95.890755] kasansavetrack+0x3f/0x70 [ 95.890755] _kasankmalloc+0x86/0x90 [ 95.890755] _kmalloc+0x17f/0x360 [ 95.890755] skprotalloc+0xe1/0x1a0 [ 95.890755] skalloc+0x31/0x4e0 [ 95.890755] btsockalloc+0x2b/0x2a0 [ 95.890755] scosockcreate+0xad/0x320 [ 95.890755] btsockcreate+0x145/0x320 [ 95.890755] _sockcreate+0x2e1/0x650 [ 95.890755] _syssocket+0xd0/0x280 [ 95.890755] _x64syssocket+0x75/0x80 [ 95.890755] dosyscall64+0xc4/0x1b0 [ 95.890755] entrySYSCALL64afterhwframe+0x67/0x6f [ 95.890755] [ 95.890755] Freed by task 506: [ 95.890755] kasansavetrack+0x3f/0x70 [ 95.890755] kasansavefreeinfo+0x40/0x50 [ 95.890755] poisonslabobject+0x118/0x180 [ 95.890755] _kasanslabfree+0x12/0x30 [ 95.890755] kfree+0xb2/0x240 [ 95.890755] _skdestruct+0x317/0x410 [ 95.890755] scosockrelease+0x232/0x280 [ 95.890755] sockclose+0xb2/0x210 [ 95.890755] _fput+0x37f/0x770 [ 95.890755] taskworkrun+0x1ae/0x210 [ 95.890755] getsignal+0xe17/0xf70 [ 95.890755] archdosignalorrestart+0x3f/0x520 [ 95.890755] syscallexittousermode+0x55/0x120 [ 95.890755] dosyscall64+0xd1/0x1b0 [ 95.890755] entrySYSCALL64afterhwframe+0x67/0x6f [ 95.890755] [ 95.890755] The buggy address belongs to the object at ffff88800c388000 [ 95.890755] which belongs to the cache kmalloc-1k of size 1024 [ 95.890755] The buggy address is located 128 bytes inside of [ 95.890755] freed 1024-byte region [ffff88800c388000, ffff88800c388400) [ 95.890755] [ 95.890755] The buggy address belongs to the physical page: [ 95.890755] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88800c38a800 pfn:0xc388 [ 95.890755] head: order:3 entiremapcount:0 nrpagesmapped:0 pincount:0 [ 95.890755] ano ---truncated---(CVE-2024-27398)