Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfs: Clean up /proc/net/rpc/nfs when nfs_fs_proc_net_init() fails.<br /> <br /> syzbot reported a warning below [1] following a fault injection in<br /> nfs_fs_proc_net_init(). [0]<br /> <br /> When nfs_fs_proc_net_init() fails, /proc/net/rpc/nfs is not removed.<br /> <br /> Later, rpc_proc_exit() tries to remove /proc/net/rpc, and the warning<br /> is logged as the directory is not empty.<br /> <br /> Let&amp;#39;s handle the error of nfs_fs_proc_net_init() properly.<br /> <br /> [0]:<br /> FAULT_INJECTION: forcing a failure.<br /> name failslab, interval 1, probability 0, space 0, times 0<br /> CPU: 1 UID: 0 PID: 6120 Comm: syz.2.27 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025<br /> Call Trace:<br /> <br /> dump_stack_lvl (lib/dump_stack.c:123)<br /> should_fail_ex (lib/fault-inject.c:73 lib/fault-inject.c:174)<br /> should_failslab (mm/failslab.c:46)<br /> kmem_cache_alloc_noprof (mm/slub.c:4178 mm/slub.c:4204)<br /> __proc_create (fs/proc/generic.c:427)<br /> proc_create_reg (fs/proc/generic.c:554)<br /> proc_create_net_data (fs/proc/proc_net.c:120)<br /> nfs_fs_proc_net_init (fs/nfs/client.c:1409)<br /> nfs_net_init (fs/nfs/inode.c:2600)<br /> ops_init (net/core/net_namespace.c:138)<br /> setup_net (net/core/net_namespace.c:443)<br /> copy_net_ns (net/core/net_namespace.c:576)<br /> create_new_namespaces (kernel/nsproxy.c:110)<br /> unshare_nsproxy_namespaces (kernel/nsproxy.c:218 (discriminator 4))<br /> ksys_unshare (kernel/fork.c:3123)<br /> __x64_sys_unshare (kernel/fork.c:3190)<br /> do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)<br /> <br /> <br /> [1]:<br /> remove_proc_entry: removing non-empty directory &amp;#39;net/rpc&amp;#39;, leaking at least &amp;#39;nfs&amp;#39;<br /> WARNING: CPU: 1 PID: 6120 at fs/proc/generic.c:727 remove_proc_entry+0x45e/0x530 fs/proc/generic.c:727<br /> Modules linked in:<br /> CPU: 1 UID: 0 PID: 6120 Comm: syz.2.27 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025<br /> RIP: 0010:remove_proc_entry+0x45e/0x530 fs/proc/generic.c:727<br /> Code: 3c 02 00 0f 85 85 00 00 00 48 8b 93 d8 00 00 00 4d 89 f0 4c 89 e9 48 c7 c6 40 ba a2 8b 48 c7 c7 60 b9 a2 8b e8 33 81 1d ff 90 0b 90 90 e9 5f fe ff ff e8 04 69 5e ff 90 48 b8 00 00 00 00 00<br /> RSP: 0018:ffffc90003637b08 EFLAGS: 00010282<br /> RAX: 0000000000000000 RBX: ffff88805f534140 RCX: ffffffff817a92c8<br /> RDX: ffff88807da99e00 RSI: ffffffff817a92d5 RDI: 0000000000000001<br /> RBP: ffff888033431ac0 R08: 0000000000000001 R09: 0000000000000000<br /> R10: 0000000000000001 R11: 0000000000000001 R12: ffff888033431a00<br /> R13: ffff888033431ae4 R14: ffff888033184724 R15: dffffc0000000000<br /> FS: 0000555580328500(0000) GS:ffff888124a62000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f71733743e0 CR3: 000000007f618000 CR4: 00000000003526f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> sunrpc_exit_net+0x46/0x90 net/sunrpc/sunrpc_syms.c:76<br /> ops_exit_list net/core/net_namespace.c:200 [inline]<br /> ops_undo_list+0x2eb/0xab0 net/core/net_namespace.c:253<br /> setup_net+0x2e1/0x510 net/core/net_namespace.c:457<br /> copy_net_ns+0x2a6/0x5f0 net/core/net_namespace.c:574<br /> create_new_namespaces+0x3ea/0xa90 kernel/nsproxy.c:110<br /> unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:218<br /> ksys_unshare+0x45b/0xa40 kernel/fork.c:3121<br /> __do_sys_unshare kernel/fork.c:3192 [inline]<br /> __se_sys_unshare kernel/fork.c:3190 [inline]<br /> __x64_sys_unshare+0x31/0x40 kernel/fork.c:3190<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xcd/0x490 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7fa1a6b8e929<br /> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: altmodes/displayport: do not index invalid pin_assignments<br /> <br /> A poorly implemented DisplayPort Alt Mode port partner can indicate<br /> that its pin assignment capabilities are greater than the maximum<br /> value, DP_PIN_ASSIGN_F. In this case, calls to pin_assignment_show<br /> will cause a BRK exception due to an out of bounds array access.<br /> <br /> Prevent for loop in pin_assignment_show from accessing<br /> invalid values in pin_assignments by adding DP_PIN_ASSIGN_MAX<br /> value in typec_dp.h and using i

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: gpio: Fix the out-of-bounds access to drvdata::gpiods<br /> <br /> drvdata::gpiods is supposed to hold an array of &amp;#39;gpio_desc&amp;#39; pointers. But<br /> the memory is allocated for only one pointer. This will lead to<br /> out-of-bounds access later in the code if &amp;#39;config::ngpios&amp;#39; is &gt; 1. So<br /> fix the code to allocate enough memory to hold &amp;#39;config::ngpios&amp;#39; of GPIO<br /> descriptors.<br /> <br /> While at it, also move the check for memory allocation failure to be below<br /> the allocation to make it more readable.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: appletb-kbd: fix memory corruption of input_handler_list<br /> <br /> In appletb_kbd_probe an input handler is initialised and then registered<br /> with input core through input_register_handler(). When this happens input<br /> core will add the input handler (specifically its node) to the global<br /> input_handler_list. The input_handler_list is central to the functionality<br /> of input core and is traversed in various places in input core. An example<br /> of this is when a new input device is plugged in and gets registered with<br /> input core.<br /> <br /> The input_handler in probe is allocated as device managed memory. If a<br /> probe failure occurs after input_register_handler() the input_handler<br /> memory is freed, yet it will remain in the input_handler_list. This<br /> effectively means the input_handler_list contains a dangling pointer<br /> to data belonging to a freed input handler.<br /> <br /> This causes an issue when any other input device is plugged in - in my<br /> case I had an old PixArt HP USB optical mouse and I decided to<br /> plug it in after a failure occurred after input_register_handler().<br /> This lead to the registration of this input device via<br /> input_register_device which involves traversing over every handler<br /> in the corrupted input_handler_list and calling input_attach_handler(),<br /> giving each handler a chance to bind to newly registered device.<br /> <br /> The core of this bug is a UAF which causes memory corruption of<br /> input_handler_list and to fix it we must ensure the input handler is<br /> unregistered from input core, this is done through<br /> input_unregister_handler().<br /> <br /> [ 63.191597] ==================================================================<br /> [ 63.192094] BUG: KASAN: slab-use-after-free in input_attach_handler.isra.0+0x1a9/0x1e0<br /> [ 63.192094] Read of size 8 at addr ffff888105ea7c80 by task kworker/0:2/54<br /> [ 63.192094]<br /> [ 63.192094] CPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.16.0-rc2-00321-g2aa6621d<br /> [ 63.192094] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.164<br /> [ 63.192094] Workqueue: usb_hub_wq hub_event<br /> [ 63.192094] Call Trace:<br /> [ 63.192094] <br /> [ 63.192094] dump_stack_lvl+0x53/0x70<br /> [ 63.192094] print_report+0xce/0x670<br /> [ 63.192094] kasan_report+0xce/0x100<br /> [ 63.192094] input_attach_handler.isra.0+0x1a9/0x1e0<br /> [ 63.192094] input_register_device+0x76c/0xd00<br /> [ 63.192094] hidinput_connect+0x686d/0xad60<br /> [ 63.192094] hid_connect+0xf20/0x1b10<br /> [ 63.192094] hid_hw_start+0x83/0x100<br /> [ 63.192094] hid_device_probe+0x2d1/0x680<br /> [ 63.192094] really_probe+0x1c3/0x690<br /> [ 63.192094] __driver_probe_device+0x247/0x300<br /> [ 63.192094] driver_probe_device+0x49/0x210<br /> [ 63.192094] __device_attach_driver+0x160/0x320<br /> [ 63.192094] bus_for_each_drv+0x10f/0x190<br /> [ 63.192094] __device_attach+0x18e/0x370<br /> [ 63.192094] bus_probe_device+0x123/0x170<br /> [ 63.192094] device_add+0xd4d/0x1460<br /> [ 63.192094] hid_add_device+0x30b/0x910<br /> [ 63.192094] usbhid_probe+0x920/0xe00<br /> [ 63.192094] usb_probe_interface+0x363/0x9a0<br /> [ 63.192094] really_probe+0x1c3/0x690<br /> [ 63.192094] __driver_probe_device+0x247/0x300<br /> [ 63.192094] driver_probe_device+0x49/0x210<br /> [ 63.192094] __device_attach_driver+0x160/0x320<br /> [ 63.192094] bus_for_each_drv+0x10f/0x190<br /> [ 63.192094] __device_attach+0x18e/0x370<br /> [ 63.192094] bus_probe_device+0x123/0x170<br /> [ 63.192094] device_add+0xd4d/0x1460<br /> [ 63.192094] usb_set_configuration+0xd14/0x1880<br /> [ 63.192094] usb_generic_driver_probe+0x78/0xb0<br /> [ 63.192094] usb_probe_device+0xaa/0x2e0<br /> [ 63.192094] really_probe+0x1c3/0x690<br /> [ 63.192094] __driver_probe_device+0x247/0x300<br /> [ 63.192094] driver_probe_device+0x49/0x210<br /> [ 63.192094] __device_attach_driver+0x160/0x320<br /> [ 63.192094] bus_for_each_drv+0x10f/0x190<br /> [ 63.192094] __device_attach+0x18e/0x370<br /> [ 63.192094] bus_probe_device+0x123/0x170<br /> [ 63.192094] device_add+0xd4d/0x1460<br /> [ 63.192094] usb_new_device+0x7b4/0x1000<br /> [ 63.192094] hub_event+0x234d/0x3<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: arm_ffa: Replace mutex with rwlock to avoid sleep in atomic context<br /> <br /> The current use of a mutex to protect the notifier hashtable accesses<br /> can lead to issues in the atomic context. It results in the below<br /> kernel warnings:<br /> <br /> | BUG: sleeping function called from invalid context at kernel/locking/mutex.c:258<br /> | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 9, name: kworker/0:0<br /> | preempt_count: 1, expected: 0<br /> | RCU nest depth: 0, expected: 0<br /> | CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.14.0 #4<br /> | Workqueue: ffa_pcpu_irq_notification notif_pcpu_irq_work_fn<br /> | Call trace:<br /> | show_stack+0x18/0x24 (C)<br /> | dump_stack_lvl+0x78/0x90<br /> | dump_stack+0x18/0x24<br /> | __might_resched+0x114/0x170<br /> | __might_sleep+0x48/0x98<br /> | mutex_lock+0x24/0x80<br /> | handle_notif_callbacks+0x54/0xe0<br /> | notif_get_and_handle+0x40/0x88<br /> | generic_exec_single+0x80/0xc0<br /> | smp_call_function_single+0xfc/0x1a0<br /> | notif_pcpu_irq_work_fn+0x2c/0x38<br /> | process_one_work+0x14c/0x2b4<br /> | worker_thread+0x2e4/0x3e0<br /> | kthread+0x13c/0x210<br /> | ret_from_fork+0x10/0x20<br /> <br /> To address this, replace the mutex with an rwlock to protect the notifier<br /> hashtable accesses. This ensures that read-side locking does not sleep and<br /> multiple readers can acquire the lock concurrently, avoiding unnecessary<br /> contention and potential deadlocks. Writer access remains exclusive,<br /> preserving correctness.<br /> <br /> This change resolves warnings from lockdep about potential sleep in<br /> atomic context.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: arm_ffa: Fix memory leak by freeing notifier callback node<br /> <br /> Commit e0573444edbf ("firmware: arm_ffa: Add interfaces to request<br /> notification callbacks") adds support for notifier callbacks by allocating<br /> and inserting a callback node into a hashtable during registration of<br /> notifiers. However, during unregistration, the code only removes the<br /> node from the hashtable without freeing the associated memory, resulting<br /> in a memory leak.<br /> <br /> Resolve the memory leak issue by ensuring the allocated notifier callback<br /> node is properly freed after it is removed from the hashtable entry.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: convert control queue mutex to a spinlock<br /> <br /> With VIRTCHNL2_CAP_MACFILTER enabled, the following warning is generated<br /> on module load:<br /> <br /> [ 324.701677] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:578<br /> [ 324.701684] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1582, name: NetworkManager<br /> [ 324.701689] preempt_count: 201, expected: 0<br /> [ 324.701693] RCU nest depth: 0, expected: 0<br /> [ 324.701697] 2 locks held by NetworkManager/1582:<br /> [ 324.701702] #0: ffffffff9f7be770 (rtnl_mutex){....}-{3:3}, at: rtnl_newlink+0x791/0x21e0<br /> [ 324.701730] #1: ff1100216c380368 (_xmit_ETHER){....}-{2:2}, at: __dev_open+0x3f0/0x870<br /> [ 324.701749] Preemption disabled at:<br /> [ 324.701752] [] __dev_open+0x3dd/0x870<br /> [ 324.701765] CPU: 30 UID: 0 PID: 1582 Comm: NetworkManager Not tainted 6.15.0-rc5+ #2 PREEMPT(voluntary)<br /> [ 324.701771] Hardware name: Intel Corporation M50FCP2SBSTD/M50FCP2SBSTD, BIOS SE5C741.86B.01.01.0001.2211140926 11/14/2022<br /> [ 324.701774] Call Trace:<br /> [ 324.701777] <br /> [ 324.701779] dump_stack_lvl+0x5d/0x80<br /> [ 324.701788] ? __dev_open+0x3dd/0x870<br /> [ 324.701793] __might_resched.cold+0x1ef/0x23d<br /> <br /> [ 324.701818] __mutex_lock+0x113/0x1b80<br /> <br /> [ 324.701917] idpf_ctlq_clean_sq+0xad/0x4b0 [idpf]<br /> [ 324.701935] ? kasan_save_track+0x14/0x30<br /> [ 324.701941] idpf_mb_clean+0x143/0x380 [idpf]<br /> <br /> [ 324.701991] idpf_send_mb_msg+0x111/0x720 [idpf]<br /> [ 324.702009] idpf_vc_xn_exec+0x4cc/0x990 [idpf]<br /> [ 324.702021] ? rcu_is_watching+0x12/0xc0<br /> [ 324.702035] idpf_add_del_mac_filters+0x3ed/0xb50 [idpf]<br /> <br /> [ 324.702122] __hw_addr_sync_dev+0x1cf/0x300<br /> [ 324.702126] ? find_held_lock+0x32/0x90<br /> [ 324.702134] idpf_set_rx_mode+0x317/0x390 [idpf]<br /> [ 324.702152] __dev_open+0x3f8/0x870<br /> [ 324.702159] ? __pfx___dev_open+0x10/0x10<br /> [ 324.702174] __dev_change_flags+0x443/0x650<br /> <br /> [ 324.702208] netif_change_flags+0x80/0x160<br /> [ 324.702218] do_setlink.isra.0+0x16a0/0x3960<br /> <br /> [ 324.702349] rtnl_newlink+0x12fd/0x21e0<br /> <br /> The sequence is as follows:<br /> rtnl_newlink()-&gt;<br /> __dev_change_flags()-&gt;<br /> __dev_open()-&gt;<br /> dev_set_rx_mode() - &gt; # disables BH and grabs "dev-&gt;addr_list_lock"<br /> idpf_set_rx_mode() -&gt; # proceed only if VIRTCHNL2_CAP_MACFILTER is ON<br /> __dev_uc_sync() -&gt;<br /> idpf_add_mac_filter -&gt;<br /> idpf_add_del_mac_filters -&gt;<br /> idpf_send_mb_msg() -&gt;<br /> idpf_mb_clean() -&gt;<br /> idpf_ctlq_clean_sq() # mutex_lock(cq_lock)<br /> <br /> Fix by converting cq_lock to a spinlock. All operations under the new<br /> lock are safe except freeing the DMA memory, which may use vunmap(). Fix<br /> by requesting a contiguous physical memory for the DMA mapping.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx5: Initialize obj_event-&gt;obj_sub_list before xa_insert<br /> <br /> The obj_event may be loaded immediately after inserted, then if the<br /> list_head is not initialized then we may get a poisonous pointer. This<br /> fixes the crash below:<br /> <br /> mlx5_core 0000:03:00.0: MLX5E: StrdRq(1) RqSz(8) StrdSz(2048) RxCqeCmprss(0 enhanced)<br /> mlx5_core.sf mlx5_core.sf.4: firmware version: 32.38.3056<br /> mlx5_core 0000:03:00.0 en3f0pf0sf2002: renamed from eth0<br /> mlx5_core.sf mlx5_core.sf.4: Rate limit: 127 rates are supported, range: 0Mbps to 195312Mbps<br /> IPv6: ADDRCONF(NETDEV_CHANGE): en3f0pf0sf2002: link becomes ready<br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060<br /> Mem abort info:<br /> ESR = 0x96000006<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000006<br /> CM = 0, WnR = 0<br /> user pgtable: 4k pages, 48-bit VAs, pgdp=00000007760fb000<br /> [0000000000000060] pgd=000000076f6d7003, p4d=000000076f6d7003, pud=0000000777841003, pmd=0000000000000000<br /> Internal error: Oops: 96000006 [#1] SMP<br /> Modules linked in: ipmb_host(OE) act_mirred(E) cls_flower(E) sch_ingress(E) mptcp_diag(E) udp_diag(E) raw_diag(E) unix_diag(E) tcp_diag(E) inet_diag(E) binfmt_misc(E) bonding(OE) rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) isofs(E) cdrom(E) mst_pciconf(OE) ib_umad(OE) mlx5_ib(OE) ipmb_dev_int(OE) mlx5_core(OE) kpatch_15237886(OEK) mlxdevm(OE) auxiliary(OE) ib_uverbs(OE) ib_core(OE) psample(E) mlxfw(OE) tls(E) sunrpc(E) vfat(E) fat(E) crct10dif_ce(E) ghash_ce(E) sha1_ce(E) sbsa_gwdt(E) virtio_console(E) ext4(E) mbcache(E) jbd2(E) xfs(E) libcrc32c(E) mmc_block(E) virtio_net(E) net_failover(E) failover(E) sha2_ce(E) sha256_arm64(E) nvme(OE) nvme_core(OE) gpio_mlxbf3(OE) mlx_compat(OE) mlxbf_pmc(OE) i2c_mlxbf(OE) sdhci_of_dwcmshc(OE) pinctrl_mlxbf3(OE) mlxbf_pka(OE) gpio_generic(E) i2c_core(E) mmc_core(E) mlxbf_gige(OE) vitesse(E) pwr_mlxbf(OE) mlxbf_tmfifo(OE) micrel(E) mlxbf_bootctl(OE) virtio_ring(E) virtio(E) ipmi_devintf(E) ipmi_msghandler(E)<br /> [last unloaded: mst_pci]<br /> CPU: 11 PID: 20913 Comm: rte-worker-11 Kdump: loaded Tainted: G OE K 5.10.134-13.1.an8.aarch64 #1<br /> Hardware name: https://www.mellanox.com BlueField-3 SmartNIC Main Card/BlueField-3 SmartNIC Main Card, BIOS 4.2.2.12968 Oct 26 2023<br /> pstate: a0400089 (NzCv daIf +PAN -UAO -TCO BTYPE=--)<br /> pc : dispatch_event_fd+0x68/0x300 [mlx5_ib]<br /> lr : devx_event_notifier+0xcc/0x228 [mlx5_ib]<br /> sp : ffff80001005bcf0<br /> x29: ffff80001005bcf0 x28: 0000000000000001<br /> x27: ffff244e0740a1d8 x26: ffff244e0740a1d0<br /> x25: ffffda56beff5ae0 x24: ffffda56bf911618<br /> x23: ffff244e0596a480 x22: ffff244e0596a480<br /> x21: ffff244d8312ad90 x20: ffff244e0596a480<br /> x19: fffffffffffffff0 x18: 0000000000000000<br /> x17: 0000000000000000 x16: ffffda56be66d620<br /> x15: 0000000000000000 x14: 0000000000000000<br /> x13: 0000000000000000 x12: 0000000000000000<br /> x11: 0000000000000040 x10: ffffda56bfcafb50<br /> x9 : ffffda5655c25f2c x8 : 0000000000000010<br /> x7 : 0000000000000000 x6 : ffff24545a2e24b8<br /> x5 : 0000000000000003 x4 : ffff80001005bd28<br /> x3 : 0000000000000000 x2 : 0000000000000000<br /> x1 : ffff244e0596a480 x0 : ffff244d8312ad90<br /> Call trace:<br /> dispatch_event_fd+0x68/0x300 [mlx5_ib]<br /> devx_event_notifier+0xcc/0x228 [mlx5_ib]<br /> atomic_notifier_call_chain+0x58/0x80<br /> mlx5_eq_async_int+0x148/0x2b0 [mlx5_core]<br /> atomic_notifier_call_chain+0x58/0x80<br /> irq_int_handler+0x20/0x30 [mlx5_core]<br /> __handle_irq_event_percpu+0x60/0x220<br /> handle_irq_event_percpu+0x3c/0x90<br /> handle_irq_event+0x58/0x158<br /> handle_fasteoi_irq+0xfc/0x188<br /> generic_handle_irq+0x34/0x48<br /> ...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/gt: Fix timeline left held on VMA alloc error<br /> <br /> The following error has been reported sporadically by CI when a test<br /> unbinds the i915 driver on a ring submission platform:<br /> <br /> [239.330153] ------------[ cut here ]------------<br /> [239.330166] i915 0000:00:02.0: [drm] drm_WARN_ON(dev_priv-&gt;mm.shrink_count)<br /> [239.330196] WARNING: CPU: 1 PID: 18570 at drivers/gpu/drm/i915/i915_gem.c:1309 i915_gem_cleanup_early+0x13e/0x150 [i915]<br /> ...<br /> [239.330640] RIP: 0010:i915_gem_cleanup_early+0x13e/0x150 [i915]<br /> ...<br /> [239.330942] Call Trace:<br /> [239.330944] <br /> [239.330949] i915_driver_late_release+0x2b/0xa0 [i915]<br /> [239.331202] i915_driver_release+0x86/0xa0 [i915]<br /> [239.331482] devm_drm_dev_init_release+0x61/0x90<br /> [239.331494] devm_action_release+0x15/0x30<br /> [239.331504] release_nodes+0x3d/0x120<br /> [239.331517] devres_release_all+0x96/0xd0<br /> [239.331533] device_unbind_cleanup+0x12/0x80<br /> [239.331543] device_release_driver_internal+0x23a/0x280<br /> [239.331550] ? bus_find_device+0xa5/0xe0<br /> [239.331563] device_driver_detach+0x14/0x20<br /> ...<br /> [357.719679] ---[ end trace 0000000000000000 ]---<br /> <br /> If the test also unloads the i915 module then that&amp;#39;s followed with:<br /> <br /> [357.787478] =============================================================================<br /> [357.788006] BUG i915_vma (Tainted: G U W N ): Objects remaining on __kmem_cache_shutdown()<br /> [357.788031] -----------------------------------------------------------------------------<br /> [357.788204] Object 0xffff888109e7f480 @offset=29824<br /> [357.788670] Allocated in i915_vma_instance+0xee/0xc10 [i915] age=292729 cpu=4 pid=2244<br /> [357.788994] i915_vma_instance+0xee/0xc10 [i915]<br /> [357.789290] init_status_page+0x7b/0x420 [i915]<br /> [357.789532] intel_engines_init+0x1d8/0x980 [i915]<br /> [357.789772] intel_gt_init+0x175/0x450 [i915]<br /> [357.790014] i915_gem_init+0x113/0x340 [i915]<br /> [357.790281] i915_driver_probe+0x847/0xed0 [i915]<br /> [357.790504] i915_pci_probe+0xe6/0x220 [i915]<br /> ...<br /> <br /> Closer analysis of CI results history has revealed a dependency of the<br /> error on a few IGT tests, namely:<br /> - igt@api_intel_allocator@fork-simple-stress-signal,<br /> - igt@api_intel_allocator@two-level-inception-interruptible,<br /> - igt@gem_linear_blits@interruptible,<br /> - igt@prime_mmap_coherency@ioctl-errors,<br /> which invisibly trigger the issue, then exhibited with first driver unbind<br /> attempt.<br /> <br /> All of the above tests perform actions which are actively interrupted with<br /> signals. Further debugging has allowed to narrow that scope down to<br /> DRM_IOCTL_I915_GEM_EXECBUFFER2, and ring_context_alloc(), specific to ring<br /> submission, in particular.<br /> <br /> If successful then that function, or its execlists or GuC submission<br /> equivalent, is supposed to be called only once per GEM context engine,<br /> followed by raise of a flag that prevents the function from being called<br /> again. The function is expected to unwind its internal errors itself, so<br /> it may be safely called once more after it returns an error.<br /> <br /> In case of ring submission, the function first gets a reference to the<br /> engine&amp;#39;s legacy timeline and then allocates a VMA. If the VMA allocation<br /> fails, e.g. when i915_vma_instance() called from inside is interrupted<br /> with a signal, then ring_context_alloc() fails, leaving the timeline held<br /> referenced. On next I915_GEM_EXECBUFFER2 IOCTL, another reference to the<br /> timeline is got, and only that last one is put on successful completion.<br /> As a consequence, the legacy timeline, with its underlying engine status<br /> page&amp;#39;s VMA object, is still held and not released on driver unbind.<br /> <br /> Get the legacy timeline only after successful allocation of the context<br /> engine&amp;#39;s VMA.<br /> <br /> v2: Add a note on other submission methods (Krzysztof Karas):<br /> Both execlists and GuC submission use lrc_alloc() which seems free<br /> from a similar issue.<br /> <br /> (cherry picked from commit cc43422b3cc79eacff4c5a8ba0d224688ca9dd4f)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSv4/pNFS: Fix a race to wake on NFS_LAYOUT_DRAIN<br /> <br /> We found a few different systems hung up in writeback waiting on the same<br /> page lock, and one task waiting on the NFS_LAYOUT_DRAIN bit in<br /> pnfs_update_layout(), however the pnfs_layout_hdr&amp;#39;s plh_outstanding count<br /> was zero.<br /> <br /> It seems most likely that this is another race between the waiter and waker<br /> similar to commit ed0172af5d6f ("SUNRPC: Fix a race to wake a sync task").<br /> Fix it up by applying the advised barrier.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix warning when reconnecting channel<br /> <br /> When reconnecting a channel in smb2_reconnect_server(), a dummy tcon<br /> is passed down to smb2_reconnect() with -&gt;query_interface<br /> uninitialized, so we can&amp;#39;t call queue_delayed_work() on it.<br /> <br /> Fix the following warning by ensuring that we&amp;#39;re queueing the delayed<br /> worker from correct tcon.<br /> <br /> WARNING: CPU: 4 PID: 1126 at kernel/workqueue.c:2498 __queue_delayed_work+0x1d2/0x200<br /> Modules linked in: cifs cifs_arc4 nls_ucs2_utils cifs_md4 [last unloaded: cifs]<br /> CPU: 4 UID: 0 PID: 1126 Comm: kworker/4:0 Not tainted 6.16.0-rc3 #5 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-4.fc42 04/01/2014<br /> Workqueue: cifsiod smb2_reconnect_server [cifs]<br /> RIP: 0010:__queue_delayed_work+0x1d2/0x200<br /> Code: 41 5e 41 5f e9 7f ee ff ff 90 0f 0b 90 e9 5d ff ff ff bf 02 00<br /> 00 00 e8 6c f3 07 00 89 c3 eb bd 90 0f 0b 90 e9 57 f&gt; 0b 90 e9 65 fe<br /> ff ff 90 0f 0b 90 e9 72 fe ff ff 90 0f 0b 90 e9<br /> RSP: 0018:ffffc900014afad8 EFLAGS: 00010003<br /> RAX: 0000000000000000 RBX: ffff888124d99988 RCX: ffffffff81399cc1<br /> RDX: dffffc0000000000 RSI: ffff888114326e00 RDI: ffff888124d999f0<br /> RBP: 000000000000ea60 R08: 0000000000000001 R09: ffffed10249b3331<br /> R10: ffff888124d9998f R11: 0000000000000004 R12: 0000000000000040<br /> R13: ffff888114326e00 R14: ffff888124d999d8 R15: ffff888114939020<br /> FS: 0000000000000000(0000) GS:ffff88829f7fe000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007ffe7a2b4038 CR3: 0000000120a6f000 CR4: 0000000000750ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> queue_delayed_work_on+0xb4/0xc0<br /> smb2_reconnect+0xb22/0xf50 [cifs]<br /> smb2_reconnect_server+0x413/0xd40 [cifs]<br /> ? __pfx_smb2_reconnect_server+0x10/0x10 [cifs]<br /> ? local_clock_noinstr+0xd/0xd0<br /> ? local_clock+0x15/0x30<br /> ? lock_release+0x29b/0x390<br /> process_one_work+0x4c5/0xa10<br /> ? __pfx_process_one_work+0x10/0x10<br /> ? __list_add_valid_or_report+0x37/0x120<br /> worker_thread+0x2f1/0x5a0<br /> ? __kthread_parkme+0xde/0x100<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0x1fe/0x380<br /> ? kthread+0x10f/0x380<br /> ? __pfx_kthread+0x10/0x10<br /> ? local_clock_noinstr+0xd/0xd0<br /> ? ret_from_fork+0x1b/0x1f0<br /> ? local_clock+0x15/0x30<br /> ? lock_release+0x29b/0x390<br /> ? rcu_is_watching+0x20/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x15b/0x1f0<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> irq event stamp: 1116206<br /> hardirqs last enabled at (1116205): [] __up_console_sem+0x52/0x60<br /> hardirqs last disabled at (1116206): [] queue_delayed_work_on+0x6e/0xc0<br /> softirqs last enabled at (1116138): [] __smb_send_rqst+0x42d/0x950 [cifs]<br /> softirqs last disabled at (1116136): [] release_sock+0x21/0xf0