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

RDMA/irdma: Fix data race on CQP completion stats

CQP completion statistics is read lockesly in irdma_wait_event and
irdma_check_cqp_progress while it can be updated in the completion
thread irdma_sc_ccq_get_cqe_info on another CPU as KCSAN reports.

Make completion statistics an atomic variable to reflect coherent updates
to it. This will also avoid load/store tearing logic bug potentially
possible by compiler optimizations.

[77346.170861] BUG: KCSAN: data-race in irdma_handle_cqp_op [irdma] / irdma_sc_ccq_get_cqe_info [irdma]

[77346.171383] write to 0xffff8a3250b108e0 of 8 bytes by task 9544 on cpu 4:
[77346.171483]  irdma_sc_ccq_get_cqe_info+0x27a/0x370 [irdma]
[77346.171658]  irdma_cqp_ce_handler+0x164/0x270 [irdma]
[77346.171835]  cqp_compl_worker+0x1b/0x20 [irdma]
[77346.172009]  process_one_work+0x4d1/0xa40
[77346.172024]  worker_thread+0x319/0x700
[77346.172037]  kthread+0x180/0x1b0
[77346.172054]  ret_from_fork+0x22/0x30

[77346.172136] read to 0xffff8a3250b108e0 of 8 bytes by task 9838 on cpu 2:
[77346.172234]  irdma_handle_cqp_op+0xf4/0x4b0 [irdma]
[77346.172413]  irdma_cqp_aeq_cmd+0x75/0xa0 [irdma]
[77346.172592]  irdma_create_aeq+0x390/0x45a [irdma]
[77346.172769]  irdma_rt_init_hw.cold+0x212/0x85d [irdma]
[77346.172944]  irdma_probe+0x54f/0x620 [irdma]
[77346.173122]  auxiliary_bus_probe+0x66/0xa0
[77346.173137]  really_probe+0x140/0x540
[77346.173154]  __driver_probe_device+0xc7/0x220
[77346.173173]  driver_probe_device+0x5f/0x140
[77346.173190]  __driver_attach+0xf0/0x2c0
[77346.173208]  bus_for_each_dev+0xa8/0xf0
[77346.173225]  driver_attach+0x29/0x30
[77346.173240]  bus_add_driver+0x29c/0x2f0
[77346.173255]  driver_register+0x10f/0x1a0
[77346.173272]  __auxiliary_driver_register+0xbc/0x140
[77346.173287]  irdma_init_module+0x55/0x1000 [irdma]
[77346.173460]  do_one_initcall+0x7d/0x410
[77346.173475]  do_init_module+0x81/0x2c0
[77346.173491]  load_module+0x1232/0x12c0
[77346.173506]  __do_sys_finit_module+0x101/0x180
[77346.173522]  __x64_sys_finit_module+0x3c/0x50
[77346.173538]  do_syscall_64+0x39/0x90
[77346.173553]  entry_SYSCALL_64_after_hwframe+0x63/0xcd

[77346.173634] value changed: 0x[PII_REDACTED]000094 -> 0x[PII_REDACTED]000095
References: https://git.kernel.org/stable/c/2623ca92cd8f9668edabe9e4f4a3cf77fd7115f2; https://git.kernel.org/stable/c/4e1a5842a359ee18d5a9e75097d7cf4d93e233bb; https://git.kernel.org/stable/c/bf0f9f65b7fe36ea9d2e23263dcefc90255d7b1f
CVE: CVE-2023-54303
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Disable preemption in bpf_perf_event_output

The nesting protection in bpf_perf_event_output relies on disabled
preemption, which is guaranteed for kprobes and tracepoints.

However bpf_perf_event_output can be also called from uprobes context
through bpf_prog_run_array_sleepable function which disables migration,
but keeps preemption enabled.

This can cause task to be preempted by another one inside the nesting
protection and lead eventually to two tasks using same perf_sample_data
buffer and cause crashes like:

  kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
  BUG: unable to handle page fault for address: ffffffff82be3eea
  ...
  Call Trace:
   ? __die+0x1f/0x70
   ? page_fault_oops+0x176/0x4d0
   ? exc_page_fault+0x132/0x230
   ? asm_exc_page_fault+0x22/0x30
   ? perf_output_sample+0x12b/0x910
   ? perf_event_output+0xd0/0x1d0
   ? bpf_perf_event_output+0x162/0x1d0
   ? bpf_prog_c6271286d9a4c938_krava1+0x76/0x87
   ? __uprobe_perf_func+0x12b/0x540
   ? uprobe_dispatcher+0x2c4/0x430
   ? uprobe_notify_resume+0x2da/0xce0
   ? atomic_notifier_call_chain+0x7b/0x110
   ? exit_to_user_mode_prepare+0x13e/0x290
   ? irqentry_exit_to_user_mode+0x5/0x30
   ? asm_exc_int3+0x35/0x40

