deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2023-53790
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Zeroing allocated object from slab in bpf memory allocator

Currently the freed element in bpf memory allocator may be immediately
reused, for htab map the reuse will reinitialize special fields in map
value (e.g., bpf_spin_lock), but lookup procedure may still access
these special fields, and it may lead to hard-lockup as shown below:

 NMI backtrace for cpu 16
 CPU: 16 PID: 2574 Comm: htab.bin Tainted: G             L     6.1.0+ #1
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
 RIP: 0010:queued_spin_lock_slowpath+0x283/0x2c0
 ......
 Call Trace:
  <TASK>
  copy_map_value_locked+0xb7/0x170
  bpf_map_copy_value+0x113/0x3c0
  __sys_bpf+0x1c67/0x2780
  __x64_sys_bpf+0x1c/0x20
  do_syscall_64+0x30/0x60
  entry_SYSCALL_64_after_hwframe+0x46/0xb0
 ......
  </TASK>

For htab map, just like the preallocated case, these is no need to
initialize these special fields in map value again once these fields
have been initialized. For preallocated htab map, these fields are
initialized through __GFP_ZERO in bpf_map_area_alloc(), so do the
similar thing for non-preallocated htab in bpf memory allocator. And
there is no need to use __GFP_ZERO for per-cpu bpf memory allocator,
because __alloc_percpu_gfp() does it implicitly.
References: https://git.kernel.org/stable/c/5d447e04290e78bdc1a3a6c321320d384e09c2f1; https://git.kernel.org/stable/c/678ea18d6240299fd77d7000c8b1d7e5f274c8af; https://git.kernel.org/stable/c/997849c4b969034e225153f41026657def66d286
CVE: CVE-2023-53791
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

md: fix warning for holder mismatch from export_rdev()

