From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
[ Upstream commit 443ef39b499cc9c6635f83238101f1bb923e9326 ]
Sparse is not happy about handling of strict types in pch_ptp_match():
.../pch_gbe_main.c:158:33: warning: incorrect type in argument 2 (different base types)
.../pch_gbe_main.c:158:33: expected unsigned short [usertype] uid_hi
.../pch_gbe_main.c:158:33: got restricted __be16 [usertype]
.../pch_gbe_main.c:158:45: warning: incorrect type in argument 3 (different base types)
.../pch_gbe_main.c:158:45: expected unsigned int [usertype] uid_lo
.../pch_gbe_main.c:158:45: got restricted __be32 [usertype]
.../pch_gbe_main.c:158:56: warning: incorrect type in argument 4 (different base types)
.../pch_gbe_main.c:158:56: expected unsigned short [usertype] seqid
.../pch_gbe_main.c:158:56: got restricted __be16 [usertype]
Fix that by switching to use proper accessors to BE data.
Reported-by: kernel test robot <redacted>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Flavio Suligoi <f.suligoi@asem.it>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
.../ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 19 ++++++-------------
1 file changed, 6 insertions(+), 13 deletions(-)
From: Jesse Brandeburg <redacted>
[ Upstream commit d4ef55288aa2e1b76033717242728ac98ddc4721 ]
Sparse tool was warning on some implicit conversions from
little endian data read from the EEPROM on the e100 cards.
Fix these by being explicit about the conversions using
le16_to_cpu().
Signed-off-by: Jesse Brandeburg <redacted>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/intel/e100.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
@@ -1423,7 +1423,7 @@ static int e100_phy_check_without_mii(struct nic *nic)u8phy_type;intwithout_mii;-phy_type=(nic->eeprom[eeprom_phy_iface]>>8)&0x0f;+phy_type=(le16_to_cpu(nic->eeprom[eeprom_phy_iface])>>8)&0x0f;switch(phy_type){caseNoSuchPhy:/* Non-MII PHY; UNTESTED! */
@@ -1543,7 +1543,7 @@ static int e100_phy_init(struct nic *nic)mdio_write(netdev,nic->mii.phy_id,MII_BMCR,bmcr);}elseif((nic->mac>=mac_82550_D102)||((nic->flags&ich)&&(mdio_read(netdev,nic->mii.phy_id,MII_TPISTATUS)&0x8000)&&-(nic->eeprom[eeprom_cnfg_mdix]&eeprom_mdix_enabled))){+(le16_to_cpu(nic->eeprom[eeprom_cnfg_mdix])&eeprom_mdix_enabled))){/* enable/disable MDI/MDI-X auto-switching. */mdio_write(netdev,nic->mii.phy_id,MII_NCONFIG,nic->mii.force_media?0:NCONFIG_AUTO_SWITCH);
@@ -2298,9 +2298,9 @@ static int e100_asf(struct nic *nic){/* ASF can be enabled from eeprom */return(nic->pdev->device>=0x1050)&&(nic->pdev->device<=0x1057)&&-(nic->eeprom[eeprom_config_asf]&eeprom_asf)&&-!(nic->eeprom[eeprom_config_asf]&eeprom_gcl)&&-((nic->eeprom[eeprom_smbus_addr]&0xFF)!=0xFE);+(le16_to_cpu(nic->eeprom[eeprom_config_asf])&eeprom_asf)&&+!(le16_to_cpu(nic->eeprom[eeprom_config_asf])&eeprom_gcl)&&+((le16_to_cpu(nic->eeprom[eeprom_smbus_addr])&0xFF)!=0xFE);}staticinte100_up(structnic*nic)
@@ -2952,7 +2952,7 @@ static int e100_probe(struct pci_dev *pdev, const struct pci_device_id *ent)/* Wol magic packet can be enabled from eeprom */if((nic->mac>=mac_82558_D101_A4)&&-(nic->eeprom[eeprom_id]&eeprom_id_wol)){+(le16_to_cpu(nic->eeprom[eeprom_id])&eeprom_id_wol)){nic->flags|=wol_magic;device_set_wakeup_enable(&pdev->dev,true);}
From: Willy Tarreau <w@1wt.eu>
[ Upstream commit 62f20e068ccc50d6ab66fdb72ba90da2b9418c99 ]
This is a complement to commit aa6dd211e4b1 ("inet: use bigger hash
table for IP ID generation"), but focusing on some specific aspects
of IPv6.
Contary to IPv4, IPv6 only uses packet IDs with fragments, and with a
minimum MTU of 1280, it's much less easy to force a remote peer to
produce many fragments to explore its ID sequence. In addition packet
IDs are 32-bit in IPv6, which further complicates their analysis. On
the other hand, it is often easier to choose among plenty of possible
source addresses and partially work around the bigger hash table the
commit above permits, which leaves IPv6 partially exposed to some
possibilities of remote analysis at the risk of weakening some
protocols like DNS if some IDs can be predicted with a good enough
probability.
Given the wide range of permitted IDs, the risk of collision is extremely
low so there's no need to rely on the positive increment algorithm that
is shared with the IPv4 code via ip_idents_reserve(). We have a fast
PRNG, so let's simply call prandom_u32() and be done with it.
Performance measurements at 10 Gbps couldn't show any difference with
the previous code, even when using a single core, because due to the
large fragments, we're limited to only ~930 kpps at 10 Gbps and the cost
of the random generation is completely offset by other operations and by
the network transfer time. In addition, this change removes the need to
update a shared entry in the idents table so it may even end up being
slightly faster on large scale systems where this matters.
The risk of at least one collision here is about 1/80 million among
10 IDs, 1/850k among 100 IDs, and still only 1/8.5k among 1000 IDs,
which remains very low compared to IPv4 where all IDs are reused
every 4 to 80ms on a 10 Gbps flow depending on packet sizes.
Reported-by: Amit Klein <redacted>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://lore.kernel.org/r/20210529110746.6796-1-w@1wt.eu
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/ipv6/output_core.c | 28 +++++-----------------------
1 file changed, 5 insertions(+), 23 deletions(-)
@@ -14,29 +14,11 @@ static u32 __ipv6_select_ident(struct net *net,conststructin6_addr*dst,conststructin6_addr*src){-conststruct{-structin6_addrdst;-structin6_addrsrc;-}__aligned(SIPHASH_ALIGNMENT)combined={-.dst=*dst,-.src=*src,-};-u32hash,id;--/* Note the following code is not safe, but this is okay. */-if(unlikely(siphash_key_is_zero(&net->ipv4.ip_id_key)))-get_random_bytes(&net->ipv4.ip_id_key,-sizeof(net->ipv4.ip_id_key));--hash=siphash(&combined,sizeof(combined),&net->ipv4.ip_id_key);--/* Treat id of 0 as unset and if we get 0 back from ip_idents_reserve,-*setthehightorderinsteadthusminimizingpossiblefuture-*collisions.-*/-id=ip_idents_reserve(hash,1);-if(unlikely(!id))-id=1<<31;+u32id;++do{+id=prandom_u32();+}while(!id);returnid;}
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
[ Upstream commit 50619dbf8db77e98d821d615af4f634d08e22698 ]
The first chunk in a packet is ensured to be present at the beginning of
sctp_rcv(), as a packet needs to have at least 1 chunk. But the second
one, may not be completely available and ch->length can be over
uninitialized memory.
Fix here is by only trying to walk on the next chunk if there is enough to
hold at least the header, and then proceed with the ch->length validation
that is already there.
Reported-by: Ilja Van Sprundel <redacted>
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/sctp/input.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Íñigo Huguet <redacted>
[ Upstream commit 45423cff1db66cf0993e8a9bd0ac93e740149e49 ]
If pci_remove was called for a PF with VFs, the removal of the VFs was
called twice from efx_ef10_sriov_fini: one directly with pci_driver->remove
and another implicit by calling pci_disable_sriov, which also perform
the VFs remove. This was leading to crashing the kernel on the second
attempt.
Given that pci_disable_sriov already calls to pci remove function, get
rid of the direct call to pci_driver->remove from the driver.
2 different ways to trigger the bug:
- Create one or more VFs, then attach the PF to a virtual machine (at
least with qemu/KVM)
- Create one or more VFs, then remove the PF with:
echo 1 > /sys/bus/pci/devices/PF_PCI_ID/remove
Removing sfc module does not trigger the error, at least for me, because
it removes the VF first, and then the PF.
Example of a log with the error:
list_del corruption, ffff967fd20a8ad0->next is LIST_POISON1 (dead000000000100)
------------[ cut here ]------------
kernel BUG at lib/list_debug.c:47!
[...trimmed...]
RIP: 0010:__list_del_entry_valid.cold.1+0x12/0x4c
[...trimmed...]
Call Trace:
efx_dissociate+0x1f/0x140 [sfc]
efx_pci_remove+0x27/0x150 [sfc]
pci_device_remove+0x3b/0xc0
device_release_driver_internal+0x103/0x1f0
pci_stop_bus_device+0x69/0x90
pci_stop_and_remove_bus_device+0xe/0x20
pci_iov_remove_virtfn+0xba/0x120
sriov_disable+0x2f/0xe0
efx_ef10_pci_sriov_disable+0x52/0x80 [sfc]
? pcie_aer_is_native+0x12/0x40
efx_ef10_sriov_fini+0x72/0x110 [sfc]
efx_pci_remove+0x62/0x150 [sfc]
pci_device_remove+0x3b/0xc0
device_release_driver_internal+0x103/0x1f0
unbind_store+0xf6/0x130
kernfs_fop_write+0x116/0x190
vfs_write+0xa5/0x1a0
ksys_write+0x4f/0xb0
do_syscall_64+0x5b/0x1a0
entry_SYSCALL_64_after_hwframe+0x65/0xca
Signed-off-by: Íñigo Huguet <redacted>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/sfc/ef10_sriov.c | 10 +---------
1 file changed, 1 insertion(+), 9 deletions(-)
@@ -415,7 +415,6 @@ int efx_ef10_sriov_init(struct efx_nic *efx)voidefx_ef10_sriov_fini(structefx_nic*efx){structefx_ef10_nic_data*nic_data=efx->nic_data;-unsignedinti;intrc;if(!nic_data->vf){
@@ -425,14 +424,7 @@ void efx_ef10_sriov_fini(struct efx_nic *efx)return;}-/* Remove any VFs in the host */-for(i=0;i<efx->vf_count;++i){-structefx_nic*vf_efx=nic_data->vf[i].efx;--if(vf_efx)-vf_efx->pci_dev->driver->remove(vf_efx->pci_dev);-}-+/* Disable SRIOV and remove any VFs in the host */rc=efx_ef10_pci_sriov_disable(efx,true);if(rc)netif_dbg(efx,drv,efx->net_dev,
From: Íñigo Huguet <redacted>
[ Upstream commit 1ebe4feb8b442884f5a28d2437040096723dd1ea ]
If SRIOV cannot be disabled during device removal or module unloading,
return error code so it can be logged properly in the calling function.
Note that this can only happen if any VF is currently attached to a
guest using Xen, but not with vfio/KVM. Despite that in that case the
VFs won't work properly with PF removed and/or the module unloaded, I
have let it as is because I don't know what side effects may have
changing it, and also it seems to be the same that other drivers are
doing in this situation.
In the case of being called during SRIOV reconfiguration, the behavior
hasn't changed because the function is called with force=false.
Signed-off-by: Íñigo Huguet <redacted>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/sfc/ef10_sriov.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
@@ -378,12 +378,17 @@ static int efx_ef10_pci_sriov_enable(struct efx_nic *efx, int num_vfs)returnrc;}+/* Disable SRIOV and remove VFs+*IfsomeVFsareattachedtoaguest(usingXen,only)nothingis+*doneifforce=false,andvportsarefreedifforce=true(forthenon+*attachedcones,only)butSRIOVisnotdisabledandVFsarenot+*removedineithercase.+*/staticintefx_ef10_pci_sriov_disable(structefx_nic*efx,boolforce){structpci_dev*dev=efx->pci_dev;-unsignedintvfs_assigned=0;--vfs_assigned=pci_vfs_assigned(dev);+unsignedintvfs_assigned=pci_vfs_assigned(dev);+intrc=0;if(vfs_assigned&&!force){netif_info(efx,drv,efx->net_dev,"VFs are assigned to guests; "
From: "Gustavo A. R. Silva" <gustavoars@kernel.org>
[ Upstream commit e93bdd78406da9ed01554c51e38b2a02c8ef8025 ]
Fix the following out-of-bounds warning:
net/wireless/wext-spy.c:178:2: warning: 'memcpy' offset [25, 28] from the object at 'threshold' is out of the bounds of referenced subobject 'low' with type 'struct iw_quality' at offset 20 [-Warray-bounds]
The problem is that the original code is trying to copy data into a
couple of struct members adjacent to each other in a single call to
memcpy(). This causes a legitimate compiler warning because memcpy()
overruns the length of &threshold.low and &spydata->spy_thr_low. As
these are just a couple of struct members, fix this by using direct
assignments, instead of memcpy().
This helps with the ongoing efforts to globally enable -Warray-bounds
and get us closer to being able to tighten the FORTIFY_SOURCE routines
on memcpy().
Link: https://github.com/KSPP/linux/issues/109
Reported-by: kernel test robot <redacted>
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: Kees Cook <redacted>
Link: https://lore.kernel.org/r/20210422200032.GA168995@embeddedor
Signed-off-by: Johannes Berg <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/wireless/wext-spy.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
@@ -120,8 +120,8 @@ int iw_handler_set_thrspy(struct net_device * dev,return-EOPNOTSUPP;/* Just do it */-memcpy(&(spydata->spy_thr_low),&(threshold->low),-2*sizeof(structiw_quality));+spydata->spy_thr_low=threshold->low;+spydata->spy_thr_high=threshold->high;/* Clear flag */memset(spydata->spy_thr_under,'\0',sizeof(spydata->spy_thr_under));
@@ -147,8 +147,8 @@ int iw_handler_get_thrspy(struct net_device * dev,return-EOPNOTSUPP;/* Just do it */-memcpy(&(threshold->low),&(spydata->spy_thr_low),-2*sizeof(structiw_quality));+threshold->low=spydata->spy_thr_low;+threshold->high=spydata->spy_thr_high;return0;}
@@ -173,10 +173,10 @@ static void iw_send_thrspy_event(struct net_device * dev,memcpy(threshold.addr.sa_data,address,ETH_ALEN);threshold.addr.sa_family=ARPHRD_ETHER;/* Copy stats */-memcpy(&(threshold.qual),wstats,sizeof(structiw_quality));+threshold.qual=*wstats;/* Copy also thresholds */-memcpy(&(threshold.low),&(spydata->spy_thr_low),-2*sizeof(structiw_quality));+threshold.low=spydata->spy_thr_low;+threshold.high=spydata->spy_thr_high;/* Send event to user space */wireless_send_event(dev,SIOCGIWTHRSPY,&wrqu,(char*)&threshold);
From: Yang Yingliang <redacted>
[ Upstream commit 35cba15a504bf4f585bb9d78f47b22b28a1a06b2 ]
Use devm_platform_get_and_ioremap_resource() to simplify
code and avoid a null-ptr-deref by checking 'res' in it.
Signed-off-by: Yang Yingliang <redacted>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/moxa/moxart_ether.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
[ Upstream commit 8380c81d5c4fced6f4397795a5ae65758272bbfd ]
__napi_schedule_irqoff() is an optimized version of __napi_schedule()
which can be used where it is known that interrupts are disabled,
e.g. in interrupt-handlers, spin_lock_irq() sections or hrtimer
callbacks.
On PREEMPT_RT enabled kernels this assumptions is not true. Force-
threaded interrupt handlers and spinlocks are not disabling interrupts
and the NAPI hrtimer callback is forced into softirq context which runs
with interrupts enabled as well.
Chasing all usage sites of __napi_schedule_irqoff() is a whack-a-mole
game so make __napi_schedule_irqoff() invoke __napi_schedule() for
PREEMPT_RT kernels.
The callers of ____napi_schedule() in the networking core have been
audited and are correct on PREEMPT_RT kernels as well.
Reported-by: Juri Lelli <juri.lelli@redhat.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-by: Thomas Gleixner <redacted>
Reviewed-by: Juri Lelli <juri.lelli@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/core/dev.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
From: Yu Liu <redacted>
[ Upstream commit 4ef36a52b0e47c80bbfd69c0cce61c7ae9f541ed ]
0x2B, 0x31 and 0x33 are reserved for future use but were not present in
the HCI to MGMT conversion table, this caused the conversion to be
incorrect for the HCI status code greater than 0x2A.
Reviewed-by: Miao-chen Chou <redacted>
Signed-off-by: Yu Liu <redacted>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/bluetooth/mgmt.c | 3 +++
1 file changed, 3 insertions(+)
@@ -212,12 +212,15 @@ static u8 mgmt_status_table[] = {MGMT_STATUS_TIMEOUT,/* Instant Passed */MGMT_STATUS_NOT_SUPPORTED,/* Pairing Not Supported */MGMT_STATUS_FAILED,/* Transaction Collision */+MGMT_STATUS_FAILED,/* Reserved for future use */MGMT_STATUS_INVALID_PARAMS,/* Unacceptable Parameter */MGMT_STATUS_REJECTED,/* QoS Rejected */MGMT_STATUS_NOT_SUPPORTED,/* Classification Not Supported */MGMT_STATUS_REJECTED,/* Insufficient Security */MGMT_STATUS_INVALID_PARAMS,/* Parameter Out Of Range */+MGMT_STATUS_FAILED,/* Reserved for future use */MGMT_STATUS_BUSY,/* Role Switch Pending */+MGMT_STATUS_FAILED,/* Reserved for future use */MGMT_STATUS_FAILED,/* Slot Violation */MGMT_STATUS_FAILED,/* Role Switch Failed */MGMT_STATUS_INVALID_PARAMS,/* EIR Too Large */
@@ -525,6 +525,15 @@ static int ns_init_card(int i, struct pci_dev *pcidev)/* Set the VPI/VCI MSb mask to zero so we can receive OAM cells */writel(0x00000000,card->membase+VPM);+card->intcnt=0;+if(request_irq+(pcidev->irq,&ns_irq_handler,IRQF_SHARED,"nicstar",card)!=0){+pr_err("nicstar%d: can't allocate IRQ %d.\n",i,pcidev->irq);+error=9;+ns_init_card_error(card,error);+returnerror;+}+/* Initialize TSQ */card->tsq.org=dma_alloc_coherent(&card->pcidev->dev,NS_TSQSIZE+NS_TSQ_ALIGNMENT,
@@ -751,15 +760,6 @@ static int ns_init_card(int i, struct pci_dev *pcidev)card->efbie=1;-card->intcnt=0;-if(request_irq-(pcidev->irq,&ns_irq_handler,IRQF_SHARED,"nicstar",card)!=0){-printk("nicstar%d: can't allocate IRQ %d.\n",i,pcidev->irq);-error=9;-ns_init_card_error(card,error);-returnerror;-}-/* Register device */card->atmdev=atm_dev_register("nicstar",&card->pcidev->dev,&atm_ops,-1,NULL);
From: Zou Wei <redacted>
[ Upstream commit 34e7434ba4e97f4b85c1423a59b2922ba7dff2ea ]
This module's remove path calls del_timer(). However, that function
does not wait until the timer handler finishes. This means that the
timer handler may still be running after the driver's remove function
has finished, which would result in a use-after-free.
Fix by calling del_timer_sync(), which makes sure the timer handler
has finished, and unable to re-schedule itself.
Reported-by: Hulk Robot <redacted>
Signed-off-by: Zou Wei <redacted>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/atm/nicstar.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Zou Wei <redacted>
[ Upstream commit 009fc857c5f6fda81f2f7dd851b2d54193a8e733 ]
This module's remove path calls del_timer(). However, that function
does not wait until the timer handler finishes. This means that the
timer handler may still be running after the driver's remove function
has finished, which would result in a use-after-free.
Fix by calling del_timer_sync(), which makes sure the timer handler
has finished, and unable to re-schedule itself.
Reported-by: Hulk Robot <redacted>
Signed-off-by: Zou Wei <redacted>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/isdn/hardware/mISDN/hfcpci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Zou Wei <redacted>
[ Upstream commit 1c72e6ab66b9598cac741ed397438a52065a8f1f ]
This module's remove path calls del_timer(). However, that function
does not wait until the timer handler finishes. This means that the
timer handler may still be running after the driver's remove function
has finished, which would result in a use-after-free.
Fix by calling del_timer_sync(), which makes sure the timer handler
has finished, and unable to re-schedule itself.
Reported-by: Hulk Robot <redacted>
Signed-off-by: Zou Wei <redacted>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/atm/iphase.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Zou Wei <redacted>
[ Upstream commit dd778f89225cd258e8f0fed2b7256124982c8bb5 ]
This patch adds missing MODULE_DEVICE_TABLE definition which generates
correct modalias for automatic loading of this driver when it is built
as an external module.
Reported-by: Hulk Robot <redacted>
Signed-off-by: Zou Wei <redacted>
Signed-off-by: Kalle Valo <redacted>
Link: https://lore.kernel.org/r/1620788714-14300-1-git-send-email-zou_wei@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/cw1200/cw1200_sdio.c | 1 +
1 file changed, 1 insertion(+)
From: Lee Gibson <redacted>
[ Upstream commit d10a87a3535cce2b890897914f5d0d83df669c63 ]
Function wl1251_cmd_scan calls memcpy without checking the length.
Harden by checking the length is within the maximum allowed size.
Signed-off-by: Lee Gibson <redacted>
Signed-off-by: Kalle Valo <redacted>
Link: https://lore.kernel.org/r/20210428115508.25624-1-leegib@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/ti/wl1251/cmd.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
From: Steffen Klassert <steffen.klassert@secunet.com>
[ Upstream commit 6fd06963fa74197103cdbb4b494763127b3f2f34 ]
When memory allocation for XFRMA_ENCAP or XFRMA_COADDR fails,
the error will not be reported because the -ENOMEM assignment
to the err variable is overwritten before. Fix this by moving
these two in front of the function so that memory allocation
failures will be reported.
Reported-by: Tobias Brunner <redacted>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/xfrm/xfrm_user.c | 28 ++++++++++++++--------------
1 file changed, 14 insertions(+), 14 deletions(-)
From: Yang Yingliang <redacted>
[ Upstream commit 20f1932e2282c58cb5ac59517585206cf5b385ae ]
It will cause null-ptr-deref if platform_get_resource() returns NULL,
we need check the return value.
Signed-off-by: Yang Yingliang <redacted>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/micrel/ks8842.c | 4 ++++
1 file changed, 4 insertions(+)
From: Tony Lindgren <tony@atomide.com>
[ Upstream commit 11ef6bc846dcdce838f0b00c5f6a562c57e5d43b ]
At least on wl12xx, reading the MAC after boot can fail with a warning
at drivers/net/wireless/ti/wlcore/sdio.c:78 wl12xx_sdio_raw_read.
The failed call comes from wl12xx_get_mac() that wlcore_nvs_cb() calls
after request_firmware_work_func().
After the error, no wireless interface is created. Reloading the wl12xx
module makes the interface work.
Turns out the wlan controller can be in a low-power ELP state after the
boot from the bootloader or kexec, and needs to be woken up first.
Let's wake the hardware and add a sleep after that similar to
wl12xx_pre_boot() is already doing.
Note that a similar issue could exist for wl18xx, but I have not seen it
so far. And a search for wl18xx_get_mac and wl12xx_sdio_raw_read did not
produce similar errors.
Cc: Carl Philipp Klemm <redacted>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Kalle Valo <redacted>
Link: https://lore.kernel.org/r/20210603062814.19464-1-tony@atomide.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/ti/wl12xx/main.c | 7 +++++++
1 file changed, 7 insertions(+)
@@ -1515,6 +1515,13 @@ static int wl12xx_get_fuse_mac(struct wl1271 *wl)u32mac1,mac2;intret;+/* Device may be in ELP from the bootloader or kexec */+ret=wlcore_write32(wl,WL12XX_WELP_ARM_COMMAND,WELP_ARM_COMMAND_VAL);+if(ret<0)+gotoout;++usleep_range(500000,700000);+ret=wlcore_set_partition(wl,&wl->ptable[PART_DRPW]);if(ret<0)gotoout;