| Submitter | Neal Cardwell |
|---|---|
| Date | Dec. 6, 2012, 3:42 p.m. |
| Message ID | <1354808546-644-1-git-send-email-ncardwell@google.com> |
| Download | mbox | patch |
| Permalink | /patch/204284/ |
| State | Changes Requested |
| Delegated to: | David Miller |
| Headers | show |
Comments
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. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch
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))
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(-)