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

ocfs2: fix defrag path triggering jbd2 ASSERT

code path:

ocfs2_ioctl_move_extents
 ocfs2_move_extents
  ocfs2_defrag_extent
   __ocfs2_move_extent
    + ocfs2_journal_access_di
    + ocfs2_split_extent  //sub-paths call jbd2_journal_restart
    + ocfs2_journal_dirty //crash by jbs2 ASSERT

crash stacks:

PID: 11297  TASK: ffff974a676dcd00  CPU: 67  COMMAND: "defragfs.ocfs2"
 #0 [ffffb25d8dad3900] machine_kexec at ffffffff8386fe01
 #1 [ffffb25d8dad3958] __crash_kexec at ffffffff8395959d
 #2 [ffffb25d8dad3a20] crash_kexec at ffffffff8395a45d
 #3 [ffffb25d8dad3a38] oops_end at ffffffff83836d3f
 #4 [ffffb25d8dad3a58] do_trap at ffffffff83833205
 #5 [ffffb25d8dad3aa0] do_invalid_op at ffffffff83833aa6
 #6 [ffffb25d8dad3ac0] invalid_op at ffffffff84200d18
    [exception RIP: jbd2_journal_dirty_metadata+0x2ba]
    RIP: ffffffffc09ca54a  RSP: ffffb25d8dad3b70  RFLAGS: 00010207
    RAX: [PII_REDACTED]  RBX: ffff9706eedc5248  RCX: [PII_REDACTED]
    RDX: [PII_REDACTED]  RSI: ffff97337029ea28  RDI: ffff9706eedc5250
    RBP: ffff9703c3520200   R8: 000000000f46b0b2   R9: [PII_REDACTED]
    R10: [PII_REDACTED]  R11:[PII_REDACTED]0000fe  R12: ffff97337029ea28
    R13: [PII_REDACTED]  R14: ffff9703de59bf60  R15: ffff9706eedc5250
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
 #7 [ffffb25d8dad3ba8] ocfs2_journal_dirty at ffffffffc137fb95 [ocfs2]
 #8 [ffffb25d8dad3be8] __ocfs2_move_extent at ffffffffc139a950 [ocfs2]
 #9 [ffffb25d8dad3c80] ocfs2_defrag_extent at ffffffffc139b2d2 [ocfs2]

Analysis

This bug has the same root cause of 'commit 7f27ec978b0e ("ocfs2: call
ocfs2_journal_access_di() before ocfs2_journal_dirty() in
ocfs2_write_end_nolock()")'.  For this bug, jbd2_journal_restart() is
called by ocfs2_split_extent() during defragmenting.

How to fix

For ocfs2_split_extent() can handle journal operations totally by itself. 
Caller doesn't need to call journal access/dirty pair, and caller only
needs to call journal start/stop pair.  The fix method is to remove
journal access/dirty from __ocfs2_move_extent().

The discussion for this patch:
https://oss.oracle.com/pipermail/ocfs2-devel/2023-February/000647.html
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-617
References: https://git.kernel.org/stable/c/2c559b3ba8e0b9e3c4bb08159a28ccadc698410f; https://git.kernel.org/stable/c/33665d1042666f2e5c736a3df1f453e31f030663; https://git.kernel.org/stable/c/590507ebabd33cd93324c04f9a5538309a5ba934
CVE: CVE-2023-53565
Published: 2025-10-04
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: brcmfmac: Check for probe() id argument being NULL

The probe() id argument may be NULL in 2 scenarios:

1. brcmf_pcie_pm_leave_D3() calling brcmf_pcie_probe() to reprobe
   the device.

2. If a user tries to manually bind the driver from sysfs then the sdio /
   pcie / usb probe() function gets called with NULL as id argument.

1. Is being hit by users causing the following oops on resume and causing
wifi to stop working:

BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
<snip>
Hardware name: Dell Inc. XPS 13 9350/0PWNCR, BIDS 1.13.0 02/10/2020
Workgueue: events_unbound async_run_entry_fn
RIP: 0010:brcmf_pcie_probe+Ox16b/0x7a0 [brcmfmac]
<snip>
Call Trace:
 <TASK>
 brcmf_pcie_pm_leave_D3+0xc5/8x1a0 [brcmfmac be3b4cefca451e190fa35be8f00db1bbec293887]
 ? pci_pm_resume+0x5b/0xf0
 ? pci_legacy_resume+0x80/0x80
 dpm_run_callback+0x47/0x150
 device_resume+0xa2/0x1f0
 async_resume+0x1d/0x30
<snip>

Fix this by checking for id being NULL.

In the PCI and USB cases try a manual lookup of the id so that manually
binding the driver through sysfs and more importantly brcmf_pcie_probe()
on resume will work.

For the SDIO case there is no helper to do a manual sdio_device_id lookup,
so just directly error out on a NULL id there.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/60fc756fc8e6954a5618eecac73b255d651602e4; https://git.kernel.org/stable/c/84766e77a5c35e2b60e34f570c62fc97adc05e09
CVE: CVE-2023-53566
Published: 2025-10-04
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: nft_set_rbtree: fix null deref on element insertion

There is no guarantee that rb_prev() will not return NULL in nft_rbtree_gc_elem():

general protection fault, probably for non-canonical address 0xdffffc[PII_REDACTED]: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x[PII_REDACTED]000018-0x[PII_REDACTED]00001f]
 nft_add_set_elem+0x14b0/0x2990
  nf_tables_newsetelem+0x528/0xb30

Furthermore, there is a possible use-after-free while iterating,
'node' can be free'd so we need to cache the next value to use.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/3fa13203b6d90cc3a33af47b058739f92ab82eef; https://git.kernel.org/stable/c/61ae320a29b0540c[PII_REDACTED]eb86bf2b66c08; https://git.kernel.org/stable/c/899aa5638568abf5d69de7a7bb95e[PII_REDACTED]b
CVE: CVE-2023-53567
Published: 2025-10-04
Description: In the Linux kernel, the following vulnerability has been resolved:

spi: qup: Don't skip cleanup in remove's error path

Returning early in a platform driver's remove callback is wrong. In this
case the dma resources are not released in the error path. this is never
retried later and so this is a permanent leak. To fix this, only skip
hardware disabling if waking the device fails.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/2d0f63077f481f11a07f20eab1c1f4367dfaef32; https://git.kernel.org/stable/c/49c17fccae36505550c[PII_REDACTED]fff337f148a; https://git.kernel.org/stable/c/55ecdcd12bc176b86fecbcb125ac814ac8fe857a
CVE: CVE-2023-53568
Published: 2025-10-04
Description: In the Linux kernel, the following vulnerability has been resolved:

s390/zcrypt: don't leak memory if dev_set_name() fails

When dev_set_name() fails, zcdn_create() doesn't free the newly
allocated resources. Do it.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/[PII_REDACTED]cb2773caee64812a811edcab6b5a55; https://git.kernel.org/stable/c/131cd74a8e38d75239f2c81dfee53d6554eb8bf8; https://git.kernel.org/stable/c/147d8da33a2c2195ec63acd56cd7d80a3458c253
CVE: CVE-2023-53569
Published: 2025-10-04
Description: In the Linux kernel, the following vulnerability has been resolved:

ext2: Check block size validity during mount

Check that log of block size stored in the superblock has sensible
value. Otherwise the shift computing the block size can overflow leading
to undefined behavior.
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/0ebfaf14150f55550cffb1148ed3920143c7a69c; https://git.kernel.org/stable/c/22ab5fed07ad4b206ea910fd0132d1a0d4831584; https://git.kernel.org/stable/c/451b98155be5dfee05bc6e7c8b30c0be4add3f71
CVE: CVE-2023-53570
Published: 2025-10-04
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: nl80211: fix integer overflow in nl80211_parse_mbssid_elems()

nl80211_parse_mbssid_elems() uses a u8 variable num_elems to count the
number of MBSSID elements in the nested netlink attribute attrs, which can
lead to an integer overflow if a user of the nl80211 interface specifies
256 or more elements in the corresponding attribute in userspace. The
integer overflow can lead to a heap buffer overflow as num_elems determines
the size of the trailing array in elems, and this array is thereafter
written to for each element in attrs.

Note that this vulnerability only affects devices with the
wiphy->mbssid_max_interfaces member set for the wireless physical device
struct in the device driver, and can only be triggered by a process with
CAP_NET_ADMIN capabilities.

Fix this by checking for a maximum of 255 elements in attrs.
CVSS Score: 7.8 (HIGH)
CWE: CWE-190
References: https://git.kernel.org/stable/c/6311071a056272e1e761de8d0305e87cc566f734; https://git.kernel.org/stable/c/7d09f9f255a5f78578deba[PII_REDACTED]bb53b16c; https://git.kernel.org/stable/c/e642eb67b8c10dcce758d549cc81564116e0fa49
CVE: CVE-2023-53571
Published: 2025-10-04
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/i915: Make intel_get_crtc_new_encoder() less oopsy

