The Linux Kernel, the operating system core itself.

Security Fix(es):

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

RDMA/rtrs: Ensure 'ib_sge list' is accessible

Move the declaration of the 'ibsge list' variable outside the 'alwaysinvalidate' block to ensure it remains accessible for use throughout the function.

Previously, 'ibsge list' was declared within the 'alwaysinvalidate' block, limiting its accessibility, then caused a 'BUG: kernel NULL pointer dereference'[1]. ? _diebody.cold+0x19/0x27 ? pagefaultoops+0x15a/0x2d0 ? searchmoduleextables+0x19/0x60 ? searchbpfextables+0x5f/0x80 ? excpagefault+0x7e/0x180 ? asmexcpagefault+0x26/0x30 ? memcpyorig+0xd5/0x140 rxemrcopy+0x1c3/0x200 [rdmarxe] ? rxepoolgetindex+0x4b/0x80 [rdmarxe] copydata+0xa5/0x230 [rdmarxe] rxerequester+0xd9b/0xf70 [rdmarxe] ? finishtaskswitch.isra.0+0x99/0x2e0 rxesender+0x13/0x40 [rdmarxe] dotask+0x68/0x1e0 [rdmarxe] processonework+0x177/0x330 workerthread+0x252/0x390 ? _pfxworker_thread+0x10/0x10

This change ensures the variable is available for subsequent operations that require it.

[1] https://lore.kernel.org/linux-rdma/6a1f3e8f-deb0-49f9-bc69-a9b03ecfcda7@fujitsu.com/(CVE-2024-36476)

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

drm/sti: avoid potential dereference of error pointers in stihqvdpatomic_check

The return value of drmatomicgetcrtcstate() needs to be checked. To avoid use of error pointer 'crtc_state' in case of the failure.(CVE-2024-56778)

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

netrom: check buffer length before accessing it

Syzkaller reports an uninit value read from ax25cmp when sending raw message through ieee802154 implementation.

===================================================== BUG: KMSAN: uninit-value in ax25cmp+0x3a5/0x460 net/ax25/ax25addr.c:119 ax25cmp+0x3a5/0x460 net/ax25/ax25addr.c:119 nrdevget+0x20e/0x450 net/netrom/nrroute.c:601 nrrouteframe+0x1a2/0xfc0 net/netrom/nrroute.c:774 nrxmit+0x5a/0x1c0 net/netrom/nrdev.c:144 netdevstartxmit include/linux/netdevice.h:4940 [inline] netdevstartxmit include/linux/netdevice.h:4954 [inline] xmitone net/core/dev.c:3548 [inline] devhardstartxmit+0x247/0xa10 net/core/dev.c:3564 _devqueuexmit+0x33b8/0x5130 net/core/dev.c:4349 devqueuexmit include/linux/netdevice.h:3134 [inline] rawsendmsg+0x654/0xc10 net/ieee802154/socket.c:299 ieee802154socksendmsg+0x91/0xc0 net/ieee802154/socket.c:96 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg net/socket.c:745 [inline] syssendmsg+0x9c2/0xd60 net/socket.c:2584 _syssendmsg+0x28d/0x3c0 net/socket.c:2638 _syssendmsg net/socket.c:2667 [inline] _dosyssendmsg net/socket.c:2676 [inline] _sesyssendmsg net/socket.c:2674 [inline] _x64syssendmsg+0x307/0x490 net/socket.c:2674 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x44/0x110 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x63/0x6b

Uninit was created at: slabpostallochook+0x129/0xa70 mm/slab.h:768 slaballocnode mm/slub.c:3478 [inline] kmemcacheallocnode+0x5e9/0xb10 mm/slub.c:3523 kmallocreserve+0x13d/0x4a0 net/core/skbuff.c:560 allocskb+0x318/0x740 net/core/skbuff.c:651 allocskb include/linux/skbuff.h:1286 [inline] allocskbwithfrags+0xc8/0xbd0 net/core/skbuff.c:6334 sockallocsendpskb+0xa80/0xbf0 net/core/sock.c:2780 sockallocsendskb include/net/sock.h:1884 [inline] rawsendmsg+0x36d/0xc10 net/ieee802154/socket.c:282 ieee802154socksendmsg+0x91/0xc0 net/ieee802154/socket.c:96 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg net/socket.c:745 [inline] _syssendmsg+0x9c2/0xd60 net/socket.c:2584 _syssendmsg+0x28d/0x3c0 net/socket.c:2638 _syssendmsg net/socket.c:2667 [inline] _dosyssendmsg net/socket.c:2676 [inline] _sesyssendmsg net/socket.c:2674 [inline] _x64syssendmsg+0x307/0x490 net/socket.c:2674 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x44/0x110 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x63/0x6b

CPU: 0 PID: 5037 Comm: syz-executor166 Not tainted 6.7.0-rc7-syzkaller-00003-gfbafc3e621c3 #0

Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023

This issue occurs because the skb buffer is too small, and it's actual allocation is aligned. This hides an actual issue, which is that nrrouteframe does not validate the buffer size before using it.

Fix this issue by checking skb->len before accessing any fields in skb->data.

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

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

media: vidtv: Fix a null-ptr-deref in vidtvmuxstop_thread

syzbot report a null-ptr-deref in vidtvmuxstop_thread. [1]

If dvb->mux is not initialized successfully by vidtvmuxinit() in the vidtvstartstreaming(), it will trigger null pointer dereference about mux in vidtvmuxstop_thread().

Adjust the timing of streaming initialization and check it before stopping it.

[1] KASAN: null-ptr-deref in range [0x0000000000000128-0x000000000000012f] CPU: 0 UID: 0 PID: 5842 Comm: syz-executor248 Not tainted 6.13.0-rc4-syzkaller-00012-g9b2ffa6148b1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:vidtvmuxstopthread+0x26/0x80 drivers/media/test-drivers/vidtv/vidtvmux.c:471 Code: 90 90 90 90 66 0f 1f 00 55 53 48 89 fb e8 82 2e c8 f9 48 8d bb 28 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 02 7e 3b 0f b6 ab 28 01 00 00 31 ff 89 ee e8 RSP: 0018:ffffc90003f2faa8 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff87cfb125 RDX: 0000000000000025 RSI: ffffffff87d120ce RDI: 0000000000000128 RBP: ffff888029b8d220 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000003 R12: ffff888029b8d188 R13: ffffffff8f590aa0 R14: ffffc9000581c5c8 R15: ffff888029a17710 FS: 00007f7eef5156c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7eef5e635c CR3: 0000000076ca6000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> vidtvstopstreaming drivers/media/test-drivers/vidtv/vidtvbridge.c:209 [inline] vidtvstopfeed+0x151/0x250 drivers/media/test-drivers/vidtv/vidtvbridge.c:252 dmxsectionfeedstopfiltering+0x90/0x160 drivers/media/dvb-core/dvbdemux.c:1000 dvbdmxdevfeedstop.isra.0+0x1ee/0x270 drivers/media/dvb-core/dmxdev.c:486 dvbdmxdevfilterstop+0x22a/0x3a0 drivers/media/dvb-core/dmxdev.c:559 dvbdmxdevfilterfree drivers/media/dvb-core/dmxdev.c:840 [inline] dvbdemuxrelease+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246 _fput+0x3f8/0xb60 fs/filetable.c:450 taskworkrun+0x14e/0x250 kernel/taskwork.c:239 getsignal+0x1d3/0x2610 kernel/signal.c:2790 archdosignalorrestart+0x90/0x7e0 arch/x86/kernel/signal.c:337 exittousermodeloop kernel/entry/common.c:111 [inline] exittousermodeprepare include/linux/entry-common.h:329 [inline] _syscallexittousermodework kernel/entry/common.c:207 [inline] syscallexittousermode+0x150/0x2a0 kernel/entry/common.c:218 dosyscall64+0xda/0x250 arch/x86/entry/common.c:89 entrySYSCALL64afterhwframe+0x77/0x7f(CVE-2024-57834)

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

