CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52648 – drm/vmwgfx: Unmap the surface before resetting it on a plane state
https://notcve.org/view.php?id=CVE-2023-52648
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Unmap the surface before resetting it on a plane state Switch to a new plane state requires unreferencing of all held surfaces. In the work required for mob cursors the mapped surfaces started being cached but the variable indicating whether the surface is currently mapped was not being reset. This leads to crashes as the duplicated state, incorrectly, indicates the that surface is mapped even when no surface is present. That's because after unreferencing the surface it's perfectly possible for the plane to be backed by a bo instead of a surface. Reset the surface mapped flag when unreferencing the plane state surface to fix null derefs in cleanup. Fixes crashes in KDE KWin 6.0 on Wayland: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 4 PID: 2533 Comm: kwin_wayland Not tainted 6.7.0-rc3-vmwgfx #2 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 RIP: 0010:vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx] Code: 00 00 00 75 3a 48 83 c4 10 5b 5d c3 cc cc cc cc 48 8b b3 a8 00 00 00 48 c7 c7 99 90 43 c0 e8 93 c5 db ca 48 8b 83 a8 00 00 00 <48> 8b 78 28 e8 e3 f> RSP: 0018:ffffb6b98216fa80 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff969d84cdcb00 RCX: 0000000000000027 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff969e75f21600 RBP: ffff969d4143dc50 R08: 0000000000000000 R09: ffffb6b98216f920 R10: 0000000000000003 R11: ffff969e7feb3b10 R12: 0000000000000000 R13: 0000000000000000 R14: 000000000000027b R15: ffff969d49c9fc00 FS: 00007f1e8f1b4180(0000) GS:ffff969e75f00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000028 CR3: 0000000104006004 CR4: 00000000003706f0 Call Trace: <TASK> ? • https://git.kernel.org/stable/c/485d98d472d53f9617ffdfba5e677ac29ad4fe20 https://git.kernel.org/stable/c/0a23f95af7f28dae7c0f7c82578ca5e1a239d461 https://git.kernel.org/stable/c/105f72cc48c4c93f4578fcc61e06276471858e92 https://git.kernel.org/stable/c/75baad63c033b3b900d822bffbc96c9d3649bc75 https://git.kernel.org/stable/c/27571c64f1855881753e6f33c3186573afbab7ba https://access.redhat.com/security/cve/CVE-2023-52648 https://bugzilla.redhat.com/show_bug.cgi?id=2278539 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2022-48668 – smb3: fix temporary data corruption in collapse range
https://notcve.org/view.php?id=CVE-2022-48668
In the Linux kernel, the following vulnerability has been resolved: smb3: fix temporary data corruption in collapse range collapse range doesn't discard the affected cached region so can risk temporarily corrupting the file data. This fixes xfstest generic/031 I also decided to merge a minor cleanup to this into the same patch (avoiding rereading inode size repeatedly unnecessarily) to make it clearer. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: smb3: corrige la corrupción temporal de datos en el rango de contracción el rango de contracción no descarta la región en caché afectada, por lo que puede correr el riesgo de corromper temporalmente los datos del archivo. Esto corrige xfstest generic/031. También decidí fusionar una limpieza menor en el mismo parche (evitando volver a leer el tamaño del inodo repetidamente innecesariamente) para que quede más claro. • https://git.kernel.org/stable/c/5476b5dd82c8bb9d0dd426f96575ae656cede140 https://git.kernel.org/stable/c/49523a4732204bdacbf3941a016503ddb4ddb3b9 https://git.kernel.org/stable/c/fa30a81f255a56cccd89552cd6ce7ea6e8d8acc4 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2022-48667 – smb3: fix temporary data corruption in insert range
https://notcve.org/view.php?id=CVE-2022-48667
In the Linux kernel, the following vulnerability has been resolved: smb3: fix temporary data corruption in insert range insert range doesn't discard the affected cached region so can risk temporarily corrupting file data. Also includes some minor cleanup (avoiding rereading inode size repeatedly unnecessarily) to make it clearer. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: smb3: corrige la corrupción de datos temporales en el rango de inserción. El rango de inserción no descarta la región en caché afectada, por lo que puede correr el riesgo de dañar temporalmente los datos del archivo. También incluye una limpieza menor (evitando volver a leer el tamaño del inodo repetidamente innecesariamente) para hacerlo más claro. • https://git.kernel.org/stable/c/7fe6fe95b936084dce6eedcc2cccadf96eafae73 https://git.kernel.org/stable/c/0cdde8460c304283d4ebe3f767a70215d1ab9d4e https://git.kernel.org/stable/c/9c8b7a293f50253e694f19161c045817a938e551 •
CVSS: 7.4EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48666 – scsi: core: Fix a use-after-free
https://notcve.org/view.php?id=CVE-2022-48666
In the Linux kernel, the following vulnerability has been resolved: scsi: core: Fix a use-after-free There are two .exit_cmd_priv implementations. Both implementations use resources associated with the SCSI host. Make sure that these resources are still available when .exit_cmd_priv is called by waiting inside scsi_remove_host() until the tag set has been freed. This commit fixes the following use-after-free: ================================================================== BUG: KASAN: use-after-free in srp_exit_cmd_priv+0x27/0xd0 [ib_srp] Read of size 8 at addr ffff888100337000 by task multipathd/16727 Call Trace: <TASK> dump_stack_lvl+0x34/0x44 print_report.cold+0x5e/0x5db kasan_report+0xab/0x120 srp_exit_cmd_priv+0x27/0xd0 [ib_srp] scsi_mq_exit_request+0x4d/0x70 blk_mq_free_rqs+0x143/0x410 __blk_mq_free_map_and_rqs+0x6e/0x100 blk_mq_free_tag_set+0x2b/0x160 scsi_host_dev_release+0xf3/0x1a0 device_release+0x54/0xe0 kobject_put+0xa5/0x120 device_release+0x54/0xe0 kobject_put+0xa5/0x120 scsi_device_dev_release_usercontext+0x4c1/0x4e0 execute_in_process_context+0x23/0x90 device_release+0x54/0xe0 kobject_put+0xa5/0x120 scsi_disk_release+0x3f/0x50 device_release+0x54/0xe0 kobject_put+0xa5/0x120 disk_release+0x17f/0x1b0 device_release+0x54/0xe0 kobject_put+0xa5/0x120 dm_put_table_device+0xa3/0x160 [dm_mod] dm_put_device+0xd0/0x140 [dm_mod] free_priority_group+0xd8/0x110 [dm_multipath] free_multipath+0x94/0xe0 [dm_multipath] dm_table_destroy+0xa2/0x1e0 [dm_mod] __dm_destroy+0x196/0x350 [dm_mod] dev_remove+0x10c/0x160 [dm_mod] ctl_ioctl+0x2c2/0x590 [dm_mod] dm_ctl_ioctl+0x5/0x10 [dm_mod] __x64_sys_ioctl+0xb4/0xf0 dm_ctl_ioctl+0x5/0x10 [dm_mod] __x64_sys_ioctl+0xb4/0xf0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: core: corrige un use-after-free Hay dos implementaciones de .exit_cmd_priv. Ambas implementaciones utilizan recursos asociados con el host SCSI. Asegúrese de que estos recursos todavía estén disponibles cuando se llame a .exit_cmd_priv esperando dentro de scsi_remove_host() hasta que se haya liberado el conjunto de etiquetas. • https://git.kernel.org/stable/c/65ca846a53149a1a72cd8d02e7b2e73dd545b834 https://git.kernel.org/stable/c/5ce8fad941233e81f2afb5b52a3fcddd3ba8732f https://git.kernel.org/stable/c/f818708eeeae793e12dc39f8984ed7732048a7d9 https://git.kernel.org/stable/c/2e7eb4c1e8af8385de22775bd0be552f59b28c9a https://git.kernel.org/stable/c/8fe4ce5836e932f5766317cb651c1ff2a4cd0506 • CWE-416: Use After Free •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2022-48665 – exfat: fix overflow for large capacity partition
https://notcve.org/view.php?id=CVE-2022-48665
In the Linux kernel, the following vulnerability has been resolved: exfat: fix overflow for large capacity partition Using int type for sector index, there will be overflow in a large capacity partition. For example, if storage with sector size of 512 bytes and partition capacity is larger than 2TB, there will be overflow. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: exfat: corrige el desbordamiento de una partición de gran capacidad. Al usar el tipo int para el índice del sector, habrá un desbordamiento en una partición de gran capacidad. Por ejemplo, si el almacenamiento con un tamaño de sector de 512 bytes y una capacidad de partición es superior a 2 TB, se producirá un desbordamiento. • https://git.kernel.org/stable/c/1b6138385499507147e8f654840f4c39afe6adbf https://git.kernel.org/stable/c/17244f71765dfec39e84493993993e896c376d09 https://git.kernel.org/stable/c/2e9ceb6728f1dc2fa4b5d08f37d88cbc49a20a62 •