Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: Fix memory leak in rx_desc and tx_desc<br /> <br /> Currently when ath12k_dp_cc_desc_init() is called we allocate<br /> memory to rx_descs and tx_descs. In ath12k_dp_cc_cleanup(), during<br /> descriptor cleanup rx_descs and tx_descs memory is not freed.<br /> <br /> This is cause of memory leak. These allocated memory should be<br /> freed in ath12k_dp_cc_cleanup.<br /> <br /> In ath12k_dp_cc_desc_init(), we can save base address of rx_descs<br /> and tx_descs. In ath12k_dp_cc_cleanup(), we can free rx_descs and<br /> tx_descs memory using their base address.<br /> <br /> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/pseries: fix possible memory leak in ibmebus_bus_init()<br /> <br /> If device_register() returns error in ibmebus_bus_init(), name of kobject<br /> which is allocated in dev_set_name() called in device_add() is leaked.<br /> <br /> As comment of device_add() says, it should call put_device() to drop<br /> the reference count that was set in device_initialize() when it fails,<br /> so the name can be freed in kobject_cleanup().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/hdmi: Add missing check for alloc_ordered_workqueue<br /> <br /> Add check for the return value of alloc_ordered_workqueue as it may return<br /> NULL pointer and cause NULL pointer dereference in `hdmi_hdcp.c` and<br /> `hdmi_hpd.c`.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/517211/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/psi: use kernfs polling functions for PSI trigger polling<br /> <br /> Destroying psi trigger in cgroup_file_release causes UAF issues when<br /> a cgroup is removed from under a polling process. This is happening<br /> because cgroup removal causes a call to cgroup_file_release while the<br /> actual file is still alive. Destroying the trigger at this point would<br /> also destroy its waitqueue head and if there is still a polling process<br /> on that file accessing the waitqueue, it will step on the freed pointer:<br /> <br /> do_select<br /> vfs_poll<br /> do_rmdir<br /> cgroup_rmdir<br /> kernfs_drain_open_files<br /> cgroup_file_release<br /> cgroup_pressure_release<br /> psi_trigger_destroy<br /> wake_up_pollfree(&amp;t-&gt;event_wait)<br /> // vfs_poll is unblocked<br /> synchronize_rcu<br /> kfree(t)<br /> poll_freewait -&gt; UAF access to the trigger&amp;#39;s waitqueue head<br /> <br /> Patch [1] fixed this issue for epoll() case using wake_up_pollfree(),<br /> however the same issue exists for synchronous poll() case.<br /> The root cause of this issue is that the lifecycles of the psi trigger&amp;#39;s<br /> waitqueue and of the file associated with the trigger are different. Fix<br /> this by using kernfs_generic_poll function when polling on cgroup-specific<br /> psi triggers. It internally uses kernfs_open_node-&gt;poll waitqueue head<br /> with its lifecycle tied to the file&amp;#39;s lifecycle. This also renders the<br /> fix in [1] obsolete, so revert it.<br /> <br /> [1] commit c2dbe32d5db5 ("sched/psi: Fix use-after-free in ep_remove_wait_queue()")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: r8712: Fix memory leak in _r8712_init_xmit_priv()<br /> <br /> In the above mentioned routine, memory is allocated in several places.<br /> If the first succeeds and a later one fails, the routine will leak memory.<br /> This patch fixes commit 2865d42c78a9 ("staging: r8712u: Add the new driver<br /> to the mainline kernel"). A potential memory leak in<br /> r8712_xmit_resource_alloc() is also addressed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix assertion of exclop condition when starting balance<br /> <br /> Balance as exclusive state is compatible with paused balance and device<br /> add, which makes some things more complicated. The assertion of valid<br /> states when starting from paused balance needs to take into account two<br /> more states, the combinations can be hit when there are several threads<br /> racing to start balance and device add. This won&amp;#39;t typically happen when<br /> the commands are started from command line.<br /> <br /> Scenario 1: With exclusive_operation state == BTRFS_EXCLOP_NONE.<br /> <br /> Concurrently adding multiple devices to the same mount point and<br /> btrfs_exclop_finish executed finishes before assertion in<br /> btrfs_exclop_balance, exclusive_operation will changed to<br /> BTRFS_EXCLOP_NONE state which lead to assertion failed:<br /> <br /> fs_info-&gt;exclusive_operation == BTRFS_EXCLOP_BALANCE ||<br /> fs_info-&gt;exclusive_operation == BTRFS_EXCLOP_DEV_ADD,<br /> in fs/btrfs/ioctl.c:456<br /> Call Trace:<br /> <br /> btrfs_exclop_balance+0x13c/0x310<br /> ? memdup_user+0xab/0xc0<br /> ? PTR_ERR+0x17/0x20<br /> btrfs_ioctl_add_dev+0x2ee/0x320<br /> btrfs_ioctl+0x9d5/0x10d0<br /> ? btrfs_ioctl_encoded_write+0xb80/0xb80<br /> __x64_sys_ioctl+0x197/0x210<br /> do_syscall_64+0x3c/0xb0<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Scenario 2: With exclusive_operation state == BTRFS_EXCLOP_BALANCE_PAUSED.<br /> <br /> Concurrently adding multiple devices to the same mount point and<br /> btrfs_exclop_balance executed finish before the latter thread execute<br /> assertion in btrfs_exclop_balance, exclusive_operation will changed to<br /> BTRFS_EXCLOP_BALANCE_PAUSED state which lead to assertion failed:<br /> <br /> fs_info-&gt;exclusive_operation == BTRFS_EXCLOP_BALANCE ||<br /> fs_info-&gt;exclusive_operation == BTRFS_EXCLOP_DEV_ADD ||<br /> fs_info-&gt;exclusive_operation == BTRFS_EXCLOP_NONE,<br /> fs/btrfs/ioctl.c:458<br /> Call Trace:<br /> <br /> btrfs_exclop_balance+0x240/0x410<br /> ? memdup_user+0xab/0xc0<br /> ? PTR_ERR+0x17/0x20<br /> btrfs_ioctl_add_dev+0x2ee/0x320<br /> btrfs_ioctl+0x9d5/0x10d0<br /> ? btrfs_ioctl_encoded_write+0xb80/0xb80<br /> __x64_sys_ioctl+0x197/0x210<br /> do_syscall_64+0x3c/0xb0<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> An example of the failed assertion is below, which shows that the<br /> paused balance is also needed to be checked.<br /> <br /> root@syzkaller:/home/xsk# ./repro<br /> Failed to add device /dev/vda, errno 14<br /> Failed to add device /dev/vda, errno 14<br /> Failed to add device /dev/vda, errno 14<br /> Failed to add device /dev/vda, errno 14<br /> Failed to add device /dev/vda, errno 14<br /> Failed to add device /dev/vda, errno 14<br /> Failed to add device /dev/vda, errno 14<br /> Failed to add device /dev/vda, errno 14<br /> Failed to add device /dev/vda, errno 14<br /> [ 416.611428][ T7970] BTRFS info (device loop0): fs_info exclusive_operation: 0<br /> Failed to add device /dev/vda, errno 14<br /> [ 416.613973][ T7971] BTRFS info (device loop0): fs_info exclusive_operation: 3<br /> Failed to add device /dev/vda, errno 14<br /> [ 416.615456][ T7972] BTRFS info (device loop0): fs_info exclusive_operation: 3<br /> Failed to add device /dev/vda, errno 14<br /> [ 416.617528][ T7973] BTRFS info (device loop0): fs_info exclusive_operation: 3<br /> Failed to add device /dev/vda, errno 14<br /> [ 416.618359][ T7974] BTRFS info (device loop0): fs_info exclusive_operation: 3<br /> Failed to add device /dev/vda, errno 14<br /> [ 416.622589][ T7975] BTRFS info (device loop0): fs_info exclusive_operation: 3<br /> Failed to add device /dev/vda, errno 14<br /> [ 416.624034][ T7976] BTRFS info (device loop0): fs_info exclusive_operation: 3<br /> Failed to add device /dev/vda, errno 14<br /> [ 416.626420][ T7977] BTRFS info (device loop0): fs_info exclusive_operation: 3<br /> Failed to add device /dev/vda, errno 14<br /> [ 416.627643][ T7978] BTRFS info (device loop0): fs_info exclusive_operation: 3<br /> Failed to add device /dev/vda, errno 14<br /> [ 416.629006][ T7979] BTRFS info (device loop0): fs_info exclusive_operation: 3<br /> [ 416.630298][ T7980] BTRFS info (device loop0): fs_info exclusive_operation: 3<br /> Fai<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/core: Fix GID entry ref leak when create_ah fails<br /> <br /> If AH create request fails, release sgid_attr to avoid GID entry<br /> referrence leak reported while releasing GID table

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udplite: Fix NULL pointer dereference in __sk_mem_raise_allocated().<br /> <br /> syzbot reported [0] a null-ptr-deref in sk_get_rmem0() while using<br /> IPPROTO_UDPLITE (0x88):<br /> <br /> 14:25:52 executing program 1:<br /> r0 = socket$inet6(0xa, 0x80002, 0x88)<br /> <br /> We had a similar report [1] for probably sk_memory_allocated_add()<br /> in __sk_mem_raise_allocated(), and commit c915fe13cbaa ("udplite: fix<br /> NULL pointer dereference") fixed it by setting .memory_allocated for<br /> udplite_prot and udplitev6_prot.<br /> <br /> To fix the variant, we need to set either .sysctl_wmem_offset or<br /> .sysctl_rmem.<br /> <br /> Now UDP and UDPLITE share the same value for .memory_allocated, so we<br /> use the same .sysctl_wmem_offset for UDP and UDPLITE.<br /> <br /> [0]:<br /> general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> CPU: 0 PID: 6829 Comm: syz-executor.1 Not tainted 6.4.0-rc2-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/28/2023<br /> RIP: 0010:sk_get_rmem0 include/net/sock.h:2907 [inline]<br /> RIP: 0010:__sk_mem_raise_allocated+0x806/0x17a0 net/core/sock.c:3006<br /> Code: c1 ea 03 80 3c 02 00 0f 85 23 0f 00 00 48 8b 44 24 08 48 8b 98 38 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 da 48 c1 ea 03 b6 14 02 48 89 d8 83 e0 07 83 c0 03 38 d0 0f 8d 6f 0a 00 00 8b<br /> RSP: 0018:ffffc90005d7f450 EFLAGS: 00010246<br /> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004d92000<br /> RDX: 0000000000000000 RSI: ffffffff88066482 RDI: ffffffff8e2ccbb8<br /> RBP: ffff8880173f7000 R08: 0000000000000005 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000030000<br /> R13: 0000000000000001 R14: 0000000000000340 R15: 0000000000000001<br /> FS: 0000000000000000(0000) GS:ffff8880b9800000(0063) knlGS:00000000f7f1cb40<br /> CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033<br /> CR2: 000000002e82f000 CR3: 0000000034ff0000 CR4: 00000000003506f0<br /> Call Trace:<br /> <br /> __sk_mem_schedule+0x6c/0xe0 net/core/sock.c:3077<br /> udp_rmem_schedule net/ipv4/udp.c:1539 [inline]<br /> __udp_enqueue_schedule_skb+0x776/0xb30 net/ipv4/udp.c:1581<br /> __udpv6_queue_rcv_skb net/ipv6/udp.c:666 [inline]<br /> udpv6_queue_rcv_one_skb+0xc39/0x16c0 net/ipv6/udp.c:775<br /> udpv6_queue_rcv_skb+0x194/0xa10 net/ipv6/udp.c:793<br /> __udp6_lib_mcast_deliver net/ipv6/udp.c:906 [inline]<br /> __udp6_lib_rcv+0x1bda/0x2bd0 net/ipv6/udp.c:1013<br /> ip6_protocol_deliver_rcu+0x2e7/0x1250 net/ipv6/ip6_input.c:437<br /> ip6_input_finish+0x150/0x2f0 net/ipv6/ip6_input.c:482<br /> NF_HOOK include/linux/netfilter.h:303 [inline]<br /> NF_HOOK include/linux/netfilter.h:297 [inline]<br /> ip6_input+0xa0/0xd0 net/ipv6/ip6_input.c:491<br /> ip6_mc_input+0x40b/0xf50 net/ipv6/ip6_input.c:585<br /> dst_input include/net/dst.h:468 [inline]<br /> ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline]<br /> NF_HOOK include/linux/netfilter.h:303 [inline]<br /> NF_HOOK include/linux/netfilter.h:297 [inline]<br /> ipv6_rcv+0x250/0x380 net/ipv6/ip6_input.c:309<br /> __netif_receive_skb_one_core+0x114/0x180 net/core/dev.c:5491<br /> __netif_receive_skb+0x1f/0x1c0 net/core/dev.c:5605<br /> netif_receive_skb_internal net/core/dev.c:5691 [inline]<br /> netif_receive_skb+0x133/0x7a0 net/core/dev.c:5750<br /> tun_rx_batched+0x4b3/0x7a0 drivers/net/tun.c:1553<br /> tun_get_user+0x2452/0x39c0 drivers/net/tun.c:1989<br /> tun_chr_write_iter+0xdf/0x200 drivers/net/tun.c:2035<br /> call_write_iter include/linux/fs.h:1868 [inline]<br /> new_sync_write fs/read_write.c:491 [inline]<br /> vfs_write+0x945/0xd50 fs/read_write.c:584<br /> ksys_write+0x12b/0x250 fs/read_write.c:637<br /> do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]<br /> __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178<br /> do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203<br /> entry_SYSENTER_compat_after_hwframe+0x70/0x82<br /> RIP: 0023:0xf7f21579<br /> Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binder: fix memory leak in binder_init()<br /> <br /> In binder_init(), the destruction of binder_alloc_shrinker_init() is not<br /> performed in the wrong path, which will cause memory leaks. So this commit<br /> introduces binder_alloc_shrinker_exit() and calls it in the wrong path to<br /> fix that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_unix: Fix data-race around unix_tot_inflight.<br /> <br /> unix_tot_inflight is changed under spin_lock(unix_gc_lock), but<br /> unix_release_sock() reads it locklessly.<br /> <br /> Let&amp;#39;s use READ_ONCE() for unix_tot_inflight.<br /> <br /> Note that the writer side was marked by commit 9d6d7f1cb67c ("af_unix:<br /> annote lockless accesses to unix_tot_inflight &amp; gc_in_progress")<br /> <br /> BUG: KCSAN: data-race in unix_inflight / unix_release_sock<br /> <br /> write (marked) to 0xffffffff871852b8 of 4 bytes by task 123 on cpu 1:<br /> unix_inflight+0x130/0x180 net/unix/scm.c:64<br /> unix_attach_fds+0x137/0x1b0 net/unix/scm.c:123<br /> unix_scm_to_skb net/unix/af_unix.c:1832 [inline]<br /> unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1955<br /> sock_sendmsg_nosec net/socket.c:724 [inline]<br /> sock_sendmsg+0x148/0x160 net/socket.c:747<br /> ____sys_sendmsg+0x4e4/0x610 net/socket.c:2493<br /> ___sys_sendmsg+0xc6/0x140 net/socket.c:2547<br /> __sys_sendmsg+0x94/0x140 net/socket.c:2576<br /> __do_sys_sendmsg net/socket.c:2585 [inline]<br /> __se_sys_sendmsg net/socket.c:2583 [inline]<br /> __x64_sys_sendmsg+0x45/0x50 net/socket.c:2583<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> <br /> read to 0xffffffff871852b8 of 4 bytes by task 4891 on cpu 0:<br /> unix_release_sock+0x608/0x910 net/unix/af_unix.c:671<br /> unix_release+0x59/0x80 net/unix/af_unix.c:1058<br /> __sock_release+0x7d/0x170 net/socket.c:653<br /> sock_close+0x19/0x30 net/socket.c:1385<br /> __fput+0x179/0x5e0 fs/file_table.c:321<br /> ____fput+0x15/0x20 fs/file_table.c:349<br /> task_work_run+0x116/0x1a0 kernel/task_work.c:179<br /> resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]<br /> exit_to_user_mode_loop kernel/entry/common.c:171 [inline]<br /> exit_to_user_mode_prepare+0x174/0x180 kernel/entry/common.c:204<br /> __syscall_exit_to_user_mode_work kernel/entry/common.c:286 [inline]<br /> syscall_exit_to_user_mode+0x1a/0x30 kernel/entry/common.c:297<br /> do_syscall_64+0x4b/0x90 arch/x86/entry/common.c:86<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> <br /> value changed: 0x00000000 -&gt; 0x00000001<br /> <br /> Reported by Kernel Concurrency Sanitizer on:<br /> CPU: 0 PID: 4891 Comm: systemd-coredum Not tainted 6.4.0-rc5-01219-gfa0e21fa4443 #5<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vmci_host: fix a race condition in vmci_host_poll() causing GPF<br /> <br /> During fuzzing, a general protection fault is observed in<br /> vmci_host_poll().<br /> <br /> general protection fault, probably for non-canonical address 0xdffffc0000000019: 0000 [#1] PREEMPT SMP KASAN<br /> KASAN: null-ptr-deref in range [0x00000000000000c8-0x00000000000000cf]<br /> RIP: 0010:__lock_acquire+0xf3/0x5e00 kernel/locking/lockdep.c:4926<br /> <br /> Call Trace:<br /> <br /> lock_acquire+0x1a4/0x4a0 kernel/locking/lockdep.c:5672<br /> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]<br /> _raw_spin_lock_irqsave+0xb3/0x100 kernel/locking/spinlock.c:162<br /> add_wait_queue+0x3d/0x260 kernel/sched/wait.c:22<br /> poll_wait include/linux/poll.h:49 [inline]<br /> vmci_host_poll+0xf8/0x2b0 drivers/misc/vmw_vmci/vmci_host.c:174<br /> vfs_poll include/linux/poll.h:88 [inline]<br /> do_pollfd fs/select.c:873 [inline]<br /> do_poll fs/select.c:921 [inline]<br /> do_sys_poll+0xc7c/0x1aa0 fs/select.c:1015<br /> __do_sys_ppoll fs/select.c:1121 [inline]<br /> __se_sys_ppoll+0x2cc/0x330 fs/select.c:1101<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x4e/0xa0 arch/x86/entry/common.c:82<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> Example thread interleaving that causes the general protection fault<br /> is as follows:<br /> <br /> CPU1 (vmci_host_poll) CPU2 (vmci_host_do_init_context)<br /> ----- -----<br /> // Read uninitialized context<br /> context = vmci_host_dev-&gt;context;<br /> // Initialize context<br /> vmci_host_dev-&gt;context = vmci_ctx_create();<br /> vmci_host_dev-&gt;ct_type = VMCIOBJ_CONTEXT;<br /> <br /> if (vmci_host_dev-&gt;ct_type == VMCIOBJ_CONTEXT) {<br /> // Dereferencing the wrong pointer<br /> poll_wait(..., &amp;context-&gt;host_context);<br /> }<br /> <br /> In this scenario, vmci_host_poll() reads vmci_host_dev-&gt;context first,<br /> and then reads vmci_host_dev-&gt;ct_type to check that<br /> vmci_host_dev-&gt;context is initialized. However, since these two reads<br /> are not atomically executed, there is a chance of a race condition as<br /> described above.<br /> <br /> To fix this race condition, read vmci_host_dev-&gt;context after checking<br /> the value of vmci_host_dev-&gt;ct_type so that vmci_host_poll() always<br /> reads an initialized context.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio_vdpa: build affinity masks conditionally<br /> <br /> We try to build affinity mask via create_affinity_masks()<br /> unconditionally which may lead several issues:<br /> <br /> - the affinity mask is not used for parent without affinity support<br /> (only VDUSE support the affinity now)<br /> - the logic of create_affinity_masks() might not work for devices<br /> other than block. For example it&amp;#39;s not rare in the networking device<br /> where the number of queues could exceed the number of CPUs. Such<br /> case breaks the current affinity logic which is based on<br /> group_cpus_evenly() who assumes the number of CPUs are not less than<br /> the number of groups. This can trigger a warning[1]:<br /> <br /> if (ret &gt;= 0)<br /> WARN_ON(nr_present + nr_others