Vulnerabilities

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: cadence: cdns_i2c_master_xfer(): Fix runtime PM leak on error path<br /> <br /> The cdns_i2c_master_xfer() function gets a runtime PM reference when the<br /> function is entered. This reference is released when the function is<br /> exited. There is currently one error path where the function exits<br /> directly, which leads to a leak of the runtime PM reference.<br /> <br /> Make sure that this error path also releases the runtime PM reference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPICA: ACPICA: check null return of ACPI_ALLOCATE_ZEROED in acpi_db_display_objects<br /> <br /> ACPICA commit 0d5f467d6a0ba852ea3aad68663cbcbd43300fd4<br /> <br /> ACPI_ALLOCATE_ZEROED may fails, object_info might be null and will cause<br /> null pointer dereference later.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/dpu: Disallow unallocated resources to be returned<br /> <br /> In the event that the topology requests resources that have not been<br /> created by the system (because they are typically not represented in<br /> dpu_mdss_cfg ^1), the resource(s) in global_state (in this case DSC<br /> blocks, until their allocation/assignment is being sanity-checked in<br /> "drm/msm/dpu: Reject topologies for which no DSC blocks are available")<br /> remain NULL but will still be returned out of<br /> dpu_rm_get_assigned_resources, where the caller expects to get an array<br /> containing num_blks valid pointers (but instead gets these NULLs).<br /> <br /> To prevent this from happening, where null-pointer dereferences<br /> typically result in a hard-to-debug platform lockup, num_blks shouldn&amp;#39;t<br /> increase past NULL blocks and will print an error and break instead.<br /> After all, max_blks represents the static size of the maximum number of<br /> blocks whereas the actual amount varies per platform.<br /> <br /> ^1: which can happen after a git rebase ended up moving additions to<br /> _dpu_cfg to a different struct which has the same patch context.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/517636/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cfg80211: ocb: don&amp;#39;t leave if not joined<br /> <br /> If there&amp;#39;s no OCB state, don&amp;#39;t ask the driver/mac80211 to<br /> leave, since that&amp;#39;s just confusing. Since set/clear the<br /> chandef state, that&amp;#39;s a simple check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI/DOE: Fix memory leak with CONFIG_DEBUG_OBJECTS=y<br /> <br /> After a pci_doe_task completes, its work_struct needs to be destroyed<br /> to avoid a memory leak with CONFIG_DEBUG_OBJECTS=y.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ionic: remove WARN_ON to prevent panic_on_warn<br /> <br /> Remove unnecessary early code development check and the WARN_ON<br /> that it uses. The irq alloc and free paths have long been<br /> cleaned up and this check shouldn&amp;#39;t have stuck around so long.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ipv4: fix one memleak in __inet_del_ifa()<br /> <br /> I got the below warning when do fuzzing test:<br /> unregister_netdevice: waiting for bond0 to become free. Usage count = 2<br /> <br /> It can be repoduced via:<br /> <br /> ip link add bond0 type bond<br /> sysctl -w net.ipv4.conf.bond0.promote_secondaries=1<br /> ip addr add 4.117.174.103/0 scope 0x40 dev bond0<br /> ip addr add 192.168.100.111/255.255.255.254 scope 0 dev bond0<br /> ip addr add 0.0.0.4/0 scope 0x40 secondary dev bond0<br /> ip addr del 4.117.174.103/0 scope 0x40 dev bond0<br /> ip link delete bond0 type bond<br /> <br /> In this reproduction test case, an incorrect &amp;#39;last_prim&amp;#39; is found in<br /> __inet_del_ifa(), as a result, the secondary address(0.0.0.4/0 scope 0x40)<br /> is lost. The memory of the secondary address is leaked and the reference of<br /> in_device and net_device is leaked.<br /> <br /> Fix this problem:<br /> Look for &amp;#39;last_prim&amp;#39; starting at location of the deleted IP and inserting<br /> the promoted IP into the location of &amp;#39;last_prim&amp;#39;.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/sev: Make enc_dec_hypercall() accept a size instead of npages<br /> <br /> enc_dec_hypercall() accepted a page count instead of a size, which<br /> forced its callers to round up. As a result, non-page aligned<br /> vaddrs caused pages to be spuriously marked as decrypted via the<br /> encryption status hypercall, which in turn caused consistent<br /> corruption of pages during live migration. Live migration requires<br /> accurate encryption status information to avoid migrating pages<br /> from the wrong perspective.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thermal: of: fix double-free on unregistration<br /> <br /> Since commit 3d439b1a2ad3 ("thermal/core: Alloc-copy-free the thermal<br /> zone parameters structure"), thermal_zone_device_register() allocates<br /> a copy of the tzp argument and frees it when unregistering, so<br /> thermal_of_zone_register() now ends up leaking its original tzp and<br /> double-freeing the tzp copy. Fix this by locating tzp on stack instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwrng: virtio - Fix race on data_avail and actual data<br /> <br /> The virtio rng device kicks off a new entropy request whenever the<br /> data available reaches zero. When a new request occurs at the end<br /> of a read operation, that is, when the result of that request is<br /> only needed by the next reader, then there is a race between the<br /> writing of the new data and the next reader.<br /> <br /> This is because there is no synchronisation whatsoever between the<br /> writer and the reader.<br /> <br /> Fix this by writing data_avail with smp_store_release and reading<br /> it with smp_load_acquire when we first enter read. The subsequent<br /> reads are safe because they&amp;#39;re either protected by the first load<br /> acquire, or by the completion mechanism.<br /> <br /> Also remove the redundant zeroing of data_idx in random_recv_done<br /> (data_idx must already be zero at this point) and data_avail in<br /> request_entropy (ditto).