{"schema_version":"1.7.2","id":"OESA-2025-1320","modified":"2025-03-21T13:18:56Z","published":"2025-03-21T13:18:56Z","upstream":["CVE-2024-36476","CVE-2024-56778","CVE-2024-57802","CVE-2024-57834","CVE-2024-57883","CVE-2024-57884","CVE-2024-57885","CVE-2024-57890","CVE-2024-57894","CVE-2024-57897","CVE-2024-57901","CVE-2024-57902","CVE-2024-57903","CVE-2024-57913","CVE-2024-57938","CVE-2024-57945","CVE-2024-58069","CVE-2024-58080","CVE-2024-58087","CVE-2025-21629","CVE-2025-21639","CVE-2025-21642","CVE-2025-21646","CVE-2025-21654","CVE-2025-21655","CVE-2025-21660","CVE-2025-21662","CVE-2025-21663","CVE-2025-21664","CVE-2025-21719","CVE-2025-21750"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rtrs: Ensure \u0026apos;ib_sge list\u0026apos; is accessible\n\nMove the declaration of the \u0026apos;ib_sge list\u0026apos; variable outside the\n\u0026apos;always_invalidate\u0026apos; block to ensure it remains accessible for use\nthroughout the function.\n\nPreviously, \u0026apos;ib_sge list\u0026apos; was declared within the \u0026apos;always_invalidate\u0026apos;\nblock, limiting its accessibility, then caused a\n\u0026apos;BUG: kernel NULL pointer dereference\u0026apos;[1].\n ? __die_body.cold+0x19/0x27\n ? page_fault_oops+0x15a/0x2d0\n ? search_module_extables+0x19/0x60\n ? search_bpf_extables+0x5f/0x80\n ? exc_page_fault+0x7e/0x180\n ? asm_exc_page_fault+0x26/0x30\n ? memcpy_orig+0xd5/0x140\n rxe_mr_copy+0x1c3/0x200 [rdma_rxe]\n ? rxe_pool_get_index+0x4b/0x80 [rdma_rxe]\n copy_data+0xa5/0x230 [rdma_rxe]\n rxe_requester+0xd9b/0xf70 [rdma_rxe]\n ? finish_task_switch.isra.0+0x99/0x2e0\n rxe_sender+0x13/0x40 [rdma_rxe]\n do_task+0x68/0x1e0 [rdma_rxe]\n process_one_work+0x177/0x330\n worker_thread+0x252/0x390\n ? __pfx_worker_thread+0x10/0x10\n\nThis change ensures the variable is available for subsequent operations\nthat require it.\n\n[1] https://lore.kernel.org/linux-rdma/6a1f3e8f-deb0-49f9-bc69-a9b03ecfcda7@fujitsu.com/(CVE-2024-36476)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/sti: avoid potential dereference of error pointers in sti_hqvdp_atomic_check\n\nThe return value of drm_atomic_get_crtc_state() needs to be\nchecked. To avoid use of error pointer \u0026apos;crtc_state\u0026apos; in case\nof the failure.(CVE-2024-56778)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetrom: check buffer length before accessing it\n\nSyzkaller reports an uninit value read from ax25cmp when sending raw message\nthrough ieee802154 implementation.\n\n=====================================================\nBUG: KMSAN: uninit-value in ax25cmp+0x3a5/0x460 net/ax25/ax25_addr.c:119\n ax25cmp+0x3a5/0x460 net/ax25/ax25_addr.c:119\n nr_dev_get+0x20e/0x450 net/netrom/nr_route.c:601\n nr_route_frame+0x1a2/0xfc0 net/netrom/nr_route.c:774\n nr_xmit+0x5a/0x1c0 net/netrom/nr_dev.c:144\n __netdev_start_xmit include/linux/netdevice.h:4940 [inline]\n netdev_start_xmit include/linux/netdevice.h:4954 [inline]\n xmit_one net/core/dev.c:3548 [inline]\n dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564\n __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349\n dev_queue_xmit include/linux/netdevice.h:3134 [inline]\n raw_sendmsg+0x654/0xc10 net/ieee802154/socket.c:299\n ieee802154_sock_sendmsg+0x91/0xc0 net/ieee802154/socket.c:96\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638\n __sys_sendmsg net/socket.c:2667 [inline]\n __do_sys_sendmsg net/socket.c:2676 [inline]\n __se_sys_sendmsg net/socket.c:2674 [inline]\n __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\n\nUninit was created at:\n slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768\n slab_alloc_node mm/slub.c:3478 [inline]\n kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523\n kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560\n __alloc_skb+0x318/0x740 net/core/skbuff.c:651\n alloc_skb include/linux/skbuff.h:1286 [inline]\n alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334\n sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2780\n sock_alloc_send_skb include/net/sock.h:1884 [inline]\n raw_sendmsg+0x36d/0xc10 net/ieee802154/socket.c:282\n ieee802154_sock_sendmsg+0x91/0xc0 net/ieee802154/socket.c:96\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638\n __sys_sendmsg net/socket.c:2667 [inline]\n __do_sys_sendmsg net/socket.c:2676 [inline]\n __se_sys_sendmsg net/socket.c:2674 [inline]\n __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\n\nCPU: 0 PID: 5037 Comm: syz-executor166 Not tainted 6.7.0-rc7-syzkaller-00003-gfbafc3e621c3 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023\n=====================================================\n\nThis issue occurs because the skb buffer is too small, and it\u0026apos;s actual\nallocation is aligned. This hides an actual issue, which is that nr_route_frame\ndoes not validate the buffer size before using it.\n\nFix this issue by checking skb-\u0026gt;len before accessing any fields in skb-\u0026gt;data.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2024-57802)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: vidtv: Fix a null-ptr-deref in vidtv_mux_stop_thread\n\nsyzbot report a null-ptr-deref in vidtv_mux_stop_thread. [1]\n\nIf dvb-\u0026gt;mux is not initialized successfully by vidtv_mux_init() in the\nvidtv_start_streaming(), it will trigger null pointer dereference about mux\nin vidtv_mux_stop_thread().\n\nAdjust the timing of streaming initialization and check it before\nstopping it.\n\n[1]\nKASAN: null-ptr-deref in range [0x0000000000000128-0x000000000000012f]\nCPU: 0 UID: 0 PID: 5842 Comm: syz-executor248 Not tainted 6.13.0-rc4-syzkaller-00012-g9b2ffa6148b1 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nRIP: 0010:vidtv_mux_stop_thread+0x26/0x80 drivers/media/test-drivers/vidtv/vidtv_mux.c:471\nCode: 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 \u0026lt;0f\u0026gt; b6 04 02 84 c0 74 02 7e 3b 0f b6 ab 28 01 00 00 31 ff 89 ee e8\nRSP: 0018:ffffc90003f2faa8 EFLAGS: 00010202\nRAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff87cfb125\nRDX: 0000000000000025 RSI: ffffffff87d120ce RDI: 0000000000000128\nRBP: ffff888029b8d220 R08: 0000000000000005 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000003 R12: ffff888029b8d188\nR13: ffffffff8f590aa0 R14: ffffc9000581c5c8 R15: ffff888029a17710\nFS:  00007f7eef5156c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f7eef5e635c CR3: 0000000076ca6000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n vidtv_stop_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:209 [inline]\n vidtv_stop_feed+0x151/0x250 drivers/media/test-drivers/vidtv/vidtv_bridge.c:252\n dmx_section_feed_stop_filtering+0x90/0x160 drivers/media/dvb-core/dvb_demux.c:1000\n dvb_dmxdev_feed_stop.isra.0+0x1ee/0x270 drivers/media/dvb-core/dmxdev.c:486\n dvb_dmxdev_filter_stop+0x22a/0x3a0 drivers/media/dvb-core/dmxdev.c:559\n dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline]\n dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246\n __fput+0x3f8/0xb60 fs/file_table.c:450\n task_work_run+0x14e/0x250 kernel/task_work.c:239\n get_signal+0x1d3/0x2610 kernel/signal.c:2790\n arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337\n exit_to_user_mode_loop kernel/entry/common.c:111 [inline]\n exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline]\n __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]\n syscall_exit_to_user_mode+0x150/0x2a0 kernel/entry/common.c:218\n do_syscall_64+0xda/0x250 arch/x86/entry/common.c:89\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-57834)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: hugetlb: independent PMD page table shared count\n\nThe folio refcount may be increased unexpectly through try_get_folio() by\ncaller such as split_huge_pages.  In huge_pmd_unshare(), we use refcount\nto check whether a pmd page table is shared.  The check is incorrect if\nthe refcount is increased by the above caller, and this can cause the page\ntable leaked:\n\n BUG: Bad page state in process sh  pfn:109324\n page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x66 pfn:0x109324\n flags: 0x17ffff800000000(node=0|zone=2|lastcpupid=0xfffff)\n page_type: f2(table)\n raw: 017ffff800000000 0000000000000000 0000000000000000 0000000000000000\n raw: 0000000000000066 0000000000000000 00000000f2000000 0000000000000000\n page dumped because: nonzero mapcount\n ...\n CPU: 31 UID: 0 PID: 7515 Comm: sh Kdump: loaded Tainted: G    B              6.13.0-rc2master+ #7\n Tainted: [B]=BAD_PAGE\n Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015\n Call trace:\n  show_stack+0x20/0x38 (C)\n  dump_stack_lvl+0x80/0xf8\n  dump_stack+0x18/0x28\n  bad_page+0x8c/0x130\n  free_page_is_bad_report+0xa4/0xb0\n  free_unref_page+0x3cc/0x620\n  __folio_put+0xf4/0x158\n  split_huge_pages_all+0x1e0/0x3e8\n  split_huge_pages_write+0x25c/0x2d8\n  full_proxy_write+0x64/0xd8\n  vfs_write+0xcc/0x280\n  ksys_write+0x70/0x110\n  __arm64_sys_write+0x24/0x38\n  invoke_syscall+0x50/0x120\n  el0_svc_common.constprop.0+0xc8/0xf0\n  do_el0_svc+0x24/0x38\n  el0_svc+0x34/0x128\n  el0t_64_sync_handler+0xc8/0xd0\n  el0t_64_sync+0x190/0x198\n\nThe issue may be triggered by damon, offline_page, page_idle, etc, which\nwill increase the refcount of page table.\n\n1. The page table itself will be discarded after reporting the\n   \u0026quot;nonzero mapcount\u0026quot;.\n\n2. The HugeTLB page mapped by the page table miss freeing since we\n   treat the page table as shared and a shared page table will not be\n   unmapped.\n\nFix it by introducing independent PMD page table shared count.  As\ndescribed by comment, pt_index/pt_mm/pt_frag_refcount are used for s390\ngmap, x86 pgds and powerpc, pt_share_count is used for x86/arm64/riscv\npmds, so we can reuse the field as pt_share_count.(CVE-2024-57883)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: vmscan: account for free pages to prevent infinite Loop in throttle_direct_reclaim()\n\nThe task sometimes continues looping in throttle_direct_reclaim() because\nallow_direct_reclaim(pgdat) keeps returning false.  \n\n #0 [ffff80002cb6f8d0] __switch_to at ffff8000080095ac\n #1 [ffff80002cb6f900] __schedule at ffff800008abbd1c\n #2 [ffff80002cb6f990] schedule at ffff800008abc50c\n #3 [ffff80002cb6f9b0] throttle_direct_reclaim at ffff800008273550\n #4 [ffff80002cb6fa20] try_to_free_pages at ffff800008277b68\n #5 [ffff80002cb6fae0] __alloc_pages_nodemask at ffff8000082c4660\n #6 [ffff80002cb6fc50] alloc_pages_vma at ffff8000082e4a98\n #7 [ffff80002cb6fca0] do_anonymous_page at ffff80000829f5a8\n #8 [ffff80002cb6fce0] __handle_mm_fault at ffff8000082a5974\n #9 [ffff80002cb6fd90] handle_mm_fault at ffff8000082a5bd4\n\nAt this point, the pgdat contains the following two zones:\n\n        NODE: 4  ZONE: 0  ADDR: ffff00817fffe540  NAME: \u0026quot;DMA32\u0026quot;\n          SIZE: 20480  MIN/LOW/HIGH: 11/28/45\n          VM_STAT:\n                NR_FREE_PAGES: 359\n        NR_ZONE_INACTIVE_ANON: 18813\n          NR_ZONE_ACTIVE_ANON: 0\n        NR_ZONE_INACTIVE_FILE: 50\n          NR_ZONE_ACTIVE_FILE: 0\n          NR_ZONE_UNEVICTABLE: 0\n        NR_ZONE_WRITE_PENDING: 0\n                     NR_MLOCK: 0\n                    NR_BOUNCE: 0\n                   NR_ZSPAGES: 0\n            NR_FREE_CMA_PAGES: 0\n\n        NODE: 4  ZONE: 1  ADDR: ffff00817fffec00  NAME: \u0026quot;Normal\u0026quot;\n          SIZE: 8454144  PRESENT: 98304  MIN/LOW/HIGH: 68/166/264\n          VM_STAT:\n                NR_FREE_PAGES: 146\n        NR_ZONE_INACTIVE_ANON: 94668\n          NR_ZONE_ACTIVE_ANON: 3\n        NR_ZONE_INACTIVE_FILE: 735\n          NR_ZONE_ACTIVE_FILE: 78\n          NR_ZONE_UNEVICTABLE: 0\n        NR_ZONE_WRITE_PENDING: 0\n                     NR_MLOCK: 0\n                    NR_BOUNCE: 0\n                   NR_ZSPAGES: 0\n            NR_FREE_CMA_PAGES: 0\n\nIn allow_direct_reclaim(), while processing ZONE_DMA32, the sum of\ninactive/active file-backed pages calculated in zone_reclaimable_pages()\nbased on the result of zone_page_state_snapshot() is zero.  \n\nAdditionally, since this system lacks swap, the calculation of inactive/\nactive anonymous pages is skipped.\n\n        crash\u0026gt; p nr_swap_pages\n        nr_swap_pages = $1937 = {\n          counter = 0\n        }\n\nAs a result, ZONE_DMA32 is deemed unreclaimable and skipped, moving on to\nthe processing of the next zone, ZONE_NORMAL, despite ZONE_DMA32 having\nfree pages significantly exceeding the high watermark.\n\nThe problem is that the pgdat-\u0026gt;kswapd_failures hasn\u0026apos;t been incremented.\n\n        crash\u0026gt; px ((struct pglist_data *) 0xffff00817fffe540)-\u0026gt;kswapd_failures\n        $1935 = 0x0\n\nThis is because the node deemed balanced.  The node balancing logic in\nbalance_pgdat() evaluates all zones collectively.  If one or more zones\n(e.g., ZONE_DMA32) have enough free pages to meet their watermarks, the\nentire node is deemed balanced.  This causes balance_pgdat() to exit early\nbefore incrementing the kswapd_failures, as it considers the overall\nmemory state acceptable, even though some zones (like ZONE_NORMAL) remain\nunder significant pressure.\n\n\nThe patch ensures that zone_reclaimable_pages() includes free pages\n(NR_FREE_PAGES) in its calculation when no other reclaimable pages are\navailable (e.g., file-backed or anonymous pages).  This change prevents\nzones like ZONE_DMA32, which have sufficient free pages, from being\nmistakenly deemed unreclaimable.  By doing so, the patch ensures proper\nnode balancing, avoids masking pressure on other zones like ZONE_NORMAL,\nand prevents infinite loops in throttle_direct_reclaim() caused by\nallow_direct_reclaim(pgdat) repeatedly returning false.\n\n\nThe kernel hangs due to a task stuck in throttle_direct_reclaim(), caused\nby a node being incorrectly deemed balanced despite pressure in certain\nzones, such as ZONE_NORMAL.  This issue arises from\nzone_reclaimable_pages\n---truncated---(CVE-2024-57884)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/kmemleak: fix sleeping function called from invalid context at print message\n\nAddress a bug in the kernel that triggers a \u0026quot;sleeping function called from\ninvalid context\u0026quot; warning when /sys/kernel/debug/kmemleak is printed under\nspecific conditions:\n- CONFIG_PREEMPT_RT=y\n- Set SELinux as the LSM for the system\n- Set kptr_restrict to 1\n- kmemleak buffer contains at least one item\n\nBUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48\nin_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 136, name: cat\npreempt_count: 1, expected: 0\nRCU nest depth: 2, expected: 2\n6 locks held by cat/136:\n #0: ffff32e64bcbf950 (\u0026amp;p-\u0026gt;lock){+.+.}-{3:3}, at: seq_read_iter+0xb8/0xe30\n #1: ffffafe6aaa9dea0 (scan_mutex){+.+.}-{3:3}, at: kmemleak_seq_start+0x34/0x128\n #3: ffff32e6546b1cd0 (\u0026amp;object-\u0026gt;lock){....}-{2:2}, at: kmemleak_seq_show+0x3c/0x1e0\n #4: ffffafe6aa8d8560 (rcu_read_lock){....}-{1:2}, at: has_ns_capability_noaudit+0x8/0x1b0\n #5: ffffafe6aabbc0f8 (notif_lock){+.+.}-{2:2}, at: avc_compute_av+0xc4/0x3d0\nirq event stamp: 136660\nhardirqs last  enabled at (136659): [\u0026lt;ffffafe6a80fd7a0\u0026gt;] _raw_spin_unlock_irqrestore+0xa8/0xd8\nhardirqs last disabled at (136660): [\u0026lt;ffffafe6a80fd85c\u0026gt;] _raw_spin_lock_irqsave+0x8c/0xb0\nsoftirqs last  enabled at (0): [\u0026lt;ffffafe6a5d50b28\u0026gt;] copy_process+0x11d8/0x3df8\nsoftirqs last disabled at (0): [\u0026lt;0000000000000000\u0026gt;] 0x0\nPreemption disabled at:\n[\u0026lt;ffffafe6a6598a4c\u0026gt;] kmemleak_seq_show+0x3c/0x1e0\nCPU: 1 UID: 0 PID: 136 Comm: cat Tainted: G            E      6.11.0-rt7+ #34\nTainted: [E]=UNSIGNED_MODULE\nHardware name: linux,dummy-virt (DT)\nCall trace:\n dump_backtrace+0xa0/0x128\n show_stack+0x1c/0x30\n dump_stack_lvl+0xe8/0x198\n dump_stack+0x18/0x20\n rt_spin_lock+0x8c/0x1a8\n avc_perm_nonode+0xa0/0x150\n cred_has_capability.isra.0+0x118/0x218\n selinux_capable+0x50/0x80\n security_capable+0x7c/0xd0\n has_ns_capability_noaudit+0x94/0x1b0\n has_capability_noaudit+0x20/0x30\n restricted_pointer+0x21c/0x4b0\n pointer+0x298/0x760\n vsnprintf+0x330/0xf70\n seq_printf+0x178/0x218\n print_unreferenced+0x1a4/0x2d0\n kmemleak_seq_show+0xd0/0x1e0\n seq_read_iter+0x354/0xe30\n seq_read+0x250/0x378\n full_proxy_read+0xd8/0x148\n vfs_read+0x190/0x918\n ksys_read+0xf0/0x1e0\n __arm64_sys_read+0x70/0xa8\n invoke_syscall.constprop.0+0xd4/0x1d8\n el0_svc+0x50/0x158\n el0t_64_sync+0x17c/0x180\n\n%pS and %pK, in the same back trace line, are redundant, and %pS can void\n%pK service in certain contexts.\n\n%pS alone already provides the necessary information, and if it cannot\nresolve the symbol, it falls back to printing the raw address voiding\nthe original intent behind the %pK.\n\nAdditionally, %pK requires a privilege check CAP_SYSLOG enforced through\nthe LSM, which can trigger a \u0026quot;sleeping function called from invalid\ncontext\u0026quot; warning under RT_PREEMPT kernels when the check occurs in an\natomic context. This issue may also affect other LSMs.\n\nThis change avoids the unnecessary privilege check and resolves the\nsleeping function warning without any loss of information.(CVE-2024-57885)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/uverbs: Prevent integer overflow issue\n\nIn the expression \u0026quot;cmd.wqe_size * cmd.wr_count\u0026quot;, both variables are u32\nvalues that come from the user so the multiplication can lead to integer\nwrapping.  Then we pass the result to uverbs_request_next_ptr() which also\ncould potentially wrap.  The \u0026quot;cmd.sge_count * sizeof(struct ib_uverbs_sge)\u0026quot;\nmultiplication can also overflow on 32bit systems although it\u0026apos;s fine on\n64bit systems.\n\nThis patch does two things.  First, I\u0026apos;ve re-arranged the condition in\nuverbs_request_next_ptr() so that the use controlled variable \u0026quot;len\u0026quot; is on\none side of the comparison by itself without any math.  Then I\u0026apos;ve modified\nall the callers to use size_mul() for the multiplications.(CVE-2024-57890)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_core: Fix sleeping function called from invalid context\n\nThis reworks hci_cb_list to not use mutex hci_cb_list_lock to avoid bugs\nlike the bellow:\n\nBUG: sleeping function called from invalid context at kernel/locking/mutex.c:585\nin_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 5070, name: kworker/u9:2\npreempt_count: 0, expected: 0\nRCU nest depth: 1, expected: 0\n4 locks held by kworker/u9:2/5070:\n #0: ffff888015be3948 ((wq_completion)hci0#2){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3229 [inline]\n #0: ffff888015be3948 ((wq_completion)hci0#2){+.+.}-{0:0}, at: process_scheduled_works+0x8e0/0x1770 kernel/workqueue.c:3335\n #1: ffffc90003b6fd00 ((work_completion)(\u0026amp;hdev-\u0026gt;rx_work)){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3230 [inline]\n #1: ffffc90003b6fd00 ((work_completion)(\u0026amp;hdev-\u0026gt;rx_work)){+.+.}-{0:0}, at: process_scheduled_works+0x91b/0x1770 kernel/workqueue.c:3335\n #2: ffff8880665d0078 (\u0026amp;hdev-\u0026gt;lock){+.+.}-{3:3}, at: hci_le_create_big_complete_evt+0xcf/0xae0 net/bluetooth/hci_event.c:6914\n #3: ffffffff8e132020 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:298 [inline]\n #3: ffffffff8e132020 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:750 [inline]\n #3: ffffffff8e132020 (rcu_read_lock){....}-{1:2}, at: hci_le_create_big_complete_evt+0xdb/0xae0 net/bluetooth/hci_event.c:6915\nCPU: 0 PID: 5070 Comm: kworker/u9:2 Not tainted 6.8.0-syzkaller-08073-g480e035fc4c7 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nWorkqueue: hci0 hci_rx_work\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114\n __might_resched+0x5d4/0x780 kernel/sched/core.c:10187\n __mutex_lock_common kernel/locking/mutex.c:585 [inline]\n __mutex_lock+0xc1/0xd70 kernel/locking/mutex.c:752\n hci_connect_cfm include/net/bluetooth/hci_core.h:2004 [inline]\n hci_le_create_big_complete_evt+0x3d9/0xae0 net/bluetooth/hci_event.c:6939\n hci_event_func net/bluetooth/hci_event.c:7514 [inline]\n hci_event_packet+0xa53/0x1540 net/bluetooth/hci_event.c:7569\n hci_rx_work+0x3e8/0xca0 net/bluetooth/hci_core.c:4171\n process_one_work kernel/workqueue.c:3254 [inline]\n process_scheduled_works+0xa00/0x1770 kernel/workqueue.c:3335\n worker_thread+0x86d/0xd70 kernel/workqueue.c:3416\n kthread+0x2f0/0x390 kernel/kthread.c:388\n ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243\n \u0026lt;/TASK\u0026gt;(CVE-2024-57894)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: Correct the migration DMA map direction\n\nThe SVM DMA device map direction should be set the same as\nthe DMA unmap setting, otherwise the DMA core will report\nthe following warning.\n\nBefore finialize this solution, there\u0026apos;re some discussion on\nthe DMA mapping type(stream-based or coherent) in this KFD\nmigration case, followed by https://lore.kernel.org/all/04d4ab32\n-45a1-4b88-86ee-fb0f35a0ca40@amd.com/T/.\n\nAs there\u0026apos;s no dma_sync_single_for_*() in the DMA buffer accessed\nthat because this migration operation should be sync properly and\nautomatically. Give that there\u0026apos;s might not be a performance problem\nin various cache sync policy of DMA sync. Therefore, in order to\nsimplify the DMA direction setting alignment, let\u0026apos;s set the DMA map\ndirection as BIDIRECTIONAL.\n\n[  150.834218] WARNING: CPU: 8 PID: 1812 at kernel/dma/debug.c:1028 check_unmap+0x1cc/0x930\n[  150.834225] Modules linked in: amdgpu(OE) amdxcp drm_exec(OE) gpu_sched drm_buddy(OE) drm_ttm_helper(OE) ttm(OE) drm_suballoc_helper(OE) drm_display_helper(OE) drm_kms_helper(OE) i2c_algo_bit rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace netfs xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo iptable_nat xt_addrtype iptable_filter br_netfilter nvme_fabrics overlay nfnetlink_cttimeout nfnetlink openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bridge stp llc sch_fq_codel intel_rapl_msr amd_atl intel_rapl_common snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg edac_mce_amd snd_pci_acp6x snd_hda_codec snd_acp_config snd_hda_core snd_hwdep snd_soc_acpi kvm_amd sunrpc snd_pcm kvm binfmt_misc snd_seq_midi crct10dif_pclmul snd_seq_midi_event ghash_clmulni_intel sha512_ssse3 snd_rawmidi nls_iso8859_1 sha256_ssse3 sha1_ssse3 snd_seq aesni_intel snd_seq_device crypto_simd snd_timer cryptd input_leds\n[  150.834310]  wmi_bmof serio_raw k10temp rapl snd sp5100_tco ipmi_devintf soundcore ccp ipmi_msghandler cm32181 industrialio mac_hid msr parport_pc ppdev lp parport efi_pstore drm(OE) ip_tables x_tables pci_stub crc32_pclmul nvme ahci libahci i2c_piix4 r8169 nvme_core i2c_designware_pci realtek i2c_ccgx_ucsi video wmi hid_generic cdc_ether usbnet usbhid hid r8152 mii\n[  150.834354] CPU: 8 PID: 1812 Comm: rocrtst64 Tainted: G           OE      6.10.0-custom #492\n[  150.834358] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 06/13/2021\n[  150.834360] RIP: 0010:check_unmap+0x1cc/0x930\n[  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 \u0026lt;0f\u0026gt; 0b 48 c7 c7 04 83 ac 84 e8 76 ba fc ff 41 8b 76 4c 49 8d 7e 50\n[  150.834365] RSP: 0018:ffffaac5023739e0 EFLAGS: 00010086\n[  150.834368] RAX: 0000000000000000 RBX: ffffffff8566a2e0 RCX: 0000000000000027\n[  150.834370] RDX: ffff8f6a8f621688 RSI: 0000000000000001 RDI: ffff8f6a8f621680\n[  150.834372] RBP: ffffaac502373a30 R08: 00000000000000c9 R09: ffffaac502373850\n[  150.834373] R10: ffffaac502373848 R11: ffffffff84f46328 R12: ffffaac502373a40\n[  150.834375] R13: ffff8f6741045330 R14: ffff8f6741a77700 R15: ffffffff84ac831b\n[  150.834377] FS:  00007faf0fc94c00(0000) GS:ffff8f6a8f600000(0000) knlGS:0000000000000000\n[  150.834379] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  150.834381] CR2: 00007faf0b600020 CR3: 000000010a52e000 CR4: 0000000000350ef0\n[  150.834383] Call Trace:\n[  150.834385]  \u0026lt;TASK\u0026gt;\n[  150.834387]  ? show_regs+0x6d/0x80\n[  150.834393]  ? __warn+0x8c/0x140\n[  150.834397]  ? check_unmap+0x1cc/0x930\n[  150.834400]  ? report_bug+0x193/0x1a0\n[  150.834406]  ? handle_bug+0x46/0x80\n[  150.834410]  ? exc_invalid_op+0x1d/0x80\n[  150.834413]  ? asm_exc_invalid_op+0x1f/0x30\n[  150.834420]  ? check_unmap+0x1cc/0x930\n[  150.834425]  debug_dma_unmap_page+0x86/0x90\n[  150.834431]  ? srso_return_thunk+0x5/0x5f\n[  150.834435] \n---truncated---(CVE-2024-57897)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\naf_packet: fix vlan_get_protocol_dgram() vs MSG_PEEK\n\nBlamed commit forgot MSG_PEEK case, allowing a crash [1] as found\nby syzbot.\n\nRework vlan_get_protocol_dgram() to not touch skb at all,\nso that it can be used from many cpus on the same skb.\n\nAdd a const qualifier to skb argument.\n\n[1]\nskbuff: skb_under_panic: text:ffffffff8a8ccd05 len:29 put:14 head:ffff88807fc8e400 data:ffff88807fc8e3f4 tail:0x11 end:0x140 dev:\u0026lt;NULL\u0026gt;\n------------[ cut here ]------------\n kernel BUG at net/core/skbuff.c:206 !\nOops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI\nCPU: 1 UID: 0 PID: 5892 Comm: syz-executor883 Not tainted 6.13.0-rc4-syzkaller-00054-gd6ef8b40d075 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\n RIP: 0010:skb_panic net/core/skbuff.c:206 [inline]\n RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216\nCode: 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 \u0026lt;0f\u0026gt; 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3\nRSP: 0018:ffffc900038d7638 EFLAGS: 00010282\nRAX: 0000000000000087 RBX: dffffc0000000000 RCX: 609ffd18ea660600\nRDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000\nRBP: ffff88802483c8d0 R08: ffffffff817f0a8c R09: 1ffff9200071ae60\nR10: dffffc0000000000 R11: fffff5200071ae61 R12: 0000000000000140\nR13: ffff88807fc8e400 R14: ffff88807fc8e3f4 R15: 0000000000000011\nFS:  00007fbac5e006c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fbac5e00d58 CR3: 000000001238e000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  skb_push+0xe5/0x100 net/core/skbuff.c:2636\n  vlan_get_protocol_dgram+0x165/0x290 net/packet/af_packet.c:585\n  packet_recvmsg+0x948/0x1ef0 net/packet/af_packet.c:3552\n  sock_recvmsg_nosec net/socket.c:1033 [inline]\n  sock_recvmsg+0x22f/0x280 net/socket.c:1055\n  ____sys_recvmsg+0x1c6/0x480 net/socket.c:2803\n  ___sys_recvmsg net/socket.c:2845 [inline]\n  do_recvmmsg+0x426/0xab0 net/socket.c:2940\n  __sys_recvmmsg net/socket.c:3014 [inline]\n  __do_sys_recvmmsg net/socket.c:3037 [inline]\n  __se_sys_recvmmsg net/socket.c:3030 [inline]\n  __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3030\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-57901)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\naf_packet: fix vlan_get_tci() vs MSG_PEEK\n\nBlamed commit forgot MSG_PEEK case, allowing a crash [1] as found\nby syzbot.\n\nRework vlan_get_tci() to not touch skb at all,\nso that it can be used from many cpus on the same skb.\n\nAdd a const qualifier to skb argument.\n\n[1]\nskbuff: skb_under_panic: text:ffffffff8a8da482 len:32 put:14 head:ffff88807a1d5800 data:ffff88807a1d5810 tail:0x14 end:0x140 dev:\u0026lt;NULL\u0026gt;\n------------[ cut here ]------------\n kernel BUG at net/core/skbuff.c:206 !\nOops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI\nCPU: 0 UID: 0 PID: 5880 Comm: syz-executor172 Not tainted 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\n RIP: 0010:skb_panic net/core/skbuff.c:206 [inline]\n RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216\nCode: 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 \u0026lt;0f\u0026gt; 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3\nRSP: 0018:ffffc90003baf5b8 EFLAGS: 00010286\nRAX: 0000000000000087 RBX: dffffc0000000000 RCX: 8565c1eec37aa000\nRDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000\nRBP: ffff88802616fb50 R08: ffffffff817f0a4c R09: 1ffff92000775e50\nR10: dffffc0000000000 R11: fffff52000775e51 R12: 0000000000000140\nR13: ffff88807a1d5800 R14: ffff88807a1d5810 R15: 0000000000000014\nFS:  00007fa03261f6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007ffd65753000 CR3: 0000000031720000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  skb_push+0xe5/0x100 net/core/skbuff.c:2636\n  vlan_get_tci+0x272/0x550 net/packet/af_packet.c:565\n  packet_recvmsg+0x13c9/0x1ef0 net/packet/af_packet.c:3616\n  sock_recvmsg_nosec net/socket.c:1044 [inline]\n  sock_recvmsg+0x22f/0x280 net/socket.c:1066\n  ____sys_recvmsg+0x1c6/0x480 net/socket.c:2814\n  ___sys_recvmsg net/socket.c:2856 [inline]\n  do_recvmmsg+0x426/0xab0 net/socket.c:2951\n  __sys_recvmmsg net/socket.c:3025 [inline]\n  __do_sys_recvmmsg net/socket.c:3048 [inline]\n  __se_sys_recvmmsg net/socket.c:3041 [inline]\n  __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3041\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83(CVE-2024-57902)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: restrict SO_REUSEPORT to inet sockets\n\nAfter blamed commit, crypto sockets could accidentally be destroyed\nfrom RCU call back, as spotted by zyzbot [1].\n\nTrying to acquire a mutex in RCU callback is not allowed.\n\nRestrict SO_REUSEPORT socket option to inet sockets.\n\nv1 of this patch supported TCP, UDP and SCTP sockets,\nbut fcnal-test.sh test needed RAW and ICMP support.\n\n[1]\nBUG: sleeping function called from invalid context at kernel/locking/mutex.c:562\nin_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 24, name: ksoftirqd/1\npreempt_count: 100, expected: 0\nRCU nest depth: 0, expected: 0\n1 lock held by ksoftirqd/1/24:\n  #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:337 [inline]\n  #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2561 [inline]\n  #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_core+0xa37/0x17a0 kernel/rcu/tree.c:2823\nPreemption disabled at:\n [\u0026lt;ffffffff8161c8c8\u0026gt;] softirq_handle_begin kernel/softirq.c:402 [inline]\n [\u0026lt;ffffffff8161c8c8\u0026gt;] handle_softirqs+0x128/0x9b0 kernel/softirq.c:537\nCPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.13.0-rc3-syzkaller-00174-ga024e377efed #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  __dump_stack lib/dump_stack.c:94 [inline]\n  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n  __might_resched+0x5d4/0x780 kernel/sched/core.c:8758\n  __mutex_lock_common kernel/locking/mutex.c:562 [inline]\n  __mutex_lock+0x131/0xee0 kernel/locking/mutex.c:735\n  crypto_put_default_null_skcipher+0x18/0x70 crypto/crypto_null.c:179\n  aead_release+0x3d/0x50 crypto/algif_aead.c:489\n  alg_do_release crypto/af_alg.c:118 [inline]\n  alg_sock_destruct+0x86/0xc0 crypto/af_alg.c:502\n  __sk_destruct+0x58/0x5f0 net/core/sock.c:2260\n  rcu_do_batch kernel/rcu/tree.c:2567 [inline]\n  rcu_core+0xaaa/0x17a0 kernel/rcu/tree.c:2823\n  handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561\n  run_ksoftirqd+0xca/0x130 kernel/softirq.c:950\n  smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164\n  kthread+0x2f0/0x390 kernel/kthread.c:389\n  ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n \u0026lt;/TASK\u0026gt;(CVE-2024-57903)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: f_fs: Remove WARN_ON in functionfs_bind\n\nThis commit addresses an issue related to below kernel panic where\npanic_on_warn is enabled. It is caused by the unnecessary use of WARN_ON\nin functionsfs_bind, which easily leads to the following scenarios.\n\n1.adb_write in adbd               2. UDC write via configfs\n  =================\t             =====================\n\n-\u0026gt;usb_ffs_open_thread()           -\u0026gt;UDC write\n -\u0026gt;open_functionfs()               -\u0026gt;configfs_write_iter()\n  -\u0026gt;adb_open()                      -\u0026gt;gadget_dev_desc_UDC_store()\n   -\u0026gt;adb_write()                     -\u0026gt;usb_gadget_register_driver_owner\n                                      -\u0026gt;driver_register()\n-\u0026gt;StartMonitor()                       -\u0026gt;bus_add_driver()\n -\u0026gt;adb_read()                           -\u0026gt;gadget_bind_driver()\n\u0026lt;times-out without BIND event\u0026gt;           -\u0026gt;configfs_composite_bind()\n                                          -\u0026gt;usb_add_function()\n-\u0026gt;open_functionfs()                        -\u0026gt;ffs_func_bind()\n -\u0026gt;adb_open()                               -\u0026gt;functionfs_bind()\n                                       \u0026lt;ffs-\u0026gt;state !=FFS_ACTIVE\u0026gt;\n\nThe adb_open, adb_read, and adb_write operations are invoked from the\ndaemon, but trying to bind the function is a process that is invoked by\nUDC write through configfs, which opens up the possibility of a race\ncondition between the two paths. In this race scenario, the kernel panic\noccurs due to the WARN_ON from functionfs_bind when panic_on_warn is\nenabled. This commit fixes the kernel panic by removing the unnecessary\nWARN_ON.\n\nKernel panic - not syncing: kernel: panic_on_warn set ...\n[   14.542395] Call trace:\n[   14.542464]  ffs_func_bind+0x1c8/0x14a8\n[   14.542468]  usb_add_function+0xcc/0x1f0\n[   14.542473]  configfs_composite_bind+0x468/0x588\n[   14.542478]  gadget_bind_driver+0x108/0x27c\n[   14.542483]  really_probe+0x190/0x374\n[   14.542488]  __driver_probe_device+0xa0/0x12c\n[   14.542492]  driver_probe_device+0x3c/0x220\n[   14.542498]  __driver_attach+0x11c/0x1fc\n[   14.542502]  bus_for_each_dev+0x104/0x160\n[   14.542506]  driver_attach+0x24/0x34\n[   14.542510]  bus_add_driver+0x154/0x270\n[   14.542514]  driver_register+0x68/0x104\n[   14.542518]  usb_gadget_register_driver_owner+0x48/0xf4\n[   14.542523]  gadget_dev_desc_UDC_store+0xf8/0x144\n[   14.542526]  configfs_write_iter+0xf0/0x138(CVE-2024-57913)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sctp: Prevent autoclose integer overflow in sctp_association_init()\n\nWhile by default max_autoclose equals to INT_MAX / HZ, one may set\nnet.sctp.max_autoclose to UINT_MAX. There is code in\nsctp_association_init() that can consequently trigger overflow.(CVE-2024-57938)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nriscv: mm: Fix the out of bound issue of vmemmap address\n\nIn sparse vmemmap model, the virtual address of vmemmap is calculated as:\n((struct page *)VMEMMAP_START - (phys_ram_base \u0026gt;\u0026gt; PAGE_SHIFT)).\nAnd the struct page\u0026apos;s va can be calculated with an offset:\n(vmemmap + (pfn)).\n\nHowever, when initializing struct pages, kernel actually starts from the\nfirst page from the same section that phys_ram_base belongs to. If the\nfirst page\u0026apos;s physical address is not (phys_ram_base \u0026gt;\u0026gt; PAGE_SHIFT), then\nwe get an va below VMEMMAP_START when calculating va for it\u0026apos;s struct page.\n\nFor example, if phys_ram_base starts from 0x82000000 with pfn 0x82000, the\nfirst page in the same section is actually pfn 0x80000. During\ninit_unavailable_range(), we will initialize struct page for pfn 0x80000\nwith virtual address ((struct page *)VMEMMAP_START - 0x2000), which is\nbelow VMEMMAP_START as well as PCI_IO_END.\n\nThis commit fixes this bug by introducing a new variable\n\u0026apos;vmemmap_start_pfn\u0026apos; which is aligned with memory section size and using\nit to calculate vmemmap address instead of phys_ram_base.(CVE-2024-57945)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read\n\nThe nvmem interface supports variable buffer sizes, while the regmap\ninterface operates with fixed-size storage. If an nvmem client uses a\nbuffer size less than 4 bytes, regmap_read will write out of bounds\nas it expects the buffer to point at an unsigned int.\n\nFix this by using an intermediary unsigned int to hold the value.(CVE-2024-58069)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclk: qcom: dispcc-sm6350: Add missing parent_map for a clock\n\nIf a clk_rcg2 has a parent, it should also have parent_map defined,\notherwise we\u0026apos;ll get a NULL pointer dereference when calling clk_set_rate\nlike the following:\n\n  [    3.388105] Call trace:\n  [    3.390664]  qcom_find_src_index+0x3c/0x70 (P)\n  [    3.395301]  qcom_find_src_index+0x1c/0x70 (L)\n  [    3.399934]  _freq_tbl_determine_rate+0x48/0x100\n  [    3.404753]  clk_rcg2_determine_rate+0x1c/0x28\n  [    3.409387]  clk_core_determine_round_nolock+0x58/0xe4\n  [    3.421414]  clk_core_round_rate_nolock+0x48/0xfc\n  [    3.432974]  clk_core_round_rate_nolock+0xd0/0xfc\n  [    3.444483]  clk_core_set_rate_nolock+0x8c/0x300\n  [    3.455886]  clk_set_rate+0x38/0x14c\n\nAdd the parent_map property for the clock where it\u0026apos;s missing and also\nun-inline the parent_data as well to keep the matching parent_map and\nparent_data together.(CVE-2024-58080)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix racy issue from session lookup and expire\n\nIncrement the session reference count within the lock for lookup to avoid\nracy issue with session expire.(CVE-2024-58087)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: reenable NETIF_F_IPV6_CSUM offload for BIG TCP packets\n\nThe blamed commit disabled hardware offoad of IPv6 packets with\nextension headers on devices that advertise NETIF_F_IPV6_CSUM,\nbased on the definition of that feature in skbuff.h:\n\n *   * - %NETIF_F_IPV6_CSUM\n *     - Driver (device) is only able to checksum plain\n *       TCP or UDP packets over IPv6. These are specifically\n *       unencapsulated packets of the form IPv6|TCP or\n *       IPv6|UDP where the Next Header field in the IPv6\n *       header is either TCP or UDP. IPv6 extension headers\n *       are not supported with this feature. This feature\n *       cannot be set in features for a device with\n *       NETIF_F_HW_CSUM also set. This feature is being\n *       DEPRECATED (see below).\n\nThe change causes skb_warn_bad_offload to fire for BIG TCP\npackets.\n\n[  496.310233] WARNING: CPU: 13 PID: 23472 at net/core/dev.c:3129 skb_warn_bad_offload+0xc4/0xe0\n\n[  496.310297]  ? skb_warn_bad_offload+0xc4/0xe0\n[  496.310300]  skb_checksum_help+0x129/0x1f0\n[  496.310303]  skb_csum_hwoffload_help+0x150/0x1b0\n[  496.310306]  validate_xmit_skb+0x159/0x270\n[  496.310309]  validate_xmit_skb_list+0x41/0x70\n[  496.310312]  sch_direct_xmit+0x5c/0x250\n[  496.310317]  __qdisc_run+0x388/0x620\n\nBIG TCP introduced an IPV6_TLV_JUMBO IPv6 extension header to\ncommunicate packet length, as this is an IPv6 jumbogram. But, the\nfeature is only enabled on devices that support BIG TCP TSO. The\nheader is only present for PF_PACKET taps like tcpdump, and not\ntransmitted by physical devices.\n\nFor this specific case of extension headers that are not\ntransmitted, return to the situation before the blamed commit\nand support hardware offload.\n\nipv6_has_hopopt_jumbo() tests not only whether this header is present,\nbut also that it is the only extension header before a terminal (L4)\nheader.(CVE-2025-21629)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: sysctl: rto_min/max: avoid using current-\u0026gt;nsproxy\n\nAs mentioned in a previous commit of this series, using the \u0026apos;net\u0026apos;\nstructure via \u0026apos;current\u0026apos; is not recommended for different reasons:\n\n- Inconsistency: getting info from the reader\u0026apos;s/writer\u0026apos;s netns vs only\n  from the opener\u0026apos;s netns.\n\n- current-\u0026gt;nsproxy can be NULL in some cases, resulting in an \u0026apos;Oops\u0026apos;\n  (null-ptr-deref), e.g. when the current task is exiting, as spotted by\n  syzbot [1] using acct(2).\n\nThe \u0026apos;net\u0026apos; structure can be obtained from the table-\u0026gt;data using\ncontainer_of().\n\nNote that table-\u0026gt;data could also be used directly, as this is the only\nmember needed from the \u0026apos;net\u0026apos; structure, but that would increase the size\nof this fix, to use \u0026apos;*data\u0026apos; everywhere \u0026apos;net-\u0026gt;sctp.rto_min/max\u0026apos; is used.(CVE-2025-21639)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: sysctl: sched: avoid using current-\u0026gt;nsproxy\n\nUsing the \u0026apos;net\u0026apos; structure via \u0026apos;current\u0026apos; is not recommended for different\nreasons.\n\nFirst, if the goal is to use it to read or write per-netns data, this is\ninconsistent with how the \u0026quot;generic\u0026quot; sysctl entries are doing: directly\nby only using pointers set to the table entry, e.g. table-\u0026gt;data. Linked\nto that, the per-netns data should always be obtained from the table\nlinked to the netns it had been created for, which may not coincide with\nthe reader\u0026apos;s or writer\u0026apos;s netns.\n\nAnother reason is that access to current-\u0026gt;nsproxy-\u0026gt;netns can oops if\nattempted when current-\u0026gt;nsproxy had been dropped when the current task\nis exiting. This is what syzbot found, when using acct(2):\n\n  Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN PTI\n  KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]\n  CPU: 1 UID: 0 PID: 5924 Comm: syz-executor Not tainted 6.13.0-rc5-syzkaller-00004-gccb98ccef0e5 #0\n  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\n  RIP: 0010:proc_scheduler+0xc6/0x3c0 net/mptcp/ctrl.c:125\n  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 \u0026lt;80\u0026gt; 3c 02 00 0f 85 cc 02 00 00 4d 8b 7c 24 28 48 8d 84 24 c8 00 00\n  RSP: 0018:ffffc900034774e8 EFLAGS: 00010206\n\n  RAX: dffffc0000000000 RBX: 1ffff9200068ee9e RCX: ffffc90003477620\n  RDX: 0000000000000005 RSI: ffffffff8b08f91e RDI: 0000000000000028\n  RBP: 0000000000000001 R08: ffffc90003477710 R09: 0000000000000040\n  R10: 0000000000000040 R11: 00000000726f7475 R12: 0000000000000000\n  R13: ffffc90003477620 R14: ffffc90003477710 R15: dffffc0000000000\n  FS:  0000000000000000(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 00007fee3cd452d8 CR3: 000000007d116000 CR4: 00000000003526f0\n  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   proc_sys_call_handler+0x403/0x5d0 fs/proc/proc_sysctl.c:601\n   __kernel_write_iter+0x318/0xa80 fs/read_write.c:612\n   __kernel_write+0xf6/0x140 fs/read_write.c:632\n   do_acct_process+0xcb0/0x14a0 kernel/acct.c:539\n   acct_pin_kill+0x2d/0x100 kernel/acct.c:192\n   pin_kill+0x194/0x7c0 fs/fs_pin.c:44\n   mnt_pin_kill+0x61/0x1e0 fs/fs_pin.c:81\n   cleanup_mnt+0x3ac/0x450 fs/namespace.c:1366\n   task_work_run+0x14e/0x250 kernel/task_work.c:239\n   exit_task_work include/linux/task_work.h:43 [inline]\n   do_exit+0xad8/0x2d70 kernel/exit.c:938\n   do_group_exit+0xd3/0x2a0 kernel/exit.c:1087\n   get_signal+0x2576/0x2610 kernel/signal.c:3017\n   arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337\n   exit_to_user_mode_loop kernel/entry/common.c:111 [inline]\n   exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline]\n   __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]\n   syscall_exit_to_user_mode+0x150/0x2a0 kernel/entry/common.c:218\n   do_syscall_64+0xda/0x250 arch/x86/entry/common.c:89\n   entry_SYSCALL_64_after_hwframe+0x77/0x7f\n  RIP: 0033:0x7fee3cb87a6a\n  Code: Unable to access opcode bytes at 0x7fee3cb87a40.\n  RSP: 002b:00007fffcccac688 EFLAGS: 00000202 ORIG_RAX: 0000000000000037\n  RAX: 0000000000000000 RBX: 00007fffcccac710 RCX: 00007fee3cb87a6a\n  RDX: 0000000000000041 RSI: 0000000000000000 RDI: 0000000000000003\n  RBP: 0000000000000003 R08: 00007fffcccac6ac R09: 00007fffcccacac7\n  R10: 00007fffcccac710 R11: 0000000000000202 R12: 00007fee3cd49500\n  R13: 00007fffcccac6ac R14: 0000000000000000 R15: 00007fee3cd4b000\n   \u0026lt;/TASK\u0026gt;\n  Modules linked in:\n  ---[ end trace 0000000000000000 ]---\n  RIP: 0010:proc_scheduler+0xc6/0x3c0 net/mptcp/ctrl.c:125\n  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\n---truncated---(CVE-2025-21642)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nafs: Fix the maximum cell name length\n\nThe kafs filesystem limits the maximum length of a cell to 256 bytes, but a\nproblem occurs if someone actually does that: kafs tries to create a\ndirectory under /proc/net/afs/ with the name of the cell, but that fails\nwith a warning:\n\n        WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:405\n\nbecause procfs limits the maximum filename length to 255.\n\nHowever, the DNS limits the maximum lookup length and, by extension, the\nmaximum cell name, to 255 less two (length count and trailing NUL).\n\nFix this by limiting the maximum acceptable cellname length to 253.  This\nalso allows us to be sure we can create the \u0026quot;/afs/.\u0026lt;cell\u0026gt;/\u0026quot; mountpoint too.\n\nFurther, split the YFS VL record cell name maximum to be the 256 allowed by\nthe protocol and ignore the record retrieved by YFSVL.GetCellName if it\nexceeds 253.(CVE-2025-21646)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\novl: support encoding fid from inode with no alias\n\nDmitry Safonov reported that a WARN_ON() assertion can be trigered by\nuserspace when calling inotify_show_fdinfo() for an overlayfs watched\ninode, whose dentry aliases were discarded with drop_caches.\n\nThe WARN_ON() assertion in inotify_show_fdinfo() was removed, because\nit is possible for encoding file handle to fail for other reason, but\nthe impact of failing to encode an overlayfs file handle goes beyond\nthis assertion.\n\nAs shown in the LTP test case mentioned in the link below, failure to\nencode an overlayfs file handle from a non-aliased inode also leads to\nfailure to report an fid with FAN_DELETE_SELF fanotify events.\n\nAs Dmitry notes in his analyzis of the problem, ovl_encode_fh() fails\nif it cannot find an alias for the inode, but this failure can be fixed.\novl_encode_fh() seldom uses the alias and in the case of non-decodable\nfile handles, as is often the case with fanotify fid info,\novl_encode_fh() never needs to use the alias to encode a file handle.\n\nDefer finding an alias until it is actually needed so ovl_encode_fh()\nwill not fail in the common case of FAN_DELETE_SELF fanotify events.(CVE-2025-21654)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/eventfd: ensure io_eventfd_signal() defers another RCU period\n\nio_eventfd_do_signal() is invoked from an RCU callback, but when\ndropping the reference to the io_ev_fd, it calls io_eventfd_free()\ndirectly if the refcount drops to zero. This isn\u0026apos;t correct, as any\npotential freeing of the io_ev_fd should be deferred another RCU grace\nperiod.\n\nJust call io_eventfd_put() rather than open-code the dec-and-test and\nfree, which will correctly defer it another RCU grace period.(CVE-2025-21655)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix unexpectedly changed path in ksmbd_vfs_kern_path_locked\n\nWhen `ksmbd_vfs_kern_path_locked` met an error and it is not the last\nentry, it will exit without restoring changed path buffer. But later this\nbuffer may be used as the filename for creation.(CVE-2025-21660)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Fix variable not being completed when function returns\n\nWhen cmd_alloc_index(), fails cmd_work_handler() needs\nto complete ent-\u0026gt;slotted before returning early.\nOtherwise the task which issued the command may hang:\n\n   mlx5_core 0000:01:00.0: cmd_work_handler:877:(pid 3880418): failed to allocate command entry\n   INFO: task kworker/13:2:4055883 blocked for more than 120 seconds.\n         Not tainted 4.19.90-25.44.v2101.ky10.aarch64 #1\n   \u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\n   kworker/13:2    D    0 4055883      2 0x00000228\n   Workqueue: events mlx5e_tx_dim_work [mlx5_core]\n   Call trace:\n      __switch_to+0xe8/0x150\n      __schedule+0x2a8/0x9b8\n      schedule+0x2c/0x88\n      schedule_timeout+0x204/0x478\n      wait_for_common+0x154/0x250\n      wait_for_completion+0x28/0x38\n      cmd_exec+0x7a0/0xa00 [mlx5_core]\n      mlx5_cmd_exec+0x54/0x80 [mlx5_core]\n      mlx5_core_modify_cq+0x6c/0x80 [mlx5_core]\n      mlx5_core_modify_cq_moderation+0xa0/0xb8 [mlx5_core]\n      mlx5e_tx_dim_work+0x54/0x68 [mlx5_core]\n      process_one_work+0x1b0/0x448\n      worker_thread+0x54/0x468\n      kthread+0x134/0x138\n      ret_from_fork+0x10/0x18(CVE-2025-21662)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: stmmac: dwmac-tegra: Read iommu stream id from device tree\n\nNvidia\u0026apos;s Tegra MGBE controllers require the IOMMU \u0026quot;Stream ID\u0026quot; (SID) to be\nwritten to the MGBE_WRAP_AXI_ASID0_CTRL register.\n\nThe current driver is hard coded to use MGBE0\u0026apos;s SID for all controllers.\nThis causes softirq time outs and kernel panics when using controllers\nother than MGBE0.\n\nExample dmesg errors when an ethernet cable is connected to MGBE1:\n\n[  116.133290] tegra-mgbe 6910000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx\n[  121.851283] tegra-mgbe 6910000.ethernet eth1: NETDEV WATCHDOG: CPU: 5: transmit queue 0 timed out 5690 ms\n[  121.851782] tegra-mgbe 6910000.ethernet eth1: Reset adapter.\n[  121.892464] tegra-mgbe 6910000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-0\n[  121.905920] tegra-mgbe 6910000.ethernet eth1: PHY [stmmac-1:00] driver [Aquantia AQR113] (irq=171)\n[  121.907356] tegra-mgbe 6910000.ethernet eth1: Enabling Safety Features\n[  121.907578] tegra-mgbe 6910000.ethernet eth1: IEEE 1588-2008 Advanced Timestamp supported\n[  121.908399] tegra-mgbe 6910000.ethernet eth1: registered PTP clock\n[  121.908582] tegra-mgbe 6910000.ethernet eth1: configuring for phy/10gbase-r link mode\n[  125.961292] tegra-mgbe 6910000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx\n[  181.921198] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:\n[  181.921404] rcu: \t7-....: (1 GPs behind) idle=540c/1/0x4000000000000002 softirq=1748/1749 fqs=2337\n[  181.921684] rcu: \t(detected by 4, t=6002 jiffies, g=1357, q=1254 ncpus=8)\n[  181.921878] Sending NMI from CPU 4 to CPUs 7:\n[  181.921886] NMI backtrace for cpu 7\n[  181.922131] CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Kdump: loaded Not tainted 6.13.0-rc3+ #6\n[  181.922390] Hardware name: NVIDIA CTI Forge + Orin AGX/Jetson, BIOS 202402.1-Unknown 10/28/2024\n[  181.922658] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[  181.922847] pc : handle_softirqs+0x98/0x368\n[  181.922978] lr : __do_softirq+0x18/0x20\n[  181.923095] sp : ffff80008003bf50\n[  181.923189] x29: ffff80008003bf50 x28: 0000000000000008 x27: 0000000000000000\n[  181.923379] x26: ffffce78ea277000 x25: 0000000000000000 x24: 0000001c61befda0\n[  181.924486] x23: 0000000060400009 x22: ffffce78e99918bc x21: ffff80008018bd70\n[  181.925568] x20: ffffce78e8bb00d8 x19: ffff80008018bc20 x18: 0000000000000000\n[  181.926655] x17: ffff318ebe7d3000 x16: ffff800080038000 x15: 0000000000000000\n[  181.931455] x14: ffff000080816680 x13: ffff318ebe7d3000 x12: 000000003464d91d\n[  181.938628] x11: 0000000000000040 x10: ffff000080165a70 x9 : ffffce78e8bb0160\n[  181.945804] x8 : ffff8000827b3160 x7 : f9157b241586f343 x6 : eeb6502a01c81c74\n[  181.953068] x5 : a4acfcdd2e8096bb x4 : ffffce78ea277340 x3 : 00000000ffffd1e1\n[  181.960329] x2 : 0000000000000101 x1 : ffffce78ea277340 x0 : ffff318ebe7d3000\n[  181.967591] Call trace:\n[  181.970043]  handle_softirqs+0x98/0x368 (P)\n[  181.974240]  __do_softirq+0x18/0x20\n[  181.977743]  ____do_softirq+0x14/0x28\n[  181.981415]  call_on_irq_stack+0x24/0x30\n[  181.985180]  do_softirq_own_stack+0x20/0x30\n[  181.989379]  __irq_exit_rcu+0x114/0x140\n[  181.993142]  irq_exit_rcu+0x14/0x28\n[  181.996816]  el1_interrupt+0x44/0xb8\n[  182.000316]  el1h_64_irq_handler+0x14/0x20\n[  182.004343]  el1h_64_irq+0x80/0x88\n[  182.007755]  cpuidle_enter_state+0xc4/0x4a8 (P)\n[  182.012305]  cpuidle_enter+0x3c/0x58\n[  182.015980]  cpuidle_idle_call+0x128/0x1c0\n[  182.020005]  do_idle+0xe0/0xf0\n[  182.023155]  cpu_startup_entry+0x3c/0x48\n[  182.026917]  secondary_start_kernel+0xdc/0x120\n[  182.031379]  __secondary_switched+0x74/0x78\n[  212.971162] rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { 7-.... } 6103 jiffies s: 417 root: 0x80/.\n[  212.985935] rcu: blocking rcu_node structures (internal RCU debug):\n[  212.992758] Sending NMI from CPU 0 to CPUs 7:\n[  212.998539] NMI backtrace for cpu 7\n[  213.004304] CPU: 7 UID: 0 PI\n---truncated---(CVE-2025-21663)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm thin: make get_first_thin use rcu-safe list first function\n\nThe documentation in rculist.h explains the absence of list_empty_rcu()\nand cautions programmers against relying on a list_empty() -\u0026gt;\nlist_first() sequence in RCU safe code.  This is because each of these\nfunctions performs its own READ_ONCE() of the list head.  This can lead\nto a situation where the list_empty() sees a valid list entry, but the\nsubsequent list_first() sees a different view of list head state after a\nmodification.\n\nIn the case of dm-thin, this author had a production box crash from a GP\nfault in the process_deferred_bios path.  This function saw a valid list\nhead in get_first_thin() but when it subsequently dereferenced that and\nturned it into a thin_c, it got the inside of the struct pool, since the\nlist was now empty and referring to itself.  The kernel on which this\noccurred printed both a warning about a refcount_t being saturated, and\na UBSAN error for an out-of-bounds cpuid access in the queued spinlock,\nprior to the fault itself.  When the resulting kdump was examined, it\nwas possible to see another thread patiently waiting in thin_dtr\u0026apos;s\nsynchronize_rcu.\n\nThe thin_dtr call managed to pull the thin_c out of the active thins\nlist (and have it be the last entry in the active_thins list) at just\nthe wrong moment which lead to this crash.\n\nFortunately, the fix here is straight forward.  Switch get_first_thin()\nfunction to use list_first_or_null_rcu() which performs just a single\nREAD_ONCE() and returns NULL if the list is already empty.\n\nThis was run against the devicemapper test suite\u0026apos;s thin-provisioning\nsuites for delete and suspend and no regressions were observed.(CVE-2025-21664)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipmr: do not call mr_mfc_uses_dev() for unres entries\n\nsyzbot found that calling mr_mfc_uses_dev() for unres entries\nwould crash [1], because c-\u0026gt;mfc_un.res.minvif / c-\u0026gt;mfc_un.res.maxvif\nalias to \u0026quot;struct sk_buff_head unresolved\u0026quot;, which contain two pointers.\n\nThis code never worked, lets remove it.\n\n[1]\nUnable to handle kernel paging request at virtual address ffff5fff2d536613\nKASAN: maybe wild-memory-access in range [0xfffefff96a9b3098-0xfffefff96a9b309f]\nModules linked in:\nCPU: 1 UID: 0 PID: 7321 Comm: syz.0.16 Not tainted 6.13.0-rc7-syzkaller-g1950a0af2d55 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline]\n pc : mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334\n lr : mr_mfc_uses_dev net/ipv4/ipmr_base.c:289 [inline]\n lr : mr_table_dump+0x694/0x8b0 net/ipv4/ipmr_base.c:334\nCall trace:\n  mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline] (P)\n  mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 (P)\n  mr_rtm_dumproute+0x254/0x454 net/ipv4/ipmr_base.c:382\n  ipmr_rtm_dumproute+0x248/0x4b4 net/ipv4/ipmr.c:2648\n  rtnl_dump_all+0x2e4/0x4e8 net/core/rtnetlink.c:4327\n  rtnl_dumpit+0x98/0x1d0 net/core/rtnetlink.c:6791\n  netlink_dump+0x4f0/0xbc0 net/netlink/af_netlink.c:2317\n  netlink_recvmsg+0x56c/0xe64 net/netlink/af_netlink.c:1973\n  sock_recvmsg_nosec net/socket.c:1033 [inline]\n  sock_recvmsg net/socket.c:1055 [inline]\n  sock_read_iter+0x2d8/0x40c net/socket.c:1125\n  new_sync_read fs/read_write.c:484 [inline]\n  vfs_read+0x740/0x970 fs/read_write.c:565\n  ksys_read+0x15c/0x26c fs/read_write.c:708(CVE-2025-21719)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: Check the return value of of_property_read_string_index()\n\nSomewhen between 6.10 and 6.11 the driver started to crash on my\nMacBookPro14,3. The property doesn\u0026apos;t exist and \u0026apos;tmp\u0026apos; remains\nuninitialized, so we pass a random pointer to devm_kstrdup().\n\nThe crash I am getting looks like this:\n\nBUG: unable to handle page fault for address: 00007f033c669379\nPF: supervisor read access in kernel mode\nPF: error_code(0x0001) - permissions violation\nPGD 8000000101341067 P4D 8000000101341067 PUD 101340067 PMD 1013bb067 PTE 800000010aee9025\nOops: Oops: 0001 [#1] SMP PTI\nCPU: 4 UID: 0 PID: 827 Comm: (udev-worker) Not tainted 6.11.8-gentoo #1\nHardware name: Apple Inc. MacBookPro14,3/Mac-551B86E5744E2388, BIOS 529.140.2.0.0 06/23/2024\nRIP: 0010:strlen+0x4/0x30\nCode: 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 \u0026lt;80\u0026gt; 3f 00 74 14 48 89 f8 48 83 c0 01 80 38 00 75 f7 48 29 f8 c3 cc\nRSP: 0018:ffffb4aac0683ad8 EFLAGS: 00010202\nRAX: 00000000ffffffea RBX: 00007f033c669379 RCX: 0000000000000001\nRDX: 0000000000000cc0 RSI: 00007f033c669379 RDI: 00007f033c669379\nRBP: 00000000ffffffea R08: 0000000000000000 R09: 00000000c0ba916a\nR10: ffffffffffffffff R11: ffffffffb61ea260 R12: ffff91f7815b50c8\nR13: 0000000000000cc0 R14: ffff91fafefffe30 R15: ffffb4aac0683b30\nFS:  00007f033ccbe8c0(0000) GS:ffff91faeed00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f033c669379 CR3: 0000000107b1e004 CR4: 00000000003706f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die+0x23/0x70\n ? page_fault_oops+0x149/0x4c0\n ? raw_spin_rq_lock_nested+0xe/0x20\n ? sched_balance_newidle+0x22b/0x3c0\n ? update_load_avg+0x78/0x770\n ? exc_page_fault+0x6f/0x150\n ? asm_exc_page_fault+0x26/0x30\n ? __pfx_pci_conf1_write+0x10/0x10\n ? strlen+0x4/0x30\n devm_kstrdup+0x25/0x70\n brcmf_of_probe+0x273/0x350 [brcmfmac](CVE-2025-21750)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-83.0.0.77.oe2403"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-83.0.0.77.oe2403.aarch64.rpm","bpftool-debuginfo-6.6.0-83.0.0.77.oe2403.aarch64.rpm","kernel-6.6.0-83.0.0.77.oe2403.aarch64.rpm","kernel-debuginfo-6.6.0-83.0.0.77.oe2403.aarch64.rpm","kernel-debugsource-6.6.0-83.0.0.77.oe2403.aarch64.rpm","kernel-devel-6.6.0-83.0.0.77.oe2403.aarch64.rpm","kernel-headers-6.6.0-83.0.0.77.oe2403.aarch64.rpm","kernel-source-6.6.0-83.0.0.77.oe2403.aarch64.rpm","kernel-tools-6.6.0-83.0.0.77.oe2403.aarch64.rpm","kernel-tools-debuginfo-6.6.0-83.0.0.77.oe2403.aarch64.rpm","kernel-tools-devel-6.6.0-83.0.0.77.oe2403.aarch64.rpm","perf-6.6.0-83.0.0.77.oe2403.aarch64.rpm","perf-debuginfo-6.6.0-83.0.0.77.oe2403.aarch64.rpm","python3-perf-6.6.0-83.0.0.77.oe2403.aarch64.rpm","python3-perf-debuginfo-6.6.0-83.0.0.77.oe2403.aarch64.rpm"],"src":["kernel-6.6.0-83.0.0.77.oe2403.src.rpm"],"x86_64":["bpftool-6.6.0-83.0.0.77.oe2403.x86_64.rpm","bpftool-debuginfo-6.6.0-83.0.0.77.oe2403.x86_64.rpm","kernel-6.6.0-83.0.0.77.oe2403.x86_64.rpm","kernel-debuginfo-6.6.0-83.0.0.77.oe2403.x86_64.rpm","kernel-debugsource-6.6.0-83.0.0.77.oe2403.x86_64.rpm","kernel-devel-6.6.0-83.0.0.77.oe2403.x86_64.rpm","kernel-headers-6.6.0-83.0.0.77.oe2403.x86_64.rpm","kernel-source-6.6.0-83.0.0.77.oe2403.x86_64.rpm","kernel-tools-6.6.0-83.0.0.77.oe2403.x86_64.rpm","kernel-tools-debuginfo-6.6.0-83.0.0.77.oe2403.x86_64.rpm","kernel-tools-devel-6.6.0-83.0.0.77.oe2403.x86_64.rpm","perf-6.6.0-83.0.0.77.oe2403.x86_64.rpm","perf-debuginfo-6.6.0-83.0.0.77.oe2403.x86_64.rpm","python3-perf-6.6.0-83.0.0.77.oe2403.x86_64.rpm","python3-perf-debuginfo-6.6.0-83.0.0.77.oe2403.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1320"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36476"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56778"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57802"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57834"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57883"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57884"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57885"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57890"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57894"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57897"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57901"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57902"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57903"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57913"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57938"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57945"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58069"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58080"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58087"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21629"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21639"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21642"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21646"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21654"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21655"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21660"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21662"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21663"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21664"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21719"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21750"}],"database_specific":{"severity":"High"}}