lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20160316.195341.68257764618999441.davem@davemloft.net>
Date:	Wed, 16 Mar 2016 19:53:41 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	weiwan@...gle.com
Cc:	edumazet@...gle.com, netdev@...r.kernel.org
Subject: Re: [PATCH] ipv6: Fix the pmtu path for connected UDP socket

From: Wei Wang <weiwan@...gle.com>
Date: Mon, 14 Mar 2016 13:59:47 -0700

> From: Wei Wang <weiwan@...gle.com>
> 
> When ICMPV6_PKT_TOOBIG message is received by a connected UDP socket,
> the new mtu value is not properly updated in the dst_entry associated
> with the socket.
> This leads to the issue that the mtu value returned by getsockopt(sockfd,
> IPPROTO_IPV6, IPV6_MTU, ...) is wrong.
> The fix is to update sk->sk_dst_cache and other corresponding fields
> when a new routing cache is allocated for the new pmtu in UDP connected
> socket case.
> 
> Signed-off-by: Wei Wang <weiwan@...gle.com>

Wait a second:

>  		if (nrt6) {
>  			rt6_do_update_pmtu(nrt6, mtu);
> -
> -			/* ip6_ins_rt(nrt6) will bump the
> -			 * rt6->rt6i_node->fn_sernum
> -			 * which will fail the next rt6_check() and
> -			 * invalidate the sk->sk_dst_cache.
> -			 */
> +			if (sk)
> +				ip6_dst_store(sk, &nrt6->dst, daddr, saddr);
>  			ip6_ins_rt(nrt6);
>  		}
>  	}

I still haven't seen a satisfactory answer as to why the as-designed
invalidation mechanism using fn_sernum is not working.

If that's broken, then a lot of other things won't work properly
either.

I've read the ip6_ins_rt() code path several times, and it always
increments the serial number, and therefore the next dst->check() call
(which every cached route usage should invoke) should invalide
this socket's route and lookup the new one.

Why does this not work?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