Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Do not register unsupported perf events<br /> <br /> Synthetic events currently do not have a function to register perf events.<br /> This leads to calling the tracepoint register functions with a NULL<br /> function pointer which triggers:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: kernel/tracepoint.c:175 at tracepoint_add_func+0x357/0x370, CPU#2: perf/2272<br /> Modules linked in: kvm_intel kvm irqbypass<br /> CPU: 2 UID: 0 PID: 2272 Comm: perf Not tainted 6.18.0-ftest-11964-ge022764176fc-dirty #323 PREEMPTLAZY<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014<br /> RIP: 0010:tracepoint_add_func+0x357/0x370<br /> Code: 28 9c e8 4c 0b f5 ff eb 0f 4c 89 f7 48 c7 c6 80 4d 28 9c e8 ab 89 f4 ff 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc 0b 49 c7 c6 ea ff ff ff e9 ee fe ff ff 0f 0b e9 f9 fe ff ff 0f<br /> RSP: 0018:ffffabc0c44d3c40 EFLAGS: 00010246<br /> RAX: 0000000000000001 RBX: ffff9380aa9e4060 RCX: 0000000000000000<br /> RDX: 000000000000000a RSI: ffffffff9e1d4a98 RDI: ffff937fcf5fd6c8<br /> RBP: 0000000000000001 R08: 0000000000000007 R09: ffff937fcf5fc780<br /> R10: 0000000000000003 R11: ffffffff9c193910 R12: 000000000000000a<br /> R13: ffffffff9e1e5888 R14: 0000000000000000 R15: ffffabc0c44d3c78<br /> FS: 00007f6202f5f340(0000) GS:ffff93819f00f000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000055d3162281a8 CR3: 0000000106a56003 CR4: 0000000000172ef0<br /> Call Trace:<br /> <br /> tracepoint_probe_register+0x5d/0x90<br /> synth_event_reg+0x3c/0x60<br /> perf_trace_event_init+0x204/0x340<br /> perf_trace_init+0x85/0xd0<br /> perf_tp_event_init+0x2e/0x50<br /> perf_try_init_event+0x6f/0x230<br /> ? perf_event_alloc+0x4bb/0xdc0<br /> perf_event_alloc+0x65a/0xdc0<br /> __se_sys_perf_event_open+0x290/0x9f0<br /> do_syscall_64+0x93/0x7b0<br /> ? entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> ? trace_hardirqs_off+0x53/0xc0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Instead, have the code return -ENODEV, which doesn&amp;#39;t warn and has perf<br /> error out with:<br /> <br /> # perf record -e synthetic:futex_wait<br /> Error:<br /> The sys_perf_event_open() syscall returned with 19 (No such device) for event (synthetic:futex_wait).<br /> "dmesg | grep -i perf" may provide additional information.<br /> <br /> Ideally perf should support synthetic events, but for now just fix the<br /> warning. The support can come later.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: Discard Beacon frames to non-broadcast address<br /> <br /> Beacon frames are required to be sent to the broadcast address, see IEEE<br /> Std 802.11-2020, 11.1.3.1 ("The Address 1 field of the Beacon .. frame<br /> shall be set to the broadcast address"). A unicast Beacon frame might be<br /> used as a targeted attack to get one of the associated STAs to do<br /> something (e.g., using CSA to move it to another channel). As such, it<br /> is better have strict filtering for this on the received side and<br /> discard all Beacon frames that are sent to an unexpected address.<br /> <br /> This is even more important for cases where beacon protection is used.<br /> The current implementation in mac80211 is correctly discarding unicast<br /> Beacon frames if the Protected Frame bit in the Frame Control field is<br /> set to 0. However, if that bit is set to 1, the logic used for checking<br /> for configured BIGTK(s) does not actually work. If the driver does not<br /> have logic for dropping unicast Beacon frames with Protected Frame bit<br /> 1, these frames would be accepted in mac80211 processing as valid Beacon<br /> frames even though they are not protected. This would allow beacon<br /> protection to be bypassed. While the logic for checking beacon<br /> protection could be extended to cover this corner case, a more generic<br /> check for discard all Beacon frames based on A1=unicast address covers<br /> this without needing additional changes.<br /> <br /> Address all these issues by dropping received Beacon frames if they are<br /> sent to a non-broadcast address.

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 /> 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 /> 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 /> 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 /> 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 /> 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 /> 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 /> 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 /> 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.