Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2025-39758 State: PUBLISHED Published: 2025-09-11T16:52:27.598Z Last Updated: 2025-09-29T05:58:48.839Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix the sendmsg byte count in siw_tcp_sendpages Ever since commit c2ff29e99a76 ("siw: Inline do_tcp_sendpages()"), we have been doing this: static int siw_tcp_sendpages(struct socket *s, struct page **page, int offset, size_t size) [...] /* Calculate the number of bytes we need to push, for this page * specifically */ size_t bytes = min_t(size_t, PAGE_SIZE - offset, size); /* If we can't splice it, then copy it in, as normal */ if (!sendpage_ok(page[i])) msg.
ze_t, PAGE_SIZE - offset, size); /* If we can't splice it, then copy it in, as normal */ if (!sendpage_ok(page[i])) msg.msg_flags &= ~MSG_SPLICE_PAGES; /* Set the bvec pointing to the page, with len $bytes */ bvec_set_page(&bvec, page[i], bytes, offset); /* Set the iter to $size, aka the size of the whole sendpages (!!!) */ iov_iter_bvec(&msg.msg_iter, ITER_SOURCE, &bvec, 1, size); try_page_again: lock_sock(sk); /* Sendmsg with $size size (!!!) */ rv = tcp_sendmsg_locked(sk, &msg, size); This means we've been sending oversized iov_iters and tcp_sendmsg calls for a while. This has a been a benign bug because sendpage_ok() always returned true. With the recent slab allocator changes being slow
is has a been a benign bug because sendpage_ok() always returned true. With the recent slab allocator changes being slowly introduced into next (that disallow sendpage on large kmalloc allocations), we have recently hit out-of-bounds crashes, due to slight differences in iov_iter behavior between the MSG_SPLICE_PAGES and "regular" copy paths: (MSG_SPLICE_PAGES) skb_splice_from_iter iov_iter_extract_pages iov_iter_extract_bvec_pages uses i->nr_segs to correctly stop in its tracks before OoB'ing everywhere skb_splice_from_iter gets a "short" read (!MSG_SPLICE_PAGES) skb_copy_to_page_nocache copy=iov_iter_count [...] copy_from_iter /* this doesn't help */ if (unlikely(iter->count < len)) len =
to_page_nocache copy=iov_iter_count [...] copy_from_iter /* this doesn't help */ if (unlikely(iter->count < len)) len = iter->count; iterate_bvec ... and we run off the bvecs Fix this by properly setting the iov_iter's byte count, plus sending the correct byte count to tcp_sendmsg_locked. References: - https://git.kernel.org/stable/c/5661fdd218c2799001b88c17acd19f4395e4488e - https://git.kernel.org/stable/c/673cf582fd788af12cdacfb62a6a593083542481 - https://git.kernel.org/stable/c/42ebc16d9d2563f1a1ce0f05b643ee68d54fabf8 - https://git.kernel.org/stable/c/edf82bc8150570167a33a7d54627d66614cbf841 - https://git.kernel.org/stable/c/c18646248fed07683d4cee8a8af933fc4fe83c0d
CVE ID: CVE-2025-39759 State: PUBLISHED Published: 2025-09-11T16:52:28.314Z Last Updated: 2025-11-03T17:43:07.988Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: btrfs: qgroup: fix race between quota disable and quota rescan ioctl There's a race between a task disabling quotas and another running the rescan ioctl that can result in a use-after-free of qgroup records from the fs_info->qgroup_tree rbtree. This happens as follows: 1) Task A enters btrfs_ioctl_quota_rescan() -> btrfs_qgroup_rescan(); 2) Task B enters btrfs_quota_disable() and calls btrfs_qgroup_wait_for_completion(), which does nothing because at that point fs_info
ers btrfs_quota_disable() and calls btrfs_qgroup_wait_for_completion(), which does nothing because at that point fs_info->qgroup_rescan_running is false (it wasn't set yet by task A); 3) Task B calls btrfs_free_qgroup_config() which starts freeing qgroups from fs_info->qgroup_tree without taking the lock fs_info->qgroup_lock; 4) Task A enters qgroup_rescan_zero_tracking() which starts iterating the fs_info->qgroup_tree tree while holding fs_info->qgroup_lock, but task B is freeing qgroup records from that tree without holding the lock, resulting in a use-after-free. Fix this by taking fs_info->qgroup_lock at btrfs_free_qgroup_config(). Also at btrfs_qgroup_rescan() don't start the rescan wor
s by taking fs_info->qgroup_lock at btrfs_free_qgroup_config(). Also at btrfs_qgroup_rescan() don't start the rescan worker if quotas were already disabled. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/7cda0fdde5d9890976861421d207870500f9aace - https://git.kernel.org/stable/c/b172535ccba12f0cf7d23b3b840989de47fc104d - https://git.kernel.org/stable/c/dd0b28d877b293b1d7f8727a7de08ae36b6b9ef0 - https://git.kernel.org/stable/c/c38028ce0d0045ca600b6a8345a0ff92bfb47b66 - https://git.kernel.org/stable/c/2fd0f5ceb997f90f4332ccbab6c7e907e6b2d0eb - https://git.kernel.org/stable/c/e1249667750399a48cafcf5945761d39fa584edf
CVE ID: CVE-2025-39760 State: PUBLISHED Published: 2025-09-11T16:52:29.045Z Last Updated: 2025-11-03T17:43:09.952Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: core: config: Prevent OOB read in SS endpoint companion parsing usb_parse_ss_endpoint_companion() checks descriptor type before length, enabling a potentially odd read outside of the buffer size. Fix this up by checking the size first before looking at any of the fields in the descriptor. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/5c3097ede7835d3caf6543eb70ff689af4550cd2 - https://git.kernel.org/stable/c/058ad2
ces: - https://git.kernel.org/stable/c/5c3097ede7835d3caf6543eb70ff689af4550cd2 - https://git.kernel.org/stable/c/058ad2b722812708fe90567875704ae36563e33b - https://git.kernel.org/stable/c/b10e0f868067c6f25bbfabdcf3e1e6432c24ca55 - https://git.kernel.org/stable/c/5badd56c711e2c8371d1670f9bd486697575423c - https://git.kernel.org/stable/c/9512510cee7d1becdb0e9413fdd3ab783e4e30ee - https://git.kernel.org/stable/c/4fe6f472f0beef4281e6f03bc38a910a33be663f - https://git.kernel.org/stable/c/9843bcb187cb933861f7805022e6873905f669e4 - https://git.kernel.org/stable/c/cf16f408364efd8a68f39011a3b073c83a03612d
CVE ID: CVE-2025-39761 State: PUBLISHED Published: 2025-09-11T16:52:29.788Z Last Updated: 2025-09-29T05:58:52.710Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Decrement TID on RX peer frag setup error handling Currently, TID is not decremented before peer cleanup, during error handling path of ath12k_dp_rx_peer_frag_setup(). This could lead to out-of-bounds access in peer->rx_tid[]. Hence, add a decrement operation for TID, before peer cleanup to ensures proper cleanup and prevents out-of-bounds access issues when the RX peer frag setup fails. Found during code review. Compile tested only. References: - https:/
ds access issues when the RX peer frag setup fails. Found during code review. Compile tested only. References: - https://git.kernel.org/stable/c/eb1e1526b82b8cf31f1ef9ca86a2647fb6cd89c6 - https://git.kernel.org/stable/c/7c3e99fd4a66a5ac9c7dd32db07359666efe0002 - https://git.kernel.org/stable/c/a3b73c72c42348bf1555fd2b00f32f941324b242 - https://git.kernel.org/stable/c/9530d666f4376c294cdf4348c29fe3542fec980a - https://git.kernel.org/stable/c/7c0884fcd2ddde0544d2e77f297ae461e1f53f58
CVE ID: CVE-2025-39762 State: PUBLISHED Published: 2025-09-11T16:52:30.647Z Last Updated: 2025-09-29T05:58:53.948Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: add null check [WHY] Prevents null pointer dereferences to enhance function robustness [HOW] Adds early null check and return false if invalid. References: - https://git.kernel.org/stable/c/13895744e2c639324cf3cb18f2ba4e3f400dd0dd - https://git.kernel.org/stable/c/10d97cc1a14ef1f611e156b0b27e8b226e103cc2 - https://git.kernel.org/stable/c/158b9201c17fc93ed4253c2f03b77fd2671669a1
CVE ID: CVE-2025-39763 State: PUBLISHED Published: 2025-09-11T16:52:31.350Z Last Updated: 2025-09-29T05:58:55.211Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ACPI: APEI: send SIGBUS to current task if synchronous memory error not recovered If a synchronous error is detected as a result of user-space process triggering a 2-bit uncorrected error, the CPU will take a synchronous error exception such as Synchronous External Abort (SEA) on Arm64. The kernel will queue a memory_failure() work which poisons the related page, unmaps the page, and then sends a SIGBUS to the process, so that a system wide panic can be avoided. Howeve
elated page, unmaps the page, and then sends a SIGBUS to the process, so that a system wide panic can be avoided. However, no memory_failure() work will be queued when abnormal synchronous errors occur. These errors can include situations like invalid PA, unexpected severity, no memory failure config support, invalid GUID section, etc. In such a case, the user-space process will trigger SEA again. This loop can potentially exceed the platform firmware threshold or even trigger a kernel hard lockup, leading to a system reboot. Fix it by performing a force kill if no memory_failure() work is queued for synchronous errors. [ rjw: Changelog edits ] References: - https://git.kernel.org/stable/c/0
ailure() work is queued for synchronous errors. [ rjw: Changelog edits ] References: - https://git.kernel.org/stable/c/082735fbcdb6cd0cf20fbec94516ab2996f1cdd5 - https://git.kernel.org/stable/c/cfc9bc15bda6fd0c496cbe2c628564d4d7c332c1 - https://git.kernel.org/stable/c/af089e41811a1ad6a7b2b80e839a73ec4c3cecdd - https://git.kernel.org/stable/c/3cb4f18797247985b0f51d5300f8cb6c78f343ea - https://git.kernel.org/stable/c/79a5ae3c4c5eb7e38e0ebe4d6bf602d296080060
CVE ID: CVE-2025-39764 State: PUBLISHED Published: 2025-09-11T16:52:32.060Z Last Updated: 2025-09-29T05:58:56.459Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: remove refcounting in expectation dumpers Same pattern as previous patch: do not keep the expectation object alive via refcount, only store a cookie value and then use that as the skip hint for dump resumption. AFAICS this has the same issue as the one resolved in the conntrack dumper, when we do if (!refcount_inc_not_zero(&exp->use)) to increment the refcount, there is a chance that exp == last, which causes a double-increment of the refcount and
use)) to increment the refcount, there is a chance that exp == last, which causes a double-increment of the refcount and subsequent memory leak. References: - https://git.kernel.org/stable/c/a4d634ded4d3d400f115d84f654f316f249531c9 - https://git.kernel.org/stable/c/1492e3dcb2be3aa46d1963da96aa9593e4e4db5a
CVE ID: CVE-2025-39765 State: PUBLISHED Published: 2025-09-11T16:56:20.738Z Last Updated: 2025-09-29T05:58:57.689Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: fix ida_free call while not allocated In the snd_utimer_create() function, if the kasprintf() function return NULL, snd_utimer_put_id() will be called, finally use ida_free() to free the unallocated id 0. the syzkaller reported the following information: ------------[ cut here ]------------ ida_free called for id=0 which is not allocated. WARNING: CPU: 1 PID: 1286 at lib/idr.c:592 ida_free+0x1fd/0x2f0 lib/idr.c:592 Modules linked in: CPU: 1 UID: 0 PID: 128
WARNING: CPU: 1 PID: 1286 at lib/idr.c:592 ida_free+0x1fd/0x2f0 lib/idr.c:592 Modules linked in: CPU: 1 UID: 0 PID: 1286 Comm: syz-executor164 Not tainted 6.15.8 #3 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.fc42 04/01/2014 RIP: 0010:ida_free+0x1fd/0x2f0 lib/idr.c:592 Code: f8 fc 41 83 fc 3e 76 69 e8 70 b2 f8 (...) RSP: 0018:ffffc900007f79c8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 1ffff920000fef3b RCX: ffffffff872176a5 RDX: ffff88800369d200 RSI: 0000000000000000 RDI: ffff88800369d200 RBP: 0000000000000000 R08: ffffffff87ba60a5 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000002 R14: 0000000
9: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000002 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f6f1abc1740(0000) GS:ffff8880d76a0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6f1ad7a784 CR3: 000000007a6e2000 CR4: 00000000000006f0 Call Trace: <TASK> snd_utimer_put_id sound/core/timer.c:2043 [inline] [snd_timer] snd_utimer_create+0x59b/0x6a0 sound/core/timer.c:2184 [snd_timer] snd_utimer_ioctl_create sound/core/timer.c:2202 [inline] [snd_timer] __snd_timer_user_ioctl.isra.0+0x724/0x1340 sound/core/timer.c:2287 [snd_timer] snd_timer_user_ioctl+0x75/0xc0 sound/core/timer.c:2298 [snd_t
tl.isra.0+0x724/0x1340 sound/core/timer.c:2287 [snd_timer] snd_timer_user_ioctl+0x75/0xc0 sound/core/timer.c:2298 [snd_timer] vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x198/0x200 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x7b/0x160 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] The utimer->id should be set properly before the kasprintf() function, ensures the snd_utimer_put_id() function will free the allocated id. References: - https://git.kernel.org/stable/c/34327b362ce2849a5eb02f47e800049e7a20a0ba - https://git.kernel.org/stable/c/a
ferences: - https://git.kernel.org/stable/c/34327b362ce2849a5eb02f47e800049e7a20a0ba - https://git.kernel.org/stable/c/af386b52531d14c4b20f11c452787b1b6dd4eb8d - https://git.kernel.org/stable/c/5003a65790ed66be882d1987cc2ca86af0de3db1
CVE ID: CVE-2025-39766 State: PUBLISHED Published: 2025-09-11T16:56:21.514Z Last Updated: 2025-11-03T17:43:11.881Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net/sched: Make cake_enqueue return NET_XMIT_CN when past buffer_limit The following setup can trigger a WARNING in htb_activate due to the condition: !cl->leaf.q->q.qlen tc qdisc del dev lo root tc qdisc add dev lo root handle 1: htb default 1 tc class add dev lo parent 1: classid 1:1 \ htb rate 64bit tc qdisc add dev lo parent 1:1 handle f: \ cake memlimit 1b ping -I lo -f -c1 -s64 -W0.001 127.0.0.1 This is because the low memlimit leads to a low buffer_limit, which
emlimit 1b ping -I lo -f -c1 -s64 -W0.001 127.0.0.1 This is because the low memlimit leads to a low buffer_limit, which causes packet dropping. However, cake_enqueue still returns NET_XMIT_SUCCESS, causing htb_enqueue to call htb_activate with an empty child qdisc. We should return NET_XMIT_CN when packets are dropped from the same tin and flow. I do not believe return value of NET_XMIT_CN is necessary for packet drops in the case of ack filtering, as that is meant to optimize performance, not to signal congestion. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/7689ab22de36f8db19095f6bdf11f28cfde92f5c - https://git.kernel.org/stable/c/de04ddd
es: - https://git.kernel.org/stable/c/7689ab22de36f8db19095f6bdf11f28cfde92f5c - https://git.kernel.org/stable/c/de04ddd2980b48caa8d7e24a7db2742917a8b280 - https://git.kernel.org/stable/c/0dacfc5372e314d1219f03e64dde3ab495a5a25e - https://git.kernel.org/stable/c/710866fc0a64eafcb8bacd91bcb1329eb7e5035f - https://git.kernel.org/stable/c/aa12ee1c1bd260943fd6ab556d8635811c332eeb - https://git.kernel.org/stable/c/ff57186b2cc39766672c4c0332323933e5faaa88 - https://git.kernel.org/stable/c/62d591dde4defb1333d202410609c4ddeae060b3 - https://git.kernel.org/stable/c/15de71d06a400f7fdc15bf377a2552b0ec437cf5
CVE ID: CVE-2025-39767 State: PUBLISHED Published: 2025-09-11T16:56:22.238Z Last Updated: 2025-09-29T05:59:00.267Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: LoongArch: Optimize module load time by optimizing PLT/GOT counting When enabling CONFIG_KASAN, CONFIG_PREEMPT_VOLUNTARY_BUILD and CONFIG_PREEMPT_VOLUNTARY at the same time, there will be soft deadlock, the relevant logs are as follows: rcu: INFO: rcu_sched self-detected stall on CPU ... Call Trace: [<900000000024f9e4>] show_stack+0x5c/0x180 [<90000000002482f4>] dump_stack_lvl+0x94/0xbc [<9000000000224544>] rcu_dump_cpu_stacks+0x1fc/0x280 [<900000000037ac80>] rcu_sched
0002482f4>] dump_stack_lvl+0x94/0xbc [<9000000000224544>] rcu_dump_cpu_stacks+0x1fc/0x280 [<900000000037ac80>] rcu_sched_clock_irq+0x720/0xf88 [<9000000000396c34>] update_process_times+0xb4/0x150 [<90000000003b2474>] tick_nohz_handler+0xf4/0x250 [<9000000000397e28>] __hrtimer_run_queues+0x1d0/0x428 [<9000000000399b2c>] hrtimer_interrupt+0x214/0x538 [<9000000000253634>] constant_timer_interrupt+0x64/0x80 [<9000000000349938>] __handle_irq_event_percpu+0x78/0x1a0 [<9000000000349a78>] handle_irq_event_percpu+0x18/0x88 [<9000000000354c00>] handle_percpu_irq+0x90/0xf0 [<9000000000348c74>] handle_irq_desc+0x94/0xb8 [<9000000001012b28>] handle_cpu_irq+0x68/0xa0 [<9000000001def8c0>] handle_loongarch_
0348c74>] handle_irq_desc+0x94/0xb8 [<9000000001012b28>] handle_cpu_irq+0x68/0xa0 [<9000000001def8c0>] handle_loongarch_irq+0x30/0x48 [<9000000001def958>] do_vint+0x80/0xd0 [<9000000000268a0c>] kasan_mem_to_shadow.part.0+0x2c/0x2a0 [<90000000006344f4>] __asan_load8+0x4c/0x120 [<900000000025c0d0>] module_frob_arch_sections+0x5c8/0x6b8 [<90000000003895f0>] load_module+0x9e0/0x2958 [<900000000038b770>] __do_sys_init_module+0x208/0x2d0 [<9000000001df0c34>] do_syscall+0x94/0x190 [<900000000024d6fc>] handle_syscall+0xbc/0x158 After analysis, this is because the slow speed of loading the amdgpu module leads to the long time occupation of the cpu and then the soft deadlock. When loading a module, mo
ing the amdgpu module leads to the long time occupation of the cpu and then the soft deadlock. When loading a module, module_frob_arch_sections() tries to figure out the number of PLTs/GOTs that will be needed to handle all the RELAs. It will call the count_max_entries() to find in an out-of-order date which counting algorithm has O(n^2) complexity. To make it faster, we sort the relocation list by info and addend. That way, to check for a duplicate relocation, it just needs to compare with the previous entry. This reduces the complexity of the algorithm to O(n log n), as done in commit d4e0340919fb ("arm64/module: Optimize module load time by optimizing PLT counting"). This gives sinificant
one in commit d4e0340919fb ("arm64/module: Optimize module load time by optimizing PLT counting"). This gives sinificant reduction in module load time for modules with large number of relocations. After applying this patch, the soft deadlock problem has been solved, and the kernel starts normally without "Call Trace". Using the default configuration to test some modules, the results are as follows: Module Size ip_tables 36K fat 143K radeon 2.5MB amdgpu 16MB Without this patch: Module Module load time (ms) Count(PLTs/GOTs) ip_tables 18 59/6 fat 0 162/14 radeon 54 1221/84 amdgpu 1411 4525/1098 With this patch: Module Module load time (ms) Count(PLTs/GOTs) ip_tables 18 59/6 fat 0 162/14 radeon
gpu 1411 4525/1098 With this patch: Module Module load time (ms) Count(PLTs/GOTs) ip_tables 18 59/6 fat 0 162/14 radeon 22 1221/84 amdgpu 45 4525/1098 References: - https://git.kernel.org/stable/c/5189c0b7c251363a4dd7678ed11b054c54f36f6f - https://git.kernel.org/stable/c/e94cdb9fb279430cbd323a74c7ec124c85109747 - https://git.kernel.org/stable/c/a096b0280168d0c8b0ec1cbbfd56c8b81af8c7d8 - https://git.kernel.org/stable/c/63dbd8fb2af3a89466538599a9acb2d11ef65c06
CVE ID: CVE-2025-39768 State: PUBLISHED Published: 2025-09-11T16:56:22.984Z Last Updated: 2025-09-29T05:59:01.618Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net/mlx5: HWS, fix complex rules rehash error flow Moving rules from matcher to matcher should not fail. However, if it does fail due to various reasons, the error flow should allow the kernel to continue functioning (albeit with broken steering rules) instead of going into series of soft lock-ups or some other problematic behaviour. Similar to the simple rules, complex rules rehash logic suffers from the same problems. This patch fixes the error flow for moving comple
mple rules, complex rules rehash logic suffers from the same problems. This patch fixes the error flow for moving complex rules: - If new rule creation fails before it was even enqeued, do not poll for completion - If TIMEOUT happened while moving the rule, no point trying to poll for completions for other rules. Something is broken, completion won't come, just abort the rehash sequence. - If some other completion with error received, don't give up. Continue handling rest of the rules to minimize the damage. - Make sure that the first error code that was received will be actually returned to the caller instead of replacing it with the generic error code. All the aforementioned issues stem fr
tually returned to the caller instead of replacing it with the generic error code. All the aforementioned issues stem from the same bad error flow, so no point fixing them one by one and leaving partially broken code - fixing them in one patch. References: - https://git.kernel.org/stable/c/37d54bc28d092bc3b314da45d730f00e9d86ec2a - https://git.kernel.org/stable/c/4a842b1bf18a32ee0c25dd6dd98728b786a76fe4
CVE ID: CVE-2025-39769 State: PUBLISHED Published: 2025-09-11T16:56:23.694Z Last Updated: 2025-09-29T05:59:02.952Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix lockdep warning during rmmod The commit under the Fixes tag added a netdev_assert_locked() in bnxt_free_ntp_fltrs(). The lock should be held during normal run-time but the assert will be triggered (see below) during bnxt_remove_one() which should not need the lock. The netdev is already unregistered by then. Fix it by calling netdev_assert_locked_or_invisible() which will not assert if the netdev is unregistered. WARNING: CPU: 5 PID: 2241 at ./include/net/
t_locked_or_invisible() which will not assert if the netdev is unregistered. WARNING: CPU: 5 PID: 2241 at ./include/net/netdev_lock.h:17 bnxt_free_ntp_fltrs+0xf8/0x100 [bnxt_en] Modules linked in: rpcrdma rdma_cm iw_cm ib_cm configfs ib_core bnxt_en(-) bridge stp llc x86_pkg_temp_thermal xfs tg3 [last unloaded: bnxt_re] CPU: 5 UID: 0 PID: 2241 Comm: rmmod Tainted: G S W 6.16.0 #2 PREEMPT(voluntary) Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01/17/2017 RIP: 0010:bnxt_free_ntp_fltrs+0xf8/0x100 [bnxt_en] Code: 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 48 8b 47 60 be ff ff ff ff 48 8d b8 28 0c 00 00 e8 d0 cf 41 c3 85 c0 0f 85 2e ff ff ff <0f> 0
41 5e 41 5f c3 cc cc cc cc 48 8b 47 60 be ff ff ff ff 48 8d b8 28 0c 00 00 e8 d0 cf 41 c3 85 c0 0f 85 2e ff ff ff <0f> 0b e9 27 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffa92082387da0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff9e5b593d8000 RCX: 0000000000000001 RDX: 0000000000000001 RSI: ffffffff83dc9a70 RDI: ffffffff83e1a1cf RBP: ffff9e5b593d8c80 R08: 0000000000000000 R09: ffffffff8373a2b3 R10: 000000008100009f R11: 0000000000000001 R12: 0000000000000001 R13: ffffffffc01c4478 R14: dead000000000122 R15: dead000000000100 FS: 00007f3a8a52c740(0000) GS:ffff9e631ad1c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055bb289419
0) GS:ffff9e631ad1c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055bb289419c8 CR3: 000000011274e001 CR4: 00000000003706f0 Call Trace: <TASK> bnxt_remove_one+0x57/0x180 [bnxt_en] pci_device_remove+0x39/0xc0 device_release_driver_internal+0xa5/0x130 driver_detach+0x42/0x90 bus_remove_driver+0x61/0xc0 pci_unregister_driver+0x38/0x90 bnxt_exit+0xc/0x7d0 [bnxt_en] References: - https://git.kernel.org/stable/c/5885d39dce879fbbc953f40e19adb60c29802302 - https://git.kernel.org/stable/c/4611d88a37cfc18cbabc6978aaf7325d1ae3f53a