Page 155 of 3067 results (0.030 seconds)

CVSS: 5.3EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: sysv: don't call sb_bread() with pointers_lock held syzbot is reporting sleep in atomic context in SysV filesystem [1], for sb_bread() is called with rw_spinlock held. A "write_lock(&pointers_lock) => read_lock(&pointers_lock) deadlock" bug and a "sb_bread() with write_lock(&pointers_lock)" bug were introduced by "Replace BKL for chain locking with sysvfs-private rwlock" in Linux 2.5.12. Then, "[PATCH] err1-40: sysvfs locking fix" in Linux 2.6.8 fixed the former bug by moving pointers_lock lock to the callers, but instead introduced a "sb_bread() with read_lock(&pointers_lock)" bug (which made this problem easier to hit). Al Viro suggested that why not to do like get_branch()/get_block()/ find_shared() in Minix filesystem does. And doing like that is almost a revert of "[PATCH] err1-40: sysvfs locking fix" except that get_branch() from with find_shared() is called without write_lock(&pointers_lock). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sysv: no llame a sb_bread() con pointers_lock retenido syzbot informa suspensión en contexto atómico en el sistema de archivos SysV [1], porque sb_bread() se llama con rw_spinlock retenido. Un error "write_lock(&pointers_lock) => read_lock(&pointers_lock) deadlock" y un error "sb_bread() with write_lock(&pointers_lock)" fueron introducidos por "Reemplazar BKL para bloqueo de cadena con sysvfs-private rwlock" en Linux 2.5.12. Luego, "[PATCH] err1-40: corrección de bloqueo de sysvfs" en Linux 2.6.8 solucionó el error anterior moviendo el bloqueo pointers_lock a las personas que llaman, pero en su lugar introdujo un error "sb_bread() con read_lock(&pointers_lock)" (que hizo que esto problema más fácil de abordar). • https://git.kernel.org/stable/c/13b33feb2ebddc2b1aa607f553566b18a4af1d76 https://git.kernel.org/stable/c/1b4fe801b5bedec2b622ddb18e5c9bf26c63d79f https://git.kernel.org/stable/c/674c1c4229e743070e09db63a23442950ff000d1 https://git.kernel.org/stable/c/fd203d2c671bdee9ab77090ff394d3b71b627927 https://git.kernel.org/stable/c/53cb1e52c9db618c08335984d1ca80db220ccf09 https://git.kernel.org/stable/c/89e8524135a3902e7563a5a59b7b5ec1bf4904ac https://git.kernel.org/stable/c/a69224223746ab96d43e5db9d22d136827b7e2d3 https://git.kernel.org/stable/c/f123dc86388cb669c3d6322702dc441ab •

CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: netfilter: validate user input for expected length I got multiple syzbot reports showing old bugs exposed by BPF after commit 20f2505fb436 ("bpf: Try to avoid kzalloc in cgroup/{s,g}etsockopt") setsockopt() @optlen argument should be taken into account before copying data. BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline] BUG: KASAN: slab-out-of-bounds in do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627 Read of size 96 at addr ffff88802cd73da0 by task syz-executor.4/7238 CPU: 1 PID: 7238 Comm: syz-executor.4 Not tainted 6.9.0-rc2-next-20240403-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105 copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] copy_from_sockptr include/linux/sockptr.h:55 [inline] do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline] do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627 nf_setsockopt+0x295/0x2c0 net/netfilter/nf_sockopt.c:101 do_sock_setsockopt+0x3af/0x720 net/socket.c:2311 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x72/0x7a RIP: 0033:0x7fd22067dde9 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:00007fd21f9ff0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036 RAX: ffffffffffffffda RBX: 00007fd2207abf80 RCX: 00007fd22067dde9 RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007fd2206ca47a R08: 0000000000000001 R09: 0000000000000000 R10: 0000000020000880 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007fd2207abf80 R15: 00007ffd2d0170d8 </TASK> Allocated by task 7238: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:370 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387 kasan_kmalloc include/linux/kasan.h:211 [inline] __do_kmalloc_node mm/slub.c:4069 [inline] __kmalloc_noprof+0x200/0x410 mm/slub.c:4082 kmalloc_noprof include/linux/slab.h:664 [inline] __cgroup_bpf_run_filter_setsockopt+0xd47/0x1050 kernel/bpf/cgroup.c:1869 do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x72/0x7a The buggy address belongs to the object at ffff88802cd73da0 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes inside of allocated 1-byte region [ffff88802cd73da0, ffff88802cd73da1) The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88802cd73020 pfn:0x2cd73 flags: 0xfff80000000000(node=0|zone=1|lastcpupid=0xfff) page_type: 0xffffefff(slab) raw: 00fff80000000000 ffff888015041280 dead000000000100 dead000000000122 raw: ffff88802cd73020 000000008080007f 00000001ffffefff 00 ---truncated--- En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: validar la entrada del usuario para la longitud esperada. Recibí varios informes de syzbot que muestran errores antiguos expuestos por BPF después de la confirmación 20f2505fb436 ("bpf: intente evitar kzalloc en cgroup/{s,g} etsockopt") setsockopt() El argumento @optlen debe tenerse en cuenta antes de copiar datos. ERROR: KASAN: losa fuera de límites en copy_from_sockptr_offset include/linux/sockptr.h:49 [en línea] ERROR: KASAN: losa fuera de límites en copy_from_sockptr include/linux/sockptr.h:55 [en línea] ERROR: KASAN: losa fuera de los límites en do_replace net/ipv4/netfilter/ip_tables.c:1111 [en línea] ERROR: KASAN: losa fuera de los límites en do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ ip_tables.c:1627 Lectura del tamaño 96 en la dirección ffff88802cd73da0 mediante la tarea syz-executor.4/7238 CPU: 1 PID: 7238 Comm: syz-executor.4 No contaminado 6.9.0-rc2-next-20240403-syzkaller #0 Hardware nombre: Google Google Compute Engine/Google Compute Engine, BIOS Google 27/03/2024 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm/ kasan/report.c:377 [en línea] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c :189 __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105 copy_from_sockptr_offset include/linux/sockptr.h:49 [en línea] copy_from_sockptr include/linux/sockptr.h:55 [en línea] do_replace net/ipv4/netfilter/ip_tables .c:1111 [en línea] do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627 nf_setsockopt+0x295/0x2c0 net/netfilter/nf_sockopt.c:101 do_sock_setsockopt+0x3af/0x720 net/socket.c:2 311 __sys_setsockopt +0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [en línea] __se_sys_setsockopt net/socket.c:2340 [en línea] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 +0xfb/0x240 Entry_SYSCALL_64_after_hwframe+0x72/0x7a RIP: 0033:0x7fd22067dde9 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 48 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:00007fd21f9ff0c8 EFLAGS: 00000246 ORIG_RAX: 00000000000 00036 RAX: ffffffffffffffda RBX: 00007fd2207abf80 RCX: 00007fd22067dde9 RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007fd2206ca47a R08: 0000000000000001 R09: 0000000000000000 R10: 0000000020000880 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007fd2207abf80 R15: 00007ffd2d0170d8 Asignado por la tarea 7238: kasan_save_stack mm/kasan/common. c:47 [en línea] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:370 [en línea] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387 kasan_kmalloc include/ linux/kasan.h: 211 [en línea] __do_kmalloc_node mm/slub.c: 4069 [inline] __kmalloc_noprof+0x200/0x410 mm/slub.c: 4082 kmalloc_noproof include/linux/slab.h: 664 [inline] __cgraGrempf_filup 47/ 0x1050 kernel/bpf/cgroup.c:1869 do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 __se_sys _setsockopt net/socket. c:2340 [en línea] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 Entry_SYSCALL_64_after_hwframe+0x72/0x7a La dirección con errores pertenece al objeto en ffff88802cd73da0 que pertenece al caché kmalloc-8 de talla 8 el cochecito La dirección se encuentra a 0 bytes dentro de la región asignada de 1 byte [ffff88802cd73da0, ffff88802cd73da1) La dirección con errores pertenece a la página física: página: refcount:1 mapcount:0 mapeo:00000000000000000 index:0xffff88802cd73020 pfn:0x2cd73 flags: 0xfff8000000 0000(nodo=0 |zone=1|lastcpupid=0xfff) tipo de página: 0xfffffff(slab) raw: 00fff80000000000 ffff888015041280 dead000000000100 dead000000000122 raw: ffff88802cd73020 000000008080007f 00000001ffffefff 00 • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/0f038242b77ddfc505bf4163d4904c1abd2e74d6 https://git.kernel.org/stable/c/440e948cf0eff32cfe322dcbca3f2525354b159b https://git.kernel.org/stable/c/18aae2cb87e5faa9c5bd865260ceadac60d5a6c5 https://git.kernel.org/stable/c/81d51b9b7c95e791ba3c1a2dd77920a9d3b3f525 https://git.kernel.org/stable/c/58f2bfb789e6bd3bc24a2c9c1580f3c67aec3018 https://git.kernel.org/stable/c/0c83842df40f86e529db6842231154772c20edcc https://lists.debian.org/debian-lts-announce/2024/06/ •

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

In the Linux kernel, the following vulnerability has been resolved: ax25: fix use-after-free bugs caused by ax25_ds_del_timer When the ax25 device is detaching, the ax25_dev_device_down() calls ax25_ds_del_timer() to cleanup the slave_timer. When the timer handler is running, the ax25_ds_del_timer() that calls del_timer() in it will return directly. As a result, the use-after-free bugs could happen, one of the scenarios is shown below: (Thread 1) | (Thread 2) | ax25_ds_timeout() ax25_dev_device_down() | ax25_ds_del_timer() | del_timer() | ax25_dev_put() //FREE | | ax25_dev-> //USE In order to mitigate bugs, when the device is detaching, use timer_shutdown_sync() to stop the timer. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ax25: corrige errores de use after free causados por ax25_ds_del_timer Cuando el dispositivo ax25 se está desconectando, ax25_dev_device_down() llama a ax25_ds_del_timer() para limpiar el Slave_timer. Cuando el controlador del temporizador se está ejecutando, el ax25_ds_del_timer() que llama a del_timer() regresará directamente. • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/74204bf9050f7627aead9875fe4e07ba125cb19b https://git.kernel.org/stable/c/c6a368f9c7af4c14b14d390c2543af8001c9bdb9 https://git.kernel.org/stable/c/fd819ad3ecf6f3c232a06b27423ce9ed8c20da89 •

CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix infinite recursion in fib6_dump_done(). syzkaller reported infinite recursive calls of fib6_dump_done() during netlink socket destruction. [1] From the log, syzkaller sent an AF_UNSPEC RTM_GETROUTE message, and then the response was generated. The following recvmmsg() resumed the dump for IPv6, but the first call of inet6_dump_fib() failed at kzalloc() due to the fault injection. • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/9472d07cd095cbd3294ac54c42f304a38fbe9bfe https://git.kernel.org/stable/c/9c5258196182c25b55c33167cd72fdd9bbf08985 https://git.kernel.org/stable/c/fd307f2d91d40fa7bc55df3e2cd1253fabf8a2d6 https://git.kernel.org/stable/c/40a344b2ddc06c1a2caa7208a43911f39c662778 https://git.kernel.org/stable/c/167d4b47a9bdcb01541dfa29e9f3cbb8edd3dfd2 https://git.kernel.org/stable/c/f2dd75e57285f49e34af1a5b6cd8945c08243776 https://git.kernel.org/stable/c/4a7c465a5dcd657d59d25bf4815e19ac0 •

CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: of: module: prevent NULL pointer dereference in vsnprintf() In of_modalias(), we can get passed the str and len parameters which would cause a kernel oops in vsnprintf() since it only allows passing a NULL ptr when the length is also 0. Also, we need to filter out the negative values of the len parameter as these will result in a really huge buffer since snprintf() takes size_t parameter while ours is ssize_t... Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: de: módulo: evita la desreferencia del puntero NULL en vsnprintf() En of_modalias(), podemos pasar los parámetros str y len que provocarían un kernel ups en vsnprintf() ya que solo permite pasar un ptr NULL cuando la longitud también es 0. Además, necesitamos filtrar los valores negativos del parámetro len ya que estos darán como resultado un búfer realmente enorme ya que snprintf() toma el parámetro size_t mientras que el nuestro es ssize_t... Encontrado por el Centro de verificación de Linux (linuxtesting.org) con la herramienta de análisis estático Svace. • https://git.kernel.org/stable/c/e4a449368a2ce6d57a775d0ead27fc07f5a86e5b https://git.kernel.org/stable/c/544561dc56f7e69a053c25e11e6170f48bb97898 https://git.kernel.org/stable/c/a1aa5390cc912934fee76ce80af5f940452fa987 https://access.redhat.com/security/cve/CVE-2024-35878 https://bugzilla.redhat.com/show_bug.cgi?id=2281718 • CWE-476: NULL Pointer Dereference •