OESA-2025-1205

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

bpf: Prevent tailcall infinite loop caused by freplace

There is a potential infinite loop issue that can occur when using a combination of tail calls and freplace.

In an upcoming selftest, the attach target for entryfreplace of tailcallfreplace.c is subprogtc of tcbpf2bpf.c, while the tail call in entryfreplace leads to entrytc. This results in an infinite loop:

entrytc -> subprogtc -> entryfreplace --tailcall-> entrytc.

The problem arises because the tailcallcnt in entryfreplace resets to zero each time entryfreplace is executed, causing the tail call mechanism to never terminate, eventually leading to a kernel panic.

To fix this issue, the solution is twofold:

1. Prevent updating a program extended by an freplace program to a prog_array map.
2. Prevent extending a program that is already part of a prog_array map with an freplace program.

This ensures that:

• If a program or its subprogram has been extended by an freplace program, it can no longer be updated to a prog_array map.
• If a program has been added to a prog_array map, neither it nor its subprograms can be extended by an freplace program.

Moreover, an extension program should not be tailcalled. As such, return -EINVAL if the program has a type of BPFPROGTYPEEXT when adding it to a progarray map.

Additionally, fix a minor code style issue by replacing eight spaces with a tab for proper formatting.(CVE-2024-47794)

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

mm/thp: fix deferred split unqueue naming and locking

