linux.git/drivers/usb/gadget/function/f_ncm.c, branch v6.6

usb: gadget: ncm: Handle decoding of multiple NTB's in unwrap call

2023-10-02T11:38:10+00:00

When NCM is used with hosts like Windows PC, it is observed that there are
multiple NTB's contained in one usb request giveback. Since the driver
unwraps the obtained request data assuming only one NTB is present, we
loose the subsequent NTB's present resulting in data loss.

Fix this by checking the parsed block length with the obtained data
length in usb request and continue parsing after the last byte of current
NTB.

Cc: stable@vger.kernel.org
Fixes: 9f6ce4240a2b ("usb: gadget: f_ncm.c added")
Signed-off-by: Krishna Kurapati 
Reviewed-by: Maciej Żenczykowski 
Link: https://lore.kernel.org/r/20230927105858.12950-1-quic_kriskura@quicinc.com
Signed-off-by: Greg Kroah-Hartman

usb: gadget: remove max support speed info in bind operation

2023-08-22T12:48:33+00:00

Take ecm_bind() for example, it call gadget_is_{*}speed() API to show
gadget max support speed, it is not much help, remove the API usage here
is safe.

Similar change apply to acm,eem,loopback,ncm,obex,rndis,serial,
sourcesink,subset functions.

Signed-off-by: Linyu Yuan 
Link: https://lore.kernel.org/r/20230803091053.9714-8-quic_linyyuan@quicinc.com
Signed-off-by: Greg Kroah-Hartman

usb: gadget: add a inline function gether_bitrate()

2023-08-22T12:48:33+00:00

In function ecm_bitrate(), it is not support report bit rate for super
speed plus mode, but it can use same bit rate value defined in ncm and
rndis.

Add a common inline function gether_bitrate() which report different for
all possible speeds, it can be used by ecm, ncm and rndis, also remove
old function from them.

Signed-off-by: Linyu Yuan 
Link: https://lore.kernel.org/r/20230803091053.9714-3-quic_linyyuan@quicinc.com
Signed-off-by: Greg Kroah-Hartman

usb: gadget: use working speed to calcaulate network bitrate and qlen

2023-08-22T12:48:33+00:00

Take ecm_bitrate() as example, it will be called after gadget device
link speed negotiation, consider code
if (gadget_is_superspeed(g) && g->speed == USB_SPEED_SUPER),
if a gadget device link speed is USB_SPEED_SUPER,
gadget_is_superspeed(g) must be true, or not it is a wrong
configuration of gadget max support speed.

Remove gadget_is_superspeed(g) checking should be safe, and remove other
similar operation in ncm, rndis, u_ether.

Signed-off-by: Linyu Yuan 
Link: https://lore.kernel.org/r/20230803091053.9714-2-quic_linyyuan@quicinc.com
Signed-off-by: Greg Kroah-Hartman

usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()

2023-01-17T16:10:34+00:00

In Google internal bug 265639009 we've received an (as yet) unreproducible
crash report from an aarch64 GKI 5.10.149-android13 running device.

AFAICT the source code is at:
  https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10

The call stack is:
  ncm_close() -> ncm_notify() -> ncm_do_notify()
with the crash at:
  ncm_do_notify+0x98/0x270
Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)

Which I believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...):

  // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification)
  0B 0D 00 79    strh w11, [x8, #6]

  // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request)
  6C 0A 00 B9    str  w12, [x19, #8]

  // x10 (NULL) was read here from offset 0 of valid pointer x9
  // IMHO we're reading 'cdev->gadget' and getting NULL
  // gadget is indeed at offset 0 of struct usb_composite_dev
  2A 01 40 F9    ldr  x10, [x9]

  // loading req->buf pointer, which is at offset 0 of struct usb_request
  69 02 40 F9    ldr  x9, [x19]

  // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed
  4B 5D 40 B9    ldr  w11, [x10, #0x5c]

which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment:

  event->wLength = cpu_to_le16(8);
  req->length = NCM_STATUS_BYTECOUNT;

  /* SPEED_CHANGE data is up/down speeds in bits/sec */
  data = req->buf + sizeof *event;
  data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));

My analysis of registers and NULL ptr deref crash offset
  (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)
heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing:
  data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));
