Page 299 of 2226 results (0.031 seconds)

CVSS: -EPSS: 0%CPEs: 4EXPL: 0

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: 0

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: 4EXPL: 0

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() &lt;- 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 •

CVSS: -EPSS: 0%CPEs: 5EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: rds: tcp: Fix use-after-free of net in reqsk_timer_handler(). syzkaller reported a warning of netns tracker [0] followed by KASAN splat [1] and another ref tracker warning [1]. syzkaller could not find a repro, but in the log, the only suspicious sequence was as follows: 18:26:22 executing program 1: r0 = socket$inet6_mptcp(0xa, 0x1, 0x106) ... connect$inet6(r0, &(0x7f0000000080)={0xa, 0x4001, 0x0, @loopback}, 0x1c) (async) The notable thing here is 0x4001 in connect(), which is RDS_TCP_PORT. So, the scenario would be: 1. unshare(CLONE_NEWNET) creates a per netns tcp listener in rds_tcp_listen_init(). 2. syz-executor connect()s to it and creates a reqsk. 3. syz-executor exit()s immediately. 4. netns is dismantled. [0] 5. reqsk timer is fired, and UAF happens while freeing reqsk. [1] 6. listener is freed after RCU grace period • https://git.kernel.org/stable/c/467fa15356acfb7b2efa38839c3e76caa4e6e0ea https://git.kernel.org/stable/c/9905a157048f441f1412e7bd13372f4a971d75c6 https://git.kernel.org/stable/c/f901ee07853ce97e9f1104c7c898fbbe447f0279 https://git.kernel.org/stable/c/9ceac040506a05a30b104b2aa2e9146810704500 https://git.kernel.org/stable/c/1e9fd5cf8d7f487332560f7bb312fc7d416817f3 https://git.kernel.org/stable/c/2a750d6a5b365265dbda33330a6188547ddb5c24 •

CVSS: 5.9EPSS: 0%CPEs: 5EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: tcp: Fix refcnt handling in __inet_hash_connect(). syzbot reported a warning in sk_nulls_del_node_init_rcu(). The commit 66b60b0c8c4a ("dccp/tcp: Unhash sk from ehash for tb2 alloc failure after check_estalblished().") tried to fix an issue that an unconnected socket occupies an ehash entry when bhash2 allocation fails. In such a case, we need to revert changes done by check_established(), which does not hold refcnt when inserting socket into ehash. So, to revert the change, we need to __sk_nulls_add_node_rcu() instead of sk_nulls_add_node_rcu(). Otherwise, sock_put() will cause refcnt underflow and leak the socket. [0]: WARNING: CPU: 0 PID: 23948 at include/net/sock.h:799 sk_nulls_del_node_init_rcu+0x166/0x1a0 include/net/sock.h:799 Modules linked in: CPU: 0 PID: 23948 Comm: syz-executor.2 Not tainted 6.8.0-rc6-syzkaller-00159-gc055fc00c07b #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 RIP: 0010:sk_nulls_del_node_init_rcu+0x166/0x1a0 include/net/sock.h:799 Code: e8 7f 71 c6 f7 83 fb 02 7c 25 e8 35 6d c6 f7 4d 85 f6 0f 95 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 1b 6d c6 f7 90 <0f> 0b 90 eb b2 e8 10 6d c6 f7 4c 89 e7 be 04 00 00 00 e8 63 e7 d2 RSP: 0018:ffffc900032d7848 EFLAGS: 00010246 RAX: ffffffff89cd0035 RBX: 0000000000000001 RCX: 0000000000040000 RDX: ffffc90004de1000 RSI: 000000000003ffff RDI: 0000000000040000 RBP: 1ffff1100439ac26 R08: ffffffff89ccffe3 R09: 1ffff1100439ac28 R10: dffffc0000000000 R11: ffffed100439ac29 R12: ffff888021cd6140 R13: dffffc0000000000 R14: ffff88802a9bf5c0 R15: ffff888021cd6130 FS: 00007f3b823f16c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f3b823f0ff8 CR3: 000000004674a000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __inet_hash_connect+0x140f/0x20b0 net/ipv4/inet_hashtables.c:1139 dccp_v6_connect+0xcb9/0x1480 net/dccp/ipv6.c:956 __inet_stream_connect+0x262/0xf30 net/ipv4/af_inet.c:678 inet_stream_connect+0x65/0xa0 net/ipv4/af_inet.c:749 __sys_connect_file net/socket.c:2048 [inline] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7f3b8167dda9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 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 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f3b823f10c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 00007f3b817abf80 RCX: 00007f3b8167dda9 RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003 RBP: 00007f3b823f1120 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 000000000000000b R14: 00007f3b817abf80 R15: 00007ffd3beb57b8 </TASK> En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: corrige el manejo de refcnt en __inet_hash_connect(). syzbot informó una advertencia en sk_nulls_del_node_init_rcu(). La confirmación 66b60b0c8c4a ("dccp/tcp: Unhash sk de ehash para falla de asignación de tb2 después de check_estalblished().") intentó solucionar un problema por el cual un socket no conectado ocupa una entrada de ehash cuando falla la asignación de bhash2. En tal caso, necesitamos revertir los cambios realizados por check_establecido(), que no retiene refcnt al insertar el socket en ehash. Entonces, para revertir el cambio, necesitamos __sk_nulls_add_node_rcu() en lugar de sk_nulls_add_node_rcu(). De lo contrario, sock_put() provocará un desbordamiento insuficiente y filtrará el socket. [0]: ADVERTENCIA: CPU: 0 PID: 23948 en include/net/sock.h:799 sk_nulls_del_node_init_rcu+0x166/0x1a0 include/net/sock.h:799 Módulos vinculados en: CPU: 0 PID: 23948 Comm: syz- executor.2 No contaminado 6.8.0-rc6-syzkaller-00159-gc055fc00c07b #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 25/01/2024 RIP: 0010:sk_nulls_del_node_init_rcu+0x166/0x1a0 include/net/ calcetín.h:799 Código: e8 7f 71 c6 f7 83 fb 02 7c 25 e8 35 6d c6 f7 4d 85 f6 0f 95 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 1b 6d c6 f7 90 &lt; 0f&gt; 0b 90 eb b2 e8 10 6d c6 f7 4c 89 e7 be 04 00 00 00 e8 63 e7 d2 RSP: 0018:ffffc900032d7848 EFLAGS: 00010246 RAX: ffffffff89cd0035 RBX: 00001 RCX: 0000000000040000 RDX: ffffc90004de1000 RSI: 000000000003ffff RDI: 0000000000040000 RBP : 1ffff1100439ac26 R08: ffffffff89ccffe3 R09: 1ffff1100439ac28 R10: dffffc0000000000 R11: ffffed100439ac29 R12: ffff888021cd6140 R13: dffffc0000000000 ff ff88802a9bf5c0 R15: ffff888021cd6130 FS: 00007f3b823f16c0(0000) GS:ffff8880b9400000(0000) knlGS:00000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f3b823f0ff8 CR3: 000000004674a000 CR4: 00000000003506f0 DR0: 00000000000000000 DR1: 0000000000000000 DR2: 000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: __inet_hash_connect+0x140f/0x20b0 net/ipv4/inet_hashtables.c:1139 dccp_v6_connect+0xcb9/0x1480 net/dccp/ipv6.c:956 __inet_stream_connect+0x262/0xf30 net/ipv4/af_inet.c:678 inet_stream_connect+0x65/0xa0 net/ipv4/af_inet.c:749 __sys_connect_file net/socket.c:2048 [en línea] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [en línea] __se_sys_connect net/socket.c:2072 [en línea] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 +0xf9/0x240 Entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7f3b8167dda9 Código: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 4 8 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f3b823f10c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 00007f3b817abf80 RCX : 00007f3b8167dda9 RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003 RBP: 00007f3b823f1120 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000000000b R14: 00007f3b817abf80 00007ffd3beb57b8 • https://git.kernel.org/stable/c/729bc77af438a6e67914c97f6f3d3af8f72c0131 https://git.kernel.org/stable/c/334a8348b2df26526f3298848ad6864285592caf https://git.kernel.org/stable/c/f8c4a6b850882bc47aaa864b720c7a2ee3102f39 https://git.kernel.org/stable/c/66b60b0c8c4a163b022a9f0ad6769b0fd3dc662f https://git.kernel.org/stable/c/86d9b040421bbd26425f5a3edc226f57ecdecbfe https://git.kernel.org/stable/c/856baaa100cd288d3685eedae9a129c996e7e755 https://git.kernel.org/stable/c/1b20e61d36f490319d3fbdedd410155232ab5190 https://git.kernel.org/stable/c/ad105cde6b261b8b05ec872fe7d198741 • CWE-200: Exposure of Sensitive Information to an Unauthorized Actor •