[moi12345]

Originalmente Escrito por moi12345

Hola.

Paulatinamente y de muy vez en cuando Google corrige errores en el kernel con sus ultimos parches de seguridad, pero por lo qué se no corrige errores como el tan mencionado SACK panic, qué esta presente en versiones de kernel 4.9 <.

Para que os hagais una idea de lo qué puede pasar, un movil conectado a internet mediante un exploit podria provocoar ataques de denegación de servicio a ese dispositivo, mediante un fallo en el protocolo TCP/IP que basicamente el principal fallo y con el commit qué pase se soluciona, es lo siguiente:

El kernel recive en orden los paquetes ACK que le llegen de una conexion GSM o wifi, el problema es qué, llega un momento en que el kernel se hace la picha un lio y produce un desbordamiento del buffer (buffer overflow) produciendo un kernel panic en la maquina o dispositivo con esa version de Linux.

Qué podria pasar? muy sencillo, que tu movil se reiniciara continuamente si un atacante conoce tu ip, o accede a una red wifi donde tu estas y mediante aircrack consigue la red wifi, podria averiguar la IP de tu dispositivo y producirte un kernel panic en el dispositivo, algo parecido a un BSOD en Windows.

Esos errores no estan corregidos por qué a google no le sale de los huevos, o no hace nada al respecto, y solo se basa en corregir errores "minimos" esos exploits qué mencionas son de la rama 4.9 del kernel, sin embargo hay muchos más, y google no los parchea.

Yo e estado trabajando para Autopistas, y actualmente soy ingeniero en desarollo de software, te hablo con propiedad ya qué basicamente para estar compleamente seguro necesitas tener una version actualizada del kernel, eso es así, bugs como Spectre que son imparcheables por mucho que existe un parche que lo intente "solucionar" podrian acceder a la pila de memoria del kernel, en modo kernel space si un hacker se lo propone podria hacerte un dump y volcar informacion privilegiada de tu dispositivo aprovechando ese fallo.

Un saludo

https://unaaldia.hispasec.com/2020/0...-criticas.html

diff --git a/include/net/sock.h b/include/net/sock.h
index 3aa7b7d6e6c7..f0f576ff5603 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -417,6 +417,7 @@ struct sock {
 	struct page_frag	sk_frag;
 	netdev_features_t	sk_route_caps;
 	netdev_features_t	sk_route_nocaps;
+	netdev_features_t	sk_route_forced_caps;
 	int			sk_gso_type;
 	unsigned int		sk_gso_max_size;
 	gfp_t			sk_allocation;
diff --git a/net/core/sock.c b/net/core/sock.c
index a1fa4a548f1b..507d8c6c4319 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1777,7 +1777,7 @@ void sk_setup_caps(struct sock *sk, struct dst_entry *dst)
 	u32 max_segs = 1;
 
 	sk_dst_set(sk, dst);
-	sk->sk_route_caps = dst->dev->features;
+	sk->sk_route_caps = dst->dev->features | sk->sk_route_forced_caps;
 	if (sk->sk_route_caps & NETIF_F_GSO)
 		sk->sk_route_caps |= NETIF_F_GSO_SOFTWARE;
 	sk->sk_route_caps &= ~sk->sk_route_nocaps;
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 48636aee23c3..4b46a2ae46e3 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -453,6 +453,7 @@ void tcp_init_sock(struct sock *sk)
 	sk->sk_rcvbuf = sock_net(sk)->ipv4.sysctl_tcp_rmem[1];
 
 	sk_sockets_allocated_inc(sk);
+	sk->sk_route_forced_caps = NETIF_F_GSO;
 }
 EXPORT_SYMBOL(tcp_init_sock);

Este parche soluciona el problema