OESA-2025-1282

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

ARM: davinci: da850-evm: Avoid NULL pointer dereference

With newer versions of GCC, there is a panic in da850evmconfigemac() when booting multiv5_defconfig in QEMU under the palmetto-bmc machine:

Unable to handle kernel NULL pointer dereference at virtual address 00000020 pgd = (ptrval) [00000020] *pgd=00000000 Internal error: Oops: 5 [#1] PREEMPT ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 5.15.0 #1 Hardware name: Generic DT based system PC is at da850evmconfigemac+0x1c/0x120 LR is at doone_initcall+0x50/0x1e0

The emacpdata pointer in socinfo is NULL because davincisocinfo only gets populated on davinci machines but da850evmconfigemac() is called on all machines via deviceinitcall().

Move the rmii_en assignment below the machine check so that it is only dereferenced when running on a supported SoC.(CVE-2021-47631)

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

video: fbdev: nvidiafb: Use strscpy() to prevent buffer overflow

Coverity complains of a possible buffer overflow. However, given the 'static' scope of nvidiasetupi2c_bus() it looks like that can't happen after examiniing the call sites.

CID 19036 (#1 of 1): Copy into fixed size buffer (STRINGOVERFLOW) 1. fixedsizedest: You might overrun the 48-character fixed-size string chan->adapter.name by copying name without checking the length. 2. parameteras_source: Note: This defect has an elevated risk because the source argument is a parameter of the current function. 89 strcpy(chan->adapter.name, name);

Fix this warning by using strscpy() which will silence the warning and prevent any future buffer overflows should the names used to identify the channel become much longer.(CVE-2021-47642)

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

dm integrity: fix memory corruption when tag_size is less than digest size

It is possible to set up dm-integrity in such a way that the "tagsize" parameter is less than the actual digest size. In this situation, a part of the digest beyond tagsize is ignored.

In this case, dm-integrity would write beyond the end of the ic->recalctags array and corrupt memory. The corruption happened in integrityrecalc->integritysectorchecksum->cryptoshashfinal.

Fix this corruption by increasing the tags array so that it has enough padding at the end to accomodate the loop in integrity_recalc() being able to write a full digest size for the last member of the tags array.(CVE-2022-49044)

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

drm/amdkfd: Check for potential null return of kmalloc_array()

As the kmallocarray() may return null, the 'eventwaiters[i].wait' would lead to null-pointer dereference. Therefore, it is better to check the return value of kmalloc_array() to avoid this confusion.(CVE-2022-49055)

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

scsi: libfc: Fix use after free in fcexchabts_resp()

fcexchrelease(ep) will decrease the ep's reference count. When the reference count reaches zero, it is freed. But ep is still used in the following code, which will lead to a use after free.

Return after the fcexchrelease() call to avoid use after free.(CVE-2022-49114)

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

drm/amd/amdgpu/amdgpucs: fix refcount leak of a dmafence obj

This issue takes place in an error path in amdgpucsfencetohandleioctl(). When info->in.what falls into default case, the function simply returns -EINVAL, forgetting to decrement the reference count of a dmafence obj, which is bumped earlier by amdgpucsget_fence(). This may result in reference count leaks.

Fix it by decreasing the refcount of specific object before returning the error code.(CVE-2022-49137)

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

media: usb: go7007: s2250-board: fix leak in probe()

Call i2cunregisterdevice(audio) on this error path.(CVE-2022-49253)

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

extcon: Modify extcon device to be created after driver data is set

Currently, someone can invoke the sysfs such as stateshow() intermittently before devset_drvdata() is done. And it can be a cause of kernel Oops because of edev is Null at that time. So modified the driver registration to after setting drviver data.

• Oops's backtrace.

Backtrace: [<c067865c>] (stateshow) from [<c05222e8>] (devattrshow) [<c05222c0>] (devattrshow) from [<c02c66e0>] (sysfskfseqshow) [<c02c6648>] (sysfskfseqshow) from [<c02c496c>] (kernfsseqshow) [<c02c4938>] (kernfsseqshow) from [<c025e2a0>] (seqread) [<c025e11c>] (seqread) from [<c02c50a0>] (kernfsfopread) [<c02c5064>] (kernfsfopread) from [<c0231cac>] (vfsread) [<c0231c5c>] (vfsread) from [<c0231ee0>] (vfsread) [<c0231e34>] (vfsread) from [<c0232464>] (ksysread) [<c02323f0>] (ksysread) from [<c02324fc>] (sysread) [<c02324e4>] (sysread) from [<c00091d0>] (systrace_return)(CVE-2022-49308)

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

rtl818x: Prevent using not initialized queues

Using not existing queues can panic the kernel with rtl8180/rtl8185 cards. Ignore the skb priority for those cards, they only have one tx queue. Pierre Asselin (pa@panix.com) reported the kernel crash in the Gentoo forum:

https://forums.gentoo.org/viewtopic-t-1147832-postdays-0-postorder-asc-start-25.html

He also confirmed that this patch fixes the issue. In summary this happened:

After updating wpasupplicant from 2.9 to 2.10 the kernel crashed with a "divide error: 0000" when connecting to an AP. Control port tx now tries to use IEEE80211ACVO for the priority, which wpasupplicants starts to use in 2.10.

Since only the rtl8187se part of the driver supports QoS, the priority of the skb is set to IEEE80211ACBE (2) by mac80211 for rtl8180/rtl8185 cards.

rtl8180 is then unconditionally reading out the priority and finally crashes on drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c line 544 without this patch: idx = (ring->idx + skbqueuelen(&ring->queue)) % ring->entries

"ring->entries" is zero for rtl8180/rtl8185 cards, tx_ring[2] never got initialized.(CVE-2022-49326)

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

bpf, arm64: Clear prog->jited_len along prog->jited

syzbot reported an illegal copytouser() attempt from bpfproggetinfoby_fd() [1]

There was no repro yet on this bug, but I think that commit 0aef499f3172 ("mm/usercopy: Detect vmalloc overruns") is exposing a prior bug in bpf arm64.

bpfproggetinfobyfd() looks at prog->jitedlen to determine if the JIT image can be copied out to user space.

My theory is that syzbot managed to get a prog where prog->jitedlen has been set to 43, while prog->bpffunc has ben cleared.

It is not clear why copytouser(uinsns, NULL, ulen) is triggering this particular warning.

I thought findvmaarea(NULL) would not find a vmstruct. As we do not hold vmaparealock spinlock, it might be possible that the found vmstruct was garbage.

[1] usercopy: Kernel memory exposure attempt detected from vmalloc (offset 792633534417210172, size 43)! kernel BUG at mm/usercopy.c:101! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 25002 Comm: syz-executor.1 Not tainted 5.18.0-syzkaller-10139-g8291eaafed36 #0 Hardware name: linux,dummy-virt (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usercopyabort+0x90/0x94 mm/usercopy.c:101 lr : usercopyabort+0x90/0x94 mm/usercopy.c:89 sp : ffff80000b773a20 x29: ffff80000b773a30 x28: faff80000b745000 x27: ffff80000b773b48 x26: 0000000000000000 x25: 000000000000002b x24: 0000000000000000 x23: 00000000000000e0 x22: ffff80000b75db67 x21: 0000000000000001 x20: 000000000000002b x19: ffff80000b75db3c x18: 00000000fffffffd x17: 2820636f6c6c616d x16: 76206d6f72662064 x15: 6574636574656420 x14: 74706d6574746120 x13: 2129333420657a69 x12: 73202c3237313031 x11: 3237313434333533 x10: 3336323937207465 x9 : 657275736f707865 x8 : ffff80000a30c550 x7 : ffff80000b773830 x6 : ffff80000b773830 x5 : 0000000000000000 x4 : ffff00007fbbaa10 x3 : 0000000000000000 x2 : 0000000000000000 x1 : f7ff000028fc0000 x0 : 0000000000000064 Call trace: usercopyabort+0x90/0x94 mm/usercopy.c:89 checkheapobject mm/usercopy.c:186 [inline] _checkobjectsize mm/usercopy.c:252 [inline] _checkobjectsize+0x198/0x36c mm/usercopy.c:214 checkobjectsize include/linux/threadinfo.h:199 [inline] checkcopysize include/linux/threadinfo.h:235 [inline] copytouser include/linux/uaccess.h:159 [inline] bpfproggetinfobyfd.isra.0+0xf14/0xfdc kernel/bpf/syscall.c:3993 bpfobjgetinfobyfd+0x12c/0x510 kernel/bpf/syscall.c:4253 _sysbpf+0x900/0x2150 kernel/bpf/syscall.c:4956 _dosysbpf kernel/bpf/syscall.c:5021 [inline] _sesysbpf kernel/bpf/syscall.c:5019 [inline] _arm64sysbpf+0x28/0x40 kernel/bpf/syscall.c:5019 _invokesyscall arch/arm64/kernel/syscall.c:38 [inline] invokesyscall+0x48/0x114 arch/arm64/kernel/syscall.c:52 el0svccommon.constprop.0+0x44/0xec arch/arm64/kernel/syscall.c:142 doel0svc+0xa0/0xc0 arch/arm64/kernel/syscall.c:206 el0svc+0x44/0xb0 arch/arm64/kernel/entry-common.c:624 el0t64synchandler+0x1ac/0x1b0 arch/arm64/kernel/entry-common.c:642 el0t64_sync+0x198/0x19c arch/arm64/kernel/entry.S:581 Code: aa0003e3 d00038c0 91248000 97fff65f (d4210000)(CVE-2022-49341)

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

net: altera: Fix refcount leak in alteratsemdio_create

Every iteration of foreachchildofnode() decrements the reference count of the previous node. When break from a foreachchildofnode() loop, we need to explicitly call ofnodeput() on the child node when not need anymore. Add missing ofnodeput() to avoid refcount leak.(CVE-2022-49351)

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

RDMA/hfi1: Fix potential integer multiplication overflow errors

When multiplying of different types, an overflow is possible even when storing the result in a larger type. This is because the conversion is done after the multiplication. So arithmetic overflow and thus in incorrect value is possible.

Correct an instance of this in the inter packet delay calculation. Fix by ensuring one of the operands is u64 which will promote the other to u64 as well ensuring no overflow.(CVE-2022-49404)

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

RDMA/hfi1: Prevent use of lock before it is initialized

If there is a failure during probe of hfi1 before the sdmamaplock is initialized, the call to hfi1freedevdata() will attempt to use a lock that has not been initialized. If the locking correctness validator is on then an INFO message and stack trace resembling the following may be seen:

INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. Call Trace: registerlockclass+0x11b/0x880 _lockacquire+0xf3/0x7930 lockacquire+0xff/0x2d0 _rawspinlockirq+0x46/0x60 sdmaclean+0x42a/0x660 [hfi1] hfi1freedevdata+0x3a7/0x420 [hfi1] initone+0x867/0x11a0 [hfi1] pcideviceprobe+0x40e/0x8d0

The use of sdmamaplock in sdmaclean() is for freeing the sdmamap memory, and sdmamap is not allocated/initialized until after sdmamaplock has been initialized. This code only needs to be run if sdmamap is not NULL, and so checking for that condition will avoid trying to use the lock before it is initialized.(CVE-2022-49433)

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

powerpc/fslrio: Fix refcount leak in fslrio_setup

ofparsephandle() returns a node pointer with refcount incremented, we should use ofnodeput() on it when not need anymore. Add missing ofnodeput() to avoid refcount leak.(CVE-2022-49439)

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

ARM: hisi: Add missing ofnodeput after offindcompatible_node

offindcompatiblenode will increment the refcount of the returned devicenode. Calling ofnodeput() to avoid the refcount leak(CVE-2022-49447)

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

md/bitmap: don't set sb values if can't pass sanity check

If bitmap area contains invalid data, kernel will crash then mdadm triggers "Segmentation fault". This is cluster-md speical bug. In non-clustered env, mdadm will handle broken metadata case. In clustered array, only kernel space handles bitmap slot info. But even this bug only happened in clustered env, current sanity check is wrong, the code should be changed.

How to trigger: (faulty injection)

dd if=/dev/zero bs=1M count=1 oflag=direct of=/dev/sda dd if=/dev/zero bs=1M count=1 oflag=direct of=/dev/sdb mdadm -C /dev/md0 -b clustered -e 1.2 -n 2 -l mirror /dev/sda /dev/sdb mdadm -Ss echo aaa > magic.txt == below modifying slot 2 bitmap data == dd if=magic.txt of=/dev/sda seek=16384 bs=1 count=3 <== destroy magic dd if=/dev/zero of=/dev/sda seek=16436 bs=1 count=4 <== ZERO chunksize mdadm -A /dev/md0 /dev/sda /dev/sdb == kernel crashes. mdadm outputs "Segmentation fault" ==

Reason of kernel crash:

In mdbitmapreadsb (called by mdbitmapcreate), bad bitmap magic didn't block chunksize assignment, and zero value made DIVROUNDUPSECTOR_T() trigger "divide error".

Crash log:

kernel: md: md0 stopped. kernel: md/raid1:md0: not clean -- starting background reconstruction kernel: md/raid1:md0: active with 2 out of 2 mirrors kernel: dlm: ... ... kernel: md-cluster: Joined cluster 44810aba-38bb-e6b8-daca-bc97a0b254aa slot 1 kernel: md0: invalid bitmap file superblock: bad magic kernel: mdbitmapcopyfromslot can't get bitmap from slot 2 kernel: md-cluster: Could not gather bitmaps from slot 2 kernel: divide error: 0000 [#1] SMP NOPTI kernel: CPU: 0 PID: 1603 Comm: mdadm Not tainted 5.14.6-1-default kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) kernel: RIP: 0010:mdbitmapcreate+0x1d1/0x850 [mdmod] kernel: RSP: 0018:ffffc22ac0843ba0 EFLAGS: 00010246 kernel: ... ... kernel: Call Trace: kernel: ? dlmlocksync+0xd0/0xd0 [mdcluster 77fe..7a0] kernel: mdbitmapcopyfromslot+0x2c/0x290 [mdmod 24ea..d3a] kernel: loadbitmaps+0xec/0x210 [mdcluster 77fe..7a0] kernel: mdbitmapload+0x81/0x1e0 [mdmod 24ea..d3a] kernel: domdrun+0x30/0x100 [mdmod 24ea..d3a] kernel: mdioctl+0x1290/0x15a0 [mdmod 24ea....d3a] kernel: ? mddevunlock+0xaa/0x130 [mdmod 24ea..d3a] kernel: ? blkdevioctl+0xb1/0x2b0 kernel: blockioctl+0x3b/0x40 kernel: _x64sysioctl+0x7f/0xb0 kernel: dosyscall64+0x59/0x80 kernel: ? exittousermodeprepare+0x1ab/0x230 kernel: ? syscallexittousermode+0x18/0x40 kernel: ? dosyscall64+0x69/0x80 kernel: entrySYSCALL64afterhwframe+0x44/0xae kernel: RIP: 0033:0x7f4a15fa722b kernel: ... ... kernel: ---[ end trace 8afa7612f559c868 ]--- kernel: RIP: 0010:mdbitmapcreate+0x1d1/0x850 md_mod

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

crypto: qat - add param check for DH

Reject requests with a source buffer that is bigger than the size of the key. This is to prevent a possible integer underflow that might happen when copying the source scatterlist into a linear buffer.(CVE-2022-49564)

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

net: tipc: fix possible refcount leak in tipcskcreate()

Free sk in case tipcskinsert() fails.(CVE-2022-49620)

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

tracing/histograms: Fix memory leak problem

This reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac.

As commit 46bbe5c671e0 ("tracing: fix double free") said, the "double free" problem reported by clang static analyzer is: > In parsevardefs() if there is a problem allocating > vardefs.expr, the earlier vardefs.name is freed. > This free is duplicated by freevardefs() which frees > the rest of the list.

However, if there is a problem allocating N-th vardefs.expr: + in parsevardefs(), the freed 'earlier vardefs.name' is actually the N-th vardefs.name; + then in freevar_defs(), the names from 0th to (N-1)-th are freed;

                    IF ALLOCATING PROBLEM HAPPENED HERE!!! -+
                                                             \
                                                              |
      0th           1th                 (N-1)-th      N-th    V
      +-------------+-------------+-----+-------------+-----------

var_defs: | name | expr | name | expr | ... | name | expr | name | /// +-------------+-------------+-----+-------------+-----------

These two frees don't act on same name, so there was no "double free" problem before. Conversely, after that commit, we get a "memory leak" problem because the above "N-th var_defs.name" is not freed.

If enable CONFIGDEBUGKMEMLEAK and inject a fault at where the N-th vardefs.expr allocated, then execute on shell like: $ echo 'hist:key=callsite:val=$v1,$v2:v1=bytesreq,v2=bytesalloc' > \ /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger

Then kmemleak reports: unreferenced object 0xffff8fb100ef3518 (size 8): comm "bash", pid 196, jiffies 4295681690 (age 28.538s) hex dump (first 8 bytes): 76 31 00 00 b1 8f ff ff v1...... backtrace: [<0000000038fe4895>] kstrdup+0x2d/0x60 [<00000000c99c049a>] eventhisttriggerparse+0x206f/0x20e0 [<00000000ae70d2cc>] triggerprocessregex+0xc0/0x110 [<0000000066737a4c>] eventtriggerwrite+0x75/0xd0 [<000000007341e40c>] vfswrite+0xbb/0x2a0 [<0000000087fde4c2>] ksyswrite+0x59/0xd0 [<00000000581e9cdf>] dosyscall64+0x3a/0x80 [<00000000cf3b065c>] entrySYSCALL64after_hwframe+0x46/0xb0(CVE-2022-49648)

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

can: gsusb: gsusb_open/close(): fix memory leak

The gsusb driver appears to suffer from a malady common to many USB CAN adapter drivers in that it performs usballoccoherent() to allocate a number of USB request blocks (URBs) for RX, and then later relies on usbkillanchoredurbs() to free them, but this doesn't actually free them. As a result, this may be leaking DMA memory that's been used by the driver.

This commit is an adaptation of the techniques found in the esdusb2 driver where a similar design pattern led to a memory leak. It explicitly frees the RX URBs and their DMA memory via a call to usbfreecoherent(). Since the RX URBs were allocated in the gscanopen(), we remove them in gscanclose() rather than in the disconnect function as was done in esdusb2.

For more information, see the 928150fad41b ("can: esd_usb2: fix memory leak").(CVE-2022-49661)

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

iio: trigger: sysfs: fix use-after-free on remove

Ensure that the irq_work has completed before the trigger is freed.

================================================================== BUG: KASAN: use-after-free in irqworkrun_list Read of size 8 at addr 0000000064702248 by task python3/25

Call Trace: irqworkrunlist irqworktick updateprocesstimes tickschedhandle tickschedtimer _hrtimerrunqueues hrtimer_interrupt

Allocated by task 25: kmemcachealloctrace iiosysfstrigadd devattrstore sysfskfwrite kernfsfopwriteiter newsyncwrite vfswrite ksyswrite syswrite

Freed by task 25: kfree iiosysfstrigremove devattrstore sysfskfwrite kernfsfopwriteiter newsyncwrite vfswrite ksyswrite sys_write

==================================================================(CVE-2022-49685)

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

cifs: Fix UAF in cifsdemultiplexthread()

There is a UAF when xfstests on cifs:

BUG: KASAN: use-after-free in smb2isnetworknamedeleted+0x27/0x160 Read of size 4 at addr ffff88810103fc08 by task cifsd/923

CPU: 1 PID: 923 Comm: cifsd Not tainted 6.1.0-rc4+ #45 ... Call Trace: <TASK> dumpstacklvl+0x34/0x44 printreport+0x171/0x472 kasanreport+0xad/0x130 kasancheckrange+0x145/0x1a0 smb2isnetworknamedeleted+0x27/0x160 cifsdemultiplexthread.cold+0x172/0x5a4 kthread+0x165/0x1a0 retfromfork+0x1f/0x30 </TASK>

Allocated by task 923: kasansavestack+0x1e/0x40 kasansettrack+0x21/0x30 _kasanslaballoc+0x54/0x60 kmemcachealloc+0x147/0x320 mempoolalloc+0xe1/0x260 cifssmallbufget+0x24/0x60 allocatebuffers+0xa1/0x1c0 cifsdemultiplexthread+0x199/0x10d0 kthread+0x165/0x1a0 retfromfork+0x1f/0x30

Freed by task 921: kasansavestack+0x1e/0x40 kasansettrack+0x21/0x30 kasansavefreeinfo+0x2a/0x40 __kasanslabfree+0x143/0x1b0 kmemcachefree+0xe3/0x4d0 cifssmallbufrelease+0x29/0x90 SMB2negotiate+0x8b7/0x1c60 smb2negotiate+0x51/0x70 cifsnegotiateprotocol+0xf0/0x160 cifsgetsmbses+0x5fa/0x13c0 mountgetconns+0x7a/0x750 cifsmount+0x103/0xd00 cifssmb3domount+0x1dd/0xcb0 smb3gettree+0x1d5/0x300 vfsgettree+0x41/0xf0 pathmount+0x9b3/0xdd0 _x64sysmount+0x190/0x1d0 dosyscall64+0x35/0x80 entrySYSCALL64after_hwframe+0x46/0xb0

The UAF is because:

mount(pid: 921) | cifsd(pid: 923) -------------------------------|------------------------------- | cifsdemultiplexthread SMB2negotiate | cifssendrecv | compoundsendrecv | smbsendrqst | waitforresponse | waiteventstate [1] | | standardreceive3 | cifshandlestandard | handlemid | mid->respbuf = buf; [2] | dequeuemid [3] KILL the process [4] | respiov[i].iovbase = buf | freerspbuf [5] | | isnetworknamedeleted [6] | callback

1. After send request to server, wait the response until mid->mid_state != SUBMITTED;
2. Receive response from server, and set it to mid;
3. Set the mid state to RECEIVED;
4. Kill the process, the mid state already RECEIVED, get 0;
5. Handle and release the negotiate response;
6. UAF.

It can be easily reproduce with add some delay in [3] - [6].

Only sync call has the problem since async call's callback is executed in cifsd process.

Add an extra state to mark the mid state to READY before wakeup the waitter, then it can get the resp safely.(CVE-2023-52572)

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

smb: client: fix TCP timers deadlock after rmmod

Commit ef7134c7fc48 ("smb: client: Fix use-after-free of network namespace.") fixed a netns UAF by manually enabled socket refcounting (sk->sknetrefcnt=1 and sockinuseadd(net, 1)).

The reason the patch worked for that bug was because we now hold references to the netns (getnettrack() gets a ref internally) and they're properly released (internally, on _skdestruct()), but only because sk->sknetrefcnt was set.

Problem: (this happens regardless of CONFIGNETNSREFCNTTRACKER and regardless if init_net or other)

Setting sk->sknetrefcnt=1 manually and after socket creation is not only out of cifs scope, but also technically wrong -- it's set conditionally based on user (=1) vs kernel (=0) sockets. And net/ implementations seem to base their user vs kernel space operations on it.

e.g. upon TCP socket close, the TCP timers are not cleared because sk->sknetrefcnt=1: (cf. commit 151c9c724d05 ("tcp: properly terminate timers for kernel sockets"))

net/ipv4/tcp.c: void tcpclose(struct sock *sk, long timeout) { locksock(sk); _tcpclose(sk, timeout); releasesock(sk); if (!sk->sknetrefcnt) inetcskclearxmittimerssync(sk); sock_put(sk); }

Which will throw a lockdep warning and then, as expected, deadlock on tcpwritetimer().

A way to reproduce this is by running the reproducer from ef7134c7fc48 and then 'rmmod cifs'. A few seconds later, the deadlock/lockdep warning shows up.

Fix: We shouldn't mess with socket internals ourselves, so do not set sknetrefcnt manually.

Also change _sockcreate() to sockcreatekern() for explicitness.

As for non-init_net network namespaces, we deal with it the best way we can -- hold an extra netns reference for server->ssocket and drop it when it's released. This ensures that the netns still exists whenever we need to create/destroy server->ssocket, but is not directly tied to it.(CVE-2024-54680)

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

hfsplus: don't query the device logical block size multiple times

Devices block sizes may change. One of these cases is a loop device by using ioctl LOOPSETBLOCK_SIZE.

While this may cause other issues like IO being rejected, in the case of hfsplus, it will allocate a block by using that size and potentially write out-of-bounds when hfsplusreadwrapper calls hfsplussubmitbio and the latter function reads a different io_size.

Using a new miniosize initally set to sbminblocksize works for the purposes of the original fix, since it will be set to the max between HFSPLUSSECTORSIZE and the first seen logical block size. We still use the max between HFSPLUSSECTORSIZE and miniosize in case the latter is not initialized.

Tested by mounting an hfsplus filesystem with loop block sizes 512, 1024 and 4096.

The produced KASAN report before the fix looks like this:

[ 419.944641] ================================================================== [ 419.945655] BUG: KASAN: slab-use-after-free in hfsplusreadwrapper+0x659/0xa0a [ 419.946703] Read of size 2 at addr ffff88800721fc00 by task repro/10678 [ 419.947612] [ 419.947846] CPU: 0 UID: 0 PID: 10678 Comm: repro Not tainted 6.12.0-rc5-00008-gdf56e0f2f3ca #84 [ 419.949007] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 419.950035] Call Trace: [ 419.950384] <TASK> [ 419.950676] dumpstacklvl+0x57/0x78 [ 419.951212] ? hfsplusreadwrapper+0x659/0xa0a [ 419.951830] printreport+0x14c/0x49e [ 419.952361] ? _virtaddrvalid+0x267/0x278 [ 419.952979] ? kmemcachedebugflags+0xc/0x1d [ 419.953561] ? hfsplusreadwrapper+0x659/0xa0a [ 419.954231] kasanreport+0x89/0xb0 [ 419.954748] ? hfsplusreadwrapper+0x659/0xa0a [ 419.955367] hfsplusreadwrapper+0x659/0xa0a [ 419.955948] ? _pfxhfsplusreadwrapper+0x10/0x10 [ 419.956618] ? dorawspinunlock+0x59/0x1a9 [ 419.957214] ? _rawspinunlock+0x1a/0x2e [ 419.957772] hfsplusfillsuper+0x348/0x1590 [ 419.958355] ? hlockclass+0x4c/0x109 [ 419.958867] ? _pfxhfsplusfillsuper+0x10/0x10 [ 419.959499] ? _pfxstring+0x10/0x10 [ 419.960006] ? lockacquire+0x3e2/0x454 [ 419.960532] ? bdevname.constprop.0+0xce/0x243 [ 419.961129] ? _pfxbdevname.constprop.0+0x10/0x10 [ 419.961799] ? pointer+0x3f0/0x62f [ 419.962277] ? _pfxpointer+0x10/0x10 [ 419.962761] ? vsnprintf+0x6c4/0xfba [ 419.963178] ? _pfxvsnprintf+0x10/0x10 [ 419.963621] ? setupbdevsuper+0x376/0x3b3 [ 419.964029] ? snprintf+0x9d/0xd2 [ 419.964344] ? _pfxsnprintf+0x10/0x10 [ 419.964675] ? lockacquired+0x45c/0x5e9 [ 419.965016] ? setblocksize+0x139/0x1c1 [ 419.965381] ? sbsetblocksize+0x6d/0xae [ 419.965742] ? _pfxhfsplusfillsuper+0x10/0x10 [ 419.966179] mountbdev+0x12f/0x1bf [ 419.966512] ? _pfxmountbdev+0x10/0x10 [ 419.966886] ? vfsparsefsstring+0xce/0x111 [ 419.967293] ? _pfxvfsparsefsstring+0x10/0x10 [ 419.967702] ? _pfxhfsplusmount+0x10/0x10 [ 419.968073] legacygettree+0x104/0x178 [ 419.968414] vfsgettree+0x86/0x296 [ 419.968751] pathmount+0xba3/0xd0b [ 419.969157] ? _pfxpathmount+0x10/0x10 [ 419.969594] ? kmemcachefree+0x1e2/0x260 [ 419.970311] domount+0x99/0xe0 [ 419.970630] ? _pfxdomount+0x10/0x10 [ 419.971008] _dosysmount+0x199/0x1c9 [ 419.971397] dosyscall64+0xd0/0x135 [ 419.971761] entrySYSCALL64afterhwframe+0x76/0x7e [ 419.972233] RIP: 0033:0x7c3cb812972e [ 419.972564] Code: 48 8b 0d f5 46 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c2 46 0d 00 f7 d8 64 89 01 48 [ 419.974371] RSP: 002b:00007ffe30632548 EFLAGS: 00000286 ORIGRAX: 00000000000000a5 [ 419.975048] RAX: ffffffffffffffda RBX: 00007ffe306328d8 RCX: 00007c3cb812972e [ 419.975701] RDX: 0000000020000000 RSI: 0000000020000c80 RDI: ---truncated---(CVE-2024-56548)

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

afpacket: avoid erroring out after sockinitdata() in packetcreate()

After sockinitdata() the allocated sk object is attached to the provided sock object. On error, packet_create() frees the sk object leaving the dangling pointer in the sock object on return. Some other code may try to use this pointer and cause use-after-free.(CVE-2024-56606)

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

net: sched: Disallow replacing of child qdisc from one parent to another

Lion Ackermann was able to create a UAF which can be abused for privilege escalation with the following script

Step 1. create root qdisc tc qdisc add dev lo root handle 1:0 drr

step2. a class for packet aggregation do demonstrate uaf tc class add dev lo classid 1:1 drr

step3. a class for nesting tc class add dev lo classid 1:2 drr

step4. a class to graft qdisc to tc class add dev lo classid 1:3 drr

step5. tc qdisc add dev lo parent 1:1 handle 2:0 plug limit 1024

step6. tc qdisc add dev lo parent 1:2 handle 3:0 drr

step7. tc class add dev lo classid 3:1 drr

step 8. tc qdisc add dev lo parent 3:1 handle 4:0 pfifo

step 9. Display the class/qdisc layout

tc class ls dev lo class drr 1:1 root leaf 2: quantum 64Kb class drr 1:2 root leaf 3: quantum 64Kb class drr 3:1 root leaf 4: quantum 64Kb

tc qdisc ls qdisc drr 1: dev lo root refcnt 2 qdisc plug 2: dev lo parent 1:1 qdisc pfifo 4: dev lo parent 3:1 limit 1000p qdisc drr 3: dev lo parent 1:2

step10. trigger the bug <=== prevented by this patch tc qdisc replace dev lo parent 1:3 handle 4:0

step 11. Redisplay again the qdiscs/classes

tc class ls dev lo class drr 1:1 root leaf 2: quantum 64Kb class drr 1:2 root leaf 3: quantum 64Kb class drr 1:3 root leaf 4: quantum 64Kb class drr 3:1 root leaf 4: quantum 64Kb

tc qdisc ls qdisc drr 1: dev lo root refcnt 2 qdisc plug 2: dev lo parent 1:1 qdisc pfifo 4: dev lo parent 3:1 refcnt 2 limit 1000p qdisc drr 3: dev lo parent 1:2

Observe that a) parent for 4:0 does not change despite the replace request. There can only be one parent. b) refcount has gone up by two for 4:0 and c) both class 1:3 and 3:1 are pointing to it.

