[PATCH net] inet_diag: fix oops for IPv4 AF_INET6 TCP SYN-RECV state

[PATCH net] inet_diag: fix oops for IPv4 AF_INET6 TCP SYN-RECV state

[Neal Cardwell]

Fix inet_diag to be aware of the fact that AF_INET6 TCP connections
instantiated for IPv4 traffic and in the SYN-RECV state were actually
created with inet_reqsk_alloc(), instead of inet6_reqsk_alloc(). This
means that for such connections inet6_rsk(req) returns a pointer to a
random spot in memory up to roughly 64KB beyond the end of the
request_sock.

With this bug, for a server using AF_INET6 TCP sockets and serving
IPv4 traffic, an inet_diag user like `ss state SYN-RECV` would lead to
inet_diag_fill_req() causing an oops or the export to user space of 16
bytes of kernel memory as a garbage IPv6 address, depending on where
the garbage inet6_rsk(req) pointed.

Signed-off-by: Neal Cardwell <ncardwell@google.com>
---
 net/ipv4/inet_diag.c |   53 ++++++++++++++++++++++++++++++++++++-------------
 1 files changed, 39 insertions(+), 14 deletions(-)

diff --git a/net/ipv4/inet_diag.c b/net/ipv4/inet_diag.c
index 0c34bfa..35c3de4 100644
--- a/net/ipv4/inet_diag.c
+++ b/net/ipv4/inet_diag.c
@@ -44,6 +44,10 @@ struct inet_diag_entry {
 	u16 dport;
 	u16 family;
 	u16 userlocks;
+#if IS_ENABLED(CONFIG_IPV6)
+	struct in6_addr saddr_storage;	/* for IPv4-mapped-IPv6 addresses */
+	struct in6_addr daddr_storage;	/* for IPv4-mapped-IPv6 addresses */
+#endif
 };
 
 static DEFINE_MUTEX(inet_diag_table_mutex);
@@ -67,6 +71,36 @@ static inline void inet_diag_unlock_handler(
 	mutex_unlock(&inet_diag_table_mutex);
 }
 
+
+/* Get the IPv4, IPv6, or IPv4-mapped-IPv6 local and remote addresses
+ * from a request_sock. For IPv4-mapped-IPv6 we must map IPv4 to IPv6.
+ */
+static inline void inet_diag_req_addrs(const struct sock *sk,
+				       const struct request_sock *req,
+				       struct inet_diag_entry *entry)
+{
+	struct inet_request_sock *ireq = inet_rsk(req);
+
+#if IS_ENABLED(CONFIG_IPV6)
+	if (sk->sk_family == AF_INET6) {
+		if (req->rsk_ops->family == AF_INET6) {
+			entry->saddr = inet6_rsk(req)->loc_addr.s6_addr32;
+			entry->daddr = inet6_rsk(req)->rmt_addr.s6_addr32;
+		} else if (req->rsk_ops->family == AF_INET) {
+			ipv6_addr_set_v4mapped(ireq->loc_addr,
+					       &entry->saddr_storage);
+			ipv6_addr_set_v4mapped(ireq->rmt_addr,
+					       &entry->daddr_storage);
+			entry->saddr = entry->saddr_storage.s6_addr32;
+			entry->daddr = entry->daddr_storage.s6_addr32;
+		}
+		return;
+	}
+#endif
+	entry->saddr = &ireq->loc_addr;
+	entry->daddr = &ireq->rmt_addr;
+}
+
 int inet_sk_diag_fill(struct sock *sk, struct inet_connection_sock *icsk,
 			      struct sk_buff *skb, struct inet_diag_req_v2 *req,
 			      struct user_namespace *user_ns,		      	
@@ -637,8 +671,10 @@ static int inet_diag_fill_req(struct sk_buff *skb, struct sock *sk,
 	r->idiag_inode = 0;
 #if IS_ENABLED(CONFIG_IPV6)
 	if (r->idiag_family == AF_INET6) {
-		*(struct in6_addr *)r->id.idiag_src = inet6_rsk(req)->loc_addr;
-		*(struct in6_addr *)r->id.idiag_dst = inet6_rsk(req)->rmt_addr;
+		struct inet_diag_entry entry;
+		inet_diag_req_addrs(sk, req, &entry);
+		memcpy(r->id.idiag_src, entry.saddr, sizeof(struct in6_addr));
+		memcpy(r->id.idiag_dst, entry.daddr, sizeof(struct in6_addr));
 	}
 #endif
 
@@ -691,18 +727,7 @@ static int inet_diag_dump_reqs(struct sk_buff *skb, struct sock *sk,
 				continue;
 
 			if (bc) {
-				entry.saddr =
-#if IS_ENABLED(CONFIG_IPV6)
-					(entry.family == AF_INET6) ?
-					inet6_rsk(req)->loc_addr.s6_addr32 :
-#endif
-					&ireq->loc_addr;
-				entry.daddr =
-#if IS_ENABLED(CONFIG_IPV6)
-					(entry.family == AF_INET6) ?
-					inet6_rsk(req)->rmt_addr.s6_addr32 :
-#endif
-					&ireq->rmt_addr;
+				inet_diag_req_addrs(sk, req, &entry);
 				entry.dport = ntohs(ireq->rmt_port);
 
 				if (!inet_diag_bc_run(bc, &entry))
-- 
1.7.7.3

Re: [PATCH net] inet_diag: fix oops for IPv4 AF_INET6 TCP SYN-RECV state

[David Miller]

From: Neal Cardwell <ncardwell@google.com>
Date: Thu,  6 Dec 2012 10:42:26 -0500

> Fix inet_diag to be aware of the fact that AF_INET6 TCP connections
> instantiated for IPv4 traffic and in the SYN-RECV state were actually
> created with inet_reqsk_alloc(), instead of inet6_reqsk_alloc(). This
> means that for such connections inet6_rsk(req) returns a pointer to a
> random spot in memory up to roughly 64KB beyond the end of the
> request_sock.
> 
> With this bug, for a server using AF_INET6 TCP sockets and serving
> IPv4 traffic, an inet_diag user like `ss state SYN-RECV` would lead to
> inet_diag_fill_req() causing an oops or the export to user space of 16
> bytes of kernel memory as a garbage IPv6 address, depending on where
> the garbage inet6_rsk(req) pointed.
> 
> Signed-off-by: Neal Cardwell <ncardwell@google.com>

Thanks for this fix, but it opens up more questions.

We don't seem to make any validations upon inet_diag_hostcond's
prefix_len.  That parameter we pass into bitstring_match() can
be just about anything.

As another example, what if we do an ipv6 128-bit compare on what's
actually an ipv4 address in the inet request sock?

I think we need to, using cond->family, make some kind of validations
upon cond->prefix_len.

Re: [PATCH net] inet_diag: fix oops for IPv4 AF_INET6 TCP SYN-RECV state

[Neal Cardwell]

On Fri, Dec 7, 2012 at 1:20 PM, David Miller <davem@davemloft.net> wrote:
> From: Neal Cardwell <ncardwell@google.com>
> Date: Thu,  6 Dec 2012 10:42:26 -0500
>
>> Fix inet_diag to be aware of the fact that AF_INET6 TCP connections
>> instantiated for IPv4 traffic and in the SYN-RECV state were actually
>> created with inet_reqsk_alloc(), instead of inet6_reqsk_alloc(). This
>> means that for such connections inet6_rsk(req) returns a pointer to a
>> random spot in memory up to roughly 64KB beyond the end of the
>> request_sock.
>>
>> With this bug, for a server using AF_INET6 TCP sockets and serving
>> IPv4 traffic, an inet_diag user like `ss state SYN-RECV` would lead to
>> inet_diag_fill_req() causing an oops or the export to user space of 16
>> bytes of kernel memory as a garbage IPv6 address, depending on where
>> the garbage inet6_rsk(req) pointed.
>>
>> Signed-off-by: Neal Cardwell <ncardwell@google.com>
>
> Thanks for this fix, but it opens up more questions.
>
> We don't seem to make any validations upon inet_diag_hostcond's
> prefix_len.  That parameter we pass into bitstring_match() can
> be just about anything.
>
> As another example, what if we do an ipv6 128-bit compare on what's
> actually an ipv4 address in the inet request sock?
>
> I think we need to, using cond->family, make some kind of validations
> upon cond->prefix_len.

OK, sounds good. I will add a patch to fix the adjacent prefix_len
issues you mention.

It also seems like it considers IPv4 and IPv6 with the same prefix as
matching, which seems bogus; eg IMHO 128.0.0.0 should not match 1::/1.
 In general it seems to me that a mismatch between entry->family and
cond->family should prevent a match, except for the IPv4-mapped-IPv6
case it already handles.

Would you like these patches against net or net-next?

neal

Re: [PATCH net] inet_diag: fix oops for IPv4 AF_INET6 TCP SYN-RECV state

[Neal Cardwell]

On Fri, Dec 7, 2012 at 9:30 PM, Neal Cardwell <ncardwell@google.com> wrote:
> It also seems like it considers IPv4 and IPv6 with the same prefix as
> matching, which seems bogus; eg IMHO 128.0.0.0 should not match 1::/1.

Oops, I think my example should be "128.0.0.0 should not match 8000::/1".

>  In general it seems to me that a mismatch between entry->family and
> cond->family should prevent a match, except for the IPv4-mapped-IPv6
> case it already handles.

But I think that general issue still remains.

neal