which calls:
  ncm_bitrate(NULL)
which then calls:
  gadget_is_superspeed(NULL)
which reads
  ((struct usb_gadget *)NULL)->max_speed
and hits a panic.

AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.
(remember there's a GKI KABI reservation of 16 bytes in struct work_struct)

It's not at all clear to me how this is all supposed to work...
but returning 0 seems much better than panic-ing...

Cc: Felipe Balbi 
Cc: Lorenzo Colitti 
Cc: Carlos Llamas 
Cc: stable@vger.kernel.org
Signed-off-by: Maciej Żenczykowski 
Cc: stable 
Link: https://lore.kernel.org/r/20230117131839.1138208-1-maze@google.com
Signed-off-by: Greg Kroah-Hartman

usb: gadget: f_ncm: noop - remove INIT_NDP{16,32}_OPTS macros

2022-08-31T07:07:52+00:00

these are only used in one place, a few lines lower

Cc: Brooke Basile 
Cc: "Bryan O'Donoghue" 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: Lorenzo Colitti 
Signed-off-by: Maciej Żenczykowski 
Link: https://lore.kernel.org/r/20220821145745.122587-1-zenczykowski@gmail.com
Signed-off-by: Greg Kroah-Hartman

usb: gadget: f_ncm: ncm_wrap_ntb - move var definitions into if statement

2021-07-21T08:04:19+00:00

Since they're only used if there's an skb.

Cc: Brooke Basile 
Cc: "Bryan O'Donoghue" 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: Lorenzo Colitti 
Signed-off-by: Maciej Żenczykowski 
Link: https://lore.kernel.org/r/20210701114834.884597-5-zenczykowski@gmail.com
Signed-off-by: Greg Kroah-Hartman

usb: gadget: f_ncm: remove spurious if statement

2021-07-21T08:04:19+00:00

the current logic is:

  struct sk_buff  *skb2 = NULL;
  ...

  if (!skb && !ncm->skb_tx_data)
    return NULL;

  if (skb) {
    ...
  } else if (ncm->skb_tx_data)
    ...
  }

  return skb2;

Which means that first if statement is simply not needed.

Cc: Brooke Basile 
Cc: "Bryan O'Donoghue" 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: Lorenzo Colitti 
Signed-off-by: Maciej Żenczykowski 
Link: https://lore.kernel.org/r/20210701114834.884597-4-zenczykowski@gmail.com
Signed-off-by: Greg Kroah-Hartman

usb: gadget: f_ncm: remove check for NULL skb_tx_data in timer function

2021-07-21T08:04:19+00:00

This condition is already checked for in ncm_wrap_ntb(),
except that that check is done with eth_dev->lock held
(it is grabbed by eth_start_xmit).

It's best to not be reaching into ncm struct without locks held.

Cc: Brooke Basile 
Cc: "Bryan O'Donoghue" 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: Lorenzo Colitti 
Signed-off-by: Maciej Żenczykowski 
Link: https://lore.kernel.org/r/20210701114834.884597-3-zenczykowski@gmail.com
Signed-off-by: Greg Kroah-Hartman

usb: gadget: f_ncm: remove spurious boolean timer_stopping

2021-07-21T08:04:19+00:00

It is equivalent to ncm->netdev being NULL.

Cc: Brooke Basile 
Cc: "Bryan O'Donoghue" 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: Lorenzo Colitti 
Signed-off-by: Maciej Żenczykowski 
Link: https://lore.kernel.org/r/20210701114834.884597-2-zenczykowski@gmail.com
Signed-off-by: Greg Kroah-Hartman