Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netdevsim: fix a race issue related to the operation on bpf_bound_progs list<br /> <br /> The netdevsim driver lacks a protection mechanism for operations on the<br /> bpf_bound_progs list. When the nsim_bpf_create_prog() performs<br /> list_add_tail, it is possible that nsim_bpf_destroy_prog() is<br /> simultaneously performs list_del. Concurrent operations on the list may<br /> lead to list corruption and trigger a kernel crash as follows:<br /> <br /> [ 417.290971] kernel BUG at lib/list_debug.c:62!<br /> [ 417.290983] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 417.290992] CPU: 10 PID: 168 Comm: kworker/10:1 Kdump: loaded Not tainted 6.19.0-rc5 #1<br /> [ 417.291003] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 417.291007] Workqueue: events bpf_prog_free_deferred<br /> [ 417.291021] RIP: 0010:__list_del_entry_valid_or_report+0xa7/0xc0<br /> [ 417.291034] Code: a8 ff 0f 0b 48 89 fe 48 89 ca 48 c7 c7 48 a1 eb ae e8 ed fb a8 ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 80 a1 eb ae e8 d9 fb a8 ff 0b 48 89 d1 48 c7 c7 d0 a1 eb ae 48 89 f2 48 89 c6 e8 c2 fb a8<br /> [ 417.291040] RSP: 0018:ffffb16a40807df8 EFLAGS: 00010246<br /> [ 417.291046] RAX: 000000000000006d RBX: ffff8e589866f500 RCX: 0000000000000000<br /> [ 417.291051] RDX: 0000000000000000 RSI: ffff8e59f7b23180 RDI: ffff8e59f7b23180<br /> [ 417.291055] RBP: ffffb16a412c9000 R08: 0000000000000000 R09: 0000000000000003<br /> [ 417.291059] R10: ffffb16a40807c80 R11: ffffffffaf9edce8 R12: ffff8e594427ac20<br /> [ 417.291063] R13: ffff8e59f7b44780 R14: ffff8e58800b7a05 R15: 0000000000000000<br /> [ 417.291074] FS: 0000000000000000(0000) GS:ffff8e59f7b00000(0000) knlGS:0000000000000000<br /> [ 417.291079] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 417.291083] CR2: 00007fc4083efe08 CR3: 00000001c3626006 CR4: 0000000000770ee0<br /> [ 417.291088] PKRU: 55555554<br /> [ 417.291091] Call Trace:<br /> [ 417.291096] <br /> [ 417.291103] nsim_bpf_destroy_prog+0x31/0x80 [netdevsim]<br /> [ 417.291154] __bpf_prog_offload_destroy+0x2a/0x80<br /> [ 417.291163] bpf_prog_dev_bound_destroy+0x6f/0xb0<br /> [ 417.291171] bpf_prog_free_deferred+0x18e/0x1a0<br /> [ 417.291178] process_one_work+0x18a/0x3a0<br /> [ 417.291188] worker_thread+0x27b/0x3a0<br /> [ 417.291197] ? __pfx_worker_thread+0x10/0x10<br /> [ 417.291207] kthread+0xe5/0x120<br /> [ 417.291214] ? __pfx_kthread+0x10/0x10<br /> [ 417.291221] ret_from_fork+0x31/0x50<br /> [ 417.291230] ? __pfx_kthread+0x10/0x10<br /> [ 417.291236] ret_from_fork_asm+0x1a/0x30<br /> [ 417.291246] <br /> <br /> Add a mutex lock, to prevent simultaneous addition and deletion operations<br /> on the list.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf: Fix refcount warning on event-&gt;mmap_count increment<br /> <br /> When calling refcount_inc(&amp;event-&gt;mmap_count) inside perf_mmap_rb(), the<br /> following warning is triggered:<br /> <br /> refcount_t: addition on 0; use-after-free.<br /> WARNING: lib/refcount.c:25<br /> <br /> PoC:<br /> <br /> struct perf_event_attr attr = {0};<br /> int fd = syscall(__NR_perf_event_open, &amp;attr, 0, -1, -1, 0);<br /> mmap(NULL, 0x3000, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);<br /> int victim = syscall(__NR_perf_event_open, &amp;attr, 0, -1, fd,<br /> PERF_FLAG_FD_OUTPUT);<br /> mmap(NULL, 0x3000, PROT_READ | PROT_WRITE, MAP_SHARED, victim, 0);<br /> <br /> This occurs when creating a group member event with the flag<br /> PERF_FLAG_FD_OUTPUT. The group leader should be mmap-ed and then mmap-ing<br /> the event triggers the warning.<br /> <br /> Since the event has copied the output_event in perf_event_set_output(),<br /> event-&gt;rb is set. As a result, perf_mmap_rb() calls<br /> refcount_inc(&amp;event-&gt;mmap_count) when event-&gt;mmap_count = 0.<br /> <br /> Disallow the case when event-&gt;mmap_count = 0. This also prevents two<br /> events from updating the same user_page.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop<br /> <br /> Currently this is checked before running the pending work. Normally this<br /> is quite fine, as work items either end up blocking (which will create a<br /> new worker for other items), or they complete fairly quickly. But syzbot<br /> reports an issue where io-wq takes seemingly forever to exit, and with a<br /> bit of debugging, this turns out to be because it queues a bunch of big<br /> (2GB - 4096b) reads with a /dev/msr* file. Since this file type doesn&amp;#39;t<br /> support -&gt;read_iter(), loop_rw_iter() ends up handling them. Each read<br /> returns 16MB of data read, which takes 20 (!!) seconds. With a bunch of<br /> these pending, processing the whole chain can take a long time. Easily<br /> longer than the syzbot uninterruptible sleep timeout of 140 seconds.<br /> This then triggers a complaint off the io-wq exit path:<br /> <br /> INFO: task syz.4.135:6326 blocked for more than 143 seconds.<br /> Not tainted syzkaller #0<br /> Blocked by coredump.<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> task:syz.4.135 state:D stack:26824 pid:6326 tgid:6324 ppid:5957 task_flags:0x400548 flags:0x00080000<br /> Call Trace:<br /> <br /> context_switch kernel/sched/core.c:5256 [inline]<br /> __schedule+0x1139/0x6150 kernel/sched/core.c:6863<br /> __schedule_loop kernel/sched/core.c:6945 [inline]<br /> schedule+0xe7/0x3a0 kernel/sched/core.c:6960<br /> schedule_timeout+0x257/0x290 kernel/time/sleep_timeout.c:75<br /> do_wait_for_common kernel/sched/completion.c:100 [inline]<br /> __wait_for_common+0x2fc/0x4e0 kernel/sched/completion.c:121<br /> io_wq_exit_workers io_uring/io-wq.c:1328 [inline]<br /> io_wq_put_and_exit+0x271/0x8a0 io_uring/io-wq.c:1356<br /> io_uring_clean_tctx+0x10d/0x190 io_uring/tctx.c:203<br /> io_uring_cancel_generic+0x69c/0x9a0 io_uring/cancel.c:651<br /> io_uring_files_cancel include/linux/io_uring.h:19 [inline]<br /> do_exit+0x2ce/0x2bd0 kernel/exit.c:911<br /> do_group_exit+0xd3/0x2a0 kernel/exit.c:1112<br /> get_signal+0x2671/0x26d0 kernel/signal.c:3034<br /> arch_do_signal_or_restart+0x8f/0x7e0 arch/x86/kernel/signal.c:337<br /> __exit_to_user_mode_loop kernel/entry/common.c:41 [inline]<br /> exit_to_user_mode_loop+0x8c/0x540 kernel/entry/common.c:75<br /> __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]<br /> syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]<br /> syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline]<br /> syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline]<br /> do_syscall_64+0x4ee/0xf80 arch/x86/entry/syscall_64.c:100<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7fa02738f749<br /> RSP: 002b:00007fa0281ae0e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca<br /> RAX: fffffffffffffe00 RBX: 00007fa0275e6098 RCX: 00007fa02738f749<br /> RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fa0275e6098<br /> RBP: 00007fa0275e6090 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007fa0275e6128 R14: 00007fff14e4fcb0 R15: 00007fff14e4fd98<br /> <br /> There&amp;#39;s really nothing wrong here, outside of processing these reads<br /> will take a LONG time. However, we can speed up the exit by checking the<br /> IO_WQ_BIT_EXIT inside the io_worker_handle_work() loop, as syzbot will<br /> exit the ring after queueing up all of these reads. Then once the first<br /> item is processed, io-wq will simply cancel the rest. That should avoid<br /> syzbot running into this complaint again.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64/fpsimd: ptrace: Fix SVE writes on !SME systems<br /> <br /> When SVE is supported but SME is not supported, a ptrace write to the<br /> NT_ARM_SVE regset can place the tracee into an invalid state where<br /> (non-streaming) SVE register data is stored in FP_STATE_SVE format but<br /> TIF_SVE is clear. This can result in a later warning from<br /> fpsimd_restore_current_state(), e.g.<br /> <br /> WARNING: CPU: 0 PID: 7214 at arch/arm64/kernel/fpsimd.c:383 fpsimd_restore_current_state+0x50c/0x748<br /> <br /> When this happens, fpsimd_restore_current_state() will set TIF_SVE,<br /> placing the task into the correct state. This occurs before any other<br /> check of TIF_SVE can possibly occur, as other checks of TIF_SVE only<br /> happen while the FPSIMD/SVE/SME state is live. Thus, aside from the<br /> warning, there is no functional issue.<br /> <br /> This bug was introduced during rework to error handling in commit:<br /> <br /> 9f8bf718f2923 ("arm64/fpsimd: ptrace: Gracefully handle errors")<br /> <br /> ... where the setting of TIF_SVE was moved into a block which is only<br /> executed when system_supports_sme() is true.<br /> <br /> Fix this by removing the system_supports_sme() check. This ensures that<br /> TIF_SVE is set for (SVE-formatted) writes to NT_ARM_SVE, at the cost of<br /> unconditionally manipulating the tracee&amp;#39;s saved svcr value. The<br /> manipulation of svcr is benign and inexpensive, and we already do<br /> similar elsewhere (e.g. during signal handling), so I don&amp;#39;t think it&amp;#39;s<br /> worth guarding this with system_supports_sme() checks.<br /> <br /> Aside from the above, there is no functional change. The &amp;#39;type&amp;#39; argument<br /> to sve_set_common() is only set to ARM64_VEC_SME (in ssve_set())) when<br /> system_supports_sme(), so the ARM64_VEC_SME case in the switch statement<br /> is still unreachable when !system_supports_sme(). When<br /> CONFIG_ARM64_SME=n, the only caller of sve_set_common() is sve_set(),<br /> and the compiler can constant-fold for the case where type is<br /> ARM64_VEC_SVE, removing the logic for other cases.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: Fix not set tty-&gt;port race condition<br /> <br /> Revert commit bfc467db60b7 ("serial: remove redundant<br /> tty_port_link_device()") because the tty_port_link_device() is not<br /> redundant: the tty-&gt;port has to be confured before we call<br /> uart_configure_port(), otherwise user-space can open console without TTY<br /> linked to the driver.<br /> <br /> This tty_port_link_device() was added explicitly to avoid this exact<br /> issue in commit fb2b90014d78 ("tty: link tty and port before configuring<br /> it as console"), so offending commit basically reverted the fix saying<br /> it is redundant without addressing the actual race condition presented<br /> there.<br /> <br /> Reproducible always as tty-&gt;port warning on Qualcomm SoC with most of<br /> devices disabled, so with very fast boot, and one serial device being<br /> the console:<br /> <br /> printk: legacy console [ttyMSM0] enabled<br /> printk: legacy console [ttyMSM0] enabled<br /> printk: legacy bootconsole [qcom_geni0] disabled<br /> printk: legacy bootconsole [qcom_geni0] disabled<br /> ------------[ cut here ]------------<br /> tty_init_dev: ttyMSM driver does not set tty-&gt;port. This would crash the kernel. Fix the driver!<br /> WARNING: drivers/tty/tty_io.c:1414 at tty_init_dev.part.0+0x228/0x25c, CPU#2: systemd/1<br /> Modules linked in: socinfo tcsrcc_eliza gcc_eliza sm3_ce fuse ipv6<br /> CPU: 2 UID: 0 PID: 1 Comm: systemd Tainted: G S 6.19.0-rc4-next-20260108-00024-g2202f4d30aa8 #73 PREEMPT<br /> Tainted: [S]=CPU_OUT_OF_SPEC<br /> Hardware name: Qualcomm Technologies, Inc. Eliza (DT)<br /> ...<br /> tty_init_dev.part.0 (drivers/tty/tty_io.c:1414 (discriminator 11)) (P)<br /> tty_open (arch/arm64/include/asm/atomic_ll_sc.h:95 (discriminator 3) drivers/tty/tty_io.c:2073 (discriminator 3) drivers/tty/tty_io.c:2120 (discriminator 3))<br /> chrdev_open (fs/char_dev.c:411)<br /> do_dentry_open (fs/open.c:962)<br /> vfs_open (fs/open.c:1094)<br /> do_open (fs/namei.c:4634)<br /> path_openat (fs/namei.c:4793)<br /> do_filp_open (fs/namei.c:4820)<br /> do_sys_openat2 (fs/open.c:1391 (discriminator 3))<br /> ...<br /> Starting Network Name Resolution...<br /> <br /> Apparently the flow with this small Yocto-based ramdisk user-space is:<br /> <br /> driver (qcom_geni_serial.c): user-space:<br /> ============================ ===========<br /> qcom_geni_serial_probe()<br /> uart_add_one_port()<br /> serial_core_register_port()<br /> serial_core_add_one_port()<br /> uart_configure_port()<br /> register_console()<br /> |<br /> | open console<br /> | ...<br /> | tty_init_dev()<br /> | driver-&gt;ports[idx] is NULL<br /> |<br /> tty_port_register_device_attr_serdev()<br /> tty_port_link_device() ports[idx]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pmdomain: imx8m-blk-ctrl: Remove separate rst and clk mask for 8mq vpu<br /> <br /> For i.MX8MQ platform, the ADB in the VPUMIX domain has no separate reset<br /> and clock enable bits, but is ungated and reset together with the VPUs.<br /> So we can&amp;#39;t reset G1 or G2 separately, it may led to the system hang.<br /> Remove rst_mask and clk_mask of imx8mq_vpu_blk_ctl_domain_data.<br /> Let imx8mq_vpu_power_notifier() do really vpu reset.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: add missing ice_deinit_hw() in devlink reinit path<br /> <br /> devlink-reload results in ice_init_hw failed error, and then removing<br /> the ice driver causes a NULL pointer dereference.<br /> <br /> [ +0.102213] ice 0000:ca:00.0: ice_init_hw failed: -16<br /> ...<br /> [ +0.000001] Call Trace:<br /> [ +0.000003] <br /> [ +0.000006] ice_unload+0x8f/0x100 [ice]<br /> [ +0.000081] ice_remove+0xba/0x300 [ice]<br /> <br /> Commit 1390b8b3d2be ("ice: remove duplicate call to ice_deinit_hw() on<br /> error paths") removed ice_deinit_hw() from ice_deinit_dev(). As a result<br /> ice_devlink_reinit_down() no longer calls ice_deinit_hw(), but<br /> ice_devlink_reinit_up() still calls ice_init_hw(). Since the control<br /> queues are not uninitialized, ice_init_hw() fails with -EBUSY.<br /> <br /> Add ice_deinit_hw() to ice_devlink_reinit_down() to correspond with<br /> ice_init_hw() in ice_devlink_reinit_up().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix data-race warning and potential load/store tearing<br /> <br /> Fix the following:<br /> <br /> BUG: KCSAN: data-race in rxrpc_peer_keepalive_worker / rxrpc_send_data_packet<br /> <br /> which is reporting an issue with the reads and writes to -&gt;last_tx_at in:<br /> <br /> conn-&gt;peer-&gt;last_tx_at = ktime_get_seconds();<br /> <br /> and:<br /> <br /> keepalive_at = peer-&gt;last_tx_at + RXRPC_KEEPALIVE_TIME;<br /> <br /> The lockless accesses to these to values aren&amp;#39;t actually a problem as the<br /> read only needs an approximate time of last transmission for the purposes<br /> of deciding whether or not the transmission of a keepalive packet is<br /> warranted yet.<br /> <br /> Also, as -&gt;last_tx_at is a 64-bit value, tearing can occur on a 32-bit<br /> arch.<br /> <br /> Fix both of these by switching to an unsigned int for -&gt;last_tx_at and only<br /> storing the LSW of the time64_t. It can then be reconstructed at need<br /> provided no more than 68 years has elapsed since the last transmission.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: sdhci-of-dwcmshc: Prevent illegal clock reduction in HS200/HS400 mode<br /> <br /> When operating in HS200 or HS400 timing modes, reducing the clock frequency<br /> below 52MHz will lead to link broken as the Rockchip DWC MSHC controller<br /> requires maintaining a minimum clock of 52MHz in these modes.<br /> <br /> Add a check to prevent illegal clock reduction through debugfs:<br /> <br /> root@debian:/# echo 50000000 &gt; /sys/kernel/debug/mmc0/clock<br /> root@debian:/# [ 30.090146] mmc0: running CQE recovery<br /> mmc0: cqhci: Failed to halt<br /> mmc0: cqhci: spurious TCN for tag 0<br /> WARNING: drivers/mmc/host/cqhci-core.c:797 at cqhci_irq+0x254/0x818, CPU#1: kworker/1:0H/24<br /> Modules linked in:<br /> CPU: 1 UID: 0 PID: 24 Comm: kworker/1:0H Not tainted 6.19.0-rc1-00001-g09db0998649d-dirty #204 PREEMPT<br /> Hardware name: Rockchip RK3588 EVB1 V10 Board (DT)<br /> Workqueue: kblockd blk_mq_run_work_fn<br /> pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : cqhci_irq+0x254/0x818<br /> lr : cqhci_irq+0x254/0x818<br /> ...

The Media Library Folders plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 8.3.6 via the delete_maxgalleria_media() and maxgalleria_rename_image() functions due to missing validation on a user controlled key. This makes it possible for authenticated attackers, with Author-level access and above, to delete or rename attachments owned by other users (including administrators). The rename flow also deletes all postmeta for the target attachment, causing data loss.

The Essential Addons for Elementor – Popular Elementor Templates &amp; Widgets plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin&amp;#39;s Info Box widget in all versions up to, and including, 6.5.9 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

The Modula Image Gallery – Photo Grid &amp; Video Gallery plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 2.13.6. This is due to the plugin not properly verifying that a user is authorized to modify specific posts before updating them via the REST API. This makes it possible for authenticated attackers, with contributor level access and above, to update the title, excerpt, and content of arbitrary posts by passing post IDs in the modulaImages field when editing a gallery.