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

exfat: use kvmalloc_array/kvfree instead of kmalloc_array/kfree

The call stack shown below is a scenario in the Linux 4.19 kernel.
Allocating memory failed where exfat fs use kmalloc_array due to
system memory fragmentation, while the u-disk was inserted without
recognition.
Devices such as u-disk using the exfat file system are pluggable and
may be insert into the system at any time.
However, long-term running systems cannot guarantee the continuity of
physical memory. Therefore, it's necessary to address this issue.

Binder:2632_6: page allocation failure: order:4,
 mode:0x6040c0(GFP_KERNEL|__GFP_COMP), nodemask=(null)
Call trace:
[[PII_REDACTED]82]  dump_backtrace+0x0/0x4
[[PII_REDACTED]89]  dump_stack+0xf4/0x134
[[PII_REDACTED]98]  warn_alloc+0xd8/0x144
[[PII_REDACTED]03]  __alloc_pages_nodemask+0x1364/0x1384
[[PII_REDACTED]08]  kmalloc_order+0x2c/0x510
[[PII_REDACTED]12]  kmalloc_order_trace+0x40/0x16c
[[PII_REDACTED]18]  __kmalloc+0x360/0x408
[[PII_REDACTED]24]  load_alloc_bitmap+0x160/0x284
[[PII_REDACTED]28]  exfat_fill_super+0xa3c/0xe7c
[[PII_REDACTED]35]  mount_bdev+0x2e8/0x3a0
[[PII_REDACTED]38]  exfat_fs_mount+0x40/0x50
[[PII_REDACTED]43]  mount_fs+0x138/0x2e8
[[PII_REDACTED]49]  vfs_kern_mount+0x90/0x270
[[PII_REDACTED]55]  do_mount+0x798/0x173c
[[PII_REDACTED]59]  ksys_mount+0x114/0x1ac
[[PII_REDACTED]65]  __arm64_sys_mount+0x24/0x34
[[PII_REDACTED]71]  el0_svc_common+0xb8/0x1b8
[[PII_REDACTED]76]  el0_svc_handler+0x74/0x90
[[PII_REDACTED]81]  el0_svc+0x8/0x340

By analyzing the exfat code,we found that continuous physical memory
is not required here,so kvmalloc_array is used can solve this problem.
References: https://git.kernel.org/stable/c/0c5c3e8a2550b6b2a304b45f260296db9c09df96; https://git.kernel.org/stable/c/1427a7e96fb90d0896f74f5bcd21feb03cc7c3d0; https://git.kernel.org/stable/c/79d16a84ea41272dfcb0c00f9798ddd0edd8098d
CVE: CVE-2023-54195
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

rxrpc: Fix timeout of a call that hasn't yet been granted a channel

afs_make_call() calls rxrpc_kernel_begin_call() to begin a call (which may
get stalled in the background waiting for a connection to become
available); it then calls rxrpc_kernel_set_max_life() to set the timeouts -
but that starts the call timer so the call timer might then expire before
we get a connection assigned - leading to the following oops if the call
stalled:

	BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
	...
	CPU: 1 PID: 5111 Comm: krxrpcio/0 Not tainted 6.3.0-rc7-build3+ #701
	RIP: 0010:rxrpc_alloc_txbuf+0xc0/0x157
	...
	Call Trace:
	 <TASK>
	 rxrpc_send_ACK+0x50/0x13b
	 rxrpc_input_call_event+0x16a/0x67d
	 rxrpc_io_thread+0x1b6/0x45f
	 ? _raw_spin_unlock_irqrestore+0x1f/0x35
	 ? rxrpc_input_packet+0x519/0x519
	 kthread+0xe7/0xef
	 ? kthread_complete_and_exit+0x1b/0x1b
	 ret_from_fork+0x22/0x30

Fix this by noting the timeouts in struct rxrpc_call when the call is
created.  The timer will be started when the first packet is transmitted.

It shouldn't be possible to trigger this directly from userspace through
AF_RXRPC as sendmsg() will return EBUSY if the call is in the
waiting-for-conn state if it dropped out of the wait due to a signal.
References: https://git.kernel.org/stable/c/72f4a9f3f447948cf86dffe1c4a4c8a429ab9666; https://git.kernel.org/stable/c/92128a7170a220b5126d09a1c1954a3a8d46cef3; https://git.kernel.org/stable/c/db099c625b13a74d462521a46d98a8ce5b53af5d
CVE: CVE-2023-54197
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

