<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/drivers/net, branch v4.4.29</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>mwifiex: correct aid value during tdls setup</title>
<updated>2016-10-31T10:13:59+00:00</updated>
<author>
<name>Xinming Hu</name>
<email>huxm@marvell.com</email>
</author>
<published>2016-08-09T14:50:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=b31602293c200928cf8d90c13738a90392757ac4'/>
<id>b31602293c200928cf8d90c13738a90392757ac4</id>
<content type='text'>
commit b64db1b252e9974a43a51ba083fa7d03e4716167 upstream.

AID gets updated during TDLS setup, but modified value isn't reflected
in "priv-&gt;assoc_rsp_buf". This causes TDLS setup failure. The problem is
fixed here.

Fixes: 4aff53ef18e4a4 ("mwifiex: parsing aid while receiving..")
Signed-off-by: Xinming Hu &lt;huxm@marvell.com&gt;
Signed-off-by: Amitkumar Karwar &lt;akarwar@marvell.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b64db1b252e9974a43a51ba083fa7d03e4716167 upstream.

AID gets updated during TDLS setup, but modified value isn't reflected
in "priv-&gt;assoc_rsp_buf". This causes TDLS setup failure. The problem is
fixed here.

Fixes: 4aff53ef18e4a4 ("mwifiex: parsing aid while receiving..")
Signed-off-by: Xinming Hu &lt;huxm@marvell.com&gt;
Signed-off-by: Amitkumar Karwar &lt;akarwar@marvell.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>brcmfmac: avoid potential stack overflow in brcmf_cfg80211_start_ap()</title>
<updated>2016-10-31T10:13:58+00:00</updated>
<author>
<name>Arend Van Spriel</name>
<email>arend.vanspriel@broadcom.com</email>
</author>
<published>2016-09-05T09:45:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=b82a7f93b4e60d8689d8f4e687ef58ed2098739f'/>
<id>b82a7f93b4e60d8689d8f4e687ef58ed2098739f</id>
<content type='text'>
commit ded89912156b1a47d940a0c954c43afbabd0c42c upstream.

User-space can choose to omit NL80211_ATTR_SSID and only provide raw
IE TLV data. When doing so it can provide SSID IE with length exceeding
the allowed size. The driver further processes this IE copying it
into a local variable without checking the length. Hence stack can be
corrupted and used as exploit.

Reported-by: Daxing Guo &lt;freener.gdx@gmail.com&gt;
Reviewed-by: Hante Meuleman &lt;hante.meuleman@broadcom.com&gt;
Reviewed-by: Pieter-Paul Giesberts &lt;pieter-paul.giesberts@broadcom.com&gt;
Reviewed-by: Franky Lin &lt;franky.lin@broadcom.com&gt;
Signed-off-by: Arend van Spriel &lt;arend.vanspriel@broadcom.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Juerg Haefliger &lt;juerg.haefliger@hpe.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit ded89912156b1a47d940a0c954c43afbabd0c42c upstream.

User-space can choose to omit NL80211_ATTR_SSID and only provide raw
IE TLV data. When doing so it can provide SSID IE with length exceeding
the allowed size. The driver further processes this IE copying it
into a local variable without checking the length. Hence stack can be
corrupted and used as exploit.

Reported-by: Daxing Guo &lt;freener.gdx@gmail.com&gt;
Reviewed-by: Hante Meuleman &lt;hante.meuleman@broadcom.com&gt;
Reviewed-by: Pieter-Paul Giesberts &lt;pieter-paul.giesberts@broadcom.com&gt;
Reviewed-by: Franky Lin &lt;franky.lin@broadcom.com&gt;
Signed-off-by: Arend van Spriel &lt;arend.vanspriel@broadcom.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Juerg Haefliger &lt;juerg.haefliger@hpe.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>net/mlx4_core: Allow resetting VF admin mac to zero</title>
<updated>2016-10-28T07:01:34+00:00</updated>
<author>
<name>Jack Morgenstein</name>
<email>jackm@dev.mellanox.co.il</email>
</author>
<published>2016-03-02T15:47:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=70c66946ef35691eeaf15977236219ffbc16f398'/>
<id>70c66946ef35691eeaf15977236219ffbc16f398</id>
<content type='text'>
commit 6e5224224faa50ec4c8949dcefadf895e565f0d1 upstream.

The VF administrative mac addresses (stored in the PF driver) are
initialized to zero when the PF driver starts up.

These addresses may be modified in the PF driver through ndo calls
initiated by iproute2 or libvirt.

While we allow the PF/host to change the VF admin mac address from zero
to a valid unicast mac, we do not allow restoring the VF admin mac to
zero. We currently only allow changing this mac to a different unicast mac.

This leads to problems when libvirt scripts are used to deal with
VF mac addresses, and libvirt attempts to revoke the mac so this
host will not use it anymore.

Fix this by allowing resetting a VF administrative MAC back to zero.

Fixes: 8f7ba3ca12f6 ('net/mlx4: Add set VF mac address support')
Signed-off-by: Jack Morgenstein &lt;jackm@dev.mellanox.co.il&gt;
Reported-by: Moshe Levi &lt;moshele@mellanox.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Juerg Haefliger &lt;juerg.haefliger@hpe.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 6e5224224faa50ec4c8949dcefadf895e565f0d1 upstream.

The VF administrative mac addresses (stored in the PF driver) are
initialized to zero when the PF driver starts up.

These addresses may be modified in the PF driver through ndo calls
initiated by iproute2 or libvirt.

While we allow the PF/host to change the VF admin mac address from zero
to a valid unicast mac, we do not allow restoring the VF admin mac to
zero. We currently only allow changing this mac to a different unicast mac.

This leads to problems when libvirt scripts are used to deal with
VF mac addresses, and libvirt attempts to revoke the mac so this
host will not use it anymore.

Fix this by allowing resetting a VF administrative MAC back to zero.

Fixes: 8f7ba3ca12f6 ('net/mlx4: Add set VF mac address support')
Signed-off-by: Jack Morgenstein &lt;jackm@dev.mellanox.co.il&gt;
Reported-by: Moshe Levi &lt;moshele@mellanox.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Juerg Haefliger &lt;juerg.haefliger@hpe.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>bnx2x: Prevent false warning for lack of FC NPIV</title>
<updated>2016-10-28T07:01:34+00:00</updated>
<author>
<name>Yuval Mintz</name>
<email>Yuval.Mintz@qlogic.com</email>
</author>
<published>2016-03-15T17:52:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6896b3dd2da5848ca54c96ee54a15ccd532e2904'/>
<id>6896b3dd2da5848ca54c96ee54a15ccd532e2904</id>
<content type='text'>
commit 1e6bb1a3540fec3ef112b9a89dda88e684c3ff59 upstream.

Not all adapters have FC-NPIV configured. If bnx2fc is used with such an
adapter, driver would read irrelevant data from the the nvram and log
"FC-NPIV table with bad length..." In system logs.

Simply accept that reading '0' as the feature offset in nvram indicates
the feature isn't there and return.

Reported-by: Andrew Patterson &lt;andrew.patterson@hpe.com&gt;
Signed-off-by: Yuval Mintz &lt;Yuval.Mintz@qlogic.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Juerg Haefliger &lt;juerg.haefliger@hpe.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 1e6bb1a3540fec3ef112b9a89dda88e684c3ff59 upstream.

Not all adapters have FC-NPIV configured. If bnx2fc is used with such an
adapter, driver would read irrelevant data from the the nvram and log
"FC-NPIV table with bad length..." In system logs.

Simply accept that reading '0' as the feature offset in nvram indicates
the feature isn't there and return.

Reported-by: Andrew Patterson &lt;andrew.patterson@hpe.com&gt;
Signed-off-by: Yuval Mintz &lt;Yuval.Mintz@qlogic.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Juerg Haefliger &lt;juerg.haefliger@hpe.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>rtlwifi: Fix missing country code for Great Britain</title>
<updated>2016-10-28T07:01:26+00:00</updated>
<author>
<name>Larry Finger</name>
<email>Larry.Finger@lwfinger.net</email>
</author>
<published>2016-08-22T19:27:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=7dcd1cd07760224f046713e7234113d08f151f06'/>
<id>7dcd1cd07760224f046713e7234113d08f151f06</id>
<content type='text'>
commit 0c9d3491530773858ff9d705ec2a9c382f449230 upstream.

Some RTL8821AE devices sold in Great Britain have the country code of
0x25 encoded in their EEPROM. This value is not tested in the routine
that establishes the regulatory info for the chip. The fix is to set
this code to have the same capabilities as the EU countries. In addition,
the channels allowed for COUNTRY_CODE_ETSI were more properly suited
for China and Israel, not the EU. This problem has also been fixed.

Signed-off-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 0c9d3491530773858ff9d705ec2a9c382f449230 upstream.

Some RTL8821AE devices sold in Great Britain have the country code of
0x25 encoded in their EEPROM. This value is not tested in the routine
that establishes the regulatory info for the chip. The fix is to set
this code to have the same capabilities as the EU countries. In addition,
the channels allowed for COUNTRY_CODE_ETSI were more properly suited
for China and Israel, not the EU. This problem has also been fixed.

Signed-off-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>brcmfmac: fix memory leak in brcmf_fill_bss_param</title>
<updated>2016-10-22T10:26:55+00:00</updated>
<author>
<name>Rafał Miłecki</name>
<email>rafal@milecki.pl</email>
</author>
<published>2016-09-21T06:23:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=85e27fe87acd059aa1c615184ec2c9ac9bfe29d2'/>
<id>85e27fe87acd059aa1c615184ec2c9ac9bfe29d2</id>
<content type='text'>
commit 23e9c128adb2038c27a424a5f91136e7fa3e0dc6 upstream.

