Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i3c: master: mipi-i3c-hci: Fix a kernel panic for accessing DAT_data.<br /> <br /> The `i3c_master_bus_init` function may attach the I2C devices before the<br /> I3C bus initialization. In this flow, the DAT `alloc_entry`` will be used<br /> before the DAT `init`. Additionally, if the `i3c_master_bus_init` fails,<br /> the DAT `cleanup` will execute before the device is detached, which will<br /> execue DAT `free_entry` function. The above scenario can cause the driver<br /> to use DAT_data when it is NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: gspca: cpia1: shift-out-of-bounds in set_flicker<br /> <br /> Syzkaller reported the following issue:<br /> UBSAN: shift-out-of-bounds in drivers/media/usb/gspca/cpia1.c:1031:27<br /> shift exponent 245 is too large for 32-bit type &amp;#39;int&amp;#39;<br /> <br /> When the value of the variable "sd-&gt;params.exposure.gain" exceeds the<br /> number of bits in an integer, a shift-out-of-bounds error is reported. It<br /> is triggered because the variable "currentexp" cannot be left-shifted by<br /> more than the number of bits in an integer. In order to avoid invalid<br /> range during left-shift, the conditional expression is added.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mfd: qcom-spmi-pmic: Fix revid implementation<br /> <br /> The Qualcomm SPMI PMIC revid implementation is broken in multiple ways.<br /> <br /> First, it assumes that just because the sibling base device has been<br /> registered that means that it is also bound to a driver, which may not<br /> be the case (e.g. due to probe deferral or asynchronous probe). This<br /> could trigger a NULL-pointer dereference when attempting to access the<br /> driver data of the unbound device.<br /> <br /> Second, it accesses driver data of a sibling device directly and without<br /> any locking, which means that the driver data may be freed while it is<br /> being accessed (e.g. on driver unbind).<br /> <br /> Third, it leaks a struct device reference to the sibling device which is<br /> looked up using the spmi_device_from_of() every time a function (child)<br /> device is calling the revid function (e.g. on probe).<br /> <br /> Fix this mess by reimplementing the revid lookup so that it is done only<br /> at probe of the PMIC device; the base device fetches the revid info from<br /> the hardware, while any secondary SPMI device fetches the information<br /> from the base device and caches it so that it can be accessed safely<br /> from its children. If the base device has not been probed yet then probe<br /> of a secondary device is deferred.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i3c: mipi-i3c-hci: Fix out of bounds access in hci_dma_irq_handler<br /> <br /> Do not loop over ring headers in hci_dma_irq_handler() that are not<br /> allocated and enabled in hci_dma_init(). Otherwise out of bounds access<br /> will occur from rings-&gt;headers[i] access when i &gt;= number of allocated<br /> ring headers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tls: fix NULL deref on tls_sw_splice_eof() with empty record<br /> <br /> syzkaller discovered that if tls_sw_splice_eof() is executed as part of<br /> sendfile() when the plaintext/ciphertext sk_msg are empty, the send path<br /> gets confused because the empty ciphertext buffer does not have enough<br /> space for the encryption overhead. This causes tls_push_record() to go on<br /> the `split = true` path (which is only supposed to be used when interacting<br /> with an attached BPF program), and then get further confused and hit the<br /> tls_merge_open_record() path, which then assumes that there must be at<br /> least one populated buffer element, leading to a NULL deref.<br /> <br /> It is possible to have empty plaintext/ciphertext buffers if we previously<br /> bailed from tls_sw_sendmsg_locked() via the tls_trim_both_msgs() path.<br /> tls_sw_push_pending_record() already handles this case correctly; let&amp;#39;s do<br /> the same check in tls_sw_splice_eof().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: wilc1000: use vmm_table as array in wilc struct<br /> <br /> Enabling KASAN and running some iperf tests raises some memory issues with<br /> vmm_table:<br /> <br /> BUG: KASAN: slab-out-of-bounds in wilc_wlan_handle_txq+0x6ac/0xdb4<br /> Write of size 4 at addr c3a61540 by task wlan0-tx/95<br /> <br /> KASAN detects that we are writing data beyond range allocated to vmm_table.<br /> There is indeed a mismatch between the size passed to allocator in<br /> wilc_wlan_init, and the range of possible indexes used later: allocation<br /> size is missing a multiplication by sizeof(u32)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gfs2: Fix slab-use-after-free in gfs2_qd_dealloc<br /> <br /> In gfs2_put_super(), whether withdrawn or not, the quota should<br /> be cleaned up by gfs2_quota_cleanup().<br /> <br /> Otherwise, struct gfs2_sbd will be freed before gfs2_qd_dealloc (rcu<br /> callback) has run for all gfs2_quota_data objects, resulting in<br /> use-after-free.<br /> <br /> Also, gfs2_destroy_threads() and gfs2_quota_cleanup() is already called<br /> by gfs2_make_fs_ro(), so in gfs2_put_super(), after calling<br /> gfs2_make_fs_ro(), there is no need to call them again.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix potential deadlock when releasing mids<br /> <br /> All release_mid() callers seem to hold a reference of @mid so there is<br /> no need to call kref_put(&amp;mid-&gt;refcount, __release_mid) under<br /> @server-&gt;mid_lock spinlock. If they don&amp;#39;t, then an use-after-free bug<br /> would have occurred anyways.<br /> <br /> By getting rid of such spinlock also fixes a potential deadlock as<br /> shown below<br /> <br /> CPU 0 CPU 1<br /> ------------------------------------------------------------------<br /> cifs_demultiplex_thread() cifs_debug_data_proc_show()<br /> release_mid()<br /> spin_lock(&amp;server-&gt;mid_lock);<br /> spin_lock(&amp;cifs_tcp_ses_lock)<br /> spin_lock(&amp;server-&gt;mid_lock)<br /> __release_mid()<br /> smb2_find_smb_tcon()<br /> spin_lock(&amp;cifs_tcp_ses_lock) *deadlock*

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Fix use-after-free in rdata-&gt;read_into_pages()<br /> <br /> When the network status is unstable, use-after-free may occur when<br /> read data from the server.<br /> <br /> BUG: KASAN: use-after-free in readpages_fill_pages+0x14c/0x7e0<br /> <br /> Call Trace:<br /> <br /> dump_stack_lvl+0x38/0x4c<br /> print_report+0x16f/0x4a6<br /> kasan_report+0xb7/0x130<br /> readpages_fill_pages+0x14c/0x7e0<br /> cifs_readv_receive+0x46d/0xa40<br /> cifs_demultiplex_thread+0x121c/0x1490<br /> kthread+0x16b/0x1a0<br /> ret_from_fork+0x2c/0x50<br /> <br /> <br /> Allocated by task 2535:<br /> kasan_save_stack+0x22/0x50<br /> kasan_set_track+0x25/0x30<br /> __kasan_kmalloc+0x82/0x90<br /> cifs_readdata_direct_alloc+0x2c/0x110<br /> cifs_readdata_alloc+0x2d/0x60<br /> cifs_readahead+0x393/0xfe0<br /> read_pages+0x12f/0x470<br /> page_cache_ra_unbounded+0x1b1/0x240<br /> filemap_get_pages+0x1c8/0x9a0<br /> filemap_read+0x1c0/0x540<br /> cifs_strict_readv+0x21b/0x240<br /> vfs_read+0x395/0x4b0<br /> ksys_read+0xb8/0x150<br /> do_syscall_64+0x3f/0x90<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> <br /> Freed by task 79:<br /> kasan_save_stack+0x22/0x50<br /> kasan_set_track+0x25/0x30<br /> kasan_save_free_info+0x2e/0x50<br /> __kasan_slab_free+0x10e/0x1a0<br /> __kmem_cache_free+0x7a/0x1a0<br /> cifs_readdata_release+0x49/0x60<br /> process_one_work+0x46c/0x760<br /> worker_thread+0x2a4/0x6f0<br /> kthread+0x16b/0x1a0<br /> ret_from_fork+0x2c/0x50<br /> <br /> Last potentially related work creation:<br /> kasan_save_stack+0x22/0x50<br /> __kasan_record_aux_stack+0x95/0xb0<br /> insert_work+0x2b/0x130<br /> __queue_work+0x1fe/0x660<br /> queue_work_on+0x4b/0x60<br /> smb2_readv_callback+0x396/0x800<br /> cifs_abort_connection+0x474/0x6a0<br /> cifs_reconnect+0x5cb/0xa50<br /> cifs_readv_from_socket.cold+0x22/0x6c<br /> cifs_read_page_from_socket+0xc1/0x100<br /> readpages_fill_pages.cold+0x2f/0x46<br /> cifs_readv_receive+0x46d/0xa40<br /> cifs_demultiplex_thread+0x121c/0x1490<br /> kthread+0x16b/0x1a0<br /> ret_from_fork+0x2c/0x50<br /> <br /> The following function calls will cause UAF of the rdata pointer.<br /> <br /> readpages_fill_pages<br /> cifs_read_page_from_socket<br /> cifs_readv_from_socket<br /> cifs_reconnect<br /> __cifs_reconnect<br /> cifs_abort_connection<br /> mid-&gt;callback() --&gt; smb2_readv_callback<br /> queue_work(&amp;rdata-&gt;work) # if the worker completes first,<br /> # the rdata is freed<br /> cifs_readv_complete<br /> kref_put<br /> cifs_readdata_release<br /> kfree(rdata)<br /> return rdata-&gt;... # UAF in readpages_fill_pages()<br /> <br /> Similarly, this problem also occurs in the uncache_fill_pages().<br /> <br /> Fix this by adjusts the order of condition judgment in the return<br /> statement.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: USB: Fix wrong-direction WARNING in plusb.c<br /> <br /> The syzbot fuzzer detected a bug in the plusb network driver: A<br /> zero-length control-OUT transfer was treated as a read instead of a<br /> write. In modern kernels this error provokes a WARNING:<br /> <br /> usb 1-1: BOGUS control dir, pipe 80000280 doesn&amp;#39;t match bRequestType c0<br /> WARNING: CPU: 0 PID: 4645 at drivers/usb/core/urb.c:411<br /> usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411<br /> Modules linked in:<br /> CPU: 1 PID: 4645 Comm: dhcpcd Not tainted<br /> 6.2.0-rc6-syzkaller-00050-g9f266ccaa2f5 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google<br /> 01/12/2023<br /> RIP: 0010:usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411<br /> ...<br /> Call Trace:<br /> <br /> usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58<br /> usb_internal_control_msg drivers/usb/core/message.c:102 [inline]<br /> usb_control_msg+0x320/0x4a0 drivers/usb/core/message.c:153<br /> __usbnet_read_cmd+0xb9/0x390 drivers/net/usb/usbnet.c:2010<br /> usbnet_read_cmd+0x96/0xf0 drivers/net/usb/usbnet.c:2068<br /> pl_vendor_req drivers/net/usb/plusb.c:60 [inline]<br /> pl_set_QuickLink_features drivers/net/usb/plusb.c:75 [inline]<br /> pl_reset+0x2f/0xf0 drivers/net/usb/plusb.c:85<br /> usbnet_open+0xcc/0x5d0 drivers/net/usb/usbnet.c:889<br /> __dev_open+0x297/0x4d0 net/core/dev.c:1417<br /> __dev_change_flags+0x587/0x750 net/core/dev.c:8530<br /> dev_change_flags+0x97/0x170 net/core/dev.c:8602<br /> devinet_ioctl+0x15a2/0x1d70 net/ipv4/devinet.c:1147<br /> inet_ioctl+0x33f/0x380 net/ipv4/af_inet.c:979<br /> sock_do_ioctl+0xcc/0x230 net/socket.c:1169<br /> sock_ioctl+0x1f8/0x680 net/socket.c:1286<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:870 [inline]<br /> __se_sys_ioctl fs/ioctl.c:856 [inline]<br /> __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> The fix is to call usbnet_write_cmd() instead of usbnet_read_cmd() and<br /> remove the USB_DIR_IN flag.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Do not use WQ_MEM_RECLAIM flag for workqueue<br /> <br /> When both ice and the irdma driver are loaded, a warning in<br /> check_flush_dependency is being triggered. This is due to ice driver<br /> workqueue being allocated with the WQ_MEM_RECLAIM flag and the irdma one<br /> is not.<br /> <br /> According to kernel documentation, this flag should be set if the<br /> workqueue will be involved in the kernel&amp;#39;s memory reclamation flow.<br /> Since it is not, there is no need for the ice driver&amp;#39;s WQ to have this<br /> flag set so remove it.<br /> <br /> Example trace:<br /> <br /> [ +0.000004] workqueue: WQ_MEM_RECLAIM ice:ice_service_task [ice] is flushing !WQ_MEM_RECLAIM infiniband:0x0<br /> [ +0.000139] WARNING: CPU: 0 PID: 728 at kernel/workqueue.c:2632 check_flush_dependency+0x178/0x1a0<br /> [ +0.000011] Modules linked in: bonding tls xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_cha<br /> in_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink bridge stp llc rfkill vfat fat intel_rapl_msr intel<br /> _rapl_common isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct1<br /> 0dif_pclmul crc32_pclmul ghash_clmulni_intel rapl intel_cstate rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_<br /> core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_cm iw_cm iTCO_wdt iTCO_vendor_support ipmi_ssif irdma mei_me ib_uverbs<br /> ib_core intel_uncore joydev pcspkr i2c_i801 acpi_ipmi mei lpc_ich i2c_smbus intel_pch_thermal ioatdma ipmi_si acpi_power_meter<br /> acpi_pad xfs libcrc32c sd_mod t10_pi crc64_rocksoft crc64 sg ahci ixgbe libahci ice i40e igb crc32c_intel mdio i2c_algo_bit liba<br /> ta dca wmi dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse<br /> [ +0.000161] [last unloaded: bonding]<br /> [ +0.000006] CPU: 0 PID: 728 Comm: kworker/0:2 Tainted: G S 6.2.0-rc2_next-queue-13jan-00458-gc20aabd57164 #1<br /> [ +0.000006] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0010.010620200716 01/06/2020<br /> [ +0.000003] Workqueue: ice ice_service_task [ice]<br /> [ +0.000127] RIP: 0010:check_flush_dependency+0x178/0x1a0<br /> [ +0.000005] Code: 89 8e 02 01 e8 49 3d 40 00 49 8b 55 18 48 8d 8d d0 00 00 00 48 8d b3 d0 00 00 00 4d 89 e0 48 c7 c7 e0 3b 08<br /> 9f e8 bb d3 07 01 0b e9 be fe ff ff 80 3d 24 89 8e 02 00 0f 85 6b ff ff ff e9 06<br /> [ +0.000004] RSP: 0018:ffff88810a39f990 EFLAGS: 00010282<br /> [ +0.000005] RAX: 0000000000000000 RBX: ffff888141bc2400 RCX: 0000000000000000<br /> [ +0.000004] RDX: 0000000000000001 RSI: dffffc0000000000 RDI: ffffffffa1213a80<br /> [ +0.000003] RBP: ffff888194bf3400 R08: ffffed117b306112 R09: ffffed117b306112<br /> [ +0.000003] R10: ffff888bd983088b R11: ffffed117b306111 R12: 0000000000000000<br /> [ +0.000003] R13: ffff888111f84d00 R14: ffff88810a3943ac R15: ffff888194bf3400<br /> [ +0.000004] FS: 0000000000000000(0000) GS:ffff888bd9800000(0000) knlGS:0000000000000000<br /> [ +0.000003] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ +0.000003] CR2: 000056035b208b60 CR3: 000000017795e005 CR4: 00000000007706f0<br /> [ +0.000003] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ +0.000003] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ +0.000002] PKRU: 55555554<br /> [ +0.000003] Call Trace:<br /> [ +0.000002] <br /> [ +0.000003] __flush_workqueue+0x203/0x840<br /> [ +0.000006] ? mutex_unlock+0x84/0xd0<br /> [ +0.000008] ? __pfx_mutex_unlock+0x10/0x10<br /> [ +0.000004] ? __pfx___flush_workqueue+0x10/0x10<br /> [ +0.000006] ? mutex_lock+0xa3/0xf0<br /> [ +0.000005] ib_cache_cleanup_one+0x39/0x190 [ib_core]<br /> [ +0.000174] __ib_unregister_device+0x84/0xf0 [ib_core]<br /> [ +0.000094] ib_unregister_device+0x25/0x30 [ib_core]<br /> [ +0.000093] irdma_ib_unregister_device+0x97/0xc0 [irdma]<br /> [ +0.000064] ? __pfx_irdma_ib_unregister_device+0x10/0x10 [irdma]<br /> [ +0.000059] ? up_write+0x5c/0x90<br /> [ +0.000005] irdma_remove+0x36/0x90 [irdma]<br /> [ +0.000062] auxiliary_bus_remove+0x32/0x50<br /> [ +0.000007] device_r<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/irdma: Fix potential NULL-ptr-dereference<br /> <br /> in_dev_get() can return NULL which will cause a failure once idev is<br /> dereferenced in in_dev_for_each_ifa_rtnl(). This patch adds a<br /> check for NULL value in idev beforehand.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.