mm: hugetlb: independent PMD page table shared count

The folio refcount may be increased unexpectly through trygetfolio() by caller such as splithugepages. In hugepmdunshare(), we use refcount to check whether a pmd page table is shared. The check is incorrect if the refcount is increased by the above caller, and this can cause the page table leaked:

BUG: Bad page state in process sh pfn:109324 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x66 pfn:0x109324 flags: 0x17ffff800000000(node=0|zone=2|lastcpupid=0xfffff) pagetype: f2(table) raw: 017ffff800000000 0000000000000000 0000000000000000 0000000000000000 raw: 0000000000000066 0000000000000000 00000000f2000000 0000000000000000 page dumped because: nonzero mapcount ... CPU: 31 UID: 0 PID: 7515 Comm: sh Kdump: loaded Tainted: G B 6.13.0-rc2master+ #7 Tainted: [B]=BADPAGE Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 Call trace: showstack+0x20/0x38 (C) dumpstacklvl+0x80/0xf8 dumpstack+0x18/0x28 badpage+0x8c/0x130 freepageisbadreport+0xa4/0xb0 freeunrefpage+0x3cc/0x620 _folioput+0xf4/0x158 splithugepagesall+0x1e0/0x3e8 splithugepageswrite+0x25c/0x2d8 fullproxywrite+0x64/0xd8 vfswrite+0xcc/0x280 ksyswrite+0x70/0x110 _arm64syswrite+0x24/0x38 invokesyscall+0x50/0x120 el0svccommon.constprop.0+0xc8/0xf0 doel0svc+0x24/0x38 el0svc+0x34/0x128 el0t64synchandler+0xc8/0xd0 el0t64_sync+0x190/0x198

The issue may be triggered by damon, offlinepage, pageidle, etc, which will increase the refcount of page table.

1. The page table itself will be discarded after reporting the "nonzero mapcount".

2. The HugeTLB page mapped by the page table miss freeing since we treat the page table as shared and a shared page table will not be unmapped.

Fix it by introducing independent PMD page table shared count. As described by comment, ptindex/ptmm/ptfragrefcount are used for s390 gmap, x86 pgds and powerpc, ptsharecount is used for x86/arm64/riscv pmds, so we can reuse the field as ptsharecount.(CVE-2024-57883)

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

mm: vmscan: account for free pages to prevent infinite Loop in throttledirectreclaim()

The task sometimes continues looping in throttledirectreclaim() because allowdirectreclaim(pgdat) keeps returning false.

#0 [ffff80002cb6f8d0] _switchto at ffff8000080095ac #1 [ffff80002cb6f900] _schedule at ffff800008abbd1c #2 [ffff80002cb6f990] schedule at ffff800008abc50c #3 [ffff80002cb6f9b0] throttledirectreclaim at ffff800008273550 #4 [ffff80002cb6fa20] trytofreepages at ffff800008277b68 #5 [ffff80002cb6fae0] _allocpagesnodemask at ffff8000082c4660 #6 [ffff80002cb6fc50] allocpagesvma at ffff8000082e4a98 #7 [ffff80002cb6fca0] doanonymouspage at ffff80000829f5a8 #8 [ffff80002cb6fce0] _handlemmfault at ffff8000082a5974 #9 [ffff80002cb6fd90] handlemmfault at ffff8000082a5bd4

At this point, the pgdat contains the following two zones:

    NODE: 4  ZONE: 0  ADDR: ffff00817fffe540  NAME: "DMA32"
      SIZE: 20480  MIN/LOW/HIGH: 11/28/45
      VM_STAT:
            NR_FREE_PAGES: 359
    NR_ZONE_INACTIVE_ANON: 18813
      NR_ZONE_ACTIVE_ANON: 0
    NR_ZONE_INACTIVE_FILE: 50
      NR_ZONE_ACTIVE_FILE: 0
      NR_ZONE_UNEVICTABLE: 0
    NR_ZONE_WRITE_PENDING: 0
                 NR_MLOCK: 0
                NR_BOUNCE: 0
               NR_ZSPAGES: 0
        NR_FREE_CMA_PAGES: 0

    NODE: 4  ZONE: 1  ADDR: ffff00817fffec00  NAME: "Normal"
      SIZE: 8454144  PRESENT: 98304  MIN/LOW/HIGH: 68/166/264
      VM_STAT:
            NR_FREE_PAGES: 146
    NR_ZONE_INACTIVE_ANON: 94668
      NR_ZONE_ACTIVE_ANON: 3
    NR_ZONE_INACTIVE_FILE: 735
      NR_ZONE_ACTIVE_FILE: 78
      NR_ZONE_UNEVICTABLE: 0
    NR_ZONE_WRITE_PENDING: 0
                 NR_MLOCK: 0
                NR_BOUNCE: 0
               NR_ZSPAGES: 0
        NR_FREE_CMA_PAGES: 0

In allowdirectreclaim(), while processing ZONEDMA32, the sum of inactive/active file-backed pages calculated in zonereclaimablepages() based on the result of zonepagestatesnapshot() is zero.

Additionally, since this system lacks swap, the calculation of inactive/ active anonymous pages is skipped.

    crash> p nr_swap_pages
    nr_swap_pages = $1937 = {
      counter = 0
    }

As a result, ZONEDMA32 is deemed unreclaimable and skipped, moving on to the processing of the next zone, ZONENORMAL, despite ZONE_DMA32 having free pages significantly exceeding the high watermark.

The problem is that the pgdat->kswapd_failures hasn't been incremented.

    crash> px ((struct pglist_data *) 0xffff00817fffe540)->kswapd_failures
    $1935 = 0x0

This is because the node deemed balanced. The node balancing logic in balancepgdat() evaluates all zones collectively. If one or more zones (e.g., ZONEDMA32) have enough free pages to meet their watermarks, the entire node is deemed balanced. This causes balancepgdat() to exit early before incrementing the kswapdfailures, as it considers the overall memory state acceptable, even though some zones (like ZONE_NORMAL) remain under significant pressure.

The patch ensures that zonereclaimablepages() includes free pages (NRFREEPAGES) in its calculation when no other reclaimable pages are available (e.g., file-backed or anonymous pages). This change prevents zones like ZONEDMA32, which have sufficient free pages, from being mistakenly deemed unreclaimable. By doing so, the patch ensures proper node balancing, avoids masking pressure on other zones like ZONENORMAL, and prevents infinite loops in throttledirectreclaim() caused by allowdirectreclaim(pgdat) repeatedly returning false.

The kernel hangs due to a task stuck in throttledirectreclaim(), caused by a node being incorrectly deemed balanced despite pressure in certain zones, such as ZONENORMAL. This issue arises from zonereclaimable_pages ---truncated---(CVE-2024-57884)

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

mm/kmemleak: fix sleeping function called from invalid context at print message

Address a bug in the kernel that triggers a "sleeping function called from invalid context" warning when /sys/kernel/debug/kmemleak is printed under specific conditions: - CONFIGPREEMPTRT=y - Set SELinux as the LSM for the system - Set kptr_restrict to 1 - kmemleak buffer contains at least one item

