netdev - Re: [PATCH net v3 4/6] usbnet: ipheth: use static NDP16 location in URB

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: <b0052319-dd9f-40e3-a969-4cf6c57dad12@pen.gy>
Date: Sun, 1 Dec 2024 22:57:32 +0100
From: Foster Snowhill <forst@....gy>
To: Paolo Abeni <pabeni@...hat.com>, "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>
Cc: Georgi Valkov <gvalkov@...il.com>, Simon Horman <horms@...nel.org>,
 Oliver Neukum <oneukum@...e.com>, netdev@...r.kernel.org,
 linux-usb@...r.kernel.org
Subject: Re: [PATCH net v3 4/6] usbnet: ipheth: use static NDP16 location in
 URB

Hello Paolo,

On 2024-11-28 10:08, Paolo Abeni wrote:
>> On iOS devices, the NDP16 header always directly follows NTH16. Rely on
>> and check for this specific format.
>> <snip>
> 
> This choice looks fragile. What if the next iOS version moves around
> such header?

This is a valid concern, and something I've been pondering myself
for a while. My thinking so far can be summed up as follows:

"iOS devices aren't fully compliant with NCM for regular tethering (missing
necessary descriptors, computer->phone not encapsulated at all), so it can't
be handled by the existing fully-featured spec-compliant `cdc_ncm` driver.
The `cdc_ncm` driver includes the functionality I need to parse incoming
NCM data, but I don't see an easy way for me to call that code from `ipheth`.
I don't want to mess with the `cdc_ncm` driver's code. So I'll approach this
by implementing the bare minimum of the NCM spec in `ipheth` just to parse
incoming NCM URBs, relying on the specific URB format that iOS devices have."

I didn't want to reimplement more than I absolutely had to, because that work
had already been done in `cdc_ncm`. I relied on the specific URB format of
iOS devices that hasn't changed since the NCM mode was introduced there.

You're right, the URB format can change, without warning. If/when that
happens, it would be a good time to re-think the approach, and maybe figure
out a way to make use of the parsing code in `cdc_ncm`.

For now I wanted to limit the scope of changes to "let's make it work with
the assumptions that hold to this day".

> I think you should add least validate the assumption in the actual URB
> payload.

This is already validated by checking that ncm0->dwSignature matches
the four-byte constant defined in the NCM 1.0 spec. However I think you're
right that it may not be enough, if by some random chance the initial four
bytes right after NTH16 are set to the desired constant, yet aren't part
of a real NDP16 header. The condition below should cover it:

	ncmh->wNdpIndex == cpu_to_le16(sizeof(struct usb_cdc_ncm_nth16))

I'll add it in v4.

>> diff --git a/drivers/net/usb/ipheth.c b/drivers/net/usb/ipheth.c
>> index 48c79e69bb7b..3f9ea6546720 100644
>> --- a/drivers/net/usb/ipheth.c
>> +++ b/drivers/net/usb/ipheth.c
>> @@ -236,16 +236,14 @@ static int ipheth_rcvbulk_callback_ncm(struct urb *urb)
>>  	}
>>
>>  	ncmh = urb->transfer_buffer;
>> -	if (ncmh->dwSignature != cpu_to_le32(USB_CDC_NCM_NTH16_SIGN) ||
>> -	    le16_to_cpu(ncmh->wNdpIndex) >= urb->actual_length) {
>> +	if (ncmh->dwSignature != cpu_to_le32(USB_CDC_NCM_NTH16_SIGN)) {
>>  		dev->net->stats.rx_errors++;
>>  		return retval;
>>  	}
> 
> The URB length is never checked, why it's safe to access (a lot of)
> bytes inside the URB without any check?

There is a length check right above this hunk, starting with:

	if (urb->actual_length < IPHETH_NCM_HEADER_SIZE) {

IPHETH_NCM_HEADER_SIZE is defined in such a way that it covers NTH16,
the fixed-size NDP16 part plus up to 22 DPEs. This is described in the
commit message.

Thank you,
Foster.