Revert "Bluetooth: btsdio: fix use after free bug in btsdio_remove due to unfinished work"

This reverts commit 1e9ac114c4428fdb7ff4635b45d4f46017e8916f.

This patch introduces a possible null-ptr-def problem. Revert it. And the
fixed bug by this patch have resolved by commit 73f7b171b7c0 ("Bluetooth:
btsdio: fix use after free bug in btsdio_remove due to race condition").
References: https://git.kernel.org/stable/c/0837d10f6c37a47a0c73bccf1e39513613a2fcc2; https://git.kernel.org/stable/c/3b4ed52009723f7dfca7a8ca95163bfb441bfb76; https://git.kernel.org/stable/c/70a104588e3131415e559c06deb834ce259a285a
CVE: CVE-2023-54198
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

tty: fix out-of-bounds access in tty_driver_lookup_tty()

When specifying an invalid console= device like console=tty3270,
tty_driver_lookup_tty() returns the tty struct without checking
whether index is a valid number.

To reproduce:

qemu-system-x86_64 -enable-kvm -nographic -serial mon:stdio \
-kernel ../linux-build-x86/arch/x86/boot/bzImage \
-append "console=ttyS0 console=tty3270"

This crashes with:

[    0.770599] BUG: kernel NULL pointer dereference, address:[PII_REDACTED]0000ef
[    0.771265] #PF: supervisor read access in kernel mode
[    0.771773] #PF: error_code(0x0000) - not-present page
[    0.772609] Oops: 0000 [#1] PREEMPT SMP PTI
[    0.774878] RIP: 0010:tty_open+0x268/0x6f0
[    0.784013]  chrdev_open+0xbd/0x230
[    0.784444]  ? cdev_device_add+0x80/0x80
[    0.784920]  do_dentry_open+0x1e0/0x410
[    0.785389]  path_openat+0xca9/0x1050
[    0.785813]  do_filp_open+0xaa/0x150
[    0.786240]  file_open_name+0x133/0x1b0
[    0.786746]  filp_open+0x27/0x50
[    0.787244]  console_on_rootfs+0x14/0x4d
[    0.787800]  kernel_init_freeable+0x1e4/0x20d
[    0.788383]  ? rest_init+0xc0/0xc0
[    0.788881]  kernel_init+0x11/0x120
[    0.789356]  ret_from_fork+0x22/0x30
References: https://git.kernel.org/stable/c/3df6f492f500a16c231f07ccc6f6ed1302caddf9; https://git.kernel.org/stable/c/765566110eb0da3cf60198b0165ecceeaafa6444; https://git.kernel.org/stable/c/84ea44dc3e4ecb[PII_REDACTED]014bf6722aa5843b
CVE: CVE-2023-54199
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/msm/adreno: Fix null ptr access in adreno_gpu_cleanup()

Fix the below kernel panic due to null pointer access:
[   18.504431] Unable to handle kernel NULL pointer dereference at virtual address [PII_REDACTED]
[   18.513464] Mem abort info:
[   18.516346]   ESR = 0x[PII_REDACTED]000005
[   18.520204]   EC = 0x25: DABT (current EL), IL = 32 bits
[   18.525706]   SET = 0, FnV = 0
[   18.528878]   EA = 0, S1PTW = 0
[   18.532117]   FSC = 0x05: level 1 translation fault
[   18.537138] Data abort info:
[   18.540110]   ISV = 0, ISS = 0x00000005
[   18.544060]   CM = 0, WnR = 0
[   18.547109] user pgtable: 4k pages, 39-bit VAs, pgdp=[PII_REDACTED]
[   18.553738] [[PII_REDACTED]] pgd=[PII_REDACTED], p4d=[PII_REDACTED], pud=[PII_REDACTED]
[   18.562690] Internal error: Oops: [PII_REDACTED] [#1] PREEMPT SMP
**Snip**
[   18.696758] Call trace:
[   18.699278]  adreno_gpu_cleanup+0x30/0x88
[   18.703396]  a6xx_destroy+0xc0/0x130
[   18.707066]  a6xx_gpu_init+0x308/0x424
[   18.710921]  adreno_bind+0x178/0x288
[   18.714590]  component_bind_all+0xe0/0x214
[   18.718797]  msm_drm_bind+0x1d4/0x614
[   18.722566]  try_to_bring_up_aggregate_device+0x16c/0x1b8
[   18.728105]  __component_add+0xa0/0x158
[   18.732048]  component_add+0x20/0x2c
[   18.735719]  adreno_probe+0x40/0xc0
[   18.739300]  platform_probe+0xb4/0xd4
[   18.743068]  really_probe+0xfc/0x284
[   18.746738]  __driver_probe_device+0xc0/0xec
[   18.751129]  driver_probe_device+0x48/0x110
[   18.755421]  __device_attach_driver+0xa8/0xd0
[   18.759900]  bus_for_each_drv+0x90/0xdc
[   18.763843]  __device_attach+0xfc/0x174
[   18.767786]  device_initial_probe+0x20/0x2c
[   18.772090]  bus_probe_device+0x40/0xa0
[   18.776032]  deferred_probe_work_func+0x94/0xd0
[   18.780686]  process_one_work+0x190/0x3d0
[   18.784805]  worker_thread+0x280/0x3d4
[   18.788659]  kthread+0x104/0x1c0
[   18.791981]  ret_from_fork+0x10/0x20
[   18.795654] Code: f9400408 aa0003f3 aa1f03f4 91142015 (f9402516)
[   18.801913] ---[ end trace [PII_REDACTED] ]---
[   18.809039] Kernel panic - not syncing: Oops: Fatal exception

Patchwork: https://patchwork.freedesktop.org/patch/515605/
References: https://git.kernel.org/stable/c/399d01375659c273fb6ad9ccfb6e92bc5b891e0d; https://git.kernel.org/stable/c/5fef23c1c0edceb44d16e64e7818f27d48b5bc38; https://git.kernel.org/stable/c/65a8b6d129cfcf63a2b8a36a63d275479ba6a217
CVE: CVE-2023-54200
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_tables: always release netdev hooks from notifier

This reverts "netfilter: nf_tables: skip netdev events generated on netns removal".

The problem is that when a veth device is released, the veth release
callback will also queue the peer netns device for removal.

Its possible that the peer netns is also slated for removal.  In this
case, the device memory is already released before the pre_exit hook of
the peer netns runs:

BUG: KASAN: slab-use-after-free in nf_hook_entry_head+0x1b8/0x1d0
Read of size 8 at addr ffff88812c0124f0 by task kworker/u8:1/45
Workqueue: netns cleanup_net
Call Trace:
 nf_hook_entry_head+0x1b8/0x1d0
 __nf_unregister_net_hook+0x76/0x510
 nft_netdev_unregister_hooks+0xa0/0x220
 __nft_release_hook+0x184/0x490
 nf_tables_pre_exit_net+0x12f/0x1b0
 ..

Order is:
1. First netns is released, veth_dellink() queues peer netns device
   for removal
2. peer netns is queued for removal
3. peer netns device is released, unreg event is triggered
4. unreg event is ignored because netns is going down
5. pre_exit hook calls nft_netdev_unregister_hooks but device memory
   might be free'd already.
References: https://git.kernel.org/stable/c/30e4b13b1bfbdf3bf3b27036d8209ea1b9f0d880; https://git.kernel.org/stable/c/8d56f00c61f67b450fbbdcb874855e60ad92c560; https://git.kernel.org/stable/c/94032527efbac13be702c76afb9d872c0cca7a43
CVE: CVE-2023-54201
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/efa: Fix wrong resources deallocation order

When trying to destroy QP or CQ, we first decrease the refcount and
potentially free memory regions allocated for the object and then
request the device to destroy the object. If the device fails, the
object isn't fully destroyed so the user/IB core can try to destroy the
object again which will lead to underflow when trying to decrease an
already zeroed refcount.

Deallocate resources in reverse order of allocating them to safely free
them.
References: https://git.kernel.org/stable/c/24f9884971f9b34915b67baacf7350a3f6f19ea4; https://git.kernel.org/stable/c/cf38960386f3cc4abf395e556af915e4babcafd2; https://git.kernel.org/stable/c/dc202c57e9a1423aed528e4b8dc949509cd32191
CVE: CVE-2023-54202
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/i915: fix race condition UAF in i915_perf_add_config_ioctl

Userspace can guess the id value and try to race oa_config object creation
with config remove, resulting in a use-after-free if we dereference the
object after unlocking the metrics_lock.  For that reason, unlocking the
metrics_lock must be done after we are done dereferencing the object.

[tursulin: Manually added stable tag.]
(cherry picked from commit 49f6f6483b652108bcb73accd0204a464b922395)
References: https://git.kernel.org/stable/c/240b[PII_REDACTED]b5e3f10b6dc5ca3f148a322fef; https://git.kernel.org/stable/c/6eeb1cba4c9dc47656ea328afa34953c28783d8c; https://git.kernel.org/stable/c/7eb98f5ac551863efe8be810cea1cd5411d677b1
CVE: CVE-2023-54203
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix slab-out-of-bounds in init_smb2_rsp_hdr

When smb1 mount fails, KASAN detect slab-out-of-bounds in
init_smb2_rsp_hdr like the following one.
For smb1 negotiate(56bytes) , init_smb2_rsp_hdr() for smb2 is called.
The issue occurs while handling smb1 negotiate as smb2 server operations.
Add smb server operations for smb1 (get_cmd_val, init_rsp_hdr,
allocate_rsp_buf, check_user_session) to handle smb1 negotiate so that
smb2 server operation does not handle it.

[  411.400423] CIFS: VFS: Use of the less secure dialect vers=1.0 is
not recommended unless required for access to very old servers
[  411.400452] CIFS: Attempting to mount \\192.168.45.139\homes
[  411.479312] ksmbd: init_smb2_rsp_hdr : 492
[  411.479323] ==================================================================
[  411.479327] BUG: KASAN: slab-out-of-bounds in
init_smb2_rsp_hdr+0x1e2/0x1f4 [ksmbd]
[  411.479369] Read of size 16 at addr ffff888488ed0734 by task kworker/14:1/199

[  411.479379] CPU: 14 PID: 199 Comm: kworker/14:1 Tainted: G
 OE      6.1.21 #3
[  411.479386] Hardware name: ASUSTeK COMPUTER INC. Z10PA-D8
Series/Z10PA-D8 Series, BIOS 3801 08/23/2019
[  411.479390] Workqueue: ksmbd-io handle_ksmbd_work [ksmbd]
[  411.479425] Call Trace:
[  411.479428]  <TASK>
[  411.479432]  dump_stack_lvl+0x49/0x63
[  411.479444]  print_report+0x171/0x4a8
[  411.479452]  ? kasan_complete_mode_report_info+0x3c/0x200
[  411.479463]  ? init_smb2_rsp_hdr+0x1e2/0x1f4 [ksmbd]
[  411.479497]  kasan_report+0xb4/0x130
[  411.479503]  ? init_smb2_rsp_hdr+0x1e2/0x1f4 [ksmbd]
[  411.479537]  kasan_check_range+0x149/0x1e0
[  411.479543]  memcpy+0x24/0x70
[  411.479550]  init_smb2_rsp_hdr+0x1e2/0x1f4 [ksmbd]
[  411.479585]  handle_ksmbd_work+0x109/0x760 [ksmbd]
[  411.479616]  ? _raw_spin_unlock_irqrestore+0x50/0x50
[  411.479624]  ? smb3_encrypt_resp+0x340/0x340 [ksmbd]
[  411.479656]  process_one_work+0x49c/0x790
[  411.479667]  worker_thread+0x2b1/0x6e0
[  411.479674]  ? process_one_work+0x790/0x790
[  411.479680]  kthread+0x177/0x1b0
[  411.479686]  ? kthread_complete_and_exit+0x30/0x30
[  411.479692]  ret_from_fork+0x22/0x30
[  411.479702]  </TASK>
References: https://git.kernel.org/stable/c/921536046bd165efeb07beef5630aff35cd6a489; https://git.kernel.org/stable/c/99a51c673b1d2d0b5a972353401b77612d9cc713; https://git.kernel.org/stable/c/a8334a0c535d0f0b4d64926c8fe0922ed98f7d43
CVE: CVE-2023-54204
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

mmc: sunplus: fix return value check of mmc_add_host()

mmc_add_host() may return error, if we ignore its return value,
1. the memory allocated in mmc_alloc_host() will be leaked
2. null-ptr-deref will happen when calling mmc_remove_host()
in remove function spmmc_drv_remove() because deleting not
added device.

Fix this by checking the return value of mmc_add_host(). Moreover,
I fixed the error handling path of spmmc_drv_probe() to clean up.
References: https://git.kernel.org/stable/c/741a951f41929f39cae70c66d86d0754d3129d0a; https://git.kernel.org/stable/c/dce6d8f985fa1ef5c2af47f4f86ea65511b78656
CVE: CVE-2023-54205
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

pinctrl: stm32: Fix refcount leak in stm32_pctrl_get_irq_domain

of_irq_find_parent() returns a node pointer with refcount incremented,
We should use of_node_put() on it when not needed anymore.
Add missing of_node_put() to avoid refcount leak.
References: https://git.kernel.org/stable/c/601be03fa8b81747a154bdef9b559411a5b921e8; https://git.kernel.org/stable/c/8ab860dd8717a7e4a143988885fea0d7e5a9412e; https://git.kernel.org/stable/c/95ab6d7905ebb52dc2ed6357c38e[PII_REDACTED]68
CVE: CVE-2023-54207
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

HID: uclogic: Correct devm device reference for hidinput input_dev name

Reference the HID device rather than the input device for the devm
allocation of the input_dev name. Referencing the input_dev would lead to a
use-after-free when the input_dev was unregistered and subsequently fires a
uevent that depends on the name. At the point of firing the uevent, the
name would be freed by devres management.

Use devm_kasprintf to simplify the logic for allocating memory and
formatting the input_dev name string.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/4c2707dfee5847dc0b5ecfbe512c29c93832fdc4; https://git.kernel.org/stable/c/51f49e3927ad545cec0c0afb86856ccacd9f085d; https://git.kernel.org/stable/c/58f0d1c0e494a88f301bf455da7df4366f179bbb
CVE: CVE-2023-54208
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

media: ov5675: Fix memleak in ov5675_init_controls()

There is a kmemleak when testing the media/i2c/ov5675.c with bpf mock
device:

AssertionError: unreferenced object 0xffff[PII_REDACTED]60 (size 16):
  comm "python3", pid 277, jiffies[PII_REDACTED] (age 20.722s)
  hex dump (first 16 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<00000000abe7d67c>] __kmalloc_node+0x44/0x1b0
    [<000000008a725aac>] kvmalloc_node+0x34/0x180
    [<000000009a53cd11>] v4l2_ctrl_handler_init_class+0x11d/0x180
[videodev]
    [<[PII_REDACTED]b46db0>] ov5675_probe+0x38b/0x897 [ov5675]
    [<[PII_REDACTED]3d886c>] i2c_device_probe+0x28d/0x680
    [<000000004afb7e8f>] really_probe+0x17c/0x3f0
    [<00000000ff2f18e4>] __driver_probe_device+0xe3/0x170
    [<000000000a001029>] driver_probe_device+0x49/0x120
    [<00000000e39743c7>] __device_attach_driver+0xf7/0x150
    [<00000000d32fd070>] bus_for_each_drv+0x114/0x180
    [<[PII_REDACTED]83ac41>] __device_attach+0x1e5/0x2d0
    [<[PII_REDACTED]b4a830>] bus_probe_device+0x126/0x140
    [<[PII_REDACTED]13deaf>] device_add+0x810/0x1130
    [<000000007becb867>] i2c_new_client_device+0x386/0x540
    [<000000007f9cf4b4>] of_i2c_register_device+0xf1/0x110
    [<00000000ebfdd032>] of_i2c_notify+0xfc/0x1f0

ov5675_init_controls() won't clean all the allocated resources in fail
path, which may causes the memleaks. Add v4l2_ctrl_handler_free() to
prevent memleak.
References: https://git.kernel.org/stable/c/086a80b842bcb621d6c4eedad20683f1f674d0c2; https://git.kernel.org/stable/c/49b849824b9862f177fc77fc92ef95ec54566ecf; https://git.kernel.org/stable/c/7a36a6be694df87d019663863b922913947b42af
CVE: CVE-2023-54209
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

block: fix blktrace debugfs entries leakage

Commit 99d055b4fd4b ("block: remove per-disk debugfs files in
blk_unregister_queue") moves blk_trace_shutdown() from
blk_release_queue() to blk_unregister_queue(), this is safe if blktrace
is created through sysfs, however, there is a regression in corner
case.

blktrace can still be enabled after del_gendisk() through ioctl if
the disk is opened before del_gendisk(), and if blktrace is not shutdown
through ioctl before closing the disk, debugfs entries will be leaked.

Fix this problem by shutdown blktrace in disk_release(), this is safe
because blk_trace_remove() is reentrant.
References: https://git.kernel.org/stable/c/7149e57cf01184fba175589f8fbe9fbf33be02e1; https://git.kernel.org/stable/c/942e81650b81b4ca62f1d8c61de455c9e7c7e6ca; https://git.kernel.org/stable/c/aa07e56c6a9c[PII_REDACTED]d14eed4fe8babf34fb
CVE: CVE-2023-54210
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_sync: Avoid use-after-free in dbg for hci_remove_adv_monitor()

KASAN reports that there's a use-after-free in
hci_remove_adv_monitor(). Trawling through the disassembly, you can
see that the complaint is from the access in bt_dev_dbg() under the
HCI_ADV_MONITOR_EXT_MSFT case. The problem case happens because
msft_remove_monitor() can end up freeing the monitor
structure. Specifically:
  hci_remove_adv_monitor() ->
  msft_remove_monitor() ->
  msft_remove_monitor_sync() ->
  msft_le_cancel_monitor_advertisement_cb() ->
  hci_free_adv_monitor()

Let's fix the problem by just stashing the relevant data when it's
still valid.
References: https://git.kernel.org/stable/c/0d4d6b083da9b033ddccef72d77f373c819ae3ea; https://git.kernel.org/stable/c/bf00c2c8f6254f44ac041aa9a311ae9e0caf692b; https://git.kernel.org/stable/c/de6dfcefd107667ce2dbedf4d9337f5ed557a4a1
CVE: CVE-2023-54211
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

tracing: Fix warning in trace_buffered_event_disable()

Warning happened in trace_buffered_event_disable() at
  WARN_ON_ONCE(!trace_buffered_event_ref)

  Call Trace:
   ? __warn+0xa5/0x1b0
   ? trace_buffered_event_disable+0x189/0x1b0
   __ftrace_event_enable_disable+0x19e/0x3e0
   free_probe_data+0x3b/0xa0
   unregister_ftrace_function_probe_func+0x6b8/0x800
   event_enable_func+0x2f0/0x3d0
   ftrace_process_regex.isra.0+0x12d/0x1b0
   ftrace_filter_write+0xe6/0x140
   vfs_write+0x1c9/0x6f0
   [...]

The cause of the warning is in __ftrace_event_enable_disable(),
trace_buffered_event_enable() was called once while
trace_buffered_event_disable() was called twice.
Reproduction script show as below, for analysis, see the comments:
 ```
 #!/bin/bash

 cd /sys/kernel/tracing/

 # 1. Register a 'disable_event' command, then:
 #    1) SOFT_DISABLED_BIT was set;
 #    2) trace_buffered_event_enable() was called first time;
 echo 'cmdline_proc_show:disable_event:initcall:initcall_finish' > \
     set_ftrace_filter

 # 2. Enable the event registered, then:
 #    1) SOFT_DISABLED_BIT was cleared;
 #    2) trace_buffered_event_disable() was called first time;
 echo 1 > events/initcall/initcall_finish/enable

 # 3. Try to call into cmdline_proc_show(), then SOFT_DISABLED_BIT was
 #    set again!!!
 cat /proc/cmdline

 # 4. Unregister the 'disable_event' command, then:
 #    1) SOFT_DISABLED_BIT was cleared again;
 #    2) trace_buffered_event_disable() was called second time!!!
 echo '!cmdline_proc_show:disable_event:initcall:initcall_finish' > \
     set_ftrace_filter
 ```

To fix it, IIUC, we can change to call trace_buffered_event_enable() at
fist time soft-mode enabled, and call trace_buffered_event_disable() at
last time soft-mode disabled.
References: https://git.kernel.org/stable/c/1488d782c9e43087a3f341b8186cd25f3cf75583; https://git.kernel.org/stable/c/528c9d73153754defb748f0b96ad33308668d817; https://git.kernel.org/stable/c/813cede7b2f5a4b1b75d2d4bb4e705cc8e063b20
CVE: CVE-2023-54212
Published: 2025-12-30
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.