deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2021-47633
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ath5k: fix OOB in ath5k_eeprom_read_pcal_info_5111

The bug was found during fuzzing. Stacktrace locates it in
ath5k_eeprom_convert_pcal_info_5111.
When none of the curve is selected in the loop, idx can go
up to AR5K_EEPROM_N_PD_CURVES. The line makes pd out of bound.
pd = &chinfo[pier].pd_curves[idx];

There are many OOB writes using pd later in the code. So I
added a sanity check for idx. Checks for other loops involving
AR5K_EEPROM_N_PD_CURVES are not needed as the loop index is not
used outside the loops.

The patch is NOT tested with real device.

The following is the fuzzing report

BUG: KASAN: slab-out-of-bounds in ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k]
Write of size 1 at addr ffff8880174a4d60 by task modprobe/214

CPU: 0 PID: 214 Comm: modprobe Not tainted 5.6.0 #1
Call Trace:
 dump_stack+0x76/0xa0
 print_address_description.constprop.0+0x16/0x200
 ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k]
 ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k]
 __kasan_report.cold+0x37/0x7c
 ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k]
 kasan_report+0xe/0x20
 ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k]
 ? apic_timer_interrupt+0xa/0x20
 ? ath5k_eeprom_init_11a_pcal_freq+0xbc0/0xbc0 [ath5k]
 ? ath5k_pci_eeprom_read+0x228/0x3c0 [ath5k]
 ath5k_eeprom_init+0x2513/0x6290 [ath5k]
 ? ath5k_eeprom_init_11a_pcal_freq+0xbc0/0xbc0 [ath5k]
 ? usleep_range+0xb8/0x100
 ? apic_timer_interrupt+0xa/0x20
 ? ath5k_eeprom_read_pcal_info_2413+0x2f20/0x2f20 [ath5k]
 ath5k_hw_init+0xb60/0x1970 [ath5k]
 ath5k_init_ah+0x6fe/0x2530 [ath5k]
 ? kasprintf+0xa6/0xe0
 ? ath5k_stop+0x140/0x140 [ath5k]
 ? _dev_notice+0xf6/0xf6
 ? apic_timer_interrupt+0xa/0x20
 ath5k_pci_probe.cold+0x29a/0x3d6 [ath5k]
 ? ath5k_pci_eeprom_read+0x3c0/0x3c0 [ath5k]
 ? mutex_lock+0x89/0xd0
 ? ath5k_pci_eeprom_read+0x3c0/0x3c0 [ath5k]
 local_pci_probe+0xd3/0x160
 pci_device_probe+0x23f/0x3e0
 ? pci_device_remove+0x280/0x280
 ? pci_device_remove+0x280/0x280
 really_probe+0x209/0x5d0
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/25efc5d03455c3839249bc77fce5e29ecb54677e; https://git.kernel.org/stable/c/564d4eceb97eaf381dd6ef6470b06377bb50c95a; https://git.kernel.org/stable/c/9d7d83d0399e23d66fd431b553842a84ac10398f
CVE: CVE-2021-47636
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ubifs: Fix read out-of-bounds in ubifs_wbuf_write_nolock()

Function ubifs_wbuf_write_nolock() may access buf out of bounds in
following process:

ubifs_wbuf_write_nolock():
  aligned_len = ALIGN(len, 8);   // Assume len = 4089, aligned_len = 4096
  if (aligned_len <= wbuf->avail) ... // Not satisfy
  if (wbuf->used) {
    ubifs_leb_write()  // Fill some data in avail wbuf
    len -= wbuf->avail;   // len is still not 8-bytes aligned
    aligned_len -= wbuf->avail;
  }
  n = aligned_len >> c->max_write_shift;
  if (n) {
    n <<= c->max_write_shift;
    err = ubifs_leb_write(c, wbuf->lnum, buf + written,
                          wbuf->offs, n);
    // n > len, read out of bounds less than 8(n-len) bytes
  }

, which can be catched by KASAN:
  =========================================================
  BUG: KASAN: slab-out-of-bounds in ecc_sw_hamming_calculate+0x1dc/0x7d0
  Read of size 4 at addr ffff888105594ff8 by task kworker/u8:4/128
  Workqueue: writeback wb_workfn (flush-ubifs_0_0)
  Call Trace:
    kasan_report.cold+0x81/0x165
    nand_write_page_swecc+0xa9/0x160
    ubifs_leb_write+0xf2/0x1b0 [ubifs]
    ubifs_wbuf_write_nolock+0x421/0x12c0 [ubifs]
    write_head+0xdc/0x1c0 [ubifs]
    ubifs_jnl_write_inode+0x627/0x960 [ubifs]
    wb_workfn+0x8af/0xb80

Function ubifs_wbuf_write_nolock() accepts that parameter 'len' is not 8
bytes aligned, the 'len' represents the true length of buf (which is
allocated in 'ubifs_jnl_xxx', eg. ubifs_jnl_write_inode), so
ubifs_wbuf_write_nolock() must handle the length read from 'buf' carefully
to write leb safely.

Fetch a reproducer in [Link].
CVSS Score: 7.1 (HIGH)
CWE: CWE-125, CWE-125
References: https://git.kernel.org/stable/c/07a209fadee7b53b46858538e[PII_REDACTED]62e4; https://git.kernel.org/stable/c/3b7fb89135a20587d57f8877c02e25003e9edbdf; https://git.kernel.org/stable/c/4f2262a334641e05f645364d5ade1f565c85f20b
CVE: CVE-2021-47637
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ubifs: Fix deadlock in concurrent rename whiteout and inode writeback

Following hung tasks:
[   77.028764] task:kworker/u8:4    state:D stack:    0 pid:  132
[   77.028820] Call Trace:
[   77.029027]  schedule+0x8c/0x1b0
[   77.029067]  mutex_lock+0x50/0x60
[   77.029074]  ubifs_write_inode+0x68/0x1f0 [ubifs]
[   77.029117]  __writeback_single_inode+0x43c/0x570
[   77.029128]  writeback_sb_inodes+0x259/0x740
[   77.029148]  wb_writeback+0x107/0x4d0
[   77.029163]  wb_workfn+0x162/0x7b0

[   92.390442] task:aa              state:D stack:    0 pid: 1506
[   92.390448] Call Trace:
[   92.390458]  schedule+0x8c/0x1b0
[   92.390461]  wb_wait_for_completion+0x82/0xd0
[   92.390469]  __writeback_inodes_sb_nr+0xb2/0x110
[   92.390472]  writeback_inodes_sb_nr+0x14/0x20
[   92.390476]  ubifs_budget_space+0x705/0xdd0 [ubifs]
[   92.390503]  do_rename.cold+0x7f/0x187 [ubifs]
[   92.390549]  ubifs_rename+0x8b/0x180 [ubifs]
[   92.390571]  vfs_rename+0xdb2/0x1170
[   92.390580]  do_renameat2+0x554/0x770

, are caused by concurrent rename whiteout and inode writeback processes:
	rename_whiteout(Thread 1)	        wb_workfn(Thread2)
ubifs_rename
  do_rename
    lock_4_inodes (Hold ui_mutex)
    ubifs_budget_space
      make_free_space
        shrink_liability
	  __writeback_inodes_sb_nr
	    bdi_split_work_to_wbs (Queue new wb work)
					      wb_do_writeback(wb work)
						__writeback_single_inode
					          ubifs_write_inode
					            LOCK(ui_mutex)
							   ↑
	      wb_wait_for_completion (Wait wb work) <-- deadlock!

Reproducer (Detail program in [Link]):
  1. SYS_renameat2("/mp/dir/file", "/mp/dir/whiteout", RENAME_WHITEOUT)
  2. Consume out of space before kernel(mdelay) doing budget for whiteout

Fix it by doing whiteout space budget before locking ubifs inodes.
BTW, it also fixes wrong goto tag 'out_release' in whiteout budget
error handling path(It should at least recover dir i_size and unlock
4 ubifs inodes).
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667, CWE-667
References: https://git.kernel.org/stable/c/37bdf1ad592555ecda1d55b89f6e393e4c0589d1; https://git.kernel.org/stable/c/70e9090acc32348cedc5def0cd6d5c126efc97b9; https://git.kernel.org/stable/c/83e42a78428fc354f5e2049935b84c8d8d29b787
CVE: CVE-2021-47638
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ubifs: rename_whiteout: Fix double free for whiteout_ui->data

'whiteout_ui->data' will be freed twice if space budget fail for
rename whiteout operation as following process:

