Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> via_wdt: fix critical boot hang due to unnamed resource allocation<br /> <br /> The VIA watchdog driver uses allocate_resource() to reserve a MMIO<br /> region for the watchdog control register. However, the allocated<br /> resource was not given a name, which causes the kernel resource tree<br /> to contain an entry marked as "" under /proc/iomem on x86<br /> platforms.<br /> <br /> During boot, this unnamed resource can lead to a critical hang because<br /> subsequent resource lookups and conflict checks fail to handle the<br /> invalid entry properly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> um: init cpu_tasks[] earlier<br /> <br /> This is currently done in uml_finishsetup(), but e.g. with<br /> KCOV enabled we&amp;#39;ll crash because some init code can call<br /> into e.g. memparse(), which has coverage annotations, and<br /> then the checks in check_kcov_mode() crash because current<br /> is NULL.<br /> <br /> Simply initialize the cpu_tasks[] array statically, which<br /> fixes the crash. For the later SMP work, it seems to have<br /> not really caused any problems yet, but initialize all of<br /> the entries anyway.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: make decode_pool() more resilient against corrupted osdmaps<br /> <br /> If the osdmap is (maliciously) corrupted such that the encoded length<br /> of ceph_pg_pool envelope is less than what is expected for a particular<br /> encoding version, out-of-bounds reads may ensue because the only bounds<br /> check that is there is based on that length value.<br /> <br /> This patch adds explicit bounds checks for each field that is decoded<br /> or skipped.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: Remove queue freezing from several sysfs store callbacks<br /> <br /> Freezing the request queue from inside sysfs store callbacks may cause a<br /> deadlock in combination with the dm-multipath driver and the<br /> queue_if_no_path option. Additionally, freezing the request queue slows<br /> down system boot on systems where sysfs attributes are set synchronously.<br /> <br /> Fix this by removing the blk_mq_freeze_queue() / blk_mq_unfreeze_queue()<br /> calls from the store callbacks that do not strictly need these callbacks.<br /> Add the __data_racy annotation to request_queue.rq_timeout to suppress<br /> KCSAN data race reports about the rq_timeout reads.<br /> <br /> This patch may cause a small delay in applying the new settings.<br /> <br /> For all the attributes affected by this patch, I/O will complete<br /> correctly whether the old or the new value of the attribute is used.<br /> <br /> This patch affects the following sysfs attributes:<br /> * io_poll_delay<br /> * io_timeout<br /> * nomerges<br /> * read_ahead_kb<br /> * rq_affinity<br /> <br /> Here is an example of a deadlock triggered by running test srp/002<br /> if this patch is not applied:<br /> <br /> task:multipathd<br /> Call Trace:<br /> <br /> __schedule+0x8c1/0x1bf0<br /> schedule+0xdd/0x270<br /> schedule_preempt_disabled+0x1c/0x30<br /> __mutex_lock+0xb89/0x1650<br /> mutex_lock_nested+0x1f/0x30<br /> dm_table_set_restrictions+0x823/0xdf0<br /> __bind+0x166/0x590<br /> dm_swap_table+0x2a7/0x490<br /> do_resume+0x1b1/0x610<br /> dev_suspend+0x55/0x1a0<br /> ctl_ioctl+0x3a5/0x7e0<br /> dm_ctl_ioctl+0x12/0x20<br /> __x64_sys_ioctl+0x127/0x1a0<br /> x64_sys_call+0xe2b/0x17d0<br /> do_syscall_64+0x96/0x3a0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> task:(udev-worker)<br /> Call Trace:<br /> <br /> __schedule+0x8c1/0x1bf0<br /> schedule+0xdd/0x270<br /> blk_mq_freeze_queue_wait+0xf2/0x140<br /> blk_mq_freeze_queue_nomemsave+0x23/0x30<br /> queue_ra_store+0x14e/0x290<br /> queue_attr_store+0x23e/0x2c0<br /> sysfs_kf_write+0xde/0x140<br /> kernfs_fop_write_iter+0x3b2/0x630<br /> vfs_write+0x4fd/0x1390<br /> ksys_write+0xfd/0x230<br /> __x64_sys_write+0x76/0xc0<br /> x64_sys_call+0x276/0x17d0<br /> do_syscall_64+0x96/0x3a0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPICA: Avoid walking the Namespace if start_node is NULL<br /> <br /> Although commit 0c9992315e73 ("ACPICA: Avoid walking the ACPI Namespace<br /> if it is not there") fixed the situation when both start_node and<br /> acpi_gbl_root_node are NULL, the Linux kernel mainline now still crashed<br /> on Honor Magicbook 14 Pro [1].<br /> <br /> That happens due to the access to the member of parent_node in<br /> acpi_ns_get_next_node(). The NULL pointer dereference will always<br /> happen, no matter whether or not the start_node is equal to<br /> ACPI_ROOT_OBJECT, so move the check of start_node being NULL<br /> out of the if block.<br /> <br /> Unfortunately, all the attempts to contact Honor have failed, they<br /> refused to provide any technical support for Linux.<br /> <br /> The bad DSDT table&amp;#39;s dump could be found on GitHub [2].<br /> <br /> DMI: HONOR FMB-P/FMB-P-PCB, BIOS 1.13 05/08/2025<br /> <br /> [ rjw: Subject adjustment, changelog edits ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/kexec: Enable SMT before waking offline CPUs<br /> <br /> If SMT is disabled or a partial SMT state is enabled, when a new kernel<br /> image is loaded for kexec, on reboot the following warning is observed:<br /> <br /> kexec: Waking offline cpu 228.<br /> WARNING: CPU: 0 PID: 9062 at arch/powerpc/kexec/core_64.c:223 kexec_prepare_cpus+0x1b0/0x1bc<br /> [snip]<br /> NIP kexec_prepare_cpus+0x1b0/0x1bc<br /> LR kexec_prepare_cpus+0x1a0/0x1bc<br /> Call Trace:<br /> kexec_prepare_cpus+0x1a0/0x1bc (unreliable)<br /> default_machine_kexec+0x160/0x19c<br /> machine_kexec+0x80/0x88<br /> kernel_kexec+0xd0/0x118<br /> __do_sys_reboot+0x210/0x2c4<br /> system_call_exception+0x124/0x320<br /> system_call_vectored_common+0x15c/0x2ec<br /> <br /> This occurs as add_cpu() fails due to cpu_bootable() returning false for<br /> CPUs that fail the cpu_smt_thread_allowed() check or non primary<br /> threads if SMT is disabled.<br /> <br /> Fix the issue by enabling SMT and resetting the number of SMT threads to<br /> the number of threads per core, before attempting to wake up all present<br /> CPUs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> SUNRPC: svcauth_gss: avoid NULL deref on zero length gss_token in gss_read_proxy_verf<br /> <br /> A zero length gss_token results in pages == 0 and in_token-&gt;pages[0]<br /> is NULL. The code unconditionally evaluates<br /> page_address(in_token-&gt;pages[0]) for the initial memcpy, which can<br /> dereference NULL even when the copy length is 0. Guard the first<br /> memcpy so it only runs when length &gt; 0.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> parisc: Do not reprogram affinitiy on ASP chip<br /> <br /> The ASP chip is a very old variant of the GSP chip and is used e.g. in<br /> HP 730 workstations. When trying to reprogram the affinity it will crash<br /> with a HPMC as the relevant registers don&amp;#39;t seem to be at the usual<br /> location. Let&amp;#39;s avoid the crash by checking the sversion. Also note,<br /> that reprogramming isn&amp;#39;t necessary either, as the HP730 is a just a<br /> single-CPU machine.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommufd/selftest: Check for overflow in IOMMU_TEST_OP_ADD_RESERVED<br /> <br /> syzkaller found it could overflow math in the test infrastructure and<br /> cause a WARN_ON by corrupting the reserved interval tree. This only<br /> effects test kernels with CONFIG_IOMMUFD_TEST.<br /> <br /> Validate the user input length in the test ioctl.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/slub: reset KASAN tag in defer_free() before accessing freed memory<br /> <br /> When CONFIG_SLUB_TINY is enabled, kfree_nolock() calls kasan_slab_free()<br /> before defer_free(). On ARM64 with MTE (Memory Tagging Extension),<br /> kasan_slab_free() poisons the memory and changes the tag from the<br /> original (e.g., 0xf3) to a poison tag (0xfe).<br /> <br /> When defer_free() then tries to write to the freed object to build the<br /> deferred free list via llist_add(), the pointer still has the old tag,<br /> causing a tag mismatch and triggering a KASAN use-after-free report:<br /> <br /> BUG: KASAN: slab-use-after-free in defer_free+0x3c/0xbc mm/slub.c:6537<br /> Write at addr f3f000000854f020 by task kworker/u8:6/983<br /> Pointer tag: [f3], memory tag: [fe]<br /> <br /> Fix this by calling kasan_reset_tag() before accessing the freed memory.<br /> This is safe because defer_free() is part of the allocator itself and is<br /> expected to manipulate freed memory for bookkeeping purposes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (w83791d) Convert macros to functions to avoid TOCTOU<br /> <br /> The macro FAN_FROM_REG evaluates its arguments multiple times. When used<br /> in lockless contexts involving shared driver data, this leads to<br /> Time-of-Check to Time-of-Use (TOCTOU) race conditions, potentially<br /> causing divide-by-zero errors.<br /> <br /> Convert the macro to a static function. This guarantees that arguments<br /> are evaluated only once (pass-by-value), preventing the race<br /> conditions.<br /> <br /> Additionally, in store_fan_div, move the calculation of the minimum<br /> limit inside the update lock. This ensures that the read-modify-write<br /> sequence operates on consistent data.<br /> <br /> Adhere to the principle of minimal changes by only converting macros<br /> that evaluate arguments multiple times and are used in lockless<br /> contexts.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hns3: add VLAN id validation before using<br /> <br /> Currently, the VLAN id may be used without validation when<br /> receive a VLAN configuration mailbox from VF. The length of<br /> vlan_del_fail_bmap is BITS_TO_LONGS(VLAN_N_VID). It may cause<br /> out-of-bounds memory access once the VLAN id is bigger than<br /> or equal to VLAN_N_VID.<br /> <br /> Therefore, VLAN id needs to be checked to ensure it is within<br /> the range of VLAN_N_VID.