CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52754 – media: imon: fix access to invalid resource for the second interface
https://notcve.org/view.php?id=CVE-2023-52754
In the Linux kernel, the following vulnerability has been resolved: media: imon: fix access to invalid resource for the second interface imon driver probes two USB interfaces, and at the probe of the second interface, the driver assumes blindly that the first interface got bound with the same imon driver. It's usually true, but it's still possible that the first interface is bound with another driver via a malformed descriptor. Then it may lead to a memory corruption, as spotted by syzkaller; imon driver accesses the data from drvdata as struct imon_context object although it's a completely different one that was assigned by another driver. This patch adds a sanity check -- whether the first interface is really bound with the imon driver or not -- for avoiding the problem above at the probe time. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medios: imon: corrige el acceso a un recurso no válido para la segunda interfaz. El controlador imon prueba dos interfaces USB y, en la prueba de la segunda interfaz, el controlador asume ciegamente que la primera interfaz obtuvo atado con el mismo conductor imon. • https://git.kernel.org/stable/c/0f5068519f89d928d6c51100e4b274479123829f https://git.kernel.org/stable/c/5e0b788fb96be36d1baf1a5c88d09c7c82a0452a https://git.kernel.org/stable/c/b083aaf5db2eeca9e362723258e5d8698f7dd84e https://git.kernel.org/stable/c/10ec5a97f8f5a772a1a42b4eb27196b447cd3aa9 https://git.kernel.org/stable/c/2a493a34bd6e496c55fabedd82b957193ace178f https://git.kernel.org/stable/c/a1766a4fd83befa0b34d932d532e7ebb7fab1fa7 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52753 – drm/amd/display: Avoid NULL dereference of timing generator
https://notcve.org/view.php?id=CVE-2023-52753
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid NULL dereference of timing generator [Why & How] Check whether assigned timing generator is NULL or not before accessing its funcs to prevent NULL dereference. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: Evite la desreferencia NULL del generador de temporización [Por qué y cómo] Verifique si el generador de temporización asignado es NULL o no antes de acceder a sus funciones para evitar la desreferencia NULL. • https://git.kernel.org/stable/c/09909f515032fa80b921fd3118efe66b185d10fd https://git.kernel.org/stable/c/eac3e4760aa12159f7f5475d55a67b7933abc195 https://git.kernel.org/stable/c/79b6a90f4f2433312154cd68452b0ba501fa74db https://git.kernel.org/stable/c/4e497f1acd99075b13605b2e7fa0cba721a2cfd9 https://git.kernel.org/stable/c/8a06894666e0b462c9316b26ab615cefdd0d676c https://git.kernel.org/stable/c/6d8653b1a7a8dc938b566ae8c4f373b36e792c68 https://git.kernel.org/stable/c/df8bc953eed72371e43ca407bd063507f760cf89 https://git.kernel.org/stable/c/b1904ed480cee3f9f4036ea0e36d139cb • CWE-476: NULL Pointer Dereference •
CVSS: 8.4EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52752 – smb: client: fix use-after-free bug in cifs_debug_data_proc_show()
https://notcve.org/view.php?id=CVE-2023-52752
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix use-after-free bug in cifs_debug_data_proc_show() Skip SMB sessions that are being teared down (e.g. @ses->ses_status == SES_EXITING) in cifs_debug_data_proc_show() to avoid use-after-free in @ses. This fixes the following GPF when reading from /proc/fs/cifs/DebugData while mounting and umounting [ 816.251274] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6d81: 0000 [#1] PREEMPT SMP NOPTI ... [ 816.260138] Call Trace: [ 816.260329] <TASK> [ 816.260499] ? die_addr+0x36/0x90 [ 816.260762] ? exc_general_protection+0x1b3/0x410 [ 816.261126] ? asm_exc_general_protection+0x26/0x30 [ 816.261502] ? • https://git.kernel.org/stable/c/558817597d5fbd7af31f891b67b0fd20f0d047b7 https://git.kernel.org/stable/c/89929ea46f9cc11ba66d2c64713aa5d5dc723b09 https://git.kernel.org/stable/c/0ab6f842452ce2cae04209d4671ac6289d0aef8a https://git.kernel.org/stable/c/d328c09ee9f15ee5a26431f5aad7c9239fa85e62 • CWE-416: Use After Free •
CVSS: 7.1EPSS: 0%CPEs: 3EXPL: 0CVE-2023-52751 – smb: client: fix use-after-free in smb2_query_info_compound()
https://notcve.org/view.php?id=CVE-2023-52751
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix use-after-free in smb2_query_info_compound() The following UAF was triggered when running fstests generic/072 with KASAN enabled against Windows Server 2022 and mount options 'multichannel,max_channels=2,vers=3.1.1,mfsymlinks,noperm' BUG: KASAN: slab-use-after-free in smb2_query_info_compound+0x423/0x6d0 [cifs] Read of size 8 at addr ffff888014941048 by task xfs_io/27534 CPU: 0 PID: 27534 Comm: xfs_io Not tainted 6.6.0-rc7 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 Call Trace: dump_stack_lvl+0x4a/0x80 print_report+0xcf/0x650 ? srso_alias_return_thunk+0x5/0x7f ? srso_alias_return_thunk+0x5/0x7f ? __phys_addr+0x46/0x90 kasan_report+0xda/0x110 ? smb2_query_info_compound+0x423/0x6d0 [cifs] ? • https://git.kernel.org/stable/c/6db94d08359c43f2c8fe372811cdee04564a41b9 https://git.kernel.org/stable/c/93877b9afc2994c89362007aac480a7b150f386f https://git.kernel.org/stable/c/5c86919455c1edec99ebd3338ad213b59271a71b https://access.redhat.com/security/cve/CVE-2023-52751 https://bugzilla.redhat.com/show_bug.cgi?id=2282748 • CWE-416: Use After Free •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52750 – arm64: Restrict CPU_BIG_ENDIAN to GNU as or LLVM IAS 15.x or newer
https://notcve.org/view.php?id=CVE-2023-52750
In the Linux kernel, the following vulnerability has been resolved: arm64: Restrict CPU_BIG_ENDIAN to GNU as or LLVM IAS 15.x or newer Prior to LLVM 15.0.0, LLVM's integrated assembler would incorrectly byte-swap NOP when compiling for big-endian, and the resulting series of bytes happened to match the encoding of FNMADD S21, S30, S0, S0. This went unnoticed until commit: 34f66c4c4d5518c1 ("arm64: Use a positive cpucap for FP/SIMD") Prior to that commit, the kernel would always enable the use of FPSIMD early in boot when __cpu_setup() initialized CPACR_EL1, and so usage of FNMADD within the kernel was not detected, but could result in the corruption of user or kernel FPSIMD state. After that commit, the instructions happen to trap during boot prior to FPSIMD being detected and enabled, e.g. | Unhandled 64-bit el1h sync exception on CPU0, ESR 0x000000001fe00000 -- ASIMD | CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1 | Hardware name: linux,dummy-virt (DT) | pstate: 400000c9 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : __pi_strcmp+0x1c/0x150 | lr : populate_properties+0xe4/0x254 | sp : ffffd014173d3ad0 | x29: ffffd014173d3af0 x28: fffffbfffddffcb8 x27: 0000000000000000 | x26: 0000000000000058 x25: fffffbfffddfe054 x24: 0000000000000008 | x23: fffffbfffddfe000 x22: fffffbfffddfe000 x21: fffffbfffddfe044 | x20: ffffd014173d3b70 x19: 0000000000000001 x18: 0000000000000005 | x17: 0000000000000010 x16: 0000000000000000 x15: 00000000413e7000 | x14: 0000000000000000 x13: 0000000000001bcc x12: 0000000000000000 | x11: 00000000d00dfeed x10: ffffd414193f2cd0 x9 : 0000000000000000 | x8 : 0101010101010101 x7 : ffffffffffffffc0 x6 : 0000000000000000 | x5 : 0000000000000000 x4 : 0101010101010101 x3 : 000000000000002a | x2 : 0000000000000001 x1 : ffffd014171f2988 x0 : fffffbfffddffcb8 | Kernel panic - not syncing: Unhandled exception | CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1 | Hardware name: linux,dummy-virt (DT) | Call trace: | dump_backtrace+0xec/0x108 | show_stack+0x18/0x2c | dump_stack_lvl+0x50/0x68 | dump_stack+0x18/0x24 | panic+0x13c/0x340 | el1t_64_irq_handler+0x0/0x1c | el1_abort+0x0/0x5c | el1h_64_sync+0x64/0x68 | __pi_strcmp+0x1c/0x150 | unflatten_dt_nodes+0x1e8/0x2d8 | __unflatten_device_tree+0x5c/0x15c | unflatten_device_tree+0x38/0x50 | setup_arch+0x164/0x1e0 | start_kernel+0x64/0x38c | __primary_switched+0xbc/0xc4 Restrict CONFIG_CPU_BIG_ENDIAN to a known good assembler, which is either GNU as or LLVM's IAS 15.0.0 and newer, which contains the linked commit. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: arm64: restringe CPU_BIG_ENDIAN a GNU como o LLVM IAS 15.x o posterior. Antes de LLVM 15.0.0, el ensamblador integrado de LLVM intercambiaba bytes incorrectamente con NOP al compilar para big-endian. y la serie de bytes resultante coincidió con la codificación de FNMADD S21, S30, S0, S0. Esto pasó desapercibido hasta la confirmación: 34f66c4c4d5518c1 ("arm64: use un cpucap positivo para FP/SIMD") Antes de esa confirmación, el kernel siempre habilitaba el uso de FPSIMD al principio del arranque cuando __cpu_setup() inicializaba CPACR_EL1, y por lo tanto el uso de FNMADD dentro del kernel no se detectó, pero podría provocar la corrupción del estado FPSIMD del usuario o del kernel. Después de esa confirmación, las instrucciones se bloquean durante el arranque antes de que se detecte y habilite FPSIMD, por ejemplo | Excepción de sincronización el1h de 64 bits no controlada en CPU0, ESR 0x000000001fe00000 - ASIMD | CPU: 0 PID: 0 Comunicaciones: intercambiador No contaminado 6.6.0-rc3-00013-g34f66c4c4d55 #1 | Nombre del hardware: linux,dummy-virt (DT) | pstate: 400000c9 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | ordenador personal: __pi_strcmp+0x1c/0x150 | lr: poblar_properties+0xe4/0x254 | sp: ffffd014173d3ad0 | x29: ffffd014173d3af0 x28: ffffbfffddffcb8 x27: 0000000000000000 | x26: 0000000000000058 x25: ffffbfffddfe054 x24: 0000000000000008 | x23: ffffbffffddfe000 x22: ffffbfffddfe000 x21: ffffbfffddfe044 | x20: ffffd014173d3b70 x19: 0000000000000001 x18: 0000000000000005 | x17: 0000000000000010 x16: 0000000000000000 x15: 00000000413e7000 | x14: 0000000000000000 x13: 0000000000001bcc x12: 0000000000000000 | x11: 00000000d00dfeed x10: ffffd414193f2cd0 x9: 0000000000000000 | x8: 0101010101010101 x7: ffffffffffffffc0 x6: 0000000000000000 | x5: 0000000000000000 x4: 0101010101010101 x3: 000000000000002a | x2: 0000000000000001 x1: ffffd014171f2988 x0: ffffbfffddffcb8 | Pánico del kernel: no se sincroniza: excepción no controlada | CPU: 0 PID: 0 Comunicaciones: intercambiador No contaminado 6.6.0-rc3-00013-g34f66c4c4d55 #1 | Nombre del hardware: linux,dummy-virt (DT) | Rastreo de llamadas: | dump_backtrace+0xec/0x108 | show_stack+0x18/0x2c | dump_stack_lvl+0x50/0x68 | dump_stack+0x18/0x24 | pánico+0x13c/0x340 | el1t_64_irq_handler+0x0/0x1c | el1_abort+0x0/0x5c | el1h_64_sync+0x64/0x68 | __pi_strcmp+0x1c/0x150 | unflatten_dt_nodes+0x1e8/0x2d8 | __unflatten_device_tree+0x5c/0x15c | unflatten_device_tree+0x38/0x50 | setup_arch+0x164/0x1e0 | start_kernel+0x64/0x38c | __primary_switched+0xbc/0xc4 Restrinja CONFIG_CPU_BIG_ENDIAN a un buen ensamblador conocido, que sea GNU o LLVM's IAS 15.0.0 y posteriores, que contiene la confirmación vinculada. • https://git.kernel.org/stable/c/d08a1e75253b4e19ae290b1c35349f12cfcebc0a https://git.kernel.org/stable/c/936c9c10efaefaf1ab3ef020e1f8aaaaff1ad2f9 https://git.kernel.org/stable/c/ef0224ee5399ea8a46bc07dc6c6494961ed5fdd2 https://git.kernel.org/stable/c/bd31e534721ab95ef237020fe6995c899ffdf21a https://git.kernel.org/stable/c/69e619d2fd056fe1f5d0adf01584f2da669e0d28 https://git.kernel.org/stable/c/146a15b873353f8ac28dc281c139ff611a3c4848 •