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

udf: Do not bother merging very long extents

When merging very long extents we try to push as much length as possible
to the first extent. However this is unnecessarily complicated and not
really worth the trouble. Furthermore there was a bug in the logic
resulting in corrupting extents in the file as syzbot reproducer shows.
So just don't bother with the merging of extents that are too long
together.
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/3d20e3b768aff32112bdce8d3219d923ae75f9f1; https://git.kernel.org/stable/c/53cafe1d6d8ef9f93318e5bfccc0d24f27d41ced; https://git.kernel.org/stable/c/5d029799d381a9ee06209a222cae75f04c5d5304
CVE: CVE-2023-53507
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

net/mlx5: Unregister devlink params in case interface is down

Currently, in case an interface is down, mlx5 driver doesn't
unregister its devlink params, which leads to this WARN[1].
Fix it by unregistering devlink params in that case as well.

[1]
[  295.244769 ] WARNING: CPU: 15 PID: 1 at net/core/devlink.c:9042 devlink_free+0x174/0x1fc
[  295.488379 ] CPU: 15 PID: 1 Comm: shutdown Tainted: G S         OE 5.15.0-1017.19.3.g0677e61-bluefield #g0677e61
[  295.509330 ] Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS 4.2.0.12761 Jun  6 2023
[  295.543096 ] pc : devlink_free+0x174/0x1fc
[  295.551104 ] lr : mlx5_devlink_free+0x18/0x2c [mlx5_core]
[  295.561816 ] sp : ffff80000809b850
[  295.711155 ] Call trace:
[  295.716030 ]  devlink_free+0x174/0x1fc
[  295.723346 ]  mlx5_devlink_free+0x18/0x2c [mlx5_core]
[  295.733351 ]  mlx5_sf_dev_remove+0x98/0xb0 [mlx5_core]
[  295.743534 ]  auxiliary_bus_remove+0x2c/0x50
[  295.751893 ]  __device_release_driver+0x19c/0x280
[  295.761120 ]  device_release_driver+0x34/0x50
[  295.769649 ]  bus_remove_device+0xdc/0x170
[  295.777656 ]  device_del+0x17c/0x3a4
[  295.784620 ]  mlx5_sf_dev_remove+0x28/0xf0 [mlx5_core]
[  295.794800 ]  mlx5_sf_dev_table_destroy+0x98/0x110 [mlx5_core]
[  295.806375 ]  mlx5_unload+0x34/0xd0 [mlx5_core]
[  295.815339 ]  mlx5_unload_one+0x70/0xe4 [mlx5_core]
[  295.824998 ]  shutdown+0xb0/0xd8 [mlx5_core]
[  295.833439 ]  pci_device_shutdown+0x3c/0xa0
[  295.841651 ]  device_shutdown+0x170/0x340
[  295.849486 ]  __do_sys_reboot+0x1f4/0x2a0
[  295.857322 ]  __arm64_sys_reboot+0x2c/0x40
[  295.865329 ]  invoke_syscall+0x78/0x100
[  295.872817 ]  el0_svc_common.constprop.0+0x54/0x184
[  295.882392 ]  do_el0_svc+0x30/0xac
[  295.889008 ]  el0_svc+0x48/0x160
[  295.895278 ]  el0t_64_sync_handler+0xa4/0x130
[  295.903807 ]  el0t_64_sync+0x1a4/0x1a8
[  295.911120 ] ---[ end trace 4f1d2381d00d9dce  ]---
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/471f59b3455314f0cafacf[PII_REDACTED]876355a9; https://git.kernel.org/stable/c/53d737dfd3d7b023fa9fa445ea3f3db0ac9da402
CVE: CVE-2023-53508
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

ublk: fail to start device if queue setup is interrupted

In ublk_ctrl_start_dev(), if wait_for_completion_interruptible() is
interrupted by signal, queues aren't setup successfully yet, so we
have to fail UBLK_CMD_START_DEV, otherwise kernel oops can be triggered.

Reported by German when working on qemu-storage-deamon which requires
single thread ublk daemon.
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/0d5916c439574b18a0734872daa0022b3d6105ad; https://git.kernel.org/stable/c/53e7d08f6d6e214c40db1f51291bb2975c789dc2; https://git.kernel.org/stable/c/6ab3e7d424cd413d7a5e976c8a30b4ffa84a65dd
CVE: CVE-2023-53510
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: ufs: core: Fix handling of lrbp->cmd

