linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] brcmfmac: Fix a wild pointer dereference bug in brcmf_chip_recognition()
@ 2022-01-24 16:48 Zhou Qingyang
  2022-01-28 10:16 ` Greg KH
  0 siblings, 1 reply; 4+ messages in thread
From: Zhou Qingyang @ 2022-01-24 16:48 UTC (permalink / raw)
  To: zhou1615
  Cc: kjlu, Arend van Spriel, Franky Lin, Hante Meuleman,
	Chi-hsien Lin, Wright Feng, Chung-hsien Hsu, Kalle Valo,
	David S. Miller, Jakub Kicinski, Pieter-Paul Giesberts,
	Angus Ainslie, Daniel (Deognyoun) Kim, John W. Linville,
	linux-wireless, brcm80211-dev-list.pdl, SHA-cyfmac-dev-list,
	netdev, linux-kernel

In brcmf_chip_recognition(), the return value of brcmf_chip_add_core()
is assigned to core and is passed to brcmf_chip_sb_corerev(). In
brcmf_chip_sb_corerev(), there exists dereference of core without check.
the return value of brcmf_chip_add_core() could be ERR_PTR on failure of
allocation, which could lead to a NULL pointer dereference bug.

Fix this bug by adding IS_ERR check for every variable core.

This bug was found by a static analyzer.

Builds with 'make allyesconfig' show no new warnings,
and our static analyzer no longer warns about this code

Fixes: cb7cf7be9eba ("brcmfmac: make chip related functions host interface independent")
Signed-off-by: Zhou Qingyang <zhou1615@umn.edu>
---
The analysis employs differential checking to identify inconsistent 
security operations (e.g., checks or kfrees) between two code paths 
and confirms that the inconsistent operations are not recovered in the
current function or the callers, so they constitute bugs. 

Note that, as a bug found by static analysis, it can be a false
positive or hard to trigger. Multiple researchers have cross-reviewed
the bug.

 .../net/wireless/broadcom/brcm80211/brcmfmac/chip.c    | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
index 1ee49f9e325d..4d91cb107cd7 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
@@ -986,18 +986,28 @@ static int brcmf_chip_recognition(struct brcmf_chip_priv *ci)
 
 		core = brcmf_chip_add_core(ci, BCMA_CORE_CHIPCOMMON,
 					   SI_ENUM_BASE_DEFAULT, 0);
+		if (IS_ERR(core))
+			return PTR_ERR(core);
 		brcmf_chip_sb_corerev(ci, core);
 		core = brcmf_chip_add_core(ci, BCMA_CORE_SDIO_DEV,
 					   BCM4329_CORE_BUS_BASE, 0);
+		if (IS_ERR(core))
+			return PTR_ERR(core);
 		brcmf_chip_sb_corerev(ci, core);
 		core = brcmf_chip_add_core(ci, BCMA_CORE_INTERNAL_MEM,
 					   BCM4329_CORE_SOCRAM_BASE, 0);
+		if (IS_ERR(core))
+			return PTR_ERR(core);
 		brcmf_chip_sb_corerev(ci, core);
 		core = brcmf_chip_add_core(ci, BCMA_CORE_ARM_CM3,
 					   BCM4329_CORE_ARM_BASE, 0);
+		if (IS_ERR(core))
+			return PTR_ERR(core);
 		brcmf_chip_sb_corerev(ci, core);
 
 		core = brcmf_chip_add_core(ci, BCMA_CORE_80211, 0x18001000, 0);
+		if (IS_ERR(core))
+			return PTR_ERR(core);
 		brcmf_chip_sb_corerev(ci, core);
 	} else if (socitype == SOCI_AI) {
 		ci->iscoreup = brcmf_chip_ai_iscoreup;
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] brcmfmac: Fix a wild pointer dereference bug in brcmf_chip_recognition()
  2022-01-24 16:48 [PATCH] brcmfmac: Fix a wild pointer dereference bug in brcmf_chip_recognition() Zhou Qingyang
@ 2022-01-28 10:16 ` Greg KH
  2022-01-28 10:31   ` Kalle Valo
  0 siblings, 1 reply; 4+ messages in thread
From: Greg KH @ 2022-01-28 10:16 UTC (permalink / raw)
  To: Zhou Qingyang
  Cc: kjlu, Arend van Spriel, Franky Lin, Hante Meuleman,
	Chi-hsien Lin, Wright Feng, Chung-hsien Hsu, Kalle Valo,
	David S. Miller, Jakub Kicinski, Pieter-Paul Giesberts,
	Angus Ainslie, Daniel (Deognyoun) Kim, John W. Linville,
	linux-wireless, brcm80211-dev-list.pdl, SHA-cyfmac-dev-list,
	netdev, linux-kernel

On Tue, Jan 25, 2022 at 12:48:45AM +0800, Zhou Qingyang wrote:
> In brcmf_chip_recognition(), the return value of brcmf_chip_add_core()
> is assigned to core and is passed to brcmf_chip_sb_corerev(). In
> brcmf_chip_sb_corerev(), there exists dereference of core without check.
> the return value of brcmf_chip_add_core() could be ERR_PTR on failure of
> allocation, which could lead to a NULL pointer dereference bug.
> 
> Fix this bug by adding IS_ERR check for every variable core.
> 
> This bug was found by a static analyzer.
> 
> Builds with 'make allyesconfig' show no new warnings,
> and our static analyzer no longer warns about this code
> 
> Fixes: cb7cf7be9eba ("brcmfmac: make chip related functions host interface independent")
> Signed-off-by: Zhou Qingyang <zhou1615@umn.edu>
> ---
> The analysis employs differential checking to identify inconsistent 
> security operations (e.g., checks or kfrees) between two code paths 
> and confirms that the inconsistent operations are not recovered in the
> current function or the callers, so they constitute bugs. 
> 
> Note that, as a bug found by static analysis, it can be a false
> positive or hard to trigger. Multiple researchers have cross-reviewed
> the bug.

As stated before, umn.edu is still not allowed to contribute to the
Linux kernel.  Please work with your administration to resolve this
issue.




^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] brcmfmac: Fix a wild pointer dereference bug in brcmf_chip_recognition()
  2022-01-28 10:16 ` Greg KH