Recent changes are putting more pressure on THP deferred split queues: under load revealing long-standing races, causing list_del corruptions, "Bad page state"s and worse (I keep BUGs in both of those, so usually don't get to see how badly they end up without). The relevant recent changes being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin, improved swap allocation, and underused THP splitting.

Before fixing locking: rename misleading folioundolargermappable(), which does not undo largermappable, to foliounqueuedeferredsplit(), which is what it does. But that and its out-of-line _callee are mm internals of very limited usability: add comment and WARNONONCEs to check usage; and return a bool to say if a deferred split was unqueued, which can then be used in WARNONONCEs around safety checks (sparing callers the arcane conditionals in _foliounqueuedeferredsplit()).

Just omit the foliounqueuedeferredsplit() from freeunreffolios(), all of whose callers now call it beforehand (and if any forget then badpage() will tell) - except for its caller putpageslist(), which itself no longer has any callers (and will be deleted separately).

Swapout: memcgroupswapout() has been resetting folio->memcgdata 0 without checking and unqueueing a THP folio from deferred split list; which is unfortunate, since the splitqueuelock depends on the memcg (when memcg is enabled); so swapout has been unqueueing such THPs later, when freeing the folio, using the pgdat's lock instead: potentially corrupting the memcg's list. _removemapping() has frozen refcount to 0 here, so no problem with calling foliounqueuedeferredsplit() before resetting memcg_data.

That goes back to 5.4 commit 87eaceb3faa5 ("mm: thp: make deferred split shrinker memcg aware"): which included a check on swapcache before adding to deferred queue, but no check on deferred queue before adding THP to swapcache. That worked fine with the usual sequence of events in reclaim (though there were a couple of rare ways in which a THP on deferred queue could have been swapped out), but 6.12 commit dafff3f4c850 ("mm: split underused THPs") avoids splitting underused THPs in reclaim, which makes swapcache THPs on deferred queue commonplace.

Keep the check on swapcache before adding to deferred queue? Yes: it is no longer essential, but preserves the existing behaviour, and is likely to be a worthwhile optimization (vmstat showed much more traffic on the queue under swapping load if the check was removed); update its comment.

Memcg-v1 move (deprecated): memcgroupmoveaccount() has been changing folio->memcgdata without checking and unqueueing a THP folio from the deferred list, sometimes corrupting "from" memcg's list, like swapout. Refcount is non-zero here, so foliounqueuedeferredsplit() can only be used in a WARNONONCE to validate the fix, which must be done earlier: memcgroupmovechargepterange() first try to split the THP (splitting of course unqueues), or skip it if that fails. Not ideal, but moving charge has been requested, and khugepaged should repair the THP later: nobody wants new custom unqueueing code just for this deprecated case.

The 87eaceb3faa5 commit did have the code to move from one deferred list to another (but was not conscious of its unsafety while refcount non-0); but that was removed by 5.6 commit fac0516b5534 ("mm: thp: don't need care deferred split queue in memcg charge move path"), which argued that the existence of a PMD mapping guarantees that the THP cannot be on a deferred list. As above, false in rare cases, and now commonly false.

Backport to 6.11 should be straightforward. Earlier backports must take care that other deferredlist fixes and dependencies are included. There is not a strong case for backports, but they can fix cornercases.(CVE-2024-53079)

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

net: sched: fix ordering of qlen adjustment

Changes to sch->q.qlen around qdisctreereducebacklog() need to happen _before a call to said function because otherwise it may fail to notify parent qdiscs when the child is about to become empty.(CVE-2024-53164)

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

xen/netfront: fix crash when removing device

When removing a netfront device directly after a suspend/resume cycle it might happen that the queues have not been setup again, causing a crash during the attempt to stop the queues another time.

Fix that by checking the queues are existing before trying to stop them.

This is XSA-465 / CVE-2024-53240.(CVE-2024-53240)

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:

net: tun: fix tunnapialloc_frags()

syzbot reported the following crash [1]

Issue came with the blamed commit. Instead of going through all the iov components, we keep using the first one and end up with a malformed skb.

[1]

kernel BUG at net/core/skbuff.c:2849 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 6230 Comm: syz-executor132 Not tainted 6.13.0-rc1-syzkaller-00407-g96b6fcc0ee41 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024 RIP: 0010:_pskbpulltail+0x1568/0x1570 net/core/skbuff.c:2848 Code: 38 c1 0f 8c 32 f1 ff ff 4c 89 f7 e8 92 96 74 f8 e9 25 f1 ff ff e8 e8 ae 09 f8 48 8b 5c 24 08 e9 eb fb ff ff e8 d9 ae 09 f8 90 <0f> 0b 66 0f 1f 44 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffc90004cbef30 EFLAGS: 00010293 RAX: ffffffff8995c347 RBX: 00000000fffffff2 RCX: ffff88802cf45a00 RDX: 0000000000000000 RSI: 00000000fffffff2 RDI: 0000000000000000 RBP: ffff88807df0c06a R08: ffffffff8995b084 R09: 1ffff1100fbe185c R10: dffffc0000000000 R11: ffffed100fbe185d R12: ffff888076e85d50 R13: ffff888076e85c80 R14: ffff888076e85cf4 R15: ffff888076e85c80 FS: 00007f0dca6ea6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f0dca6ead58 CR3: 00000000119da000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> skbcowdata+0x2da/0xcb0 net/core/skbuff.c:5284 tipcaeaddecrypt net/tipc/crypto.c:894 [inline] tipccryptorcv+0x402/0x24e0 net/tipc/crypto.c:1844 tipcrcv+0x57e/0x12a0 net/tipc/node.c:2109 tipcl2rcvmsg+0x2bd/0x450 net/tipc/bearer.c:668 _netifreceiveskblistptype net/core/dev.c:5720 [inline] _netifreceiveskblistcore+0x8b7/0x980 net/core/dev.c:5762 _netifreceiveskblist net/core/dev.c:5814 [inline] netifreceiveskblistinternal+0xa51/0xe30 net/core/dev.c:5905 gronormallist include/net/gro.h:515 [inline] napicompletedone+0x2b5/0x870 net/core/dev.c:6256 napicomplete include/linux/netdevice.h:567 [inline] tungetuser+0x2ea0/0x4890 drivers/net/tun.c:1982 tunchrwriteiter+0x10d/0x1f0 drivers/net/tun.c:2057 doiterreadvwritev+0x600/0x880 vfswritev+0x376/0xba0 fs/readwrite.c:1050 dowritev+0x1b6/0x360 fs/readwrite.c:1096 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f(CVE-2024-56372)

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

wifi: ath12k: fix atomic calls in ath12kmacopsetbitrate_mask()

When I try to manually set bitrates:

iw wlan0 set bitrates legacy-2.4 1

I get sleeping from invalid context error, see below. Fix that by switching to use recently introduced ieee80211iteratestations_mtx().

Do note that WCN6855 firmware is still crashing, I'm not sure if that firmware even supports bitrate WMI commands and should we consider disabling ath12kmacopsetbitrate_mask() for WCN6855? But that's for another patch.

BUG: sleeping function called from invalid context at drivers/net/wireless/ath/ath12k/wmi.c:420 inatomic(): 0, irqsdisabled(): 0, nonblock: 0, pid: 2236, name: iw preemptcount: 0, expected: 0 RCU nest depth: 1, expected: 0 3 locks held by iw/2236: #0: ffffffffabc6f1d8 (cblock){++++}-{3:3}, at: genlrcv+0x14/0x40 #1: ffff888138410810 (&rdev->wiphy.mtx){+.+.}-{3:3}, at: nl80211predoit+0x54d/0x800 [cfg80211] #2: ffffffffab2cfaa0 (rcureadlock){....}-{1:2}, at: ieee80211iteratestationsatomic+0x2f/0x200 [mac80211] CPU: 3 UID: 0 PID: 2236 Comm: iw Not tainted 6.11.0-rc7-wt-ath+ #1772 Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021 Call Trace: <TASK> dumpstacklvl+0xa4/0xe0 dumpstack+0x10/0x20 mightresched+0x363/0x5a0 ? _allocskb+0x165/0x340 _mightsleep+0xad/0x160 ath12kwmicmdsend+0xb1/0x3d0 [ath12k] ? ath12kwmiinitwcn7850+0xa40/0xa40 [ath12k] ? _netdevallocskb+0x45/0x7b0 ? _asanmemset+0x39/0x40 ? ath12kwmiallocskb+0xf0/0x150 [ath12k] ? reacquireheldlocks+0x4d0/0x4d0 ath12kwmisetpeerparam+0x340/0x5b0 [ath12k] ath12kmacdisablepeerfixedrate+0xa3/0x110 [ath12k] ? ath12kmacvdevstop+0x4f0/0x4f0 [ath12k] ieee80211iteratestationsatomic+0xd4/0x200 [mac80211] ath12kmacopsetbitratemask+0x5d2/0x1080 [ath12k] ? ath12kmacvifchan+0x320/0x320 [ath12k] drvsetbitratemask+0x267/0x470 [mac80211] ieee80211setbitratemask+0x4cc/0x8a0 [mac80211] ? _thiscpupreemptcheck+0x13/0x20 nl80211settxbitratemask+0x2bc/0x530 [cfg80211] ? nl80211parsetxbitratemask+0x2320/0x2320 [cfg80211] ? tracecontentionend+0xef/0x140 ? rtnlunlock+0x9/0x10 ? nl80211predoit+0x557/0x800 [cfg80211] genlfamilyrcvmsgdoit+0x1f0/0x2e0 ? genlfamilyrcvmsgattrsparse.isra.0+0x250/0x250 ? nscapable+0x57/0xd0 genlfamilyrcvmsg+0x34c/0x600 ? genlfamilyrcvmsgdumpit+0x310/0x310 ? _lockacquire+0xc62/0x1de0 ? hesetmcsmask.isra.0+0x8d0/0x8d0 [cfg80211] ? nl80211parsetxbitratemask+0x2320/0x2320 [cfg80211] ? cfg80211externalauthrequest+0x690/0x690 [cfg80211] genlrcvmsg+0xa0/0x130 netlinkrcvskb+0x14c/0x400 ? genlfamilyrcvmsg+0x600/0x600 ? netlinkack+0xd70/0xd70 ? rwsemoptimisticspin+0x4f0/0x4f0 ? genlrcv+0x14/0x40 ? downreadkillable+0x580/0x580 ? netlinkdelivertap+0x13e/0x350 ? _thiscpupreemptcheck+0x13/0x20 genlrcv+0x23/0x40 netlinkunicast+0x45e/0x790 ? netlinkattachskb+0x7f0/0x7f0 netlinksendmsg+0x7eb/0xdb0 ? netlinkunicast+0x790/0x790 ? _thiscpupreemptcheck+0x13/0x20 ? selinuxsocketsendmsg+0x31/0x40 ? netlinkunicast+0x790/0x790 _socksendmsg+0xc9/0x160 _syssendmsg+0x620/0x990 ? kernelsendmsg+0x30/0x30 ? copymsghdr+0x410/0x410 ? _kasancheckread+0x11/0x20 ? marklock+0xe6/0x1470 _syssendmsg+0xe9/0x170 ? copymsghdrfromuser+0x120/0x120 ? _lockacquire+0xc62/0x1de0 ? dofaultaround+0x2c6/0x4e0 ? douseraddrfault+0x8c1/0xde0 ? reacquireheldlocks+0x220/0x4d0 ? douseraddrfault+0x8c1/0xde0 ? _kasancheckread+0x11/0x20 ? _fdget+0x4e/0x1d0 ? sockfdlookuplight+0x1a/0x170 _syssendmsg+0xd2/0x180 ? _syssendmsgsock+0x20/0x20 ? reacquireheldlocks+0x4d0/0x4d0 ? debugsmpprocessorid+0x17/0x20 _x64syssendmsg+0x72/0xb0 ? lockdephardirqson+0x7d/0x100 x64syscall+0x894/0x9f0 dosyscall64+0x64/0x130 entrySYSCALL64after ---truncated---(CVE-2024-56607)

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

netfilter: nftables: do not defer rule destruction via callrcu

nftableschaindestroy can sleep, it can't be used from callrcu callbacks.

Moreover, nftablesrulerelease() is only safe for error unwinding, while transaction mutex is held and the to-be-desroyed rule was not exposed to either dataplane or dumps, as it deactives+frees without the required synchronizercu() in-between.

nftruleexprdeactivate() callbacks will change ->use counters of other chains/sets, see e.g. nftlookup .deactivate callback, these must be serialized via transaction mutex.

Also add a few lockdep asserts to make this more explicit.

Calling synchronize_rcu() isn't ideal, but fixing this without is hard and way more intrusive. As-is, we can get:

WARNING: .. net/netfilter/nftablesapi.c:5515 nftsetdestroy+0x.. Workqueue: events nftablestransdestroywork RIP: 0010:nftsetdestroy+0x3fe/0x5c0 Call Trace: <TASK> nftablestransdestroywork+0x6b7/0xad0 processonework+0x64a/0xce0 worker_thread+0x613/0x10d0

In case the synchronize_rcu becomes an issue, we can explore alternatives.

One way would be to allocate nfttransrule objects + one nfttranschain object, deactivate the rules + the chain and then defer the freeing to the nft destroy workqueue. We'd still need to keep the synchronize_rcu path as a fallback to handle -ENOMEM corner cases though.(CVE-2024-56655)

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:

net: lapb: increase LAPBHEADERLEN

It is unclear if net/lapb code is supposed to be ready for 8021q.

We can at least avoid crashes like the following :

skbuff: skbunderpanic: text:ffffffff8aabe1f6 len:24 put:20 head:ffff88802824a400 data:ffff88802824a3fe tail:0x16 end:0x140 dev:nr0.2 ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 5508 Comm: dhcpcd Not tainted 6.12.0-rc7-syzkaller-00144-g66418447d27b #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 RIP: 0010:skbpanic net/core/skbuff.c:206 [inline] RIP: 0010:skbunderpanic+0x14b/0x150 net/core/skbuff.c:216 Code: 0d 8d 48 c7 c6 2e 9e 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 1a 6f 37 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc90002ddf638 EFLAGS: 00010282 RAX: 0000000000000086 RBX: dffffc0000000000 RCX: 7a24750e538ff600 RDX: 0000000000000000 RSI: 0000000000000201 RDI: 0000000000000000 RBP: ffff888034a86650 R08: ffffffff8174b13c R09: 1ffff920005bbe60 R10: dffffc0000000000 R11: fffff520005bbe61 R12: 0000000000000140 R13: ffff88802824a400 R14: ffff88802824a3fe R15: 0000000000000016 FS: 00007f2a5990d740(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000110c2631fd CR3: 0000000029504000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> skbpush+0xe5/0x100 net/core/skbuff.c:2636 nrheader+0x36/0x320 net/netrom/nrdev.c:69 devhardheader include/linux/netdevice.h:3148 [inline] vlandevhardheader+0x359/0x480 net/8021q/vlandev.c:83 devhardheader include/linux/netdevice.h:3148 [inline] lapbethdatatransmit+0x1f6/0x2a0 drivers/net/wan/lapbether.c:257 lapbdatatransmit+0x91/0xb0 net/lapb/lapbiface.c:447 lapbtransmitbuffer+0x168/0x1f0 net/lapb/lapbout.c:149 lapbestablishdatalink+0x84/0xd0 lapbdeviceevent+0x4e0/0x670 notifiercallchain+0x19f/0x3e0 kernel/notifier.c:93 _devnotifyflags+0x207/0x400 devchangeflags+0xf0/0x1a0 net/core/dev.c:8922 devinetioctl+0xa4e/0x1aa0 net/ipv4/devinet.c:1188 inetioctl+0x3d7/0x4f0 net/ipv4/afinet.c:1003 sockdoioctl+0x158/0x460 net/socket.c:1227 sockioctl+0x626/0x8e0 net/socket.c:1346 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:907 [inline] _sesysioctl+0xf9/0x170 fs/ioctl.c:893 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall_64+0xf3/0x230 arch/x86/entry/common.c:83(CVE-2024-56659)

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

net: mscc: ocelot: fix incorrect IFH SRCPORT field in ocelotifhsetbasic()

Packets injected by the CPU should have a SRCPORT field equal to the CPU port module index in the Analyzer block (ocelot->numphys_ports).

The blamed commit copied the ocelotifhsetbasic() call incorrectly from ocelotxmitcommon() in net/dsa/tagocelot.c. Instead of calling with "x", it calls with BIT_ULL(x), but the field is not a port mask, but rather a single port index.

[ side note: this is the technical debt of code duplication :( ]

The error used to be silent and doesn't appear to have other user-visible manifestations, but with new changes in the packing library, it now fails loudly as follows:

------------[ cut here ]------------ Cannot store 0x40 inside bits 46-43 - will truncate sja1105 spi2.0: xmit timed out WARNING: CPU: 1 PID: 102 at lib/packing.c:98 _pack+0x90/0x198 sja1105 spi2.0: timed out polling for tstamp CPU: 1 UID: 0 PID: 102 Comm: felixxmit Tainted: G W N 6.13.0-rc1-00372-gf706b85d972d-dirty #2605 Call trace: _pack+0x90/0x198 (P) _pack+0x90/0x198 (L) packing+0x78/0x98 ocelotifhsetbasic+0x260/0x368 ocelotportinjectframe+0xa8/0x250 felixportdeferredxmit+0x14c/0x258 kthreadworker_fn+0x134/0x350 kthread+0x114/0x138

The code path pertains to the ocelot switchdev driver and to the felix secondary DSA tag protocol, ocelot-8021q. Here seen with ocelot-8021q.

The messenger (packing) is not really to blame, so fix the original commit instead.(CVE-2024-56717)

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

dmaengine: atxdmac: avoid nullprtderef in atxdmacprepdma_memset

The atxdmacmemsetcreatedesc may return NULL, which will lead to a null pointer dereference. For example, the len input is error, or the atchan->freedescslist is empty and memory is exhausted. Therefore, add check to avoid this.(CVE-2024-56767)

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:

scsi: mpi3mr: Fix corrupt config pages PHY state is switched in sysfs

The driver, through the SAS transport, exposes a sysfs interface to enable/disable PHYs in a controller/expander setup. When multiple PHYs are disabled and enabled in rapid succession, the persistent and current config pages related to SAS IO unit/SAS Expander pages could get corrupted.

Use separate memory for each config request.(CVE-2024-57804)

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

scsi: megaraid_sas: Fix for a potential deadlock

This fixes a 'possible circular locking dependency detected' warning CPU0 CPU1 ---- ---- lock(&instance->resetmutex); lock(&shost->scanmutex); lock(&instance->resetmutex); lock(&shost->scanmutex);

Fix this by temporarily releasing the reset_mutex.(CVE-2024-57807)

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

tracing: Have process_string() also allow arrays

In order to catch a common bug where a TRACEEVENT() TPfastassign() assigns an address of an allocated string to the ring buffer and then references it in TPprintk(), which can be executed hours later when the string is free, the function testeventprintk() runs on all events as they are registered to make sure there's no unwanted dereferencing.

It calls processstring() to handle cases in TPprintk() format that has "%s". It returns whether or not the string is safe. But it can have some false positives.

For instance, xebomove() has:

TPprintk("movelackssource:%s, migrate object %p [size %zu] from %s to %s deviceid:%s", entry->movelackssource ? "yes" : "no", _entry->bo, _entry->size, xememtypetoname[entry->oldplacement], xememtypetoname[entry->newplacement], _getstr(device_id))

Where the "%s" references into xememtypetoname[]. This is an array of pointers that should be safe for the event to access. Instead of flagging this as a bad reference, if a reference points to an array, where the record field is the index, consider it safe.(CVE-2024-57930)

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

virtio-blk: don't keep queue frozen during system suspend

Commit 4ce6e2db00de ("virtio-blk: Ensure no requests in virtqueues before deleting vqs.") replaces queue quiesce with queue freeze in virtio-blk's PM callbacks. And the motivation is to drain inflight IOs before suspending.

block layer's queue freeze looks very handy, but it is also easy to cause deadlock, such as, any attempt to call into bioqueueenter() may run into deadlock if the queue is frozen in current context. There are all kinds of ->suspend() called in suspend context, so keeping queue frozen in the whole suspend context isn't one good idea. And Marek reported lockdep warning[1] caused by virtio-blk's freeze queue in virtblk_freeze().

[1] https://lore.kernel.org/linux-block/ca16370e-d646-4eee-b9cc-87277c89c43c@samsung.com/

Given the motivation is to drain in-flight IOs, it can be done by calling freeze & unfreeze, meantime restore to previous behavior by keeping queue quiesced during suspend.(CVE-2024-57946)

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

block, bfq: fix wakerbfqq UAF after bfqsplit_bfqq()

Our syzkaller report a following UAF for v6.6:

BUG: KASAN: slab-use-after-free in bfqinitrq+0x175d/0x17a0 block/bfq-iosched.c:6958 Read of size 8 at addr ffff8881b57147d8 by task fsstress/232726

CPU: 2 PID: 232726 Comm: fsstress Not tainted 6.6.0-g3629d1885222 #39 Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x91/0xf0 lib/dumpstack.c:106 printaddressdescription.constprop.0+0x66/0x300 mm/kasan/report.c:364 printreport+0x3e/0x70 mm/kasan/report.c:475 kasanreport+0xb8/0xf0 mm/kasan/report.c:588 hlistaddhead include/linux/list.h:1023 [inline] bfqinitrq+0x175d/0x17a0 block/bfq-iosched.c:6958 bfqinsertrequest.isra.0+0xe8/0xa20 block/bfq-iosched.c:6271 bfqinsertrequests+0x27f/0x390 block/bfq-iosched.c:6323 blkmqinsertrequest+0x290/0x8f0 block/blk-mq.c:2660 blkmqsubmitbio+0x1021/0x15e0 block/blk-mq.c:3143 _submitbio+0xa0/0x6b0 block/blk-core.c:639 _submitbionoacctmq block/blk-core.c:718 [inline] submitbionoacctnocheck+0x5b7/0x810 block/blk-core.c:747 submitbionoacct+0xca0/0x1990 block/blk-core.c:847 _ext4readbh fs/ext4/super.c:205 [inline] ext4readbh+0x15e/0x2e0 fs/ext4/super.c:230 _readextenttreeblock+0x304/0x6f0 fs/ext4/extents.c:567 ext4findextent+0x479/0xd20 fs/ext4/extents.c:947 ext4extmapblocks+0x1a3/0x2680 fs/ext4/extents.c:4182 ext4mapblocks+0x929/0x15a0 fs/ext4/inode.c:660 ext4iomapbeginreport+0x298/0x480 fs/ext4/inode.c:3569 iomapiter+0x3dd/0x1010 fs/iomap/iter.c:91 iomapfiemap+0x1f4/0x360 fs/iomap/fiemap.c:80 ext4fiemap+0x181/0x210 fs/ext4/extents.c:5051 ioctlfiemap.isra.0+0x1b4/0x290 fs/ioctl.c:220 dovfsioctl+0x31c/0x11a0 fs/ioctl.c:811 _dosysioctl fs/ioctl.c:869 [inline] _sesysioctl+0xae/0x190 fs/ioctl.c:857 dosyscallx64 arch/x86/entry/common.c:51 [inline] dosyscall64+0x70/0x120 arch/x86/entry/common.c:81 entrySYSCALL64afterhwframe+0x78/0xe2

Allocated by task 232719: kasansavestack+0x22/0x50 mm/kasan/common.c:45 kasansettrack+0x25/0x30 mm/kasan/common.c:52 _kasanslaballoc+0x87/0x90 mm/kasan/common.c:328 kasanslaballoc include/linux/kasan.h:188 [inline] slabpostallochook mm/slab.h:768 [inline] slaballocnode mm/slub.c:3492 [inline] kmemcacheallocnode+0x1b8/0x6f0 mm/slub.c:3537 bfqgetqueue+0x215/0x1f00 block/bfq-iosched.c:5869 bfqgetbfqqhandlesplit+0x167/0x5f0 block/bfq-iosched.c:6776 bfqinitrq+0x13a4/0x17a0 block/bfq-iosched.c:6938 bfqinsertrequest.isra.0+0xe8/0xa20 block/bfq-iosched.c:6271 bfqinsertrequests+0x27f/0x390 block/bfq-iosched.c:6323 blkmqinsertrequest+0x290/0x8f0 block/blk-mq.c:2660 blkmqsubmitbio+0x1021/0x15e0 block/blk-mq.c:3143 _submitbio+0xa0/0x6b0 block/blk-core.c:639 _submitbionoacctmq block/blk-core.c:718 [inline] submitbionoacctnocheck+0x5b7/0x810 block/blk-core.c:747 submitbionoacct+0xca0/0x1990 block/blk-core.c:847 _ext4readbh fs/ext4/super.c:205 [inline] ext4readbhnowait+0x15a/0x240 fs/ext4/super.c:217 ext4readbhlock+0xac/0xd0 fs/ext4/super.c:242 ext4breadbatch+0x268/0x500 fs/ext4/inode.c:958 _ext4findentry+0x448/0x10f0 fs/ext4/namei.c:1671 ext4lookupentry fs/ext4/namei.c:1774 [inline] ext4lookup.part.0+0x359/0x6f0 fs/ext4/namei.c:1842 ext4lookup+0x72/0x90 fs/ext4/namei.c:1839 _lookupslow+0x257/0x480 fs/namei.c:1696 lookupslow fs/namei.c:1713 [inline] walkcomponent+0x454/0x5c0 fs/namei.c:2004 linkpathwalk.part.0+0x773/0xda0 fs/namei.c:2331 linkpathwalk fs/namei.c:3826 [inline] pathopenat+0x1b9/0x520 fs/namei.c:3826 dofilpopen+0x1b7/0x400 fs/namei.c:3857 dosysopenat2+0x5dc/0x6e0 fs/open.c:1428 dosysopen fs/open.c:1443 [inline] _dosysopenat fs/open.c:1459 [inline] _sesysopenat fs/open.c:1454 [inline] _x64sysopenat+0x148/0x200 fs/open.c:1454 dosyscallx64 arch/x86/entry/common.c:51 [inline] dosyscall6 ---truncated---(CVE-2025-21631)

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

hwmon: (drivetemp) Fix driver producing garbage data when SCSI errors occur

scsiexecutecmd() function can return both negative (linux codes) and positive (scsi_cmnd result field) error codes.

Currently the driver just passes error codes of scsiexecutecmd() to hwmon core, which is incorrect because hwmon only checks for negative error codes. This leads to hwmon reporting uninitialized data to userspace in case of SCSI errors (for example if the disk drive was disconnected).

This patch checks scsiexecutecmd() output and returns -EIO if it's error code is positive.

groeck: Avoid inline variable declaration for portability

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

USB: serial: quatech2: fix null-ptr-deref in qt2processread_urb()

This patch addresses a null-ptr-deref in qt2processread_urb() due to an incorrect bounds check in the following:

   if (newport > serial->num_ports) {
           dev_err(&port->dev,
                   "%s - port change to invalid port: %i\n",
                   __func__, newport);
           break;
   }

The condition doesn't account for the valid range of the serial->port buffer, which is from 0 to serial->numports - 1. When newport is equal to serial->numports, the assignment of "port" in the following code is out-of-bounds and NULL:

   serial_priv->current_port = newport;
   port = serial->port[serial_priv->current_port];

The fix checks if newport is greater than or equal to serial->num_ports indicating it is out-of-bounds.(CVE-2025-21689)

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

gfs2: Truncate address space when flipping GFS2DIFJDATA flag

Truncate an inode's address space when flipping the GFS2DIFJDATA flag: depending on that flag, the pages in the address space will either use buffer heads or iomapfoliostate structs, and we cannot mix the two.(CVE-2025-21699)

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

usb: cdc-acm: Check control transfer buffer size before access

If the first fragment is shorter than struct usbcdcnotification, we can't calculate an expectedsize. Log an error and discard the notification instead of reading lengths from memory outside the received data, which can lead to memory corruption when the expectedsize decreases between fragments, causing expected_size - acm->nb_index to wrap.

This issue has been present since the beginning of git history; however, it only leads to memory corruption since commit ea2583529cd1 ("cdc-acm: reassemble fragmented notifications").

A mitigating factor is that acmctrlirq() can only execute after userspace has opened /dev/ttyACM*; but if ModemManager is running, ModemManager will do that automatically depending on the USB device's vendor/product IDs and its other interfaces.(CVE-2025-21704)