OESA-2025-1158

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

ila: call nfunregisternet_hooks() sooner

syzbot found an use-after-free Read in ilanfinput [1]

Issue here is that ilaxlatexitnet() frees the rhashtable, then call nfunregisternethooks().

It should be done in the reverse way, with a synchronize_rcu().

This is a good match for a pre_exit() method.

[1] BUG: KASAN: use-after-free in rhtkeyhashfn include/linux/rhashtable.h:159 [inline] BUG: KASAN: use-after-free in _rhashtablelookup include/linux/rhashtable.h:604 [inline] BUG: KASAN: use-after-free in rhashtablelookup include/linux/rhashtable.h:646 [inline] BUG: KASAN: use-after-free in rhashtablelookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672 Read of size 4 at addr ffff888064620008 by task ksoftirqd/0/16

CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.11.0-rc4-syzkaller-00238-g2ad6d23f465a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: <TASK> _dumpstack lib/dumpstack.c:93 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:119 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0x169/0x550 mm/kasan/report.c:488 kasanreport+0x143/0x180 mm/kasan/report.c:601 rhtkeyhashfn include/linux/rhashtable.h:159 [inline] _rhashtablelookup include/linux/rhashtable.h:604 [inline] rhashtablelookup include/linux/rhashtable.h:646 [inline] rhashtablelookupfast+0x77a/0x9b0 include/linux/rhashtable.h:672 ilalookupwildcards net/ipv6/ila/ilaxlat.c:132 [inline] ilaxlataddr net/ipv6/ila/ilaxlat.c:652 [inline] ilanfinput+0x1fe/0x3c0 net/ipv6/ila/ilaxlat.c:190 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xc3/0x220 net/netfilter/core.c:626 nfhook include/linux/netfilter.h:269 [inline] NFHOOK+0x29e/0x450 include/linux/netfilter.h:312 _netifreceiveskbonecore net/core/dev.c:5661 [inline] _netifreceiveskb+0x1ea/0x650 net/core/dev.c:5775 processbacklog+0x662/0x15b0 net/core/dev.c:6108 _napipoll+0xcb/0x490 net/core/dev.c:6772 napipoll net/core/dev.c:6841 [inline] netrxaction+0x89b/0x1240 net/core/dev.c:6963 handlesoftirqs+0x2c4/0x970 kernel/softirq.c:554 runksoftirqd+0xca/0x130 kernel/softirq.c:928 smpbootthreadfn+0x544/0xa30 kernel/smpboot.c:164 kthread+0x2f0/0x390 kernel/kthread.c:389 retfromfork+0x4b/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK>

The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x64620 flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff) pagetype: 0xbfffffff(buddy) raw: 00fff00000000000 ffffea0000959608 ffffea00019d9408 0000000000000000 raw: 0000000000000000 0000000000000003 00000000bfffffff 0000000000000000 page dumped because: kasan: bad access detected pageowner tracks the page as freed page last allocated via order 3, migratetype Unmovable, gfpmask 0x52dc0(GFPKERNEL|GFPNOWARN|GFPNORETRY|GFPCOMP|GFPZERO), pid 5242, tgid 5242 (syz-executor), ts 73611328570, freets 618981657187 setpageowner include/linux/pageowner.h:32 [inline] postallochook+0x1f3/0x230 mm/pagealloc.c:1493 prepnewpage mm/pagealloc.c:1501 [inline] getpagefromfreelist+0x2e4c/0x2f10 mm/pagealloc.c:3439 allocpagesnoprof+0x256/0x6c0 mm/pagealloc.c:4695 _allocpagesnodenoprof include/linux/gfp.h:269 [inline] allocpagesnodenoprof include/linux/gfp.h:296 [inline] kmalloclargenode+0x8b/0x1d0 mm/slub.c:4103 _kmalloclargenodenoprof+0x1a/0x80 mm/slub.c:4130 _dokmallocnode mm/slub.c:4146 [inline] _kmallocnodenoprof+0x2d2/0x440 mm/slub.c:4164 _kvmallocnodenoprof+0x72/0x190 mm/util.c:650 buckettablealloc lib/rhashtable.c:186 [inline] rhashtableinitnoprof+0x534/0xa60 lib/rhashtable.c:1071 ilaxlatinitnet+0xa0/0x110 net/ipv6/ila/ilaxlat.c:613 ops_ini ---truncated---(CVE-2024-46782)

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

drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error

Ensure index in rtl2830pidfilter does not exceed 31 to prevent out-of-bounds access.

dev->filters is a 32-bit value, so setbit and clearbit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue.(CVE-2024-47697)

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

nvme-rdma: unquiesce admin_q before destroy it

Kernel will hang on destroy admin_q while we create ctrl failed, such as following calltrace:

