Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc, afs: Fix peer hash locking vs RCU callback<br /> <br /> In its address list, afs now retains pointers to and refs on one or more<br /> rxrpc_peer objects. The address list is freed under RCU and at this time,<br /> it puts the refs on those peers.<br /> <br /> Now, when an rxrpc_peer object runs out of refs, it gets removed from the<br /> peer hash table and, for that, rxrpc has to take a spinlock. However, it<br /> is now being called from afs&amp;#39;s RCU cleanup, which takes place in BH<br /> context - but it is just taking an ordinary spinlock.<br /> <br /> The put may also be called from non-BH context, and so there exists the<br /> possibility of deadlock if the BH-based RCU cleanup happens whilst the hash<br /> spinlock is held. This led to the attached lockdep complaint.<br /> <br /> Fix this by changing spinlocks of rxnet-&gt;peer_hash_lock back to<br /> BH-disabling locks.<br /> <br /> ================================<br /> WARNING: inconsistent lock state<br /> 6.13.0-rc5-build2+ #1223 Tainted: G E<br /> --------------------------------<br /> inconsistent {SOFTIRQ-ON-W} -&gt; {IN-SOFTIRQ-W} usage.<br /> swapper/1/0 [HC0[0]:SC1[1]:HE1:SE0] takes:<br /> ffff88810babe228 (&amp;rxnet-&gt;peer_hash_lock){+.?.}-{3:3}, at: rxrpc_put_peer+0xcb/0x180<br /> {SOFTIRQ-ON-W} state was registered at:<br /> mark_usage+0x164/0x180<br /> __lock_acquire+0x544/0x990<br /> lock_acquire.part.0+0x103/0x280<br /> _raw_spin_lock+0x2f/0x40<br /> rxrpc_peer_keepalive_worker+0x144/0x440<br /> process_one_work+0x486/0x7c0<br /> process_scheduled_works+0x73/0x90<br /> worker_thread+0x1c8/0x2a0<br /> kthread+0x19b/0x1b0<br /> ret_from_fork+0x24/0x40<br /> ret_from_fork_asm+0x1a/0x30<br /> irq event stamp: 972402<br /> hardirqs last enabled at (972402): [] _raw_spin_unlock_irqrestore+0x2e/0x50<br /> hardirqs last disabled at (972401): [] _raw_spin_lock_irqsave+0x18/0x60<br /> softirqs last enabled at (972300): [] handle_softirqs+0x3ee/0x430<br /> softirqs last disabled at (972313): [] __irq_exit_rcu+0x44/0x110<br /> <br /> other info that might help us debug this:<br /> Possible unsafe locking scenario:<br /> CPU0<br /> ----<br /> lock(&amp;rxnet-&gt;peer_hash_lock);<br /> <br /> lock(&amp;rxnet-&gt;peer_hash_lock);<br /> <br /> *** DEADLOCK ***<br /> 1 lock held by swapper/1/0:<br /> #0: ffffffff83576be0 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire+0x7/0x30<br /> <br /> stack backtrace:<br /> CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Tainted: G E 6.13.0-rc5-build2+ #1223<br /> Tainted: [E]=UNSIGNED_MODULE<br /> Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x57/0x80<br /> print_usage_bug.part.0+0x227/0x240<br /> valid_state+0x53/0x70<br /> mark_lock_irq+0xa5/0x2f0<br /> mark_lock+0xf7/0x170<br /> mark_usage+0xe1/0x180<br /> __lock_acquire+0x544/0x990<br /> lock_acquire.part.0+0x103/0x280<br /> _raw_spin_lock+0x2f/0x40<br /> rxrpc_put_peer+0xcb/0x180<br /> afs_free_addrlist+0x46/0x90 [kafs]<br /> rcu_do_batch+0x2d2/0x640<br /> rcu_core+0x2f7/0x350<br /> handle_softirqs+0x1ee/0x430<br /> __irq_exit_rcu+0x44/0x110<br /> irq_exit_rcu+0xa/0x30<br /> sysvec_apic_timer_interrupt+0x7f/0xa0<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> driver core: class: Fix wild pointer dereferences in API class_dev_iter_next()<br /> <br /> There are a potential wild pointer dereferences issue regarding APIs<br /> class_dev_iter_(init|next|exit)(), as explained by below typical usage:<br /> <br /> // All members of @iter are wild pointers.<br /> struct class_dev_iter iter;<br /> <br /> // class_dev_iter_init(@iter, @class, ...) checks parameter @class for<br /> // potential class_to_subsys() error, and it returns void type and does<br /> // not initialize its output parameter @iter, so caller can not detect<br /> // the error and continues to invoke class_dev_iter_next(@iter) even if<br /> // @iter still contains wild pointers.<br /> class_dev_iter_init(&amp;iter, ...);<br /> <br /> // Dereference these wild pointers in @iter here once suffer the error.<br /> while (dev = class_dev_iter_next(&amp;iter)) { ... };<br /> <br /> // Also dereference these wild pointers here.<br /> class_dev_iter_exit(&amp;iter);<br /> <br /> Actually, all callers of these APIs have such usage pattern in kernel tree.<br /> Fix by:<br /> - Initialize output parameter @iter by memset() in class_dev_iter_init()<br /> and give callers prompt by pr_crit() for the error.<br /> - Check if @iter is valid in class_dev_iter_next().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: protect access to buffers with no active references<br /> <br /> nilfs_lookup_dirty_data_buffers(), which iterates through the buffers<br /> attached to dirty data folios/pages, accesses the attached buffers without<br /> locking the folios/pages.<br /> <br /> For data cache, nilfs_clear_folio_dirty() may be called asynchronously<br /> when the file system degenerates to read only, so<br /> nilfs_lookup_dirty_data_buffers() still has the potential to cause use<br /> after free issues when buffers lose the protection of their dirty state<br /> midway due to this asynchronous clearing and are unintentionally freed by<br /> try_to_free_buffers().<br /> <br /> Eliminate this race issue by adjusting the lock section in this function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ax25: rcu protect dev-&gt;ax25_ptr<br /> <br /> syzbot found a lockdep issue [1].<br /> <br /> We should remove ax25 RTNL dependency in ax25_setsockopt()<br /> <br /> This should also fix a variety of possible UAF in ax25.<br /> <br /> [1]<br /> <br /> WARNING: possible circular locking dependency detected<br /> 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Not tainted<br /> ------------------------------------------------------<br /> syz.5.1818/12806 is trying to acquire lock:<br /> ffffffff8fcb3988 (rtnl_mutex){+.+.}-{4:4}, at: ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680<br /> <br /> but task is already holding lock:<br /> ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline]<br /> ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574<br /> <br /> which lock already depends on the new lock.<br /> <br /> the existing dependency chain (in reverse order) is:<br /> <br /> -&gt; #1 (sk_lock-AF_AX25){+.+.}-{0:0}:<br /> lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849<br /> lock_sock_nested+0x48/0x100 net/core/sock.c:3642<br /> lock_sock include/net/sock.h:1618 [inline]<br /> ax25_kill_by_device net/ax25/af_ax25.c:101 [inline]<br /> ax25_device_event+0x24d/0x580 net/ax25/af_ax25.c:146<br /> notifier_call_chain+0x1a5/0x3f0 kernel/notifier.c:85<br /> __dev_notify_flags+0x207/0x400<br /> dev_change_flags+0xf0/0x1a0 net/core/dev.c:9026<br /> dev_ifsioc+0x7c8/0xe70 net/core/dev_ioctl.c:563<br /> dev_ioctl+0x719/0x1340 net/core/dev_ioctl.c:820<br /> sock_do_ioctl+0x240/0x460 net/socket.c:1234<br /> sock_ioctl+0x626/0x8e0 net/socket.c:1339<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:906 [inline]<br /> __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> -&gt; #0 (rtnl_mutex){+.+.}-{4:4}:<br /> check_prev_add kernel/locking/lockdep.c:3161 [inline]<br /> check_prevs_add kernel/locking/lockdep.c:3280 [inline]<br /> validate_chain+0x18ef/0x5920 kernel/locking/lockdep.c:3904<br /> __lock_acquire+0x1397/0x2100 kernel/locking/lockdep.c:5226<br /> lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849<br /> __mutex_lock_common kernel/locking/mutex.c:585 [inline]<br /> __mutex_lock+0x1ac/0xee0 kernel/locking/mutex.c:735<br /> ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680<br /> do_sock_setsockopt+0x3af/0x720 net/socket.c:2324<br /> __sys_setsockopt net/socket.c:2349 [inline]<br /> __do_sys_setsockopt net/socket.c:2355 [inline]<br /> __se_sys_setsockopt net/socket.c:2352 [inline]<br /> __x64_sys_setsockopt+0x1ee/0x280 net/socket.c:2352<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> other info that might help us debug this:<br /> <br /> Possible unsafe locking scenario:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> lock(sk_lock-AF_AX25);<br /> lock(rtnl_mutex);<br /> lock(sk_lock-AF_AX25);<br /> lock(rtnl_mutex);<br /> <br /> *** DEADLOCK ***<br /> <br /> 1 lock held by syz.5.1818/12806:<br /> #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline]<br /> #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574<br /> <br /> stack backtrace:<br /> CPU: 1 UID: 0 PID: 12806 Comm: syz.5.1818 Not tainted 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120<br /> print_circular_bug+0x13a/0x1b0 kernel/locking/lockdep.c:2074<br /> check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2206<br /> check_prev_add kernel/locking/lockdep.c:3161 [inline]<br /> check_prevs_add kernel/lockin<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> timers/migration: Fix off-by-one root mis-connection<br /> <br /> Before attaching a new root to the old root, the children counter of the<br /> new root is checked to verify that only the upcoming CPU&amp;#39;s top group have<br /> been connected to it. However since the recently added commit b729cc1ec21a<br /> ("timers/migration: Fix another race between hotplug and idle entry/exit")<br /> this check is not valid anymore because the old root is pre-accounted<br /> as a child to the new root. Therefore after connecting the upcoming<br /> CPU&amp;#39;s top group to the new root, the children count to be expected must<br /> be 2 and not 1 anymore.<br /> <br /> This omission results in the old root to not be connected to the new<br /> root. Then eventually the system may run with more than one top level,<br /> which defeats the purpose of a single idle migrator.<br /> <br /> Also the old root is pre-accounted but not connected upon the new root<br /> creation. But it can be connected to the new root later on. Therefore<br /> the old root may be accounted twice to the new root. The propagation of<br /> such overcommit can end up creating a double final top-level root with a<br /> groupmask incorrectly initialized. Although harmless given that the final<br /> top level roots will never have a parent to walk up to, this oddity<br /> opportunistically reported the core issue:<br /> <br /> WARNING: CPU: 8 PID: 0 at kernel/time/timer_migration.c:543 tmigr_requires_handle_remote<br /> CPU: 8 UID: 0 PID: 0 Comm: swapper/8<br /> RIP: 0010:tmigr_requires_handle_remote<br /> Call Trace:<br /> <br /> ? tmigr_requires_handle_remote<br /> ? hrtimer_run_queues<br /> update_process_times<br /> tick_periodic<br /> tick_handle_periodic<br /> __sysvec_apic_timer_interrupt<br /> sysvec_apic_timer_interrupt<br /> <br /> <br /> Fix the problem by taking the old root into account in the children count<br /> of the new root so the connection is not omitted.<br /> <br /> Also warn when more than one top level group exists to better detect<br /> similar issues in the future.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ptp: Ensure info-&gt;enable callback is always set<br /> <br /> The ioctl and sysfs handlers unconditionally call the -&gt;enable callback.<br /> Not all drivers implement that callback, leading to NULL dereferences.<br /> Example of affected drivers: ptp_s390.c, ptp_vclock.c and ptp_mock.c.<br /> <br /> Instead use a dummy callback if no better was specified by the driver.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mailbox: th1520: Fix a NULL vs IS_ERR() bug<br /> <br /> The devm_ioremap() function doesn&amp;#39;t return error pointers, it returns<br /> NULL. Update the error checking to match.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> memory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code()<br /> <br /> As of_find_node_by_name() release the reference of the argument device<br /> node, tegra_emc_find_node_by_ram_code() releases some device nodes while<br /> still in use, resulting in possible UAFs. According to the bindings and<br /> the in-tree DTS files, the "emc-tables" node is always device&amp;#39;s child<br /> node with the property "nvidia,use-ram-code", and the "lpddr2" node is a<br /> child of the "emc-tables" node. Thus utilize the<br /> for_each_child_of_node() macro and of_get_child_by_name() instead of<br /> of_find_node_by_name() to simplify the code.<br /> <br /> This bug was found by an experimental verification tool that I am<br /> developing.<br /> <br /> [krzysztof: applied v1, adjust the commit msg to incorporate v2 parts]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rhashtable: Fix potential deadlock by moving schedule_work outside lock<br /> <br /> Move the hash table growth check and work scheduling outside the<br /> rht lock to prevent a possible circular locking dependency.<br /> <br /> The original implementation could trigger a lockdep warning due to<br /> a potential deadlock scenario involving nested locks between<br /> rhashtable bucket, rq lock, and dsq lock. By relocating the<br /> growth check and work scheduling after releasing the rth lock, we break<br /> this potential deadlock chain.<br /> <br /> This change expands the flexibility of rhashtable by removing<br /> restrictive locking that previously limited its use in scheduler<br /> and workqueue contexts.<br /> <br /> Import to say that this calls rht_grow_above_75(), which reads from<br /> struct rhashtable without holding the lock, if this is a problem, we can<br /> move the check to the lock, and schedule the workqueue after the lock.<br /> <br /> <br /> Modified so that atomic_inc is also moved outside of the bucket<br /> lock along with the growth above 75% check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firewire: test: Fix potential null dereference in firewire kunit test<br /> <br /> kunit_kzalloc() may return a NULL pointer, dereferencing it without<br /> NULL check may lead to NULL dereference.<br /> Add a NULL check for test_state.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: ti: am65-cpsw: fix freeing IRQ in am65_cpsw_nuss_remove_tx_chns()<br /> <br /> When getting the IRQ we use k3_udma_glue_tx_get_irq() which returns<br /> negative error value on error. So not NULL check is not sufficient<br /> to deteremine if IRQ is valid. Check that IRQ is greater then zero<br /> to ensure it is valid.<br /> <br /> There is no issue at probe time but at runtime user can invoke<br /> .set_channels which results in the following call chain.<br /> am65_cpsw_set_channels()<br /> am65_cpsw_nuss_update_tx_rx_chns()<br /> am65_cpsw_nuss_remove_tx_chns()<br /> am65_cpsw_nuss_init_tx_chns()<br /> <br /> At this point if am65_cpsw_nuss_init_tx_chns() fails due to<br /> k3_udma_glue_tx_get_irq() then tx_chn-&gt;irq will be set to a<br /> negative value.<br /> <br /> Then, at subsequent .set_channels with higher channel count we<br /> will attempt to free an invalid IRQ in am65_cpsw_nuss_remove_tx_chns()<br /> leading to a kernel warning.<br /> <br /> The issue is present in the original commit that introduced this driver,<br /> although there, am65_cpsw_nuss_update_tx_rx_chns() existed as<br /> am65_cpsw_nuss_update_tx_chns().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: HWS, fix definer&amp;#39;s HWS_SET32 macro for negative offset<br /> <br /> When bit offset for HWS_SET32 macro is negative,<br /> UBSAN complains about the shift-out-of-bounds:<br /> <br /> UBSAN: shift-out-of-bounds in<br /> drivers/net/ethernet/mellanox/mlx5/core/steering/hws/definer.c:177:2<br /> shift exponent -8 is negative