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 •
CVSS: 4.4EPSS: 0%CPEs: 3EXPL: 0CVE-2023-52749 – spi: Fix null dereference on suspend
https://notcve.org/view.php?id=CVE-2023-52749
In the Linux kernel, the following vulnerability has been resolved: spi: Fix null dereference on suspend A race condition exists where a synchronous (noqueue) transfer can be active during a system suspend. This can cause a null pointer dereference exception to occur when the system resumes. Example order of events leading to the exception: 1. spi_sync() calls __spi_transfer_message_noqueue() which sets ctlr->cur_msg 2. Spi transfer begins via spi_transfer_one_message() 3. System is suspended interrupting the transfer context 4. System is resumed 6. spi_controller_resume() calls spi_start_queue() which resets cur_msg to NULL 7. • https://git.kernel.org/stable/c/4ec4508db97502a12daee88c74782e8d35ced068 https://git.kernel.org/stable/c/96474ea47dc67b0704392d59192b233c8197db0e https://git.kernel.org/stable/c/bef4a48f4ef798c4feddf045d49e53c8a97d5e37 https://access.redhat.com/security/cve/CVE-2023-52749 https://bugzilla.redhat.com/show_bug.cgi?id=2282679 • CWE-476: NULL Pointer Dereference •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2022-48710 – drm/radeon: fix a possible null pointer dereference
https://notcve.org/view.php?id=CVE-2022-48710
In the Linux kernel, the following vulnerability has been resolved: drm/radeon: fix a possible null pointer dereference In radeon_fp_native_mode(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. The failure status of drm_cvt_mode() on the other path is checked too. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/radeon: corrige una posible desreferencia del puntero null. En radeon_fp_native_mode(), el valor de retorno de drm_mode_duplicate() se asigna al modo, lo que conducirá a una desreferencia del puntero NULL en caso de falla de drm_mode_duplicate(). Agregue una marca para evitar npd. • https://git.kernel.org/stable/c/b33f7d99c9226892c7794dc2500fae35966020c9 https://git.kernel.org/stable/c/16a0f0b63c4c7eb46fc4c3f00bf2836e6ee46a9f https://git.kernel.org/stable/c/8a89bfeef9abe93371e3ea8796377f2d132eee29 https://git.kernel.org/stable/c/28fd384c78d7d8ed8af0d086d778c3e438ba7f60 https://git.kernel.org/stable/c/fee8ae0a0bb66eb7730c22f44fbd7203f63c2eab https://git.kernel.org/stable/c/7b7fba107b2c4ec7673d0f45bdbb9d1af697d9b9 https://git.kernel.org/stable/c/e938d24f0b7392e142b8aa434f18590d99dbe479 https://git.kernel.org/stable/c/140d9807b96e1303f6f2675a7ae8710a2 •