deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2022-50738
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

vhost-vdpa: fix an iotlb memory leak

Before commit 3d[PII_REDACTED] ("vhost-vdpa: introduce asid based IOTLB")
we called vhost_vdpa_iotlb_unmap(v, iotlb, 0ULL, 0ULL - 1) during
release to free all the resources allocated when processing user IOTLB
messages through vhost_vdpa_process_iotlb_update().
That commit changed the handling of IOTLB a bit, and we accidentally
removed some code called during the release.

We partially fixed this with commit 037d4305569a ("vhost-vdpa: call
vhost_vdpa_cleanup during the release") but a potential memory leak is
still there as showed by kmemleak if the application does not send
VHOST_IOTLB_INVALIDATE or crashes:

  unreferenced object 0xffff888007fbaa30 (size 16):
    comm "blkio-bench", pid 914, jiffies[PII_REDACTED] (age 885.500s)
    hex dump (first 16 bytes):
      40 73 41 07 80 88 ff ff 00 00 00 00 00 00 00 00  @sA.............
    backtrace:
      [<[PII_REDACTED]736d2a>] kmem_cache_alloc_trace+0x142/0x1c0
      [<[PII_REDACTED]740f50>] vhost_vdpa_process_iotlb_msg+0x68c/0x901 [vhost_vdpa]
      [<[PII_REDACTED]e8e205>] vhost_chr_write_iter+0xc0/0x4a0 [vhost]
      [<000000008f2f414a>] vhost_vdpa_chr_write_iter+0x18/0x20 [vhost_vdpa]
      [<00000000de1cd4a0>] vfs_write+0x216/0x4b0
      [<00000000a2850200>] ksys_write+0x71/0xf0
      [<00000000de8e720b>] __x64_sys_write+0x19/0x20
      [<[PII_REDACTED]b12cbb>] do_syscall_64+0x3f/0x90
      [<[PII_REDACTED]6ec465>] entry_SYSCALL_64_after_hwframe+0x63/0xcd

Let's fix this calling vhost_vdpa_iotlb_unmap() on the whole range in
vhost_vdpa_remove_as(). We move that call before vhost_dev_cleanup()
since we need a valid v->vdev.mm in vhost_vdpa_pa_unmap().
vhost_iotlb_reset() call can be removed, since vhost_vdpa_iotlb_unmap()
on the whole range removes all the entries.

The kmemleak log reported was observed with a vDPA device that has `use_va`
set to true (e.g. VDUSE). This patch has been tested with both types of
devices.
References: https://git.kernel.org/stable/c/4e92cb33bfb51eee5f28bb10846c46f266a4bb67; https://git.kernel.org/stable/c/a2907867e2c86067accd2f011d6f23ee5533aa6c; https://git.kernel.org/stable/c/c070c1912a83432530cbb4271d5b9b11fa36b67a
CVE: CVE-2022-50740
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath9k: hif_usb: fix memory leak of urbs in ath9k_hif_usb_dealloc_tx_urbs()

Syzkaller reports a long-known leak of urbs in
ath9k_hif_usb_dealloc_tx_urbs().

The cause of the leak is that usb_get_urb() is called but usb_free_urb()
(or usb_put_urb()) is not called inside usb_kill_urb() as urb->dev or
urb->ep fields have not been initialized and usb_kill_urb() returns
immediately.

The patch removes trying to kill urbs located in hif_dev->tx.tx_buf
because hif_dev->tx.tx_buf is not supposed to contain urbs which are in
pending state (the pending urbs are stored in hif_dev->tx.tx_pending).
The tx.tx_lock is acquired so there should not be any changes in the list.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
References: https://git.kernel.org/stable/c/08aa0537ec8cf29ceccae98acc1a534fc12598c1; https://git.kernel.org/stable/c/134ae5eba41294eff76e4be20d6001b8f0192207; https://git.kernel.org/stable/c/472312fef2b9eccaa03bd59e0ab2527da945e736
CVE: CVE-2022-50741
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

media: imx-jpeg: Disable useless interrupt to avoid kernel panic

There is a hardware bug that the interrupt STMBUF_HALF may be triggered
after or when disable interrupt.
It may led to unexpected kernel panic.
And interrupt STMBUF_HALF and STMBUF_RTND have no other effect.
So disable them and the unused interrupts.

meanwhile clear the interrupt status when disable interrupt.
References: https://git.kernel.org/stable/c/35591c2469953d59abdb16cb7beac834052cdb4f; https://git.kernel.org/stable/c/ad31bc146f0e[PII_REDACTED]f4f99d8a3c3b2761f6; https://git.kernel.org/stable/c/c3720e65c9013a7b2a5dbb63e6bf6d74a35dd894
CVE: CVE-2022-50742
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

misc: ocxl: fix possible refcount leak in afu_ioctl()

eventfd_ctx_put need to be called to put the refcount that gotten by
eventfd_ctx_fdget when ocxl_irq_set_handler fails.
References: https://git.kernel.org/stable/c/11bd8bbdf8f6f5c1145bb158793107a57e3a1f07; https://git.kernel.org/stable/c/66032c43291672bae8b93184d2806f05be3e16df; https://git.kernel.org/stable/c/7ba19a60c74fb0057d4daef2fa2cbfc9522f3ba1
CVE: CVE-2022-50743
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

erofs: Fix pcluster memleak when its block address is zero

syzkaller reported a memleak:
https://syzkaller.appspot.com/bug?id=62f37ff612f0021641eda5b17f056f1668aa9aed

unreferenced object 0xffff88811009c7f8 (size 136):
  ...
  backtrace:
    [<ffffffff821db19b>] z_erofs_do_read_page+0x99b/0x1740
    [<ffffffff821dee9e>] z_erofs_readahead+0x24e/0x580
    [<ffffffff814bc0d6>] read_pages+0x86/0x3d0
    ...

syzkaller constructed a case: in z_erofs_register_pcluster(),
ztailpacking = false and map->m_pa = zero. This makes pcl->obj.index be
zero although pcl is not a inline pcluster.

Then following path adds refcount for grp, but the refcount won't be put
because pcl is inline.

z_erofs_readahead()
  z_erofs_do_read_page() # for another page
    z_erofs_collector_begin()
      erofs_find_workgroup()
        erofs_workgroup_get()

Since it's illegal for the block address of a non-inlined pcluster to
be zero, add check here to avoid registering the pcluster which would
be leaked.
References: https://git.kernel.org/stable/c/618e712b99c78d1004b70a1a9ab0a4830d0b2673; https://git.kernel.org/stable/c/ac54c1f7b288d83b6ba1e320efff24ecc21309cd; https://git.kernel.org/stable/c/c42c0ffe81176940bd5dead474216b7198d77675
CVE: CVE-2022-50744
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: lpfc: Fix hard lockup when reading the rx_monitor from debugfs

During I/O and simultaneous cat of /sys/kernel/debug/lpfc/fnX/rx_monitor, a
hard lockup similar to the call trace below may occur.

The spin_lock_bh in lpfc_rx_monitor_report is not protecting from timer
interrupts as expected, so change the strength of the spin lock to _irq.

Kernel panic - not syncing: Hard LOCKUP
CPU: 3 PID: 110402 Comm: cat Kdump: loaded

exception RIP: native_queued_spin_lock_slowpath+91

[IRQ stack]
 native_queued_spin_lock_slowpath at ffffffffb814e30b
 _raw_spin_lock at ffffffffb89a667a
 lpfc_rx_monitor_record at ffffffffc0a73a36 [lpfc]
 lpfc_cmf_timer at ffffffffc0abbc67 [lpfc]
 __hrtimer_run_queues at ffffffffb8184250
 hrtimer_interrupt at ffffffffb8184ab0
 smp_apic_timer_interrupt at ffffffffb8a026ba
 apic_timer_interrupt at ffffffffb8a01c4f
[End of IRQ stack]

 apic_timer_interrupt at ffffffffb8a01c4f
 lpfc_rx_monitor_report at ffffffffc0a73c80 [lpfc]
 lpfc_rx_monitor_read at ffffffffc0addde1 [lpfc]
 full_proxy_read at ffffffffb83e7fc3
 vfs_read at ffffffffb833fe71
 ksys_read at ffffffffb83402af
 do_syscall_64 at ffffffffb800430b
 entry_SYSCALL_64_after_hwframe at ffffffffb8a000ad
References: https://git.kernel.org/stable/c/2cf66428a2545bb33beb9624124a2377468bb478; https://git.kernel.org/stable/c/39761417ea7b654217d6d9085afbf7c87ba3675d; https://git.kernel.org/stable/c/c44e50f4a0ec00c2298f31f91bc2c3e9bbd81c7e
CVE: CVE-2022-50745
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

staging: media: tegra-video: fix device_node use after free

At probe time this code path is followed:

 * tegra_csi_init
   * tegra_csi_channels_alloc
     * for_each_child_of_node(node, channel) -- iterates over channels
       * automatically gets 'channel'
         * tegra_csi_channel_alloc()
           * saves into chan->of_node a pointer to the channel OF node
       * automatically gets and puts 'channel'
       * now the node saved in chan->of_node has refcount 0, can disappear
   * tegra_csi_channels_init
     * iterates over channels
       * tegra_csi_channel_init -- uses chan->of_node

After that, chan->of_node keeps storing the node until the device is
removed.

of_node_get() the node and of_node_put() it during teardown to avoid any
risk.
References: https://git.kernel.org/stable/c/0fd003d3c708c80350a815eaf37b8e1114b976cf; https://git.kernel.org/stable/c/5451efb2ca30f3c42b9efb8327ce35b62870dbd3; https://git.kernel.org/stable/c/6512c9498fcb97e7c760e3ef86b2272f2c0f765f
CVE: CVE-2022-50746
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

erofs: validate the extent length for uncompressed pclusters

syzkaller reported a KASAN use-after-free:
https://syzkaller.appspot.com/bug?extid=2ae90e873e97f1faf6f2

The referenced fuzzed image actually has two issues:
 - m_pa == 0 as a non-inlined pcluster;
 - The logical length is longer than its physical length.

The first issue has already been addressed.  This patch addresses
the second issue by checking the extent length validity.
References: https://git.kernel.org/stable/c/40c73b2ea9611b5388807be406f30f5e4e1162da; https://git.kernel.org/stable/c/c505feba4c0d76084e56ec498ce819f02a7043ae; https://git.kernel.org/stable/c/dc8b6bd587b13b85aff6e9d36cdfcd3f955cac9e
CVE: CVE-2022-50747
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

hfs: Fix OOB Write in hfs_asc2mac

Syzbot reported a OOB Write bug:

loop0: detected capacity change from 0 to 64
==================================================================
BUG: KASAN: slab-out-of-bounds in hfs_asc2mac+0x467/0x9a0
fs/hfs/trans.c:133
Write of size 1 at addr ffff[PII_REDACTED]4e by task syz-executor391/3632

Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106
 print_address_description+0x74/0x340 mm/kasan/report.c:284
 print_report+0x107/0x1f0 mm/kasan/report.c:395
 kasan_report+0xcd/0x100 mm/kasan/report.c:495
 hfs_asc2mac+0x467/0x9a0 fs/hfs/trans.c:133
 hfs_cat_build_key+0x92/0x170 fs/hfs/catalog.c:28
 hfs_lookup+0x1ab/0x2c0 fs/hfs/dir.c:31
 lookup_open fs/namei.c:3391 [inline]
 open_last_lookups fs/namei.c:3481 [inline]
 path_openat+0x10e6/0x2df0 fs/namei.c:3710
 do_filp_open+0x264/0x4f0 fs/namei.c:3740

If in->len is much larger than HFS_NAMELEN(31) which is the maximum
length of an HFS filename, a OOB write could occur in hfs_asc2mac(). In
that case, when the dst reaches the boundary, the srclen is still
greater than 0, which causes a OOB write.
Fix this by adding a check on dstlen in while() before writing to dst
address.
References: https://git.kernel.org/stable/c/6a95b17e4d4cd2d8278559f930b447f8c9c8cff9; https://git.kernel.org/stable/c/7af9cb8cbb81308ce4b06cc7164267faccbf75dd; https://git.kernel.org/stable/c/8399318b13dc9e0569dee07ba[PII_REDACTED]d4fb2
CVE: CVE-2022-50748
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

ipc: mqueue: fix possible memory leak in init_mqueue_fs()

commit db7cfc380900 ("ipc: Free mq_sysctls if ipc namespace creation
failed")

Here's a similar memory leak to the one fixed by the patch above.
retire_mq_sysctls need to be called when init_mqueue_fs fails after
setup_mq_sysctls.
References: https://git.kernel.org/stable/c/55b3709c6d68e32cd3fdd2a630b1f4c97d51b17c; https://git.kernel.org/stable/c/a1f321051e0dcf2415fb94f81fdc5044cad4c1d6; https://git.kernel.org/stable/c/c579d60f0d0cd87552f64fdebe68b5d941d20309
CVE: CVE-2022-50749
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

acct: fix potential integer overflow in encode_comp_t()

The integer overflow is descripted with following codes:
  > 317 static comp_t encode_comp_t(u64 value)
  > 318 {
  > 319         int exp, rnd;
    ......
  > 341         exp <<= MANTSIZE;
  > 342         exp += value;
  > 343         return exp;
  > 344 }

Currently comp_t is defined as type of '__u16', but the variable 'exp' is
type of 'int', so overflow would happen when variable 'exp' in line 343 is
greater than 65535.
References: https://git.kernel.org/stable/c/0aac6e60c464a5f942f995428e67f8ae1c422250; https://git.kernel.org/stable/c/1750a0983c455a9b3badd848471fc8d58cb61f67; https://git.kernel.org/stable/c/2224897d8187dc22a83e05d9361efcccf67bcf12
CVE: CVE-2022-50750
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/panel/panel-sitronix-st7701: Remove panel on DSI attach failure

In case mipi_dsi_attach() fails, call drm_panel_remove() to
avoid memory leak.
References: https://git.kernel.org/stable/c/0b7c47b7f358f932159a9d5beec9616ef8a0c6b4; https://git.kernel.org/stable/c/13fc167e1645c43c631d7752d98e377f0e4cbb15; https://git.kernel.org/stable/c/23fddf78eac8d79c56f93ab69b6c47a0816967c9
CVE: CVE-2022-50751
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

configfs: fix possible memory leak in configfs_create_dir()

kmemleak reported memory leaks in configfs_create_dir():

unreferenced object 0xffff888009f6af00 (size 192):
  comm "modprobe", pid 3777, jiffies[PII_REDACTED] (age 233.784s)
  backtrace:
    kmem_cache_alloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273)
    new_fragment (./include/linux/slab.h:600 fs/configfs/dir.c:163)
    configfs_register_subsystem (fs/configfs/dir.c:1857)
    basic_write (drivers/hwtracing/stm/p_basic.c:14) stm_p_basic
    do_one_initcall (init/main.c:1296)
    do_init_module (kernel/module/main.c:2455)
    ...

unreferenced object 0xffff888003ba7180 (size 96):
  comm "modprobe", pid 3777, jiffies[PII_REDACTED] (age 233.784s)
  backtrace:
    kmem_cache_alloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273)
    configfs_new_dirent (./include/linux/slab.h:723 fs/configfs/dir.c:194)
    configfs_make_dirent (fs/configfs/dir.c:248)
    configfs_create_dir (fs/configfs/dir.c:296)
    configfs_attach_group.isra.28 (fs/configfs/dir.c:816 fs/configfs/dir.c:852)
    configfs_register_subsystem (fs/configfs/dir.c:1881)
    basic_write (drivers/hwtracing/stm/p_basic.c:14) stm_p_basic
    do_one_initcall (init/main.c:1296)
    do_init_module (kernel/module/main.c:2455)
    ...

This is because the refcount is not correct in configfs_make_dirent().
For normal stage, the refcount is changing as:

configfs_register_subsystem()
  configfs_create_dir()
    configfs_make_dirent()
      configfs_new_dirent() # set s_count = 1
      dentry->d_fsdata = configfs_get(sd); # s_count = 2
...
configfs_unregister_subsystem()
  configfs_remove_dir()
    remove_dir()
      configfs_remove_dirent() # s_count = 1
    dput() ...
      *dentry_unlink_inode()*
        configfs_d_iput() # s_count = 0, release

However, if we failed in configfs_create():

configfs_register_subsystem()
  configfs_create_dir()
    configfs_make_dirent() # s_count = 2
    ...
    configfs_create() # fail
    ->out_remove:
    configfs_remove_dirent(dentry)
      configfs_put(sd) # s_count = 1
      return PTR_ERR(inode);

There is no inode in the error path, so the configfs_d_iput() is lost
and makes sd and fragment memory leaked.

To fix this, when we failed in configfs_create(), manually call
configfs_put(sd) to keep the refcount correct.
References: https://git.kernel.org/stable/c/07f82dca112262b169bec[PII_REDACTED]439cab776; https://git.kernel.org/stable/c/74ac7c9ee2d486c501e7864c903f5098fc477acd; https://git.kernel.org/stable/c/8bc77754224a2c8581727ffe2e958119b4e27c8f
CVE: CVE-2022-50753
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix to do sanity check on summary info