This function is called from get_station callback which means that every
time user space was getting/dumping station(s) we were leaking 2 KiB.

Signed-off-by: Rafał Miłecki &lt;rafal@milecki.pl&gt;
Fixes: 1f0dc59a6de ("brcmfmac: rework .get_station() callback")
Acked-by: Arend van Spriel &lt;arend.vanspriel@broadcom.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 23e9c128adb2038c27a424a5f91136e7fa3e0dc6 upstream.

This function is called from get_station callback which means that every
time user space was getting/dumping station(s) we were leaking 2 KiB.

Signed-off-by: Rafał Miłecki &lt;rafal@milecki.pl&gt;
Fixes: 1f0dc59a6de ("brcmfmac: rework .get_station() callback")
Acked-by: Arend van Spriel &lt;arend.vanspriel@broadcom.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>i40e: avoid NULL pointer dereference and recursive errors on early PCI error</title>
<updated>2016-10-22T10:26:55+00:00</updated>
<author>
<name>Guilherme G Piccoli</name>
<email>gpiccoli@linux.vnet.ibm.com</email>
</author>
<published>2016-10-03T07:31:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6281c0883a9d56371a791304e756513a45975304'/>
<id>6281c0883a9d56371a791304e756513a45975304</id>
<content type='text'>
commit edfc23ee3e0ebbb6713d7574ab1b00abff178f6c upstream.

Although rare, it's possible to hit PCI error early on device
probe, meaning possibly some structs are not entirely initialized,
and some might even be completely uninitialized, leading to NULL
pointer dereference.

The i40e driver currently presents a "bad" behavior if device hits
such early PCI error: firstly, the struct i40e_pf might not be
attached to pci_dev yet, leading to a NULL pointer dereference on
access to pf-&gt;state.

Even checking if the struct is NULL and avoiding the access in that
case isn't enough, since the driver cannot recover from PCI error
that early; in our experiments we saw multiple failures on kernel
log, like:

  [549.664] i40e 0007:01:00.1: Initial pf_reset failed: -15
  [549.664] i40e: probe of 0007:01:00.1 failed with error -15
  [...]
  [871.644] i40e 0007:01:00.1: The driver for the device stopped because the
  device firmware failed to init. Try updating your NVM image.
  [871.644] i40e: probe of 0007:01:00.1 failed with error -32
  [...]
  [872.516] i40e 0007:01:00.0: ARQ: Unknown event 0x0000 ignored

Between the first probe failure (error -15) and the second (error -32)
another PCI error happened due to the first bad probe. Also, driver
started to flood console with those ARQ event messages.

This patch will prevent these issues by allowing error recovery
mechanism to remove the failed device from the system instead of
trying to recover from early PCI errors during device probe.

Signed-off-by: Guilherme G Piccoli &lt;gpiccoli@linux.vnet.ibm.com&gt;
Acked-by: Jacob Keller &lt;jacob.e.keller@intel.com&gt;
Tested-by: Andrew Bowers &lt;andrewx.bowers@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit edfc23ee3e0ebbb6713d7574ab1b00abff178f6c upstream.

Although rare, it's possible to hit PCI error early on device
probe, meaning possibly some structs are not entirely initialized,
and some might even be completely uninitialized, leading to NULL
pointer dereference.

The i40e driver currently presents a "bad" behavior if device hits
such early PCI error: firstly, the struct i40e_pf might not be
attached to pci_dev yet, leading to a NULL pointer dereference on
access to pf-&gt;state.

Even checking if the struct is NULL and avoiding the access in that
case isn't enough, since the driver cannot recover from PCI error
that early; in our experiments we saw multiple failures on kernel
log, like:

  [549.664] i40e 0007:01:00.1: Initial pf_reset failed: -15
  [549.664] i40e: probe of 0007:01:00.1 failed with error -15
  [...]
  [871.644] i40e 0007:01:00.1: The driver for the device stopped because the
  device firmware failed to init. Try updating your NVM image.
  [871.644] i40e: probe of 0007:01:00.1 failed with error -32
  [...]
  [872.516] i40e 0007:01:00.0: ARQ: Unknown event 0x0000 ignored

Between the first probe failure (error -15) and the second (error -32)
another PCI error happened due to the first bad probe. Also, driver
started to flood console with those ARQ event messages.

This patch will prevent these issues by allowing error recovery
mechanism to remove the failed device from the system instead of
trying to recover from early PCI errors during device probe.

