linux-kernel - Re: [PATCH v5 01/11] net: qrtr: ns: validate msglen before ctrl

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: <d5ae397b-a33a-42c9-91a1-5ba3fcc367a5@ionic.de>
Date: Fri, 22 Aug 2025 21:08:47 +0200
From: Mihai Moldovan <ionic@...ic.de>
To: Jakub Kicinski <kuba@...nel.org>
Cc: linux-arm-msm@...r.kernel.org, Manivannan Sadhasivam <mani@...nel.org>,
 Denis Kenzior <denkenz@...il.com>, Eric Dumazet <edumazet@...gle.com>,
 Kuniyuki Iwashima <kuniyu@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
 Willem de Bruijn <willemb@...gle.com>, "David S . Miller"
 <davem@...emloft.net>, Simon Horman <horms@...nel.org>,
 linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH v5 01/11] net: qrtr: ns: validate msglen before ctrl_pkt
 use

* On 8/15/25 20:09, Jakub Kicinski wrote:
> If this is a fix it has to go to net, then once it reaches Linus's tree
> the dependent patches should be reposted for net-next.

Thanks.

Will split out the two commits and resend the resend of the series later on 
after the fixes have been merged.

Might take me a few weeks, I'm currently very limited on time and internet access.

>> diff --git a/net/qrtr/ns.c b/net/qrtr/ns.c
>> index 3de9350cbf30..2bcfe539dc3e 100644
>> --- a/net/qrtr/ns.c
>> +++ b/net/qrtr/ns.c
>> @@ -619,6 +619,9 @@ static void qrtr_ns_worker(struct work_struct *work)
>>   			break;
>>   		}
>>   
>> +		if ((size_t)msglen < sizeof(*pkt))
>> +			break;
> 
> why not continue?

I don't really know and am not familiar with the QRTR protocol, but here's my 
best guess:

Since we're using non-blocking I/O, it doesn't seem to make sense to continue, 
because the next receive call would just break out anyway once it returns no 
data at all. Notice that we're also breaking out for -EAGAIN.

Also, if we somehow got a short read, and we're currently dropping the buffer we 
just read, any additional data after a subsequent receive would be garbage to us 
anyway. We'd probably have to keep the old buffer content around and concatenate 
it with data returned from a new receive call.

Mihai