The point of the WARN was to print something, not oops
straight up. Currently that is precisely what happens
if we can't find the connector for the crtc in the atomic
state. Get the dev pointer from the atomic state instead
of the potentially NULL encoder to avoid that.

(cherry picked from commit 3b6692357f70498f617ea1b31a0378070a0acf1c)
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0fe6ef82e4f4764e8f556632e4cd93d78d448e99; https://git.kernel.org/stable/c/54202488c835dab8c648acd107f0bb8eaa699894; https://git.kernel.org/stable/c/631420b06597a33c72b6dcef78d1c2dea17f452d
CVE: CVE-2023-53572
Published: 2025-10-04
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: imx: scu: use _safe list iterator to avoid a use after free

This loop is freeing "clk" so it needs to use list_for_each_entry_safe().
Otherwise it dereferences a freed variable to get the next item on the
loop.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/08cc7cd2c2a29a2abf5bceb8f048c0734d3694ba; https://git.kernel.org/stable/c/0a719f0e4b6f233979e219baff73923e76a96e09; https://git.kernel.org/stable/c/3d90921f91fc6a8c801d527bb5848c99e335c1cf
CVE: CVE-2023-53573
Published: 2025-10-04
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: rs9: Fix suspend/resume

Disabling the cache in commit 2ff4ba9e3702 ("clk: rs9: Fix I2C accessors")
without removing cache synchronization in resume path results in a
kernel panic as map->cache_ops is unset, due to REGCACHE_NONE.
Enable flat cache again to support resume again. num_reg_defaults_raw
is necessary to read the cache defaults from hardware. Some registers
are strapped in hardware and cannot be provided in software.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/632e04739c8f45c2d9ca4d4c5bd18d80c2ac9296; https://git.kernel.org/stable/c/74f4471ad64214dd5046213ebdd6e0930da7bd2c; https://git.kernel.org/stable/c/a[PII_REDACTED]75880d6160a17ace2c0f48717ff33
CVE: CVE-2023-53574
Published: 2025-10-04
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: rtw88: delete timer and free skb queue when unloading

Fix possible crash and memory leak on driver unload by deleting
TX purge timer and freeing C2H queue in 'rtw_core_deinit()',
shrink critical section in the latter by freeing COEX queue
out of TX report lock scope.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/4128b00a6006870e117ab1841e58f369e9284ecb; https://git.kernel.org/stable/c/634fcbcaa4062db39aeb5ac6ed1bc1feb8dd5216
CVE: CVE-2023-53575
Published: 2025-10-04
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: fix potential array out of bounds access

Account for IWL_SEC_WEP_KEY_OFFSET when needed while verifying
key_len size in iwl_mvm_sec_key_add().
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/133b1cd4d98bb8b272335c8e6b0e0c399c0b2ffa; https://git.kernel.org/stable/c/637452360ecde9ac972d19416e[PII_REDACTED]b302
CVE: CVE-2023-53576
Published: 2025-10-04
Description: In the Linux kernel, the following vulnerability has been resolved:

null_blk: Always check queue mode setting from configfs

Make sure to check device queue mode in the null_validate_conf() and
return error for NULL_Q_RQ as we don't allow legacy I/O path, without
this patch we get OOPs when queue mode is set to 1 from configfs,
following are repro steps :-

modprobe null_blk nr_devices=0
mkdir config/nullb/nullb0
echo 1 > config/nullb/nullb0/memory_backed
echo 4096 > config/nullb/nullb0/blocksize
echo 20480 > config/nullb/nullb0/size
echo 1 > config/nullb/nullb0/queue_mode
echo 1 > config/nullb/nullb0/power

