deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2022-49358
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_tables: memleak flow rule from commit path

Abort path release flow rule object, however, commit path does not.
Update code to destroy these objects before releasing the transaction.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/330c0c6cd2150a2d7f47af16aa590078b0d2f736; https://git.kernel.org/stable/c/5b8d63489c3b701eb2a76f848ec94d8cbc9373b9; https://git.kernel.org/stable/c/80de9ea1f5b808a6601e91111fae601df2b26369
CVE: CVE-2022-49359
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/panfrost: Job should reference MMU not file_priv

For a while now it's been allowed for a MMU context to outlive it's
corresponding panfrost_priv, however the job structure still references
panfrost_priv to get hold of the MMU context. If panfrost_priv has been
freed this is a use-after-free which I've been able to trigger resulting
in a splat.

To fix this, drop the reference to panfrost_priv in the job structure
and add a direct reference to the MMU structure which is what's actually
needed.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/472dd7ea5e19a1aeabf1711ddc756777e05ee7c2; https://git.kernel.org/stable/c/6e516faf04317db2c46cbec4e3b78b4653a5b109; https://git.kernel.org/stable/c/8c8e8cc91a6ffc[PII_REDACTED]9a74fd57d9070a17
CVE: CVE-2022-49360
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix to do sanity check on total_data_blocks

As Yanming reported in bugzilla:

https://bugzilla.kernel.org/show_bug.cgi?id=215916

The kernel message is shown below:

kernel BUG at fs/f2fs/segment.c:2560!
Call Trace:
 allocate_segment_by_default+0x228/0x440
 f2fs_allocate_data_block+0x13d1/0x31f0
 do_write_page+0x18d/0x710
 f2fs_outplace_write_data+0x151/0x250
 f2fs_do_write_data_page+0xef9/0x1980
 move_data_page+0x6af/0xbc0
 do_garbage_collect+0x312f/0x46f0
 f2fs_gc+0x6b0/0x3bc0
 f2fs_balance_fs+0x921/0x2260
 f2fs_write_single_data_page+0x16be/0x2370
 f2fs_write_cache_pages+0x428/0xd00
 f2fs_write_data_pages+0x96e/0xd50
 do_writepages+0x168/0x550
 __writeback_single_inode+0x9f/0x870
 writeback_sb_inodes+0x47d/0xb20
 __writeback_inodes_wb+0xb2/0x200
 wb_writeback+0x4bd/0x660
 wb_workfn+0x5f3/0xab0
 process_one_work+0x79f/0x13e0
 worker_thread+0x89/0xf60
 kthread+0x26a/0x300
 ret_from_fork+0x22/0x30
RIP: 0010:new_curseg+0xe8d/0x15f0

The root cause is: ckpt.valid_block_count is inconsistent with SIT table,
stat info indicates filesystem has free blocks, but SIT table indicates
filesystem has no free segment.

So that during garbage colloection, it triggers panic when LFS allocator
fails to find free segment.

This patch tries to fix this issue by checking consistency in between
ckpt.valid_block_count and block accounted from SIT.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/071b1269a3b3ad9cec16ed76a48015bfffd9aee8; https://git.kernel.org/stable/c/6b8beca0edd32075a769bfe4178ca00c0dcd22a9; https://git.kernel.org/stable/c/c9e4cd5b0ccd7168801d6a811919171b185c5cf8
CVE: CVE-2022-49361
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix to do sanity check for inline inode

Yanming reported a kernel bug in Bugzilla kernel [1], which can be
reproduced. The bug message is:

The kernel message is shown below:

kernel BUG at fs/inode.c:611!
Call Trace:
 evict+0x282/0x4e0
 __dentry_kill+0x2b2/0x4d0
 dput+0x2dd/0x720
 do_renameat2+0x596/0x970
 __x64_sys_rename+0x78/0x90
 do_syscall_64+0x3b/0x90

[1] https://bugzilla.kernel.org/show_bug.cgi?id=215895

The bug is due to fuzzed inode has both inline_data and encrypted flags.
During f2fs_evict_inode(), as the inode was deleted by rename(), it
will cause inline data conversion due to conflicting flags. The page
cache will be polluted and the panic will be triggered in clear_inode().