PID: 23644 TASK: ff2d52b40f439fc0 CPU: 2 COMMAND: "nvme" #0 [ff61d23de260fb78] _schedule at ffffffff8323bc15 #1 [ff61d23de260fc08] schedule at ffffffff8323c014 #2 [ff61d23de260fc28] blkmqfreezequeuewait at ffffffff82a3dba1 #3 [ff61d23de260fc78] blkfreezequeue at ffffffff82a4113a #4 [ff61d23de260fc90] blkcleanupqueue at ffffffff82a33006 #5 [ff61d23de260fcb0] nvmerdmadestroyadminqueue at ffffffffc12686ce #6 [ff61d23de260fcc8] nvmerdmasetupctrl at ffffffffc1268ced #7 [ff61d23de260fd28] nvmerdmacreatectrl at ffffffffc126919b #8 [ff61d23de260fd68] nvmfdevwrite at ffffffffc024f362 #9 [ff61d23de260fe38] vfswrite at ffffffff827d5f25 RIP: 00007fda7891d574 RSP: 00007ffe2ef06958 RFLAGS: 00000202 RAX: ffffffffffffffda RBX: 000055e8122a4d90 RCX: 00007fda7891d574 RDX: 000000000000012b RSI: 000055e8122a4d90 RDI: 0000000000000004 RBP: 00007ffe2ef079c0 R8: 000000000000012b R9: 000055e8122a4d90 R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000004 R13: 000055e8122923c0 R14: 000000000000012b R15: 00007fda78a54500 ORIG_RAX: 0000000000000001 CS: 0033 SS: 002b

This due to we have quiesced admiq before cancel requests, but forgot to unquiesce before destroy it, as a result we fail to drain the pending requests, and hang on blkmqfreezequeuewait() forever. Here try to reuse nvmerdmateardownadmin_queue() to fix this issue and simplify the code.(CVE-2024-49569)

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

Bluetooth: SCO: Fix UAF on scosocktimeout

conn->sk maybe have been unlinked/freed while waiting for scoconnlock so this checks if the conn->sk is still valid by checking if it part of scosklist.(CVE-2024-50125)

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

usb: typec: fix potential out of bounds in ucsiccgupdatesetnewcamcmd()

The "*cmd" variable can be controlled by the user via debugfs. That means "newcam" can be as high as 255 while the size of the uc->updated[] array is UCSIMAX_ALTMODES (30).

The call tree is: ucsicmd() // val comes from simpleattrwritexsigned() -> ucsisendcommand() -> ucsisendcommandcommon() -> ucsiruncommand() // calls ucsi->ops->synccontrol() -> ucsiccgsync_control()(CVE-2024-50268)

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

net/sched: stop qdisctreereducebacklog on TCH_ROOT

In qdisctreereduce_backlog, Qdiscs with major handle ffff: are assumed to be either root or ingress. This assumption is bogus since it's valid to create egress qdiscs with major handle ffff: Budimir Markovic found that for qdiscs like DRR that maintain an active class list, it will cause a UAF with a dangling class pointer.

In 066a3b5b2346, the concern was to avoid iterating over the ingress qdisc since its parent is itself. The proper fix is to stop when parent TCHROOT is reached because the only way to retrieve ingress is when a hierarchy which does not contain a ffff: major handle call into qdisclookup with TCHMAJ(TCH_ROOT).

In the scenario where major ffff: is an egress qdisc in any of the tree levels, the updates will also propagate to TCHROOT, which then the iteration must stop.

net/sched/sch_api.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)(CVE-2024-53057)

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

mm: resolve faulty mmap_region() error path behaviour

The mmap_region() function is somewhat terrifying, with spaghetti-like control flow and numerous means by which issues can arise and incomplete state, memory leaks and other unpleasantness can occur.

A large amount of the complexity arises from trying to handle errors late in the process of mapping a VMA, which forms the basis of recently observed issues with resource leaks and observable inconsistent state.

Taking advantage of previous patches in this series we move a number of checks earlier in the code, simplifying things by moving the core of the logic into a static internal function _mmapregion().

Doing this allows us to perform a number of checks up front before we do any real work, and allows us to unwind the writable unmap check unconditionally as required and to perform a CONFIGDEBUGVMMAPLETREE validation unconditionally also.

We move a number of things here:

1. We preallocate memory for the iterator before we call the file-backed memory hook, allowing us to exit early and avoid having to perform complicated and error-prone close/free logic. We carefully free iterator state on both success and error paths.

2. The enclosing mmapregion() function handles the mappingmapwritable() logic early. Previously the logic had the mappingmapwritable() at the point of mapping a newly allocated file-backed VMA, and a matching mappingunmap_writable() on success and error paths.

   We now do this unconditionally if this is a file-backed, shared writable mapping. If a driver changes the flags to eliminate VM_MAYWRITE, however doing so does not invalidate the seal check we just performed, and we in any case always decrement the counter in the wrapper.

   We perform a debug assert to ensure a driver does not attempt to do the opposite.

