linux-kernel - Re: [PATCH net-next v3 02/10] udp/ipv6: move pending section of udpv6

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]

Date:   Mon, 16 May 2022 21:09:55 +0100
From:   Pavel Begunkov <asml.silence@...il.com>
To:     Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org,
        "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>
Cc:     David Ahern <dsahern@...nel.org>,
        Eric Dumazet <edumazet@...gle.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v3 02/10] udp/ipv6: move pending section of
 udpv6_sendmsg

On 5/16/22 14:11, Paolo Abeni wrote:
> On Fri, 2022-05-13 at 16:26 +0100, Pavel Begunkov wrote:
>> Move up->pending section of udpv6_sendmsg() to the beginning of the
>> function. Even though it require some code duplication for sin6 parsing,
>> it clearly localises the pending handling in one place, removes an extra
>> if and more importantly will prepare the code for further patches.
>>
>> Signed-off-by: Pavel Begunkov <asml.silence@...il.com>
>> ---
>>   net/ipv6/udp.c | 70 ++++++++++++++++++++++++++++++--------------------
>>   1 file changed, 42 insertions(+), 28 deletions(-)
>>
>> diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
>> index 11d44ed46953..85bff1252f5c 100644
>> --- a/net/ipv6/udp.c
>> +++ b/net/ipv6/udp.c
>> @@ -1318,6 +1318,46 @@ int udpv6_sendmsg(struct sock *sk, struct msghdr *msg, size_t len)
>>   	ipc6.sockc.tsflags = sk->sk_tsflags;
>>   	ipc6.sockc.mark = sk->sk_mark;
>>   
>> +	/* Rough check on arithmetic overflow,
>> +	   better check is made in ip6_append_data().
>> +	   */
>> +	if (unlikely(len > INT_MAX - sizeof(struct udphdr)))
>> +		return -EMSGSIZE;
>> +
>> +	getfrag  =  is_udplite ?  udplite_getfrag : ip_generic_getfrag;
>> +
>> +	/* There are pending frames. */
>> +	if (up->pending) {
>> +		if (up->pending == AF_INET)
>> +			return udp_sendmsg(sk, msg, len);
>> +
>> +		/* Do a quick destination sanity check before corking. */
>> +		if (sin6) {
>> +			if (msg->msg_namelen < offsetof(struct sockaddr, sa_data))
>> +				return -EINVAL;
>> +			if (sin6->sin6_family == AF_INET6) {
>> +				if (msg->msg_namelen < SIN6_LEN_RFC2133)
>> +					return -EINVAL;
>> +				if (ipv6_addr_any(&sin6->sin6_addr) &&
>> +				    ipv6_addr_v4mapped(&np->saddr))
>> +					return -EINVAL;
> 
> It looks like 'any' destination with ipv4 mapped source is now
> rejected, while the existing code accept it.

It should be up->pending == AF_INET6 to get there, and previously it'd
fall into udp_sendmsg() and fail

if (unlikely(up->pending != AF_INET))
         return -EINVAL;

I don't see it anyhow rejecting cases that were working before.
Can you elaborate a bit?

-- 
Pavel Begunkov