deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2022-50250
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

regulator: core: fix use_count leakage when handling boot-on

I found a use_count leakage towards supply regulator of rdev with
boot-on option.

┌───────────────────┐           ┌───────────────────┐
│  regulator_dev A  │           │  regulator_dev B  │
│     (boot-on)     │           │     (boot-on)     │
│    use_count=0    │◀──supply──│    use_count=1    │
│                   │           │                   │
└───────────────────┘           └───────────────────┘

In case of rdev(A) configured with `regulator-boot-on', the use_count
of supplying regulator(B) will increment inside
regulator_enable(rdev->supply).

Thus, B will acts like always-on, and further balanced
regulator_enable/disable cannot actually disable it anymore.

However, B was also configured with `regulator-boot-on', we wish it
could be disabled afterwards.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0591b14ce[PII_REDACTED]c759f889647369aa616a0; https://git.kernel.org/stable/c/4b737246ff50f810d6ab4be13c1388a07f0c14b1; https://git.kernel.org/stable/c/4dd6e1cc9c7403f1ee1b7eee85bc31b797ae8347
CVE: CVE-2022-50251
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

mmc: vub300: fix return value check of mmc_add_host()

mmc_add_host() may return error, if we ignore its return value, the memory
that allocated in mmc_alloc_host() will be leaked and it will lead a kernel
crash because of deleting not added device in the remove path.

So fix this by checking the return value and goto error path which will call
mmc_free_host(), besides, the timer added before mmc_add_host() needs be del.

And this patch fixes another missing call mmc_free_host() if usb_control_msg()
fails.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/0613ad2401f88bdeae5594c30afe318e93b14676; https://git.kernel.org/stable/c/2044b2ea77945f372ef161d1bbf814e471767ff2; https://git.kernel.org/stable/c/25f05d762ca5e1c685002a53dd44f68e78ca3feb
CVE: CVE-2022-50252
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

igb: Do not free q_vector unless new one was allocated

Avoid potential use-after-free condition under memory pressure. If the
kzalloc() fails, q_vector will be freed but left in the original
adapter->q_vector[v_idx] array position.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/0200f0fbb11e359cc35af72ab10b2ec224e6f633; https://git.kernel.org/stable/c/[PII_REDACTED]ca66f90d395f36ccdaebc3e0e84801; https://git.kernel.org/stable/c/314f7092b27749bdde44c14095b5533afa2a3bc8
CVE: CVE-2022-50253
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: make sure skb->len != 0 when redirecting to a tunneling device

syzkaller managed to trigger another case where skb->len == 0
when we enter __dev_queue_xmit:

WARNING: CPU: 0 PID: 2470 at include/linux/skbuff.h:2576 skb_assert_len include/linux/skbuff.h:2576 [inline]
WARNING: CPU: 0 PID: 2470 at include/linux/skbuff.h:2576 __dev_queue_xmit+0x2069/0x35e0 net/core/dev.c:4295

Call Trace:
 dev_queue_xmit+0x17/0x20 net/core/dev.c:4406
 __bpf_tx_skb net/core/filter.c:2115 [inline]
 __bpf_redirect_no_mac net/core/filter.c:2140 [inline]
 __bpf_redirect+0x5fb/0xda0 net/core/filter.c:2163
 ____bpf_clone_redirect net/core/filter.c:2447 [inline]
 bpf_clone_redirect+0x247/0x390 net/core/filter.c:2419
 bpf_prog_48159a89cb4a9a16+0x59/0x5e
 bpf_dispatcher_nop_func include/linux/bpf.h:897 [inline]
 __bpf_prog_run include/linux/filter.h:596 [inline]
 bpf_prog_run include/linux/filter.h:603 [inline]
 bpf_test_run+0x46c/0x890 net/bpf/test_run.c:402
 bpf_prog_test_run_skb+0xbdc/0x14c0 net/bpf/test_run.c:1170
 bpf_prog_test_run+0x345/0x3c0 kernel/bpf/syscall.c:3648
 __sys_bpf+0x43a/0x6c0 kernel/bpf/syscall.c:5005
 __do_sys_bpf kernel/bpf/syscall.c:5091 [inline]
 __se_sys_bpf kernel/bpf/syscall.c:5089 [inline]
 __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5089
 do_syscall_64+0x54/0x70 arch/x86/entry/common.c:48
 entry_SYSCALL_64_after_hwframe+0x61/0xc6

