Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommufd: IOMMUFD_DESTROY should not increase the refcount<br /> <br /> syzkaller found a race where IOMMUFD_DESTROY increments the refcount:<br /> <br /> obj = iommufd_get_object(ucmd-&gt;ictx, cmd-&gt;id, IOMMUFD_OBJ_ANY);<br /> if (IS_ERR(obj))<br /> return PTR_ERR(obj);<br /> iommufd_ref_to_users(obj);<br /> /* See iommufd_ref_to_users() */<br /> if (!iommufd_object_destroy_user(ucmd-&gt;ictx, obj))<br /> <br /> As part of the sequence to join the two existing primitives together.<br /> <br /> Allowing the refcount the be elevated without holding the destroy_rwsem<br /> violates the assumption that all temporary refcount elevations are<br /> protected by destroy_rwsem. Racing IOMMUFD_DESTROY with<br /> iommufd_object_destroy_user() will cause spurious failures:<br /> <br /> WARNING: CPU: 0 PID: 3076 at drivers/iommu/iommufd/device.c:477 iommufd_access_destroy+0x18/0x20 drivers/iommu/iommufd/device.c:478<br /> Modules linked in:<br /> CPU: 0 PID: 3076 Comm: syz-executor.0 Not tainted 6.3.0-rc1-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/03/2023<br /> RIP: 0010:iommufd_access_destroy+0x18/0x20 drivers/iommu/iommufd/device.c:477<br /> Code: e8 3d 4e 00 00 84 c0 74 01 c3 0f 0b c3 0f 1f 44 00 00 f3 0f 1e fa 48 89 fe 48 8b bf a8 00 00 00 e8 1d 4e 00 00 84 c0 74 01 c3 0b c3 0f 1f 44 00 00 41 57 41 56 41 55 4c 8d ae d0 00 00 00 41<br /> RSP: 0018:ffffc90003067e08 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffff888109ea0300 RCX: 0000000000000000<br /> RDX: 0000000000000001 RSI: 0000000000000000 RDI: 00000000ffffffff<br /> RBP: 0000000000000004 R08: 0000000000000000 R09: ffff88810bbb3500<br /> R10: ffff88810bbb3e48 R11: 0000000000000000 R12: ffffc90003067e88<br /> R13: ffffc90003067ea8 R14: ffff888101249800 R15: 00000000fffffffe<br /> FS: 00007ff7254fe6c0(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000555557262da8 CR3: 000000010a6fd000 CR4: 0000000000350ef0<br /> Call Trace:<br /> <br /> iommufd_test_create_access drivers/iommu/iommufd/selftest.c:596 [inline]<br /> iommufd_test+0x71c/0xcf0 drivers/iommu/iommufd/selftest.c:813<br /> iommufd_fops_ioctl+0x10f/0x1b0 drivers/iommu/iommufd/main.c:337<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+0x84/0xc0 fs/ioctl.c:856<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x38/0x80 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> The solution is to not increment the refcount on the IOMMUFD_DESTROY path<br /> at all. Instead use the xa_lock to serialize everything. The refcount<br /> check == 1 and xa_erase can be done under a single critical region. This<br /> avoids the need for any refcount incrementing.<br /> <br /> It has the downside that if userspace races destroy with other operations<br /> it will get an EBUSY instead of waiting, but this is kind of racing is<br /> already dangerous.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix information leak in f2fs_move_inline_dirents()<br /> <br /> When converting an inline directory to a regular one, f2fs is leaking<br /> uninitialized memory to disk because it doesn&amp;#39;t initialize the entire<br /> directory block. Fix this by zero-initializing the block.<br /> <br /> This bug was introduced by commit 4ec17d688d74 ("f2fs: avoid unneeded<br /> initializing when converting inline dentry"), which didn&amp;#39;t consider the<br /> security implications of leaking uninitialized memory to disk.<br /> <br /> This was found by running xfstest generic/435 on a KMSAN-enabled kernel.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: wacom: Use ktime_t rather than int when dealing with timestamps<br /> <br /> Code which interacts with timestamps needs to use the ktime_t type<br /> returned by functions like ktime_get. The int type does not offer<br /> enough space to store these values, and attempting to use it is a<br /> recipe for problems. In this particular case, overflows would occur<br /> when calculating/storing timestamps leading to incorrect values being<br /> reported to userspace. In some cases these bad timestamps cause input<br /> handling in userspace to appear hung.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethtool: Fix uninitialized number of lanes<br /> <br /> It is not possible to set the number of lanes when setting link modes<br /> using the legacy IOCTL ethtool interface. Since &amp;#39;struct<br /> ethtool_link_ksettings&amp;#39; is not initialized in this path, drivers receive<br /> an uninitialized number of lanes in &amp;#39;struct<br /> ethtool_link_ksettings::lanes&amp;#39;.<br /> <br /> When this information is later queried from drivers, it results in the<br /> ethtool code making decisions based on uninitialized memory, leading to<br /> the following KMSAN splat [1]. In practice, this most likely only<br /> happens with the tun driver that simply returns whatever it got in the<br /> set operation.<br /> <br /> As far as I can tell, this uninitialized memory is not leaked to user<br /> space thanks to the &amp;#39;ethtool_ops-&gt;cap_link_lanes_supported&amp;#39; check in<br /> linkmodes_prepare_data().<br /> <br /> Fix by initializing the structure in the IOCTL path. Did not find any<br /> more call sites that pass an uninitialized structure when calling<br /> &amp;#39;ethtool_ops::set_link_ksettings()&amp;#39;.<br /> <br /> [1]<br /> BUG: KMSAN: uninit-value in ethnl_update_linkmodes net/ethtool/linkmodes.c:273 [inline]<br /> BUG: KMSAN: uninit-value in ethnl_set_linkmodes+0x190b/0x19d0 net/ethtool/linkmodes.c:333<br /> ethnl_update_linkmodes net/ethtool/linkmodes.c:273 [inline]<br /> ethnl_set_linkmodes+0x190b/0x19d0 net/ethtool/linkmodes.c:333<br /> ethnl_default_set_doit+0x88d/0xde0 net/ethtool/netlink.c:640<br /> genl_family_rcv_msg_doit net/netlink/genetlink.c:968 [inline]<br /> genl_family_rcv_msg net/netlink/genetlink.c:1048 [inline]<br /> genl_rcv_msg+0x141a/0x14c0 net/netlink/genetlink.c:1065<br /> netlink_rcv_skb+0x3f8/0x750 net/netlink/af_netlink.c:2577<br /> genl_rcv+0x40/0x60 net/netlink/genetlink.c:1076<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]<br /> netlink_unicast+0xf41/0x1270 net/netlink/af_netlink.c:1365<br /> netlink_sendmsg+0x127d/0x1430 net/netlink/af_netlink.c:1942<br /> sock_sendmsg_nosec net/socket.c:724 [inline]<br /> sock_sendmsg net/socket.c:747 [inline]<br /> ____sys_sendmsg+0xa24/0xe40 net/socket.c:2501<br /> ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2555<br /> __sys_sendmsg net/socket.c:2584 [inline]<br /> __do_sys_sendmsg net/socket.c:2593 [inline]<br /> __se_sys_sendmsg net/socket.c:2591 [inline]<br /> __x64_sys_sendmsg+0x36b/0x540 net/socket.c:2591<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Uninit was stored to memory at:<br /> tun_get_link_ksettings+0x37/0x60 drivers/net/tun.c:3544<br /> __ethtool_get_link_ksettings+0x17b/0x260 net/ethtool/ioctl.c:441<br /> ethnl_set_linkmodes+0xee/0x19d0 net/ethtool/linkmodes.c:327<br /> ethnl_default_set_doit+0x88d/0xde0 net/ethtool/netlink.c:640<br /> genl_family_rcv_msg_doit net/netlink/genetlink.c:968 [inline]<br /> genl_family_rcv_msg net/netlink/genetlink.c:1048 [inline]<br /> genl_rcv_msg+0x141a/0x14c0 net/netlink/genetlink.c:1065<br /> netlink_rcv_skb+0x3f8/0x750 net/netlink/af_netlink.c:2577<br /> genl_rcv+0x40/0x60 net/netlink/genetlink.c:1076<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]<br /> netlink_unicast+0xf41/0x1270 net/netlink/af_netlink.c:1365<br /> netlink_sendmsg+0x127d/0x1430 net/netlink/af_netlink.c:1942<br /> sock_sendmsg_nosec net/socket.c:724 [inline]<br /> sock_sendmsg net/socket.c:747 [inline]<br /> ____sys_sendmsg+0xa24/0xe40 net/socket.c:2501<br /> ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2555<br /> __sys_sendmsg net/socket.c:2584 [inline]<br /> __do_sys_sendmsg net/socket.c:2593 [inline]<br /> __se_sys_sendmsg net/socket.c:2591 [inline]<br /> __x64_sys_sendmsg+0x36b/0x540 net/socket.c:2591<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Uninit was stored to memory at:<br /> tun_set_link_ksettings+0x37/0x60 drivers/net/tun.c:3553<br /> ethtool_set_link_ksettings+0x600/0x690 net/ethtool/ioctl.c:609<br /> __dev_ethtool net/ethtool/ioctl.c:3024 [inline]<br /> dev_ethtool+0x1db9/0x2a70 net/ethtool/ioctl.c:3078<br /> dev_ioctl+0xb07/0x1270 net/core/dev_ioctl.c:524<br /> sock_do_ioctl+0x295/0x540 net/socket.c:1213<br /> sock_i<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: api - Use work queue in crypto_destroy_instance<br /> <br /> The function crypto_drop_spawn expects to be called in process<br /> context. However, when an instance is unregistered while it still<br /> has active users, the last user may cause the instance to be freed<br /> in atomic context.<br /> <br /> Fix this by delaying the freeing to a work queue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubi: Fix use-after-free when volume resizing failed<br /> <br /> There is an use-after-free problem reported by KASAN:<br /> ==================================================================<br /> BUG: KASAN: use-after-free in ubi_eba_copy_table+0x11f/0x1c0 [ubi]<br /> Read of size 8 at addr ffff888101eec008 by task ubirsvol/4735<br /> <br /> CPU: 2 PID: 4735 Comm: ubirsvol<br /> Not tainted 6.1.0-rc1-00003-g84fa3304a7fc-dirty #14<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),<br /> BIOS 1.14.0-1.fc33 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x34/0x44<br /> print_report+0x171/0x472<br /> kasan_report+0xad/0x130<br /> ubi_eba_copy_table+0x11f/0x1c0 [ubi]<br /> ubi_resize_volume+0x4f9/0xbc0 [ubi]<br /> ubi_cdev_ioctl+0x701/0x1850 [ubi]<br /> __x64_sys_ioctl+0x11d/0x170<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> <br /> When ubi_change_vtbl_record() returns an error in ubi_resize_volume(),<br /> "new_eba_tbl" will be freed on error handing path, but it is holded<br /> by "vol-&gt;eba_tbl" in ubi_eba_replace_table(). It means that the liftcycle<br /> of "vol-&gt;eba_tbl" and "vol" are different, so when resizing volume in<br /> next time, it causing an use-after-free fault.<br /> <br /> Fix it by not freeing "new_eba_tbl" after it replaced in<br /> ubi_eba_replace_table(), while will be freed in next volume resizing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/sprd: Release dma buffer to avoid memory leak<br /> <br /> When attaching to a domain, the driver would alloc a DMA buffer which<br /> is used to store address mapping table, and it need to be released<br /> when the IOMMU domain is freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath9k: htc_hst: free skb in ath9k_htc_rx_msg() if there is no callback function<br /> <br /> It is stated that ath9k_htc_rx_msg() either frees the provided skb or<br /> passes its management to another callback function. However, the skb is<br /> not freed in case there is no another callback function, and Syzkaller was<br /> able to cause a memory leak. Also minor comment fix.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: da9063: fix null pointer deref with partial DT config<br /> <br /> When some of the da9063 regulators do not have corresponding DT nodes<br /> a null pointer dereference occurs on boot because such regulators have<br /> no init_data causing the pointers calculated in<br /> da9063_check_xvp_constraints() to be invalid.<br /> <br /> Do not dereference them in this case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: hda/ca0132: fixup buffer overrun at tuning_ctl_set()<br /> <br /> tuning_ctl_set() might have buffer overrun at (X) if it didn&amp;#39;t break<br /> from loop by matching (A).<br /> <br /> static int tuning_ctl_set(...)<br /> {<br /> for (i = 0; i

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/amd: Improve page fault error reporting<br /> <br /> If IOMMU domain for device group is not setup properly then we may hit<br /> IOMMU page fault. Current page fault handler assumes that domain is<br /> always setup and it will hit NULL pointer derefence (see below sample log).<br /> <br /> Lets check whether domain is setup or not and log appropriate message.<br /> <br /> Sample log:<br /> ----------<br /> amdgpu 0000:00:01.0: amdgpu: SE 1, SH per SE 1, CU per SH 8, active_cu_number 6<br /> BUG: kernel NULL pointer dereference, address: 0000000000000058<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 /> CPU: 2 PID: 56 Comm: irq/24-AMD-Vi Not tainted 6.2.0-rc2+ #89<br /> Hardware name: xxx<br /> RIP: 0010:report_iommu_fault+0x11/0x90<br /> [...]<br /> Call Trace:<br /> <br /> amd_iommu_int_thread+0x60c/0x760<br /> ? __pfx_irq_thread_fn+0x10/0x10<br /> irq_thread_fn+0x1f/0x60<br /> irq_thread+0xea/0x1a0<br /> ? preempt_count_add+0x6a/0xa0<br /> ? __pfx_irq_thread_dtor+0x10/0x10<br /> ? __pfx_irq_thread+0x10/0x10<br /> kthread+0xe9/0x110<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x2c/0x50<br /> <br /> <br /> [joro: Edit commit message]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Zeroing allocated object from slab in bpf memory allocator<br /> <br /> Currently the freed element in bpf memory allocator may be immediately<br /> reused, for htab map the reuse will reinitialize special fields in map<br /> value (e.g., bpf_spin_lock), but lookup procedure may still access<br /> these special fields, and it may lead to hard-lockup as shown below:<br /> <br /> NMI backtrace for cpu 16<br /> CPU: 16 PID: 2574 Comm: htab.bin Tainted: G L 6.1.0+ #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),<br /> RIP: 0010:queued_spin_lock_slowpath+0x283/0x2c0<br /> ......<br /> Call Trace:<br /> <br /> copy_map_value_locked+0xb7/0x170<br /> bpf_map_copy_value+0x113/0x3c0<br /> __sys_bpf+0x1c67/0x2780<br /> __x64_sys_bpf+0x1c/0x20<br /> do_syscall_64+0x30/0x60<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> ......<br /> <br /> <br /> For htab map, just like the preallocated case, these is no need to<br /> initialize these special fields in map value again once these fields<br /> have been initialized. For preallocated htab map, these fields are<br /> initialized through __GFP_ZERO in bpf_map_area_alloc(), so do the<br /> similar thing for non-preallocated htab in bpf memory allocator. And<br /> there is no need to use __GFP_ZERO for per-cpu bpf memory allocator,<br /> because __alloc_percpu_gfp() does it implicitly.