3. We also move archvalidateflags() up into the mmap_region() function. This is only relevant on arm64 and sparc64, and the check is only meaningful for SPARC with ADI enabled. We explicitly add a warning for this arch if a driver invalidates this check, though the code ought eventually to be fixed to eliminate the need for this.

With all of these measures in place, we no longer need to explicitly close the VMA on error paths, as we place all checks which might fail prior to a call to any driver mmap hook.

This eliminates an entire class of errors, makes the code easier to reason about and more robust.(CVE-2024-53096)

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

netfilter: ipset: add missing range check in bitmapipuadt

When tb[IPSETATTRIPTO] is not present but tb[IPSETATTRCIDR] exists, the values of ip and ipto are slightly swapped. Therefore, the range check for ip should be done later, but this part is missing and it seems that the vulnerability occurs.

So we should add missing range checks and remove unnecessary range checks.(CVE-2024-53141)

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

comedi: Flush partial mappings in error case

If some remappfnrange() calls succeeded before one failed, we still have buffer pages mapped into the userspace page tables when we drop the buffer reference with comedibufmap_put(bm). The userspace mappings are only cleaned up later in the mmap error path.

Fix it by explicitly flushing all mappings in our VMA on the error path.

See commit 79a61cc3fc04 ("mm: avoid leaving partial pfn mappings around in error case").(CVE-2024-53148)

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

wifi: ath9k: add range check for connrspepid in htcconnectservice()

I found the following bug in my fuzzer:

UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath9k/htchst.c:26:51 index 255 is out of range for type 'htcendpoint [22]' CPU: 0 UID: 0 PID: 8 Comm: kworker/0:0 Not tainted 6.11.0-rc6-dirty #14 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: events requestfirmwareworkfunc Call Trace: <TASK> dumpstacklvl+0x180/0x1b0 _ubsanhandleoutofbounds+0xd4/0x130 htcissuesend.constprop.0+0x20c/0x230 ? rawspinunlockirqrestore+0x3c/0x70 ath9kwmicmd+0x41d/0x610 ? markheldlocks+0x9f/0xe0 ...

Since this bug has been confirmed to be caused by insufficient verification of connrspepid, I think it would be appropriate to add a range check for connrspepid to htcconnectservice() to prevent the bug from occurring.(CVE-2024-53156)

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

net: inet6: do not leave a dangling sk pointer in inet6_create()

sockinitdata() attaches the allocated sk pointer to the provided sock object. If inet6_create() fails later, the sk object is released, but the sock object retains the dangling sk pointer, which may cause use-after-free later.

Clear the sock sk pointer on error.(CVE-2024-56600)

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

net: inet: do not leave a dangling sk pointer in inet_create()

sockinitdata() attaches the allocated sk object to the provided sock object. If inet_create() fails later, the sk object is freed, but the sock object retains the dangling pointer, which may create use-after-free later.

Clear the sk pointer in the sock object on error.(CVE-2024-56601)

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

gpio: grgpio: Add NULL check in grgpio_probe

devmkasprintf() can return a NULL pointer on failure,but this returned value in grgpioprobe is not checked. Add NULL check in grgpio_probe, to handle kernel NULL pointer dereference error.(CVE-2024-56634)

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

s390/cpum_sf: Handle CPU hotplug remove during sampling

CPU hotplug remove handling triggers the following function call sequence:

CPUHPAPPERFS390SFONLINE --> s390pmusfofflinecpu() ... CPUHPAPPERFONLINE --> perfeventexit_cpu()

The s390 CPUMF sampling CPU hotplug handler invokes:

s390pmusfofflinecpu() +--> cpusfpmusetup() +--> setuppmccpu() +--> deallocate_buffers()

This function de-allocates all sampling data buffers (SDBs) allocated for that CPU at event initialization. It also clears the PMUFRESERVED bit. The CPU is gone and can not be sampled.

With the event still being active on the removed CPU, the CPU event hotplug support in kernel performance subsystem triggers the following function calls on the removed CPU:

perfeventexitcpu() +--> perfeventexitcpucontext() +--> _perfeventexitcontext() +--> _perfremovefromcontext() +--> eventschedout() +--> cpumsfpmudel() +--> cpumsfpmustop() +--> hwperfeventupdate()

to stop and remove the event. During removal of the event, the sampling device driver tries to read out the remaining samples from the sample data buffers (SDBs). But they have already been freed (and may have been re-assigned). This may lead to a use after free situation in which case the samples are most likely invalid. In the best case the memory has not been reassigned and still contains valid data.