Try fixing the bug by doing more sanity checks for inline data inode in
sanity_check_inode().
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/11c1cd032df85df3c096a57a7f27d57819956e4a; https://git.kernel.org/stable/c/198fd9faa271dd54dca6fc8eb6873f42dfd3b4d8; https://git.kernel.org/stable/c/677a82b44ebf263d4f9a0cfbd576a6ade797a07b
CVE: CVE-2022-49362
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

NFSD: Fix potential use-after-free in nfsd_file_put()

nfsd_file_put_noref() can free @nf, so don't dereference @nf
immediately upon return from nfsd_file_put_noref().
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/261eabe19cb28e4a8587a4442d257b543d7c2d57; https://git.kernel.org/stable/c/333dcc94ebf53f79f3dc0e7a7c16700bc7ff7e57; https://git.kernel.org/stable/c/ada1757b259f353cade47037ee0a0249b4cddad3
CVE: CVE-2022-49363
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix to do sanity check on block address in f2fs_do_zero_range()

As Yanming reported in bugzilla:

https://bugzilla.kernel.org/show_bug.cgi?id=215894

I have encountered a bug in F2FS file system in kernel v5.17.

I have uploaded the system call sequence as case.c, and a fuzzed image can
be found in google net disk

The kernel should enable CONFIG_KASAN=y and CONFIG_KASAN_INLINE=y. You can
reproduce the bug by running the following commands:

kernel BUG at fs/f2fs/segment.c:2291!
Call Trace:
 f2fs_invalidate_blocks+0x193/0x2d0
 f2fs_fallocate+0x2593/0x4a70
 vfs_fallocate+0x2a5/0xac0
 ksys_fallocate+0x35/0x70
 __x64_sys_fallocate+0x8e/0xf0
 do_syscall_64+0x3b/0x90
 entry_SYSCALL_64_after_hwframe+0x44/0xae

The root cause is, after image was fuzzed, block mapping info in inode
will be inconsistent with SIT table, so in f2fs_fallocate(), it will cause
panic when updating SIT with invalid blkaddr.

Let's fix the issue by adding sanity check on block address before updating
SIT table with it.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/25f8236213a91efdf708b9d77e9e51b6fc3e141c; https://git.kernel.org/stable/c/470493be19a5730ed432e3ac0f29a2ee7fc6c557; https://git.kernel.org/stable/c/7361c9f2bd6a8f0cbb41cdea9aff04765ff23f67
CVE: CVE-2022-49364
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix to clear dirty inode in f2fs_evict_inode()

As Yanming reported in bugzilla:

https://bugzilla.kernel.org/show_bug.cgi?id=215904

The kernel message is shown below:

kernel BUG at fs/f2fs/inode.c:825!
Call Trace:
 evict+0x282/0x4e0
 __dentry_kill+0x2b2/0x4d0
 shrink_dentry_list+0x17c/0x4f0
 shrink_dcache_parent+0x143/0x1e0
 do_one_tree+0x9/0x30
 shrink_dcache_for_umount+0x51/0x120
 generic_shutdown_super+0x5c/0x3a0
 kill_block_super+0x90/0xd0
 kill_f2fs_super+0x225/0x310
 deactivate_locked_super+0x78/0xc0
 cleanup_mnt+0x2b7/0x480
 task_work_run+0xc8/0x150
 exit_to_user_mode_prepare+0x14a/0x150
 syscall_exit_to_user_mode+0x1d/0x40
 do_syscall_64+0x48/0x90

The root cause is: inode node and dnode node share the same nid,
so during f2fs_evict_inode(), dnode node truncation will invalidate
its NAT entry, so when truncating inode node, it fails due to
invalid NAT entry, result in inode is still marked as dirty, fix
this issue by clearing dirty for inode and setting SBI_NEED_FSCK
flag in filesystem.

output from dump.f2fs:
[print_node_info: 354] Node ID [0xf:15] is inode
i_nid[0]                      		[0x       f : 15]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/03c9373b15fa1c245ec99b2b5e7ba209eae4ef42; https://git.kernel.org/stable/c/54c116615c99e22aa08aa950757ed726e2f60821; https://git.kernel.org/stable/c/c469953917b319d415fd621b9e5d0ea5203565cd
CVE: CVE-2022-49365
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: Off by one in dm_dmub_outbox1_low_irq()

The > ARRAY_SIZE() should be >= ARRAY_SIZE() to prevent an out of bounds
access.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-193, CWE-193
References: https://git.kernel.org/stable/c/607c5cd1a08e196d9f2bd3b25a8083ed27ad7ceb; https://git.kernel.org/stable/c/a35faec3db0e13aac8ea720bc1a3503081dd5a3d; https://git.kernel.org/stable/c/b0808b7a04157b3f56e919f27023fec37a075fad
CVE: CVE-2022-49366
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix reference count leak in smb_check_perm_dacl()

The issue happens in a specific path in smb_check_perm_dacl(). When
"id" and "uid" have the same value, the function simply jumps out of
the loop without decrementing the reference count of the object
"posix_acls", which is increased by get_acl() earlier. This may
result in memory leaks.

Fix it by decreasing the reference count of "posix_acls" before
jumping to label "check_access_bits".
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/248d71b440aef829f5cc5f6545ca113ef5062900; https://git.kernel.org/stable/c/9758a6653c27867d810de02b4e5697163dda9883; https://git.kernel.org/stable/c/cf824b95c12a1abacadbc2d[PII_REDACTED]21a3414
CVE: CVE-2022-49367
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

net: dsa: mv88e6xxx: Fix refcount leak in mv88e6xxx_mdios_register

of_get_child_by_name() returns a node pointer with refcount
incremented, we should use of_node_put() on it when done.

mv88e6xxx_mdio_register() pass the device node to of_mdiobus_register().
We don't need the device node after it.

Add missing of_node_put() to avoid refcount leak.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/02ded5a173619b11728b8bf75a3fd995a2c1ff28; https://git.kernel.org/stable/c/42658e47f1abbbe592007d3ba303de466114d0bb; https://git.kernel.org/stable/c/86c3c5f8e4bd1325e24f6fba9017cade29933377
CVE: CVE-2022-49368
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

net: ethernet: mtk_eth_soc: out of bounds read in mtk_hwlro_get_fdir_entry()

The "fsp->location" variable comes from user via ethtool_get_rxnfc().
Check that it is valid to prevent an out of bounds read.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125, CWE-125
References: https://git.kernel.org/stable/c/0b238f75b65ed4462ef4cdfa718cac0ac7fce3b8; https://git.kernel.org/stable/c/2bd1faedb74dc2a2be3972abcd4239b75a3e7b00; https://git.kernel.org/stable/c/4cde554c70d7397cfa2e4116bacb4accdfb6fd48
CVE: CVE-2022-49369
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

amt: fix possible memory leak in amt_rcv()

If an amt receives packets and it finds socket.
If it can't find a socket, it should free a received skb.
But it doesn't.
So, a memory leak would possibly occur.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/1a1a0e80e005cbdc2c250fc858e1d8570f4e4acb; https://git.kernel.org/stable/c/4b8032d39b276c52db57ff834c300405b9da2691; https://git.kernel.org/stable/c/60d9c020c69977e138727b3577bc6a0458325e9c
CVE: CVE-2022-49370
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

firmware: dmi-sysfs: Fix memory leak in dmi_sysfs_register_handle

kobject_init_and_add() takes reference even when it fails.
According to the doc of kobject_init_and_add()

   If this function returns an error, kobject_put() must be called to
   properly clean up the memory associated with the object.

Fix this issue by calling kobject_put().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/3ba359ebe914ac3f8c6c832b28007c14c39d3766; https://git.kernel.org/stable/c/660ba678f9998aca6db74f2dd912fa5124f0fa31; https://git.kernel.org/stable/c/985706bd3bbeffc8737bc05965ca8d24837bc7db
CVE: CVE-2022-49371
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

driver core: fix deadlock in __device_attach