Step 12. send one packet to plug echo "" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10001)) step13. send one packet to the grafted fifo echo "" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10003))

step14. lets trigger the uaf tc class delete dev lo classid 1:3 tc class delete dev lo classid 1:1

The semantics of "replace" is for a del/add on the same node and not a delete from one node(3:1) and add to another node (1:3) as in step10. While we could "fix" with a more complex approach there could be consequences to expectations so the patch takes the preventive approach of "disallow such config".

Joint work with Lion Ackermann <nnamrec@gmail.com>(CVE-2025-21700)

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

pfifotailenqueue: Drop new packet when sch->limit == 0

Expected behaviour: In case we reach scheduler's limit, pfifotailenqueue() will drop a packet in scheduler's queue and decrease scheduler's qlen by one. Then, pfifotailenqueue() enqueue new packet and increase scheduler's qlen by one. Finally, pfifotailenqueue() return NET_XMIT_CN status code.

Weird behaviour: In case we set sch->limit == 0 and trigger pfifotailenqueue() on a scheduler that has no packet, the 'drop a packet' step will do nothing. This means the scheduler's qlen still has value equal 0. Then, we continue to enqueue new packet and increase scheduler's qlen by one. In summary, we can leverage pfifotailenqueue() to increase qlen by one and return NET_XMIT_CN status code.

The problem is: Let's say we have two qdiscs: QdiscA and QdiscB. - QdiscA's type must have '->graft()' function to create parent/child relationship. Let's say QdiscA's type is hfsc. Enqueue packet to this qdisc will trigger hfsc_enqueue. - QdiscB's type is pfifoheaddrop. Enqueue packet to this qdisc will trigger pfifo_tail_enqueue. - QdiscB is configured to have sch->limit == 0. - QdiscA is configured to route the enqueued's packet to QdiscB.

Enqueue packet through QdiscA will lead to: - hfscenqueue(QdiscA) -> pfifotailenqueue(QdiscB) - QdiscB->q.qlen += 1 - pfifotailenqueue() return NET_XMIT_CN - hfscenqueue() check for NET_XMIT_SUCCESS and see NET_XMIT_CN => hfscenqueue() don't increase qlen of QdiscA.

The whole process lead to a situation where QdiscA->q.qlen == 0 and QdiscB->q.qlen == 1. Replace 'hfsc' with other type (for example: 'drr') still lead to the same problem. This violate the design where parent's qlen should equal to the sum of its childrens'qlen.

Bug impact: This issue can be used for user->kernel privilege escalation when it is reachable.(CVE-2025-21702)