* Re: [PATCH] marvell wireless: cleanup -- make error values consistent
From: Kalle Valo @ 2019-07-24 11:39 UTC (permalink / raw)
To: Pavel Machek
Cc: amitkarwar, nishants, gbhat, huxinming820, davem, linux-wireless,
netdev, linux-kernel
In-Reply-To: <20190724095015.GA6592@amd>
Pavel Machek <pavel@ucw.cz> wrote:
> Surrounding code uses -ERRNO as a result, so don't pass plain -1.
>
> Signed-off-by: Pavel Machek <pavel@denx.de>
The title prefix should be "mwifiex:", I'll fix that.
--
https://patchwork.kernel.org/patch/11056525/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v3 6/7] net: Rename skb_frag_t size to bv_len
From: Matthew Wilcox @ 2019-07-24 11:41 UTC (permalink / raw)
To: David Laight; +Cc: davem@davemloft.net, hch@lst.de, netdev@vger.kernel.org
In-Reply-To: <b47b0b19e5594b97af62352dc0dbffcc@AcuMS.aculab.com>
On Wed, Jul 24, 2019 at 10:49:03AM +0000, David Laight wrote:
> This is 'just plain stupid'.
> The 'bv_' prefix of the members of 'struct bvec' is there so that 'grep'
> (etc) can be used to find the uses of the members.
>
> In a 'struct skb_frag_struct' a sensible prefix might be 'sf_'.
>
> OTOH it might be sensible to use (or embed) a 'struct bvec'
> instead of 'skb_frag_struct'.
Maybe you should read patch 7/7. Or 0/7.
^ permalink raw reply
* Re: [PATCH] rsi: return explicit error values
From: Kalle Valo @ 2019-07-24 11:42 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: linux-kernel, amitkarwar, siva8118, linux-wireless, netdev
In-Reply-To: <1561645802-1279-1-git-send-email-info@metux.net>
"Enrico Weigelt, metux IT consult" <info@metux.net> wrote:
> From: Enrico Weigelt <info@metux.net>
>
> Explicitly return constants instead of variable (and rely on
> it to be explicitly initialized), if the value is supposed
> to be fixed anyways. Align it with the rest of the driver,
> which does it the same way.
>
> Signed-off-by: Enrico Weigelt <info@metux.net>
Patch applied to wireless-drivers-next.git, thanks.
231e83fdcd03 rsi: return explicit error values
--
https://patchwork.kernel.org/patch/11019801/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2 2/2] rt2x00usb: remove unnecessary rx flag checks
From: Kalle Valo @ 2019-07-24 11:42 UTC (permalink / raw)
To: Soeren Moch
Cc: Stanislaw Gruszka, Soeren Moch, Helmut Schaa, David S. Miller,
linux-wireless, netdev, linux-kernel
In-Reply-To: <20190701105314.9707-2-smoch@web.de>
Soeren Moch <smoch@web.de> wrote:
> In contrast to the TX path, there is no need to separately read the transfer
> status from the device after receiving RX data. Consequently, there is no
> real STATUS_PENDING RX processing queue entry state.
> Remove the unnecessary ENTRY_DATA_STATUS_PENDING flag checks from the RX path.
> Also remove the misleading comment about reading RX status from device.
>
> Suggested-by: Stanislaw Gruszka <sgruszka@redhat.com>
> Signed-off-by: Soeren Moch <smoch@web.de>
> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Patch applied to wireless-drivers-next.git, thanks.
3b902fa811cf rt2x00usb: remove unnecessary rx flag checks
--
https://patchwork.kernel.org/patch/11025559/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2] rt2x00: no need to check return value of debugfs_create functions
From: Kalle Valo @ 2019-07-24 11:43 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Stanislaw Gruszka, Helmut Schaa, David S. Miller, linux-wireless,
netdev
In-Reply-To: <20190703113956.GA26652@kroah.com>
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Because we don't need to save the individual debugfs files and
> directories, remove the local storage of them and just remove the entire
> debugfs directory in a single call, making things a lot simpler.
>
> Cc: Stanislaw Gruszka <sgruszka@redhat.com>
> Cc: Helmut Schaa <helmut.schaa@googlemail.com>
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: linux-wireless@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Patch applied to wireless-drivers-next.git, thanks.
1dc244064c47 rt2x00: no need to check return value of debugfs_create functions
--
https://patchwork.kernel.org/patch/11029367/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU
From: Kalle Valo @ 2019-07-24 11:44 UTC (permalink / raw)
To: Chris Chiu
Cc: jes.sorensen, davem, linux-wireless, netdev, linux-kernel, linux
In-Reply-To: <20190704105528.74028-1-chiu@endlessm.com>
Chris Chiu <chiu@endlessm.com> wrote:
> The WiFi tx power of RTL8723BU is extremely low after booting. So
> the WiFi scan gives very limited AP list and it always fails to
> connect to the selected AP. This module only supports 1x1 antenna
> and the antenna is switched to bluetooth due to some incorrect
> register settings.
>
> Compare with the vendor driver https://github.com/lwfinger/rtl8723bu,
> we realized that the 8723bu's enable_rf() does the same thing as
> rtw_btcoex_HAL_Initialize() in vendor driver. And it by default
> sets the antenna path to BTC_ANT_PATH_BT which we verified it's
> the cause of the wifi weak tx power. The vendor driver will set
> the antenna path to BTC_ANT_PATH_PTA in the consequent btcoexist
> mechanism, by the function halbtc8723b1ant_PsTdma.
>
> This commit hand over the antenna control to PTA(Packet Traffic
> Arbitration), which compares the weight of bluetooth/wifi traffic
> then determine whether to continue current wifi traffic or not.
> After PTA take control, The wifi signal will be back to normal and
> the bluetooth scan can also work at the same time. However, the
> btcoexist still needs to be handled under different circumstances.
> If there's a BT connection established, the wifi still fails to
> connect until BT disconnected.
>
> Signed-off-by: Chris Chiu <chiu@endlessm.com>
Patch applied to wireless-drivers-next.git, thanks.
18e714687bea rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU
--
https://patchwork.kernel.org/patch/11031397/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] libertas: remove redundant assignment to variable ret
From: Kalle Valo @ 2019-07-24 11:44 UTC (permalink / raw)
To: Colin King
Cc: David S . Miller, libertas-dev, linux-wireless, netdev,
kernel-janitors, linux-kernel
In-Reply-To: <20190705081734.15292-1-colin.king@canonical.com>
Colin King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> The variable ret is being initialized with a value that is never
> read and it is being updated later with a new value. The
> initialization is redundant and can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Patch applied to wireless-drivers-next.git, thanks.
4c8a46851019 libertas: remove redundant assignment to variable ret
--
https://patchwork.kernel.org/patch/11032181/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] wl3501_cs: remove redundant variable rc
From: Kalle Valo @ 2019-07-24 11:45 UTC (permalink / raw)
To: Colin King
Cc: David S . Miller, linux-wireless, netdev, kernel-janitors,
linux-kernel
In-Reply-To: <20190705103732.30568-1-colin.king@canonical.com>
Colin King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> The variable rc is being initialized with a value that is never
> read and it is being updated later with a new value that is returned.
> The variable is redundant and can be replaced with a return 0 as
> there are no other return points in this function.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Patch applied to wireless-drivers-next.git, thanks.
c032461936de wl3501_cs: remove redundant variable rc
--
https://patchwork.kernel.org/patch/11032441/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 09/12] rtw88: Fix misuse of GENMASK macro
From: Kalle Valo @ 2019-07-24 11:48 UTC (permalink / raw)
To: Joe Perches
Cc: Andrew Morton, Yan-Hsuan Chuang, David S. Miller, linux-wireless,
netdev, linux-kernel
In-Reply-To: <0de52d891d7925b02f4f0fe2c750d076e55434d9.1562734889.git.joe@perches.com>
Joe Perches <joe@perches.com> wrote:
> Arguments are supposed to be ordered high then low.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> Acked-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Patch applied to wireless-drivers-next.git, thanks.
5ff29d836d1b rtw88: Fix misuse of GENMASK macro
--
https://patchwork.kernel.org/patch/11037805/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] libertas: Add missing sentinel at end of if_usb.c fw_table
From: Kalle Valo @ 2019-07-24 11:49 UTC (permalink / raw)
To: Kevin Easton
Cc: linux-wireless, andreyknvl, davem, libertas-dev, linux-kernel,
syzbot, netdev, syzkaller-bugs
In-Reply-To: <20190710133138.GA31901@ip-172-31-14-16>
Kevin Easton <kevin@guarana.org> wrote:
> This sentinel tells the firmware loading process when to stop.
>
> Reported-and-tested-by: syzbot+98156c174c5a2cad9f8f@syzkaller.appspotmail.com
> Signed-off-by: Kevin Easton <kevin@guarana.org>
Patch applied to wireless-drivers-next.git, thanks.
764f3f1ecffc libertas: Add missing sentinel at end of if_usb.c fw_table
--
https://patchwork.kernel.org/patch/11038493/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v4 1/2] rtw88: pci: Rearrange the memory usage for skb in RX ISR
From: Kalle Valo @ 2019-07-24 11:49 UTC (permalink / raw)
To: Jian-Hong Pan
Cc: Yan-Hsuan Chuang, David S . Miller, Larry Finger, David Laight,
Christoph Hellwig, linux-wireless, netdev, linux-kernel, linux,
Daniel Drake, Jian-Hong Pan, stable
In-Reply-To: <20190711052427.5582-1-jian-hong@endlessm.com>
Jian-Hong Pan <jian-hong@endlessm.com> wrote:
> Testing with RTL8822BE hardware, when available memory is low, we
> frequently see a kernel panic and system freeze.
>
> First, rtw_pci_rx_isr encounters a memory allocation failure (trimmed):
>
> rx routine starvation
> WARNING: CPU: 7 PID: 9871 at drivers/net/wireless/realtek/rtw88/pci.c:822 rtw_pci_rx_isr.constprop.25+0x35a/0x370 [rtwpci]
> [ 2356.580313] RIP: 0010:rtw_pci_rx_isr.constprop.25+0x35a/0x370 [rtwpci]
>
> Then we see a variety of different error conditions and kernel panics,
> such as this one (trimmed):
>
> rtw_pci 0000:02:00.0: pci bus timeout, check dma status
> skbuff: skb_over_panic: text:00000000091b6e66 len:415 put:415 head:00000000d2880c6f data:000000007a02b1ea tail:0x1df end:0xc0 dev:<NULL>
> ------------[ cut here ]------------
> kernel BUG at net/core/skbuff.c:105!
> invalid opcode: 0000 [#1] SMP NOPTI
> RIP: 0010:skb_panic+0x43/0x45
>
> When skb allocation fails and the "rx routine starvation" is hit, the
> function returns immediately without updating the RX ring. At this
> point, the RX ring may continue referencing an old skb which was already
> handed off to ieee80211_rx_irqsafe(). When it comes to be used again,
> bad things happen.
>
> This patch allocates a new, data-sized skb first in RX ISR. After
> copying the data in, we pass it to the upper layers. However, if skb
> allocation fails, we effectively drop the frame. In both cases, the
> original, full size ring skb is reused.
>
> In addition, to fixing the kernel crash, the RX routine should now
> generally behave better under low memory conditions.
>
> Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=204053
> Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
> Cc: <stable@vger.kernel.org>
2 patches applied to wireless-drivers-next.git, thanks.
ee6db78f5db9 rtw88: pci: Rearrange the memory usage for skb in RX ISR
29b68a920f6a rtw88: pci: Use DMA sync instead of remapping in RX ISR
--
https://patchwork.kernel.org/patch/11039275/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] rtlwifi: btcoex: fix issue possible condition with no effect (if == else)
From: Kalle Valo @ 2019-07-24 11:52 UTC (permalink / raw)
To: Hariprasad Kelam
Cc: Ping-Ke Shih, David S. Miller, YueHaibing, Hariprasad Kelam,
Larry Finger, Nathan Chancellor, linux-wireless, netdev,
linux-kernel
In-Reply-To: <20190712191535.GA4215@hari-Inspiron-1545>
Hariprasad Kelam <hariprasad.kelam@gmail.com> wrote:
> fix below issue reported by coccicheck
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c:514:1-3:
> WARNING: possible condition with no effect (if == else)
>
> Signed-off-by: Hariprasad Kelam <hariprasad.kelam@gmail.com>
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Patch applied to wireless-drivers-next.git, thanks.
9a29f7d8476c rtlwifi: btcoex: fix issue possible condition with no effect (if == else)
--
https://patchwork.kernel.org/patch/11042665/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2] libertas_tf: Use correct channel range in lbtf_geo_init
From: Kalle Valo @ 2019-07-24 11:53 UTC (permalink / raw)
To: YueHaibing
Cc: davem, lkundrak, derosier, linux-kernel, netdev, linux-wireless,
YueHaibing
In-Reply-To: <20190716144218.20608-1-yuehaibing@huawei.com>
YueHaibing <yuehaibing@huawei.com> wrote:
> It seems we should use 'range' instead of 'priv->range'
> in lbtf_geo_init(), because 'range' is the corret one
> related to current regioncode.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Fixes: 691cdb49388b ("libertas_tf: command helper functions for libertas_tf")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Patch applied to wireless-drivers-next.git, thanks.
2ec4ad49b98e libertas_tf: Use correct channel range in lbtf_geo_init
--
https://patchwork.kernel.org/patch/11046191/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH net-next 00/10] Use dev_get_drvdata where possible
From: Kalle Valo @ 2019-07-24 11:57 UTC (permalink / raw)
To: Chuhong Yuan
Cc: Mirko Lindner, Stephen Hemminger, Jiri Slaby, Nick Kossifidis,
Luis Chamberlain, Stanislaw Gruszka, QCA ath9k Development,
Maya Erez, Johannes Berg, Emmanuel Grumbach, Luca Coelho,
Amitkumar Karwar, Nishant Sarmukadam, Ganapathi Bhat, Xinming Hu,
Igor Mitsyanko, Avinash Patil, Sergey Matyukevich, Ping-Ke Shih,
Intel Linux Wireless, David S . Miller,
Solarflare linux maintainers, Edward Cree, Mart in Habets, netdev,
wil6210, linux-wireless, linux-kernel
In-Reply-To: <20190724112524.13042-1-hslester96@gmail.com>
Chuhong Yuan <hslester96@gmail.com> writes:
> These patches use dev_get_drvdata instead of
> using to_pci_dev + pci_get_drvdata to make
> code simpler.
>
> Chuhong Yuan (10):
> net: marvell: Use dev_get_drvdata where possible
> forcedeth: Use dev_get_drvdata where possible
> sfc: Use dev_get_drvdata where possible
> sfc-falcon: Use dev_get_drvdata where possible
> ath: Use dev_get_drvdata where possible
> iwlegacy: Use dev_get_drvdata where possible
> iwlwifi: Use dev_get_drvdata where possible
> mwifiex: pcie: Use dev_get_drvdata
> qtnfmac_pcie: Use dev_get_drvdata
> rtlwifi: rtl_pci: Use dev_get_drvdata
>
> drivers/net/ethernet/marvell/skge.c | 6 ++----
> drivers/net/ethernet/marvell/sky2.c | 3 +--
> drivers/net/ethernet/nvidia/forcedeth.c | 3 +--
> drivers/net/ethernet/sfc/ef10.c | 4 ++--
> drivers/net/ethernet/sfc/efx.c | 10 +++++-----
> drivers/net/ethernet/sfc/falcon/efx.c | 6 +++---
> drivers/net/ethernet/sfc/falcon/falcon_boards.c | 4 ++--
> drivers/net/wireless/ath/ath5k/pci.c | 3 +--
> drivers/net/wireless/ath/ath9k/pci.c | 5 ++---
> drivers/net/wireless/ath/wil6210/pcie_bus.c | 6 ++----
> drivers/net/wireless/intel/iwlegacy/common.c | 3 +--
> drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 12 ++++--------
> drivers/net/wireless/marvell/mwifiex/pcie.c | 8 ++------
> drivers/net/wireless/quantenna/qtnfmac/pcie/pcie.c | 4 ++--
> drivers/net/wireless/realtek/rtlwifi/pci.c | 6 ++----
> 15 files changed, 32 insertions(+), 51 deletions(-)
Do note that wireless patches go to wireless-drivers-next, not net-next.
But I assume Dave will ignore patches 5-10 and I can take them.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool
From: Jon Hunter @ 2019-07-24 11:58 UTC (permalink / raw)
To: Jose Abreu, Ilias Apalodimas
Cc: David Miller, robin.murphy@arm.com, lists@bofh.nu,
Joao.Pinto@synopsys.com, alexandre.torgue@st.com,
maxime.ripard@bootlin.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com, wens@csie.org,
mcoquelin.stm32@gmail.com, linux-tegra@vger.kernel.org,
peppe.cavallaro@st.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <BYAPR12MB32696F0A2BFDF69F31C4311CD3C60@BYAPR12MB3269.namprd12.prod.outlook.com>
On 24/07/2019 12:34, Jose Abreu wrote:
> From: Jon Hunter <jonathanh@nvidia.com>
> Date: Jul/24/2019, 12:10:47 (UTC+00:00)
>
>>
>> On 24/07/2019 11:04, Jose Abreu wrote:
>>
>> ...
>>
>>> Jon, I was able to replicate (at some level) your setup:
>>>
>>> # dmesg | grep -i arm-smmu
>>> [ 1.337322] arm-smmu 70040000.iommu: probing hardware
>>> configuration...
>>> [ 1.337330] arm-smmu 70040000.iommu: SMMUv2 with:
>>> [ 1.337338] arm-smmu 70040000.iommu: stage 1 translation
>>> [ 1.337346] arm-smmu 70040000.iommu: stage 2 translation
>>> [ 1.337354] arm-smmu 70040000.iommu: nested translation
>>> [ 1.337363] arm-smmu 70040000.iommu: stream matching with 128
>>> register groups
>>> [ 1.337374] arm-smmu 70040000.iommu: 1 context banks (0
>>> stage-2 only)
>>> [ 1.337383] arm-smmu 70040000.iommu: Supported page sizes:
>>> 0x61311000
>>> [ 1.337393] arm-smmu 70040000.iommu: Stage-1: 48-bit VA ->
>>> 48-bit IPA
>>> [ 1.337402] arm-smmu 70040000.iommu: Stage-2: 48-bit IPA ->
>>> 48-bit PA
>>>
>>> # dmesg | grep -i stmmac
>>> [ 1.344106] stmmaceth 70000000.ethernet: Adding to iommu group 0
>>> [ 1.344233] stmmaceth 70000000.ethernet: no reset control found
>>> [ 1.348276] stmmaceth 70000000.ethernet: User ID: 0x10, Synopsys ID:
>>> 0x51
>>> [ 1.348285] stmmaceth 70000000.ethernet: DWMAC4/5
>>> [ 1.348293] stmmaceth 70000000.ethernet: DMA HW capability register
>>> supported
>>> [ 1.348302] stmmaceth 70000000.ethernet: RX Checksum Offload Engine
>>> supported
>>> [ 1.348311] stmmaceth 70000000.ethernet: TX Checksum insertion
>>> supported
>>> [ 1.348320] stmmaceth 70000000.ethernet: TSO supported
>>> [ 1.348328] stmmaceth 70000000.ethernet: Enable RX Mitigation via HW
>>> Watchdog Timer
>>> [ 1.348337] stmmaceth 70000000.ethernet: TSO feature enabled
>>> [ 1.348409] libphy: stmmac: probed
>>> [ 4159.140990] stmmaceth 70000000.ethernet eth0: PHY [stmmac-0:01]
>>> driver [Generic PHY]
>>> [ 4159.141005] stmmaceth 70000000.ethernet eth0: phy: setting supported
>>> 00,00000000,000062ff advertising 00,00000000,000062ff
>>> [ 4159.142359] stmmaceth 70000000.ethernet eth0: No Safety Features
>>> support found
>>> [ 4159.142369] stmmaceth 70000000.ethernet eth0: IEEE 1588-2008 Advanced
>>> Timestamp supported
>>> [ 4159.142429] stmmaceth 70000000.ethernet eth0: registered PTP clock
>>> [ 4159.142439] stmmaceth 70000000.ethernet eth0: configuring for
>>> phy/gmii link mode
>>> [ 4159.142452] stmmaceth 70000000.ethernet eth0: phylink_mac_config:
>>> mode=phy/gmii/Unknown/Unknown adv=00,00000000,000062ff pause=10 link=0
>>> an=1
>>> [ 4159.142466] stmmaceth 70000000.ethernet eth0: phy link up
>>> gmii/1Gbps/Full
>>> [ 4159.142475] stmmaceth 70000000.ethernet eth0: phylink_mac_config:
>>> mode=phy/gmii/1Gbps/Full adv=00,00000000,00000000 pause=0f link=1 an=0
>>> [ 4159.142481] stmmaceth 70000000.ethernet eth0: Link is Up - 1Gbps/Full
>>> - flow control rx/tx
>>>
>>> The only missing point is the NFS boot that I can't replicate with this
>>> setup. But I did some sanity checks:
>>>
>>> Remote Enpoint:
>>> # dd if=/dev/urandom of=output.dat bs=128M count=1
>>> # nc -c 192.168.0.2 1234 < output.dat
>>> # md5sum output.dat
>>> fde9e0818281836e4fc0edfede2b8762 output.dat
>>>
>>> DUT:
>>> # nc -l -c -p 1234 > output.dat
>>> # md5sum output.dat
>>> fde9e0818281836e4fc0edfede2b8762 output.dat
>>
>> On my setup, if I do not use NFS to mount the rootfs, but then manually
>> mount the NFS share after booting, I do not see any problems reading or
>> writing to files on the share. So I am not sure if it is some sort of
>> race that is occurring when mounting the NFS share on boot. It is 100%
>> reproducible when using NFS for the root file-system.
>
> I don't understand how can there be corruption then unless the IP AXI
> parameters are misconfigured which can lead to sporadic undefined
> behavior.
>
> These prints from your logs:
> [ 14.579392] Run /init as init process
> /init: line 58: chmod: command not found
> [ 10:22:46 ] L4T-INITRD Build DATE: Mon Jul 22 10:22:46 UTC 2019
> [ 10:22:46 ] Root device found: nfs
> [ 10:22:46 ] Ethernet interfaces: eth0
> [ 10:22:46 ] IP Address: 10.21.140.41
>
> Where are they coming from ? Do you have any extra init script ?
By default there is an initial ramdisk that is loaded first and then the
rootfs is mounted over NFS. However, even if I remove this ramdisk and
directly mount the rootfs via NFS without it the problem persists. So I
don't see any issue with the ramdisk and whats more is we have been
using this for a long long time. Nothing has changed here.
Jon
--
nvpublic
^ permalink raw reply
* [PATCH] ip6_gre: reload ipv6h in prepare_ip6gre_xmit_ipv6
From: Haishuang Yan @ 2019-07-24 12:00 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov
Cc: netdev, linux-kernel, Haishuang Yan, William Tu
Since ip6_tnl_parse_tlv_enc_lim() can call pskb_may_pull()
which may change skb->data, so we need to re-load ipv6h at
the right place.
Fixes: 898b29798e36 ("ip6_gre: Refactor ip6gre xmit codes")
Cc: William Tu <u9012063@gmail.com>
Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
---
net/ipv6/ip6_gre.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index c2049c7..dd2d0b96 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -660,12 +660,13 @@ static int prepare_ip6gre_xmit_ipv6(struct sk_buff *skb,
struct flowi6 *fl6, __u8 *dsfield,
int *encap_limit)
{
- struct ipv6hdr *ipv6h = ipv6_hdr(skb);
+ struct ipv6hdr *ipv6h;
struct ip6_tnl *t = netdev_priv(dev);
__u16 offset;
offset = ip6_tnl_parse_tlv_enc_lim(skb, skb_network_header(skb));
/* ip6_tnl_parse_tlv_enc_lim() might have reallocated skb->head */
+ ipv6h = ipv6_hdr(skb);
if (offset > 0) {
struct ipv6_tlv_tnl_enc_lim *tel;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH 4.4 stable net] net: tcp: Fix use-after-free in tcp_write_xmit
From: maowenan @ 2019-07-24 12:13 UTC (permalink / raw)
To: Greg KH; +Cc: stable, davem, netdev, linux-kernel
In-Reply-To: <20190724110524.GA4472@kroah.com>
On 2019/7/24 19:05, Greg KH wrote:
> On Wed, Jul 24, 2019 at 05:17:15PM +0800, Mao Wenan wrote:
>> There is one report about tcp_write_xmit use-after-free with version 4.4.136:
>>
>> BUG: KASAN: use-after-free in tcp_skb_pcount include/net/tcp.h:796 [inline]
>> BUG: KASAN: use-after-free in tcp_init_tso_segs net/ipv4/tcp_output.c:1619 [inline]
>> BUG: KASAN: use-after-free in tcp_write_xmit+0x3fc2/0x4cb0 net/ipv4/tcp_output.c:2056
>> Read of size 2 at addr ffff8801d6fc87b0 by task syz-executor408/4195
>>
>> CPU: 0 PID: 4195 Comm: syz-executor408 Not tainted 4.4.136-gfb7e319 #59
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
>> 0000000000000000 7d8f38ecc03be946 ffff8801d73b7710 ffffffff81e0edad
>> ffffea00075bf200 ffff8801d6fc87b0 0000000000000000 ffff8801d6fc87b0
>> dffffc0000000000 ffff8801d73b7748 ffffffff815159b6 ffff8801d6fc87b0
>> Call Trace:
>> [<ffffffff81e0edad>] __dump_stack lib/dump_stack.c:15 [inline]
>> [<ffffffff81e0edad>] dump_stack+0xc1/0x124 lib/dump_stack.c:51
>> [<ffffffff815159b6>] print_address_description+0x6c/0x216 mm/kasan/report.c:252
>> [<ffffffff81515cd5>] kasan_report_error mm/kasan/report.c:351 [inline]
>> [<ffffffff81515cd5>] kasan_report.cold.7+0x175/0x2f7 mm/kasan/report.c:408
>> [<ffffffff814f9784>] __asan_report_load2_noabort+0x14/0x20 mm/kasan/report.c:427
>> [<ffffffff83286582>] tcp_skb_pcount include/net/tcp.h:796 [inline]
>> [<ffffffff83286582>] tcp_init_tso_segs net/ipv4/tcp_output.c:1619 [inline]
>> [<ffffffff83286582>] tcp_write_xmit+0x3fc2/0x4cb0 net/ipv4/tcp_output.c:2056
>> [<ffffffff83287a40>] __tcp_push_pending_frames+0xa0/0x290 net/ipv4/tcp_output.c:2307
>> [<ffffffff8328e966>] tcp_send_fin+0x176/0xab0 net/ipv4/tcp_output.c:2883
>> [<ffffffff8324c0d0>] tcp_close+0xca0/0xf70 net/ipv4/tcp.c:2112
>> [<ffffffff832f8d0f>] inet_release+0xff/0x1d0 net/ipv4/af_inet.c:435
>> [<ffffffff82f1a156>] sock_release+0x96/0x1c0 net/socket.c:586
>> [<ffffffff82f1a296>] sock_close+0x16/0x20 net/socket.c:1037
>> [<ffffffff81522da5>] __fput+0x235/0x6f0 fs/file_table.c:208
>> [<ffffffff815232e5>] ____fput+0x15/0x20 fs/file_table.c:244
>> [<ffffffff8118bd7f>] task_work_run+0x10f/0x190 kernel/task_work.c:115
>> [<ffffffff81135285>] exit_task_work include/linux/task_work.h:21 [inline]
>> [<ffffffff81135285>] do_exit+0x9e5/0x26b0 kernel/exit.c:759
>> [<ffffffff8113b1d1>] do_group_exit+0x111/0x330 kernel/exit.c:889
>> [<ffffffff8115e5cc>] get_signal+0x4ec/0x14b0 kernel/signal.c:2321
>> [<ffffffff8100e02b>] do_signal+0x8b/0x1d30 arch/x86/kernel/signal.c:712
>> [<ffffffff8100360a>] exit_to_usermode_loop+0x11a/0x160 arch/x86/entry/common.c:248
>> [<ffffffff81006535>] prepare_exit_to_usermode arch/x86/entry/common.c:283 [inline]
>> [<ffffffff81006535>] syscall_return_slowpath+0x1b5/0x1f0 arch/x86/entry/common.c:348
>> [<ffffffff838c29b5>] int_ret_from_sys_call+0x25/0xa3
>>
>> Allocated by task 4194:
>> [<ffffffff810341d6>] save_stack_trace+0x26/0x50 arch/x86/kernel/stacktrace.c:63
>> [<ffffffff814f8873>] save_stack+0x43/0xd0 mm/kasan/kasan.c:512
>> [<ffffffff814f8b57>] set_track mm/kasan/kasan.c:524 [inline]
>> [<ffffffff814f8b57>] kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:616
>> [<ffffffff814f9122>] kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:554
>> [<ffffffff814f4c1e>] slab_post_alloc_hook mm/slub.c:1349 [inline]
>> [<ffffffff814f4c1e>] slab_alloc_node mm/slub.c:2615 [inline]
>> [<ffffffff814f4c1e>] slab_alloc mm/slub.c:2623 [inline]
>> [<ffffffff814f4c1e>] kmem_cache_alloc+0xbe/0x2a0 mm/slub.c:2628
>> [<ffffffff82f380a6>] kmem_cache_alloc_node include/linux/slab.h:350 [inline]
>> [<ffffffff82f380a6>] __alloc_skb+0xe6/0x600 net/core/skbuff.c:218
>> [<ffffffff832466c3>] alloc_skb_fclone include/linux/skbuff.h:856 [inline]
>> [<ffffffff832466c3>] sk_stream_alloc_skb+0xa3/0x5d0 net/ipv4/tcp.c:833
>> [<ffffffff83249164>] tcp_sendmsg+0xd34/0x2b00 net/ipv4/tcp.c:1178
>> [<ffffffff83300ef3>] inet_sendmsg+0x203/0x4d0 net/ipv4/af_inet.c:755
>> [<ffffffff82f1e1fc>] sock_sendmsg_nosec net/socket.c:625 [inline]
>> [<ffffffff82f1e1fc>] sock_sendmsg+0xcc/0x110 net/socket.c:635
>> [<ffffffff82f1eedc>] SYSC_sendto+0x21c/0x370 net/socket.c:1665
>> [<ffffffff82f21560>] SyS_sendto+0x40/0x50 net/socket.c:1633
>> [<ffffffff838c2825>] entry_SYSCALL_64_fastpath+0x22/0x9e
>>
>> Freed by task 4194:
>> [<ffffffff810341d6>] save_stack_trace+0x26/0x50 arch/x86/kernel/stacktrace.c:63
>> [<ffffffff814f8873>] save_stack+0x43/0xd0 mm/kasan/kasan.c:512
>> [<ffffffff814f91a2>] set_track mm/kasan/kasan.c:524 [inline]
>> [<ffffffff814f91a2>] kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:589
>> [<ffffffff814f632e>] slab_free_hook mm/slub.c:1383 [inline]
>> [<ffffffff814f632e>] slab_free_freelist_hook mm/slub.c:1405 [inline]
>> [<ffffffff814f632e>] slab_free mm/slub.c:2859 [inline]
>> [<ffffffff814f632e>] kmem_cache_free+0xbe/0x340 mm/slub.c:2881
>> [<ffffffff82f3527f>] kfree_skbmem+0xcf/0x100 net/core/skbuff.c:635
>> [<ffffffff82f372fd>] __kfree_skb+0x1d/0x20 net/core/skbuff.c:676
>> [<ffffffff83288834>] sk_wmem_free_skb include/net/sock.h:1447 [inline]
>> [<ffffffff83288834>] tcp_write_queue_purge include/net/tcp.h:1460 [inline]
>> [<ffffffff83288834>] tcp_connect_init net/ipv4/tcp_output.c:3122 [inline]
>> [<ffffffff83288834>] tcp_connect+0xb24/0x30c0 net/ipv4/tcp_output.c:3261
>> [<ffffffff8329b991>] tcp_v4_connect+0xf31/0x1890 net/ipv4/tcp_ipv4.c:246
>> [<ffffffff832f9ca9>] __inet_stream_connect+0x2a9/0xc30 net/ipv4/af_inet.c:615
>> [<ffffffff832fa685>] inet_stream_connect+0x55/0xa0 net/ipv4/af_inet.c:676
>> [<ffffffff82f1eb78>] SYSC_connect+0x1b8/0x300 net/socket.c:1557
>> [<ffffffff82f214b4>] SyS_connect+0x24/0x30 net/socket.c:1538
>> [<ffffffff838c2825>] entry_SYSCALL_64_fastpath+0x22/0x9e
>>
>> Syzkaller reproducer():
>> r0 = socket$packet(0x11, 0x3, 0x300)
>> r1 = socket$inet_tcp(0x2, 0x1, 0x0)
>> bind$inet(r1, &(0x7f0000000300)={0x2, 0x4e21, @multicast1}, 0x10)
>> connect$inet(r1, &(0x7f0000000140)={0x2, 0x1000004e21, @loopback}, 0x10)
>> recvmmsg(r1, &(0x7f0000001e40)=[{{0x0, 0x0, &(0x7f0000000100)=[{&(0x7f00000005c0)=""/88, 0x58}], 0x1}}], 0x1, 0x40000000, 0x0)
>> sendto$inet(r1, &(0x7f0000000000)="e2f7ad5b661c761edf", 0x9, 0x8080, 0x0, 0x0)
>> r2 = fcntl$dupfd(r1, 0x0, r0)
>> connect$unix(r2, &(0x7f00000001c0)=@file={0x0, './file0\x00'}, 0x6e)
>>
>> C repro link: https://syzkaller.appspot.com/text?tag=ReproC&x=14db474f800000
>>
>> This is because when tcp_connect_init call tcp_write_queue_purge, it will
>> kfree all the skb in the write_queue, but the sk->sk_send_head forget to set NULL,
>> then tcp_write_xmit try to send skb, which has freed in tcp_write_queue_purge, UAF happens.
>>
>> Signed-off-by: Mao Wenan <maowenan@huawei.com>
>> ---
>> include/net/tcp.h | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/include/net/tcp.h b/include/net/tcp.h
>> index bf8a0dae977a..8f8aace28cf8 100644
>> --- a/include/net/tcp.h
>> +++ b/include/net/tcp.h
>> @@ -1457,6 +1457,7 @@ static inline void tcp_write_queue_purge(struct sock *sk)
>>
>> while ((skb = __skb_dequeue(&sk->sk_write_queue)) != NULL)
>> sk_wmem_free_skb(sk, skb);
>> + sk->sk_send_head = NULL;
>> sk_mem_reclaim(sk);
>> tcp_clear_all_retrans_hints(tcp_sk(sk));
>> inet_csk(sk)->icsk_backoff = 0;
>
> Does this corrispond with a specific commit that is already in Linus's
> tree? If not, why, did we change/mess something up when doing
> backports, or is the code just that different?
>
> Also, is this needed in 4.9.y, 4.14.y, 4.19.y, and/or 5.2.y? Why just
> 4.4.y?
Is it the commit 75c119afe14f? It does not use sk_send_head to indicate whether it has skb to be sent.
commit 75c119afe14f74b4dd967d75ed9f57ab6c0ef045
Author: Eric Dumazet <edumazet@google.com>
Date: Thu Oct 5 22:21:27 2017 -0700
tcp: implement rb-tree based retransmit queue
static inline struct sk_buff *tcp_send_head(const struct sock *sk)
{
- return sk->sk_send_head;
+ return skb_peek(&sk->sk_write_queue);
}
>
> thanks,
>
> greg k-h
>
> .
>
^ permalink raw reply
* Re: [RFC PATCH net-next 00/12] drop_monitor: Capture dropped packets and metadata
From: Toke Høiland-Jørgensen @ 2019-07-24 9:51 UTC (permalink / raw)
To: Ido Schimmel
Cc: netdev, davem, nhorman, dsahern, roopa, nikolay, jakub.kicinski,
andy, f.fainelli, andrew, vivien.didelot, mlxsw, Ido Schimmel
In-Reply-To: <20190724081042.GB15878@splinter>
Ido Schimmel <idosch@idosch.org> writes:
> On Tue, Jul 23, 2019 at 06:08:21PM +0200, Toke Høiland-Jørgensen wrote:
>> Also, presumably the queue will have to change from a struct
>> sk_buff_head to something that can hold XDP frames and whatever devlink
>> puts there as well, right?
>
> Good point!
>
> For HW drops we get an SKB and relevant metadata from devlink about why
> the packet was dropped etc. I plan to store a pointer to this metadata
> in the SKB control block.
>
> Let me see how the implementation goes. Even if use sk_buff_head for
> now, I will make sure that converting to a more generalized data
> structure is straightforward.
Yup, that's fine, just wanted to make sure you were aware of the
eventual need to change it :)
-Toke
^ permalink raw reply
* Re: [PATCH 4.4 stable net] net: tcp: Fix use-after-free in tcp_write_xmit
From: maowenan @ 2019-07-24 12:29 UTC (permalink / raw)
To: Eric Dumazet, davem, gregkh, netdev, linux-kernel
In-Reply-To: <c7eb64e0-702d-0792-9aea-c303454e7a33@huawei.com>
On 2019/7/24 18:38, maowenan wrote:
>
>
> On 2019/7/24 18:13, Eric Dumazet wrote:
>>
>>
>> On 7/24/19 12:01 PM, Eric Dumazet wrote:
>>>
>>>
>>> On 7/24/19 11:17 AM, Mao Wenan wrote:
>>>> There is one report about tcp_write_xmit use-after-free with version 4.4.136:
>>>
>>> Current stable 4.4 is 4.4.186
>>>
>>> Can you check the bug is still there ?
>>>
>>
>> BTW, I tried the C repro and another bug showed up.
>>
>> It looks like 4.4.186 misses other fixes :/
>
> I will try 4.4.186.
Hi Eric, bug exist in latest commit for 4.4 stable.
a3e421f Linux 4.4.186
>
>>
>> [ 180.811610] skbuff: skb_under_panic: text:ffffffff825ec6ea len:156 put:84 head:ffff8837dd1f0990 data:ffff8837dd1f098c tail:0x98 end:0xc0 dev:ip6gre0
>> [ 180.825037] ------------[ cut here ]------------
>> [ 180.829688] kernel BUG at net/core/skbuff.c:104!
>> [ 180.834316] invalid opcode: 0000 [#1] SMP KASAN
>> [ 180.839305] gsmi: Log Shutdown Reason 0x03
>> [ 180.843426] Modules linked in: ipip bonding bridge stp llc tun veth w1_therm wire i2c_mux_pca954x i2c_mux cdc_acm ehci_pci ehci_hcd ip_gre mlx4_en ib_uverbs mlx4_ib ib_sa ib_mad ib_core ib_addr mlx4_core
>> [ 180.862052] CPU: 22 PID: 1619 Comm: kworker/22:1 Not tainted 4.4.186-smp-DEV #41
>> [ 180.869475] Hardware name: Intel BIOS 2.56.0 10/19/2018
>> [ 180.876463] Workqueue: ipv6_addrconf addrconf_dad_work
>> [ 180.881658] task: ffff8837f1f59d80 ti: ffff8837eeeb8000 task.ti: ffff8837eeeb8000
>> [ 180.889171] RIP: 0010:[<ffffffff821ef26f>] [<ffffffff821ef26f>] skb_panic+0x14f/0x210
>> [ 180.897162] RSP: 0018:ffff8837eeebf4b8 EFLAGS: 00010282
>> [ 180.902504] RAX: 0000000000000088 RBX: ffff8837eeeeb600 RCX: 0000000000000000
>> [ 180.909645] RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffffffff83508c00
>> [ 180.916854] RBP: ffff8837eeebf520 R08: 0000000000000016 R09: 0000000000000000
>> [ 180.924029] R10: ffff881fc8abf038 R11: 0000000000000007 R12: ffff881fc8abe720
>> [ 180.931213] R13: ffffffff82aa9e80 R14: 00000000000000c0 R15: 0000000000000098
>> [ 180.938390] FS: 0000000000000000(0000) GS:ffff8837ff280000(0000) knlGS:0000000000000000
>> [ 180.946519] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> [ 180.952290] CR2: 00007f519426f530 CR3: 00000037d37f2000 CR4: 0000000000160670
>> [ 180.959447] Stack:
>> [ 180.961458] ffff8837dd1f098c 0000000000000098 00000000000000c0 ffff881fc8abe720
>> [ 180.968909] ffffea00df747c00 ffff881fff404b40 ffff8837ff2a1a20 ffff8837eeebf5b8
>> [ 180.976371] ffff8837eeeeb600 ffffffff825ec6ea 1ffff106fddd7eb6 ffff8837eeeeb600
>> [ 180.983848] Call Trace:
>> [ 180.986297] [<ffffffff825ec6ea>] ? ip6gre_header+0xba/0xd50
>> [ 180.991962] [<ffffffff821f0e01>] skb_push+0xc1/0x100
>> [ 180.997023] [<ffffffff825ec6ea>] ip6gre_header+0xba/0xd50
>> [ 181.002519] [<ffffffff8158dc16>] ? memcpy+0x36/0x40
>> [ 181.007509] [<ffffffff825ec630>] ? ip6gre_changelink+0x6d0/0x6d0
>> [ 181.013629] [<ffffffff82550741>] ? ndisc_constructor+0x5b1/0x770
>> [ 181.019728] [<ffffffff82666861>] ? _raw_write_unlock_bh+0x41/0x50
>> [ 181.025924] [<ffffffff8226540b>] ? __neigh_create+0xe6b/0x1670
>> [ 181.031851] [<ffffffff8225817f>] neigh_connected_output+0x23f/0x480
>> [ 181.038219] [<ffffffff824f61ec>] ip6_finish_output2+0x74c/0x1a90
>> [ 181.044324] [<ffffffff810f1d33>] ? print_context_stack+0x73/0xf0
>> [ 181.050429] [<ffffffff824f5aa0>] ? ip6_xmit+0x1700/0x1700
>> [ 181.055933] [<ffffffff82304a28>] ? nf_hook_slow+0x118/0x1b0
>> [ 181.061617] [<ffffffff82502d7a>] ip6_finish_output+0x2ba/0x580
>> [ 181.067546] [<ffffffff82503179>] ip6_output+0x139/0x380
>> [ 181.072884] [<ffffffff82503040>] ? ip6_finish_output+0x580/0x580
>> [ 181.079004] [<ffffffff82502ac0>] ? ip6_fragment+0x31b0/0x31b0
>> [ 181.084852] [<ffffffff82251b51>] ? dst_init+0x4b1/0x820
>> [ 181.090172] [<ffffffff8158da45>] ? kasan_unpoison_shadow+0x35/0x50
>> [ 181.096437] [<ffffffff8158da45>] ? kasan_unpoison_shadow+0x35/0x50
>> [ 181.102712] [<ffffffff8254f3ca>] NF_HOOK_THRESH.constprop.22+0xca/0x180
>> [ 181.109421] [<ffffffff8254f300>] ? ndisc_alloc_skb+0x340/0x340
>> [ 181.115338] [<ffffffff8254d820>] ? compat_ipv6_setsockopt+0x180/0x180
>> [ 181.121874] [<ffffffff8254fbc2>] ndisc_send_skb+0x742/0xd10
>> [ 181.127550] [<ffffffff8254f480>] ? NF_HOOK_THRESH.constprop.22+0x180/0x180
>> [ 181.134516] [<ffffffff821f2440>] ? skb_complete_tx_timestamp+0x280/0x280
>> [ 181.141311] [<ffffffff8254e2b3>] ? ndisc_fill_addr_option+0x193/0x260
>> [ 181.147844] [<ffffffff82553bd9>] ndisc_send_rs+0x179/0x2d0
>> [ 181.153426] [<ffffffff8251e7df>] addrconf_dad_completed+0x41f/0x7c0
>> [ 181.159795] [<ffffffff81297f78>] ? pick_next_entity+0x198/0x470
>> [ 181.165807] [<ffffffff8251e3c0>] ? addrconf_rs_timer+0x4a0/0x4a0
>> [ 181.171918] [<ffffffff81aab928>] ? find_next_bit+0x18/0x20
>> [ 181.177504] [<ffffffff81a99ec9>] ? prandom_seed+0xd9/0x160
>> [ 181.183095] [<ffffffff8251eef5>] addrconf_dad_work+0x375/0x9e0
>> [ 181.189024] [<ffffffff8251eb80>] ? addrconf_dad_completed+0x7c0/0x7c0
>> [ 181.195576] [<ffffffff81249d8f>] process_one_work+0x52f/0xf60
>> [ 181.201468] [<ffffffff8124a89d>] worker_thread+0xdd/0xe80
>> [ 181.206977] [<ffffffff8265cf0a>] ? __schedule+0x73a/0x16d0
>> [ 181.212550] [<ffffffff8124a7c0>] ? process_one_work+0xf60/0xf60
>> [ 181.218572] [<ffffffff8125a115>] kthread+0x205/0x2b0
>> [ 181.223633] [<ffffffff81259f10>] ? kthread_worker_fn+0x4e0/0x4e0
>> [ 181.229743] [<ffffffff81259f10>] ? kthread_worker_fn+0x4e0/0x4e0
>> [ 181.235834] [<ffffffff8266726f>] ret_from_fork+0x3f/0x70
>> [ 181.241232] [<ffffffff81259f10>] ? kthread_worker_fn+0x4e0/0x4e0
>>
>>
>> .
>>
>
>
> .
>
^ permalink raw reply
* [PATCH] r8169: fix a typo in a comment
From: Corentin Musard @ 2019-07-24 12:34 UTC (permalink / raw)
To: David S. Miller, netdev, linux-kernel; +Cc: trivial
Replace "additonal" by "additional" in a comment.
Typo found by checkpatch.pl.
Signed-off-by: Corentin Musard <corentinmusard@gmail.com>
---
drivers/net/ethernet/realtek/r8169_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
index 0637c6752a78..7231ab3573ff 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -6334,7 +6334,7 @@ rtl8169_get_stats64(struct net_device *dev, struct rtnl_link_stats64 *stats)
stats->multicast = dev->stats.multicast;
/*
- * Fetch additonal counter values missing in stats collected by driver
+ * Fetch additional counter values missing in stats collected by driver
* from tally counters.
*/
if (pm_runtime_active(&pdev->dev))
--
2.22.0
^ permalink raw reply related
* [PATCH 1/2] net: mac80211: Fix possible null-pointer dereferences in ieee80211_setup_sdata()
From: Jia-Ju Bai @ 2019-07-24 12:36 UTC (permalink / raw)
To: johannes, davem; +Cc: linux-wireless, netdev, linux-kernel, Jia-Ju Bai
In ieee80211_setup_sdata(), there is an if statement on line 1410 to
check whether sdata->dev is NULL:
if (sdata->dev)
When sdata->dev is NULL, it is used on lines 1458 and 1459:
sdata->dev->type = ARPHRD_IEEE80211_RADIOTAP;
sdata->dev->netdev_ops = &ieee80211_monitorif_ops;
Thus, possible null-pointer dereferences may occur.
To fix these bugs, sdata->dev is checked before being used.
These bugs are found by a static analysis tool STCheck written by us.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
net/mac80211/iface.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 06aac0aaae64..e49264981a7b 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -1455,8 +1455,10 @@ static void ieee80211_setup_sdata(struct ieee80211_sub_if_data *sdata,
ieee80211_mesh_init_sdata(sdata);
break;
case NL80211_IFTYPE_MONITOR:
- sdata->dev->type = ARPHRD_IEEE80211_RADIOTAP;
- sdata->dev->netdev_ops = &ieee80211_monitorif_ops;
+ if (sdata->dev) {
+ sdata->dev->type = ARPHRD_IEEE80211_RADIOTAP;
+ sdata->dev->netdev_ops = &ieee80211_monitorif_ops;
+ }
sdata->u.mntr.flags = MONITOR_FLAG_CONTROL |
MONITOR_FLAG_OTHER_BSS;
break;
--
2.17.0
^ permalink raw reply related
* [PATCH 2/2] net: mac80211: Fix possible null-pointer dereferences in ieee80211_xmit_fast_finish()
From: Jia-Ju Bai @ 2019-07-24 12:36 UTC (permalink / raw)
To: johannes, davem; +Cc: linux-wireless, netdev, linux-kernel, Jia-Ju Bai
In ieee80211_xmit_fast_finish(), there is an if statement on line 3356
to check whether key is NULL:
if (key)
When key is NULL, it is used on line 3388:
switch (key->conf.cipher)
and line 3393:
pn = atomic64_inc_return(&key->conf.tx_pn);
and line 3396:
crypto_hdr[3] = 0x20 | (key->conf.keyidx << 6);
Thus, possible null-pointer dereferences may occur.
To fix these bugs, key is checked on line 3384.
These bugs are found by a static analysis tool STCheck written by us.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
net/mac80211/tx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index f13eb2f61ccf..2cc261165b91 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -3381,7 +3381,7 @@ static void ieee80211_xmit_fast_finish(struct ieee80211_sub_if_data *sdata,
sta->tx_stats.bytes[skb_get_queue_mapping(skb)] += skb->len;
sta->tx_stats.packets[skb_get_queue_mapping(skb)]++;
- if (pn_offs) {
+ if (key && pn_offs) {
u64 pn;
u8 *crypto_hdr = skb->data + pn_offs;
--
2.17.0
^ permalink raw reply related
* Re: [PATCH net-next 1/4] sctp: check addr_size with sa_family_t size in __sctp_setsockopt_connectx
From: Marcelo Ricardo Leitner @ 2019-07-24 12:36 UTC (permalink / raw)
To: Neil Horman; +Cc: Xin Long, network dev, linux-sctp, davem
In-Reply-To: <20190724112235.GA7212@hmswarspite.think-freely.org>
On Wed, Jul 24, 2019 at 07:22:35AM -0400, Neil Horman wrote:
> On Wed, Jul 24, 2019 at 03:21:12PM +0800, Xin Long wrote:
> > On Tue, Jul 23, 2019 at 11:25 PM Neil Horman <nhorman@tuxdriver.com> wrote:
> > >
> > > On Tue, Jul 23, 2019 at 01:37:57AM +0800, Xin Long wrote:
> > > > Now __sctp_connect() is called by __sctp_setsockopt_connectx() and
> > > > sctp_inet_connect(), the latter has done addr_size check with size
> > > > of sa_family_t.
> > > >
> > > > In the next patch to clean up __sctp_connect(), we will remove
> > > > addr_size check with size of sa_family_t from __sctp_connect()
> > > > for the 1st address.
> > > >
> > > > So before doing that, __sctp_setsockopt_connectx() should do
> > > > this check first, as sctp_inet_connect() does.
> > > >
> > > > Signed-off-by: Xin Long <lucien.xin@gmail.com>
> > > > ---
> > > > net/sctp/socket.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> > > > index aa80cda..5f92e4a 100644
> > > > --- a/net/sctp/socket.c
> > > > +++ b/net/sctp/socket.c
> > > > @@ -1311,7 +1311,7 @@ static int __sctp_setsockopt_connectx(struct sock *sk,
> > > > pr_debug("%s: sk:%p addrs:%p addrs_size:%d\n",
> > > > __func__, sk, addrs, addrs_size);
> > > >
> > > > - if (unlikely(addrs_size <= 0))
> > > > + if (unlikely(addrs_size < sizeof(sa_family_t)))
> > > I don't think this is what you want to check for here. sa_family_t is
> > > an unsigned short, and addrs_size is the number of bytes in the addrs
> > > array. The addrs array should be at least the size of one struct
> > > sockaddr (16 bytes iirc), and, if larger, should be a multiple of
> > > sizeof(struct sockaddr)
> > sizeof(struct sockaddr) is not the right value to check either.
> >
> > The proper check will be done later in __sctp_connect():
> >
> > af = sctp_get_af_specific(daddr->sa.sa_family);
> > if (!af || af->sockaddr_len > addrs_size)
> > return -EINVAL;
> >
> > So the check 'addrs_size < sizeof(sa_family_t)' in this patch is
> > just to make sure daddr->sa.sa_family is accessible. the same
> > check is also done in sctp_inet_connect().
> >
> That doesn't make much sense, if the proper check is done in __sctp_connect with
> the size of the families sockaddr_len, then we don't need this check at all, we
> can just let memdup_user take the fault on copy_to_user and return -EFAULT. If
> we get that from memdup_user, we know its not accessible, and can bail out.
>
> About the only thing we need to check for here is that addr_len isn't some
> absurdly high value (i.e. a negative value), so that we avoid trying to kmalloc
> upwards of 2G in memdup_user. Your change does that just fine, but its no
> better or worse than checking for <=0
One can argue that such check against absurdly high values is random
and not effective, as 2G can be somewhat reasonable on 8GB systems but
certainly isn't on 512MB ones. On that, kmemdup_user() will also fail
gracefully as it uses GFP_USER and __GFP_NOWARN.
The original check is more for protecting for sane usage of the
variable, which is an int, and a negative value is questionable. We
could cast, yes, but.. was that really the intent of the application?
Probably not.
>
> Neil
>
> > >
> > > Neil
> > >
> > > > return -EINVAL;
> > > >
> > > > kaddrs = memdup_user(addrs, addrs_size);
> > > > --
> > > > 2.1.0
> > > >
> > > >
> >
^ permalink raw reply
* Re: [PATCH 2/2] net: mac80211: Fix possible null-pointer dereferences in ieee80211_xmit_fast_finish()
From: Johannes Berg @ 2019-07-24 12:39 UTC (permalink / raw)
To: Jia-Ju Bai, davem; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20190724123633.10145-1-baijiaju1990@gmail.com>
On Wed, 2019-07-24 at 20:36 +0800, Jia-Ju Bai wrote:
> In ieee80211_xmit_fast_finish(), there is an if statement on line 3356
> to check whether key is NULL:
> if (key)
>
> When key is NULL, it is used on line 3388:
> switch (key->conf.cipher)
> and line 3393:
> pn = atomic64_inc_return(&key->conf.tx_pn);
> and line 3396:
> crypto_hdr[3] = 0x20 | (key->conf.keyidx << 6);
>
> Thus, possible null-pointer dereferences may occur.
No, this cannot happen, because pn_offs can only be non-zero when there
is a key. Maybe we should pass the fast_tx pointer instead of the
pn_offs/key from it, but the two are coupled.
johannes
^ permalink raw reply
* Re: [PATCH 1/2] net: mac80211: Fix possible null-pointer dereferences in ieee80211_setup_sdata()
From: Johannes Berg @ 2019-07-24 12:40 UTC (permalink / raw)
To: Jia-Ju Bai, davem; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20190724123623.10093-1-baijiaju1990@gmail.com>
On Wed, 2019-07-24 at 20:36 +0800, Jia-Ju Bai wrote:
> In ieee80211_setup_sdata(), there is an if statement on line 1410 to
> check whether sdata->dev is NULL:
> if (sdata->dev)
>
> When sdata->dev is NULL, it is used on lines 1458 and 1459:
> sdata->dev->type = ARPHRD_IEEE80211_RADIOTAP;
> sdata->dev->netdev_ops = &ieee80211_monitorif_ops;
>
> Thus, possible null-pointer dereferences may occur.
No, this cannot happen, monitor interfaces (NL80211_IFTYPE_MONITOR) must
have a valid ->dev, only P2P device and NAN might not.
johannes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox