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

kobject: Add sanity check for kset->kobj.ktype in kset_register()

When I register a kset in the following way:
	static struct kset my_kset;
	kobject_set_name(&my_kset.kobj, "my_kset");
        ret = kset_register(&my_kset);

A null pointer dereference exception is occurred:
[ 4453.568337] Unable to handle kernel NULL pointer dereference at \
virtual address [PII_REDACTED]
... ...
[ 4453.810361] Call trace:
[ 4453.813062]  kobject_get_ownership+0xc/0x34
[ 4453.817493]  kobject_add_internal+0x98/0x274
[ 4453.822005]  kset_register+0x5c/0xb4
[ 4453.825820]  my_kobj_init+0x44/0x1000 [my_kset]
... ...

Because I didn't initialize my_kset.kobj.ktype.

According to the description in Documentation/core-api/kobject.rst:
 - A ktype is the type of object that embeds a kobject.  Every structure
   that embeds a kobject needs a corresponding ktype.

So add sanity check to make sure kset->kobj.ktype is not NULL.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/039ec9db2d30032eafa365f5f89b30eca5322b05; https://git.kernel.org/stable/c/1a772881bc059c596d8ca587cbd2a233edce3d3b; https://git.kernel.org/stable/c/48aebbe801e78a8932404c122ed0e880ccedc220
CVE: CVE-2023-53481
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

ubi: ubi_wl_put_peb: Fix infinite loop when wear-leveling work failed

Following process will trigger an infinite loop in ubi_wl_put_peb():

	ubifs_bgt		ubi_bgt
ubifs_leb_unmap
  ubi_leb_unmap
    ubi_eba_unmap_leb
      ubi_wl_put_peb	wear_leveling_worker
                          e1 = rb_entry(rb_first(&ubi->used)
			  e2 = get_peb_for_wl(ubi)
			  ubi_io_read_vid_hdr  // return err (flash fault)
			  out_error:
			    ubi->move_from = ubi->move_to = NULL
			    wl_entry_destroy(ubi, e1)
			      ubi->lookuptbl[e->pnum] = NULL
      retry:
        e = ubi->lookuptbl[pnum];	// return NULL
	if (e == ubi->move_from) {	// NULL == NULL gets true
	  goto retry;			// infinite loop !!!

$ top
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     COMMAND
  7676 root     20   0       0      0      0 R 100.0  0.0  ubifs_bgt0_0

Fix it by:
 1) Letting ubi_wl_put_peb() returns directly if wearl leveling entry has
    been removed from 'ubi->lookuptbl'.
 2) Using 'ubi->wl_lock' protecting wl entry deletion to preventing an
    use-after-free problem for wl entry in ubi_wl_put_peb().

Fetch a reproducer in [Link].
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-835
References: https://git.kernel.org/stable/c/3afaaf6f5867dc4ad383808d4053f428ec7b867d; https://git.kernel.org/stable/c/4d57a7333e26040f2b583983e1970d9d460e56b0; https://git.kernel.org/stable/c/5af1c643184a5d09ff5b3f334077a4d0a163c677
CVE: CVE-2023-53482
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

iommu: Fix error unwind in iommu_group_alloc()

If either iommu_group_grate_file() fails then the
iommu_group is leaked.

Destroy it on these error paths.

Found by kselftest/iommu/iommufd_fail_nth
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/4c23124b45ee0aa895ed8d5d08871ae6b15ee336; https://git.kernel.org/stable/c/4daa861174d56023c2068ddb03de0752f07fa199; https://git.kernel.org/stable/c/8602fa38a63fc689eca29c8c586fac2d8a1f8739
CVE: CVE-2023-53483
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

ACPI: processor: Check for null return of devm_kzalloc() in fch_misc_setup()

devm_kzalloc() may fail, clk_data->name might be NULL and will
cause a NULL pointer dereference later.

[ rjw: Subject and changelog edits ]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/4dea41775d951ff1f7b472a346a8ca3ae7e74455; https://git.kernel.org/stable/c/79ca94bc3e8cc3befa883c7d30b30a27ef0ea386; https://git.kernel.org/stable/c/8a632ff6a2bea49993002b4c46092a2aea625840
CVE: CVE-2023-53484
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

lib: cpu_rmap: Avoid use after free on rmap->obj array entries

When calling irq_set_affinity_notifier() with NULL at the notify
argument, it will cause freeing of the glue pointer in the
corresponding array entry but will leave the pointer in the array. A
subsequent call to free_irq_cpu_rmap() will try to free this entry again
leading to possible use after free.

Fix that by setting NULL to the array entry and checking that we have
non-zero at the array entry when iterating over the array in
free_irq_cpu_rmap().

The current code does not suffer from this since there are no cases
where irq_set_affinity_notifier(irq, NULL) (note the NULL passed for the
notify arg) is called, followed by a call to free_irq_cpu_rmap() so we
don't hit and issue. Subsequent patches in this series excersize this
flow, hence the required fix.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/4e0473f1060aa49621d40a113afde24818101d37; https://git.kernel.org/stable/c/67bca5f1d644f4e79b694abd8052a177de81c37f; https://git.kernel.org/stable/c/981f339d2905b6a92ef59358158b326493aecac5
CVE: CVE-2023-53485
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

fs: jfs: Fix UBSAN: array-index-out-of-bounds in dbAllocDmapLev

Syzkaller reported the following issue:

UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:1965:6
index -84 is out of range for type 's8[341]' (aka 'signed char[341]')
CPU: 1 PID: 4995 Comm: syz-executor146 Not tainted 6.4.0-rc6-syzkaller-00037-gb6dad5178cea #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+0x1e7/0x2d0 lib/dump_stack.c:106
 ubsan_epilogue lib/ubsan.c:217 [inline]
 __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348
 dbAllocDmapLev+0x3e5/0x430 fs/jfs/jfs_dmap.c:1965
 dbAllocCtl+0x113/0x920 fs/jfs/jfs_dmap.c:1809
 dbAllocAG+0x28f/0x10b0 fs/jfs/jfs_dmap.c:1350
 dbAlloc+0x658/0xca0 fs/jfs/jfs_dmap.c:874
 dtSplitUp fs/jfs/jfs_dtree.c:974 [inline]
 dtInsert+0xda7/0x6b00 fs/jfs/jfs_dtree.c:863
 jfs_create+0x7b6/0xbb0 fs/jfs/namei.c:137
 lookup_open fs/namei.c:3492 [inline]
 open_last_lookups fs/namei.c:3560 [inline]
 path_openat+0x13df/0x3170 fs/namei.c:3788
 do_filp_open+0x234/0x490 fs/namei.c:3818
 do_sys_openat2+0x13f/0x500 fs/open.c:1356
 do_sys_open fs/open.c:1372 [inline]
 __do_sys_openat fs/open.c:1388 [inline]
 __se_sys_openat fs/open.c:1383 [inline]
 __x64_sys_openat+0x247/0x290 fs/open.c:1383
 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
RIP: 0033:0x7f1f4e33f7e9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 14 00 00 90 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 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffc21129578 EFLAGS: 00000246 ORIG_RAX: [PII_REDACTED]
RAX: ffffffffffffffda RBX: [PII_REDACTED] RCX: 00007f1f4e33f7e9
RDX:[PII_REDACTED]00275a RSI: [PII_REDACTED] RDI: 00000000ffffff9c
RBP: 00007f1f4e2ff080 R08: [PII_REDACTED] R09: [PII_REDACTED]
R10: [PII_REDACTED] R11: [PII_REDACTED] R12: 00007f1f4e2ff110
R13: [PII_REDACTED] R14: [PII_REDACTED] R15: [PII_REDACTED]
 </TASK>

