- 10 Aug, 2022 13 commits
-
-
Peilin Ye authored
An O_NONBLOCK vsock_connect() request may try to reschedule @connect_work. Imagine the following sequence of vsock_connect() requests: 1. The 1st, non-blocking request schedules @connect_work, which will expire after 200 jiffies. Socket state is now SS_CONNECTING; 2. Later, the 2nd, blocking request gets interrupted by a signal after a few jiffies while waiting for the connection to be established. Socket state is back to SS_UNCONNECTED, but @connect_work is still pending, and will expire after 100 jiffies. 3. Now, the 3rd, non-blocking request tries to schedule @connect_work again. Since @connect_work is already scheduled, schedule_delayed_work() silently returns. sock_hold() is called twice, but sock_put() will only be called once in vsock_connect_timeout(), causing a memory leak reported by syzbot: BUG: memory leak unreferenced object 0xffff88810ea56a40 (size 1232): comm "syz-executor756", pid 3604, jiffies 4294947681 (age 12.350s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace: [<ffffffff837c830e>] sk_prot_alloc+0x3e/0x1b0 net/core/sock.c:1930 [<ffffffff837cbe22>] sk_alloc+0x32/0x2e0 net/core/sock.c:1989 [<ffffffff842ccf68>] __vsock_create.constprop.0+0x38/0x320 net/vmw_vsock/af_vsock.c:734 [<ffffffff842ce8f1>] vsock_create+0xc1/0x2d0 net/vmw_vsock/af_vsock.c:2203 [<ffffffff837c0cbb>] __sock_create+0x1ab/0x2b0 net/socket.c:1468 [<ffffffff837c3acf>] sock_create net/socket.c:1519 [inline] [<ffffffff837c3acf>] __sys_socket+0x6f/0x140 net/socket.c:1561 [<ffffffff837c3bba>] __do_sys_socket net/socket.c:1570 [inline] [<ffffffff837c3bba>] __se_sys_socket net/socket.c:1568 [inline] [<ffffffff837c3bba>] __x64_sys_socket+0x1a/0x20 net/socket.c:1568 [<ffffffff84512815>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<ffffffff84512815>] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:80 [<ffffffff84600068>] entry_SYSCALL_64_after_hwframe+0x44/0xae <...> Use mod_delayed_work() instead: if @connect_work is already scheduled, reschedule it, and undo sock_hold() to keep the reference count balanced. Reported-and-tested-by: syzbot+b03f55bf128f9a38f064@syzkaller.appspotmail.com Fixes: d021c344 ("VSOCK: Introduce VM Sockets") Co-developed-by:Stefano Garzarella <sgarzare@redhat.com> Signed-off-by:
Peilin Ye <peilin.ye@bytedance.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jose Alonso authored
This reverts commit 36a15e1c. The usage of FLAG_SEND_ZLP causes problems to other firmware/hardware versions that have no issues. The FLAG_SEND_ZLP is not safe to use in this context. See: https://patchwork.ozlabs.org/project/netdev/patch/1270599787.8900.8.camel@Linuxdev4-laptop/#118378 The original problem needs another way to solve. Fixes: 36a15e1c ("net: usb: ax88179_178a needs FLAG_SEND_ZLP") Cc: stable@vger.kernel.org Reported-by:
Ronald Wahl <ronald.wahl@raritan.com> Link: https://bugzilla.kernel.org/show_bug.cgi?id=216327 Link: https://bugs.archlinux.org/task/75491Signed-off-by:
Jose Alonso <joalonsof@gmail.com> Signed-off-by:
-
Topi Miettinen authored
'IPv4 and IPv4' should be 'IPv4 and IPv6'. Signed-off-by:
Topi Miettinen <toiwoton@gmail.com> Acked-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
-
David S. Miller authored
Merge tag 'linux-can-fixes-for-6.0-20220810' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can Marc Kleine-Budde says: ==================== this is a pull request of 4 patches for net/master, with the whitespace issue fixed. Fedor Pchelkin contributes 2 fixes for the j1939 CAN protocol. A patch by me for the ems_usb driver fixes an unaligned access warning. Sebastian Würl's patch for the mcp251x driver fixes a race condition in the receive interrupt. ==================== Signed-off-by:
-
Jakub Kicinski authored
Matthias May says: ==================== Do not use RT_TOS for IPv6 flowlabel According to Guillaume Nault RT_TOS should never be used for IPv6. Quote: RT_TOS() is an old macro used to interprete IPv4 TOS as described in the obsolete RFC 1349. It's conceptually wrong to use it even in IPv4 code, although, given the current state of the code, most of the existing calls have no consequence. But using RT_TOS() in IPv6 code is always a bug: IPv6 never had a "TOS" field to be interpreted the RFC 1349 way. There's no historical compatibility to worry about. ==================== Link: https://lore.kernel.org/r/20220805191906.9323-1-matthias.may@westermo.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Matthias May authored
According to Guillaume Nault RT_TOS should never be used for IPv6. Quote: RT_TOS() is an old macro used to interprete IPv4 TOS as described in the obsolete RFC 1349. It's conceptually wrong to use it even in IPv4 code, although, given the current state of the code, most of the existing calls have no consequence. But using RT_TOS() in IPv6 code is always a bug: IPv6 never had a "TOS" field to be interpreted the RFC 1349 way. There's no historical compatibility to worry about. Fixes: 571912c6 ("net: UDP tunnel encapsulation module for tunnelling different protocols like MPLS, IP, NSH etc.") Acked-by:
Guillaume Nault <gnault@redhat.com> Signed-off-by:
Matthias May <matthias.may@westermo.com> Signed-off-by:
-
Matthias May authored
According to Guillaume Nault RT_TOS should never be used for IPv6. Quote: RT_TOS() is an old macro used to interprete IPv4 TOS as described in the obsolete RFC 1349. It's conceptually wrong to use it even in IPv4 code, although, given the current state of the code, most of the existing calls have no consequence. But using RT_TOS() in IPv6 code is always a bug: IPv6 never had a "TOS" field to be interpreted the RFC 1349 way. There's no historical compatibility to worry about. Fixes: ce99f6b9 ("net/mlx5e: Support SRIOV TC encapsulation offloads for IPv6 tunnels") Acked-by:
-
Matthias May authored
According to Guillaume Nault RT_TOS should never be used for IPv6. Quote: RT_TOS() is an old macro used to interprete IPv4 TOS as described in the obsolete RFC 1349. It's conceptually wrong to use it even in IPv4 code, although, given the current state of the code, most of the existing calls have no consequence. But using RT_TOS() in IPv6 code is always a bug: IPv6 never had a "TOS" field to be interpreted the RFC 1349 way. There's no historical compatibility to worry about. Fixes: 1400615d ("vxlan: allow setting ipv6 traffic class") Acked-by:
-
Matthias May authored
According to Guillaume Nault RT_TOS should never be used for IPv6. Quote: RT_TOS() is an old macro used to interprete IPv4 TOS as described in the obsolete RFC 1349. It's conceptually wrong to use it even in IPv4 code, although, given the current state of the code, most of the existing calls have no consequence. But using RT_TOS() in IPv6 code is always a bug: IPv6 never had a "TOS" field to be interpreted the RFC 1349 way. There's no historical compatibility to worry about. Fixes: 3a56f86f ("geneve: handle ipv6 priority like ipv4 tos") Acked-by:
-
Matthias May authored
The current code retrieves the TOS field after the lookup on the ipv4 routing table. The routing process currently only allows routing based on the original 3 TOS bits, and not on the full 6 DSCP bits. As a result the retrieved TOS is cut to the 3 bits. However for inheriting purposes the full 6 bits should be used. Extract the full 6 bits before the route lookup and use that instead of the cut off 3 TOS bits. Fixes: e305ac6c ("geneve: Add support to collect tunnel metadata.") Signed-off-by:
-
Chia-Lin Kao (AceLan) authored
The final update statement of the for loop exceeds the array range, the dereference of self->aq_vec[i] is not checked and then leads to the index out of range error. Also fixed this kind of coding style in other for loop. [ 97.937604] UBSAN: array-index-out-of-bounds in drivers/net/ethernet/aquantia/atlantic/aq_nic.c:1404:48 [ 97.937607] index 8 is out of range for type 'aq_vec_s *[8]' [ 97.937608] CPU: 38 PID: 3767 Comm: kworker/u256:18 Not tainted 5.19.0+ #2 [ 97.937610] Hardware name: Dell Inc. Precision 7865 Tower/, BIOS 1.0.0 06/12/2022 [ 97.937611] Workqueue: events_unbound async_run_entry_fn [ 97.937616] Call Trace: [ 97.937617] <TASK> [ 97.937619] dump_stack_lvl+0x49/0x63 [ 97.937624] dump_stack+0x10/0x16 [ 97.937626] ubsan_epilogue+0x9/0x3f [ 97.937627] __ubsan_handle_out_of_bounds.cold+0x44/0x49 [ 97.937629] ? __scm_send+0x348/0x440 [ 97.937632] ? aq_vec_stop+0x72/0x80 [atlantic] [ 97.937639] aq_nic_stop+0x1b6/0x1c0 [atlantic] [ 97.937644] aq_suspend_common+0x88/0x90 [atlantic] [ 97.937648] aq_pm_suspend_poweroff+0xe/0x20 [atlantic] [ 97.937653] pci_pm_suspend+0x7e/0x1a0 [ 97.937655] ? pci_pm_suspend_noirq+0x2b0/0x2b0 [ 97.937657] dpm_run_callback+0x54/0x190 [ 97.937660] __device_suspend+0x14c/0x4d0 [ 97.937661] async_suspend+0x23/0x70 [ 97.937663] async_run_entry_fn+0x33/0x120 [ 97.937664] process_one_work+0x21f/0x3f0 [ 97.937666] worker_thread+0x4a/0x3c0 [ 97.937668] ? process_one_work+0x3f0/0x3f0 [ 97.937669] kthread+0xf0/0x120 [ 97.937671] ? kthread_complete_and_exit+0x20/0x20 [ 97.937672] ret_from_fork+0x22/0x30 [ 97.937676] </TASK> v2. fixed "warning: variable 'aq_vec' set but not used" v3. simplified a for loop Fixes: 97bde5c4 ("net: ethernet: aquantia: Support for NIC-specific code") Signed-off-by:
Chia-Lin Kao (AceLan) <acelan.kao@canonical.com> Acked-by:
Sudarsana Reddy Kalluru <skalluru@marvell.com> Link: https://lore.kernel.org/r/20220808081845.42005-1-acelan.kao@canonical.comSigned-off-by:
-
Christophe JAILLET authored
s/by caused/be caused/ s/ax88786/ax88796/ Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/7db4b622d2c3e5af58c1d1f32b81836f4af71f18.1659801746.git.christophe.jaillet@wanadoo.frSigned-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nfJakub Kicinski authored
Pablo Neira Ayuso says: ==================== Netfilter fixes for net The following patchset contains Netfilter fixes for net: 1) Harden set element field checks to avoid out-of-bound memory access, this patch also fixes the type of issue described in 7e6bc1f6 ("netfilter: nf_tables: stricter validation of element data") in a broader way. 2) Patches to restrict the chain, set, and rule id lookup in the transaction to the corresponding top-level table, patches from Thadeu Lima de Souza Cascardo. 3) Fix incorrect comment in ip6t_LOG.h 4) nft_data_init() performs upfront validation of the expected data. struct nft_data_desc is used to describe the expected data to be received from userspace. The .size field represents the maximum size that can be stored, for bound checks. Then, .len is an input/output field which stores the expected length as input (this is optional, to restrict the checks), as output it stores the real length received from userspace (if it was not specified as input). This patch comes in response to 7e6bc1f6 ("netfilter: nf_tables: stricter validation of element data") to address this type of issue in a more generic way by avoid opencoded data validation. Next patch requires this as a dependency. 5) Disallow jump to implicit chain from set element, this configuration is invalid. Only allow jump to chain via immediate expression is supported at this stage. 6) Fix possible null-pointer derefence in the error path of table updates, if memory allocation of the transaction fails. From Florian Westphal. * git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf: netfilter: nf_tables: fix null deref due to zeroed list head netfilter: nf_tables: disallow jump to implicit chain from set element netfilter: nf_tables: upfront validation of data via nft_data_init() netfilter: ip6t_LOG: Fix a typo in a comment netfilter: nf_tables: do not allow RULE_ID to refer to another chain netfilter: nf_tables: do not allow CHAIN_ID to refer to another table netfilter: nf_tables: do not allow SET_ID to refer to another table netfilter: nf_tables: validate variable length element extension ==================== Link: https://lore.kernel.org/r/20220809220532.130240-1-pablo@netfilter.org/Signed-off-by:
-
- 09 Aug, 2022 27 commits
-
-
Sebastian Würl authored
The mcp251x driver uses both receiving mailboxes of the CAN controller chips. For retrieving the CAN frames from the controller via SPI, it checks once per interrupt which mailboxes have been filled and will retrieve the messages accordingly. This introduces a race condition, as another CAN frame can enter mailbox 1 while mailbox 0 is emptied. If now another CAN frame enters mailbox 0 until the interrupt handler is called next, mailbox 0 is emptied before mailbox 1, leading to out-of-order CAN frames in the network device. This is fixed by checking the interrupt flags once again after freeing mailbox 0, to correctly also empty mailbox 1 before leaving the handler. For reproducing the bug I created the following setup: - Two CAN devices, one Raspberry Pi with MCP2515, the other can be any. - Setup CAN to 1 MHz - Spam bursts of 5 CAN-messages with increasing CAN-ids - Continue sending the bursts while sleeping a second between the bursts - Check on the RPi whether the received messages have increasing CAN-ids - Without this patch, every burst of messages will contain a flipped pair v3: https://lore.kernel.org/all/20220804075914.67569-1-sebastian.wuerl@ororatech.com v2: https://lore.kernel.org/all/20220804064803.63157-1-sebastian.wuerl@ororatech.com v1: https://lore.kernel.org/all/20220803153300.58732-1-sebastian.wuerl@ororatech.com Fixes: bf66f373 ("can: mcp251x: Move to threaded interrupts instead of workqueues.") Signed-off-by:
Sebastian Würl <sebastian.wuerl@ororatech.com> Link: https://lore.kernel.org/all/20220804081411.68567-1-sebastian.wuerl@ororatech.com [mkl: reduce scope of intf1, eflag1] Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de>
-
Florian Westphal authored
WARNING: suspicious RCU usage 5.2.0-rc2-00605-g2638eb8b #1 Not tainted drivers/net/plip/plip.c:1110 suspicious rcu_dereference_check() usage! plip_open is called with RTNL held, switch to the correct helper. Fixes: 2638eb8b ("net: ipv4: provide __rcu annotation for ifa_list") Reported-by:
kernel test robot <oliver.sang@intel.com> Signed-off-by:
Florian Westphal <fw@strlen.de> Link: https://lore.kernel.org/r/20220807115304.13257-1-fw@strlen.deSigned-off-by:
-
Sandor Bodo-Merle authored
On one of our machines we got: kernel BUG at lib/dynamic_queue_limits.c:27! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM CPU: 0 PID: 1166 Comm: irq/41-bgmac Tainted: G W O 4.14.275-rt132 #1 Hardware name: BRCM XGS iProc task: ee3415c0 task.stack: ee32a000 PC is at dql_completed+0x168/0x178 LR is at bgmac_poll+0x18c/0x6d8 pc : [<c03b9430>] lr : [<c04b5a18>] psr: 800a0313 sp : ee32be14 ip : 000005ea fp : 00000bd4 r10: ee558500 r9 : c0116298 r8 : 00000002 r7 : 00000000 r6 : ef128810 r5 : 01993267 r4 : 01993851 r3 : ee558000 r2 : 000070e1 r1 : 00000bd4 r0 : ee52c180 Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 12c5387d Table: 8e88c04a DAC: 00000051 Process irq/41-bgmac (pid: 1166, stack limit = 0xee32a210) Stack: (0xee32be14 to 0xee32c000) be00: ee558520 ee52c100 ef128810 be20: 00000000 00000002 c0116298 c04b5a18 00000000 c0a0c8c4 c0951780 00000040 be40: c0701780 ee558500 ee55d520 ef05b340 ef6f9780 ee558520 00000001 00000040 be60: ffffe000 c0a56878 ef6fa040 c0952040 0000012c c0528744 ef6f97b0 fffcfb6a be80: c0a04104 2eda8000 c0a0c4ec c0a0d368 ee32bf44 c0153534 ee32be98 ee32be98 bea0: ee32bea0 ee32bea0 ee32bea8 ee32bea8 00000000 c01462e4 ffffe000 ef6f22a8 bec0: ffffe000 00000008 ee32bee4 c0147430 ffffe000 c094a2a8 00000003 ffffe000 bee0: c0a54528 00208040 0000000c c0a0c8c4 c0a65980 c0124d3c 00000008 ee558520 bf00: c094a23c c0a02080 00000000 c07a9910 ef136970 ef136970 ee30a440 ef136900 bf20: ee30a440 00000001 ef136900 ee30a440 c016d990 00000000 c0108db0 c012500c bf40: ef136900 c016da14 ee30a464 ffffe000 00000001 c016dd14 00000000 c016db28 bf60: ffffe000 ee21a080 ee30a400 00000000 ee32a000 ee30a440 c016dbfc ee25fd70 bf80: ee21a09c c013edcc ee32a000 ee30a400 c013ec7c 00000000 00000000 00000000 bfa0: 00000000 00000000 00000000 c0108470 00000000 00000000 00000000 00000000 bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [<c03b9430>] (dql_completed) from [<c04b5a18>] (bgmac_poll+0x18c/0x6d8) [<c04b5a18>] (bgmac_poll) from [<c0528744>] (net_rx_action+0x1c4/0x494) [<c0528744>] (net_rx_action) from [<c0124d3c>] (do_current_softirqs+0x1ec/0x43c) [<c0124d3c>] (do_current_softirqs) from [<c012500c>] (__local_bh_enable+0x80/0x98) [<c012500c>] (__local_bh_enable) from [<c016da14>] (irq_forced_thread_fn+0x84/0x98) [<c016da14>] (irq_forced_thread_fn) from [<c016dd14>] (irq_thread+0x118/0x1c0) [<c016dd14>] (irq_thread) from [<c013edcc>] (kthread+0x150/0x158) [<c013edcc>] (kthread) from [<c0108470>] (ret_from_fork+0x14/0x24) Code: a83f15e0 0200001a 0630a0e1 c3ffffea (f201f0e7) The issue seems similar to commit 90b3b339 ("net: hisilicon: Fix a BUG trigered by wrong bytes_compl") and potentially introduced by commit b38c83dd ("bgmac: simplify tx ring index handling"). If there is an RX interrupt between setting ring->end and netdev_sent_queue() we can hit the BUG_ON as bgmac_dma_tx_free() can miscalculate the queue size while called from bgmac_poll(). The machine which triggered the BUG runs a v4.14 RT kernel - but the issue seems present in mainline too. Fixes: b38c83dd ("bgmac: simplify tx ring index handling") Signed-off-by:
Sandor Bodo-Merle <sbodomerle@gmail.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20220808173939.193804-1-sbodomerle@gmail.comSigned-off-by:
-
Vladimir Oltean authored
The way in which dsa_tree_change_tag_proto() works is that when dsa_tree_notify() fails, it doesn't know whether the operation failed mid way in a multi-switch tree, or it failed for a single-switch tree. So even though drivers need to fail cleanly in ds->ops->change_tag_protocol(), DSA will still call dsa_tree_notify() again, to restore the old tag protocol for potential switches in the tree where the change did succeeed (before failing for others). This means for the felix driver that if we report an error in felix_change_tag_protocol(), we'll get another call where proto_ops == old_proto_ops. If we proceed to act upon that, we may do unexpected things. For example, we will call dsa_tag_8021q_register() twice in a row, without any dsa_tag_8021q_unregister() in between. Then we will actually call dsa_tag_8021q_unregister() via old_proto_ops->teardown, which (if it manages to run at all, after walking through corrupted data structures) will leave the ports inoperational anyway. The bug can be readily reproduced if we force an error while in tag_8021q mode; this crashes the kernel. echo ocelot-8021q > /sys/class/net/eno2/dsa/tagging echo edsa > /sys/class/net/eno2/dsa/tagging # -EPROTONOSUPPORT Unable to handle kernel NULL pointer dereference at virtual address 0000000000000014 Call trace: vcap_entry_get+0x24/0x124 ocelot_vcap_filter_del+0x198/0x270 felix_tag_8021q_vlan_del+0xd4/0x21c dsa_switch_tag_8021q_vlan_del+0x168/0x2cc dsa_switch_event+0x68/0x1170 dsa_tree_notify+0x14/0x34 dsa_port_tag_8021q_vlan_del+0x84/0x110 dsa_tag_8021q_unregister+0x15c/0x1c0 felix_tag_8021q_teardown+0x16c/0x180 felix_change_tag_protocol+0x1bc/0x230 dsa_switch_event+0x14c/0x1170 dsa_tree_change_tag_proto+0x118/0x1c0 Fixes: 7a29d220 ("net: dsa: felix: reimplement tagging protocol change with function pointers") Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wirelessJakub Kicinski authored
Kalle Valo says: ==================== wireless fixes for v6.0 First set of fixes for v6.0. Small one this time, fix a cfg80211 warning seen with brcmfmac and remove an unncessary inline keyword from wilc1000. * tag 'wireless-2022-08-09' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: wifi: wilc1000: fix spurious inline in wilc_handle_disconnect() wifi: cfg80211: Fix validating BSS pointers in __cfg80211_connect_result ==================== Link: https://lore.kernel.org/r/20220809164756.B1DAEC433D6@smtp.kernel.orgSigned-off-by:
-
Florian Westphal authored
In nf_tables_updtable, if nf_tables_table_enable returns an error, nft_trans_destroy is called to free the transaction object. nft_trans_destroy() calls list_del(), but the transaction was never placed on a list -- the list head is all zeroes, this results in a null dereference: BUG: KASAN: null-ptr-deref in nft_trans_destroy+0x26/0x59 Call Trace: nft_trans_destroy+0x26/0x59 nf_tables_newtable+0x4bc/0x9bc [..] Its sane to assume that nft_trans_destroy() can be called on the transaction object returned by nft_trans_alloc(), so make sure the list head is initialised. Fixes: 55dd6f93 ("netfilter: nf_tables: use new transaction infrastructure to handle table") Reported-by:
mingi cho <mgcho.minic@gmail.com> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org>
-
Pablo Neira Ayuso authored
Extend struct nft_data_desc to add a flag field that specifies nft_data_init() is being called for set element data. Use it to disallow jump to implicit chain from set element, only jump to chain via immediate expression is allowed. Fixes: d0e2c7de ("netfilter: nf_tables: add NFT_CHAIN_BINDING") Signed-off-by:
-
Pablo Neira Ayuso authored
Instead of parsing the data and then validate that type and length are correct, pass a description of the expected data so it can be validated upfront before parsing it to bail out earlier. This patch adds a new .size field to specify the maximum size of the data area. The .len field is optional and it is used as an input/output field, it provides the specific length of the expected data in the input path. If then .len field is not specified, then obtained length from the netlink attribute is stored. This is required by cmp, bitwise, range and immediate, which provide no netlink attribute that describes the data length. The immediate expression uses the destination register type to infer the expected data type. Relying on opencoded validation of the expected data might lead to subtle bugs as described in 7e6bc1f6 ("netfilter: nf_tables: stricter validation of element data"). Signed-off-by:
-
Christophe JAILLET authored
s/_IPT_LOG_H/_IP6T_LOG_H/ While at it add some surrounding space to ease reading. Signed-off-by:
-
Thadeu Lima de Souza Cascardo authored
When doing lookups for rules on the same batch by using its ID, a rule from a different chain can be used. If a rule is added to a chain but tries to be positioned next to a rule from a different chain, it will be linked to chain2, but the use counter on chain1 would be the one to be incremented. When looking for rules by ID, use the chain that was used for the lookup by name. The chain used in the context copied to the transaction needs to match that same chain. That way, struct nft_rule does not need to get enlarged with another member. Fixes: 1a94e38d ("netfilter: nf_tables: add NFTA_RULE_ID attribute") Fixes: 75dd48e2 ("netfilter: nf_tables: Support RULE_ID reference in new rule") Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Thadeu Lima de Souza Cascardo authored
When doing lookups for chains on the same batch by using its ID, a chain from a different table can be used. If a rule is added to a table but refers to a chain in a different table, it will be linked to the chain in table2, but would have expressions referring to objects in table1. Then, when table1 is removed, the rule will not be removed as its linked to a chain in table2. When expressions in the rule are processed or removed, that will lead to a use-after-free. When looking for chains by ID, use the table that was used for the lookup by name, and only return chains belonging to that same table. Fixes: 837830a4 ("netfilter: nf_tables: add NFTA_RULE_CHAIN_ID attribute") Signed-off-by:
-
Thadeu Lima de Souza Cascardo authored
When doing lookups for sets on the same batch by using its ID, a set from a different table can be used. Then, when the table is removed, a reference to the set may be kept after the set is freed, leading to a potential use-after-free. When looking for sets by ID, use the table that was used for the lookup by name, and only return sets belonging to that same table. This fixes CVE-2022-2586, also reported as ZDI-CAN-17470. Reported-by: Team Orca of Sea Security (@seasecresponse) Fixes: 958bee14 ("netfilter: nf_tables: use new transaction infrastructure to handle sets") Signed-off-by:
-
Pablo Neira Ayuso authored
Update template to validate variable length extensions. This patch adds a new .ext_len[id] field to the template to store the expected extension length. This is used to sanity check the initialization of the variable length extension. Use PTR_ERR() in nft_set_elem_init() to report errors since, after this update, there are two reason why this might fail, either because of ENOMEM or insufficient room in the extension field (EINVAL). Kernels up until 7e6bc1f6 ("netfilter: nf_tables: stricter validation of element data") allowed to copy more data to the extension than was allocated. This ext_len field allows to validate if the destination has the correct size as additional check. Signed-off-by:
-
Marc Kleine-Budde authored
clang emits a -Wunaligned-access warning on struct __packed ems_cpc_msg. The reason is that the anonymous union msg (not declared as packed) is being packed right after some non naturally aligned variables (3*8 bits + 2*32) inside a packed struct: | struct __packed ems_cpc_msg { | u8 type; /* type of message */ | u8 length; /* length of data within union 'msg' */ | u8 msgid; /* confirmation handle */ | __le32 ts_sec; /* timestamp in seconds */ | __le32 ts_nsec; /* timestamp in nano seconds */ | /* ^ not naturally aligned */ | | union { | /* ^ not declared as packed */ | u8 generic[64]; | struct cpc_can_msg can_msg; | struct cpc_can_params can_params; | struct cpc_confirm confirmation; | struct cpc_overrun overrun; | struct cpc_can_error error; | struct cpc_can_err_counter err_counter; | u8 can_state; | } msg; | }; Starting from LLVM 14, having an unpacked struct nested in a packed struct triggers a warning. c.f. [1]. Fix the warning by marking the anonymous union as packed. [1] https://github.com/llvm/llvm-project/issues/55520 Fixes: 702171ad ("ems_usb: Added support for EMS CPC-USB/ARM7 CAN/USB interface") Link: https://lore.kernel.org/all/20220802094021.959858-1-mkl@pengutronix.de Cc: Gerhard Uttenthaler <uttenthaler@ems-wuensche.com> Cc: Sebastian Haas <haas@ems-wuensche.com> Signed-off-by: -
Fedor Pchelkin authored
We need to drop skb references taken in j1939_session_skb_queue() when destroying a session in j1939_session_destroy(). Otherwise those skbs would be lost. Link to Syzkaller info and repro: https://forge.ispras.ru/issues/11743. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. V1: https://lore.kernel.org/all/20220708175949.539064-1-pchelkin@ispras.ru Fixes: 9d71dd0c ("can: add support of SAE J1939 protocol") Suggested-by:
Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by:
Fedor Pchelkin <pchelkin@ispras.ru> Signed-off-by:
Alexey Khoroshilov <khoroshilov@ispras.ru> Acked-by:
-
Fedor Pchelkin authored
We should warn user-space that it is doing something wrong when trying to activate sessions with identical parameters but WARN_ON_ONCE macro can not be used here as it serves a different purpose. So it would be good to replace it with netdev_warn_once() message. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 9d71dd0c ("can: add support of SAE J1939 protocol") Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetoothJakub Kicinski authored
Luiz Augusto von Dentz says: ==================== bluetooth pull request for net: - Fixes various issues related to ISO channel/socket support - Fixes issues when building with C=1 - Fix cancel uninitilized work which blocks syzbot to run * tag 'for-net-2022-08-08' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth: Bluetooth: ISO: Fix not using the correct QoS Bluetooth: don't try to cancel uninitialized works at mgmt_index_removed() Bluetooth: ISO: Fix iso_sock_getsockopt for BT_DEFER_SETUP Bluetooth: MGMT: Fixes build warnings with C=1 Bluetooth: hci_event: Fix build warning with C=1 Bluetooth: ISO: Fix memory corruption Bluetooth: Fix null pointer deref on unexpected status event Bluetooth: ISO: Fix info leak in iso_sock_getsockopt() Bluetooth: hci_conn: Fix updating ISO QoS PHY Bluetooth: ISO: unlock on error path in iso_sock_setsockopt() Bluetooth: L2CAP: Fix l2cap_global_chan_by_psm regression ==================== Link: https://lore.kernel.org/r/20220809001224.412807-1-luiz.dentz@gmail.comSigned-off-by:
-
Alexandra Winter authored
Since commit e6e771b3 ("s390/qeth: detach netdevice while card is offline") there was a timing window during recovery, that qeth_query_card_info could be sent to the card, even before it was ready for it, leading to a failing card recovery. There is evidence that this window was hit, as not all callers of get_link_ksettings() check for netif_device_present. Use cached values in qeth_get_link_ksettings(), instead of calling qeth_query_card_info() and falling back to default values in case it fails. Link info is already updated when the card goes online, e.g. after STARTLAN (physical link up). Set the link info to default values, when the card goes offline or at STOPLAN (physical link down). A follow-on patch will improve values reported for link down. Fixes: e6e771b3 ("s390/qeth: detach netdevice while card is offline") Signed-off-by:
Alexandra Winter <wintera@linux.ibm.com> Reviewed-by:
Thorsten Winkler <twinkler@linux.ibm.com> Link: https://lore.kernel.org/r/20220805155714.59609-1-wintera@linux.ibm.comSigned-off-by:
-
Nikita Shubin authored
If CONFIG_NVMEM is not set of_nvmem_cell_get, of_nvmem_device_get functions will return ERR_PTR(-EOPNOTSUPP) and "failed to get nvmem cell io_impedance_ctrl" error would be reported despite "io_impedance_ctrl" is completely missing in Device Tree and we should use default values. Check -EOPNOTSUPP togather with -ENOENT to avoid this situation. Fixes: 5c2d0a6a ("net: phy: dp83867: implement support for io_impedance_ctrl nvmem cell") Signed-off-by:
Nikita Shubin <n.shubin@yadro.com> Acked-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20220805084843.24542-1-nikita.shubin@maquefel.meSigned-off-by:
-
Oleksij Rempel authored
In case master/slave clock role is not specified (which is default), the aneg registers will not be written. The visible impact of this is missing pause advertisement. So, rework genphy_c45_baset1_an_config_aneg() to be able to write advertisement registers even if clock role is unknown. Fixes: 3da8ffd8 ("net: phy: Add 10BASE-T1L support in phy-c45") Signed-off-by:
-
Duoming Zhou authored
There are use-after-free bugs caused by tst_timer. The root cause is that there are no functions to stop tst_timer in idt77252_exit(). One of the possible race conditions is shown below: (thread 1) | (thread 2) | idt77252_init_one | init_card | fill_tst | mod_timer(&card->tst_timer, ...) idt77252_exit | (wait a time) | tst_timer | | ... kfree(card) // FREE | | card->soft_tst[e] // USE The idt77252_dev is deallocated in idt77252_exit() and used in timer handler. This patch adds del_timer_sync() in idt77252_exit() in order that the timer handler could be stopped before the idt77252_dev is deallocated. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:Duoming Zhou <duoming@zju.edu.cn> Link: https://lore.kernel.org/r/20220805070008.18007-1-duoming@zju.edu.cnSigned-off-by:
-
Vladimir Oltean authored
min_gate_len[tc] is supposed to track the shortest interval of continuously open gates for a traffic class. For example, in the following case: TC 76543210 t0 00000001b 200000 ns t1 00000010b 200000 ns min_gate_len[0] and min_gate_len[1] should be 200000, while min_gate_len[2-7] should be 0. However what happens is that min_gate_len[0] is 200000, but min_gate_len[1] ends up being 0 (despite gate_len[1] being 200000 at the point where the logic detects the gate close event for TC 1). The problem is that the code considers a "gate close" event whenever it sees that there is a 0 for that TC (essentially it's level rather than edge triggered). By doing that, any time a gate is seen as closed without having been open prior, gate_len, which is 0, will be written into min_gate_len. Once min_gate_len becomes 0, it's impossible for it to track anything higher than that (the length of actually open intervals). To fix this, we make the writing to min_gate_len[tc] be edge-triggered, which avoids writes for gates that are closed in consecutive intervals. However what this does is it makes us need to special-case the permanently closed gates at the end. Fixes: 55a515b1 ("net: dsa: felix: drop oversized frames with tc-taprio instead of hanging the port") Signed-off-by:
-
Martin Schiller authored
When a userspace application starts a blocking connect(), a CALL REQUEST is sent, the t21 timer is started and the connect is waiting in x25_wait_for_connection_establishment(). If then for some reason the t21 timer expires before any reaction on the assigned logical channel (e.g. CALL ACCEPT, CLEAR REQUEST), there is sent a CLEAR REQUEST and timer t23 is started waiting for a CLEAR confirmation. If we now receive a CLEAR CONFIRMATION from the peer, x25_disconnect() is called in x25_state2_machine() with reason "0", which means "normal" call clearing. This is ok, but the parameter "reason" is used as sk->sk_err in x25_disconnect() and sock_error(sk) is evaluated in x25_wait_for_connection_establishment() to check if the call is still pending. As "0" is not rated as an error, the connect will stuck here forever. To fix this situation, also check if the sk->sk_state changed form TCP_SYN_SENT to TCP_CLOSE in the meantime, which is also done by x25_disconnect(). Signed-off-by:
Martin Schiller <ms@dev.tdt.de> Link: https://lore.kernel.org/r/20220805061810.10824-1-ms@dev.tdt.deSigned-off-by:
-
Jakub Kicinski authored
Gerhard Engleder says: ==================== tsnep: Two fixes for the driver Two simple bugfixes for tsnep driver. ==================== Link: https://lore.kernel.org/r/20220804183935.73763-1-gerhard@engleder-embedded.comSigned-off-by:
-
Gerhard Engleder authored
If tsnep_tx_map() fails, then tsnep_tx_unmap() shall start at the write index like tsnep_tx_map(). This is different to the normal operation. Thus, add an additional parameter to tsnep_tx_unmap() to enable start at different positions for successful TX and failed TX. Fixes: 403f69bb ("tsnep: Add TSN endpoint Ethernet MAC driver") Signed-off-by:
Gerhard Engleder <gerhard@engleder-embedded.com> Signed-off-by:
-
Gerhard Engleder authored
Kernel test robot found the following warning: drivers/net/ethernet/engleder/tsnep_main.c:1254:34: warning: 'tsnep_of_match' defined but not used [-Wunused-const-variable=] of_match_ptr() compiles into NULL if CONFIG_OF is disabled. tsnep_of_match exists always so use of of_match_ptr() is useless. Fix warning by dropping of_match_ptr(). Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
Luiz Augusto von Dentz authored
This fixes using wrong QoS settings when attempting to send frames while acting as peripheral since the QoS settings in use are stored in hconn->iso_qos not in sk->qos, this is actually properly handled on getsockopt(BT_ISO_QOS) but not on iso_send_frame. Fixes: ccf74f23 ("Bluetooth: Add BTPROTO_ISO socket type") Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
