Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: BPF: Sign extend kfunc call arguments<br /> <br /> The kfunc calls are native calls so they should follow LoongArch calling<br /> conventions. Sign extend its arguments properly to avoid kernel panic.<br /> This is done by adding a new emit_abi_ext() helper. The emit_abi_ext()<br /> helper performs extension in place meaning a value already store in the<br /> target register (Note: this is different from the existing sign_extend()<br /> helper and thus we can&amp;#39;t reuse it).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/gem: Zero-initialize the eb.vma array in i915_gem_do_execbuffer<br /> <br /> Initialize the eb.vma array with values of 0 when the eb structure is<br /> first set up. In particular, this sets the eb-&gt;vma[i].vma pointers to<br /> NULL, simplifying cleanup and getting rid of the bug described below.<br /> <br /> During the execution of eb_lookup_vmas(), the eb-&gt;vma array is<br /> successively filled up with struct eb_vma objects. This process includes<br /> calling eb_add_vma(), which might fail; however, even in the event of<br /> failure, eb-&gt;vma[i].vma is set for the currently processed buffer.<br /> <br /> If eb_add_vma() fails, eb_lookup_vmas() returns with an error, which<br /> prompts a call to eb_release_vmas() to clean up the mess. Since<br /> eb_lookup_vmas() might fail during processing any (possibly not first)<br /> buffer, eb_release_vmas() checks whether a buffer&amp;#39;s vma is NULL to know<br /> at what point did the lookup function fail.<br /> <br /> In eb_lookup_vmas(), eb-&gt;vma[i].vma is set to NULL if either the helper<br /> function eb_lookup_vma() or eb_validate_vma() fails. eb-&gt;vma[i+1].vma is<br /> set to NULL in case i915_gem_object_userptr_submit_init() fails; the<br /> current one needs to be cleaned up by eb_release_vmas() at this point,<br /> so the next one is set. If eb_add_vma() fails, neither the current nor<br /> the next vma is set to NULL, which is a source of a NULL deref bug<br /> described in the issue linked in the Closes tag.<br /> <br /> When entering eb_lookup_vmas(), the vma pointers are set to the slab<br /> poison value, instead of NULL. This doesn&amp;#39;t matter for the actual<br /> lookup, since it gets overwritten anyway, however the eb_release_vmas()<br /> function only recognizes NULL as the stopping value, hence the pointers<br /> are being set to NULL as they go in case of intermediate failure. This<br /> patch changes the approach to filling them all with NULL at the start<br /> instead, rather than handling that manually during failure.<br /> <br /> (cherry picked from commit 08889b706d4f0b8d2352b7ca29c2d8df4d0787cd)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: seqiv - Do not use req-&gt;iv after crypto_aead_encrypt<br /> <br /> As soon as crypto_aead_encrypt is called, the underlying request<br /> may be freed by an asynchronous completion. Thus dereferencing<br /> req-&gt;iv after it returns is invalid.<br /> <br /> Instead of checking req-&gt;iv against info, create a new variable<br /> unaligned_info and use it for that purpose instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smc91x: fix broken irq-context in PREEMPT_RT<br /> <br /> When smc91x.c is built with PREEMPT_RT, the following splat occurs<br /> in FVP_RevC:<br /> <br /> [ 13.055000] smc91x LNRO0003:00 eth0: link up, 10Mbps, half-duplex, lpa 0x0000<br /> [ 13.062137] BUG: workqueue leaked atomic, lock or RCU: kworker/2:1[106]<br /> [ 13.062137] preempt=0x00000000 lock=0-&gt;0 RCU=0-&gt;1 workfn=mld_ifc_work<br /> [ 13.062266] C<br /> ** replaying previous printk message **<br /> [ 13.062266] CPU: 2 UID: 0 PID: 106 Comm: kworker/2:1 Not tainted 6.18.0-dirty #179 PREEMPT_{RT,(full)}<br /> [ 13.062353] Hardware name: , BIOS<br /> [ 13.062382] Workqueue: mld mld_ifc_work<br /> [ 13.062469] Call trace:<br /> [ 13.062494] show_stack+0x24/0x40 (C)<br /> [ 13.062602] __dump_stack+0x28/0x48<br /> [ 13.062710] dump_stack_lvl+0x7c/0xb0<br /> [ 13.062818] dump_stack+0x18/0x34<br /> [ 13.062926] process_scheduled_works+0x294/0x450<br /> [ 13.063043] worker_thread+0x260/0x3d8<br /> [ 13.063124] kthread+0x1c4/0x228<br /> [ 13.063235] ret_from_fork+0x10/0x20<br /> <br /> This happens because smc_special_trylock() disables IRQs even on PREEMPT_RT,<br /> but smc_special_unlock() does not restore IRQs on PREEMPT_RT.<br /> The reason is that smc_special_unlock() calls spin_unlock_irqrestore(),<br /> and rcu_read_unlock_bh() in __dev_queue_xmit() cannot invoke<br /> rcu_read_unlock() through __local_bh_enable_ip() when current-&gt;softirq_disable_cnt becomes zero.<br /> <br /> To address this issue, replace smc_special_trylock() with spin_trylock_irqsave().

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.