BUG: sleeping function called from invalid context at kernel/locking/spinlockrt.c:48 inatomic(): 1, irqsdisabled(): 1, nonblock: 0, pid: 136, name: cat preemptcount: 1, expected: 0 RCU nest depth: 2, expected: 2 6 locks held by cat/136: #0: ffff32e64bcbf950 (&p->lock){+.+.}-{3:3}, at: seqreaditer+0xb8/0xe30 #1: ffffafe6aaa9dea0 (scanmutex){+.+.}-{3:3}, at: kmemleakseqstart+0x34/0x128 #3: ffff32e6546b1cd0 (&object->lock){....}-{2:2}, at: kmemleakseqshow+0x3c/0x1e0 #4: ffffafe6aa8d8560 (rcureadlock){....}-{1:2}, at: hasnscapabilitynoaudit+0x8/0x1b0 #5: ffffafe6aabbc0f8 (notiflock){+.+.}-{2:2}, at: avccomputeav+0xc4/0x3d0 irq event stamp: 136660 hardirqs last enabled at (136659): [<ffffafe6a80fd7a0>] rawspinunlockirqrestore+0xa8/0xd8 hardirqs last disabled at (136660): [<ffffafe6a80fd85c>] rawspinlockirqsave+0x8c/0xb0 softirqs last enabled at (0): [<ffffafe6a5d50b28>] copyprocess+0x11d8/0x3df8 softirqs last disabled at (0): [<0000000000000000>] 0x0 Preemption disabled at: [<ffffafe6a6598a4c>] kmemleakseqshow+0x3c/0x1e0 CPU: 1 UID: 0 PID: 136 Comm: cat Tainted: G E 6.11.0-rt7+ #34 Tainted: [E]=UNSIGNEDMODULE Hardware name: linux,dummy-virt (DT) Call trace: dumpbacktrace+0xa0/0x128 showstack+0x1c/0x30 dumpstacklvl+0xe8/0x198 dumpstack+0x18/0x20 rtspinlock+0x8c/0x1a8 avcpermnonode+0xa0/0x150 credhascapability.isra.0+0x118/0x218 selinuxcapable+0x50/0x80 securitycapable+0x7c/0xd0 hasnscapabilitynoaudit+0x94/0x1b0 hascapabilitynoaudit+0x20/0x30 restrictedpointer+0x21c/0x4b0 pointer+0x298/0x760 vsnprintf+0x330/0xf70 seqprintf+0x178/0x218 printunreferenced+0x1a4/0x2d0 kmemleakseqshow+0xd0/0x1e0 seqreaditer+0x354/0xe30 seqread+0x250/0x378 fullproxyread+0xd8/0x148 vfsread+0x190/0x918 ksysread+0xf0/0x1e0 _arm64sysread+0x70/0xa8 invokesyscall.constprop.0+0xd4/0x1d8 el0svc+0x50/0x158 el0t64_sync+0x17c/0x180

%pS and %pK, in the same back trace line, are redundant, and %pS can void %pK service in certain contexts.

%pS alone already provides the necessary information, and if it cannot resolve the symbol, it falls back to printing the raw address voiding the original intent behind the %pK.

Additionally, %pK requires a privilege check CAPSYSLOG enforced through the LSM, which can trigger a "sleeping function called from invalid context" warning under RTPREEMPT kernels when the check occurs in an atomic context. This issue may also affect other LSMs.

This change avoids the unnecessary privilege check and resolves the sleeping function warning without any loss of information.(CVE-2024-57885)

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

RDMA/uverbs: Prevent integer overflow issue

In the expression "cmd.wqesize * cmd.wrcount", both variables are u32 values that come from the user so the multiplication can lead to integer wrapping. Then we pass the result to uverbsrequestnextptr() which also could potentially wrap. The "cmd.sgecount * sizeof(struct ibuverbssge)" multiplication can also overflow on 32bit systems although it's fine on 64bit systems.

This patch does two things. First, I've re-arranged the condition in uverbsrequestnextptr() so that the use controlled variable "len" is on one side of the comparison by itself without any math. Then I've modified all the callers to use sizemul() for the multiplications.(CVE-2024-57890)

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

Bluetooth: hci_core: Fix sleeping function called from invalid context

This reworks hcicblist to not use mutex hcicblist_lock to avoid bugs like the bellow:

BUG: sleeping function called from invalid context at kernel/locking/mutex.c:585 inatomic(): 0, irqsdisabled(): 0, nonblock: 0, pid: 5070, name: kworker/u9:2 preemptcount: 0, expected: 0 RCU nest depth: 1, expected: 0 4 locks held by kworker/u9:2/5070: #0: ffff888015be3948 ((wqcompletion)hci0#2){+.+.}-{0:0}, at: processonework kernel/workqueue.c:3229 [inline] #0: ffff888015be3948 ((wqcompletion)hci0#2){+.+.}-{0:0}, at: processscheduledworks+0x8e0/0x1770 kernel/workqueue.c:3335 #1: ffffc90003b6fd00 ((workcompletion)(&hdev->rxwork)){+.+.}-{0:0}, at: processonework kernel/workqueue.c:3230 [inline] #1: ffffc90003b6fd00 ((workcompletion)(&hdev->rxwork)){+.+.}-{0:0}, at: processscheduledworks+0x91b/0x1770 kernel/workqueue.c:3335 #2: ffff8880665d0078 (&hdev->lock){+.+.}-{3:3}, at: hcilecreatebigcompleteevt+0xcf/0xae0 net/bluetooth/hcievent.c:6914 #3: ffffffff8e132020 (rcureadlock){....}-{1:2}, at: rculockacquire include/linux/rcupdate.h:298 [inline] #3: ffffffff8e132020 (rcureadlock){....}-{1:2}, at: rcureadlock include/linux/rcupdate.h:750 [inline] #3: ffffffff8e132020 (rcureadlock){....}-{1:2}, at: hcilecreatebigcompleteevt+0xdb/0xae0 net/bluetooth/hcievent.c:6915 CPU: 0 PID: 5070 Comm: kworker/u9:2 Not tainted 6.8.0-syzkaller-08073-g480e035fc4c7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Workqueue: hci0 hcirxwork Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:114 _mightresched+0x5d4/0x780 kernel/sched/core.c:10187 _mutexlockcommon kernel/locking/mutex.c:585 [inline] _mutexlock+0xc1/0xd70 kernel/locking/mutex.c:752 hciconnectcfm include/net/bluetooth/hcicore.h:2004 [inline] hcilecreatebigcompleteevt+0x3d9/0xae0 net/bluetooth/hcievent.c:6939 hcieventfunc net/bluetooth/hcievent.c:7514 [inline] hcieventpacket+0xa53/0x1540 net/bluetooth/hcievent.c:7569 hcirxwork+0x3e8/0xca0 net/bluetooth/hcicore.c:4171 processonework kernel/workqueue.c:3254 [inline] processscheduledworks+0xa00/0x1770 kernel/workqueue.c:3335 workerthread+0x86d/0xd70 kernel/workqueue.c:3416 kthread+0x2f0/0x390 kernel/kthread.c:388 retfromfork+0x4b/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:243 </TASK>(CVE-2024-57894)

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

drm/amdkfd: Correct the migration DMA map direction

The SVM DMA device map direction should be set the same as the DMA unmap setting, otherwise the DMA core will report the following warning.

Before finialize this solution, there're some discussion on the DMA mapping type(stream-based or coherent) in this KFD migration case, followed by https://lore.kernel.org/all/04d4ab32 -45a1-4b88-86ee-fb0f35a0ca40@amd.com/T/.

As there's no dmasyncsinglefor*() in the DMA buffer accessed that because this migration operation should be sync properly and automatically. Give that there's might not be a performance problem in various cache sync policy of DMA sync. Therefore, in order to simplify the DMA direction setting alignment, let's set the DMA map direction as BIDIRECTIONAL.

[ 150.834218] WARNING: CPU: 8 PID: 1812 at kernel/dma/debug.c:1028 checkunmap+0x1cc/0x930 [ 150.834225] Modules linked in: amdgpu(OE) amdxcp drmexec(OE) gpusched drmbuddy(OE) drmttmhelper(OE) ttm(OE) drmsuballochelper(OE) drmdisplayhelper(OE) drmkmshelper(OE) i2calgobit rpcsecgsskrb5 authrpcgss nfsv4 nfs lockd grace netfs xtconntrack xtMASQUERADE nfconntracknetlink xfrmuser xfrmalgo iptablenat xtaddrtype iptablefilter brnetfilter nvmefabrics overlay nfnetlinkcttimeout nfnetlink openvswitch nsh nfconncount nfnat nfconntrack nfdefragipv6 nfdefragipv4 libcrc32c bridge stp llc schfqcodel intelraplmsr amdatl intelraplcommon sndhdacodecrealtek sndhdacodecgeneric sndhdascodeccomponent sndhdacodechdmi sndhdaintel sndinteldspcfg edacmceamd sndpciacp6x sndhdacodec sndacpconfig sndhdacore sndhwdep sndsocacpi kvmamd sunrpc sndpcm kvm binfmtmisc sndseqmidi crct10difpclmul sndseqmidievent ghashclmulniintel sha512ssse3 sndrawmidi nlsiso88591 sha256ssse3 sha1ssse3 sndseq aesniintel sndseqdevice cryptosimd sndtimer cryptd inputleds [ 150.834310] wmibmof serioraw k10temp rapl snd sp5100tco ipmidevintf soundcore ccp ipmimsghandler cm32181 industrialio machid msr parportpc ppdev lp parport efipstore drm(OE) iptables xtables pcistub crc32pclmul nvme ahci libahci i2cpiix4 r8169 nvmecore i2cdesignwarepci realtek i2cccgxucsi video wmi hidgeneric cdcether usbnet usbhid hid r8152 mii [ 150.834354] CPU: 8 PID: 1812 Comm: rocrtst64 Tainted: G OE 6.10.0-custom #492 [ 150.834358] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 06/13/2021 [ 150.834360] RIP: 0010:checkunmap+0x1cc/0x930 [ 150.834363] Code: c0 4c 89 4d c8 e8 34 bf 86 00 4c 8b 4d c8 4c 8b 45 c0 48 8b 4d b8 48 89 c6 41 57 4c 89 ea 48 c7 c7 80 49 b4 84 e8 b4 81 f3 ff <0f> 0b 48 c7 c7 04 83 ac 84 e8 76 ba fc ff 41 8b 76 4c 49 8d 7e 50 [ 150.834365] RSP: 0018:ffffaac5023739e0 EFLAGS: 00010086 [ 150.834368] RAX: 0000000000000000 RBX: ffffffff8566a2e0 RCX: 0000000000000027 [ 150.834370] RDX: ffff8f6a8f621688 RSI: 0000000000000001 RDI: ffff8f6a8f621680 [ 150.834372] RBP: ffffaac502373a30 R08: 00000000000000c9 R09: ffffaac502373850 [ 150.834373] R10: ffffaac502373848 R11: ffffffff84f46328 R12: ffffaac502373a40 [ 150.834375] R13: ffff8f6741045330 R14: ffff8f6741a77700 R15: ffffffff84ac831b [ 150.834377] FS: 00007faf0fc94c00(0000) GS:ffff8f6a8f600000(0000) knlGS:0000000000000000 [ 150.834379] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 150.834381] CR2: 00007faf0b600020 CR3: 000000010a52e000 CR4: 0000000000350ef0 [ 150.834383] Call Trace: [ 150.834385] <TASK> [ 150.834387] ? showregs+0x6d/0x80 [ 150.834393] ? _warn+0x8c/0x140 [ 150.834397] ? checkunmap+0x1cc/0x930 [ 150.834400] ? reportbug+0x193/0x1a0 [ 150.834406] ? handlebug+0x46/0x80 [ 150.834410] ? excinvalidop+0x1d/0x80 [ 150.834413] ? asmexcinvalidop+0x1f/0x30 [ 150.834420] ? checkunmap+0x1cc/0x930 [ 150.834425] debugdmaunmappage+0x86/0x90 [ 150.834431] ? srsoreturn_thunk+0x5/0x5f [ 150.834435] ---truncated---(CVE-2024-57897)

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

afpacket: fix vlangetprotocoldgram() vs MSG_PEEK

Blamed commit forgot MSG_PEEK case, allowing a crash [1] as found by syzbot.

Rework vlangetprotocol_dgram() to not touch skb at all, so that it can be used from many cpus on the same skb.

Add a const qualifier to skb argument.

[1] skbuff: skbunderpanic: text:ffffffff8a8ccd05 len:29 put:14 head:ffff88807fc8e400 data:ffff88807fc8e3f4 tail:0x11 end:0x140 dev:<NULL> ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 5892 Comm: syz-executor883 Not tainted 6.13.0-rc4-syzkaller-00054-gd6ef8b40d075 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skbpanic net/core/skbuff.c:206 [inline] RIP: 0010:skbunderpanic+0x14b/0x150 net/core/skbuff.c:216 Code: 0b 8d 48 c7 c6 86 d5 25 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 5a 69 79 f7 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:ffffc900038d7638 EFLAGS: 00010282 RAX: 0000000000000087 RBX: dffffc0000000000 RCX: 609ffd18ea660600 RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 RBP: ffff88802483c8d0 R08: ffffffff817f0a8c R09: 1ffff9200071ae60 R10: dffffc0000000000 R11: fffff5200071ae61 R12: 0000000000000140 R13: ffff88807fc8e400 R14: ffff88807fc8e3f4 R15: 0000000000000011 FS: 00007fbac5e006c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fbac5e00d58 CR3: 000000001238e000 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 vlangetprotocoldgram+0x165/0x290 net/packet/afpacket.c:585 packetrecvmsg+0x948/0x1ef0 net/packet/afpacket.c:3552 sockrecvmsgnosec net/socket.c:1033 [inline] sockrecvmsg+0x22f/0x280 net/socket.c:1055 sysrecvmsg+0x1c6/0x480 net/socket.c:2803 sysrecvmsg net/socket.c:2845 [inline] dorecvmmsg+0x426/0xab0 net/socket.c:2940 _sysrecvmmsg net/socket.c:3014 [inline] _dosysrecvmmsg net/socket.c:3037 [inline] _sesysrecvmmsg net/socket.c:3030 [inline] _x64sysrecvmmsg+0x199/0x250 net/socket.c:3030 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f(CVE-2024-57901)

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

afpacket: fix vlangettci() vs MSGPEEK

Blamed commit forgot MSG_PEEK case, allowing a crash [1] as found by syzbot.

Rework vlangettci() to not touch skb at all, so that it can be used from many cpus on the same skb.

Add a const qualifier to skb argument.

[1] skbuff: skbunderpanic: text:ffffffff8a8da482 len:32 put:14 head:ffff88807a1d5800 data:ffff88807a1d5810 tail:0x14 end:0x140 dev:<NULL> ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 5880 Comm: syz-executor172 Not tainted 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skbpanic net/core/skbuff.c:206 [inline] RIP: 0010:skbunderpanic+0x14b/0x150 net/core/skbuff.c:216 Code: 0b 8d 48 c7 c6 9e 6c 26 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 3a 5a 79 f7 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:ffffc90003baf5b8 EFLAGS: 00010286 RAX: 0000000000000087 RBX: dffffc0000000000 RCX: 8565c1eec37aa000 RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 RBP: ffff88802616fb50 R08: ffffffff817f0a4c R09: 1ffff92000775e50 R10: dffffc0000000000 R11: fffff52000775e51 R12: 0000000000000140 R13: ffff88807a1d5800 R14: ffff88807a1d5810 R15: 0000000000000014 FS: 00007fa03261f6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffd65753000 CR3: 0000000031720000 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 vlangettci+0x272/0x550 net/packet/afpacket.c:565 packetrecvmsg+0x13c9/0x1ef0 net/packet/afpacket.c:3616 sockrecvmsgnosec net/socket.c:1044 [inline] sockrecvmsg+0x22f/0x280 net/socket.c:1066 _sysrecvmsg+0x1c6/0x480 net/socket.c:2814 sysrecvmsg net/socket.c:2856 [inline] dorecvmmsg+0x426/0xab0 net/socket.c:2951 _sysrecvmmsg net/socket.c:3025 [inline] _dosysrecvmmsg net/socket.c:3048 [inline] _sesysrecvmmsg net/socket.c:3041 [inline] _x64sysrecvmmsg+0x199/0x250 net/socket.c:3041 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83(CVE-2024-57902)

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

net: restrict SO_REUSEPORT to inet sockets

After blamed commit, crypto sockets could accidentally be destroyed from RCU call back, as spotted by zyzbot [1].

Trying to acquire a mutex in RCU callback is not allowed.

Restrict SO_REUSEPORT socket option to inet sockets.

v1 of this patch supported TCP, UDP and SCTP sockets, but fcnal-test.sh test needed RAW and ICMP support.

[1] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:562 inatomic(): 1, irqsdisabled(): 0, nonblock: 0, pid: 24, name: ksoftirqd/1 preemptcount: 100, expected: 0 RCU nest depth: 0, expected: 0 1 lock held by ksoftirqd/1/24: #0: ffffffff8e937ba0 (rcucallback){....}-{0:0}, at: rculockacquire include/linux/rcupdate.h:337 [inline] #0: ffffffff8e937ba0 (rcucallback){....}-{0:0}, at: rcudobatch kernel/rcu/tree.c:2561 [inline] #0: ffffffff8e937ba0 (rcucallback){....}-{0:0}, at: rcucore+0xa37/0x17a0 kernel/rcu/tree.c:2823 Preemption disabled at: [<ffffffff8161c8c8>] softirqhandlebegin kernel/softirq.c:402 [inline] [<ffffffff8161c8c8>] handlesoftirqs+0x128/0x9b0 kernel/softirq.c:537 CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.13.0-rc3-syzkaller-00174-ga024e377efed #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <TASK> _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:120 _mightresched+0x5d4/0x780 kernel/sched/core.c:8758 _mutexlockcommon kernel/locking/mutex.c:562 [inline] _mutexlock+0x131/0xee0 kernel/locking/mutex.c:735 cryptoputdefaultnullskcipher+0x18/0x70 crypto/cryptonull.c:179 aeadrelease+0x3d/0x50 crypto/algifaead.c:489 algdorelease crypto/afalg.c:118 [inline] algsockdestruct+0x86/0xc0 crypto/afalg.c:502 _skdestruct+0x58/0x5f0 net/core/sock.c:2260 rcudobatch kernel/rcu/tree.c:2567 [inline] rcucore+0xaaa/0x17a0 kernel/rcu/tree.c:2823 handlesoftirqs+0x2d4/0x9b0 kernel/softirq.c:561 runksoftirqd+0xca/0x130 kernel/softirq.c:950 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/entry64.S:244 </TASK>(CVE-2024-57903)

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

usb: gadget: ffs: Remove WARNON in functionfs_bind

This commit addresses an issue related to below kernel panic where paniconwarn is enabled. It is caused by the unnecessary use of WARNON in functionsfsbind, which easily leads to the following scenarios.

1.adb_write in adbd 2. UDC write via configfs ================= =====================

->usbffsopenthread() ->UDC write ->openfunctionfs() ->configfswriteiter() ->adbopen() ->gadgetdevdescUDCstore() ->adbwrite() ->usbgadgetregisterdriverowner ->driverregister() ->StartMonitor() ->busadddriver() ->adbread() ->gadgetbinddriver() <times-out without BIND event> ->configfscompositebind() ->usbaddfunction() ->openfunctionfs() ->ffsfuncbind() ->adbopen() ->functionfsbind() <ffs->state !=FFSACTIVE>

The adbopen, adbread, and adbwrite operations are invoked from the daemon, but trying to bind the function is a process that is invoked by UDC write through configfs, which opens up the possibility of a race condition between the two paths. In this race scenario, the kernel panic occurs due to the WARNON from functionfsbind when paniconwarn is enabled. This commit fixes the kernel panic by removing the unnecessary WARNON.

Kernel panic - not syncing: kernel: paniconwarn set ... [ 14.542395] Call trace: [ 14.542464] ffsfuncbind+0x1c8/0x14a8 [ 14.542468] usbaddfunction+0xcc/0x1f0 [ 14.542473] configfscompositebind+0x468/0x588 [ 14.542478] gadgetbinddriver+0x108/0x27c [ 14.542483] reallyprobe+0x190/0x374 [ 14.542488] _driverprobedevice+0xa0/0x12c [ 14.542492] driverprobedevice+0x3c/0x220 [ 14.542498] _driverattach+0x11c/0x1fc [ 14.542502] busforeachdev+0x104/0x160 [ 14.542506] driverattach+0x24/0x34 [ 14.542510] busadddriver+0x154/0x270 [ 14.542514] driverregister+0x68/0x104 [ 14.542518] usbgadgetregisterdriverowner+0x48/0xf4 [ 14.542523] gadgetdevdescUDCstore+0xf8/0x144 [ 14.542526] configfswrite_iter+0xf0/0x138(CVE-2024-57913)

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

net/sctp: Prevent autoclose integer overflow in sctpassociationinit()

While by default maxautoclose equals to INTMAX / HZ, one may set net.sctp.maxautoclose to UINTMAX. There is code in sctpassociationinit() that can consequently trigger overflow.(CVE-2024-57938)

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

riscv: mm: Fix the out of bound issue of vmemmap address

In sparse vmemmap model, the virtual address of vmemmap is calculated as: ((struct page *)VMEMMAPSTART - (physrambase >> PAGESHIFT)). And the struct page's va can be calculated with an offset: (vmemmap + (pfn)).

However, when initializing struct pages, kernel actually starts from the first page from the same section that physrambase belongs to. If the first page's physical address is not (physrambase >> PAGESHIFT), then we get an va below VMEMMAPSTART when calculating va for it's struct page.

For example, if physrambase starts from 0x82000000 with pfn 0x82000, the first page in the same section is actually pfn 0x80000. During initunavailablerange(), we will initialize struct page for pfn 0x80000 with virtual address ((struct page *)VMEMMAPSTART - 0x2000), which is below VMEMMAPSTART as well as PCIIOEND.

This commit fixes this bug by introducing a new variable 'vmemmapstartpfn' which is aligned with memory section size and using it to calculate vmemmap address instead of physrambase.(CVE-2024-57945)

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

rtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read