The reproducer doesn't really reproduce outside of syzkaller
environment, so I'm taking a guess here. It looks like we
do generate correct ETH_HLEN-sized packet, but we redirect
the packet to the tunneling device. Before we do so, we
__skb_pull l2 header and arrive again at skb->len == 0.
Doesn't seem like we can do anything better than having
an explicit check after __skb_pull?
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/07ec7b502800ba9f7b8b15cb01dd6556bb41aaca; https://git.kernel.org/stable/c/1b65704b8c08ae92db29f720d3b298031131da53; https://git.kernel.org/stable/c/5d3f4478d22b2cb1810f6fe0f797411e9d87b3e5
CVE: CVE-2022-50254
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

media: ov8865: Fix an error handling path in ov8865_probe()

The commit in Fixes also introduced some new error handling which should
goto the existing error handling path.
Otherwise some resources leak.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/080e0b[PII_REDACTED]628674b07286f16cc389a892; https://git.kernel.org/stable/c/1f55a2273a7b41895ea6272e51ccb1d797cfd39b
CVE: CVE-2022-50255
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

tracing: Fix reading strings from synthetic events

The follow commands caused a crash:

  # cd /sys/kernel/tracing
  # echo 's:open char file[]' > dynamic_events
  # echo 'hist:keys=common_pid:file=filename:onchange($file).trace(open,$file)' > events/syscalls/sys_enter_openat/trigger'
  # echo 1 > events/synthetic/open/enable

BOOM!

The problem is that the synthetic event field "char file[]" will read
the value given to it as a string without any memory checks to make sure
the address is valid. The above example will pass in the user space
address and the sythetic event code will happily call strlen() on it
and then strscpy() where either one will cause an oops when accessing
user space addresses.

Use the helper functions from trace_kprobe and trace_eprobe that can
read strings safely (and actually succeed when the address is from user
space and the memory is mapped in).

Now the above can show:

     packagekitd-1721    [000] ...2.   104.597170: open: file=/usr/lib/rpm/fileattrs/cmake.attr
    in:imjournal-978     [006] ...2.   104.599642: open: file=/var/lib/rsyslog/imjournal.state.tmp
     packagekitd-1721    [000] ...2.   104.626308: open: file=/usr/lib/rpm/fileattrs/debuginfo.attr
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/0934ae9977c27133449b6dd8c6213970e7eece38; https://git.kernel.org/stable/c/149198d0b884e4606ed1d29b330c70016d878276; https://git.kernel.org/stable/c/d9c79fbcbdb6cb10c07c85040eaf615180b26c48
CVE: CVE-2022-50259
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf, sockmap: fix race in sock_map_free()

sock_map_free() calls release_sock(sk) without owning a reference
on the socket. This can cause use-after-free as syzbot found [1]

