deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2023-52997
Published: 2025-03-27
Description: In the Linux kernel, the following vulnerability has been resolved:

ipv4: prevent potential spectre v1 gadget in ip_metrics_convert()

if (!type)
		continue;
	if (type > RTAX_MAX)
		return -EINVAL;
	...
	metrics[type - 1] = val;

@type being used as an array index, we need to prevent
cpu speculation or risk leaking kernel memory content.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1d1d63b612801b3f0a39b7d4467cad0abd60e5c8; https://git.kernel.org/stable/c/34c6142f0df9cd75cba5a7aa9df0960d2854b415; https://git.kernel.org/stable/c/6850fe301d015a7d2012d1de8caf43dafb7cc2f6
CVE: CVE-2023-52999
Published: 2025-03-27
Description: In the Linux kernel, the following vulnerability has been resolved:

net: fix UaF in netns ops registration error path

If net_assign_generic() fails, the current error path in ops_init() tries
to clear the gen pointer slot. Anyway, in such error path, the gen pointer
itself has not been modified yet, and the existing and accessed one is
smaller than the accessed index, causing an out-of-bounds error:

 BUG: KASAN: slab-out-of-bounds in ops_init+0x2de/0x320
 Write of size 8 at addr ffff[PII_REDACTED]78 by task modprobe/1018

 CPU: 2 PID: 1018 Comm: modprobe Not tainted 6.2.0-rc2.mptcp_ae5ac65fbed5+ #1641
 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.1-2.fc37 04/01/2014
 Call Trace:
  <TASK>
  dump_stack_lvl+0x6a/0x9f
  print_address_description.constprop.0+0x86/0x2b5
  print_report+0x11b/0x1fb
  kasan_report+0x87/0xc0
  ops_init+0x2de/0x320
  register_pernet_operations+0x2e4/0x750
  register_pernet_subsys+0x24/0x40
  tcf_register_action+0x9f/0x560
  do_one_initcall+0xf9/0x570
  do_init_module+0x190/0x650
  load_module+0x1fa5/0x23c0
  __do_sys_finit_module+0x10d/0x1b0
  do_syscall_64+0x58/0x80
  entry_SYSCALL_64_after_hwframe+0x72/0xdc
 RIP: 0033:0x7f42518f778d
 Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48
       89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
       ff 73 01 c3 48 8b 0d cb 56 2c 00 f7 d8 64 89 01 48
 RSP: 002b:00007fff96869688 EFLAGS: 00000246 ORIG_RAX: [PII_REDACTED]
 RAX: ffffffffffffffda RBX: 00005568ef7f7c90 RCX: 00007f42518f778d
 RDX: [PII_REDACTED] RSI: 00005568ef41d796 RDI: [PII_REDACTED]
 RBP: 00005568ef41d796 R08: [PII_REDACTED] R09: [PII_REDACTED]
 R10: [PII_REDACTED] R11: [PII_REDACTED] R12: [PII_REDACTED]
 R13: 00005568ef7f7d30 R14: [PII_REDACTED] R15: [PII_REDACTED]
  </TASK>

This change addresses the issue by skipping the gen pointer
de-reference in the mentioned error-path.

Found by code inspection and verified with explicit error injection
on a kasan-enabled kernel.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/12075708f2e77ee6a9f8bb2cf512c38be3099794; https://git.kernel.org/stable/c/66689a72ba73575e76d4f6a8748d3fa2690ec1c4; https://git.kernel.org/stable/c/71ab9c3e[PII_REDACTED]c31c89dbb2c69305cc89b1
CVE: CVE-2023-53000
Published: 2025-03-27
Description: In the Linux kernel, the following vulnerability has been resolved:

netlink: prevent potential spectre v1 gadgets

Most netlink attributes are parsed and validated from
__nla_validate_parse() or validate_nla()

    u16 type = nla_type(nla);

    if (type == 0 || type > maxtype) {
        /* error or continue */
    }

@type is then used as an array index and can be used
as a Spectre v1 gadget.

array_index_nospec() can be used to prevent leaking
content of kernel memory to malicious users.

