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

bpf, cpumap: Handle skb as well when clean up ptr_ring

The following warning was reported when running xdp_redirect_cpu with
both skb-mode and stress-mode enabled:

  ------------[ cut here ]------------
  Incorrect XDP memory type ([PII_REDACTED]) usage
  WARNING: CPU: 7 PID: 1442 at net/core/xdp.c:405
  Modules linked in:
  CPU: 7 PID: 1442 Comm: kworker/7:0 Tainted: G  6.5.0-rc2+ #1
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
  Workqueue: events __cpu_map_entry_free
  RIP: 0010:__xdp_return+0x1e4/0x4a0
  ......
  Call Trace:
   <TASK>
   ? show_regs+0x65/0x70
   ? __warn+0xa5/0x240
   ? __xdp_return+0x1e4/0x4a0
   ......
   xdp_return_frame+0x4d/0x150
   __cpu_map_entry_free+0xf9/0x230
   process_one_work+0x6b0/0xb80
   worker_thread+0x96/0x720
   kthread+0x1a5/0x1f0
   ret_from_fork+0x3a/0x70
   ret_from_fork_asm+0x1b/0x30
   </TASK>

The reason for the warning is twofold. One is due to the kthread
cpu_map_kthread_run() is stopped prematurely. Another one is
__cpu_map_ring_cleanup() doesn't handle skb mode and treats skbs in
ptr_ring as XDP frames.

Prematurely-stopped kthread will be fixed by the preceding patch and
ptr_ring will be empty when __cpu_map_ring_cleanup() is called. But
as the comments in __cpu_map_ring_cleanup() said, handling and freeing
skbs in ptr_ring as well to "catch any broken behaviour gracefully".
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/7c62b75cd1a792e14b037fa4f61f9b18914e7de1; https://git.kernel.org/stable/c/937345720d18f1ad006ba3d5dcb3fa121037b8a2; https://git.kernel.org/stable/c/b58d34068fd9f96bfc7d389988dfaf9a92a8fe00
CVE: CVE-2023-53661
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

bnxt: avoid overflow in bnxt_get_nvram_directory()

The value of an arithmetic expression is subject
of possible overflow due to a failure to cast operands to a larger data
type before performing arithmetic. Used macro for multiplication instead
operator for avoiding overflow.

Found by Security Code and Linux Verification
Center (linuxtesting.org) with SVACE.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190
References: https://git.kernel.org/stable/c/17e0453a7523ad7a25bb47af941b150a6c66d7b6; https://git.kernel.org/stable/c/7c6dddc239abe660598c49ec95ea0ed6399a4b2a; https://git.kernel.org/stable/c/d5eaf2a6b077f32a477feb1e9e1c1f60605b460e
CVE: CVE-2023-53662
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: fix memory leaks in ext4_fname_{setup_filename,prepare_lookup}

If the filename casefolding fails, we'll be leaking memory from the
fscrypt_name struct, namely from the 'crypto_buf.name' member.

Make sure we free it in the error path on both ext4_fname_setup_filename()
and ext4_fname_prepare_lookup() functions.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/1fb3f1bbfdb511034b0360dbeb0f6a8424ed2a5c; https://git.kernel.org/stable/c/36daf050be3f6f067631dc52054de2d3b7cc849f; https://git.kernel.org/stable/c/7ca4b085f430f3774c3838b3da569ceccd6a0177
CVE: CVE-2023-53663
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: nSVM: Check instead of asserting on nested TSC scaling support

Check for nested TSC scaling support on nested SVM VMRUN instead of
asserting that TSC scaling is exposed to L1 if L1's MSR_AMD64_TSC_RATIO
has diverged from KVM's default.  Userspace can trigger the WARN at will
by writing the MSR and then updating guest CPUID to hide the feature
(modifying guest CPUID is allowed anytime before KVM_RUN).  E.g. hacking
KVM's state_test selftest to do

		vcpu_set_msr(vcpu, MSR_AMD64_TSC_RATIO, 0);
		vcpu_clear_cpuid_feature(vcpu, X86_FEATURE_TSCRATEMSR);

after restoring state in a new VM+vCPU yields an endless supply of:

  ------------[ cut here ]------------
  WARNING: CPU: 164 PID: 62565 at arch/x86/kvm/svm/nested.c:699
           nested_vmcb02_prepare_control+0x3d6/0x3f0 [kvm_amd]
  Call Trace:
   <TASK>
   enter_svm_guest_mode+0x114/0x560 [kvm_amd]
   nested_svm_vmrun+0x260/0x330 [kvm_amd]
   vmrun_interception+0x29/0x30 [kvm_amd]
   svm_invoke_exit_handler+0x35/0x100 [kvm_amd]
   svm_handle_exit+0xe7/0x180 [kvm_amd]
   kvm_arch_vcpu_ioctl_run+0x1eab/0x2570 [kvm]
   kvm_vcpu_ioctl+0x4c9/0x5b0 [kvm]
   __se_sys_ioctl+0x7a/0xc0
   __x64_sys_ioctl+0x21/0x30
   do_syscall_64+0x41/0x90
   entry_SYSCALL_64_after_hwframe+0x63/0xcd
  RIP: 0033:0x45ca1b

Note, the nested #VMEXIT path has the same flaw, but needs a different
fix and will be handled separately.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/02b24270568f65dd607c4a848512dc8055b4491b; https://git.kernel.org/stable/c/6c1ecfea1daf6e75c46e295aad99dfbafd878897; https://git.kernel.org/stable/c/7cafe9b8e22bb3d77f130c461aedf6868c4aaf58
CVE: CVE-2023-53664
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

OPP: Fix potential null ptr dereference in dev_pm_opp_get_required_pstate()

"opp" pointer is dereferenced before the IS_ERR_OR_NULL() check. Fix it by
removing the dereference to cache opp_table and dereference it directly
where opp_table is used.

This fixes the following smatch warning:

drivers/opp/core.c:232 dev_pm_opp_get_required_pstate() warn: variable
dereferenced before IS_ERR check 'opp' (see line 230)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/25130b27e0352acb83e91c467853eb9afad3b644; https://git.kernel.org/stable/c/7ddd8deb1c3c0363a7e14fafb5df26e2089a69a5
CVE: CVE-2023-53665
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

md: don't dereference mddev after export_rdev()

Except for initial reference, mddev->kobject is referenced by
rdev->kobject, and if the last rdev is freed, there is no guarantee that
mddev is still valid. Hence mddev should not be used anymore after
export_rdev().

This problem can be triggered by following test for mdadm at very
low rate:

New file: mdadm/tests/23rdev-lifetime

devname=${dev0##*/}
devt=`cat /sys/block/$devname/dev`
pid=""
runtime=2

clean_up_test() {
        pill -9 $pid
        echo clear > /sys/block/md0/md/array_state
}

trap 'clean_up_test' EXIT

add_by_sysfs() {
        while true; do
                echo $devt > /sys/block/md0/md/new_dev
        done
}

remove_by_sysfs(){
        while true; do
                echo remove > /sys/block/md0/md/dev-${devname}/state
        done
}

echo md0 > /sys/module/md_mod/parameters/new_array || die "create md0 failed"

add_by_sysfs &
pid="$pid $!"

remove_by_sysfs &
pid="$pid $!"

sleep $runtime
exit 0

Test cmd:

./test --save-logs --logdir=/tmp/ --keep-going --dev=loop --tests=23rdev-lifetime

Test result:

general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bcb: 0000 [#4] PREEMPT SMP
CPU: 0 PID: 1292 Comm: test Tainted: G      D W          6.5.0-rc2-00121-g01e55c376936 #562
RIP: 0010:md_wakeup_thread+0x9e/0x320 [md_mod]
Call Trace:
 <TASK>
 mddev_unlock+0x1b6/0x310 [md_mod]
 rdev_attr_store+0xec/0x190 [md_mod]
 sysfs_kf_write+0x52/0x70
 kernfs_fop_write_iter+0x19a/0x2a0
 vfs_write+0x3b5/0x770
 ksys_write+0x74/0x150
 __x64_sys_write+0x22/0x30
 do_syscall_64+0x40/0x90
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Fix this problem by don't dereference mddev after export_rdev().
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/7deac114be5fb25a4e865212ed0feaf5f85f2a28; https://git.kernel.org/stable/c/ad430ad0669d[PII_REDACTED]390d68e1454fc7a344
CVE: CVE-2023-53666
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: codecs: wcd938x: fix missing mbhc init error handling

MBHC initialisation can fail so add the missing error handling to avoid
dereferencing an error pointer when later configuring the jack:

    Unable to handle kernel paging request at virtual address fffffffffffffff8

    pc : wcd_mbhc_start+0x28/0x380 [snd_soc_wcd_mbhc]
    lr : wcd938x_codec_set_jack+0x28/0x48 [snd_soc_wcd938x]

    Call trace:
     wcd_mbhc_start+0x28/0x380 [snd_soc_wcd_mbhc]
     wcd938x_codec_set_jack+0x28/0x48 [snd_soc_wcd938x]
     snd_soc_component_set_jack+0x28/0x8c [snd_soc_core]
     qcom_snd_wcd_jack_setup+0x7c/0x19c [snd_soc_qcom_common]
     sc8280xp_snd_init+0x20/0x2c [snd_soc_sc8280xp]
     snd_soc_link_init+0x28/0x90 [snd_soc_core]
     snd_soc_bind_card+0x628/0xbfc [snd_soc_core]
     snd_soc_register_card+0xec/0x104 [snd_soc_core]
     devm_snd_soc_register_card+0x4c/0xa4 [snd_soc_core]
     sc8280xp_platform_probe+0xf0/0x108 [snd_soc_sc8280xp]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/31ee704c84c4bf4df8521ef1478c161f710d0f94; https://git.kernel.org/stable/c/5a34d252052b5da743ef82591c860fc947384d4e; https://git.kernel.org/stable/c/7dfae2631bfbdebecd35fe7b472ab3cc95c9ed66
CVE: CVE-2023-53667
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

net: cdc_ncm: Deal with too low values of dwNtbOutMaxSize

Currently in cdc_ncm_check_tx_max(), if dwNtbOutMaxSize is lower than
the calculated "min" value, but greater than zero, the logic sets
tx_max to dwNtbOutMaxSize. This is then used to allocate a new SKB in
cdc_ncm_fill_tx_frame() where all the data is handled.

For small values of dwNtbOutMaxSize the memory allocated during
alloc_skb(dwNtbOutMaxSize, GFP_ATOMIC) will have the same size, due to
how size is aligned at alloc time:
	size = SKB_DATA_ALIGN(size);
        size += SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
Thus we hit the same bug that we tried to squash with
commit 2be6d4d16a084 ("net: cdc_ncm: Allow for dwNtbOutMaxSize to be unset or zero")

Low values of dwNtbOutMaxSize do not cause an issue presently because at
alloc_skb() time more memory (512b) is allocated than required for the
SKB headers alone (320b), leaving some space (512b - 320b = 192b)
for CDC data (172b).

However, if more elements (for example 3 x u64 = [24b]) were added to
one of the SKB header structs, say 'struct skb_shared_info',
increasing its original size (320b [320b aligned]) to something larger
(344b [384b aligned]), then suddenly the CDC data (172b) no longer
fits in the spare SKB data area (512b - 384b = 128b).

Consequently the SKB bounds checking semantics fails and panics:

skbuff: skb_over_panic: text:ffffffff831f755b len:184 put:172 head:ffff88811f1c6c00 data:ffff88811f1c6c00 tail:0xb8 end:0x80 dev:<NULL>
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:113!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 57 Comm: kworker/0:2 Not tainted 5.15.106-syzkaller-00249-g19c0ed55a470 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023
Workqueue: mld mld_ifc_work
RIP: 0010:skb_panic net/core/skbuff.c:113 [inline]
RIP: 0010:skb_over_panic+0x14c/0x150 net/core/skbuff.c:118
[snip]
Call Trace:
 <TASK>
 skb_put+0x151/0x210 net/core/skbuff.c:2047
 skb_put_zero include/linux/skbuff.h:2422 [inline]
 cdc_ncm_ndp16 drivers/net/usb/cdc_ncm.c:1131 [inline]
 cdc_ncm_fill_tx_frame+0x11ab/0x3da0 drivers/net/usb/cdc_ncm.c:1308
 cdc_ncm_tx_fixup+0xa3/0x100

Deal with too low values of dwNtbOutMaxSize, clamp it in the range
[USB_CDC_NCM_NTB_MIN_OUT_SIZE, CDC_NCM_NTB_MAX_SIZE_TX]. We ensure
enough data space is allocated to handle CDC data by making sure
dwNtbOutMaxSize is not smaller than USB_CDC_NCM_NTB_MIN_OUT_SIZE.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/2334ff0b343ba6ba7a6c0586fcc83992bbbc1776; https://git.kernel.org/stable/c/42b78c8cc774b47023d6d16d96d54cc7015e4a07; https://git.kernel.org/stable/c/6147745d43ff4e0d2c542e5b93e398ef0ee4db00
CVE: CVE-2023-53668
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

ring-buffer: Fix deadloop issue on reading trace_pipe

Soft lockup occurs when reading file 'trace_pipe':

  watchdog: BUG: soft lockup - CPU#6 stuck for 22s! [cat:4488]
  [...]
  RIP: 0010:ring_buffer_empty_cpu+0xed/0x170
  RSP: 0018:ffff88810dd6fc48 EFLAGS: 00000246
  RAX: [PII_REDACTED] RBX: [PII_REDACTED] RCX: ffffffff93d1aaeb
  RDX: ffff88810a280040 RSI: [PII_REDACTED] RDI: ffff88811164b218
  RBP: ffff88811164b218 R08: [PII_REDACTED] R09: ffff[PII_REDACTED]0f
  R10: ffffed102a2acc01 R11: [PII_REDACTED] R12: [PII_REDACTED]
  R13: [PII_REDACTED] R14: ffff888115e49500 R15: [PII_REDACTED]
  [...]
  CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
  CR2: 00007f8d853c2000 CR3: 000000010dcd8000 CR4:[PII_REDACTED]0006e0
  DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
  DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
  Call Trace:
   __find_next_entry+0x1a8/0x4b0
   ? peek_next_entry+0x250/0x250
   ? down_write+0xa5/0x120
   ? down_write_killable+0x130/0x130
   trace_find_next_entry_inc+0x3b/0x1d0
   tracing_read_pipe+0x423/0xae0
   ? tracing_splice_read_pipe+0xcb0/0xcb0
   vfs_read+0x16b/0x490
   ksys_read+0x105/0x210
   ? __ia32_sys_pwrite64+0x200/0x200
   ? switch_fpu_return+0x108/0x220
   do_syscall_64+0x33/0x40
   entry_SYSCALL_64_after_hwframe+0x61/0xc6

Through the vmcore, I found it's because in tracing_read_pipe(),
ring_buffer_empty_cpu() found some buffer is not empty but then it
cannot read anything due to "rb_num_of_entries() == 0" always true,
Then it infinitely loop the procedure due to user buffer not been
filled, see following code path:

  tracing_read_pipe() {
    ... ...
    waitagain:
      tracing_wait_pipe() // 1. find non-empty buffer here
      trace_find_next_entry_inc()  // 2. loop here try to find an entry
        __find_next_entry()
          ring_buffer_empty_cpu();  // 3. find non-empty buffer
          peek_next_entry()  // 4. but peek always return NULL
            ring_buffer_peek()
              rb_buffer_peek()
                rb_get_reader_page()
                  // 5. because rb_num_of_entries() == 0 always true here
                  //    then return NULL
      // 6. user buffer not been filled so goto 'waitgain'
      //    and eventually leads to an deadloop in kernel!!!
  }

By some analyzing, I found that when resetting ringbuffer, the 'entries'
of its pages are not all cleared (see rb_reset_cpu()). Then when reducing
the ringbuffer, and if some reduced pages exist dirty 'entries' data, they
will be added into 'cpu_buffer->overrun' (see rb_remove_pages()), which
cause wrong 'overrun' count and eventually cause the deadloop issue.

To fix it, we need to clear every pages in rb_reset_cpu().
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/0a29dae5786d263016a9aceb1e56bf3fd4cc6fa0; https://git.kernel.org/stable/c/27bdd93e44cc28dd9b94893fae146b83d4f5b31e; https://git.kernel.org/stable/c/5e68f1f3a20fe9b6bde018e353269fbfa289609c
CVE: CVE-2023-53669
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

tcp: fix skb_copy_ubufs() vs BIG TCP

David Ahern reported crashes in skb_copy_ubufs() caused by TCP tx zerocopy
using hugepages, and skb length bigger than ~68 KB.

skb_copy_ubufs() assumed it could copy all payload using up to
MAX_SKB_FRAGS order-0 pages.

This assumption broke when BIG TCP was able to put up to 512 KB per skb.

We did not hit this bug at Google because we use CONFIG_MAX_SKB_FRAGS=45
and limit gso_max_size to 180000.

A solution is to use higher order pages if needed.

v2: add missing __GFP_COMP, or we leak memory.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/3c77a377877acbaf03cd7caa21d3644a5dd16301; https://git.kernel.org/stable/c/7e692df3933628d974acb9f5b334d2b3e885e2a6; https://git.kernel.org/stable/c/7fa93e39fbb0566019c388a8038a4d58552e0910
CVE: CVE-2023-53670
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

nvme-core: fix dev_pm_qos memleak

Call dev_pm_qos_hide_latency_tolerance() in the error unwind patch to
avoid following kmemleak:-

blktests (master) # kmemleak-clear; ./check nvme/044;
blktests (master) # kmemleak-scan ; kmemleak-show
nvme/044 (Test bi-directional authentication)                [passed]
    runtime  2.111s  ...  2.124s
unreferenced object 0xffff888110c46240 (size 96):
  comm "nvme", pid 33461, jiffies[PII_REDACTED] (age 75.586s)
  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:
    [<[PII_REDACTED]ac2cec>] kmalloc_trace+0x25/0x90
    [<000000006acc66d5>] dev_pm_qos_update_user_latency_tolerance+0x6f/0x100
    [<00000000cc376ea7>] nvme_init_ctrl+0x38e/0x410 [nvme_core]
    [<000000007df61b4b>] 0xffffffffc05e88b3
    [<00000000d152b985>] 0xffffffffc05744cb
    [<00000000f04a4041>] vfs_write+0xc5/0x3c0
    [<00000000f9491baf>] ksys_write+0x5f/0xe0
    [<000000001c46513d>] do_syscall_64+0x3b/0x90
    [<00000000ecf348fe>] entry_SYSCALL_64_after_hwframe+0x72/0xdc
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/2ed9a89192e3192e5fea7ff6475c8722513f325e; https://git.kernel.org/stable/c/7237c26431cc78e5ec3259f4350f3dd58f6a4319; https://git.kernel.org/stable/c/7ed5cf8e6d9bfb6a78d0471317edff14f0f2b4dd
CVE: CVE-2023-53672
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

btrfs: output extra debug info if we failed to find an inline backref

[BUG]
Syzbot reported several warning triggered inside
lookup_inline_extent_backref().

[CAUSE]
As usual, the reproducer doesn't reliably trigger locally here, but at
least we know the WARN_ON() is triggered when an inline backref can not
be found, and it can only be triggered when @insert is true. (I.e.
inserting a new inline backref, which means the backref should already
exist)

[ENHANCEMENT]
After the WARN_ON(), dump all the parameters and the extent tree
leaf to help debug.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/28062cd6eda04035d8f6ded2001292ac8b496149; https://git.kernel.org/stable/c/376b41524b71e494514720bd6114325b0a2ed19c; https://git.kernel.org/stable/c/400e08a16604b534fdd82c5a288fa150d04f5f79
CVE: CVE-2023-53674
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: Fix memory leak in devm_clk_notifier_register()

devm_clk_notifier_register() allocates a devres resource for clk
notifier but didn't register that to the device, so the notifier didn't
get unregistered on device detach and the allocated resource was leaked.

Fix the issue by registering the resource through devres_add().

This issue was found with kmemleak on a Chromebook.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/49451db71b746df[PII_REDACTED]61f1033f7c9b734; https://git.kernel.org/stable/c/7fb933e56f77a57ef7cfc59fc34cbbf1b1fa31ff; https://git.kernel.org/stable/c/a326cf0107b197e649bbaa2a2b[PII_REDACTED]ce32
CVE: CVE-2023-53675
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: ses: Fix possible desc_ptr out-of-bounds accesses

Sanitize possible desc_ptr out-of-bounds accesses in
ses_enclosure_data_process().
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/414418abc19fa4ccf730d273061a426c07a061d6; https://git.kernel.org/stable/c/4b8cae410472653a59e15af62c57c49b8e0a1201; https://git.kernel.org/stable/c/584892fd29a41ef424a148118a3103b16b94fb8c
CVE: CVE-2023-53676
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: target: iscsi: Fix buffer overflow in lio_target_nacl_info_show()

The function lio_target_nacl_info_show() uses sprintf() in a loop to print
details for every iSCSI connection in a session without checking for the
buffer length. With enough iSCSI connections it's possible to overflow the
buffer provided by configfs and corrupt the memory.

This patch replaces sprintf() with sysfs_emit_at() that checks for buffer
boundries.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/0cac6cbb[PII_REDACTED]a5d30c[PII_REDACTED]d3da50; https://git.kernel.org/stable/c/114b44dddea1f8f99576de3c0e6e[PII_REDACTED]fc; https://git.kernel.org/stable/c/2cbe6a88fbdd6e8aeab358eef61472e2de43d6f6
CVE: CVE-2023-53677
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/i915: Fix memory leaks in i915 selftests

This patch fixes memory leaks on error escapes in function fake_get_pages

(cherry picked from commit 8bfbdadce85c4c51689da10f39c805a7106d4567)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/596d7308e189a3230bf33d667b64acc73846c2d0; https://git.kernel.org/stable/c/803033c148f754f32da1b93926c49c22731ec485
CVE: CVE-2023-53680
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

NFSD: Avoid calling OPDESC() with ops->opnum == OP_ILLEGAL

OPDESC() simply indexes into nfsd4_ops[] by the op's operation
number, without range checking that value. It assumes callers are
careful to avoid calling it with an out-of-bounds opnum value.

nfsd4_decode_compound() is not so careful, and can invoke OPDESC()
with opnum set to OP_ILLEGAL, which is 10044 -- well beyond the end
of nfsd4_ops[].
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/50827896c365e0f6c8b55ed56d444dafd87c92c5; https://git.kernel.org/stable/c/804d8e0a6e[PII_REDACTED]0472781e03bc243f4ee3; https://git.kernel.org/stable/c/a64160124d5a078be0c380b1e8a0bad2d040d3a1
CVE: CVE-2023-53681
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

bcache: Fix __bch_btree_node_alloc to make the failure behavior consistent

In some specific situations, the return value of __bch_btree_node_alloc
may be NULL. This may lead to a potential NULL pointer dereference in
caller function like a calling chain :
btree_split->bch_btree_node_alloc->__bch_btree_node_alloc.

Fix it by initializing the return value in __bch_btree_node_alloc.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/4514847aee18d9391a0cf3aad75d3567c72795a4; https://git.kernel.org/stable/c/587b4e8bb5dac682f09280ab35db4632b29d5ac4; https://git.kernel.org/stable/c/7ecea5ce3dc17339c280c75b58ac93d8c8620d9f
CVE: CVE-2023-53682
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

hwmon: (xgene) Fix ioremap and memremap leak

Smatch reports:

drivers/hwmon/xgene-hwmon.c:757 xgene_hwmon_probe() warn:
'ctx->pcc_comm_addr' from ioremap() not released on line: 757.

This is because in drivers/hwmon/xgene-hwmon.c:701 xgene_hwmon_probe(),
ioremap and memremap is not released, which may cause a leak.

To fix this, ioremap and memremap is modified to devm_ioremap and
devm_memremap.

[groeck: Fixed formatting and subject]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/1773185a0a87006c1be78a978d9dd61aa7a33db8; https://git.kernel.org/stable/c/813cc94c7847ae4a17e9f744fb4dbdf7df6bd732; https://git.kernel.org/stable/c/9d482a09acd3d5f61a56aefc125d32c81994707b
CVE: CVE-2023-53683
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

fs: hfsplus: remove WARN_ON() from hfsplus_cat_{read,write}_inode()

syzbot is hitting WARN_ON() in hfsplus_cat_{read,write}_inode(), for
crafted filesystem image can contain bogus length. There conditions are
not kernel bugs that can justify kernel to panic.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-617
References: https://git.kernel.org/stable/c/37cab61a52d6f42b2d961c51bcf369f09e235fb5; https://git.kernel.org/stable/c/3a9d68d84b2e41ba3f2a727b36f035fad6800492; https://git.kernel.org/stable/c/48960a503fcec76d3f72347b7e679dda08ca43be