Menglong Dong [Mon, 28 Jun 2021 06:37:44 +0000 (23:37 -0700)]
net: tipc: fix FB_MTU eat two pages
[ Upstream commit
0c6de0c943dbb42831bf7502eb5c007f71e752d2 ]
FB_MTU is used in 'tipc_msg_build()' to alloc smaller skb when memory
allocation fails, which can avoid unnecessary sending failures.
The value of FB_MTU now is 3744, and the data size will be:
(3744 + SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) + \
SKB_DATA_ALIGN(BUF_HEADROOM + BUF_TAILROOM + 3))
which is larger than one page(4096), and two pages will be allocated.
To avoid it, replace '3744' with a calculation:
(PAGE_SIZE - SKB_DATA_ALIGN(BUF_OVERHEAD) - \
SKB_DATA_ALIGN(sizeof(struct skb_shared_info)))
What's more, alloc_skb_fclone() will call SKB_DATA_ALIGN for data size,
and it's not necessary to make alignment for buf_size in
tipc_buf_acquire(). So, just remove it.
Fixes:
4c94cc2d3d57 ("tipc: fall back to smaller MTU if allocation of local send skb fails")
Signed-off-by: Menglong Dong <dong.menglong@zte.com.cn>
Acked-by: Jon Maloy <jmaloy@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pavel Skripkin [Fri, 25 Jun 2021 20:23:48 +0000 (23:23 +0300)]
net: sched: fix warning in tcindex_alloc_perfect_hash
[ Upstream commit
3f2db250099f46988088800052cdf2332c7aba61 ]
Syzbot reported warning in tcindex_alloc_perfect_hash. The problem
was in too big cp->hash, which triggers warning in kmalloc. Since
cp->hash comes from userspace, there is no need to warn if value
is not correct
Fixes:
b9a24bb76bf6 ("net_sched: properly handle failure case of tcf_exts_init()")
Reported-and-tested-by: syzbot+1071ad60cd7df39fdadb@syzkaller.appspotmail.com
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Acked-by: Cong Wang <cong.wang@bytedance.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Vadim Fedorenko [Fri, 25 Jun 2021 16:21:39 +0000 (19:21 +0300)]
net: lwtunnel: handle MTU calculation in forwading
[ Upstream commit
fade56410c22cacafb1be9f911a0afd3701d8366 ]
Commit
14972cbd34ff ("net: lwtunnel: Handle fragmentation") moved
fragmentation logic away from lwtunnel by carry encap headroom and
use it in output MTU calculation. But the forwarding part was not
covered and created difference in MTU for output and forwarding and
further to silent drops on ipv4 forwarding path. Fix it by taking
into account lwtunnel encap headroom.
The same commit also introduced difference in how to treat RTAX_MTU
in IPv4 and IPv6 where latter explicitly removes lwtunnel encap
headroom from route MTU. Make IPv4 version do the same.
Fixes:
14972cbd34ff ("net: lwtunnel: Handle fragmentation")
Suggested-by: David Ahern <dsahern@gmail.com>
Signed-off-by: Vadim Fedorenko <vfedorenko@novek.ru>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Muchun Song [Fri, 2 Apr 2021 09:11:45 +0000 (17:11 +0800)]
writeback: fix obtain a reference to a freeing memcg css
[ Upstream commit
8b0ed8443ae6458786580d36b7d5f8125535c5d4 ]
The caller of wb_get_create() should pin the memcg, because
wb_get_create() relies on this guarantee. The rcu read lock
only can guarantee that the memcg css returned by css_from_id()
cannot be released, but the reference of the memcg can be zero.
rcu_read_lock()
memcg_css = css_from_id()
wb_get_create(memcg_css)
cgwb_create(memcg_css)
// css_get can change the ref counter from 0 back to 1
css_get(memcg_css)
rcu_read_unlock()
Fix it by holding a reference to the css before calling
wb_get_create(). This is not a problem I encountered in the
real world. Just the result of a code review.
Fixes:
682aa8e1a6a1 ("writeback: implement unlocked_inode_to_wb transaction and use it for stat updates")
Link: https://lore.kernel.org/r/20210402091145.80635-1-songmuchun@bytedance.com
Signed-off-by: Muchun Song <songmuchun@bytedance.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Robert Hancock [Thu, 25 Mar 2021 19:26:39 +0000 (13:26 -0600)]
clk: si5341: Update initialization magic
[ Upstream commit
3c9b49b0031aefb81adfdba5ab0ddf3ca3a2cdc9 ]
Update the default register settings to include the VCO_RESET_CALCODE
settings (set by the SiLabs ClockBuilder software but not described in
the datasheet). Also update part of the initialization sequence to match
ClockBuilder and the datasheet.
Fixes:
3044a860fd ("clk: Add Si5341/Si5340 driver")
Signed-off-by: Robert Hancock <robert.hancock@calian.com>
Link: https://lore.kernel.org/r/20210325192643.2190069-6-robert.hancock@calian.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Robert Hancock [Thu, 25 Mar 2021 19:26:38 +0000 (13:26 -0600)]
clk: si5341: Check for input clock presence and PLL lock on startup
[ Upstream commit
71dcc4d1f7d2ad97ff7ab831281bc6893ff713a2 ]
After initializing the device, wait for it to report that the input
clock is present and the PLL has locked before declaring success.
Fixes:
3044a860fd ("clk: Add Si5341/Si5340 driver")
Signed-off-by: Robert Hancock <robert.hancock@calian.com>
Link: https://lore.kernel.org/r/20210325192643.2190069-5-robert.hancock@calian.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Robert Hancock [Thu, 25 Mar 2021 19:26:37 +0000 (13:26 -0600)]
clk: si5341: Avoid divide errors due to bogus register contents
[ Upstream commit
78f6f406026d688868223d5dbeb197a4f7e9a9fd ]
If the Si5341 is being initially programmed and has no stored NVM
configuration, some of the register contents may contain unexpected
values, such as zeros, which could cause divide by zero errors during
driver initialization. Trap errors caused by zero registers or zero clock
rates which could result in divide errors later in the code.
Fixes:
3044a860fd ("clk: Add Si5341/Si5340 driver")
Signed-off-by: Robert Hancock <robert.hancock@calian.com>
Link: https://lore.kernel.org/r/20210325192643.2190069-4-robert.hancock@calian.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Robert Hancock [Thu, 25 Mar 2021 19:26:36 +0000 (13:26 -0600)]
clk: si5341: Wait for DEVICE_READY on startup
[ Upstream commit
6e7d2de1e000d36990923ed80d2e78dfcb545cee ]
The Si5341 datasheet warns that before accessing any other registers,
including the PAGE register, we need to wait for the DEVICE_READY register
to indicate the device is ready, or the process of the device loading its
state from NVM can be corrupted. Wait for DEVICE_READY on startup before
continuing initialization. This is done using a raw I2C register read
prior to setting up regmap to avoid any potential unwanted automatic PAGE
register accesses from regmap at this stage.
Fixes:
3044a860fd ("clk: Add Si5341/Si5340 driver")
Signed-off-by: Robert Hancock <robert.hancock@calian.com>
Link: https://lore.kernel.org/r/20210325192643.2190069-3-robert.hancock@calian.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jonathan Marek [Wed, 9 Jun 2021 02:28:52 +0000 (22:28 -0400)]
clk: qcom: clk-alpha-pll: fix CAL_L write in alpha_pll_fabia_prepare
[ Upstream commit
7f54bf2640e877c8a9b4cc7e2b29f82e3ca1a284 ]
Caught this when looking at alpha-pll code. Untested but it is clear that
this was intended to write to PLL_CAL_L_VAL and not PLL_ALPHA_VAL.
Fixes:
691865bad627 ("clk: qcom: clk-alpha-pll: Add support for Fabia PLL calibration")
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Link: https://lore.kernel.org/r/20210609022852.4151-1-jonathan@marek.ca
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Cristian Ciocaltea [Thu, 10 Jun 2021 20:05:24 +0000 (23:05 +0300)]
clk: actions: Fix AHPPREDIV-H-AHB clock chain on Owl S500 SoC
[ Upstream commit
fd90b5b9045274360b12cea0f2ce50f3bcfb25cc ]
There are a few issues with the setup of the Actions Semi Owl S500 SoC's
clock chain involving AHPPREDIV, H and AHB clocks:
* AHBPREDIV clock is defined as a muxer only, although it also acts as
a divider.
* H clock is using a wrong divider register offset
* AHB is defined as a multi-rate factor clock, but it is actually just
a fixed pass clock.
Let's provide the following fixes:
* Change AHBPREDIV clock to an ungated OWL_COMP_DIV definition.
* Use the correct register shift value in the OWL_DIVIDER definition
for H clock
* Drop the unneeded 'ahb_factor_table[]' and change AHB clock to an
ungated OWL_COMP_FIXED_FACTOR definition.
Fixes:
ed6b4795ece4 ("clk: actions: Add clock driver for S500 SoC")
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@gmail.com>
Link: https://lore.kernel.org/r/21c1abd19a7089b65a34852ac6513961be88cbe1.1623354574.git.cristian.ciocaltea@gmail.com
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Cristian Ciocaltea [Thu, 10 Jun 2021 20:05:23 +0000 (23:05 +0300)]
clk: actions: Fix bisp_factor_table based clocks on Owl S500 SoC
[ Upstream commit
a8f1f03caa51aa7a69c671aa87c475034db7d368 ]
The following clocks of the Actions Semi Owl S500 SoC have been defined
to use a shared clock factor table 'bisp_factor_table[]': DE[1-2], VCE,
VDE, BISP, SENSOR[0-1]
There are several issues involved in this approach:
* 'bisp_factor_table[]' describes the configuration of a regular 8-rates
divider, so its usage is redundant. Additionally, judging by the BISP
clock context, it is incomplete since it maps only 8 out of 12
possible entries.
* The clocks mentioned above are not identical in terms of the available
rates, therefore cannot rely on the same factor table. Specifically,
BISP and SENSOR* are standard 12-rate dividers so their configuration
should rely on a proper clock div table, while VCE and VDE require a
factor table that is a actually a subset of the one needed for DE[1-2]
clocks.
Let's fix this by implementing the following:
* Add new factor tables 'de_factor_table' and 'hde_factor_table' to
properly handle DE[1-2], VCE and VDE clocks.
* Add a common div table 'std12rate_div_table' for BISP and SENSOR[0-1]
clocks converted to OWL_COMP_DIV.
* Drop the now unused 'bisp_factor_table[]'.
Additionally, drop the CLK_IGNORE_UNUSED flag for SENSOR[0-1] since
there is no reason to always keep ON those clocks.
Fixes:
ed6b4795ece4 ("clk: actions: Add clock driver for S500 SoC")
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@gmail.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/e675820a46cd9930d8d576c6cae61d41c1a8416f.1623354574.git.cristian.ciocaltea@gmail.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Cristian Ciocaltea [Thu, 10 Jun 2021 20:05:22 +0000 (23:05 +0300)]
clk: actions: Fix SD clocks factor table on Owl S500 SoC
[ Upstream commit
fe1f71e338d77814da3ef44e9f64d32981a6ccdf ]
Drop the unsupported entries in the factor table used for the SD[0-2]
clocks definitions on the Actions Semi Owl S500 SoC.
Fixes:
ed6b4795ece4 ("clk: actions: Add clock driver for S500 SoC")
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@gmail.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/196c948d708a22b8198c95f064a0f6b6820f9980.1623354574.git.cristian.ciocaltea@gmail.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Cristian Ciocaltea [Thu, 10 Jun 2021 20:05:21 +0000 (23:05 +0300)]
clk: actions: Fix UART clock dividers on Owl S500 SoC
[ Upstream commit
2dca2a619a907579e3e65e7c1789230c2b912e88 ]
Use correct divider registers for the Actions Semi Owl S500 SoC's UART
clocks.
Fixes:
ed6b4795ece4 ("clk: actions: Add clock driver for S500 SoC")
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@gmail.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/4714d05982b19ac5fec2ed74f54be42d8238e392.1623354574.git.cristian.ciocaltea@gmail.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Luiz Augusto von Dentz [Wed, 23 Jun 2021 03:59:02 +0000 (20:59 -0700)]
Bluetooth: Fix handling of HCI_LE_Advertising_Set_Terminated event
[ Upstream commit
23837a6d7a1a61818ed94a6b8af552d6cf7d32d5 ]
Error status of this event means that it has ended due reasons other
than a connection:
'If advertising has terminated as a result of the advertising duration
elapsing, the Status parameter shall be set to the error code
Advertising Timeout (0x3C).'
'If advertising has terminated because the
Max_Extended_Advertising_Events was reached, the Status parameter
shall be set to the error code Limit Reached (0x43).'
Fixes:
acf0aeae431a0 ("Bluetooth: Handle ADv set terminated event")
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Luiz Augusto von Dentz [Wed, 9 Jun 2021 18:09:27 +0000 (11:09 -0700)]
Bluetooth: Fix Set Extended (Scan Response) Data
[ Upstream commit
c9ed0a7077306f9d41d74fb006ab5dbada8349c5 ]
These command do have variable length and the length can go up to 251,
so this changes the struct to not use a fixed size and then when
creating the PDU only the actual length of the data send to the
controller.
Fixes:
a0fb3726ba551 ("Bluetooth: Use Set ext adv/scan rsp data if controller supports")
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Luiz Augusto von Dentz [Sat, 14 Nov 2020 00:44:33 +0000 (16:44 -0800)]
Bluetooth: Fix not sending Set Extended Scan Response
[ Upstream commit
a76a0d365077711594ce200a9553ed6d1ff40276 ]
Current code is actually failing on the following tests of mgmt-tester
because get_adv_instance_scan_rsp_len did not account for flags that
cause scan response data to be included resulting in non-scannable
instance when in fact it should be scannable.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Luiz Augusto von Dentz [Fri, 28 May 2021 18:45:02 +0000 (11:45 -0700)]
Bluetooth: mgmt: Fix slab-out-of-bounds in tlv_data_is_valid
[ Upstream commit
799acb9347915bfe4eac0ff2345b468f0a1ca207 ]
This fixes parsing of LTV entries when the length is 0.
Found with:
tools/mgmt-tester -s "Add Advertising - Success (ScRsp only)"
Add Advertising - Success (ScRsp only) - run
Sending Add Advertising (0x003e)
Test condition added, total 1
[ 11.004577] ==================================================================
[ 11.005292] BUG: KASAN: slab-out-of-bounds in tlv_data_is_valid+0x87/0xe0
[ 11.005984] Read of size 1 at addr
ffff888002c695b0 by task mgmt-tester/87
[ 11.006711]
[ 11.007176]
[ 11.007429] Allocated by task 87:
[ 11.008151]
[ 11.008438] The buggy address belongs to the object at
ffff888002c69580
[ 11.008438] which belongs to the cache kmalloc-64 of size 64
[ 11.010526] The buggy address is located 48 bytes inside of
[ 11.010526] 64-byte region [
ffff888002c69580,
ffff888002c695c0)
[ 11.012423] The buggy address belongs to the page:
[ 11.013291]
[ 11.013544] Memory state around the buggy address:
[ 11.014359]
ffff888002c69480: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
[ 11.015453]
ffff888002c69500: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
[ 11.016232] >
ffff888002c69580: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc
[ 11.017010] ^
[ 11.017547]
ffff888002c69600: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc
[ 11.018296]
ffff888002c69680: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
[ 11.019116] ==================================================================
Fixes:
2bb36870e8cb2 ("Bluetooth: Unify advertising instance flags check")
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Petr Oros [Fri, 25 Jun 2021 08:27:45 +0000 (10:27 +0200)]
Revert "be2net: disable bh with spin_lock in be_process_mcc"
[ Upstream commit
d6765985a42a660f078896d5c5b27f97c580a490 ]
Patch was based on wrong presumption that be_poll can be called only
from bh context. It reintroducing old regression (also reverted) and
causing deadlock when we use netconsole with benet in bonding.
Old revert: commit
072a9c486004 ("netpoll: revert
6bdb7fe3104 and fix
be_poll() instead")
[ 331.269715] bond0: (slave enp0s7f0): Releasing backup interface
[ 331.270121] CPU: 4 PID: 1479 Comm: ifenslave Not tainted 5.13.0-rc7+ #2
[ 331.270122] Call Trace:
[ 331.270122] [
c00000001789f200] [
c0000000008c505c] dump_stack+0x100/0x174 (unreliable)
[ 331.270124] [
c00000001789f240] [
c008000001238b9c] be_poll+0x64/0xe90 [be2net]
[ 331.270125] [
c00000001789f330] [
c000000000d1e6e4] netpoll_poll_dev+0x174/0x3d0
[ 331.270127] [
c00000001789f400] [
c008000001bc167c] bond_poll_controller+0xb4/0x130 [bonding]
[ 331.270128] [
c00000001789f450] [
c000000000d1e624] netpoll_poll_dev+0xb4/0x3d0
[ 331.270129] [
c00000001789f520] [
c000000000d1ed88] netpoll_send_skb+0x448/0x470
[ 331.270130] [
c00000001789f5d0] [
c0080000011f14f8] write_msg+0x180/0x1b0 [netconsole]
[ 331.270131] [
c00000001789f640] [
c000000000230c0c] console_unlock+0x54c/0x790
[ 331.270132] [
c00000001789f7b0] [
c000000000233098] vprintk_emit+0x2d8/0x450
[ 331.270133] [
c00000001789f810] [
c000000000234758] vprintk+0xc8/0x270
[ 331.270134] [
c00000001789f850] [
c000000000233c28] printk+0x40/0x54
[ 331.270135] [
c00000001789f870] [
c000000000ccf908] __netdev_printk+0x150/0x198
[ 331.270136] [
c00000001789f910] [
c000000000ccfdb4] netdev_info+0x68/0x94
[ 331.270137] [
c00000001789f950] [
c008000001bcbd70] __bond_release_one+0x188/0x6b0 [bonding]
[ 331.270138] [
c00000001789faa0] [
c008000001bcc6f4] bond_do_ioctl+0x42c/0x490 [bonding]
[ 331.270139] [
c00000001789fb60] [
c000000000d0d17c] dev_ifsioc+0x17c/0x400
[ 331.270140] [
c00000001789fbc0] [
c000000000d0db70] dev_ioctl+0x390/0x890
[ 331.270141] [
c00000001789fc10] [
c000000000c7c76c] sock_do_ioctl+0xac/0x1b0
[ 331.270142] [
c00000001789fc90] [
c000000000c7ffac] sock_ioctl+0x31c/0x6e0
[ 331.270143] [
c00000001789fd60] [
c0000000005b9728] sys_ioctl+0xf8/0x150
[ 331.270145] [
c00000001789fdb0] [
c0000000000336c0] system_call_exception+0x160/0x2f0
[ 331.270146] [
c00000001789fe10] [
c00000000000d35c] system_call_common+0xec/0x278
[ 331.270147] --- interrupt: c00 at 0x7fffa6c6ec00
[ 331.270147] NIP:
00007fffa6c6ec00 LR:
0000000105c4185c CTR:
0000000000000000
[ 331.270148] REGS:
c00000001789fe80 TRAP: 0c00 Not tainted (5.13.0-rc7+)
[ 331.270148] MSR:
800000000280f033 <SF,VEC,VSX,EE,PR,FP,ME,IR,DR,RI,LE> CR:
28000428 XER:
00000000
[ 331.270155] IRQMASK: 0
[ 331.270156] GPR00:
0000000000000036 00007fffd494d5b0 00007fffa6d57100 0000000000000003
[ 331.270158] GPR04:
0000000000008991 00007fffd494d6d0 0000000000000008 00007fffd494f28c
[ 331.270161] GPR08:
0000000000000003 0000000000000000 0000000000000000 0000000000000000
[ 331.270164] GPR12:
0000000000000000 00007fffa6dfa220 0000000000000000 0000000000000000
[ 331.270167] GPR16:
0000000105c44880 0000000000000000 0000000105c60088 0000000105c60318
[ 331.270170] GPR20:
0000000105c602c0 0000000105c44560 0000000000000000 0000000000000000
[ 331.270172] GPR24:
00007fffd494dc50 00007fffd494d6a8 0000000105c60008 00007fffd494d6d0
[ 331.270175] GPR28:
00007fffd494f27e 0000000105c6026c 00007fffd494f284 0000000000000000
[ 331.270178] NIP [
00007fffa6c6ec00] 0x7fffa6c6ec00
[ 331.270178] LR [
0000000105c4185c] 0x105c4185c
[ 331.270179] --- interrupt: c00
This reverts commit
d0d006a43e9a7a796f6f178839c92fcc222c564d.
Fixes:
d0d006a43e9a7a ("be2net: disable bh with spin_lock in be_process_mcc")
Signed-off-by: Petr Oros <poros@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bailey Forrest [Fri, 25 Jun 2021 02:55:41 +0000 (19:55 -0700)]
gve: Fix swapped vars when fetching max queues
[ Upstream commit
1db1a862a08f85edc36aad091236ac9b818e949e ]
Fixes:
893ce44df565 ("gve: Add basic driver framework for Compute Engine Virtual NIC")
Signed-off-by: Bailey Forrest <bcf@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Håkon Bugge [Tue, 22 Jun 2021 14:13:27 +0000 (16:13 +0200)]
RDMA/cma: Fix incorrect Packet Lifetime calculation
[ Upstream commit
e84045eab69c625bc0b0bf24d8e05bc65da1eed1 ]
An approximation for the PacketLifeTime is half the local ACK timeout.
The encoding for both timers are logarithmic.
If the local ACK timeout is set, but zero, it means the timer is
disabled. In this case, we choose the CMA_IBOE_PACKET_LIFETIME value,
since 50% of infinite makes no sense.
Before this commit, the PacketLifeTime became 255 if local ACK
timeout was zero (not running).
Fixed by explicitly testing for timeout being zero.
Fixes:
e1ee1e62bec4 ("RDMA/cma: Use ACK timeout for RoCE packetLifeTime")
Link: https://lore.kernel.org/r/1624371207-26710-1-git-send-email-haakon.bugge@oracle.com
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Gary Lin [Wed, 23 Jun 2021 04:09:18 +0000 (12:09 +0800)]
bpfilter: Specify the log level for the kmsg message
[ Upstream commit
a196fa78a26571359740f701cf30d774eb8a72cb ]
Per the kmsg document [0], if we don't specify the log level with a
prefix "<N>" in the message string, the default log level will be
applied to the message. Since the default level could be warning(4),
this would make the log utility such as journalctl treat the message,
"Started bpfilter", as a warning. To avoid confusion, this commit
adds the prefix "<5>" to make the message always a notice.
[0] https://www.kernel.org/doc/Documentation/ABI/testing/dev-kmsg
Fixes:
36c4357c63f3 ("net: bpfilter: print umh messages to /dev/kmsg")
Reported-by: Martin Loviska <mloviska@suse.com>
Signed-off-by: Gary Lin <glin@suse.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Dmitrii Banshchikov <me@ubique.spb.ru>
Link: https://lore.kernel.org/bpf/20210623040918.8683-1-glin@suse.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Vladimir Oltean [Thu, 24 Jun 2021 15:52:07 +0000 (18:52 +0300)]
net: dsa: sja1105: fix NULL pointer dereference in sja1105_reload_cbs()
[ Upstream commit
be7f62eebaff2f86c1467a2d33930a0a7a87675b ]
priv->cbs is an array of priv->info->num_cbs_shapers elements of type
struct sja1105_cbs_entry which only get allocated if CONFIG_NET_SCH_CBS
is enabled.
However, sja1105_reload_cbs() is called from sja1105_static_config_reload()
which in turn is called for any of the items in sja1105_reset_reasons,
therefore during the normal runtime of the driver and not just from a
code path which can be triggered by the tc-cbs offload.
The sja1105_reload_cbs() function does not contain a check whether the
priv->cbs array is NULL or not, it just assumes it isn't and proceeds to
iterate through the credit-based shaper elements. This leads to a NULL
pointer dereference.
The solution is to return success if the priv->cbs array has not been
allocated, since sja1105_reload_cbs() has nothing to do.
Fixes:
4d7525085a9b ("net: dsa: sja1105: offload the Credit-Based Shaper qdisc")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sasha Neftin [Thu, 24 Jun 2021 19:02:48 +0000 (12:02 -0700)]
e1000e: Check the PCIm state
[ Upstream commit
2e7256f12cdb16eaa2515b6231d665044a07c51a ]
Complete to commit
def4ec6dce393e ("e1000e: PCIm function state support")
Check the PCIm state only on CSME systems. There is no point to do this
check on non CSME systems.
This patch fixes a generation a false-positive warning:
"Error in exiting dmoff"
Fixes:
def4ec6dce39 ("e1000e: PCIm function state support")
Signed-off-by: Sasha Neftin <sasha.neftin@intel.com>
Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eric Dumazet [Thu, 24 Jun 2021 10:07:20 +0000 (03:07 -0700)]
ipv6: fix out-of-bound access in ip6_parse_tlv()
[ Upstream commit
624085a31c1ad6a80b1e53f686bf6ee92abbf6e8 ]
First problem is that optlen is fetched without checking
there is more than one byte to parse.
Fix this by taking care of IPV6_TLV_PAD1 before
fetching optlen (under appropriate sanity checks against len)
Second problem is that IPV6_TLV_PADN checks of zero
padding are performed before the check of remaining length.
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Fixes:
c1412fce7ecc ("net/ipv6/exthdrs.c: Strict PadN option checking")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Tom Herbert <tom@herbertland.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Antoine Tenart [Thu, 24 Jun 2021 09:38:30 +0000 (11:38 +0200)]
net: atlantic: fix the macsec key length
[ Upstream commit
d67fb4772d9a6cfd10f1109f0e7b1e6eb58c8e16 ]
The key length used to store the macsec key was set to MACSEC_KEYID_LEN
(16), which is an issue as:
- This was never meant to be the key length.
- The key length can be > 16.
Fix this by using MACSEC_MAX_KEY_LEN instead (the max length accepted in
uAPI).
Fixes:
27736563ce32 ("net: atlantic: MACSec egress offload implementation")
Fixes:
9ff40a751a6f ("net: atlantic: MACSec ingress offload implementation")
Reported-by: Lior Nahmanson <liorna@nvidia.com>
Signed-off-by: Antoine Tenart <atenart@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Antoine Tenart [Thu, 24 Jun 2021 09:38:29 +0000 (11:38 +0200)]
net: phy: mscc: fix macsec key length
[ Upstream commit
c309217f91f2d2097c2a0a832d9bff50b88c81dc ]
The key length used to store the macsec key was set to MACSEC_KEYID_LEN
(16), which is an issue as:
- This was never meant to be the key length.
- The key length can be > 16.
Fix this by using MACSEC_MAX_KEY_LEN instead (the max length accepted in
uAPI).
Fixes:
28c5107aa904 ("net: phy: mscc: macsec support")
Reported-by: Lior Nahmanson <liorna@nvidia.com>
Signed-off-by: Antoine Tenart <atenart@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Antoine Tenart [Thu, 24 Jun 2021 09:38:28 +0000 (11:38 +0200)]
net: macsec: fix the length used to copy the key for offloading
[ Upstream commit
1f7fe5121127e037b86592ba42ce36515ea0e3f7 ]
The key length used when offloading macsec to Ethernet or PHY drivers
was set to MACSEC_KEYID_LEN (16), which is an issue as:
- This was never meant to be the key length.
- The key length can be > 16.
Fix this by using MACSEC_MAX_KEY_LEN to store the key (the max length
accepted in uAPI) and secy->key_len to copy it.
Fixes:
3cf3227a21d1 ("net: macsec: hardware offloading infrastructure")
Reported-by: Lior Nahmanson <liorna@nvidia.com>
Signed-off-by: Antoine Tenart <atenart@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Håkon Bugge [Tue, 22 Jun 2021 13:39:57 +0000 (15:39 +0200)]
RDMA/cma: Protect RMW with qp_mutex
[ Upstream commit
ca0c448d2b9f43e3175835d536853854ef544e22 ]
The struct rdma_id_private contains three bit-fields, tos_set,
timeout_set, and min_rnr_timer_set. These are set by accessor functions
without any synchronization. If two or all accessor functions are invoked
in close proximity in time, there will be Read-Modify-Write from several
contexts to the same variable, and the result will be intermittent.
Fixed by protecting the bit-fields by the qp_mutex in the accessor
functions.
The consumer of timeout_set and min_rnr_timer_set is in
rdma_init_qp_attr(), which is called with qp_mutex held for connected
QPs. Explicit locking is added for the consumers of tos and tos_set.
This commit depends on ("RDMA/cma: Remove unnecessary INIT->INIT
transition"), since the call to rdma_init_qp_attr() from
cma_init_conn_qp() does not hold the qp_mutex.
Fixes:
2c1619edef61 ("IB/cma: Define option to set ack timeout and pack tos_set")
Fixes:
3aeffc46afde ("IB/cma: Introduce rdma_set_min_rnr_timer()")
Link: https://lore.kernel.org/r/1624369197-24578-3-git-send-email-haakon.bugge@oracle.com
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sukadev Bhattiprolu [Thu, 24 Jun 2021 04:13:15 +0000 (21:13 -0700)]
ibmvnic: free tx_pool if tso_pool alloc fails
[ Upstream commit
f6ebca8efa52e4ae770f0325d618e7bcf08ada0c ]
Free tx_pool and clear it, if allocation of tso_pool fails.
release_tx_pools() assumes we have both tx and tso_pools if ->tx_pool is
non-NULL. If allocation of tso_pool fails in init_tx_pools(), the assumption
will not be true and we would end up dereferencing ->tx_buff, ->free_map
fields from a NULL pointer.
Fixes:
3205306c6b8d ("ibmvnic: Update TX pool initialization routine")
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sukadev Bhattiprolu [Thu, 24 Jun 2021 04:13:14 +0000 (21:13 -0700)]
ibmvnic: set ltb->buff to NULL after freeing
[ Upstream commit
552a33729f1a7cc5115d0752064fe9abd6e3e336 ]
free_long_term_buff() checks ltb->buff to decide whether we have a long
term buffer to free. So set ltb->buff to NULL afer freeing. While here,
also clear ->map_id, fix up some coding style and log an error.
Fixes:
9c4eaabd1bb39 ("Check CRQ command return codes")
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dany Madden [Thu, 24 Jun 2021 04:13:11 +0000 (21:13 -0700)]
Revert "ibmvnic: remove duplicate napi_schedule call in open function"
[ Upstream commit
2ca220f92878470c6ba03f9946e412323093cc94 ]
This reverts commit
7c451f3ef676c805a4b77a743a01a5c21a250a73.
When a vnic interface is taken down and then up, connectivity is not
restored. We bisected it to this commit. Reverting this commit until
we can fully investigate the issue/benefit of the change.
Fixes:
7c451f3ef676 ("ibmvnic: remove duplicate napi_schedule call in open function")
Reported-by: Cristobal Forno <cforno12@linux.ibm.com>
Reported-by: Abdul Haleem <abdhalee@in.ibm.com>
Signed-off-by: Dany Madden <drt@linux.ibm.com>
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jan Sokolowski [Fri, 11 Jun 2021 10:01:41 +0000 (12:01 +0200)]
i40e: Fix missing rtnl locking when setting up pf switch
[ Upstream commit
956e759d5f8e0859e86b951a8779c60af633aafd ]
A recent change that made i40e use new udp_tunnel infrastructure
uses a method that expects to be called under rtnl lock.
However, not all codepaths do the lock prior to calling
i40e_setup_pf_switch.
Fix that by adding additional rtnl locking and unlocking.
Fixes:
40a98cb6f01f ("i40e: convert to new udp_tunnel infrastructure")
Signed-off-by: Jan Sokolowski <jan.sokolowski@intel.com>
Signed-off-by: Mateusz Palczewski <mateusz.palczewski@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Mateusz Palczewski [Wed, 10 Mar 2021 11:12:54 +0000 (11:12 +0000)]
i40e: Fix autoneg disabling for non-10GBaseT links
[ Upstream commit
9262793e59f0423437166a879a73d056b1fe6f9a ]
Disabling autonegotiation was allowed only for 10GBaseT PHY.
The condition was changed to check if link media type is BaseT.
Fixes:
3ce12ee9d8f9 ("i40e: Fix order of checks when enabling/disabling autoneg in ethtool")
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Karen Sornek <karen.sornek@intel.com>
Signed-off-by: Dawid Lukwinski <dawid.lukwinski@intel.com>
Signed-off-by: Mateusz Palczewski <mateusz.palczewski@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dinghao Liu [Sun, 28 Feb 2021 11:50:58 +0000 (19:50 +0800)]
i40e: Fix error handling in i40e_vsi_open
[ Upstream commit
9c04cfcd4aad232e36306cdc5c74cd9fc9148a7e ]
When vsi->type == I40E_VSI_FDIR, we have caught the return value of
i40e_vsi_request_irq() but without further handling. Check and execute
memory clean on failure just like the other i40e_vsi_request_irq().
Fixes:
8a9eb7d3cbcab ("i40e: rework fdir setup and teardown")
Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Maciej Żenczykowski [Thu, 17 Jun 2021 00:09:51 +0000 (17:09 -0700)]
bpf: Do not change gso_size during bpf_skb_change_proto()
[ Upstream commit
364745fbe981a4370f50274475da4675661104df ]
This is technically a backwards incompatible change in behaviour, but I'm
going to argue that it is very unlikely to break things, and likely to fix
*far* more then it breaks.
In no particular order, various reasons follow:
(a) I've long had a bug assigned to myself to debug a super rare kernel crash
on Android Pixel phones which can (per stacktrace) be traced back to BPF clat
IPv6 to IPv4 protocol conversion causing some sort of ugly failure much later
on during transmit deep in the GSO engine, AFAICT precisely because of this
change to gso_size, though I've never been able to manually reproduce it. I
believe it may be related to the particular network offload support of attached
USB ethernet dongle being used for tethering off of an IPv6-only cellular
connection. The reason might be we end up with more segments than max permitted,
or with a GSO packet with only one segment... (either way we break some
assumption and hit a BUG_ON)
(b) There is no check that the gso_size is > 20 when reducing it by 20, so we
might end up with a negative (or underflowing) gso_size or a gso_size of 0.
This can't possibly be good. Indeed this is probably somehow exploitable (or
at least can result in a kernel crash) by delivering crafted packets and perhaps
triggering an infinite loop or a divide by zero... As a reminder: gso_size (MSS)
is related to MTU, but not directly derived from it: gso_size/MSS may be
significantly smaller then one would get by deriving from local MTU. And on
some NICs (which do loose MTU checking on receive, it may even potentially be
larger, for example my work pc with 1500 MTU can receive 1520 byte frames [and
sometimes does due to bugs in a vendor plat46 implementation]). Indeed even just
going from 21 to 1 is potentially problematic because it increases the number
of segments by a factor of 21 (think DoS, or some other crash due to too many
segments).
(c) It's always safe to not increase the gso_size, because it doesn't result in
the max packet size increasing. So the skb_increase_gso_size() call was always
unnecessary for correctness (and outright undesirable, see later). As such the
only part which is potentially dangerous (ie. could cause backwards compatibility
issues) is the removal of the skb_decrease_gso_size() call.
(d) If the packets are ultimately destined to the local device, then there is
absolutely no benefit to playing around with gso_size. It only matters if the
packets will egress the device. ie. we're either forwarding, or transmitting
from the device.
(e) This logic only triggers for packets which are GSO. It does not trigger for
skbs which are not GSO. It will not convert a non-GSO MTU sized packet into a
GSO packet (and you don't even know what the MTU is, so you can't even fix it).
As such your transmit path must *already* be able to handle an MTU 20 bytes
larger then your receive path (for IPv4 to IPv6 translation) - and indeed 28
bytes larger due to IPv4 fragments. Thus removing the skb_decrease_gso_size()
call doesn't actually increase the size of the packets your transmit side must
be able to handle. ie. to handle non-GSO max-MTU packets, the IPv4/IPv6 device/
route MTUs must already be set correctly. Since for example with an IPv4 egress
MTU of 1500, IPv4 to IPv6 translation will already build 1520 byte IPv6 frames,
so you need a 1520 byte device MTU. This means if your IPv6 device's egress
MTU is 1280, your IPv4 route must be 1260 (and actually 1252, because of the
need to handle fragments). This is to handle normal non-GSO packets. Thus the
reduction is simply not needed for GSO packets, because when they're correctly
built, they will already be the right size.
(f) TSO/GSO should be able to exactly undo GRO: the number of packets (TCP
segments) should not be modified, so that TCP's MSS counting works correctly
(this matters for congestion control). If protocol conversion changes the
gso_size, then the number of TCP segments may increase or decrease. Packet loss
after protocol conversion can result in partial loss of MSS segments that the
sender sent. How's the sending TCP stack going to react to receiving ACKs/SACKs
in the middle of the segments it sent?
(g) skb_{decrease,increase}_gso_size() are already no-ops for GSO_BY_FRAGS
case (besides triggering WARN_ON_ONCE). This means you already cannot guarantee
that gso_size (and thus resulting packet MTU) is changed. ie. you must assume
it won't be changed.
(h) changing gso_size is outright buggy for UDP GSO packets, where framing
matters (I believe that's also the case for SCTP, but it's already excluded
by [g]). So the only remaining case is TCP, which also doesn't want it
(see [f]).
(i) see also the reasoning on the previous attempt at fixing this
(commit
fa7b83bf3b156c767f3e4a25bbf3817b08f3ff8e) which shows that the current
behaviour causes TCP packet loss:
In the forwarding path GRO -> BPF 6 to 4 -> GSO for TCP traffic, the
coalesced packet payload can be > MSS, but < MSS + 20.
bpf_skb_proto_6_to_4() will upgrade the MSS and it can be > the payload
length. After then tcp_gso_segment checks for the payload length if it
is <= MSS. The condition is causing the packet to be dropped.
tcp_gso_segment():
[...]
mss = skb_shinfo(skb)->gso_size;
if (unlikely(skb->len <= mss)) goto out;
[...]
Thus changing the gso_size is simply a very bad idea. Increasing is unnecessary
and buggy, and decreasing can go negative.
Fixes:
6578171a7ff0 ("bpf: add bpf_skb_change_proto helper")
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: Dongseok Yi <dseok.yi@samsung.com>
Cc: Willem de Bruijn <willemb@google.com>
Link: https://lore.kernel.org/bpf/CANP3RGfjLikQ6dg=YpBU0OeHvyv7JOki7CyOUS9modaXAi-9vQ@mail.gmail.com
Link: https://lore.kernel.org/bpf/20210617000953.2787453-2-zenczykowski@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Norbert Slusarek [Sun, 20 Jun 2021 12:38:42 +0000 (14:38 +0200)]
can: j1939: j1939_sk_setsockopt(): prevent allocation of j1939 filter for optlen == 0
[ Upstream commit
aaf473d0100f64abc88560e2bea905805bcf2a8e ]
If optval != NULL and optlen == 0 are specified for SO_J1939_FILTER in
j1939_sk_setsockopt(), memdup_sockptr() will return ZERO_PTR for 0
size allocation. The new filter will be mistakenly assigned ZERO_PTR.
This patch checks for optlen != 0 and filter will be assigned NULL in
case of optlen == 0.
Fixes:
9d71dd0c7009 ("can: add support of SAE J1939 protocol")
Link: https://lore.kernel.org/r/20210620123842.117975-1-nslusarek@gmx.net
Signed-off-by: Norbert Slusarek <nslusarek@gmx.net>
Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eric Dumazet [Wed, 23 Jun 2021 15:27:00 +0000 (08:27 -0700)]
ipv6: exthdrs: do not blindly use init_net
[ Upstream commit
bcc3f2a829b9edbe3da5fb117ee5a63686d31834 ]
I see no reason why max_dst_opts_cnt and max_hbh_opts_cnt
are fetched from the initial net namespace.
The other sysctls (max_dst_opts_len & max_hbh_opts_len)
are in fact already using the current ns.
Note: it is not clear why ipv6_destopt_rcv() use two ways to
get to the netns :
1) dev_net(dst->dev)
Originally used to increment IPSTATS_MIB_INHDRERRORS
2) dev_net(skb->dev)
Tom used this variant in his patch.
Maybe this calls to use ipv6_skb_net() instead ?
Fixes:
47d3d7ac656a ("ipv6: Implement limits on Hop-by-Hop and Destination options")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Tom Herbert <tom@quantonium.net>
Cc: Coco Li <lixiaoyan@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jian-Hong Pan [Wed, 23 Jun 2021 03:28:03 +0000 (11:28 +0800)]
net: bcmgenet: Fix attaching to PYH failed on RPi 4B
[ Upstream commit
b2ac9800cfe0f8da16abc4e74e003440361c112e ]
The Broadcom UniMAC MDIO bus from mdio-bcm-unimac module comes too late.
So, GENET cannot find the ethernet PHY on UniMAC MDIO bus. This leads
GENET fail to attach the PHY as following log:
bcmgenet
fd580000.ethernet: GENET 5.0 EPHY: 0x0000
...
could not attach to PHY
bcmgenet
fd580000.ethernet eth0: failed to connect to PHY
uart-pl011
fe201000.serial: no DMA platform data
libphy: bcmgenet MII bus: probed
...
unimac-mdio unimac-mdio.-19: Broadcom UniMAC MDIO bus
This patch adds the soft dependency to load mdio-bcm-unimac module
before genet module to avoid the issue.
Fixes:
9a4e79697009 ("net: bcmgenet: utilize generic Broadcom UniMAC MDIO controller driver")
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=213485
Signed-off-by: Jian-Hong Pan <jhp@endlessos.org>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ping-Ke Shih [Wed, 23 Jun 2021 13:48:25 +0000 (21:48 +0800)]
mac80211: remove iwlwifi specific workaround NDPs of null_response
[ Upstream commit
744757e46bf13ec3a7b3507d17ab3faab9516d43 ]
Remove the remaining workaround that is not removed by the
commit
e41eb3e408de ("mac80211: remove iwlwifi specific workaround
that broke sta NDP tx")
Fixes:
41cbb0f5a295 ("mac80211: add support for HE")
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://lore.kernel.org/r/20210623134826.10318-1-pkshih@realtek.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zhen Lei [Mon, 10 May 2021 06:38:05 +0000 (14:38 +0800)]
drm/msm/dpu: Fix error return code in dpu_mdss_init()
[ Upstream commit
e020ac961ce5d038de66dc7f6ffca98899e9a3f3 ]
The error code returned by platform_get_irq() is stored in 'irq', it's
forgotten to be copied to 'ret' before being returned. As a result, the
value 0 of 'ret' is returned incorrectly.
After the above fix is completed, initializing the local variable 'ret'
to 0 is no longer needed, remove it.
In addition, when dpu_mdss_init() is successfully returned, the value of
'ret' is always 0. Therefore, replace "return ret" with "return 0" to make
the code clearer.
Fixes:
070e64dc1bbc ("drm/msm/dpu: Convert to a chained irq chip")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Link: https://lore.kernel.org/r/20210510063805.3262-2-thunder.leizhen@huawei.com
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zhen Lei [Sat, 8 May 2021 02:28:36 +0000 (10:28 +0800)]
drm/msm: Fix error return code in msm_drm_init()
[ Upstream commit
a1c9b1e3bdd6d8dc43c18699772fb6cf4497d45a ]
Fix to return a negative error code from the error handling case instead
of 0, as done elsewhere in this function.
Fixes:
7f9743abaa79 ("drm/msm: validate display and event threads")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Link: https://lore.kernel.org/r/20210508022836.1777-1-thunder.leizhen@huawei.com
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
John Fastabend [Wed, 16 Jun 2021 22:55:00 +0000 (15:55 -0700)]
bpf: Fix null ptr deref with mixed tail calls and subprogs
[ Upstream commit
7506d211b932870155bcb39e3dd9e39fab45a7c7 ]
The sub-programs prog->aux->poke_tab[] is populated in jit_subprogs() and
then used when emitting 'BPF_JMP|BPF_TAIL_CALL' insn->code from the
individual JITs. The poke_tab[] to use is stored in the insn->imm by
the code adding it to that array slot. The JIT then uses imm to find the
right entry for an individual instruction. In the x86 bpf_jit_comp.c
this is done by calling emit_bpf_tail_call_direct with the poke_tab[]
of the imm value.
However, we observed the below null-ptr-deref when mixing tail call
programs with subprog programs. For this to happen we just need to
mix bpf-2-bpf calls and tailcalls with some extra calls or instructions
that would be patched later by one of the fixup routines. So whats
happening?
Before the fixup_call_args() -- where the jit op is done -- various
code patching is done by do_misc_fixups(). This may increase the
insn count, for example when we patch map_lookup_up using map_gen_lookup
hook. This does two things. First, it means the instruction index,
insn_idx field, of a tail call instruction will move by a 'delta'.
In verifier code,
struct bpf_jit_poke_descriptor desc = {
.reason = BPF_POKE_REASON_TAIL_CALL,
.tail_call.map = BPF_MAP_PTR(aux->map_ptr_state),
.tail_call.key = bpf_map_key_immediate(aux),
.insn_idx = i + delta,
};
Then subprog start values subprog_info[i].start will be updated
with the delta and any poke descriptor index will also be updated
with the delta in adjust_poke_desc(). If we look at the adjust
subprog starts though we see its only adjusted when the delta
occurs before the new instructions,
/* NOTE: fake 'exit' subprog should be updated as well. */
for (i = 0; i <= env->subprog_cnt; i++) {
if (env->subprog_info[i].start <= off)
continue;
Earlier subprograms are not changed because their start values
are not moved. But, adjust_poke_desc() does the offset + delta
indiscriminately. The result is poke descriptors are potentially
corrupted.
Then in jit_subprogs() we only populate the poke_tab[]
when the above insn_idx is less than the next subprogram start. From
above we corrupted our insn_idx so we might incorrectly assume a
poke descriptor is not used in a subprogram omitting it from the
subprogram. And finally when the jit runs it does the deref of poke_tab
when emitting the instruction and crashes with below. Because earlier
step omitted the poke descriptor.
The fix is straight forward with above context. Simply move same logic
from adjust_subprog_starts() into adjust_poke_descs() and only adjust
insn_idx when needed.
[ 82.396354] bpf_testmod: version magic '5.12.0-rc2alu+ SMP preempt mod_unload ' should be '5.12.0+ SMP preempt mod_unload '
[ 82.623001] loop10: detected capacity change from 0 to 8
[ 88.487424] ==================================================================
[ 88.487438] BUG: KASAN: null-ptr-deref in do_jit+0x184a/0x3290
[ 88.487455] Write of size 8 at addr
0000000000000008 by task test_progs/5295
[ 88.487471] CPU: 7 PID: 5295 Comm: test_progs Tainted: G I 5.12.0+ #386
[ 88.487483] Hardware name: Dell Inc. Precision 5820 Tower/002KVM, BIOS 1.9.2 01/24/2019
[ 88.487490] Call Trace:
[ 88.487498] dump_stack+0x93/0xc2
[ 88.487515] kasan_report.cold+0x5f/0xd8
[ 88.487530] ? do_jit+0x184a/0x3290
[ 88.487542] do_jit+0x184a/0x3290
...
[ 88.487709] bpf_int_jit_compile+0x248/0x810
...
[ 88.487765] bpf_check+0x3718/0x5140
...
[ 88.487920] bpf_prog_load+0xa22/0xf10
Fixes:
a748c6975dea3 ("bpf: propagate poke descriptors to subprograms")
Reported-by: Jussi Maki <joamaki@gmail.com>
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Reviewed-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eric Dumazet [Mon, 21 Jun 2021 18:02:44 +0000 (11:02 -0700)]
ieee802154: hwsim: avoid possible crash in hwsim_del_edge_nl()
[ Upstream commit
0303b30375dff5351a79cc2c3c87dfa4fda29bed ]
Both MAC802154_HWSIM_ATTR_RADIO_ID and MAC802154_HWSIM_ATTR_RADIO_EDGE
must be present to avoid a crash.
Fixes:
f25da51fdc38 ("ieee802154: hwsim: add replacement for fakelb")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Alexander Aring <alex.aring@gmail.com>
Cc: Stefan Schmidt <stefan@datenfreihafen.org>
Reported-by: syzbot <syzkaller@googlegroups.com>
Acked-by: Alexander Aring <aahringo@redhat.com>
Link: https://lore.kernel.org/r/20210621180244.882076-1-eric.dumazet@gmail.com
Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dongliang Mu [Wed, 16 Jun 2021 02:09:01 +0000 (10:09 +0800)]
ieee802154: hwsim: Fix memory leak in hwsim_add_one
[ Upstream commit
28a5501c3383f0e6643012c187b7c2027ef42aea ]
No matter from hwsim_remove or hwsim_del_radio_nl, hwsim_del fails to
remove the entry in the edges list. Take the example below, phy0, phy1
and e0 will be deleted, resulting in e1 not freed and accessed in the
future.
hwsim_phys
|
------------------------------
| |
phy0 (edges) phy1 (edges)
----> e1 (idx = 1) ----> e0 (idx = 0)
Fix this by deleting and freeing all the entries in the edges list
between hwsim_edge_unsubscribe_me and list_del(&phy->list).
Reported-by: syzbot+b80c9959009a9325cdff@syzkaller.appspotmail.com
Fixes:
1c9f4a3fce77 ("ieee802154: hwsim: fix rcu handling")
Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
Acked-by: Alexander Aring <aahringo@redhat.com>
Link: https://lore.kernel.org/r/20210616020901.2759466-1-mudongliangabcd@gmail.com
Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Marcelo Ricardo Leitner [Tue, 22 Jun 2021 15:05:00 +0000 (12:05 -0300)]
tc-testing: fix list handling
[ Upstream commit
b4fd096cbb871340be837491fa1795864a48b2d9 ]
python lists don't have an 'add' method, but 'append'.
Fixes:
14e5175e9e04 ("tc-testing: introduce scapyPlugin for basic traffic")
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>
Vignesh Raghavendra [Tue, 22 Jun 2021 14:38:57 +0000 (20:08 +0530)]
net: ti: am65-cpsw-nuss: Fix crash when changing number of TX queues
[ Upstream commit
ce8eb4c728ef40b554b4f3d8963f11ed44502e00 ]
When changing number of TX queues using ethtool:
# ethtool -L eth0 tx 1
[ 135.301047] Unable to handle kernel paging request at virtual address
00000000af5d0000
[...]
[ 135.525128] Call trace:
[ 135.525142] dma_release_from_dev_coherent+0x2c/0xb0
[ 135.525148] dma_free_attrs+0x54/0xe0
[ 135.525156] k3_cppi_desc_pool_destroy+0x50/0xa0
[ 135.525164] am65_cpsw_nuss_remove_tx_chns+0x88/0xdc
[ 135.525171] am65_cpsw_set_channels+0x3c/0x70
[...]
This is because k3_cppi_desc_pool_destroy() which is called after
k3_udma_glue_release_tx_chn() in am65_cpsw_nuss_remove_tx_chns()
references struct device that is unregistered at the end of
k3_udma_glue_release_tx_chn()
Therefore the right order is to call k3_cppi_desc_pool_destroy() and
destroy desc pool before calling k3_udma_glue_release_tx_chn().
Fix this throughout the driver.
Fixes:
93a76530316a ("net: ethernet: ti: introduce am65x/j721e gigabit eth subsystem driver")
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Miao Wang [Tue, 22 Jun 2021 04:24:50 +0000 (12:24 +0800)]
net/ipv4: swap flow ports when validating source
[ Upstream commit
c69f114d09891adfa3e301a35d9e872b8b7b5a50 ]
When doing source address validation, the flowi4 struct used for
fib_lookup should be in the reverse direction to the given skb.
fl4_dport and fl4_sport returned by fib4_rules_early_flow_dissect
should thus be swapped.
Fixes:
5a847a6e1477 ("net/ipv4: Initialize proto and ports in flow struct")
Signed-off-by: Miao Wang <shankerwangmiao@gmail.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jakub Kicinski [Tue, 22 Jun 2021 01:52:54 +0000 (18:52 -0700)]
ip6_tunnel: fix GRE6 segmentation
[ Upstream commit
a6e3f2985a80ef6a45a17d2d9d9151f17ea3ce07 ]
Commit
6c11fbf97e69 ("ip6_tunnel: add MPLS transmit support")
moved assiging inner_ipproto down from ipxip6_tnl_xmit() to
its callee ip6_tnl_xmit(). The latter is also used by GRE.
Since commit
38720352412a ("gre: Use inner_proto to obtain inner
header protocol") GRE had been depending on skb->inner_protocol
during segmentation. It sets it in gre_build_header() and reads
it in gre_gso_segment(). Changes to ip6_tnl_xmit() overwrite
the protocol, resulting in GSO skbs getting dropped.
Note that inner_protocol is a union with inner_ipproto,
GRE uses the former while the change switched it to the latter
(always setting it to just IPPROTO_GRE).
Restore the original location of skb_set_inner_ipproto(),
it is unclear why it was moved in the first place.
Fixes:
6c11fbf97e69 ("ip6_tunnel: add MPLS transmit support")
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Tested-by: Vadim Fedorenko <vfedorenko@novek.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eric Dumazet [Mon, 21 Jun 2021 14:44:17 +0000 (07:44 -0700)]
vxlan: add missing rcu_read_lock() in neigh_reduce()
[ Upstream commit
85e8b032d6ebb0f698a34dd22c2f13443d905888 ]
syzbot complained in neigh_reduce(), because rcu_read_lock_bh()
is treated differently than rcu_read_lock()
WARNING: suspicious RCU usage
5.13.0-rc6-syzkaller #0 Not tainted
-----------------------------
include/net/addrconf.h:313 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
3 locks held by kworker/0:0/5:
#0:
ffff888011064d38 ((wq_completion)events){+.+.}-{0:0}, at: arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
#0:
ffff888011064d38 ((wq_completion)events){+.+.}-{0:0}, at: atomic64_set include/asm-generic/atomic-instrumented.h:856 [inline]
#0:
ffff888011064d38 ((wq_completion)events){+.+.}-{0:0}, at: atomic_long_set include/asm-generic/atomic-long.h:41 [inline]
#0:
ffff888011064d38 ((wq_completion)events){+.+.}-{0:0}, at: set_work_data kernel/workqueue.c:617 [inline]
#0:
ffff888011064d38 ((wq_completion)events){+.+.}-{0:0}, at: set_work_pool_and_clear_pending kernel/workqueue.c:644 [inline]
#0:
ffff888011064d38 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x871/0x1600 kernel/workqueue.c:2247
#1:
ffffc90000ca7da8 ((work_completion)(&port->wq)){+.+.}-{0:0}, at: process_one_work+0x8a5/0x1600 kernel/workqueue.c:2251
#2:
ffffffff8bf795c0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0x1da/0x3130 net/core/dev.c:4180
stack backtrace:
CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.13.0-rc6-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: events ipvlan_process_multicast
Call Trace:
__dump_stack lib/dump_stack.c:79 [inline]
dump_stack+0x141/0x1d7 lib/dump_stack.c:120
__in6_dev_get include/net/addrconf.h:313 [inline]
__in6_dev_get include/net/addrconf.h:311 [inline]
neigh_reduce drivers/net/vxlan.c:2167 [inline]
vxlan_xmit+0x34d5/0x4c30 drivers/net/vxlan.c:2919
__netdev_start_xmit include/linux/netdevice.h:4944 [inline]
netdev_start_xmit include/linux/netdevice.h:4958 [inline]
xmit_one net/core/dev.c:3654 [inline]
dev_hard_start_xmit+0x1eb/0x920 net/core/dev.c:3670
__dev_queue_xmit+0x2133/0x3130 net/core/dev.c:4246
ipvlan_process_multicast+0xa99/0xd70 drivers/net/ipvlan/ipvlan_core.c:287
process_one_work+0x98d/0x1600 kernel/workqueue.c:2276
worker_thread+0x64c/0x1120 kernel/workqueue.c:2422
kthread+0x3b1/0x4a0 kernel/kthread.c:313
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
Fixes:
f564f45c4518 ("vxlan: add ipv6 proxy support")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Po-Hao Huang [Mon, 26 Apr 2021 01:32:52 +0000 (09:32 +0800)]
rtw88: 8822c: fix lc calibration timing
[ Upstream commit
05684fd583e1acc34dddea283838fbfbed4904a0 ]
Before this patch, we use value from 2 seconds ago to decide
whether we should do lc calibration.
Although this don't happen frequently, fix flow to the way it should be.
Fixes:
7ae7784ec2a8 ("rtw88: 8822c: add LC calibration for RTL8822C")
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210426013252.5665-3-pkshih@realtek.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Luca Coelho [Sat, 12 Jun 2021 11:32:40 +0000 (14:32 +0300)]
iwlwifi: increase PNVM load timeout
[ Upstream commit
5cc816ef9db1fe03f73e56e9d8f118add9c6efe4 ]
The FW has a watchdog of 200ms in the PNVM load flow, so the driver
should have a slightly higher timeout. Change the timeout from 100ms
to 250ms.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Fixes:
70d3ca86b025 ("iwlwifi: mvm: ring the doorbell and wait for PNVM load completion")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210612142637.ba22aec1e2be.I36bfadc28c480f4fc57266c075a79e8ea4a6934f@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ayush Sawal [Tue, 22 Jun 2021 03:55:31 +0000 (09:25 +0530)]
xfrm: Fix xfrm offload fallback fail case
[ Upstream commit
dd72fadf2186fc8a6018f97fe72f4d5ca05df440 ]
In case of xfrm offload, if xdo_dev_state_add() of driver returns
-EOPNOTSUPP, xfrm offload fallback is failed.
In xfrm state_add() both xso->dev and xso->real_dev are initialized to
dev and when err(-EOPNOTSUPP) is returned only xso->dev is set to null.
So in this scenario the condition in func validate_xmit_xfrm(),
if ((x->xso.dev != dev) && (x->xso.real_dev == dev))
return skb;
returns true, due to which skb is returned without calling esp_xmit()
below which has fallback code. Hence the CRYPTO_FALLBACK is failing.
So fixing this with by keeping x->xso.real_dev as NULL when err is
returned in func xfrm_dev_state_add().
Fixes:
bdfd2d1fa79a ("bonding/xfrm: use real_dev instead of slave_dev")
Signed-off-by: Ayush Sawal <ayush.sawal@chelsio.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eric Dumazet [Mon, 21 Jun 2021 17:54:49 +0000 (10:54 -0700)]
pkt_sched: sch_qfq: fix qfq_change_class() error path
[ Upstream commit
0cd58e5c53babb9237b741dbef711f0a9eb6d3fd ]
If qfq_change_class() is unable to allocate memory for qfq_aggregate,
it frees the class that has been inserted in the class hash table,
but does not unhash it.
Defer the insertion after the problematic allocation.
BUG: KASAN: use-after-free in hlist_add_head include/linux/list.h:884 [inline]
BUG: KASAN: use-after-free in qdisc_class_hash_insert+0x200/0x210 net/sched/sch_api.c:731
Write of size 8 at addr
ffff88814a534f10 by task syz-executor.4/31478
CPU: 0 PID: 31478 Comm: syz-executor.4 Not tainted 5.13.0-rc6-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:79 [inline]
dump_stack+0x141/0x1d7 lib/dump_stack.c:120
print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:233
__kasan_report mm/kasan/report.c:419 [inline]
kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:436
hlist_add_head include/linux/list.h:884 [inline]
qdisc_class_hash_insert+0x200/0x210 net/sched/sch_api.c:731
qfq_change_class+0x96c/0x1990 net/sched/sch_qfq.c:489
tc_ctl_tclass+0x514/0xe50 net/sched/sch_api.c:2113
rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5564
netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2504
netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]
netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1340
netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1929
sock_sendmsg_nosec net/socket.c:654 [inline]
sock_sendmsg+0xcf/0x120 net/socket.c:674
____sys_sendmsg+0x6e8/0x810 net/socket.c:2350
___sys_sendmsg+0xf3/0x170 net/socket.c:2404
__sys_sendmsg+0xe5/0x1b0 net/socket.c:2433
do_syscall_64+0x3a/0xb0 arch/x86/entry/common.c:47
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x4665d9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:
00007fdc7b5f0188 EFLAGS:
00000246 ORIG_RAX:
000000000000002e
RAX:
ffffffffffffffda RBX:
000000000056bf80 RCX:
00000000004665d9
RDX:
0000000000000000 RSI:
00000000200001c0 RDI:
0000000000000003
RBP:
00007fdc7b5f01d0 R08:
0000000000000000 R09:
0000000000000000
R10:
0000000000000000 R11:
0000000000000246 R12:
0000000000000002
R13:
00007ffcf7310b3f R14:
00007fdc7b5f0300 R15:
0000000000022000
Allocated by task 31445:
kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38
kasan_set_track mm/kasan/common.c:46 [inline]
set_alloc_info mm/kasan/common.c:428 [inline]
____kasan_kmalloc mm/kasan/common.c:507 [inline]
____kasan_kmalloc mm/kasan/common.c:466 [inline]
__kasan_kmalloc+0x9b/0xd0 mm/kasan/common.c:516
kmalloc include/linux/slab.h:556 [inline]
kzalloc include/linux/slab.h:686 [inline]
qfq_change_class+0x705/0x1990 net/sched/sch_qfq.c:464
tc_ctl_tclass+0x514/0xe50 net/sched/sch_api.c:2113
rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5564
netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2504
netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]
netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1340
netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1929
sock_sendmsg_nosec net/socket.c:654 [inline]
sock_sendmsg+0xcf/0x120 net/socket.c:674
____sys_sendmsg+0x6e8/0x810 net/socket.c:2350
___sys_sendmsg+0xf3/0x170 net/socket.c:2404
__sys_sendmsg+0xe5/0x1b0 net/socket.c:2433
do_syscall_64+0x3a/0xb0 arch/x86/entry/common.c:47
entry_SYSCALL_64_after_hwframe+0x44/0xae
Freed by task 31445:
kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38
kasan_set_track+0x1c/0x30 mm/kasan/common.c:46
kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:357
____kasan_slab_free mm/kasan/common.c:360 [inline]
____kasan_slab_free mm/kasan/common.c:325 [inline]
__kasan_slab_free+0xfb/0x130 mm/kasan/common.c:368
kasan_slab_free include/linux/kasan.h:212 [inline]
slab_free_hook mm/slub.c:1583 [inline]
slab_free_freelist_hook+0xdf/0x240 mm/slub.c:1608
slab_free mm/slub.c:3168 [inline]
kfree+0xe5/0x7f0 mm/slub.c:4212
qfq_change_class+0x10fb/0x1990 net/sched/sch_qfq.c:518
tc_ctl_tclass+0x514/0xe50 net/sched/sch_api.c:2113
rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5564
netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2504
netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]
netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1340
netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1929
sock_sendmsg_nosec net/socket.c:654 [inline]
sock_sendmsg+0xcf/0x120 net/socket.c:674
____sys_sendmsg+0x6e8/0x810 net/socket.c:2350
___sys_sendmsg+0xf3/0x170 net/socket.c:2404
__sys_sendmsg+0xe5/0x1b0 net/socket.c:2433
do_syscall_64+0x3a/0xb0 arch/x86/entry/common.c:47
entry_SYSCALL_64_after_hwframe+0x44/0xae
The buggy address belongs to the object at
ffff88814a534f00
which belongs to the cache kmalloc-128 of size 128
The buggy address is located 16 bytes inside of
128-byte region [
ffff88814a534f00,
ffff88814a534f80)
The buggy address belongs to the page:
page:
ffffea0005294d00 refcount:1 mapcount:0 mapping:
0000000000000000 index:0x0 pfn:0x14a534
flags: 0x57ff00000000200(slab|node=1|zone=2|lastcpupid=0x7ff)
raw:
057ff00000000200 ffffea00004fee00 0000000600000006 ffff8880110418c0
raw:
0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0x12cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY), pid 29797, ts
604817765317, free_ts
604810151744
prep_new_page mm/page_alloc.c:2358 [inline]
get_page_from_freelist+0x1033/0x2b60 mm/page_alloc.c:3994
__alloc_pages+0x1b2/0x500 mm/page_alloc.c:5200
alloc_pages+0x18c/0x2a0 mm/mempolicy.c:2272
alloc_slab_page mm/slub.c:1646 [inline]
allocate_slab+0x2c5/0x4c0 mm/slub.c:1786
new_slab mm/slub.c:1849 [inline]
new_slab_objects mm/slub.c:2595 [inline]
___slab_alloc+0x4a1/0x810 mm/slub.c:2758
__slab_alloc.constprop.0+0xa7/0xf0 mm/slub.c:2798
slab_alloc_node mm/slub.c:2880 [inline]
slab_alloc mm/slub.c:2922 [inline]
__kmalloc+0x315/0x330 mm/slub.c:4050
kmalloc include/linux/slab.h:561 [inline]
kzalloc include/linux/slab.h:686 [inline]
__register_sysctl_table+0x112/0x1090 fs/proc/proc_sysctl.c:1318
mpls_dev_sysctl_register+0x1b7/0x2d0 net/mpls/af_mpls.c:1421
mpls_add_dev net/mpls/af_mpls.c:1472 [inline]
mpls_dev_notify+0x214/0x8b0 net/mpls/af_mpls.c:1588
notifier_call_chain+0xb5/0x200 kernel/notifier.c:83
call_netdevice_notifiers_info+0xb5/0x130 net/core/dev.c:2121
call_netdevice_notifiers_extack net/core/dev.c:2133 [inline]
call_netdevice_notifiers net/core/dev.c:2147 [inline]
register_netdevice+0x106b/0x1500 net/core/dev.c:10312
veth_newlink+0x585/0xac0 drivers/net/veth.c:1547
__rtnl_newlink+0x1062/0x1710 net/core/rtnetlink.c:3452
rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3500
page last free stack trace:
reset_page_owner include/linux/page_owner.h:24 [inline]
free_pages_prepare mm/page_alloc.c:1298 [inline]
free_pcp_prepare+0x223/0x300 mm/page_alloc.c:1342
free_unref_page_prepare mm/page_alloc.c:3250 [inline]
free_unref_page+0x12/0x1d0 mm/page_alloc.c:3298
__vunmap+0x783/0xb60 mm/vmalloc.c:2566
free_work+0x58/0x70 mm/vmalloc.c:80
process_one_work+0x98d/0x1600 kernel/workqueue.c:2276
worker_thread+0x64c/0x1120 kernel/workqueue.c:2422
kthread+0x3b1/0x4a0 kernel/kthread.c:313
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
Memory state around the buggy address:
ffff88814a534e00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88814a534e80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>
ffff88814a534f00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88814a534f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88814a535000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Fixes:
462dbc9101acd ("pkt_sched: QFQ Plus: fair-queueing service at DRR cost")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pablo Neira Ayuso [Fri, 18 Jun 2021 23:25:14 +0000 (01:25 +0200)]
netfilter: nf_tables_offload: check FLOW_DISSECTOR_KEY_BASIC in VLAN transfer logic
[ Upstream commit
ea45fdf82cc90430bb7c280e5e53821e833782c5 ]
The VLAN transfer logic should actually check for
FLOW_DISSECTOR_KEY_BASIC, not FLOW_DISSECTOR_KEY_CONTROL. Moreover, do
not fallback to case 2) .n_proto is set to 802.1q or 802.1ad, if
FLOW_DISSECTOR_KEY_BASIC is unset.
Fixes:
783003f3bb8a ("netfilter: nftables_offload: special ethertype handling for VLAN")
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jakub Kicinski [Fri, 18 Jun 2021 20:34:06 +0000 (13:34 -0700)]
tls: prevent oversized sendfile() hangs by ignoring MSG_MORE
[ Upstream commit
d452d48b9f8b1a7f8152d33ef52cfd7fe1735b0a ]
We got multiple reports that multi_chunk_sendfile test
case from tls selftest fails. This was sort of expected,
as the original fix was never applied (see it in the first
Link:). The test in question uses sendfile() with count
larger than the size of the underlying file. This will
make splice set MSG_MORE on all sendpage calls, meaning
TLS will never close and flush the last partial record.
Eric seem to have addressed a similar problem in
commit
35f9c09fe9c7 ("tcp: tcp_sendpages() should call tcp_push() once")
by introducing MSG_SENDPAGE_NOTLAST. Unlike MSG_MORE
MSG_SENDPAGE_NOTLAST is not set on the last call
of a "pipefull" of data (PIPE_DEF_BUFFERS == 16,
so every 16 pages or whenever we run out of data).
Having a break every 16 pages should be fine, TLS
can pack exactly 4 pages into a record, so for
aligned reads there should be no difference,
unaligned may see one extra record per sendpage().
Sticking to TCP semantics seems preferable to modifying
splice, but we can revisit it if real life scenarios
show a regression.
Reported-by: Vadim Fedorenko <vfedorenko@novek.ru>
Reported-by: Seth Forshee <seth.forshee@canonical.com>
Link: https://lore.kernel.org/netdev/1591392508-14592-1-git-send-email-pooja.trivedi@stackpath.com/
Fixes:
3c4d7559159b ("tls: kernel TLS support")
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Tested-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yunsheng Lin [Thu, 17 Jun 2021 01:04:14 +0000 (09:04 +0800)]
net: sched: add barrier to ensure correct ordering for lockless qdisc
[ Upstream commit
89837eb4b2463c556a123437f242d6c2bc62ce81 ]
The spin_trylock() was assumed to contain the implicit
barrier needed to ensure the correct ordering between
STATE_MISSED setting/clearing and STATE_MISSED checking
in commit
a90c57f2cedd ("net: sched: fix packet stuck
problem for lockless qdisc").
But it turns out that spin_trylock() only has load-acquire
semantic, for strongly-ordered system(like x86), the compiler
barrier implicitly contained in spin_trylock() seems enough
to ensure the correct ordering. But for weakly-orderly system
(like arm64), the store-release semantic is needed to ensure
the correct ordering as clear_bit() and test_bit() is store
operation, see queued_spin_lock().
So add the explicit barrier to ensure the correct ordering
for the above case.
Fixes:
a90c57f2cedd ("net: sched: fix packet stuck problem for lockless qdisc")
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Acked-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Antoine Tenart [Fri, 18 Jun 2021 15:15:53 +0000 (17:15 +0200)]
vrf: do not push non-ND strict packets with a source LLA through packet taps again
[ Upstream commit
603113c514e95c3350598bc3cccbd03af7ea4ab2 ]
Non-ND strict packets with a source LLA go through the packet taps
again, while non-ND strict packets with other source addresses do not,
and we can see a clone of those packets on the vrf interface (we should
not). This is due to a series of changes:
Commit
6f12fa775530[1] made non-ND strict packets not being pushed again
in the packet taps. This changed with commit
205704c618af[2] for those
packets having a source LLA, as they need a lookup with the orig_iif.
The issue now is those packets do not skip the 'vrf_ip6_rcv' function to
the end (as the ones without a source LLA) and go through the check to
call packet taps again. This check was changed by commit
6f12fa775530[1]
and do not exclude non-strict packets anymore. Packets matching
'need_strict && !is_ndisc && is_ll_src' are now being sent through the
packet taps again. This can be seen by dumping packets on the vrf
interface.
Fix this by having the same code path for all non-ND strict packets and
selectively lookup with the orig_iif for those with a source LLA. This
has the effect to revert to the pre-
205704c618af[2] condition, which
should also be easier to maintain.
[1]
6f12fa775530 ("vrf: mark skb for multicast or link-local as enslaved to VRF")
[2]
205704c618af ("vrf: packets with lladdr src needs dst at input with orig_iif when needs strict")
Fixes:
205704c618af ("vrf: packets with lladdr src needs dst at input with orig_iif when needs strict")
Cc: Stephen Suryaputra <ssuryaextr@gmail.com>
Reported-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Antoine Tenart <atenart@kernel.org>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pavel Skripkin [Fri, 18 Jun 2021 16:14:47 +0000 (19:14 +0300)]
net: ethernet: ezchip: fix error handling
[ Upstream commit
0de449d599594f5472e00267d651615c7f2c6c1d ]
As documented at drivers/base/platform.c for platform_get_irq:
* Gets an IRQ for a platform device and prints an error message if finding the
* IRQ fails. Device drivers should check the return value for errors so as to
* not pass a negative integer value to the request_irq() APIs.
So, the driver should check that platform_get_irq() return value
is _negative_, not that it's equal to zero, because -ENXIO (return
value from request_irq() if irq was not found) will
pass this check and it leads to passing negative irq to request_irq()
Fixes:
0dd077093636 ("NET: Add ezchip ethernet driver")
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pavel Skripkin [Fri, 18 Jun 2021 16:14:31 +0000 (19:14 +0300)]
net: ethernet: ezchip: fix UAF in nps_enet_remove
[ Upstream commit
e4b8700e07a86e8eab6916aa5c5ba99042c34089 ]
priv is netdev private data, but it is used
after free_netdev(). It can cause use-after-free when accessing priv
pointer. So, fix it by moving free_netdev() after netif_napi_del()
call.
Fixes:
0dd077093636 ("NET: Add ezchip ethernet driver")
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pavel Skripkin [Fri, 18 Jun 2021 14:57:31 +0000 (17:57 +0300)]
net: ethernet: aeroflex: fix UAF in greth_of_remove
[ Upstream commit
e3a5de6d81d8b2199935c7eb3f7d17a50a7075b7 ]
static int greth_of_remove(struct platform_device *of_dev)
{
...
struct greth_private *greth = netdev_priv(ndev);
...
unregister_netdev(ndev);
free_netdev(ndev);
of_iounmap(&of_dev->resource[0], greth->regs, resource_size(&of_dev->resource[0]));
...
}
greth is netdev private data, but it is used
after free_netdev(). It can cause use-after-free when accessing greth
pointer. So, fix it by moving free_netdev() after of_iounmap()
call.
Fixes:
d4c41139df6e ("net: Add Aeroflex Gaisler 10/100/1G Ethernet MAC driver")
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lorenzo Bianconi [Tue, 27 Apr 2021 10:07:14 +0000 (12:07 +0200)]
mt76: mt7615: fix NULL pointer dereference in tx_prepare_skb()
[ Upstream commit
8d3cdc1bbb1d355f0ebef973175ae5fd74286feb ]
Fix theoretical NULL pointer dereference in mt7615_tx_prepare_skb and
mt7663_usb_sdio_tx_prepare_skb routines. This issue has been identified
by code analysis.
Fixes:
6aa4ed7927f11 ("mt76: mt7615: implement DMA support for MT7622")
Fixes:
4bb586bc33b98 ("mt76: mt7663u: sync probe sampling with rate configuration")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lorenzo Bianconi [Tue, 27 Apr 2021 10:05:00 +0000 (12:05 +0200)]
mt76: fix possible NULL pointer dereference in mt76_tx
[ Upstream commit
d7400a2f3e295b8cee692c7a66e10f60015a3c37 ]
Even if this is not a real issue since mt76_tx is never run with wcid set
to NULL, fix a theoretical NULL pointer dereference in mt76_tx routine
Fixes:
db9f11d3433f7 ("mt76: store wcid tx rate info in one u32 reduce locking")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wang Hai [Wed, 16 Jun 2021 04:25:34 +0000 (12:25 +0800)]
samples/bpf: Fix the error return code of xdp_redirect's main()
[ Upstream commit
7c6090ee2a7b3315410cfc83a94c3eb057407b25 ]
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
If bpf_map_update_elem() failed, main() should return a negative error.
Fixes:
832622e6bd18 ("xdp: sample program for new bpf_redirect helper")
Signed-off-by: Wang Hai <wanghai38@huawei.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20210616042534.315097-1-wanghai38@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wang Hai [Wed, 16 Jun 2021 04:23:24 +0000 (12:23 +0800)]
samples/bpf: Fix Segmentation fault for xdp_redirect command
[ Upstream commit
85102ba58b4125ebad941d7555c3c248b23efd16 ]
A Segmentation fault error is caused when the following command
is executed.
$ sudo ./samples/bpf/xdp_redirect lo
Segmentation fault
This command is missing a device <IFNAME|IFINDEX> as an argument, resulting
in out-of-bounds access from argv.
If the number of devices for the xdp_redirect parameter is not 2,
we should report an error and exit.
Fixes:
24251c264798 ("samples/bpf: add option for native and skb mode for redirect apps")
Signed-off-by: Wang Hai <wanghai38@huawei.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20210616042324.314832-1-wanghai38@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jack Wang [Mon, 14 Jun 2021 09:03:33 +0000 (11:03 +0200)]
RDMA/rtrs-srv: Set minimal max_send_wr and max_recv_wr
[ Upstream commit
5e91eabf66c854f16ca2e954e5c68939bc81601e ]
Currently rtrs when create_qp use a coarse numbers (bigger in general),
which leads to hardware create more resources which only waste memory with
no benefits.
For max_send_wr, we don't really need alway max_qp_wr size when creating
qp, reduce it to cq_size.
For max_recv_wr, cq_size is enough.
With the patch when sess_queue_depth=128, per session (2 paths) memory
consumption reduced from 188 MB to 65MB
When always_invalidate is enabled, we need send more wr, so treat it
special.
Fixes:
9cb837480424e ("RDMA/rtrs: server: main functionality")
Link: https://lore.kernel.org/r/20210614090337.29557-2-jinpu.wang@ionos.com
Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
Reviewed-by: Md Haris Iqbal <haris.iqbal@cloud.ionos.com>
Signed-off-by: Gioh Kim <gi-oh.kim@ionos.com>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tony Ambardar [Fri, 18 Jun 2021 06:14:04 +0000 (23:14 -0700)]
bpf: Fix libelf endian handling in resolv_btfids
[ Upstream commit
61e8aeda9398925f8c6fc290585bdd9727d154c4 ]
The vmlinux ".BTF_ids" ELF section is declared in btf_ids.h to hold a list
of zero-filled BTF IDs, which is then patched at link-time with correct
values by resolv_btfids. The section is flagged as "allocable" to preclude
compression, but notably the section contents (BTF IDs) are untyped.
When patching the BTF IDs, resolve_btfids writes in host-native endianness
and relies on libelf for any required translation on reading and updating
vmlinux. However, since the type of the .BTF_ids section content defaults
to ELF_T_BYTE (i.e. unsigned char), no translation occurs. This results in
incorrect patched values when cross-compiling to non-native endianness,
and can manifest as kernel Oops and test failures which are difficult to
troubleshoot [1].
Explicitly set the type of patched data to ELF_T_WORD, the architecture-
neutral ELF type corresponding to the u32 BTF IDs. This enables libelf to
transparently perform any needed endian conversions.
Fixes:
fbbb68de80a4 ("bpf: Add resolve_btfids tool to resolve BTF IDs in ELF object")
Signed-off-by: Tony Ambardar <Tony.Ambardar@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Jiri Olsa <jolsa@redhat.com>
Cc: Frank Eigler <fche@redhat.com>
Cc: Mark Wielaard <mark@klomp.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Yonghong Song <yhs@fb.com>
Link: https://lore.kernel.org/bpf/CAPGftE_eY-Zdi3wBcgDfkz_iOr1KF10n=9mJHm1_a_PykcsoeA@mail.gmail.com
Link: https://lore.kernel.org/bpf/20210618061404.818569-1-Tony.Ambardar@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Magnus Karlsson [Fri, 18 Jun 2021 07:58:05 +0000 (09:58 +0200)]
xsk: Fix broken Tx ring validation
[ Upstream commit
f654fae47e83e56b454fbbfd0af0a4f232e356d6 ]
Fix broken Tx ring validation for AF_XDP. The commit under the Fixes
tag, fixed an off-by-one error in the validation but introduced
another error. Descriptors are now let through even if they straddle a
chunk boundary which they are not allowed to do in aligned mode. Worse
is that they are let through even if they straddle the end of the umem
itself, tricking the kernel to read data outside the allowed umem
region which might or might not be mapped at all.
Fix this by reintroducing the old code, but subtract the length by one
to fix the off-by-one error that the original patch was
addressing. The test chunk != chunk_end makes sure packets do not
straddle chunk boundraries. Note that packets of zero length are
allowed in the interface, therefore the test if the length is
non-zero.
Fixes:
ac31565c2193 ("xsk: Fix for xp_aligned_validate_desc() when len == chunk_size")
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Acked-by: Björn Töpel <bjorn@kernel.org>
Link: https://lore.kernel.org/bpf/20210618075805.14412-1-magnus.karlsson@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Magnus Karlsson [Thu, 17 Jun 2021 09:22:55 +0000 (11:22 +0200)]
xsk: Fix missing validation for skb and unaligned mode
[ Upstream commit
2f99619820c2269534eb2c0cde44870313c6d353 ]
Fix a missing validation of a Tx descriptor when executing in skb mode
and the umem is in unaligned mode. A descriptor could point to a
buffer straddling the end of the umem, thus effectively tricking the
kernel to read outside the allowed umem region. This could lead to a
kernel crash if that part of memory is not mapped.
In zero-copy mode, the descriptor validation code rejects such
descriptors by checking a bit in the DMA address that tells us if the
next page is physically contiguous or not. For the last page in the
umem, this bit is not set, therefore any descriptor pointing to a
packet straddling this last page boundary will be rejected. However,
the skb path does not use this bit since it copies out data and can do
so to two different pages. (It also does not have the array of DMA
address, so it cannot even store this bit.) The code just returned
that the packet is always physically contiguous. But this is
unfortunately also returned for the last page in the umem, which means
that packets that cross the end of the umem are being allowed, which
they should not be.
Fix this by introducing a check for this in the SKB path only, not
penalizing the zero-copy path.
Fixes:
2b43470add8c ("xsk: Introduce AF_XDP buffer allocation API")
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Björn Töpel <bjorn@kernel.org>
Link: https://lore.kernel.org/bpf/20210617092255.3487-1-magnus.karlsson@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Daniel Xu [Wed, 16 Jun 2021 21:52:11 +0000 (14:52 -0700)]
selftests/bpf: Whitelist test_progs.h from .gitignore
[ Upstream commit
809ed84de8b3f2fd7b1d06efb94bf98fd318a7d7 ]
Somehow test_progs.h was being included by the existing rule:
/test_progs*
This is bad because:
1) test_progs.h is a checked in file
2) grep-like tools like ripgrep[0] respect gitignore and
test_progs.h was being hidden from searches
[0]: https://github.com/BurntSushi/ripgrep
Fixes:
74b5a5968fe8 ("selftests/bpf: Replace test_progs and test_maps w/ general rule")
Signed-off-by: Daniel Xu <dxu@dxuuu.xyz>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/a46f64944bf678bc652410ca6028d3450f4f7f4b.1623880296.git.dxu@dxuuu.xyz
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bob Pearson [Fri, 4 Jun 2021 23:05:59 +0000 (18:05 -0500)]
RDMA/rxe: Fix qp reference counting for atomic ops
[ Upstream commit
15ae1375ea91ae2dee6f12d71a79d8c0a10a30bf ]
Currently the rdma_rxe driver attempts to protect atomic responder
resources by taking a reference to the qp which is only freed when the
resource is recycled for a new read or atomic operation. This means that
in normal circumstances there is almost always an extra qp reference once
an atomic operation has been executed which prevents cleaning up the qp
and associated pd and cqs when the qp is destroyed.
This patch removes the call to rxe_add_ref() in send_atomic_ack() and the
call to rxe_drop_ref() in free_rd_atomic_resource(). If the qp is
destroyed while a peer is retrying an atomic op it will cause the
operation to fail which is acceptable.
Link: https://lore.kernel.org/r/20210604230558.4812-1-rpearsonhpe@gmail.com
Reported-by: Zhu Yanjun <zyjzyj2000@gmail.com>
Fixes:
86af61764151 ("IB/rxe: remove unnecessary skb_clone")
Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pablo Neira Ayuso [Fri, 11 Jun 2021 17:26:56 +0000 (19:26 +0200)]
netfilter: nft_tproxy: restrict support to TCP and UDP transport protocols
[ Upstream commit
52f0f4e178c757b3d356087376aad8bd77271828 ]
Add unfront check for TCP and UDP packets before performing further
processing.
Fixes:
4ed8eb6570a4 ("netfilter: nf_tables: Add native tproxy support")
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pablo Neira Ayuso [Thu, 10 Jun 2021 18:20:31 +0000 (20:20 +0200)]
netfilter: nft_osf: check for TCP packet before further processing
[ Upstream commit
8f518d43f89ae00b9cf5460e10b91694944ca1a8 ]
The osf expression only supports for TCP packets, add a upfront sanity
check to skip packet parsing if this is not a TCP packet.
Fixes:
b96af92d6eaf ("netfilter: nf_tables: implement Passive OS fingerprint module in nft_osf")
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pablo Neira Ayuso [Thu, 10 Jun 2021 18:20:30 +0000 (20:20 +0200)]
netfilter: nft_exthdr: check for IPv6 packet before further processing
[ Upstream commit
cdd73cc545c0fb9b1a1f7b209f4f536e7990cff4 ]
ipv6_find_hdr() does not validate that this is an IPv6 packet. Add a
sanity check for calling ipv6_find_hdr() to make sure an IPv6 packet
is passed for parsing.
Fixes:
96518518cc41 ("netfilter: add nftables")
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Leon Romanovsky [Mon, 31 May 2021 16:04:44 +0000 (19:04 +0300)]
RDMA/mlx5: Don't add slave port to unaffiliated list
[ Upstream commit
7ce6095e3bff8e20ce018b050960b527e298f7df ]
The mlx5_ib_bind_slave_port() doesn't remove multiport device from the
unaffiliated list, but mlx5_ib_unbind_slave_port() did it. This unbalanced
flow caused to the situation where mlx5_ib_unaffiliated_port_list was
changed during iteration.
Fixes:
32f69e4be269 ("{net, IB}/mlx5: Manage port association for multiport RoCE")
Link: https://lore.kernel.org/r/2726e6603b1e6ecfe76aa5a12a063af72173bcf7.1622477058.git.leonro@nvidia.com
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Liu Shixin [Tue, 15 Jun 2021 02:14:44 +0000 (10:14 +0800)]
netlabel: Fix memory leak in netlbl_mgmt_add_common
[ Upstream commit
b8f6b0522c298ae9267bd6584e19b942a0636910 ]
Hulk Robot reported memory leak in netlbl_mgmt_add_common.
The problem is non-freed map in case of netlbl_domhsh_add() failed.
BUG: memory leak
unreferenced object 0xffff888100ab7080 (size 96):
comm "syz-executor537", pid 360, jiffies
4294862456 (age 22.678s)
hex dump (first 32 bytes):
05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
fe 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 ................
backtrace:
[<
0000000008b40026>] netlbl_mgmt_add_common.isra.0+0xb2a/0x1b40
[<
000000003be10950>] netlbl_mgmt_add+0x271/0x3c0
[<
00000000c70487ed>] genl_family_rcv_msg_doit.isra.0+0x20e/0x320
[<
000000001f2ff614>] genl_rcv_msg+0x2bf/0x4f0
[<
0000000089045792>] netlink_rcv_skb+0x134/0x3d0
[<
0000000020e96fdd>] genl_rcv+0x24/0x40
[<
0000000042810c66>] netlink_unicast+0x4a0/0x6a0
[<
000000002e1659f0>] netlink_sendmsg+0x789/0xc70
[<
000000006e43415f>] sock_sendmsg+0x139/0x170
[<
00000000680a73d7>] ____sys_sendmsg+0x658/0x7d0
[<
0000000065cbb8af>] ___sys_sendmsg+0xf8/0x170
[<
0000000019932b6c>] __sys_sendmsg+0xd3/0x190
[<
00000000643ac172>] do_syscall_64+0x37/0x90
[<
000000009b79d6dc>] entry_SYSCALL_64_after_hwframe+0x44/0xae
Fixes:
63c416887437 ("netlabel: Add network address selectors to the NetLabel/LSM domain mapping")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Liu Shixin <liushixin2@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Seevalamuthu Mariappan [Tue, 25 May 2021 13:30:28 +0000 (15:30 +0200)]
ath11k: send beacon template after vdev_start/restart during csa
[ Upstream commit
979ebc54cf13bd1e3eb6e21766d208d5de984fb8 ]
Firmware has added assert if beacon template is received after
vdev_down. Firmware expects beacon template after vdev_start
and before vdev_up. This change is needed to support MBSSID EMA
cases in firmware.
Hence, Change the sequence in ath11k as expected from firmware.
This new change is not causing any issues with older
firmware.
Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1.r3-00011-QCAHKSWPL_SILICONZ-1
Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1.r4-00008-QCAHKSWPL_SILICONZ-1
Fixes:
d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Signed-off-by: Seevalamuthu Mariappan <seevalam@codeaurora.org>
[sven@narfation.org: added tested-on/fixes information]
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210525133028.2805615-1-sven@narfation.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Li [Tue, 25 May 2021 10:46:17 +0000 (18:46 +0800)]
ath10k: Fix an error code in ath10k_add_interface()
[ Upstream commit
e9ca70c735ce66fc6a0e02c8b6958434f74ef8de ]
When the code execute this if statement, the value of ret is 0.
However, we can see from the ath10k_warn() log that the value of
ret should be -EINVAL.
Clean up smatch warning:
drivers/net/wireless/ath/ath10k/mac.c:5596 ath10k_add_interface() warn:
missing error code 'ret'
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Fixes:
ccec9038c721 ("ath10k: enable raw encap mode and software crypto engine")
Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1621939577-62218-1-git-send-email-yang.lee@linux.alibaba.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christophe JAILLET [Sat, 22 May 2021 09:50:54 +0000 (11:50 +0200)]
ath11k: Fix an error handling path in ath11k_core_fetch_board_data_api_n()
[ Upstream commit
515bda1d1e51c64edf2a384a58801f85a80a3f2d ]
All error paths but this one 'goto err' in order to release some
resources.
Fix this.
Fixes:
d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/e959eb544f3cb04258507d8e25a6f12eab126bde.1621676864.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hang Zhang [Fri, 21 May 2021 22:32:38 +0000 (15:32 -0700)]
cw1200: Revert unnecessary patches that fix unreal use-after-free bugs
[ Upstream commit
3f60f4685699aa6006e58e424637e8e413e0a94d ]
A previous commit
4f68ef64cd7f ("cw1200: Fix concurrency
use-after-free bugs in cw1200_hw_scan()") tried to fix a seemingly
use-after-free bug between cw1200_bss_info_changed() and
cw1200_hw_scan(), where the former frees a sk_buff pointed
to by frame.skb, and the latter accesses the sk_buff
pointed to by frame.skb. However, this issue should be a
false alarm because:
(1) "frame.skb" is not a shared variable between the above
two functions, because "frame" is a local function variable,
each of the two functions has its own local "frame" - they
just happen to have the same variable name.
(2) the sk_buff(s) pointed to by these two "frame.skb" are
also two different object instances, they are individually
allocated by different dev_alloc_skb() within the two above
functions. To free one object instance will not invalidate
the access of another different one.
Based on these facts, the previous commit should be unnecessary.
Moreover, it also introduced a missing unlock which was
addressed in a subsequent commit
51c8d24101c7 ("cw1200: fix missing
unlock on error in cw1200_hw_scan()"). Now that the
original use-after-free is unreal, these two commits should
be reverted. This patch performs the reversion.
Fixes:
4f68ef64cd7f ("cw1200: Fix concurrency use-after-free bugs in cw1200_hw_scan()")
Fixes:
51c8d24101c7 ("cw1200: fix missing unlock on error in cw1200_hw_scan()")
Signed-off-by: Hang Zhang <zh.nvgt@gmail.com>
Acked-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210521223238.25020-1-zh.nvgt@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christophe JAILLET [Wed, 12 May 2021 20:58:30 +0000 (22:58 +0200)]
brcmsmac: mac80211_if: Fix a resource leak in an error handling path
[ Upstream commit
9a25344d5177c2b9285532236dc3d10a091f39a8 ]
If 'brcms_attach()' fails, we must undo the previous 'ieee80211_alloc_hw()'
as already done in the remove function.
Fixes:
5b435de0d786 ("net: wireless: add brcm80211 drivers")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/8fbc171a1a493b38db5a6f0873c6021fca026a6c.1620852921.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tong Tiangen [Tue, 1 Jun 2021 10:01:28 +0000 (18:01 +0800)]
brcmfmac: Fix a double-free in brcmf_sdio_bus_reset
[ Upstream commit
7ea7a1e05c7ff5ffc9f9ec1f0849f6ceb7fcd57c ]
brcmf_sdiod_remove has been called inside brcmf_sdiod_probe when fails,
so there's no need to call another one. Otherwise, sdiodev->freezer
would be double freed.
Fixes:
7836102a750a ("brcmfmac: reset SDIO bus on a firmware crash")
Signed-off-by: Tong Tiangen <tongtiangen@huawei.com>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210601100128.69561-1-tongtiangen@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Alvin Šipraga [Thu, 6 May 2021 13:20:12 +0000 (13:20 +0000)]
brcmfmac: correctly report average RSSI in station info
[ Upstream commit
9a1590934d9a02e570636432b93052c0c035f31f ]
The rx_lastpkt_rssi field provided by the firmware is suitable for
NL80211_STA_INFO_{SIGNAL,CHAIN_SIGNAL}, while the rssi field is an
average. Fix up the assignments and set the correct STA_INFO bits. This
lets userspace know that the average RSSI is part of the station info.
Fixes:
cae355dc90db ("brcmfmac: Add RSSI information to get_station.")
Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210506132010.3964484-2-alsi@bang-olufsen.dk
Signed-off-by: Sasha Levin <sashal@kernel.org>
Alvin Šipraga [Thu, 6 May 2021 13:20:12 +0000 (13:20 +0000)]
brcmfmac: fix setting of station info chains bitmask
[ Upstream commit
feb45643762172110cb3a44f99dd54304f33b711 ]
The sinfo->chains field is a bitmask for filled values in chain_signal
and chain_signal_avg, not a count. Treat it as such so that the driver
can properly report per-chain RSSI information.
Before (MIMO mode):
$ iw dev wlan0 station dump
...
signal: -51 [-51] dBm
After (MIMO mode):
$ iw dev wlan0 station dump
...
signal: -53 [-53, -54] dBm
Fixes:
cae355dc90db ("brcmfmac: Add RSSI information to get_station.")
Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210506132010.3964484-1-alsi@bang-olufsen.dk
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zhen Lei [Sat, 15 May 2021 07:29:49 +0000 (15:29 +0800)]
ssb: Fix error return code in ssb_bus_scan()
[ Upstream commit
77a0989baa427dbd242c5784d05a53ca3d197d43 ]
Fix to return -EINVAL from the error handling case instead of 0, as done
elsewhere in this function.
Fixes:
61e115a56d1a ("[SSB]: add Sonics Silicon Backplane bus support")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Acked-by: Michael Büsch <m@bues.ch>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210515072949.7151-1-thunder.leizhen@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bryan O'Donoghue [Sat, 5 Jun 2021 17:33:47 +0000 (18:33 +0100)]
wcn36xx: Move hal_buf allocation to devm_kmalloc in probe
[ Upstream commit
ef48667557c53d4b51a1ee3090eab7699324c9de ]
Right now wcn->hal_buf is allocated in wcn36xx_start(). This is a problem
since we should have setup all of the buffers we required by the time
ieee80211_register_hw() is called.
struct ieee80211_ops callbacks may run prior to mac_start() and therefore
wcn->hal_buf must be initialized.
This is easily remediated by moving the allocation to probe() taking the
opportunity to tidy up freeing memory by using devm_kmalloc().
Fixes:
8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware")
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210605173347.2266003-1-bryan.odonoghue@linaro.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lucas Stach [Fri, 28 May 2021 18:01:35 +0000 (20:01 +0200)]
clk: imx8mq: remove SYS PLL 1/2 clock gates
[ Upstream commit
c586f53ae159c6c1390f093a1ec94baef2df9f3a ]
Remove the PLL clock gates as the allowing to gate the sys1_pll_266m breaks
the uSDHC module which is sporadically unable to enumerate devices after
this change. Also it makes AMP clock management harder with no obvious
benefit to Linux, so just revert the change.
Link: https://lore.kernel.org/r/20210528180135.1640876-1-l.stach@pengutronix.de
Fixes:
b04383b6a558 ("clk: imx8mq: Define gates for pll1/2 fixed dividers")
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Abel Vesa <abel.vesa@nxp.com>
Signed-off-by: Abel Vesa <abel.vesa@nxp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dongliang Mu [Fri, 11 Jun 2021 01:58:12 +0000 (09:58 +0800)]
ieee802154: hwsim: Fix possible memory leak in hwsim_subscribe_all_others
[ Upstream commit
ab372c2293f5d0b279f31c8d768566ea37602dc9 ]
In hwsim_subscribe_all_others, the error handling code performs
incorrectly if the second hwsim_alloc_edge fails. When this issue occurs,
it goes to sub_fail, without cleaning the edges allocated before.
Fixes:
f25da51fdc38 ("ieee802154: hwsim: add replacement for fakelb")
Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
Acked-by: Alexander Aring <aahringo@redhat.com>
Link: https://lore.kernel.org/r/20210611015812.1626999-1-mudongliangabcd@gmail.com
Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Randy Dunlap [Mon, 31 May 2021 14:41:28 +0000 (17:41 +0300)]
wireless: carl9170: fix LEDS build errors & warnings
[ Upstream commit
272fdc0c4542fad173b44965be02a16d6db95499 ]
kernel test robot reports over 200 build errors and warnings
that are due to this Kconfig problem when CARL9170=m,
MAC80211=y, and LEDS_CLASS=m.
WARNING: unmet direct dependencies detected for MAC80211_LEDS
Depends on [n]: NET [=y] && WIRELESS [=y] && MAC80211 [=y] && (LEDS_CLASS [=m]=y || LEDS_CLASS [=m]=MAC80211 [=y])
Selected by [m]:
- CARL9170_LEDS [=y] && NETDEVICES [=y] && WLAN [=y] && WLAN_VENDOR_ATH [=y] && CARL9170 [=m]
CARL9170_LEDS selects MAC80211_LEDS even though its kconfig
dependencies are not met. This happens because 'select' does not follow
any Kconfig dependency chains.
Fix this by making CARL9170_LEDS depend on MAC80211_LEDS, where
the latter supplies any needed dependencies on LEDS_CLASS.
Fixes:
1d7e1e6b1b8ed ("carl9170: Makefile, Kconfig files and MAINTAINERS")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: kernel test robot <lkp@intel.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: Christian Lamparter <chunkeey@googlemail.com>
Cc: linux-wireless@vger.kernel.org
Cc: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Christian Lamparter <chunkeey@googlemail.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210530031134.23274-1-rdunlap@infradead.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Mon, 31 May 2021 14:41:28 +0000 (17:41 +0300)]
ath10k: add missing error return code in ath10k_pci_probe()
[ Upstream commit
e2783e2f39ba99178dedfc1646d5cc0979d1bab3 ]
When chip_id is not supported, the resources will be freed
on path err_unsupported, these resources will also be freed
when calling ath10k_pci_remove(), it will cause double free,
so return -ENODEV when it doesn't support the device with wrong
chip_id.
Fixes:
c0c378f9907c ("ath10k: remove target soc ps code")
Fixes:
7505f7c3ec1d ("ath10k: create a chip revision whitelist")
Fixes:
f8914a14623a ("ath10k: restore QCA9880-AR1A (v1) detection")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210522105822.1091848-3-yangyingliang@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Mon, 31 May 2021 14:41:28 +0000 (17:41 +0300)]
ath10k: go to path err_unsupported when chip id is not supported
[ Upstream commit
9e88dd431d2345acdb7a549f3e88aaf4c2a307a1 ]
When chip id is not supported, it go to path err_unsupported
to print the error message.
Fixes:
f8914a14623a ("ath10k: restore QCA9880-AR1A (v1) detection")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210522105822.1091848-2-yangyingliang@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zhihao Cheng [Wed, 9 Jun 2021 11:59:16 +0000 (19:59 +0800)]
tools/bpftool: Fix error return code in do_batch()
[ Upstream commit
ca16b429f39b4ce013bfa7e197f25681e65a2a42 ]
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Fixes:
668da745af3c2 ("tools: bpftool: add support for quotations ...")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Reviewed-by: Quentin Monnet <quentin@isovalent.com>
Link: https://lore.kernel.org/bpf/20210609115916.2186872-1-chengzhihao1@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Colin Ian King [Tue, 8 Jun 2021 16:13:13 +0000 (17:13 +0100)]
drm: qxl: ensure surf.data is ininitialized
[ Upstream commit
fbbf23ddb2a1cc0c12c9f78237d1561c24006f50 ]
The object surf is not fully initialized and the uninitialized
field surf.data is being copied by the call to qxl_bo_create
via the call to qxl_gem_object_create. Set surf.data to zero
to ensure garbage data from the stack is not being copied.
Addresses-Coverity: ("Uninitialized scalar variable")
Fixes:
f64122c1f6ad ("drm: add new QXL driver. (v1.4)")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20210608161313.161922-1-colin.king@canonical.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Luca Ceresoli [Thu, 27 May 2021 21:16:47 +0000 (23:16 +0200)]
clk: vc5: fix output disabling when enabling a FOD
[ Upstream commit
fc336ae622df0ec114dbe5551a4d2760c535ecd0 ]
On 5P49V6965, when an output is enabled we enable the corresponding
FOD. When this happens for the first time, and specifically when writing
register VC5_OUT_DIV_CONTROL in vc5_clk_out_prepare(), all other outputs
are stopped for a short time and then restarted.
According to Renesas support this is intended: "The reason for that is VC6E
has synced up all output function".
This behaviour can be disabled at least on VersaClock 6E devices, of which
only the 5P49V6965 is currently implemented by this driver. This requires
writing bit 7 (bypass_sync{1..4}) in register 0x20..0x50. Those registers
are named "Unused Factory Reserved Register", and the bits are documented
as "Skip VDDO<N> verification", which does not clearly explain the relation
to FOD sync. However according to Renesas support as well as my testing
setting this bit does prevent disabling of all clock outputs when enabling
a FOD.
See "VersaClock ® 6E Family Register Descriptions and Programming Guide"
(August 30, 2018), Table 116 "Power Up VDD check", page 58:
https://www.renesas.com/us/en/document/mau/versaclock-6e-family-register-descriptions-and-programming-guide
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Reviewed-by: Adam Ford <aford173@gmail.com>
Link: https://lore.kernel.org/r/20210527211647.1520720-1-luca@lucaceresoli.net
Fixes:
2bda748e6ad8 ("clk: vc5: Add support for IDT VersaClock 5P49V6965")
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Maxime Ripard [Mon, 24 May 2021 13:18:51 +0000 (15:18 +0200)]
drm/vc4: hdmi: Fix error path of hpd-gpios
[ Upstream commit
e075a7811977ff51c917a65ed1896e08231d2615 ]
If the of_get_named_gpio_flags call fails in vc4_hdmi_bind, we jump to
the err_unprepare_hsm label. That label will then call
pm_runtime_disable and put_device on the DDC device.
We just retrieved the DDC device, so the latter is definitely justified.
However at that point we still haven't called pm_runtime_enable, so the
call to pm_runtime_disable is not supposed to be there.
Fixes:
10ee275cb12f ("drm/vc4: prepare for CEC support")
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210524131852.263883-1-maxime@cerno.tech
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kees Cook [Fri, 4 Jun 2021 01:40:55 +0000 (18:40 -0700)]
drm/pl111: Actually fix CONFIG_VEXPRESS_CONFIG depends
[ Upstream commit
4e566003571244f508408f59ce78f6ac2ccdba8e ]
VEXPRESS_CONFIG needs to either be missing, built-in, or modular when
pl111 is modular. Update the Kconfig to reflect the need.
Fixes:
4dc7c97d04dc ("drm/pl111: depend on CONFIG_VEXPRESS_CONFIG")
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210604014055.4060521-1-keescook@chromium.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kamal Heib [Thu, 3 Jun 2021 09:01:12 +0000 (12:01 +0300)]
RDMA/rxe: Fix failure during driver load
[ Upstream commit
32a25f2ea690dfaace19f7a3a916f5d7e1ddafe8 ]
To avoid the following failure when trying to load the rdma_rxe module
while IPv6 is disabled, add a check for EAFNOSUPPORT and ignore the
failure, also delete the needless debug print from rxe_setup_udp_tunnel().
$ modprobe rdma_rxe
modprobe: ERROR: could not insert 'rdma_rxe': Operation not permitted
Fixes:
dfdd6158ca2c ("IB/rxe: Fix kernel panic in udp_setup_tunnel")
Link: https://lore.kernel.org/r/20210603090112.36341-1-kamalheib1@gmail.com
Reported-by: Yi Zhang <yi.zhang@redhat.com>
Signed-off-by: Kamal Heib <kamalheib1@gmail.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kees Cook [Wed, 2 Jun 2021 21:52:52 +0000 (14:52 -0700)]
drm/pl111: depend on CONFIG_VEXPRESS_CONFIG
[ Upstream commit
4dc7c97d04dcaa9f19482f70dcfdbeb52cc7193f ]
Avoid randconfig build failures by requiring VEXPRESS_CONFIG:
aarch64-linux-gnu-ld: drivers/gpu/drm/pl111/pl111_versatile.o: in function `pl111_vexpress_clcd_init':
pl111_versatile.c:(.text+0x220): undefined reference to `devm_regmap_init_vexpress_config'
Fixes:
826fc86b5903 ("drm: pl111: Move VExpress setup into versatile init")
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210602215252.695994-4-keescook@chromium.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Leon Romanovsky [Wed, 19 May 2021 08:37:31 +0000 (11:37 +0300)]
RDMA/core: Sanitize WQ state received from the userspace
[ Upstream commit
f97442887275d11c88c2899e720fe945c1f61488 ]
The mlx4 and mlx5 implemented differently the WQ input checks. Instead of
duplicating mlx4 logic in the mlx5, let's prepare the input in the central
place.
The mlx5 implementation didn't check for validity of state input. It is
not real bug because our FW checked that, but still worth to fix.
Fixes:
f213c0527210 ("IB/uverbs: Add WQ support")
Link: https://lore.kernel.org/r/ac41ad6a81b095b1a8ad453dcf62cf8d3c5da779.1621413310.git.leonro@nvidia.com
Reported-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Boris Sukholitko [Tue, 1 Jun 2021 12:30:50 +0000 (15:30 +0300)]
net/sched: act_vlan: Fix modify to allow 0
[ Upstream commit
9c5eee0afca09cbde6bd00f77876754aaa552970 ]
Currently vlan modification action checks existence of vlan priority by
comparing it to 0. Therefore it is impossible to modify existing vlan
tag to have priority 0.
For example, the following tc command will change the vlan id but will
not affect vlan priority:
tc filter add dev eth1 ingress matchall action vlan modify id 300 \
priority 0 pipe mirred egress redirect dev eth2
The incoming packet on eth1:
ethertype 802.1Q (0x8100), vlan 200, p 4, ethertype IPv4
will be changed to:
ethertype 802.1Q (0x8100), vlan 300, p 4, ethertype IPv4
although the user has intended to have p == 0.
The fix is to add tcfv_push_prio_exists flag to struct tcf_vlan_params
and rely on it when deciding to set the priority.
Fixes:
45a497f2d149a4a8061c (net/sched: act_vlan: Introduce TCA_VLAN_ACT_MODIFY vlan action)
Signed-off-by: Boris Sukholitko <boris.sukholitko@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Xin Long [Sat, 29 May 2021 20:23:18 +0000 (16:23 -0400)]
xfrm: remove the fragment check for ipv6 beet mode
[ Upstream commit
eebd49a4ffb420a991c606e54aa3c9f02857a334 ]
In commit
68dc022d04eb ("xfrm: BEET mode doesn't support fragments
for inner packets"), it tried to fix the issue that in TX side the
packet is fragmented before the ESP encapping while in the RX side
the fragments always get reassembled before decapping with ESP.
This is not true for IPv6. IPv6 is different, and it's using exthdr
to save fragment info, as well as the ESP info. Exthdrs are added
in TX and processed in RX both in order. So in the above case, the
ESP decapping will be done earlier than the fragment reassembling
in TX side.
Here just remove the fragment check for the IPv6 inner packets to
recover the fragments support for BEET mode.
Fixes:
68dc022d04eb ("xfrm: BEET mode doesn't support fragments for inner packets")
Reported-by: Xiumei Mu <xmu@redhat.com>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>