All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@codeaurora.org>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Hui Peng <benquike@gmail.com>,
	davem@davemloft.net, Mathias Payer <mathias.payer@nebelwelt.net>,
	ath10k@lists.infradead.org, linux-wireless@vger.kernel.org,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] Fix a NULL-ptr-deref bug in ath10k_usb_alloc_urb_from_pipe
Date: Fri, 18 Oct 2019 10:58:32 +0300	[thread overview]
Message-ID: <875zkmxz6f.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <20191018040530.GA28167@roeck-us.net> (Guenter Roeck's message of "Thu, 17 Oct 2019 21:05:30 -0700")

Guenter Roeck <linux@roeck-us.net> writes:

> On Sun, Sep 01, 2019 at 11:06:05AM +0300, Kalle Valo wrote:
>> Guenter Roeck <linux@roeck-us.net> writes:
>> 
>> > Hi,
>> >
>> > On Sat, Aug 03, 2019 at 08:31:01PM -0400, Hui Peng wrote:
>> >> The `ar_usb` field of `ath10k_usb_pipe_usb_pipe` objects
>> >> are initialized to point to the containing `ath10k_usb` object
>> >> according to endpoint descriptors read from the device side, as shown
>> >> below in `ath10k_usb_setup_pipe_resources`:
>> >> 
>> >> for (i = 0; i < iface_desc->desc.bNumEndpoints; ++i) {
>> >>         endpoint = &iface_desc->endpoint[i].desc;
>> >> 
>> >>         // get the address from endpoint descriptor
>> >>         pipe_num = ath10k_usb_get_logical_pipe_num(ar_usb,
>> >>                                                 endpoint->bEndpointAddress,
>> >>                                                 &urbcount);
>> >>         ......
>> >>         // select the pipe object
>> >>         pipe = &ar_usb->pipes[pipe_num];
>> >> 
>> >>         // initialize the ar_usb field
>> >>         pipe->ar_usb = ar_usb;
>> >> }
>> >> 
>> >> The driver assumes that the addresses reported in endpoint
>> >> descriptors from device side  to be complete. If a device is
>> >> malicious and does not report complete addresses, it may trigger
>> >> NULL-ptr-deref `ath10k_usb_alloc_urb_from_pipe` and
>> >> `ath10k_usb_free_urb_to_pipe`.
>> >> 
>> >> This patch fixes the bug by preventing potential NULL-ptr-deref.
>> >> 
>> >> Signed-off-by: Hui Peng <benquike@gmail.com>
>> >> Reported-by: Hui Peng <benquike@gmail.com>
>> >> Reported-by: Mathias Payer <mathias.payer@nebelwelt.net>
>> >
>> > This patch fixes CVE-2019-15099, which has CVSS scores of 7.5 (CVSS 3.0)
>> > and 7.8 (CVSS 2.0). Yet, I don't find it in the upstream kernel or in Linux
>> > next.
>> >
>> > Is the patch going to be applied to the upstream kernel anytime soon ?
>> 
>> Same answer as in patch 1:
>> 
>> https://patchwork.kernel.org/patch/11074655/
>> 
>
> Sorry to bring this up again. The ath6k patch made it into the upstream
> kernel, but the ath10k patch didn't. Did it get lost, or was there a
> reason not to apply this patch ?

This patch had a build warning, you can see it from patchwork:

https://patchwork.kernel.org/patch/11074657/

Can someone fix it and resend the patch, please?

-- 
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

WARNING: multiple messages have this Message-ID (diff)
From: Kalle Valo <kvalo@codeaurora.org>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Mathias Payer <mathias.payer@nebelwelt.net>,
	netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
	linux-kernel@vger.kernel.org, ath10k@lists.infradead.org,
	Hui Peng <benquike@gmail.com>,
	davem@davemloft.net
Subject: Re: [PATCH 2/2] Fix a NULL-ptr-deref bug in ath10k_usb_alloc_urb_from_pipe
Date: Fri, 18 Oct 2019 10:58:32 +0300	[thread overview]
Message-ID: <875zkmxz6f.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <20191018040530.GA28167@roeck-us.net> (Guenter Roeck's message of "Thu, 17 Oct 2019 21:05:30 -0700")

Guenter Roeck <linux@roeck-us.net> writes:

> On Sun, Sep 01, 2019 at 11:06:05AM +0300, Kalle Valo wrote:
>> Guenter Roeck <linux@roeck-us.net> writes:
>> 
>> > Hi,
>> >
>> > On Sat, Aug 03, 2019 at 08:31:01PM -0400, Hui Peng wrote:
>> >> The `ar_usb` field of `ath10k_usb_pipe_usb_pipe` objects
>> >> are initialized to point to the containing `ath10k_usb` object
>> >> according to endpoint descriptors read from the device side, as shown
>> >> below in `ath10k_usb_setup_pipe_resources`:
>> >> 
>> >> for (i = 0; i < iface_desc->desc.bNumEndpoints; ++i) {
>> >>         endpoint = &iface_desc->endpoint[i].desc;
>> >> 
>> >>         // get the address from endpoint descriptor
>> >>         pipe_num = ath10k_usb_get_logical_pipe_num(ar_usb,
>> >>                                                 endpoint->bEndpointAddress,
>> >>                                                 &urbcount);
>> >>         ......
>> >>         // select the pipe object
>> >>         pipe = &ar_usb->pipes[pipe_num];
>> >> 
>> >>         // initialize the ar_usb field
>> >>         pipe->ar_usb = ar_usb;
>> >> }
>> >> 
>> >> The driver assumes that the addresses reported in endpoint
>> >> descriptors from device side  to be complete. If a device is
>> >> malicious and does not report complete addresses, it may trigger
>> >> NULL-ptr-deref `ath10k_usb_alloc_urb_from_pipe` and
>> >> `ath10k_usb_free_urb_to_pipe`.
>> >> 
>> >> This patch fixes the bug by preventing potential NULL-ptr-deref.
>> >> 
>> >> Signed-off-by: Hui Peng <benquike@gmail.com>
>> >> Reported-by: Hui Peng <benquike@gmail.com>
>> >> Reported-by: Mathias Payer <mathias.payer@nebelwelt.net>
>> >
>> > This patch fixes CVE-2019-15099, which has CVSS scores of 7.5 (CVSS 3.0)
>> > and 7.8 (CVSS 2.0). Yet, I don't find it in the upstream kernel or in Linux
>> > next.
>> >
>> > Is the patch going to be applied to the upstream kernel anytime soon ?
>> 
>> Same answer as in patch 1:
>> 
>> https://patchwork.kernel.org/patch/11074655/
>> 
>
> Sorry to bring this up again. The ath6k patch made it into the upstream
> kernel, but the ath10k patch didn't. Did it get lost, or was there a
> reason not to apply this patch ?

This patch had a build warning, you can see it from patchwork:

https://patchwork.kernel.org/patch/11074657/

Can someone fix it and resend the patch, please?

-- 
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

  reply	other threads:[~2019-10-18  7:58 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-04  0:31 [PATCH 2/2] Fix a NULL-ptr-deref bug in ath10k_usb_alloc_urb_from_pipe Hui Peng
2019-08-04  0:31 ` Hui Peng
2019-08-10 10:13 ` Greg KH
2019-08-10 10:13   ` Greg KH
2019-08-31 21:31 ` Guenter Roeck
2019-08-31 21:31   ` Guenter Roeck
2019-09-01  8:06   ` Kalle Valo
2019-09-01  8:06     ` Kalle Valo
2019-10-18  4:05     ` Guenter Roeck
2019-10-18  4:05       ` Guenter Roeck
2019-10-18  7:58       ` Kalle Valo [this message]
2019-10-18  7:58         ` Kalle Valo
2019-10-18 13:35         ` Guenter Roeck
2019-10-18 13:35           ` Guenter Roeck
2019-09-01 19:45   ` Hui Peng
2019-09-01 19:45     ` Hui Peng
2019-09-03 14:14 ` Kalle Valo
2019-09-03 14:14 ` Kalle Valo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=875zkmxz6f.fsf@kamboji.qca.qualcomm.com \
    --to=kvalo@codeaurora.org \
    --cc=ath10k@lists.infradead.org \
    --cc=benquike@gmail.com \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=mathias.payer@nebelwelt.net \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.