Vulnerabilities

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 /> 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 /> io_uring: fix fget leak when fs don&amp;#39;t support nowait buffered read<br /> <br /> Heming reported a BUG when using io_uring doing link-cp on ocfs2. [1]<br /> <br /> Do the following steps can reproduce this BUG:<br /> mount -t ocfs2 /dev/vdc /mnt/ocfs2<br /> cp testfile /mnt/ocfs2/<br /> ./link-cp /mnt/ocfs2/testfile /mnt/ocfs2/testfile.1<br /> umount /mnt/ocfs2<br /> <br /> Then umount will fail, and it outputs:<br /> umount: /mnt/ocfs2: target is busy.<br /> <br /> While tracing umount, it blames mnt_get_count() not return as expected.<br /> Do a deep investigation for fget()/fput() on related code flow, I&amp;#39;ve<br /> finally found that fget() leaks since ocfs2 doesn&amp;#39;t support nowait<br /> buffered read.<br /> <br /> io_issue_sqe<br /> |-io_assign_file // do fget() first<br /> |-io_read<br /> |-io_iter_do_read<br /> |-ocfs2_file_read_iter // return -EOPNOTSUPP<br /> |-kiocb_done<br /> |-io_rw_done<br /> |-__io_complete_rw_common // set REQ_F_REISSUE<br /> |-io_resubmit_prep<br /> |-io_req_prep_async // override req-&gt;file, leak happens<br /> <br /> This was introduced by commit a196c78b5443 in v5.18. Fix it by don&amp;#39;t<br /> re-assign req-&gt;file if it has already been assigned.<br /> <br /> [1] https://lore.kernel.org/ocfs2-devel/ab580a75-91c8-d68a-3455-40361be1bfa8@linux.alibaba.com/T/#t

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 /> nbd: fix incomplete validation of ioctl arg<br /> <br /> We tested and found an alarm caused by nbd_ioctl arg without verification.<br /> The UBSAN warning calltrace like below:<br /> <br /> UBSAN: Undefined behaviour in fs/buffer.c:1709:35<br /> signed integer overflow:<br /> -9223372036854775808 - 1 cannot be represented in type &amp;#39;long long int&amp;#39;<br /> CPU: 3 PID: 2523 Comm: syz-executor.0 Not tainted 4.19.90 #1<br /> Hardware name: linux,dummy-virt (DT)<br /> Call trace:<br /> dump_backtrace+0x0/0x3f0 arch/arm64/kernel/time.c:78<br /> show_stack+0x28/0x38 arch/arm64/kernel/traps.c:158<br /> __dump_stack lib/dump_stack.c:77 [inline]<br /> dump_stack+0x170/0x1dc lib/dump_stack.c:118<br /> ubsan_epilogue+0x18/0xb4 lib/ubsan.c:161<br /> handle_overflow+0x188/0x1dc lib/ubsan.c:192<br /> __ubsan_handle_sub_overflow+0x34/0x44 lib/ubsan.c:206<br /> __block_write_full_page+0x94c/0xa20 fs/buffer.c:1709<br /> block_write_full_page+0x1f0/0x280 fs/buffer.c:2934<br /> blkdev_writepage+0x34/0x40 fs/block_dev.c:607<br /> __writepage+0x68/0xe8 mm/page-writeback.c:2305<br /> write_cache_pages+0x44c/0xc70 mm/page-writeback.c:2240<br /> generic_writepages+0xdc/0x148 mm/page-writeback.c:2329<br /> blkdev_writepages+0x2c/0x38 fs/block_dev.c:2114<br /> do_writepages+0xd4/0x250 mm/page-writeback.c:2344<br /> <br /> The reason for triggering this warning is __block_write_full_page()<br /> -&gt; i_size_read(inode) - 1 overflow.<br /> inode-&gt;i_size is assigned in __nbd_ioctl() -&gt; nbd_set_size() -&gt; bytesize.<br /> We think it is necessary to limit the size of arg to prevent errors.<br /> <br /> Moreover, __nbd_ioctl() -&gt; nbd_add_socket(), arg will be cast to int.<br /> Assuming the value of arg is 0x80000000000000001) (on a 64-bit machine),<br /> it will become 1 after the coercion, which will return unexpected results.<br /> <br /> Fix it by adding checks to prevent passing in too large numbers.

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 /> 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.

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 /> 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 /> RDMA/bnxt_re: Properly order ib_device_unalloc() to avoid UAF<br /> <br /> ib_dealloc_device() should be called only after device cleanup. Fix the<br /> dealloc sequence.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: tegra: tegra124-emc: Fix potential memory leak<br /> <br /> The tegra and tegra needs to be freed in the error handling path, otherwise<br /> it will be leaked.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udf: Do not bother merging very long extents<br /> <br /> When merging very long extents we try to push as much length as possible<br /> to the first extent. However this is unnecessarily complicated and not<br /> really worth the trouble. Furthermore there was a bug in the logic<br /> resulting in corrupting extents in the file as syzbot reproducer shows.<br /> So just don&amp;#39;t bother with the merging of extents that are too long<br /> together.