Jakub Sitnicki already took care of a similar issue
in sock_hash_free() in commit 75e68e5bf2c7 ("bpf, sockhash:
Synchronize delete from bucket list on map free")

[1]
refcount_t: decrement hit 0; leaking memory.
WARNING: CPU: 0 PID: 3785 at lib/refcount.c:31 refcount_warn_saturate+0x17c/0x1a0 lib/refcount.c:31
Modules linked in:
CPU: 0 PID: 3785 Comm: kworker/u4:6 Not tainted 6.1.0-rc7-syzkaller-00103-gef4d3ea40565 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Workqueue: events_unbound bpf_map_free_deferred
RIP: 0010:refcount_warn_saturate+0x17c/0x1a0 lib/refcount.c:31
Code: 68 8b 31 c0 e8 75 71 15 fd 0f 0b e9 64 ff ff ff e8 d9 6e 4e fd c6 05 62 9c 3d 0a 01 48 c7 c7 80 bb 68 8b 31 c0 e8 54 71 15 fd <0f> 0b e9 43 ff ff ff 89 d9 80 e1 07 80 c1 03 38 c1 0f 8c a2 fe ff
RSP: 0018:ffffc9000456fb60 EFLAGS: 00010246
RAX: eae59bab72dcd700 RBX: [PII_REDACTED] RCX: ffff[PII_REDACTED]c0
RDX: [PII_REDACTED] RSI: [PII_REDACTED] RDI: [PII_REDACTED]
RBP: [PII_REDACTED] R08: ffffffff816fdabd R09: fffff520008adee5
R10: fffff520008adee5 R11: 1ffff920008adee4 R12: [PII_REDACTED]
R13: dffffc[PII_REDACTED] R14: ffff88807b1c6c00 R15: 1ffff1100f638dcf
FS: [PII_REDACTED](0000) GS:ffff8880b9800000(0000) knlGS:[PII_REDACTED]
CS: 0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: 0000001b30c30000 CR3: 000000000d08e000 CR4:[PII_REDACTED]3506f0
DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
Call Trace:
<TASK>
__refcount_dec include/linux/refcount.h:344 [inline]
refcount_dec include/linux/refcount.h:359 [inline]
__sock_put include/net/sock.h:779 [inline]
tcp_release_cb+0x2d0/0x360 net/ipv4/tcp_output.c:1092
release_sock+0xaf/0x1c0 net/core/sock.c:3468
sock_map_free+0x219/0x2c0 net/core/sock_map.c:356
process_one_work+0x81c/0xd10 kernel/workqueue.c:2289
worker_thread+0xb14/0x1330 kernel/workqueue.c:2436
kthread+0x266/0x300 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
</TASK>
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/0a182f8d[PII_REDACTED]56b4dbef5d6cad8de22469; https://git.kernel.org/stable/c/4cabc3af4a6f36c222fecb15858c1060e59218e7; https://git.kernel.org/stable/c/5c[PII_REDACTED]bc73fd6b37748d2d8f95cd8f22f3
CVE: CVE-2022-50261
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/sti: Fix return type of sti_{dvo,hda,hdmi}_connector_mode_valid()

With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:

  drivers/gpu/drm/sti/sti_hda.c:637:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict]
          .mode_valid = sti_hda_connector_mode_valid,
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
  drivers/gpu/drm/sti/sti_dvo.c:376:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict]
          .mode_valid = sti_dvo_connector_mode_valid,
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
  drivers/gpu/drm/sti/sti_hdmi.c:1035:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict]
          .mode_valid = sti_hdmi_connector_mode_valid,
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~

->mode_valid() in 'struct drm_connector_helper_funcs' expects a return
type of 'enum drm_mode_status', not 'int'. Adjust the return type of
sti_{dvo,hda,hdmi}_connector_mode_valid() to match the prototype's to
resolve the warning and CFI failure.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/04371a75a58422a301a9ff9ae3babd310ac3bb3f; https://git.kernel.org/stable/c/0ad811cc08a937d875cbad0149c1bab17f84ba05; https://git.kernel.org/stable/c/511b48ee8e4aec2d03d2af06b363d9eb3230b017
CVE: CVE-2023-53148
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

igb: Fix igb_down hung on surprise removal