In __device_attach function, The lock holding logic is as follows:
...
__device_attach
device_lock(dev)      // get lock dev
  async_schedule_dev(__device_attach_async_helper, dev); // func
    async_schedule_node
      async_schedule_node_domain(func)
        entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC);
	/* when fail or work limit, sync to execute func, but
	   __device_attach_async_helper will get lock dev as
	   well, which will lead to A-A deadlock.  */
	if (!entry || atomic_read(&entry_count) > MAX_WORK) {
	  func;
	else
	  queue_work_node(node, system_unbound_wq, &entry->work)
  device_unlock(dev)

As shown above, when it is allowed to do async probes, because of
out of memory or work limit, async work is not allowed, to do
sync execute instead. it will lead to A-A deadlock because of
__device_attach_async_helper getting lock dev.

To fix the deadlock, move the async_schedule_dev outside device_lock,
as we can see, in async_schedule_node_domain, the parameter of
queue_work_node is system_unbound_wq, so it can accept concurrent
operations. which will also not change the code logic, and will
not lead to deadlock.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667, CWE-667
References: https://git.kernel.org/stable/c/34fdd9b7def9d2fcb71bb7b0bc4848dd7313767e; https://git.kernel.org/stable/c/36ee9ffca8ef56c302f2855c4a5fccf61c0c1ada; https://git.kernel.org/stable/c/593b595332bd2d65e1a5c1ae7897996c157f5468
CVE: CVE-2022-49372
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

tcp: tcp_rtx_synack() can be called from process context

Laurent reported the enclosed report [1]

This bug triggers with following coditions:

0) Kernel built with CONFIG_DEBUG_PREEMPT=y

1) A new passive FastOpen TCP socket is created.
   This FO socket waits for an ACK coming from client to be a complete
   ESTABLISHED one.
2) A socket operation on this socket goes through lock_sock()
   release_sock() dance.
3) While the socket is owned by the user in step 2),
   a retransmit of the SYN is received and stored in socket backlog.
4) At release_sock() time, the socket backlog is processed while
   in process context.
5) A SYNACK packet is cooked in response of the SYN retransmit.
6) -> tcp_rtx_synack() is called in process context.

Before blamed commit, tcp_rtx_synack() was always called from BH handler,
from a timer handler.

Fix this by using TCP_INC_STATS() & NET_INC_STATS()
which do not assume caller is in non preemptible context.

[1]
BUG: using __this_cpu_add() in preemptible [00000000] code: epollpep/2180
caller is tcp_rtx_synack.part.0+0x36/0xc0
CPU: 10 PID: 2180 Comm: epollpep Tainted: G           OE     5.16.0-0.bpo.4-amd64 #1  Debian 5.16.12-1~bpo11+1
Hardware name: Supermicro SYS-5039MC-H8TRF/X11SCD-F, BIOS 1.7 11/23/2021
Call Trace:
 <TASK>
 dump_stack_lvl+0x48/0x5e
 check_preemption_disabled+0xde/0xe0
 tcp_rtx_synack.part.0+0x36/0xc0
 tcp_rtx_synack+0x8d/0xa0
 ? kmem_cache_alloc+0x2e0/0x3e0
 ? apparmor_file_alloc_security+0x3b/0x1f0
 inet_rtx_syn_ack+0x16/0x30
 tcp_check_req+0x367/0x610
 tcp_rcv_state_process+0x91/0xf60
 ? get_nohz_timer_target+0x18/0x1a0
 ? lock_timer_base+0x61/0x80
 ? preempt_count_add+0x68/0xa0
 tcp_v4_do_rcv+0xbd/0x270
 __release_sock+0x6d/0xb0
 release_sock+0x2b/0x90
 sock_setsockopt+0x138/0x1140
 ? __sys_getsockname+0x7e/0xc0
 ? aa_sk_perm+0x3e/0x1a0
 __sys_setsockopt+0x198/0x1e0
 __x64_sys_setsockopt+0x21/0x30
 do_syscall_64+0x38/0xc0
 entry_SYSCALL_64_after_hwframe+0x44/0xae
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0a0f7f84148445c9f02f226928803a870139d820; https://git.kernel.org/stable/c/0a375c822497ed6ad6b5da0792a12a6f1af10c0b; https://git.kernel.org/stable/c/3db889f883e65bbd3b1401279bfc1e9ed255c481
CVE: CVE-2022-49373
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

