OESA-2025-1203

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

usb: typec: altmode should keep reference to parent

The altmode device release refers to its parent device, but without keeping a reference to it.

When registering the altmode, get a reference to the parent and put it in the release function.

Before this fix, when using CONFIGDEBUGKOBJECT_RELEASE, we see issues like this:

[ 43.572860] kobject: 'port0.0' (ffff8880057ba008): kobjectrelease, parent 0000000000000000 (delayed 3000) [ 43.573532] kobject: 'port0.1' (ffff8880057bd008): kobjectrelease, parent 0000000000000000 (delayed 1000) [ 43.574407] kobject: 'port0' (ffff8880057b9008): kobjectrelease, parent 0000000000000000 (delayed 3000) [ 43.575059] kobject: 'port1.0' (ffff8880057ca008): kobjectrelease, parent 0000000000000000 (delayed 4000) [ 43.575908] kobject: 'port1.1' (ffff8880057c9008): kobjectrelease, parent 0000000000000000 (delayed 4000) [ 43.576908] kobject: 'typec' (ffff8880062dbc00): kobjectrelease, parent 0000000000000000 (delayed 4000) [ 43.577769] kobject: 'port1' (ffff8880057bf008): kobjectrelease, parent 0000000000000000 (delayed 3000) [ 46.612867] ================================================================== [ 46.613402] BUG: KASAN: slab-use-after-free in typecaltmoderelease+0x38/0x129 [ 46.614003] Read of size 8 at addr ffff8880057b9118 by task kworker/2:1/48 [ 46.614538] [ 46.614668] CPU: 2 UID: 0 PID: 48 Comm: kworker/2:1 Not tainted 6.12.0-rc1-00138-gedbae730ad31 #535 [ 46.615391] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 46.616042] Workqueue: events kobjectdelayedcleanup [ 46.616446] Call Trace: [ 46.616648] <TASK> [ 46.616820] dumpstacklvl+0x5b/0x7c [ 46.617112] ? typecaltmoderelease+0x38/0x129 [ 46.617470] printreport+0x14c/0x49e [ 46.617769] ? rcureadunlocksched+0x56/0x69 [ 46.618117] ? _virtaddrvalid+0x19a/0x1ab [ 46.618456] ? kmemcachedebugflags+0xc/0x1d [ 46.618807] ? typecaltmoderelease+0x38/0x129 [ 46.619161] kasanreport+0x8d/0xb4 [ 46.619447] ? typecaltmoderelease+0x38/0x129 [ 46.619809] ? processscheduledworks+0x3cb/0x85f [ 46.620185] typecaltmoderelease+0x38/0x129 [ 46.620537] ? processscheduledworks+0x3cb/0x85f [ 46.620907] devicerelease+0xaf/0xf2 [ 46.621206] kobjectdelayedcleanup+0x13b/0x17a [ 46.621584] processscheduledworks+0x4f6/0x85f [ 46.621955] ? _pfxprocessscheduledworks+0x10/0x10 [ 46.622353] ? hlockclass+0x31/0x9a [ 46.622647] ? lockacquired+0x361/0x3c3 [ 46.622956] ? movelinkedworks+0x46/0x7d [ 46.623277] workerthread+0x1ce/0x291 [ 46.623582] ? _kthreadparkme+0xc8/0xdf [ 46.623900] ? _pfxworkerthread+0x10/0x10 [ 46.624236] kthread+0x17e/0x190 [ 46.624501] ? kthread+0xfb/0x190 [ 46.624756] ? _pfxkthread+0x10/0x10 [ 46.625015] retfromfork+0x20/0x40 [ 46.625268] ? _pfxkthread+0x10/0x10 [ 46.625532] retfromforkasm+0x1a/0x30 [ 46.625805] </TASK> [ 46.625953] [ 46.626056] Allocated by task 678: [ 46.626287] kasansavestack+0x24/0x44 [ 46.626555] kasansavetrack+0x14/0x2d [ 46.626811] _kasankmalloc+0x3f/0x4d [ 46.627049] _kmallocnoprof+0x1bf/0x1f0 [ 46.627362] typecregisterport+0x23/0x491 [ 46.627698] crostypecprobe+0x634/0xbb6 [ 46.628026] platformprobe+0x47/0x8c [ 46.628311] reallyprobe+0x20a/0x47d [ 46.628605] devicedriverattach+0x39/0x72 [ 46.628940] bindstore+0x87/0xd7 [ 46.629213] kernfsfopwriteiter+0x1aa/0x218 [ 46.629574] vfswrite+0x1d6/0x29b [ 46.629856] ksyswrite+0xcd/0x13b [ 46.630128] dosyscall64+0xd4/0x139 [ 46.630420] entrySYSCALL64afterhwframe+0x76/0x7e [ 46.630820] [ 46.630946] Freed by task 48: [ 46.631182] kasansavestack+0x24/0x44 [ 46.631493] kasansavetrack+0x14/0x2d [ 46.631799] kasansavefreeinfo+0x3f/0x4d [ 46.632144] _kasanslabfree+0x37/0x45 [ 46.632474] ---truncated---(CVE-2024-50150)

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