As Wenqing Liu reported in bugzilla:

https://bugzilla.kernel.org/show_bug.cgi?id=216456

BUG: KASAN: use-after-free in recover_data+0x63ae/0x6ae0 [f2fs]
Read of size 4 at addr ffff8881464dcd80 by task mount/1013

CPU: 3 PID: 1013 Comm: mount Tainted: G        W          6.0.0-rc4 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
Call Trace:
 dump_stack_lvl+0x45/0x5e
 print_report.cold+0xf3/0x68d
 kasan_report+0xa8/0x130
 recover_data+0x63ae/0x6ae0 [f2fs]
 f2fs_recover_fsync_data+0x120d/0x1fc0 [f2fs]
 f2fs_fill_super+0x4665/0x61e0 [f2fs]
 mount_bdev+0x2cf/0x3b0
 legacy_get_tree+0xed/0x1d0
 vfs_get_tree+0x81/0x2b0
 path_mount+0x47e/0x19d0
 do_mount+0xce/0xf0
 __x64_sys_mount+0x12c/0x1a0
 do_syscall_64+0x38/0x90
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

The root cause is: in fuzzed image, SSA table is corrupted: ofs_in_node
is larger than ADDRS_PER_PAGE(), result in out-of-range access on 4k-size
page.

- recover_data
 - do_recover_data
  - check_index_in_prev_nodes
   - f2fs_data_blkaddr