Signed-off-by: Guilherme G Piccoli &lt;gpiccoli@linux.vnet.ibm.com&gt;
Acked-by: Jacob Keller &lt;jacob.e.keller@intel.com&gt;
Tested-by: Andrew Bowers &lt;andrewx.bowers@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>brcmsmac: Initialize power in brcms_c_stf_ss_algo_channel_get()</title>
<updated>2016-10-07T13:23:46+00:00</updated>
<author>
<name>Florian Fainelli</name>
<email>f.fainelli@gmail.com</email>
</author>
<published>2016-07-18T23:24:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=32a57f4ed2f654685f200dc6ab0aed67364af570'/>
<id>32a57f4ed2f654685f200dc6ab0aed67364af570</id>
<content type='text'>
commit f823a2aa8f4674c095a5413b9e3ba12d82df06f2 upstream.

wlc_phy_txpower_get_current() does a logical OR of power-&gt;flags, which
presumes that power.flags was initiliazed earlier by the caller,
unfortunately, this is not the case, so make sure we zero out the struct
tx_power before calling into wlc_phy_txpower_get_current().

Reported-by: coverity (CID 146011)
Fixes: 5b435de0d7868 ("net: wireless: add brcm80211 drivers")
Signed-off-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Acked-by: Arend van Spriel &lt;arend.vanspriel@broadcom.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit f823a2aa8f4674c095a5413b9e3ba12d82df06f2 upstream.

wlc_phy_txpower_get_current() does a logical OR of power-&gt;flags, which
presumes that power.flags was initiliazed earlier by the caller,
unfortunately, this is not the case, so make sure we zero out the struct
tx_power before calling into wlc_phy_txpower_get_current().

Reported-by: coverity (CID 146011)
Fixes: 5b435de0d7868 ("net: wireless: add brcm80211 drivers")
Signed-off-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Acked-by: Arend van Spriel &lt;arend.vanspriel@broadcom.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>brcmsmac: Free packet if dma_mapping_error() fails in dma_rxfill</title>
<updated>2016-10-07T13:23:46+00:00</updated>
<author>
<name>Florian Fainelli</name>
<email>f.fainelli@gmail.com</email>
</author>
<published>2016-07-18T23:24:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=3d0ef898fbbea4406e8a0b15201348bc30a2cadd'/>
<id>3d0ef898fbbea4406e8a0b15201348bc30a2cadd</id>
<content type='text'>
commit 5c5fa1f464ac954982df1d96b9f9a5103d21aedd upstream.

In case dma_mapping_error() returns an error in dma_rxfill, we would be
leaking a packet that we allocated with brcmu_pkt_buf_get_skb().

Reported-by: coverity (CID 1081819)
Fixes: 67d0cf50bd32 ("brcmsmac: Fix WARNING caused by lack of calls to dma_mapping_error()")
Signed-off-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Acked-by: Arend van Spriel &lt;arend@broadcom.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 5c5fa1f464ac954982df1d96b9f9a5103d21aedd upstream.

In case dma_mapping_error() returns an error in dma_rxfill, we would be
leaking a packet that we allocated with brcmu_pkt_buf_get_skb().

Reported-by: coverity (CID 1081819)
Fixes: 67d0cf50bd32 ("brcmsmac: Fix WARNING caused by lack of calls to dma_mapping_error()")
Signed-off-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Acked-by: Arend van Spriel &lt;arend@broadcom.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>brcmfmac: Fix glob_skb leak in brcmf_sdiod_recv_chain</title>
<updated>2016-10-07T13:23:45+00:00</updated>
<author>
<name>Florian Fainelli</name>
<email>f.fainelli@gmail.com</email>
</author>
<published>2016-07-18T23:24:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=a6501617e689ad80c4d185e0d8f485e0d0b1a708'/>
<id>a6501617e689ad80c4d185e0d8f485e0d0b1a708</id>
<content type='text'>
commit 3bdae810721b33061d2e541bd78a70f86ca42af3 upstream.

In case brcmf_sdiod_recv_chain() cannot complete a succeful call to
brcmf_sdiod_buffrw, we would be leaking glom_skb and not free it as we
should, fix this.

Reported-by: coverity (CID 1164856)
Fixes: a413e39a38573 ("brcmfmac: fix brcmf_sdcard_recv_chain() for host without sg support")
Signed-off-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Acked-by: Arend van Spriel &lt;arend.vanspriel@broadcom.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 3bdae810721b33061d2e541bd78a70f86ca42af3 upstream.

In case brcmf_sdiod_recv_chain() cannot complete a succeful call to
brcmf_sdiod_buffrw, we would be leaking glom_skb and not free it as we
should, fix this.

Reported-by: coverity (CID 1164856)
Fixes: a413e39a38573 ("brcmfmac: fix brcmf_sdcard_recv_chain() for host without sg support")
Signed-off-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Acked-by: Arend van Spriel &lt;arend.vanspriel@broadcom.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