@ 2022-01-28 10:31   ` Kalle Valo
  2022-01-28 10:54     ` Greg KH
  0 siblings, 1 reply; 4+ messages in thread
From: Kalle Valo @ 2022-01-28 10:31 UTC (permalink / raw)
  To: Greg KH
  Cc: Zhou Qingyang, kjlu, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	David S. Miller, Jakub Kicinski, Pieter-Paul Giesberts,
	Angus Ainslie, Daniel (Deognyoun) Kim, John W. Linville,
	linux-wireless, brcm80211-dev-list.pdl, SHA-cyfmac-dev-list,
	netdev, linux-kernel

Greg KH <greg@kroah.com> writes:

> On Tue, Jan 25, 2022 at 12:48:45AM +0800, Zhou Qingyang wrote:
>> In brcmf_chip_recognition(), the return value of brcmf_chip_add_core()
>> is assigned to core and is passed to brcmf_chip_sb_corerev(). In
>> brcmf_chip_sb_corerev(), there exists dereference of core without check.
>> the return value of brcmf_chip_add_core() could be ERR_PTR on failure of
>> allocation, which could lead to a NULL pointer dereference bug.
>> 
>> Fix this bug by adding IS_ERR check for every variable core.
>> 
>> This bug was found by a static analyzer.
>> 
>> Builds with 'make allyesconfig' show no new warnings,
>> and our static analyzer no longer warns about this code
>> 
>> Fixes: cb7cf7be9eba ("brcmfmac: make chip related functions host
>> interface independent")
>> Signed-off-by: Zhou Qingyang <zhou1615@umn.edu>
>> ---
>> The analysis employs differential checking to identify inconsistent 
>> security operations (e.g., checks or kfrees) between two code paths 
>> and confirms that the inconsistent operations are not recovered in the
>> current function or the callers, so they constitute bugs. 
>> 
>> Note that, as a bug found by static analysis, it can be a false
>> positive or hard to trigger. Multiple researchers have cross-reviewed
>> the bug.
>
> As stated before, umn.edu is still not allowed to contribute to the
> Linux kernel.  Please work with your administration to resolve this
> issue.

Thanks Greg, I didn't notice that this is from umn.edu. After seeing
what kind of "research" umn.edu does I will not even look at umn.edu
patches, they all will be automatically rejected without comments.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] brcmfmac: Fix a wild pointer dereference bug in brcmf_chip_recognition()
  2022-01-28 10:31   ` Kalle Valo
@ 2022-01-28 10:54     ` Greg KH
  0 siblings, 0 replies; 4+ messages in thread