This patch adds sanity check on summary info in recovery and GC flow
in where the flows rely on them.

After patch:
[   29.310883] F2FS-fs (loop0): Inconsistent ofs_in_node:65286 in summary, ino:0, nid:6, max:1018
References: https://git.kernel.org/stable/c/0922ad64ccefa3e483e84355942b86e13c8fea68; https://git.kernel.org/stable/c/4a8e8bf280703e04e0b9d91f101e1fdd9a5bd09e; https://git.kernel.org/stable/c/73687c53919f49dff[PII_REDACTED]dab7a35c52854
CVE: CVE-2022-50754
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

apparmor: fix a memleak in multi_transaction_new()

In multi_transaction_new(), the variable t is not freed or passed out
on the failure of copy_from_user(t->data, buf, size), which could lead
to a memleak.

Fix this bug by adding a put_multi_transaction(t) in the error path.
References: https://git.kernel.org/stable/c/11d5fe7da67c3334cefc981297fd5defb78df15c; https://git.kernel.org/stable/c/3d27a436e294ac5d7a51bd5348ca63a42a468b35; https://git.kernel.org/stable/c/775a37ffa9f4681c4ad84c8634a7eec8af7098d4
CVE: CVE-2022-50755
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

udf: Avoid double brelse() in udf_rename()