Entering kdb (current=0xffff88810acdd080, pid 2372) on processor 42 Oops: (null)
due to oops @ 0xffffffffc041c329
CPU: 42 PID: 2372 Comm: sh Tainted: G           O     N 6.3.0-rc5lblk+ #5
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
RIP: 0010:null_add_dev.part.0+0xd9/0x720 [null_blk]
Code: 01 00 00 85 d2 0f 85 a1 03 00 00 48 83 bb 08 01 00 00 00 0f 85 f7 03 00 00 80 bb 62 01 00 00 00 48 8b 75 20 0f 85 6d 02 00 00 <48> 89 6e 60 48 8b 75 20 bf 06 00 00 00 e8 f5 37 2c c1 48 8b 75 20
RSP: 0018:ffffc900052cbde0 EFLAGS: 00010246
RAX: [PII_REDACTED] RBX: ffff88811084d800 RCX: [PII_REDACTED]
RDX: [PII_REDACTED] RSI: [PII_REDACTED] RDI: ffff888100042e00
RBP: ffff8881053d8200 R08: ffffc900052cbd68 R09: ffff888105db2000
R10: [PII_REDACTED] R11: [PII_REDACTED] R12: [PII_REDACTED]
R13: ffff[PII_REDACTED]00 R14: ffff88810eec1748 R15: ffff88810eec1740
FS:  00007fd445fd1740(0000) GS:ffff8897dfc80000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: [PII_REDACTED] CR3:[PII_REDACTED]a00000 CR4:[PII_REDACTED]350ee0
DR0: ffffffff8437a488 DR1: ffffffff8437a489 DR2: ffffffff8437a48a
DR3: ffffffff8437a48b DR6: 00000000ffff0ff0 DR7: [PII_REDACTED]
Call Trace:
 <TASK>
 nullb_device_power_store+0xd1/0x120 [null_blk]
 configfs_write_iter+0xb4/0x120
 vfs_write+0x2ba/0x3c0
 ksys_write+0x5f/0xe0
 do_syscall_64+0x3b/0x90
 entry_SYSCALL_64_after_hwframe+0x72/0xdc
RIP: 0033:0x7fd4460c57a7
Code: 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
RSP: 002b:00007ffd3792a4a8 EFLAGS: 00000246 ORIG_RAX: [PII_REDACTED]
RAX: ffffffffffffffda RBX: [PII_REDACTED] RCX: 00007fd4460c57a7
RDX: [PII_REDACTED] RSI: 000055b43c02e4c0 RDI: [PII_REDACTED]
RBP: 000055b43c02e4c0 R08:[PII_REDACTED]00000a R09: 00007fd44615b4e0
R10: 00007fd44615b3e0 R11: [PII_REDACTED] R12: [PII_REDACTED]
R13: 00007fd446198520 R14: [PII_REDACTED] R15: 00007fd446198700
 </TASK>
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/35e304dbcefa95237a3d6f94c007bfb10f012b17; https://git.kernel.org/stable/c/63f8793ee60513a09f110ea460a6ff2c33811cdb; https://git.kernel.org/stable/c/651260e563d9f50827dac496dc8a0b9b23d5db1a
CVE: CVE-2023-53577
Published: 2025-10-04
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf, cpumap: Make sure kthread is running before map update returns

