CVE-2024-26950 – wireguard: netlink: access device through ctx instead of peer
https://notcve.org/view.php?id=CVE-2024-26950
In the Linux kernel, the following vulnerability has been resolved: wireguard: netlink: access device through ctx instead of peer The previous commit fixed a bug that led to a NULL peer->device being dereferenced. It's actually easier and faster performance-wise to instead get the device from ctx->wg. This semantically makes more sense too, since ctx->wg->peer_allowedips.seq is compared with ctx->allowedips_seq, basing them both in ctx. This also acts as a defence in depth provision against freed peers. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wireguard: netlink: acceda al dispositivo a través de ctx en lugar de peer. el commit anterior solucionó un error que provocaba que se desreferenciara un dispositivo NULL peer->. • https://git.kernel.org/stable/c/e7096c131e5161fa3b8e52a650d7719d2857adfd https://git.kernel.org/stable/c/493aa6bdcffd90a4f82aa614fe4f4db0641b4068 https://git.kernel.org/stable/c/4be453271a882c8ebc28df3dbf9e4d95e6ac42f5 https://git.kernel.org/stable/c/09c3fa70f65175861ca948cb2f0f791e666c90e5 https://git.kernel.org/stable/c/c991567e6c638079304cc15dff28748e4a3c4a37 https://git.kernel.org/stable/c/93bcc1752c69bb309f4d8cfaf960ef1faeb34996 https://git.kernel.org/stable/c/d44bd323d8bb8031eef4bdc44547925998a11e47 https://git.kernel.org/stable/c/71cbd32e3db82ea4a74e3ef9aeeaa6971 •
CVE-2024-26948 – drm/amd/display: Add a dc_state NULL check in dc_state_release
https://notcve.org/view.php?id=CVE-2024-26948
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add a dc_state NULL check in dc_state_release [How] Check wheather state is NULL before releasing it. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: agregue una verificación dc_state NULL en dc_state_release [Cómo] Verifique si el estado es NULL antes de liberarlo. • https://git.kernel.org/stable/c/d37a08f840485995e3fb91dad95e441b9d28a269 https://git.kernel.org/stable/c/334b56cea5d9df5989be6cf1a5898114fa70ad98 •
CVE-2024-26947 – ARM: 9359/1: flush: check if the folio is reserved for no-mapping addresses
https://notcve.org/view.php?id=CVE-2024-26947
In the Linux kernel, the following vulnerability has been resolved: ARM: 9359/1: flush: check if the folio is reserved for no-mapping addresses Since commit a4d5613c4dc6 ("arm: extend pfn_valid to take into account freed memory map alignment") changes the semantics of pfn_valid() to check presence of the memory map for a PFN. A valid page for an address which is reserved but not mapped by the kernel[1], the system crashed during some uio test with the following memory layout: node 0: [mem 0x00000000c0a00000-0x00000000cc8fffff] node 0: [mem 0x00000000d0000000-0x00000000da1fffff] the uio layout is:0xc0900000, 0x100000 the crash backtrace like: Unable to handle kernel paging request at virtual address bff00000 [...] CPU: 1 PID: 465 Comm: startapp.bin Tainted: G O 5.10.0 #1 Hardware name: Generic DT based system PC is at b15_flush_kern_dcache_area+0x24/0x3c LR is at __sync_icache_dcache+0x6c/0x98 [...] (b15_flush_kern_dcache_area) from (__sync_icache_dcache+0x6c/0x98) (__sync_icache_dcache) from (set_pte_at+0x28/0x54) (set_pte_at) from (remap_pfn_range+0x1a0/0x274) (remap_pfn_range) from (uio_mmap+0x184/0x1b8 [uio]) (uio_mmap [uio]) from (__mmap_region+0x264/0x5f4) (__mmap_region) from (__do_mmap_mm+0x3ec/0x440) (__do_mmap_mm) from (do_mmap+0x50/0x58) (do_mmap) from (vm_mmap_pgoff+0xfc/0x188) (vm_mmap_pgoff) from (ksys_mmap_pgoff+0xac/0xc4) (ksys_mmap_pgoff) from (ret_fast_syscall+0x0/0x5c) Code: e0801001 e2423001 e1c00003 f57ff04f (ee070f3e) ---[ end trace 09cf0734c3805d52 ]--- Kernel panic - not syncing: Fatal exception So check if PG_reserved was set to solve this issue. [1]: https://lore.kernel.org/lkml/Zbtdue57RO0QScJM@linux.ibm.com/ En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ARM: 9359/1: descarga: verifique si la publicación está reservada para direcciones sin asignación. Desde el commit a4d5613c4dc6 ("arm: extienda pfn_valid para tener en cuenta la alineación del mapa de memoria liberada") cambia la semántica de pfn_valid() para verificar la presencia del mapa de memoria para un PFN. A valid page for an address which is reserved but not mapped by the kernel[1], the system crashed during some uio test with the following memory layout: node 0: [mem 0x00000000c0a00000-0x00000000cc8fffff] node 0: [mem 0x00000000d0000000-0x00000000da1fffff] el diseño de uio es? 0xc0900000, 0x100000 el seguimiento del fallo es como: No se puede manejar la solicitud de paginación del kernel en la dirección virtual bff00000 [...] • https://git.kernel.org/stable/c/a4d5613c4dc6d413e0733e37db9d116a2a36b9f3 https://git.kernel.org/stable/c/6026d4032dbbe3d7f4ac2c8daa923fe74dcf41c4 https://git.kernel.org/stable/c/65c578935bcc26ddc04e6757b2c7be95bf235b31 https://git.kernel.org/stable/c/0c027c2bad7f5111c51a358b5d392e1a695dabff https://git.kernel.org/stable/c/9f7ddc222cae8254e93d5c169a8ae11a49d912a7 https://git.kernel.org/stable/c/fb3a122a978626b33de3367ee1762da934c0f512 https://git.kernel.org/stable/c/0c66c6f4e21cb22220cbd8821c5c73fc157d20dc https://access.redhat.com/security/cve/CVE-2024-26947 • CWE-439: Behavioral Change in New Version or Environment •
CVE-2024-26944 – btrfs: zoned: fix use-after-free in do_zone_finish()
https://notcve.org/view.php?id=CVE-2024-26944
In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: fix use-after-free in do_zone_finish() Shinichiro reported the following use-after-free triggered by the device replace operation in fstests btrfs/070. BTRFS info (device nullb1): scrub: finished on devid 1 with status: 0 ================================================================== BUG: KASAN: slab-use-after-free in do_zone_finish+0x91a/0xb90 [btrfs] Read of size 8 at addr ffff8881543c8060 by task btrfs-cleaner/3494007 CPU: 0 PID: 3494007 Comm: btrfs-cleaner Tainted: G W 6.8.0-rc5-kts #1 Hardware name: Supermicro Super Server/X11SPi-TF, BIOS 3.3 02/21/2020 Call Trace: <TASK> dump_stack_lvl+0x5b/0x90 print_report+0xcf/0x670 ? __virt_addr_valid+0x200/0x3e0 kasan_report+0xd8/0x110 ? do_zone_finish+0x91a/0xb90 [btrfs] ? do_zone_finish+0x91a/0xb90 [btrfs] do_zone_finish+0x91a/0xb90 [btrfs] btrfs_delete_unused_bgs+0x5e1/0x1750 [btrfs] ? __pfx_btrfs_delete_unused_bgs+0x10/0x10 [btrfs] ? • https://git.kernel.org/stable/c/34ca809e055eca5cfe63d9c7efbf80b7c21b4e57 https://git.kernel.org/stable/c/1ec17ef59168a1a6f1105f5dc517f783839a5302 •
CVE-2024-26938 – drm/i915/bios: Tolerate devdata==NULL in intel_bios_encoder_supports_dp_dual_mode()
https://notcve.org/view.php?id=CVE-2024-26938
In the Linux kernel, the following vulnerability has been resolved: drm/i915/bios: Tolerate devdata==NULL in intel_bios_encoder_supports_dp_dual_mode() If we have no VBT, or the VBT didn't declare the encoder in question, we won't have the 'devdata' for the encoder. Instead of oopsing just bail early. We won't be able to tell whether the port is DP++ or not, but so be it. (cherry picked from commit 26410896206342c8a80d2b027923e9ee7d33b733) En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: drm/i915/bios: Tolerate devdata==NULL in intel_bios_encoder_supports_dp_dual_mode() Si no tenemos VBT, o el VBT no declaró el codificador en cuestión, no tendremos los 'devdata' para el codificador. En lugar de huir, simplemente sal de la cárcel antes de tiempo. No podremos saber si el puerto es DP++ o no, pero que así sea. (cereza escogida del compromiso 26410896206342c8a80d2b027923e9ee7d33b733) • https://git.kernel.org/stable/c/72e4d3fb72e9f0f016946158a7d95304832768e6 https://git.kernel.org/stable/c/a891add409e3bc381f4f68c2ce9d953f1865cb1f https://git.kernel.org/stable/c/f4bbac954d8f9ab214ea1d4f385de4fa6bd92dd0 https://git.kernel.org/stable/c/94cf2fb6feccd625e5b4e23e1b70f39a206f82ac https://git.kernel.org/stable/c/32e39bab59934bfd3f37097d4dd85ac5eb0fd549 https://access.redhat.com/security/cve/CVE-2024-26938 https://bugzilla.redhat.com/show_bug.cgi?id=2278229 •