Remedy this situation and check if the CPU is still in reserved state (bit PMUFRESERVED set). In this case the SDBs have not been released an contain valid data. This is always the case when the event is removed (and no CPU hotplug off occured). If the PMUFRESERVED bit is not set, the SDB buffers are gone.(CVE-2024-57849)

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

ila: serialize calls to nfregisternet_hooks()

syzbot found a race in ilaaddmapping() [1]

commit 031ae72825ce ("ila: call nfunregisternet_hooks() sooner") attempted to fix a similar issue.

Looking at the syzbot repro, we have concurrent ILACMDADD commands.

Add a mutex to make sure at most one thread is calling nfregisternet_hooks().

[1] BUG: KASAN: slab-use-after-free in rhtkeyhashfn include/linux/rhashtable.h:159 [inline] BUG: KASAN: slab-use-after-free in _rhashtablelookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604 Read of size 4 at addr ffff888028f40008 by task dhcpcd/5501

CPU: 1 UID: 0 PID: 5501 Comm: dhcpcd Not tainted 6.13.0-rc4-syzkaller-00054-gd6ef8b40d075 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <IRQ> _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x116/0x1f0 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xc3/0x620 mm/kasan/report.c:489 kasanreport+0xd9/0x110 mm/kasan/report.c:602 rhtkeyhashfn include/linux/rhashtable.h:159 [inline] _rhashtablelookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604 rhashtablelookup include/linux/rhashtable.h:646 [inline] rhashtablelookupfast include/linux/rhashtable.h:672 [inline] ilalookupwildcards net/ipv6/ila/ilaxlat.c:127 [inline] ilaxlataddr net/ipv6/ila/ilaxlat.c:652 [inline] ilanfinput+0x1ee/0x620 net/ipv6/ila/ilaxlat.c:185 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xbb/0x200 net/netfilter/core.c:626 nfhook.constprop.0+0x42e/0x750 include/linux/netfilter.h:269 NFHOOK include/linux/netfilter.h:312 [inline] ipv6rcv+0xa4/0x680 net/ipv6/ip6input.c:309 _netifreceiveskbonecore+0x12e/0x1e0 net/core/dev.c:5672 _netifreceiveskb+0x1d/0x160 net/core/dev.c:5785 processbacklog+0x443/0x15f0 net/core/dev.c:6117 _napipoll.constprop.0+0xb7/0x550 net/core/dev.c:6883 napipoll net/core/dev.c:6952 [inline] netrxaction+0xa94/0x1010 net/core/dev.c:7074 handlesoftirqs+0x213/0x8f0 kernel/softirq.c:561 _dosoftirq kernel/softirq.c:595 [inline] invokesoftirq kernel/softirq.c:435 [inline] _irqexitrcu+0x109/0x170 kernel/softirq.c:662 irqexitrcu+0x9/0x30 kernel/softirq.c:678 instrsysvecapictimerinterrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvecapictimer_interrupt+0xa4/0xc0 arch/x86/kernel/apic/apic.c:1049(CVE-2024-57900)

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

sched: sch_cake: add bounds checks to host bulk flow fairness counts

Even though we fixed a logic error in the commit cited below, syzbot still managed to trigger an underflow of the per-host bulk flow counters, leading to an out of bounds memory access.

To avoid any such logic errors causing out of bounds memory accesses, this commit factors out all accesses to the per-host bulk flow counters to a series of helpers that perform bounds-checking before any increments and decrements. This also has the benefit of improving readability by moving the conditional checks for the flow mode into these helpers, instead of having them spread out throughout the code (which was the cause of the original logic error).

As part of this change, the flow quantum calculation is consolidated into a helper function, which means that the dithering applied to the ost load scaling is now applied both in the DRR rotation and when a sparse flow's quantum is first initiated. The only user-visible effect of this is that the maximum packet size that can be sent while a flow stays sparse will now vary with +/- one byte in some cases. This should not make a noticeable difference in practice, and thus it's not worth complicating the code to preserve the old behaviour.(CVE-2025-21647)

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

netfilter: conntrack: clamp maximum hashtable size to INT_MAX

Use INTMAX as maximum size for the conntrack hashtable. Otherwise, it is possible to hit WARNONONCE in _kvmallocnodenoprof() when resizing hashtable because _GFPNOWARN is unset. See:

0708a0afe291 ("mm: Consider _GFPNOWARN flag for oversized kvmalloc() calls")

Note: hashtable resize is only possible from init_netns.(CVE-2025-21648)

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

iomap: avoid avoid truncating 64-bit offset to 32 bits

on 32-bit kernels, iomapwritedelallocscan() was inadvertently using a 32-bit position due to folionext_index() returning an unsigned long. This could lead to an infinite loop when writing to an xfs filesystem.(CVE-2025-21667)