The nvmem interface supports variable buffer sizes, while the regmap interface operates with fixed-size storage. If an nvmem client uses a buffer size less than 4 bytes, regmap_read will write out of bounds as it expects the buffer to point at an unsigned int.

Fix this by using an intermediary unsigned int to hold the value.(CVE-2024-58069)

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

clk: qcom: dispcc-sm6350: Add missing parent_map for a clock

If a clkrcg2 has a parent, it should also have parentmap defined, otherwise we'll get a NULL pointer dereference when calling clksetrate like the following:

[ 3.388105] Call trace: [ 3.390664] qcomfindsrcindex+0x3c/0x70 (P) [ 3.395301] qcomfindsrcindex+0x1c/0x70 (L) [ 3.399934] freqtbldeterminerate+0x48/0x100 [ 3.404753] clkrcg2determinerate+0x1c/0x28 [ 3.409387] clkcoredetermineroundnolock+0x58/0xe4 [ 3.421414] clkcoreroundratenolock+0x48/0xfc [ 3.432974] clkcoreroundratenolock+0xd0/0xfc [ 3.444483] clkcoresetratenolock+0x8c/0x300 [ 3.455886] clkset_rate+0x38/0x14c

Add the parentmap property for the clock where it's missing and also un-inline the parentdata as well to keep the matching parentmap and parentdata together.(CVE-2024-58080)

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

ksmbd: fix racy issue from session lookup and expire

Increment the session reference count within the lock for lookup to avoid racy issue with session expire.(CVE-2024-58087)

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

net: reenable NETIFFIPV6_CSUM offload for BIG TCP packets

The blamed commit disabled hardware offoad of IPv6 packets with extension headers on devices that advertise NETIFFIPV6_CSUM, based on the definition of that feature in skbuff.h:

* * - %NETIFFIPV6CSUM * - Driver (device) is only able to checksum plain * TCP or UDP packets over IPv6. These are specifically * unencapsulated packets of the form IPv6|TCP or * IPv6|UDP where the Next Header field in the IPv6 * header is either TCP or UDP. IPv6 extension headers * are not supported with this feature. This feature * cannot be set in features for a device with * NETIFFHWCSUM also set. This feature is being * DEPRECATED (see below).

The change causes skbwarnbad_offload to fire for BIG TCP packets.

[ 496.310233] WARNING: CPU: 13 PID: 23472 at net/core/dev.c:3129 skbwarnbad_offload+0xc4/0xe0

[ 496.310297] ? skbwarnbadoffload+0xc4/0xe0 [ 496.310300] skbchecksumhelp+0x129/0x1f0 [ 496.310303] skbcsumhwoffloadhelp+0x150/0x1b0 [ 496.310306] validatexmitskb+0x159/0x270 [ 496.310309] validatexmitskblist+0x41/0x70 [ 496.310312] schdirectxmit+0x5c/0x250 [ 496.310317] _qdisc_run+0x388/0x620

BIG TCP introduced an IPV6TLVJUMBO IPv6 extension header to communicate packet length, as this is an IPv6 jumbogram. But, the feature is only enabled on devices that support BIG TCP TSO. The header is only present for PF_PACKET taps like tcpdump, and not transmitted by physical devices.

For this specific case of extension headers that are not transmitted, return to the situation before the blamed commit and support hardware offload.

ipv6hashopopt_jumbo() tests not only whether this header is present, but also that it is the only extension header before a terminal (L4) header.(CVE-2025-21629)

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

sctp: sysctl: rto_min/max: avoid using current->nsproxy

As mentioned in a previous commit of this series, using the 'net' structure via 'current' is not recommended for different reasons:

• Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.

• current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).

The 'net' structure can be obtained from the table->data using container_of().

Note that table->data could also be used directly, as this is the only member needed from the 'net' structure, but that would increase the size of this fix, to use '*data' everywhere 'net->sctp.rto_min/max' is used.(CVE-2025-21639)

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

mptcp: sysctl: sched: avoid using current->nsproxy

Using the 'net' structure via 'current' is not recommended for different reasons.

First, if the goal is to use it to read or write per-netns data, this is inconsistent with how the "generic" sysctl entries are doing: directly by only using pointers set to the table entry, e.g. table->data. Linked to that, the per-netns data should always be obtained from the table linked to the netns it had been created for, which may not coincide with the reader's or writer's netns.

Another reason is that access to current->nsproxy->netns can oops if attempted when current->nsproxy had been dropped when the current task is exiting. This is what syzbot found, when using acct(2):

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] CPU: 1 UID: 0 PID: 5924 Comm: syz-executor Not tainted 6.13.0-rc5-syzkaller-00004-gccb98ccef0e5 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:proc_scheduler+0xc6/0x3c0 net/mptcp/ctrl.c:125 Code: 03 42 80 3c 38 00 0f 85 fe 02 00 00 4d 8b a4 24 08 09 00 00 48 b8 00 00 00 00 00 fc ff df 49 8d 7c 24 28 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 cc 02 00 00 4d 8b 7c 24 28 48 8d 84 24 c8 00 00 RSP: 0018:ffffc900034774e8 EFLAGS: 00010206

RAX: dffffc0000000000 RBX: 1ffff9200068ee9e RCX: ffffc90003477620 RDX: 0000000000000005 RSI: ffffffff8b08f91e RDI: 0000000000000028 RBP: 0000000000000001 R08: ffffc90003477710 R09: 0000000000000040 R10: 0000000000000040 R11: 00000000726f7475 R12: 0000000000000000 R13: ffffc90003477620 R14: ffffc90003477710 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fee3cd452d8 CR3: 000000007d116000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> procsyscallhandler+0x403/0x5d0 fs/proc/procsysctl.c:601 _kernelwriteiter+0x318/0xa80 fs/readwrite.c:612 _kernelwrite+0xf6/0x140 fs/readwrite.c:632 doacctprocess+0xcb0/0x14a0 kernel/acct.c:539 acctpinkill+0x2d/0x100 kernel/acct.c:192 pinkill+0x194/0x7c0 fs/fspin.c:44 mntpinkill+0x61/0x1e0 fs/fspin.c:81 cleanupmnt+0x3ac/0x450 fs/namespace.c:1366 taskworkrun+0x14e/0x250 kernel/taskwork.c:239 exittaskwork include/linux/taskwork.h:43 [inline] doexit+0xad8/0x2d70 kernel/exit.c:938 dogroupexit+0xd3/0x2a0 kernel/exit.c:1087 getsignal+0x2576/0x2610 kernel/signal.c:3017 archdosignalorrestart+0x90/0x7e0 arch/x86/kernel/signal.c:337 exittousermodeloop kernel/entry/common.c:111 [inline] exittousermodeprepare include/linux/entry-common.h:329 [inline] _syscallexittousermodework kernel/entry/common.c:207 [inline] syscallexittousermode+0x150/0x2a0 kernel/entry/common.c:218 dosyscall64+0xda/0x250 arch/x86/entry/common.c:89 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7fee3cb87a6a Code: Unable to access opcode bytes at 0x7fee3cb87a40. RSP: 002b:00007fffcccac688 EFLAGS: 00000202 ORIGRAX: 0000000000000037 RAX: 0000000000000000 RBX: 00007fffcccac710 RCX: 00007fee3cb87a6a RDX: 0000000000000041 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 0000000000000003 R08: 00007fffcccac6ac R09: 00007fffcccacac7 R10: 00007fffcccac710 R11: 0000000000000202 R12: 00007fee3cd49500 R13: 00007fffcccac6ac R14: 0000000000000000 R15: 00007fee3cd4b000 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:proc_scheduler+0xc6/0x3c0 net/mptcp/ctrl.c:125 Code: 03 42 80 3c 38 00 0f 85 fe 02 00 00 4d 8b a4 24 08 09 00 00 48 b8 00 00 00 00 00 fc ---truncated---(CVE-2025-21642)

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

