CVSS: 7.8EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52444 – f2fs: fix to avoid dirent corruption
https://notcve.org/view.php?id=CVE-2023-52444
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid dirent corruption As Al reported in link[1]: f2fs_rename() ... if (old_dir != new_dir && !whiteout) f2fs_set_link(old_inode, old_dir_entry, old_dir_page, new_dir); else f2fs_put_page(old_dir_page, 0); You want correct inumber in the ".." link. And cross-directory rename does move the source to new parent, even if you'd been asked to leave a whiteout in the old place. [1] https://lore.kernel.org/all/20231017055040.GN800259@ZenIV/ With below testcase, it may cause dirent corruption, due to it missed to call f2fs_set_link() to update ".." link to new directory. - mkdir -p dir/foo - renameat2 -w dir/foo bar [ASSERT] (__chk_dots_dentries:1421) --> Bad inode number[0x4] for '. • https://git.kernel.org/stable/c/7e01e7ad746bc8198a8b46163ddc73a1c7d22339 https://git.kernel.org/stable/c/02160112e6d45c2610b049df6eb693d7a2e57b46 https://git.kernel.org/stable/c/5624a3c1b1ebc8991318e1cce2aa719542991024 https://git.kernel.org/stable/c/6f866885e147d33efc497f1095f35b2ee5ec7310 https://git.kernel.org/stable/c/f100ba617d8be6c98a68f3744ef7617082975b77 https://git.kernel.org/stable/c/f0145860c20be6bae6785c7a2249577674702ac7 https://git.kernel.org/stable/c/d3c0b49aaa12a61d560528f5d605029ab57f0728 https://git.kernel.org/stable/c/2fb4867f4405aea8c0519d7d188207f23 • CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26590 – erofs: fix inconsistent per-file compression format
https://notcve.org/view.php?id=CVE-2024-26590
In the Linux kernel, the following vulnerability has been resolved: erofs: fix inconsistent per-file compression format EROFS can select compression algorithms on a per-file basis, and each per-file compression algorithm needs to be marked in the on-disk superblock for initialization. However, syzkaller can generate inconsistent crafted images that use an unsupported algorithmtype for specific inodes, e.g. use MicroLZMA algorithmtype even it's not set in `sbi->available_compr_algs`. This can lead to an unexpected "BUG: kernel NULL pointer dereference" if the corresponding decompressor isn't built-in. Fix this by checking against `sbi->available_compr_algs` for each m_algorithmformat request. Incorrect !erofs_sb_has_compr_cfgs preset bitmap is now fixed together since it was harmless previously. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: erofs: corrige el formato de compresión por archivo inconsistente EROFS puede seleccionar algoritmos de compresión por archivo, y cada algoritmo de compresión por archivo debe marcarse en el superbloque del disco para la inicialización. • https://git.kernel.org/stable/c/8f89926290c4b3d31748d5089b27952243be0693 https://git.kernel.org/stable/c/47467e04816cb297905c0f09bc2d11ef865942d9 https://git.kernel.org/stable/c/823ba1d2106019ddf195287ba53057aee33cf724 https://git.kernel.org/stable/c/eed24b816e50c6cd18cbee0ff0d7218c8fced199 https://git.kernel.org/stable/c/118a8cf504d7dfa519562d000f423ee3ca75d2c4 • CWE-476: NULL Pointer Dereference •
CVSS: 7.8EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26589 – bpf: Reject variable offset alu on PTR_TO_FLOW_KEYS
https://notcve.org/view.php?id=CVE-2024-26589
In the Linux kernel, the following vulnerability has been resolved: bpf: Reject variable offset alu on PTR_TO_FLOW_KEYS For PTR_TO_FLOW_KEYS, check_flow_keys_access() only uses fixed off for validation. However, variable offset ptr alu is not prohibited for this ptr kind. So the variable offset is not checked. The following prog is accepted: func#0 @0 0: R1=ctx() R10=fp0 0: (bf) r6 = r1 ; R1=ctx() R6_w=ctx() 1: (79) r7 = *(u64 *)(r6 +144) ; R6_w=ctx() R7_w=flow_keys() 2: (b7) r8 = 1024 ; R8_w=1024 3: (37) r8 /= 1 ; R8_w=scalar() 4: (57) r8 &= 1024 ; R8_w=scalar(smin=smin32=0, smax=umax=smax32=umax32=1024,var_off=(0x0; 0x400)) 5: (0f) r7 += r8 mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r8 stack= before 4: (57) r8 &= 1024 mark_precise: frame0: regs=r8 stack= before 3: (37) r8 /= 1 mark_precise: frame0: regs=r8 stack= before 2: (b7) r8 = 1024 6: R7_w=flow_keys(smin=smin32=0,smax=umax=smax32=umax32=1024,var_off =(0x0; 0x400)) R8_w=scalar(smin=smin32=0,smax=umax=smax32=umax32=1024, var_off=(0x0; 0x400)) 6: (79) r0 = *(u64 *)(r7 +0) ; R0_w=scalar() 7: (95) exit This prog loads flow_keys to r7, and adds the variable offset r8 to r7, and finally causes out-of-bounds access: BUG: unable to handle page fault for address: ffffc90014c80038 [...] Call Trace: <TASK> bpf_dispatcher_nop_func include/linux/bpf.h:1231 [inline] __bpf_prog_run include/linux/filter.h:651 [inline] bpf_prog_run include/linux/filter.h:658 [inline] bpf_prog_run_pin_on_cpu include/linux/filter.h:675 [inline] bpf_flow_dissect+0x15f/0x350 net/core/flow_dissector.c:991 bpf_prog_test_run_flow_dissector+0x39d/0x620 net/bpf/test_run.c:1359 bpf_prog_test_run kernel/bpf/syscall.c:4107 [inline] __sys_bpf+0xf8f/0x4560 kernel/bpf/syscall.c:5475 __do_sys_bpf kernel/bpf/syscall.c:5561 [inline] __se_sys_bpf kernel/bpf/syscall.c:5559 [inline] __x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:5559 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Fix this by rejecting ptr alu with variable offset on flow_keys. Applying the patch rejects the program with "R7 pointer arithmetic on flow_keys prohibited". En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Rechazar variable offset alu en PTR_TO_FLOW_KEYS Para PTR_TO_FLOW_KEYS, check_flow_keys_access() solo usa fijo para la validación. Sin embargo, el desplazamiento variable ptr alu no está prohibido para este tipo de ptr. • https://git.kernel.org/stable/c/d58e468b1112dcd1d5193c0a89ff9f98b5a3e8b9 https://git.kernel.org/stable/c/29ffa63f21bcdcef3e36b03cccf9d0cd031f6ab0 https://git.kernel.org/stable/c/4108b86e324da42f7ed425bd71632fd844300dc8 https://git.kernel.org/stable/c/e8d3872b617c21100c5ee4f64e513997a68c2e3d https://git.kernel.org/stable/c/1b500d5d6cecf98dd6ca88bc9e7ae1783c83e6d3 https://git.kernel.org/stable/c/22c7fa171a02d310e3a3f6ed46a698ca8a0060ed • CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer •
CVSS: 7.8EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26588 – LoongArch: BPF: Prevent out-of-bounds memory access
https://notcve.org/view.php?id=CVE-2024-26588
In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Prevent out-of-bounds memory access The test_tag test triggers an unhandled page fault: # ./test_tag [ 130.640218] CPU 0 Unable to handle kernel paging request at virtual address ffff80001b898004, era == 9000000003137f7c, ra == 9000000003139e70 [ 130.640501] Oops[#3]: [ 130.640553] CPU: 0 PID: 1326 Comm: test_tag Tainted: G D O 6.7.0-rc4-loong-devel-gb62ab1a397cf #47 61985c1d94084daa2432f771daa45b56b10d8d2a [ 130.640764] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022 [ 130.640874] pc 9000000003137f7c ra 9000000003139e70 tp 9000000104cb4000 sp 9000000104cb7a40 [ 130.641001] a0 ffff80001b894000 a1 ffff80001b897ff8 a2 000000006ba210be a3 0000000000000000 [ 130.641128] a4 000000006ba210be a5 00000000000000f1 a6 00000000000000b3 a7 0000000000000000 [ 130.641256] t0 0000000000000000 t1 00000000000007f6 t2 0000000000000000 t3 9000000004091b70 [ 130.641387] t4 000000006ba210be t5 0000000000000004 t6 fffffffffffffff0 t7 90000000040913e0 [ 130.641512] t8 0000000000000005 u0 0000000000000dc0 s9 0000000000000009 s0 9000000104cb7ae0 [ 130.641641] s1 00000000000007f6 s2 0000000000000009 s3 0000000000000095 s4 0000000000000000 [ 130.641771] s5 ffff80001b894000 s6 ffff80001b897fb0 s7 9000000004090c50 s8 0000000000000000 [ 130.641900] ra: 9000000003139e70 build_body+0x1fcc/0x4988 [ 130.642007] ERA: 9000000003137f7c build_body+0xd8/0x4988 [ 130.642112] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) [ 130.642261] PRMD: 00000004 (PPLV0 +PIE -PWE) [ 130.642353] EUEN: 00000003 (+FPE +SXE -ASXE -BTE) [ 130.642458] ECFG: 00071c1c (LIE=2-4,10-12 VS=7) [ 130.642554] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0) [ 130.642658] BADV: ffff80001b898004 [ 130.642719] PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) [ 130.642815] Modules linked in: [last unloaded: bpf_testmod(O)] [ 130.642924] Process test_tag (pid: 1326, threadinfo=00000000f7f4015f, task=000000006499f9fd) [ 130.643062] Stack : 0000000000000000 9000000003380724 0000000000000000 0000000104cb7be8 [ 130.643213] 0000000000000000 25af8d9b6e600558 9000000106250ea0 9000000104cb7ae0 [ 130.643378] 0000000000000000 0000000000000000 9000000104cb7be8 90000000049f6000 [ 130.643538] 0000000000000090 9000000106250ea0 ffff80001b894000 ffff80001b894000 [ 130.643685] 00007ffffb917790 900000000313ca94 0000000000000000 0000000000000000 [ 130.643831] ffff80001b894000 0000000000000ff7 0000000000000000 9000000100468000 [ 130.643983] 0000000000000000 0000000000000000 0000000000000040 25af8d9b6e600558 [ 130.644131] 0000000000000bb7 ffff80001b894048 0000000000000000 0000000000000000 [ 130.644276] 9000000104cb7be8 90000000049f6000 0000000000000090 9000000104cb7bdc [ 130.644423] ffff80001b894000 0000000000000000 00007ffffb917790 90000000032acfb0 [ 130.644572] ... [ 130.644629] Call Trace: [ 130.644641] [<9000000003137f7c>] build_body+0xd8/0x4988 [ 130.644785] [<900000000313ca94>] bpf_int_jit_compile+0x228/0x4ec [ 130.644891] [<90000000032acfb0>] bpf_prog_select_runtime+0x158/0x1b0 [ 130.645003] [<90000000032b3504>] bpf_prog_load+0x760/0xb44 [ 130.645089] [<90000000032b6744>] __sys_bpf+0xbb8/0x2588 [ 130.645175] [<90000000032b8388>] sys_bpf+0x20/0x2c [ 130.645259] [<9000000003f6ab38>] do_syscall+0x7c/0x94 [ 130.645369] [<9000000003121c5c>] handle_syscall+0xbc/0x158 [ 130.645507] [ 130.645539] Code: 380839f6 380831f9 28412bae <24000ca6> 004081ad 0014cb50 004083e8 02bff34c 58008e91 [ 130.645729] [ 130.646418] ---[ end trace 0000000000000000 ]--- On my machine, which has CONFIG_PAGE_SIZE_16KB=y, the test failed at loading a BPF prog with 2039 instructions: prog = (struct bpf_prog *)ffff80001b894000 insn = (struct bpf_insn *)(prog->insnsi)fff ---truncated--- En el kernel de Linux, se resolvió la siguiente vulnerabilidad: LoongArch: BPF: evita el acceso a la memoria fuera de los límites La prueba test_tag desencadena un error de página no controlada: # ./test_tag [130.640218] CPU 0 No se puede manejar la solicitud de paginación del kernel en virtual dirección ffff80001b898004, era == 9000000003137f7c, ra == 9000000003139e70 [ 130.640501] Ups[#3]: [ 130.640553] CPU: 0 PID: 1326 Comm: test_tag Contaminado: GDO 6.7.0-rc4 -loong-devel-gb62ab1a397cf #47 61985c1d94084daa2432f771daa45b56b10d8d2a [130.640764] Nombre de hardware: QEMU QEMU Máquina virtual, BIOS desconocido 2/2/2022 [ 130.640874] pc 9000000003137f7c ra 9000000003139e70 tp 9000000104cb4000 sp 9000000104cb7a40 [ 13 0.641001] a0 ffff80001b894000 a1 ffff80001b897ff8 a2 000000006ba210be a3 0000000000000000 [ 130.641128] a4 000000006ba210be a5 00000000000000 f1 a6 00000000000000b3 a7 0000000000000000 [ 130.641256] t0 00000000000000000 t1 00000000000007f6 t2 00000000000000000 t3 9000000004091b70 [ 130.641387] t4 00 0000006ba210be t5 0000000000000004 t6 ffffffffffffffff0 t7 90000000040913e0 [ 130.641512] t8 00000000000000005 u0 0000000000000dc0 s9 000000000 0000009 s0 9000000104cb7ae0 [ 130.641641] s1 00000000000007f6 s2 0000000000000009 s3 00000000000000095 s4 0000000000000000 [ 130.6 41771] s5 ffff80001b894000 s6 ffff80001b897fb0 s7 9000000004090c50 s8 0000000000000000 [ 130.641900] ra: 9000000003139e70 build_body+0x1fcc/0x4988 [ 130.642007] ERA: 9 000000003137f7c build_body+0xd8/0x4988 [ 130.642112] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE ) [ 130.642261] PRMD: 00000004 (PPLV0 +PIE -PWE) [ 130.642353] EUEN: 00000003 (+FPE +SXE -ASXE -BTE) [ 130.642458] ECFG: 00071c1c (LIE=2-4,10-12 VS=7) [ 130.642554] ESTAT: 00010000 [PIL] (IS= ECode=1 EssubCode=0) [ 130.642658] BADV: ffff80001b898004 [ 130.642719] PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) [ 1 30.642815] Módulos vinculados en: [última descarga : bpf_testmod(O)] [130.642924] Procesar test_tag (pid: 1326, threadinfo=00000000f7f4015f, tarea=000000006499f9fd) [130.643062] Pila: 0000000000000000 900000000338072 4 0000000000000000 0000000104cb7be8 [ 130.643213] 0000000000000000 25af8d9b6e600558 9000000106250ea0 9000000104cb7ae0 [ 130.643378] 0 000000000000000 0000000000000000 9000000104cb7be8 90000000049f6000 [ 130.643538] 0000000000000090 9000000106250ea0 ffff80001b894000 ffff80001b894000 [ 130.643685] 00007ffffb917790 900000000313ca94 00000000000000000 0000000000000000 [ 130.643831] ffff80001b894000 0000000000000ff7 0000000000000000 9000000100468000 [ 130.643983] 00000000000000000 0000000000000000 0000000000000040 25af8d9b6e600558 [ 130.644131] 0000000000000bb7 ffff80001b894048 0000000000000000 00000000000000 000 [ 130.644276] 9000000104cb7be8 90000000049f6000 0000000000000090 9000000104cb7bdc [ 130.644423] ffff80001b894000 0000000000000000 0 00007ffffb917790 90000000032acfb0 [ 130.644572] . .. [ 130.644629] Seguimiento de llamadas: [ 130.644641] [<9000000003137f7c>] build_body+0xd8/0x4988 [ 130.644785] [<900000000313ca94>] bpf_int_jit_compile+0x228/0x4ec [ 1 30.644891] [<90000000032acfb0>] bpf_prog_select_runtime+0x158/0x1b0 [ 130.645003] [<90000000032b3504>] bpf_prog_load+0x760/0xb44 [ 130.645089] [<90000000032b6744>] __sys_bpf+0xbb8/0x2588 [ 130.645175] [<90000000032b838 8>] sys_bpf+0x20/0x2c [ 130.645259] [<9000000003f6ab38>] do_syscall+0x7c/0x94 [ 130.645369] [<9000000003121c5c>] handle_syscall+0xbc/0x158 [ 130.645507] [ 130.645539] Código: 380839f6 380831f9 28412bae <24000ca6> 004081ad 0014 cb50 004083e8 02bff34c 58008e91 [ 130.645729] [ 130.646418] ---[ final de seguimiento 0000000000000000 ]--- En mi máquina, que tiene CONFIG_PAGE_SIZE_16KB=y, la prueba falló al cargar un programa BPF con 2039 instrucciones: prog = (struct bpf_prog *)ffff80001b894000 insn = (struct bpf_insn *)(prog->insnsi)fff ---truncado--- • https://git.kernel.org/stable/c/bbfddb904df6f82a5948687a2d57766216b9bc0f https://git.kernel.org/stable/c/4631c2dd69d928bca396f9f58baeddf85e14ced5 https://git.kernel.org/stable/c/9aeb09f4d85a87bac46c010d75a2ea299d462f28 https://git.kernel.org/stable/c/7924ade13a49c0067da6ea13e398102979c0654a https://git.kernel.org/stable/c/36a87385e31c9343af9a4756598e704741250a67 • CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26587 – net: netdevsim: don't try to destroy PHC on VFs
https://notcve.org/view.php?id=CVE-2024-26587
In the Linux kernel, the following vulnerability has been resolved: net: netdevsim: don't try to destroy PHC on VFs PHC gets initialized in nsim_init_netdevsim(), which is only called if (nsim_dev_port_is_pf()). Create a counterpart of nsim_init_netdevsim() and move the mock_phc_destroy() there. This fixes a crash trying to destroy netdevsim with VFs instantiated, as caught by running the devlink.sh test: BUG: kernel NULL pointer dereference, address: 00000000000000b8 RIP: 0010:mock_phc_destroy+0xd/0x30 Call Trace: <TASK> nsim_destroy+0x4a/0x70 [netdevsim] __nsim_dev_port_del+0x47/0x70 [netdevsim] nsim_dev_reload_destroy+0x105/0x120 [netdevsim] nsim_drv_remove+0x2f/0xb0 [netdevsim] device_release_driver_internal+0x1a1/0x210 bus_remove_device+0xd5/0x120 device_del+0x159/0x490 device_unregister+0x12/0x30 del_device_store+0x11a/0x1a0 [netdevsim] kernfs_fop_write_iter+0x130/0x1d0 vfs_write+0x30b/0x4b0 ksys_write+0x69/0xf0 do_syscall_64+0xcc/0x1e0 entry_SYSCALL_64_after_hwframe+0x6f/0x77 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: netdevsim: no intente destruir PHC en VF PHC se inicializa en nsim_init_netdevsim(), que sólo se llama si (nsim_dev_port_is_pf()). Cree una contraparte de nsim_init_netdevsim() y mueva el mock_phc_destroy() allí. Esto soluciona un fallo al intentar destruir netdevsim con VF instanciados, detectado al ejecutar la prueba devlink.sh: ERROR: desreferencia del puntero NULL del núcleo, dirección: 00000000000000b8 RIP: 0010:mock_phc_destroy+0xd/0x30 Seguimiento de llamadas: nsim_destroy+0x4a /0x70 [netdevsim] __nsim_dev_port_del+0x47/0x70 [netdevsim] nsim_dev_reload_destroy+0x105/0x120 [netdevsim] nsim_drv_remove+0x2f/0xb0 [netdevsim] dispositivo_release_driver_internal+0x1a1/0x210 bus_remove_device+0xd5/0x120 dispositivo_del+0x159/0x490 dispositivo_unregister+0x12/0x30 del_device_store +0x11a/0x1a0 [netdevsim] kernfs_fop_write_iter+0x130/0x1d0 vfs_write+0x30b/0x4b0 ksys_write+0x69/0xf0 do_syscall_64+0xcc/0x1e0 Entry_SYSCALL_64_after_hwframe+0x6f/0x77 • https://git.kernel.org/stable/c/b63e78fca889e07931ec8f259701718a24e5052e https://git.kernel.org/stable/c/08aca65997fb6f233066883b1f1e653bcb1f26ca https://git.kernel.org/stable/c/c5068e442eed063d2f1658e6b6d3c1c6fcf1e588 https://git.kernel.org/stable/c/ea937f77208323d35ffe2f8d8fc81b00118bfcda • CWE-476: NULL Pointer Dereference •