Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: af_alg - zero initialize memory allocated via sock_kmalloc<br /> <br /> Several crypto user API contexts and requests allocated with<br /> sock_kmalloc() were left uninitialized, relying on callers to<br /> set fields explicitly. This resulted in the use of uninitialized<br /> data in certain error paths or when new fields are added in the<br /> future.<br /> <br /> The ACVP patches also contain two user-space interface files:<br /> algif_kpp.c and algif_akcipher.c. These too rely on proper<br /> initialization of their context structures.<br /> <br /> A particular issue has been observed with the newly added<br /> &amp;#39;inflight&amp;#39; variable introduced in af_alg_ctx by commit:<br /> <br /> 67b164a871af ("crypto: af_alg - Disallow multiple in-flight AIO requests")<br /> <br /> Because the context is not memset to zero after allocation,<br /> the inflight variable has contained garbage values. As a result,<br /> af_alg_alloc_areq() has incorrectly returned -EBUSY randomly when<br /> the garbage value was interpreted as true:<br /> <br /> https://github.com/gregkh/linux/blame/master/crypto/af_alg.c#L1209<br /> <br /> The check directly tests ctx-&gt;inflight without explicitly<br /> comparing against true/false. Since inflight is only ever set to<br /> true or false later, an uninitialized value has triggered<br /> -EBUSY failures. Zero-initializing memory allocated with<br /> sock_kmalloc() ensures inflight and other fields start in a known<br /> state, removing random issues caused by uninitialized data.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scs: fix a wrong parameter in __scs_magic<br /> <br /> __scs_magic() needs a &amp;#39;void *&amp;#39; variable, but a &amp;#39;struct task_struct *&amp;#39; is<br /> given. &amp;#39;task_scs(tsk)&amp;#39; is the starting address of the task&amp;#39;s shadow call<br /> stack, and &amp;#39;__scs_magic(task_scs(tsk))&amp;#39; is the end address of the task&amp;#39;s<br /> shadow call stack. Here should be &amp;#39;__scs_magic(task_scs(tsk))&amp;#39;.<br /> <br /> The user-visible effect of this bug is that when CONFIG_DEBUG_STACK_USAGE<br /> is enabled, the shadow call stack usage checking function<br /> (scs_check_usage) would scan an incorrect memory range. This could lead<br /> <br /> 1. **Inaccurate stack usage reporting**: The function would calculate<br /> wrong usage statistics for the shadow call stack, potentially showing<br /> incorrect value in kmsg.<br /> <br /> 2. **Potential kernel crash**: If the value of __scs_magic(tsk)is<br /> greater than that of __scs_magic(task_scs(tsk)), the for loop may<br /> access unmapped memory, potentially causing a kernel panic. However,<br /> this scenario is unlikely because task_struct is allocated via the slab<br /> allocator (which typically returns lower addresses), while the shadow<br /> call stack returned by task_scs(tsk) is allocated via vmalloc(which<br /> typically returns higher addresses).<br /> <br /> However, since this is purely a debugging feature<br /> (CONFIG_DEBUG_STACK_USAGE), normal production systems should be not<br /> unaffected. The bug only impacts developers and testers who are actively<br /> debugging stack usage with this configuration enabled.