CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52600 – jfs: fix uaf in jfs_evict_inode
https://notcve.org/view.php?id=CVE-2023-52600
In the Linux kernel, the following vulnerability has been resolved: jfs: fix uaf in jfs_evict_inode When the execution of diMount(ipimap) fails, the object ipimap that has been released may be accessed in diFreeSpecial(). Asynchronous ipimap release occurs when rcu_core() calls jfs_free_node(). Therefore, when diMount(ipimap) fails, sbi->ipimap should not be initialized as ipimap. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: jfs: corrige uaf en jfs_evict_inode Cuando falla la ejecución de diMount(ipimap), se puede acceder al objeto ipimap que se ha liberado en diFreeSpecial(). La liberación asincrónica de ipimap ocurre cuando rcu_core() llama a jfs_free_node(). Por lo tanto, cuando falla diMount(ipimap), sbi->ipimap no debe inicializarse como ipimap. • https://git.kernel.org/stable/c/81b4249ef37297fb17ba102a524039a05c6c5d35 https://git.kernel.org/stable/c/93df0a2a0b3cde2d7ab3a52ed46ea1d6d4aaba5f https://git.kernel.org/stable/c/bc6ef64dbe71136f327d63b2b9071b828af2c2a8 https://git.kernel.org/stable/c/8e44dc3f96e903815dab1d74fff8faafdc6feb61 https://git.kernel.org/stable/c/32e8f2d95528d45828c613417cb2827d866cbdce https://git.kernel.org/stable/c/1696d6d7d4a1b373e96428d0fe1166bd7c3c795e https://git.kernel.org/stable/c/bacdaa04251382d7efd4f09f9a0686bfcc297e2e https://git.kernel.org/stable/c/e0e1958f4c365e380b17ccb35617345b3 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52599 – jfs: fix array-index-out-of-bounds in diNewExt
https://notcve.org/view.php?id=CVE-2023-52599
In the Linux kernel, the following vulnerability has been resolved: jfs: fix array-index-out-of-bounds in diNewExt [Syz report] UBSAN: array-index-out-of-bounds in fs/jfs/jfs_imap.c:2360:2 index -878706688 is out of range for type 'struct iagctl[128]' CPU: 1 PID: 5065 Comm: syz-executor282 Not tainted 6.7.0-rc4-syzkaller-00009-gbee0e7762ad2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:217 [inline] __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348 diNewExt+0x3cf3/0x4000 fs/jfs/jfs_imap.c:2360 diAllocExt fs/jfs/jfs_imap.c:1949 [inline] diAllocAG+0xbe8/0x1e50 fs/jfs/jfs_imap.c:1666 diAlloc+0x1d3/0x1760 fs/jfs/jfs_imap.c:1587 ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56 jfs_mkdir+0x1c5/0xb90 fs/jfs/namei.c:225 vfs_mkdir+0x2f1/0x4b0 fs/namei.c:4106 do_mkdirat+0x264/0x3a0 fs/namei.c:4129 __do_sys_mkdir fs/namei.c:4149 [inline] __se_sys_mkdir fs/namei.c:4147 [inline] __x64_sys_mkdir+0x6e/0x80 fs/namei.c:4147 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x45/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b RIP: 0033:0x7fcb7e6a0b57 Code: ff ff 77 07 31 c0 c3 0f 1f 40 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 b8 53 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffd83023038 EFLAGS: 00000286 ORIG_RAX: 0000000000000053 RAX: ffffffffffffffda RBX: 00000000ffffffff RCX: 00007fcb7e6a0b57 RDX: 00000000000a1020 RSI: 00000000000001ff RDI: 0000000020000140 RBP: 0000000020000140 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000286 R12: 00007ffd830230d0 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [Analysis] When the agstart is too large, it can cause agno overflow. [Fix] After obtaining agno, if the value is invalid, exit the subsequent process. Modified the test from agno > MAXAG to agno >= MAXAG based on linux-next report by kernel test robot (Dan Carpenter). En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: jfs: corrige array-index-out-of-bounds en diNewExt [Informe Syz] UBSAN: array-index-out-of-bounds en fs/jfs/jfs_imap.c: Índice 2360:2 -878706688 está fuera de rango para el tipo 'struct iagctl[128]' CPU: 1 PID: 5065 Comm: syz-executor282 No contaminado 6.7.0-rc4-syzkaller-00009-gbee0e7762ad2 #0 Nombre de hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2023 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c: 217 [en línea] __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348 diNewExt+0x3cf3/0x4000 fs/jfs/jfs_imap.c:2360 diAllocExt fs/jfs/jfs_imap.c:1949 [en línea] diAllocAG+0xbe8/0x1 e50 fs/ jfs/jfs_imap.c:1666 diAlloc+0x1d3/0x1760 fs/jfs/jfs_imap.c:1587 ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56 jfs_mkdir+0x1c5/0xb90 fs/jfs/namei.c:225 vfs_m kdir +0x2f1/0x4b0 fs/namei.c:4106 do_mkdirat+0x264/0x3a0 fs/namei.c:4129 __do_sys_mkdir fs/namei.c:4149 [en línea] __se_sys_mkdir fs/namei.c:4147 [en línea] __x64_sys_mkdir+0x 6e/0x80 fs/namei.c:4147 do_syscall_x64 arch/x86/entry/common.c:51 [en línea] do_syscall_64+0x45/0x110 arch/x86/entry/common.c:82 Entry_SYSCALL_64_after_hwframe+0x63/0x6b RIP: 0033:0x7fcb7e6a0b57 Código: ff ff 77 07 31 c0 c3 0f 1f 40 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 b8 53 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffd83023038 EFLAGS: 00000286 ORIG_RAX: 00000000000000053 RAX: ffffffffffffffda RBX: 0000000 0ffffffff RCX: 00007fcb7e6a0b57 RDX: 00000000000a1020 RSI: 00000000000001ff RDI: 0000000020000140 RBP: 0000000020000140 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000286 R12: 00007ffd830230d0 R13: 0000000000000000 R14 : 0000000000000000 R15: 0000000000000000 [Análisis] Cuando el agstart es demasiado grande, puede causar un desbordamiento de agno. [Solución] Después de obtener agno, si el valor no es válido, salga del proceso posterior. Se modificó la prueba de agno > MAXAG a agno >= MAXAG según el informe de Linux-next realizado por el robot de prueba del kernel (Dan Carpenter). • https://git.kernel.org/stable/c/f423528488e4f9606cef858eceea210bf1163f41 https://git.kernel.org/stable/c/de6a91aed1e0b1a23e9c11e7d7557f088eeeb017 https://git.kernel.org/stable/c/e2b77d107b33bb31c8b1f5c4cb8f277b23728f1e https://git.kernel.org/stable/c/6aa30020879042d46df9f747e4f0a486eea6fe98 https://git.kernel.org/stable/c/3537f92cd22c672db97fae6997481e678ad14641 https://git.kernel.org/stable/c/6996d43b14486f4a6655b10edc541ada1b580b4b https://git.kernel.org/stable/c/5a6660139195f5e2fbbda459eeecb8788f3885fe https://git.kernel.org/stable/c/49f9637aafa6e63ba686c13cb8549bf5e •
CVSS: 6.0EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52598 – s390/ptrace: handle setting of fpc register correctly
https://notcve.org/view.php?id=CVE-2023-52598
In the Linux kernel, the following vulnerability has been resolved: s390/ptrace: handle setting of fpc register correctly If the content of the floating point control (fpc) register of a traced process is modified with the ptrace interface the new value is tested for validity by temporarily loading it into the fpc register. This may lead to corruption of the fpc register of the tracing process: if an interrupt happens while the value is temporarily loaded into the fpc register, and within interrupt context floating point or vector registers are used, the current fp/vx registers are saved with save_fpu_regs() assuming they belong to user space and will be loaded into fp/vx registers when returning to user space. test_fp_ctl() restores the original user space fpc register value, however it will be discarded, when returning to user space. In result the tracer will incorrectly continue to run with the value that was supposed to be used for the traced process. Fix this by saving fpu register contents with save_fpu_regs() before using test_fp_ctl(). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/ptrace: maneja la configuración del registro fpc correctamente Si el contenido del registro de control de punto flotante (fpc) de un proceso rastreado se modifica con la interfaz ptrace, se prueba el nuevo valor validez cargándolo temporalmente en el registro fpc. Esto puede conducir a la corrupción del registro fpc del proceso de seguimiento: si ocurre una interrupción mientras el valor se carga temporalmente en el registro fpc, y dentro del contexto de interrupción se utilizan registros de punto flotante o vectoriales, los registros fp/vx actuales se guardan con save_fpu_regs() suponiendo que pertenecen al espacio del usuario y se cargarán en los registros fp/vx cuando regresen al espacio del usuario. test_fp_ctl() restaura el valor del registro fpc del espacio de usuario original; sin embargo, se descartará al regresar al espacio de usuario. Como resultado, el rastreador continuará ejecutándose incorrectamente con el valor que se suponía que debía usarse para el proceso rastreado. Solucione este problema guardando el contenido del registro fpu con save_fpu_regs() antes de usar test_fp_ctl(). • https://git.kernel.org/stable/c/6ccf904aac0292e1f6b1a1be6c407c414f7cf713 https://git.kernel.org/stable/c/6d0822f2cc9b153bf2df49a84599195a2e0d21a8 https://git.kernel.org/stable/c/856caf2730ea18cb39e95833719c02a02447dc0a https://git.kernel.org/stable/c/28a1f492cb527f64593457a0a0f0d809b3f36c25 https://git.kernel.org/stable/c/7a4d6481fbdd661f9e40e95febb95e3dee82bad3 https://git.kernel.org/stable/c/02c6bbfb08bad78dd014e24c7b893723c15ec7a1 https://git.kernel.org/stable/c/bdce67df7f12fb0409fbc604ce7c4254703f56d4 https://git.kernel.org/stable/c/8b13601d19c541158a6e18b278c00ba69 • CWE-20: Improper Input Validation •
CVSS: 4.0EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52597 – KVM: s390: fix setting of fpc register
https://notcve.org/view.php?id=CVE-2023-52597
In the Linux kernel, the following vulnerability has been resolved: KVM: s390: fix setting of fpc register kvm_arch_vcpu_ioctl_set_fpu() allows to set the floating point control (fpc) register of a guest cpu. The new value is tested for validity by temporarily loading it into the fpc register. This may lead to corruption of the fpc register of the host process: if an interrupt happens while the value is temporarily loaded into the fpc register, and within interrupt context floating point or vector registers are used, the current fp/vx registers are saved with save_fpu_regs() assuming they belong to user space and will be loaded into fp/vx registers when returning to user space. test_fp_ctl() restores the original user space / host process fpc register value, however it will be discarded, when returning to user space. In result the host process will incorrectly continue to run with the value that was supposed to be used for a guest cpu. Fix this by simply removing the test. There is another test right before the SIE context is entered which will handles invalid values. This results in a change of behaviour: invalid values will now be accepted instead of that the ioctl fails with -EINVAL. This seems to be acceptable, given that this interface is most likely not used anymore, and this is in addition the same behaviour implemented with the memory mapped interface (replace invalid values with zero) - see sync_regs() in kvm-s390.c. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: KVM: s390: configuración fija del registro fpc kvm_arch_vcpu_ioctl_set_fpu() permite configurar el registro de control de punto flotante (fpc) de una CPU invitada. • https://git.kernel.org/stable/c/3a04410b0bc7e056e0843ac598825dd359246d18 https://git.kernel.org/stable/c/5e63c9ae8055109d805aacdaf2a4fe2c3b371ba1 https://git.kernel.org/stable/c/150a3a3871490e8c454ffbac2e60abeafcecff99 https://git.kernel.org/stable/c/732a3bea7aba5b15026ea42d14953c3425cc7dc2 https://git.kernel.org/stable/c/0671f42a9c1084db10d68ac347d08dbf6689ecb3 https://git.kernel.org/stable/c/c87d7d910775a025e230fd6359b60627e392460f https://git.kernel.org/stable/c/2823db0010c400e4b2b12d02aa5d0d3ecb15d7c7 https://git.kernel.org/stable/c/b988b1bb0053c0dcd26187d29ef07566a • CWE-20: Improper Input Validation •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2023-52596 – sysctl: Fix out of bounds access for empty sysctl registers
https://notcve.org/view.php?id=CVE-2023-52596
In the Linux kernel, the following vulnerability has been resolved: sysctl: Fix out of bounds access for empty sysctl registers When registering tables to the sysctl subsystem there is a check to see if header is a permanently empty directory (used for mounts). This check evaluates the first element of the ctl_table. This results in an out of bounds evaluation when registering empty directories. The function register_sysctl_mount_point now passes a ctl_table of size 1 instead of size 0. It now relies solely on the type to identify a permanently empty register. Make sure that the ctl_table has at least one element before testing for permanent emptiness. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sysctl: corrige el acceso fuera de los límites para registros sysctl vacíos. • https://git.kernel.org/stable/c/15893975e9e382f8294ea8d926f08dc2d8d39ede https://git.kernel.org/stable/c/2ae7081bc10123b187e36a4f3a8e53768de31489 https://git.kernel.org/stable/c/315552310c7de92baea4e570967066569937a843 •