The bug occurs when the dbAllocDmapLev()function attempts to access
dp->tree.stree[leafidx + LEAFIND] while the leafidx value is negative.

To rectify this, the patch introduces a safeguard within the
dbAllocDmapLev() function. A check has been added to verify if leafidx is
negative. If it is, the function immediately returns an I/O error, preventing
any further execution that could potentially cause harm.

Tested via syzbot.
CVSS Score: 7.8 (HIGH)
CWE: CWE-129
References: https://git.kernel.org/stable/c/0d9e678a82915633b99603f744e7735d1a673d72; https://git.kernel.org/stable/c/39f6292d75959e8accac0b3e24090094ba0824e9; https://git.kernel.org/stable/c/4e302336d5ca1767a06beee7596a72d3bdc8d983
CVE: CVE-2023-53487
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

powerpc/rtas_flash: allow user copy to flash block cache objects

With hardened usercopy enabled (CONFIG_HARDENED_USERCOPY=y), using the
/proc/powerpc/rtas/firmware_update interface to prepare a system
firmware update yields a BUG():

  kernel BUG at mm/usercopy.c:102!
  Oops: Exception in kernel mode, sig: 5 [#1]
  LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
  Modules linked in:
  CPU: 0 PID: 2232 Comm: dd Not tainted 6.5.0-rc3+ #2
  Hardware name: IBM,8408-E8E POWER8E (raw) 0x4b0201 0xf000004 of:IBM,FW860.50 (SV860_146) hv:phyp pSeries
  NIP:  c[PII_REDACTED]991d0 LR: c[PII_REDACTED]991cc CTR: [PII_REDACTED]
  REGS: c[PII_REDACTED]c76a0 TRAP: 0700   Not tainted  (6.5.0-rc3+)
  MSR:  [PII_REDACTED] <SF,EE,ME,IR,DR,RI,LE>  CR: 24002242  XER: 0000000c
  CFAR: c[PII_REDACTED]fbd34 IRQMASK: 0
  [ ... GPRs omitted ... ]
  NIP usercopy_abort+0xa0/0xb0
  LR  usercopy_abort+0x9c/0xb0
  Call Trace:
    usercopy_abort+0x9c/0xb0 (unreliable)
    __check_heap_object+0x1b4/0x1d0
    __check_object_size+0x2d0/0x380
    rtas_flash_write+0xe4/0x250
    proc_reg_write+0xfc/0x160
    vfs_write+0xfc/0x4e0
    ksys_write+0x90/0x160
    system_call_exception+0x178/0x320
    system_call_common+0x160/0x2c4

The blocks of the firmware image are copied directly from user memory
to objects allocated from flash_block_cache, so flash_block_cache must
be created using kmem_cache_create_usercopy() to mark it safe for user
access.

[mpe: Trim and indent oops]
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/0ba7f969be599e21d4b1f1e947593de6515f4996; https://git.kernel.org/stable/c/1d29e21ed09fa668416fa7721e08d451b9903485; https://git.kernel.org/stable/c/4f3175979e62de3b929bfa54a0db4b87d36257a7
CVE: CVE-2023-53488
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

IB/hfi1: Fix possible panic during hotplug remove

During hotplug remove it is possible that the update counters work
might be pending, and may run after memory has been freed.
Cancel the update counters work before freeing memory.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/33c677d1e087e437c7dcaad8d73402cf6add282e; https://git.kernel.org/stable/c/4fdfaef71fced[PII_REDACTED]31a795497646f4555; https://git.kernel.org/stable/c/5e72f33ddfdb69cb21c1b59d31bbd3498d31b14a
CVE: CVE-2023-53490
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

mptcp: fix disconnect vs accept race

Despite commit 0ad529d9fd2b ("mptcp: fix possible divide by zero in
recvmsg()"), the mptcp protocol is still prone to a race between
disconnect() (or shutdown) and accept.

The root cause is that the mentioned commit checks the msk-level
flag, but mptcp_stream_accept() does acquire the msk-level lock,
as it can rely directly on the first subflow lock.

As reported by Christoph than can lead to a race where an msk
socket is accepted after that mptcp_subflow_queue_clean() releases
the listener socket lock and just before it takes destructive
actions leading to the following splat:

BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
PGD 5a4ca067 P4D 5a4ca067 PUD 37d4c067 PMD 0
Oops: 0000 [#1] PREEMPT SMP
CPU: 2 PID: 10955 Comm: syz-executor.5 Not tainted 6.5.0-rc1-gdc7b257ee5dd #37
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
RIP: 0010:mptcp_stream_accept+0x1ee/0x2f0 include/net/inet_sock.h:330
Code: 0a 09 00 48 8b 1b 4c 39 e3 74 07 e8 bc 7c 7f fe eb a1 e8 b5 7c 7f fe 4c 8b 6c 24 08 eb 05 e8 a9 7c 7f fe 49 8b 85 d8 09 00 00 <0f> b6 40 12 88 44 24 07 0f b6 6c 24 07 bf 07 00 00 00 89 ee e8 89
RSP: 0018:ffffc90000d07dc0 EFLAGS: 00010293
RAX: [PII_REDACTED] RBX: ffff888037e8d020 RCX: ffff88803b093300
RDX: [PII_REDACTED] RSI: ffffffff833822c5 RDI: ffffffff8333896a
RBP: 0000607f82031520 R08: ffff88803b093300 R09: [PII_REDACTED]
R10: [PII_REDACTED] R11:[PII_REDACTED]003e83 R12: ffff888037e8d020
R13: ffff888037e8c680 R14: ffff888009af7900 R15: ffff888009af6880
FS:  00007fc26d708640(0000) GS:ffff88807dd00000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: [PII_REDACTED] CR3:[PII_REDACTED]bc5001 CR4:[PII_REDACTED]370ee0
DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
Call Trace:
 <TASK>
 do_accept+0x1ae/0x260 net/socket.c:1872
 __sys_accept4+0x9b/0x110 net/socket.c:1913
 __do_sys_accept4 net/socket.c:1954 [inline]
 __se_sys_accept4 net/socket.c:1951 [inline]
 __x64_sys_accept4+0x20/0x30 net/socket.c:1951
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x47/0xa0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x6e/0xd8

Address the issue by temporary removing the pending request socket
from the accept queue, so that racing accept() can't touch them.

After depleting the msk - the ssk still exists, as plain TCP sockets,
re-insert them into the accept queue, so that later inet_csk_listen_stop()
will complete the tcp socket disposal.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/511b90e39250135a7f900f1c3afbce25543018a2; https://git.kernel.org/stable/c/b2b4c84eb7149f34c0f25f17042d095ba5357d68; https://git.kernel.org/stable/c/ded9f5551ce5cafa3c41c794428c27a0d0a00542
CVE: CVE-2023-53491
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

start_kernel: Add __no_stack_protector function attribute

Back during the discussion of
commit a9a3ed1eff36 ("x86: Fix early boot crash on gcc-10, third try")
we discussed the need for a function attribute to control the omission
of stack protectors on a per-function basis; at the time Clang had
support for no_stack_protector but GCC did not. This was fixed in
gcc-11. Now that the function attribute is available, let's start using
it.

Callers of boot_init_stack_canary need to use this function attribute
unless they're compiled with -fno-stack-protector, otherwise the canary
stored in the stack slot of the caller will differ upon the call to
boot_init_stack_canary. This will lead to a call to __stack_chk_fail()
then panic.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/25e73018b4093e0cfbcec5dc4a4bb86d0b69ed56; https://git.kernel.org/stable/c/514ca14ed5444b911de59ed3381dfd195d99fe4b
CVE: CVE-2023-53493
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

accel/qaic: tighten bounds checking in decode_message()

Copy the bounds checking from encode_message() to decode_message().

This patch addresses the following concerns.  Ensure that there is
enough space for at least one header so that we don't have a negative
size later.

	if (msg_hdr_len < sizeof(*trans_hdr))

Ensure that we have enough space to read the next header from the
msg->data.

	if (msg_len > msg_hdr_len - sizeof(*trans_hdr))
		return -EINVAL;

Check that the trans_hdr->len is not below the minimum size:

	if (hdr_len < sizeof(*trans_hdr))

This minimum check ensures that we don't corrupt memory in
decode_passthrough() when we do.

	memcpy(out_trans->data, in_trans->data, len - sizeof(in_trans->hdr));

And finally, use size_add() to prevent an integer overflow:

	if (size_add(msg_len, hdr_len) > msg_hdr_len)
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/51b56382ed2a2b[PII_REDACTED]2362b3baa623ed1e; https://git.kernel.org/stable/c/57d14cb3bae4619ce2fb5235cb318c3d5d8f53fd
CVE: CVE-2023-53494
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

crypto: xts - Handle EBUSY correctly

As it is xts only handles the special return value of EINPROGRESS,
which means that in all other cases it will free data related to the
request.

However, as the caller of xts may specify MAY_BACKLOG, we also need
to expect EBUSY and treat it in the same way.  Otherwise backlogged
requests will trigger a use-after-free.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/51c082514c2dedf2711c99d93c196cc4eedceb40; https://git.kernel.org/stable/c/57c3e1d63b63dc0841d41df729297cd7c1c35808; https://git.kernel.org/stable/c/912eb10b65646ffd222256c78a1c566a3dac177d
CVE: CVE-2023-53495
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

net: ethernet: mvpp2_main: fix possible OOB write in mvpp2_ethtool_get_rxnfc()

rules is allocated in ethtool_get_rxnfc and the size is determined by
rule_cnt from user space. So rule_cnt needs to be check before using
rules to avoid OOB writing or NULL pointer dereference.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/349638f7e5d3c7d328565587bb7b0454bbee02e2; https://git.kernel.org/stable/c/51fe0a470543f345e3c62b6798929de3ddcedc1d; https://git.kernel.org/stable/c/5bb09dddc724c5f7c4dc6dd3bfebd685eecd93e8
CVE: CVE-2023-53496
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/platform/uv: Use alternate source for socket to node data

The UV code attempts to build a set of tables to allow it to do
bidirectional socket<=>node lookups.

But when nr_cpus is set to a smaller number than actually present, the
cpu_to_node() mapping information for unused CPUs is not available to
build_socket_tables(). This results in skipping some nodes or sockets
when creating the tables and leaving some -1's for later code to trip.
over, causing oopses.

The problem is that the socket<=>node lookups are created by doing a
loop over all CPUs, then looking up the CPU's APICID and socket. But
if a CPU is not present, there is no way to start this lookup.

Instead of looping over all CPUs, take CPUs out of the equation
entirely. Loop over all APICIDs which are mapped to a valid NUMA node.
Then just extract the socket-id from the APICID.

This avoid tripping over disabled CPUs.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0d01a0c3046d1545391ef7bb1f114743d00e3793; https://git.kernel.org/stable/c/5290e88ba2c742ca77c5f5b690e5af549cfd8591
CVE: CVE-2023-53498
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix potential null dereference

The adev->dm.dc pointer can be NULL and dereferenced in amdgpu_dm_fini()
without checking.

Add a NULL pointer check before calling dc_dmub_srv_destroy().

Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/281933f36a53fed1c2993a92cf1edfb424595474; https://git.kernel.org/stable/c/4b1afffdd94093118b3cc235ef2b4d2520fb4950; https://git.kernel.org/stable/c/52f1783ff[PII_REDACTED]422c1cd94fcb4ce39b6fe
CVE: CVE-2023-53499
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

virtio_net: Fix error unwinding of XDP initialization

When initializing XDP in virtnet_open(), some rq xdp initialization
may hit an error causing net device open failed. However, previous
rqs have already initialized XDP and enabled NAPI, which is not the
expected behavior. Need to roll back the previous rq initialization
to avoid leaks in error unwinding of init code.

Also extract helper functions of disable and enable queue pairs.
Use newly introduced disable helper function in error unwinding and
virtnet_close. Use enable helper function in virtnet_open.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/037768b28e3752c07d63d1c72a651a6775b080bb; https://git.kernel.org/stable/c/5306623a9826aa7d63b32c6a3803c798a765474d; https://git.kernel.org/stable/c/6a7690f2bd178eee80f33411ae32e543ae66379c
CVE: CVE-2023-53501
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

iommu/amd/iommu_v2: Fix pasid_state refcount dec hit 0 warning on pasid unbind

When unbinding pasid - a race condition exists vs outstanding page faults.

To prevent this, the pasid_state object contains a refcount.
    * set to 1 on pasid bind
    * incremented on each ppr notification start
    * decremented on each ppr notification done
    * decremented on pasid unbind

Since refcount_dec assumes that refcount will never reach 0:
  the current implementation causes the following to be invoked on
  pasid unbind:
        REFCOUNT_WARN("decrement hit 0; leaking memory")

Fix this issue by changing refcount_dec to refcount_dec_and_test
to explicitly handle refcount=1.
CVSS Score: 4.7 (MEDIUM)
References: https://git.kernel.org/stable/c/13ed255248dfbbb7f23f9170c7a537fb9ca22c73; https://git.kernel.org/stable/c/534103bcd52ca9c1fecbc70e717b4a538dc4ded8; https://git.kernel.org/stable/c/98d86bf32187db27946ca817c2467a5f2f7aa02f
CVE: CVE-2023-53502
Published: 2025-10-01
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2023-53503
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: allow ext4_get_group_info() to fail

Previously, ext4_get_group_info() would treat an invalid group number
as BUG(), since in theory it should never happen.  However, if a
malicious attaker (or fuzzer) modifies the superblock via the block
device while it is the file system is mounted, it is possible for
s_first_data_block to get set to a very large number.  In that case,
when calculating the block group of some block number (such as the
starting block of a preallocation region), could result in an
underflow and very large block group number.  Then the BUG_ON check in
ext4_get_group_info() would fire, resutling in a denial of service
attack that can be triggered by root or someone with write access to
the block device.

For a quality of implementation perspective, it's best that even if
the system administrator does something that they shouldn't, that it
will not trigger a BUG.  So instead of BUG'ing, ext4_get_group_info()
will call ext4_error and return NULL.  We also add fallback code in
all of the callers of ext4_get_group_info() that it might NULL.

Also, since ext4_get_group_info() was already borderline to be an
inline function, un-inline it.  The results in a next reduction of the
compiled text size of ext4 by roughly 2k.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/100c0ad6c04597fefeaaba2bb1827cc015d95067; https://git.kernel.org/stable/c/31668cebf45adfb6283e465e641c4f5a21b07afa; https://git.kernel.org/stable/c/5354b2af34064a4579be8bc0e2f15a7b70f14b5f
CVE: CVE-2023-53504
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/bnxt_re: Properly order ib_device_unalloc() to avoid UAF

ib_dealloc_device() should be called only after device cleanup.  Fix the
dealloc sequence.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/5363fc488da579923edf6a2fdca3d3b651dd800b; https://git.kernel.org/stable/c/c95863f6d970ef968e7c1f3c481f72a4b0734654
CVE: CVE-2023-53505
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: tegra: tegra124-emc: Fix potential memory leak

The tegra and tegra needs to be freed in the error handling path, otherwise
it will be leaked.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/404e9f741acfb188212f7142d91e247630dd77cc; https://git.kernel.org/stable/c/4e59e355f9fcccd9edf65d09f769bb4c163a1c36; https://git.kernel.org/stable/c/53a06e5924c0d43c11379a08c5a78529c3e61595