This should take care of vast majority of netlink uses,
but an audit is needed to take care of others where
validation is not yet centralized in core netlink functions.
CVSS Score: 7.8 (HIGH)
CWE: CWE-129
References: https://git.kernel.org/stable/c/3e5082b1c66c7783fbcd79b5b178573230e528ff; https://git.kernel.org/stable/c/41b74e95f297ac360ca7ed6bf200100717cb6c45; https://git.kernel.org/stable/c/539ca5dcbc91134bbe2c45677811c31d8b030d2d
CVE: CVE-2023-53001
Published: 2025-03-27
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2023-53002
Published: 2025-03-27
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/i915: Fix a memory leak with reused mmap_offset

drm_vma_node_allow() and drm_vma_node_revoke() should be called in
balanced pairs. We call drm_vma_node_allow() once per-file everytime a
user calls mmap_offset, but only call drm_vma_node_revoke once per-file
on each mmap_offset. As the mmap_offset is reused by the client, the
per-file vm_count may remain non-zero and the rbtree leaked.

Call drm_vma_node_allow_once() instead to prevent that memory leak.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/0220e4fe178c3390eb0291cdb34912d66972db8a; https://git.kernel.org/stable/c/0bdc4b4ba7206c452ee81c82fa66e39d0e1780fb
CVE: CVE-2023-53003
Published: 2025-03-27
Description: In the Linux kernel, the following vulnerability has been resolved:

EDAC/qcom: Do not pass llcc_driv_data as edac_device_ctl_info's pvt_info

The memory for llcc_driv_data is allocated by the LLCC driver. But when
it is passed as the private driver info to the EDAC core, it will get freed
during the qcom_edac driver release. So when the qcom_edac driver gets probed
again, it will try to use the freed data leading to the use-after-free bug.

Hence, do not pass llcc_driv_data as pvt_info but rather reference it
using the platform_data pointer in the qcom_edac driver.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/66e10d5f399629ef7877304d9ba2b35d0474e7eb; https://git.kernel.org/stable/c/6f0351d0c311951b8b3064db91e61841e85b2b96; https://git.kernel.org/stable/c/76d9ebb7f0bc10fbc78b6d576751552edf743968
CVE: CVE-2023-53004
Published: 2025-03-27
Description: In the Linux kernel, the following vulnerability has been resolved:

ovl: fix tmpfile leak

Missed an error cleanup.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/baabaa505563362b71f2637aedd7b807d270656c; https://git.kernel.org/stable/c/caa0ea92503f8afa1941f6ac899e5c4e3f6ec8bb
CVE: CVE-2023-53005
Published: 2025-03-27
Description: In the Linux kernel, the following vulnerability has been resolved:

trace_events_hist: add check for return value of 'create_hist_field'

Function 'create_hist_field' is called recursively at
trace_events_hist.c:1954 and can return NULL-value that's why we have
to check it to avoid null pointer dereference.

Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/31b2414abeaa6de0490e85164badc6dcb1bb8ec9; https://git.kernel.org/stable/c/592ba7116fa620425725ff0972691f352ba3caf6; https://git.kernel.org/stable/c/886aa449235f478e262bbd5dcdee6ed6bc202949
CVE: CVE-2023-53006
Published: 2025-03-27
Description: In the Linux kernel, the following vulnerability has been resolved:

cifs: Fix oops due to uncleared server->smbd_conn in reconnect

In smbd_destroy(), clear the server->smbd_conn pointer after freeing the
smbd_connection struct that it points to so that reconnection doesn't get
confused.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/4b83bc6f87eedab4599b0123e572a422689444be; https://git.kernel.org/stable/c/5109607a4ece7cd8536172bf7549eb4dce1f3576; https://git.kernel.org/stable/c/91be54849d5392050f5b847b42bd5e6221551ac8
CVE: CVE-2023-53007
Published: 2025-03-27
Description: In the Linux kernel, the following vulnerability has been resolved:

tracing: Make sure trace_printk() can output as soon as it can be used

Currently trace_printk() can be used as soon as early_trace_init() is
called from start_kernel(). But if a crash happens, and
"ftrace_dump_on_oops" is set on the kernel command line, all you get will
be:

  [    0.456075]   <idle>-0         0dN.2. 347519us : Unknown type 6
  [    0.456075]   <idle>-0         0dN.2. 353141us : Unknown type 6
  [    0.456075]   <idle>-0         0dN.2. 358684us : Unknown type 6

This is because the trace_printk() event (type 6) hasn't been registered
yet. That gets done via an early_initcall(), which may be early, but not
early enough.

Instead of registering the trace_printk() event (and other ftrace events,
which are not trace events) via an early_initcall(), have them registered at
the same time that trace_printk() can be used. This way, if there is a
crash before early_initcall(), then the trace_printk()s will actually be
useful.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/198c83963f6335ca6d690cff067679560f2a3a22; https://git.kernel.org/stable/c/3bb06eb6e9acf7c4a3e1b5bc87aed398ff8e2253; https://git.kernel.org/stable/c/76b2390fdc80c0a8300e5da5b6b62d201b6fe9ce
CVE: CVE-2023-53008
Published: 2025-03-27
Description: In the Linux kernel, the following vulnerability has been resolved:

cifs: fix potential memory leaks in session setup

Make sure to free cifs_ses::auth_key.response before allocating it as
we might end up leaking memory in reconnect or mounting.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/2fe58d977ee05da5bb89ef5dc4f5bf2dc15db46f; https://git.kernel.org/stable/c/893d45394dbe4b5cbf3723c19e2ccc8b93a6ac9b
CVE: CVE-2023-53009
Published: 2025-03-27
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdkfd: Add sync after creating vram bo

There will be data corruption on vram allocated by svm
if the initialization is not complete and application is
writting on the memory. Adding sync to wait for the
initialization completion is to resolve this issue.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/92af2d3b57a1afdfdcafb1c6a07ffd89cf3e98fb; https://git.kernel.org/stable/c/ba029e9991d9be90a28b6a0ceb25e9a6fb348829
CVE: CVE-2023-53010
Published: 2025-03-27
Description: In the Linux kernel, the following vulnerability has been resolved:

bnxt: Do not read past the end of test names

Test names were being concatenated based on a offset beyond the end of
the first name, which tripped the buffer overflow detection logic:

 detected buffer overflow in strnlen
 [...]
 Call Trace:
 bnxt_ethtool_init.cold+0x18/0x18

Refactor struct hwrm_selftest_qlist_output to use an actual array,
and adjust the concatenation to use snprintf() rather than a series of
strncat() calls.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/cefa85480ac99c0bef5a09daadb48d65fc28e279; https://git.kernel.org/stable/c/d3e599c090fc[PII_REDACTED]c5f0a69ab8ce87da21
CVE: CVE-2023-53011
Published: 2025-03-27
Description: In the Linux kernel, the following vulnerability has been resolved:

net: stmmac: enable all safety features by default

In the original implementation of dwmac5
commit 8bf993a5877e ("net: stmmac: Add support for DWMAC5 and implement Safety Features")
all safety features were enabled by default.

Later it seems some implementations didn't have support for all the
features, so in
commit 5ac712dcdfef ("net: stmmac: enable platform specific safety features")
the safety_feat_cfg structure was added to the callback and defined for
some platforms to selectively enable these safety features.

The problem is that only certain platforms were given that software
support. If the automotive safety package bit is set in the hardware
features register the safety feature callback is called for the platform,
and for platforms that didn't get a safety_feat_cfg defined this results
in the following NULL pointer dereference:

[    7.933303] Call trace:
[    7.935812]  dwmac5_safety_feat_config+0x20/0x170 [stmmac]
[    7.941455]  __stmmac_open+0x16c/0x474 [stmmac]
[    7.946117]  stmmac_open+0x38/0x70 [stmmac]
[    7.950414]  __dev_open+0x100/0x1dc
[    7.954006]  __dev_change_flags+0x18c/0x204
[    7.958297]  dev_change_flags+0x24/0x6c
[    7.962237]  do_setlink+0x2b8/0xfa4
[    7.965827]  __rtnl_newlink+0x4ec/0x840
[    7.969766]  rtnl_newlink+0x50/0x80
[    7.973353]  rtnetlink_rcv_msg+0x12c/0x374
[    7.977557]  netlink_rcv_skb+0x5c/0x130
[    7.981500]  rtnetlink_rcv+0x18/0x2c
[    7.985172]  netlink_unicast+0x2e8/0x340
[    7.989197]  netlink_sendmsg+0x1a8/0x420
[    7.993222]  ____sys_sendmsg+0x218/0x280
[    7.997249]  ___sys_sendmsg+0xac/0x100
[    8.001103]  __sys_sendmsg+0x84/0xe0
[    8.004776]  __arm64_sys_sendmsg+0x24/0x30
[    8.008983]  invoke_syscall+0x48/0x114
[    8.012840]  el0_svc_common.constprop.0+0xcc/0xec
[    8.017665]  do_el0_svc+0x38/0xb0
[    8.021071]  el0_svc+0x2c/0x84
[    8.024212]  el0t_64_sync_handler+0xf4/0x120
[    8.028598]  el0t_64_sync+0x190/0x194

Go back to the original behavior, if the automotive safety package
is found to be supported in hardware enable all the features unless
safety_feat_cfg is passed in saying this particular platform only
supports a subset of the features.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/120b8e527e07c65de7f2b9018dcd9d17e66f2427; https://git.kernel.org/stable/c/aebf7e62708ba706ee7bf484c9023b15c214e92a; https://git.kernel.org/stable/c/fdfc76a116b5e9d3e98e6c96fe83b42d011d21d4
CVE: CVE-2023-53012
Published: 2025-03-27
Description: In the Linux kernel, the following vulnerability has been resolved:

thermal: core: call put_device() only after device_register() fails

put_device() shouldn't be called before a prior call to
device_register(). __thermal_cooling_device_register() doesn't follow
that properly and needs fixing. Also
thermal_cooling_device_destroy_sysfs() is getting called unnecessarily
on few error paths.

Fix all this by placing the calls at the right place.

Based on initial work done by Caleb Connolly.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2846a7412f6246fd5171f51011bf76dfebcec0ee; https://git.kernel.org/stable/c/6c54b7bc8a31ce0f7cc7f8deef05067df414f1d8; https://git.kernel.org/stable/c/a7d736cc3c6cb0d7498bbfb56515d414e35e9510
CVE: CVE-2023-53013
Published: 2025-03-27
Description: In the Linux kernel, the following vulnerability has been resolved:

ptdma: pt_core_execute_cmd() should use spinlock

The interrupt handler (pt_core_irq_handler()) of the ptdma
driver can be called from interrupt context. The code flow
in this function can lead down to pt_core_execute_cmd() which
will attempt to grab a mutex, which is not appropriate in
interrupt context and ultimately leads to a kernel panic.
The fix here changes this mutex to a spinlock, which has
been verified to resolve the issue.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667, CWE-667
References: https://git.kernel.org/stable/c/13ba563c2c8055ba8a637c9f70bb833b43cb4207; https://git.kernel.org/stable/c/95e5fda3b5f9ed8239b145da3fa01e641cf5d53c; https://git.kernel.org/stable/c/ed0d8f731e0bf1bb12a7a37698ac613db20e2794
CVE: CVE-2023-53014
Published: 2025-03-27
Description: In the Linux kernel, the following vulnerability has been resolved:

dmaengine: tegra: Fix memory leak in terminate_all()

Terminate vdesc when terminating an ongoing transfer.
This will ensure that the vdesc is present in the desc_terminated list
The descriptor will be freed later in desc_free_list().

This fixes the memory leaks which can happen when terminating an
ongoing transfer.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/567128076d554e41609c61b7d447089094ff72c5; https://git.kernel.org/stable/c/a7a7ee6f5a019ad72852c001abbce50d35e992f2
CVE: CVE-2023-53015
Published: 2025-03-27
Description: In the Linux kernel, the following vulnerability has been resolved:

HID: betop: check shape of output reports

betopff_init() only checks the total sum of the report counts for each
report field to be at least 4, but hid_betopff_play() expects 4 report
fields.
A device advertising an output report with one field and 4 report counts
would pass the check but crash the kernel with a NULL pointer dereference
in hid_betopff_play().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/07bc32e53c7bd5c91472cc485231ef6274db9b76; https://git.kernel.org/stable/c/1a2a47b85cab50a3c146731bfeaf2d860f5344ee; https://git.kernel.org/stable/c/28fc6095da22dc88433d79578ae1c495ebe8ca43
CVE: CVE-2023-53016
Published: 2025-03-27
Description: In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: Fix possible deadlock in rfcomm_sk_state_change

syzbot reports a possible deadlock in rfcomm_sk_state_change [1].
While rfcomm_sock_connect acquires the sk lock and waits for
the rfcomm lock, rfcomm_sock_release could have the rfcomm
lock and hit a deadlock for acquiring the sk lock.
Here's a simplified flow:

rfcomm_sock_connect:
  lock_sock(sk)
  rfcomm_dlc_open:
    rfcomm_lock()

rfcomm_sock_release:
  rfcomm_sock_shutdown:
    rfcomm_lock()
    __rfcomm_dlc_close:
        rfcomm_k_state_change:
	  lock_sock(sk)

This patch drops the sk lock before calling rfcomm_dlc_open to
avoid the possible deadlock and holds sk's reference count to
prevent use-after-free after rfcomm_dlc_open completes.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-416, CWE-667, CWE-667
References: https://git.kernel.org/stable/c/17511bd84871f4a6106cb335616e086880313f3f; https://git.kernel.org/stable/c/1d80d57ffcb55488f0ec0b77928d4f82d16b6a90; https://git.kernel.org/stable/c/98aec50ff7f60cc6f2d6a4396b475c547e58b04d
CVE: CVE-2023-53017
Published: 2025-03-27
Description: In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_sync: fix memory leak in hci_update_adv_data()

When hci_cmd_sync_queue() failed in hci_update_adv_data(), inst_ptr is
not freed, which will cause memory leak, convert to use ERR_PTR/PTR_ERR
to pass the instance to callback so no memory needs to be allocated.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/1ed8b37cbaf14574c779064ef1372af62e8ba6aa; https://git.kernel.org/stable/c/8ac6043bd3e5b58d30f50737aedc2e58e8087ad5
CVE: CVE-2023-53018
Published: 2025-03-27
Description: In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_conn: Fix memory leaks

When hci_cmd_sync_queue() failed in hci_le_terminate_big() or
hci_le_big_terminate(), the memory pointed by variable d is not freed,
which will cause memory leak. Add release process to error path.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/3aa21311f36d8a2730c7ccef37235e951f23927b; https://git.kernel.org/stable/c/f51a825b9f730a782aa768454906b4468e67b667
CVE: CVE-2023-53019
Published: 2025-03-27
Description: In the Linux kernel, the following vulnerability has been resolved:

net: mdio: validate parameter addr in mdiobus_get_phy()

The caller may pass any value as addr, what may result in an out-of-bounds
access to array mdio_map. One existing case is stmmac_init_phy() that
may pass -1 as addr. Therefore validate addr before using it.
CVSS Score: 7.8 (HIGH)
CWE: CWE-129
References: https://git.kernel.org/stable/c/1d80c259dfbadefa61b7ea334dfce5cb57f8c72f; https://git.kernel.org/stable/c/4bc5f1f6bc94e695dfd912122af96e7115a0ddb8; https://git.kernel.org/stable/c/[PII_REDACTED]e6ffd838ae0f2af1ab49ee46354973
CVE: CVE-2023-53020
Published: 2025-03-27
Description: In the Linux kernel, the following vulnerability has been resolved:

l2tp: close all race conditions in l2tp_tunnel_register()

The code in l2tp_tunnel_register() is racy in several ways:

1. It modifies the tunnel socket _after_ publishing it.

2. It calls setup_udp_tunnel_sock() on an existing socket without
   locking.

3. It changes sock lock class on fly, which triggers many syzbot
   reports.

This patch amends all of them by moving socket initialization code
before publishing and under sock lock. As suggested by Jakub, the
l2tp lockdep class is not necessary as we can just switch to
bh_lock_sock_nested().
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362, CWE-362
References: https://git.kernel.org/stable/c/0b2c59720e65885a394a017d0cf9cab118914682; https://git.kernel.org/stable/c/2d77e5c0ad79004b5ef901895437e9cce6dfcc7e; https://git.kernel.org/stable/c/77e8ed776cdb1a24b2aab8fe7c6f1f154235e1ce
CVE: CVE-2023-53022
Published: 2025-03-27
Description: In the Linux kernel, the following vulnerability has been resolved:

net: enetc: avoid deadlock in enetc_tx_onestep_tstamp()

This lockdep splat says it better than I could:

================================
WARNING: inconsistent lock state
6.2.0-rc2-07010-ga9b9500ffaac-dirty #967 Not tainted
--------------------------------
inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
kworker/1:3/179 [HC0[0]:SC0[0]:HE1:SE1] takes:
ffff3ec4036ce098 (_xmit_ETHER#2){+.?.}-{3:3}, at: netif_freeze_queues+0x5c/0xc0
{IN-SOFTIRQ-W} state was registered at:
  _raw_spin_lock+0x5c/0xc0
  sch_direct_xmit+0x148/0x37c
  __dev_queue_xmit+0x528/0x111c
  ip6_finish_output2+0x5ec/0xb7c
  ip6_finish_output+0x240/0x3f0
  ip6_output+0x78/0x360
  ndisc_send_skb+0x33c/0x85c
  ndisc_send_rs+0x54/0x12c
  addrconf_rs_timer+0x154/0x260
  call_timer_fn+0xb8/0x3a0
  __run_timers.part.0+0x214/0x26c
  run_timer_softirq+0x3c/0x74
  __do_softirq+0x14c/0x5d8
  ____do_softirq+0x10/0x20
  call_on_irq_stack+0x2c/0x5c
  do_softirq_own_stack+0x1c/0x30
  __irq_exit_rcu+0x168/0x1a0
  irq_exit_rcu+0x10/0x40
  el1_interrupt+0x38/0x64
irq event stamp: 7825
hardirqs last  enabled at (7825): [<ffffdf1f7200cae4>] exit_to_kernel_mode+0x34/0x130
hardirqs last disabled at (7823): [<ffffdf1f708105f0>] __do_softirq+0x550/0x5d8
softirqs last  enabled at (7824): [<ffffdf1f7081050c>] __do_softirq+0x46c/0x5d8
softirqs last disabled at (7811): [<ffffdf1f708166e0>] ____do_softirq+0x10/0x20

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(_xmit_ETHER#2);
  <Interrupt>
    lock(_xmit_ETHER#2);

 *** DEADLOCK ***

3 locks held by kworker/1:3/179:
 #0: ffff3ec400004748 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0
 #1: ffff80000a0bbdc8 ((work_completion)(&priv->tx_onestep_tstamp)){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0
 #2: ffff3ec4036cd438 (&dev->tx_global_lock){+.+.}-{3:3}, at: netif_tx_lock+0x1c/0x34

Workqueue: events enetc_tx_onestep_tstamp
Call trace:
 print_usage_bug.part.0+0x208/0x22c
 mark_lock+0x7f0/0x8b0
 __lock_acquire+0x7c4/0x1ce0
 lock_acquire.part.0+0xe0/0x220
 lock_acquire+0x68/0x84
 _raw_spin_lock+0x5c/0xc0
 netif_freeze_queues+0x5c/0xc0
 netif_tx_lock+0x24/0x34
 enetc_tx_onestep_tstamp+0x20/0x100
 process_one_work+0x28c/0x6c0
 worker_thread+0x74/0x450
 kthread+0x118/0x11c

but I'll say it anyway: the enetc_tx_onestep_tstamp() work item runs in
process context, therefore with softirqs enabled (i.o.w., it can be
interrupted by a softirq). If we hold the netif_tx_lock() when there is
an interrupt, and the NET_TX softirq then gets scheduled, this will take
the netif_tx_lock() a second time and deadlock the kernel.

To solve this, use netif_tx_lock_bh(), which blocks softirqs from
running.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667, CWE-667
References: https://git.kernel.org/stable/c/3c463721a73bdb57a913e0d3124677a3758886fc; https://git.kernel.org/stable/c/8232e5a84d25a84a5cbda0f241a00793fb6eb608; https://git.kernel.org/stable/c/e893dced1a18e77b1262f5c10169413f0ece0da7
CVE: CVE-2023-53025
Published: 2025-03-27
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.