ufshcd_queuecommand() may be called two times in a row for a SCSI command
before it is completed. Hence make the following changes:

 - In the functions that submit a command, do not check the old value of
   lrbp->cmd nor clear lrbp->cmd in error paths.

 - In ufshcd_release_scsi_cmd(), do not clear lrbp->cmd.

See also scsi_send_eh_cmnd().

This commit prevents that the following appears if a command times out:

WARNING: at drivers/ufs/core/ufshcd.c:2965 ufshcd_queuecommand+0x6f8/0x9a8
Call trace:
 ufshcd_queuecommand+0x6f8/0x9a8
 scsi_send_eh_cmnd+0x2c0/0x960
 scsi_eh_test_devices+0x100/0x314
 scsi_eh_ready_devs+0xd90/0x114c
 scsi_error_handler+0x2b4/0xb70
 kthread+0x16c/0x1e0
CVSS Score: 7.8 (HIGH)
CWE: CWE-415
References: https://git.kernel.org/stable/c/49234a401e161a2f2698f4612ab792c49b3cad1b; https://git.kernel.org/stable/c/549e91a9bbaa0ee480f[PII_REDACTED]1a61d369770; https://git.kernel.org/stable/c/b6d76d63c6d21d5d26c301a46853a2aee72397d5
CVE: CVE-2023-53511
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

io_uring: fix fget leak when fs don't support nowait buffered read

Heming reported a BUG when using io_uring doing link-cp on ocfs2. [1]

Do the following steps can reproduce this BUG:
mount -t ocfs2 /dev/vdc /mnt/ocfs2
cp testfile /mnt/ocfs2/
./link-cp /mnt/ocfs2/testfile /mnt/ocfs2/testfile.1
umount /mnt/ocfs2

Then umount will fail, and it outputs:
umount: /mnt/ocfs2: target is busy.

While tracing umount, it blames mnt_get_count() not return as expected.
Do a deep investigation for fget()/fput() on related code flow, I've
finally found that fget() leaks since ocfs2 doesn't support nowait
buffered read.

io_issue_sqe
|-io_assign_file  // do fget() first
  |-io_read
  |-io_iter_do_read
    |-ocfs2_file_read_iter  // return -EOPNOTSUPP
  |-kiocb_done
    |-io_rw_done
      |-__io_complete_rw_common  // set REQ_F_REISSUE
    |-io_resubmit_prep
      |-io_req_prep_async  // override req->file, leak happens

This was introduced by commit a196c78b5443 in v5.18. Fix it by don't
re-assign req->file if it has already been assigned.

[1] https://lore.kernel.org/ocfs2-devel/ab580a75-91c8-d68a-3455-40361be1bfa8@linux.alibaba.com/T/#t
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/10fb2e16ee6ffaf1716b9e90d007e6b300bfa457; https://git.kernel.org/stable/c/54aa7f2330b82884f4a1afce0220add6e8312f8b; https://git.kernel.org/stable/c/75a499fc9d66a32271e2b3e4ca71156e8ad3b484
CVE: CVE-2023-53512
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: mpt3sas: Fix a memory leak

Add a forgotten kfree().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/28137ea3eb05a87329a7154a8ff410d9e8bcc0a5; https://git.kernel.org/stable/c/30c7c72b6cf9d8c95f9b219c9d2e4e31b15bebe5; https://git.kernel.org/stable/c/378cc0eec4aa546ce1ae17515e2dfab719d4fb1e
CVE: CVE-2023-53513
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

nbd: fix incomplete validation of ioctl arg

We tested and found an alarm caused by nbd_ioctl arg without verification.
The UBSAN warning calltrace like below:

UBSAN: Undefined behaviour in fs/buffer.c:1709:35
signed integer overflow:
[PII_REDACTED]854775808 - 1 cannot be represented in type 'long long int'
CPU: 3 PID: 2523 Comm: syz-executor.0 Not tainted 4.19.90 #1
Hardware name: linux,dummy-virt (DT)
Call trace:
 dump_backtrace+0x0/0x3f0 arch/arm64/kernel/time.c:78
 show_stack+0x28/0x38 arch/arm64/kernel/traps.c:158
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x170/0x1dc lib/dump_stack.c:118
 ubsan_epilogue+0x18/0xb4 lib/ubsan.c:161
 handle_overflow+0x188/0x1dc lib/ubsan.c:192
 __ubsan_handle_sub_overflow+0x34/0x44 lib/ubsan.c:206
 __block_write_full_page+0x94c/0xa20 fs/buffer.c:1709
 block_write_full_page+0x1f0/0x280 fs/buffer.c:2934
 blkdev_writepage+0x34/0x40 fs/block_dev.c:607
 __writepage+0x68/0xe8 mm/page-writeback.c:2305
 write_cache_pages+0x44c/0xc70 mm/page-writeback.c:2240
 generic_writepages+0xdc/0x148 mm/page-writeback.c:2329
 blkdev_writepages+0x2c/0x38 fs/block_dev.c:2114
 do_writepages+0xd4/0x250 mm/page-writeback.c:2344

The reason for triggering this warning is __block_write_full_page()
-> i_size_read(inode) - 1 overflow.
inode->i_size is assigned in __nbd_ioctl() -> nbd_set_size() -> bytesize.
We think it is necessary to limit the size of arg to prevent errors.

Moreover, __nbd_ioctl() -> nbd_add_socket(), arg will be cast to int.
Assuming the value of arg is 0x[PII_REDACTED]0000001) (on a 64-bit machine),
it will become 1 after the coercion, which will return unexpected results.

Fix it by adding checks to prevent passing in too large numbers.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-674
References: https://git.kernel.org/stable/c/52851d0c3354b397c11d31dfeb8b2a2fc85a0002; https://git.kernel.org/stable/c/55793ea54d77719a071b1ccc05a05056e3b5e009; https://git.kernel.org/stable/c/fab766c8a1aff715bce7075aab40e780266f8e1a
CVE: CVE-2023-53514
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

gpu: host1x: Fix memory leak of device names

The device names allocated by dev_set_name() need be freed
before module unloading, but they can not be freed because
the kobject's refcount which was set in device_initialize()
has not be decreased to 0.

As comment of device_add() says, if it fails, use only
put_device() drop the refcount, then the name will be
freed in kobejct_cleanup().

device_del() and put_device() can be replaced with
device_unregister(), so call it to unregister the added
successfully devices, and just call put_device() to the
not added device.

Add a release() function to device to avoid null release()
function WARNING in device_release(), it's empty, because
the context devices are freed together in
host1x_memory_context_list_free().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/3ab0f5ddb761270b11d8c90b8550a59666cfc9bb; https://git.kernel.org/stable/c/55879dad0f3ae8468444b42f785ad79eac05fe5b; https://git.kernel.org/stable/c/958c6cbc32996c375af42db96ceba021a1959899
CVE: CVE-2023-53515
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

virtio-mmio: don't break lifecycle of vm_dev

vm_dev has a separate lifecycle because it has a 'struct device'
embedded. Thus, having a release callback for it is correct.

Allocating the vm_dev struct with devres totally breaks this protection,
though. Instead of waiting for the vm_dev release callback, the memory
is freed when the platform_device is removed. Resulting in a
use-after-free when finally the callback is to be called.

To easily see the problem, compile the kernel with
CONFIG_DEBUG_KOBJECT_RELEASE and unbind with sysfs.

The fix is easy, don't use devres in this case.

Found during my research about object lifetime problems.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/2dcb368fe5a8eee498ca75c93a18ce2f3b0d6a8e; https://git.kernel.org/stable/c/3ff54d904fafabd[PII_REDACTED]e53cce4e69ca123; https://git.kernel.org/stable/c/55c91fedd03d7b9cf0c5199b2eb12b9b8e95281a
CVE: CVE-2023-53516
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

macvlan: add forgotten nla_policy for IFLA_MACVLAN_BC_CUTOFF

