Re: [PATCH v9 2/6] dt: bindings: add mt7621-clk device tree binding documentation
Hi Rob,
On Fri, Mar 5, 2021 at 11:47 PM Rob Herring wrote:
[snip]
> > +
> > + ralink,sysctl:
> > +$ref: /schemas/types.yaml#/definitions/phandle
> > +description:
> > + phandle of syscon used to control system registers
> > +
> > + ralink,memctl:
> > +$ref: /schemas/types.yaml#/definitions/phandle
> > +description:
> > + phandle of syscon used to control memory registers
>
> I assume one of these phandles are the main registers for the clocks?
> Make this a child node and drop that phandle.
The 'ralink,sysctl' phandle is to read bootstrap register to be able
to derive xtal and a clk gate register for the peripherals.
The 'ralink,memctl' phandle is to read the cpu clock frequency from
the memory controller.
So there is not "main registers". I already put this as a child node
in v4 and I was told to get rid of child nodes. I need this as a
regmap to other DT node registers (sysctl, and memctl) to be able to
use the driver without specific architecture operations and properly
enable for COMPILE_TEST without dirty Makefile arch flags. Both sysctl
and memctl has no other child nodes, and I think that's why I was told
to avoid child nodes at the end. I explained here [0] current sysctl
and memctl in the mt7621 device tree and my view of the need for this
two syscons:
[0]: https://lkml.org/lkml/2021/1/2/9
So to avoid to send again "a previous version" on this patch, please
guide me in the correct thing to do. Stephen, Rob, I will be really
happy with your help :)
Best regards,
Sergio Paracuellos
>
> > +
> > + clock-output-names:
> > +maxItems: 8
> > +
> > +required:
> > + - compatible
> > + - '#clock-cells'
> > + - ralink,sysctl
> > + - ralink,memctl
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +#include
> > +
> > +pll {
> > + compatible = "mediatek,mt7621-clk";
> > + #clock-cells = <1>;
> > + ralink,sysctl = <>;
> > + ralink,memctl = <>;
> > + clock-output-names = "xtal", "cpu", "bus",
> > + "50m", "125m", "150m",
> > + "250m", "270m";
> > +};
> > --
> > 2.25.1
> >
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: android: ashmem: fixed a struct without const
Fixed a struct without const
Signed-off-by: nabil5352
---
drivers/staging/android/ashmem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c
index d66a64e42273..7854fd410efa 100644
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -376,7 +376,7 @@ ashmem_vmfile_get_unmapped_area(struct file *file, unsigned
long addr,
static int ashmem_mmap(struct file *file, struct vm_area_struct *vma)
{
- static struct file_operations vmfile_fops;
+ static const struct file_operations vmfile_fops;
struct ashmem_area *asma = file->private_data;
int ret = 0;
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
donation of 3,500,000.00
Best regards, You have a donation of 3,500,000.00 I have volunteered to donate an amount of 3,500,000.00 to one of the selected 5 people to help during this pandemic. Come back to argue. This is your donation code: [NJ005USA00035] Come back with a reply for your gift. I wish you a nice day. Adrian Tongson. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v9 2/6] dt: bindings: add mt7621-clk device tree binding documentation
Hi Rob! On Sat, Mar 6, 2021 at 6:48 AM Rob Herring wrote: > > On Thu, Feb 18, 2021 at 08:07:05AM +0100, Sergio Paracuellos wrote: > > Adds device tree binding documentation for clocks in the > > MT7621 SOC. > > > > Signed-off-by: Sergio Paracuellos > > --- > > .../bindings/clock/mediatek,mt7621-clk.yaml | 66 +++ > > 1 file changed, 66 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml > > > > diff --git > > a/Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml > > b/Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml > > new file mode 100644 > > index ..842a0f2c9d40 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml > > @@ -0,0 +1,66 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/clock/mediatek,mt7621-clk.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: MT7621 Clock Device Tree Bindings > > + > > +maintainers: > > + - Sergio Paracuellos > > + > > +description: | > > + The MT7621 has a PLL controller from where the cpu clock is provided > > + as well as derived clocks for the bus and the peripherals. It also > > + can gate SoC device clocks. > > + > > + Each clock is assigned an identifier and client nodes use this identifier > > + to specify the clock which they consume. > > + > > + All these identifiers could be found in: > > + [1]: . > > + > > +properties: > > + compatible: > > +const: mediatek,mt7621-clk > > + > > + "#clock-cells": > > +description: > > + The first cell indicates the clock number, see [1] for available > > + clocks. > > +const: 1 > > + > > + ralink,sysctl: > > +$ref: /schemas/types.yaml#/definitions/phandle > > +description: > > + phandle of syscon used to control system registers > > + > > + ralink,memctl: > > +$ref: /schemas/types.yaml#/definitions/phandle > > +description: > > + phandle of syscon used to control memory registers > > I assume one of these phandles are the main registers for the clocks? > Make this a child node and drop that phandle. On MT7621, CPU clock can be chosen from 3 sources: crystal clock, a fixed 500MHz clock or a clock created by the memory controller. sysctl contains a bootstrap register to determine crystal clock, a clock mux for choosing between the 3 sources for CPU clock, and a clock gate register for various peripherals. The ralink,memctl phandle here is to read the cpu clock frequency from the memory controller. The original implementation hides this hardware detail to avoid splitting the driver into three just for the CPU clock. Is this approach okay and we can put it under sysctl node, or this driver needs to be further splitted? -- Regards, Chuanhong Guo ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v9 2/6] dt: bindings: add mt7621-clk device tree binding documentation
On Thu, Feb 18, 2021 at 08:07:05AM +0100, Sergio Paracuellos wrote:
> Adds device tree binding documentation for clocks in the
> MT7621 SOC.
>
> Signed-off-by: Sergio Paracuellos
> ---
> .../bindings/clock/mediatek,mt7621-clk.yaml | 66 +++
> 1 file changed, 66 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml
>
> diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml
> b/Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml
> new file mode 100644
> index ..842a0f2c9d40
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml
> @@ -0,0 +1,66 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/mediatek,mt7621-clk.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MT7621 Clock Device Tree Bindings
> +
> +maintainers:
> + - Sergio Paracuellos
> +
> +description: |
> + The MT7621 has a PLL controller from where the cpu clock is provided
> + as well as derived clocks for the bus and the peripherals. It also
> + can gate SoC device clocks.
> +
> + Each clock is assigned an identifier and client nodes use this identifier
> + to specify the clock which they consume.
> +
> + All these identifiers could be found in:
> + [1]: .
> +
> +properties:
> + compatible:
> +const: mediatek,mt7621-clk
> +
> + "#clock-cells":
> +description:
> + The first cell indicates the clock number, see [1] for available
> + clocks.
> +const: 1
> +
> + ralink,sysctl:
> +$ref: /schemas/types.yaml#/definitions/phandle
> +description:
> + phandle of syscon used to control system registers
> +
> + ralink,memctl:
> +$ref: /schemas/types.yaml#/definitions/phandle
> +description:
> + phandle of syscon used to control memory registers
I assume one of these phandles are the main registers for the clocks?
Make this a child node and drop that phandle.
> +
> + clock-output-names:
> +maxItems: 8
> +
> +required:
> + - compatible
> + - '#clock-cells'
> + - ralink,sysctl
> + - ralink,memctl
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +
> +pll {
> + compatible = "mediatek,mt7621-clk";
> + #clock-cells = <1>;
> + ralink,sysctl = <>;
> + ralink,memctl = <>;
> + clock-output-names = "xtal", "cpu", "bus",
> + "50m", "125m", "150m",
> + "250m", "270m";
> +};
> --
> 2.25.1
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Assist me purchase a living home
Assist me purchase a living home, .I have huge sum in financial institution .Should there be a need for an evidence, or a prove of my seriousness and genuineness. I have a Certificate of Deposit as a prove of fund. am from Syria, (where I can invest to sustain my living until the political crisis in my country is over).Could you please send me an email on ( ahmedhussein44...@gmail.com ) to enable me know you have received my email. Ahmed Hussein ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: wimax: fix style check warnings
From: Gabriele Modena
Fix style warnings reported by checkpatch.pl on op-rfkill.c
by moving */ on a separate line in a block comment,
adding a missing blank line after declarations,
and reformatting a quoted string split across lines.
Signed-off-by: Gabriele Modena
---
drivers/staging/wimax/op-rfkill.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/wimax/op-rfkill.c
b/drivers/staging/wimax/op-rfkill.c
index 78b294481a59..52612ed09183 100644
--- a/drivers/staging/wimax/op-rfkill.c
+++ b/drivers/staging/wimax/op-rfkill.c
@@ -294,7 +294,8 @@ int wimax_rfkill(struct wimax_dev *wimax_dev, enum
wimax_rf_state state)
/* While initializing, < 1.4.3 wimax-tools versions use
* this call to check if the device is a valid WiMAX
* device; so we allow it to proceed always,
-* considering the radios are all off. */
+* considering the radios are all off.
+*/
if (result == -ENOMEDIUM && state == WIMAX_RF_QUERY)
result = WIMAX_RF_OFF << 1 | WIMAX_RF_OFF;
goto error_not_ready;
@@ -378,6 +379,7 @@ int wimax_rfkill_add(struct wimax_dev *wimax_dev)
void wimax_rfkill_rm(struct wimax_dev *wimax_dev)
{
struct device *dev = wimax_dev_to_dev(wimax_dev);
+
d_fnstart(3, dev, "(wimax_dev %p)\n", wimax_dev);
rfkill_unregister(wimax_dev->rfkill);
rfkill_destroy(wimax_dev->rfkill);
@@ -415,8 +417,7 @@ int wimax_gnl_doit_rfkill(struct sk_buff *skb, struct
genl_info *info)
dev = wimax_dev_to_dev(wimax_dev);
result = -EINVAL;
if (info->attrs[WIMAX_GNL_RFKILL_STATE] == NULL) {
- dev_err(dev, "WIMAX_GNL_RFKILL: can't find RFKILL_STATE "
- "attribute\n");
+ dev_err(dev, "WIMAX_GNL_RFKILL: can't find RFKILL_STATE
attribute\n");
goto error_no_pid;
}
new_state = nla_get_u32(info->attrs[WIMAX_GNL_RFKILL_STATE]);
--
2.11.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8723bs: removed unused code block
Removed conditional code block checked by unused CONFIG_TX_BCAST2UNI
This patch does the cleaning required in TODO file:
find and remove code blocks guarded by never set CONFIG_FOO defines
Signed-off-by: Fabio Aiuto
---
drivers/staging/rtl8723bs/os_dep/xmit_linux.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/xmit_linux.c
b/drivers/staging/rtl8723bs/os_dep/xmit_linux.c
index 1c23fbe58881..a89b88eaed39 100644
--- a/drivers/staging/rtl8723bs/os_dep/xmit_linux.c
+++ b/drivers/staging/rtl8723bs/os_dep/xmit_linux.c
@@ -212,9 +212,6 @@ int _rtw_xmit_entry(_pkt *pkt, _nic_hdl pnetdev)
&& check_fwstate(pmlmepriv, WIFI_AP_STATE) == true
&& (IP_MCAST_MAC(pkt->data)
|| ICMPV6_MCAST_MAC(pkt->data)
- #ifdef CONFIG_TX_BCAST2UNI
- || is_broadcast_mac_addr(pkt->data)
- #endif
)
&& padapter->registrypriv.wifi_spec == 0) {
if (pxmitpriv->free_xmitframe_cnt > (NR_XMITFRAME / 4)) {
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8188eu: prevent ->ssid overflow in rtw_wx_set_scan()
On Fri, Mar 5, 2021 at 12:33 PM Dan Carpenter wrote:
>
> It's good that you're reviewing code...
Right now watching the patches flow feels like I'm just shadowing.
Later, when I get the hang of it, I might try providing something on
my own. I'll just watch things from a distance for the time being
perhaps making questions here or there (like I just did).
Just in case, my main point was to use a min() (or MIN? whatever way
it's provided in the standard) to have only two conditions instead of
three... .to keep them on separate lines, it could be done like this:
if (sec_len > 0 &&
sec_len <= min(len, 32)) {
_but_ I understand if you would rather keep the 3 conditions.
Thanks for your comment.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8188eu: prevent ->ssid overflow in rtw_wx_set_scan()
On Fri, Mar 05, 2021 at 10:58:17AM -0600, Edmundo Carmona Antoranz wrote:
> On Fri, Mar 5, 2021 at 2:59 AM Dan Carpenter wrote:
> > - if (sec_len > 0 && sec_len <= len) {
> > + if (sec_len > 0 &&
> > + sec_len <= len &&
> > + sec_len <= 32) {
>
> I wonder if this could be reduced to (sec_len > 0 && sec_len <=
> min(len, 32)) from a stylistic POV?
I kind of prefer it the way I wrote it. I prefer conditions split
apart and done ploddingly, one at a time... You'll notice how I could
have written it like:
if (sec_len > 0 && sec_len <= len &&
sec_len <= 32) {
But I really like my conditions to be spelled out so the "sec_len" is
perfectly aligned in each part of the condition. Your way would be to
combine two conditions into one part of a line and seems sneaky.
>
> First attempt at something kernel related so I know there's plenty of
> things to learn (including patterns for problems like this and
> etiquette).
It's good that you're reviewing code... We try to be predictable though
and no one would have predicted your response. Ideally patch review
should be like, "Ugh! Why didn't I think of that? Of course, we should
propagate the error code." Or "Oh, I didn't know checkpatch warns about
that."
The truth is that I don't always agree with all of Greg's reviews. He
is more strict than I am about breaking up patches into multiple things.
(It's a tricky line to define for me). But I can always predict what
Greg will say in a review so that saves time when I know which patches
he will accept and which he won't.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8188eu: prevent ->ssid overflow in rtw_wx_set_scan()
On Fri, Mar 5, 2021 at 2:59 AM Dan Carpenter wrote:
> - if (sec_len > 0 && sec_len <= len) {
> + if (sec_len > 0 &&
> + sec_len <= len &&
> + sec_len <= 32) {
I wonder if this could be reduced to (sec_len > 0 && sec_len <=
min(len, 32)) from a stylistic POV?
First attempt at something kernel related so I know there's plenty of
things to learn (including patterns for problems like this and
etiquette).
BR
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8192e: Fix possible buffer overflow in _rtl92e_wx_set_scan
Hi Dan, Do you think any of these could be potential issues: driver/staging/ rtl8192e/rtllib_rx.c:2442 wlan-ng/cfg80211.c:316 rtl8723bs/os_dep/ioctl_cfg80211.c:1591 rtl8723bs/os_dep/ioctl_cfg80211.c:2738 and if so, findable via Smatch? Regards, Lee On Fri, Mar 05, 2021 at 11:22:28AM +0300, Dan Carpenter wrote: > Actually, I looked through a bunch of these and they're mostly false > positives outside of staging. I guess there are a few ways the ->ssid > can be changed. Via netlink, from the network or from the an ioctl. > > I still have a couple questions, but so far as I can see it's mostly the > ioctl which has problems. > > I really want Smatch to be able to figure the netlink stuff... That > should be doable. > > regards, > dan carpenter > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8723bs: remove duplicate pstat->hwaddr check
IS_MCAST(pstat->hwaddr) checked twice in a row in
odm_RefreshRateAdaptiveMaskCE(). Remove the second check.
Signed-off-by: Denis Efremov
---
drivers/staging/rtl8723bs/hal/odm.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/odm.c
b/drivers/staging/rtl8723bs/hal/odm.c
index f2a9e95a1563..5e432f1bc150 100644
--- a/drivers/staging/rtl8723bs/hal/odm.c
+++ b/drivers/staging/rtl8723bs/hal/odm.c
@@ -1114,8 +1114,6 @@ void odm_RefreshRateAdaptiveMaskCE(PDM_ODM_T pDM_Odm)
if (IS_STA_VALID(pstat)) {
if (IS_MCAST(pstat->hwaddr)) /* if (psta->mac_id == 1)
*/
continue;
- if (IS_MCAST(pstat->hwaddr))
- continue;
if (true == ODM_RAStateCheck(pDM_Odm,
pstat->rssi_stat.UndecoratedSmoothedPWDB, false, >rssi_level)) {
ODM_RT_TRACE(pDM_Odm, ODM_COMP_RA_MASK,
ODM_DBG_LOUD, ("RSSI:%d, RSSI_LEVEL:%d\n",
pstat->rssi_stat.UndecoratedSmoothedPWDB, pstat->rssi_level));
--
2.26.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 0/5] Reset driver for IMX8MQ VPU hardware block
Le 03/03/2021 à 17:25, Philipp Zabel a écrit : On Wed, 2021-03-03 at 16:20 +0100, Benjamin Gaignard wrote: Le 03/03/2021 à 15:17, Philipp Zabel a écrit : Hi Benjamin, On Mon, 2021-03-01 at 16:17 +0100, Benjamin Gaignard wrote: The two VPUs inside IMX8MQ share the same control block which can be see as a reset hardware block. This isn't a reset controller though. The control block also contains clock gates of some sort and a filter register for the featureset fuses. Those shouldn't be manipulated via the reset API. They are all part of the control block and of the reset process for this hardware that why I put them here. I guess it is border line :-) I'm pushing back to keep the reset control framework focused on controlling reset lines. Every side effect (such as the asymmetric clock ungating) in a random driver makes it harder to reason about behaviour at the API level, and to review patches for hardware I am not familiar with. In order to be able to add the second VPU (for HECV decoding) it will be more handy if the both VPU drivers instance don't have to share the control block registers. This lead to implement it as an independ reset driver and to change the VPU driver to use it. Why not switch to a syscon regmap for the control block? That should also allow to keep backwards compatibility with the old binding with minimal effort. I will give a try in this direction. Thank you. Please note that this series break the compatibility between the DTB and kernel. This break is limited to IMX8MQ SoC and is done when the driver is still in staging directory. I know in this case we are pretty sure there are no users of this binding except for a staging driver, but it would still be nice to keep support for the deprecated binding, to avoid the requirement of updating kernel and DT in lock-step. If I want to use a syscon (or a reset) the driver must not ioremap the "ctrl" registers. It means that "ctrl" has to be removed from the driver requested reg-names (imx8mq_reg_names[]). Doing that break the kernel/DT compatibility. Somehow syscon and "ctrl" are exclusive. The way the driver is set up currently, yes. You could add a bit of platform specific probe code, though, that would set up the regmap either by calling syscon_regmap_lookup_by_phandle(); for the new binding, or, if the phandle is not available, fall back to platform_get_resource_byname(..., "ctrl"); devm_ioremap_resource(); devm_regmap_init_mmio(); for the old binding. The actual codec .reset and variant .runtime_resume ops could be identical then. I made it works with syscon and your proposal. The next version of the patches will be without reset and won't break DT compatibility. Thanks for your help, Benjamin regards Philipp ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8188eu: prevent ->ssid overflow in rtw_wx_set_scan()
This code has a check to prevent read overflow but it needs another
check to prevent writing beyond the end of the ->ssid[] array.
Fixes: a2c60d42d97c ("staging: r8188eu: Add files for new driver - part 16")
Signed-off-by: Dan Carpenter
---
drivers/staging/rtl8188eu/os_dep/ioctl_linux.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
index bf22f130d3e1..58954b88a817 100644
--- a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
@@ -1133,9 +1133,11 @@ static int rtw_wx_set_scan(struct net_device *dev,
struct iw_request_info *a,
break;
}
sec_len = *(pos++); len -= 1;
- if (sec_len > 0 && sec_len <= len) {
+ if (sec_len > 0 &&
+ sec_len <= len &&
+ sec_len <= 32) {
ssid[ssid_index].ssid_length =
sec_len;
- memcpy(ssid[ssid_index].ssid,
pos, ssid[ssid_index].ssid_length);
+ memcpy(ssid[ssid_index].ssid,
pos, sec_len);
ssid_index++;
}
pos += sec_len;
--
2.30.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8188eu: fix potential memory corruption in rtw_check_beacon_data()
The "ie_len" is a value in the 1-255 range that comes from the user. We
have to cap it to ensure that it's not too large or it could lead to
memory corruption.
Fixes: 9a7fe54ddc3a ("staging: r8188eu: Add source files for new driver - part
1")
Signed-off-by: Dan Carpenter
---
drivers/staging/rtl8188eu/core/rtw_ap.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/staging/rtl8188eu/core/rtw_ap.c
b/drivers/staging/rtl8188eu/core/rtw_ap.c
index fa1e34a0d456..182bb944c9b3 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ap.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ap.c
@@ -791,6 +791,7 @@ int rtw_check_beacon_data(struct adapter *padapter, u8
*pbuf, int len)
p = rtw_get_ie(ie + _BEACON_IE_OFFSET_, WLAN_EID_SSID, _len,
pbss_network->ie_length - _BEACON_IE_OFFSET_);
if (p && ie_len > 0) {
+ ie_len = min_t(int, ie_len, sizeof(pbss_network->ssid.ssid));
memset(_network->ssid, 0, sizeof(struct ndis_802_11_ssid));
memcpy(pbss_network->ssid.ssid, p + 2, ie_len);
pbss_network->ssid.ssid_length = ie_len;
@@ -811,6 +812,7 @@ int rtw_check_beacon_data(struct adapter *padapter, u8
*pbuf, int len)
p = rtw_get_ie(ie + _BEACON_IE_OFFSET_, WLAN_EID_SUPP_RATES, _len,
pbss_network->ie_length - _BEACON_IE_OFFSET_);
if (p) {
+ ie_len = min_t(int, ie_len, NDIS_802_11_LENGTH_RATES_EX);
memcpy(supportRate, p + 2, ie_len);
supportRateNum = ie_len;
}
@@ -819,6 +821,8 @@ int rtw_check_beacon_data(struct adapter *padapter, u8
*pbuf, int len)
p = rtw_get_ie(ie + _BEACON_IE_OFFSET_, WLAN_EID_EXT_SUPP_RATES,
_len, pbss_network->ie_length - _BEACON_IE_OFFSET_);
if (p) {
+ ie_len = min_t(int, ie_len,
+ NDIS_802_11_LENGTH_RATES_EX - supportRateNum);
memcpy(supportRate + supportRateNum, p + 2, ie_len);
supportRateNum += ie_len;
}
@@ -934,6 +938,7 @@ int rtw_check_beacon_data(struct adapter *padapter, u8
*pbuf, int len)
pht_cap->mcs.rx_mask[0] = 0xff;
pht_cap->mcs.rx_mask[1] = 0x0;
+ ie_len = min_t(int, ie_len, sizeof(pmlmepriv->htpriv.ht_cap));
memcpy(>htpriv.ht_cap, p + 2, ie_len);
}
--
2.30.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8192e: Fix possible buffer overflow in _rtl92e_wx_set_scan
Actually, I looked through a bunch of these and they're mostly false positives outside of staging. I guess there are a few ways the ->ssid can be changed. Via netlink, from the network or from the an ioctl. I still have a couple questions, but so far as I can see it's mostly the ioctl which has problems. I really want Smatch to be able to figure the netlink stuff... That should be doable. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8192u: fix ->ssid overflow in r8192_wx_set_scan()
We need to cap len at IW_ESSID_MAX_SIZE (32) to avoid memory corruption.
This can be controlled by the user via the ioctl.
Fixes: 5f53d8ca3d5d ("Staging: add rtl8192SU wireless usb driver")
Signed-off-by: Dan Carpenter
---
drivers/staging/rtl8192u/r8192U_wx.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_wx.c
b/drivers/staging/rtl8192u/r8192U_wx.c
index 175bb8b15389..5211b2005763 100644
--- a/drivers/staging/rtl8192u/r8192U_wx.c
+++ b/drivers/staging/rtl8192u/r8192U_wx.c
@@ -331,8 +331,10 @@ static int r8192_wx_set_scan(struct net_device *dev,
struct iw_request_info *a,
struct iw_scan_req *req = (struct iw_scan_req *)b;
if (req->essid_len) {
- ieee->current_network.ssid_len = req->essid_len;
- memcpy(ieee->current_network.ssid, req->essid,
req->essid_len);
+ int len = min_t(int, req->essid_len, IW_ESSID_MAX_SIZE);
+
+ ieee->current_network.ssid_len = len;
+ memcpy(ieee->current_network.ssid, req->essid, len);
}
}
--
2.30.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