afs: Fix the maximum cell name length

The kafs filesystem limits the maximum length of a cell to 256 bytes, but a problem occurs if someone actually does that: kafs tries to create a directory under /proc/net/afs/ with the name of the cell, but that fails with a warning:

    WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:405

because procfs limits the maximum filename length to 255.

However, the DNS limits the maximum lookup length and, by extension, the maximum cell name, to 255 less two (length count and trailing NUL).

Fix this by limiting the maximum acceptable cellname length to 253. This also allows us to be sure we can create the "/afs/.<cell>/" mountpoint too.

Further, split the YFS VL record cell name maximum to be the 256 allowed by the protocol and ignore the record retrieved by YFSVL.GetCellName if it exceeds 253.(CVE-2025-21646)

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

ovl: support encoding fid from inode with no alias

Dmitry Safonov reported that a WARNON() assertion can be trigered by userspace when calling inotifyshowfdinfo() for an overlayfs watched inode, whose dentry aliases were discarded with dropcaches.

The WARNON() assertion in inotifyshow_fdinfo() was removed, because it is possible for encoding file handle to fail for other reason, but the impact of failing to encode an overlayfs file handle goes beyond this assertion.

As shown in the LTP test case mentioned in the link below, failure to encode an overlayfs file handle from a non-aliased inode also leads to failure to report an fid with FANDELETESELF fanotify events.

As Dmitry notes in his analyzis of the problem, ovlencodefh() fails if it cannot find an alias for the inode, but this failure can be fixed. ovlencodefh() seldom uses the alias and in the case of non-decodable file handles, as is often the case with fanotify fid info, ovlencodefh() never needs to use the alias to encode a file handle.

Defer finding an alias until it is actually needed so ovlencodefh() will not fail in the common case of FANDELETESELF fanotify events.(CVE-2025-21654)

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

iouring/eventfd: ensure ioeventfd_signal() defers another RCU period

ioeventfddosignal() is invoked from an RCU callback, but when dropping the reference to the ioevfd, it calls ioeventfdfree() directly if the refcount drops to zero. This isn't correct, as any potential freeing of the ioev_fd should be deferred another RCU grace period.

Just call ioeventfdput() rather than open-code the dec-and-test and free, which will correctly defer it another RCU grace period.(CVE-2025-21655)

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

ksmbd: fix unexpectedly changed path in ksmbdvfskernpathlocked

When ksmbd_vfs_kern_path_locked met an error and it is not the last entry, it will exit without restoring changed path buffer. But later this buffer may be used as the filename for creation.(CVE-2025-21660)

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

net/mlx5: Fix variable not being completed when function returns

When cmdallocindex(), fails cmdworkhandler() needs to complete ent->slotted before returning early. Otherwise the task which issued the command may hang:

mlx5core 0000:01:00.0: cmdworkhandler:877:(pid 3880418): failed to allocate command entry INFO: task kworker/13:2:4055883 blocked for more than 120 seconds. Not tainted 4.19.90-25.44.v2101.ky10.aarch64 #1 "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. kworker/13:2 D 0 4055883 2 0x00000228 Workqueue: events mlx5etxdimwork [mlx5core] Call trace: _switchto+0xe8/0x150 _schedule+0x2a8/0x9b8 schedule+0x2c/0x88 scheduletimeout+0x204/0x478 waitforcommon+0x154/0x250 waitforcompletion+0x28/0x38 cmdexec+0x7a0/0xa00 [mlx5core] mlx5cmdexec+0x54/0x80 [mlx5core] mlx5coremodifycq+0x6c/0x80 [mlx5core] mlx5coremodifycqmoderation+0xa0/0xb8 [mlx5core] mlx5etxdimwork+0x54/0x68 [mlx5core] processonework+0x1b0/0x448 workerthread+0x54/0x468 kthread+0x134/0x138 retfrom_fork+0x10/0x18(CVE-2025-21662)

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

net: stmmac: dwmac-tegra: Read iommu stream id from device tree

Nvidia's Tegra MGBE controllers require the IOMMU "Stream ID" (SID) to be written to the MGBEWRAPAXIASID0CTRL register.

The current driver is hard coded to use MGBE0's SID for all controllers. This causes softirq time outs and kernel panics when using controllers other than MGBE0.

Example dmesg errors when an ethernet cable is connected to MGBE1:

[ 116.133290] tegra-mgbe 6910000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx [ 121.851283] tegra-mgbe 6910000.ethernet eth1: NETDEV WATCHDOG: CPU: 5: transmit queue 0 timed out 5690 ms [ 121.851782] tegra-mgbe 6910000.ethernet eth1: Reset adapter. [ 121.892464] tegra-mgbe 6910000.ethernet eth1: Register MEMTYPEPAGEPOOL RxQ-0 [ 121.905920] tegra-mgbe 6910000.ethernet eth1: PHY [stmmac-1:00] driver [Aquantia AQR113] (irq=171) [ 121.907356] tegra-mgbe 6910000.ethernet eth1: Enabling Safety Features [ 121.907578] tegra-mgbe 6910000.ethernet eth1: IEEE 1588-2008 Advanced Timestamp supported [ 121.908399] tegra-mgbe 6910000.ethernet eth1: registered PTP clock [ 121.908582] tegra-mgbe 6910000.ethernet eth1: configuring for phy/10gbase-r link mode [ 125.961292] tegra-mgbe 6910000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx [ 181.921198] rcu: INFO: rcupreempt detected stalls on CPUs/tasks: [ 181.921404] rcu: 7-....: (1 GPs behind) idle=540c/1/0x4000000000000002 softirq=1748/1749 fqs=2337 [ 181.921684] rcu: (detected by 4, t=6002 jiffies, g=1357, q=1254 ncpus=8) [ 181.921878] Sending NMI from CPU 4 to CPUs 7: [ 181.921886] NMI backtrace for cpu 7 [ 181.922131] CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Kdump: loaded Not tainted 6.13.0-rc3+ #6 [ 181.922390] Hardware name: NVIDIA CTI Forge + Orin AGX/Jetson, BIOS 202402.1-Unknown 10/28/2024 [ 181.922658] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 181.922847] pc : handlesoftirqs+0x98/0x368 [ 181.922978] lr : dosoftirq+0x18/0x20 [ 181.923095] sp : ffff80008003bf50 [ 181.923189] x29: ffff80008003bf50 x28: 0000000000000008 x27: 0000000000000000 [ 181.923379] x26: ffffce78ea277000 x25: 0000000000000000 x24: 0000001c61befda0 [ 181.924486] x23: 0000000060400009 x22: ffffce78e99918bc x21: ffff80008018bd70 [ 181.925568] x20: ffffce78e8bb00d8 x19: ffff80008018bc20 x18: 0000000000000000 [ 181.926655] x17: ffff318ebe7d3000 x16: ffff800080038000 x15: 0000000000000000 [ 181.931455] x14: ffff000080816680 x13: ffff318ebe7d3000 x12: 000000003464d91d [ 181.938628] x11: 0000000000000040 x10: ffff000080165a70 x9 : ffffce78e8bb0160 [ 181.945804] x8 : ffff8000827b3160 x7 : f9157b241586f343 x6 : eeb6502a01c81c74 [ 181.953068] x5 : a4acfcdd2e8096bb x4 : ffffce78ea277340 x3 : 00000000ffffd1e1 [ 181.960329] x2 : 0000000000000101 x1 : ffffce78ea277340 x0 : ffff318ebe7d3000 [ 181.967591] Call trace: [ 181.970043] handlesoftirqs+0x98/0x368 (P) [ 181.974240] _dosoftirq+0x18/0x20 [ 181.977743] _dosoftirq+0x14/0x28 [ 181.981415] callonirqstack+0x24/0x30 [ 181.985180] dosoftirqownstack+0x20/0x30 [ 181.989379] _irqexitrcu+0x114/0x140 [ 181.993142] irqexitrcu+0x14/0x28 [ 181.996816] el1interrupt+0x44/0xb8 [ 182.000316] el1h64irqhandler+0x14/0x20 [ 182.004343] el1h64irq+0x80/0x88 [ 182.007755] cpuidleenterstate+0xc4/0x4a8 (P) [ 182.012305] cpuidleenter+0x3c/0x58 [ 182.015980] cpuidleidlecall+0x128/0x1c0 [ 182.020005] doidle+0xe0/0xf0 [ 182.023155] cpustartupentry+0x3c/0x48 [ 182.026917] secondarystartkernel+0xdc/0x120 [ 182.031379] _secondaryswitched+0x74/0x78 [ 212.971162] rcu: INFO: rcupreempt detected expedited stalls on CPUs/tasks: { 7-.... } 6103 jiffies s: 417 root: 0x80/. [ 212.985935] rcu: blocking rcunode structures (internal RCU debug): [ 212.992758] Sending NMI from CPU 0 to CPUs 7: [ 212.998539] NMI backtrace for cpu 7 [ 213.004304] CPU: 7 UID: 0 PI ---truncated---(CVE-2025-21663)

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