In a setup where a Thunderbolt hub connects to Ethernet and a display
through USB Type-C, users may experience a hung task timeout when they
remove the cable between the PC and the Thunderbolt hub.
This is because the igb_down function is called multiple times when
the Thunderbolt hub is unplugged. For example, the igb_io_error_detected
triggers the first call, and the igb_remove triggers the second call.
The second call to igb_down will block at napi_synchronize.
Here's the call trace:
    __schedule+0x3b0/0xddb
    ? __mod_timer+0x164/0x5d3
    schedule+0x44/0xa8
    schedule_timeout+0xb2/0x2a4
    ? run_local_timers+0x4e/0x4e
    msleep+0x31/0x38
    igb_down+0x12c/0x22a [igb[PII_REDACTED]948bfde0bf01429257eb59f13030d4]
    __igb_close+0x6f/0x9c [igb[PII_REDACTED]948bfde0bf01429257eb59f13030d4]
    igb_close+0x23/0x2b [igb[PII_REDACTED]948bfde0bf01429257eb59f13030d4]
    __dev_close_many+0x95/0xec
    dev_close_many+0x6e/0x103
    unregister_netdevice_many+0x105/0x5b1
    unregister_netdevice_queue+0xc2/0x10d
    unregister_netdev+0x1c/0x23
    igb_remove+0xa7/0x11c [igb[PII_REDACTED]948bfde0bf01429257eb59f13030d4]
    pci_device_remove+0x3f/0x9c
    device_release_driver_internal+0xfe/0x1b4
    pci_stop_bus_device+0x5b/0x7f
    pci_stop_bus_device+0x30/0x7f
    pci_stop_bus_device+0x30/0x7f
    pci_stop_and_remove_bus_device+0x12/0x19
    pciehp_unconfigure_device+0x76/0xe9
    pciehp_disable_slot+0x6e/0x131
    pciehp_handle_presence_or_link_change+0x7a/0x3f7
    pciehp_ist+0xbe/0x194
    irq_thread_fn+0x22/0x4d
    ? irq_thread+0x1fd/0x1fd
    irq_thread+0x17b/0x1fd
    ? irq_forced_thread_fn+0x5f/0x5f
    kthread+0x142/0x153
    ? __irq_get_irqchip_state+0x46/0x46
    ? kthread_associate_blkcg+0x71/0x71
    ret_from_fork+0x1f/0x30

In this case, igb_io_error_detected detaches the network interface
and requests a PCIE slot reset, however, the PCIE reset callback is
not being invoked and thus the Ethernet connection breaks down.
As the PCIE error in this case is a non-fatal one, requesting a
slot reset can be avoided.
This patch fixes the task hung issue and preserves Ethernet
connection by ignoring non-fatal PCIE errors.
CVSS Score: 7.8 (HIGH)
CWE: CWE-415
References: https://git.kernel.org/stable/c/004d25060c78fc31f66da0fa439c544dda1ac9d5; https://git.kernel.org/stable/c/124e39a734cb90658b8f0dc110847bbfc6e33792; https://git.kernel.org/stable/c/39695e87d86f0e7d897fba1d2559f825aa20caeb
CVE: CVE-2023-53149
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: avoid deadlock in fs reclaim with page writeback

Ext4 has a filesystem wide lock protecting ext4_writepages() calls to
avoid races with switching of journalled data flag or inode format. This
lock can however cause a deadlock like:

CPU0                            CPU1

ext4_writepages()
  percpu_down_read(sbi->s_writepages_rwsem);
                                ext4_change_inode_journal_flag()
                                  percpu_down_write(sbi->s_writepages_rwsem);
                                    - blocks, all readers block from now on
  ext4_do_writepages()
    ext4_init_io_end()
      kmem_cache_zalloc(io_end_cachep, GFP_KERNEL)
        fs_reclaim frees dentry...
          dentry_unlink_inode()
            iput() - last ref =>
              iput_final() - inode dirty =>
                write_inode_now()...
                  ext4_writepages() tries to acquire sbi->s_writepages_rwsem
                    and blocks forever

Make sure we cannot recurse into filesystem reclaim from writeback code
to avoid the deadlock.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/00d873c17e29cc32d90ca852b82685f1673acaa5; https://git.kernel.org/stable/c/2ec97dc90df40c50e509809dc9a198638a7e18b6; https://git.kernel.org/stable/c/4b4340bf04ce9a52061f15000ecedd126abc093c
CVE: CVE-2023-53150
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: qla2xxx: Pointer may be dereferenced

