deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-26750
Published: 2024-04-04
Description: In the Linux kernel, the following vulnerability has been resolved:

af_unix: Drop oob_skb ref before purging queue in GC.

syzbot reported another task hung in __unix_gc().  [0]

The current while loop assumes that all of the left candidates
have oob_skb and calling kfree_skb(oob_skb) releases the remaining
candidates.

However, I missed a case that oob_skb has self-referencing fd and
another fd and the latter sk is placed before the former in the
candidate list.  Then, the while loop never proceeds, resulting
the task hung.

__unix_gc() has the same loop just before purging the collected skb,
so we can call kfree_skb(oob_skb) there and let __skb_queue_purge()
release all inflight sockets.

[0]:
Sending NMI from CPU 0 to CPUs 1:
NMI backtrace for cpu 1
CPU: 1 PID: 2784 Comm: kworker/u4:8 Not tainted 6.8.0-rc4-syzkaller-01028-g71b605d32017 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
Workqueue: events_unbound __unix_gc
RIP: 0010:__sanitizer_cov_trace_pc+0x0/0x70 kernel/kcov.c:200
Code: 89 fb e8 23 00 00 00 48 8b 3d 84 f5 1a 0c 48 89 de 5b e9 43 26 57 00 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 <f3> 0f 1e fa 48 8b 04 24 65 48 8b 0d 90 52 70 7e 65 8b 15 91 52 70
RSP: 0018:ffffc9000a17fa78 EFLAGS: 00000287
RAX: ffffffff8a0a6108 RBX: ffff88802b6c2640 RCX: ffff88802c0b3b80
RDX: [PII_REDACTED] RSI: [PII_REDACTED] RDI: [PII_REDACTED]
RBP: ffffc9000a17fbf0 R08: ffffffff89383f1d R09: 1ffff1100ee5ff84
R10: dffffc[PII_REDACTED] R11: ffffed100ee5ff85 R12: 1ffff110056d84ee
R13: ffffc9000a17fae0 R14: [PII_REDACTED] R15: ffffffff8f47b840
FS:  [PII_REDACTED](0000) GS:ffff8880b9500000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: 00007ffef5687ff8 CR3:[PII_REDACTED]b34000 CR4:[PII_REDACTED]3506f0
DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
Call Trace:
 <NMI>
 </NMI>
 <TASK>
 __unix_gc+0xe69/0xf40 net/unix/garbage.c:343
 process_one_work kernel/workqueue.c:2633 [inline]
 process_scheduled_works+0x913/0x1420 kernel/workqueue.c:2706
 worker_thread+0xa5f/0x1000 kernel/workqueue.c:2787
 kthread+0x2ef/0x390 kernel/kthread.c:388
 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242
 </TASK>
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/43ba9e331559a30000c862eea313248707afa787; https://git.kernel.org/stable/c/6c480d0f131862645d172ca9e25dc152b1a5c3a6; https://git.kernel.org/stable/c/aa82ac51d[PII_REDACTED]5c827775d64dbfd9941f3
CVE: CVE-2024-26783
Published: 2024-04-04
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/vmscan: fix a bug calling wakeup_kswapd() with a wrong zone index

With numa balancing on, when a numa system is running where a numa node
doesn't have its local memory so it has no managed zones, the following
oops has been observed.  It's because wakeup_kswapd() is called with a
wrong zone index, -1.  Fixed it by checking the index before calling
wakeup_kswapd().

> BUG: unable to handle page fault for address:[PII_REDACTED]0033f3
> #PF: supervisor read access in kernel mode
> #PF: error_code(0x0000) - not-present page
> PGD 0 P4D 0
> Oops: 0000 [#1] PREEMPT SMP NOPTI
> CPU: 2 PID: 895 Comm: masim Not tainted 6.6.0-dirty #255
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
>    rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
> RIP: 0010:wakeup_kswapd (./linux/mm/vmscan.c:7812)
> Code: (omitted)
> RSP: 0000:ffffc90004257d58 EFLAGS: 00010286
> RAX: ffffffffffffffff RBX: ffff88883fff0480 RCX: [PII_REDACTED]
> RDX: [PII_REDACTED] RSI: [PII_REDACTED] RDI: ffff88883fff0480
> RBP: ffffffffffffffff R08: ff0003ffffffffff R09: ffffffffffffffff
> R10: ffff888106c95540 R11: [PII_REDACTED] R12: [PII_REDACTED]
> R13: [PII_REDACTED] R14: [PII_REDACTED] R15: ffff88883fff0940
> FS:  00007fc4b8124740(0000) GS:ffff888827c00000(0000) knlGS:[PII_REDACTED]
> CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
> CR2:[PII_REDACTED]0033f3 CR3: 000000026cc08004 CR4:[PII_REDACTED]770ee0
> DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
> DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
> PKRU: 55555554
> Call Trace:
>  <TASK>
> ? __die
> ? page_fault_oops
> ? __pte_offset_map_lock
> ? exc_page_fault
> ? asm_exc_page_fault
> ? wakeup_kswapd
> migrate_misplaced_page
> __handle_mm_fault
> handle_mm_fault
> do_user_addr_fault
> exc_page_fault
> asm_exc_page_fault
> RIP: 0033:0x55b897ba0808
> Code: (omitted)
> RSP: 002b:00007ffeefa821a0 EFLAGS: 00010287
> RAX: 000055b89983acd0 RBX: 00007ffeefa823f8 RCX: 000055b89983acd0
> RDX: 00007fc2f8122010 RSI: [PII_REDACTED] RDI: 000055b89983acd0
> RBP: 00007ffeefa821a0 R08: [PII_REDACTED] R09: [PII_REDACTED]
> R10: [PII_REDACTED] R11: [PII_REDACTED] R12: [PII_REDACTED]
> R13: 00007ffeefa82410 R14: 000055b897ba5dd8 R15: 00007fc4b8340000
>  </TASK>
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2774f256e7c0219e2b0a0894af1c76bdabc4f974; https://git.kernel.org/stable/c/bdd21eed8b72f9e28d6c279f6db258e090c79080; https://git.kernel.org/stable/c/d6159bd4c00594249e305bfe02304c67c506264e
CVE: CVE-2024-26784
Published: 2024-04-04
Description: In the Linux kernel, the following vulnerability has been resolved:

pmdomain: arm: Fix NULL dereference on scmi_perf_domain removal

On unloading of the scmi_perf_domain module got the below splat, when in
the DT provided to the system under test the '#power-domain-cells' property
was missing. Indeed, this particular setup causes the probe to bail out
early without giving any error, which leads to the ->remove() callback gets
to run too, but without all the expected initialized structures in place.

Add a check and bail out early on remove too.

 Call trace:
  scmi_perf_domain_remove+0x28/0x70 [scmi_perf_domain]
  scmi_dev_remove+0x28/0x40 [scmi_core]
  device_remove+0x54/0x90
  device_release_driver_internal+0x1dc/0x240
  driver_detach+0x58/0xa8
  bus_remove_driver+0x78/0x108
  driver_unregister+0x38/0x70
  scmi_driver_unregister+0x28/0x180 [scmi_core]
  scmi_perf_domain_driver_exit+0x18/0xb78 [scmi_perf_domain]
  __arm64_sys_delete_module+0x1a8/0x2c0
  invoke_syscall+0x50/0x128
  el0_svc_common.constprop.0+0x48/0xf0
  do_el0_svc+0x24/0x38
  el0_svc+0x34/0xb8
  el0t_64_sync_handler+0x100/0x130
  el0t_64_sync+0x190/0x198
 Code: a90153f3 f9403c14 f9414800 955f8a05 (b9400a80)
 ---[ end trace [PII_REDACTED] ]---
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/eb5555d422d0fc325e1574a7353d3c616f82d8b5; https://git.kernel.org/stable/c/f6aaf131e4d4a9a26040ecc018eb70ab8b3d355d; https://git.kernel.org/stable/c/eb5555d422d0fc325e1574a7353d3c616f82d8b5
CVE: CVE-2024-26785
Published: 2024-04-04
Description: In the Linux kernel, the following vulnerability has been resolved:

iommufd: Fix protection fault in iommufd_test_syz_conv_iova

Syzkaller reported the following bug:

  general protection fault, probably for non-canonical address 0xdffffc[PII_REDACTED]: 0000 [#1] SMP KASAN
  KASAN: null-ptr-deref in range [0x[PII_REDACTED]0001c0-0x[PII_REDACTED]0001c7]
  Call Trace:
   lock_acquire
   lock_acquire+0x1ce/0x4f0
   down_read+0x93/0x4a0
   iommufd_test_syz_conv_iova+0x56/0x1f0
   iommufd_test_access_rw.isra.0+0x2ec/0x390
   iommufd_test+0x1058/0x1e30
   iommufd_fops_ioctl+0x381/0x510
   vfs_ioctl
   __do_sys_ioctl
   __se_sys_ioctl
   __x64_sys_ioctl+0x170/0x1e0
   do_syscall_x64
   do_syscall_64+0x71/0x140

This is because the new iommufd_access_change_ioas() sets access->ioas to
NULL during its process, so the lock might be gone in a concurrent racing
context.

Fix this by doing the same access->ioas sanity as iommufd_access_rw() and
iommufd_access_pin_pages() functions do.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-120
References: https://git.kernel.org/stable/c/cf7c2789822db8b5efa34f5ebcf1621bc0008d48; https://git.kernel.org/stable/c/fc719ecbca45c9c046640d72baddba3d83e0bc0b; https://git.kernel.org/stable/c/fd4d5cd7a2e8f08357c9bfc0905957cffe8ce568
CVE: CVE-2024-26786
Published: 2024-04-04
Description: In the Linux kernel, the following vulnerability has been resolved:

iommufd: Fix iopt_access_list_id overwrite bug

Syzkaller reported the following WARN_ON:
  WARNING: CPU: 1 PID: 4738 at drivers/iommu/iommufd/io_pagetable.c:1360

  Call Trace:
   iommufd_access_change_ioas+0x2fe/0x4e0
   iommufd_access_destroy_object+0x50/0xb0
   iommufd_object_remove+0x2a3/0x490
   iommufd_object_destroy_user
   iommufd_access_destroy+0x71/0xb0
   iommufd_test_staccess_release+0x89/0xd0
   __fput+0x272/0xb50
   __fput_sync+0x4b/0x60
   __do_sys_close
   __se_sys_close
   __x64_sys_close+0x8b/0x110
   do_syscall_x64

The mismatch between the access pointer in the list and the passed-in
pointer is resulting from an overwrite of access->iopt_access_list_id, in
iopt_add_access(). Called from iommufd_access_change_ioas() when
xa_alloc() succeeds but iopt_calculate_iova_alignment() fails.

Add a new_id in iopt_add_access() and only update iopt_access_list_id when
returning successfully.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/9526a46cc0c378d381560279bea9aa34c84298a0; https://git.kernel.org/stable/c/aeb004c0cd6958e910123a[PII_REDACTED]09c9539; https://git.kernel.org/stable/c/f1fb745ee0a6fe43f1d84ec369c7e6af2310fda9
CVE: CVE-2024-26787
Published: 2024-04-04
Description: In the Linux kernel, the following vulnerability has been resolved:

mmc: mmci: stm32: fix DMA API overlapping mappings warning

Turning on CONFIG_DMA_API_DEBUG_SG results in the following warning:

DMA-API: mmci-pl18x 48220000.mmc: cacheline tracking EEXIST,
overlapping mappings aren't supported
WARNING: CPU: 1 PID: 51 at kernel/dma/debug.c:568
add_dma_entry+0x234/0x2f4
Modules linked in:
CPU: 1 PID: 51 Comm: kworker/1:2 Not tainted 6.1.28 #1
Hardware name: STMicroelectronics STM32MP257F-EV1 Evaluation Board (DT)
Workqueue: events_freezable mmc_rescan
Call trace:
add_dma_entry+0x234/0x2f4
debug_dma_map_sg+0x198/0x350
__dma_map_sg_attrs+0xa0/0x110
dma_map_sg_attrs+0x10/0x2c
sdmmc_idma_prep_data+0x80/0xc0
mmci_prep_data+0x38/0x84
mmci_start_data+0x108/0x2dc
mmci_request+0xe4/0x190
__mmc_start_request+0x68/0x140
mmc_start_request+0x94/0xc0
mmc_wait_for_req+0x70/0x100
mmc_send_tuning+0x108/0x1ac
sdmmc_execute_tuning+0x14c/0x210
mmc_execute_tuning+0x48/0xec
mmc_sd_init_uhs_card.part.0+0x208/0x464
mmc_sd_init_card+0x318/0x89c
mmc_attach_sd+0xe4/0x180
mmc_rescan+0x244/0x320

DMA API debug brings to light leaking dma-mappings as dma_map_sg and
dma_unmap_sg are not correctly balanced.

If an error occurs in mmci_cmd_irq function, only mmci_dma_error
function is called and as this API is not managed on stm32 variant,
dma_unmap_sg is never called in this error path.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0224cbc53ba82b84affa7619b6d1b1a254bc2c53; https://git.kernel.org/stable/c/176e66269f0de327375fc0ea51c12c2f5a97e4c4; https://git.kernel.org/stable/c/5ae5060e17a3fc38e54c3e5bd8abd6b1d5bfae7c
CVE: CVE-2024-26788
Published: 2024-04-04
Description: In the Linux kernel, the following vulnerability has been resolved:

dmaengine: fsl-qdma: init irq after reg initialization

Initialize the qDMA irqs after the registers are configured so that
interrupts that may have been pending from a primary kernel don't get
processed by the irq handler before it is ready to and cause panic with
the following trace:

  Call trace:
   fsl_qdma_queue_handler+0xf8/0x3e8
   __handle_irq_event_percpu+0x78/0x2b0
   handle_irq_event_percpu+0x1c/0x68
   handle_irq_event+0x44/0x78
   handle_fasteoi_irq+0xc8/0x178
   generic_handle_irq+0x24/0x38
   __handle_domain_irq+0x90/0x100
   gic_handle_irq+0x5c/0xb8
   el1_irq+0xb8/0x180
   _raw_spin_unlock_irqrestore+0x14/0x40
   __setup_irq+0x4bc/0x798
   request_threaded_irq+0xd8/0x190
   devm_request_threaded_irq+0x74/0xe8
   fsl_qdma_probe+0x4d4/0xca8
   platform_drv_probe+0x50/0xa0
   really_probe+0xe0/0x3f8
   driver_probe_device+0x64/0x130
   device_driver_attach+0x6c/0x78
   __driver_attach+0xbc/0x158
   bus_for_each_dev+0x5c/0x98
   driver_attach+0x20/0x28
   bus_add_driver+0x158/0x220
   driver_register+0x60/0x110
   __platform_driver_register+0x44/0x50
   fsl_qdma_driver_init+0x18/0x20
   do_one_initcall+0x48/0x258
   kernel_init_freeable+0x1a4/0x23c
   kernel_init+0x10/0xf8
   ret_from_fork+0x10/0x18
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/3cc5fb824c2125aa3740d905b3e5b378c8a09478; https://git.kernel.org/stable/c/4529c084a320be78ff2c5e64297ae998c6fdf66b; https://git.kernel.org/stable/c/474d521da890b3e3585335fb80a6044cb2553d99
CVE: CVE-2024-26789
Published: 2024-04-04
Description: In the Linux kernel, the following vulnerability has been resolved:

crypto: arm64/neonbs - fix out-of-bounds access on short input

The bit-sliced implementation of AES-CTR operates on blocks of 128
bytes, and will fall back to the plain NEON version for tail blocks or
inputs that are shorter than 128 bytes to begin with.

It will call straight into the plain NEON asm helper, which performs all
memory accesses in granules of 16 bytes (the size of a NEON register).
For this reason, the associated plain NEON glue code will copy inputs
shorter than 16 bytes into a temporary buffer, given that this is a rare
occurrence and it is not worth the effort to work around this in the asm
code.

The fallback from the bit-sliced NEON version fails to take this into
account, potentially resulting in out-of-bounds accesses. So clone the
same workaround, and use a temp buffer for short in/outputs.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/034e2d70b5c7f578200ad09955aeb2aa65d1164a; https://git.kernel.org/stable/c/1291d278b5574819a7266568ce4c28bce9438705; https://git.kernel.org/stable/c/1c0cf6d[PII_REDACTED]889d72622b90fc01562ce4
CVE: CVE-2024-26790
Published: 2024-04-04
Description: In the Linux kernel, the following vulnerability has been resolved:

dmaengine: fsl-qdma: fix SoC may hang on 16 byte unaligned read

There is chip (ls1028a) errata:

The SoC may hang on 16 byte unaligned read transactions by QDMA.

Unaligned read transactions initiated by QDMA may stall in the NOC
(Network On-Chip), causing a deadlock condition. Stalled transactions will
trigger completion timeouts in PCIe controller.

Workaround:
Enable prefetch by setting the source descriptor prefetchable bit
( SD[PF] = 1 ).

Implement this workaround.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/106c1ac953a66556ec77456c46e818208d3a9bce; https://git.kernel.org/stable/c/237ecf1afe6c22534fa43abdf2bf0b0f52de0aaa; https://git.kernel.org/stable/c/518d78b4fac68cac29a263554d7f3b19da99d0da
CVE: CVE-2024-26791
Published: 2024-04-04
Description: In the Linux kernel, the following vulnerability has been resolved:

btrfs: dev-replace: properly validate device names

There's a syzbot report that device name buffers passed to device
replace are not properly checked for string termination which could lead
to a read out of bounds in getname_kernel().

Add a helper that validates both source and target device name buffers.
For devid as the source initialize the buffer to empty string in case
something tries to read it later.

This was originally analyzed and fixed in a different way by Edward Adam
Davis (see links).
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/11d7a2e429c02d51e2dc90713823ea8b8d3d3a84; https://git.kernel.org/stable/c/2886fe308a83968dde252302884a1e63351cf16d; https://git.kernel.org/stable/c/343eecb4ff49a7b1cc1dfe86958a805cf2341cfb
CVE: CVE-2024-26794
Published: 2024-04-04
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-26795
Published: 2024-04-04
Description: In the Linux kernel, the following vulnerability has been resolved:

riscv: Sparse-Memory/vmemmap out-of-bounds fix

Offset vmemmap so that the first page of vmemmap will be mapped
to the first page of physical memory in order to ensure that
vmemmap’s bounds will be respected during
pfn_to_page()/page_to_pfn() operations.
The conversion macros will produce correct SV39/48/57 addresses
for every possible/valid DRAM_BASE inside the physical memory limits.

v2:Address Alex's comments
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2a1728c15ec4f45ed9248ae22f626541c179bfbe; https://git.kernel.org/stable/c/5941a90c55d3bfba732b32208d58d997600b44ef; https://git.kernel.org/stable/c/[PII_REDACTED]b40fd9f2a8b808c657269678c149af
CVE: CVE-2024-26796
Published: 2024-04-04
Description: In the Linux kernel, the following vulnerability has been resolved:

drivers: perf: ctr_get_width function for legacy is not defined

With parameters CONFIG_RISCV_PMU_LEGACY=y and CONFIG_RISCV_PMU_SBI=n
linux kernel crashes when you try perf record:

$ perf record ls
[ 46.749286] Unable to handle kernel NULL pointer dereference at virtual address [PII_REDACTED]
[ 46.750199] Oops [#1]
[ 46.750342] Modules linked in:
[ 46.750608] CPU: 0 PID: 107 Comm: perf-exec Not tainted 6.6.0 #2
[ 46.750906] Hardware name: riscv-virtio,qemu (DT)
[ 46.751184] epc : 0x0
[ 46.751430] ra : arch_perf_update_userpage+0x54/0x13e
[ 46.751680] epc : [PII_REDACTED] ra : ffffffff8072ee52 sp : ff[PII_REDACTED]b8f0
[ 46.751958] gp : ffffffff81505988 tp : ff[PII_REDACTED]d400 t0 : ff[PII_REDACTED]b9c0
[ 46.752229] t1 : [PII_REDACTED] t2 : [PII_REDACTED] s0 : ff[PII_REDACTED]b930
[ 46.752451] s1 : ff600000028fb000 a0 : [PII_REDACTED] a1 : ff600000028fb000
[ 46.752673] a2 : 0000000ae2751268 a3 :[PII_REDACTED]4fb708 a4 : [PII_REDACTED]
[ 46.752895] a5 : [PII_REDACTED] a6 :[PII_REDACTED]17ffe3 a7 :[PII_REDACTED]0000d2
[ 46.753117] s2 : ff600000028fb000 s3 : 0000000ae2751268 s4 : [PII_REDACTED]
[ 46.753338] s5 : ffffffff8153e290 s6 : ff600000863b9000 s7 : ff[PII_REDACTED]1078
[ 46.753562] s8 : ff[PII_REDACTED]1048 s9 : ff[PII_REDACTED]1058 s10: [PII_REDACTED]
[ 46.753783] s11: [PII_REDACTED] t3 : ffffffffffffffff t4 : ffffffffffffffff
[ 46.754005] t5 : ff[PII_REDACTED]270c t6 : ff[PII_REDACTED]bb30
[ 46.754179] status: [PII_REDACTED] badaddr: [PII_REDACTED] cause:[PII_REDACTED]00000c
[ 46.754653] Code: Unable to access instruction at 0xffffffffffffffec.
[ 46.754939] ---[ end trace [PII_REDACTED] ]---
[ 46.755131] note: perf-exec[107] exited with irqs disabled
[ 46.755546] note: perf-exec[107] exited with preempt_count 4

This happens because in the legacy case the ctr_get_width function was not
defined, but it is used in arch_perf_update_userpage.

Also remove extra check in riscv_pmu_ctr_get_width_mask
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/682dc133f83e0194796e6ea72eb642df1c03dfbe; https://git.kernel.org/stable/c/e0d17ee872cf8d0f51cc561329b8e1a0aa792bbb; https://git.kernel.org/stable/c/e4f50e85de5a6b21dfdc0d7ca435eba4f62935c3
CVE: CVE-2024-26797
Published: 2024-04-04
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Prevent potential buffer overflow in map_hw_resources

Adds a check in the map_hw_resources function to prevent a potential
buffer overflow. The function was accessing arrays using an index that
could potentially be greater than the size of the arrays, leading to a
buffer overflow.

Adds a check to ensure that the index is within the bounds of the
arrays. If the index is out of bounds, an error message is printed and
break it will continue execution with just ignoring extra data early to
prevent the buffer overflow.

Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/dml2_wrapper.c:79 map_hw_resources() error: buffer overflow 'dml2->v20.scratch.dml_to_dc_pipe_mapping.disp_cfg_to_stream_id' 6 <= 7
drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/dml2_wrapper.c:81 map_hw_resources() error: buffer overflow 'dml2->v20.scratch.dml_to_dc_pipe_mapping.disp_cfg_to_plane_id' 6 <= 7
CVSS Score: 7.8 (HIGH)
CWE: CWE-120
References: https://git.kernel.org/stable/c/0f8ca019544a252d1afb468ce840c6dcbac73af4; https://git.kernel.org/stable/c/50a6302cf881f67f1410461a68fe9eabd00ff31d; https://git.kernel.org/stable/c/0f8ca019544a252d1afb468ce840c6dcbac73af4
CVE: CVE-2024-26798
Published: 2024-04-04
Description: In the Linux kernel, the following vulnerability has been resolved:

fbcon: always restore the old font data in fbcon_do_set_font()

Commit a5a923038d70 (fbdev: fbcon: Properly revert changes when
vc_resize() failed) started restoring old font data upon failure (of
vc_resize()). But it performs so only for user fonts. It means that the
"system"/internal fonts are not restored at all. So in result, the very
first call to fbcon_do_set_font() performs no restore at all upon
failing vc_resize().

This can be reproduced by Syzkaller to crash the system on the next
invocation of font_get(). It's rather hard to hit the allocation failure
in vc_resize() on the first font_set(), but not impossible. Esp. if
fault injection is used to aid the execution/failure. It was
demonstrated by Sirius:
  BUG: unable to handle page fault for address: fffffffffffffff8
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD cb7b067 P4D cb7b067 PUD cb7d067 PMD 0
  Oops: 0000 [#1] PREEMPT SMP KASAN
  CPU: 1 PID: 8007 Comm: poc Not tainted 6.7.0-g9d1694dc91ce #20
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  RIP: 0010:fbcon_get_font+0x229/0x800 drivers/video/fbdev/core/fbcon.c:2286
  Call Trace:
   <TASK>
   con_font_get drivers/tty/vt/vt.c:4558 [inline]
   con_font_op+0x1fc/0xf20 drivers/tty/vt/vt.c:4673
   vt_k_ioctl drivers/tty/vt/vt_ioctl.c:474 [inline]
   vt_ioctl+0x632/0x2ec0 drivers/tty/vt/vt_ioctl.c:752
   tty_ioctl+0x6f8/0x1570 drivers/tty/tty_io.c:2803
   vfs_ioctl fs/ioctl.c:51 [inline]
  ...

So restore the font data in any case, not only for user fonts. Note the
later 'if' is now protected by 'old_userfont' and not 'old_data' as the
latter is always set now. (And it is supposed to be non-NULL. Otherwise
we would see the bug above again.)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-770
References: https://git.kernel.org/stable/c/00d6a284fcf3fad1b7e1b5bc3cd87cbfb60ce03f; https://git.kernel.org/stable/c/20a4b5214f7bee13c897477168c77bbf79683c3d; https://git.kernel.org/stable/c/2f91a96b892fab2f2543b4a55740c5bee36b1a6b
CVE: CVE-2024-26799
Published: 2024-04-04
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: qcom: Fix uninitialized pointer dmactl

In the case where __lpass_get_dmactl_handle is called and the driver
id dai_id is invalid the pointer dmactl is not being assigned a value,
and dmactl contains a garbage value since it has not been initialized
and so the null check may not work. Fix this to initialize dmactl to
NULL. One could argue that modern compilers will set this to zero, but
it is useful to keep this initialized as per the same way in functions
__lpass_platform_codec_intf_init and lpass_cdc_dma_daiops_hw_params.

Cleans up clang scan build warning:
sound/soc/qcom/lpass-cdc-dma.c:275:7: warning: Branch condition
evaluates to a garbage value [core.uninitialized.Branch]
CVSS Score: 6.2 (MEDIUM)
CWE: CWE-824
References: https://git.kernel.org/stable/c/1382d8b55129875b2e07c4d2a7ebc790183769ee; https://git.kernel.org/stable/c/99adc8b4d2f38bf0d06483ec845bc48f60c3f8cf; https://git.kernel.org/stable/c/d5a7726e6ea62d447b79ab5baeb537ea6bdb225b