Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: Fix NULL pointer dereference in core_scsi3_decode_spec_i_port()<br /> <br /> The function core_scsi3_decode_spec_i_port(), in its error code path,<br /> unconditionally calls core_scsi3_lunacl_undepend_item() passing the<br /> dest_se_deve pointer, which may be NULL.<br /> <br /> This can lead to a NULL pointer dereference if dest_se_deve remains<br /> unset.<br /> <br /> SPC-3 PR SPEC_I_PT: Unable to locate dest_tpg<br /> Unable to handle kernel paging request at virtual address dfff800000000012<br /> Call trace:<br /> core_scsi3_lunacl_undepend_item+0x2c/0xf0 [target_core_mod] (P)<br /> core_scsi3_decode_spec_i_port+0x120c/0x1c30 [target_core_mod]<br /> core_scsi3_emulate_pro_register+0x6b8/0xcd8 [target_core_mod]<br /> target_scsi3_emulate_pr_out+0x56c/0x840 [target_core_mod]<br /> <br /> Fix this by adding a NULL check before calling<br /> core_scsi3_lunacl_undepend_item()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtk-sd: Prevent memory corruption from DMA map failure<br /> <br /> If msdc_prepare_data() fails to map the DMA region, the request is<br /> not prepared for data receiving, but msdc_start_data() proceeds<br /> the DMA with previous setting.<br /> Since this will lead a memory corruption, we have to stop the<br /> request operation soon after the msdc_prepare_data() fails to<br /> prepare it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: spi-qpic-snand: reallocate BAM transactions<br /> <br /> Using the mtd_nandbiterrs module for testing the driver occasionally<br /> results in weird things like below.<br /> <br /> 1. swiotlb mapping fails with the following message:<br /> <br /> [ 85.926216] qcom_snand 79b0000.spi: swiotlb buffer is full (sz: 4294967294 bytes), total 512 (slots), used 0 (slots)<br /> [ 85.932937] qcom_snand 79b0000.spi: failure in mapping desc<br /> [ 87.999314] qcom_snand 79b0000.spi: failure to write raw page<br /> [ 87.999352] mtd_nandbiterrs: error: write_oob failed (-110)<br /> <br /> Rebooting the board after this causes a panic due to a NULL pointer<br /> dereference.<br /> <br /> 2. If the swiotlb mapping does not fail, rebooting the board may result<br /> in a different panic due to a bad spinlock magic:<br /> <br /> [ 256.104459] BUG: spinlock bad magic on CPU#3, procd/2241<br /> [ 256.104488] Unable to handle kernel paging request at virtual address ffffffff0000049b<br /> ...<br /> <br /> Investigating the issue revealed that these symptoms are results of<br /> memory corruption which is caused by out of bounds access within the<br /> driver.<br /> <br /> The driver uses a dynamically allocated structure for BAM transactions,<br /> which structure must have enough space for all possible variations of<br /> different flash operations initiated by the driver. The required space<br /> heavily depends on the actual number of &amp;#39;codewords&amp;#39; which is calculated<br /> from the pagesize of the actual NAND chip.<br /> <br /> Although the qcom_nandc_alloc() function allocates memory for the BAM<br /> transactions during probe, but since the actual number of &amp;#39;codewords&amp;#39;<br /> is not yet know the allocation is done for one &amp;#39;codeword&amp;#39; only.<br /> <br /> Because of this, whenever the driver does a flash operation, and the<br /> number of the required transactions exceeds the size of the allocated<br /> arrays the driver accesses memory out of the allocated range.<br /> <br /> To avoid this, change the code to free the initially allocated BAM<br /> transactions memory, and allocate a new one once the actual number of<br /> &amp;#39;codewords&amp;#39; required for a given NAND chip is known.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: return 0 size for RSS key if not supported<br /> <br /> Returning -EOPNOTSUPP from function returning u32 is leading to<br /> cast and invalid size value as a result.<br /> <br /> -EOPNOTSUPP as a size probably will lead to allocation fail.<br /> <br /> Command: ethtool -x eth0<br /> It is visible on all devices that don&amp;#39;t have RSS caps set.<br /> <br /> [ 136.615917] Call Trace:<br /> [ 136.615921] <br /> [ 136.615927] ? __warn+0x89/0x130<br /> [ 136.615942] ? __alloc_frozen_pages_noprof+0x322/0x330<br /> [ 136.615953] ? report_bug+0x164/0x190<br /> [ 136.615968] ? handle_bug+0x58/0x90<br /> [ 136.615979] ? exc_invalid_op+0x17/0x70<br /> [ 136.615987] ? asm_exc_invalid_op+0x1a/0x20<br /> [ 136.616001] ? rss_prepare_get.constprop.0+0xb9/0x170<br /> [ 136.616016] ? __alloc_frozen_pages_noprof+0x322/0x330<br /> [ 136.616028] __alloc_pages_noprof+0xe/0x20<br /> [ 136.616038] ___kmalloc_large_node+0x80/0x110<br /> [ 136.616072] __kmalloc_large_node_noprof+0x1d/0xa0<br /> [ 136.616081] __kmalloc_noprof+0x32c/0x4c0<br /> [ 136.616098] ? rss_prepare_get.constprop.0+0xb9/0x170<br /> [ 136.616105] rss_prepare_get.constprop.0+0xb9/0x170<br /> [ 136.616114] ethnl_default_doit+0x107/0x3d0<br /> [ 136.616131] genl_family_rcv_msg_doit+0x100/0x160<br /> [ 136.616147] genl_rcv_msg+0x1b8/0x2c0<br /> [ 136.616156] ? __pfx_ethnl_default_doit+0x10/0x10<br /> [ 136.616168] ? __pfx_genl_rcv_msg+0x10/0x10<br /> [ 136.616176] netlink_rcv_skb+0x58/0x110<br /> [ 136.616186] genl_rcv+0x28/0x40<br /> [ 136.616195] netlink_unicast+0x19b/0x290<br /> [ 136.616206] netlink_sendmsg+0x222/0x490<br /> [ 136.616215] __sys_sendto+0x1fd/0x210<br /> [ 136.616233] __x64_sys_sendto+0x24/0x30<br /> [ 136.616242] do_syscall_64+0x82/0x160<br /> [ 136.616252] ? __sys_recvmsg+0x83/0xe0<br /> [ 136.616265] ? syscall_exit_to_user_mode+0x10/0x210<br /> [ 136.616275] ? do_syscall_64+0x8e/0x160<br /> [ 136.616282] ? __count_memcg_events+0xa1/0x130<br /> [ 136.616295] ? count_memcg_events.constprop.0+0x1a/0x30<br /> [ 136.616306] ? handle_mm_fault+0xae/0x2d0<br /> [ 136.616319] ? do_user_addr_fault+0x379/0x670<br /> [ 136.616328] ? clear_bhb_loop+0x45/0xa0<br /> [ 136.616340] ? clear_bhb_loop+0x45/0xa0<br /> [ 136.616349] ? clear_bhb_loop+0x45/0xa0<br /> [ 136.616359] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [ 136.616369] RIP: 0033:0x7fd30ba7b047<br /> [ 136.616376] Code: 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d bd d5 0c 00 00 41 89 ca 74 10 b8 2c 00 00 00 0f 05 3d 00 f0 ff ff 77 71 c3 55 48 83 ec 30 44 89 4c 24 2c 4c 89 44<br /> [ 136.616381] RSP: 002b:00007ffde1796d68 EFLAGS: 00000202 ORIG_RAX: 000000000000002c<br /> [ 136.616388] RAX: ffffffffffffffda RBX: 000055d7bd89f2a0 RCX: 00007fd30ba7b047<br /> [ 136.616392] RDX: 0000000000000028 RSI: 000055d7bd89f3b0 RDI: 0000000000000003<br /> [ 136.616396] RBP: 00007ffde1796e10 R08: 00007fd30bb4e200 R09: 000000000000000c<br /> [ 136.616399] R10: 0000000000000000 R11: 0000000000000202 R12: 000055d7bd89f340<br /> [ 136.616403] R13: 000055d7bd89f3b0 R14: 000055d78943f200 R15: 0000000000000000

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-multipath: fix suspicious RCU usage warning<br /> <br /> When I run the NVME over TCP test in virtme-ng, I get the following<br /> "suspicious RCU usage" warning in nvme_mpath_add_sysfs_link():<br /> <br /> &amp;#39;&amp;#39;&amp;#39;<br /> [ 5.024557][ T44] nvmet: Created nvm controller 1 for subsystem nqn.2025-06.org.nvmexpress.mptcp for NQN nqn.2014-08.org.nvmexpress:uuid:f7f6b5e0-ff97-4894-98ac-c85309e0bc77.<br /> [ 5.027401][ T183] nvme nvme0: creating 2 I/O queues.<br /> [ 5.029017][ T183] nvme nvme0: mapped 2/0/0 default/read/poll queues.<br /> [ 5.032587][ T183] nvme nvme0: new ctrl: NQN "nqn.2025-06.org.nvmexpress.mptcp", addr 127.0.0.1:4420, hostnqn: nqn.2014-08.org.nvmexpress:uuid:f7f6b5e0-ff97-4894-98ac-c85309e0bc77<br /> [ 5.042214][ T25]<br /> [ 5.042440][ T25] =============================<br /> [ 5.042579][ T25] WARNING: suspicious RCU usage<br /> [ 5.042705][ T25] 6.16.0-rc3+ #23 Not tainted<br /> [ 5.042812][ T25] -----------------------------<br /> [ 5.042934][ T25] drivers/nvme/host/multipath.c:1203 RCU-list traversed in non-reader section!!<br /> [ 5.043111][ T25]<br /> [ 5.043111][ T25] other info that might help us debug this:<br /> [ 5.043111][ T25]<br /> [ 5.043341][ T25]<br /> [ 5.043341][ T25] rcu_scheduler_active = 2, debug_locks = 1<br /> [ 5.043502][ T25] 3 locks held by kworker/u9:0/25:<br /> [ 5.043615][ T25] #0: ffff888008730948 ((wq_completion)async){+.+.}-{0:0}, at: process_one_work+0x7ed/0x1350<br /> [ 5.043830][ T25] #1: ffffc900001afd40 ((work_completion)(&amp;entry-&gt;work)){+.+.}-{0:0}, at: process_one_work+0xcf3/0x1350<br /> [ 5.044084][ T25] #2: ffff888013ee0020 (&amp;head-&gt;srcu){.+.+}-{0:0}, at: nvme_mpath_add_sysfs_link.part.0+0xb4/0x3a0<br /> [ 5.044300][ T25]<br /> [ 5.044300][ T25] stack backtrace:<br /> [ 5.044439][ T25] CPU: 0 UID: 0 PID: 25 Comm: kworker/u9:0 Not tainted 6.16.0-rc3+ #23 PREEMPT(full)<br /> [ 5.044441][ T25] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011<br /> [ 5.044442][ T25] Workqueue: async async_run_entry_fn<br /> [ 5.044445][ T25] Call Trace:<br /> [ 5.044446][ T25] <br /> [ 5.044449][ T25] dump_stack_lvl+0x6f/0xb0<br /> [ 5.044453][ T25] lockdep_rcu_suspicious.cold+0x4f/0xb1<br /> [ 5.044457][ T25] nvme_mpath_add_sysfs_link.part.0+0x2fb/0x3a0<br /> [ 5.044459][ T25] ? queue_work_on+0x90/0xf0<br /> [ 5.044461][ T25] ? lockdep_hardirqs_on+0x78/0x110<br /> [ 5.044466][ T25] nvme_mpath_set_live+0x1e9/0x4f0<br /> [ 5.044470][ T25] nvme_mpath_add_disk+0x240/0x2f0<br /> [ 5.044472][ T25] ? __pfx_nvme_mpath_add_disk+0x10/0x10<br /> [ 5.044475][ T25] ? add_disk_fwnode+0x361/0x580<br /> [ 5.044480][ T25] nvme_alloc_ns+0x81c/0x17c0<br /> [ 5.044483][ T25] ? kasan_quarantine_put+0x104/0x240<br /> [ 5.044487][ T25] ? __pfx_nvme_alloc_ns+0x10/0x10<br /> [ 5.044495][ T25] ? __pfx_nvme_find_get_ns+0x10/0x10<br /> [ 5.044496][ T25] ? rcu_read_lock_any_held+0x45/0xa0<br /> [ 5.044498][ T25] ? validate_chain+0x232/0x4f0<br /> [ 5.044503][ T25] nvme_scan_ns+0x4c8/0x810<br /> [ 5.044506][ T25] ? __pfx_nvme_scan_ns+0x10/0x10<br /> [ 5.044508][ T25] ? find_held_lock+0x2b/0x80<br /> [ 5.044512][ T25] ? ktime_get+0x16d/0x220<br /> [ 5.044517][ T25] ? kvm_clock_get_cycles+0x18/0x30<br /> [ 5.044520][ T25] ? __pfx_nvme_scan_ns_async+0x10/0x10<br /> [ 5.044522][ T25] async_run_entry_fn+0x97/0x560<br /> [ 5.044523][ T25] ? rcu_is_watching+0x12/0xc0<br /> [ 5.044526][ T25] process_one_work+0xd3c/0x1350<br /> [ 5.044532][ T25] ? __pfx_process_one_work+0x10/0x10<br /> [ 5.044536][ T25] ? assign_work+0x16c/0x240<br /> [ 5.044539][ T25] worker_thread+0x4da/0xd50<br /> [ 5.044545][ T25] ? __pfx_worker_thread+0x10/0x10<br /> [ 5.044546][ T25] kthread+0x356/0x5c0<br /> [ 5.044548][ T25] ? __pfx_kthread+0x10/0x10<br /> [ 5.044549][ T25] ? ret_from_fork+0x1b/0x2e0<br /> [ 5.044552][ T25] ? __lock_release.isra.0+0x5d/0x180<br /> [ 5.044553][ T25] ? ret_from_fork+0x1b/0x2e0<br /> [ 5.044555][ T25] ? rcu_is_watching+0x12/0xc0<br /> [ 5.044557][ T25] ? __pfx_kthread+0x10/0x10<br /> [ 5.04<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 /> 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.

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.