Page 444 of 3453 results (0.009 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: llc: make llc_ui_sendmsg() more robust against bonding changes syzbot was able to trick llc_ui_sendmsg(), allocating an skb with no headroom, but subsequently trying to push 14 bytes of Ethernet header [1] Like some others, llc_ui_sendmsg() releases the socket lock before calling sock_alloc_send_skb(). Then it acquires it again, but does not redo all the sanity checks that were performed. This fix: - Uses LL_RESERVED_SPACE() to reserve space. - Check all conditions again after socket lock is held again. - Do not account Ethernet header for mtu limitation. [1] skbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0 kernel BUG at net/core/skbuff.c:193 ! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 6875 Comm: syz-executor.0 Not tainted 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_panic net/core/skbuff.c:189 [inline] pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 lr : skb_panic net/core/skbuff.c:189 [inline] lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 sp : ffff800096f97000 x29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000 x26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2 x23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0 x20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce x17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001 x14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400 x8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000 x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800082b78714 x2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089 Call trace: skb_panic net/core/skbuff.c:189 [inline] skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 skb_push+0xf0/0x108 net/core/skbuff.c:2451 eth_header+0x44/0x1f8 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3188 [inline] llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33 llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85 llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline] llc_sap_next_state net/llc/llc_sap.c:182 [inline] llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209 llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270 llc_ui_sendmsg+0x7bc/0xb1c net/llc/af_llc.c:997 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] sock_sendmsg+0x194/0x274 net/socket.c:767 splice_to_socket+0x7cc/0xd58 fs/splice.c:881 do_splice_from fs/splice.c:933 [inline] direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142 splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088 do_splice_direct+0x20c/0x348 fs/splice.c:1194 do_sendfile+0x4bc/0xc70 fs/read_write.c:1254 __do_sys_sendfile64 fs/read_write.c:1322 [inline] __se_sys_sendfile64 fs/read_write.c:1308 [inline] __arm64_sys_sendfile64+0x160/0x3b4 fs/read_write.c:1308 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155 el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595 Code: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000) En el kernel de Linux, se resolvió la siguiente vulnerabilidad: llc: hacer que llc_ui_sendmsg() sea más robusto contra cambios de vinculación syzbot pudo engañar a llc_ui_sendmsg(), asignando un skb sin espacio libre, pero posteriormente intentó enviar 14 bytes de encabezado Ethernet [ 1] Como otros, llc_ui_sendmsg() libera el bloqueo del socket antes de llamar a sock_alloc_send_skb(). Luego lo adquiere nuevamente, pero no rehace todas las comprobaciones de cordura que se realizaron. Esta solución: - Utiliza LL_RESERVED_SPACE() para reservar espacio. - Verifique todas las condiciones nuevamente después de mantener nuevamente el bloqueo del casquillo. - No tenga en cuenta el encabezado Ethernet para la limitación de mtu. [1] skbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0 ERROR del kernel en net/core/skbuff.c:193. Error interno: Ups - ERROR: 00000000f2000800 [#1] PREEMPT Módulos SMP vinculados en: CPU: 0 PID: 6875 Comm: syz-executor.0 No contaminado 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0 Nombre del hardware : Google Google Compute Engine/Google Compute Engine, BIOS Google 17/11/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc: skb_panic net/core/skbuff.c:189 [en línea] pc: skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 lr: skb_panic net/core/skbuff.c:189 [en línea] lr: skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 sp: ffff800096f97000 x29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000 x26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c 9c36ff2 x23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0 x20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce x1 7: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001 x14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000001 x10: 0000000000ff0100 x9: e28a51f1087e8400 x8: e28a 51f1087e8400 x7: ffff80008028f8d0 x6: 0000000000000000 x5: 0000000000000001 x4: 0000000000000001 x3: ffff800082b78714 x2: 00000000000000 001 x1: 0000000100000000 x0: 0000000000000089 Rastreo de llamadas: skb_panic net/core /skbuff.c:189 [en línea] skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 skb_push+0xf0/0x108 net/core/skbuff.c:2451 eth_header+0x44/0x1f8 net/ethernet/eth.c: 83 dev_hard_header include/linux/netdevice.h:3188 [en línea] llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33 llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85 llc_exec_sap_trans_ acciones net/llc/llc_sap.c :153 [en línea] llc_sap_next_state net/llc/llc_sap.c:182 [en línea] llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209 llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270 llc_ ui_sendmsg+0x7bc/ 0xb1c net/llc/af_llc.c:997 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg net/socket.c:745 [en línea] sock_sendmsg+0x194/0x274 net/socket.c:767 splice_to_socket+0x7cc/0xd58 fs /splice.c:881 do_splice_from fs/splice.c:933 [en línea] direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142 splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088 do_splice_direct+0x20c/0x348 fs/splice. c:1194 do_sendfile+0x4bc/0xc70 fs/read_write.c:1254 __do_sys_sendfile64 fs/read_write.c:1322 [en línea] __se_sys_sendfile64 fs/read_write.c:1308 [en línea] __arm64_sys_sendfile64+0x160/0x3b4 fs /read_write.c:1308 __invoke_syscall arch/arm64/kernel/syscall.c:37 [en línea] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136 do_el0_svc+0x48/ 0x58 arch/arm64/kernel/syscall.c:155 el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696 el0t_64_sync+ 0x190/0x194 arch/arm64/kernel/entry.S:595 Código: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000) • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/84e9d10419f6f4f3f3cd8f9aaf44a48719aa4b1b https://git.kernel.org/stable/c/b643d0defcbacd7fe548bc65c3e4e6f17dc5eb2d https://git.kernel.org/stable/c/04f2a74b562f3a7498be0399309669f342793d8c https://git.kernel.org/stable/c/c22044270da68881074fda81a7d34812726cb249 https://git.kernel.org/stable/c/6d53b813ff8b177f86f149c2f744442681f720e4 https://git.kernel.org/stable/c/cafd3ad3fe03ef4d6632747be9ee15dc0029db4b https://git.kernel.org/stable/c/c451c008f563d56d5e676c9dcafae565f •

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

In the Linux kernel, the following vulnerability has been resolved: llc: Drop support for ETH_P_TR_802_2. syzbot reported an uninit-value bug below. [0] llc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2 (0x0011), and syzbot abused the latter to trigger the bug. write$tun(r0, &(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, ')', "90e5dd"}}}}, 0x16) llc_conn_handler() initialises local variables {saddr,daddr}.mac based on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passes them to __llc_lookup(). However, the initialisation is done only when skb->protocol is htons(ETH_P_802_2), otherwise, __llc_lookup_established() and __llc_lookup_listener() will read garbage. The missing initialisation existed prior to commit 211ed865108e ("net: delete all instances of special processing for token ring"). It removed the part to kick out the token ring stuff but forgot to close the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv(). Let's remove llc_tr_packet_type and complete the deprecation. [0]: BUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90 __llc_lookup_established+0xe9d/0xf90 __llc_lookup net/llc/llc_conn.c:611 [inline] llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206 __netif_receive_skb_one_core net/core/dev.c:5527 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641 netif_receive_skb_internal net/core/dev.c:5727 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5786 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2020 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x8ef/0x1490 fs/read_write.c:584 ksys_write+0x20f/0x4c0 fs/read_write.c:637 __do_sys_write fs/read_write.c:649 [inline] __se_sys_write fs/read_write.c:646 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:646 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b Local variable daddr created at: llc_conn_handler+0x53/0x1360 net/llc/llc_conn.c:783 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206 CPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: llc: Eliminación del soporte para ETH_P_TR_802_2. syzbot informó un error de valor uninit a continuación. [0] llc admite ETH_P_802_2 (0x0004) y solía admitir ETH_P_TR_802_2 (0x0011), y syzbot abusó de este último para desencadenar el error. escribir$tun(r0, &(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, ')', "90e5dd" }}}}, 0x16) llc_conn_handler() inicializa las variables locales {saddr,daddr}.mac basadas en skb en llc_pdu_decode_sa()/llc_pdu_decode_da() y las pasa a __llc_lookup(). Sin embargo, la inicialización se realiza solo cuando skb->protocol es htons(ETH_P_802_2); de lo contrario, __llc_lookup_establecido() y __llc_lookup_listener() leerán basura. La inicialización faltante existía antes de el commit 211ed865108e ("net: eliminar todas las instancias de procesamiento especial para Token Ring"). Quitó la parte para expulsar el token ring, pero se olvidó de cerrar la puerta permitiendo que los paquetes ETH_P_TR_802_2 se colaran en llc_rcv(). Eliminemos llc_tr_packet_type y completemos la desaprobación. [0]: ERROR: KMSAN: valor uninit en __llc_lookup_establecido+0xe9d/0xf90 __llc_lookup_establecido+0xe9d/0xf90 __llc_lookup net/llc/llc_conn.c:611 [en línea] llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:79 1 llc_rcv +0xfbb/0x14a0 net/llc/llc_input.c:206 __netif_receive_skb_one_core net/core/dev.c:5527 [en línea] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641 netif_receive_skb_internal net/core/dev.c:5727 [en línea] netif_receive_skb+0x58/0x660 net/core/dev.c:5786 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2020 [en línea] new_sync_write fs/read_write.c:491 [en línea] vfs_write+0x8ef/0x1490 fs/read_write.c:584 ksys_write+0x20f/0x4c0 fs/read_write.c:637 __do_sys_write fs/read_write.c:649 [en línea] __se_sys_write fs/read_write.c:646 [en línea] __x64_sys_write+0x93/0xd0 fs/read_write.c:646 do_syscall_x64 arch/x86/entry/common. c: 51 [en línea] do_syscall_64+0x44/0x110 arch/x86/entry/comunes.c: 82 entry_syscall_64_after_hwframe+0x63/0x6b local variable daddr creado FBB /0x14a0 net/llc/llc_input.c:206 CPU: 1 PID: 5004 Comm: syz-executor994 No contaminado 6.6.0-syzkaller-14500-g1c41041124bd #0 Nombre de hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 10 /09/2023 • https://git.kernel.org/stable/c/211ed865108e24697b44bee5daac502ee6bdd4a4 https://git.kernel.org/stable/c/165ad1e22779685c3ed3dd349c6c4c632309cc62 https://git.kernel.org/stable/c/b8e8838f82f332ae80c643dbb1ca4418d0628097 https://git.kernel.org/stable/c/9ccdef19cf9497c2803b005369668feb91cacdfd https://git.kernel.org/stable/c/c0fe2fe7a5a291dfcf6dc64301732c8d3dc6a828 https://git.kernel.org/stable/c/660c3053d992b68fee893a0e9ec9159228cffdc6 https://git.kernel.org/stable/c/f1f34a515fb1e25e85dee94f781e7869ae351fb8 https://git.kernel.org/stable/c/df57fc2f2abf548aa889a36ab0bdcc94a •

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

