Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: chips-media: wave5: Fix device cleanup order to prevent kernel panic<br /> <br /> Move video device unregistration to the beginning of the remove function<br /> to ensure all video operations are stopped before cleaning up the worker<br /> thread and disabling PM runtime. This prevents hardware register access<br /> after the device has been powered down.<br /> <br /> In polling mode, the hrtimer periodically triggers<br /> wave5_vpu_timer_callback() which queues work to the kthread worker.<br /> The worker executes wave5_vpu_irq_work_fn() which reads hardware<br /> registers via wave5_vdi_read_register().<br /> <br /> The original cleanup order disabled PM runtime and powered down hardware<br /> before unregistering video devices. When autosuspend triggers and powers<br /> off the hardware, the video devices are still registered and the worker<br /> thread can still be triggered by the hrtimer, causing it to attempt<br /> reading registers from powered-off hardware. This results in a bus error<br /> (synchronous external abort) and kernel panic.<br /> <br /> This causes random kernel panics during encoding operations:<br /> <br /> Internal error: synchronous external abort: 0000000096000010<br /> [#1] PREEMPT SMP<br /> Modules linked in: wave5 rpmsg_ctrl rpmsg_char ...<br /> CPU: 0 UID: 0 PID: 1520 Comm: vpu_irq_thread<br /> Tainted: G M W<br /> pc : wave5_vdi_read_register+0x10/0x38 [wave5]<br /> lr : wave5_vpu_irq_work_fn+0x28/0x60 [wave5]<br /> Call trace:<br /> wave5_vdi_read_register+0x10/0x38 [wave5]<br /> kthread_worker_fn+0xd8/0x238<br /> kthread+0x104/0x120<br /> ret_from_fork+0x10/0x20<br /> Code: aa1e03e9 d503201f f9416800 8b214000 (b9400000)<br /> ---[ end trace 0000000000000000 ]---<br /> Kernel panic - not syncing: synchronous external abort:<br /> Fatal exception

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clocksource/drivers/sh_tmu: Always leave device running after probe<br /> <br /> The TMU device can be used as both a clocksource and a clockevent<br /> provider. The driver tries to be smart and power itself on and off, as<br /> well as enabling and disabling its clock when it&amp;#39;s not in operation.<br /> This behavior is slightly altered if the TMU is used as an early<br /> platform device in which case the device is left powered on after probe,<br /> but the clock is still enabled and disabled at runtime.<br /> <br /> This has worked for a long time, but recent improvements in PREEMPT_RT<br /> and PROVE_LOCKING have highlighted an issue. As the TMU registers itself<br /> as a clockevent provider, clockevents_register_device(), it needs to use<br /> raw spinlocks internally as this is the context of which the clockevent<br /> framework interacts with the TMU driver. However in the context of<br /> holding a raw spinlock the TMU driver can&amp;#39;t really manage its power<br /> state or clock with calls to pm_runtime_*() and clk_*() as these calls<br /> end up in other platform drivers using regular spinlocks to control<br /> power and clocks.<br /> <br /> This mix of spinlock contexts trips a lockdep warning.<br /> <br /> =============================<br /> [ BUG: Invalid wait context ]<br /> 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 Not tainted<br /> -----------------------------<br /> swapper/0/0 is trying to lock:<br /> ffff000008c9e180 (&amp;dev-&gt;power.lock){-...}-{3:3}, at: __pm_runtime_resume+0x38/0x88<br /> other info that might help us debug this:<br /> context-{5:5}<br /> 1 lock held by swapper/0/0:<br /> ccree e6601000.crypto: ARM CryptoCell 630P Driver: HW version 0xAF400001/0xDCC63000, Driver version 5.0<br /> #0: ffff8000817ec298<br /> ccree e6601000.crypto: ARM ccree device initialized<br /> (tick_broadcast_lock){-...}-{2:2}, at: __tick_broadcast_oneshot_control+0xa4/0x3a8<br /> stack backtrace:<br /> CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 PREEMPT<br /> Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT)<br /> Call trace:<br /> show_stack+0x14/0x1c (C)<br /> dump_stack_lvl+0x6c/0x90<br /> dump_stack+0x14/0x1c<br /> __lock_acquire+0x904/0x1584<br /> lock_acquire+0x220/0x34c<br /> _raw_spin_lock_irqsave+0x58/0x80<br /> __pm_runtime_resume+0x38/0x88<br /> sh_tmu_clock_event_set_oneshot+0x84/0xd4<br /> clockevents_switch_state+0xfc/0x13c<br /> tick_broadcast_set_event+0x30/0xa4<br /> __tick_broadcast_oneshot_control+0x1e0/0x3a8<br /> tick_broadcast_oneshot_control+0x30/0x40<br /> cpuidle_enter_state+0x40c/0x680<br /> cpuidle_enter+0x30/0x40<br /> do_idle+0x1f4/0x280<br /> cpu_startup_entry+0x34/0x40<br /> kernel_init+0x0/0x130<br /> do_one_initcall+0x0/0x230<br /> __primary_switched+0x88/0x90<br /> <br /> For non-PREEMPT_RT builds this is not really an issue, but for<br /> PREEMPT_RT builds where normal spinlocks can sleep this might be an<br /> issue. Be cautious and always leave the power and clock running after<br /> probe.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/zcrx: fix sgtable leak on mapping failures<br /> <br /> In an unlikely case when io_populate_area_dma() fails, which could only<br /> happen on a PAGE_POOL_32BIT_ARCH_WITH_64BIT_DMA machine,<br /> io_zcrx_map_area() will have an initialised and not freed table. It was<br /> supposed to be cleaned up in the error path, but !is_mapped prevents<br /> that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: pvrusb2: fix URB leak in pvr2_send_request_ex<br /> <br /> When pvr2_send_request_ex() submits a write URB successfully but fails to<br /> submit the read URB (e.g. returns -ENOMEM), it returns immediately without<br /> waiting for the write URB to complete. Since the driver reuses the same<br /> URB structure, a subsequent call to pvr2_send_request_ex() attempts to<br /> submit the still-active write URB, triggering a &amp;#39;URB submitted while<br /> active&amp;#39; warning in usb_submit_urb().<br /> <br /> Fix this by ensuring the write URB is unlinked and waited upon if the read<br /> URB submission fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfs: Replace BUG_ON with error handling for CNID count checks<br /> <br /> In a06ec283e125 next_id, folder_count, and file_count in the super block<br /> info were expanded to 64 bits, and BUG_ONs were added to detect<br /> overflow. This triggered an error reported by syzbot: if the MDB is<br /> corrupted, the BUG_ON is triggered. This patch replaces this mechanism<br /> with proper error handling and resolves the syzbot reported bug.<br /> <br /> Singed-off-by: Jori Koolstra

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/rds: No shortcut out of RDS_CONN_ERROR<br /> <br /> RDS connections carry a state "rds_conn_path::cp_state"<br /> and transitions from one state to another and are conditional<br /> upon an expected state: "rds_conn_path_transition."<br /> <br /> There is one exception to this conditionality, which is<br /> "RDS_CONN_ERROR" that can be enforced by "rds_conn_path_drop"<br /> regardless of what state the condition is currently in.<br /> <br /> But as soon as a connection enters state "RDS_CONN_ERROR",<br /> the connection handling code expects it to go through the<br /> shutdown-path.<br /> <br /> The RDS/TCP multipath changes added a shortcut out of<br /> "RDS_CONN_ERROR" straight back to "RDS_CONN_CONNECTING"<br /> via "rds_tcp_accept_one_path" (e.g. after "rds_tcp_state_change").<br /> <br /> A subsequent "rds_tcp_reset_callbacks" can then transition<br /> the state to "RDS_CONN_RESETTING" with a shutdown-worker queued.<br /> <br /> That&amp;#39;ll trip up "rds_conn_init_shutdown", which was<br /> never adjusted to handle "RDS_CONN_RESETTING" and subsequently<br /> drops the connection with the dreaded "DR_INV_CONN_STATE",<br /> which leaves "RDS_SHUTDOWN_WORK_QUEUED" on forever.<br /> <br /> So we do two things here:<br /> <br /> a) Don&amp;#39;t shortcut "RDS_CONN_ERROR", but take the longer<br /> path through the shutdown code.<br /> <br /> b) Add "RDS_CONN_RESETTING" to the expected states in<br /> "rds_conn_init_shutdown" so that we won&amp;#39;t error out<br /> and get stuck, if we ever hit weird state transitions<br /> like this again."

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/rds: Clear reconnect pending bit<br /> <br /> When canceling the reconnect worker, care must be taken to reset the<br /> reconnect-pending bit. If the reconnect worker has not yet been<br /> scheduled before it is canceled, the reconnect-pending bit will stay<br /> on forever.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8723bs: fix memory leak on failure path<br /> <br /> cfg80211_inform_bss_frame() may return NULL on failure. In that case,<br /> the allocated buffer &amp;#39;buf&amp;#39; is not freed and the function returns early,<br /> leading to potential memory leak.<br /> Fix this by ensuring that &amp;#39;buf&amp;#39; is freed on both success and failure paths.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: Drop the lock in skb_may_tx_timestamp()<br /> <br /> skb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock must<br /> not be taken in IRQ context, only softirq is okay. A few drivers receive<br /> the timestamp via a dedicated interrupt and complete the TX timestamp<br /> from that handler. This will lead to a deadlock if the lock is already<br /> write-locked on the same CPU.<br /> <br /> Taking the lock can be avoided. The socket (pointed by the skb) will<br /> remain valid until the skb is released. The -&gt;sk_socket and -&gt;file<br /> member will be set to NULL once the user closes the socket which may<br /> happen before the timestamp arrives.<br /> If we happen to observe the pointer while the socket is closing but<br /> before the pointer is set to NULL then we may use it because both<br /> pointer (and the file&amp;#39;s cred member) are RCU freed.<br /> <br /> Drop the lock. Use READ_ONCE() to obtain the individual pointer. Add a<br /> matching WRITE_ONCE() where the pointer are cleared.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: iris: gen2: Add sanity check for session stop<br /> <br /> In iris_kill_session, inst-&gt;state is set to IRIS_INST_ERROR and<br /> session_close is executed, which will kfree(inst_hfi_gen2-&gt;packet).<br /> If stop_streaming is called afterward, it will cause a crash.<br /> <br /> Add a NULL check for inst_hfi_gen2-&gt;packet before sendling STOP packet<br /> to firmware to fix that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: i2c/tw9903: Fix potential memory leak in tw9903_probe()<br /> <br /> In one of the error paths in tw9903_probe(), the memory allocated in<br /> v4l2_ctrl_handler_init() and v4l2_ctrl_new_std() is not freed. Fix that<br /> by calling v4l2_ctrl_handler_free() on the handler in that error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: cpsw_new: Fix potential unregister of netdev that has not been registered yet<br /> <br /> If an error occurs during register_netdev() for the first MAC in<br /> cpsw_register_ports(), even though cpsw-&gt;slaves[0].ndev is set to NULL,<br /> cpsw-&gt;slaves[1].ndev would remain unchanged. This could later cause<br /> cpsw_unregister_ports() to attempt unregistering the second MAC.<br /> To address this, add a check for ndev-&gt;reg_state before calling<br /> unregister_netdev(). With this change, setting cpsw-&gt;slaves[i].ndev<br /> to NULL becomes unnecessary and can be removed accordingly.