rename_whiteout
  dev = kmalloc
  whiteout_ui->data = dev
  kfree(whiteout_ui->data)  // Free first time
  iput(whiteout)
    ubifs_free_inode
      kfree(ui->data)	    // Double free!

KASAN reports:
==================================================================
BUG: KASAN: double-free or invalid-free in ubifs_free_inode+0x4f/0x70
Call Trace:
  kfree+0x117/0x490
  ubifs_free_inode+0x4f/0x70 [ubifs]
  i_callback+0x30/0x60
  rcu_do_batch+0x366/0xac0
  __do_softirq+0x133/0x57f

Allocated by task 1506:
  kmem_cache_alloc_trace+0x3c2/0x7a0
  do_rename+0x9b7/0x1150 [ubifs]
  ubifs_rename+0x106/0x1f0 [ubifs]
  do_syscall_64+0x35/0x80

Freed by task 1506:
  kfree+0x117/0x490
  do_rename.cold+0x53/0x8a [ubifs]
  ubifs_rename+0x106/0x1f0 [ubifs]
  do_syscall_64+0x35/0x80

The buggy address belongs to the object at ffff88810238bed8 which
belongs to the cache kmalloc-8 of size 8
==================================================================

Let ubifs_free_inode() free 'whiteout_ui->data'. BTW, delete unused
assignment 'whiteout_ui->data_len = 0', process 'ubifs_evict_inode()
-> ubifs_jnl_delete_inode() -> ubifs_jnl_write_inode()' doesn't need it
(because 'inc_nlink(whiteout)' won't be excuted by 'goto out_release',
 and the nlink of whiteout inode is 0).
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-415, CWE-415
References: https://git.kernel.org/stable/c/14276d38c89a170363e90b6ac0a53c3cf61b87fc; https://git.kernel.org/stable/c/2ad07009c459e56ebdcc089d850d664660fdb742; https://git.kernel.org/stable/c/2b3236ecf96db7af5836e1366ce39ace8ce832fa
CVE: CVE-2021-47639
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: x86/mmu: Zap _all_ roots when unmapping gfn range in TDP MMU

Zap both valid and invalid roots when zapping/unmapping a gfn range, as
KVM must ensure it holds no references to the freed page after returning
from the unmap operation.  Most notably, the TDP MMU doesn't zap invalid
roots in mmu_notifier callbacks.  This leads to use-after-free and other
issues if the mmu_notifier runs to completion while an invalid root
zapper yields as KVM fails to honor the requirement that there must be
_no_ references to the page after the mmu_notifier returns.

The bug is most easily reproduced by hacking KVM to cause a collision
between set_nx_huge_pages() and kvm_mmu_notifier_release(), but the bug
exists between kvm_mmu_notifier_invalidate_range_start() and memslot
updates as well.  Invalidating a root ensures pages aren't accessible by
the guest, and KVM won't read or write page data itself, but KVM will
trigger e.g. kvm_set_pfn_dirty() when zapping SPTEs, and thus completing
a zap of an invalid root _after_ the mmu_notifier returns is fatal.

  WARNING: CPU: 24 PID: 1496 at arch/x86/kvm/../../../virt/kvm/kvm_main.c:173 [kvm]
  RIP: 0010:kvm_is_zone_device_pfn+0x96/0xa0 [kvm]
  Call Trace:
   <TASK>
   kvm_set_pfn_dirty+0xa8/0xe0 [kvm]
   __handle_changed_spte+0x2ab/0x5e0 [kvm]
   __handle_changed_spte+0x2ab/0x5e0 [kvm]
   __handle_changed_spte+0x2ab/0x5e0 [kvm]
   zap_gfn_range+0x1f3/0x310 [kvm]
   kvm_tdp_mmu_zap_invalidated_roots+0x50/0x90 [kvm]
   kvm_mmu_zap_all_fast+0x177/0x1a0 [kvm]
   set_nx_huge_pages+0xb4/0x190 [kvm]
   param_attr_store+0x70/0x100
   module_attr_store+0x19/0x30
   kernfs_fop_write_iter+0x119/0x1b0
   new_sync_write+0x11c/0x1b0
   vfs_write+0x1cc/0x270
   ksys_write+0x5f/0xe0
   do_syscall_64+0x38/0xc0
   entry_SYSCALL_64_after_hwframe+0x44/0xae
   </TASK>
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/0c8a8da182d4333d9bbb9131d765145568c847b2; https://git.kernel.org/stable/c/8cf6f98ab1d16d5e607635a0c21c4231eb15367e; https://git.kernel.org/stable/c/af47248407c0c5ae52a752af1ab5ce5b0db91502
CVE: CVE-2021-47640
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

powerpc/kasan: Fix early region not updated correctly

The shadow's page table is not updated when PTE_RPN_SHIFT is 24
and PAGE_SHIFT is 12. It not only causes false positives but
also false negative as shown the following text.

Fix it by bringing the logic of kasan_early_shadow_page_entry here.

1. False Positive:
==================================================================
BUG: KASAN: vmalloc-out-of-bounds in pcpu_alloc+0x508/0xa50
Write of size 16 at addr f57f3be0 by task swapper/0/1

CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.0-12267-gdebe436e77c7 #1
Call Trace:
[c80d1c20] [c07fe7b8] dump_stack_lvl+0x4c/0x6c (unreliable)
[c80d1c40] [c02ff668] print_address_description.constprop.0+0x88/0x300
[c80d1c70] [c02ff45c] kasan_report+0x1ec/0x200
[c80d1cb0] [c0300b20] kasan_check_range+0x160/0x2f0
[c80d1cc0] [c03018a4] memset+0x34/0x90
[c80d1ce0] [c0280108] pcpu_alloc+0x508/0xa50
[c80d1d40] [c02fd7bc] __kmem_cache_create+0xfc/0x570
[c80d1d70] [c0283d64] kmem_cache_create_usercopy+0x274/0x3e0
[c80d1db0] [c2036580] init_sd+0xc4/0x1d0
[c80d1de0] [c00044a0] do_one_initcall+0xc0/0x33c
[c80d1eb0] [c2001624] kernel_init_freeable+0x2c8/0x384
[c80d1ef0] [c0004b14] kernel_init+0x24/0x170
[c80d1f10] [c001b26c] ret_from_kernel_thread+0x5c/0x64

Memory state around the buggy address:
 f57f3a80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
 f57f3b00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
>f57f3b80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
                                               ^
 f57f3c00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
 f57f3c80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
==================================================================

2. False Negative (with KASAN tests):
==================================================================
Before fix:
    ok 45 - kmalloc_double_kzfree
    # vmalloc_oob: EXPECTATION FAILED at lib/test_kasan.c:1039
    KASAN failure expected in "((volatile char *)area)[3100]", but none occurred
    not ok 46 - vmalloc_oob
    not ok 1 - kasan

==================================================================
After fix:
    ok 1 - kasan
CVSS Score: 7.8 (HIGH)
CWE: CWE-787, CWE-787
References: https://git.kernel.org/stable/c/5a3d8f3192a409893c57808cc935e16484df1068; https://git.kernel.org/stable/c/7f19245c3647afea8c7c41f795506ef70f64b9f2; https://git.kernel.org/stable/c/dd75080aa8409ce10d50fb58981c6b59bf8707d3
CVE: CVE-2021-47641
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

video: fbdev: cirrusfb: check pixclock to avoid divide by zero

Do a sanity check on pixclock value to avoid divide by zero.

If the pixclock value is zero, the cirrusfb driver will round up
pixclock to get the derived frequency as close to maxclock as
possible.

Syzkaller reported a divide error in cirrusfb_check_pixclock.

divide error: 0000 [#1] SMP KASAN PTI
CPU: 0 PID: 14938 Comm: cirrusfb_test Not tainted 5.15.0-rc6 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2
RIP: 0010:cirrusfb_check_var+0x6f1/0x1260

Call Trace:
 fb_set_var+0x398/0xf90
 do_fb_ioctl+0x4b8/0x6f0
 fb_ioctl+0xeb/0x130
 __x64_sys_ioctl+0x19d/0x220
 do_syscall_64+0x3a/0x80
 entry_SYSCALL_64_after_hwframe+0x44/0xae
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-369, CWE-369
References: https://git.kernel.org/stable/c/1d3fb46439ad4e8f0c5739eb33d1875ac9e0f135; https://git.kernel.org/stable/c/40b13e3d85744210db[PII_REDACTED]634e2d056bd; https://git.kernel.org/stable/c/45800c42ef000f417270bcfc08630e42486fca99
CVE: CVE-2021-47642
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

video: fbdev: nvidiafb: Use strscpy() to prevent buffer overflow

Coverity complains of a possible buffer overflow. However,
given the 'static' scope of nvidia_setup_i2c_bus() it looks
like that can't happen after examiniing the call sites.

CID 19036 (#1 of 1): Copy into fixed size buffer (STRING_OVERFLOW)
1. fixed_size_dest: You might overrun the 48-character fixed-size string
  chan->adapter.name by copying name without checking the length.
2. parameter_as_source: Note: This defect has an elevated risk because the
  source argument is a parameter of the current function.
 89        strcpy(chan->adapter.name, name);

Fix this warning by using strscpy() which will silence the warning and
prevent any future buffer overflows should the names used to identify the
channel become much longer.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/055cdd2e7b992921424d4daaa285ced787fb205f; https://git.kernel.org/stable/c/08dff[PII_REDACTED]35c185532b1ad7d584785a86e; https://git.kernel.org/stable/c/37a1a2e6eeeb101285cd34e12e48a881524701aa
CVE: CVE-2021-47643
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

media: ir_toy: free before error exiting

Fix leak in error path.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/2011363c196846c083649c91ed30aeef64358d52; https://git.kernel.org/stable/c/382e0f6958ef34eb093127b6d74c12f3b8fd0904; https://git.kernel.org/stable/c/52cdb013036391d9d87aba5b4fc49cdfc6ea4b23
CVE: CVE-2021-47644
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

media: staging: media: zoran: move videodev alloc

Move some code out of zr36057_init() and create new functions for handling
zr->video_dev. This permit to ease code reading and fix a zr->video_dev
memory leak.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/1e501ec38796f43e995731d1bcd4173cb1ccfce0; https://git.kernel.org/stable/c/82e3a496eb56da0b9f29fdc5b63cedb3289e91de; https://git.kernel.org/stable/c/8dce4b265a[PII_REDACTED]f69645840dabc718c687
CVE: CVE-2021-47645
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

media: staging: media: zoran: calculate the right buffer number for zoran_reap_stat_com

On the case tmp_dcim=1, the index of buffer is miscalculated.
This generate a NULL pointer dereference later.

So let's fix the calcul and add a check to prevent this to reappear.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/20811bbe685ca3eddd34b0c750860427d7030910; https://git.kernel.org/stable/c/20db2ed1e2f9fcd417fa67853e5154f0c2537d6c; https://git.kernel.org/stable/c/7e76f3ed7ab2ae026c6ef9cc23096a7554af8c52
CVE: CVE-2021-47646
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

Revert "Revert "block, bfq: honor already-setup queue merges""

A crash [1] happened to be triggered in conjunction with commit
2d52c58b9c9b ("block, bfq: honor already-setup queue merges"). The
latter was then reverted by commit ebc69e897e17 ("Revert "block, bfq:
honor already-setup queue merges""). Yet, the reverted commit was not
the one introducing the bug. In fact, it actually triggered a UAF
introduced by a different commit, and now fixed by commit d29bd41428cf
("block, bfq: reset last_bfqq_created on group change").

So, there is no point in keeping commit 2d52c58b9c9b ("block, bfq:
honor already-setup queue merges") out. This commit restores it.

[1] https://bugzilla.kernel.org/show_bug.cgi?id=214503
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/15729ff8143f8135b03988a100a19e66d7cb7ecd; https://git.kernel.org/stable/c/4083925bd6dc89216d156474a8076feec904e607; https://git.kernel.org/stable/c/65d8a737452e88f251fe5d925371de6d606df613
CVE: CVE-2021-47648
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

gpu: host1x: Fix a memory leak in 'host1x_remove()'

Add a missing 'host1x_channel_list_free()' call in the remove function,
as already done in the error handling path of the probe function.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/025c6643a81564f066d8381b9e2f4603e0f8438f; https://git.kernel.org/stable/c/5124a344983e1b9670dae7add0e4d00d589aabcd; https://git.kernel.org/stable/c/6bb107332db28a0e9256c2d36a0902b85307612c
CVE: CVE-2021-47649
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

udmabuf: validate ubuf->pagecount

Syzbot has reported GPF in sg_alloc_append_table_from_pages(). The
problem was in ubuf->pages == ZERO_PTR.

ubuf->pagecount is calculated from arguments passed from user-space. If
user creates udmabuf with list.size == 0 then ubuf->pagecount will be
also equal to zero; it causes kmalloc_array() to return ZERO_PTR.

Fix it by validating ubuf->pagecount before passing it to
kmalloc_array().
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2b6dd600dd72573c23ea180b5b0b2f[PII_REDACTED]; https://git.kernel.org/stable/c/5d50f851dd307c07ca[PII_REDACTED]f19967c834a9; https://git.kernel.org/stable/c/811b667cefbea9cb7511a874b169d6a92907137e
CVE: CVE-2021-47650
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: soc-compress: prevent the potentially use of null pointer

There is one call trace that snd_soc_register_card()
->snd_soc_bind_card()->soc_init_pcm_runtime()
->snd_soc_dai_compress_new()->snd_soc_new_compress().
In the trace the 'codec_dai' transfers from card->dai_link,
and we can see from the snd_soc_add_pcm_runtime() in
snd_soc_bind_card() that, if value of card->dai_link->num_codecs
is 0, then 'codec_dai' could be null pointer caused
by index out of bound in 'asoc_rtd_to_codec(rtd, 0)'.
And snd_soc_register_card() is called by various platforms.
Therefore, it is better to add the check in the case of misusing.
And because 'cpu_dai' has already checked in soc_init_pcm_runtime(),
there is no need to check again.
Adding the check as follow, then if 'codec_dai' is null,
snd_soc_new_compress() will not pass through the check
'if (playback + capture != 1)', avoiding the leftover use of
'codec_dai'.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/08af6da684b44097ea09f1d74d5858b837ed203b; https://git.kernel.org/stable/c/4639c1d97f385f4784f44d66a3da0672f4951ada; https://git.kernel.org/stable/c/68a69ad8df959e5211ed4a8e120783b2d352ea74
CVE: CVE-2021-47651
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

soc: qcom: rpmpd: Check for null return of devm_kcalloc

Because of the possible failure of the allocation, data->domains might
be NULL pointer and will cause the dereference of the NULL pointer
later.
Therefore, it might be better to check it and directly return -ENOMEM
without releasing data manually if fails, because the comment of the
devm_kmalloc() says "Memory allocated with this function is
automatically freed on driver detach.".
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/31b5124d742969ea8bf7a1360596f548ca23e770; https://git.kernel.org/stable/c/5a811126d38f9767a20cc271b34db7c8efc5a46c; https://git.kernel.org/stable/c/724376c30af5a57686b223dbcd6188e07d2a1de2
CVE: CVE-2021-47652
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

video: fbdev: smscufx: Fix null-ptr-deref in ufx_usb_probe()

I got a null-ptr-deref report:

BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
...
RIP: 0010:fb_destroy_modelist+0x38/0x100
...
Call Trace:
 ufx_usb_probe.cold+0x2b5/0xac1 [smscufx]
 usb_probe_interface+0x1aa/0x3c0 [usbcore]
 really_probe+0x167/0x460
...
 ret_from_fork+0x1f/0x30

If fb_alloc_cmap() fails in ufx_usb_probe(), fb_destroy_modelist() will
be called to destroy modelist in the error handling path. But modelist
has not been initialized yet, so it will result in null-ptr-deref.

Initialize modelist before calling fb_alloc_cmap() to fix this bug.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/0fd28daec73525382e5c992db8743bf76e42cd5c; https://git.kernel.org/stable/c/1791f487f877a9e83d81c8677bd3e7b259e7cb27; https://git.kernel.org/stable/c/64ec3e678d76419f207b9cdd338dda438ca10b1c
CVE: CVE-2021-47653
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

media: davinci: vpif: fix use-after-free on driver unbind

The driver allocates and registers two platform device structures during
probe, but the devices were never deregistered on driver unbind.

This results in a use-after-free on driver unbind as the device
structures were allocated using devres and would be freed by driver
core when remove() returns.

Fix this by adding the missing deregistration calls to the remove()
callback and failing probe on registration errors.

Note that the platform device structures must be freed using a proper
release callback to avoid leaking associated resources like device
names.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/43acb728bbc40169d2e2425e84a[PII_REDACTED]4be; https://git.kernel.org/stable/c/6512c3c39cb6b573b791ce45365818a38b76afbe; https://git.kernel.org/stable/c/9ffc602e14d7b9f7e7cb2f67e18dfef9ef8af676