Klocwork tool reported pointer 'rport' returned from call to function
fc_bsg_to_rport() may be NULL and will be dereferenced.

Add a fix to validate rport before dereferencing.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/005961bd8f066fe931104f67c34ebfcc7f240099; https://git.kernel.org/stable/c/00eca15319d9ce8c31cdf22f32a[PII_REDACTED]df4; https://git.kernel.org/stable/c/0715da51391d223bf4981e28346770edea7eeb74
CVE: CVE-2023-53151
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

md/raid10: prevent soft lockup while flush writes

Currently, there is no limit for raid1/raid10 plugged bio. While flushing
writes, raid1 has cond_resched() while raid10 doesn't, and too many
writes can cause soft lockup.

Follow up soft lockup can be triggered easily with writeback test for
raid10 with ramdisks:

watchdog: BUG: soft lockup - CPU#10 stuck for 27s! [md0_raid10:1293]
Call Trace:
 <TASK>
 call_rcu+0x16/0x20
 put_object+0x41/0x80
 __delete_object+0x50/0x90
 delete_object_full+0x2b/0x40
 kmemleak_free+0x46/0xa0
 slab_free_freelist_hook.constprop.0+0xed/0x1a0
 kmem_cache_free+0xfd/0x300
 mempool_free_slab+0x1f/0x30
 mempool_free+0x3a/0x100
 bio_free+0x59/0x80
 bio_put+0xcf/0x2c0
 free_r10bio+0xbf/0xf0
 raid_end_bio_io+0x78/0xb0
 one_write_done+0x8a/0xa0
 raid10_end_write_request+0x1b4/0x430
 bio_endio+0x175/0x320
 brd_submit_bio+0x3b9/0x9b7 [brd]
 __submit_bio+0x69/0xe0
 submit_bio_noacct_nocheck+0x1e6/0x5a0
 submit_bio_noacct+0x38c/0x7e0
 flush_pending_writes+0xf0/0x240
 raid10d+0xac/0x1ed0

Fix the problem by adding cond_resched() to raid10 like what raid1 did.

Note that unlimited plugged bio still need to be optimized, for example,
in the case of lots of dirty pages writeback, this will take lots of
memory and io will spend a long time in plug, hence io latency is bad.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/00ecb6fa67c0f772290c5ea5ae8b46eefd503b83; https://git.kernel.org/stable/c/010444623e7f4da6b4a4dd603a7da7469981e293; https://git.kernel.org/stable/c/1d467e10507167eb6dc2c281a87675b731955d86
CVE: CVE-2023-53152
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: fix calltrace warning in amddrm_buddy_fini

The following call trace is observed when removing the amdgpu driver, which
is caused by that BOs allocated for psp are not freed until removing.

[61811.450562] RIP: 0010:amddrm_buddy_fini.cold+0x29/0x47 [amddrm_buddy]
[61811.450577] Call Trace:
[61811.450577]  <TASK>
[61811.450579]  amdgpu_vram_mgr_fini+0x135/0x1c0 [amdgpu]
[61811.450728]  amdgpu_ttm_fini+0x207/0x290 [amdgpu]
[61811.450870]  amdgpu_bo_fini+0x27/0xa0 [amdgpu]
[61811.451012]  gmc_v9_0_sw_fini+0x4a/0x60 [amdgpu]
[61811.451166]  amdgpu_device_fini_sw+0x117/0x520 [amdgpu]
[61811.451306]  amdgpu_driver_release_kms+0x16/0x30 [amdgpu]
[61811.451447]  devm_drm_dev_init_release+0x4d/0x80 [drm]
[61811.451466]  devm_action_release+0x15/0x20
[61811.451469]  release_nodes+0x40/0xb0
[61811.451471]  devres_release_all+0x9b/0xd0
[61811.451473]  __device_release_driver+0x1bb/0x2a0
[61811.451476]  driver_detach+0xf3/0x140
[61811.451479]  bus_remove_driver+0x6c/0xf0
[61811.451481]  driver_unregister+0x31/0x60
[61811.451483]  pci_unregister_driver+0x40/0x90
[61811.451486]  amdgpu_exit+0x15/0x447 [amdgpu]

For smu v13_0_2, if the GPU supports xgmi, refer to

commit f5c7e7797060 ("drm/amdgpu: Adjust removal control flow for smu v13_0_2"),

it will run gpu recover in AMDGPU_RESET_FOR_DEVICE_REMOVE mode when removing,
which makes all devices in hive list have hw reset but no resume except the
basic ip blocks, then other ip blocks will not call .hw_fini according to
ip_block.status.hw.

Since psp_free_shared_bufs just includes some software operations, so move
it to psp_sw_fini.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-772
References: https://git.kernel.org/stable/c/[PII_REDACTED]9871d0799bab6bd412c228486af5bf; https://git.kernel.org/stable/c/756d674117f5c451f415d1c4046b927052a90c14; https://git.kernel.org/stable/c/ab6f446c220db0c131f2071846afd835799be0fb
CVE: CVE-2023-53153
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: cfg80211: Fix use after free for wext

Key information in wext.connect is not reset on (re)connect and can hold
data from a previous connection.

Reset key data to avoid that drivers or mac80211 incorrectly detect a
WEP connection request and access the freed or already reused memory.

Additionally optimize cfg80211_sme_connect() and avoid an useless
schedule of conn_work.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/015b8cc5e7c4d7bb671f1984d7b7338c310b185b; https://git.kernel.org/stable/c/22dfb21bf1cd876616d45cda1bc6daa89eec6747; https://git.kernel.org/stable/c/2cfe78619b0de6d2da773978bc2d22797212eaa7
CVE: CVE-2023-53163
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: don't hold ni_lock when calling truncate_setsize()

syzbot is reporting hung task at do_user_addr_fault() [1], for there is
a silent deadlock between PG_locked bit and ni_lock lock.

Since filemap_update_page() calls filemap_read_folio() after calling
folio_trylock() which will set PG_locked bit, ntfs_truncate() must not
call truncate_setsize() which will wait for PG_locked bit to be cleared
when holding ni_lock lock.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0226635c304cfd5c9db9b78c259cb713819b057e; https://git.kernel.org/stable/c/6bb6b1c6b0c31e36736b87a39dd1cbbd9d5ec22f; https://git.kernel.org/stable/c/73fee7e1e5ea11b51c51c46e0577a197ca3602cf
CVE: CVE-2023-53164
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

irqchip/ti-sci: Fix refcount leak in ti_sci_intr_irq_domain_probe

of_irq_find_parent() returns a node pointer with refcount incremented,
We should use of_node_put() on it when not needed anymore.
Add missing of_node_put() to avoid refcount leak.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/02298b7bae12936ca313975b02e7f98b06670d37; https://git.kernel.org/stable/c/07fceab32096c1290b491f2fcaace03f78e2db37; https://git.kernel.org/stable/c/4ae40c20f1519e1767ba01609abc7e8d6485fc0c
CVE: CVE-2023-53165
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

udf: Fix uninitialized array access for some pathnames

For filenames that begin with . and are between 2 and 5 characters long,
UDF charset conversion code would read uninitialized memory in the
output buffer. The only practical impact is that the name may be prepended a
"unification hash" when it is not actually needed but still it is good
to fix this.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/008ae78d1e12efa904dc819b1ec83e2bca6b2c56; https://git.kernel.org/stable/c/028f6055c912588e6f72722d89c30b401bbcf013; https://git.kernel.org/stable/c/3f1368af47acf4d0b2a5fb0d2c0d6919d2234b6d