deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2023-53460
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: rtw88: fix memory leak in rtw_usb_probe()

drivers/net/wireless/realtek/rtw88/usb.c:876 rtw_usb_probe()
warn: 'hw' from ieee80211_alloc_hw() not released on lines: 811

Fix this by modifying return to a goto statement.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/48181d285623198c33bb[PII_REDACTED]687b258efa; https://git.kernel.org/stable/c/6cc92379b80af005e1f49ef6ef790cddc58cf0da
CVE: CVE-2023-53461
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

io_uring: wait interruptibly for request completions on exit

WHen the ring exits, cleanup is done and the final cancelation and
waiting on completions is done by io_ring_exit_work. That function is
invoked by kworker, which doesn't take any signals. Because of that, it
doesn't really matter if we wait for completions in TASK_INTERRUPTIBLE
or TASK_UNINTERRUPTIBLE state. However, it does matter to the hung task
detection checker!

Normally we expect cancelations and completions to happen rather
quickly. Some test cases, however, will exit the ring and park the
owning task stopped (eg via SIGSTOP). If the owning task needs to run
task_work to complete requests, then io_ring_exit_work won't make any
progress until the task is runnable again. Hence io_ring_exit_work can
trigger the hung task detection, which is particularly problematic if
panic-on-hung-task is enabled.

As the ring exit doesn't take signals to begin with, have it wait
interruptibly rather than uninterruptibly. io_uring has a separate
stuck-exit warning that triggers independently anyway, so we're not
really missing anything by making this switch.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/28e649dc9947e6525c95e32aa9a8e147925e3f56; https://git.kernel.org/stable/c/4826c59453b3b4677d6bf72814e7ababdea86949; https://git.kernel.org/stable/c/58e80cb68b057e974768792c34708c[PII_REDACTED]
CVE: CVE-2023-53462
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

hsr: Fix uninit-value access in fill_frame_info()

Syzbot reports the following uninit-value access problem.

=====================================================
BUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:601 [inline]
BUG: KMSAN: uninit-value in hsr_forward_skb+0x9bd/0x30f0 net/hsr/hsr_forward.c:616
 fill_frame_info net/hsr/hsr_forward.c:601 [inline]
 hsr_forward_skb+0x9bd/0x30f0 net/hsr/hsr_forward.c:616
 hsr_dev_xmit+0x192/0x330 net/hsr/hsr_device.c:223
 __netdev_start_xmit include/linux/netdevice.h:4889 [inline]
 netdev_start_xmit include/linux/netdevice.h:4903 [inline]
 xmit_one net/core/dev.c:3544 [inline]
 dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3560
 __dev_queue_xmit+0x34d0/0x52a0 net/core/dev.c:4340
 dev_queue_xmit include/linux/netdevice.h:3082 [inline]
 packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276
 packet_snd net/packet/af_packet.c:3087 [inline]
 packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119
 sock_sendmsg_nosec net/socket.c:730 [inline]
 sock_sendmsg net/socket.c:753 [inline]
 __sys_sendto+0x781/0xa30 net/socket.c:2176
 __do_sys_sendto net/socket.c:2188 [inline]
 __se_sys_sendto net/socket.c:2184 [inline]
 __ia32_sys_sendto+0x11f/0x1c0 net/socket.c:2184
 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]
 __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178
 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203
 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246
 entry_SYSENTER_compat_after_hwframe+0x70/0x82

Uninit was created at:
 slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767
 slab_alloc_node mm/slub.c:3478 [inline]
 kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523
 kmalloc_reserve+0x148/0x470 net/core/skbuff.c:559
 __alloc_skb+0x318/0x740 net/core/skbuff.c:644
 alloc_skb include/linux/skbuff.h:1286 [inline]
 alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6299
 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2794
 packet_alloc_skb net/packet/af_packet.c:2936 [inline]
 packet_snd net/packet/af_packet.c:3030 [inline]
 packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119
 sock_sendmsg_nosec net/socket.c:730 [inline]
 sock_sendmsg net/socket.c:753 [inline]
 __sys_sendto+0x781/0xa30 net/socket.c:2176
 __do_sys_sendto net/socket.c:2188 [inline]
 __se_sys_sendto net/socket.c:2184 [inline]
 __ia32_sys_sendto+0x11f/0x1c0 net/socket.c:2184
 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]
 __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178
 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203
 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246
 entry_SYSENTER_compat_after_hwframe+0x70/0x82

It is because VLAN not yet supported in hsr driver. Return error
when protocol is ETH_P_8021Q in fill_frame_info() now to fix it.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/1e90a93ac4845c31724ec5dc96fb51e608435a9d; https://git.kernel.org/stable/c/484b4833c604c0adcf19eac1ca14b60b757355b5; https://git.kernel.org/stable/c/61866f7d814e5792bf47410d7d3ff32e49bd292a
CVE: CVE-2023-53463
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

ibmvnic: Do not reset dql stats on NON_FATAL err

All ibmvnic resets, make a call to netdev_tx_reset_queue() when
re-opening the device. netdev_tx_reset_queue() resets the num_queued
and num_completed byte counters. These stats are used in Byte Queue
Limit (BQL) algorithms. The difference between these two stats tracks
the number of bytes currently sitting on the physical NIC. ibmvnic
increases the number of queued bytes though calls to
netdev_tx_sent_queue() in the drivers xmit function. When, VIOS reports
that it is done transmitting bytes, the ibmvnic device increases the
number of completed bytes through calls to netdev_tx_completed_queue().
It is important to note that the driver batches its transmit calls and
num_queued is increased every time that an skb is added to the next
batch, not necessarily when the batch is sent to VIOS for transmission.

Unlike other reset types, a NON FATAL reset will not flush the sub crq
tx buffers. Therefore, it is possible for the batched skb array to be
partially full. So if there is call to netdev_tx_reset_queue() when
re-opening the device, the value of num_queued (0) would not account
for the skb's that are currently batched. Eventually, when the batch
is sent to VIOS, the call to netdev_tx_completed_queue() would increase
num_completed to a value greater than the num_queued. This causes a
BUG_ON crash:

ibmvnic 30000002: Firmware reports error, cause: adapter problem.
Starting recovery...
ibmvnic 30000002: tx error 600
ibmvnic 30000002: tx error 600
ibmvnic 30000002: tx error 600
ibmvnic 30000002: tx error 600
------------[ cut here ]------------
kernel BUG at lib/dynamic_queue_limits.c:27!
Oops: Exception in kernel mode, sig: 5
[....]
NIP dql_completed+0x28/0x1c0
LR ibmvnic_complete_tx.isra.0+0x23c/0x420 [ibmvnic]
Call Trace:
ibmvnic_complete_tx.isra.0+0x3f8/0x420 [ibmvnic] (unreliable)
ibmvnic_interrupt_tx+0x40/0x70 [ibmvnic]
__handle_irq_event_percpu+0x98/0x270
---[ end trace ]---

Therefore, do not reset the dql stats when performing a NON_FATAL reset.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/48538ccb825b05544ec308a509e2cc9c013402db; https://git.kernel.org/stable/c/91a0632e73070928aafeb36b3cc676843c716931; https://git.kernel.org/stable/c/b8aedf29db1280c83191fc9579ae605791faf97f
CVE: CVE-2023-53464
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: iscsi_tcp: Check that sock is valid before iscsi_set_param()

The validity of sock should be checked before assignment to avoid incorrect
values. Commit 57569c37f0ad ("scsi: iscsi: iscsi_tcp: Fix null-ptr-deref
while calling getpeername()") introduced this change which may lead to
inconsistent values of tcp_sw_conn->sendpage and conn->datadgst_en.

Fix the issue by moving the position of the assignment.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/48b19b79cfa37b1e50da3b5a8af529f994c08901; https://git.kernel.org/stable/c/499757ad3332e2527254f9ab68dec1da087b1d96; https://git.kernel.org/stable/c/5e5c5f472972c4bc9430adc08b36763a0fa5b9f7
CVE: CVE-2023-53465
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

soundwire: qcom: fix storing port config out-of-bounds

The 'qcom_swrm_ctrl->pconfig' has size of QCOM_SDW_MAX_PORTS (14),
however we index it starting from 1, not 0, to match real port numbers.
This can lead to writing port config past 'pconfig' bounds and
overwriting next member of 'qcom_swrm_ctrl' struct.  Reported also by
smatch:

  drivers/soundwire/qcom.c:1269 qcom_swrm_get_port_config() error: buffer overflow 'ctrl->pconfig' 14 <= 14
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/20f7c4d51c94abb1a1a7c21900db4fb5afe5c8ff; https://git.kernel.org/stable/c/32eb67d7360d48c15883e0d21b29c0aab9da022e; https://git.kernel.org/stable/c/490937d479abe5f6584e69b96df066bc87be92e9
CVE: CVE-2023-53466
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: mt7915: fix memory leak in mt7915_mcu_exit

Always purge mcu skb queues in mt7915_mcu_exit routine even if
mt7915_firmware_state fails.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/3095fe1e1d3198e62a3c7116c4cf7c734871475f; https://git.kernel.org/stable/c/49bd78282e79ad177d14f37f4049f0605bf92dad; https://git.kernel.org/stable/c/4cbb876153b63fe248200f734069c6881cf97722
CVE: CVE-2023-53467
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: rtw89: fix potential leak in rtw89_append_probe_req_ie()

Do `kfree_skb(new)` before `goto out` to prevent potential leak.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/1e336d6bab68973084a18c1e4bd78cd0bbbdcacd; https://git.kernel.org/stable/c/4a0e218cc9c42d1903ade8b5a371dcf48cf918c5; https://git.kernel.org/stable/c/a10b6d73123bd480751d916575835abb615072fd
CVE: CVE-2023-53468
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

ubifs: Fix memory leak in alloc_wbufs()

kmemleak reported a sequence of memory leaks, and show them as following:

  unreferenced object 0xffff8881575f8400 (size 1024):
    comm "mount", pid 19625, jiffies[PII_REDACTED] (age 20.383s)
    hex dump (first 32 bytes):
      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    backtrace:
      [<ffffffff8176cecd>] __kmalloc+0x4d/0x150
      [<ffffffffa0406b2b>] ubifs_mount+0x307b/0x7170 [ubifs]
      [<ffffffff819fa8fd>] legacy_get_tree+0xed/0x1d0
      [<ffffffff81936f2d>] vfs_get_tree+0x7d/0x230
      [<ffffffff819b2bd4>] path_mount+0xdd4/0x17b0
      [<ffffffff819b37aa>] __x64_sys_mount+0x1fa/0x270
      [<ffffffff83c14295>] do_syscall_64+0x35/0x80
      [<ffffffff83e0006a>] entry_SYSCALL_64_after_hwframe+0x46/0xb0

  unreferenced object 0xffff8881798a6e00 (size 512):
    comm "mount", pid 19677, jiffies[PII_REDACTED] (age 37.816s)
    hex dump (first 32 bytes):
      6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
      6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
    backtrace:
      [<ffffffff8176cecd>] __kmalloc+0x4d/0x150
      [<ffffffffa0418342>] ubifs_wbuf_init+0x52/0x480 [ubifs]
      [<ffffffffa0406ca5>] ubifs_mount+0x31f5/0x7170 [ubifs]
      [<ffffffff819fa8fd>] legacy_get_tree+0xed/0x1d0
      [<ffffffff81936f2d>] vfs_get_tree+0x7d/0x230
      [<ffffffff819b2bd4>] path_mount+0xdd4/0x17b0
      [<ffffffff819b37aa>] __x64_sys_mount+0x1fa/0x270
      [<ffffffff83c14295>] do_syscall_64+0x35/0x80
      [<ffffffff83e0006a>] entry_SYSCALL_64_after_hwframe+0x46/0xb0

The problem is that the ubifs_wbuf_init() returns an error in the
loop which in the alloc_wbufs(), then the wbuf->buf and wbuf->inodes
that were successfully alloced before are not freed.

Fix it by adding error hanging path in alloc_wbufs() which frees
the memory alloced before when ubifs_wbuf_init() returns an error.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/1f206002c6bc302bface871ef3f72c0bbcaa931c; https://git.kernel.org/stable/c/26ec45f1c504e[PII_REDACTED]df139d7983f1e67f; https://git.kernel.org/stable/c/3e29634eb56e6547272fe4e568f63421f8b3b9fa
CVE: CVE-2023-53469
Published: 2025-10-01
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2023-53470
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

ionic: catch failure from devlink_alloc

Add a check for NULL on the alloc return.  If devlink_alloc() fails and
we try to use devlink_priv() on the NULL return, the kernel gets very
unhappy and panics. With this fix, the driver load will still fail,
but at least it won't panic the kernel.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0020c16c8af7f4bc9503a2088fb30793b6771fac; https://git.kernel.org/stable/c/0d02efe7f25158c93146e3bb827bc7bb3cd5e71a; https://git.kernel.org/stable/c/4a54903ff68ddb33b6463c94b4eb37fc584ef760
CVE: CVE-2023-53471
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu/gfx: disable gfx9 cp_ecc_error_irq only when enabling legacy gfx ras

gfx9 cp_ecc_error_irq is only enabled when legacy gfx ras is assert.
So in gfx_v9_0_hw_fini, interrupt disablement for cp_ecc_error_irq
should be executed under such condition, otherwise, an amdgpu_irq_put
calltrace will occur.

[ 7283.170322] RIP: 0010:amdgpu_irq_put+0x45/0x70 [amdgpu]
[ 7283.170964] RSP: 0018:ffff9a5fc3967d00 EFLAGS: 00010246
[ 7283.170967] RAX: ffff98d88afd3040 RBX: ffff98d89da20000 RCX: [PII_REDACTED]
[ 7283.170969] RDX: [PII_REDACTED] RSI: ffff98d89da2bef8 RDI: ffff98d89da20000
[ 7283.170971] RBP: ffff98d89da20000 R08: ffff98d89da2ca18 R09: [PII_REDACTED]
[ 7283.170973] R10: ffffd5764243c008 R11: [PII_REDACTED] R12: [PII_REDACTED]
[ 7283.170975] R13: ffff98d89da38978 R14: ffffffff999ae15a R15: ffff98d880130105
[ 7283.170978] FS:  [PII_REDACTED](0000) GS:ffff98d996f00000(0000) knlGS:[PII_REDACTED]
[ 7283.170981] CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
[ 7283.170983] CR2: 00000000f7a9d178 CR3: 00000001c42ea000 CR4:[PII_REDACTED]3506e0
[ 7283.170986] Call Trace:
[ 7283.170988]  <TASK>
[ 7283.170989]  gfx_v9_0_hw_fini+0x1c/0x6d0 [amdgpu]
[ 7283.171655]  amdgpu_device_ip_suspend_phase2+0x101/0x1a0 [amdgpu]
[ 7283.172245]  amdgpu_device_suspend+0x103/0x180 [amdgpu]
[ 7283.172823]  amdgpu_pmops_freeze+0x21/0x60 [amdgpu]
[ 7283.173412]  pci_pm_freeze+0x54/0xc0
[ 7283.173419]  ? __pfx_pci_pm_freeze+0x10/0x10
[ 7283.173425]  dpm_run_callback+0x98/0x200
[ 7283.173430]  __device_suspend+0x164/0x5f0

v2: drop gfx11 as it's fixed in a different solution by retiring cp_ecc_irq funcs(Hawking)
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/20ca90ceda71ed90a4d6960acbe7d5e120b40c0d; https://git.kernel.org/stable/c/3d28af21a874c5123d1681c2d686627f7ff7e488; https://git.kernel.org/stable/c/4a[PII_REDACTED]0aefe5074bed8f06afa354b85c48
CVE: CVE-2023-53472
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

pwm: lpc32xx: Remove handling of PWM channels

Because LPC32xx PWM controllers have only a single output which is
registered as the only PWM device/channel per controller, it is known in
advance that pwm->hwpwm value is always 0. On basis of this fact
simplify the code by removing operations with pwm->hwpwm, there is no
controls which require channel number as input.

Even though I wasn't aware at the time when I forward ported that patch,
this fixes a null pointer dereference as lpc32xx->chip.pwms is NULL
before devm_pwmchip_add() is called.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/04301da4d87067a989f70ee56942bf9d97cd2a45; https://git.kernel.org/stable/c/4aae44f65827f0213a7361cf9c32cfe06114473f; https://git.kernel.org/stable/c/523f6268e86552a[PII_REDACTED]51184c4e9a4b38f
CVE: CVE-2023-53473
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: improve error handling from ext4_dirhash()

The ext4_dirhash() will *almost* never fail, especially when the hash
tree feature was first introduced.  However, with the addition of
support of encrypted, casefolded file names, that function can most
certainly fail today.

So make sure the callers of ext4_dirhash() properly check for
failures, and reflect the errors back up to their callers.
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/4b3cb1d108bfc2aebb0d7c8a52261a53cf7f5786; https://git.kernel.org/stable/c/70d579aefa652a06af97e013e3fbbabbe5a43553; https://git.kernel.org/stable/c/b[PII_REDACTED]deb3f479c4fa1bcd787b74b8faa6a
CVE: CVE-2023-53474
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/MCE/AMD: Use an u64 for bank_map

Thee maximum number of MCA banks is 64 (MAX_NR_BANKS), see

  a0bc32b3cacf ("x86/mce: Increase maximum number of banks to 64").

However, the bank_map which contains a bitfield of which banks to
initialize is of type unsigned int and that overflows when those bit
numbers are >= 32, leading to UBSAN complaining correctly:

  UBSAN: shift-out-of-bounds in arch/x86/kernel/cpu/mce/amd.c:1365:38
  shift exponent 32 is too large for 32-bit type 'int'

Change the bank_map to a u64 and use the proper BIT_ULL() macro when
modifying bits in there.

  [ bp: Rewrite commit message. ]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190
References: https://git.kernel.org/stable/c/11c58a0c1937c157dbdf82d5ab634d68c99f3098; https://git.kernel.org/stable/c/4c1cdec319b9aadb65737c3eb1f5cb74bd6aa156; https://git.kernel.org/stable/c/67bb7521b6420d81dab7538c0686f18f7d6d09f4
CVE: CVE-2023-53475
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: xhci: tegra: fix sleep in atomic call

When we set the dual-role port to Host mode, we observed the following
splat:
[  167.057718] BUG: sleeping function called from invalid context at
include/linux/sched/mm.h:229
[  167.057872] Workqueue: events tegra_xusb_usb_phy_work
[  167.057954] Call trace:
[  167.057962]  dump_backtrace+0x0/0x210
[  167.057996]  show_stack+0x30/0x50
[  167.058020]  dump_stack_lvl+0x64/0x84
[  167.058065]  dump_stack+0x14/0x34
[  167.058100]  __might_resched+0x144/0x180
[  167.058140]  __might_sleep+0x64/0xd0
[  167.058171]  slab_pre_alloc_hook.constprop.0+0xa8/0x110
[  167.058202]  __kmalloc_track_caller+0x74/0x2b0
[  167.058233]  kvasprintf+0xa4/0x190
[  167.058261]  kasprintf+0x58/0x90
[  167.058285]  tegra_xusb_find_port_node.isra.0+0x58/0xd0
[  167.058334]  tegra_xusb_find_port+0x38/0xa0
[  167.058380]  tegra_xusb_padctl_get_usb3_companion+0x38/0xd0
[  167.058430]  tegra_xhci_id_notify+0x8c/0x1e0
[  167.058473]  notifier_call_chain+0x88/0x100
[  167.058506]  atomic_notifier_call_chain+0x44/0x70
[  167.058537]  tegra_xusb_usb_phy_work+0x60/0xd0
[  167.058581]  process_one_work+0x1dc/0x4c0
[  167.058618]  worker_thread+0x54/0x410
[  167.058650]  kthread+0x188/0x1b0
[  167.058672]  ret_from_fork+0x10/0x20

The function tegra_xusb_padctl_get_usb3_companion eventually calls
tegra_xusb_find_port and this in turn calls kasprintf which might sleep
and so cannot be called from an atomic context.

Fix this by moving the call to tegra_xusb_padctl_get_usb3_companion to
the tegra_xhci_id_work function where it is really needed.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1122474b757a5dd8b2b50008a97f33cdb10dff6e; https://git.kernel.org/stable/c/130c61c516cd0684282a8f6ab163281d60642fc5; https://git.kernel.org/stable/c/1fe6015aa92cc0dfd875c1d3c7c1750a1b0767d9
CVE: CVE-2023-53476
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

iw_cxgb4: Fix potential NULL dereference in c4iw_fill_res_cm_id_entry()

This condition needs to match the previous "if (epcp->state == LISTEN) {"
exactly to avoid a NULL dereference of either "listen_ep" or "ep". The
problem is that "epcp" has been re-assigned so just testing
"if (epcp->state == LISTEN) {" a second time is not sufficient.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/24278dc380aab6a1aef0a75317f57ad4c2453cf6; https://git.kernel.org/stable/c/4ca446b127c568b59cb8d9748b6f70499624bb18; https://git.kernel.org/stable/c/76e0396313c79ecd0df44ee3c18745cfac52b3e6
CVE: CVE-2023-53477
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

ipv6: Add lwtunnel encap size of all siblings in nexthop calculation

In function rt6_nlmsg_size(), the length of nexthop is calculated
by multipling the nexthop length of fib6_info and the number of
siblings. However if the fib6_info has no lwtunnel but the siblings
have lwtunnels, the nexthop length is less than it should be, and
it will trigger a warning in inet6_rt_notify() as follows:

WARNING: CPU: 0 PID: 6082 at net/ipv6/route.c:6180 inet6_rt_notify+0x120/0x130
......
Call Trace:
 <TASK>
 fib6_add_rt2node+0x685/0xa30
 fib6_add+0x96/0x1b0
 ip6_route_add+0x50/0xd0
 inet6_rtm_newroute+0x97/0xa0
 rtnetlink_rcv_msg+0x156/0x3d0
 netlink_rcv_skb+0x5a/0x110
 netlink_unicast+0x246/0x350
 netlink_sendmsg+0x250/0x4c0
 sock_sendmsg+0x66/0x70
 ___sys_sendmsg+0x7c/0xd0
 __sys_sendmsg+0x5d/0xb0
 do_syscall_64+0x3f/0x90
 entry_SYSCALL_64_after_hwframe+0x72/0xdc

This bug can be reproduced by script:

ip -6 addr add 2002::2/64 dev ens2
ip -6 route add 100::/64 via 2002::1 dev ens2 metric 100

for i in 10 20 30 40 50 60 70;
do
	ip link add link ens2 name ipv_$i type ipvlan
	ip -6 addr add 2002::$i/64 dev ipv_$i
	ifconfig ipv_$i up
done

for i in 10 20 30 40 50 60;
do
	ip -6 route append 100::/64 encap ip6 dst 2002::$i via 2002::1
dev ipv_$i metric 100
done

ip -6 route append 100::/64 via 2002::1 dev ipv_70 metric 100

This patch fixes it by adding nexthop_len of every siblings using
rt6_nh_nlmsg_size().
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/4cc59f386991ec9374cb4bc83dbe1c0b5a95033f; https://git.kernel.org/stable/c/aa75d826c221e8d48607aef33836cf872a159cf1; https://git.kernel.org/stable/c/aba298b35619213ca787d08d472049627d8cd012
CVE: CVE-2023-53479
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

cxl/acpi: Fix a use-after-free in cxl_parse_cfmws()

KASAN and KFENCE detected an user-after-free in the CXL driver. This
happens in the cxl_decoder_add() fail path. KASAN prints the following
error:

   BUG: KASAN: slab-use-after-free in cxl_parse_cfmws (drivers/cxl/acpi.c:299)

This happens in cxl_parse_cfmws(), where put_device() is called,
releasing cxld, which is accessed later.

Use the local variables in the dev_err() instead of pointing to the
released memory. Since the dev_err() is printing a resource, change the open
coded print format to use the %pr format specifier.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/316db489647b8ddc381682597e89787eac61a278; https://git.kernel.org/stable/c/4cf67d3cc9994a59cf77bb9c0ccf9007fe916afe; https://git.kernel.org/stable/c/748fadc08bcbdaf573b34d9784bb3dbd87441dbf