Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: Don&amp;#39;t WARN if memory is dirtied without a vCPU when the VM is dying<br /> <br /> When marking a page dirty, complain about not having a running/loaded vCPU<br /> if and only if the VM is still alive, i.e. its refcount is non-zero. This<br /> will allow fixing a memory leak for x86 SEV-ES guests without hitting what<br /> is effectively a false positive on the WARN.<br /> <br /> For some SEV-ES VM-Exits, KVM keeps a writable mapping of a guest page<br /> across an exit to userspace, and typically unmaps the page on the next<br /> KVM_RUN. But if userspace never calls KVM_RUN after such an exit, then KVM<br /> needs to unmap the page when the vCPU is destroyed, which in turn triggers<br /> the WARN about not having a running vCPU.<br /> <br /> Alternatively, SEV-ES could temporarily load the vCPU to suppress the WARN,<br /> as is done in nested_vmx_free_vcpu() (but for completely unrelated reasons;<br /> suppressing WARN from nested_put_vmcs12_pages() is pure happenstance). But<br /> loading a vCPU during destruction is gross (ideally nVMX code would be<br /> cleaned up), risks complicating the SEV-ES code (KVM would need to ensure<br /> the temporarily load()+put() only runs when the vCPU isn&amp;#39;t already loaded),<br /> and is ultimately pointless.<br /> <br /> The motivation for the WARN is to guard against KVM dirtying guest memory<br /> without pushing the corresponding GFN to the active vCPU&amp;#39;s dirty ring, e.g.<br /> to ensure userspace doesn&amp;#39;t miss a dirty page. But for the VM&amp;#39;s refcount<br /> to reach zero, there can&amp;#39;t be _any_ userspace mappings to the dirty ring,<br /> as mapping the dirty ring requires doing mmap() on the vCPU FD. I.e. if<br /> userspace had a valid mapping for the dirty ring, then the vCPU file and<br /> thus the owning VM would still be alive. And so since userspace can&amp;#39;t<br /> possibly reach the dirty ring, whether or not KVM technically "misses" a<br /> push to the dirty ring is irrelevant.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: mcp23s08: Initialize mcp-&gt;dev and mcp-&gt;addr before regmap init<br /> <br /> Regmap initialization triggers regcache_maple_populate() which attempts<br /> SPI read to populate cache. SPI read requires mcp-&gt;dev and mcp-&gt;addr to<br /> be set, without them, NULL pointer dereference occurs during probe.<br /> <br /> Move initialization before mcp23s08_spi_regmap_init() call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: 9475/1: entry: use byte load for KASAN VMAP stack shadow<br /> <br /> Commit 44e9a3bb76e5 ("ARM: 9430/1: entry: Do a dummy read from<br /> VMAP shadow") added a dummy read from the KASAN VMAP stack shadow in<br /> __switch_to(). The read uses ldr, but the KASAN shadow address is<br /> byte-granular and is not guaranteed to be word aligned.<br /> <br /> ARMv5 faults unaligned word loads. With CONFIG_KASAN_VMALLOC and<br /> CONFIG_VMAP_STACK enabled, ARM926/VersatilePB crashes in __switch_to()<br /> with an alignment exception before reaching init.<br /> <br /> Use ldrb for the dummy shadow access. The code only needs to fault in the<br /> shadow mapping if the stack shadow is missing, so a byte load is sufficient<br /> and matches the granularity of KASAN shadow memory.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: mm: call pagetable dtor when freeing hot-removed page tables<br /> <br /> Since 5e8eb9aeeda3 ("arm64: mm: always call PTE/PMD ctor in<br /> __create_pgd_mapping()") page-table allocation on ARM64 always calls<br /> pagetable_{pte,pmd,pud,p4d}_ctor(). This sets the page_type to<br /> PGTY_table, increments NR_PAGETABLE and possible allocates a PTL. However<br /> the matching pagetable_dtor() calls were never added.<br /> <br /> With DEBUG_VM enabled on kernel versions prior to v6.17 without<br /> 2dfcd1608f3a9 ("mm/page_alloc: let page freeing clear any set page type")<br /> this leads to the following warning when freeing these pages due to<br /> page-&gt;page_type sharing page-&gt;_mapcount:<br /> <br /> BUG: Bad page state in process ... pfn:284fbb<br /> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x284fbb<br /> flags: 0x17fffc000000000(node=0|zone=2|lastcpupid=0x1ffff)<br /> page_type: f2(table)<br /> page dumped because: nonzero mapcount<br /> Call trace:<br /> bad_page+0x13c/0x160<br /> __free_frozen_pages+0x6cc/0x860<br /> ___free_pages+0xf4/0x180<br /> free_pages+0x54/0x80<br /> free_hotplug_page_range.part.0+0x58/0x90<br /> free_empty_tables+0x438/0x500<br /> __remove_pgd_mapping.constprop.0+0x60/0xa8<br /> arch_remove_memory+0x48/0x80<br /> try_remove_memory+0x158/0x1d8<br /> offline_and_remove_memory+0x138/0x180<br /> <br /> It can also lead to leaking the ptl allocation if ALLOC_SPLIT_PTLOCKS is<br /> defined and incorrect NR_PAGETABLE stats. Fix this by calling<br /> pagetable_dtor() in free_hotplug_pgtable_page() prior to freeing the page<br /> to undo the effects of calling pagetable_*_ctor().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fhandle: fix UAF due to unlocked -&gt;mnt_ns read in may_decode_fh()<br /> <br /> may_decode_fh() accesses mount::mnt_ns without holding any locks; that<br /> means the mount can concurrently be unmounted, and the mnt_namespace can<br /> concurrently be freed after an RCU grace period.<br /> <br /> This race can happens as follows, assuming that the mount point was<br /> created by open_tree(..., OPEN_TREE_CLONE):<br /> <br /> thread 1 thread 2 RCU<br /> __do_sys_open_by_handle_at<br /> do_handle_open<br /> handle_to_path<br /> may_decode_fh<br /> is_mounted<br /> [mount::mnt_ns access]<br /> [mount::mnt_ns access]<br /> __do_sys_close<br /> fput_close_sync<br /> __fput<br /> dissolve_on_fput<br /> umount_tree<br /> class_namespace_excl_destructor<br /> namespace_unlock<br /> free_mnt_ns<br /> mnt_ns_tree_remove<br /> call_rcu(mnt_ns_release_rcu)<br /> mnt_ns_release_rcu<br /> mnt_ns_release<br /> kfree<br /> [mnt_namespace::user_ns access] **UAF**<br /> <br /> Fix it by taking rcu_read_lock() around the mount::mnt_ns access, like<br /> in __prepend_path().<br /> Additionally, document the semantics of mount::mnt_ns, and use WRITE_ONCE()<br /> for writers that can race with lockless readers.<br /> <br /> This bug is unreachable unless one of the following is set:<br /> <br /> - CONFIG_PREEMPTION<br /> - CONFIG_RCU_STRICT_GRACE_PERIOD<br /> <br /> because it requires an RCU grace period to happen during a syscall without<br /> an explicit preemption.<br /> <br /> This doesn&amp;#39;t seem to have interesting security impact; worst-case, it could<br /> leak the result of an integer comparison to userspace (from the level<br /> check in cap_capable()), cause an endless loop, or crash the kernel by<br /> dereferencing an invalid address.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: imx: fix clock and pinctrl state inconsistency in runtime PM<br /> <br /> In i2c_imx_runtime_suspend(), the clock is disabled before switching<br /> the pinctrl state to sleep. If pinctrl_pm_select_sleep_state() fails,<br /> the runtime suspend is aborted but the clock remains disabled, causing<br /> a system crash when the hardware is subsequently accessed.<br /> <br /> Fix this by switching the pinctrl state before disabling the clock so<br /> that a pinctrl failure leaves the clock enabled and the hardware<br /> accessible.<br /> <br /> In i2c_imx_runtime_resume(), restore the pinctrl state back to sleep<br /> if clk_enable() fails to keep the consistent.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: qcom-cci: Fix NULL pointer dereference in cci_remove()<br /> <br /> On all modern platforms Qualcomm CCI controller provides two I2C masters,<br /> and on particular boards only one I2C master may be initialized, and in<br /> such cases the device unbinding or driver removal causes a NULL pointer<br /> dereference, because cci_halt() is called for all two I2C masters, but<br /> a completion is initialized only for the single enabled master:<br /> <br /> % rmmod i2c-qcom-cci<br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> <br /> Call trace:<br /> __wait_for_common+0x194/0x1a8 (P)<br /> wait_for_completion_timeout+0x20/0x2c<br /> cci_remove+0xc4/0x138 [i2c_qcom_cci]<br /> platform_remove+0x20/0x30<br /> device_remove+0x4c/0x80<br /> device_release_driver_internal+0x1c8/0x224<br /> driver_detach+0x50/0x98<br /> bus_remove_driver+0x6c/0xbc<br /> driver_unregister+0x30/0x60<br /> platform_driver_unregister+0x14/0x20<br /> qcom_cci_driver_exit+0x18/0x1008 [i2c_qcom_cci]<br /> ....

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: airoha: Add NULL check for of_reserved_mem_lookup() in airoha_qdma_init_hfwd_queues()<br /> <br /> of_reserved_mem_lookup() may return NULL if the reserved memory region<br /> referenced by the "memory-region" phandle is not found in the reserved<br /> memory table (e.g. due to a misconfigured DTS or a removed<br /> memory-region node). The current code dereferences the returned<br /> pointer without checking for NULL, leading to a kernel NULL pointer<br /> dereference at the following lines:<br /> <br /> dma_addr = rmem-&gt;base; // line 1156<br /> num_desc = div_u64(rmem-&gt;size, buf_size); // line 1160<br /> <br /> Add a NULL check after of_reserved_mem_lookup() and return -ENODEV if<br /> the lookup fails, which is consistent with the existing error handling<br /> for of_parse_phandle() failure in the same code block.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: bonding: fix NULL pointer dereference in bond_do_ioctl()<br /> <br /> In bond_do_ioctl(), slave_dev is obtained via __dev_get_by_name() which<br /> can return NULL if the requested interface name does not exist. However,<br /> the subsequent slave_dbg() call is placed before the NULL check:<br /> <br /> slave_dev = __dev_get_by_name(net, ifr-&gt;ifr_slave);<br /> slave_dbg(bond_dev, slave_dev, "slave_dev=%p:\n", slave_dev); //here<br /> if (!slave_dev)<br /> return -ENODEV;<br /> <br /> The slave_dbg() macro expands to netdev_dbg(bond_dev, "(slave %s): " fmt,<br /> (slave_dev)-&gt;name, ...) which unconditionally dereferences slave_dev-&gt;name<br /> before the NULL check is performed. This results in a NULL pointer<br /> dereference kernel oops when a user calls bonding ioctl (e.g.<br /> SIOCBONDENSLAVE, SIOCBONDRELEASE, etc.) with a non-existent slave<br /> interface name.<br /> <br /> This is reachable from userspace via the bonding ioctl interface with<br /> CAP_NET_ADMIN capability, making it a potential local denial-of-service<br /> vector.<br /> <br /> Fix by moving the slave_dbg() call after the NULL check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmem: layouts: onie-tlv: fix hang on unknown types<br /> <br /> The EEPROM on my board has a vendor specific entry of type 0x41. When<br /> stumbling upon that, this driver hangs in an endless loop.<br /> <br /> Fix it by keep incrementing the offset on unknown entries, so the loop<br /> will eventually stop.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/lru_sort: handle ctx allocation failure<br /> <br /> DAMON_LRU_SORT allocates the damon_ctx object for its kdamond in its init<br /> function. damon_lru_sort_enabled_store() wrongly assumes the allocation<br /> will always succeed once tried. If the damon_ctx allocation was failed,<br /> therefore, code execution reaches to damon_commit_ctx() while &amp;#39;ctx&amp;#39; is<br /> NULL. As a result, it dereferences the NULL &amp;#39;ctx&amp;#39; pointer. Avoid the<br /> NULL dereference by returning -ENOMEM if &amp;#39;ctx&amp;#39; is NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/reclaim: handle ctx allocation failure<br /> <br /> Patch series "mm/damon/{reclaim,lru_sort}: handle ctx allocation failures".<br /> <br /> DAMON_RECLAIM and DAMON_LRU_SORT could dereference NULL pointers if their<br /> damon_ctx object allocations fail. The bugs are expected to happen<br /> infrequently because the allocations are arguably too small to fail on<br /> common setups. But theoretically they are possible and the consequences<br /> are bad. Fix those.<br /> <br /> The issues were discovered [1] by Sashiko.<br /> <br /> <br /> This patch (of 2):<br /> <br /> DAMON_RECLAIM allocates the damon_ctx object for its kdamond in its init<br /> function. damon_reclaim_enabled_store() wrongly assumes the allocation<br /> will always succeed once tried. If the damon_ctx allocation was failed,<br /> therefore, code execution reaches to damon_commit_ctx() while &amp;#39;ctx&amp;#39; is<br /> NULL. As a result, it dereferences the NULL &amp;#39;ctx&amp;#39; pointer. Avoid the<br /> NULL dereference by returning -ENOMEM if &amp;#39;ctx&amp;#39; is NULL.