The following warning was reported when running stress-mode enabled
xdp_redirect_cpu with some RT threads:

  ------------[ cut here ]------------
  WARNING: CPU: 4 PID: 65 at kernel/bpf/cpumap.c:135
  CPU: 4 PID: 65 Comm: kworker/4:1 Not tainted 6.5.0-rc2+ #1
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
  Workqueue: events cpu_map_kthread_stop
  RIP: 0010:put_cpu_map_entry+0xda/0x220
  ......
  Call Trace:
   <TASK>
   ? show_regs+0x65/0x70
   ? __warn+0xa5/0x240
   ......
   ? put_cpu_map_entry+0xda/0x220
   cpu_map_kthread_stop+0x41/0x60
   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 root cause is the same as commit[PII_REDACTED]31 ("bpf: cpumap: Fix memory
leak in cpu_map_update_elem"). The kthread is stopped prematurely by
kthread_stop() in cpu_map_kthread_stop(), and kthread() doesn't call
cpu_map_kthread_run() at all but XDP program has already queued some
frames or skbs into ptr_ring. So when __cpu_map_ring_cleanup() checks
the ptr_ring, it will find it was not emptied and report a warning.

An alternative fix is to use __cpu_map_ring_cleanup() to drop these
pending frames or skbs when kthread_stop() returns -EINTR, but it may
confuse the user, because these frames or skbs have been handled
correctly by XDP program. So instead of dropping these frames or skbs,
just make sure the per-cpu kthread is running before
__cpu_map_entry_alloc() returns.

After apply the fix, the error handle for kthread_stop() will be
unnecessary because it will always return 0, so just remove it.
CVSS Score: 7.8 (HIGH)
CWE: CWE-401
References: https://git.kernel.org/stable/c/640a604585aa30f93e39b17d4d6ba69fcb1e66c9; https://git.kernel.org/stable/c/7a1178a3671b40746830d355836b72e47ceb2490; https://git.kernel.org/stable/c/b44d28b98f185d2f2348aa3c3636838c316f889e
CVE: CVE-2023-53578
Published: 2025-10-04
Description: In the Linux kernel, the following vulnerability has been resolved:

net: qrtr: Fix an uninit variable access bug in qrtr_tx_resume()

Syzbot reported a bug as following:

=====================================================
BUG: KMSAN: uninit-value in qrtr_tx_resume+0x185/0x1f0 net/qrtr/af_qrtr.c:230
 qrtr_tx_resume+0x185/0x1f0 net/qrtr/af_qrtr.c:230
 qrtr_endpoint_post+0xf85/0x11b0 net/qrtr/af_qrtr.c:519
 qrtr_tun_write_iter+0x270/0x400 net/qrtr/tun.c:108
 call_write_iter include/linux/fs.h:2189 [inline]
 aio_write+0x63a/0x950 fs/aio.c:1600
 io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019
 __do_sys_io_submit fs/aio.c:2078 [inline]
 __se_sys_io_submit+0x293/0x770 fs/aio.c:2048
 __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Uninit was created at:
 slab_post_alloc_hook mm/slab.h:766 [inline]
 slab_alloc_node mm/slub.c:3452 [inline]
 __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491
 __do_kmalloc_node mm/slab_common.c:967 [inline]
 __kmalloc_node_track_caller+0x114/0x3b0 mm/slab_common.c:988
 kmalloc_reserve net/core/skbuff.c:492 [inline]
 __alloc_skb+0x3af/0x8f0 net/core/skbuff.c:565
 __netdev_alloc_skb+0x120/0x7d0 net/core/skbuff.c:630
 qrtr_endpoint_post+0xbd/0x11b0 net/qrtr/af_qrtr.c:446
 qrtr_tun_write_iter+0x270/0x400 net/qrtr/tun.c:108
 call_write_iter include/linux/fs.h:2189 [inline]
 aio_write+0x63a/0x950 fs/aio.c:1600
 io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019
 __do_sys_io_submit fs/aio.c:2078 [inline]
 __se_sys_io_submit+0x293/0x770 fs/aio.c:2048
 __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

It is because that skb->len requires at least sizeof(struct qrtr_ctrl_pkt)
in qrtr_tx_resume(). And skb->len equals to size in qrtr_endpoint_post().
But size is less than sizeof(struct qrtr_ctrl_pkt) when qrtr_cb->type
equals to QRTR_TYPE_RESUME_TX in qrtr_endpoint_post() under the syzbot
scenario. This triggers the uninit variable access bug.

Add size check when qrtr_cb->type equals to QRTR_TYPE_RESUME_TX in
qrtr_endpoint_post() to fix the bug.
CVSS Score: 7.8 (HIGH)
CWE: CWE-908
References: https://git.kernel.org/stable/c/3814d211ff13ee35f2d9437439a6c7df58524137; https://git.kernel.org/stable/c/[PII_REDACTED]de3bcdbe0646e7256dae58fd8083ba; https://git.kernel.org/stable/c/8c9ce34a6ff2c544f96ce0b088e8fd3c1b9698c4
CVE: CVE-2023-53579
Published: 2025-10-04
Description: In the Linux kernel, the following vulnerability has been resolved:

gpio: mvebu: fix irq domain leak

Uwe Kleine-König pointed out we still have one resource leak in the mvebu
driver triggered on driver detach. Let's address it with a custom devm
action.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/44e2afbf650f[PII_REDACTED]fcc9e6b4d2f6e8d547; https://git.kernel.org/stable/c/644ee70267a934be27370f9aa618b29af7290544; https://git.kernel.org/stable/c/b19e90521286a03bc3793fd598f20277a8f99c85
CVE: CVE-2023-53580
Published: 2025-10-04
Description: In the Linux kernel, the following vulnerability has been resolved:

USB: Gadget: core: Help prevent panic during UVC unconfigure

Avichal Rakesh reported a kernel panic that occurred when the UVC
gadget driver was removed from a gadget's configuration.  The panic
involves a somewhat complicated interaction between the kernel driver
and a userspace component (as described in the Link tag below), but
the analysis did make one thing clear: The Gadget core should
accomodate gadget drivers calling usb_gadget_deactivate() as part of
their unbind procedure.

Currently this doesn't work.  gadget_unbind_driver() calls
driver->unbind() while holding the udc->connect_lock mutex, and
usb_gadget_deactivate() attempts to acquire that mutex, which will
result in a deadlock.

The simple fix is for gadget_unbind_driver() to release the mutex when
invoking the ->unbind() callback.  There is no particular reason for
it to be holding the mutex at that time, and the mutex isn't held
while the ->bind() callback is invoked.  So we'll drop the mutex
before performing the unbind callback and reacquire it afterward.

We'll also add a couple of comments to usb_gadget_activate() and
usb_gadget_deactivate().  Because they run in process context they
must not be called from a gadget driver's ->disconnect() callback,
which (according to the kerneldoc for struct usb_gadget_driver in
include/linux/usb/gadget.h) may run in interrupt context.  This may
help prevent similar bugs from arising in the future.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/65dadb2beeb7360232b09ebc4585b54475dfee06; https://git.kernel.org/stable/c/8c1edc00db65f6d4408b3d1cd845e8da3b9e0ca4; https://git.kernel.org/stable/c/bed19d95fcb9c98dfaa9585922b39a2dfba7898d
CVE: CVE-2023-53584
Published: 2025-10-04
Description: In the Linux kernel, the following vulnerability has been resolved:

ubifs: ubifs_releasepage: Remove ubifs_assert(0) to valid this process

There are two states for ubifs writing pages:
1. Dirty, Private
2. Not Dirty, Not Private

The normal process cannot go to ubifs_releasepage() which means there
exists pages being private but not dirty. Reproducer[1] shows that it
could occur (which maybe related to [2]) with following process:

     PA                     PB                    PC
lock(page)[PA]
ubifs_write_end
  attach_page_private         // set Private
  __set_page_dirty_nobuffers  // set Dirty
unlock(page)

write_cache_pages[PA]
  lock(page)
  clear_page_dirty_for_io(page)	// clear Dirty
  ubifs_writepage

                        do_truncation[PB]
			  truncate_setsize
			    i_size_write(inode, newsize) // newsize = 0

    i_size = i_size_read(inode)	// i_size = 0
    end_index = i_size >> PAGE_SHIFT
    if (page->index > end_index)
      goto out // jump
out:
unlock(page)   // Private, Not Dirty

						generic_fadvise[PC]
						  lock(page)
						  invalidate_inode_page
						    try_to_release_page
						      ubifs_releasepage
						        ubifs_assert(c, 0)
		                                        // bad assertion!
						  unlock(page)
			  truncate_pagecache[PB]

Then we may get following assertion failed:
  UBIFS error (ubi0:0 pid 1683): ubifs_assert_failed [ubifs]:
  UBIFS assert failed: 0, in fs/ubifs/file.c:1513
  UBIFS warning (ubi0:0 pid 1683): ubifs_ro_mode [ubifs]:
  switched to read-only mode, error -22
  CPU: 2 PID: 1683 Comm: aa Not tainted 5.16.0-rc5-00184-g0bca5994cacc-dirty #308
  Call Trace:
    dump_stack+0x13/0x1b
    ubifs_ro_mode+0x54/0x60 [ubifs]
    ubifs_assert_failed+0x4b/0x80 [ubifs]
    ubifs_releasepage+0x67/0x1d0 [ubifs]
    try_to_release_page+0x57/0xe0
    invalidate_inode_page+0xfb/0x130
    __invalidate_mapping_pages+0xb9/0x280
    invalidate_mapping_pagevec+0x12/0x20
    generic_fadvise+0x303/0x3c0
    ksys_fadvise64_64+0x4c/0xb0

[1] https://bugzilla.kernel.org/show_bug.cgi?id=215373
[2] https://linux-mtd.infradead.narkive.com/NQoBeT1u/patch-rfc-ubifs-fix-assert-failed-in-ubifs-set-page-dirty
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-617
References: https://git.kernel.org/stable/c/66f4742e93523ab2f062d9d9828b3e590bc61536; https://git.kernel.org/stable/c/7750be5d3e18500b[PII_REDACTED]63b500a0b8b0d8; https://git.kernel.org/stable/c/bd188ff1c8a1935c93a1e3cacf3be62667fdf762