syzbot reported a warning like below [1]:

VFS: brelse: Trying to free free buffer
WARNING: CPU: 2 PID: 7301 at fs/buffer.c:1145 __brelse+0x67/0xa0
...
Call Trace:
 <TASK>
 invalidate_bh_lru+0x99/0x150
 smp_call_function_many_cond+0xe2a/0x10c0
 ? generic_remap_file_range_prep+0x50/0x50
 ? __brelse+0xa0/0xa0
 ? __mutex_lock+0x21c/0x12d0
 ? smp_call_on_cpu+0x250/0x250
 ? rcu_read_lock_sched_held+0xb/0x60
 ? lock_release+0x587/0x810
 ? __brelse+0xa0/0xa0
 ? generic_remap_file_range_prep+0x50/0x50
 on_each_cpu_cond_mask+0x3c/0x80
 blkdev_flush_mapping+0x13a/0x2f0
 blkdev_put_whole+0xd3/0xf0
 blkdev_put+0x222/0x760
 deactivate_locked_super+0x96/0x160
 deactivate_super+0xda/0x100
 cleanup_mnt+0x222/0x3d0
 task_work_run+0x149/0x240
 ? task_work_cancel+0x30/0x30
 do_exit+0xb29/0x2a40
 ? reacquire_held_locks+0x4a0/0x4a0
 ? do_raw_spin_lock+0x12a/0x2b0
 ? mm_update_next_owner+0x7c0/0x7c0
 ? rwlock_bug.part.0+0x90/0x90
 ? zap_other_threads+0x234/0x2d0
 do_group_exit+0xd0/0x2a0
 __x64_sys_exit_group+0x3a/0x50
 do_syscall_64+0x34/0xb0
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

The cause of the issue is that brelse() is called on both ofibh.sbh
and ofibh.ebh by udf_find_entry() when it returns NULL.  However,
brelse() is called by udf_rename(), too.  So, b_count on buffer_head
becomes unbalanced.

This patch fixes the issue by not calling brelse() by udf_rename()
when udf_find_entry() returns NULL.
References: https://git.kernel.org/stable/c/090bf49833c51da297ec74f98ad2bf44daea9311; https://git.kernel.org/stable/c/156d440dea97deada629bb51cb17887abd862605; https://git.kernel.org/stable/c/40dba68d418237b1ae2beaa06d46a94dd946278e
CVE: CVE-2022-50756
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

nvme-pci: fix mempool alloc size

Convert the max size to bytes to match the units of the divisor that
calculates the worst-case number of PRP entries.

The result is used to determine how many PRP Lists are required. The
code was previously rounding this to 1 list, but we can require 2 in the
worst case. In that scenario, the driver would corrupt memory beyond the
size provided by the mempool.

While unlikely to occur (you'd need a 4MB in exactly 127 phys segments
on a queue that doesn't support SGLs), this memory corruption has been
observed by kfence.
References: https://git.kernel.org/stable/c/9141144b37f30e3e7fa024bcfa0a13011e546ba9; https://git.kernel.org/stable/c/b1814724e0d7162bdf4799f2d565381bc2251c63; https://git.kernel.org/stable/c/c89a529e823d51dd23c7ec0c047c7a454a428541
CVE: CVE-2022-50757
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

media: camss: Clean up received buffers on failed start of streaming

It is required to return the received buffers, if streaming can not be
started. For instance media_pipeline_start() may fail with EPIPE, if
a link validation between entities is not passed, and in such a case
a user gets a kernel warning:

  WARNING: CPU: 1 PID: 520 at drivers/media/common/videobuf2/videobuf2-core.c:1592 vb2_start_streaming+0xec/0x160
  <snip>
  Call trace:
   vb2_start_streaming+0xec/0x160
   vb2_core_streamon+0x9c/0x1a0
   vb2_ioctl_streamon+0x68/0xbc
   v4l_streamon+0x30/0x3c
   __video_do_ioctl+0x184/0x3e0
   video_usercopy+0x37c/0x7b0
   video_ioctl2+0x24/0x40
   v4l2_ioctl+0x4c/0x70

The fix is to correct the error path in video_start_streaming() of camss.
References: https://git.kernel.org/stable/c/04c734c716a97f1493b1edac41316aaed1d2a9d9; https://git.kernel.org/stable/c/24df4fa3e795fb4b15fd4d3c036596e0978d265a; https://git.kernel.org/stable/c/3d5cab726e3b370fea1b6e67183f0e13c409ce5c
CVE: CVE-2022-50758
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

staging: vt6655: fix potential memory leak

In function device_init_td0_ring, memory is allocated for member
td_info of priv->apTD0Rings[i], with i increasing from 0. In case of
allocation failure, the memory is freed in reversed order, with i
decreasing to 0. However, the case i=0 is left out and thus memory is
leaked.

Modify the memory freeing loop to include the case i=0.
References: https://git.kernel.org/stable/c/16a45e78a687eb6c69acc4e62b94b6508b0bfbda; https://git.kernel.org/stable/c/1b3cebeca99e8e0aa4fa57faac8dbf41e967317a; https://git.kernel.org/stable/c/c8ff91535880d41b49699b3829fb6151942de29e
CVE: CVE-2022-50759
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

media: i2c: ov5648: Free V4L2 fwnode data on unbind

The V4L2 fwnode data structure doesn't get freed on unbind, which leads to
a memleak.
References: https://git.kernel.org/stable/c/3a54b72868930f07935accaf95ec4df639324940; https://git.kernel.org/stable/c/4a34fd4d9b548789d4a2018940edbec86282ed3b; https://git.kernel.org/stable/c/c95770e4fc172696dcb1450893cda7d6324d96fc
CVE: CVE-2022-50760
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: Fix PCI device refcount leak in amdgpu_atrm_get_bios()

As comment of pci_get_class() says, it returns a pci_device with its
refcount increased and decreased the refcount for the input parameter
@from if it is not NULL.

If we break the loop in amdgpu_atrm_get_bios() with 'pdev' not NULL, we
need to call pci_dev_put() to decrease the refcount. Add the missing
pci_dev_put() to avoid refcount leak.
References: https://git.kernel.org/stable/c/3360125d721c91d697c71201f18f042ff743e936; https://git.kernel.org/stable/c/6611feef35c0c8c4d297b28a7fc6ab3a2c47eca7; https://git.kernel.org/stable/c/7c1ddf7c664b5bc91f14b1bdeaa45520ef1760e4