In the Linux kernel, the following vulnerability has been resolved: crypto: lib/mpi - Fix unexpected pointer access in mpi_ec_init When the mpi_ec_ctx structure is initialized, some fields are not cleared, causing a crash when referencing the field when the structure was released. Initially, this issue was ignored because memory for mpi_ec_ctx is allocated with the __GFP_ZERO flag. For example, this error will be triggered when calculating the Za value for SM2 separately. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: crypto: lib/mpi: corrige el acceso inesperado al puntero en mpi_ec_init Cuando se inicializa la estructura mpi_ec_ctx, algunos campos no se borran, lo que provoca un bloqueo al hacer referencia al campo cuando se lanzó la estructura. Inicialmente, este problema se ignoró porque la memoria para mpi_ec_ctx se asigna con el indicador __GFP_ZERO. Por ejemplo, este error se activará al calcular el valor Za para SM2 por separado. • https://git.kernel.org/stable/c/d58bb7e55a8a65894cc02f27c3e2bf9403e7c40f https://git.kernel.org/stable/c/0c3687822259a7628c85cd21a3445cbe3c367165 https://git.kernel.org/stable/c/2bb86817b33c9d704e127f92b838035a72c315b6 https://git.kernel.org/stable/c/bb44477d4506e52785693a39f03cdc6a2c5e8598 https://git.kernel.org/stable/c/7ebf812b7019fd2d4d5a7ca45ef4bf3a6f4bda0a https://git.kernel.org/stable/c/7abdfd45a650c714d5ebab564bb1b988f14d9b49 https://git.kernel.org/stable/c/ba3c5574203034781ac4231acf117da917efcd2a https://lists.debian.org/debian-lts-announce/2024/06/ •

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

