Re: [PATCH net-next v2] usbnet: ipheth: prevent OoB reads of NDP16

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 9/12/24 23:18, Foster Snowhill wrote:
In "NCM mode", the iOS device encapsulates RX (phone->computer) traffic
in NCM Transfer Blocks (similarly to CDC NCM). However, unlike reverse
tethering (handled by the `cdc_ncm` driver), regular tethering is not
compliant with the CDC NCM spec, as the device is missing the necessary
descriptors, and TX (computer->phone) traffic is not encapsulated
at all. Thus `ipheth` implements a very limited subset of the spec with
the sole purpose of parsing RX URBs.

In the first iteration of the NCM mode implementation, there were a few
potential out of bounds reads when processing malformed URBs received
from a connected device:

* Only the start of NDP16 (wNdpIndex) was checked to fit in the URB
   buffer.
* Datagram length check as part of DPEs could overflow.
* DPEs could be read past the end of NDP16 and even end of URB buffer
   if a trailer DPE wasn't encountered.

The above is not expected to happen in normal device operation.

To address the above issues for iOS devices in NCM mode, rely on
and check for a specific fixed format of incoming URBs expected from
an iOS device:

* 12-byte NTH16
* 96-byte NDP16, allowing up to 22 DPEs (up to 21 datagrams + trailer)

On iOS, NDP16 directly follows NTH16, and its length is constant
regardless of the DPE count.

Adapt the driver to use the fixed URB format. Set an upper bound for
the DPE count based on the expected header size. Always expect a null
trailer DPE.

The minimal URB length of 108 bytes (IPHETH_NCM_HEADER_SIZE) in NCM mode
is already enforced in ipheth since introduction of NCM mode support.

Signed-off-by: Foster Snowhill <forst@xxxxxx>
Tested-by: Georgi Valkov <gvalkov@xxxxxxxxx>
---
v2: No code changes. Update commit message to further clarify that
     `ipheth` is not and does not aim to be a complete or spec-compliant
     CDC NCM implementation.
v1: https://lore.kernel.org/netdev/20240907230108.978355-1-forst@xxxxxx/

This should perhaps go into "net" rather than "net-next"? I submitted
the previous patch series to "net-next", but it got merged into "net"
[1]. However it's quite late in the 6.11-rc cycle, so not sure.

This indeed looks like a fix. I suggest to post it for the net tree including a suitable fixes tag.

Additionally since it looks like the patch addressed several issues, it would be probably better to split it in a small series, each patch addressing a single issue - and each patch with it's own fixed tag.

Thanks,

Paolo





[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux