Page 269 of 4824 results (0.011 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails Calling a6xx_destroy() before adreno_gpu_init() leads to a null pointer dereference on: msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL); as gpu->pdev is only assigned in: a6xx_gpu_init() |_ adreno_gpu_init |_ msm_gpu_init() Instead of relying on handwavy null checks down the cleanup chain, explicitly de-allocate the LLC data and free a6xx_gpu instead. Patchwork: https://patchwork.freedesktop.org/patch/588919/ • https://git.kernel.org/stable/c/76efc2453d0e8e5d6692ef69981b183ad674edea https://git.kernel.org/stable/c/5fea4202b5faccfc6449381a299e8ce4b994d666 https://git.kernel.org/stable/c/247849eeb3fd88f8990ed73e33af70d5c10f9aec https://git.kernel.org/stable/c/a1955a6df91355fef72a3a254700acd3cc1fec0d https://git.kernel.org/stable/c/617e3d1680504a3f9d88e1582892c68be155498f https://git.kernel.org/stable/c/46d4efcccc688cbacdd70a238bedca510acaa8e4 •

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

In the Linux kernel, the following vulnerability has been resolved: ALSA: hda/cs_dsp_ctl: Use private_free for control cleanup Use the control private_free callback to free the associated data block. This ensures that the memory won't leak, whatever way the control gets destroyed. The original implementation didn't actually remove the ALSA controls in hda_cs_dsp_control_remove(). It only freed the internal tracking structure. This meant it was possible to remove/unload the amp driver while leaving its ALSA controls still present in the soundcard. Obviously attempting to access them could cause segfaults or at least dereferencing stale pointers. • https://git.kernel.org/stable/c/3233b978af23f11b4ad4f7f11a9a64bd05702b1f https://git.kernel.org/stable/c/191dc1b2ff0fb35e7aff15a53224837637df8bff https://git.kernel.org/stable/c/6e359be4975006ff72818e79dad8fe48293f2eb2 https://git.kernel.org/stable/c/3291486af5636540980ea55bae985f3eaa5b0740 https://git.kernel.org/stable/c/172811e3a557d8681a5e2d0f871dc04a2d17eb13 •

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

In the Linux kernel, the following vulnerability has been resolved: nfc: nci: Fix uninit-value in nci_rx_work syzbot reported the following uninit-value access issue [1] nci_rx_work() parses received packet from ndev->rx_q. It should be validated header size, payload size and total packet size before processing the packet. If an invalid packet is detected, it should be silently discarded. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nfc: nci: corrigió el valor uninit en nci_rx_work syzbot informó el siguiente problema de acceso al valor uninit [1] nci_rx_work() analiza el paquete recibido de ndev->rx_q. Se debe validar el tamaño del encabezado, el tamaño del payload y el tamaño total del paquete antes de procesar el paquete. • https://git.kernel.org/stable/c/11387b2effbb55f58dc2111ef4b4b896f2756240 https://git.kernel.org/stable/c/03fe259649a551d336a7f20919b641ea100e3fff https://git.kernel.org/stable/c/755e53bbc61bc1aff90eafa64c8c2464fd3dfa3c https://git.kernel.org/stable/c/ac68d9fa09e410fa3ed20fb721d56aa558695e16 https://git.kernel.org/stable/c/b51ec7fc9f877ef869c01d3ea6f18f6a64e831a7 https://git.kernel.org/stable/c/a946ebee45b09294c8b0b0e77410b763c4d2817a https://git.kernel.org/stable/c/d24b03535e5eb82e025219c2f632b485409c898f https://git.kernel.org/stable/c/8948e30de81faee87eeee01ef42a1f600 •

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

In the Linux kernel, the following vulnerability has been resolved: tcp: Fix shift-out-of-bounds in dctcp_update_alpha(). In dctcp_update_alpha(), we use a module parameter dctcp_shift_g as follows: alpha -= min_not_zero(alpha, alpha >> dctcp_shift_g); ... delivered_ce <<= (10 - dctcp_shift_g); It seems syzkaller started fuzzing module parameters and triggered shift-out-of-bounds [0] by setting 100 to dctcp_shift_g: memcpy((void*)0x20000080, "/sys/module/tcp_dctcp/parameters/dctcp_shift_g\000", 47); res = syscall(__NR_openat, /*fd=*/0xffffffffffffff9cul, /*file=*/0x20000080ul, /*flags=*/2ul, /*mode=*/0ul); memcpy((void*)0x20000000, "100\000", 4); syscall(__NR_write, /*fd=*/r[0], /*val=*/0x20000000ul, /*len=*/4ul); Let's limit the max value of dctcp_shift_g by param_set_uint_minmax(). With this patch: # echo 10 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g # cat /sys/module/tcp_dctcp/parameters/dctcp_shift_g 10 # echo 11 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g -bash: echo: write error: Invalid argument [0]: UBSAN: shift-out-of-bounds in net/ipv4/tcp_dctcp.c:143:12 shift exponent 100 is too large for 32-bit type 'u32' (aka 'unsigned int') CPU: 0 PID: 8083 Comm: syz-executor345 Not tainted 6.9.0-05151-g1b294a1f3561 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x201/0x300 lib/dump_stack.c:114 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_shift_out_of_bounds+0x346/0x3a0 lib/ubsan.c:468 dctcp_update_alpha+0x540/0x570 net/ipv4/tcp_dctcp.c:143 tcp_in_ack_event net/ipv4/tcp_input.c:3802 [inline] tcp_ack+0x17b1/0x3bc0 net/ipv4/tcp_input.c:3948 tcp_rcv_state_process+0x57a/0x2290 net/ipv4/tcp_input.c:6711 tcp_v4_do_rcv+0x764/0xc40 net/ipv4/tcp_ipv4.c:1937 sk_backlog_rcv include/net/sock.h:1106 [inline] __release_sock+0x20f/0x350 net/core/sock.c:2983 release_sock+0x61/0x1f0 net/core/sock.c:3549 mptcp_subflow_shutdown+0x3d0/0x620 net/mptcp/protocol.c:2907 mptcp_check_send_data_fin+0x225/0x410 net/mptcp/protocol.c:2976 __mptcp_close+0x238/0xad0 net/mptcp/protocol.c:3072 mptcp_close+0x2a/0x1a0 net/mptcp/protocol.c:3127 inet_release+0x190/0x1f0 net/ipv4/af_inet.c:437 __sock_release net/socket.c:659 [inline] sock_close+0xc0/0x240 net/socket.c:1421 __fput+0x41b/0x890 fs/file_table.c:422 task_work_run+0x23b/0x300 kernel/task_work.c:180 exit_task_work include/linux/task_work.h:38 [inline] do_exit+0x9c8/0x2540 kernel/exit.c:878 do_group_exit+0x201/0x2b0 kernel/exit.c:1027 __do_sys_exit_group kernel/exit.c:1038 [inline] __se_sys_exit_group kernel/exit.c:1036 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1036 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xe4/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x67/0x6f RIP: 0033:0x7f6c2b5005b6 Code: Unable to access opcode bytes at 0x7f6c2b50058c. RSP: 002b:00007ffe883eb948 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 00007f6c2b5862f0 RCX: 00007f6c2b5005b6 RDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001 RBP: 0000000000000001 R08: 00000000000000e7 R09: ffffffffffffffc0 R10: 0000000000000006 R11: 0000000000000246 R12: 00007f6c2b5862f0 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001 </TASK> En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: corrige el desplazamiento fuera de los límites en dctcp_update_alpha(). En dctcp_update_alpha(), utilizamos un parámetro de módulo dctcp_shift_g de la siguiente manera: alpha -= min_not_zero(alpha, alpha &gt;&gt; dctcp_shift_g); ... entregado_ce &lt;&lt;= (10 - dctcp_shift_g); Parece que syzkaller comenzó a modificar los parámetros del módulo y activó el desplazamiento fuera de los límites [0] estableciendo 100 en dctcp_shift_g: memcpy((void*)0x20000080, "/sys/module/tcp_dctcp/parameters/dctcp_shift_g\000", 47) ; res = syscall(__NR_openat, /*fd=*/0xffffffffffffff9cul, /*file=*/0x20000080ul, /*flags=*/2ul, /*mode=*/0ul); memcpy((void*)0x20000000, "100\000", 4); syscall(__NR_write, /*fd=*/r[0], /*val=*/0x20000000ul, /*len=*/4ul); Limitemos el valor máximo de dctcp_shift_g mediante param_set_uint_minmax(). Con este parche: # echo 10 &gt; /sys/module/tcp_dctcp/parameters/dctcp_shift_g # cat /sys/module/tcp_dctcp/parameters/dctcp_shift_g 10 # echo 11 &gt; /sys/module/tcp_dctcp/parameters/dctcp_shift_g -bash: echo: error de escritura: argumento no válido [0]: UBSAN: desplazamiento fuera de los límites en net/ipv4/tcp_dctcp.c:143:12 el exponente de desplazamiento 100 es demasiado grande para el tipo 'u32' de 32 bits (también conocido como 'int sin signo' ) CPU: 0 PID: 8083 Comm: syz-executor345 No contaminado 6.9.0-05151-g1b294a1f3561 #2 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 01/04/2014 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x201/0x300 lib/dump_stack.c:114 ubsan_epilogue lib/ubsan.c:231 [en línea] __ubsan_handle_shift_out_of_bounds+0x346/0x3a0 lib/ubsan.c :468 dctcp_update_alpha+0x540/0x570 net/ipv4/tcp_dctcp.c:143 tcp_in_ack_event net/ipv4/tcp_input.c:3802 [en línea] tcp_ack+0x17b1/0x3bc0 net/ipv4/tcp_input.c:3948 v_state_process+0x57a/0x2290 neto/ ipv4/tcp_input.c:6711 tcp_v4_do_rcv+0x764/0xc40 net/ipv4/tcp_ipv4.c:1937 sk_backlog_rcv include/net/sock.h:1106 [en línea] __release_sock+0x20f/0x350 net/core/sock.c:2983 release_sock+ 0x61/0x1f0 net/core/sock.c:3549 mptcp_subflow_shutdown+0x3d0/0x620 net/mptcp/protocol.c:2907 mptcp_check_send_data_fin+0x225/0x410 net/mptcp/protocol.c:2976 __mptcp_close+0x238/0x ad0 net/mptcp/protocolo .c:3072 mptcp_close+0x2a/0x1a0 net/mptcp/protocol.c:3127 inet_release+0x190/0x1f0 net/ipv4/af_inet.c:437 __sock_release net/socket.c:659 [en línea] sock_close+0xc0/0x240 net/ socket.c:1421 __fput+0x41b/0x890 fs/file_table.c:422 task_work_run+0x23b/0x300 kernel/task_work.c:180 exit_task_work include/linux/task_work.h:38 [en línea] do_exit+0x9c8/0x2540 kernel/exit .c:878 do_group_exit+0x201/0x2b0 kernel/exit.c:1027 __do_sys_exit_group kernel/exit.c:1038 [en línea] __se_sys_exit_group kernel/exit.c:1036 [en línea] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:10 36 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xe4/0x240 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x67/0x6f RIP: 0033:0x7f6c2b5005b6 Código: no se puede acceder a los bytes del código de operación en 0x7f6c2b50058c . RSP: 002b:00007ffe883eb948 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 00007f6c2b5862f0 RCX: 00007f6c2b5005b6 RDX: 0000000001 RSI: 000000000000003c RDI: 0000000000000001 RBP: 0000000000000001 R08: 00000000000000e7 R09: ffffffffffffffc0 R10: 06 R11: 0000000000000246 R12: 00007f6c2b5862f0 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001 • https://git.kernel.org/stable/c/e3118e8359bb7c59555aca60c725106e6d78c5ce https://git.kernel.org/stable/c/06d0fe049b51b0a92a70df8333fd85c4ba3eb2c6 https://git.kernel.org/stable/c/6aacaa80d962f4916ccf90e2080306cec6c90fcf https://git.kernel.org/stable/c/e9b2f60636d18dfd0dd4965b3316f88dfd6a2b31 https://git.kernel.org/stable/c/8602150286a2a860a1dc55cbd04f99316f19b40a https://git.kernel.org/stable/c/e65d13ec00a738fa7661925fd5929ab3c765d4be https://git.kernel.org/stable/c/02261d3f9dc7d1d7be7d778f839e3404ab99034c https://git.kernel.org/stable/c/237340dee373b97833a491d2e99fcf1d4 • CWE-125: Out-of-bounds Read •

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

In the Linux kernel, the following vulnerability has been resolved: tls: fix missing memory barrier in tls_init In tls_init(), a write memory barrier is missing, and store-store reordering may cause NULL dereference in tls_{setsockopt,getsockopt}. CPU0 CPU1 ----- ----- // In tls_init() // In tls_ctx_create() ctx = kzalloc() ctx->sk_proto = READ_ONCE(sk->sk_prot) -(1) // In update_sk_prot() WRITE_ONCE(sk->sk_prot, tls_prots) -(2) // In sock_common_setsockopt() READ_ONCE(sk->sk_prot)->setsockopt() // In tls_{setsockopt,getsockopt}() ctx->sk_proto->setsockopt() -(3) In the above scenario, when (1) and (2) are reordered, (3) can observe the NULL value of ctx->sk_proto, causing NULL dereference. To fix it, we rely on rcu_assign_pointer() which implies the release barrier semantic. By moving rcu_assign_pointer() after ctx->sk_proto is initialized, we can ensure that ctx->sk_proto are visible when changing sk->sk_prot. • https://git.kernel.org/stable/c/d5bee7374b68de3c44586d46e9e61ffc97a1e886 https://git.kernel.org/stable/c/d72e126e9a36d3d33889829df8fc90100bb0e071 https://git.kernel.org/stable/c/2c260a24cf1c4d30ea3646124f766ee46169280b https://git.kernel.org/stable/c/335c8f1566d8e44c384d16b450a18554896d4e8b https://git.kernel.org/stable/c/ab67c2fd3d070a21914d0c31319d3858ab4e199c https://git.kernel.org/stable/c/ef21007a7b581c7fe64d5a10c320880a033c837b https://git.kernel.org/stable/c/91e61dd7a0af660408e87372d8330ceb218be302 https://access.redhat.com/security/cve/CVE-2024-36489 • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •