Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PM / devfreq: Fix leak in devfreq_dev_release()<br /> <br /> srcu_init_notifier_head() allocates resources that need to be released<br /> with a srcu_cleanup_notifier_head() call.<br /> <br /> Reported by kmemleak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: pcie: Fix integer overflow in iwl_write_to_user_buf<br /> <br /> An integer overflow occurs in the iwl_write_to_user_buf() function,<br /> which is called by the iwl_dbgfs_monitor_data_read() function.<br /> <br /> static bool iwl_write_to_user_buf(char __user *user_buf, ssize_t count,<br /> void *buf, ssize_t *size,<br /> ssize_t *bytes_copied)<br /> {<br /> int buf_size_left = count - *bytes_copied;<br /> <br /> buf_size_left = buf_size_left - (buf_size_left % sizeof(u32));<br /> if (*size &gt; buf_size_left)<br /> *size = buf_size_left;<br /> <br /> If the user passes a SIZE_MAX value to the "ssize_t count" parameter,<br /> the ssize_t count parameter is assigned to "int buf_size_left".<br /> Then compare "*size" with "buf_size_left" . Here, "buf_size_left" is a<br /> negative number, so "*size" is assigned "buf_size_left" and goes into<br /> the third argument of the copy_to_user function, causing a heap overflow.<br /> <br /> This is not a security vulnerability because iwl_dbgfs_monitor_data_read()<br /> is a debugfs operation with 0400 privileges.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: gs_usb: fix time stamp counter initialization<br /> <br /> If the gs_usb device driver is unloaded (or unbound) before the<br /> interface is shut down, the USB stack first calls the struct<br /> usb_driver::disconnect and then the struct net_device_ops::ndo_stop<br /> callback.<br /> <br /> In gs_usb_disconnect() all pending bulk URBs are killed, i.e. no more<br /> RX&amp;#39;ed CAN frames are send from the USB device to the host. Later in<br /> gs_can_close() a reset control message is send to each CAN channel to<br /> remove the controller from the CAN bus. In this race window the USB<br /> device can still receive CAN frames from the bus and internally queue<br /> them to be send to the host.<br /> <br /> At least in the current version of the candlelight firmware, the queue<br /> of received CAN frames is not emptied during the reset command. After<br /> loading (or binding) the gs_usb driver, new URBs are submitted during<br /> the struct net_device_ops::ndo_open callback and the candlelight<br /> firmware starts sending its already queued CAN frames to the host.<br /> <br /> However, this scenario was not considered when implementing the<br /> hardware timestamp function. The cycle counter/time counter<br /> infrastructure is set up (gs_usb_timestamp_init()) after the USBs are<br /> submitted, resulting in a NULL pointer dereference if<br /> timecounter_cyc2time() (via the call chain:<br /> gs_usb_receive_bulk_callback() -&gt; gs_usb_set_timestamp() -&gt;<br /> gs_usb_skb_set_timestamp()) is called too early.<br /> <br /> Move the gs_usb_timestamp_init() function before the URBs are<br /> submitted to fix this problem.<br /> <br /> For a comprehensive solution, we need to consider gs_usb devices with<br /> more than 1 channel. The cycle counter/time counter infrastructure is<br /> setup per channel, but the RX URBs are per device. Once gs_can_open()<br /> of _a_ channel has been called, and URBs have been submitted, the<br /> gs_usb_receive_bulk_callback() can be called for _all_ available<br /> channels, even for channels that are not running, yet. As cycle<br /> counter/time counter has not set up, this will again lead to a NULL<br /> pointer dereference.<br /> <br /> Convert the cycle counter/time counter from a "per channel" to a "per<br /> device" functionality. Also set it up, before submitting any URBs to<br /> the device.<br /> <br /> Further in gs_usb_receive_bulk_callback(), don&amp;#39;t process any URBs for<br /> not started CAN channels, only resubmit the URB.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cgroup,freezer: hold cpu_hotplug_lock before freezer_mutex<br /> <br /> syzbot is reporting circular locking dependency between cpu_hotplug_lock<br /> and freezer_mutex, for commit f5d39b020809 ("freezer,sched: Rewrite core<br /> freezer logic") replaced atomic_inc() in freezer_apply_state() with<br /> static_branch_inc() which holds cpu_hotplug_lock.<br /> <br /> cpu_hotplug_lock =&gt; cgroup_threadgroup_rwsem =&gt; freezer_mutex<br /> <br /> cgroup_file_write() {<br /> cgroup_procs_write() {<br /> __cgroup_procs_write() {<br /> cgroup_procs_write_start() {<br /> cgroup_attach_lock() {<br /> cpus_read_lock() {<br /> percpu_down_read(&amp;cpu_hotplug_lock);<br /> }<br /> percpu_down_write(&amp;cgroup_threadgroup_rwsem);<br /> }<br /> }<br /> cgroup_attach_task() {<br /> cgroup_migrate() {<br /> cgroup_migrate_execute() {<br /> freezer_attach() {<br /> mutex_lock(&amp;freezer_mutex);<br /> (...snipped...)<br /> }<br /> }<br /> }<br /> }<br /> (...snipped...)<br /> }<br /> }<br /> }<br /> <br /> freezer_mutex =&gt; cpu_hotplug_lock<br /> <br /> cgroup_file_write() {<br /> freezer_write() {<br /> freezer_change_state() {<br /> mutex_lock(&amp;freezer_mutex);<br /> freezer_apply_state() {<br /> static_branch_inc(&amp;freezer_active) {<br /> static_key_slow_inc() {<br /> cpus_read_lock();<br /> static_key_slow_inc_cpuslocked();<br /> cpus_read_unlock();<br /> }<br /> }<br /> }<br /> mutex_unlock(&amp;freezer_mutex);<br /> }<br /> }<br /> }<br /> <br /> Swap locking order by moving cpus_read_lock() in freezer_apply_state()<br /> to before mutex_lock(&amp;freezer_mutex) in freezer_change_state().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ses: Fix slab-out-of-bounds in ses_intf_remove()<br /> <br /> A fix for:<br /> <br /> BUG: KASAN: slab-out-of-bounds in ses_intf_remove+0x23f/0x270 [ses]<br /> Read of size 8 at addr ffff88a10d32e5d8 by task rmmod/12013<br /> <br /> When edev-&gt;components is zero, accessing edev-&gt;component[0] members is<br /> wrong.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: v4l2-mem2mem: add lock to protect parameter num_rdy<br /> <br /> Getting below error when using KCSAN to check the driver. Adding lock to<br /> protect parameter num_rdy when getting the value with function:<br /> v4l2_m2m_num_src_bufs_ready/v4l2_m2m_num_dst_bufs_ready.<br /> <br /> kworker/u16:3: [name:report&amp;]BUG: KCSAN: data-race in v4l2_m2m_buf_queue<br /> kworker/u16:3: [name:report&amp;]<br /> <br /> kworker/u16:3: [name:report&amp;]read-write to 0xffffff8105f35b94 of 1 bytes by task 20865 on cpu 7:<br /> kworker/u16:3:  v4l2_m2m_buf_queue+0xd8/0x10c

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: Fix hci_suspend_sync crash<br /> <br /> If hci_unregister_dev() frees the hci_dev object but hci_suspend_notifier<br /> may still be accessing it, it can cause the program to crash.<br /> Here&amp;#39;s the call trace:<br /> [102152.653246] Call Trace:<br /> [102152.653254] hci_suspend_sync+0x109/0x301 [bluetooth]<br /> [102152.653259] hci_suspend_dev+0x78/0xcd [bluetooth]<br /> [102152.653263] hci_suspend_notifier+0x42/0x7a [bluetooth]<br /> [102152.653268] notifier_call_chain+0x43/0x6b<br /> [102152.653271] __blocking_notifier_call_chain+0x48/0x69<br /> [102152.653273] __pm_notifier_call_chain+0x22/0x39<br /> [102152.653276] pm_suspend+0x287/0x57c<br /> [102152.653278] state_store+0xae/0xe5<br /> [102152.653281] kernfs_fop_write+0x109/0x173<br /> [102152.653284] __vfs_write+0x16f/0x1a2<br /> [102152.653287] ? selinux_file_permission+0xca/0x16f<br /> [102152.653289] ? security_file_permission+0x36/0x109<br /> [102152.653291] vfs_write+0x114/0x21d<br /> [102152.653293] __x64_sys_write+0x7b/0xdb<br /> [102152.653296] do_syscall_64+0x59/0x194<br /> [102152.653299] entry_SYSCALL_64_after_hwframe+0x5c/0xc1<br /> <br /> This patch holds the reference count of the hci_dev object while<br /> processing it in hci_suspend_notifier to avoid potential crash<br /> caused by the race condition.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpt3sas: Fix a memory leak<br /> <br /> Add a forgotten kfree().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpu: host1x: Fix memory leak of device names<br /> <br /> The device names allocated by dev_set_name() need be freed<br /> before module unloading, but they can not be freed because<br /> the kobject&amp;#39;s refcount which was set in device_initialize()<br /> has not be decreased to 0.<br /> <br /> As comment of device_add() says, if it fails, use only<br /> put_device() drop the refcount, then the name will be<br /> freed in kobejct_cleanup().<br /> <br /> device_del() and put_device() can be replaced with<br /> device_unregister(), so call it to unregister the added<br /> successfully devices, and just call put_device() to the<br /> not added device.<br /> <br /> Add a release() function to device to avoid null release()<br /> function WARNING in device_release(), it&amp;#39;s empty, because<br /> the context devices are freed together in<br /> host1x_memory_context_list_free().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: do not update mtu if msg_max is too small in mtu negotiation<br /> <br /> When doing link mtu negotiation, a malicious peer may send Activate msg<br /> with a very small mtu, e.g. 4 in Shuang&amp;#39;s testing, without checking for<br /> the minimum mtu, l-&gt;mtu will be set to 4 in tipc_link_proto_rcv(), then<br /> n-&gt;links[bearer_id].mtu is set to 4294967228, which is a overflow of<br /> &amp;#39;4 - INT_H_SIZE - EMSG_OVERHEAD&amp;#39; in tipc_link_mss().<br /> <br /> With tipc_link.mtu = 4, tipc_link_xmit() kept printing the warning:<br /> <br /> tipc: Too large msg, purging xmit list 1 5 0 40 4!<br /> tipc: Too large msg, purging xmit list 1 15 0 60 4!<br /> <br /> And with tipc_link_entry.mtu 4294967228, a huge skb was allocated in<br /> named_distribute(), and when purging it in tipc_link_xmit(), a crash<br /> was even caused:<br /> <br /> general protection fault, probably for non-canonical address 0x2100001011000dd: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 0 PID: 0 Comm: swapper/0 Kdump: loaded Not tainted 6.3.0.neta #19<br /> RIP: 0010:kfree_skb_list_reason+0x7e/0x1f0<br /> Call Trace:<br /> <br /> skb_release_data+0xf9/0x1d0<br /> kfree_skb_reason+0x40/0x100<br /> tipc_link_xmit+0x57a/0x740 [tipc]<br /> tipc_node_xmit+0x16c/0x5c0 [tipc]<br /> tipc_named_node_up+0x27f/0x2c0 [tipc]<br /> tipc_node_write_unlock+0x149/0x170 [tipc]<br /> tipc_rcv+0x608/0x740 [tipc]<br /> tipc_udp_recv+0xdc/0x1f0 [tipc]<br /> udp_queue_rcv_one_skb+0x33e/0x620<br /> udp_unicast_rcv_skb.isra.72+0x75/0x90<br /> __udp4_lib_rcv+0x56d/0xc20<br /> ip_protocol_deliver_rcu+0x100/0x2d0<br /> <br /> This patch fixes it by checking the new mtu against tipc_bearer_min_mtu(),<br /> and not updating mtu if it is too small.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> macvlan: add forgotten nla_policy for IFLA_MACVLAN_BC_CUTOFF<br /> <br /> The previous commit 954d1fa1ac93 ("macvlan: Add netlink attribute for<br /> broadcast cutoff") added one additional attribute named<br /> IFLA_MACVLAN_BC_CUTOFF to allow broadcast cutfoff.<br /> <br /> However, it forgot to describe the nla_policy at macvlan_policy<br /> (drivers/net/macvlan.c). Hence, this suppose NLA_S32 (4 bytes) integer<br /> can be faked as empty (0 bytes) by a malicious user, which could leads<br /> to OOB in heap just like CVE-2023-3773.<br /> <br /> To fix it, this commit just completes the nla_policy description for<br /> IFLA_MACVLAN_BC_CUTOFF. This enforces the length check and avoids the<br /> potential OOB read.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio-mmio: don&amp;#39;t break lifecycle of vm_dev<br /> <br /> vm_dev has a separate lifecycle because it has a &amp;#39;struct device&amp;#39;<br /> embedded. Thus, having a release callback for it is correct.<br /> <br /> Allocating the vm_dev struct with devres totally breaks this protection,<br /> though. Instead of waiting for the vm_dev release callback, the memory<br /> is freed when the platform_device is removed. Resulting in a<br /> use-after-free when finally the callback is to be called.<br /> <br /> To easily see the problem, compile the kernel with<br /> CONFIG_DEBUG_KOBJECT_RELEASE and unbind with sysfs.<br /> <br /> The fix is easy, don&amp;#39;t use devres in this case.<br /> <br /> Found during my research about object lifetime problems.