Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf: RISC-V: Remove PERF_HES_STOPPED flag checking in riscv_pmu_start()<br /> <br /> Since commit 096b52fd2bb4 ("perf: RISC-V: throttle perf events") the<br /> perf_sample_event_took() function was added to report time spent in<br /> overflow interrupts. If the interrupt takes too long, the perf framework<br /> will lower the sysctl_perf_event_sample_rate and max_samples_per_tick.<br /> When hwc-&gt;interrupts is larger than max_samples_per_tick, the<br /> hwc-&gt;interrupts will be set to MAX_INTERRUPTS, and events will be<br /> throttled within the __perf_event_account_interrupt() function.<br /> <br /> However, the RISC-V PMU driver doesn&amp;#39;t call riscv_pmu_stop() to update the<br /> PERF_HES_STOPPED flag after perf_event_overflow() in pmu_sbi_ovf_handler()<br /> function to avoid throttling. When the perf framework unthrottled the event<br /> in the timer interrupt handler, it triggers riscv_pmu_start() function<br /> and causes a WARN_ON_ONCE() warning, as shown below:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 240 at drivers/perf/riscv_pmu.c:184 riscv_pmu_start+0x7c/0x8e<br /> Modules linked in:<br /> CPU: 0 PID: 240 Comm: ls Not tainted 6.4-rc4-g19d0788e9ef2 #1<br /> Hardware name: SiFive (DT)<br /> epc : riscv_pmu_start+0x7c/0x8e<br /> ra : riscv_pmu_start+0x28/0x8e<br /> epc : ffffffff80aef864 ra : ffffffff80aef810 sp : ffff8f80004db6f0<br /> gp : ffffffff81c83750 tp : ffffaf80069f9bc0 t0 : ffff8f80004db6c0<br /> t1 : 0000000000000000 t2 : 000000000000001f s0 : ffff8f80004db720<br /> s1 : ffffaf8008ca1068 a0 : 0000ffffffffffff a1 : 0000000000000000<br /> a2 : 0000000000000001 a3 : 0000000000000870 a4 : 0000000000000000<br /> a5 : 0000000000000000 a6 : 0000000000000840 a7 : 0000000000000030<br /> s2 : 0000000000000000 s3 : ffffaf8005165800 s4 : ffffaf800424da00<br /> s5 : ffffffffffffffff s6 : ffffffff81cc7590 s7 : 0000000000000000<br /> s8 : 0000000000000006 s9 : 0000000000000001 s10: ffffaf807efbc340<br /> s11: ffffaf807efbbf00 t3 : ffffaf8006a16028 t4 : 00000000dbfbb796<br /> t5 : 0000000700000000 t6 : ffffaf8005269870<br /> status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003<br /> [] riscv_pmu_start+0x7c/0x8e<br /> [] perf_adjust_freq_unthr_context+0x15e/0x174<br /> [] perf_event_task_tick+0x88/0x9c<br /> [] scheduler_tick+0xfe/0x27c<br /> [] update_process_times+0x9a/0xba<br /> [] tick_sched_handle+0x32/0x66<br /> [] tick_sched_timer+0x64/0xb0<br /> [] __hrtimer_run_queues+0x156/0x2f4<br /> [] hrtimer_interrupt+0xe2/0x1fe<br /> [] riscv_timer_interrupt+0x38/0x42<br /> [] handle_percpu_devid_irq+0x90/0x1d2<br /> [] generic_handle_domain_irq+0x28/0x36<br /> <br /> After referring other PMU drivers like Arm, Loongarch, Csky, and Mips,<br /> they don&amp;#39;t call *_pmu_stop() to update with PERF_HES_STOPPED flag<br /> after perf_event_overflow() function nor do they add PERF_HES_STOPPED<br /> flag checking in *_pmu_start() which don&amp;#39;t cause this warning.<br /> <br /> Thus, it&amp;#39;s recommended to remove this unnecessary check in<br /> riscv_pmu_start() function to prevent this warning.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: Fix multiple LUN_RESET handling<br /> <br /> This fixes a bug where an initiator thinks a LUN_RESET has cleaned up<br /> running commands when it hasn&amp;#39;t. The bug was added in commit 51ec502a3266<br /> ("target: Delete tmr from list before processing").<br /> <br /> The problem occurs when:<br /> <br /> 1. We have N I/O cmds running in the target layer spread over 2 sessions.<br /> <br /> 2. The initiator sends a LUN_RESET for each session.<br /> <br /> 3. session1&amp;#39;s LUN_RESET loops over all the running commands from both<br /> sessions and moves them to its local drain_task_list.<br /> <br /> 4. session2&amp;#39;s LUN_RESET does not see the LUN_RESET from session1 because<br /> the commit above has it remove itself. session2 also does not see any<br /> commands since the other reset moved them off the state lists.<br /> <br /> 5. sessions2&amp;#39;s LUN_RESET will then complete with a successful response.<br /> <br /> 6. sessions2&amp;#39;s inititor believes the running commands on its session are<br /> now cleaned up due to the successful response and cleans up the running<br /> commands from its side. It then restarts them.<br /> <br /> 7. The commands do eventually complete on the backend and the target<br /> starts to return aborted task statuses for them. The initiator will<br /> either throw a invalid ITT error or might accidentally lookup a new<br /> task if the ITT has been reallocated already.<br /> <br /> Fix the bug by reverting the patch, and serialize the execution of<br /> LUN_RESETs and Preempt and Aborts.<br /> <br /> Also prevent us from waiting on LUN_RESETs in core_tmr_drain_tmr_list,<br /> because it turns out the original patch fixed a bug that was not<br /> mentioned. For LUN_RESET1 core_tmr_drain_tmr_list can see a second<br /> LUN_RESET and wait on it. Then the second reset will run<br /> core_tmr_drain_tmr_list and see the first reset and wait on it resulting in<br /> a deadlock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw88: delete timer and free skb queue when unloading<br /> <br /> Fix possible crash and memory leak on driver unload by deleting<br /> TX purge timer and freeing C2H queue in &amp;#39;rtw_core_deinit()&amp;#39;,<br /> shrink critical section in the latter by freeing COEX queue<br /> out of TX report lock scope.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mvm: fix potential array out of bounds access<br /> <br /> Account for IWL_SEC_WEP_KEY_OFFSET when needed while verifying<br /> key_len size in iwl_mvm_sec_key_add().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> null_blk: Always check queue mode setting from configfs<br /> <br /> Make sure to check device queue mode in the null_validate_conf() and<br /> return error for NULL_Q_RQ as we don&amp;#39;t allow legacy I/O path, without<br /> this patch we get OOPs when queue mode is set to 1 from configfs,<br /> following are repro steps :-<br /> <br /> modprobe null_blk nr_devices=0<br /> mkdir config/nullb/nullb0<br /> echo 1 &gt; config/nullb/nullb0/memory_backed<br /> echo 4096 &gt; config/nullb/nullb0/blocksize<br /> echo 20480 &gt; config/nullb/nullb0/size<br /> echo 1 &gt; config/nullb/nullb0/queue_mode<br /> echo 1 &gt; config/nullb/nullb0/power<br /> <br /> Entering kdb (current=0xffff88810acdd080, pid 2372) on processor 42 Oops: (null)<br /> due to oops @ 0xffffffffc041c329<br /> CPU: 42 PID: 2372 Comm: sh Tainted: G O N 6.3.0-rc5lblk+ #5<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:null_add_dev.part.0+0xd9/0x720 [null_blk]<br /> Code: 01 00 00 85 d2 0f 85 a1 03 00 00 48 83 bb 08 01 00 00 00 0f 85 f7 03 00 00 80 bb 62 01 00 00 00 48 8b 75 20 0f 85 6d 02 00 00 89 6e 60 48 8b 75 20 bf 06 00 00 00 e8 f5 37 2c c1 48 8b 75 20<br /> RSP: 0018:ffffc900052cbde0 EFLAGS: 00010246<br /> RAX: 0000000000000001 RBX: ffff88811084d800 RCX: 0000000000000001<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888100042e00<br /> RBP: ffff8881053d8200 R08: ffffc900052cbd68 R09: ffff888105db2000<br /> R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000002<br /> R13: ffff888104765200 R14: ffff88810eec1748 R15: ffff88810eec1740<br /> FS: 00007fd445fd1740(0000) GS:ffff8897dfc80000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000060 CR3: 0000000166a00000 CR4: 0000000000350ee0<br /> DR0: ffffffff8437a488 DR1: ffffffff8437a489 DR2: ffffffff8437a48a<br /> DR3: ffffffff8437a48b DR6: 00000000ffff0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> nullb_device_power_store+0xd1/0x120 [null_blk]<br /> configfs_write_iter+0xb4/0x120<br /> vfs_write+0x2ba/0x3c0<br /> ksys_write+0x5f/0xe0<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> RIP: 0033:0x7fd4460c57a7<br /> Code: 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24<br /> RSP: 002b:00007ffd3792a4a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fd4460c57a7<br /> RDX: 0000000000000002 RSI: 000055b43c02e4c0 RDI: 0000000000000001<br /> RBP: 000055b43c02e4c0 R08: 000000000000000a R09: 00007fd44615b4e0<br /> R10: 00007fd44615b3e0 R11: 0000000000000246 R12: 0000000000000002<br /> R13: 00007fd446198520 R14: 0000000000000002 R15: 00007fd446198700<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Check for NOT_READY flag state after locking<br /> <br /> Currently the check for NOT_READY flag is performed before obtaining the<br /> necessary lock. This opens a possibility for race condition when the flow<br /> is concurrently removed from unready_flows list by the workqueue task,<br /> which causes a double-removal from the list and a crash[0]. Fix the issue<br /> by moving the flag check inside the section protected by<br /> uplink_priv-&gt;unready_flows_lock mutex.<br /> <br /> [0]:<br /> [44376.389654] general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP<br /> [44376.391665] CPU: 7 PID: 59123 Comm: tc Not tainted 6.4.0-rc4+ #1<br /> [44376.392984] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> [44376.395342] RIP: 0010:mlx5e_tc_del_fdb_flow+0xb3/0x340 [mlx5_core]<br /> [44376.396857] Code: 00 48 8b b8 68 ce 02 00 e8 8a 4d 02 00 4c 8d a8 a8 01 00 00 4c 89 ef e8 8b 79 88 e1 48 8b 83 98 06 00 00 48 8b 93 90 06 00 00 89 42 08 48 89 10 48 b8 00 01 00 00 00 00 ad de 48 89 83 90 06<br /> [44376.399167] RSP: 0018:ffff88812cc97570 EFLAGS: 00010246<br /> [44376.399680] RAX: dead000000000122 RBX: ffff8881088e3800 RCX: ffff8881881bac00<br /> [44376.400337] RDX: dead000000000100 RSI: ffff88812cc97500 RDI: ffff8881242f71b0<br /> [44376.401001] RBP: ffff88811cbb0940 R08: 0000000000000400 R09: 0000000000000001<br /> [44376.401663] R10: 0000000000000001 R11: 0000000000000000 R12: ffff88812c944000<br /> [44376.402342] R13: ffff8881242f71a8 R14: ffff8881222b4000 R15: 0000000000000000<br /> [44376.402999] FS: 00007f0451104800(0000) GS:ffff88852cb80000(0000) knlGS:0000000000000000<br /> [44376.403787] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [44376.404343] CR2: 0000000000489108 CR3: 0000000123a79003 CR4: 0000000000370ea0<br /> [44376.405004] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [44376.405665] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [44376.406339] Call Trace:<br /> [44376.406651] <br /> [44376.406939] ? die_addr+0x33/0x90<br /> [44376.407311] ? exc_general_protection+0x192/0x390<br /> [44376.407795] ? asm_exc_general_protection+0x22/0x30<br /> [44376.408292] ? mlx5e_tc_del_fdb_flow+0xb3/0x340 [mlx5_core]<br /> [44376.408876] __mlx5e_tc_del_fdb_peer_flow+0xbc/0xe0 [mlx5_core]<br /> [44376.409482] mlx5e_tc_del_flow+0x42/0x210 [mlx5_core]<br /> [44376.410055] mlx5e_flow_put+0x25/0x50 [mlx5_core]<br /> [44376.410529] mlx5e_delete_flower+0x24b/0x350 [mlx5_core]<br /> [44376.411043] tc_setup_cb_reoffload+0x22/0x80<br /> [44376.411462] fl_reoffload+0x261/0x2f0 [cls_flower]<br /> [44376.411907] ? mlx5e_rep_indr_setup_ft_cb+0x160/0x160 [mlx5_core]<br /> [44376.412481] ? mlx5e_rep_indr_setup_ft_cb+0x160/0x160 [mlx5_core]<br /> [44376.413044] tcf_block_playback_offloads+0x76/0x170<br /> [44376.413497] tcf_block_unbind+0x7b/0xd0<br /> [44376.413881] tcf_block_setup+0x17d/0x1c0<br /> [44376.414269] tcf_block_offload_cmd.isra.0+0xf1/0x130<br /> [44376.414725] tcf_block_offload_unbind+0x43/0x70<br /> [44376.415153] __tcf_block_put+0x82/0x150<br /> [44376.415532] ingress_destroy+0x22/0x30 [sch_ingress]<br /> [44376.415986] qdisc_destroy+0x3b/0xd0<br /> [44376.416343] qdisc_graft+0x4d0/0x620<br /> [44376.416706] tc_get_qdisc+0x1c9/0x3b0<br /> [44376.417074] rtnetlink_rcv_msg+0x29c/0x390<br /> [44376.419978] ? rep_movs_alternative+0x3a/0xa0<br /> [44376.420399] ? rtnl_calcit.isra.0+0x120/0x120<br /> [44376.420813] netlink_rcv_skb+0x54/0x100<br /> [44376.421192] netlink_unicast+0x1f6/0x2c0<br /> [44376.421573] netlink_sendmsg+0x232/0x4a0<br /> [44376.421980] sock_sendmsg+0x38/0x60<br /> [44376.422328] ____sys_sendmsg+0x1d0/0x1e0<br /> [44376.422709] ? copy_msghdr_from_user+0x6d/0xa0<br /> [44376.423127] ___sys_sendmsg+0x80/0xc0<br /> [44376.423495] ? ___sys_recvmsg+0x8b/0xc0<br /> [44376.423869] __sys_sendmsg+0x51/0x90<br /> [44376.424226] do_syscall_64+0x3d/0x90<br /> [44376.424587] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> [44376.425046] RIP: 0033:0x7f045134f887<br /> [44376.425403] Code: 0a 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: brcmfmac: ensure CLM version is null-terminated to prevent stack-out-of-bounds<br /> <br /> Fix a stack-out-of-bounds read in brcmfmac that occurs<br /> when &amp;#39;buf&amp;#39; that is not null-terminated is passed as an argument of<br /> strreplace() in brcmf_c_preinit_dcmds(). This buffer is filled with<br /> a CLM version string by memcpy() in brcmf_fil_iovar_data_get().<br /> Ensure buf is null-terminated.<br /> <br /> Found by a modified version of syzkaller.<br /> <br /> [ 33.004414][ T1896] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available<br /> [ 33.013486][ T1896] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43236/3 wl0: Nov 30 2011 17:33:42 version 5.90.188.22<br /> [ 33.021554][ T1896] ==================================================================<br /> [ 33.022379][ T1896] BUG: KASAN: stack-out-of-bounds in strreplace+0xf2/0x110<br /> [ 33.023122][ T1896] Read of size 1 at addr ffffc90001d6efc8 by task kworker/0:2/1896<br /> [ 33.023852][ T1896]<br /> [ 33.024096][ T1896] CPU: 0 PID: 1896 Comm: kworker/0:2 Tainted: G O 5.14.0+ #132<br /> [ 33.024927][ T1896] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014<br /> [ 33.026065][ T1896] Workqueue: usb_hub_wq hub_event<br /> [ 33.026581][ T1896] Call Trace:<br /> [ 33.026896][ T1896] dump_stack_lvl+0x57/0x7d<br /> [ 33.027372][ T1896] print_address_description.constprop.0.cold+0xf/0x334<br /> [ 33.028037][ T1896] ? strreplace+0xf2/0x110<br /> [ 33.028403][ T1896] ? strreplace+0xf2/0x110<br /> [ 33.028807][ T1896] kasan_report.cold+0x83/0xdf<br /> [ 33.029283][ T1896] ? strreplace+0xf2/0x110<br /> [ 33.029666][ T1896] strreplace+0xf2/0x110<br /> [ 33.029966][ T1896] brcmf_c_preinit_dcmds+0xab1/0xc40<br /> [ 33.030351][ T1896] ? brcmf_c_set_joinpref_default+0x100/0x100<br /> [ 33.030787][ T1896] ? rcu_read_lock_sched_held+0xa1/0xd0<br /> [ 33.031223][ T1896] ? rcu_read_lock_bh_held+0xb0/0xb0<br /> [ 33.031661][ T1896] ? lock_acquire+0x19d/0x4e0<br /> [ 33.032091][ T1896] ? find_held_lock+0x2d/0x110<br /> [ 33.032605][ T1896] ? brcmf_usb_deq+0x1a7/0x260<br /> [ 33.033087][ T1896] ? brcmf_usb_rx_fill_all+0x5a/0xf0<br /> [ 33.033582][ T1896] brcmf_attach+0x246/0xd40<br /> [ 33.034022][ T1896] ? wiphy_new_nm+0x1476/0x1d50<br /> [ 33.034383][ T1896] ? kmemdup+0x30/0x40<br /> [ 33.034722][ T1896] brcmf_usb_probe+0x12de/0x1690<br /> [ 33.035223][ T1896] ? brcmf_usbdev_qinit.constprop.0+0x470/0x470<br /> [ 33.035833][ T1896] usb_probe_interface+0x25f/0x710<br /> [ 33.036315][ T1896] really_probe+0x1be/0xa90<br /> [ 33.036656][ T1896] __driver_probe_device+0x2ab/0x460<br /> [ 33.037026][ T1896] ? usb_match_id.part.0+0x88/0xc0<br /> [ 33.037383][ T1896] driver_probe_device+0x49/0x120<br /> [ 33.037790][ T1896] __device_attach_driver+0x18a/0x250<br /> [ 33.038300][ T1896] ? driver_allows_async_probing+0x120/0x120<br /> [ 33.038986][ T1896] bus_for_each_drv+0x123/0x1a0<br /> [ 33.039906][ T1896] ? bus_rescan_devices+0x20/0x20<br /> [ 33.041412][ T1896] ? lockdep_hardirqs_on_prepare+0x273/0x3e0<br /> [ 33.041861][ T1896] ? trace_hardirqs_on+0x1c/0x120<br /> [ 33.042330][ T1896] __device_attach+0x207/0x330<br /> [ 33.042664][ T1896] ? device_bind_driver+0xb0/0xb0<br /> [ 33.043026][ T1896] ? kobject_uevent_env+0x230/0x12c0<br /> [ 33.043515][ T1896] bus_probe_device+0x1a2/0x260<br /> [ 33.043914][ T1896] device_add+0xa61/0x1ce0<br /> [ 33.044227][ T1896] ? __mutex_unlock_slowpath+0xe7/0x660<br /> [ 33.044891][ T1896] ? __fw_devlink_link_to_suppliers+0x550/0x550<br /> [ 33.045531][ T1896] usb_set_configuration+0x984/0x1770<br /> [ 33.046051][ T1896] ? kernfs_create_link+0x175/0x230<br /> [ 33.046548][ T1896] usb_generic_driver_probe+0x69/0x90<br /> [ 33.046931][ T1896] usb_probe_device+0x9c/0x220<br /> [ 33.047434][ T1896] really_probe+0x1be/0xa90<br /> [ 33.047760][ T1896] __driver_probe_device+0x2ab/0x460<br /> [ 33.048134][ T1896] driver_probe_device+0x49/0x120<br /> [ 33.048516][ T1896] __device_attach_driver+0x18a/0x250<br /> [ 33.048910][ T1896] ? driver_allows_async_probing+0x120/0x120<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: Gadget: core: Help prevent panic during UVC unconfigure<br /> <br /> Avichal Rakesh reported a kernel panic that occurred when the UVC<br /> gadget driver was removed from a gadget&amp;#39;s configuration. The panic<br /> involves a somewhat complicated interaction between the kernel driver<br /> and a userspace component (as described in the Link tag below), but<br /> the analysis did make one thing clear: The Gadget core should<br /> accomodate gadget drivers calling usb_gadget_deactivate() as part of<br /> their unbind procedure.<br /> <br /> Currently this doesn&amp;#39;t work. gadget_unbind_driver() calls<br /> driver-&gt;unbind() while holding the udc-&gt;connect_lock mutex, and<br /> usb_gadget_deactivate() attempts to acquire that mutex, which will<br /> result in a deadlock.<br /> <br /> The simple fix is for gadget_unbind_driver() to release the mutex when<br /> invoking the -&gt;unbind() callback. There is no particular reason for<br /> it to be holding the mutex at that time, and the mutex isn&amp;#39;t held<br /> while the -&gt;bind() callback is invoked. So we&amp;#39;ll drop the mutex<br /> before performing the unbind callback and reacquire it afterward.<br /> <br /> We&amp;#39;ll also add a couple of comments to usb_gadget_activate() and<br /> usb_gadget_deactivate(). Because they run in process context they<br /> must not be called from a gadget driver&amp;#39;s -&gt;disconnect() callback,<br /> which (according to the kerneldoc for struct usb_gadget_driver in<br /> include/linux/usb/gadget.h) may run in interrupt context. This may<br /> help prevent similar bugs from arising in the future.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: mvebu: fix irq domain leak<br /> <br /> Uwe Kleine-König pointed out we still have one resource leak in the mvebu<br /> driver triggered on driver detach. Let&amp;#39;s address it with a custom devm<br /> action.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: qrtr: Fix an uninit variable access bug in qrtr_tx_resume()<br /> <br /> Syzbot reported a bug as following:<br /> <br /> =====================================================<br /> BUG: KMSAN: uninit-value in qrtr_tx_resume+0x185/0x1f0 net/qrtr/af_qrtr.c:230<br /> qrtr_tx_resume+0x185/0x1f0 net/qrtr/af_qrtr.c:230<br /> qrtr_endpoint_post+0xf85/0x11b0 net/qrtr/af_qrtr.c:519<br /> qrtr_tun_write_iter+0x270/0x400 net/qrtr/tun.c:108<br /> call_write_iter include/linux/fs.h:2189 [inline]<br /> aio_write+0x63a/0x950 fs/aio.c:1600<br /> io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019<br /> __do_sys_io_submit fs/aio.c:2078 [inline]<br /> __se_sys_io_submit+0x293/0x770 fs/aio.c:2048<br /> __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slab.h:766 [inline]<br /> slab_alloc_node mm/slub.c:3452 [inline]<br /> __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491<br /> __do_kmalloc_node mm/slab_common.c:967 [inline]<br /> __kmalloc_node_track_caller+0x114/0x3b0 mm/slab_common.c:988<br /> kmalloc_reserve net/core/skbuff.c:492 [inline]<br /> __alloc_skb+0x3af/0x8f0 net/core/skbuff.c:565<br /> __netdev_alloc_skb+0x120/0x7d0 net/core/skbuff.c:630<br /> qrtr_endpoint_post+0xbd/0x11b0 net/qrtr/af_qrtr.c:446<br /> qrtr_tun_write_iter+0x270/0x400 net/qrtr/tun.c:108<br /> call_write_iter include/linux/fs.h:2189 [inline]<br /> aio_write+0x63a/0x950 fs/aio.c:1600<br /> io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019<br /> __do_sys_io_submit fs/aio.c:2078 [inline]<br /> __se_sys_io_submit+0x293/0x770 fs/aio.c:2048<br /> __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> It is because that skb-&gt;len requires at least sizeof(struct qrtr_ctrl_pkt)<br /> in qrtr_tx_resume(). And skb-&gt;len equals to size in qrtr_endpoint_post().<br /> But size is less than sizeof(struct qrtr_ctrl_pkt) when qrtr_cb-&gt;type<br /> equals to QRTR_TYPE_RESUME_TX in qrtr_endpoint_post() under the syzbot<br /> scenario. This triggers the uninit variable access bug.<br /> <br /> Add size check when qrtr_cb-&gt;type equals to QRTR_TYPE_RESUME_TX in<br /> qrtr_endpoint_post() to fix the bug.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, cpumap: Make sure kthread is running before map update returns<br /> <br /> The following warning was reported when running stress-mode enabled<br /> xdp_redirect_cpu with some RT threads:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 4 PID: 65 at kernel/bpf/cpumap.c:135<br /> CPU: 4 PID: 65 Comm: kworker/4:1 Not tainted 6.5.0-rc2+ #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)<br /> Workqueue: events cpu_map_kthread_stop<br /> RIP: 0010:put_cpu_map_entry+0xda/0x220<br /> ......<br /> Call Trace:<br /> <br /> ? show_regs+0x65/0x70<br /> ? __warn+0xa5/0x240<br /> ......<br /> ? put_cpu_map_entry+0xda/0x220<br /> cpu_map_kthread_stop+0x41/0x60<br /> process_one_work+0x6b0/0xb80<br /> worker_thread+0x96/0x720<br /> kthread+0x1a5/0x1f0<br /> ret_from_fork+0x3a/0x70<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> <br /> The root cause is the same as commit 436901649731 ("bpf: cpumap: Fix memory<br /> leak in cpu_map_update_elem"). The kthread is stopped prematurely by<br /> kthread_stop() in cpu_map_kthread_stop(), and kthread() doesn&amp;#39;t call<br /> cpu_map_kthread_run() at all but XDP program has already queued some<br /> frames or skbs into ptr_ring. So when __cpu_map_ring_cleanup() checks<br /> the ptr_ring, it will find it was not emptied and report a warning.<br /> <br /> An alternative fix is to use __cpu_map_ring_cleanup() to drop these<br /> pending frames or skbs when kthread_stop() returns -EINTR, but it may<br /> confuse the user, because these frames or skbs have been handled<br /> correctly by XDP program. So instead of dropping these frames or skbs,<br /> just make sure the per-cpu kthread is running before<br /> __cpu_map_entry_alloc() returns.<br /> <br /> After apply the fix, the error handle for kthread_stop() will be<br /> unnecessary because it will always return 0, so just remove it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext2: Check block size validity during mount<br /> <br /> Check that log of block size stored in the superblock has sensible<br /> value. Otherwise the shift computing the block size can overflow leading<br /> to undefined behavior.