Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: llc: llame a sock_orphan() en el momento del lanzamiento syzbot informó un rastro interesante [1] causado por un puntero sk->sk_wq obsoleto en un socket llc cerrado. En El commit ff7b11aa481f ("net: socket: set sock->sk to NULL after call proto_ops::release()") Eric Biggers insinuó que a algunos protocolos les falta un sock_orphan(), necesitamos realizar una auditoría completa. En net-next, planeo borrar sock->sk de sock_orphan() y modificar el parche de Eric para agregar una advertencia. [1] ERROR: KASAN: slab-use-after-free en list_empty include/linux/list.h:373 [en línea] ERROR: KASAN: slab-use-after-free en waitqueue_active include/linux/wait.h:127 [en línea] ERROR: KASAN: slab-use-after-free en sock_def_write_space_wfree net/core/sock.c:3384 [en línea] ERROR: KASAN: slab-use-after-free en sock_wfree+0x9a8/0x9d0 net/core/sock .c:2468 Lectura del tamaño 8 en la dirección ffff88802f4fc880 por tarea ksoftirqd/1/27 CPU: 1 PID: 27 Comm: ksoftirqd/1 Not tainted 6.8.0-rc1-syzkaller-00049-g6098d87eaf31 #0 Nombre de hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 01/04/2014 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack .c:106 print_address_description mm/kasan/report.c:377 [en línea] print_report+0xc4/0x620 mm/kasan/report.c:488 kasan_report+0xda/0x110 mm/kasan/report.c:601 list_empty include/linux/ list.h:373 [en línea] waitqueue_active include/linux/wait.h:127 [en línea] sock_def_write_space_wfree net/core/sock.c:3384 [en línea] sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468 skb_release_head_state+ 0xa3/0x2b0 net/core/skbuff.c:1080 skb_release_all net/core/skbuff.c:1092 [en línea] napi_consume_skb+0x119/0x2b0 net/core/skbuff.c:1404 e1000_unmap_and_free_tx_resource+0x144/0x200 drivers/net/ethernet/ intel/e1000/e1000_main.c:1970 e1000_clean_tx_irq controladores/net/ethernet/intel/e1000/e1000_main.c:3860 [en línea] e1000_clean+0x4a1/0x26e0 controladores/net/ethernet/intel/e1000/e1000_main.c:3801 __ napi_poll. constprop.0+0xb4/0x540 net/core/dev.c:6576 napi_poll net/core/dev.c:6645 [en línea] net_rx_action+0x956/0xe90 net/core/dev.c:6778 __do_softirq+0x21a/0x8de kernel/ softirq.c:553 run_ksoftirqd kernel/softirq.c:921 [en línea] run_ksoftirqd+0x31/0x60 kernel/softirq.c:913 smpboot_thread_fn+0x660/0xa10 kernel/smpboot.c:164 kthread+0x2c6/0x3a0 kernel/kthread.c :388 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242 Asignado por tarea 5167: kasan_save_stack+0x33/0x50 mm/ kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:314 [en línea] __kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:340 kasan_slab_alloc incluir /linux/kasan.h:201 [en línea] slab_post_alloc_hook mm/slub.c:3813 [en línea] slab_alloc_node mm/slub.c:3860 [en línea] kmem_cache_alloc_lru+0x142/0x6f0 mm/slub.c:3879 alloc_inode_sb include/linux/ fs.h:3019 [en línea] sock_alloc_inode+0x25/0x1c0 net/socket.c:308 alloc_inode+0x5d/0x220 fs/inode.c:260 new_inode_pseudo+0x16/0x80 fs/inode.c:1005 sock_alloc+0x40/0x270 net /socket.c:634 __sock_create+0xbc/0x800 net/socket.c:1535 sock_create net/socket.c:1622 [en línea] __sys_socket_create net/socket.c:1659 [en línea] __sys_socket+0x14c/0x260 net/socket.c :1706 __do_sys_socket net/socket.c:1720 [en línea] __se_sys_socket net/socket.c:1718 [en línea] __x64_sys_socket+0x72/0xb0 net/socket.c:1718 do_syscall_x64 arch/x86/entry/common.c:52 [en línea ] do_syscall_64+0xd3/0x250 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x63/0x6b Liberado por la tarea 0: kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/ common.c:68 kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640 veneno_slab_object mm/kasan/common.c:241 [en línea] __kasan_slab_free+0x121/0x1b0 mm/kasan/common.c:257 kasan_slab_free include/linux /kasan.h:184 [en línea] slab_free_hook mm/slub.c:2121 [en línea ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ipmr: corrige el pánico del kernel al reenviar paquetes mcast El stacktrace fue: [86.305548] ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000092 [86.306815] #PF: acceso de lectura del supervisor en modo kernel [ 86.307717] #PF: error_code(0x0000) - página no presente [ 86.308624] PGD 0 P4D 0 [ 86.309091] Ups: 0000 [#1] PREEMPT SMP NOPTI [ 86.309883] CPU: 2 PID: 3139 Comm: pimd Contaminado: GU 6.8.0-6wind-knet #1 [ 86.311027] Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS rel-1.11.1-0-g0551a4be2c-prebuilt.qemu-project.org 01/04/2014 [ 86.312728] RIP: 0010:ip_mr_forward (/build/work/knet/net/ipv4/ipmr.c:1985) [86.313399] Código: f9 1f 0f 87 85 03 00 00 48 8d 04 5b 48 8d 04 83 49 8d 44 c 5 00 48 8b 40 70 48 39 c2 0f 84 d9 00 00 00 49 8b 46 58 48 83 e0 fe <80> b8 92 00 00 00 00 0f 84 55 ff ff 49 83 47 38 01 45 85 e4 0f [ 86.316565] RSP : 0018:ffffad21c0583ae0 EFLAGS: 00010246 [ 86.317497] RAX: 0000000000000000 RBX: 00000000000000000 RCX: 00000000000000000 [ 86.318596] RDX: ff ff9559cb46c000 RSI: 0000000000000000 RDI: 0000000000000000 [ 86.319627] RBP: ffffad21c0583b30 R08: 00000000000000000 R09: 00000000000000000 [ 86.320650] R10: 0000000000000000 R11 : 0000000000000000 R12: 00000000000000001 [ 86.321672] R13: ffff9559c093a000 R14: ffff9559cc00b800 R15: ffff9559c09c1d80 [ 86.322873] FS: 0 0007f85db661980(0000) GS:ffff955a79d00000(0000) knlGS:0000000000000000 [ 86.324291] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [86.325314] CR2: 0000000000000092 CR3: 000000002f13a000 CR4: 0000000000350ef0 [86.326589] Seguimiento de llamadas: [86.327036] [86.327434] ? show_regs (/build/work/knet/arch/x86/kernel/dumpstack.c:479) [86.328049]? __die (/build/work/knet/arch/x86/kernel/dumpstack.c:421 /build/work/knet/arch/x86/kernel/dumpstack.c:434) [86.328508] ? page_fault_oops (/build/work/knet/arch/x86/mm/fault.c:707) [86.329107]? do_user_addr_fault (/build/work/knet/arch/x86/mm/fault.c:1264) [86.329756]? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223) [86.330350]? __irq_work_queue_local (/build/work/knet/kernel/irq_work.c:111 (discriminador 1)) [86.331013]? exc_page_fault (/build/work/knet/./arch/x86/include/asm/paravirt.h:693 /build/work/knet/arch/x86/mm/fault.c:1515 /build/work/knet/arch /x86/mm/fault.c:1563) [86.331702]? asm_exc_page_fault (/build/work/knet/./arch/x86/include/asm/idtentry.h:570) [86.332468]? ip_mr_forward (/build/work/knet/net/ipv4/ipmr.c:1985) [86.333183]? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223) [ 86.333920] ipmr_mfc_add (/build/work/knet/./include/linux/rcupdate.h:782 /build/work/knet /net/ipv4/ipmr.c:1009 /build/work/knet/net/ipv4/ipmr.c:1273) [86.334583]? __pfx_ipmr_hash_cmp (/build/work/knet/net/ipv4/ipmr.c:363) [ 86.335357] ip_mroute_setsockopt (/build/work/knet/net/ipv4/ipmr.c:1470) [ 86.336135] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223) [86.336854]? ip_mroute_setsockopt (/build/work/knet/net/ipv4/ipmr.c:1470) [ 86.337679] do_ip_setsockopt (/build/work/knet/net/ipv4/ip_sockglue.c:944) [ 86.338408] ? __pfx_unix_stream_read_actor (/build/work/knet/net/unix/af_unix.c:2862) [86.339232]? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223) [86.339809]? aa_sk_perm (/build/work/knet/security/apparmor/include/cred.h:153 /build/work/knet/security/apparmor/net.c:181) [ 86.340342] ip_setsockopt (/build/work/knet/net /ipv4/ip_sockglue.c:1415) [86.340859] raw_setsockopt (/build/work/knet/net/ipv4/raw.c:836) [86.341408] ? security_socket_setsockopt (/build/work/knet/security/security.c:4561 (discriminador 13)) [ 86.342116] sock_common_setsockopt (/build/work/knet/net/core/sock.c:3716) [ 86.342747] do_sock_setsockopt (/build /work/knet/net/socket.c:2313) [ 86.343363] __sys_setsockopt (/build/work/knet/./include/linux/file.h:32 /build/work/kn ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: core: Saque scsi_host_busy() del bloqueo del host para activar el controlador EH Dentro de scsi_eh_wakeup(), se llama a scsi_host_busy() y se verifica con el bloqueo del host cada vez para decidir si se produce un error. Es necesario activar el controlador kthread. Esto puede ser demasiado pesado en caso de recuperación, como por ejemplo: - N colas de hardware - la profundidad de la cola es M para cada cola de hardware - cada scsi_host_busy() itera sobre (N * M) etiquetas/solicitudes Si la recuperación se activa en caso de que todas las solicitudes están en curso, cada scsi_eh_wakeup() está estrictamente serializado, cuando se llama a scsi_eh_wakeup() para la última solicitud en curso, scsi_host_busy() se ha ejecutado (N * M - 1) veces y la solicitud se ha iterado durante ( N*M - 1) * (N * M) veces. Si tanto N como M son lo suficientemente grandes, se puede activar un bloqueo duro al adquirir el bloqueo del host, y se observa en mpi3mr (128 colas hw, profundidad de cola 8169). Solucione el problema llamando a scsi_host_busy() fuera del bloqueo del host. No necesitamos el bloqueo del host para obtener el recuento de ocupación porque el bloqueo del host nunca cubre eso. [mkp: elimine las variables 'ocupadas' innecesarias señaladas por Bart]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: UBSAN: array-index-out-of-bounds en dtSplitRoot Syzkaller informó el siguiente problema: oop0: se detectó un cambio de capacidad de 0 a 32768 UBSAN: array-index-out-of- límites en fs/jfs/jfs_dtree.c:1971:9 índice -2 está fuera de rango para el tipo 'struct dtslot [128]' CPU: 0 PID: 3613 Comm: syz-executor270 No contaminado 6.0.0-syzkaller-09423- g493ffd6605b2 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 22/09/2022 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c: 106 ubsan_epilogue lib/ubsan.c:151 [en línea] __ubsan_handle_out_of_bounds+0xdb/0x130 lib/ubsan.c:283 dtSplitRoot+0x8d8/0x1900 fs/jfs/jfs_dtree.c:1971 dtSplitUp fs/jfs/jfs_dtree.c:9 85 [en línea ] dtInsert+0x1189/0x6b80 fs/jfs/jfs_dtree.c:863 jfs_mkdir+0x757/0xb00 fs/jfs/namei.c:270 vfs_mkdir+0x3b3/0x590 fs/namei.c:4013 do_mkdirat+0x279/0x550 f s/namei. c:4038 __do_sys_mkdirat fs/namei.c:4053 [en línea] __se_sys_mkdirat fs/namei.c:4051 [en línea] __x64_sys_mkdirat+0x85/0x90 fs/namei.c:4051 do_syscall_x64 arch/x86/entry/common.c:50 [ inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fcdc0113fd9 Código: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 F7 48 89 D6 48 89 CA 4D 89 C2 4D 89 C8 4C 8B 4C 24 08 0F 05 <48> 3D 01 F0 FF FF 73 01 C3 48 C7 C1 C0 FF FF FF F7 D8 64 89 01 48 RSP: 002B: 00007ffeb8bc67d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000102 RAX: ffffffffffffffda RBX: 00000000000000000 RCX: 00007fcdc0113fd9 RDX: 00000000000000000 RSI: 0000000020000340 RDI: 0000000000000003 RBP: 00007fcdc00d37a0 R08: 0000000000000000 R09: 00007fcdc00d37a0 R10: 00005555559a72c0 R11: 0000000000000246 R12: 00000000f8008000 R13: 0000000000000000 R14: 00083878000000f8 R15 : 0000000000000000 El problema se produce cuando el valor de fsi es inferior a -1. La verificación para romper el ciclo cuando el valor fsi se convierte en -1 está presente, pero syzbot pudo producir un valor menor que -1, lo que causa el error. Este parche simplemente agrega el cambio para los valores menores que 0. El parche se prueba a través de syzbot.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: FS:JFS:UBSAN:array-index-out-of-bounds en dbAdjTree Syzkaller informó el siguiente problema: UBSAN: array-index-out-of-bounds en fs/jfs /jfs_dmap.c:2867:6 el índice 196694 está fuera del rango para el tipo 's8[1365]' (también conocido como 'carácter firmado[1365]') CPU: 1 PID: 109 Comm: jfsCommit No contaminado 6.6.0-rc3-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/08/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 dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867 dbJoin+0x210/0x2d0 fs/jfs/jfs _dmap.c: 2834 dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331 dbFreeDmap fs/jfs/jfs_dmap.c:2080 [en línea] dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402 txFreeMap+0x798/0xd50 fs/j fs /jfs_txnmgr.c:2534 txUpdateMap+0x342/0x9e0 txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [en línea] jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732 kthread+0x2d3/0x3 70 kernel/kthread.c:388 ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 ============== ==================================================== ================ Pánico del kernel: no se sincroniza: UBSAN: pánico_on_warn configurado... CPU: 1 PID: 109 Comm: jfsCommit No contaminado 6.6.0-rc3-syzkaller #0 Hardware nombre: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/08/2023 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106 pánico+0x30f /0x770 Kernel/Panic.C: 340 check_panic_on_warn+0x82/0xa0 kernel/Panic.c: 236 UBSAN_EPILOGO LIB/UBSAN.C: 223 [Inline] __ubsan_handle_out_of_bounds+0x13c/0x150 LIB/UB/UBSAN.C: 4F0 FS /jfs/jfs_dmap.c:2867 dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834 dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331 dbFreeDmap fs/jfs/jfs_dmap.c:2080 [en línea] dbFree +0x343/0x650 fs/jfs/jfs_dmap.c:402 txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534 txUpdateMap+0x342/0x9e0 txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [en línea] jf s_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732 kthread+0x2d3/0x370 kernel/kthread.c:388 ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64. S:304 Desplazamiento del kernel: deshabilitado Reinicio en 86400 segundos. El problema se produce cuando el valor de lp se vuelve mayor que CTLTREESIZE, que es el tamaño máximo de stree. Agregar una verificación simple resuelve este problema. Dave: Como la función devuelve un valor nulo, un buen manejo de errores requeriría una reorganización del código más intrusiva, así que modifiqué el parche de Osama en use WARN_ON_ONCE por falta de una opción más limpia. El parche se prueba mediante syzbot.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPI: extlog: corrige la verificación de desreferencia del puntero NULL El complemento gcc -fanalyzer [1] intenta detectar varios patrones de comportamiento incorrecto. La herramienta informa: drivers/acpi/acpi_extlog.c: En función 'extlog_exit': drivers/acpi/acpi_extlog.c:307:12: advertencia: verificación de 'extlog_l1_addr' para NULL después de desreferenciarlo [-Wanalyzer-deref-before -verificar] | | 306 | ((struct extlog_l1_head *)extlog_l1_addr)->flags &= ~FLAG_OS_OPTIN; | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~ | | | | | (1) Aquí se elimina la referencia al puntero 'extlog_l1_addr' | 307 | si (extlog_l1_addr) | | ~ | | | | | (2) El puntero 'extlog_l1_addr' está marcado como NULL aquí pero ya se eliminó la referencia en (1) | Corrija la verificación de desreferencia del puntero NULL en extlog_exit().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/lib: validar tamaño para operaciones vectoriales Parte del código fp/vmx en sstep.c asume un cierto tamaño máximo para las instrucciones que se emula. Sin embargo, el tamaño de esas operaciones se determina por separado en analyse_instr(). Agregue una verificación para validar la suposición sobre el tamaño máximo de las operaciones, a fin de evitar daños no deseados en la pila del kernel.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: powerpc/mm: corrige la desreferencia del puntero nulo en pgtable_cache_add kasprintf() devuelve un puntero a la memoria asignada dinámicamente que puede ser NULL en caso de falla. Asegúrese de que la asignación se haya realizado correctamente comprobando la validez del puntero.

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).

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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jfs: corrige el índice de matriz fuera de los límites en dbAdjTree Actualmente falta una verificación de los límite en dbAdjTree al acceder a dmt_stree. Para agregar la verificación requerida, se agregó el bool is_ctl que se requiere para determinar el tamaño como se sugiere en el siguiente commit. https://lore.kernel.org/linux-kernel-mentees/f9475918-2186-49b8-b801-6f0f9e75f4fa@oracle.com/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jfs: arreglar slab-out-of-bounds Leer en dtSearch Actualmente, mientras se busca la página actual en la tabla de entradas ordenadas de la página, hay un acceso fuera de los límites. Se agregó un cheque encuadernado para corregir el error. Dave: establece el código de retorno en -EIO