From: Greg KH @ 2022-01-28 10:54 UTC (permalink / raw)
  To: Kalle Valo
  Cc: Zhou Qingyang, kjlu, Arend van Spriel, Franky Lin,
	Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
	David S. Miller, Jakub Kicinski, Pieter-Paul Giesberts,
	Angus Ainslie, Daniel (Deognyoun) Kim, John W. Linville,
	linux-wireless, brcm80211-dev-list.pdl, SHA-cyfmac-dev-list,
	netdev, linux-kernel

On Fri, Jan 28, 2022 at 12:31:44PM +0200, Kalle Valo wrote:
> Greg KH <greg@kroah.com> writes:
> 
> > On Tue, Jan 25, 2022 at 12:48:45AM +0800, Zhou Qingyang wrote:
> >> In brcmf_chip_recognition(), the return value of brcmf_chip_add_core()
> >> is assigned to core and is passed to brcmf_chip_sb_corerev(). In
> >> brcmf_chip_sb_corerev(), there exists dereference of core without check.
> >> the return value of brcmf_chip_add_core() could be ERR_PTR on failure of
> >> allocation, which could lead to a NULL pointer dereference bug.
> >> 
> >> Fix this bug by adding IS_ERR check for every variable core.
> >> 
> >> This bug was found by a static analyzer.
> >> 
> >> Builds with 'make allyesconfig' show no new warnings,
> >> and our static analyzer no longer warns about this code
> >> 
> >> Fixes: cb7cf7be9eba ("brcmfmac: make chip related functions host
> >> interface independent")
> >> Signed-off-by: Zhou Qingyang <zhou1615@umn.edu>
> >> ---
> >> The analysis employs differential checking to identify inconsistent 
> >> security operations (e.g., checks or kfrees) between two code paths 
> >> and confirms that the inconsistent operations are not recovered in the
> >> current function or the callers, so they constitute bugs. 
> >> 
> >> Note that, as a bug found by static analysis, it can be a false
> >> positive or hard to trigger. Multiple researchers have cross-reviewed
> >> the bug.
> >
> > As stated before, umn.edu is still not allowed to contribute to the
> > Linux kernel.  Please work with your administration to resolve this
> > issue.
> 
> Thanks Greg, I didn't notice that this is from umn.edu. After seeing
> what kind of "research" umn.edu does I will not even look at umn.edu
> patches, they all will be automatically rejected without comments.

Thank you.  We could just block their emails from the mailing lists, but
then that would not let us see when they send a patch and cc: the
relevant maintainers, so we have to live with this way for now.

I'll be contacting the umn.edu administration again and ask them what
went wrong here.

greg k-h

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-01-28 10:54 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-24 16:48 [PATCH] brcmfmac: Fix a wild pointer dereference bug in brcmf_chip_recognition() Zhou Qingyang
2022-01-28 10:16 ` Greg KH
2022-01-28 10:31   ` Kalle Valo
2022-01-28 10:54     ` Greg KH

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).