Fixing this by disabling preemption in bpf_perf_event_output.
References: https://git.kernel.org/stable/c/3654ed5daf492463c3faa434c7000d45c2da2ace; https://git.kernel.org/stable/c/a0ac32cf61e5a76e2429e486925a52ee41dd75e3; https://git.kernel.org/stable/c/f2c67a3e60d1071b65848efaa8c3b66c363dd025
CVE: CVE-2023-54304
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

firmware: meson_sm: fix to avoid potential NULL pointer dereference

of_match_device() may fail and returns a NULL pointer.

Fix this by checking the return value of of_match_device.
References: https://git.kernel.org/stable/c/2d6c4a1a4e6678cb98dd57964f133a995ecc91c1; https://git.kernel.org/stable/c/502dfc5875bab9ae5d6a2939146c2c5e5683be40; https://git.kernel.org/stable/c/68f3209546b5083f8bffa46f7173cc05191eace1
CVE: CVE-2023-54305
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: refuse to create ea block when umounted

The ea block expansion need to access s_root while it is
already set as NULL when umount is triggered. Refuse this
request to avoid panic.
References: https://git.kernel.org/stable/c/05cbf6ddd9847c7b4f0662c048f195b09405a9d0; https://git.kernel.org/stable/c/0dc0fa313bb4e86382a3e[PII_REDACTED]d44383196; https://git.kernel.org/stable/c/116008ada3d0de4991099edaf6b8c2e9cd6f225a
CVE: CVE-2023-54306
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

net: tls: avoid hanging tasks on the tx_lock

syzbot sent a hung task report and Eric explains that adversarial
receiver may keep RWIN at 0 for a long time, so we are not guaranteed
to make forward progress. Thread which took tx_lock and went to sleep
may not release tx_lock for hours. Use interruptible sleep where
possible and reschedule the work if it can't take the lock.

Testing: existing selftest passes
References: https://git.kernel.org/stable/c/1f800f6aae57d2d8f63d32fff383017cbc11cf65; https://git.kernel.org/stable/c/7123a4337bf73132bbfb5437e4dc83ba864a9a1e; https://git.kernel.org/stable/c/bde541a57b4204d0a800afbbd3d1c06c9cdb133f
CVE: CVE-2023-54307
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

ptp_qoriq: fix memory leak in probe()

Smatch complains that:
drivers/ptp/ptp_qoriq.c ptp_qoriq_probe()
warn: 'base' from ioremap() not released.

Fix this by revising the parameter from 'ptp_qoriq->base' to 'base'.
This is only a bug if ptp_qoriq_init() returns on the
first -ENODEV error path.
For other error paths ptp_qoriq->base and base are the same.
And this change makes the code more readable.
References: https://git.kernel.org/stable/c/3907fcb5a439933cf8c10d6dc300bc11eba30de3; https://git.kernel.org/stable/c/43b4331ce0cd88ccba425e0702ba35c1a52daccf; https://git.kernel.org/stable/c/46c4993a1514eea3bbc7147d0c81c23cc06c6bed
CVE: CVE-2023-54309
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

tpm: tpm_vtpm_proxy: fix a race condition in /dev/vtpmx creation

/dev/vtpmx is made visible before 'workqueue' is initialized, which can
lead to a memory corruption in the worst case scenario.

Address this by initializing 'workqueue' as the very first step of the
driver initialization.
References: https://git.kernel.org/stable/c/04e8697d26613ccea760cf57eb20a5a27f788c0f; https://git.kernel.org/stable/c/092db954e2c3c5ba6c0ce990c7da72cf8f3b9c51; https://git.kernel.org/stable/c/509d21f1c4bb9d35d397fca3226165b156a7639f
CVE: CVE-2023-54310
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: message: mptlan: Fix use after free bug in mptlan_remove() due to race condition

mptlan_probe() calls mpt_register_lan_device() which initializes the
&priv->post_buckets_task workqueue. A call to
mpt_lan_wake_post_buckets_task() will subsequently start the work.

During driver unload in mptlan_remove() the following race may occur:

CPU0                  CPU1

                    |mpt_lan_post_receive_buckets_work()
mptlan_remove()     |
  free_netdev()     |
    kfree(dev);     |
                    |
                    | dev->mtu
                    |   //use

Fix this by finishing the work prior to cleaning up in mptlan_remove().

[mkp: we really should remove mptlan instead of attempting to fix it]
References: https://git.kernel.org/stable/c/410e610a96c52a7b41e2ab6c9ca60868d9acecce; https://git.kernel.org/stable/c/48daa4a3015d859ee424948844ce3c12f2fe44e6; https://git.kernel.org/stable/c/60c8645ad6f5b722615383d595d63b62b07a13c3
CVE: CVE-2023-54311
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: fix deadlock when converting an inline directory in nojournal mode

In no journal mode, ext4_finish_convert_inline_dir() can self-deadlock
by calling ext4_handle_dirty_dirblock() when it already has taken the
directory lock.  There is a similar self-deadlock in
ext4_incvert_inline_data_nolock() for data files which we'll fix at
the same time.

A simple reproducer demonstrating the problem:

    mke2fs -Fq -t ext2 -O inline_data -b 4k /dev/vdc 64
    mount -t ext4 -o dirsync /dev/vdc /vdc
    cd /vdc
    mkdir file0
    cd file0
    touch file0
    touch file1
    attr -s BurnSpaceInEA -V abcde .
    touch supercalifragilisticexpialidocious
References: https://git.kernel.org/stable/c/0b1c4357bb21d9770451a1bdb8d419ea10bada88; https://git.kernel.org/stable/c/5f8b55136ad787aed2c184f7cb3e93772ae637a3; https://git.kernel.org/stable/c/640c8c365999c6f23447ac766437236ad88317c5
CVE: CVE-2023-54312
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

samples/bpf: Fix buffer overflow in tcp_basertt

Using sizeof(nv) or strlen(nv)+1 is correct.
References: https://git.kernel.org/stable/c/56c25f2763a16db4fa1b486e6a21dc246cd992bd; https://git.kernel.org/stable/c/7c08d1b0d1f75117cf82aeaef49ba9f861b3fb59; https://git.kernel.org/stable/c/bd3e880dce27d225598730d2bbb3dc05b443af22
CVE: CVE-2023-54313
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

ovl: fix null pointer dereference in ovl_get_acl_rcu()

Following process:
         P1                     P2
 path_openat
  link_path_walk
   may_lookup
    inode_permission(rcu)
     ovl_permission
      acl_permission_check
       check_acl
        get_cached_acl_rcu
	 ovl_get_inode_acl
	  realinode = ovl_inode_real(ovl_inode)
	                      drop_cache
		               __dentry_kill(ovl_dentry)
				iput(ovl_inode)
		                 ovl_destroy_inode(ovl_inode)
		                  dput(oi->__upperdentry)
		                   dentry_kill(upperdentry)
		                    dentry_unlink_inode
				     upperdentry->d_inode = NULL
	    ovl_inode_upper
	     upperdentry = ovl_i_dentry_upper(ovl_inode)
	     d_inode(upperdentry) // returns NULL
	  IS_POSIXACL(realinode) // NULL pointer dereference
, will trigger an null pointer dereference at realinode:
  [  205.472797] BUG: kernel NULL pointer dereference, address:
                 [PII_REDACTED]
  [  205.476701] CPU: 2 PID: 2713 Comm: ls Not tainted
                 6.3.0-12064-g2edfa098e750-dirty #1216
  [  205.478754] RIP: 0010:do_ovl_get_acl+0x5d/0x300
  [  205.489584] Call Trace:
  [  205.489812]  <TASK>
  [  205.490014]  ovl_get_inode_acl+0x26/0x30
  [  205.490466]  get_cached_acl_rcu+0x61/0xa0
  [  205.490908]  generic_permission+0x1bf/0x4e0
  [  205.491447]  ovl_permission+0x79/0x1b0
  [  205.491917]  inode_permission+0x15e/0x2c0
  [  205.492425]  link_path_walk+0x115/0x550
  [  205.493311]  path_lookupat.isra.0+0xb2/0x200
  [  205.493803]  filename_lookup+0xda/0x240
  [  205.495747]  vfs_fstatat+0x7b/0xb0

Fetch a reproducer in [Link].

Use the helper ovl_i_path_realinode() to get realinode and then do
non-nullptr checking.
References: https://git.kernel.org/stable/c/c4a5fb1ae5d3f02d3227afde2b[PII_REDACTED]463d; https://git.kernel.org/stable/c/d536af163c53ce9f9bcfe87d2e9946f06f1a7ea4; https://git.kernel.org/stable/c/d97481c7b2739a704848bb3c01f224dc71bdf78e
CVE: CVE-2023-54314
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

media: af9005: Fix null-ptr-deref in af9005_i2c_xfer

In af9005_i2c_xfer, msg is controlled by user. When msg[i].buf
is null and msg[i].len is zero, former checks on msg[i].buf would be
passed. Malicious data finally reach af9005_i2c_xfer. If accessing
msg[i].buf[0] without sanity check, null ptr deref would happen.
We add check on msg[i].len to prevent crash.

Similar commit:
commit 0ed554fd769a
("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")
References: https://git.kernel.org/stable/c/033b0c0780adee32dde218179e9bc51d2525108f; https://git.kernel.org/stable/c/0c02eb70b1dd4ae9bb304ce6cdadbc6faba2b2e9; https://git.kernel.org/stable/c/63d962ac7a52c0ff4cd09af2e284dce5e5955dfe
CVE: CVE-2023-54315
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

powerpc/powernv/sriov: perform null check on iov before dereferencing iov

Currently pointer iov is being dereferenced before the null check of iov
which can lead to null pointer dereference errors. Fix this by moving the
iov null check before the dereferencing.

Detected using cppcheck static analysis:
linux/arch/powerpc/platforms/powernv/pci-sriov.c:597:12: warning: Either
the condition '!iov' is redundant or there is possible null pointer
dereference: iov. [nullPointerRedundantCheck]
 num_vfs = iov->num_vfs;
           ^
References: https://git.kernel.org/stable/c/07c19c0ad4b07f4b598da369714de028f6a6a323; https://git.kernel.org/stable/c/6314465b88072a6b6f3b3c12a7898abe09095f95; https://git.kernel.org/stable/c/72990144e17e5e2cb378f1d9b10530b85b9bc382
CVE: CVE-2023-54316
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

refscale: Fix uninitalized use of wait_queue_head_t

Running the refscale test occasionally crashes the kernel with the
following error:

[ 8569.952896] BUG: unable to handle page fault for address: ffffffffffffffe8
[ 8569.952900] #PF: supervisor read access in kernel mode
[ 8569.952902] #PF: error_code(0x0000) - not-present page
[ 8569.952904] PGD c4b048067 P4D c4b049067 PUD c4b04b067 PMD 0
[ 8569.952910] Oops: 0000 [#1] PREEMPT_RT SMP NOPTI
[ 8569.952916] Hardware name: Dell Inc. PowerEdge R750/0WMWCR, BIOS 1.2.4 05/28/2021
[ 8569.952917] RIP: 0010:prepare_to_wait_event+0x101/0x190
  :
[ 8569.952940] Call Trace:
[ 8569.952941]  <TASK>
[ 8569.952944]  ref_scale_reader+0x380/0x4a0 [refscale]
[ 8569.952959]  kthread+0x10e/0x130
[ 8569.952966]  ret_from_fork+0x1f/0x30
[ 8569.952973]  </TASK>

The likely cause is that init_waitqueue_head() is called after the call to
the torture_create_kthread() function that creates the ref_scale_reader
kthread.  Although this init_waitqueue_head() call will very likely
complete before this kthread is created and starts running, it is
possible that the calling kthread will be delayed between the calls to
torture_create_kthread() and init_waitqueue_head().  In this case, the
new kthread will use the waitqueue head before it is properly initialized,
which is not good for the kernel's health and well-being.

The above crash happened here:

	static inline void __add_wait_queue(...)
	{
		:
		if (!(wq->flags & WQ_FLAG_PRIORITY)) <=== Crash here

The offset of flags from list_head entry in wait_queue_entry is
-0x18. If reader_tasks[i].wq.head.next is NULL as allocated reader_task
structure is zero initialized, the instruction will try to access address
0xffffffffffffffe8, which is exactly the fault address listed above.

This commit therefore invokes init_waitqueue_head() before creating
the kthread.
References: https://git.kernel.org/stable/c/066fbd8bc981cf49923bf828b7b4092894df577f; https://git.kernel.org/stable/c/70a2856fd1d0a040c876ba9e3f89b949ae92e4dd; https://git.kernel.org/stable/c/e0322a255a2242dbe4686b6176b3c83dea490529
CVE: CVE-2023-54317
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

dm flakey: don't corrupt the zero page

When we need to zero some range on a block device, the function
__blkdev_issue_zero_pages submits a write bio with the bio vector pointing
to the zero page. If we use dm-flakey with corrupt bio writes option, it
will corrupt the content of the zero page which results in crashes of
various userspace programs. Glibc assumes that memory returned by mmap is
zeroed and it uses it for calloc implementation; if the newly mapped
memory is not zeroed, calloc will return non-zeroed memory.

Fix this bug by testing if the page is equal to ZERO_PAGE(0) and
avoiding the corruption in this case.
References: https://git.kernel.org/stable/c/3c4a56ef7c538d16c1738ba0ccea9e7146105b5a; https://git.kernel.org/stable/c/63d31617883d64b43b0e2d529f0751f40713ecae; https://git.kernel.org/stable/c/98e311be44dbe31ad9c42aa067b2359bac451fda
CVE: CVE-2023-54318
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

net/smc: use smc_lgr_list.lock to protect smc_lgr_list.list iterate in smcr_port_add

While doing smcr_port_add, there maybe linkgroup add into or delete
from smc_lgr_list.list at the same time, which may result kernel crash.
So, use smc_lgr_list.lock to protect smc_lgr_list.list iterate in
smcr_port_add.

The crash calltrace show below:
BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
PGD 0 P4D 0
Oops: 0000 [#1] SMP NOPTI
CPU: 0 PID: 559726 Comm: kworker/0:92 Kdump: loaded Tainted: G
Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 449e491 04/01/2014
Workqueue: events smc_ib_port_event_work [smc]
RIP: 0010:smcr_port_add+0xa6/0xf0 [smc]
RSP: 0000:ffffa5a2c8f67de0 EFLAGS: 00010297
RAX: [PII_REDACTED] RBX: ffff9935e0650000 RCX: [PII_REDACTED]
RDX: [PII_REDACTED] RSI: ffff9935e0654290 RDI: ffff9935c8560000
RBP: [PII_REDACTED] R08: [PII_REDACTED] R09: ffff9934c0401918
R10: [PII_REDACTED] R11: ffffffffb4a5c278 R12: ffff99364029aae4
R13: ffff99364029aa00 R14: 00000000ffffffed R15: ffff99364029ab08
FS:  [PII_REDACTED](0000) GS:ffff[PII_REDACTED]00(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: [PII_REDACTED] CR3: 0000000f06a10003 CR4:[PII_REDACTED]770ef0
PKRU: 55555554
Call Trace:
 smc_ib_port_event_work+0x18f/0x380 [smc]
 process_one_work+0x19b/0x340
 worker_thread+0x30/0x370
 ? process_one_work+0x340/0x340
 kthread+0x114/0x130
 ? __kthread_cancel_work+0x50/0x50
 ret_from_fork+0x1f/0x30
References: https://git.kernel.org/stable/c/06b4934ab2b534bb92935c[PII_REDACTED]ebb9eab8; https://git.kernel.org/stable/c/70c8d17007dc4a07156b7da[PII_REDACTED]0e569b3; https://git.kernel.org/stable/c/b717463610a27fc0b58484cfead7a623d5913e61
CVE: CVE-2023-54319
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

pinctrl: at91-pio4: check return value of devm_kasprintf()

devm_kasprintf() returns a pointer to dynamically allocated memory.
Pointer could be NULL in case allocation fails. Check pointer validity.
Identified with coccinelle (kmerr.cocci script).

Depends-on: 1c4e5c470a56 ("pinctrl: at91: use devm_kasprintf() to avoid potential leaks")
Depends-on: 5a8f9cf269e8 ("pinctrl: at91-pio4: use proper format specifier for unsigned int")
References: https://git.kernel.org/stable/c/0a95dd17a73b7603818ad7c46c99d757232be331; https://git.kernel.org/stable/c/0af388fce352ed2ab383fd5d1a08db551ca15c38; https://git.kernel.org/stable/c/3e8ce1d5a1a9d758b359e5c426543957f35991f8
CVE: CVE-2023-54320
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

platform/x86/amd: pmc: Fix memory leak in amd_pmc_stb_debugfs_open_v2()

Function amd_pmc_stb_debugfs_open_v2() may be called when the STB
debug mechanism enabled.

When amd_pmc_send_cmd() fails, the 'buf' needs to be released.
References: https://git.kernel.org/stable/c/d804adef7b23b22bb82e1b3dd113e9073cea9bc1; https://git.kernel.org/stable/c/f6e7ac4c35a28aef0be93b32c533ae678ad0b9e7
CVE: CVE-2023-54321
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

driver core: fix potential null-ptr-deref in device_add()

I got the following null-ptr-deref report while doing fault injection test:

BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
CPU: 2 PID: 278 Comm: 37-i2c-ds2482 Tainted: G    B   W        N 6.1.0-rc3+
RIP: 0010:klist_put+0x2d/0xd0
Call Trace:
 <TASK>
 klist_remove+0xf1/0x1c0
 device_release_driver_internal+0x196/0x210
 bus_remove_device+0x1bd/0x240
 device_add+0xd3d/0x1100
 w1_add_master_device+0x476/0x490 [wire]
 ds2482_probe+0x303/0x3e0 [ds2482]

This is how it happened:

w1_alloc_dev()
  // The dev->driver is set to w1_master_driver.
  memcpy(&dev->dev, device, sizeof(struct device));
  device_add()
    bus_add_device()
    dpm_sysfs_add() // It fails, calls bus_remove_device.

    // error path
    bus_remove_device()
      // The dev->driver is not null, but driver is not bound.
      __device_release_driver()
        klist_remove(&dev->p->knode_driver) <-- It causes null-ptr-deref.

    // normal path
    bus_probe_device() // It's not called yet.
      device_bind_driver()

If dev->driver is set, in the error path after calling bus_add_device()
in device_add(), bus_remove_device() is called, then the device will be
detached from driver. But device_bind_driver() is not called yet, so it
causes null-ptr-deref while access the 'knode_driver'. To fix this, set
dev->driver to null in the error path before calling bus_remove_device().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/[PII_REDACTED]c5c10924e73f7ca5556e0d7378452; https://git.kernel.org/stable/c/2c59650d078b1b3f1ea50d5f8ee9fcc537dc02d3; https://git.kernel.org/stable/c/7cf515bf9e8c2908dc170ecf2df117162a16c9c5
CVE: CVE-2023-54323
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

cxl/pmem: Fix nvdimm registration races

A loop of the form:

    while true; do modprobe cxl_pci; modprobe -r cxl_pci; done

...fails with the following crash signature:

    BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
    [..]
    RIP: 0010:cxl_internal_send_cmd+0x5/0xb0 [cxl_core]
    [..]
    Call Trace:
     <TASK>
     cxl_pmem_ctl+0x121/0x240 [cxl_pmem]
     nvdimm_get_config_data+0xd6/0x1a0 [libnvdimm]
     nd_label_data_init+0x135/0x7e0 [libnvdimm]
     nvdimm_probe+0xd6/0x1c0 [libnvdimm]
     nvdimm_bus_probe+0x7a/0x1e0 [libnvdimm]
     really_probe+0xde/0x380
     __driver_probe_device+0x78/0x170
     driver_probe_device+0x1f/0x90
     __device_attach_driver+0x85/0x110
     bus_for_each_drv+0x7d/0xc0
     __device_attach+0xb4/0x1e0
     bus_probe_device+0x9f/0xc0
     device_add+0x445/0x9c0
     nd_async_device_register+0xe/0x40 [libnvdimm]
     async_run_entry_fn+0x30/0x130

...namely that the bottom half of async nvdimm device registration runs
after the CXL has already torn down the context that cxl_pmem_ctl()
needs. Unlike the ACPI NFIT case that benefits from launching multiple
nvdimm device registrations in parallel from those listed in the table,
CXL is already marked PROBE_PREFER_ASYNCHRONOUS. So provide for a
synchronous registration path to preclude this scenario.
References: https://git.kernel.org/stable/c/18c65667fa9104780eeaa0dc1bc240f0c2094772; https://git.kernel.org/stable/c/a371788d4f4a7f59eecd22644331d599979fd283; https://git.kernel.org/stable/c/f57aec443c24d2e8e1f3b5b4856aea12ddda4254