netfilter: xtables: fix LED ID check in ledtg_check()

Syzbot has reported the following BUG detected by KASAN:

BUG: KASAN: slab-out-of-bounds in strlen+0x58/0x70 Read of size 1 at addr ffff8881022da0c8 by task repro/5879 ... Call Trace: <TASK> dumpstacklvl+0x241/0x360 ? pfxdumpstacklvl+0x10/0x10 ? _pfxprintk+0x10/0x10 ? printk+0xd5/0x120 ? virtaddrvalid+0x183/0x530 ? _virtaddrvalid+0x183/0x530 printreport+0x169/0x550 ? _virtaddrvalid+0x183/0x530 ? _virtaddrvalid+0x183/0x530 ? _virtaddrvalid+0x45f/0x530 ? _physaddr+0xba/0x170 ? strlen+0x58/0x70 kasanreport+0x143/0x180 ? strlen+0x58/0x70 strlen+0x58/0x70 kstrdup+0x20/0x80 ledtgcheck+0x18b/0x3c0 xtchecktarget+0x3bb/0xa40 ? _pfxxtchecktarget+0x10/0x10 ? stackdepotsaveflags+0x6e4/0x830 ? nfttargetinit+0x174/0xc30 nfttargetinit+0x82d/0xc30 ? _pfxnfttargetinit+0x10/0x10 ? nftablesnewrule+0x1609/0x2980 ? nftablesnewrule+0x1609/0x2980 ? rcuiswatching+0x15/0xb0 ? nftablesnewrule+0x1609/0x2980 ? nftablesnewrule+0x1609/0x2980 ? _kmallocnoprof+0x21a/0x400 nftablesnewrule+0x1860/0x2980 ? _pfxnftablesnewrule+0x10/0x10 ? _nlaparse+0x40/0x60 nfnetlinkrcv+0x14e5/0x2ab0 ? _pfxvalidatechain+0x10/0x10 ? _pfxnfnetlinkrcv+0x10/0x10 ? _lockacquire+0x1384/0x2050 ? netlinkdelivertap+0x2e/0x1b0 ? _pfxlockrelease+0x10/0x10 ? netlinkdelivertap+0x2e/0x1b0 netlinkunicast+0x7f8/0x990 ? _pfxnetlinkunicast+0x10/0x10 ? _virtaddrvalid+0x183/0x530 ? _checkobjectsize+0x48e/0x900 netlinksendmsg+0x8e4/0xcb0 ? _pfxnetlinksendmsg+0x10/0x10 ? aasockmsgperm+0x91/0x160 ? _pfxnetlinksendmsg+0x10/0x10 _socksendmsg+0x223/0x270 syssendmsg+0x52a/0x7e0 ? pfxsyssendmsg+0x10/0x10 _syssendmsg+0x292/0x380 ? _pfxsyssendmsg+0x10/0x10 ? lockdephardirqsonprepare+0x43d/0x780 ? _pfxlockdephardirqsonprepare+0x10/0x10 ? excpagefault+0x590/0x8c0 ? dosyscall64+0xb6/0x230 dosyscall64+0xf3/0x230 entrySYSCALL64afterhwframe+0x77/0x7f ... </TASK>

