Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: always call ceph_shift_unused_folios_left()<br /> <br /> The function ceph_process_folio_batch() sets folio_batch entries to<br /> NULL, which is an illegal state. Before folio_batch_release() crashes<br /> due to this API violation, the function ceph_shift_unused_folios_left()<br /> is supposed to remove those NULLs from the array.<br /> <br /> However, since commit ce80b76dd327 ("ceph: introduce<br /> ceph_process_folio_batch() method"), this shifting doesn&amp;#39;t happen<br /> anymore because the "for" loop got moved to ceph_process_folio_batch(),<br /> and now the `i` variable that remains in ceph_writepages_start()<br /> doesn&amp;#39;t get incremented anymore, making the shifting effectively<br /> unreachable much of the time.<br /> <br /> Later, commit 1551ec61dc55 ("ceph: introduce ceph_submit_write()<br /> method") added more preconditions for doing the shift, replacing the<br /> `i` check (with something that is still just as broken):<br /> <br /> - if ceph_process_folio_batch() fails, shifting never happens<br /> <br /> - if ceph_move_dirty_page_in_page_array() was never called (because<br /> ceph_process_folio_batch() has returned early for some of various<br /> reasons), shifting never happens<br /> <br /> - if `processed_in_fbatch` is zero (because ceph_process_folio_batch()<br /> has returned early for some of the reasons mentioned above or<br /> because ceph_move_dirty_page_in_page_array() has failed), shifting<br /> never happens<br /> <br /> Since those two commits, any problem in ceph_process_folio_batch()<br /> could crash the kernel, e.g. this way:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000034<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> PGD 0 P4D 0<br /> Oops: Oops: 0002 [#1] SMP NOPTI<br /> CPU: 172 UID: 0 PID: 2342707 Comm: kworker/u778:8 Not tainted 6.15.10-cm4all1-es #714 NONE<br /> Hardware name: Dell Inc. PowerEdge R7615/0G9DHV, BIOS 1.6.10 12/08/2023<br /> Workqueue: writeback wb_workfn (flush-ceph-1)<br /> RIP: 0010:folios_put_refs+0x85/0x140<br /> Code: 83 c5 01 39 e8 7e 76 48 63 c5 49 8b 5c c4 08 b8 01 00 00 00 4d 85 ed 74 05 41 8b 44 ad 00 48 8b 15 b0 &gt;<br /> RSP: 0018:ffffb880af8db778 EFLAGS: 00010207<br /> RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000003<br /> RDX: ffffe377cc3b0000 RSI: 0000000000000000 RDI: ffffb880af8db8c0<br /> RBP: 0000000000000000 R08: 000000000000007d R09: 000000000102b86f<br /> R10: 0000000000000001 R11: 00000000000000ac R12: ffffb880af8db8c0<br /> R13: 0000000000000000 R14: 0000000000000000 R15: ffff9bd262c97000<br /> FS: 0000000000000000(0000) GS:ffff9c8efc303000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000034 CR3: 0000000160958004 CR4: 0000000000770ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ceph_writepages_start+0xeb9/0x1410<br /> <br /> The crash can be reproduced easily by changing the<br /> ceph_check_page_before_write() return value to `-E2BIG`.<br /> <br /> (Interestingly, the crash happens only if `huge_zero_folio` has<br /> already been allocated; without `huge_zero_folio`,<br /> is_huge_zero_folio(NULL) returns true and folios_put_refs() skips NULL<br /> entries instead of dereferencing them. That makes reproducing the bug<br /> somewhat unreliable. See<br /> https://lore.kernel.org/20250826231626.218675-1-max.kellermann@ionos.com<br /> for a discussion of this detail.)<br /> <br /> My suggestion is to move the ceph_shift_unused_folios_left() to right<br /> after ceph_process_folio_batch() to ensure it always gets called to<br /> fix up the illegal folio_batch state.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: fix invalid accesses to ceph_connection_v1_info<br /> <br /> There is a place where generic code in messenger.c is reading and<br /> another place where it is writing to con-&gt;v1 union member without<br /> checking that the union member is active (i.e. msgr1 is in use).<br /> <br /> On 64-bit systems, con-&gt;v1.auth_retry overlaps with con-&gt;v2.out_iter,<br /> so such a read is almost guaranteed to return a bogus value instead of<br /> 0 when msgr2 is in use. This ends up being fairly benign because the<br /> side effect is just the invalidation of the authorizer and successive<br /> fetching of new tickets.<br /> <br /> con-&gt;v1.connect_seq overlaps with con-&gt;v2.conn_bufs and the fact that<br /> it&amp;#39;s being written to can cause more serious consequences, but luckily<br /> it&amp;#39;s not something that happens often.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kernfs: Fix UAF in polling when open file is released<br /> <br /> A use-after-free (UAF) vulnerability was identified in the PSI (Pressure<br /> Stall Information) monitoring mechanism:<br /> <br /> BUG: KASAN: slab-use-after-free in psi_trigger_poll+0x3c/0x140<br /> Read of size 8 at addr ffff3de3d50bd308 by task systemd/1<br /> <br /> psi_trigger_poll+0x3c/0x140<br /> cgroup_pressure_poll+0x70/0xa0<br /> cgroup_file_poll+0x8c/0x100<br /> kernfs_fop_poll+0x11c/0x1c0<br /> ep_item_poll.isra.0+0x188/0x2c0<br /> <br /> Allocated by task 1:<br /> cgroup_file_open+0x88/0x388<br /> kernfs_fop_open+0x73c/0xaf0<br /> do_dentry_open+0x5fc/0x1200<br /> vfs_open+0xa0/0x3f0<br /> do_open+0x7e8/0xd08<br /> path_openat+0x2fc/0x6b0<br /> do_filp_open+0x174/0x368<br /> <br /> Freed by task 8462:<br /> cgroup_file_release+0x130/0x1f8<br /> kernfs_drain_open_files+0x17c/0x440<br /> kernfs_drain+0x2dc/0x360<br /> kernfs_show+0x1b8/0x288<br /> cgroup_file_show+0x150/0x268<br /> cgroup_pressure_write+0x1dc/0x340<br /> cgroup_file_write+0x274/0x548<br /> <br /> Reproduction Steps:<br /> 1. Open test/cpu.pressure and establish epoll monitoring<br /> 2. Disable monitoring: echo 0 &gt; test/cgroup.pressure<br /> 3. Re-enable monitoring: echo 1 &gt; test/cgroup.pressure<br /> <br /> The race condition occurs because:<br /> 1. When cgroup.pressure is disabled (echo 0 &gt; cgroup.pressure), it:<br /> - Releases PSI triggers via cgroup_file_release()<br /> - Frees of-&gt;priv through kernfs_drain_open_files()<br /> 2. While epoll still holds reference to the file and continues polling<br /> 3. Re-enabling (echo 1 &gt; cgroup.pressure) accesses freed of-&gt;priv<br /> <br /> epolling disable/enable cgroup.pressure<br /> fd=open(cpu.pressure)<br /> while(1)<br /> ...<br /> epoll_wait<br /> kernfs_fop_poll<br /> kernfs_get_active = true echo 0 &gt; cgroup.pressure<br /> ... cgroup_file_show<br /> kernfs_show<br /> // inactive kn<br /> kernfs_drain_open_files<br /> cft-&gt;release(of);<br /> kfree(ctx);<br /> ...<br /> kernfs_get_active = false<br /> echo 1 &gt; cgroup.pressure<br /> kernfs_show<br /> kernfs_activate_one(kn);<br /> kernfs_fop_poll<br /> kernfs_get_active = true<br /> cgroup_file_poll<br /> psi_trigger_poll<br /> // UAF<br /> ...<br /> end: close(fd)<br /> <br /> To address this issue, introduce kernfs_get_active_of() for kernfs open<br /> files to obtain active references. This function will fail if the open file<br /> has been released. Replace kernfs_get_active() with kernfs_get_active_of()<br /> to prevent further operations on released file descriptors.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/mediatek: fix potential OF node use-after-free<br /> <br /> The for_each_child_of_node() helper drops the reference it takes to each<br /> node as it iterates over children and an explicit of_node_put() is only<br /> needed when exiting the loop early.<br /> <br /> Drop the recently introduced bogus additional reference count decrement<br /> at each iteration that could potentially lead to a use-after-free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: ti: edma: Fix memory allocation size for queue_priority_map<br /> <br /> Fix a critical memory allocation bug in edma_setup_from_hw() where<br /> queue_priority_map was allocated with insufficient memory. The code<br /> declared queue_priority_map as s8 (*)[2] (pointer to array of 2 s8),<br /> but allocated memory using sizeof(s8) instead of the correct size.<br /> <br /> This caused out-of-bounds memory writes when accessing:<br /> queue_priority_map[i][0] = i;<br /> queue_priority_map[i][1] = i;<br /> <br /> The bug manifested as kernel crashes with "Oops - undefined instruction"<br /> on ARM platforms (BeagleBoard-X15) during EDMA driver probe, as the<br /> memory corruption triggered kernel hardening features on Clang.<br /> <br /> Change the allocation to use sizeof(*queue_priority_map) which<br /> automatically gets the correct size for the 2D array structure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: idxd: Fix double free in idxd_setup_wqs()<br /> <br /> The clean up in idxd_setup_wqs() has had a couple bugs because the error<br /> handling is a bit subtle. It&amp;#39;s simpler to just re-write it in a cleaner<br /> way. The issues here are:<br /> <br /> 1) If "idxd-&gt;max_wqs" is

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: idxd: Remove improper idxd_free<br /> <br /> The call to idxd_free() introduces a duplicate put_device() leading to a<br /> reference count underflow:<br /> refcount_t: underflow; use-after-free.<br /> WARNING: CPU: 15 PID: 4428 at lib/refcount.c:28 refcount_warn_saturate+0xbe/0x110<br /> ...<br /> Call Trace:<br /> <br /> idxd_remove+0xe4/0x120 [idxd]<br /> pci_device_remove+0x3f/0xb0<br /> device_release_driver_internal+0x197/0x200<br /> driver_detach+0x48/0x90<br /> bus_remove_driver+0x74/0xf0<br /> pci_unregister_driver+0x2e/0xb0<br /> idxd_exit_module+0x34/0x7a0 [idxd]<br /> __do_sys_delete_module.constprop.0+0x183/0x280<br /> do_syscall_64+0x54/0xd70<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> The idxd_unregister_devices() which is invoked at the very beginning of<br /> idxd_remove(), already takes care of the necessary put_device() through the<br /> following call path:<br /> idxd_unregister_devices() -&gt; device_unregister() -&gt; put_device()<br /> <br /> In addition, when CONFIG_DEBUG_KOBJECT_RELEASE is enabled, put_device() may<br /> trigger asynchronous cleanup via schedule_delayed_work(). If idxd_free() is<br /> called immediately after, it can result in a use-after-free.<br /> <br /> Remove the improper idxd_free() to avoid both the refcount underflow and<br /> potential memory corruption during module unload.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hsr: hold rcu and dev lock for hsr_get_port_ndev<br /> <br /> hsr_get_port_ndev calls hsr_for_each_port, which need to hold rcu lock.<br /> On the other hand, before return the port device, we need to hold the<br /> device reference to avoid UaF in the caller function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: xilinx_can: xcan_write_frame(): fix use-after-free of transmitted SKB<br /> <br /> can_put_echo_skb() takes ownership of the SKB and it may be freed<br /> during or after the call.<br /> <br /> However, xilinx_can xcan_write_frame() keeps using SKB after the call.<br /> <br /> Fix that by only calling can_put_echo_skb() after the code is done<br /> touching the SKB.<br /> <br /> The tx_lock is held for the entire xcan_write_frame() execution and<br /> also on the can_get_echo_skb() side so the order of operations does not<br /> matter.<br /> <br /> An earlier fix commit 3d3c817c3a40 ("can: xilinx_can: Fix usage of skb<br /> memory") did not move the can_put_echo_skb() call far enough.<br /> <br /> [mkl: add "commit" in front of sha1 in patch description]<br /> [mkl: fix indention]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> macsec: sync features on RTM_NEWLINK<br /> <br /> Syzkaller managed to lock the lower device via ETHTOOL_SFEATURES:<br /> <br /> netdev_lock include/linux/netdevice.h:2761 [inline]<br /> netdev_lock_ops include/net/netdev_lock.h:42 [inline]<br /> netdev_sync_lower_features net/core/dev.c:10649 [inline]<br /> __netdev_update_features+0xcb1/0x1be0 net/core/dev.c:10819<br /> netdev_update_features+0x6d/0xe0 net/core/dev.c:10876<br /> macsec_notify+0x2f5/0x660 drivers/net/macsec.c:4533<br /> notifier_call_chain+0x1b3/0x3e0 kernel/notifier.c:85<br /> call_netdevice_notifiers_extack net/core/dev.c:2267 [inline]<br /> call_netdevice_notifiers net/core/dev.c:2281 [inline]<br /> netdev_features_change+0x85/0xc0 net/core/dev.c:1570<br /> __dev_ethtool net/ethtool/ioctl.c:3469 [inline]<br /> dev_ethtool+0x1536/0x19b0 net/ethtool/ioctl.c:3502<br /> dev_ioctl+0x392/0x1150 net/core/dev_ioctl.c:759<br /> <br /> It happens because lower features are out of sync with the upper:<br /> <br /> __dev_ethtool (real_dev)<br /> netdev_lock_ops(real_dev)<br /> ETHTOOL_SFEATURES<br /> __netdev_features_change<br /> netdev_sync_upper_features<br /> disable LRO on the lower<br /> if (old_features != dev-&gt;features)<br /> netdev_features_change<br /> fires NETDEV_FEAT_CHANGE<br /> macsec_notify<br /> NETDEV_FEAT_CHANGE<br /> netdev_update_features (for each macsec dev)<br /> netdev_sync_lower_features<br /> if (upper_features != lower_features)<br /> netdev_lock_ops(lower) # lower == real_dev<br /> stuck<br /> ...<br /> <br /> netdev_unlock_ops(real_dev)<br /> <br /> Per commit af5f54b0ef9e ("net: Lock lower level devices when updating<br /> features"), we elide the lock/unlock when the upper and lower features<br /> are synced. Makes sure the lower (real_dev) has proper features after<br /> the macsec link has been created. This makes sure we never hit the<br /> situation where we need to sync upper flags to the lower.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> igb: Fix NULL pointer dereference in ethtool loopback test<br /> <br /> The igb driver currently causes a NULL pointer dereference when executing<br /> the ethtool loopback test. This occurs because there is no associated<br /> q_vector for the test ring when it is set up, as interrupts are typically<br /> not added to the test rings.<br /> <br /> Since commit 5ef44b3cb43b removed the napi_id assignment in<br /> __xdp_rxq_info_reg(), there is no longer a need to pass a napi_id to it.<br /> Therefore, simply use 0 as the last parameter.

A vulnerability was detected in code-projects Online Bidding System 1.0. Affected is an unknown function of the file /administrator/wew.php. Performing manipulation of the argument ID results in sql injection. The attack may be initiated remotely. The exploit is now public and may be used.