dm thin: make getfirstthin use rcu-safe list first function

The documentation in rculist.h explains the absence of listemptyrcu() and cautions programmers against relying on a listempty() -> listfirst() sequence in RCU safe code. This is because each of these functions performs its own READONCE() of the list head. This can lead to a situation where the listempty() sees a valid list entry, but the subsequent list_first() sees a different view of list head state after a modification.

In the case of dm-thin, this author had a production box crash from a GP fault in the processdeferredbios path. This function saw a valid list head in getfirstthin() but when it subsequently dereferenced that and turned it into a thinc, it got the inside of the struct pool, since the list was now empty and referring to itself. The kernel on which this occurred printed both a warning about a refcountt being saturated, and a UBSAN error for an out-of-bounds cpuid access in the queued spinlock, prior to the fault itself. When the resulting kdump was examined, it was possible to see another thread patiently waiting in thindtr's synchronizercu.

The thindtr call managed to pull the thinc out of the active thins list (and have it be the last entry in the active_thins list) at just the wrong moment which lead to this crash.

Fortunately, the fix here is straight forward. Switch getfirstthin() function to use listfirstornullrcu() which performs just a single READ_ONCE() and returns NULL if the list is already empty.

This was run against the devicemapper test suite's thin-provisioning suites for delete and suspend and no regressions were observed.(CVE-2025-21664)

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

ipmr: do not call mrmfcuses_dev() for unres entries

syzbot found that calling mrmfcusesdev() for unres entries would crash [1], because c->mfcun.res.minvif / c->mfcun.res.maxvif alias to "struct skbuff_head unresolved", which contain two pointers.

This code never worked, lets remove it.

[1] Unable to handle kernel paging request at virtual address ffff5fff2d536613 KASAN: maybe wild-memory-access in range [0xfffefff96a9b3098-0xfffefff96a9b309f] Modules linked in: CPU: 1 UID: 0 PID: 7321 Comm: syz.0.16 Not tainted 6.13.0-rc7-syzkaller-g1950a0af2d55 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mrmfcusesdev net/ipv4/ipmrbase.c:290 [inline] pc : mrtabledump+0x5a4/0x8b0 net/ipv4/ipmrbase.c:334 lr : mrmfcusesdev net/ipv4/ipmrbase.c:289 [inline] lr : mrtabledump+0x694/0x8b0 net/ipv4/ipmrbase.c:334 Call trace: mrmfcusesdev net/ipv4/ipmrbase.c:290 [inline] (P) mrtabledump+0x5a4/0x8b0 net/ipv4/ipmrbase.c:334 (P) mrrtmdumproute+0x254/0x454 net/ipv4/ipmrbase.c:382 ipmrrtmdumproute+0x248/0x4b4 net/ipv4/ipmr.c:2648 rtnldumpall+0x2e4/0x4e8 net/core/rtnetlink.c:4327 rtnldumpit+0x98/0x1d0 net/core/rtnetlink.c:6791 netlinkdump+0x4f0/0xbc0 net/netlink/afnetlink.c:2317 netlinkrecvmsg+0x56c/0xe64 net/netlink/afnetlink.c:1973 sockrecvmsgnosec net/socket.c:1033 [inline] sockrecvmsg net/socket.c:1055 [inline] sockreaditer+0x2d8/0x40c net/socket.c:1125 newsyncread fs/readwrite.c:484 [inline] vfsread+0x740/0x970 fs/readwrite.c:565 ksysread+0x15c/0x26c fs/read_write.c:708(CVE-2025-21719)

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

wifi: brcmfmac: Check the return value of ofpropertyreadstringindex()

Somewhen between 6.10 and 6.11 the driver started to crash on my MacBookPro14,3. The property doesn't exist and 'tmp' remains uninitialized, so we pass a random pointer to devm_kstrdup().

The crash I am getting looks like this:

BUG: unable to handle page fault for address: 00007f033c669379 PF: supervisor read access in kernel mode PF: errorcode(0x0001) - permissions violation PGD 8000000101341067 P4D 8000000101341067 PUD 101340067 PMD 1013bb067 PTE 800000010aee9025 Oops: Oops: 0001 [#1] SMP PTI CPU: 4 UID: 0 PID: 827 Comm: (udev-worker) Not tainted 6.11.8-gentoo #1 Hardware name: Apple Inc. MacBookPro14,3/Mac-551B86E5744E2388, BIOS 529.140.2.0.0 06/23/2024 RIP: 0010:strlen+0x4/0x30 Code: f7 75 ec 31 c0 c3 cc cc cc cc 48 89 f8 c3 cc cc cc cc 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa <80> 3f 00 74 14 48 89 f8 48 83 c0 01 80 38 00 75 f7 48 29 f8 c3 cc RSP: 0018:ffffb4aac0683ad8 EFLAGS: 00010202 RAX: 00000000ffffffea RBX: 00007f033c669379 RCX: 0000000000000001 RDX: 0000000000000cc0 RSI: 00007f033c669379 RDI: 00007f033c669379 RBP: 00000000ffffffea R08: 0000000000000000 R09: 00000000c0ba916a R10: ffffffffffffffff R11: ffffffffb61ea260 R12: ffff91f7815b50c8 R13: 0000000000000cc0 R14: ffff91fafefffe30 R15: ffffb4aac0683b30 FS: 00007f033ccbe8c0(0000) GS:ffff91faeed00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f033c669379 CR3: 0000000107b1e004 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? _die+0x23/0x70 ? pagefaultoops+0x149/0x4c0 ? rawspinrqlocknested+0xe/0x20 ? schedbalancenewidle+0x22b/0x3c0 ? updateloadavg+0x78/0x770 ? excpagefault+0x6f/0x150 ? asmexcpagefault+0x26/0x30 ? _pfxpciconf1write+0x10/0x10 ? strlen+0x4/0x30 devmkstrdup+0x25/0x70 brcmfofprobe+0x273/0x350 brcmfmac