In the Linux kernel, the following vulnerability has been resolved: hwrng: core - Fix page fault dead lock on mmap-ed hwrng There is a dead-lock in the hwrng device read path. This triggers when the user reads from /dev/hwrng into memory also mmap-ed from /dev/hwrng. The resulting page fault triggers a recursive read which then dead-locks. Fix this by using a stack buffer when calling copy_to_user. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: hwrng: core: soluciona el bloqueo de falla de página en mmap-ed hwrng Hay un bloqueo en la ruta de lectura del dispositivo hwrng. Esto se activa cuando el usuario lee desde /dev/hwrng en la memoria y también realiza mmap-ed desde /dev/hwrng. • https://git.kernel.org/stable/c/9996508b3353063f2d6c48c1a28a84543d72d70b https://git.kernel.org/stable/c/eafd83b92f6c044007a3591cbd476bcf90455990 https://git.kernel.org/stable/c/5030d4c798863ccb266563201b341a099e8cdd48 https://git.kernel.org/stable/c/c6a8111aacbfe7a8a70f46cc0de8eed00561693c https://git.kernel.org/stable/c/26cc6d7006f922df6cc4389248032d955750b2a0 https://git.kernel.org/stable/c/aa8aa16ed9adf1df05bb339d588cf485a011839e https://git.kernel.org/stable/c/ecabe8cd456d3bf81e92c53b074732f3140f170d https://git.kernel.org/stable/c/6822a14271786150e178869f1495cc03e • CWE-400: Uncontrolled Resource Consumption •

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

