Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func<br /> <br /> This commit adds a null check for the set_output_gamma function pointer<br /> in the dcn30_set_output_transfer_func function. Previously,<br /> set_output_gamma was being checked for nullity at line 386, but then it<br /> was being dereferenced without any nullity check at line 401. This<br /> could potentially lead to a null pointer dereference error if<br /> set_output_gamma is indeed null.<br /> <br /> To fix this, we now ensure that set_output_gamma is not null before<br /> dereferencing it. We do this by adding a nullity check for<br /> set_output_gamma before the call to set_output_gamma at line 401. If<br /> set_output_gamma is null, we log an error message and do not call the<br /> function.<br /> <br /> This fix prevents a potential null pointer dereference error.<br /> <br /> drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func()<br /> error: we previously assumed &amp;#39;mpc-&gt;funcs-&gt;set_output_gamma&amp;#39; could be null (see line 386)<br /> <br /> drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c<br /> 373 bool dcn30_set_output_transfer_func(struct dc *dc,<br /> 374 struct pipe_ctx *pipe_ctx,<br /> 375 const struct dc_stream_state *stream)<br /> 376 {<br /> 377 int mpcc_id = pipe_ctx-&gt;plane_res.hubp-&gt;inst;<br /> 378 struct mpc *mpc = pipe_ctx-&gt;stream_res.opp-&gt;ctx-&gt;dc-&gt;res_pool-&gt;mpc;<br /> 379 const struct pwl_params *params = NULL;<br /> 380 bool ret = false;<br /> 381<br /> 382 /* program OGAM or 3DLUT only for the top pipe*/<br /> 383 if (pipe_ctx-&gt;top_pipe == NULL) {<br /> 384 /*program rmu shaper and 3dlut in MPC*/<br /> 385 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream);<br /> 386 if (ret == false &amp;&amp; mpc-&gt;funcs-&gt;set_output_gamma) {<br /> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL<br /> <br /> 387 if (stream-&gt;out_transfer_func.type == TF_TYPE_HWPWL)<br /> 388 params = &amp;stream-&gt;out_transfer_func.pwl;<br /> 389 else if (pipe_ctx-&gt;stream-&gt;out_transfer_func.type ==<br /> 390 TF_TYPE_DISTRIBUTED_POINTS &amp;&amp;<br /> 391 cm3_helper_translate_curve_to_hw_format(<br /> 392 &amp;stream-&gt;out_transfer_func,<br /> 393 &amp;mpc-&gt;blender_params, false))<br /> 394 params = &amp;mpc-&gt;blender_params;<br /> 395 /* there are no ROM LUTs in OUTGAM */<br /> 396 if (stream-&gt;out_transfer_func.type == TF_TYPE_PREDEFINED)<br /> 397 BREAK_TO_DEBUGGER();<br /> 398 }<br /> 399 }<br /> 400<br /> --&gt; 401 mpc-&gt;funcs-&gt;set_output_gamma(mpc, mpcc_id, params);<br /> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash<br /> <br /> 402 return ret;<br /> 403 }

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netkit: Assign missing bpf_net_context<br /> <br /> During the introduction of struct bpf_net_context handling for<br /> XDP-redirect, the netkit driver has been missed, which also requires it<br /> because NETKIT_REDIRECT invokes skb_do_redirect() which is accessing the<br /> per-CPU variables. Otherwise we see the following crash:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000038<br /> bpf_redirect()<br /> netkit_xmit()<br /> dev_hard_start_xmit()<br /> <br /> Set the bpf_net_context before invoking netkit_xmit() program within the<br /> netkit driver.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_unix: Don&amp;#39;t return OOB skb in manage_oob().<br /> <br /> syzbot reported use-after-free in unix_stream_recv_urg(). [0]<br /> <br /> The scenario is<br /> <br /> 1. send(MSG_OOB)<br /> 2. recv(MSG_OOB)<br /> -&gt; The consumed OOB remains in recv queue<br /> 3. send(MSG_OOB)<br /> 4. recv()<br /> -&gt; manage_oob() returns the next skb of the consumed OOB<br /> -&gt; This is also OOB, but unix_sk(sk)-&gt;oob_skb is not cleared<br /> 5. recv(MSG_OOB)<br /> -&gt; unix_sk(sk)-&gt;oob_skb is used but already freed<br /> <br /> The recent commit 8594d9b85c07 ("af_unix: Don&amp;#39;t call skb_get() for OOB<br /> skb.") uncovered the issue.<br /> <br /> If the OOB skb is consumed and the next skb is peeked in manage_oob(),<br /> we still need to check if the skb is OOB.<br /> <br /> Let&amp;#39;s do so by falling back to the following checks in manage_oob()<br /> and add the test case in selftest.<br /> <br /> Note that we need to add a similar check for SIOCATMARK.<br /> <br /> [0]:<br /> BUG: KASAN: slab-use-after-free in unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959<br /> Read of size 4 at addr ffff8880326abcc4 by task syz-executor178/5235<br /> <br /> CPU: 0 UID: 0 PID: 5235 Comm: syz-executor178 Not tainted 6.11.0-rc5-syzkaller-00742-gfbdaffe41adc #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:93 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119<br /> print_address_description mm/kasan/report.c:377 [inline]<br /> print_report+0x169/0x550 mm/kasan/report.c:488<br /> kasan_report+0x143/0x180 mm/kasan/report.c:601<br /> unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959<br /> unix_stream_recv_urg+0x1df/0x320 net/unix/af_unix.c:2640<br /> unix_stream_read_generic+0x2456/0x2520 net/unix/af_unix.c:2778<br /> unix_stream_recvmsg+0x22b/0x2c0 net/unix/af_unix.c:2996<br /> sock_recvmsg_nosec net/socket.c:1046 [inline]<br /> sock_recvmsg+0x22f/0x280 net/socket.c:1068<br /> ____sys_recvmsg+0x1db/0x470 net/socket.c:2816<br /> ___sys_recvmsg net/socket.c:2858 [inline]<br /> __sys_recvmsg+0x2f0/0x3e0 net/socket.c:2888<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f5360d6b4e9<br /> Code: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007fff29b3a458 EFLAGS: 00000246 ORIG_RAX: 000000000000002f<br /> RAX: ffffffffffffffda RBX: 00007fff29b3a638 RCX: 00007f5360d6b4e9<br /> RDX: 0000000000002001 RSI: 0000000020000640 RDI: 0000000000000003<br /> RBP: 00007f5360dde610 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001<br /> R13: 00007fff29b3a628 R14: 0000000000000001 R15: 0000000000000001<br /> <br /> <br /> Allocated by task 5235:<br /> kasan_save_stack mm/kasan/common.c:47 [inline]<br /> kasan_save_track+0x3f/0x80 mm/kasan/common.c:68<br /> unpoison_slab_object mm/kasan/common.c:312 [inline]<br /> __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338<br /> kasan_slab_alloc include/linux/kasan.h:201 [inline]<br /> slab_post_alloc_hook mm/slub.c:3988 [inline]<br /> slab_alloc_node mm/slub.c:4037 [inline]<br /> kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4080<br /> __alloc_skb+0x1c3/0x440 net/core/skbuff.c:667<br /> alloc_skb include/linux/skbuff.h:1320 [inline]<br /> alloc_skb_with_frags+0xc3/0x770 net/core/skbuff.c:6528<br /> sock_alloc_send_pskb+0x91a/0xa60 net/core/sock.c:2815<br /> sock_alloc_send_skb include/net/sock.h:1778 [inline]<br /> queue_oob+0x108/0x680 net/unix/af_unix.c:2198<br /> unix_stream_sendmsg+0xd24/0xf80 net/unix/af_unix.c:2351<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg+0x221/0x270 net/socket.c:745<br /> ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597<br /> ___sys_sendmsg net/socket.c:2651 [inline]<br /> __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Freed by task 5235:<br /> kasan_save_stack mm/kasan/common.c:47<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7996: use hweight16 to get correct tx antenna<br /> <br /> The chainmask is u16 so using hweight8 cannot get correct tx_ant.<br /> Without this patch, the tx_ant of band 2 would be -1 and lead to the<br /> following issue:<br /> BUG: KASAN: stack-out-of-bounds in mt7996_mcu_add_sta+0x12e0/0x16e0 [mt7996e]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7915: fix oops on non-dbdc mt7986<br /> <br /> mt7915_band_config() sets band_idx = 1 on the main phy for mt7986<br /> with MT7975_ONE_ADIE or MT7976_ONE_ADIE.<br /> <br /> Commit 0335c034e726 ("wifi: mt76: fix race condition related to<br /> checking tx queue fill status") introduced a dereference of the<br /> phys array indirectly indexed by band_idx via wcid-&gt;phy_idx in<br /> mt76_wcid_cleanup(). This caused the following Oops on affected<br /> mt7986 devices:<br /> <br /> Unable to handle kernel read from unreadable memory at virtual address 0000000000000024<br /> Mem abort info:<br /> ESR = 0x0000000096000005<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x05: level 1 translation fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000005<br /> CM = 0, WnR = 0<br /> user pgtable: 4k pages, 39-bit VAs, pgdp=0000000042545000<br /> [0000000000000024] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000<br /> Internal error: Oops: 0000000096000005 [#1] SMP<br /> Modules linked in: ... mt7915e mt76_connac_lib mt76 mac80211 cfg80211 ...<br /> CPU: 2 PID: 1631 Comm: hostapd Not tainted 5.15.150 #0<br /> Hardware name: ZyXEL EX5700 (Telenor) (DT)<br /> pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : mt76_wcid_cleanup+0x84/0x22c [mt76]<br /> lr : mt76_wcid_cleanup+0x64/0x22c [mt76]<br /> sp : ffffffc00a803700<br /> x29: ffffffc00a803700 x28: ffffff80008f7300 x27: ffffff80003f3c00<br /> x26: ffffff80000a7880 x25: ffffffc008c26e00 x24: 0000000000000001<br /> x23: ffffffc000a68114 x22: 0000000000000000 x21: ffffff8004172cc8<br /> x20: ffffffc00a803748 x19: ffffff8004152020 x18: 0000000000000000<br /> x17: 00000000000017c0 x16: ffffffc008ef5000 x15: 0000000000000be0<br /> x14: ffffff8004172e28 x13: ffffff8004172e28 x12: 0000000000000000<br /> x11: 0000000000000000 x10: ffffff8004172e30 x9 : ffffff8004172e28<br /> x8 : 0000000000000000 x7 : ffffff8004156020 x6 : 0000000000000000<br /> x5 : 0000000000000031 x4 : 0000000000000000 x3 : 0000000000000001<br /> x2 : 0000000000000000 x1 : ffffff80008f7300 x0 : 0000000000000024<br /> Call trace:<br /> mt76_wcid_cleanup+0x84/0x22c [mt76]<br /> __mt76_sta_remove+0x70/0xbc [mt76]<br /> mt76_sta_state+0x8c/0x1a4 [mt76]<br /> mt7915_eeprom_get_power_delta+0x11e4/0x23a0 [mt7915e]<br /> drv_sta_state+0x144/0x274 [mac80211]<br /> sta_info_move_state+0x1cc/0x2a4 [mac80211]<br /> sta_set_sinfo+0xaf8/0xc24 [mac80211]<br /> sta_info_destroy_addr_bss+0x4c/0x6c [mac80211]<br /> <br /> ieee80211_color_change_finish+0x1c08/0x1e70 [mac80211]<br /> cfg80211_check_station_change+0x1360/0x4710 [cfg80211]<br /> genl_family_rcv_msg_doit+0xb4/0x110<br /> genl_rcv_msg+0xd0/0x1bc<br /> netlink_rcv_skb+0x58/0x120<br /> genl_rcv+0x34/0x50<br /> netlink_unicast+0x1f0/0x2ec<br /> netlink_sendmsg+0x198/0x3d0<br /> ____sys_sendmsg+0x1b0/0x210<br /> ___sys_sendmsg+0x80/0xf0<br /> __sys_sendmsg+0x44/0xa0<br /> __arm64_sys_sendmsg+0x20/0x30<br /> invoke_syscall.constprop.0+0x4c/0xe0<br /> do_el0_svc+0x40/0xd0<br /> el0_svc+0x14/0x4c<br /> el0t_64_sync_handler+0x100/0x110<br /> el0t_64_sync+0x15c/0x160<br /> Code: d2800002 910092c0 52800023 f9800011 (885f7c01)<br /> ---[ end trace 7e42dd9a39ed2281 ]---<br /> <br /> Fix by using mt76_dev_phy() which will map band_idx to the correct phy<br /> for all hardware combinations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: 9410/1: vfp: Use asm volatile in fmrx/fmxr macros<br /> <br /> Floating point instructions in userspace can crash some arm kernels<br /> built with clang/LLD 17.0.6:<br /> <br /> BUG: unsupported FP instruction in kernel mode<br /> FPEXC == 0xc0000780<br /> Internal error: Oops - undefined instruction: 0 [#1] ARM<br /> CPU: 0 PID: 196 Comm: vfp-reproducer Not tainted 6.10.0 #1<br /> Hardware name: BCM2835<br /> PC is at vfp_support_entry+0xc8/0x2cc<br /> LR is at do_undefinstr+0xa8/0x250<br /> pc : [] lr : [] psr: a0000013<br /> sp : dc8d1f68 ip : 60000013 fp : bedea19c<br /> r10: ec532b17 r9 : 00000010 r8 : 0044766c<br /> r7 : c0000780 r6 : ec532b17 r5 : c1c13800 r4 : dc8d1fb0<br /> r3 : c10072c4 r2 : c0101c88 r1 : ec532b17 r0 : 0044766c<br /> Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none<br /> Control: 00c5387d Table: 0251c008 DAC: 00000051<br /> Register r0 information: non-paged memory<br /> Register r1 information: vmalloc memory<br /> Register r2 information: non-slab/vmalloc memory<br /> Register r3 information: non-slab/vmalloc memory<br /> Register r4 information: 2-page vmalloc region<br /> Register r5 information: slab kmalloc-cg-2k<br /> Register r6 information: vmalloc memory<br /> Register r7 information: non-slab/vmalloc memory<br /> Register r8 information: non-paged memory<br /> Register r9 information: zero-size pointer<br /> Register r10 information: vmalloc memory<br /> Register r11 information: non-paged memory<br /> Register r12 information: non-paged memory<br /> Process vfp-reproducer (pid: 196, stack limit = 0x61aaaf8b)<br /> Stack: (0xdc8d1f68 to 0xdc8d2000)<br /> 1f60: 0000081f b6f69300 0000000f c10073f4 c10072c4 dc8d1fb0<br /> 1f80: ec532b17 0c532b17 0044766c b6f9ccd8 00000000 c010a80c 00447670 60000010<br /> 1fa0: ffffffff c1c13800 00c5387d c0100f10 b6f68af8 00448fc0 00000000 bedea188<br /> 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c<br /> 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff 00000000 00000000<br /> Call trace:<br /> [] (vfp_support_entry) from [] (do_undefinstr+0xa8/0x250)<br /> [] (do_undefinstr) from [] (__und_usr+0x70/0x80)<br /> Exception stack(0xdc8d1fb0 to 0xdc8d1ff8)<br /> 1fa0: b6f68af8 00448fc0 00000000 bedea188<br /> 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c<br /> 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff<br /> Code: 0a000061 e3877202 e594003c e3a09010 (eef16a10)<br /> ---[ end trace 0000000000000000 ]---<br /> Kernel panic - not syncing: Fatal exception in interrupt<br /> ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---<br /> <br /> This is a minimal userspace reproducer on a Raspberry Pi Zero W:<br /> <br /> #include <br /> #include <br /> <br /> int main(void)<br /> {<br /> double v = 1.0;<br /> printf("%fn", NAN + *(volatile double *)&amp;v);<br /> return 0;<br /> }<br /> <br /> Another way to consistently trigger the oops is:<br /> <br /> calvin@raspberry-pi-zero-w ~$ python -c "import json"<br /> <br /> The bug reproduces only when the kernel is built with DYNAMIC_DEBUG=n,<br /> because the pr_debug() calls act as barriers even when not activated.<br /> <br /> This is the output from the same kernel source built with the same<br /> compiler and DYNAMIC_DEBUG=y, where the userspace reproducer works as<br /> expected:<br /> <br /> VFP: bounce: trigger ec532b17 fpexc c0000780<br /> VFP: emulate: INST=0xee377b06 SCR=0x00000000<br /> VFP: bounce: trigger eef1fa10 fpexc c0000780<br /> VFP: emulate: INST=0xeeb40b40 SCR=0x00000000<br /> VFP: raising exceptions 30000000<br /> <br /> calvin@raspberry-pi-zero-w ~$ ./vfp-reproducer<br /> nan<br /> <br /> Crudely grepping for vmsr/vmrs instructions in the otherwise nearly<br /> idential text for vfp_support_entry() makes the problem obvious:<br /> <br /> vmlinux.llvm.good [0xc0101cb8] : vmrs r7, fpexc<br /> vmlinux.llvm.good [0xc0101cd8] : vmsr fpexc, r0<br /> vmlinux.llvm.good [0xc0101d20<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: fix potential invalid pointer dereference in blk_add_partition<br /> <br /> The blk_add_partition() function initially used a single if-condition<br /> (IS_ERR(part)) to check for errors when adding a partition. This was<br /> modified to handle the specific case of -ENXIO separately, allowing the<br /> function to proceed without logging the error in this case. However,<br /> this change unintentionally left a path where md_autodetect_dev()<br /> could be called without confirming that part is a valid pointer.<br /> <br /> This commit separates the error handling logic by splitting the<br /> initial if-condition, improving code readability and handling specific<br /> error scenarios explicitly. The function now distinguishes the general<br /> error case from -ENXIO without altering the existing behavior of<br /> md_autodetect_dev() calls.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block, bfq: fix possible UAF for bfqq-&gt;bic with merge chain<br /> <br /> 1) initial state, three tasks:<br /> <br /> Process 1 Process 2 Process 3<br /> (BIC1) (BIC2) (BIC3)<br /> | Λ | Λ | Λ<br /> | | | | | |<br /> V | V | V |<br /> bfqq1 bfqq2 bfqq3<br /> process ref: 1 1 1<br /> <br /> 2) bfqq1 merged to bfqq2:<br /> <br /> Process 1 Process 2 Process 3<br /> (BIC1) (BIC2) (BIC3)<br /> | | | Λ<br /> \--------------\| | |<br /> V V |<br /> bfqq1---------&gt;bfqq2 bfqq3<br /> process ref: 0 2 1<br /> <br /> 3) bfqq2 merged to bfqq3:<br /> <br /> Process 1 Process 2 Process 3<br /> (BIC1) (BIC2) (BIC3)<br /> here -&gt; Λ | |<br /> \--------------\ \-------------\|<br /> V V<br /> bfqq1---------&gt;bfqq2----------&gt;bfqq3<br /> process ref: 0 1 3<br /> <br /> In this case, IO from Process 1 will get bfqq2 from BIC1 first, and then<br /> get bfqq3 through merge chain, and finially handle IO by bfqq3.<br /> Howerver, current code will think bfqq2 is owned by BIC1, like initial<br /> state, and set bfqq2-&gt;bic to BIC1.<br /> <br /> bfq_insert_request<br /> -&gt; by Process 1<br /> bfqq = bfq_init_rq(rq)<br /> bfqq = bfq_get_bfqq_handle_split<br /> bfqq = bic_to_bfqq<br /> -&gt; get bfqq2 from BIC1<br /> bfqq-&gt;ref++<br /> rq-&gt;elv.priv[0] = bic<br /> rq-&gt;elv.priv[1] = bfqq<br /> if (bfqq_process_refs(bfqq) == 1)<br /> bfqq-&gt;bic = bic<br /> -&gt; record BIC1 to bfqq2<br /> <br /> __bfq_insert_request<br /> new_bfqq = bfq_setup_cooperator<br /> -&gt; get bfqq3 from bfqq2-&gt;new_bfqq<br /> bfqq_request_freed(bfqq)<br /> new_bfqq-&gt;ref++<br /> rq-&gt;elv.priv[1] = new_bfqq<br /> -&gt; handle IO by bfqq3<br /> <br /> Fix the problem by checking bfqq is from merge chain fist. And this<br /> might fix a following problem reported by our syzkaller(unreproducible):<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline]<br /> BUG: KASAN: slab-use-after-free in bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline]<br /> BUG: KASAN: slab-use-after-free in bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889<br /> Write of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595<br /> <br /> CPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G L 6.6.0-07439-gba2303cacfda #6<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> Workqueue: kblockd blk_mq_requeue_work<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106<br /> print_address_description mm/kasan/report.c:364 [inline]<br /> print_report+0x10d/0x610 mm/kasan/report.c:475<br /> kasan_report+0x8e/0xc0 mm/kasan/report.c:588<br /> bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline]<br /> bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline]<br /> bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889<br /> bfq_get_bfqq_handle_split+0x169/0x5d0 block/bfq-iosched.c:6757<br /> bfq_init_rq block/bfq-iosched.c:6876 [inline]<br /> bfq_insert_request block/bfq-iosched.c:6254 [inline]<br /> bfq_insert_requests+0x1112/0x5cf0 block/bfq-iosched.c:6304<br /> blk_mq_insert_request+0x290/0x8d0 block/blk-mq.c:2593<br /> blk_mq_requeue_work+0x6bc/0xa70 block/blk-mq.c:1502<br /> process_one_work kernel/workqueue.c:2627 [inline]<br /> process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700<br /> worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781<br /> kthread+0x33c/0x440 kernel/kthread.c:388<br /> ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305<br /> <br /> <br /> Allocated by task 20776:<br /> kasan_save_stack+0x20/0x40 mm/kasan/common.c:45<br /> kasan_set_track+0x25/0x30 mm/kasan/common.c:52<br /> __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328<br /> kasan_slab_alloc include/linux/kasan.h:188 [inline]<br /> slab_post_alloc_hook mm/slab.h:763 [inline]<br /> slab_alloc_node mm/slub.c:3458 [inline]<br /> kmem_cache_alloc_node+0x1a4/0x6f0 mm/slub.c:3503<br /> ioc_create_icq block/blk-ioc.c:370 [inline]<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev()<br /> <br /> Blamed commit accidentally removed a check for rt-&gt;rt6i_idev being NULL,<br /> as spotted by syzbot:<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI<br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> CPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024<br /> RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline]<br /> RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914<br /> Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06<br /> RSP: 0018:ffffc900047374e0 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000<br /> RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0<br /> RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8c<br /> R10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18<br /> R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930<br /> FS: 0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856<br /> addrconf_notify+0x3cb/0x1020<br /> notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93<br /> call_netdevice_notifiers_extack net/core/dev.c:2032 [inline]<br /> call_netdevice_notifiers net/core/dev.c:2046 [inline]<br /> unregister_netdevice_many_notify+0xd81/0x1c40 net/core/dev.c:11352<br /> unregister_netdevice_many net/core/dev.c:11414 [inline]<br /> unregister_netdevice_queue+0x303/0x370 net/core/dev.c:11289<br /> unregister_netdevice include/linux/netdevice.h:3129 [inline]<br /> __tun_detach+0x6b9/0x1600 drivers/net/tun.c:685<br /> tun_detach drivers/net/tun.c:701 [inline]<br /> tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510<br /> __fput+0x24a/0x8a0 fs/file_table.c:422<br /> task_work_run+0x24f/0x310 kernel/task_work.c:228<br /> exit_task_work include/linux/task_work.h:40 [inline]<br /> do_exit+0xa2f/0x27f0 kernel/exit.c:882<br /> do_group_exit+0x207/0x2c0 kernel/exit.c:1031<br /> __do_sys_exit_group kernel/exit.c:1042 [inline]<br /> __se_sys_exit_group kernel/exit.c:1040 [inline]<br /> __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040<br /> x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f1acc77def9<br /> Code: Unable to access opcode bytes at 0x7f1acc77decf.<br /> RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7<br /> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043<br /> RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001<br /> R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0<br /> <br /> Modules linked in:<br /> ---[ end trace 0000000000000000 ]---<br /> RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline]<br /> RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914<br /> Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06<br /> RSP: 0018:ffffc900047374e0 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000<br /> RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0<br /> R<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: bcm: Clear bo-&gt;bcm_proc_read after remove_proc_entry().<br /> <br /> syzbot reported a warning in bcm_release(). [0]<br /> <br /> The blamed change fixed another warning that is triggered when<br /> connect() is issued again for a socket whose connect()ed device has<br /> been unregistered.<br /> <br /> However, if the socket is just close()d without the 2nd connect(), the<br /> remaining bo-&gt;bcm_proc_read triggers unnecessary remove_proc_entry()<br /> in bcm_release().<br /> <br /> Let&amp;#39;s clear bo-&gt;bcm_proc_read after remove_proc_entry() in bcm_notify().<br /> <br /> [0]<br /> name &amp;#39;4986&amp;#39;<br /> WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024<br /> RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711<br /> Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07<br /> RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246<br /> RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a<br /> R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640<br /> R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000<br /> FS: 0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> bcm_release+0x250/0x880 net/can/bcm.c:1578<br /> __sock_release net/socket.c:659 [inline]<br /> sock_close+0xbc/0x240 net/socket.c:1421<br /> __fput+0x24a/0x8a0 fs/file_table.c:422<br /> task_work_run+0x24f/0x310 kernel/task_work.c:228<br /> exit_task_work include/linux/task_work.h:40 [inline]<br /> do_exit+0xa2f/0x27f0 kernel/exit.c:882<br /> do_group_exit+0x207/0x2c0 kernel/exit.c:1031<br /> __do_sys_exit_group kernel/exit.c:1042 [inline]<br /> __se_sys_exit_group kernel/exit.c:1040 [inline]<br /> __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040<br /> x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7fcfb51ee969<br /> Code: Unable to access opcode bytes at 0x7fcfb51ee93f.<br /> RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7<br /> RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969<br /> RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001<br /> RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000<br /> R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0<br /> R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sock_map: Add a cond_resched() in sock_hash_free()<br /> <br /> Several syzbot soft lockup reports all have in common sock_hash_free()<br /> <br /> If a map with a large number of buckets is destroyed, we need to yield<br /> the cpu when needed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: wilc1000: fix potential RCU dereference issue in wilc_parse_join_bss_param<br /> <br /> In the `wilc_parse_join_bss_param` function, the TSF field of the `ies`<br /> structure is accessed after the RCU read-side critical section is<br /> unlocked. According to RCU usage rules, this is illegal. Reusing this<br /> pointer can lead to unpredictable behavior, including accessing memory<br /> that has been updated or causing use-after-free issues.<br /> <br /> This possible bug was identified using a static analysis tool developed<br /> by myself, specifically designed to detect RCU-related issues.<br /> <br /> To address this, the TSF value is now stored in a local variable<br /> `ies_tsf` before the RCU lock is released. The `param-&gt;tsf_lo` field is<br /> then assigned using this local variable, ensuring that the TSF value is<br /> safely accessed.