CVSS: 6.2EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26799 – ASoC: qcom: Fix uninitialized pointer dmactl
https://notcve.org/view.php?id=CVE-2024-26799
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] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: qcom: corrige el puntero no inicializado dmactl. En el caso de que se llame a __lpass_get_dmactl_handle y el ID del controlador dai_id no sea válido, al puntero dmactl no se le asigna un valor y dmactl contiene un valor basura. ya que no se ha inicializado y, por lo tanto, es posible que la verificación nula no funcione. Solucione esto para inicializar dmactl a NULL. • https://git.kernel.org/stable/c/b81af585ea54ee9f749391e594ee9cbd44061eae https://git.kernel.org/stable/c/99adc8b4d2f38bf0d06483ec845bc48f60c3f8cf https://git.kernel.org/stable/c/d5a7726e6ea62d447b79ab5baeb537ea6bdb225b https://git.kernel.org/stable/c/1382d8b55129875b2e07c4d2a7ebc790183769ee •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26798 – fbcon: always restore the old font data in fbcon_do_set_font()
https://notcve.org/view.php?id=CVE-2024-26798
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. • https://git.kernel.org/stable/c/ebd6f886aa2447fcfcdce5450c9e1028e1d681bb https://git.kernel.org/stable/c/a5a923038d70d2d4a86cb4e3f32625a5ee6e7e24 https://git.kernel.org/stable/c/f08ccb792d3eaf1dc62d8cbf6a30d6522329f660 https://git.kernel.org/stable/c/20a4b5214f7bee13c897477168c77bbf79683c3d https://git.kernel.org/stable/c/2f91a96b892fab2f2543b4a55740c5bee36b1a6b https://git.kernel.org/stable/c/73a6bd68a1342f3a44cac9dffad81ad6a003e520 https://git.kernel.org/stable/c/a2c881413dcc5d801bdc9535e51270cc88cb9cd8 https://git.kernel.org/stable/c/00d6a284fcf3fad1b7e1b5bc3cd87cbfb •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26796 – drivers: perf: ctr_get_width function for legacy is not defined
https://notcve.org/view.php?id=CVE-2024-26796
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 0000000000000000 [ 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 : 0000000000000000 ra : ffffffff8072ee52 sp : ff2000000022b8f0 [ 46.751958] gp : ffffffff81505988 tp : ff6000000290d400 t0 : ff2000000022b9c0 [ 46.752229] t1 : 0000000000000001 t2 : 0000000000000003 s0 : ff2000000022b930 [ 46.752451] s1 : ff600000028fb000 a0 : 0000000000000000 a1 : ff600000028fb000 [ 46.752673] a2 : 0000000ae2751268 a3 : 00000000004fb708 a4 : 0000000000000004 [ 46.752895] a5 : 0000000000000000 a6 : 000000000017ffe3 a7 : 00000000000000d2 [ 46.753117] s2 : ff600000028fb000 s3 : 0000000ae2751268 s4 : 0000000000000000 [ 46.753338] s5 : ffffffff8153e290 s6 : ff600000863b9000 s7 : ff60000002961078 [ 46.753562] s8 : ff60000002961048 s9 : ff60000002961058 s10: 0000000000000001 [ 46.753783] s11: 0000000000000018 t3 : ffffffffffffffff t4 : ffffffffffffffff [ 46.754005] t5 : ff6000000292270c t6 : ff2000000022bb30 [ 46.754179] status: 0000000200000100 badaddr: 0000000000000000 cause: 000000000000000c [ 46.754653] Code: Unable to access instruction at 0xffffffffffffffec. [ 46.754939] ---[ end trace 0000000000000000 ]--- [ 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 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: controladores: perf: ctr_get_width la función para legado no está definida Con los parámetros CONFIG_RISCV_PMU_LEGACY=y y CONFIG_RISCV_PMU_SBI=n el kernel de Linux falla cuando intenta el registro de rendimiento: $ perf record ls [ 46.749286] No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000000 [ 46.750199] Ups [#1] [ 46.750342] Módulos vinculados en: [ 46.750608] CPU: 0 PID: 107 Comm: perf-exec Not tainted 6.6.0 #2 [ 46.750906] Nombre del hardware : riscv-virtio,qemu (DT) [ 46.751184] epc : 0x0 [ 46.751430 ] ra : arch_perf_update_userpage+0x54/0x13e [ 46.751680] epc : 00000000000000000 ra : ffffffff8072ee52 sp : ff20000 00022b8f0 [46.751958] gp: ffffffff81505988 tp: ff6000000290d400 t0: ff2000000022b9c0 [ 46.752229] t1 : 0000000000000001 t2 : 0000000000000003 s0 : ff2000000022b930 [ 46.752451] s1 : ff600000028fb000 a0 : 0000000000000000 a 1: ff600000028fb000 [46.752673] a2: 0000000ae2751268 a3: 00000000004fb708 a4: 00000000000000004 [46.752895] a5: 0000000000000000 a6: 000000000017ffe3 a7: 00000000000000d2 [46.753117] s2: ff600000028fb000 s3: 0000000ae2751268 s4: 0000000000000000 [46.753338] s5: ffffffff8153e290 s6: ff600000863b9000 s7: ff60000002 961078 [46.753562] s8: ff60000002961048 s9: ff60000002961058 s10: 00000000000000001 [46.753783] s11: 0000000000000018 t3: ffffffffffffff ff t4 : ffffffffffffffff [ 46.754005] t5 : ff6000000292270c t6: ff2000000022bb30 [46.754179] estado: 0000000200000100 badaddr: 00000000000000000 causa: 0000000000000000c [46.754653] Código: No se puede acceder instrucción en 0xffffffffffffffec. [ 46.754939] ---[ end trace 0000000000000000 ]--- [ 46.755131] nota: perf-exec[107] salió con irqs deshabilitados [ 46.755546] nota: perf-exec[107] salió con preempt_count 4 Esto sucede porque en el legado En este caso, la función ctr_get_width no se definió, pero se usa en arch_perf_update_userpage. También elimine el control adicional en riscv_pmu_ctr_get_width_mask • https://git.kernel.org/stable/c/cc4c07c89aada16229084eeb93895c95b7eabaa3 https://git.kernel.org/stable/c/e0d17ee872cf8d0f51cc561329b8e1a0aa792bbb https://git.kernel.org/stable/c/e4f50e85de5a6b21dfdc0d7ca435eba4f62935c3 https://git.kernel.org/stable/c/682dc133f83e0194796e6ea72eb642df1c03dfbe •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26795 – riscv: Sparse-Memory/vmemmap out-of-bounds fix
https://notcve.org/view.php?id=CVE-2024-26795
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 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: riscv: Sparse-Memory/vmemmap fuera de los límites corrige Offset vmemmap para que la primera página de vmemmap se asigne a la primera página de la memoria física para garantizar que vmemmap Los límites se respetarán durante las operaciones pfn_to_page()/page_to_pfn(). Las macros de conversión producirán direcciones SV39/48/57 correctas para cada DRAM_BASE posible/válida dentro de los límites de la memoria física. v2: Abordar los comentarios de Alex • https://git.kernel.org/stable/c/d95f1a542c3df396137afa217ef9bd39cb8931ca https://git.kernel.org/stable/c/8af1c121b0102041809bc137ec600d1865eaeedd https://git.kernel.org/stable/c/5941a90c55d3bfba732b32208d58d997600b44ef https://git.kernel.org/stable/c/8310080799b40fd9f2a8b808c657269678c149af https://git.kernel.org/stable/c/a278d5c60f21aa15d540abb2f2da6e6d795c3e6e https://git.kernel.org/stable/c/2a1728c15ec4f45ed9248ae22f626541c179bfbe https://git.kernel.org/stable/c/a11dd49dcb9376776193e15641f84fcc1e5980c9 https://lists.debian.org/debian-lts-announce/2024/06/ •
CVSS: 5.3EPSS: 0%CPEs: 2EXPL: 0CVE-2024-26794 – btrfs: fix race between ordered extent completion and fiemap
https://notcve.org/view.php?id=CVE-2024-26794
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race between ordered extent completion and fiemap For fiemap we recently stopped locking the target extent range for the whole duration of the fiemap call, in order to avoid a deadlock in a scenario where the fiemap buffer happens to be a memory mapped range of the same file. This use case is very unlikely to be useful in practice but it may be triggered by fuzz testing (syzbot, etc). However by not locking the target extent range for the whole duration of the fiemap call we can race with an ordered extent. This happens like this: 1) The fiemap task finishes processing a file extent item that covers the file range [512K, 1M[, and that file extent item is the last item in the leaf currently being processed; 2) And ordered extent for the file range [768K, 2M[, in COW mode, completes (btrfs_finish_one_ordered()) and the file extent item covering the range [512K, 1M[ is trimmed to cover the range [512K, 768K[ and then a new file extent item for the range [768K, 2M[ is inserted in the inode's subvolume tree; 3) The fiemap task calls fiemap_next_leaf_item(), which then calls btrfs_next_leaf() to find the next leaf / item. This finds that the the next key following the one we previously processed (its type is BTRFS_EXTENT_DATA_KEY and its offset is 512K), is the key corresponding to the new file extent item inserted by the ordered extent, which has a type of BTRFS_EXTENT_DATA_KEY and an offset of 768K; 4) Later the fiemap code ends up at emit_fiemap_extent() and triggers the warning: if (cache->offset + cache->len > offset) { WARN_ON(1); return -EINVAL; } Since we get 1M > 768K, because the previously emitted entry for the old extent covering the file range [512K, 1M[ ends at an offset that is greater than the new extent's start offset (768K). This makes fiemap fail with -EINVAL besides triggering the warning that produces a stack trace like the following: [1621.677651] ------------[ cut here ]------------ [1621.677656] WARNING: CPU: 1 PID: 204366 at fs/btrfs/extent_io.c:2492 emit_fiemap_extent+0x84/0x90 [btrfs] [1621.677899] Modules linked in: btrfs blake2b_generic (...) [1621.677951] CPU: 1 PID: 204366 Comm: pool Not tainted 6.8.0-rc5-btrfs-next-151+ #1 [1621.677954] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [1621.677956] RIP: 0010:emit_fiemap_extent+0x84/0x90 [btrfs] [1621.678033] Code: 2b 4c 89 63 (...) [1621.678035] RSP: 0018:ffffab16089ffd20 EFLAGS: 00010206 [1621.678037] RAX: 00000000004fa000 RBX: ffffab16089ffe08 RCX: 0000000000009000 [1621.678039] RDX: 00000000004f9000 RSI: 00000000004f1000 RDI: ffffab16089ffe90 [1621.678040] RBP: 00000000004f9000 R08: 0000000000001000 R09: 0000000000000000 [1621.678041] R10: 0000000000000000 R11: 0000000000001000 R12: 0000000041d78000 [1621.678043] R13: 0000000000001000 R14: 0000000000000000 R15: ffff9434f0b17850 [1621.678044] FS: 00007fa6e20006c0(0000) GS:ffff943bdfa40000(0000) knlGS:0000000000000000 [1621.678046] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [1621.678048] CR2: 00007fa6b0801000 CR3: 000000012d404002 CR4: 0000000000370ef0 [1621.678053] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [1621.678055] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [1621.678056] Call Trace: [1621.678074] <TASK> [1621.678076] ? • https://git.kernel.org/stable/c/ded566b4637f1b6b4c9ba74e7d0b8493e93f19cf https://git.kernel.org/stable/c/89bca7fe6382d61e88c67a0b0e7bce315986fb8b https://git.kernel.org/stable/c/d43f8e58f10a44df8c08e7f7076f3288352cd168 https://git.kernel.org/stable/c/31d07a757c6d3430e03cc22799921569999b9a12 https://git.kernel.org/stable/c/a1a4a9ca77f143c00fce69c1239887ff8b813bec •