| Message ID | 1355031803-14547-1-git-send-email-ncardwell@google.com |
|---|---|
| State | Accepted, archived |
| Delegated to: | David Miller |
| Headers | show |
Thanks a lot for working on a complete fix for these problems, I'll review these patches soon. -- 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 Sun, Dec 9, 2012 at 12:46 AM, David Miller <davem@davemloft.net> wrote: > > Thanks a lot for working on a complete fix for these problems, I'll > review these patches soon. Thanks, David! I appreciate it. 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 Sun, Dec 9, 2012 at 1:01 AM, Neal Cardwell <ncardwell@google.com> wrote: > On Sun, Dec 9, 2012 at 12:46 AM, David Miller <davem@davemloft.net> wrote: >> >> Thanks a lot for working on a complete fix for these problems, I'll >> review these patches soon. > > Thanks, David! I appreciate it. I noticed another related validation issue, and submitted a separate patch for that one, based on those previous three: http://patchwork.ozlabs.org/patch/204786/ Please let me know if you'd like be to regenerate them all as a single 4-patch series instead. thanks, neal ps: please excuse the duplicate send of that last patch... the first "git send-email" seemed unsuccessful, so I retried, but apparently the first attempt actually succeeded... -- 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
From: Neal Cardwell <ncardwell@google.com> Date: Sun, 9 Dec 2012 16:15:07 -0500 > On Sun, Dec 9, 2012 at 1:01 AM, Neal Cardwell <ncardwell@google.com> wrote: >> On Sun, Dec 9, 2012 at 12:46 AM, David Miller <davem@davemloft.net> wrote: >>> >>> Thanks a lot for working on a complete fix for these problems, I'll >>> review these patches soon. >> >> Thanks, David! I appreciate it. > > I noticed another related validation issue, and submitted a separate > patch for that one, based on those previous three: > > http://patchwork.ozlabs.org/patch/204786/ > > Please let me know if you'd like be to regenerate them all as a single > 4-patch series instead. What you did is fine, thanks 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
From: Neal Cardwell <ncardwell@google.com> Date: Sun, 9 Dec 2012 00:43:21 -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> Applied. -- 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 Sun, Dec 9, 2012 at 7:01 PM, David Miller <davem@davemloft.net> wrote: > From: Neal Cardwell <ncardwell@google.com> > Date: Sun, 9 Dec 2012 00:43:21 -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> > > Applied. Thanks, David. 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
diff --git a/net/ipv4/inet_diag.c b/net/ipv4/inet_diag.c index 0c34bfa..16cfa42 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); @@ -596,6 +600,36 @@ static int inet_twsk_diag_dump(struct inet_timewait_sock *tw, cb->nlh->nlmsg_seq, NLM_F_MULTI, cb->nlh); } +/* 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; + } + } else +#endif + { + entry->saddr = &ireq->loc_addr; + entry->daddr = &ireq->rmt_addr; + } +} + static int inet_diag_fill_req(struct sk_buff *skb, struct sock *sk, struct request_sock *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(-)