CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-26870 – NFSv4.2: fix nfs4_listxattr kernel BUG at mm/usercopy.c:102
https://notcve.org/view.php?id=CVE-2024-26870
In the Linux kernel, the following vulnerability has been resolved: NFSv4.2: fix nfs4_listxattr kernel BUG at mm/usercopy.c:102 A call to listxattr() with a buffer size = 0 returns the actual size of the buffer needed for a subsequent call. When size > 0, nfs4_listxattr() does not return an error because either generic_listxattr() or nfs4_listxattr_nfs4_label() consumes exactly all the bytes then size is 0 when calling nfs4_listxattr_nfs4_user() which then triggers the following kernel BUG: [ 99.403778] kernel BUG at mm/usercopy.c:102! [ 99.404063] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 99.408463] CPU: 0 PID: 3310 Comm: python3 Not tainted 6.6.0-61.fc40.aarch64 #1 [ 99.415827] Call trace: [ 99.415985] usercopy_abort+0x70/0xa0 [ 99.416227] __check_heap_object+0x134/0x158 [ 99.416505] check_heap_object+0x150/0x188 [ 99.416696] __check_object_size.part.0+0x78/0x168 [ 99.416886] __check_object_size+0x28/0x40 [ 99.417078] listxattr+0x8c/0x120 [ 99.417252] path_listxattr+0x78/0xe0 [ 99.417476] __arm64_sys_listxattr+0x28/0x40 [ 99.417723] invoke_syscall+0x78/0x100 [ 99.417929] el0_svc_common.constprop.0+0x48/0xf0 [ 99.418186] do_el0_svc+0x24/0x38 [ 99.418376] el0_svc+0x3c/0x110 [ 99.418554] el0t_64_sync_handler+0x120/0x130 [ 99.418788] el0t_64_sync+0x194/0x198 [ 99.418994] Code: aa0003e3 d000a3e0 91310000 97f49bdb (d4210000) Issue is reproduced when generic_listxattr() returns 'system.nfs4_acl', thus calling lisxattr() with size = 16 will trigger the bug. Add check on nfs4_listxattr() to return ERANGE error when it is called with size > 0 and the return value is greater than size. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFSv4.2: corrige el ERROR del kernel nfs4_listxattr en mm/usercopy.c:102 Una llamada a listxattr() con un tamaño de búfer = 0 devuelve el tamaño real del búfer necesario para un convocatoria posterior. Cuando el tamaño > 0, nfs4_listxattr() no devuelve un error porque generic_listxattr() o nfs4_listxattr_nfs4_label() consume exactamente todos los bytes, entonces el tamaño es 0 al llamar a nfs4_listxattr_nfs4_user(), lo que luego activa el siguiente ERROR del kernel: [99.403778] ERROR del kernel en mm/usercopy.c:102! • https://git.kernel.org/stable/c/012a211abd5db098094ce429de5f046368391e68 https://git.kernel.org/stable/c/4403438eaca6e91f02d272211c4d6b045092396b https://git.kernel.org/stable/c/9d52865ff28245fc2134da9f99baff603a24407a https://git.kernel.org/stable/c/06e828b3f1b206de08ef520fc46a40b22e1869cb https://git.kernel.org/stable/c/79cdcc765969d23f4e3d6ea115660c3333498768 https://git.kernel.org/stable/c/80365c9f96015bbf048fdd6c8705d3f8770132bf https://git.kernel.org/stable/c/23bfecb4d852751d5e403557dd500bb563313baf https://git.kernel.org/stable/c/251a658bbfceafb4d58c76b77682c8bf7 • CWE-20: Improper Input Validation •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26869 – f2fs: fix to truncate meta inode pages forcely
https://notcve.org/view.php?id=CVE-2024-26869
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to truncate meta inode pages forcely Below race case can cause data corruption: Thread A GC thread - gc_data_segment - ra_data_block - locked meta_inode page - f2fs_inplace_write_data - invalidate_mapping_pages : fail to invalidate meta_inode page due to lock failure or dirty|writeback status - f2fs_submit_page_bio : write last dirty data to old blkaddr - move_data_block - load old data from meta_inode page - f2fs_submit_page_write : write old data to new blkaddr Because invalidate_mapping_pages() will skip invalidating page which has unclear status including locked, dirty, writeback and so on, so we need to use truncate_inode_pages_range() instead of invalidate_mapping_pages() to make sure meta_inode page will be dropped. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para truncar las páginas de meta-inodo a la fuerza El siguiente caso de carrera puede causar corrupción de datos: Hilo Un hilo de GC - gc_data_segment - ra_data_block - página de meta_inodo bloqueada - f2fs_inplace_write_data - invalidate_mapping_pages: no se puede invalidar meta_inode página debido a falla de bloqueo o estado sucio|reescritura - f2fs_submit_page_bio: escribe los últimos datos sucios en el blkaddr antiguo - move_data_block - carga datos antiguos de la página meta_inode - f2fs_submit_page_write: escribe datos antiguos en el blkaddr nuevo Porque invalidate_mapping_pages() omitirá la página de invalidación cuyo estado no está claro incluyendo bloqueado, sucio, reescritura, etc., por lo que debemos usar truncate_inode_pages_range() en lugar de invalidate_mapping_pages() para asegurarnos de que la página meta_inode se elimine. • https://git.kernel.org/stable/c/6aa58d8ad20a3323f42274c25820a6f54192422d https://git.kernel.org/stable/c/c92f2927df860a60ba815d3ee610a944b92a8694 https://git.kernel.org/stable/c/77bfdb89cc222fc7bfe198eda77bdc427d5ac189 https://git.kernel.org/stable/c/04226d8e3c4028dc451e9d8777356ec0f7919253 https://git.kernel.org/stable/c/9f0c4a46be1fe9b97dbe66d49204c1371e3ece65 •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26868 – nfs: fix panic when nfs4_ff_layout_prepare_ds() fails
https://notcve.org/view.php?id=CVE-2024-26868
In the Linux kernel, the following vulnerability has been resolved: nfs: fix panic when nfs4_ff_layout_prepare_ds() fails We've been seeing the following panic in production BUG: kernel NULL pointer dereference, address: 0000000000000065 PGD 2f485f067 P4D 2f485f067 PUD 2cc5d8067 PMD 0 RIP: 0010:ff_layout_cancel_io+0x3a/0x90 [nfs_layout_flexfiles] Call Trace: <TASK> ? __die+0x78/0xc0 ? page_fault_oops+0x286/0x380 ? __rpc_execute+0x2c3/0x470 [sunrpc] ? rpc_new_task+0x42/0x1c0 [sunrpc] ? • https://git.kernel.org/stable/c/b739a5bd9d9f18cc69dced8db128ef7206e000cd https://git.kernel.org/stable/c/31db25e3141b20e2a76a9f219eeca52e3cab126c https://git.kernel.org/stable/c/7ca651b4ec4a049f5a46a0e5ff921b86b91c47c5 https://git.kernel.org/stable/c/5ada9016b1217498fad876a3d5b07645cc955608 https://git.kernel.org/stable/c/dac068f164ad05b35e7c0be13f138c3f6adca58f https://git.kernel.org/stable/c/719fcafe07c12646691bd62d7f8d94d657fa0766 https://access.redhat.com/security/cve/CVE-2024-26868 https://bugzilla.redhat.com/show_bug.cgi?id=2275715 • CWE-476: NULL Pointer Dereference •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-26867 – comedi: comedi_8255: Correct error in subdevice initialization
https://notcve.org/view.php?id=CVE-2024-26867
In the Linux kernel, the following vulnerability has been resolved: comedi: comedi_8255: Correct error in subdevice initialization The refactoring done in commit 5c57b1ccecc7 ("comedi: comedi_8255: Rework subdevice initialization functions") to the initialization of the io field of struct subdev_8255_private broke all cards using the drivers/comedi/drivers/comedi_8255.c module. Prior to 5c57b1ccecc7, __subdev_8255_init() initialized the io field in the newly allocated struct subdev_8255_private to the non-NULL callback given to the function, otherwise it used a flag parameter to select between subdev_8255_mmio and subdev_8255_io. The refactoring removed that logic and the flag, as subdev_8255_mm_init() and subdev_8255_io_init() now explicitly pass subdev_8255_mmio and subdev_8255_io respectively to __subdev_8255_init(), only __subdev_8255_init() never sets spriv->io to the supplied callback. That spriv->io is NULL leads to a later BUG: BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0010 [#1] SMP PTI CPU: 1 PID: 1210 Comm: systemd-udevd Not tainted 6.7.3-x86_64 #1 Hardware name: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 0018:ffffa3f1c02d7b78 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff91f847aefd00 RCX: 000000000000009b RDX: 0000000000000003 RSI: 0000000000000001 RDI: ffff91f840f6fc00 RBP: ffff91f840f6fc00 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 000000000000005f R12: 0000000000000000 R13: 0000000000000000 R14: ffffffffc0102498 R15: ffff91f847ce6ba8 FS: 00007f72f4e8f500(0000) GS:ffff91f8d5c80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 000000010540e000 CR4: 00000000000406f0 Call Trace: <TASK> ? __die_body+0x15/0x57 ? page_fault_oops+0x2ef/0x33c ? • https://git.kernel.org/stable/c/5c57b1ccecc72738d4b9be2dfcdfb9001be76bd7 https://git.kernel.org/stable/c/4a825457a45d8debc46ab8cba57d47462411710d https://git.kernel.org/stable/c/cfa9ba1ae0bef0681833a22d326174fe633caab5 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26866 – spi: lpspi: Avoid potential use-after-free in probe()
https://notcve.org/view.php?id=CVE-2024-26866
In the Linux kernel, the following vulnerability has been resolved: spi: lpspi: Avoid potential use-after-free in probe() fsl_lpspi_probe() is allocating/disposing memory manually with spi_alloc_host()/spi_alloc_target(), but uses devm_spi_register_controller(). In case of error after the latter call the memory will be explicitly freed in the probe function by spi_controller_put() call, but used afterwards by "devm" management outside probe() (spi_unregister_controller() <- devm_spi_unregister() below). Unable to handle kernel NULL pointer dereference at virtual address 0000000000000070 ... Call trace: kernfs_find_ns kernfs_find_and_get_ns sysfs_remove_group sysfs_remove_groups device_remove_attrs device_del spi_unregister_controller devm_spi_unregister release_nodes devres_release_all really_probe driver_probe_device __device_attach_driver bus_for_each_drv __device_attach device_initial_probe bus_probe_device deferred_probe_work_func process_one_work worker_thread kthread ret_from_fork En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: lpspi: evita el posible use-after-free en probe() fsl_lpspi_probe() está asignando/eliminando memoria manualmente con spi_alloc_host()/spi_alloc_target(), pero usa devm_spi_register_controller() . En caso de error después de la última llamada, la memoria se liberará explícitamente en la función de sonda mediante la llamada a spi_controller_put(), pero la administración "devm" externa a probe() la utilizará después (spi_unregister_controller() <- devm_spi_unregister() a continuación). No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000070... Rastreo de llamadas: kernfs_find_ns kernfs_find_and_get_ns sysfs_remove_group sysfs_remove_groups device_remove_attrs device_del spi_unregister_controller devm_spi_unregister release_nodes devres_release _todos realmente_probe driver_probe_device __device_attach_driver bus_for_each_drv __device_attach dispositivo_initial_probe bus_probe_device deferred_probe_work_func proceso_one_work trabajador_hilo kthread ret_from_fork • https://git.kernel.org/stable/c/5314987de5e5f5e38436ef4a69328bc472bbd63e https://git.kernel.org/stable/c/da83ed350e4604b976e94239b08d8e2e7eaee7ea https://git.kernel.org/stable/c/1543418e82789cc383cd36d41469983c64e3fc7f https://git.kernel.org/stable/c/996ce839606afd0fef91355627868022aa73eb68 https://git.kernel.org/stable/c/2ae0ab0143fcc06190713ed81a6486ed0ad3c861 •