xamxte/cve-to-cwe huggingface dataset:
CVE-2023-53823: In the Linux kernel, the following vulnerability has been resolved:  block/rq_qos: protect rq_qos apis with a new lock  commit 50e34d78815e ("block: disable the elevator int del_gendisk") move rq_qos_exit() from disk_release() to del_gendisk(), this will introduce some problems:  1) If rq_qos_add() is triggered by enabling iocost/iolatency through    cgroupfs, then it can concurrent with del_gendisk(), it's not safe to    write 'q->rq_qos' concurrently.  2) Activate cgroup policy that is relied on rq_qos will call    rq_qos_add() and blkcg_activate_policy(), and if rq_qos_exit() is    called in the middle, null-ptr-dereference will be triggered in    blkcg_activate_policy().  3) blkg_conf_open_bdev() can call blkdev_get_no_open() first to find the    disk, then if rq_qos_exit() from del_gendisk() is done before    rq_qos_add(), then memory will be leaked.  This patch add a new disk level mutex 'rq_qos_mutex':  1) The lock will protect rq_qos_exit() directly.  2) For wbt that doesn't relied on blk-cgroup, rq_qos_add() can only be    called from disk initialization for now because wbt can't be    destructed until rq_qos_exit(), so it's safe not to protect wbt for    now. Hoever, in case that rq_qos dynamically destruction is supported    in the furture, this patch also protect rq_qos_add() from wbt_init()    directly, this is enough because blk-sysfs already synchronize    writers with disk removal.  3) For iocost and iolatency, in order to synchronize disk removal and    cgroup configuration, the lock is held after blkdev_get_no_open()    from blkg_conf_open_bdev(), and is released in blkg_conf_exit().    In order to fix the above memory leak, disk_live() is checked after    holding the new lock.
CVE-2023-53824: In the Linux kernel, the following vulnerability has been resolved:  netlink: annotate lockless accesses to nlk->max_recvmsg_len  syzbot reported a data-race in data-race in netlink_recvmsg() [1]  Indeed, netlink_recvmsg() can be run concurrently, and netlink_dump() also needs protection.  [1] BUG: KCSAN: data-race in netlink_recvmsg / netlink_recvmsg  read to 0xffff888141840b38 of 8 bytes by task 23057 on cpu 0: netlink_recvmsg+0xea/0x730 net/netlink/af_netlink.c:1988 sock_recvmsg_nosec net/socket.c:1017 [inline] sock_recvmsg net/socket.c:1038 [inline] __sys_recvfrom+0x1ee/0x2e0 net/socket.c:2194 __do_sys_recvfrom net/socket.c:2212 [inline] __se_sys_recvfrom net/socket.c:2208 [inline] __x64_sys_recvfrom+0x78/0x90 net/socket.c:2208 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd  write to 0xffff888141840b38 of 8 bytes by task 23037 on cpu 1: netlink_recvmsg+0x114/0x730 net/netlink/af_netlink.c:1989 sock_recvmsg_nosec net/socket.c:1017 [inline] sock_recvmsg net/socket.c:1038 [inline] ____sys_recvmsg+0x156/0x310 net/socket.c:2720 ___sys_recvmsg net/socket.c:2762 [inline] do_recvmmsg+0x2e5/0x710 net/socket.c:2856 __sys_recvmmsg net/socket.c:2935 [inline] __do_sys_recvmmsg net/socket.c:2958 [inline] __se_sys_recvmmsg net/socket.c:2951 [inline] __x64_sys_recvmmsg+0xe2/0x160 net/socket.c:2951 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd  value changed: 0x0000000000000000 -> 0x0000000000001000  Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 23037 Comm: syz-executor.2 Not tainted 6.3.0-rc4-syzkaller-00195-g5a57b48fdfcb #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023
CVE-2023-53826: In the Linux kernel, the following vulnerability has been resolved:  ubi: Fix UAF wear-leveling entry in eraseblk_count_seq_show()  Wear-leveling entry could be freed in error path, which may be accessed again in eraseblk_count_seq_show(), for example:  __erase_worker                eraseblk_count_seq_show                                 wl = ubi->lookuptbl[*block_number]     if (wl)   wl_entry_destroy     ubi->lookuptbl[e->pnum] = NULL     kmem_cache_free(ubi_wl_entry_slab, e)                      erase_count = wl->ec  // UAF!  Wear-leveling entry updating/accessing in ubi->lookuptbl should be protected by ubi->wl_lock, fix it by adding ubi->wl_lock to serialize wl entry accessing between wl_entry_destroy() and eraseblk_count_seq_show().  Fetch a reproducer in [Link].
CVE-2023-53827: In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: L2CAP: Fix use-after-free in l2cap_disconnect_{req,rsp}  Similar to commit d0be8347c623 ("Bluetooth: L2CAP: Fix use-after-free caused by l2cap_chan_put"), just use l2cap_chan_hold_unless_zero to prevent referencing a channel that is about to be destroyed.
CVE-2023-53828: In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: hci_sync: Avoid use-after-free in dbg for hci_add_adv_monitor()  KSAN reports use-after-free in hci_add_adv_monitor().  While adding an adv monitor,     hci_add_adv_monitor() calls ->     msft_add_monitor_pattern() calls ->     msft_add_monitor_sync() calls ->     msft_le_monitor_advertisement_cb() calls in an error case ->     hci_free_adv_monitor() which frees the *moniter.  This is referenced by bt_dev_dbg() in hci_add_adv_monitor().  Fix the bt_dev_dbg() by using handle instead of monitor->handle.
CVE-2023-53830: In the Linux kernel, the following vulnerability has been resolved:  platform/x86: think-lmi: Fix memory leak when showing current settings  When retriving a item string with tlmi_setting(), the result has to be freed using kfree(). In current_value_show() however, malformed item strings are not freed, causing a memory leak. Fix this by eliminating the early return responsible for this.
CVE-2023-53832: In the Linux kernel, the following vulnerability has been resolved:  md/raid10: fix null-ptr-deref in raid10_sync_request  init_resync() inits mempool and sets conf->have_replacemnt at the beginning of sync, close_sync() frees the mempool when sync is completed.  After [1] recovery might be skipped and init_resync() is called but close_sync() is not. null-ptr-deref occurs with r10bio->dev[i].repl_bio.  The following is one way to reproduce the issue.    1) create a array, wait for resync to complete, mddev->recovery_cp is set      to MaxSector.   2) recovery is woken and it is skipped. conf->have_replacement is set to      0 in init_resync(). close_sync() not called.   3) some io errors and rdev A is set to WantReplacement.   4) a new device is added and set to A's replacement.   5) recovery is woken, A have replacement, but conf->have_replacemnt is      0. r10bio->dev[i].repl_bio will not be alloced and null-ptr-deref      occurs.  Fix it by not calling init_resync() if recovery skipped.  [1] commit 7e83ccbecd60 ("md/raid10: Allow skipping recovery when clean arrays are assembled")
CVE-2023-53833: In the Linux kernel, the following vulnerability has been resolved:  drm/i915: Fix NULL ptr deref by checking new_crtc_state  intel_atomic_get_new_crtc_state can return NULL, unless crtc state wasn't obtained previously with intel_atomic_get_crtc_state, so we must check it for NULLness here, just as in many other places, where we can't guarantee that intel_atomic_get_crtc_state was called. We are currently getting NULL ptr deref because of that, so this fix was confirmed to help.  (cherry picked from commit 1d5b09f8daf859247a1ea65b0d732a24d88980d8)
CVE-2023-53834: In the Linux kernel, the following vulnerability has been resolved:  iio: adc: ina2xx: avoid NULL pointer dereference on OF device match  The affected lines were resulting in a NULL pointer dereference on our platform because the device tree contained the following list of compatible strings:      power-sensor@40 {         compatible = "ti,ina232", "ti,ina231";         ...     };  Since the driver doesn't declare a compatible string "ti,ina232", the OF matching succeeds on "ti,ina231". But the I2C device ID info is populated via the first compatible string, cf. modalias population in of_i2c_get_board_info(). Since there is no "ina232" entry in the legacy I2C device ID table either, the struct i2c_device_id *id pointer in the probe function is NULL.  Fix this by using the already populated type variable instead, which points to the proper driver data. Since the name is also wanted, add a generic one to the ina2xx_config table.
CVE-2023-53836: In the Linux kernel, the following vulnerability has been resolved:  bpf, sockmap: Fix skb refcnt race after locking changes  There is a race where skb's from the sk_psock_backlog can be referenced after userspace side has already skb_consumed() the sk_buff and its refcnt dropped to zer0 causing use after free.  The flow is the following:    while ((skb = skb_peek(&psock->ingress_skb))     sk_psock_handle_Skb(psock, skb, ..., ingress)     if (!ingress) ...     sk_psock_skb_ingress        sk_psock_skb_ingress_enqueue(skb)           msg->skb = skb           sk_psock_queue_msg(psock, msg)     skb_dequeue(&psock->ingress_skb)  The sk_psock_queue_msg() puts the msg on the ingress_msg queue. This is what the application reads when recvmsg() is called. An application can read this anytime after the msg is placed on the queue. The recvmsg hook will also read msg->skb and then after user space reads the msg will call consume_skb(skb) on it effectively free'ing it.  But, the race is in above where backlog queue still has a reference to the skb and calls skb_dequeue(). If the skb_dequeue happens after the user reads and free's the skb we have a use after free.  The !ingress case does not suffer from this problem because it uses sendmsg_*(sk, msg) which does not pass the sk_buff further down the stack.  The following splat was observed with 'test_progs -t sockmap_listen':    [ 1022.710250][ T2556] general protection fault, ...   [...]   [ 1022.712830][ T2556] Workqueue: events sk_psock_backlog   [ 1022.713262][ T2556] RIP: 0010:skb_dequeue+0x4c/0x80   [ 1022.713653][ T2556] Code: ...   [...]   [ 1022.720699][ T2556] Call Trace:   [ 1022.720984][ T2556]  <TASK>   [ 1022.721254][ T2556]  ? die_addr+0x32/0x80^M   [ 1022.721589][ T2556]  ? exc_general_protection+0x25a/0x4b0   [ 1022.722026][ T2556]  ? asm_exc_general_protection+0x22/0x30   [ 1022.722489][ T2556]  ? skb_dequeue+0x4c/0x80   [ 1022.722854][ T2556]  sk_psock_backlog+0x27a/0x300   [ 1022.723243][ T2556]  process_one_work+0x2a7/0x5b0   [ 1022.723633][ T2556]  worker_thread+0x4f/0x3a0   [ 1022.723998][ T2556]  ? __pfx_worker_thread+0x10/0x10   [ 1022.724386][ T2556]  kthread+0xfd/0x130   [ 1022.724709][ T2556]  ? __pfx_kthread+0x10/0x10   [ 1022.725066][ T2556]  ret_from_fork+0x2d/0x50   [ 1022.725409][ T2556]  ? __pfx_kthread+0x10/0x10   [ 1022.725799][ T2556]  ret_from_fork_asm+0x1b/0x30   [ 1022.726201][ T2556]  </TASK>  To fix we add an skb_get() before passing the skb to be enqueued in the engress queue. This bumps the skb->users refcnt so that consume_skb() and kfree_skb will not immediately free the sk_buff. With this we can be sure the skb is still around when we do the dequeue. Then we just need to decrement the refcnt or free the skb in the backlog case which we do by calling kfree_skb() on the ingress case as well as the sendmsg case.  Before locking change from fixes tag we had the sock locked so we couldn't race with user and there was no issue here.
CVE-2023-53838: In the Linux kernel, the following vulnerability has been resolved:  f2fs: synchronize atomic write aborts  To fix a race condition between atomic write aborts, I use the inode lock and make COW inode to be re-usable thoroughout the whole atomic file inode lifetime.
CVE-2023-53839: In the Linux kernel, the following vulnerability has been resolved:  dccp: fix data-race around dp->dccps_mss_cache  dccp_sendmsg() reads dp->dccps_mss_cache before locking the socket. Same thing in do_dccp_getsockopt().  Add READ_ONCE()/WRITE_ONCE() annotations, and change dccp_sendmsg() to check again dccps_mss_cache after socket is locked.
CVE-2023-53840: In the Linux kernel, the following vulnerability has been resolved:  usb: early: xhci-dbc: Fix a potential out-of-bound memory access  If xdbc_bulk_write() fails, the values in 'buf' can be anything. So the string is not guaranteed to be NULL terminated when xdbc_trace() is called.  Reserve an extra byte, which will be zeroed automatically because 'buf' is a static variable, in order to avoid troubles, should it happen.
CVE-2023-53843: In the Linux kernel, the following vulnerability has been resolved:  net: openvswitch: reject negative ifindex  Recent changes in net-next (commit 759ab1edb56c ("net: store netdevs in an xarray")) refactored the handling of pre-assigned ifindexes and let syzbot surface a latent problem in ovs. ovs does not validate ifindex, making it possible to create netdev ports with negative ifindex values. It's easy to repro with YNL:  $ ./cli.py --spec netlink/specs/ovs_datapath.yaml \          --do new \   --json '{"upcall-pid": 1, "name":"my-dp"}' $ ./cli.py --spec netlink/specs/ovs_vport.yaml \   --do new \   --json '{"upcall-pid": "00000001", "name": "some-port0", "dp-ifindex":3,"ifindex":4294901760,"type":2}'  $ ip link show -65536: some-port0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000     link/ether 7a:48:21:ad:0b:fb brd ff:ff:ff:ff:ff:ff ...  Validate the inputs. Now the second command correctly returns:  $ ./cli.py --spec netlink/specs/ovs_vport.yaml \   --do new \   --json '{"upcall-pid": "00000001", "name": "some-port0", "dp-ifindex":3,"ifindex":4294901760,"type":2}'  lib.ynl.NlError: Netlink error: Numerical result out of range nl_len = 108 (92) nl_flags = 0x300 nl_type = 2  error: -34 extack: {'msg': 'integer out of range', 'unknown': [[type:4 len:36] b'\x0c\x00\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0c\x00\x03\x00\xff\xff\xff\x7f\x00\x00\x00\x00\x08\x00\x01\x00\x08\x00\x00\x00'], 'bad-attr': '.ifindex'}  Accept 0 since it used to be silently ignored.
CVE-2023-53844: In the Linux kernel, the following vulnerability has been resolved:  drm/ttm: Don't leak a resource on swapout move error  If moving the bo to system for swapout failed, we were leaking a resource. Fix.
CVE-2023-53845: In the Linux kernel, the following vulnerability has been resolved:  nilfs2: fix infinite loop in nilfs_mdt_get_block()  If the disk image that nilfs2 mounts is corrupted and a virtual block address obtained by block lookup for a metadata file is invalid, nilfs_bmap_lookup_at_level() may return the same internal return code as -ENOENT, meaning the block does not exist in the metadata file.  This duplication of return codes confuses nilfs_mdt_get_block(), causing it to read and create a metadata block indefinitely.  In particular, if this happens to the inode metadata file, ifile, semaphore i_rwsem can be left held, causing task hangs in lock_mount.  Fix this issue by making nilfs_bmap_lookup_at_level() treat virtual block address translation failures with -ENOENT as metadata corruption instead of returning the error code.
CVE-2023-53846: In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to do sanity check on direct node in truncate_dnode()  syzbot reports below bug:  BUG: KASAN: slab-use-after-free in f2fs_truncate_data_blocks_range+0x122a/0x14c0 fs/f2fs/file.c:574 Read of size 4 at addr ffff88802a25c000 by task syz-executor148/5000  CPU: 1 PID: 5000 Comm: syz-executor148 Not tainted 6.4.0-rc7-syzkaller-00041-ge660abd551f1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023 Call Trace:  <TASK>  __dump_stack lib/dump_stack.c:88 [inline]  dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106  print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351  print_report mm/kasan/report.c:462 [inline]  kasan_report+0x11c/0x130 mm/kasan/report.c:572  f2fs_truncate_data_blocks_range+0x122a/0x14c0 fs/f2fs/file.c:574  truncate_dnode+0x229/0x2e0 fs/f2fs/node.c:944  f2fs_truncate_inode_blocks+0x64b/0xde0 fs/f2fs/node.c:1154  f2fs_do_truncate_blocks+0x4ac/0xf30 fs/f2fs/file.c:721  f2fs_truncate_blocks+0x7b/0x300 fs/f2fs/file.c:749  f2fs_truncate.part.0+0x4a5/0x630 fs/f2fs/file.c:799  f2fs_truncate include/linux/fs.h:825 [inline]  f2fs_setattr+0x1738/0x2090 fs/f2fs/file.c:1006  notify_change+0xb2c/0x1180 fs/attr.c:483  do_truncate+0x143/0x200 fs/open.c:66  handle_truncate fs/namei.c:3295 [inline]  do_open fs/namei.c:3640 [inline]  path_openat+0x2083/0x2750 fs/namei.c:3791  do_filp_open+0x1ba/0x410 fs/namei.c:3818  do_sys_openat2+0x16d/0x4c0 fs/open.c:1356  do_sys_open fs/open.c:1372 [inline]  __do_sys_creat fs/open.c:1448 [inline]  __se_sys_creat fs/open.c:1442 [inline]  __x64_sys_creat+0xcd/0x120 fs/open.c:1442  do_syscall_x64 arch/x86/entry/common.c:50 [inline]  do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80  entry_SYSCALL_64_after_hwframe+0x63/0xcd  The root cause is, inodeA references inodeB via inodeB's ino, once inodeA is truncated, it calls truncate_dnode() to truncate data blocks in inodeB's node page, it traverse mapping data from node->i.i_addr[0] to node->i.i_addr[ADDRS_PER_BLOCK() - 1], result in out-of-boundary access.  This patch fixes to add sanity check on dnode page in truncate_dnode(), so that, it can help to avoid triggering such issue, and once it encounters such issue, it will record newly introduced ERROR_INVALID_NODE_REFERENCE error into superblock, later fsck can detect such issue and try repairing.  Also, it removes f2fs_truncate_data_blocks() for cleanup due to the function has only one caller, and uses f2fs_truncate_data_blocks_range() instead.
CVE-2023-53847: In the Linux kernel, the following vulnerability has been resolved:  usb-storage: alauda: Fix uninit-value in alauda_check_media()  Syzbot got KMSAN to complain about access to an uninitialized value in the alauda subdriver of usb-storage:  BUG: KMSAN: uninit-value in alauda_transport+0x462/0x57f0 drivers/usb/storage/alauda.c:1137 CPU: 0 PID: 12279 Comm: usb-storage Not tainted 5.3.0-rc7+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace:   __dump_stack lib/dump_stack.c:77 [inline]   dump_stack+0x191/0x1f0 lib/dump_stack.c:113   kmsan_report+0x13a/0x2b0 mm/kmsan/kmsan_report.c:108   __msan_warning+0x73/0xe0 mm/kmsan/kmsan_instr.c:250   alauda_check_media+0x344/0x3310 drivers/usb/storage/alauda.c:460  The problem is that alauda_check_media() doesn't verify that its USB transfer succeeded before trying to use the received data.  What should happen if the transfer fails isn't entirely clear, but a reasonably conservative approach is to pretend that no media is present.  A similar problem exists in a usb_stor_dbg() call in alauda_get_media_status().  In this case, when an error occurs the call is redundant, because usb_stor_ctrl_transfer() already will print a debugging message.  Finally, unrelated to the uninitialized memory access, is the fact that alauda_check_media() performs DMA to a buffer on the stack. Fortunately usb-storage provides a general purpose DMA-able buffer for uses like this.  We'll use it instead.
CVE-2023-53848: In the Linux kernel, the following vulnerability has been resolved:  md/raid5-cache: fix a deadlock in r5l_exit_log()  Commit b13015af94cf ("md/raid5-cache: Clear conf->log after finishing work") introduce a new problem:  // caller hold reconfig_mutex r5l_exit_log  flush_work(&log->disable_writeback_work)    r5c_disable_writeback_async     wait_event      /*       * conf->log is not NULL, and mddev_trylock()       * will fail, wait_event() can never pass.       */  conf->log = NULL  Fix this problem by setting 'config->log' to NULL before wake_up() as it used to be, so that wait_event() from r5c_disable_writeback_async() can exist. In the meantime, move forward md_unregister_thread() so that null-ptr-deref this commit fixed can still be fixed.
CVE-2023-53849: In the Linux kernel, the following vulnerability has been resolved:  drm/msm: fix workqueue leak on bind errors  Make sure to destroy the workqueue also in case of early errors during bind (e.g. a subcomponent failing to bind).  Since commit c3b790ea07a1 ("drm: Manage drm_mode_config_init with drmm_") the mode config will be freed when the drm device is released also when using the legacy interface, but add an explicit cleanup for consistency and to facilitate backporting.  Patchwork: https://patchwork.freedesktop.org/patch/525093/
CVE-2023-53851: In the Linux kernel, the following vulnerability has been resolved:  drm/msm/dp: Drop aux devices together with DP controller  Using devres to depopulate the aux bus made sure that upon a probe deferral the EDP panel device would be destroyed and recreated upon next attempt.  But the struct device which the devres is tied to is the DPUs (drm_dev->dev), which may be happen after the DP controller is torn down.  Indications of this can be seen in the commonly seen EDID-hexdump full of zeros in the log, or the occasional/rare KASAN fault where the panel's attempt to read the EDID information causes a use after free on DP resources.  It's tempting to move the devres to the DP controller's struct device, but the resources used by the device(s) on the aux bus are explicitly torn down in the error path. The KASAN-reported use-after-free also remains, as the DP aux "module" explicitly frees its devres-allocated memory in this code path.  As such, explicitly depopulate the aux bus in the error path, and in the component unbind path, to avoid these issues.  Patchwork: https://patchwork.freedesktop.org/patch/542163/
CVE-2023-53852: In the Linux kernel, the following vulnerability has been resolved:  nvme-core: fix memory leak in dhchap_secret_store  Free dhchap_secret in nvme_ctrl_dhchap_secret_store() before we return fix following kmemleack:-  unreferenced object 0xffff8886376ea800 (size 64):   comm "check", pid 22048, jiffies 4344316705 (age 92.199s)   hex dump (first 32 bytes):     44 48 48 43 2d 31 3a 30 30 3a 6e 78 72 35 4b 67  DHHC-1:00:nxr5Kg     75 58 34 75 6f 41 78 73 4a 61 34 63 2f 68 75 4c  uX4uoAxsJa4c/huL   backtrace:     [<0000000030ce5d4b>] __kmalloc+0x4b/0x130     [<000000009be1cdc1>] nvme_ctrl_dhchap_secret_store+0x8f/0x160 [nvme_core]     [<00000000ac06c96a>] kernfs_fop_write_iter+0x12b/0x1c0     [<00000000437e7ced>] vfs_write+0x2ba/0x3c0     [<00000000f9491baf>] ksys_write+0x5f/0xe0     [<000000001c46513d>] do_syscall_64+0x3b/0x90     [<00000000ecf348fe>] entry_SYSCALL_64_after_hwframe+0x72/0xdc unreferenced object 0xffff8886376eaf00 (size 64):   comm "check", pid 22048, jiffies 4344316736 (age 92.168s)   hex dump (first 32 bytes):     44 48 48 43 2d 31 3a 30 30 3a 6e 78 72 35 4b 67  DHHC-1:00:nxr5Kg     75 58 34 75 6f 41 78 73 4a 61 34 63 2f 68 75 4c  uX4uoAxsJa4c/huL   backtrace:     [<0000000030ce5d4b>] __kmalloc+0x4b/0x130     [<000000009be1cdc1>] nvme_ctrl_dhchap_secret_store+0x8f/0x160 [nvme_core]     [<00000000ac06c96a>] kernfs_fop_write_iter+0x12b/0x1c0     [<00000000437e7ced>] vfs_write+0x2ba/0x3c0     [<00000000f9491baf>] ksys_write+0x5f/0xe0     [<000000001c46513d>] do_syscall_64+0x3b/0x90     [<00000000ecf348fe>] entry_SYSCALL_64_after_hwframe+0x72/0xdc