* [PATCH AUTOSEL 5.4 03/19] mac80211: do not access the IV when it was stripped
[not found] <20211126023448.442529-1-sashal@kernel.org>
@ 2021-11-26 2:34 ` Sasha Levin
2021-11-26 2:34 ` [PATCH AUTOSEL 5.4 04/19] tun: fix bonding active backup with arp monitoring Sasha Levin
` (6 subsequent siblings)
7 siblings, 0 replies; 8+ messages in thread
From: Sasha Levin @ 2021-11-26 2:34 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Xing Song, Johannes Berg, Sasha Levin, johannes, davem, kuba,
matthias.bgg, linux-wireless, netdev, linux-arm-kernel,
linux-mediatek
From: Xing Song <xing.song@mediatek.com>
[ Upstream commit 77dfc2bc0bb4b8376ecd7a430f27a4a8fff6a5a0 ]
ieee80211_get_keyid() will return false value if IV has been stripped,
such as return 0 for IP/ARP frames due to LLC header, and return -EINVAL
for disassociation frames due to its length... etc. Don't try to access
it if it's not present.
Signed-off-by: Xing Song <xing.song@mediatek.com>
Link: https://lore.kernel.org/r/20211101024657.143026-1-xing.song@mediatek.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/mac80211/rx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index c7e6bf7c22c78..282bf336b15a4 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -1918,7 +1918,8 @@ ieee80211_rx_h_decrypt(struct ieee80211_rx_data *rx)
int keyid = rx->sta->ptk_idx;
sta_ptk = rcu_dereference(rx->sta->ptk[keyid]);
- if (ieee80211_has_protected(fc)) {
+ if (ieee80211_has_protected(fc) &&
+ !(status->flag & RX_FLAG_IV_STRIPPED)) {
cs = rx->sta->cipher_scheme;
keyid = ieee80211_get_keyid(rx->skb, cs);
--
2.33.0
^ permalink raw reply related [flat|nested] 8+ messages in thread* [PATCH AUTOSEL 5.4 04/19] tun: fix bonding active backup with arp monitoring
[not found] <20211126023448.442529-1-sashal@kernel.org>
2021-11-26 2:34 ` [PATCH AUTOSEL 5.4 03/19] mac80211: do not access the IV when it was stripped Sasha Levin
@ 2021-11-26 2:34 ` Sasha Levin
2021-11-26 2:34 ` [PATCH AUTOSEL 5.4 05/19] net/smc: Transfer remaining wait queue entries during fallback Sasha Levin
` (5 subsequent siblings)
7 siblings, 0 replies; 8+ messages in thread
From: Sasha Levin @ 2021-11-26 2:34 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Nicolas Dichtel, David S . Miller, Sasha Levin, kuba, netdev
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
[ Upstream commit a31d27fbed5d518734cb60956303eb15089a7634 ]
As stated in the bonding doc, trans_start must be set manually for drivers
using NETIF_F_LLTX:
Drivers that use NETIF_F_LLTX flag must also update
netdev_queue->trans_start. If they do not, then the ARP monitor will
immediately fail any slaves using that driver, and those slaves will stay
down.
Link: https://www.kernel.org/doc/html/v5.15/networking/bonding.html#arp-monitor-operation
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/tun.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 7c40ae058e6d1..10211ea605140 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1071,6 +1071,7 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct tun_struct *tun = netdev_priv(dev);
int txq = skb->queue_mapping;
+ struct netdev_queue *queue;
struct tun_file *tfile;
int len = skb->len;
@@ -1117,6 +1118,10 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
if (ptr_ring_produce(&tfile->tx_ring, skb))
goto drop;
+ /* NETIF_F_LLTX requires to do our own update of trans_start */
+ queue = netdev_get_tx_queue(dev, txq);
+ queue->trans_start = jiffies;
+
/* Notify and wake up reader process */
if (tfile->flags & TUN_FASYNC)
kill_fasync(&tfile->fasync, SIGIO, POLL_IN);
--
2.33.0
^ permalink raw reply related [flat|nested] 8+ messages in thread* [PATCH AUTOSEL 5.4 05/19] net/smc: Transfer remaining wait queue entries during fallback
[not found] <20211126023448.442529-1-sashal@kernel.org>
2021-11-26 2:34 ` [PATCH AUTOSEL 5.4 03/19] mac80211: do not access the IV when it was stripped Sasha Levin
2021-11-26 2:34 ` [PATCH AUTOSEL 5.4 04/19] tun: fix bonding active backup with arp monitoring Sasha Levin
@ 2021-11-26 2:34 ` Sasha Levin
2021-11-26 2:34 ` [PATCH AUTOSEL 5.4 06/19] atlantic: Fix OOB read and write in hw_atl_utils_fw_rpc_wait Sasha Levin
` (4 subsequent siblings)
7 siblings, 0 replies; 8+ messages in thread
From: Sasha Levin @ 2021-11-26 2:34 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Wen Gu, Tony Lu, David S . Miller, Sasha Levin, kgraul, kuba,
linux-s390, netdev
From: Wen Gu <guwen@linux.alibaba.com>
[ Upstream commit 2153bd1e3d3dbf6a3403572084ef6ed31c53c5f0 ]
The SMC fallback is incomplete currently. There may be some
wait queue entries remaining in smc socket->wq, which should
be removed to clcsocket->wq during the fallback.
For example, in nginx/wrk benchmark, this issue causes an
all-zeros test result:
server: nginx -g 'daemon off;'
client: smc_run wrk -c 1 -t 1 -d 5 http://11.200.15.93/index.html
Running 5s test @ http://11.200.15.93/index.html
1 threads and 1 connections
Thread Stats Avg Stdev Max ± Stdev
Latency 0.00us 0.00us 0.00us -nan%
Req/Sec 0.00 0.00 0.00 -nan%
0 requests in 5.00s, 0.00B read
Requests/sec: 0.00
Transfer/sec: 0.00B
The reason for this all-zeros result is that when wrk used SMC
to replace TCP, it added an eppoll_entry into smc socket->wq
and expected to be notified if epoll events like EPOLL_IN/
EPOLL_OUT occurred on the smc socket.
However, once a fallback occurred, wrk switches to use clcsocket.
Now it is clcsocket->wq instead of smc socket->wq which will
be woken up. The eppoll_entry remaining in smc socket->wq does
not work anymore and wrk stops the test.
This patch fixes this issue by removing remaining wait queue
entries from smc socket->wq to clcsocket->wq during the fallback.
Link: https://www.spinics.net/lists/netdev/msg779769.html
Signed-off-by: Wen Gu <guwen@linux.alibaba.com>
Reviewed-by: Tony Lu <tonylu@linux.alibaba.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/smc/af_smc.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
index 6b0f09c5b195f..1fad05d6dd9ad 100644
--- a/net/smc/af_smc.c
+++ b/net/smc/af_smc.c
@@ -467,12 +467,26 @@ static void smc_link_save_peer_info(struct smc_link *link,
static void smc_switch_to_fallback(struct smc_sock *smc)
{
+ wait_queue_head_t *smc_wait = sk_sleep(&smc->sk);
+ wait_queue_head_t *clc_wait = sk_sleep(smc->clcsock->sk);
+ unsigned long flags;
+
smc->use_fallback = true;
if (smc->sk.sk_socket && smc->sk.sk_socket->file) {
smc->clcsock->file = smc->sk.sk_socket->file;
smc->clcsock->file->private_data = smc->clcsock;
smc->clcsock->wq.fasync_list =
smc->sk.sk_socket->wq.fasync_list;
+
+ /* There may be some entries remaining in
+ * smc socket->wq, which should be removed
+ * to clcsocket->wq during the fallback.
+ */
+ spin_lock_irqsave(&smc_wait->lock, flags);
+ spin_lock(&clc_wait->lock);
+ list_splice_init(&smc_wait->head, &clc_wait->head);
+ spin_unlock(&clc_wait->lock);
+ spin_unlock_irqrestore(&smc_wait->lock, flags);
}
}
--
2.33.0
^ permalink raw reply related [flat|nested] 8+ messages in thread* [PATCH AUTOSEL 5.4 06/19] atlantic: Fix OOB read and write in hw_atl_utils_fw_rpc_wait
[not found] <20211126023448.442529-1-sashal@kernel.org>
` (2 preceding siblings ...)
2021-11-26 2:34 ` [PATCH AUTOSEL 5.4 05/19] net/smc: Transfer remaining wait queue entries during fallback Sasha Levin
@ 2021-11-26 2:34 ` Sasha Levin
2021-11-26 2:34 ` [PATCH AUTOSEL 5.4 07/19] net: return correct error code Sasha Levin
` (3 subsequent siblings)
7 siblings, 0 replies; 8+ messages in thread
From: Sasha Levin @ 2021-11-26 2:34 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Zekun Shen, Brendan Dolan-Gavitt, David S . Miller, Sasha Levin,
irusskikh, kuba, netdev
From: Zekun Shen <bruceshenzk@gmail.com>
[ Upstream commit b922f622592af76b57cbc566eaeccda0b31a3496 ]
This bug report shows up when running our research tools. The
reports is SOOB read, but it seems SOOB write is also possible
a few lines below.
In details, fw.len and sw.len are inputs coming from io. A len
over the size of self->rpc triggers SOOB. The patch fixes the
bugs by adding sanity checks.
The bugs are triggerable with compromised/malfunctioning devices.
They are potentially exploitable given they first leak up to
0xffff bytes and able to overwrite the region later.
The patch is tested with QEMU emulater.
This is NOT tested with a real device.
Attached is the log we found by fuzzing.
BUG: KASAN: slab-out-of-bounds in
hw_atl_utils_fw_upload_dwords+0x393/0x3c0 [atlantic]
Read of size 4 at addr ffff888016260b08 by task modprobe/213
CPU: 0 PID: 213 Comm: modprobe Not tainted 5.6.0 #1
Call Trace:
dump_stack+0x76/0xa0
print_address_description.constprop.0+0x16/0x200
? hw_atl_utils_fw_upload_dwords+0x393/0x3c0 [atlantic]
? hw_atl_utils_fw_upload_dwords+0x393/0x3c0 [atlantic]
__kasan_report.cold+0x37/0x7c
? aq_hw_read_reg_bit+0x60/0x70 [atlantic]
? hw_atl_utils_fw_upload_dwords+0x393/0x3c0 [atlantic]
kasan_report+0xe/0x20
hw_atl_utils_fw_upload_dwords+0x393/0x3c0 [atlantic]
hw_atl_utils_fw_rpc_call+0x95/0x130 [atlantic]
hw_atl_utils_fw_rpc_wait+0x176/0x210 [atlantic]
hw_atl_utils_mpi_create+0x229/0x2e0 [atlantic]
? hw_atl_utils_fw_rpc_wait+0x210/0x210 [atlantic]
? hw_atl_utils_initfw+0x9f/0x1c8 [atlantic]
hw_atl_utils_initfw+0x12a/0x1c8 [atlantic]
aq_nic_ndev_register+0x88/0x650 [atlantic]
? aq_nic_ndev_init+0x235/0x3c0 [atlantic]
aq_pci_probe+0x731/0x9b0 [atlantic]
? aq_pci_func_init+0xc0/0xc0 [atlantic]
local_pci_probe+0xd3/0x160
pci_device_probe+0x23f/0x3e0
Reported-by: Brendan Dolan-Gavitt <brendandg@nyu.edu>
Signed-off-by: Zekun Shen <bruceshenzk@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
.../ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c
index 873f9865f0d15..b7d70c33459fd 100644
--- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c
+++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c
@@ -481,6 +481,11 @@ int hw_atl_utils_fw_rpc_wait(struct aq_hw_s *self,
goto err_exit;
if (fw.len == 0xFFFFU) {
+ if (sw.len > sizeof(self->rpc)) {
+ printk(KERN_INFO "Invalid sw len: %x\n", sw.len);
+ err = -EINVAL;
+ goto err_exit;
+ }
err = hw_atl_utils_fw_rpc_call(self, sw.len);
if (err < 0)
goto err_exit;
@@ -489,6 +494,11 @@ int hw_atl_utils_fw_rpc_wait(struct aq_hw_s *self,
if (rpc) {
if (fw.len) {
+ if (fw.len > sizeof(self->rpc)) {
+ printk(KERN_INFO "Invalid fw len: %x\n", fw.len);
+ err = -EINVAL;
+ goto err_exit;
+ }
err =
hw_atl_utils_fw_downld_dwords(self,
self->rpc_addr,
--
2.33.0
^ permalink raw reply related [flat|nested] 8+ messages in thread* [PATCH AUTOSEL 5.4 07/19] net: return correct error code
[not found] <20211126023448.442529-1-sashal@kernel.org>
` (3 preceding siblings ...)
2021-11-26 2:34 ` [PATCH AUTOSEL 5.4 06/19] atlantic: Fix OOB read and write in hw_atl_utils_fw_rpc_wait Sasha Levin
@ 2021-11-26 2:34 ` Sasha Levin
2021-11-26 2:34 ` [PATCH AUTOSEL 5.4 15/19] ethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port() Sasha Levin
` (2 subsequent siblings)
7 siblings, 0 replies; 8+ messages in thread
From: Sasha Levin @ 2021-11-26 2:34 UTC (permalink / raw)
To: linux-kernel, stable
Cc: liuguoqiang, David S . Miller, Sasha Levin, yoshfuji, dsahern,
kuba, netdev
From: liuguoqiang <liuguoqiang@uniontech.com>
[ Upstream commit 6def480181f15f6d9ec812bca8cbc62451ba314c ]
When kmemdup called failed and register_net_sysctl return NULL, should
return ENOMEM instead of ENOBUFS
Signed-off-by: liuguoqiang <liuguoqiang@uniontech.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/ipv4/devinet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 603a3495afa62..4a8ad46397c0e 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -2585,7 +2585,7 @@ static int __devinet_sysctl_register(struct net *net, char *dev_name,
free:
kfree(t);
out:
- return -ENOBUFS;
+ return -ENOMEM;
}
static void __devinet_sysctl_unregister(struct net *net,
--
2.33.0
^ permalink raw reply related [flat|nested] 8+ messages in thread* [PATCH AUTOSEL 5.4 15/19] ethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port()
[not found] <20211126023448.442529-1-sashal@kernel.org>
` (4 preceding siblings ...)
2021-11-26 2:34 ` [PATCH AUTOSEL 5.4 07/19] net: return correct error code Sasha Levin
@ 2021-11-26 2:34 ` Sasha Levin
2021-11-26 2:34 ` [PATCH AUTOSEL 5.4 16/19] net: tulip: de4x5: fix the problem that the array 'lp->phy[8]' may be out of bound Sasha Levin
2021-11-26 2:34 ` [PATCH AUTOSEL 5.4 17/19] net: ethernet: dec: tulip: de4x5: fix possible array overflows in type3_infoblock() Sasha Levin
7 siblings, 0 replies; 8+ messages in thread
From: Sasha Levin @ 2021-11-26 2:34 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Teng Qi, TOTE Robot, David S . Miller, Sasha Levin, yisen.zhuang,
salil.mehta, kuba, lipeng321, huangguangbin2, liuyonglong,
zhengyongjun3, shenyang39, netdev
From: Teng Qi <starmiku1207184332@gmail.com>
[ Upstream commit a66998e0fbf213d47d02813b9679426129d0d114 ]
The if statement:
if (port >= DSAF_GE_NUM)
return;
limits the value of port less than DSAF_GE_NUM (i.e., 8).
However, if the value of port is 6 or 7, an array overflow could occur:
port_rst_off = dsaf_dev->mac_cb[port]->port_rst_off;
because the length of dsaf_dev->mac_cb is DSAF_MAX_PORT_NUM (i.e., 6).
To fix this possible array overflow, we first check port and if it is
greater than or equal to DSAF_MAX_PORT_NUM, the function returns.
Reported-by: TOTE Robot <oslab@tsinghua.edu.cn>
Signed-off-by: Teng Qi <starmiku1207184332@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
index ed3829ae4ef1b..580199fdd0c22 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
@@ -398,6 +398,10 @@ static void hns_dsaf_ge_srst_by_port(struct dsaf_device *dsaf_dev, u32 port,
return;
if (!HNS_DSAF_IS_DEBUG(dsaf_dev)) {
+ /* DSAF_MAX_PORT_NUM is 6, but DSAF_GE_NUM is 8.
+ We need check to prevent array overflow */
+ if (port >= DSAF_MAX_PORT_NUM)
+ return;
reg_val_1 = 0x1 << port;
port_rst_off = dsaf_dev->mac_cb[port]->port_rst_off;
/* there is difference between V1 and V2 in register.*/
--
2.33.0
^ permalink raw reply related [flat|nested] 8+ messages in thread* [PATCH AUTOSEL 5.4 16/19] net: tulip: de4x5: fix the problem that the array 'lp->phy[8]' may be out of bound
[not found] <20211126023448.442529-1-sashal@kernel.org>
` (5 preceding siblings ...)
2021-11-26 2:34 ` [PATCH AUTOSEL 5.4 15/19] ethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port() Sasha Levin
@ 2021-11-26 2:34 ` Sasha Levin
2021-11-26 2:34 ` [PATCH AUTOSEL 5.4 17/19] net: ethernet: dec: tulip: de4x5: fix possible array overflows in type3_infoblock() Sasha Levin
7 siblings, 0 replies; 8+ messages in thread
From: Sasha Levin @ 2021-11-26 2:34 UTC (permalink / raw)
To: linux-kernel, stable
Cc: zhangyue, David S . Miller, Sasha Levin, kuba, arnd,
starmiku1207184332, tanghui20, netdev, linux-parisc
From: zhangyue <zhangyue1@kylinos.cn>
[ Upstream commit 61217be886b5f7402843677e4be7e7e83de9cb41 ]
In line 5001, if all id in the array 'lp->phy[8]' is not 0, when the
'for' end, the 'k' is 8.
At this time, the array 'lp->phy[8]' may be out of bound.
Signed-off-by: zhangyue <zhangyue1@kylinos.cn>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/dec/tulip/de4x5.c | 30 +++++++++++++++-----------
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/dec/tulip/de4x5.c b/drivers/net/ethernet/dec/tulip/de4x5.c
index c813e6f2b371e..a80252973171f 100644
--- a/drivers/net/ethernet/dec/tulip/de4x5.c
+++ b/drivers/net/ethernet/dec/tulip/de4x5.c
@@ -4999,19 +4999,23 @@ mii_get_phy(struct net_device *dev)
}
if ((j == limit) && (i < DE4X5_MAX_MII)) {
for (k=0; k < DE4X5_MAX_PHY && lp->phy[k].id; k++);
- lp->phy[k].addr = i;
- lp->phy[k].id = id;
- lp->phy[k].spd.reg = GENERIC_REG; /* ANLPA register */
- lp->phy[k].spd.mask = GENERIC_MASK; /* 100Mb/s technologies */
- lp->phy[k].spd.value = GENERIC_VALUE; /* TX & T4, H/F Duplex */
- lp->mii_cnt++;
- lp->active++;
- printk("%s: Using generic MII device control. If the board doesn't operate,\nplease mail the following dump to the author:\n", dev->name);
- j = de4x5_debug;
- de4x5_debug |= DEBUG_MII;
- de4x5_dbg_mii(dev, k);
- de4x5_debug = j;
- printk("\n");
+ if (k < DE4X5_MAX_PHY) {
+ lp->phy[k].addr = i;
+ lp->phy[k].id = id;
+ lp->phy[k].spd.reg = GENERIC_REG; /* ANLPA register */
+ lp->phy[k].spd.mask = GENERIC_MASK; /* 100Mb/s technologies */
+ lp->phy[k].spd.value = GENERIC_VALUE; /* TX & T4, H/F Duplex */
+ lp->mii_cnt++;
+ lp->active++;
+ printk("%s: Using generic MII device control. If the board doesn't operate,\nplease mail the following dump to the author:\n", dev->name);
+ j = de4x5_debug;
+ de4x5_debug |= DEBUG_MII;
+ de4x5_dbg_mii(dev, k);
+ de4x5_debug = j;
+ printk("\n");
+ } else {
+ goto purgatory;
+ }
}
}
purgatory:
--
2.33.0
^ permalink raw reply related [flat|nested] 8+ messages in thread* [PATCH AUTOSEL 5.4 17/19] net: ethernet: dec: tulip: de4x5: fix possible array overflows in type3_infoblock()
[not found] <20211126023448.442529-1-sashal@kernel.org>
` (6 preceding siblings ...)
2021-11-26 2:34 ` [PATCH AUTOSEL 5.4 16/19] net: tulip: de4x5: fix the problem that the array 'lp->phy[8]' may be out of bound Sasha Levin
@ 2021-11-26 2:34 ` Sasha Levin
7 siblings, 0 replies; 8+ messages in thread
From: Sasha Levin @ 2021-11-26 2:34 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Teng Qi, TOTE Robot, Arnd Bergmann, David S . Miller, Sasha Levin,
kuba, tanghui20, zhangyue1, netdev, linux-parisc
From: Teng Qi <starmiku1207184332@gmail.com>
[ Upstream commit 0fa68da72c3be09e06dd833258ee89c33374195f ]
The definition of macro MOTO_SROM_BUG is:
#define MOTO_SROM_BUG (lp->active == 8 && (get_unaligned_le32(
dev->dev_addr) & 0x00ffffff) == 0x3e0008)
and the if statement
if (MOTO_SROM_BUG) lp->active = 0;
using this macro indicates lp->active could be 8. If lp->active is 8 and
the second comparison of this macro is false. lp->active will remain 8 in:
lp->phy[lp->active].gep = (*p ? p : NULL); p += (2 * (*p) + 1);
lp->phy[lp->active].rst = (*p ? p : NULL); p += (2 * (*p) + 1);
lp->phy[lp->active].mc = get_unaligned_le16(p); p += 2;
lp->phy[lp->active].ana = get_unaligned_le16(p); p += 2;
lp->phy[lp->active].fdx = get_unaligned_le16(p); p += 2;
lp->phy[lp->active].ttm = get_unaligned_le16(p); p += 2;
lp->phy[lp->active].mci = *p;
However, the length of array lp->phy is 8, so array overflows can occur.
To fix these possible array overflows, we first check lp->active and then
return -EINVAL if it is greater or equal to ARRAY_SIZE(lp->phy) (i.e. 8).
Reported-by: TOTE Robot <oslab@tsinghua.edu.cn>
Signed-off-by: Teng Qi <starmiku1207184332@gmail.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/dec/tulip/de4x5.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/dec/tulip/de4x5.c b/drivers/net/ethernet/dec/tulip/de4x5.c
index a80252973171f..c97fc0e384ca6 100644
--- a/drivers/net/ethernet/dec/tulip/de4x5.c
+++ b/drivers/net/ethernet/dec/tulip/de4x5.c
@@ -4708,6 +4708,10 @@ type3_infoblock(struct net_device *dev, u_char count, u_char *p)
lp->ibn = 3;
lp->active = *p++;
if (MOTO_SROM_BUG) lp->active = 0;
+ /* if (MOTO_SROM_BUG) statement indicates lp->active could
+ * be 8 (i.e. the size of array lp->phy) */
+ if (WARN_ON(lp->active >= ARRAY_SIZE(lp->phy)))
+ return -EINVAL;
lp->phy[lp->active].gep = (*p ? p : NULL); p += (2 * (*p) + 1);
lp->phy[lp->active].rst = (*p ? p : NULL); p += (2 * (*p) + 1);
lp->phy[lp->active].mc = get_unaligned_le16(p); p += 2;
--
2.33.0
^ permalink raw reply related [flat|nested] 8+ messages in thread