Since an invalid (without '\0' byte at all) byte sequence may be passed from userspace, add an extra check to ensure that such a sequence is rejected as possible ID and so never passed to 'kstrdup()' and further.(CVE-2024-56650)

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

net: defer final 'struct net' free in netns dismantle

Ilya reported a slab-use-after-free in dst_destroy [1]

Issue is in xfrm6netinit() and xfrm4netinit() :

They copy xfrm[46]dstopstemplate into net->xfrm.xfrm[46]dst_ops.

But net structure might be freed before all the dst callbacks are called. So when dst_destroy() calls later :

if (dst->ops->destroy) dst->ops->destroy(dst);

dst->ops points to the old net->xfrm.xfrm[46]dstops, which has been freed.

See a relevant issue fixed in :

ac888d58869b ("net: do not delay dstentriesadd() in dst_release()")

A fix is to queue the 'struct net' to be freed after one another cleanupnet() round (and existing rcubarrier())

[1]

BUG: KASAN: slab-use-after-free in dstdestroy (net/core/dst.c:112) Read of size 8 at addr ffff8882137ccab0 by task swapper/37/0 Dec 03 05:46:18 kernel: CPU: 37 UID: 0 PID: 0 Comm: swapper/37 Kdump: loaded Not tainted 6.12.0 #67 Hardware name: Red Hat KVM/RHEL, BIOS 1.16.1-1.el9 04/01/2014 Call Trace: <IRQ> dumpstacklvl (lib/dumpstack.c:124) printaddressdescription.constprop.0 (mm/kasan/report.c:378) ? dstdestroy (net/core/dst.c:112) printreport (mm/kasan/report.c:489) ? dstdestroy (net/core/dst.c:112) ? kasanaddrtoslab (mm/kasan/common.c:37) kasanreport (mm/kasan/report.c:603) ? dstdestroy (net/core/dst.c:112) ? rcudobatch (kernel/rcu/tree.c:2567) dstdestroy (net/core/dst.c:112) rcudobatch (kernel/rcu/tree.c:2567) ? _pfxrcudobatch (kernel/rcu/tree.c:2491) ? lockdephardirqsonprepare (kernel/locking/lockdep.c:4339 kernel/locking/lockdep.c:4406) rcucore (kernel/rcu/tree.c:2825) handlesoftirqs (kernel/softirq.c:554) _irqexitrcu (kernel/softirq.c:589 kernel/softirq.c:428 kernel/softirq.c:637) irqexitrcu (kernel/softirq.c:651) sysvecapictimerinterrupt (arch/x86/kernel/apic/apic.c:1049 arch/x86/kernel/apic/apic.c:1049) </IRQ> <TASK> asmsysvecapictimerinterrupt (./arch/x86/include/asm/idtentry.h:702) RIP: 0010:defaultidle (./arch/x86/include/asm/irqflags.h:37 ./arch/x86/include/asm/irqflags.h:92 arch/x86/kernel/process.c:743) Code: 00 4d 29 c8 4c 01 c7 4c 29 c2 e9 6e ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 0f 00 2d c7 c9 27 00 fb f4 <fa> c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 RSP: 0018:ffff888100d2fe00 EFLAGS: 00000246 RAX: 00000000001870ed RBX: 1ffff110201a5fc2 RCX: ffffffffb61a3e46 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffb3d4d123 RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed11c7e1835d R10: ffff888e3f0c1aeb R11: 0000000000000000 R12: 0000000000000000 R13: ffff888100d20000 R14: dffffc0000000000 R15: 0000000000000000 ? ctkernelexit.constprop.0 (kernel/contexttracking.c:148) ? cpuidleidlecall (kernel/sched/idle.c:186) defaultidlecall (./include/linux/cpuidle.h:143 kernel/sched/idle.c:118) cpuidleidlecall (kernel/sched/idle.c:186) ? _pfxcpuidleidlecall (kernel/sched/idle.c:168) ? lockrelease (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5848) ? lockdephardirqsonprepare (kernel/locking/lockdep.c:4347 kernel/locking/lockdep.c:4406) ? tscverifytscadjust (arch/x86/kernel/tscsync.c:59) doidle (kernel/sched/idle.c:326) cpustartupentry (kernel/sched/idle.c:423 (discriminator 1)) startsecondary (arch/x86/kernel/smpboot.c:202 arch/x86/kernel/smpboot.c:282) ? _pfxstartsecondary (arch/x86/kernel/smpboot.c:232) ? softrestartcpu (arch/x86/kernel/head64.S:452) commonstartup64 (arch/x86/kernel/head64.S:414) </TASK> Dec 03 05:46:18 kernel: Allocated by task 12184: kasansavestack (mm/kasan/common.c:48) kasansavetrack (./arch/x86/include/asm/current.h:49 mm/kasan/common.c:60 mm/kasan/common.c:69) _kasanslaballoc (mm/kasan/common.c:319 mm/kasan/common.c:345) kmemcacheallocnoprof (mm/slub.c:4085 mm/slub.c:4134 mm/slub.c:4141) copynetns (net/core/netnamespace.c:421 net/core/netnamespace.c:480) createnew_namespaces ---truncated---(CVE-2024-56658)

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

crypto: caam - Fix the pointer passed to caamqishutdown()

The type of the last parameter given to devmaddactionorreset() is "struct caamdrvprivate *", but in caamqishutdown(), it is casted to "struct device *".

Pass the correct parameter to devmaddactionorreset() so that the resources are released as expected.(CVE-2024-56754)

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

power: supply: gpio-charger: Fix set charge current limits

Fix set charge current limits for devices which allow to set the lowest charge current limit to be greater zero. If requested charge current limit is below lowest limit, the index equals currentlimitmap_size which leads to accessing memory beyond allocated memory.(CVE-2024-57792)

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

RDMA/rxe: Remove the direct link to net_device

The similar patch in siw is in the link: https://git.kernel.org/rdma/rdma/c/16b87037b48889

This problem also occurred in RXE. The following analyze this problem. In the following Call Traces: " BUG: KASAN: slab-use-after-free in devgetflags+0x188/0x1d0 net/core/dev.c:8782 Read of size 4 at addr ffff8880554640b0 by task kworker/1:4/5295

CPU: 1 UID: 0 PID: 5295 Comm: kworker/1:4 Not tainted 6.12.0-rc3-syzkaller-00399-g9197b73fd7bb #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: infiniband ibcacheeventtask Call Trace: <TASK> _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0x169/0x550 mm/kasan/report.c:488 kasanreport+0x143/0x180 mm/kasan/report.c:601 devgetflags+0x188/0x1d0 net/core/dev.c:8782 rxequeryport+0x12d/0x260 drivers/infiniband/sw/rxe/rxeverbs.c:60 _ibqueryport drivers/infiniband/core/device.c:2111 [inline] ibqueryport+0x168/0x7d0 drivers/infiniband/core/device.c:2143 ibcacheupdate+0x1a9/0xb80 drivers/infiniband/core/cache.c:1494 ibcacheeventtask+0xf3/0x1e0 drivers/infiniband/core/cache.c:1568 processonework kernel/workqueue.c:3229 [inline] processscheduledworks+0xa65/0x1850 kernel/workqueue.c:3310 workerthread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f2/0x390 kernel/kthread.c:389 retfromfork+0x4d/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> "

1). In the link [1],

" infiniband syz2: set down "

This means that on 839.350575, the event ibcacheeventtask was sent andi queued in ibwq.

2). In the link [1],

" team0 (unregistering): Port device teamslave0 removed "

It indicates that before 843.251853, the net device should be freed.

3). In the link [1],

" BUG: KASAN: slab-use-after-free in devgetflags+0x188/0x1d0 "

This means that on 850.559070, this slab-use-after-free problem occurred.

In all, on 839.350575, the event ibcacheeventtask was sent and queued in ibwq,

before 843.251853, the net device veth was freed.

on 850.559070, this event was executed, and the mentioned freed net device was called. Thus, the above call trace occurred.

[1] https://syzkaller.appspot.com/x/log.txt?x=12e7025f980000(CVE-2024-57795)

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

RDMA/siw: Remove direct link to net_device

Do not manage a per device direct link to netdevice. Rely on associated ibdevices netdevice management, not doubling the effort locally. A badly managed local link to netdevice was causing a 'KASAN: slab-use-after-free' exception during siwqueryport() call.(CVE-2024-57857)