@@ -4986,31 +4986,6 @@ int ath11k_wmi_pull_fw_stats(struct ath11k_base *ab, struct sk_buff *skb,return0;}-staticint-ath11k_pull_pdev_temp_ev(structath11k_base*ab,u8*evt_buf,-u32len,conststructwmi_pdev_temperature_event*ev)-{-constvoid**tb;-intret;--tb=ath11k_wmi_tlv_parse_alloc(ab,evt_buf,len,GFP_ATOMIC);-if(IS_ERR(tb)){-ret=PTR_ERR(tb);-ath11k_warn(ab,"failed to parse tlv: %d\n",ret);-returnret;-}--ev=tb[WMI_TAG_PDEV_TEMPERATURE_EVENT];-if(!ev){-ath11k_warn(ab,"failed to fetch pdev temp ev");-kfree(tb);-return-EPROTO;-}--kfree(tb);-return0;-}-size_tath11k_wmi_fw_stats_num_vdevs(structlist_head*head){structath11k_fw_stats_vdev*i;
@@ -6390,23 +6365,37 @@ ath11k_wmi_pdev_temperature_event(struct ath11k_base *ab,structsk_buff*skb){structath11k*ar;-structwmi_pdev_temperature_eventev={0};+constvoid**tb;+conststructwmi_pdev_temperature_event*ev;+intret;++tb=ath11k_wmi_tlv_parse_alloc(ab,skb->data,skb->len,GFP_ATOMIC);+if(IS_ERR(tb)){+ret=PTR_ERR(tb);+ath11k_warn(ab,"failed to parse tlv: %d\n",ret);+return;+}-if(ath11k_pull_pdev_temp_ev(ab,skb->data,skb->len,&ev)!=0){-ath11k_warn(ab,"failed to extract pdev temperature event");+ev=tb[WMI_TAG_PDEV_TEMPERATURE_EVENT];+if(!ev){+ath11k_warn(ab,"failed to fetch pdev temp ev");+kfree(tb);return;}ath11k_dbg(ab,ATH11K_DBG_WMI,-"pdev temperature ev temp %d pdev_id %d\n",ev.temp,ev.pdev_id);+"pdev temperature ev temp %d pdev_id %d\n",ev->temp,ev->pdev_id);-ar=ath11k_mac_get_ar_by_pdev_id(ab,ev.pdev_id);+ar=ath11k_mac_get_ar_by_pdev_id(ab,ev->pdev_id);if(!ar){-ath11k_warn(ab,"invalid pdev id in pdev temperature ev %d",ev.pdev_id);+ath11k_warn(ab,"invalid pdev id in pdev temperature ev %d",ev->pdev_id);+kfree(tb);return;}-ath11k_thermal_event_temperature(ar,ev.temp);+ath11k_thermal_event_temperature(ar,ev->temp);++kfree(tb);}staticvoidath11k_wmi_tlv_op_rx(structath11k_base*ab,structsk_buff*skb)
From: Jonathan McDowell <redacted>
[ Upstream commit e127906b68b49ddb3ecba39ffa36a329c48197d3 ]
Commit eaf4fac47807 ("net: stmmac: Do not accept invalid MTU values")
started using the TX FIFO size to verify what counts as a valid MTU
request for the stmmac driver. This is unset for the ipq806x variant.
Looking at older patches for this it seems the RX + TXs buffers can be
up to 8k, so set appropriately.
(I sent this as an RFC patch in June last year, but received no replies.
I've been running with this on my hardware (a MikroTik RB3011) since
then with larger MTUs to support both the internal qca8k switch and
VLANs with no problems. Without the patch it's impossible to set the
larger MTU required to support this.)
Signed-off-by: Jonathan McDowell <redacted>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c | 2 ++
1 file changed, 2 insertions(+)
From: Vladimir Oltean <vladimir.oltean@nxp.com>
[ Upstream commit 787a4109f46847975ffae7d528a55c6b768ef0aa ]
The "bridge fdb add" command provided in the switchdev documentation is
junk now, not only because it is syntactically incorrect and rejected by
the iproute2 bridge program, but also because it was not updated in
light of Arkadi Sharshevsky's radical switchdev refactoring in commit
29ab586c3d83 ("net: switchdev: Remove bridge bypass support from
switchdev"). Try to explain what the intended usage pattern is with the
new kernel implementation.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
Documentation/networking/switchdev.rst | 47 +++++++++++++++++++-------
1 file changed, 35 insertions(+), 12 deletions(-)
@@ -181,18 +181,41 @@ To offloading L2 bridging, the switchdev driver/device should support: Static FDB Entries ^^^^^^^^^^^^^^^^^^-The switchdev driver should implement ndo_fdb_add, ndo_fdb_del and ndo_fdb_dump-to support static FDB entries installed to the device. Static bridge FDB-entries are installed, for example, using iproute2 bridge cmd::-- bridge fdb add ADDR dev DEV [vlan VID] [self]--The driver should use the helper switchdev_port_fdb_xxx ops for ndo_fdb_xxx-ops, and handle add/delete/dump of SWITCHDEV_OBJ_ID_PORT_FDB object using-switchdev_port_obj_xxx ops.--XXX: what should be done if offloading this rule to hardware fails (for-example, due to full capacity in hardware tables) ?+A driver which implements the ``ndo_fdb_add``, ``ndo_fdb_del`` and+``ndo_fdb_dump`` operations is able to support the command below, which adds a+static bridge FDB entry::++ bridge fdb add dev DEV ADDRESS [vlan VID] [self] static++(the "static" keyword is non-optional: if not specified, the entry defaults to+being "local", which means that it should not be forwarded)++The "self" keyword (optional because it is implicit) has the role of+instructing the kernel to fulfill the operation through the ``ndo_fdb_add``+implementation of the ``DEV`` device itself. If ``DEV`` is a bridge port, this+will bypass the bridge and therefore leave the software database out of sync+with the hardware one.++To avoid this, the "master" keyword can be used::++ bridge fdb add dev DEV ADDRESS [vlan VID] master static++The above command instructs the kernel to search for a master interface of+``DEV`` and fulfill the operation through the ``ndo_fdb_add`` method of that.+This time, the bridge generates a ``SWITCHDEV_FDB_ADD_TO_DEVICE`` notification+which the port driver can handle and use it to program its hardware table. This+way, the software and the hardware database will both contain this static FDB+entry.++Note: for new switchdev drivers that offload the Linux bridge, implementing the+``ndo_fdb_add`` and ``ndo_fdb_del`` bridge bypass methods is strongly+discouraged: all static FDB entries should be added on a bridge port using the+"master" flag. The ``ndo_fdb_dump`` is an exception and can be implemented to+visualize the hardware tables, if the device does not have an interrupt for+notifying the operating system of newly learned/forgotten dynamic FDB+addresses. In that case, the hardware FDB might end up having entries that the+software FDB does not, and implementing ``ndo_fdb_dump`` is the only way to see+them. Note: by default, the bridge does not filter on VLAN and only bridges untagged traffic. To enable VLAN support, turn on VLAN filtering::
From: Hoang Le <redacted>
[ Upstream commit 1980d37565061ab44bdc2f9e4da477d3b9752e81 ]
(struct tipc_link_info)->dest is in network order (__be32), so we must
convert the value to network order before assigning. The problem detected
by sparse:
net/tipc/netlink_compat.c:699:24: warning: incorrect type in assignment (different base types)
net/tipc/netlink_compat.c:699:24: expected restricted __be32 [usertype] dest
net/tipc/netlink_compat.c:699:24: got int
Acked-by: Jon Maloy <jmaloy@redhat.com>
Signed-off-by: Hoang Le <redacted>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/tipc/netlink_compat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Maxim Mikityanskiy <redacted>
[ Upstream commit 991b2654605b455a94dac73e14b23480e7e20991 ]
Commit e20f0dbf204f ("net/mlx5e: RX, Add a prefetch command for small
L1_CACHE_BYTES") switched to using net_prefetchw at all places in mlx5e.
In the same time frame, commit 5af75c747e2a ("net/mlx5e: Enhanced TX
MPWQE for SKBs") added one more usage of prefetchw. When these two
changes were merged, this new occurrence of prefetchw wasn't replaced
with net_prefetchw.
This commit fixes this last occurrence of prefetchw in
mlx5e_tx_mpwqe_session_start, making the same change that was done in
mlx5e_xdp_mpwqe_session_start.
Signed-off-by: Maxim Mikityanskiy <redacted>
Reviewed-by: Saeed Mahameed <saeedm@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/mellanox/mlx5/core/en_tx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Archie Pusaka <redacted>
[ Upstream commit 3a9d54b1947ecea8eea9a902c0b7eb58a98add8a ]
Currently l2cap_chan_set_defaults() reset chan->conf_state to zero.
However, there is a flag CONF_NOT_COMPLETE which is set when
creating the l2cap_chan. It is suggested that the flag should be
cleared when l2cap_chan is ready, but when l2cap_chan_set_defaults()
is called, l2cap_chan is not yet ready. Therefore, we must set this
flag as the default.
Example crash call trace:
__dump_stack lib/dump_stack.c:15 [inline]
dump_stack+0xc4/0x118 lib/dump_stack.c:56
panic+0x1c6/0x38b kernel/panic.c:117
__warn+0x170/0x1b9 kernel/panic.c:471
warn_slowpath_fmt+0xc7/0xf8 kernel/panic.c:494
debug_print_object+0x175/0x193 lib/debugobjects.c:260
debug_object_assert_init+0x171/0x1bf lib/debugobjects.c:614
debug_timer_assert_init kernel/time/timer.c:629 [inline]
debug_assert_init kernel/time/timer.c:677 [inline]
del_timer+0x7c/0x179 kernel/time/timer.c:1034
try_to_grab_pending+0x81/0x2e5 kernel/workqueue.c:1230
cancel_delayed_work+0x7c/0x1c4 kernel/workqueue.c:2929
l2cap_clear_timer+0x1e/0x41 include/net/bluetooth/l2cap.h:834
l2cap_chan_del+0x2d8/0x37e net/bluetooth/l2cap_core.c:640
l2cap_chan_close+0x532/0x5d8 net/bluetooth/l2cap_core.c:756
l2cap_sock_shutdown+0x806/0x969 net/bluetooth/l2cap_sock.c:1174
l2cap_sock_release+0x64/0x14d net/bluetooth/l2cap_sock.c:1217
__sock_release+0xda/0x217 net/socket.c:580
sock_close+0x1b/0x1f net/socket.c:1039
__fput+0x322/0x55c fs/file_table.c:208
____fput+0x17/0x19 fs/file_table.c:244
task_work_run+0x19b/0x1d3 kernel/task_work.c:115
exit_task_work include/linux/task_work.h:21 [inline]
do_exit+0xe4c/0x204a kernel/exit.c:766
do_group_exit+0x291/0x291 kernel/exit.c:891
get_signal+0x749/0x1093 kernel/signal.c:2396
do_signal+0xa5/0xcdb arch/x86/kernel/signal.c:737
exit_to_usermode_loop arch/x86/entry/common.c:243 [inline]
prepare_exit_to_usermode+0xed/0x235 arch/x86/entry/common.c:277
syscall_return_slowpath+0x3a7/0x3b3 arch/x86/entry/common.c:348
int_ret_from_sys_call+0x25/0xa3
Signed-off-by: Archie Pusaka <redacted>
Reported-by: syzbot+338f014a98367a08a114@syzkaller.appspotmail.com
Reviewed-by: Alain Michaud <redacted>
Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/bluetooth/l2cap_core.c | 2 ++
1 file changed, 2 insertions(+)
From: Archie Pusaka <redacted>
[ Upstream commit 5c4c8c9544099bb9043a10a5318130a943e32fc3 ]
hci_chan can be created in 2 places: hci_loglink_complete_evt() if
it is an AMP hci_chan, or l2cap_conn_add() otherwise. In theory,
Only AMP hci_chan should be removed by a call to
hci_disconn_loglink_complete_evt(). However, the controller might mess
up, call that function, and destroy an hci_chan which is not initiated
by hci_loglink_complete_evt().
This patch adds a verification that the destroyed hci_chan must have
been init'd by hci_loglink_complete_evt().
Example crash call trace:
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xe3/0x144 lib/dump_stack.c:118
print_address_description+0x67/0x22a mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report mm/kasan/report.c:412 [inline]
kasan_report+0x251/0x28f mm/kasan/report.c:396
hci_send_acl+0x3b/0x56e net/bluetooth/hci_core.c:4072
l2cap_send_cmd+0x5af/0x5c2 net/bluetooth/l2cap_core.c:877
l2cap_send_move_chan_cfm_icid+0x8e/0xb1 net/bluetooth/l2cap_core.c:4661
l2cap_move_fail net/bluetooth/l2cap_core.c:5146 [inline]
l2cap_move_channel_rsp net/bluetooth/l2cap_core.c:5185 [inline]
l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:5464 [inline]
l2cap_sig_channel net/bluetooth/l2cap_core.c:5799 [inline]
l2cap_recv_frame+0x1d12/0x51aa net/bluetooth/l2cap_core.c:7023
l2cap_recv_acldata+0x2ea/0x693 net/bluetooth/l2cap_core.c:7596
hci_acldata_packet net/bluetooth/hci_core.c:4606 [inline]
hci_rx_work+0x2bd/0x45e net/bluetooth/hci_core.c:4796
process_one_work+0x6f8/0xb50 kernel/workqueue.c:2175
worker_thread+0x4fc/0x670 kernel/workqueue.c:2321
kthread+0x2f0/0x304 kernel/kthread.c:253
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415
Allocated by task 38:
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0x8d/0x9a mm/kasan/kasan.c:553
kmem_cache_alloc_trace+0x102/0x129 mm/slub.c:2787
kmalloc include/linux/slab.h:515 [inline]
kzalloc include/linux/slab.h:709 [inline]
hci_chan_create+0x86/0x26d net/bluetooth/hci_conn.c:1674
l2cap_conn_add.part.0+0x1c/0x814 net/bluetooth/l2cap_core.c:7062
l2cap_conn_add net/bluetooth/l2cap_core.c:7059 [inline]
l2cap_connect_cfm+0x134/0x852 net/bluetooth/l2cap_core.c:7381
hci_connect_cfm+0x9d/0x122 include/net/bluetooth/hci_core.h:1404
hci_remote_ext_features_evt net/bluetooth/hci_event.c:4161 [inline]
hci_event_packet+0x463f/0x72fa net/bluetooth/hci_event.c:5981
hci_rx_work+0x197/0x45e net/bluetooth/hci_core.c:4791
process_one_work+0x6f8/0xb50 kernel/workqueue.c:2175
worker_thread+0x4fc/0x670 kernel/workqueue.c:2321
kthread+0x2f0/0x304 kernel/kthread.c:253
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415
Freed by task 1732:
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free mm/kasan/kasan.c:521 [inline]
__kasan_slab_free+0x106/0x128 mm/kasan/kasan.c:493
slab_free_hook mm/slub.c:1409 [inline]
slab_free_freelist_hook+0xaa/0xf6 mm/slub.c:1436
slab_free mm/slub.c:3009 [inline]
kfree+0x182/0x21e mm/slub.c:3972
hci_disconn_loglink_complete_evt net/bluetooth/hci_event.c:4891 [inline]
hci_event_packet+0x6a1c/0x72fa net/bluetooth/hci_event.c:6050
hci_rx_work+0x197/0x45e net/bluetooth/hci_core.c:4791
process_one_work+0x6f8/0xb50 kernel/workqueue.c:2175
worker_thread+0x4fc/0x670 kernel/workqueue.c:2321
kthread+0x2f0/0x304 kernel/kthread.c:253
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415
The buggy address belongs to the object at ffff8881d7af9180
which belongs to the cache kmalloc-128 of size 128
The buggy address is located 24 bytes inside of
128-byte region [ffff8881d7af9180, ffff8881d7af9200)
The buggy address belongs to the page:
page:ffffea00075ebe40 count:1 mapcount:0 mapping:ffff8881da403200 index:0x0
flags: 0x8000000000000200(slab)
raw: 8000000000000200 dead000000000100 dead000000000200 ffff8881da403200
raw: 0000000000000000 0000000080150015 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8881d7af9080: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
ffff8881d7af9100: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
^
ffff8881d7af9200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8881d7af9280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
Signed-off-by: Archie Pusaka <redacted>
Reported-by: syzbot+98228e7407314d2d4ba2@syzkaller.appspotmail.com
Reviewed-by: Alain Michaud <redacted>
Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
include/net/bluetooth/hci_core.h | 1 +
net/bluetooth/hci_event.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
From: Nikolay Aleksandrov <redacted>
[ Upstream commit 0353b4a96b7a9f60fe20d1b3ebd4931a4085f91c ]
Recently we had an interop issue where RARP packets got suppressed with
bridge neigh suppression enabled, but the check in the code was meant to
suppress GARP. Exclude RARP packets from it which would allow some VMWare
setups to work, to quote the report:
"Those RARP packets usually get generated by vMware to notify physical
switches when vMotion occurs. vMware may use random sip/tip or just use
sip=tip=0. So the RARP packet sometimes get properly flooded by the vtep
and other times get dropped by the logic"
Reported-by: Amer Abdalamer <redacted>
Signed-off-by: Nikolay Aleksandrov <redacted>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/bridge/br_arp_nd_proxy.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
[ Upstream commit be8597239379f0f53c9710dd6ab551bbf535bec6 ]
syzbot is hitting "INFO: trying to register non-static key." message [1],
for "struct l2cap_chan"->tx_q.lock spinlock is not yet initialized when
l2cap_chan_del() is called due to e.g. timeout.
Since "struct l2cap_chan"->lock mutex is initialized at l2cap_chan_create()
immediately after "struct l2cap_chan" is allocated using kzalloc(), let's
as well initialize "struct l2cap_chan"->{tx_q,srej_q}.lock spinlocks there.
[1] https://syzkaller.appspot.com/bug?extid=fadfba6a911f6bf71842
Reported-and-tested-by: syzbot <redacted>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/bluetooth/l2cap_core.c | 2 ++
1 file changed, 2 insertions(+)
From: Vladimir Oltean <vladimir.oltean@nxp.com>
[ Upstream commit 6215afcb9a7e35cef334dc0ae7f998cc72c8465f ]
A make W=1 build complains that:
net/sched/cls_flower.c:214:20: warning: cast from restricted __be16
net/sched/cls_flower.c:214:20: warning: incorrect type in argument 1 (different base types)
net/sched/cls_flower.c:214:20: expected unsigned short [usertype] val
net/sched/cls_flower.c:214:20: got restricted __be16 [usertype] dst
This is because we use htons on struct flow_dissector_key_ports members
src and dst, which are defined as __be16, so they are already in network
byte order, not host. The byte swap function for the other direction
should have been used.
Because htons and ntohs do the same thing (either both swap, or none
does), this change has no functional effect except to silence the
warnings.
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>
---
net/sched/cls_flower.c | 36 ++++++++++++++++++------------------
1 file changed, 18 insertions(+), 18 deletions(-)
@@ -209,16 +209,16 @@ static bool fl_range_port_dst_cmp(struct cls_fl_filter *filter,structfl_flow_key*key,structfl_flow_key*mkey){-__be16min_mask,max_mask,min_val,max_val;+u16min_mask,max_mask,min_val,max_val;-min_mask=htons(filter->mask->key.tp_range.tp_min.dst);-max_mask=htons(filter->mask->key.tp_range.tp_max.dst);-min_val=htons(filter->key.tp_range.tp_min.dst);-max_val=htons(filter->key.tp_range.tp_max.dst);+min_mask=ntohs(filter->mask->key.tp_range.tp_min.dst);+max_mask=ntohs(filter->mask->key.tp_range.tp_max.dst);+min_val=ntohs(filter->key.tp_range.tp_min.dst);+max_val=ntohs(filter->key.tp_range.tp_max.dst);if(min_mask&&max_mask){-if(htons(key->tp_range.tp.dst)<min_val||-htons(key->tp_range.tp.dst)>max_val)+if(ntohs(key->tp_range.tp.dst)<min_val||+ntohs(key->tp_range.tp.dst)>max_val)returnfalse;/* skb does not have min and max values */
@@ -232,16 +232,16 @@ static bool fl_range_port_src_cmp(struct cls_fl_filter *filter,structfl_flow_key*key,structfl_flow_key*mkey){-__be16min_mask,max_mask,min_val,max_val;+u16min_mask,max_mask,min_val,max_val;-min_mask=htons(filter->mask->key.tp_range.tp_min.src);-max_mask=htons(filter->mask->key.tp_range.tp_max.src);-min_val=htons(filter->key.tp_range.tp_min.src);-max_val=htons(filter->key.tp_range.tp_max.src);+min_mask=ntohs(filter->mask->key.tp_range.tp_min.src);+max_mask=ntohs(filter->mask->key.tp_range.tp_max.src);+min_val=ntohs(filter->key.tp_range.tp_min.src);+max_val=ntohs(filter->key.tp_range.tp_max.src);if(min_mask&&max_mask){-if(htons(key->tp_range.tp.src)<min_val||-htons(key->tp_range.tp.src)>max_val)+if(ntohs(key->tp_range.tp.src)<min_val||+ntohs(key->tp_range.tp.src)>max_val)returnfalse;/* skb does not have min and max values */
@@ -779,16 +779,16 @@ static int fl_set_key_port_range(struct nlattr **tb, struct fl_flow_key *key,TCA_FLOWER_UNSPEC,sizeof(key->tp_range.tp_max.src));if(mask->tp_range.tp_min.dst&&mask->tp_range.tp_max.dst&&-htons(key->tp_range.tp_max.dst)<=-htons(key->tp_range.tp_min.dst)){+ntohs(key->tp_range.tp_max.dst)<=+ntohs(key->tp_range.tp_min.dst)){NL_SET_ERR_MSG_ATTR(extack,tb[TCA_FLOWER_KEY_PORT_DST_MIN],"Invalid destination port range (min must be strictly smaller than max)");return-EINVAL;}if(mask->tp_range.tp_min.src&&mask->tp_range.tp_max.src&&-htons(key->tp_range.tp_max.src)<=-htons(key->tp_range.tp_min.src)){+ntohs(key->tp_range.tp_max.src)<=+ntohs(key->tp_range.tp_min.src)){NL_SET_ERR_MSG_ATTR(extack,tb[TCA_FLOWER_KEY_PORT_SRC_MIN],"Invalid source port range (min must be strictly smaller than max)");
From: Guangbin Huang <redacted>
[ Upstream commit a2ee6fd28a190588e142ad8ea9d40069cd3c9f98 ]
The array size of bd_num_list is a fixed value, it may have potential
overflow risk when array size of hclge_dfx_bd_offset_list is greater
than that fixed value. So modify bd_num_list as a pointer and allocate
memory for it according to array size of hclge_dfx_bd_offset_list.
Signed-off-by: Guangbin Huang <redacted>
Signed-off-by: Huazhong Tan <redacted>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
.../hisilicon/hns3/hns3pf/hclge_main.c | 27 ++++++++++++++-----
1 file changed, 20 insertions(+), 7 deletions(-)
@@ -10939,15 +10938,19 @@ static int hclge_get_dfx_reg_len(struct hclge_dev *hdev, int *len){u32dfx_reg_type_num=ARRAY_SIZE(hclge_dfx_bd_offset_list);intdata_len_per_desc,bd_num,i;-intbd_num_list[BD_LIST_MAX_NUM];+int*bd_num_list;u32data_len;intret;+bd_num_list=kcalloc(dfx_reg_type_num,sizeof(int),GFP_KERNEL);+if(!bd_num_list)+return-ENOMEM;+ret=hclge_get_dfx_reg_bd_num(hdev,bd_num_list,dfx_reg_type_num);if(ret){dev_err(&hdev->pdev->dev,"Get dfx reg bd num fail, status is %d.\n",ret);-returnret;+gotoout;}data_len_per_desc=sizeof_field(structhclge_desc,data);
@@ -10958,6 +10961,8 @@ static int hclge_get_dfx_reg_len(struct hclge_dev *hdev, int *len)*len+=(data_len/REG_LEN_PER_LINE+1)*REG_LEN_PER_LINE;}+out:+kfree(bd_num_list);returnret;}
@@ -10965,16 +10970,20 @@ static int hclge_get_dfx_reg(struct hclge_dev *hdev, void *data){u32dfx_reg_type_num=ARRAY_SIZE(hclge_dfx_bd_offset_list);intbd_num,bd_num_max,buf_len,i;-intbd_num_list[BD_LIST_MAX_NUM];structhclge_desc*desc_src;+int*bd_num_list;u32*reg=data;intret;+bd_num_list=kcalloc(dfx_reg_type_num,sizeof(int),GFP_KERNEL);+if(!bd_num_list)+return-ENOMEM;+ret=hclge_get_dfx_reg_bd_num(hdev,bd_num_list,dfx_reg_type_num);if(ret){dev_err(&hdev->pdev->dev,"Get dfx reg bd num fail, status is %d.\n",ret);-returnret;+gotoout;}bd_num_max=bd_num_list[0];
From: Phillip Potter <phil@philpotter.co.uk>
[ Upstream commit bd78980be1a68d14524c51c4b4170782fada622b ]
Use memset to initialize local array in drivers/net/usb/ax88179_178a.c, and
also set a local u16 and u32 variable to 0. Fixes a KMSAN found uninit-value bug
reported by syzbot at:
https://syzkaller.appspot.com/bug?id=00371c73c72f72487c1d0bfe0cc9d00de339d5aa
Reported-by: syzbot+4993e4a0e237f1b53747@syzkaller.appspotmail.com
Signed-off-by: Phillip Potter <phil@philpotter.co.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/usb/ax88179_178a.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
@@ -1296,6 +1296,8 @@ static void ax88179_get_mac_addr(struct usbnet *dev){u8mac[ETH_ALEN];+memset(mac,0,sizeof(mac));+/* Maybe the boot loader passed the MAC address via device tree */if(!eth_platform_get_mac_address(&dev->udev->dev,mac)){netif_dbg(dev,ifup,dev->net,
From: Paul M Stillwell Jr <redacted>
[ Upstream commit 2ec5638559c13b923250eccf495d2a033fccb3e7 ]
There is an issue when the Tx or Rx ring size increases using
'ethtool -L ...' where the new rings don't get the correct ITR
values because when we rebuild the VSI we don't know that some
of the rings may be new.
Fix this by looking at the original number of rings and
determining if the rings in ice_vsi_rebuild_set_coalesce()
were not present in the original rings received in
ice_vsi_rebuild_get_coalesce().
Also change the code to return an error if we can't allocate
memory for the coalesce data in ice_vsi_rebuild().
Signed-off-by: Paul M Stillwell Jr <redacted>
Tested-by: Tony Brelinski <redacted>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/intel/ice/ice_lib.c | 123 ++++++++++++++++------
drivers/net/ethernet/intel/ice/ice_txrx.h | 2 +
2 files changed, 92 insertions(+), 33 deletions(-)
@@ -2684,38 +2684,46 @@ int ice_vsi_release(struct ice_vsi *vsi)}/**-*ice_vsi_rebuild_update_coalesce-setcoalesceforaq_vector+*ice_vsi_rebuild_update_coalesce_intrl-setinterruptratelimitforaq_vector*@q_vector:pointertoq_vectorwhichisbeingupdated-*@coalesce:pointertoarrayofstructwithstoredcoalesce+*@stored_intrl_setting:originalINTRLsetting**Setcoalesceparaminq_vectorandupdatetheseparametersinHW.*/staticvoid-ice_vsi_rebuild_update_coalesce(structice_q_vector*q_vector,-structice_coalesce_stored*coalesce)+ice_vsi_rebuild_update_coalesce_intrl(structice_q_vector*q_vector,+u16stored_intrl_setting){-structice_ring_container*rx_rc=&q_vector->rx;-structice_ring_container*tx_rc=&q_vector->tx;structice_hw*hw=&q_vector->vsi->back->hw;-tx_rc->itr_setting=coalesce->itr_tx;-rx_rc->itr_setting=coalesce->itr_rx;--/* dynamic ITR values will be updated during Tx/Rx */-if(!ITR_IS_DYNAMIC(tx_rc->itr_setting))-wr32(hw,GLINT_ITR(tx_rc->itr_idx,q_vector->reg_idx),-ITR_REG_ALIGN(tx_rc->itr_setting)>>-ICE_ITR_GRAN_S);-if(!ITR_IS_DYNAMIC(rx_rc->itr_setting))-wr32(hw,GLINT_ITR(rx_rc->itr_idx,q_vector->reg_idx),-ITR_REG_ALIGN(rx_rc->itr_setting)>>-ICE_ITR_GRAN_S);--q_vector->intrl=coalesce->intrl;+q_vector->intrl=stored_intrl_setting;wr32(hw,GLINT_RATE(q_vector->reg_idx),ice_intrl_usec_to_reg(q_vector->intrl,hw->intrl_gran));}+/**+*ice_vsi_rebuild_update_coalesce_itr-setcoalesceforaq_vector+*@q_vector:pointertoq_vectorwhichisbeingupdated+*@rc:pointertoringcontainer+*@stored_itr_setting:originalITRsetting+*+*Setcoalesceparaminq_vectorandupdatetheseparametersinHW.+*/+staticvoid+ice_vsi_rebuild_update_coalesce_itr(structice_q_vector*q_vector,+structice_ring_container*rc,+u16stored_itr_setting)+{+structice_hw*hw=&q_vector->vsi->back->hw;++rc->itr_setting=stored_itr_setting;++/* dynamic ITR values will be updated during Tx/Rx */+if(!ITR_IS_DYNAMIC(rc->itr_setting))+wr32(hw,GLINT_ITR(rc->itr_idx,q_vector->reg_idx),+ITR_REG_ALIGN(rc->itr_setting)>>ICE_ITR_GRAN_S);+}+/***ice_vsi_rebuild_get_coalesce-getcoalescefromallq_vectors*@vsi:VSIconnectedwithq_vectors
@@ -2759,17 +2772,59 @@ ice_vsi_rebuild_set_coalesce(struct ice_vsi *vsi,if((size&&!coalesce)||!vsi)return;-for(i=0;i<size&&i<vsi->num_q_vectors;i++)-ice_vsi_rebuild_update_coalesce(vsi->q_vectors[i],-&coalesce[i]);--/* number of q_vectors increased, so assume coalesce settings were-*changedglobally(i.e.ethtool-Ceth0insteadofper-queue)anduse-*theprevioussettingsfromq_vector0forallofthenewq_vectors+/* There are a couple of cases that have to be handled here:+*1.Thecasewherethenumberofqueuevectorsstaysthesame,but+*thenumberofTxorRxringschanges(thefirstforloop)+*2.Thecasewherethenumberofqueuevectorsincreased(the+*secondforloop)*/-for(;i<vsi->num_q_vectors;i++)-ice_vsi_rebuild_update_coalesce(vsi->q_vectors[i],-&coalesce[0]);+for(i=0;i<size&&i<vsi->num_q_vectors;i++){+/* There are 2 cases to handle here and they are the same for+*bothTxandRx:+*iftheentrywasvalidpreviously(coalesce[i].[tr]x_valid+*andtheloopvariableislessthanthenumberofrings+*allocated,thenwritethepreviousvalues+*+*iftheentrywasnotvalidpreviously,butthenumberof+*ringsislessthanareallocated(thismeansthenumberof+*ringsincreasedfrompreviously),thenwriteoutthe+*valuesinthefirstelement+*/+if(i<vsi->alloc_rxq&&coalesce[i].rx_valid)+ice_vsi_rebuild_update_coalesce_itr(vsi->q_vectors[i],+&vsi->q_vectors[i]->rx,+coalesce[i].itr_rx);+elseif(i<vsi->alloc_rxq)+ice_vsi_rebuild_update_coalesce_itr(vsi->q_vectors[i],+&vsi->q_vectors[i]->rx,+coalesce[0].itr_rx);++if(i<vsi->alloc_txq&&coalesce[i].tx_valid)+ice_vsi_rebuild_update_coalesce_itr(vsi->q_vectors[i],+&vsi->q_vectors[i]->tx,+coalesce[i].itr_tx);+elseif(i<vsi->alloc_txq)+ice_vsi_rebuild_update_coalesce_itr(vsi->q_vectors[i],+&vsi->q_vectors[i]->tx,+coalesce[0].itr_tx);++ice_vsi_rebuild_update_coalesce_intrl(vsi->q_vectors[i],+coalesce[i].intrl);+}++/* the number of queue vectors increased so write whatever is in+*thefirstelement+*/+for(;i<vsi->num_q_vectors;i++){+ice_vsi_rebuild_update_coalesce_itr(vsi->q_vectors[i],+&vsi->q_vectors[i]->tx,+coalesce[0].itr_tx);+ice_vsi_rebuild_update_coalesce_itr(vsi->q_vectors[i],+&vsi->q_vectors[i]->rx,+coalesce[0].itr_rx);+ice_vsi_rebuild_update_coalesce_intrl(vsi->q_vectors[i],+coalesce[0].intrl);+}}/**
@@ -2798,9 +2853,11 @@ int ice_vsi_rebuild(struct ice_vsi *vsi, bool init_vsi)coalesce=kcalloc(vsi->num_q_vectors,sizeof(structice_coalesce_stored),GFP_KERNEL);-if(coalesce)-prev_num_q_vectors=ice_vsi_rebuild_get_coalesce(vsi,-coalesce);+if(!coalesce)+return-ENOMEM;++prev_num_q_vectors=ice_vsi_rebuild_get_coalesce(vsi,coalesce);+ice_rm_vsi_lan_cfg(vsi->port_info,vsi->idx);ice_vsi_free_q_vectors(vsi);
@@ -351,6 +351,8 @@ struct ice_coalesce_stored {u16itr_tx;u16itr_rx;u8intrl;+u8tx_valid;+u8rx_valid;};/* iterator for handling rings in ring container */
From: Johannes Berg <redacted>
[ Upstream commit 48a5494d6a4cb5812f0640d9515f1876ffc7a013 ]
If we (for example) have a trans_cfg entry in the PCI IDs table,
but then don't find a full cfg entry for it in the info table,
we fall through to the code that treats the PCI ID table entry
as a full cfg entry. This obviously causes crashes later, e.g.
when trying to build the firmware name string.
Avoid such crashes by using the low bit of the pointer as a tag
for trans_cfg entries (automatically using a macro that checks
the type when assigning) and then checking that before trying to
use the data as a full entry - if it's just a partial entry at
that point, fail.
Since we're adding some macro magic, also check that the type is
in fact either struct iwl_cfg_trans_params or struct iwl_cfg,
failing compilation ("initializer element is not constant") if
it isn't.
Signed-off-by: Johannes Berg <redacted>
Signed-off-by: Luca Coelho <redacted>
Link: https://lore.kernel.org/r/iwlwifi.20210330162204.6f69fe6e4128.I921d4ae20ef5276716baeeeda0b001cf25b9b968@changeid
Signed-off-by: Luca Coelho <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 35 +++++++++++++++----
1 file changed, 28 insertions(+), 7 deletions(-)
@@ -73,10 +73,20 @@#include"iwl-prph.h"#include"internal.h"+#define TRANS_CFG_MARKER BIT(0)+#define _IS_A(cfg, _struct) __builtin_types_compatible_p(typeof(cfg), \+struct_struct)+externint_invalid_type;+#define _TRANS_CFG_MARKER(cfg) \+(__builtin_choose_expr(_IS_A(cfg,iwl_cfg_trans_params),\+TRANS_CFG_MARKER,\+__builtin_choose_expr(_IS_A(cfg,iwl_cfg),0,_invalid_type)))+#define _ASSIGN_CFG(cfg) (_TRANS_CFG_MARKER(cfg) + (kernel_ulong_t)&(cfg))+#define IWL_PCI_DEVICE(dev, subdev, cfg) \.vendor=PCI_VENDOR_ID_INTEL,.device=(dev),\.subvendor=PCI_ANY_ID,.subdevice=(subdev),\-.driver_data=(kernel_ulong_t)&(cfg)+.driver_data=_ASSIGN_CFG(cfg)/* Hardware specific file defines the PCI IDs table for that hardware module */staticconststructpci_device_idiwl_hw_card_ids[]={
@@ -1018,20 +1028,23 @@ static const struct iwl_dev_info iwl_dev_info_table[] = {staticintiwl_pci_probe(structpci_dev*pdev,conststructpci_device_id*ent){-conststructiwl_cfg_trans_params*trans=-(structiwl_cfg_trans_params*)(ent->driver_data);+conststructiwl_cfg_trans_params*trans;conststructiwl_cfg*cfg_7265d__maybe_unused=NULL;structiwl_trans*iwl_trans;structiwl_trans_pcie*trans_pcie;unsignedlongflags;inti,ret;+conststructiwl_cfg*cfg;++trans=(void*)(ent->driver_data&~TRANS_CFG_MARKER);+/**Thisisneededforbackwardscompatibilitywiththeold*tables,sowedon'tneedtochangealltheconfigstructs*atthesametime.Thecfgisusedtocomparewiththeold*fullcfgstructs.*/-conststructiwl_cfg*cfg=(structiwl_cfg*)(ent->driver_data);+cfg=(void*)(ent->driver_data&~TRANS_CFG_MARKER);/* make sure trans is the first element in iwl_cfg */BUILD_BUG_ON(offsetof(structiwl_cfg,trans));
@@ -1133,11 +1146,19 @@ static int iwl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)#endif/*-*Ifwedidn'tsetthecfgyet,assumethetransisactually-*afullcfgfromtheoldtables.+*Ifwedidn'tsetthecfgyet,thePCIIDtableentryshouldhave+*beenafullconfig-ifyes,useit,otherwisefail.*/-if(!iwl_trans->cfg)+if(!iwl_trans->cfg){+if(ent->driver_data&TRANS_CFG_MARKER){+pr_err("No config found for PCI dev %04x/%04x, rev=0x%x, rfid=0x%x\n",+pdev->device,pdev->subsystem_device,+iwl_trans->hw_rev,iwl_trans->hw_rf_id);+ret=-EINVAL;+gotoout_free_trans;+}iwl_trans->cfg=cfg;+}/* if we don't have a name yet, copy name from the old cfg */if(!iwl_trans->name)
From: David Bauer <redacted>
[ Upstream commit 4b36cc6b390f18dbc59a45fb4141f90d7dfe2b23 ]
When operating two VAP on a MT7610 with encryption (PSK2, SAE, OWE),
only the first one to be created will transmit properly encrypteded
frames.
All subsequently created VAPs will sent out frames with the payload left
unencrypted, breaking multicast traffic (ICMP6 NDP) and potentially
disclosing information to a third party.
Disable GTK offloading and encrypt these frames in software to
circumvent this issue. THis only seems to be necessary on MT7610 chips,
as MT7612 is not affected from our testing.
Signed-off-by: David Bauer <redacted>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt76x02_util.c | 4 ++++
1 file changed, 4 insertions(+)
@@ -446,6 +446,10 @@ int mt76x02_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,!(key->flags&IEEE80211_KEY_FLAG_PAIRWISE))return-EOPNOTSUPP;+/* MT76x0 GTK offloading does not work with more than one VIF */+if(is_mt76x0(dev)&&!(key->flags&IEEE80211_KEY_FLAG_PAIRWISE))+return-EOPNOTSUPP;+msta=sta?(structmt76x02_sta*)sta->drv_priv:NULL;wcid=msta?&msta->wcid:&mvif->group_wcid;
From: "Gustavo A. R. Silva" <gustavoars@kernel.org>
[ Upstream commit e5272ad4aab347dde5610c0aedb786219e3ff793 ]
Fix the following out-of-bounds warning:
net/sctp/sm_make_chunk.c:3150:4: warning: 'memcpy' offset [17, 28] from the object at 'addr' is out of the bounds of referenced subobject 'v4' with type 'struct sockaddr_in' at offset 0 [-Warray-bounds]
This helps with the ongoing efforts to globally enable -Warray-bounds
and get us closer to being able to tighten the FORTIFY_SOURCE routines
on memcpy().
Link: https://github.com/KSPP/linux/issues/109
Reported-by: kernel test robot <redacted>
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: Kees Cook <redacted>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/sctp/sm_make_chunk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: "Gustavo A. R. Silva" <gustavoars@kernel.org>
[ Upstream commit 1e3d976dbb23b3fce544752b434bdc32ce64aabc ]
Fix the following out-of-bounds warning:
net/core/flow_dissector.c:835:3: warning: 'memcpy' offset [33, 48] from the object at 'flow_keys' is out of the bounds of referenced subobject 'ipv6_src' with type '__u32[4]' {aka 'unsigned int[4]'} at offset 16 [-Warray-bounds]
The problem is that the original code is trying to copy data into a
couple of struct members adjacent to each other in a single call to
memcpy(). So, the compiler legitimately complains about it. As these
are just a couple of members, fix this by copying each one of them in
separate calls to memcpy().
This helps with the ongoing efforts to globally enable -Warray-bounds
and get us closer to being able to tighten the FORTIFY_SOURCE routines
on memcpy().
Link: https://github.com/KSPP/linux/issues/109
Reported-by: kernel test robot <redacted>
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/core/flow_dissector.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
From: Sander Vanheule <sander@svanheule.net>
[ Upstream commit 858ebf446bee7d5077bd99488aae617908c3f4fe ]
EEPROM blobs for MT7613BE radios start with (little endian) 0x7663,
which is also the PCI device ID for this device. The EEPROM is required
for the radio to work at useful power levels, otherwise only the lowest
power level is available.
Suggested-by: Georgi Vlaev <redacted>
Tested-by: Stijn Segers <redacted>
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c | 1 +
1 file changed, 1 insertion(+)
From: "Gustavo A. R. Silva" <gustavoars@kernel.org>
[ Upstream commit 820aa37638a252b57967bdf4038a514b1ab85d45 ]
Fix the following out-of-bounds warnings by enclosing structure members
daddr and saddr into new struct addr, in structures wl3501_md_req and
wl3501_md_ind:
arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [18, 23] from the object at 'sig' is out of the bounds of referenced subobject 'daddr' with type 'u8[6]' {aka 'unsigned char[6]'} at offset 11 [-Warray-bounds]
arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [18, 23] from the object at 'sig' is out of the bounds of referenced subobject 'daddr' with type 'u8[6]' {aka 'unsigned char[6]'} at offset 11 [-Warray-bounds]
Refactor the code, accordingly:
$ pahole -C wl3501_md_req drivers/net/wireless/wl3501_cs.o
struct wl3501_md_req {
u16 next_blk; /* 0 2 */
u8 sig_id; /* 2 1 */
u8 routing; /* 3 1 */
u16 data; /* 4 2 */
u16 size; /* 6 2 */
u8 pri; /* 8 1 */
u8 service_class; /* 9 1 */
struct {
u8 daddr[6]; /* 10 6 */
u8 saddr[6]; /* 16 6 */
} addr; /* 10 12 */
/* size: 22, cachelines: 1, members: 8 */
/* last cacheline: 22 bytes */
};
$ pahole -C wl3501_md_ind drivers/net/wireless/wl3501_cs.o
struct wl3501_md_ind {
u16 next_blk; /* 0 2 */
u8 sig_id; /* 2 1 */
u8 routing; /* 3 1 */
u16 data; /* 4 2 */
u16 size; /* 6 2 */
u8 reception; /* 8 1 */
u8 pri; /* 9 1 */
u8 service_class; /* 10 1 */
struct {
u8 daddr[6]; /* 11 6 */
u8 saddr[6]; /* 17 6 */
} addr; /* 11 12 */
/* size: 24, cachelines: 1, members: 9 */
/* padding: 1 */
/* last cacheline: 24 bytes */
};
The problem is that the original code is trying to copy data into a
couple of arrays adjacent to each other in a single call to memcpy().
Now that a new struct _addr_ enclosing those two adjacent arrays
is introduced, memcpy() doesn't overrun the length of &sig.daddr[0]
and &sig.daddr, because the address of the new struct object _addr_
is used, instead.
This helps with the ongoing efforts to globally enable -Warray-bounds
and get us closer to being able to tighten the FORTIFY_SOURCE routines
on memcpy().
Link: https://github.com/KSPP/linux/issues/109
Reported-by: kernel test robot <redacted>
Reviewed-by: Kees Cook <redacted>
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Kalle Valo <redacted>
Link: https://lore.kernel.org/r/d260fe56aed7112bff2be5b4d152d03ad7b78e78.1618442265.git.gustavoars@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/wl3501.h | 12 ++++++++----
drivers/net/wireless/wl3501_cs.c | 10 ++++++----
2 files changed, 14 insertions(+), 8 deletions(-)
From: Lee Gibson <redacted>
[ Upstream commit 130f634da1af649205f4a3dd86cbe5c126b57914 ]
Function qtnf_event_handle_external_auth calls memcpy without
checking the length.
A user could control that length and trigger a buffer overflow.
Fix by checking the length is within the maximum allowed size.
Signed-off-by: Lee Gibson <redacted>
Signed-off-by: Kalle Valo <redacted>
Link: https://lore.kernel.org/r/20210419145842.345787-1-leegib@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/quantenna/qtnfmac/event.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
From: Yunsheng Lin <redacted>
[ Upstream commit d5d5e0193ee8f88efbbc7f1471087255657bc19a ]
Currently hns3 driver only handle the xmit skb with one level of
fraglist skb, add handling for multi level by calling hns3_tx_bd_num()
recursively when calculating bd num and calling hns3_fill_skb_to_desc()
recursively when filling tx desc.
When the skb has a fraglist level of 24, the skb is simply dropped and
stats.max_recursion_level is added to record the error. Move the stat
handling from hns3_nic_net_xmit() to hns3_nic_maybe_stop_tx() in order
to handle different error stat and add the 'max_recursion_level' and
'hw_limitation' stat.
Note that the max recursive level as 24 is chose according to below:
commit 48a1df65334b ("skbuff: return -EMSGSIZE in skb_to_sgvec to
prevent overflow").
And that we are not able to find a testcase to verify the recursive
fraglist case, so Fixes tag is not provided.
Reported-by: Barry Song <redacted>
Signed-off-by: Yunsheng Lin <redacted>
Signed-off-by: Huazhong Tan <redacted>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
.../net/ethernet/hisilicon/hns3/hns3_enet.c | 115 +++++++++++-------
.../net/ethernet/hisilicon/hns3/hns3_enet.h | 2 +
.../ethernet/hisilicon/hns3/hns3_ethtool.c | 2 +
3 files changed, 78 insertions(+), 41 deletions(-)
@@ -1192,23 +1192,21 @@ static unsigned int hns3_skb_bd_num(struct sk_buff *skb, unsigned int *bd_size,}staticunsignedinthns3_tx_bd_num(structsk_buff*skb,unsignedint*bd_size,-u8max_non_tso_bd_num)+u8max_non_tso_bd_num,unsignedintbd_num,+unsignedintrecursion_level){+#define HNS3_MAX_RECURSION_LEVEL 24+structsk_buff*frag_skb;-unsignedintbd_num=0;/* If the total len is within the max bd limit */-if(likely(skb->len<=HNS3_MAX_BD_SIZE&&!skb_has_frag_list(skb)&&+if(likely(skb->len<=HNS3_MAX_BD_SIZE&&!recursion_level&&+!skb_has_frag_list(skb)&&skb_shinfo(skb)->nr_frags<max_non_tso_bd_num))returnskb_shinfo(skb)->nr_frags+1U;-/* The below case will always be linearized, return-*HNS3_MAX_BD_NUM_TSO+1Utomakesureitislinearized.-*/-if(unlikely(skb->len>HNS3_MAX_TSO_SIZE||-(!skb_is_gso(skb)&&skb->len>-HNS3_MAX_NON_TSO_SIZE(max_non_tso_bd_num))))-returnHNS3_MAX_TSO_BD_NUM+1U;+if(unlikely(recursion_level>=HNS3_MAX_RECURSION_LEVEL))+returnUINT_MAX;bd_num=hns3_skb_bd_num(skb,bd_size,bd_num);
@@ -1216,7 +1214,8 @@ static unsigned int hns3_tx_bd_num(struct sk_buff *skb, unsigned int *bd_size,returnbd_num;skb_walk_frags(skb,frag_skb){-bd_num=hns3_skb_bd_num(frag_skb,bd_size,bd_num);+bd_num=hns3_tx_bd_num(frag_skb,bd_size,max_non_tso_bd_num,+bd_num,recursion_level+1);if(bd_num>HNS3_MAX_TSO_BD_NUM)returnbd_num;}
@@ -1276,6 +1275,43 @@ void hns3_shinfo_pack(struct skb_shared_info *shinfo, __u32 *size)size[i]=skb_frag_size(&shinfo->frags[i]);}+staticinthns3_skb_linearize(structhns3_enet_ring*ring,+structsk_buff*skb,+u8max_non_tso_bd_num,+unsignedintbd_num)+{+/* 'bd_num == UINT_MAX' means the skb' fraglist has a+*recursionlevelofoverHNS3_MAX_RECURSION_LEVEL.+*/+if(bd_num==UINT_MAX){+u64_stats_update_begin(&ring->syncp);+ring->stats.over_max_recursion++;+u64_stats_update_end(&ring->syncp);+return-ENOMEM;+}++/* The skb->len has exceeded the hw limitation, linearization+*willnothelp.+*/+if(skb->len>HNS3_MAX_TSO_SIZE||+(!skb_is_gso(skb)&&skb->len>+HNS3_MAX_NON_TSO_SIZE(max_non_tso_bd_num))){+u64_stats_update_begin(&ring->syncp);+ring->stats.hw_limitation++;+u64_stats_update_end(&ring->syncp);+return-ENOMEM;+}++if(__skb_linearize(skb)){+u64_stats_update_begin(&ring->syncp);+ring->stats.sw_err_cnt++;+u64_stats_update_end(&ring->syncp);+return-ENOMEM;+}++return0;+}+staticinthns3_nic_maybe_stop_tx(structhns3_enet_ring*ring,structnet_device*netdev,structsk_buff*skb)
@@ -1285,7 +1321,7 @@ static int hns3_nic_maybe_stop_tx(struct hns3_enet_ring *ring,unsignedintbd_size[HNS3_MAX_TSO_BD_NUM+1U];unsignedintbd_num;-bd_num=hns3_tx_bd_num(skb,bd_size,max_non_tso_bd_num);+bd_num=hns3_tx_bd_num(skb,bd_size,max_non_tso_bd_num,0,0);if(unlikely(bd_num>max_non_tso_bd_num)){if(bd_num<=HNS3_MAX_TSO_BD_NUM&&skb_is_gso(skb)&&!hns3_skb_need_linearized(skb,bd_size,bd_num,
@@ -1294,16 +1330,11 @@ static int hns3_nic_maybe_stop_tx(struct hns3_enet_ring *ring,gotoout;}-if(__skb_linearize(skb))+if(hns3_skb_linearize(ring,skb,max_non_tso_bd_num,+bd_num))return-ENOMEM;bd_num=hns3_tx_bd_count(skb->len);-if((skb_is_gso(skb)&&bd_num>HNS3_MAX_TSO_BD_NUM)||-(!skb_is_gso(skb)&&-bd_num>max_non_tso_bd_num)){-trace_hns3_over_max_bd(skb);-return-ENOMEM;-}u64_stats_update_begin(&ring->syncp);ring->stats.tx_copy++;
@@ -1327,6 +1358,10 @@ static int hns3_nic_maybe_stop_tx(struct hns3_enet_ring *ring,returnbd_num;}+u64_stats_update_begin(&ring->syncp);+ring->stats.tx_busy++;+u64_stats_update_end(&ring->syncp);+return-EBUSY;}
@@ -1374,6 +1409,7 @@ static int hns3_fill_skb_to_desc(struct hns3_enet_ring *ring,structsk_buff*skb,enumhns_desc_typetype){unsignedintsize=skb_headlen(skb);+structsk_buff*frag_skb;inti,ret,bd_num=0;if(size){
@@ -1398,6 +1434,15 @@ static int hns3_fill_skb_to_desc(struct hns3_enet_ring *ring,bd_num+=ret;}+skb_walk_frags(skb,frag_skb){+ret=hns3_fill_skb_to_desc(ring,frag_skb,+DESC_TYPE_FRAGLIST_SKB);+if(unlikely(ret<0))+returnret;++bd_num+=ret;+}+returnbd_num;}
From: Yonghong Song <redacted>
[ Upstream commit 26e6dd1072763cd5696b75994c03982dde952ad9 ]
selftests/bpf/Makefile includes lib.mk. With the following command
make -j60 LLVM=1 LLVM_IAS=1 <=== compile kernel
make -j60 -C tools/testing/selftests/bpf LLVM=1 LLVM_IAS=1 V=1
some files are still compiled with gcc. This patch
fixed lib.mk issue which sets CC to gcc in all cases.
Signed-off-by: Yonghong Song <redacted>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20210413153413.3027426-1-yhs@fb.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/testing/selftests/lib.mk | 4 ++++
1 file changed, 4 insertions(+)
@@ -1,6 +1,10 @@# This mimics the top-level Makefile. We do it explicitly here so that this# Makefile can operate with or without the kbuild infrastructure.+ifneq ($(LLVM),)+CC:=clang+elseCC:=$(CROSS_COMPILE)gcc+endififeq (0,$(MAKELEVEL)) ifeq ($(OUTPUT),)
From: Emmanuel Grumbach <redacted>
[ Upstream commit d6843d1ee283137723b4a8c76244607ce6db1951 ]
After channel switch, we should consider any beacon with a
CSA IE as a new switch. If the CSA IE is a leftover from
before the switch that the AP forgot to remove, we'll get
a CSA-to-Self.
This caused issues in iwlwifi where the firmware saw a beacon
with a CSA-to-Self with mode = 1 on the new channel after a
switch. The firmware considered this a new switch and closed
its queues. Since the beacon didn't change between before and
after the switch, we wouldn't handle it (the CRC is the same)
and we wouldn't let the firmware open its queues again or
disconnect if the CSA IE stays for too long.
Clear the CRC valid state after we switch to make sure that
we handle the beacon and handle the CSA IE as required.
Signed-off-by: Emmanuel Grumbach <redacted>
Link: https://lore.kernel.org/r/20210408143124.b9e68aa98304.I465afb55ca2c7d59f7bf610c6046a1fd732b4c28@changeid
Signed-off-by: Johannes Berg <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/mac80211/mlme.c | 5 +++++
1 file changed, 5 insertions(+)
From commit c0bbbdc32feb ("__netif_receive_skb_core: pass skb by
reference"), the first argument passed into __netif_receive_skb_core
has changed to reference of a skb pointer.
This commit fixes by using bpf_probe_read_kernel.
Signed-off-by: Yaqi Chen <redacted>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Yonghong Song <redacted>
Link: https://lore.kernel.org/bpf/20210416154803.37157-1-chendotjs@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
samples/bpf/tracex1_kern.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
@@ -26,7 +26,7 @@SEC("kprobe/__netif_receive_skb_core")intbpf_prog1(structpt_regs*ctx){-/* attaches to kprobe netif_receive_skb,+/* attaches to kprobe __netif_receive_skb_core,*looksforpacketsonloobpackdeviceandprintsthem*/chardevname[IFNAMSIZ];
@@ -35,7 +35,7 @@ int bpf_prog1(struct pt_regs *ctx)intlen;/* non-portable! works for the given kernel only */-skb=(structsk_buff*)PT_REGS_PARM1(ctx);+bpf_probe_read_kernel(&skb,sizeof(skb),(void*)PT_REGS_PARM1(ctx));dev=_(skb->dev);len=_(skb->len);
From: "Gustavo A. R. Silva" <gustavoars@kernel.org>
[ Upstream commit bb43e5718d8f1b46e7a77e7b39be3c691f293050 ]
Fix the following out-of-bounds warnings by adding a new structure
wl3501_req instead of duplicating the same members in structure
wl3501_join_req and wl3501_scan_confirm:
arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [39, 108] from the object at 'sig' is out of the bounds of referenced subobject 'beacon_period' with type 'short unsigned int' at offset 36 [-Warray-bounds]
arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [25, 95] from the object at 'sig' is out of the bounds of referenced subobject 'beacon_period' with type 'short unsigned int' at offset 22 [-Warray-bounds]
Refactor the code, accordingly:
$ pahole -C wl3501_req drivers/net/wireless/wl3501_cs.o
struct wl3501_req {
u16 beacon_period; /* 0 2 */
u16 dtim_period; /* 2 2 */
u16 cap_info; /* 4 2 */
u8 bss_type; /* 6 1 */
u8 bssid[6]; /* 7 6 */
struct iw_mgmt_essid_pset ssid; /* 13 34 */
struct iw_mgmt_ds_pset ds_pset; /* 47 3 */
struct iw_mgmt_cf_pset cf_pset; /* 50 8 */
struct iw_mgmt_ibss_pset ibss_pset; /* 58 4 */
struct iw_mgmt_data_rset bss_basic_rset; /* 62 10 */
/* size: 72, cachelines: 2, members: 10 */
/* last cacheline: 8 bytes */
};
$ pahole -C wl3501_join_req drivers/net/wireless/wl3501_cs.o
struct wl3501_join_req {
u16 next_blk; /* 0 2 */
u8 sig_id; /* 2 1 */
u8 reserved; /* 3 1 */
struct iw_mgmt_data_rset operational_rset; /* 4 10 */
u16 reserved2; /* 14 2 */
u16 timeout; /* 16 2 */
u16 probe_delay; /* 18 2 */
u8 timestamp[8]; /* 20 8 */
u8 local_time[8]; /* 28 8 */
struct wl3501_req req; /* 36 72 */
/* size: 108, cachelines: 2, members: 10 */
/* last cacheline: 44 bytes */
};
$ pahole -C wl3501_scan_confirm drivers/net/wireless/wl3501_cs.o
struct wl3501_scan_confirm {
u16 next_blk; /* 0 2 */
u8 sig_id; /* 2 1 */
u8 reserved; /* 3 1 */
u16 status; /* 4 2 */
char timestamp[8]; /* 6 8 */
char localtime[8]; /* 14 8 */
struct wl3501_req req; /* 22 72 */
/* --- cacheline 1 boundary (64 bytes) was 30 bytes ago --- */
u8 rssi; /* 94 1 */
/* size: 96, cachelines: 2, members: 8 */
/* padding: 1 */
/* last cacheline: 32 bytes */
};
The problem is that the original code is trying to copy data into a
bunch of struct members adjacent to each other in a single call to
memcpy(). Now that a new struct wl3501_req enclosing all those adjacent
members is introduced, memcpy() doesn't overrun the length of
&sig.beacon_period and &this->bss_set[i].beacon_period, because the
address of the new struct object _req_ is used as the destination,
instead.
This helps with the ongoing efforts to globally enable -Warray-bounds
and get us closer to being able to tighten the FORTIFY_SOURCE routines
on memcpy().
Link: https://github.com/KSPP/linux/issues/109
Reported-by: kernel test robot <redacted>
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: Kees Cook <redacted>
Signed-off-by: Kalle Valo <redacted>
Link: https://lore.kernel.org/r/1fbaf516da763b50edac47d792a9145aa4482e29.1618442265.git.gustavoars@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/wl3501.h | 35 +++++++++++--------------
drivers/net/wireless/wl3501_cs.c | 44 +++++++++++++++++---------------
2 files changed, 38 insertions(+), 41 deletions(-)
From: Felix Fietkau <nbd@nbd.name>
[ Upstream commit 3f57d8c40fea9b20543cab4da12f4680d2ef182c ]
The VLAN ID in the rx descriptor is only valid if the RX_DMA_VTAG bit is
set. Fixes frames wrongly marked with VLAN tags.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
[Ilya: fix commit message]
Signed-off-by: Ilya Lipnitskiy <redacted>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 2 +-
drivers/net/ethernet/mediatek/mtk_eth_soc.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
From: Stefan Assmann <redacted>
[ Upstream commit 1a0e880b028f97478dc689e2900b312741d0d772 ]
Both iavf_free_all_tx_resources() and iavf_free_all_rx_resources() have
already been called in the very same function.
Remove the duplicate calls.
Signed-off-by: Stefan Assmann <redacted>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/intel/iavf/iavf_main.c | 2 --
1 file changed, 2 deletions(-)
From: Petr Machata <petrm@nvidia.com>
[ Upstream commit dda7f4fa55839baeb72ae040aeaf9ccf89d3e416 ]
The intention behind this test is to make sure that qdisc limit is
correctly projected to the HW. However, first, due to rounding in the
qdisc, and then in the driver, the number cannot actually be accurate. And
second, the approach to testing this is to oversubscribe the port with
traffic generated on the same switch. The actual backlog size therefore
fluctuates.
In practice, this test proved to be noisier than the rest, and spuriously
fails every now and then. Increase the tolerance to 10 % to avoid these
issues.
Signed-off-by: Petr Machata <petrm@nvidia.com>
Acked-by: Jiri Pirko <redacted>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/testing/selftests/drivers/net/mlxsw/sch_red_core.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Petr Machata <petrm@nvidia.com>
[ Upstream commit 1233898ab758cbcf5f6fea10b8dd16a0b2c24fab ]
The mirror_gre_scale test creates as many ERSPAN sessions as the underlying
chip supports, and tests that they all work. In order to determine that it
issues a stream of ICMP packets and checks if they are mirrored as
expected.
However, the mausezahn invocation missed the -6 flag to identify the use of
IPv6 protocol, and was sending ICMP messages over IPv6, as opposed to
ICMP6. It also didn't pass an explicit source IP address, which apparently
worked at some point in the past, but does not anymore.
To fix these issues, extend the function mirror_test() in mirror_lib by
detecting the IPv6 protocol addresses, and using a different ICMP scheme.
Fix __mirror_gre_test() in the selftest itself to pass a source IP address.
Signed-off-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
.../drivers/net/mlxsw/mirror_gre_scale.sh | 3 ++-
.../selftests/net/forwarding/mirror_lib.sh | 19 +++++++++++++++++--
2 files changed, 19 insertions(+), 3 deletions(-)
From: "Gustavo A. R. Silva" <gustavoars@kernel.org>
[ Upstream commit c1d9e34e11281a8ba1a1c54e4db554232a461488 ]
Fix the following out-of-bounds warning:
net/ethtool/ioctl.c:492:2: warning: 'memcpy' offset [49, 84] from the object at 'link_usettings' is out of the bounds of referenced subobject 'base' with type 'struct ethtool_link_settings' at offset 0 [-Warray-bounds]
The problem is that the original code is trying to copy data into a
some struct members adjacent to each other in a single call to
memcpy(). This causes a legitimate compiler warning because memcpy()
overruns the length of &link_usettings.base. Fix this by directly
using &link_usettings and _from_ as destination and source addresses,
instead.
This helps with the ongoing efforts to globally enable -Warray-bounds
and get us closer to being able to tighten the FORTIFY_SOURCE routines
on memcpy().
Link: https://github.com/KSPP/linux/issues/109
Reported-by: kernel test robot <redacted>
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/ethtool/ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Du Cheng <redacted>
[ Upstream commit ed8157f1ebf1ae81a8fa2653e3f20d2076fad1c9 ]
There is a reproducible sequence from the userland that will trigger a WARN_ON()
condition in taprio_get_start_time, which causes kernel to panic if configured
as "panic_on_warn". Catch this condition in parse_taprio_schedule to
prevent this condition.
Reported as bug on syzkaller:
https://syzkaller.appspot.com/bug?extid=d50710fd0873a9c6b40c
Reported-by: syzbot+d50710fd0873a9c6b40c@syzkaller.appspotmail.com
Signed-off-by: Du Cheng <redacted>
Acked-by: Cong Wang <redacted>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/sched/sch_taprio.c | 6 ++++++
1 file changed, 6 insertions(+)
@@ -900,6 +900,12 @@ static int parse_taprio_schedule(struct taprio_sched *q, struct nlattr **tb,list_for_each_entry(entry,&new->entries,list)cycle=ktime_add_ns(cycle,entry->interval);++if(!cycle){+NL_SET_ERR_MSG(extack,"'cycle_time' can never be 0");+return-EINVAL;+}+new->cycle_time=cycle;}