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

i2c: designware: Fix handling of real but unexpected device interrupts

Commit c7b79a752871 ("mfd: intel-lpss: Add Intel Alder Lake PCH-S PCI
IDs") caused a regression on certain Gigabyte motherboards for Intel
Alder Lake-S where system crashes to NULL pointer dereference in
i2c_dw_xfer_msg() when system resumes from S3 sleep state ("deep").

I was able to debug the issue on Gigabyte Z690 AORUS ELITE and made
following notes:

- Issue happens when resuming from S3 but not when resuming from
  "s2idle"
- PCI device 00:15.0 == i2c_designware.0 is already in D0 state when
  system enters into pci_pm_resume_noirq() while all other i2c_designware
  PCI devices are in D3. Devices were runtime suspended and in D3 prior
  entering into suspend
- Interrupt comes after pci_pm_resume_noirq() when device interrupts are
  re-enabled
- According to register dump the interrupt really comes from the
  i2c_designware.0. Controller is enabled, I2C target address register
  points to a one detectable I2C device address 0x60 and the
  DW_IC_RAW_INTR_STAT register START_DET, STOP_DET, ACTIVITY and
  TX_EMPTY bits are set indicating completed I2C transaction.

My guess is that the firmware uses this controller to communicate with
an on-board I2C device during resume but does not disable the controller
before giving control to an operating system.

I was told the UEFI update fixes this but never the less it revealed the
driver is not ready to handle TX_EMPTY (or RX_FULL) interrupt when device
is supposed to be idle and state variables are not set (especially the
dev->msgs pointer which may point to NULL or stale old data).

Introduce a new software status flag STATUS_ACTIVE indicating when the
controller is active in driver point of view. Now treat all interrupts
that occur when is not set as unexpected and mask all interrupts from
the controller.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/301c8f5c32c8fb79c67539bc23972dc3ef48024c; https://git.kernel.org/stable/c/7fa5304c4b5b425d4a0b3acf10139a7f6108a85f; https://git.kernel.org/stable/c/a206f7fbe9589c60fafad12884628c909ecb042f
CVE: CVE-2022-50371
Published: 2025-09-17
Description: In the Linux kernel, the following vulnerability has been resolved:

led: qcom-lpg: Fix sleeping in atomic

lpg_brighness_set() function can sleep, while led's brightness_set()
callback must be non-blocking. Change LPG driver to use
brightness_set_blocking() instead.

BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 0, name: swapper/0
preempt_count: 101, expected: 0
INFO: lockdep is turned off.
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W          6.1.0-rc1-00014-gbe99b089c6fc-dirty #85
Hardware name: Qualcomm Technologies, Inc. DB820c (DT)
Call trace:
 dump_backtrace.part.0+0xe4/0xf0
 show_stack+0x18/0x40
 dump_stack_lvl+0x88/0xb4
 dump_stack+0x18/0x34
 __might_resched+0x170/0x254
 __might_sleep+0x48/0x9c
 __mutex_lock+0x4c/0x400
 mutex_lock_nested+0x2c/0x40
 lpg_brightness_single_set+0x40/0x90
 led_set_brightness_nosleep+0x34/0x60
 led_heartbeat_function+0x80/0x170
 call_timer_fn+0xb8/0x340
 __run_timers.part.0+0x20c/0x254
 run_timer_softirq+0x3c/0x7c
 _stext+0x14c/0x578
 ____do_softirq+0x10/0x20
 call_on_irq_stack+0x2c/0x5c
 do_softirq_own_stack+0x1c/0x30
 __irq_exit_rcu+0x164/0x170
 irq_exit_rcu+0x10/0x40
 el1_interrupt+0x38/0x50
 el1h_64_irq_handler+0x18/0x2c
 el1h_64_irq+0x64/0x68
 cpuidle_enter_state+0xc8/0x380
 cpuidle_enter+0x38/0x50
 do_idle+0x244/0x2d0
 cpu_startup_entry+0x24/0x30
 rest_init+0x128/0x1a0
 arch_post_acpi_subsys_init+0x0/0x18
 start_kernel+0x6f4/0x734
 __primary_switched+0xbc/0xc4
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667, CWE-667
References: https://git.kernel.org/stable/c/3031993b3474794ecb71b6f969a3e60e4bda9d8a; https://git.kernel.org/stable/c/380304391fa7fb084745f26b4b9a59f4666520c1; https://git.kernel.org/stable/c/9deba7b51d5ee7a2d93fabb69f9b8189241f90e3
CVE: CVE-2022-50372
Published: 2025-09-17
Description: In the Linux kernel, the following vulnerability has been resolved:

cifs: Fix memory leak when build ntlmssp negotiate blob failed

There is a memory leak when mount cifs:
  unreferenced object 0xffff[PII_REDACTED]00 (size 448):
    comm "mount.cifs", pid 51391, jiffies[PII_REDACTED] (age 330.596s)
    hex dump (first 32 bytes):
      fe 53 4d 42 40 00 00 00 00 00 00 00 01 00 82 00  .SMB@...........
      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    backtrace:
      [<[PII_REDACTED]609a61>] mempool_alloc+0xe1/0x260
      [<00000000adfa6c63>] cifs_small_buf_get+0x24/0x60
      [<00000000ebb404c7>] __smb2_plain_req_init+0x32/0x460
      [<00000000bcf875b4>] SMB2_sess_alloc_buffer+0xa4/0x3f0
      [<[PII_REDACTED]3a2987>] SMB2_sess_auth_rawntlmssp_negotiate+0xf5/0x480
      [<00000000f0c1f4f9>] SMB2_sess_setup+0x253/0x410
      [<00000000a8b83303>] cifs_setup_session+0x18f/0x4c0
      [<[PII_REDACTED]4bd16d>] cifs_get_smb_ses+0xae7/0x13c0
      [<000000006cbc43d9>] mount_get_conns+0x7a/0x730
      [<[PII_REDACTED]22d816>] cifs_mount+0x103/0xd10
      [<00000000e33def3b>] cifs_smb3_do_mount+0x1dd/0xc90
      [<[PII_REDACTED]>] smb3_get_tree+0x1d5/0x300
      [<[PII_REDACTED]71f980>] vfs_get_tree+0x41/0xf0
      [<00000000b670d8a7>] path_mount+0x9b3/0xdd0
      [<000000005e839a7d>] __x64_sys_mount+0x190/0x1d0
      [<[PII_REDACTED]04c3b9>] do_syscall_64+0x35/0x80

When build ntlmssp negotiate blob failed, the session setup request
should be freed.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/30b2d7f8f[PII_REDACTED]d6af45f60270b3eb6736; https://git.kernel.org/stable/c/fa5a70bdd5e565c8696fb04dfe18a4e8aff4695d
CVE: CVE-2022-50374
Published: 2025-09-17
Description: In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_{ldisc,serdev}: check percpu_init_rwsem() failure

syzbot is reporting NULL pointer dereference at hci_uart_tty_close() [1],
for rcu_sync_enter() is called without rcu_sync_init() due to
hci_uart_tty_open() ignoring percpu_init_rwsem() failure.

While we are at it, fix that hci_uart_register_device() ignores
percpu_init_rwsem() failure and hci_uart_unregister_device() does not
call percpu_free_rwsem().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908, CWE-908
References: https://git.kernel.org/stable/c/3124d320c22f3f4388d9ac5c8f37eaad0cefd6b1; https://git.kernel.org/stable/c/75b2c71ea581c7bb1303860d89366a42ad0506d2; https://git.kernel.org/stable/c/98ce10f3f345e61fc6c83bff9cd11cda252b05ac
CVE: CVE-2023-53335
Published: 2025-09-17
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/cxgb4: Fix potential null-ptr-deref in pass_establish()

If get_ep_from_tid() fails to lookup non-NULL value for ep, ep is
dereferenced later regardless of whether it is empty.
This patch adds a simple sanity check to fix the issue.

Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/283861a4c52c1ea4df3dd1b6fc75a50796ce3524; https://git.kernel.org/stable/c/2cfc00e974d75a3aa8155f2660f57d342e1f67ca; https://git.kernel.org/stable/c/9dca64042d855a24b0bd81ce242e5dc7e939f6eb
CVE: CVE-2023-53336
Published: 2025-09-17
Description: In the Linux kernel, the following vulnerability has been resolved:

media: ipu-bridge: Fix null pointer deref on SSDB/PLD parsing warnings

When ipu_bridge_parse_rotation() and ipu_bridge_parse_orientation() run
sensor->adev is not set yet.

So if either of the dev_warn() calls about unknown values are hit this
will lead to a NULL pointer deref.

Set sensor->adev earlier, with a borrowed ref to avoid making unrolling
on errors harder, to fix this.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/284be[PII_REDACTED]e1cf17c03917eecd1d6681bcf; https://git.kernel.org/stable/c/3de35e29cfddfe6bff762b15bcfe8d80bebac6cb; https://git.kernel.org/stable/c/e08b091e33ecf6e4cb2c0c5820a69abe7673280b
CVE: CVE-2023-53337
Published: 2025-09-17
Description: In the Linux kernel, the following vulnerability has been resolved:

nilfs2: do not write dirty data after degenerating to read-only

According to syzbot's report, mark_buffer_dirty() called from
nilfs_segctor_do_construct() outputs a warning with some patterns after
nilfs2 detects metadata corruption and degrades to read-only mode.

After such read-only degeneration, page cache data may be cleared through
nilfs_clear_dirty_page() which may also clear the uptodate flag for their
buffer heads.  However, even after the degeneration, log writes are still
performed by unmount processing etc., which causes mark_buffer_dirty() to
be called for buffer heads without the "uptodate" flag and causes the
warning.

Since any writes should not be done to a read-only file system in the
first place, this fixes the warning in mark_buffer_dirty() by letting
nilfs_segctor_do_construct() abort early if in read-only mode.

This also changes the retry check of nilfs_segctor_write_out() to avoid
unnecessary log write retries if it detects -EROFS that
nilfs_segctor_do_construct() returned.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/13f73ef77baa4764dc1ca4fcbae9cade05b83866; https://git.kernel.org/stable/c/28a65b49eb53e172d[PII_REDACTED]5019658bfdb4d; https://git.kernel.org/stable/c/4005cec6847c06ee191583270b7cdd7e696543cc
CVE: CVE-2023-53338
Published: 2025-09-17
Description: In the Linux kernel, the following vulnerability has been resolved:

lwt: Fix return values of BPF xmit ops

BPF encap ops can return different types of positive values, such like
NET_RX_DROP, NET_XMIT_CN, NETDEV_TX_BUSY, and so on, from function
skb_do_redirect and bpf_lwt_xmit_reroute. At the xmit hook, such return
values would be treated implicitly as LWTUNNEL_XMIT_CONTINUE in
ip(6)_finish_output2. When this happens, skbs that have been freed would
continue to the neighbor subsystem, causing use-after-free bug and
kernel crashes.

To fix the incorrect behavior, skb_do_redirect return values can be
simply discarded, the same as tc-egress behavior. On the other hand,
bpf_lwt_xmit_reroute returns useful errors to local senders, e.g. PMTU
information. Thus convert its return values to avoid the conflict with
LWTUNNEL_XMIT_CONTINUE.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416, CWE-416
References: https://git.kernel.org/stable/c/065d5f17096ec9161180e2c890afdff4dc6125f2; https://git.kernel.org/stable/c/29b22badb7a84b783e3a4fffca16f7768fb31205; https://git.kernel.org/stable/c/65583f9e070db7bece20710cfa2e3daeb0b831d9
CVE: CVE-2023-53339
Published: 2025-09-17
Description: In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix BUG_ON condition in btrfs_cancel_balance

Pausing and canceling balance can race to interrupt balance lead to BUG_ON
panic in btrfs_cancel_balance. The BUG_ON condition in btrfs_cancel_balance
does not take this race scenario into account.

However, the race condition has no other side effects. We can fix that.

Reproducing it with panic trace like this:

  kernel BUG at fs/btrfs/volumes.c:4618!
  RIP: 0010:btrfs_cancel_balance+0x5cf/0x6a0
  Call Trace:
   <TASK>
   ? do_nanosleep+0x60/0x120
   ? hrtimer_nanosleep+0xb7/0x1a0
   ? sched_core_clone_cookie+0x70/0x70
   btrfs_ioctl_balance_ctl+0x55/0x70
   btrfs_ioctl+0xa46/0xd20
   __x64_sys_ioctl+0x7d/0xa0
   do_syscall_64+0x38/0x80
   entry_SYSCALL_64_after_hwframe+0x63/0xcd

  Race scenario as follows:
  > mutex_unlock(&fs_info->balance_mutex);
  > --------------------
  > .......issue pause and cancel req in another thread
  > --------------------
  > ret = __btrfs_balance(fs_info);
  >
  > mutex_lock(&fs_info->balance_mutex);
  > if (ret == -ECANCELED && atomic_read(&fs_info->balance_pause_req)) {
  >         btrfs_info(fs_info, "balance: paused");
  >         btrfs_exclop_balance(fs_info, BTRFS_EXCLOP_BALANCE_PAUSED);
  > }
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-617
References: https://git.kernel.org/stable/c/29eefa6d0d07e185f7bfe9576f91e6dba98189c2; https://git.kernel.org/stable/c/ae81329f7de3aa6f34ecdfa5412e72161a30e9ce; https://git.kernel.org/stable/c/ceb9ba8e30833a4823e2dc73f80ebcdf2498d01a
CVE: CVE-2023-53340
Published: 2025-09-17
Description: In the Linux kernel, the following vulnerability has been resolved:

net/mlx5: Collect command failures data only for known commands

DEVX can issue a general command, which is not used by mlx5 driver.
In case such command is failed, mlx5 is trying to collect the failure
data, However, mlx5 doesn't create a storage for this command, since
mlx5 doesn't use it. This lead to array-index-out-of-bounds error.

Fix it by checking whether the command is known before collecting the
failure data.
CVSS Score: 7.8 (HIGH)
CWE: CWE-129, CWE-129
References: https://git.kernel.org/stable/c/2a0a935fb64ee8af253b9c6133bb6702fb152ac2; https://git.kernel.org/stable/c/411e4d6caa7f7169192b8dacc8421ac4fd64a354; https://git.kernel.org/stable/c/d8b6f175235d7327b4e1b13216859e89496dfbd5
CVE: CVE-2023-53341
Published: 2025-09-17
Description: In the Linux kernel, the following vulnerability has been resolved:

of/fdt: run soc memory setup when early_init_dt_scan_memory fails

If memory has been found early_init_dt_scan_memory now returns 1. If
it hasn't found any memory it will return 0, allowing other memory
setup mechanisms to carry on.

Previously early_init_dt_scan_memory always returned 0 without
distinguishing between any kind of memory setup being done or not. Any
code path after the early_init_dt_scan memory call in the ramips
plat_mem_setup code wouldn't be executed anymore. Making
early_init_dt_scan_memory the only way to initialize the memory.

Some boards, including my mt7621 based Cudy X6 board, depend on memory
initialization being done via the soc_info.mem_detect function
pointer. Those wouldn't be able to obtain memory and panic the kernel
during early bootup with the message "early_init_dt_alloc_memory_arch:
Failed to allocate 12416 bytes align=0x40".
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908, CWE-908
References: https://git.kernel.org/stable/c/04836fc5b720dfa32ff781383d84f63019abf9b9; https://git.kernel.org/stable/c/2a12187d5853d9fd5102278cecef7dac7c8ce7ea; https://git.kernel.org/stable/c/c4849f18185fd4e93b04cd45552f8d68c0240e21
CVE: CVE-2023-53344
Published: 2025-09-17
Description: In the Linux kernel, the following vulnerability has been resolved:

can: bcm: bcm_tx_setup(): fix KMSAN uninit-value in vfs_write

Syzkaller reported the following issue:

=====================================================
BUG: KMSAN: uninit-value in aio_rw_done fs/aio.c:1520 [inline]
BUG: KMSAN: uninit-value in aio_write+0x899/0x950 fs/aio.c:1600
 aio_rw_done fs/aio.c:1520 [inline]
 aio_write+0x899/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+0x11d/0x3b0 mm/slab_common.c:981
 kmalloc_array include/linux/slab.h:636 [inline]
 bcm_tx_setup+0x80e/0x29d0 net/can/bcm.c:930
 bcm_sendmsg+0x3a2/0xce0 net/can/bcm.c:1351
 sock_sendmsg_nosec net/socket.c:714 [inline]
 sock_sendmsg net/socket.c:734 [inline]
 sock_write_iter+0x495/0x5e0 net/socket.c:1108
 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

CPU: 1 PID: 5034 Comm: syz-executor350 Not tainted 6.2.0-rc6-syzkaller-80422-geda666ff2276 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023
=====================================================

We can follow the call chain and find that 'bcm_tx_setup' function
calls 'memcpy_from_msg' to copy some content to the newly allocated
frame of 'op->frames'. After that the 'len' field of copied structure
being compared with some constant value (64 or 8). However, if
'memcpy_from_msg' returns an error, we will compare some uninitialized
memory. This triggers 'uninit-value' issue.

This patch will add 'memcpy_from_msg' possible errors processing to
avoid uninit-value issue.

Tested via syzkaller
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908, CWE-908
References: https://git.kernel.org/stable/c/2b4c99f7d9a57ecd644eda9b1fb0a[PII_REDACTED]f; https://git.kernel.org/stable/c/2e6ad51c709fa794e0ce26003c9c9cd944e3383a; https://git.kernel.org/stable/c/3fa0f1e0e31b1b73cdf59d4c36c7242e6ef821be
CVE: CVE-2023-53345
Published: 2025-09-17
Description: In the Linux kernel, the following vulnerability has been resolved:

rxrpc: Fix potential data race in rxrpc_wait_to_be_connected()

Inside the loop in rxrpc_wait_to_be_connected() it checks call->error to
see if it should exit the loop without first checking the call state.  This
is probably safe as if call->error is set, the call is dead anyway, but we
should probably wait for the call state to have been set to completion
first, lest it cause surprise on the way out.

Fix this by only accessing call->error if the call is complete.  We don't
actually need to access the error inside the loop as we'll do that after.

This caused the following report:

    BUG: KCSAN: data-race in rxrpc_send_data / rxrpc_set_call_completion

    write to 0xffff888159cf3c50 of 4 bytes by task 25673 on cpu 1:
     rxrpc_set_call_completion+0x71/0x1c0 net/rxrpc/call_state.c:22
     rxrpc_send_data_packet+0xba9/0x1650 net/rxrpc/output.c:479
     rxrpc_transmit_one+0x1e/0x130 net/rxrpc/output.c:714
     rxrpc_decant_prepared_tx net/rxrpc/call_event.c:326 [inline]
     rxrpc_transmit_some_data+0x496/0x600 net/rxrpc/call_event.c:350
     rxrpc_input_call_event+0x564/0x1220 net/rxrpc/call_event.c:464
     rxrpc_io_thread+0x307/0x1d80 net/rxrpc/io_thread.c:461
     kthread+0x1ac/0x1e0 kernel/kthread.c:376
     ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308

    read to 0xffff888159cf3c50 of 4 bytes by task 25672 on cpu 0:
     rxrpc_send_data+0x29e/0x1950 net/rxrpc/sendmsg.c:296
     rxrpc_do_sendmsg+0xb7a/0xc20 net/rxrpc/sendmsg.c:726
     rxrpc_sendmsg+0x413/0x520 net/rxrpc/af_rxrpc.c:565
     sock_sendmsg_nosec net/socket.c:724 [inline]
     sock_sendmsg net/socket.c:747 [inline]
     ____sys_sendmsg+0x375/0x4c0 net/socket.c:2501
     ___sys_sendmsg net/socket.c:2555 [inline]
     __sys_sendmmsg+0x263/0x500 net/socket.c:2641
     __do_sys_sendmmsg net/socket.c:2670 [inline]
     __se_sys_sendmmsg net/socket.c:2667 [inline]
     __x64_sys_sendmmsg+0x57/0x60 net/socket.c:2667
     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

    value changed: 0x00000000 -> 0xffffffea
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362, CWE-362
References: https://git.kernel.org/stable/c/2b5fdc0f5caa505afe34d608e2eefadadf2ee67a; https://git.kernel.org/stable/c/3e8ba61a3fe4475a9b5c9fbfc664435c6795d872; https://git.kernel.org/stable/c/454e48a9ff04c5fa1631bb172070fcb6389b97f9
CVE: CVE-2023-53346
Published: 2025-09-17
Description: In the Linux kernel, the following vulnerability has been resolved:

kernel/fail_function: fix memory leak with using debugfs_lookup()

When calling debugfs_lookup() the result must have dput() called on it,
otherwise the memory will leak over time.  To make things simpler, just
call debugfs_lookup_and_remove() instead which handles all of the logic
at once.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/29d53c4c5a6f6d2b93aaac95b65cb4c907faf2ff; https://git.kernel.org/stable/c/2bb3669f576559db273efe49e0e69f82450efbca; https://git.kernel.org/stable/c/94f68f3e059c478e240f65fcb64746fe371295df
CVE: CVE-2023-53349
Published: 2025-09-17
Description: In the Linux kernel, the following vulnerability has been resolved:

media: ov2740: Fix memleak in ov2740_init_controls()

There is a kmemleak when testing the media/i2c/ov2740.c with bpf mock
device:

unreferenced object 0xffff8881090e19e0 (size 16):
  comm "51-i2c-ov2740", pid 278, jiffies[PII_REDACTED] (age 23.613s)
  hex dump (first 16 bytes):
    00 f3 7c 0b 81 88 ff ff 80 75 6a 09 81 88 ff ff  ..|......uj.....
  backtrace:
    [<000000004e9fad8f>] __kmalloc_node+0x44/0x1b0
    [<[PII_REDACTED]c802f4>] kvmalloc_node+0x34/0x180
    [<000000009b8b5c63>] v4l2_ctrl_handler_init_class+0x11d/0x180
[videodev]
    [<[PII_REDACTED]>] ov2740_probe+0x37d/0x84f [ov2740]
    [<[PII_REDACTED]489f59>] i2c_device_probe+0x28d/0x680
    [<[PII_REDACTED]38babe>] really_probe+0x17c/0x3f0
    [<[PII_REDACTED]c7af1c>] __driver_probe_device+0xe3/0x170
    [<00000000e1b3dc24>] device_driver_attach+0x34/0x80
    [<000000005a04a34d>] bind_store+0x10b/0x1a0
    [<00000000ce25d4f2>] drv_attr_store+0x49/0x70
    [<000000007d9f4e9a>] sysfs_kf_write+0x8c/0xb0
    [<00000000be6cff0f>] kernfs_fop_write_iter+0x216/0x2e0
    [<[PII_REDACTED]ddb40a>] vfs_write+0x658/0x810
    [<[PII_REDACTED]beecdd>] ksys_write+0xd6/0x1b0
    [<[PII_REDACTED]>] do_syscall_64+0x38/0x90
    [<00000000b2cc2da2>] entry_SYSCALL_64_after_hwframe+0x63/0xcd

ov2740_init_controls() won't clean all the allocated resources in fail
path, which may causes the memleaks. Add v4l2_ctrl_handler_free() to
prevent memleak.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/2d899592ed7829d0d5140853bac4d58742a6b8af; https://git.kernel.org/stable/c/3969b2ebc66039306f505c7c630c5530800f83c0; https://git.kernel.org/stable/c/7c405ee63447f14eefcfe12a18aa749abbd596ea
CVE: CVE-2023-53350
Published: 2025-09-17
Description: In the Linux kernel, the following vulnerability has been resolved:

accel/qaic: Fix slicing memory leak

The temporary buffer storing slicing configuration data from user is only
freed on error.  This is a memory leak.  Free the buffer unconditionally.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/2d956177b7c96e62fac762a3b7da4318cde27a73; https://git.kernel.org/stable/c/df45c3e46cdb41f486eecb4277fbcc4c1ffbf9be