Commit a1d767191096 ("md: use mddev->external to select holder in
export_rdev()") fix the problem that 'claim_rdev' is used for
blkdev_get_by_dev() while 'rdev' is used for blkdev_put().

However, if mddev->external is changed from 0 to 1, then 'rdev' is used
for blkdev_get_by_dev() while 'claim_rdev' is used for blkdev_put(). And
this problem can be reporduced reliably by following:

New file: mdadm/tests/23rdev-lifetime

devname=${dev0##*/}
devt=`cat /sys/block/$devname/dev`
pid=""
runtime=2

clean_up_test() {
        pill -9 $pid
        echo clear > /sys/block/md0/md/array_state
}

trap 'clean_up_test' EXIT

add_by_sysfs() {
        while true; do
                echo $devt > /sys/block/md0/md/new_dev
        done
}

remove_by_sysfs(){
        while true; do
                echo remove > /sys/block/md0/md/dev-${devname}/state
        done
}

echo md0 > /sys/module/md_mod/parameters/new_array || die "create md0 failed"

add_by_sysfs &
pid="$pid $!"

remove_by_sysfs &
pid="$pid $!"

sleep $runtime
exit 0

Test cmd:

./test --save-logs --logdir=/tmp/ --keep-going --dev=loop --tests=23rdev-lifetime

Test result:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 960 at block/bdev.c:618 blkdev_put+0x27c/0x330
Modules linked in: multipath md_mod loop
CPU: 0 PID: 960 Comm: test Not tainted 6.5.0-rc2-00121-g01e55c376936-dirty #50
RIP: 0010:blkdev_put+0x27c/0x330
Call Trace:
 <TASK>
 export_rdev.isra.23+0x50/0xa0 [md_mod]
 mddev_unlock+0x19d/0x300 [md_mod]
 rdev_attr_store+0xec/0x190 [md_mod]
 sysfs_kf_write+0x52/0x70
 kernfs_fop_write_iter+0x19a/0x2a0
 vfs_write+0x3b5/0x770
 ksys_write+0x74/0x150
 __x64_sys_write+0x22/0x30
 do_syscall_64+0x40/0x90
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Fix the problem by recording if 'rdev' is used as holder.
References: https://git.kernel.org/stable/c/99892147f028d711f9d40fefad4f[PII_REDACTED]4c; https://git.kernel.org/stable/c/99fcd427178d0f58f5520f8f01df727f8eaeb2c7
CVE: CVE-2023-53792
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

nvme-core: fix memory leak in dhchap_ctrl_secret

Free dhchap_secret in nvme_ctrl_dhchap_ctrl_secret_store() before we
return when nvme_auth_generate_key() returns error.
References: https://git.kernel.org/stable/c/39b90fc75943406d2bd60fd1ea041aca2559cc5f; https://git.kernel.org/stable/c/43d0724d756a13694f612a8a151f835ad6425b93; https://git.kernel.org/stable/c/6ec30a62789913b1bd0f0d44ea4d0d2d5608b1e8
CVE: CVE-2023-53793
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

perf tool x86: Fix perf_env memory leak

Found by leak sanitizer:
```
==1632594==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 21 byte(s) in 1 object(s) allocated from:
    #0 0x7f2953a7077b in __interceptor_strdup ../../../../src/libsanitizer/asan/asan_interceptors.cpp:439
    #1 0x556701d6fbbf in perf_env__read_cpuid util/env.c:369
    #2 0x556701d70589 in perf_env__cpuid util/env.c:465
    #3 0x55670204bba2 in x86__is_amd_cpu arch/x86/util/env.c:14
    #4 0x[PII_REDACTED]a2 in arch__post_evsel_config arch/x86/util/evsel.c:83
    #5 0x556701d8f78b in evsel__config util/evsel.c:1366
    #6 0x556701ef5872 in evlist__config util/record.c:108
    #7 0x556701cd6bcd in test__PERF_RECORD tests/perf-record.c:112
    #8 0x556701cacd07 in run_test tests/builtin-test.c:236
    #9 0x556701cacfac in test_and_print tests/builtin-test.c:265
    #10 0x556701cadddb in __cmd_test tests/builtin-test.c:402
    #11 0x556701caf2aa in cmd_test tests/builtin-test.c:559
    #12 0x556701d3b557 in run_builtin tools/perf/perf.c:323
    #13 0x556701d3bac8 in handle_internal_command tools/perf/perf.c:377
    #14 0x556701d3be90 in run_argv tools/perf/perf.c:421
    #15 0x556701d3c3f8 in main tools/perf/perf.c:537
    #16 0x7f2952a46189 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

SUMMARY: AddressSanitizer: 21 byte(s) leaked in 1 allocation(s).
```
References: https://git.kernel.org/stable/c/010139bfc6bb9ddab81dbc2cf71cd3a9c28adc7f; https://git.kernel.org/stable/c/75d65c1cc439606ada882755fd205d13c2c7907d; https://git.kernel.org/stable/c/99d4850062a84564f36923764bb93935ef2ed108
CVE: CVE-2023-53794
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

cifs: fix session state check in reconnect to avoid use-after-free issue

Don't collect exiting session in smb2_reconnect_server(), because it
will be released soon.

Note that the exiting session will stay in server->smb_ses_list until
it complete the cifs_free_ipc() and logoff() and then delete itself
from the list.
References: https://git.kernel.org/stable/c/759ffc164d95a32c09528766d74d9b4fb054e8f4; https://git.kernel.org/stable/c/7e4f5c3f01fb0e51ca438e43262d858daf9a0a76; https://git.kernel.org/stable/c/99f280700b4cc02d5f141b8d15f8e9fad0418f65
CVE: CVE-2023-53795
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

iommufd: IOMMUFD_DESTROY should not increase the refcount

syzkaller found a race where IOMMUFD_DESTROY increments the refcount:

       obj = iommufd_get_object(ucmd->ictx, cmd->id, IOMMUFD_OBJ_ANY);
       if (IS_ERR(obj))
               return PTR_ERR(obj);
       iommufd_ref_to_users(obj);
       /* See iommufd_ref_to_users() */
       if (!iommufd_object_destroy_user(ucmd->ictx, obj))

As part of the sequence to join the two existing primitives together.

Allowing the refcount the be elevated without holding the destroy_rwsem
violates the assumption that all temporary refcount elevations are
protected by destroy_rwsem. Racing IOMMUFD_DESTROY with
iommufd_object_destroy_user() will cause spurious failures:

  WARNING: CPU: 0 PID: 3076 at drivers/iommu/iommufd/device.c:477 iommufd_access_destroy+0x18/0x20 drivers/iommu/iommufd/device.c:478
  Modules linked in:
  CPU: 0 PID: 3076 Comm: syz-executor.0 Not tainted 6.3.0-rc1-syzkaller #0
  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/03/2023
  RIP: 0010:iommufd_access_destroy+0x18/0x20 drivers/iommu/iommufd/device.c:477
  Code: e8 3d 4e 00 00 84 c0 74 01 c3 0f 0b c3 0f 1f 44 00 00 f3 0f 1e fa 48 89 fe 48 8b bf a8 00 00 00 e8 1d 4e 00 00 84 c0 74 01 c3 <0f> 0b c3 0f 1f 44 00 00 41 57 41 56 41 55 4c 8d ae d0 00 00 00 41
  RSP: 0018:ffffc90003067e08 EFLAGS: 00010246
  RAX: [PII_REDACTED] RBX: ffff888109ea0300 RCX: [PII_REDACTED]
  RDX: [PII_REDACTED] RSI: [PII_REDACTED] RDI: 00000000ffffffff
  RBP: [PII_REDACTED] R08: [PII_REDACTED] R09: ffff88810bbb3500
  R10: ffff88810bbb3e48 R11: [PII_REDACTED] R12: ffffc90003067e88
  R13: ffffc90003067ea8 R14: ffff[PII_REDACTED]00 R15: 00000000fffffffe
  FS:  00007ff7254fe6c0(0000) GS:ffff888237c00000(0000) knlGS:[PII_REDACTED]
  CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
  CR2:[PII_REDACTED]262da8 CR3: 000000010a6fd000 CR4:[PII_REDACTED]350ef0
  Call Trace:
   <TASK>
   iommufd_test_create_access drivers/iommu/iommufd/selftest.c:596 [inline]
   iommufd_test+0x71c/0xcf0 drivers/iommu/iommufd/selftest.c:813
   iommufd_fops_ioctl+0x10f/0x1b0 drivers/iommu/iommufd/main.c:337
   vfs_ioctl fs/ioctl.c:51 [inline]
   __do_sys_ioctl fs/ioctl.c:870 [inline]
   __se_sys_ioctl fs/ioctl.c:856 [inline]
   __x64_sys_ioctl+0x84/0xc0 fs/ioctl.c:856
   do_syscall_x64 arch/x86/entry/common.c:50 [inline]
   do_syscall_64+0x38/0x80 arch/x86/entry/common.c:80
   entry_SYSCALL_64_after_hwframe+0x63/0xcd

The solution is to not increment the refcount on the IOMMUFD_DESTROY path
at all. Instead use the xa_lock to serialize everything. The refcount
check == 1 and xa_erase can be done under a single critical region. This
avoids the need for any refcount incrementing.

It has the downside that if userspace races destroy with other operations
it will get an EBUSY instead of waiting, but this is kind of racing is
already dangerous.
References: https://git.kernel.org/stable/c/495b327435b0298e9b3b434f5834d459a93673ce; https://git.kernel.org/stable/c/99f98a7c0d6985d5507c8130a981972e4b7b3bdc
CVE: CVE-2023-53796
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix information leak in f2fs_move_inline_dirents()

When converting an inline directory to a regular one, f2fs is leaking
uninitialized memory to disk because it doesn't initialize the entire
directory block.  Fix this by zero-initializing the block.

This bug was introduced by commit 4ec17d688d74 ("f2fs: avoid unneeded
initializing when converting inline dentry"), which didn't consider the
security implications of leaking uninitialized memory to disk.

This was found by running xfstest generic/435 on a KMSAN-enabled kernel.
References: https://git.kernel.org/stable/c/00b[PII_REDACTED]d0fddb2a5f5a3d4acd950102ace; https://git.kernel.org/stable/c/117d4f6687b1f74423b5d398ea95c63b262a8e73; https://git.kernel.org/stable/c/2bef8314fcf94ddc27e22d03f237c0fafd00de33
CVE: CVE-2023-53797
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

HID: wacom: Use ktime_t rather than int when dealing with timestamps

Code which interacts with timestamps needs to use the ktime_t type
returned by functions like ktime_get. The int type does not offer
enough space to store these values, and attempting to use it is a
recipe for problems. In this particular case, overflows would occur
when calculating/storing timestamps leading to incorrect values being
reported to userspace. In some cases these bad timestamps cause input
handling in userspace to appear hung.
References: https://git.kernel.org/stable/c/67ce7724637c6adb66f788677cb50b82615de0ac; https://git.kernel.org/stable/c/9598a647ecc8f300b0540abf9d3b3439859d163b; https://git.kernel.org/stable/c/99036f1aed7e82773904f5d91a9897bb3e507fd9
CVE: CVE-2023-53799
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

crypto: api - Use work queue in crypto_destroy_instance

The function crypto_drop_spawn expects to be called in process
context.  However, when an instance is unregistered while it still
has active users, the last user may cause the instance to be freed
in atomic context.

Fix this by delaying the freeing to a work queue.
References: https://git.kernel.org/stable/c/048545d9fc6424b0a11e7e8771225bb9afe09422; https://git.kernel.org/stable/c/625bf86bf53eb7a8ee60fb9dc45b272b77e5ce1c; https://git.kernel.org/stable/c/867a146690960ac7b89ce40f4ee60dd32eeb1682
CVE: CVE-2023-53800
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

ubi: Fix use-after-free when volume resizing failed

There is an use-after-free problem reported by KASAN:
  ==================================================================
  BUG: KASAN: use-after-free in ubi_eba_copy_table+0x11f/0x1c0 [ubi]
  Read of size 8 at addr ffff888101eec008 by task ubirsvol/4735

  CPU: 2 PID: 4735 Comm: ubirsvol
  Not tainted 6.1.0-rc1-00003-g84fa3304a7fc-dirty #14
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
  BIOS 1.14.0-1.fc33 04/01/2014
  Call Trace:
   <TASK>
   dump_stack_lvl+0x34/0x44
   print_report+0x171/0x472
   kasan_report+0xad/0x130
   ubi_eba_copy_table+0x11f/0x1c0 [ubi]
   ubi_resize_volume+0x4f9/0xbc0 [ubi]
   ubi_cdev_ioctl+0x701/0x1850 [ubi]
   __x64_sys_ioctl+0x11d/0x170
   do_syscall_64+0x35/0x80
   entry_SYSCALL_64_after_hwframe+0x46/0xb0
   </TASK>

When ubi_change_vtbl_record() returns an error in ubi_resize_volume(),
"new_eba_tbl" will be freed on error handing path, but it is holded
by "vol->eba_tbl" in ubi_eba_replace_table(). It means that the liftcycle
of "vol->eba_tbl" and "vol" are different, so when resizing volume in
next time, it causing an use-after-free fault.

Fix it by not freeing "new_eba_tbl" after it replaced in
ubi_eba_replace_table(), while will be freed in next volume resizing.
References: https://git.kernel.org/stable/c/35f8d4064e54c18424db2997059d4c0b1d13d093; https://git.kernel.org/stable/c/3d6378f7056ac7350338f941001162a8f660853c; https://git.kernel.org/stable/c/53818746e549e[PII_REDACTED]2a8d94344494be797
CVE: CVE-2023-53801
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

iommu/sprd: Release dma buffer to avoid memory leak

When attaching to a domain, the driver would alloc a DMA buffer which
is used to store address mapping table, and it need to be released
when the IOMMU domain is freed.
References: https://git.kernel.org/stable/c/8745f3592ee4a7b49ede16ddd3f12a41ecaa23c9; https://git.kernel.org/stable/c/92c089a931fd3939cd32318cf4f54e69e8f51a19; https://git.kernel.org/stable/c/9afea57384d4ae7b2034593eac7fa76c7122762a
CVE: CVE-2023-53802
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath9k: htc_hst: free skb in ath9k_htc_rx_msg() if there is no callback function

It is stated that ath9k_htc_rx_msg() either frees the provided skb or
passes its management to another callback function. However, the skb is
not freed in case there is no another callback function, and Syzkaller was
able to cause a memory leak. Also minor comment fix.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
References: https://git.kernel.org/stable/c/564bc2222bf50eb6cdee715a5431bf4dc9f923c1; https://git.kernel.org/stable/c/5a84e51f72580fc70066b03f3dac38421e702a0b; https://git.kernel.org/stable/c/68171c006c8645a3e0293a6c3e6037c6538ac1c5
CVE: CVE-2023-53803
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: ses: Fix slab-out-of-bounds in ses_enclosure_data_process()

A fix for:

BUG: KASAN: slab-out-of-bounds in ses_enclosure_data_process+0x949/0xe30 [ses]
Read of size 1 at addr ffff88a1b043a451 by task systemd-udevd/3271

Checking after (and before in next loop) addl_desc_ptr[1] is sufficient, we
expect the size to be sanitized before first access to addl_desc_ptr[1].
Make sure we don't walk beyond end of page.
References: https://git.kernel.org/stable/c/0dfe68394cbe1d4fe579fb325ecc813c50528c5a; https://git.kernel.org/stable/c/2b28a7d261cb309912596d6a2d383ca370483527; https://git.kernel.org/stable/c/467afb1dd630d8c6d172bd6cacc125199b5f4f2d
CVE: CVE-2023-53804
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

nilfs2: fix use-after-free bug of nilfs_root in nilfs_evict_inode()

During unmount process of nilfs2, nothing holds nilfs_root structure after
nilfs2 detaches its writer in nilfs_detach_log_writer().  However, since
nilfs_evict_inode() uses nilfs_root for some cleanup operations, it may
cause use-after-free read if inodes are left in "garbage_list" and
released by nilfs_dispose_list() at the end of nilfs_detach_log_writer().

Fix this issue by modifying nilfs_evict_inode() to only clear inode
without additional metadata changes that use nilfs_root if the file system
is degraded to read-only or the writer is detached.
References: https://git.kernel.org/stable/c/116d53f09ff52e6f98e3fe1f85d8898d6ba26c68; https://git.kernel.org/stable/c/2a782ea8ebd712a458466e3103e2881b4f886cb5; https://git.kernel.org/stable/c/6b4205ea97901f822004e6c8d59484ccfda03faa
CVE: CVE-2023-53805
Published: 2025-12-09
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2023-53806
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: populate subvp cmd info only for the top pipe

[Why]
System restart observed while changing the display resolution
to 8k with extended mode. Sytem restart was caused by a page fault.

[How]
When the driver populates subvp info it did it for both the pipes using
vblank which caused an outof bounds array access causing the page fault.
added checks to allow the top pipe only to fix this issue.
References: https://git.kernel.org/stable/c/375d192eb1f1d9229a6d994da7ba31f3582b106b; https://git.kernel.org/stable/c/92e6c79acad4b96efeff261d27bdbd8089a7dd24; https://git.kernel.org/stable/c/9bb10b7aaec3b6278f9cc410c17dcaa129bbbbf0
CVE: CVE-2023-53807
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: clocking-wizard: Fix Oops in clk_wzrd_register_divider()

Smatch detected this potential error pointer dereference
clk_wzrd_register_divider().  If devm_clk_hw_register() fails then
it sets "hw" to an error pointer and then dereferences it on the
next line.  Return the error directly instead.
References: https://git.kernel.org/stable/c/25dbdfb7b71ef8601d00c6d9a2b1a96de28b30c5; https://git.kernel.org/stable/c/2f276dd9c0f835242836d9f[PII_REDACTED]ce2585c; https://git.kernel.org/stable/c/9c632a6396505a019ea6d12b5ab45e659a542a93
CVE: CVE-2023-53808
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mwifiex: fix memory leak in mwifiex_histogram_read()

Always free the zeroed page on return from 'mwifiex_histogram_read()'.
References: https://git.kernel.org/stable/c/0c4240d23db525208fd40dd6371ca3254fa1b93d; https://git.kernel.org/stable/c/308eb3a609ac39ca9c3e466b35e8825007c8d826; https://git.kernel.org/stable/c/5d66b32a6ecf2e2e1a9523eaa4f8b314832fe06c
CVE: CVE-2023-53810
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

blk-mq: release crypto keyslot before reporting I/O complete

Once all I/O using a blk_crypto_key has completed, filesystems can call
blk_crypto_evict_key().  However, the block layer currently doesn't call
blk_crypto_put_keyslot() until the request is being freed, which happens
after upper layers have been told (via bio_endio()) the I/O has
completed.  This causes a race condition where blk_crypto_evict_key()
can see 'slot_refs != 0' without there being an actual bug.

This makes __blk_crypto_evict_key() hit the
'WARN_ON_ONCE(atomic_read(&slot->slot_refs) != 0)' and return without
doing anything, eventually causing a use-after-free in
blk_crypto_reprogram_all_keys().  (This is a very rare bug and has only
been seen when per-file keys are being used with fscrypt.)

There are two options to fix this: either release the keyslot before
bio_endio() is called on the request's last bio, or make
__blk_crypto_evict_key() ignore slot_refs.  Let's go with the first
solution, since it preserves the ability to report bugs (via
WARN_ON_ONCE) where a key is evicted while still in-use.
References: https://git.kernel.org/stable/c/7d206ec7a04e[PII_REDACTED]b6ea8b49d3ea61391f; https://git.kernel.org/stable/c/874bdf43b4a7dc5463c31508f62b3e42eb237b08; https://git.kernel.org/stable/c/92d5d233b9ff531cf9cc36ab4251779e07adb633
CVE: CVE-2023-53811
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/irdma: Cap MSIX used to online CPUs + 1

The irdma driver can use a maximum number of msix vectors equal
to num_online_cpus() + 1 and the kernel warning stack below is shown
if that number is exceeded.

The kernel throws a warning as the driver tries to update the affinity
hint with a CPU mask greater than the max CPU IDs. Fix this by capping
the MSIX vectors to num_online_cpus() + 1.

 WARNING: CPU: 7 PID: 23655 at include/linux/cpumask.h:106 irdma_cfg_ceq_vector+0x34c/0x3f0 [irdma]
 RIP: 0010:irdma_cfg_ceq_vector+0x34c/0x3f0 [irdma]
 Call Trace:
 irdma_rt_init_hw+0xa62/0x1290 [irdma]
 ? irdma_alloc_local_mac_entry+0x1a0/0x1a0 [irdma]
 ? __is_kernel_percpu_address+0x63/0x310
 ? rcu_read_lock_held_common+0xe/0xb0
 ? irdma_lan_unregister_qset+0x280/0x280 [irdma]
 ? irdma_request_reset+0x80/0x80 [irdma]
 ? ice_get_qos_params+0x84/0x390 [ice]
 irdma_probe+0xa40/0xfc0 [irdma]
 ? rcu_read_lock_bh_held+0xd0/0xd0
 ? irdma_remove+0x140/0x140 [irdma]
 ? rcu_read_lock_sched_held+0x62/0xe0
 ? down_write+0x187/0x3d0
 ? auxiliary_match_id+0xf0/0x1a0
 ? irdma_remove+0x140/0x140 [irdma]
 auxiliary_bus_probe+0xa6/0x100
 __driver_probe_device+0x4a4/0xd50
 ? __device_attach_driver+0x2c0/0x2c0
 driver_probe_device+0x4a/0x110
 __driver_attach+0x1aa/0x350
 bus_for_each_dev+0x11d/0x1b0
 ? subsys_dev_iter_init+0xe0/0xe0
 bus_add_driver+0x3b1/0x610
 driver_register+0x18e/0x410
 ? 0xffffffffc0b88000
 irdma_init_module+0x50/0xaa [irdma]
 do_one_initcall+0x103/0x5f0
 ? perf_trace_initcall_level+0x420/0x420
 ? do_init_module+0x4e/0x700
 ? __kasan_kmalloc+0x7d/0xa0
 ? kmem_cache_alloc_trace+0x188/0x2b0
 ? kasan_unpoison+0x21/0x50
 do_init_module+0x1d1/0x700
 load_module+0x3867/0x5260
 ? layout_and_allocate+0x3990/0x3990
 ? rcu_read_lock_held_common+0xe/0xb0
 ? rcu_read_lock_sched_held+0x62/0xe0
 ? rcu_read_lock_bh_held+0xd0/0xd0
 ? __vmalloc_node_range+0x46b/0x890
 ? lock_release+0x5c8/0xba0
 ? alloc_vm_area+0x120/0x120
 ? selinux_kernel_module_from_file+0x2a5/0x300
 ? __inode_security_revalidate+0xf0/0xf0
 ? __do_sys_init_module+0x1db/0x260
 __do_sys_init_module+0x1db/0x260
 ? load_module+0x5260/0x5260
 ? do_syscall_64+0x22/0x450
 do_syscall_64+0xa5/0x450
 entry_SYSCALL_64_after_hwframe+0x66/0xdb
References: https://git.kernel.org/stable/c/209e4aa9a7b636d8aaa1297e1d089ee2ed91d73f; https://git.kernel.org/stable/c/87674a359ad173a3b8cd484e92e4f1901666da4c; https://git.kernel.org/stable/c/9cd9842c46996ef62173c36619c746f57416bcb0