watchdog: ts4800_wdt: Fix refcount leak in ts4800_wdt_probe

of_parse_phandle() returns a node pointer with refcount
incremented, we should use of_node_put() on it when done.
Add  missing of_node_put() in some error paths.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/5b110d940417942bc87d9e4bea6d4f24e05ed483; https://git.kernel.org/stable/c/5d24df3d[PII_REDACTED]28e7a19a43d84bc5b99d44; https://git.kernel.org/stable/c/7a4afd8a003d6abf1f5d159c2bb67e6b7cbde253
CVE: CVE-2022-49374
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

tipc: check attribute length for bearer name

syzbot reported uninit-value:
=====================================================
BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:644 [inline]
BUG: KMSAN: uninit-value in string+0x4f9/0x6f0 lib/vsprintf.c:725
 string_nocheck lib/vsprintf.c:644 [inline]
 string+0x4f9/0x6f0 lib/vsprintf.c:725
 vsnprintf+0x2222/0x3650 lib/vsprintf.c:2806
 vprintk_store+0x537/0x2150 kernel/printk/printk.c:2158
 vprintk_emit+0x28b/0xab0 kernel/printk/printk.c:2256
 vprintk_default+0x86/0xa0 kernel/printk/printk.c:2283
 vprintk+0x15f/0x180 kernel/printk/printk_safe.c:50
 _printk+0x18d/0x1cf kernel/printk/printk.c:2293
 tipc_enable_bearer net/tipc/bearer.c:371 [inline]
 __tipc_nl_bearer_enable+0x2022/0x22a0 net/tipc/bearer.c:1033
 tipc_nl_bearer_enable+0x6c/0xb0 net/tipc/bearer.c:1042
 genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline]

- Do sanity check the attribute length for TIPC_NLA_BEARER_NAME.
- Do not use 'illegal name' in printing message.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908, CWE-908
References: https://git.kernel.org/stable/c/292be63c382ce20673ee61dff1ee9ed4a3dcaae7; https://git.kernel.org/stable/c/3af15272cde28fe5c8489174b8624e232c1775ec; https://git.kernel.org/stable/c/7f36f798f89bf32c0164049cb0e3fd1af613d0bb
CVE: CVE-2022-49375
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

rtc: mt6397: check return value after calling platform_get_resource()

It will cause null-ptr-deref if platform_get_resource() returns NULL,
we need check the return value.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/3867f0bbb94773d41e789257abec0d14f37da217; https://git.kernel.org/stable/c/58a729c55ce3a432eb827fdaa24c7909cd3b0a6b; https://git.kernel.org/stable/c/6ecd4d5c28408df36a1a6f0b1973f633c949ac1f
CVE: CVE-2022-49376
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: sd: Fix potential NULL pointer dereference

If sd_probe() sees an early error before sdkp->device is initialized,
sd_zbc_release_disk() is called. This causes a NULL pointer dereference
when sd_is_zoned() is called inside that function. Avoid this by removing
the call to sd_zbc_release_disk() in sd_probe() error path.

This change is safe and does not result in zone information memory leakage
because the zone information for a zoned disk is allocated only when
sd_revalidate_disk() is called, at which point sdkp->disk_dev is fully set,
resulting in sd_disk_release() being called when needed to cleanup a disk
zone information using sd_zbc_release_disk().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/05fbde3a77a4f1d62e4c4428f384288c1f1a0be5; https://git.kernel.org/stable/c/0fcb0b131cc90c8f523a293d84c58d0c7273c96f; https://git.kernel.org/stable/c/[PII_REDACTED]ad12f7b54ae35c273ea6f15d692de3
CVE: CVE-2022-49377
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

blk-mq: don't touch ->tagset in blk_mq_get_sq_hctx

blk_mq_run_hw_queues() could be run when there isn't queued request and
after queue is cleaned up, at that time tagset is freed, because tagset
lifetime is covered by driver, and often freed after blk_cleanup_queue()
returns.

So don't touch ->tagset for figuring out current default hctx by the mapping
built in request queue, so use-after-free on tagset can be avoided. Meantime
this way should be fast than retrieving mapping from tagset.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/460aa288c5cd0544dcf933a2f0ad0e8c6d2d35ff; https://git.kernel.org/stable/c/5d05426e2d5fd7df8afc866b78c36b37b00188b7; https://git.kernel.org/stable/c/70fdd922c7bf8949f8df109cf2635dff64c90392
CVE: CVE-2022-49378
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

sfc: fix considering that all channels have TX queues

Normally, all channels have RX and TX queues, but this is not true if
modparam efx_separate_tx_channels=1 is used. In that cases, some
channels only have RX queues and others only TX queues (or more
preciselly, they have them allocated, but not initialized).

Fix efx_channel_has_tx_queues to return the correct value for this case
too.

Messages shown at probe time before the fix:
 sfc 0000:03:00.0 ens6f0np0: MC command 0x82 inlen 544 failed rc=-22 (raw=0) arg=0
 ------------[ cut here ]------------
 netdevice: ens6f0np0: failed to initialise TXQ -1
 WARNING: CPU: 1 PID: 626 at drivers/net/ethernet/sfc/ef10.c:2393 efx_ef10_tx_init+0x201/0x300 [sfc]
 [...] stripped
 RIP: 0010:efx_ef10_tx_init+0x201/0x300 [sfc]
 [...] stripped
 Call Trace:
  efx_init_tx_queue+0xaa/0xf0 [sfc]
  efx_start_channels+0x49/0x120 [sfc]
  efx_start_all+0x1f8/0x430 [sfc]
  efx_net_open+0x5a/0xe0 [sfc]
  __dev_open+0xd0/0x190
  __dev_change_flags+0x1b3/0x220
  dev_change_flags+0x21/0x60
 [...] stripped

Messages shown at remove time before the fix:
 sfc 0000:03:00.0 ens6f0np0: failed to flush 10 queues
 sfc 0000:03:00.0 ens6f0np0: failed to flush queues
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2e102b53f8a778f872dc137f4c7ac548705817aa; https://git.kernel.org/stable/c/5567d69b95b9c07e1c56f15cf0301251d12e5f97; https://git.kernel.org/stable/c/8f81a4113e1e574d2cbde4f2cd599380a9189c0f
CVE: CVE-2022-49379
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

driver core: Fix wait_for_device_probe() & deferred_probe_timeout interaction

Mounting NFS rootfs was timing out when deferred_probe_timeout was
non-zero [1].  This was because ip_auto_config() initcall times out
waiting for the network interfaces to show up when
deferred_probe_timeout was non-zero. While ip_auto_config() calls
wait_for_device_probe() to make sure any currently running deferred
probe work or asynchronous probe finishes, that wasn't sufficient to
account for devices being deferred until deferred_probe_timeout.

Commit 35a672363ab3 ("driver core: Ensure wait_for_device_probe() waits
until the deferred_probe_timeout fires") tried to fix that by making
sure wait_for_device_probe() waits for deferred_probe_timeout to expire
before returning.

However, if wait_for_device_probe() is called from the kernel_init()
context:

- Before deferred_probe_initcall() [2], it causes the boot process to
  hang due to a deadlock.

- After deferred_probe_initcall() [3], it blocks kernel_init() from
  continuing till deferred_probe_timeout expires and beats the point of
  deferred_probe_timeout that's trying to wait for userspace to load
  modules.

Neither of this is good. So revert the changes to
wait_for_device_probe().

[1] - https://lore.kernel.org/lkml/TYAPR01MB45443DF63B9EF29054F7C41FD8C60@TYAPR01MB4544.jpnprd01.prod.outlook.com/
[2] - https://lore.kernel.org/lkml/YowHNo4sBjr9ijZr@dev-arch.thelio-3990X/
[3] - https://lore.kernel.org/lkml/Yo3WvGnNk3LvLb7R@linutronix.de/
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/29357883a89193863f3cc6a2c5e0b42ceb022761; https://git.kernel.org/stable/c/4ad6af07efcca85369c21e4897b3020cff2c170b; https://git.kernel.org/stable/c/528229474e1cbb1b3451cb713d94aecb5f6ee264