Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: dvb-frontends: avoid stack overflow warnings with clang<br /> <br /> A previous patch worked around a KASAN issue in stv0367, now a similar<br /> problem showed up with clang:<br /> <br /> drivers/media/dvb-frontends/stv0367.c:1222:12: error: stack frame size (3624) exceeds limit (2048) in &amp;#39;stv0367ter_set_frontend&amp;#39; [-Werror,-Wframe-larger-than]<br /> 1214 | static int stv0367ter_set_frontend(struct dvb_frontend *fe)<br /> <br /> Rework the stv0367_writereg() function to be simpler and mark both<br /> register access functions as noinline_for_stack so the temporary<br /> i2c_msg structures do not get duplicated on the stack when KASAN_STACK<br /> is enabled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7925e: fix use-after-free in free_irq()<br /> <br /> From commit a304e1b82808 ("[PATCH] Debug shared irqs"), there is a test<br /> to make sure the shared irq handler should be able to handle the unexpected<br /> event after deregistration. For this case, let&amp;#39;s apply MT76_REMOVED flag to<br /> indicate the device was removed and do not run into the resource access<br /> anymore.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libbpf: Use OPTS_SET() macro in bpf_xdp_query()<br /> <br /> When the feature_flags and xdp_zc_max_segs fields were added to the libbpf<br /> bpf_xdp_query_opts, the code writing them did not use the OPTS_SET() macro.<br /> This causes libbpf to write to those fields unconditionally, which means<br /> that programs compiled against an older version of libbpf (with a smaller<br /> size of the bpf_xdp_query_opts struct) will have its stack corrupted by<br /> libbpf writing out of bounds.<br /> <br /> The patch adding the feature_flags field has an early bail out if the<br /> feature_flags field is not part of the opts struct (via the OPTS_HAS)<br /> macro, but the patch adding xdp_zc_max_segs does not. For consistency, this<br /> fix just changes the assignments to both fields to use the OPTS_SET()<br /> macro.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get&amp;#39;s return value<br /> <br /> cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it<br /> and return 0 in case of error.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtl8xxxu: add cancel_work_sync() for c2hcmd_work<br /> <br /> The workqueue might still be running, when the driver is stopped. To<br /> avoid a use-after-free, call cancel_work_sync() in rtl8xxxu_stop().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: wilc1000: fix RCU usage in connect path<br /> <br /> With lockdep enabled, calls to the connect function from cfg802.11 layer<br /> lead to the following warning:<br /> <br /> =============================<br /> WARNING: suspicious RCU usage<br /> 6.7.0-rc1-wt+ #333 Not tainted<br /> -----------------------------<br /> drivers/net/wireless/microchip/wilc1000/hif.c:386<br /> suspicious rcu_dereference_check() usage!<br /> [...]<br /> stack backtrace:<br /> CPU: 0 PID: 100 Comm: wpa_supplicant Not tainted 6.7.0-rc1-wt+ #333<br /> Hardware name: Atmel SAMA5<br /> unwind_backtrace from show_stack+0x18/0x1c<br /> show_stack from dump_stack_lvl+0x34/0x48<br /> dump_stack_lvl from wilc_parse_join_bss_param+0x7dc/0x7f4<br /> wilc_parse_join_bss_param from connect+0x2c4/0x648<br /> connect from cfg80211_connect+0x30c/0xb74<br /> cfg80211_connect from nl80211_connect+0x860/0xa94<br /> nl80211_connect from genl_rcv_msg+0x3fc/0x59c<br /> genl_rcv_msg from netlink_rcv_skb+0xd0/0x1f8<br /> netlink_rcv_skb from genl_rcv+0x2c/0x3c<br /> genl_rcv from netlink_unicast+0x3b0/0x550<br /> netlink_unicast from netlink_sendmsg+0x368/0x688<br /> netlink_sendmsg from ____sys_sendmsg+0x190/0x430<br /> ____sys_sendmsg from ___sys_sendmsg+0x110/0x158<br /> ___sys_sendmsg from sys_sendmsg+0xe8/0x150<br /> sys_sendmsg from ret_fast_syscall+0x0/0x1c<br /> <br /> This warning is emitted because in the connect path, when trying to parse<br /> target BSS parameters, we dereference a RCU pointer whithout being in RCU<br /> critical section.<br /> Fix RCU dereference usage by moving it to a RCU read critical section. To<br /> avoid wrapping the whole wilc_parse_join_bss_param under the critical<br /> section, just use the critical section to copy ies data

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/dasd: fix double module refcount decrement<br /> <br /> Once the discipline is associated with the device, deleting the device<br /> takes care of decrementing the module&amp;#39;s refcount. Doing it manually on<br /> this error path causes refcount to artificially decrease on each error<br /> while it should just stay the same.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: SOF: ipc4-pcm: Workaround for crashed firmware on system suspend<br /> <br /> When the system is suspended while audio is active, the<br /> sof_ipc4_pcm_hw_free() is invoked to reset the pipelines since during<br /> suspend the DSP is turned off, streams will be re-started after resume.<br /> <br /> If the firmware crashes during while audio is running (or when we reset<br /> the stream before suspend) then the sof_ipc4_set_multi_pipeline_state()<br /> will fail with IPC error and the state change is interrupted.<br /> This will cause misalignment between the kernel and firmware state on next<br /> DSP boot resulting errors returned by firmware for IPC messages, eventually<br /> failing the audio resume.<br /> On stream close the errors are ignored so the kernel state will be<br /> corrected on the next DSP boot, so the second boot after the DSP panic.<br /> <br /> If sof_ipc4_trigger_pipelines() is called from sof_ipc4_pcm_hw_free() then<br /> state parameter is SOF_IPC4_PIPE_RESET and only in this case.<br /> <br /> Treat a forced pipeline reset similarly to how we treat a pcm_free by<br /> ignoring error on state sending to allow the kernel&amp;#39;s state to be<br /> consistent with the state the firmware will have after the next boot.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tmpfs: fix race on handling dquot rbtree<br /> <br /> A syzkaller reproducer found a race while attempting to remove dquot<br /> information from the rb tree.<br /> <br /> Fetching the rb_tree root node must also be protected by the<br /> dqopt-&gt;dqio_sem, otherwise, giving the right timing, shmem_release_dquot()<br /> will trigger a warning because it couldn&amp;#39;t find a node in the tree, when<br /> the real reason was the root node changing before the search starts:<br /> <br /> Thread 1 Thread 2<br /> - shmem_release_dquot() - shmem_{acquire,release}_dquot()<br /> <br /> - fetch ROOT - Fetch ROOT<br /> <br /> - acquire dqio_sem<br /> - wait dqio_sem<br /> <br /> - do something, triger a tree rebalance<br /> - release dqio_sem<br /> <br /> - acquire dqio_sem<br /> - start searching for the node, but<br /> from the wrong location, missing<br /> the node, and triggering a warning.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: usb-storage: Prevent divide-by-0 error in isd200_ata_command<br /> <br /> The isd200 sub-driver in usb-storage uses the HEADS and SECTORS values<br /> in the ATA ID information to calculate cylinder and head values when<br /> creating a CDB for READ or WRITE commands. The calculation involves<br /> division and modulus operations, which will cause a crash if either of<br /> these values is 0. While this never happens with a genuine device, it<br /> could happen with a flawed or subversive emulation, as reported by the<br /> syzbot fuzzer.<br /> <br /> Protect against this possibility by refusing to bind to the device if<br /> either the ATA_ID_HEADS or ATA_ID_SECTORS value in the device&amp;#39;s ID<br /> information is 0. This requires isd200_Initialization() to return a<br /> negative error code when initialization fails; currently it always<br /> returns 0 (even when there is an error).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thunderbolt: Fix NULL pointer dereference in tb_port_update_credits()<br /> <br /> Olliver reported that his system crashes when plugging in Thunderbolt 1<br /> device:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000020<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> RIP: 0010:tb_port_do_update_credits+0x1b/0x130 [thunderbolt]<br /> Call Trace:<br /> <br /> ? __die+0x23/0x70<br /> ? page_fault_oops+0x171/0x4e0<br /> ? exc_page_fault+0x7f/0x180<br /> ? asm_exc_page_fault+0x26/0x30<br /> ? tb_port_do_update_credits+0x1b/0x130<br /> ? tb_switch_update_link_attributes+0x83/0xd0<br /> tb_switch_add+0x7a2/0xfe0<br /> tb_scan_port+0x236/0x6f0<br /> tb_handle_hotplug+0x6db/0x900<br /> process_one_work+0x171/0x340<br /> worker_thread+0x27b/0x3a0<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0xe5/0x120<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x31/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> <br /> This is due the fact that some Thunderbolt 1 devices only have one lane<br /> adapter. Fix this by checking for the lane 1 before we read its credits.