The previous commit 954d1fa1ac93 ("macvlan: Add netlink attribute for
broadcast cutoff") added one additional attribute named
IFLA_MACVLAN_BC_CUTOFF to allow broadcast cutfoff.

However, it forgot to describe the nla_policy at macvlan_policy
(drivers/net/macvlan.c). Hence, this suppose NLA_S32 (4 bytes) integer
can be faked as empty (0 bytes) by a malicious user, which could leads
to OOB in heap just like CVE-2023-3773.

To fix it, this commit just completes the nla_policy description for
IFLA_MACVLAN_BC_CUTOFF. This enforces the length check and avoids the
potential OOB read.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/55cef78c244d0d076f5a75a35530ca63c92f4426; https://git.kernel.org/stable/c/79f44709aa7a744fbfbadd4aef678443290c6991
CVE: CVE-2023-53517
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

tipc: do not update mtu if msg_max is too small in mtu negotiation

When doing link mtu negotiation, a malicious peer may send Activate msg
with a very small mtu, e.g. 4 in Shuang's testing, without checking for
the minimum mtu, l->mtu will be set to 4 in tipc_link_proto_rcv(), then
n->links[bearer_id].mtu is set to[PII_REDACTED], which is a overflow of
'4 - INT_H_SIZE - EMSG_OVERHEAD' in tipc_link_mss().

With tipc_link.mtu = 4, tipc_link_xmit() kept printing the warning:

 tipc: Too large msg, purging xmit list 1 5 0 40 4!
 tipc: Too large msg, purging xmit list 1 15 0 60 4!

And with tipc_link_entry.mtu[PII_REDACTED], a huge skb was allocated in
named_distribute(), and when purging it in tipc_link_xmit(), a crash
was even caused:

  general protection fault, probably for non-canonical address 0x[PII_REDACTED]000dd: 0000 [#1] PREEMPT SMP PTI
  CPU: 0 PID: 0 Comm: swapper/0 Kdump: loaded Not tainted 6.3.0.neta #19
  RIP: 0010:kfree_skb_list_reason+0x7e/0x1f0
  Call Trace:
   <IRQ>
   skb_release_data+0xf9/0x1d0
   kfree_skb_reason+0x40/0x100
   tipc_link_xmit+0x57a/0x740 [tipc]
   tipc_node_xmit+0x16c/0x5c0 [tipc]
   tipc_named_node_up+0x27f/0x2c0 [tipc]
   tipc_node_write_unlock+0x149/0x170 [tipc]
   tipc_rcv+0x608/0x740 [tipc]
   tipc_udp_recv+0xdc/0x1f0 [tipc]
   udp_queue_rcv_one_skb+0x33e/0x620
   udp_unicast_rcv_skb.isra.72+0x75/0x90
   __udp4_lib_rcv+0x56d/0xc20
   ip_protocol_deliver_rcu+0x100/0x2d0

This patch fixes it by checking the new mtu against tipc_bearer_min_mtu(),
and not updating mtu if it is too small.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1dd7ae5e0cf5a56e513f7ab7ab9570b7496281d2; https://git.kernel.org/stable/c/259683001d7e879fea4b42084fb6560dd9408a7e; https://git.kernel.org/stable/c/2bd4ff4ffb92113f8acd04dbaed83269172c24b4
CVE: CVE-2023-53518
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

PM / devfreq: Fix leak in devfreq_dev_release()

srcu_init_notifier_head() allocates resources that need to be released
with a srcu_cleanup_notifier_head() call.

Reported by kmemleak.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/111bafa210ae546bee7644be730c42df9c35b66e; https://git.kernel.org/stable/c/1640e9c72173911ad0fddb05012c01eafe082c4e; https://git.kernel.org/stable/c/29811f4b8255d4238cf326f3bb[PII_REDACTED]beab
CVE: CVE-2023-53519
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

media: v4l2-mem2mem: add lock to protect parameter num_rdy

Getting below error when using KCSAN to check the driver. Adding lock to
protect parameter num_rdy when getting the value with function:
v4l2_m2m_num_src_bufs_ready/v4l2_m2m_num_dst_bufs_ready.

kworker/u16:3: [name:report&]BUG: KCSAN: data-race in v4l2_m2m_buf_queue
kworker/u16:3: [name:report&]

kworker/u16:3: [name:report&]read-write to 0xffffff8105f35b94 of 1 bytes by task 20865 on cpu 7:
kworker/u16:3:  v4l2_m2m_buf_queue+0xd8/0x10c
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/1676748aa29099fc0abd71e0fb092e76e835f25c; https://git.kernel.org/stable/c/56b5c3e67b0f9af3f45cf393be048ee8d8a92694; https://git.kernel.org/stable/c/690dd4780b3f4d755e4e7883e8c3d1b5052f6bf2
CVE: CVE-2023-53520
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: Fix hci_suspend_sync crash

If hci_unregister_dev() frees the hci_dev object but hci_suspend_notifier
may still be accessing it, it can cause the program to crash.
Here's the call trace:
  <4>[[PII_REDACTED]46] Call Trace:
  <4>[[PII_REDACTED]54]  hci_suspend_sync+0x109/0x301 [bluetooth]
  <4>[[PII_REDACTED]59]  hci_suspend_dev+0x78/0xcd [bluetooth]
  <4>[[PII_REDACTED]63]  hci_suspend_notifier+0x42/0x7a [bluetooth]
  <4>[[PII_REDACTED]68]  notifier_call_chain+0x43/0x6b
  <4>[[PII_REDACTED]71]  __blocking_notifier_call_chain+0x48/0x69
  <4>[[PII_REDACTED]73]  __pm_notifier_call_chain+0x22/0x39
  <4>[[PII_REDACTED]76]  pm_suspend+0x287/0x57c
  <4>[[PII_REDACTED]78]  state_store+0xae/0xe5
  <4>[[PII_REDACTED]81]  kernfs_fop_write+0x109/0x173
  <4>[[PII_REDACTED]84]  __vfs_write+0x16f/0x1a2
  <4>[[PII_REDACTED]87]  ? selinux_file_permission+0xca/0x16f
  <4>[[PII_REDACTED]89]  ? security_file_permission+0x36/0x109
  <4>[[PII_REDACTED]91]  vfs_write+0x114/0x21d
  <4>[[PII_REDACTED]93]  __x64_sys_write+0x7b/0xdb
  <4>[[PII_REDACTED]96]  do_syscall_64+0x59/0x194
  <4>[[PII_REDACTED]99]  entry_SYSCALL_64_after_hwframe+0x5c/0xc1

This patch holds the reference count of the hci_dev object while
processing it in hci_suspend_notifier to avoid potential crash
caused by the race condition.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/06e2b5ad72b60f90bfe565c201346532e271f484; https://git.kernel.org/stable/c/573ebae162111063eedc6c838a659ba628f66a0f; https://git.kernel.org/stable/c/e1fa25a91091bbed691ba2996a6cee809e3309a2
CVE: CVE-2023-53521
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: ses: Fix slab-out-of-bounds in ses_intf_remove()

A fix for:

BUG: KASAN: slab-out-of-bounds in ses_intf_remove+0x23f/0x270 [ses]
Read of size 8 at addr ffff88a10d32e5d8 by task rmmod/12013

When edev->components is zero, accessing edev->component[0] members is
wrong.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/0595cdb587726b4f0fa780eb7462e3679d141e82; https://git.kernel.org/stable/c/2fb1fa8425cce2dc4dce298275d22d7077694b73; https://git.kernel.org/stable/c/40af9a6deed723485e05b7d3255a28750692e8db
CVE: CVE-2023-53522
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

cgroup,freezer: hold cpu_hotplug_lock before freezer_mutex

syzbot is reporting circular locking dependency between cpu_hotplug_lock
and freezer_mutex, for commit f5d39b020809 ("freezer,sched: Rewrite core
freezer logic") replaced atomic_inc() in freezer_apply_state() with
static_branch_inc() which holds cpu_hotplug_lock.

cpu_hotplug_lock => cgroup_threadgroup_rwsem => freezer_mutex

  cgroup_file_write() {
    cgroup_procs_write() {
      __cgroup_procs_write() {
        cgroup_procs_write_start() {
          cgroup_attach_lock() {
            cpus_read_lock() {
              percpu_down_read(&cpu_hotplug_lock);
            }
            percpu_down_write(&cgroup_threadgroup_rwsem);
          }
        }
        cgroup_attach_task() {
          cgroup_migrate() {
            cgroup_migrate_execute() {
              freezer_attach() {
                mutex_lock(&freezer_mutex);
                (...snipped...)
              }
            }
          }
        }
        (...snipped...)
      }
    }
  }

freezer_mutex => cpu_hotplug_lock

  cgroup_file_write() {
    freezer_write() {
      freezer_change_state() {
        mutex_lock(&freezer_mutex);
        freezer_apply_state() {
          static_branch_inc(&freezer_active) {
            static_key_slow_inc() {
              cpus_read_lock();
              static_key_slow_inc_cpuslocked();
              cpus_read_unlock();
            }
          }
        }
        mutex_unlock(&freezer_mutex);
      }
    }
  }

Swap locking order by moving cpus_read_lock() in freezer_apply_state()
to before mutex_lock(&freezer_mutex) in freezer_change_state().
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/34fbb7b45bae20b551dda24337c7761ca13ce69d; https://git.kernel.org/stable/c/3756171b97c307d9df8b8ded1d883eec30172085; https://git.kernel.org/stable/c/57dcd64c7e036299ef526b400a8d12b8a2352f26
CVE: CVE-2023-53523
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

can: gs_usb: fix time stamp counter initialization

If the gs_usb device driver is unloaded (or unbound) before the
interface is shut down, the USB stack first calls the struct
usb_driver::disconnect and then the struct net_device_ops::ndo_stop
callback.

In gs_usb_disconnect() all pending bulk URBs are killed, i.e. no more
RX'ed CAN frames are send from the USB device to the host. Later in
gs_can_close() a reset control message is send to each CAN channel to
remove the controller from the CAN bus. In this race window the USB
device can still receive CAN frames from the bus and internally queue
them to be send to the host.

At least in the current version of the candlelight firmware, the queue
of received CAN frames is not emptied during the reset command. After
loading (or binding) the gs_usb driver, new URBs are submitted during
the struct net_device_ops::ndo_open callback and the candlelight
firmware starts sending its already queued CAN frames to the host.

However, this scenario was not considered when implementing the
hardware timestamp function. The cycle counter/time counter
infrastructure is set up (gs_usb_timestamp_init()) after the USBs are
submitted, resulting in a NULL pointer dereference if
timecounter_cyc2time() (via the call chain:
gs_usb_receive_bulk_callback() -> gs_usb_set_timestamp() ->
gs_usb_skb_set_timestamp()) is called too early.

Move the gs_usb_timestamp_init() function before the URBs are
submitted to fix this problem.

For a comprehensive solution, we need to consider gs_usb devices with
more than 1 channel. The cycle counter/time counter infrastructure is
setup per channel, but the RX URBs are per device. Once gs_can_open()
of _a_ channel has been called, and URBs have been submitted, the
gs_usb_receive_bulk_callback() can be called for _all_ available
channels, even for channels that are not running, yet. As cycle
counter/time counter has not set up, this will again lead to a NULL
pointer dereference.

Convert the cycle counter/time counter from a "per channel" to a "per
device" functionality. Also set it up, before submitting any URBs to
the device.

Further in gs_usb_receive_bulk_callback(), don't process any URBs for
not started CAN channels, only resubmit the URB.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/210a8cffc9c1b044281c0a868485c870c9c11374; https://git.kernel.org/stable/c/5886e4d5ecec3e22844efed90b2dd383ef804b3a
CVE: CVE-2023-53524
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: pcie: Fix integer overflow in iwl_write_to_user_buf

An integer overflow occurs in the iwl_write_to_user_buf() function,
which is called by the iwl_dbgfs_monitor_data_read() function.

static bool iwl_write_to_user_buf(char __user *user_buf, ssize_t count,
				  void *buf, ssize_t *size,
				  ssize_t *bytes_copied)
{
	int buf_size_left = count - *bytes_copied;

	buf_size_left = buf_size_left - (buf_size_left % sizeof(u32));
	if (*size > buf_size_left)
		*size = buf_size_left;

If the user passes a SIZE_MAX value to the "ssize_t count" parameter,
the ssize_t count parameter is assigned to "int buf_size_left".
Then compare "*size" with "buf_size_left" . Here, "buf_size_left" is a
negative number, so "*size" is assigned "buf_size_left" and goes into
the third argument of the copy_to_user function, causing a heap overflow.

This is not a security vulnerability because iwl_dbgfs_monitor_data_read()
is a debugfs operation with 0400 privileges.
CVSS Score: 7.8 (HIGH)
CWE: CWE-190
References: https://git.kernel.org/stable/c/059e426d666a41e26b184c177c1ca3ee2d6fa1b6; https://git.kernel.org/stable/c/0ad8dd870aa187d0c21d032bb2c[PII_REDACTED]eec; https://git.kernel.org/stable/c/58d1b717879bfeabe09b35e41ad667c79933eb2e