Vulnerabilities

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.

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 /> 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 /> qed: allow sleep in qed_mcp_trace_dump()<br /> <br /> By default, qed_mcp_cmd_and_union() delays 10us at a time in a loop<br /> that can run 500K times, so calls to qed_mcp_nvm_rd_cmd()<br /> may block the current thread for over 5s.<br /> We observed thread scheduling delays over 700ms in production,<br /> with stacktraces pointing to this code as the culprit.<br /> <br /> qed_mcp_trace_dump() is called from ethtool, so sleeping is permitted.<br /> It already can sleep in qed_mcp_halt(), which calls qed_mcp_cmd().<br /> Add a "can sleep" parameter to qed_find_nvram_image() and<br /> qed_nvram_read() so they can sleep during qed_mcp_trace_dump().<br /> qed_mcp_trace_get_meta_info() and qed_mcp_trace_read_meta(),<br /> called only by qed_mcp_trace_dump(), allow these functions to sleep.<br /> I can&amp;#39;t tell if the other caller (qed_grc_dump_mcp_hw_dump()) can sleep,<br /> so keep b_can_sleep set to false when it calls these functions.<br /> <br /> An example stacktrace from a custom warning we added to the kernel<br /> showing a thread that has not scheduled despite long needing resched:<br /> [ 2745.362925,17] ------------[ cut here ]------------<br /> [ 2745.362941,17] WARNING: CPU: 23 PID: 5640 at arch/x86/kernel/irq.c:233 do_IRQ+0x15e/0x1a0()<br /> [ 2745.362946,17] Thread not rescheduled for 744 ms after irq 99<br /> [ 2745.362956,17] Modules linked in: ...<br /> [ 2745.363339,17] CPU: 23 PID: 5640 Comm: lldpd Tainted: P O 4.4.182+ #202104120910+6d1da174272d.61x<br /> [ 2745.363343,17] Hardware name: FOXCONN MercuryB/Quicksilver Controller, BIOS H11P1N09 07/08/2020<br /> [ 2745.363346,17] 0000000000000000 ffff885ec07c3ed8 ffffffff8131eb2f ffff885ec07c3f20<br /> [ 2745.363358,17] ffffffff81d14f64 ffff885ec07c3f10 ffffffff81072ac2 ffff88be98ed0000<br /> [ 2745.363369,17] 0000000000000063 0000000000000174 0000000000000074 0000000000000000<br /> [ 2745.363379,17] Call Trace:<br /> [ 2745.363382,17] [] dump_stack+0x8e/0xcf<br /> [ 2745.363393,17] [] warn_slowpath_common+0x82/0xc0<br /> [ 2745.363398,17] [] warn_slowpath_fmt+0x4c/0x50<br /> [ 2745.363404,17] [] ? rcu_irq_exit+0xae/0xc0<br /> [ 2745.363408,17] [] do_IRQ+0x15e/0x1a0<br /> [ 2745.363413,17] [] common_interrupt+0x89/0x89<br /> [ 2745.363416,17] [] ? delay_tsc+0x24/0x50<br /> [ 2745.363425,17] [] __udelay+0x34/0x40<br /> [ 2745.363457,17] [] qed_mcp_cmd_and_union+0x36f/0x7d0 [qed]<br /> [ 2745.363473,17] [] qed_mcp_nvm_rd_cmd+0x4d/0x90 [qed]<br /> [ 2745.363490,17] [] qed_mcp_trace_dump+0x4a7/0x630 [qed]<br /> [ 2745.363504,17] [] ? qed_fw_asserts_dump+0x1d6/0x1f0 [qed]<br /> [ 2745.363520,17] [] qed_dbg_mcp_trace_get_dump_buf_size+0x37/0x80 [qed]<br /> [ 2745.363536,17] [] qed_dbg_feature_size+0x61/0xa0 [qed]<br /> [ 2745.363551,17] [] qed_dbg_all_data_size+0x247/0x260 [qed]<br /> [ 2745.363560,17] [] qede_get_regs_len+0x30/0x40 [qede]<br /> [ 2745.363566,17] [] ethtool_get_drvinfo+0xe3/0x190<br /> [ 2745.363570,17] [] dev_ethtool+0x1362/0x2140<br /> [ 2745.363575,17] [] ? finish_task_switch+0x76/0x260<br /> [ 2745.363580,17] [] ? __schedule+0x3c6/0x9d0<br /> [ 2745.363585,17] [] ? hrtimer_start_range_ns+0x1d0/0x370<br /> [ 2745.363589,17] [] ? dev_get_by_name_rcu+0x6b/0x90<br /> [ 2745.363594,17] [] dev_ioctl+0xe8/0x710<br /> [ 2745.363599,17] [] sock_do_ioctl+0x48/0x60<br /> [ 2745.363603,17] [] sock_ioctl+0x1c7/0x280<br /> [ 2745.363608,17] [] ? seccomp_phase1+0x83/0x220<br /> [ 2745.363612,17] [] do_vfs_ioctl+0x2b3/0x4e0<br /> [ 2745.363616,17] [] SyS_ioctl+0x41/0x70<br /> [ 2745.363619,17] [] entry_SYSCALL_64_fastpath+0x1e/0x79<br /> [ 2745.363622,17] ---[ end trace f6954aa440266421 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ublk: fail to start device if queue setup is interrupted<br /> <br /> In ublk_ctrl_start_dev(), if wait_for_completion_interruptible() is<br /> interrupted by signal, queues aren&amp;#39;t setup successfully yet, so we<br /> have to fail UBLK_CMD_START_DEV, otherwise kernel oops can be triggered.<br /> <br /> Reported by German when working on qemu-storage-deamon which requires<br /> single thread ublk daemon.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Unregister devlink params in case interface is down<br /> <br /> Currently, in case an interface is down, mlx5 driver doesn&amp;#39;t<br /> unregister its devlink params, which leads to this WARN[1].<br /> Fix it by unregistering devlink params in that case as well.<br /> <br /> [1]<br /> [ 295.244769 ] WARNING: CPU: 15 PID: 1 at net/core/devlink.c:9042 devlink_free+0x174/0x1fc<br /> [ 295.488379 ] CPU: 15 PID: 1 Comm: shutdown Tainted: G S OE 5.15.0-1017.19.3.g0677e61-bluefield #g0677e61<br /> [ 295.509330 ] Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS 4.2.0.12761 Jun 6 2023<br /> [ 295.543096 ] pc : devlink_free+0x174/0x1fc<br /> [ 295.551104 ] lr : mlx5_devlink_free+0x18/0x2c [mlx5_core]<br /> [ 295.561816 ] sp : ffff80000809b850<br /> [ 295.711155 ] Call trace:<br /> [ 295.716030 ] devlink_free+0x174/0x1fc<br /> [ 295.723346 ] mlx5_devlink_free+0x18/0x2c [mlx5_core]<br /> [ 295.733351 ] mlx5_sf_dev_remove+0x98/0xb0 [mlx5_core]<br /> [ 295.743534 ] auxiliary_bus_remove+0x2c/0x50<br /> [ 295.751893 ] __device_release_driver+0x19c/0x280<br /> [ 295.761120 ] device_release_driver+0x34/0x50<br /> [ 295.769649 ] bus_remove_device+0xdc/0x170<br /> [ 295.777656 ] device_del+0x17c/0x3a4<br /> [ 295.784620 ] mlx5_sf_dev_remove+0x28/0xf0 [mlx5_core]<br /> [ 295.794800 ] mlx5_sf_dev_table_destroy+0x98/0x110 [mlx5_core]<br /> [ 295.806375 ] mlx5_unload+0x34/0xd0 [mlx5_core]<br /> [ 295.815339 ] mlx5_unload_one+0x70/0xe4 [mlx5_core]<br /> [ 295.824998 ] shutdown+0xb0/0xd8 [mlx5_core]<br /> [ 295.833439 ] pci_device_shutdown+0x3c/0xa0<br /> [ 295.841651 ] device_shutdown+0x170/0x340<br /> [ 295.849486 ] __do_sys_reboot+0x1f4/0x2a0<br /> [ 295.857322 ] __arm64_sys_reboot+0x2c/0x40<br /> [ 295.865329 ] invoke_syscall+0x78/0x100<br /> [ 295.872817 ] el0_svc_common.constprop.0+0x54/0x184<br /> [ 295.882392 ] do_el0_svc+0x30/0xac<br /> [ 295.889008 ] el0_svc+0x48/0x160<br /> [ 295.895278 ] el0t_64_sync_handler+0xa4/0x130<br /> [ 295.903807 ] el0t_64_sync+0x1a4/0x1a8<br /> [ 295.911120 ] ---[ end trace 4f1d2381d00d9dce ]---

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.

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.