In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: Fix buffer overflow in trans_stat_show Fix buffer overflow in trans_stat_show(). Convert simple snprintf to the more secure scnprintf with size of PAGE_SIZE. Add condition checking if we are exceeding PAGE_SIZE and exit early from loop. Also add at the end a warning that we exceeded PAGE_SIZE and that stats is disabled. Return -EFBIG in the case where we don't have enough space to write the full transition table. Also document in the ABI that this function can return -EFBIG error. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: PM / devfreq: Arreglar desbordamiento de búfer en trans_stat_show Arreglar desbordamiento de búfer en trans_stat_show(). Convierta snprintf simple en scnprintf más seguro con un tamaño de PAGE_SIZE. Agregue verificación de condiciones si excedemos PAGE_SIZE y salga temprano del ciclo. • https://git.kernel.org/stable/c/e552bbaf5b987f57c43e6981a452b8a3c700b1ae https://git.kernel.org/stable/c/087de000e4f8c878c81d9dd3725f00a1d292980c https://git.kernel.org/stable/c/796d3fad8c35ee9df9027899fb90ceaeb41b958f https://git.kernel.org/stable/c/8a7729cda2dd276d7a3994638038fb89035b6f2c https://git.kernel.org/stable/c/a979f56aa4b93579cf0e4265ae04d7e9300fd3e8 https://git.kernel.org/stable/c/eaef4650fa2050147ca25fd7ee43bc0082e03c87 https://git.kernel.org/stable/c/08e23d05fa6dc4fc13da0ccf09defdd4bbc92ff4 https://lists.debian.org/debian-lts-announce/2024/06/ • CWE-121: Stack-based Buffer Overflow •