* Re: [RFC PATCH 2/2] net: phylink: don't start and stop SGMII PHYs in SFP modules twice
From: Russell King - ARM Linux admin @ 2019-07-24 9:01 UTC (permalink / raw)
To: Arseny Solokha; +Cc: Claudiu Manoil, Ioana Ciornei, Andrew Lunn, netdev
In-Reply-To: <20190723151702.14430-3-asolokha@kb.kras.ru>
On Tue, Jul 23, 2019 at 10:17:02PM +0700, Arseny Solokha wrote:
> SFP modules connected using the SGMII interface have their own PHYs which
> are handled by the struct phylink's phydev field. After commit ce0aa27ff3f6
> ("sfp: add sfp-bus to bridge between network devices and sfp cages") an
> sfp-bus attached to the same phylink also gets control over a PHY in an SFP
> module which is actually the same PHY managed by phylink itself. This
> results in WARNs during network interface bringup and shutdown when a
> copper SFP module is connected, as phy_start() and phy_stop() are called
> twice in a row for the same phy_device:
>...
> So, skip explicit calls to phy_start() and phy_stop() when phylink has just
> enabled or disabled an attached SFP module.
I'd prefer if we re-ordered these so phy_start() happens before
sfp_upstream_start() and the reverse for the stop calls.
pl->phydev won't be set at these points, so the calls will be no-ops.
(The reason is when we support mac--phy--sfp setups, having the
phy_start() and phy_stop() here are still necessary.)
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* RE: [patch iproute2 1/2] tc: action: fix crash caused by incorrect *argv check
From: David Laight @ 2019-07-24 9:07 UTC (permalink / raw)
To: 'Stephen Hemminger', Jiri Pirko
Cc: netdev@vger.kernel.org, sthemmin@microsoft.com, dsahern@gmail.com,
alexanderk@mellanox.com, mlxsw@mellanox.com
In-Reply-To: <20190723105401.4975396d@hermes.lan>
From: Stephen Hemminger
> Sent: 23 July 2019 18:54
>
> On Tue, 23 Jul 2019 13:25:37 +0200
> Jiri Pirko <jiri@resnulli.us> wrote:
>
> > From: Jiri Pirko <jiri@mellanox.com>
> >
> > One cannot depend on *argv being null in case of no arg is left on the
> > command line. For example in batch mode, this is not always true. Check
> > argc instead to prevent crash.
Hmmm... expecting the increments of argv and decrements of argc to match
it probably wishful thinking....
A lot of parsers don't even look at argc.
> Actually makeargs does NULL terminate the last arg so what input
> to batchmode is breaking this?
The 'usual' problem is an extra increment of argv because the last entry
was something that 'eats' two or more entries.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* [PATCH 4.4 stable net] net: tcp: Fix use-after-free in tcp_write_xmit
From: Mao Wenan @ 2019-07-24 9:17 UTC (permalink / raw)
To: davem, gregkh, netdev, linux-kernel; +Cc: Mao Wenan
There is one report about tcp_write_xmit use-after-free with version 4.4.136:
BUG: KASAN: use-after-free in tcp_skb_pcount include/net/tcp.h:796 [inline]
BUG: KASAN: use-after-free in tcp_init_tso_segs net/ipv4/tcp_output.c:1619 [inline]
BUG: KASAN: use-after-free in tcp_write_xmit+0x3fc2/0x4cb0 net/ipv4/tcp_output.c:2056
Read of size 2 at addr ffff8801d6fc87b0 by task syz-executor408/4195
CPU: 0 PID: 4195 Comm: syz-executor408 Not tainted 4.4.136-gfb7e319 #59
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
0000000000000000 7d8f38ecc03be946 ffff8801d73b7710 ffffffff81e0edad
ffffea00075bf200 ffff8801d6fc87b0 0000000000000000 ffff8801d6fc87b0
dffffc0000000000 ffff8801d73b7748 ffffffff815159b6 ffff8801d6fc87b0
Call Trace:
[<ffffffff81e0edad>] __dump_stack lib/dump_stack.c:15 [inline]
[<ffffffff81e0edad>] dump_stack+0xc1/0x124 lib/dump_stack.c:51
[<ffffffff815159b6>] print_address_description+0x6c/0x216 mm/kasan/report.c:252
[<ffffffff81515cd5>] kasan_report_error mm/kasan/report.c:351 [inline]
[<ffffffff81515cd5>] kasan_report.cold.7+0x175/0x2f7 mm/kasan/report.c:408
[<ffffffff814f9784>] __asan_report_load2_noabort+0x14/0x20 mm/kasan/report.c:427
[<ffffffff83286582>] tcp_skb_pcount include/net/tcp.h:796 [inline]
[<ffffffff83286582>] tcp_init_tso_segs net/ipv4/tcp_output.c:1619 [inline]
[<ffffffff83286582>] tcp_write_xmit+0x3fc2/0x4cb0 net/ipv4/tcp_output.c:2056
[<ffffffff83287a40>] __tcp_push_pending_frames+0xa0/0x290 net/ipv4/tcp_output.c:2307
[<ffffffff8328e966>] tcp_send_fin+0x176/0xab0 net/ipv4/tcp_output.c:2883
[<ffffffff8324c0d0>] tcp_close+0xca0/0xf70 net/ipv4/tcp.c:2112
[<ffffffff832f8d0f>] inet_release+0xff/0x1d0 net/ipv4/af_inet.c:435
[<ffffffff82f1a156>] sock_release+0x96/0x1c0 net/socket.c:586
[<ffffffff82f1a296>] sock_close+0x16/0x20 net/socket.c:1037
[<ffffffff81522da5>] __fput+0x235/0x6f0 fs/file_table.c:208
[<ffffffff815232e5>] ____fput+0x15/0x20 fs/file_table.c:244
[<ffffffff8118bd7f>] task_work_run+0x10f/0x190 kernel/task_work.c:115
[<ffffffff81135285>] exit_task_work include/linux/task_work.h:21 [inline]
[<ffffffff81135285>] do_exit+0x9e5/0x26b0 kernel/exit.c:759
[<ffffffff8113b1d1>] do_group_exit+0x111/0x330 kernel/exit.c:889
[<ffffffff8115e5cc>] get_signal+0x4ec/0x14b0 kernel/signal.c:2321
[<ffffffff8100e02b>] do_signal+0x8b/0x1d30 arch/x86/kernel/signal.c:712
[<ffffffff8100360a>] exit_to_usermode_loop+0x11a/0x160 arch/x86/entry/common.c:248
[<ffffffff81006535>] prepare_exit_to_usermode arch/x86/entry/common.c:283 [inline]
[<ffffffff81006535>] syscall_return_slowpath+0x1b5/0x1f0 arch/x86/entry/common.c:348
[<ffffffff838c29b5>] int_ret_from_sys_call+0x25/0xa3
Allocated by task 4194:
[<ffffffff810341d6>] save_stack_trace+0x26/0x50 arch/x86/kernel/stacktrace.c:63
[<ffffffff814f8873>] save_stack+0x43/0xd0 mm/kasan/kasan.c:512
[<ffffffff814f8b57>] set_track mm/kasan/kasan.c:524 [inline]
[<ffffffff814f8b57>] kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:616
[<ffffffff814f9122>] kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:554
[<ffffffff814f4c1e>] slab_post_alloc_hook mm/slub.c:1349 [inline]
[<ffffffff814f4c1e>] slab_alloc_node mm/slub.c:2615 [inline]
[<ffffffff814f4c1e>] slab_alloc mm/slub.c:2623 [inline]
[<ffffffff814f4c1e>] kmem_cache_alloc+0xbe/0x2a0 mm/slub.c:2628
[<ffffffff82f380a6>] kmem_cache_alloc_node include/linux/slab.h:350 [inline]
[<ffffffff82f380a6>] __alloc_skb+0xe6/0x600 net/core/skbuff.c:218
[<ffffffff832466c3>] alloc_skb_fclone include/linux/skbuff.h:856 [inline]
[<ffffffff832466c3>] sk_stream_alloc_skb+0xa3/0x5d0 net/ipv4/tcp.c:833
[<ffffffff83249164>] tcp_sendmsg+0xd34/0x2b00 net/ipv4/tcp.c:1178
[<ffffffff83300ef3>] inet_sendmsg+0x203/0x4d0 net/ipv4/af_inet.c:755
[<ffffffff82f1e1fc>] sock_sendmsg_nosec net/socket.c:625 [inline]
[<ffffffff82f1e1fc>] sock_sendmsg+0xcc/0x110 net/socket.c:635
[<ffffffff82f1eedc>] SYSC_sendto+0x21c/0x370 net/socket.c:1665
[<ffffffff82f21560>] SyS_sendto+0x40/0x50 net/socket.c:1633
[<ffffffff838c2825>] entry_SYSCALL_64_fastpath+0x22/0x9e
Freed by task 4194:
[<ffffffff810341d6>] save_stack_trace+0x26/0x50 arch/x86/kernel/stacktrace.c:63
[<ffffffff814f8873>] save_stack+0x43/0xd0 mm/kasan/kasan.c:512
[<ffffffff814f91a2>] set_track mm/kasan/kasan.c:524 [inline]
[<ffffffff814f91a2>] kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:589
[<ffffffff814f632e>] slab_free_hook mm/slub.c:1383 [inline]
[<ffffffff814f632e>] slab_free_freelist_hook mm/slub.c:1405 [inline]
[<ffffffff814f632e>] slab_free mm/slub.c:2859 [inline]
[<ffffffff814f632e>] kmem_cache_free+0xbe/0x340 mm/slub.c:2881
[<ffffffff82f3527f>] kfree_skbmem+0xcf/0x100 net/core/skbuff.c:635
[<ffffffff82f372fd>] __kfree_skb+0x1d/0x20 net/core/skbuff.c:676
[<ffffffff83288834>] sk_wmem_free_skb include/net/sock.h:1447 [inline]
[<ffffffff83288834>] tcp_write_queue_purge include/net/tcp.h:1460 [inline]
[<ffffffff83288834>] tcp_connect_init net/ipv4/tcp_output.c:3122 [inline]
[<ffffffff83288834>] tcp_connect+0xb24/0x30c0 net/ipv4/tcp_output.c:3261
[<ffffffff8329b991>] tcp_v4_connect+0xf31/0x1890 net/ipv4/tcp_ipv4.c:246
[<ffffffff832f9ca9>] __inet_stream_connect+0x2a9/0xc30 net/ipv4/af_inet.c:615
[<ffffffff832fa685>] inet_stream_connect+0x55/0xa0 net/ipv4/af_inet.c:676
[<ffffffff82f1eb78>] SYSC_connect+0x1b8/0x300 net/socket.c:1557
[<ffffffff82f214b4>] SyS_connect+0x24/0x30 net/socket.c:1538
[<ffffffff838c2825>] entry_SYSCALL_64_fastpath+0x22/0x9e
Syzkaller reproducer():
r0 = socket$packet(0x11, 0x3, 0x300)
r1 = socket$inet_tcp(0x2, 0x1, 0x0)
bind$inet(r1, &(0x7f0000000300)={0x2, 0x4e21, @multicast1}, 0x10)
connect$inet(r1, &(0x7f0000000140)={0x2, 0x1000004e21, @loopback}, 0x10)
recvmmsg(r1, &(0x7f0000001e40)=[{{0x0, 0x0, &(0x7f0000000100)=[{&(0x7f00000005c0)=""/88, 0x58}], 0x1}}], 0x1, 0x40000000, 0x0)
sendto$inet(r1, &(0x7f0000000000)="e2f7ad5b661c761edf", 0x9, 0x8080, 0x0, 0x0)
r2 = fcntl$dupfd(r1, 0x0, r0)
connect$unix(r2, &(0x7f00000001c0)=@file={0x0, './file0\x00'}, 0x6e)
C repro link: https://syzkaller.appspot.com/text?tag=ReproC&x=14db474f800000
This is because when tcp_connect_init call tcp_write_queue_purge, it will
kfree all the skb in the write_queue, but the sk->sk_send_head forget to set NULL,
then tcp_write_xmit try to send skb, which has freed in tcp_write_queue_purge, UAF happens.
Signed-off-by: Mao Wenan <maowenan@huawei.com>
---
include/net/tcp.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index bf8a0dae977a..8f8aace28cf8 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1457,6 +1457,7 @@ static inline void tcp_write_queue_purge(struct sock *sk)
while ((skb = __skb_dequeue(&sk->sk_write_queue)) != NULL)
sk_wmem_free_skb(sk, skb);
+ sk->sk_send_head = NULL;
sk_mem_reclaim(sk);
tcp_clear_all_retrans_hints(tcp_sk(sk));
inet_csk(sk)->icsk_backoff = 0;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] can: ti_hecc: use timestamp based rx-offloading
From: Jeroen Hofstee @ 2019-07-24 9:13 UTC (permalink / raw)
To: Marc Kleine-Budde, linux-can@vger.kernel.org
Cc: Anant Gole, AnilKumar Ch, Wolfgang Grandegger, David S. Miller,
open list:NETWORKING DRIVERS, open list
In-Reply-To: <5881cb80-883b-a96b-2939-973150cfc196@pengutronix.de>
Hello Marc,
On 7/24/19 10:26 AM, Marc Kleine-Budde wrote:
> On 4/29/19 2:03 PM, Jeroen Hofstee wrote:
>> As already mentioned in [1] and included in [2], there is an off by one
>> issue since the high bank is already enabled when the _next_ mailbox to
>> be read has index 12, so the mailbox being read was 13. The message can
>> therefore go into mailbox 31 and the driver will be repolled until the
>> mailbox 12 eventually receives a msg. Or the message might end up in the
>> 12th mailbox, but then it would become disabled after reading it and only
>> be enabled again in the next "round" after mailbox 13 was read, which can
>> cause out of order messages, since the lower priority mailboxes can
>> accept messages in the meantime.
>>
>> As mentioned in [3] there is a hardware race condition when changing the
>> CANME register while messages are being received. Even when including a
>> busy poll on reception, like in [2] there are still overflows and out of
>> order messages at times, but less then without the busy loop polling.
>> Unlike what the patch suggests, the polling time is not in the microsecond
>> range, but takes as long as a current CAN bus reception needs to finish,
>> so typically more in the fraction of millisecond range. Since the timeout
>> is in jiffies it won't timeout.
>>
>> Even with these additional fixes the driver is still not able to provide a
>> proper FIFO which doesn't drop packages. So change the driver to use
>> rx-offload and base order on timestamp instead of message box numbers. As
>> a side affect, this also fixes [4] and [5].
>>
>> Before this change messages with a single byte counter were dropped /
>> received out of order at a bitrate of 250kbit/s on an am3517. With this
>> patch that no longer occurs up to and including 1Mbit/s.
>>
>> [1] https://linux-can.vger.kernel.narkive.com/zgO9inVi/patch-can-ti-hecc-fix-rx-wrong-sequence-issue#post6
>> [2] http://arago-project.org/git/projects/?p=linux-omap3.git;a=commit;h=02346892777f07245de4d5af692513ebd852dcb2
>> [3] https://linux-can.vger.kernel.narkive.com/zgO9inVi/patch-can-ti-hecc-fix-rx-wrong-sequence-issue#post5
>> [4] https://patchwork.ozlabs.org/patch/895956/
>> [5] https://www.spinics.net/lists/netdev/msg494971.html
>>
>> Cc: Anant Gole <anantgole@ti.com>
>> Cc: AnilKumar Ch <anilkumar@ti.com>
>> Signed-off-by: Jeroen Hofstee <jhofstee@victronenergy.com>
>> ---
>> drivers/net/can/ti_hecc.c | 189 +++++++++++++---------------------------------
>> 1 file changed, 53 insertions(+), 136 deletions(-)
>>
>> diff --git a/drivers/net/can/ti_hecc.c b/drivers/net/can/ti_hecc.c
>> index db6ea93..fe7ffff 100644
>> --- a/drivers/net/can/ti_hecc.c
>> +++ b/drivers/net/can/ti_hecc.c
>> @@ -5,6 +5,7 @@
>> * specs for the same is available at <http://www.ti.com>
>> *
>> * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/
>> + * Copyright (C) 2019 Jeroen Hofstee <jhofstee@victronenergy.com>
>> *
>> * This program is free software; you can redistribute it and/or
>> * modify it under the terms of the GNU General Public License as
>> @@ -34,6 +35,7 @@
>> #include <linux/can/dev.h>
>> #include <linux/can/error.h>
>> #include <linux/can/led.h>
>> +#include <linux/can/rx-offload.h>
>>
>> #define DRV_NAME "ti_hecc"
>> #define HECC_MODULE_VERSION "0.7"
>> @@ -63,29 +65,16 @@ MODULE_VERSION(HECC_MODULE_VERSION);
>> #define HECC_TX_PRIO_MASK (MAX_TX_PRIO << HECC_MB_TX_SHIFT)
>> #define HECC_TX_MB_MASK (HECC_MAX_TX_MBOX - 1)
>> #define HECC_TX_MASK ((HECC_MAX_TX_MBOX - 1) | HECC_TX_PRIO_MASK)
>> -#define HECC_TX_MBOX_MASK (~(BIT(HECC_MAX_TX_MBOX) - 1))
>> -#define HECC_DEF_NAPI_WEIGHT HECC_MAX_RX_MBOX
>>
>> /*
>> - * Important Note: RX mailbox configuration
>> - * RX mailboxes are further logically split into two - main and buffer
>> - * mailboxes. The goal is to get all packets into main mailboxes as
>> - * driven by mailbox number and receive priority (higher to lower) and
>> - * buffer mailboxes are used to receive pkts while main mailboxes are being
>> - * processed. This ensures in-order packet reception.
>> - *
>> - * Here are the recommended values for buffer mailbox. Note that RX mailboxes
>> - * start after TX mailboxes:
>> - *
>> - * HECC_MAX_RX_MBOX HECC_RX_BUFFER_MBOX No of buffer mailboxes
>> - * 28 12 8
>> - * 16 20 4
>> + * RX mailbox configuration
>> + * The remaining mailboxes are used for reception and are delivered based on
>> + * their timestamp, to avoid a hardware race when CANME is changed while
>> + * CAN-bus traffix is being received.
>> */
>>
>> #define HECC_MAX_RX_MBOX (HECC_MAX_MAILBOXES - HECC_MAX_TX_MBOX)
>> -#define HECC_RX_BUFFER_MBOX 12 /* as per table above */
>> #define HECC_RX_FIRST_MBOX (HECC_MAX_MAILBOXES - 1)
>> -#define HECC_RX_HIGH_MBOX_MASK (~(BIT(HECC_RX_BUFFER_MBOX) - 1))
>>
>> /* TI HECC module registers */
>> #define HECC_CANME 0x0 /* Mailbox enable */
>> @@ -123,6 +112,8 @@ MODULE_VERSION(HECC_MODULE_VERSION);
>> #define HECC_CANMDL 0x8
>> #define HECC_CANMDH 0xC
>>
>> +#define HECC_CANMOTS 0x100
> It's actually 0x80
>
>> +
>> #define HECC_SET_REG 0xFFFFFFFF
>> #define HECC_CANID_MASK 0x3FF /* 18 bits mask for extended id's */
>> #define HECC_CCE_WAIT_COUNT 100 /* Wait for ~1 sec for CCE bit */
>> @@ -193,7 +184,7 @@ static const struct can_bittiming_const ti_hecc_bittiming_const = {
>>
>> struct ti_hecc_priv {
>> struct can_priv can; /* MUST be first member/field */
>> - struct napi_struct napi;
>> + struct can_rx_offload offload;
>> struct net_device *ndev;
>> struct clk *clk;
>> void __iomem *base;
>> @@ -203,7 +194,6 @@ struct ti_hecc_priv {
>> spinlock_t mbx_lock; /* CANME register needs protection */
>> u32 tx_head;
>> u32 tx_tail;
>> - u32 rx_next;
>> struct regulator *reg_xceiver;
>> };
>>
>> @@ -265,6 +255,11 @@ static inline u32 hecc_get_bit(struct ti_hecc_priv *priv, int reg, u32 bit_mask)
>> return (hecc_read(priv, reg) & bit_mask) ? 1 : 0;
>> }
>>
>> +static inline u32 hecc_read_stamp(struct ti_hecc_priv *priv, u32 mbxno)
>> +{
>> + return __raw_readl(priv->hecc_ram + 0x80 + 4 * mbxno);
> I've changed this function to use HECC_CANMOTS.
>
That is correct. For completeness the HECC_CANMOTS wasn't
even used in the original patch, so there is no functional difference.
Thanks,
Jeroen
^ permalink raw reply
* Re: [PATCH 4.4 stable net] net: tcp: Fix use-after-free in tcp_write_xmit
From: maowenan @ 2019-07-24 9:15 UTC (permalink / raw)
To: davem, gregkh, netdev, linux-kernel
Cc: stable, Wangkefeng (Maro), weiyongjun (A)
In-Reply-To: <20190724091715.137033-1-maowenan@huawei.com>
Add stable@vger.kernel.org.
On 2019/7/24 17:17, Mao Wenan wrote:
> There is one report about tcp_write_xmit use-after-free with version 4.4.136:
>
> BUG: KASAN: use-after-free in tcp_skb_pcount include/net/tcp.h:796 [inline]
> BUG: KASAN: use-after-free in tcp_init_tso_segs net/ipv4/tcp_output.c:1619 [inline]
> BUG: KASAN: use-after-free in tcp_write_xmit+0x3fc2/0x4cb0 net/ipv4/tcp_output.c:2056
> Read of size 2 at addr ffff8801d6fc87b0 by task syz-executor408/4195
>
> CPU: 0 PID: 4195 Comm: syz-executor408 Not tainted 4.4.136-gfb7e319 #59
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> 0000000000000000 7d8f38ecc03be946 ffff8801d73b7710 ffffffff81e0edad
> ffffea00075bf200 ffff8801d6fc87b0 0000000000000000 ffff8801d6fc87b0
> dffffc0000000000 ffff8801d73b7748 ffffffff815159b6 ffff8801d6fc87b0
> Call Trace:
> [<ffffffff81e0edad>] __dump_stack lib/dump_stack.c:15 [inline]
> [<ffffffff81e0edad>] dump_stack+0xc1/0x124 lib/dump_stack.c:51
> [<ffffffff815159b6>] print_address_description+0x6c/0x216 mm/kasan/report.c:252
> [<ffffffff81515cd5>] kasan_report_error mm/kasan/report.c:351 [inline]
> [<ffffffff81515cd5>] kasan_report.cold.7+0x175/0x2f7 mm/kasan/report.c:408
> [<ffffffff814f9784>] __asan_report_load2_noabort+0x14/0x20 mm/kasan/report.c:427
> [<ffffffff83286582>] tcp_skb_pcount include/net/tcp.h:796 [inline]
> [<ffffffff83286582>] tcp_init_tso_segs net/ipv4/tcp_output.c:1619 [inline]
> [<ffffffff83286582>] tcp_write_xmit+0x3fc2/0x4cb0 net/ipv4/tcp_output.c:2056
> [<ffffffff83287a40>] __tcp_push_pending_frames+0xa0/0x290 net/ipv4/tcp_output.c:2307
> [<ffffffff8328e966>] tcp_send_fin+0x176/0xab0 net/ipv4/tcp_output.c:2883
> [<ffffffff8324c0d0>] tcp_close+0xca0/0xf70 net/ipv4/tcp.c:2112
> [<ffffffff832f8d0f>] inet_release+0xff/0x1d0 net/ipv4/af_inet.c:435
> [<ffffffff82f1a156>] sock_release+0x96/0x1c0 net/socket.c:586
> [<ffffffff82f1a296>] sock_close+0x16/0x20 net/socket.c:1037
> [<ffffffff81522da5>] __fput+0x235/0x6f0 fs/file_table.c:208
> [<ffffffff815232e5>] ____fput+0x15/0x20 fs/file_table.c:244
> [<ffffffff8118bd7f>] task_work_run+0x10f/0x190 kernel/task_work.c:115
> [<ffffffff81135285>] exit_task_work include/linux/task_work.h:21 [inline]
> [<ffffffff81135285>] do_exit+0x9e5/0x26b0 kernel/exit.c:759
> [<ffffffff8113b1d1>] do_group_exit+0x111/0x330 kernel/exit.c:889
> [<ffffffff8115e5cc>] get_signal+0x4ec/0x14b0 kernel/signal.c:2321
> [<ffffffff8100e02b>] do_signal+0x8b/0x1d30 arch/x86/kernel/signal.c:712
> [<ffffffff8100360a>] exit_to_usermode_loop+0x11a/0x160 arch/x86/entry/common.c:248
> [<ffffffff81006535>] prepare_exit_to_usermode arch/x86/entry/common.c:283 [inline]
> [<ffffffff81006535>] syscall_return_slowpath+0x1b5/0x1f0 arch/x86/entry/common.c:348
> [<ffffffff838c29b5>] int_ret_from_sys_call+0x25/0xa3
>
> Allocated by task 4194:
> [<ffffffff810341d6>] save_stack_trace+0x26/0x50 arch/x86/kernel/stacktrace.c:63
> [<ffffffff814f8873>] save_stack+0x43/0xd0 mm/kasan/kasan.c:512
> [<ffffffff814f8b57>] set_track mm/kasan/kasan.c:524 [inline]
> [<ffffffff814f8b57>] kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:616
> [<ffffffff814f9122>] kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:554
> [<ffffffff814f4c1e>] slab_post_alloc_hook mm/slub.c:1349 [inline]
> [<ffffffff814f4c1e>] slab_alloc_node mm/slub.c:2615 [inline]
> [<ffffffff814f4c1e>] slab_alloc mm/slub.c:2623 [inline]
> [<ffffffff814f4c1e>] kmem_cache_alloc+0xbe/0x2a0 mm/slub.c:2628
> [<ffffffff82f380a6>] kmem_cache_alloc_node include/linux/slab.h:350 [inline]
> [<ffffffff82f380a6>] __alloc_skb+0xe6/0x600 net/core/skbuff.c:218
> [<ffffffff832466c3>] alloc_skb_fclone include/linux/skbuff.h:856 [inline]
> [<ffffffff832466c3>] sk_stream_alloc_skb+0xa3/0x5d0 net/ipv4/tcp.c:833
> [<ffffffff83249164>] tcp_sendmsg+0xd34/0x2b00 net/ipv4/tcp.c:1178
> [<ffffffff83300ef3>] inet_sendmsg+0x203/0x4d0 net/ipv4/af_inet.c:755
> [<ffffffff82f1e1fc>] sock_sendmsg_nosec net/socket.c:625 [inline]
> [<ffffffff82f1e1fc>] sock_sendmsg+0xcc/0x110 net/socket.c:635
> [<ffffffff82f1eedc>] SYSC_sendto+0x21c/0x370 net/socket.c:1665
> [<ffffffff82f21560>] SyS_sendto+0x40/0x50 net/socket.c:1633
> [<ffffffff838c2825>] entry_SYSCALL_64_fastpath+0x22/0x9e
>
> Freed by task 4194:
> [<ffffffff810341d6>] save_stack_trace+0x26/0x50 arch/x86/kernel/stacktrace.c:63
> [<ffffffff814f8873>] save_stack+0x43/0xd0 mm/kasan/kasan.c:512
> [<ffffffff814f91a2>] set_track mm/kasan/kasan.c:524 [inline]
> [<ffffffff814f91a2>] kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:589
> [<ffffffff814f632e>] slab_free_hook mm/slub.c:1383 [inline]
> [<ffffffff814f632e>] slab_free_freelist_hook mm/slub.c:1405 [inline]
> [<ffffffff814f632e>] slab_free mm/slub.c:2859 [inline]
> [<ffffffff814f632e>] kmem_cache_free+0xbe/0x340 mm/slub.c:2881
> [<ffffffff82f3527f>] kfree_skbmem+0xcf/0x100 net/core/skbuff.c:635
> [<ffffffff82f372fd>] __kfree_skb+0x1d/0x20 net/core/skbuff.c:676
> [<ffffffff83288834>] sk_wmem_free_skb include/net/sock.h:1447 [inline]
> [<ffffffff83288834>] tcp_write_queue_purge include/net/tcp.h:1460 [inline]
> [<ffffffff83288834>] tcp_connect_init net/ipv4/tcp_output.c:3122 [inline]
> [<ffffffff83288834>] tcp_connect+0xb24/0x30c0 net/ipv4/tcp_output.c:3261
> [<ffffffff8329b991>] tcp_v4_connect+0xf31/0x1890 net/ipv4/tcp_ipv4.c:246
> [<ffffffff832f9ca9>] __inet_stream_connect+0x2a9/0xc30 net/ipv4/af_inet.c:615
> [<ffffffff832fa685>] inet_stream_connect+0x55/0xa0 net/ipv4/af_inet.c:676
> [<ffffffff82f1eb78>] SYSC_connect+0x1b8/0x300 net/socket.c:1557
> [<ffffffff82f214b4>] SyS_connect+0x24/0x30 net/socket.c:1538
> [<ffffffff838c2825>] entry_SYSCALL_64_fastpath+0x22/0x9e
>
> Syzkaller reproducer():
> r0 = socket$packet(0x11, 0x3, 0x300)
> r1 = socket$inet_tcp(0x2, 0x1, 0x0)
> bind$inet(r1, &(0x7f0000000300)={0x2, 0x4e21, @multicast1}, 0x10)
> connect$inet(r1, &(0x7f0000000140)={0x2, 0x1000004e21, @loopback}, 0x10)
> recvmmsg(r1, &(0x7f0000001e40)=[{{0x0, 0x0, &(0x7f0000000100)=[{&(0x7f00000005c0)=""/88, 0x58}], 0x1}}], 0x1, 0x40000000, 0x0)
> sendto$inet(r1, &(0x7f0000000000)="e2f7ad5b661c761edf", 0x9, 0x8080, 0x0, 0x0)
> r2 = fcntl$dupfd(r1, 0x0, r0)
> connect$unix(r2, &(0x7f00000001c0)=@file={0x0, './file0\x00'}, 0x6e)
>
> C repro link: https://syzkaller.appspot.com/text?tag=ReproC&x=14db474f800000
>
> This is because when tcp_connect_init call tcp_write_queue_purge, it will
> kfree all the skb in the write_queue, but the sk->sk_send_head forget to set NULL,
> then tcp_write_xmit try to send skb, which has freed in tcp_write_queue_purge, UAF happens.
>
> Signed-off-by: Mao Wenan <maowenan@huawei.com>
> ---
> include/net/tcp.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index bf8a0dae977a..8f8aace28cf8 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -1457,6 +1457,7 @@ static inline void tcp_write_queue_purge(struct sock *sk)
>
> while ((skb = __skb_dequeue(&sk->sk_write_queue)) != NULL)
> sk_wmem_free_skb(sk, skb);
> + sk->sk_send_head = NULL;
> sk_mem_reclaim(sk);
> tcp_clear_all_retrans_hints(tcp_sk(sk));
> inet_csk(sk)->icsk_backoff = 0;
>
^ permalink raw reply
* Re: pull-request: can-next 2019-07-24
From: Oliver Hartkopp @ 2019-07-24 9:22 UTC (permalink / raw)
To: Marc Kleine-Budde, netdev; +Cc: davem, kernel, linux-can
In-Reply-To: <93540cba-184a-a9c5-f9d2-b1779a69a36f@pengutronix.de>
Hi Marc,
why didn't you include the CAN FD support for the can-gw?
[PATCH 1/2] can: gw: use struct canfd_frame as internal data structure
https://marc.info/?l=linux-can&m=156388681922741&w=2
[PATCH 2/2] can: gw: add support for CAN FD frames
https://marc.info/?l=linux-can&m=156388682022742&w=2
The patches have already been sent in January as RFC and I did extensive
testing since then.
Regards,
Oliver
On 24.07.19 11:00, Marc Kleine-Budde wrote:
> Hello David,
>
> this is a pull request for net-next/master consisting of 26 patches.
>
> The first two patches are by me. One adds missing files of the CAN
> subsystem to the MAINTAINERS file, while the other sorts the
> Makefile/Kconfig of the sja1000 drivers sub directory. In the next patch
> Ji-Ze Hong (Peter Hong) provides a driver for the "Fintek PCIE to 2 CAN"
> controller, based on the the sja1000 IP core.
>
> Gustavo A. R. Silva's patch for the kvaser_usb driver introduces the use
> of struct_size() instead of open coding it. Henning Colliander's patch
> adds a driver for the "Kvaser PCIEcan" devices.
>
> Another patch by Gustavo A. R. Silva marks expected switch fall-throughs
> properly.
>
> Dan Murphy provides 5 patches for the m_can. After cleanups a framework
> is introduced so that the driver can be used from memory mapped IO as
> well as SPI attached devices. Finally he adds a driver for the tcan4x5x
> which uses this framework.
>
> A series of 5 patches by Appana Durga Kedareswara rao for the xilinx_can
> driver, first clean up,then add support for CANFD. Colin Ian King
> contributes another cleanup for the xilinx_can driver.
>
> Robert P. J. Day's patch corrects the brief history of the CAN protocol
> given in the Kconfig menu entry.
>
> 2 patches by Dong Aisheng for the flexcan driver provide PE clock source
> select support and dt-bindings description.
> 2 patches by Sean Nyekjaer for the flexcan driver provide add CAN
> wakeup-source property and dt-bindings description.
>
> Jeroen Hofstee's patch converts the ti_hecc driver to make use of the
> rx-offload helper fixing a number of outstanding bugs.
>
> The first patch of Oliver Hartkopp removes the now obsolete empty
> ioctl() handler for the CAN protocols. The second patch adds SPDX
> license identifiers for CAN subsystem.
>
> regards,
> Marc
>
> ---
>
> The following changes since commit 3e3bb69589e482e0783f28d4cd1d8e56fda0bcbb:
>
> tc-testing: added tdc tests for [b|p]fifo qdisc (2019-07-23 14:08:15 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git tags/linux-can-next-for-5.4-20190724
>
> for you to fetch changes up to fba76a58452694b9b13c07e48839fa84c75f57af:
>
> can: Add SPDX license identifiers for CAN subsystem (2019-07-24 10:31:55 +0200)
>
> ----------------------------------------------------------------
> linux-can-next-for-5.4-20190724
>
> ----------------------------------------------------------------
> Aisheng Dong (1):
> can: flexcan: implement can Runtime PM
>
> Appana Durga Kedareswara rao (5):
> can: xilinx_can: Fix style issues
> can: xilinx_can: Fix kernel doc warnings
> can: xilinx_can: Fix flags field initialization for axi can and canps
> can: xilinx_can: Add cantype parameter in xcan_devtype_data struct
> can: xilinx_can: Add support for CANFD FD frames
>
> Colin Ian King (1):
> can: xilinx_can: clean up indentation issue
>
> Dan Murphy (5):
> can: m_can: Fix checkpatch issues on existing code
> can: m_can: Create a m_can platform framework
> can: m_can: Rename m_can_priv to m_can_classdev
> dt-bindings: can: tcan4x5x: Add DT bindings for TCAN4x5X driver
> can: tcan4x5x: Add tcan4x5x driver to the kernel
>
> Dong Aisheng (2):
> dt-bindings: can: flexcan: add PE clock source property to device tree
> can: flexcan: add support for PE clock source select
>
> Gustavo A. R. Silva (2):
> can: kvaser_usb: Use struct_size() in alloc_candev()
> can: mark expected switch fall-throughs
>
> Henning Colliander (1):
> can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices
>
> Jeroen Hofstee (1):
> can: ti_hecc: use timestamp based rx-offloading
>
> Ji-Ze Hong (Peter Hong) (1):
> can: sja1000: f81601: add Fintek F81601 support
>
> Marc Kleine-Budde (2):
> MAINTAINERS: can: add missing files to CAN NETWORK DRIVERS and CAN NETWORK LAYER
> can: sja1000: Makefile/Kconfig: sort alphabetically
>
> Oliver Hartkopp (2):
> can: remove obsolete empty ioctl() handler
> can: Add SPDX license identifiers for CAN subsystem
>
> Robert P. J. Day (1):
> can: Kconfig: correct history of the CAN protocol
>
> Sean Nyekjaer (2):
> dt-bindings: can: flexcan: add can wakeup property
> can: flexcan: add support for DT property 'wakeup-source'
>
> .../devicetree/bindings/net/can/fsl-flexcan.txt | 10 +
> .../devicetree/bindings/net/can/tcan4x5x.txt | 37 +
> MAINTAINERS | 5 +
> drivers/net/can/Kconfig | 13 +
> drivers/net/can/Makefile | 1 +
> drivers/net/can/at91_can.c | 6 +-
> drivers/net/can/flexcan.c | 136 +-
> drivers/net/can/kvaser_pciefd.c | 1912 ++++++++++++++++++++
> drivers/net/can/m_can/Kconfig | 22 +-
> drivers/net/can/m_can/Makefile | 2 +
> drivers/net/can/m_can/m_can.c | 1079 +++++------
> drivers/net/can/m_can/m_can.h | 110 ++
> drivers/net/can/m_can/m_can_platform.c | 202 +++
> drivers/net/can/m_can/tcan4x5x.c | 532 ++++++
> drivers/net/can/peak_canfd/peak_pciefd_main.c | 2 +-
> drivers/net/can/sja1000/Kconfig | 79 +-
> drivers/net/can/sja1000/Makefile | 11 +-
> drivers/net/can/sja1000/f81601.c | 212 +++
> drivers/net/can/spi/mcp251x.c | 3 +-
> drivers/net/can/ti_hecc.c | 191 +-
> drivers/net/can/usb/kvaser_usb/kvaser_usb_core.c | 3 +-
> drivers/net/can/usb/peak_usb/pcan_usb.c | 2 +-
> drivers/net/can/xilinx_can.c | 293 ++-
> include/linux/can/core.h | 3 +-
> include/linux/can/skb.h | 2 +-
> net/can/Kconfig | 11 +-
> net/can/af_can.c | 10 +-
> net/can/af_can.h | 1 +
> net/can/bcm.c | 3 +-
> net/can/gw.c | 1 +
> net/can/proc.c | 1 +
> net/can/raw.c | 3 +-
> 32 files changed, 4098 insertions(+), 800 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/net/can/tcan4x5x.txt
> create mode 100644 drivers/net/can/kvaser_pciefd.c
> create mode 100644 drivers/net/can/m_can/m_can.h
> create mode 100644 drivers/net/can/m_can/m_can_platform.c
> create mode 100644 drivers/net/can/m_can/tcan4x5x.c
> create mode 100644 drivers/net/can/sja1000/f81601.c
>
^ permalink raw reply
* RE: pull-request: can-next 2019-07-24
From: Stéphane Grosjean @ 2019-07-24 9:24 UTC (permalink / raw)
To: Marc Kleine-Budde, netdev@vger.kernel.org
Cc: kernel@pengutronix.de, linux-can@vger.kernel.org
In-Reply-To: <93540cba-184a-a9c5-f9d2-b1779a69a36f@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 8120 bytes --]
Hello Mark,
I hope you're fine. Did you see the attached patch I've sent earlier this month?
Regards,
— Stéphane
> -----Original Message-----
> From: linux-can-owner@vger.kernel.org <linux-can-
> owner@vger.kernel.org> On Behalf Of Marc Kleine-Budde
> Sent: mercredi 24 juillet 2019 11:00
> To: netdev@vger.kernel.org
> Cc: davem@davemloft.net; kernel@pengutronix.de; linux-
> can@vger.kernel.org
> Subject: pull-request: can-next 2019-07-24
>
> Hello David,
>
> this is a pull request for net-next/master consisting of 26 patches.
>
> The first two patches are by me. One adds missing files of the CAN
> subsystem to the MAINTAINERS file, while the other sorts the
> Makefile/Kconfig of the sja1000 drivers sub directory. In the next patch Ji-Ze
> Hong (Peter Hong) provides a driver for the "Fintek PCIE to 2 CAN"
> controller, based on the the sja1000 IP core.
>
> Gustavo A. R. Silva's patch for the kvaser_usb driver introduces the use of
> struct_size() instead of open coding it. Henning Colliander's patch adds a
> driver for the "Kvaser PCIEcan" devices.
>
> Another patch by Gustavo A. R. Silva marks expected switch fall-throughs
> properly.
>
> Dan Murphy provides 5 patches for the m_can. After cleanups a framework
> is introduced so that the driver can be used from memory mapped IO as well
> as SPI attached devices. Finally he adds a driver for the tcan4x5x which uses
> this framework.
>
> A series of 5 patches by Appana Durga Kedareswara rao for the xilinx_can
> driver, first clean up,then add support for CANFD. Colin Ian King contributes
> another cleanup for the xilinx_can driver.
>
> Robert P. J. Day's patch corrects the brief history of the CAN protocol given in
> the Kconfig menu entry.
>
> 2 patches by Dong Aisheng for the flexcan driver provide PE clock source
> select support and dt-bindings description.
> 2 patches by Sean Nyekjaer for the flexcan driver provide add CAN wakeup-
> source property and dt-bindings description.
>
> Jeroen Hofstee's patch converts the ti_hecc driver to make use of the rx-
> offload helper fixing a number of outstanding bugs.
>
> The first patch of Oliver Hartkopp removes the now obsolete empty
> ioctl() handler for the CAN protocols. The second patch adds SPDX license
> identifiers for CAN subsystem.
>
> regards,
> Marc
>
> ---
>
> The following changes since commit
> 3e3bb69589e482e0783f28d4cd1d8e56fda0bcbb:
>
> tc-testing: added tdc tests for [b|p]fifo qdisc (2019-07-23 14:08:15 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git
> tags/linux-can-next-for-5.4-20190724
>
> for you to fetch changes up to fba76a58452694b9b13c07e48839fa84c75f57af:
>
> can: Add SPDX license identifiers for CAN subsystem (2019-07-24 10:31:55
> +0200)
>
> ----------------------------------------------------------------
> linux-can-next-for-5.4-20190724
>
> ----------------------------------------------------------------
> Aisheng Dong (1):
> can: flexcan: implement can Runtime PM
>
> Appana Durga Kedareswara rao (5):
> can: xilinx_can: Fix style issues
> can: xilinx_can: Fix kernel doc warnings
> can: xilinx_can: Fix flags field initialization for axi can and canps
> can: xilinx_can: Add cantype parameter in xcan_devtype_data struct
> can: xilinx_can: Add support for CANFD FD frames
>
> Colin Ian King (1):
> can: xilinx_can: clean up indentation issue
>
> Dan Murphy (5):
> can: m_can: Fix checkpatch issues on existing code
> can: m_can: Create a m_can platform framework
> can: m_can: Rename m_can_priv to m_can_classdev
> dt-bindings: can: tcan4x5x: Add DT bindings for TCAN4x5X driver
> can: tcan4x5x: Add tcan4x5x driver to the kernel
>
> Dong Aisheng (2):
> dt-bindings: can: flexcan: add PE clock source property to device tree
> can: flexcan: add support for PE clock source select
>
> Gustavo A. R. Silva (2):
> can: kvaser_usb: Use struct_size() in alloc_candev()
> can: mark expected switch fall-throughs
>
> Henning Colliander (1):
> can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices
>
> Jeroen Hofstee (1):
> can: ti_hecc: use timestamp based rx-offloading
>
> Ji-Ze Hong (Peter Hong) (1):
> can: sja1000: f81601: add Fintek F81601 support
>
> Marc Kleine-Budde (2):
> MAINTAINERS: can: add missing files to CAN NETWORK DRIVERS and CAN
> NETWORK LAYER
> can: sja1000: Makefile/Kconfig: sort alphabetically
>
> Oliver Hartkopp (2):
> can: remove obsolete empty ioctl() handler
> can: Add SPDX license identifiers for CAN subsystem
>
> Robert P. J. Day (1):
> can: Kconfig: correct history of the CAN protocol
>
> Sean Nyekjaer (2):
> dt-bindings: can: flexcan: add can wakeup property
> can: flexcan: add support for DT property 'wakeup-source'
>
> .../devicetree/bindings/net/can/fsl-flexcan.txt | 10 +
> .../devicetree/bindings/net/can/tcan4x5x.txt | 37 +
> MAINTAINERS | 5 +
> drivers/net/can/Kconfig | 13 +
> drivers/net/can/Makefile | 1 +
> drivers/net/can/at91_can.c | 6 +-
> drivers/net/can/flexcan.c | 136 +-
> drivers/net/can/kvaser_pciefd.c | 1912 ++++++++++++++++++++
> drivers/net/can/m_can/Kconfig | 22 +-
> drivers/net/can/m_can/Makefile | 2 +
> drivers/net/can/m_can/m_can.c | 1079 +++++------
> drivers/net/can/m_can/m_can.h | 110 ++
> drivers/net/can/m_can/m_can_platform.c | 202 +++
> drivers/net/can/m_can/tcan4x5x.c | 532 ++++++
> drivers/net/can/peak_canfd/peak_pciefd_main.c | 2 +-
> drivers/net/can/sja1000/Kconfig | 79 +-
> drivers/net/can/sja1000/Makefile | 11 +-
> drivers/net/can/sja1000/f81601.c | 212 +++
> drivers/net/can/spi/mcp251x.c | 3 +-
> drivers/net/can/ti_hecc.c | 191 +-
> drivers/net/can/usb/kvaser_usb/kvaser_usb_core.c | 3 +-
> drivers/net/can/usb/peak_usb/pcan_usb.c | 2 +-
> drivers/net/can/xilinx_can.c | 293 ++-
> include/linux/can/core.h | 3 +-
> include/linux/can/skb.h | 2 +-
> net/can/Kconfig | 11 +-
> net/can/af_can.c | 10 +-
> net/can/af_can.h | 1 +
> net/can/bcm.c | 3 +-
> net/can/gw.c | 1 +
> net/can/proc.c | 1 +
> net/can/raw.c | 3 +-
> 32 files changed, 4098 insertions(+), 800 deletions(-) create mode 100644
> Documentation/devicetree/bindings/net/can/tcan4x5x.txt
> create mode 100644 drivers/net/can/kvaser_pciefd.c create mode 100644
> drivers/net/can/m_can/m_can.h create mode 100644
> drivers/net/can/m_can/m_can_platform.c
> create mode 100644 drivers/net/can/m_can/tcan4x5x.c create mode
> 100644 drivers/net/can/sja1000/f81601.c
>
> --
> Pengutronix e.K. | Marc Kleine-Budde |
> Industrial Linux Solutions | Phone: +49-231-2826-924 |
> Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |-
> Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
>
>
>
>
--
PEAK-System Technik GmbH
Sitz der Gesellschaft Darmstadt - HRB 9183
Geschaeftsfuehrung: Alexander Gach / Uwe Wilhelm
Unsere Datenschutzerklaerung mit wichtigen Hinweisen
zur Behandlung personenbezogener Daten finden Sie unter
www.peak-system.com/Datenschutz.483.0.html
[-- Attachment #2: Type: message/rfc822, Size: 5881 bytes --]
From: "Stéphane Grosjean" <s.grosjean@peak-system.com>
To: linux-can Mailing List <linux-can@vger.kernel.org>
Cc: "Stéphane Grosjean" <s.grosjean@peak-system.com>
Subject: [PATCH] can/peak_usb: fix potential double kfree_skb()
Date: Fri, 5 Jul 2019 13:32:16 +0000
Message-ID: <20190705133217.4204-1-s.grosjean@peak-system.com>
When closing the CAN device while tx skbs are inflight, echo skb could be
released twice. By calling close_candev() before unlinking all pending
tx urbs, then the internal echo_skb[] array is fully and correctly cleared
before the USB write callback and, therefore, can_get_echo_skb() are called,
for each aborted URB.
Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com>
---
drivers/net/can/usb/peak_usb/pcan_usb_core.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_core.c b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
index 611f9d31be5d..740ef47eab01 100644
--- a/drivers/net/can/usb/peak_usb/pcan_usb_core.c
+++ b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
@@ -576,16 +576,16 @@ static int peak_usb_ndo_stop(struct net_device *netdev)
dev->state &= ~PCAN_USB_STATE_STARTED;
netif_stop_queue(netdev);
+ close_candev(netdev);
+
+ dev->can.state = CAN_STATE_STOPPED;
+
/* unlink all pending urbs and free used memory */
peak_usb_unlink_all_urbs(dev);
if (dev->adapter->dev_stop)
dev->adapter->dev_stop(dev);
- close_candev(netdev);
-
- dev->can.state = CAN_STATE_STOPPED;
-
/* can set bus off now */
if (dev->adapter->dev_set_bus) {
int err = dev->adapter->dev_set_bus(dev, 0);
--
2.20.1
--
PEAK-System Technik GmbH
Sitz der Gesellschaft Darmstadt - HRB 9183
Geschaeftsfuehrung: Alexander Gach / Uwe Wilhelm
Unsere Datenschutzerklaerung mit wichtigen Hinweisen
zur Behandlung personenbezogener Daten finden Sie unter
www.peak-system.com/Datenschutz.483.0.html
^ permalink raw reply related
* Re: pull-request: can-next 2019-07-24
From: Marc Kleine-Budde @ 2019-07-24 9:26 UTC (permalink / raw)
To: Oliver Hartkopp, netdev; +Cc: davem, kernel, linux-can
In-Reply-To: <3b3a3c9f-41ac-74a0-4238-ba01799accb6@hartkopp.net>
[-- Attachment #1.1: Type: text/plain, Size: 891 bytes --]
On 7/24/19 11:22 AM, Oliver Hartkopp wrote:
> why didn't you include the CAN FD support for the can-gw?
I wanted to have a look at the patches. But the other patches are
already reviewed.
I'll do another pull-request this week.
> [PATCH 1/2] can: gw: use struct canfd_frame as internal data structure
> https://marc.info/?l=linux-can&m=156388681922741&w=2
>
> [PATCH 2/2] can: gw: add support for CAN FD frames
> https://marc.info/?l=linux-can&m=156388682022742&w=2
>
> The patches have already been sent in January as RFC and I did extensive
> testing since then.
Good.
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: pull-request: can-next 2019-07-24
From: Marc Kleine-Budde @ 2019-07-24 9:31 UTC (permalink / raw)
To: Stéphane Grosjean, netdev@vger.kernel.org
Cc: kernel@pengutronix.de, linux-can@vger.kernel.org
In-Reply-To: <AM6PR03MB4006F834B65943E49F485FA6D6C60@AM6PR03MB4006.eurprd03.prod.outlook.com>
[-- Attachment #1.1: Type: text/plain, Size: 685 bytes --]
On 7/24/19 11:24 AM, Stéphane Grosjean wrote:
> I hope you're fine.
Yes, the summer holidays of our $CUSTOMERS gave me a bit more time for CAN.
> Did you see the attached patch I've sent earlier this month?
Yes, it will be included in "linux-can-fixes-for-5.3-20190724".
https://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can.git/log/?h=linux-can-fixes-for-5.3-20190724
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] net: key: af_key: Fix possible null-pointer dereferences in pfkey_send_policy_notify()
From: Jia-Ju Bai @ 2019-07-24 9:35 UTC (permalink / raw)
To: steffen.klassert, herbert, davem; +Cc: netdev, linux-kernel, Jia-Ju Bai
In pfkey_send_policy_notify(), there is an if statement on line 3081 to
check whether xp is NULL:
if (xp && xp->type != XFRM_POLICY_TYPE_MAIN)
When xp is NULL, it is used by key_notify_policy() on line 3090:
key_notify_policy(xp, ...)
pfkey_xfrm_policy2msg_prep(xp) -- line 2211
pfkey_xfrm_policy2msg_size(xp) -- line 2046
for (i=0; i<xp->xfrm_nr; i++) -- line 2026
t = xp->xfrm_vec + i; -- line 2027
key_notify_policy(xp, ...)
xp_net(xp) -- line 2231
return read_pnet(&xp->xp_net); -- line 534
Thus, possible null-pointer dereferences may occur.
To fix these bugs, xp is checked before calling key_notify_policy().
These bugs are found by a static analysis tool STCheck written by us.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
net/key/af_key.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/key/af_key.c b/net/key/af_key.c
index b67ed3a8486c..ced54144d5fd 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -3087,6 +3087,8 @@ static int pfkey_send_policy_notify(struct xfrm_policy *xp, int dir, const struc
case XFRM_MSG_DELPOLICY:
case XFRM_MSG_NEWPOLICY:
case XFRM_MSG_UPDPOLICY:
+ if (!xp)
+ break;
return key_notify_policy(xp, dir, c);
case XFRM_MSG_FLUSHPOLICY:
if (c->data.type != XFRM_POLICY_TYPE_MAIN)
--
2.17.0
^ permalink raw reply related
* [PATCH] net: ceph: Fix a possible null-pointer dereference in ceph_crypto_key_destroy()
From: Jia-Ju Bai @ 2019-07-24 9:43 UTC (permalink / raw)
To: idryomov, jlayton, sage, davem
Cc: ceph-devel, netdev, linux-kernel, Jia-Ju Bai
In set_secret(), key->tfm is assigned to NULL on line 55, and then
ceph_crypto_key_destroy(key) is executed.
ceph_crypto_key_destroy(key)
crypto_free_sync_skcipher(key->tfm)
crypto_skcipher_tfm(tfm)
return &tfm->base;
Thus, a possible null-pointer dereference may occur.
To fix this bug, key->tfm is checked before calling
crypto_free_sync_skcipher().
This bug is found by a static analysis tool STCheck written by us.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
net/ceph/crypto.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/ceph/crypto.c b/net/ceph/crypto.c
index 5d6724cee38f..ac28463bcfd8 100644
--- a/net/ceph/crypto.c
+++ b/net/ceph/crypto.c
@@ -136,7 +136,8 @@ void ceph_crypto_key_destroy(struct ceph_crypto_key *key)
if (key) {
kfree(key->key);
key->key = NULL;
- crypto_free_sync_skcipher(key->tfm);
+ if (key->tfm)
+ crypto_free_sync_skcipher(key->tfm);
key->tfm = NULL;
}
}
--
2.17.0
^ permalink raw reply related
* RE: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool
From: Jose Abreu @ 2019-07-24 9:43 UTC (permalink / raw)
To: Ilias Apalodimas, David Miller
Cc: jonathanh@nvidia.com, robin.murphy@arm.com,
Jose.Abreu@synopsys.com, lists@bofh.nu, Joao.Pinto@synopsys.com,
alexandre.torgue@st.com, maxime.ripard@bootlin.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com, wens@csie.org,
mcoquelin.stm32@gmail.com, linux-tegra@vger.kernel.org,
peppe.cavallaro@st.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190724085427.GA10736@apalos>
From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Date: Jul/24/2019, 09:54:27 (UTC+00:00)
> Hi David,
>
> > From: Jon Hunter <jonathanh@nvidia.com>
> > Date: Tue, 23 Jul 2019 13:09:00 +0100
> >
> > > Setting "iommu.passthrough=1" works for me. However, I am not sure where
> > > to go from here, so any ideas you have would be great.
> >
> > Then definitely we are accessing outside of a valid IOMMU mapping due
> > to the page pool support changes.
>
> Yes. On the netsec driver i did test with and without SMMU to make sure i am not
> breaking anything.
> Since we map the whole page on the API i think some offset on the driver causes
> that. In any case i'll have another look on page_pool to make sure we are not
> missing anything.
Ilias, can it be due to this:
stmmac_main.c:
pp_params.order = DIV_ROUND_UP(priv->dma_buf_sz, PAGE_SIZE);
page_pool.c:
dma = dma_map_page_attrs(pool->p.dev, page, 0,
(PAGE_SIZE << pool->p.order),
pool->p.dma_dir, DMA_ATTR_SKIP_CPU_SYNC);
"order", will be at least 1 and then mapping the page can cause overlap
?
---
Thanks,
Jose Miguel Abreu
^ permalink raw reply
* Re: [PATCH 4.4 stable net] net: tcp: Fix use-after-free in tcp_write_xmit
From: Eric Dumazet @ 2019-07-24 9:45 UTC (permalink / raw)
To: Mao Wenan, davem, gregkh, netdev, linux-kernel
In-Reply-To: <20190724091715.137033-1-maowenan@huawei.com>
On 7/24/19 11:17 AM, Mao Wenan wrote:
> There is one report about tcp_write_xmit use-after-free with version 4.4.136:
>
> BUG: KASAN: use-after-free in tcp_skb_pcount include/net/tcp.h:796 [inline]
> BUG: KASAN: use-after-free in tcp_init_tso_segs net/ipv4/tcp_output.c:1619 [inline]
> BUG: KASAN: use-after-free in tcp_write_xmit+0x3fc2/0x4cb0 net/ipv4/tcp_output.c:2056
> Read of size 2 at addr ffff8801d6fc87b0 by task syz-executor408/4195
>
> CPU: 0 PID: 4195 Comm: syz-executor408 Not tainted 4.4.136-gfb7e319 #59
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> 0000000000000000 7d8f38ecc03be946 ffff8801d73b7710 ffffffff81e0edad
> ffffea00075bf200 ffff8801d6fc87b0 0000000000000000 ffff8801d6fc87b0
> dffffc0000000000 ffff8801d73b7748 ffffffff815159b6 ffff8801d6fc87b0
> Call Trace:
> [<ffffffff81e0edad>] __dump_stack lib/dump_stack.c:15 [inline]
> [<ffffffff81e0edad>] dump_stack+0xc1/0x124 lib/dump_stack.c:51
> [<ffffffff815159b6>] print_address_description+0x6c/0x216 mm/kasan/report.c:252
> [<ffffffff81515cd5>] kasan_report_error mm/kasan/report.c:351 [inline]
> [<ffffffff81515cd5>] kasan_report.cold.7+0x175/0x2f7 mm/kasan/report.c:408
> [<ffffffff814f9784>] __asan_report_load2_noabort+0x14/0x20 mm/kasan/report.c:427
> [<ffffffff83286582>] tcp_skb_pcount include/net/tcp.h:796 [inline]
> [<ffffffff83286582>] tcp_init_tso_segs net/ipv4/tcp_output.c:1619 [inline]
> [<ffffffff83286582>] tcp_write_xmit+0x3fc2/0x4cb0 net/ipv4/tcp_output.c:2056
> [<ffffffff83287a40>] __tcp_push_pending_frames+0xa0/0x290 net/ipv4/tcp_output.c:2307
> [<ffffffff8328e966>] tcp_send_fin+0x176/0xab0 net/ipv4/tcp_output.c:2883
> [<ffffffff8324c0d0>] tcp_close+0xca0/0xf70 net/ipv4/tcp.c:2112
> [<ffffffff832f8d0f>] inet_release+0xff/0x1d0 net/ipv4/af_inet.c:435
> [<ffffffff82f1a156>] sock_release+0x96/0x1c0 net/socket.c:586
> [<ffffffff82f1a296>] sock_close+0x16/0x20 net/socket.c:1037
> [<ffffffff81522da5>] __fput+0x235/0x6f0 fs/file_table.c:208
> [<ffffffff815232e5>] ____fput+0x15/0x20 fs/file_table.c:244
> [<ffffffff8118bd7f>] task_work_run+0x10f/0x190 kernel/task_work.c:115
> [<ffffffff81135285>] exit_task_work include/linux/task_work.h:21 [inline]
> [<ffffffff81135285>] do_exit+0x9e5/0x26b0 kernel/exit.c:759
> [<ffffffff8113b1d1>] do_group_exit+0x111/0x330 kernel/exit.c:889
> [<ffffffff8115e5cc>] get_signal+0x4ec/0x14b0 kernel/signal.c:2321
> [<ffffffff8100e02b>] do_signal+0x8b/0x1d30 arch/x86/kernel/signal.c:712
> [<ffffffff8100360a>] exit_to_usermode_loop+0x11a/0x160 arch/x86/entry/common.c:248
> [<ffffffff81006535>] prepare_exit_to_usermode arch/x86/entry/common.c:283 [inline]
> [<ffffffff81006535>] syscall_return_slowpath+0x1b5/0x1f0 arch/x86/entry/common.c:348
> [<ffffffff838c29b5>] int_ret_from_sys_call+0x25/0xa3
>
> Allocated by task 4194:
> [<ffffffff810341d6>] save_stack_trace+0x26/0x50 arch/x86/kernel/stacktrace.c:63
> [<ffffffff814f8873>] save_stack+0x43/0xd0 mm/kasan/kasan.c:512
> [<ffffffff814f8b57>] set_track mm/kasan/kasan.c:524 [inline]
> [<ffffffff814f8b57>] kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:616
> [<ffffffff814f9122>] kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:554
> [<ffffffff814f4c1e>] slab_post_alloc_hook mm/slub.c:1349 [inline]
> [<ffffffff814f4c1e>] slab_alloc_node mm/slub.c:2615 [inline]
> [<ffffffff814f4c1e>] slab_alloc mm/slub.c:2623 [inline]
> [<ffffffff814f4c1e>] kmem_cache_alloc+0xbe/0x2a0 mm/slub.c:2628
> [<ffffffff82f380a6>] kmem_cache_alloc_node include/linux/slab.h:350 [inline]
> [<ffffffff82f380a6>] __alloc_skb+0xe6/0x600 net/core/skbuff.c:218
> [<ffffffff832466c3>] alloc_skb_fclone include/linux/skbuff.h:856 [inline]
> [<ffffffff832466c3>] sk_stream_alloc_skb+0xa3/0x5d0 net/ipv4/tcp.c:833
> [<ffffffff83249164>] tcp_sendmsg+0xd34/0x2b00 net/ipv4/tcp.c:1178
> [<ffffffff83300ef3>] inet_sendmsg+0x203/0x4d0 net/ipv4/af_inet.c:755
> [<ffffffff82f1e1fc>] sock_sendmsg_nosec net/socket.c:625 [inline]
> [<ffffffff82f1e1fc>] sock_sendmsg+0xcc/0x110 net/socket.c:635
> [<ffffffff82f1eedc>] SYSC_sendto+0x21c/0x370 net/socket.c:1665
> [<ffffffff82f21560>] SyS_sendto+0x40/0x50 net/socket.c:1633
> [<ffffffff838c2825>] entry_SYSCALL_64_fastpath+0x22/0x9e
>
> Freed by task 4194:
> [<ffffffff810341d6>] save_stack_trace+0x26/0x50 arch/x86/kernel/stacktrace.c:63
> [<ffffffff814f8873>] save_stack+0x43/0xd0 mm/kasan/kasan.c:512
> [<ffffffff814f91a2>] set_track mm/kasan/kasan.c:524 [inline]
> [<ffffffff814f91a2>] kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:589
> [<ffffffff814f632e>] slab_free_hook mm/slub.c:1383 [inline]
> [<ffffffff814f632e>] slab_free_freelist_hook mm/slub.c:1405 [inline]
> [<ffffffff814f632e>] slab_free mm/slub.c:2859 [inline]
> [<ffffffff814f632e>] kmem_cache_free+0xbe/0x340 mm/slub.c:2881
> [<ffffffff82f3527f>] kfree_skbmem+0xcf/0x100 net/core/skbuff.c:635
> [<ffffffff82f372fd>] __kfree_skb+0x1d/0x20 net/core/skbuff.c:676
> [<ffffffff83288834>] sk_wmem_free_skb include/net/sock.h:1447 [inline]
> [<ffffffff83288834>] tcp_write_queue_purge include/net/tcp.h:1460 [inline]
> [<ffffffff83288834>] tcp_connect_init net/ipv4/tcp_output.c:3122 [inline]
> [<ffffffff83288834>] tcp_connect+0xb24/0x30c0 net/ipv4/tcp_output.c:3261
> [<ffffffff8329b991>] tcp_v4_connect+0xf31/0x1890 net/ipv4/tcp_ipv4.c:246
> [<ffffffff832f9ca9>] __inet_stream_connect+0x2a9/0xc30 net/ipv4/af_inet.c:615
> [<ffffffff832fa685>] inet_stream_connect+0x55/0xa0 net/ipv4/af_inet.c:676
> [<ffffffff82f1eb78>] SYSC_connect+0x1b8/0x300 net/socket.c:1557
> [<ffffffff82f214b4>] SyS_connect+0x24/0x30 net/socket.c:1538
> [<ffffffff838c2825>] entry_SYSCALL_64_fastpath+0x22/0x9e
>
> Syzkaller reproducer():
> r0 = socket$packet(0x11, 0x3, 0x300)
> r1 = socket$inet_tcp(0x2, 0x1, 0x0)
> bind$inet(r1, &(0x7f0000000300)={0x2, 0x4e21, @multicast1}, 0x10)
> connect$inet(r1, &(0x7f0000000140)={0x2, 0x1000004e21, @loopback}, 0x10)
> recvmmsg(r1, &(0x7f0000001e40)=[{{0x0, 0x0, &(0x7f0000000100)=[{&(0x7f00000005c0)=""/88, 0x58}], 0x1}}], 0x1, 0x40000000, 0x0)
> sendto$inet(r1, &(0x7f0000000000)="e2f7ad5b661c761edf", 0x9, 0x8080, 0x0, 0x0)
> r2 = fcntl$dupfd(r1, 0x0, r0)
> connect$unix(r2, &(0x7f00000001c0)=@file={0x0, './file0\x00'}, 0x6e)
>
> C repro link: https://syzkaller.appspot.com/text?tag=ReproC&x=14db474f800000
>
> This is because when tcp_connect_init call tcp_write_queue_purge, it will
> kfree all the skb in the write_queue, but the sk->sk_send_head forget to set NULL,
> then tcp_write_xmit try to send skb, which has freed in tcp_write_queue_purge, UAF happens.
>
> Signed-off-by: Mao Wenan <maowenan@huawei.com>
> ---
> include/net/tcp.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index bf8a0dae977a..8f8aace28cf8 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -1457,6 +1457,7 @@ static inline void tcp_write_queue_purge(struct sock *sk)
>
> while ((skb = __skb_dequeue(&sk->sk_write_queue)) != NULL)
> sk_wmem_free_skb(sk, skb);
> + sk->sk_send_head = NULL;
> sk_mem_reclaim(sk);
> tcp_clear_all_retrans_hints(tcp_sk(sk));
> inet_csk(sk)->icsk_backoff = 0;
>
This is strange, because tcp_init_send_head() is called from tcp_disconnect()
which is the syzkaller way to trigger this kind of bugs.
I suspect there is another root cause.
^ permalink raw reply
* [PATCH] marvell wireless: cleanup -- make error values consistent
From: Pavel Machek @ 2019-07-24 9:50 UTC (permalink / raw)
To: amitkarwar, nishants, gbhat, huxinming820, kvalo, davem,
linux-wireless, netdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 807 bytes --]
Surrounding code uses -ERRNO as a result, so don't pass plain -1.
Signed-off-by: Pavel Machek <pavel@denx.de>
diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c b/drivers/net/wireless/marvell/mwifiex/scan.c
index 0d6d417..ddf75a5 100644
--- a/drivers/net/wireless/marvell/mwifiex/scan.c
+++ b/drivers/net/wireless/marvell/mwifiex/scan.c
@@ -1243,7 +1243,7 @@ int mwifiex_update_bss_desc_with_ie(struct mwifiex_adapter *adapter,
mwifiex_dbg(adapter, ERROR,
"err: InterpretIE: in processing\t"
"IE, bytes left < IE length\n");
- return -1;
+ return -EINVAL;
}
switch (element_id) {
case WLAN_EID_SSID:
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply related
* Re: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool
From: Ilias Apalodimas @ 2019-07-24 9:53 UTC (permalink / raw)
To: Jose Abreu
Cc: David Miller, jonathanh@nvidia.com, robin.murphy@arm.com,
lists@bofh.nu, Joao.Pinto@synopsys.com, alexandre.torgue@st.com,
maxime.ripard@bootlin.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com, wens@csie.org,
mcoquelin.stm32@gmail.com, linux-tegra@vger.kernel.org,
peppe.cavallaro@st.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <BYAPR12MB3269AA9955844E317B62A239D3C60@BYAPR12MB3269.namprd12.prod.outlook.com>
Jose,
> From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> Date: Jul/24/2019, 09:54:27 (UTC+00:00)
>
> > Hi David,
> >
> > > From: Jon Hunter <jonathanh@nvidia.com>
> > > Date: Tue, 23 Jul 2019 13:09:00 +0100
> > >
> > > > Setting "iommu.passthrough=1" works for me. However, I am not sure where
> > > > to go from here, so any ideas you have would be great.
> > >
> > > Then definitely we are accessing outside of a valid IOMMU mapping due
> > > to the page pool support changes.
> >
> > Yes. On the netsec driver i did test with and without SMMU to make sure i am not
> > breaking anything.
> > Since we map the whole page on the API i think some offset on the driver causes
> > that. In any case i'll have another look on page_pool to make sure we are not
> > missing anything.
>
> Ilias, can it be due to this:
>
> stmmac_main.c:
> pp_params.order = DIV_ROUND_UP(priv->dma_buf_sz, PAGE_SIZE);
>
> page_pool.c:
> dma = dma_map_page_attrs(pool->p.dev, page, 0,
> (PAGE_SIZE << pool->p.order),
> pool->p.dma_dir, DMA_ATTR_SKIP_CPU_SYNC);
>
> "order", will be at least 1 and then mapping the page can cause overlap
> ?
well the API is calling the map with the correct page, page offset (0) and size
right? I don't see any overlapping here. Aren't we mapping what we allocate?
Why do you need higher order pages? Jumbo frames? Can we do a quick test with
the order being 0?
Thanks,
/Ilias
^ permalink raw reply
* RE: [PATCH net-next 1/3] enetc: Add mdio bus driver for the PCIe MDIO endpoint
From: Claudiu Manoil @ 2019-07-24 9:53 UTC (permalink / raw)
To: Andrew Lunn
Cc: David S . Miller, devicetree@vger.kernel.org,
netdev@vger.kernel.org, Alexandru Marginean,
linux-kernel@vger.kernel.org, Leo Li, Rob Herring,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190723222454.GE13517@lunn.ch>
>-----Original Message-----
>From: Andrew Lunn <andrew@lunn.ch>
>Sent: Wednesday, July 24, 2019 1:25 AM
>To: Claudiu Manoil <claudiu.manoil@nxp.com>
>Cc: David S . Miller <davem@davemloft.net>; devicetree@vger.kernel.org;
>netdev@vger.kernel.org; Alexandru Marginean
><alexandru.marginean@nxp.com>; linux-kernel@vger.kernel.org; Leo Li
><leoyang.li@nxp.com>; Rob Herring <robh+dt@kernel.org>; linux-arm-
>kernel@lists.infradead.org
>Subject: Re: [PATCH net-next 1/3] enetc: Add mdio bus driver for the PCIe MDIO
>endpoint
>
>> + bus = mdiobus_alloc_size(sizeof(u32 *));
>> + if (!bus)
>> + return -ENOMEM;
>> +
>
>> + bus->priv = pci_iomap_range(pdev, 0, ENETC_MDIO_REG_OFFSET, 0);
>
>This got me confused for a while. You allocate space for a u32
>pointer. bus->priv will point to this space. However, you are not
>using this space, you {ab}use the pointer to directly hold the return
>from pci_iomap_range(). This works, but sparse is probably unhappy,
>and you are wasting the space the u32 pointer takes.
>
Thanks Andrew,
This is not what I wanted to do, don't ask me how I got to this, it's
confusing indeed.
What's needed here is mdiobus_alloc() or better, devm_mdiobus_alloc().
I've got to do some cleanup in the local mdio bus probing too.
Will send v2.
Thanks,
Claudiu
^ permalink raw reply
* RE: [PATCH net-next 1/3] enetc: Add mdio bus driver for the PCIe MDIO endpoint
From: Claudiu Manoil @ 2019-07-24 9:55 UTC (permalink / raw)
To: Saeed Mahameed, davem@davemloft.net
Cc: linux-arm-kernel@lists.infradead.org, Leo Li,
devicetree@vger.kernel.org, netdev@vger.kernel.org,
Alexandru Marginean, robh+dt@kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <2e3c565cacae6050656aeb7c0132736c60f9f4ee.camel@mellanox.com>
>-----Original Message-----
>From: Saeed Mahameed <saeedm@mellanox.com>
[...]
>
>mdiobus_free(bus) is missing here and in every error path.
>
[...]
>
>this should come last to be symmetrical with probe flow.
>
Will clean these up too. Thanks.
^ permalink raw reply
* Re: [PATCH 4.4 stable net] net: tcp: Fix use-after-free in tcp_write_xmit
From: Eric Dumazet @ 2019-07-24 10:01 UTC (permalink / raw)
To: Mao Wenan, davem, gregkh, netdev, linux-kernel
In-Reply-To: <20190724091715.137033-1-maowenan@huawei.com>
On 7/24/19 11:17 AM, Mao Wenan wrote:
> There is one report about tcp_write_xmit use-after-free with version 4.4.136:
Current stable 4.4 is 4.4.186
Can you check the bug is still there ?
List of patches between 4.4.136 and 4.4.186 (this list is not exhaustive)
46c7b5d6f2a51c355b29118814fbfbdb79c35656 tcp: refine memory limit test in tcp_fragment()
f938ae0ce5ef7b693125b918509b941281afc957 tcp: enforce tcp_min_snd_mss in tcp_mtu_probing()
e757d052f3b8ce739d068a1e890643376c16b7a9 tcp: add tcp_min_snd_mss sysctl
ad472d3a9483abc155e1644ad740cd8c039b5170 tcp: tcp_fragment() should apply sane memory limits
4657ee0fe05e15ab572b157f13a82e080d4b7d73 tcp: limit payload size of sacked skbs
b6d37bba0f7a7492427d7518d4be485dcdd9d5d1 tcp: tcp_grow_window() needs to respect tcp_space()
68337354043a3d5207cd4f055e5a8342ec4eec0f tcp: Ensure DCTCP reacts to losses
7ed7c0386ef2a5cbe58e15af5014c9302d3593eb tcp/dccp: drop SYN packets if accept queue is full
191aa19ab8c1459c11a5c541801f17e01dda17de tcp: handle inet_csk_reqsk_queue_add() failures
a466589807a13da2b7fbb2776e01634b38a4233b tcp: clear icsk_backoff in tcp_write_queue_purge()
122e4a30779336643614fe0f81e1f3fcbd0a371c tcp: tcp_v4_err() should be more careful
ed7748bcf290ad8f80020217d832f458ac9bae7f tcp: fix NULL ref in tail loss probe
eee1af4e268e10fecb76bce42a8d7343aeb2a5e6 tcp: add tcp_ooo_try_coalesce() helper
be288481479ca8c1beba02a7e779ffeaa11f1597 tcp: call tcp_drop() from tcp_data_queue_ofo()
352b66932a23fb11f0a7c316361220648bca3c79 tcp: free batches of packets in tcp_prune_ofo_queue()
e747775172a2d4dc4dae794f248f9687ba793f54 tcp: fix a stale ooo_last_skb after a replace
4666b6e2b27d91e05a5b8459e40e4a05dbc1c7b0 tcp: use an RB tree for ooo receive queue
ec7055c62714326c56dabcf7757069ac7f276bda tcp: increment sk_drops for dropped rx packets
86a0a00794c21b35c72d767a98fb917b5b76b513 tcp: do not restart timewait timer on rst reception
81970da69122fe4bf2af5bb1bb4c7f62d4744e79 tcp: identify cryptic messages as TCP seq # bugs
43707aa8c55fb165a1a56f590e0defb198ebdde9 tcp: remove DELAYED ACK events in DCTCP
42962538cd9fe281a6e8602f22c7b1e218ed812a tcp: Fix missing range_truesize enlargement in the backport
27a0762cb570834dc44155363c118cabdd024c3c tcp: add one more quick ack after after ECN events
cd760ab9f4e13aedccc80f19a0b7863d5c0b3c8c tcp: refactor tcp_ecn_check_ce to remove sk type cast
96b792d199d17545d6a53faf44b9c91d038f1ab3 tcp: do not aggressively quick ack after ECN events
2b30c04bc6f9e7be2d9a5e1b504faa904154c7da tcp: add max_quickacks param to tcp_incr_quickack and tcp_enter_quickack_mode
e2f337e2bd4efe32051a496a7fcdd94ea67c0cfa tcp: do not force quickack when receiving out-of-order packets
dc6ae4dffd656811dee7151b19545e4cd839d378 tcp: detect malicious patterns in tcp_collapse_ofo_queue()
5fbec4801264cb3279ef6ac9c70bcbe2aaef89d5 tcp: avoid collapses in tcp_prune_queue() if possible
255924ea891f647451af3acbc40a3730dcb3255e tcp: do not delay ACK in DCTCP upon CE status change
0b1d40e9e7738e3396ce414b1c62b911c285dfa3 tcp: do not cancel delay-AcK on DCTCP special ACK
17fea38e74ab24afb06970bbd9dc52db11a8034b tcp: helpers to send special DCTCP ack
500e03f463835e74c75890d56d9a7ab63755aa2d tcp: fix dctcp delayed ACK schedule
61c66cc52d42f78bbdd8f2e40b7c0bb9b936a12d tcp: prevent bogus FRTO undos with non-SACK flows
48ffbdea28808354b89447fac2d8524c29ce7ab4 tcp: verify the checksum of the first data segment in a new connection
4dff97920e13af3e92180eefa6b7712d4eac5e58 tcp: do not overshoot window_clamp in tcp_rcv_space_adjust()
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool
From: Robin Murphy @ 2019-07-24 10:03 UTC (permalink / raw)
To: Jon Hunter, Jose Abreu, Lars Persson, Ilias Apalodimas
Cc: Joao Pinto, Alexandre Torgue, Maxime Ripard,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com, Chen-Yu Tsai,
Maxime Coquelin, linux-tegra, Giuseppe Cavallaro,
David S . Miller, linux-arm-kernel@lists.infradead.org
In-Reply-To: <ae11deb4-abec-f0f9-312d-b11d72bc74cd@nvidia.com>
On 23/07/2019 22:39, Jon Hunter wrote:
>
> On 23/07/2019 14:19, Robin Murphy wrote:
>
> ...
>
>>>> Do you know if the SMMU interrupts are working correctly? If not, it's
>>>> possible that an incorrect address or mapping direction could lead to
>>>> the DMA transaction just being silently terminated without any fault
>>>> indication, which generally presents as inexplicable weirdness (I've
>>>> certainly seen that on another platform with the mix of an unsupported
>>>> interrupt controller and an 'imperfect' ethernet driver).
>>>
>>> If I simply remove the iommu node for the ethernet controller, then I
>>> see lots of ...
>>>
>>> [ 6.296121] arm-smmu 12000000.iommu: Unexpected global fault, this
>>> could be serious
>>> [ 6.296125] arm-smmu 12000000.iommu: GFSR 0x00000002,
>>> GFSYNR0 0x00000000, GFSYNR1 0x00000014, GFSYNR2 0x00000000
>>>
>>> So I assume that this is triggering the SMMU interrupt correctly.
>>
>> According to tegra186.dtsi it appears you're using the MMU-500 combined
>> interrupt, so if global faults are being delivered then context faults
>> *should* also, but I'd be inclined to try a quick hack of the relevant
>> stmmac_desc_ops::set_addr callback to write some bogus unmapped address
>> just to make sure arm_smmu_context_fault() then screams as expected, and
>> we're not missing anything else.
>
> I hacked the driver and forced the address to zero for a test and
> in doing so I see ...
>
> [ 10.440072] arm-smmu 12000000.iommu: Unhandled context fault: fsr=0x402, iova=0x00000000, fsynr=0x1c0011, cbfrsynra=0x14, cb=0
>
> So looks like the interrupts are working AFAICT.
OK, that's good, thanks for confirming. Unfortunately that now leaves us
with the challenge of figuring out how things are managing to go wrong
*without* ever faulting... :)
I wonder if we can provoke the failure on non-IOMMU platforms with
"swiotlb=force" - I have a few boxes I could potentially test that on,
but sadly forgot my plan to bring one with me this morning.
Robin.
^ permalink raw reply
* RE: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool
From: Jose Abreu @ 2019-07-24 10:04 UTC (permalink / raw)
To: Ilias Apalodimas, Jose Abreu
Cc: David Miller, jonathanh@nvidia.com, robin.murphy@arm.com,
lists@bofh.nu, Joao.Pinto@synopsys.com, alexandre.torgue@st.com,
maxime.ripard@bootlin.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com, wens@csie.org,
mcoquelin.stm32@gmail.com, linux-tegra@vger.kernel.org,
peppe.cavallaro@st.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190724095310.GA12991@apalos>
From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Date: Jul/24/2019, 10:53:10 (UTC+00:00)
> Jose,
> > From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> > Date: Jul/24/2019, 09:54:27 (UTC+00:00)
> >
> > > Hi David,
> > >
> > > > From: Jon Hunter <jonathanh@nvidia.com>
> > > > Date: Tue, 23 Jul 2019 13:09:00 +0100
> > > >
> > > > > Setting "iommu.passthrough=1" works for me. However, I am not sure where
> > > > > to go from here, so any ideas you have would be great.
> > > >
> > > > Then definitely we are accessing outside of a valid IOMMU mapping due
> > > > to the page pool support changes.
> > >
> > > Yes. On the netsec driver i did test with and without SMMU to make sure i am not
> > > breaking anything.
> > > Since we map the whole page on the API i think some offset on the driver causes
> > > that. In any case i'll have another look on page_pool to make sure we are not
> > > missing anything.
> >
> > Ilias, can it be due to this:
> >
> > stmmac_main.c:
> > pp_params.order = DIV_ROUND_UP(priv->dma_buf_sz, PAGE_SIZE);
> >
> > page_pool.c:
> > dma = dma_map_page_attrs(pool->p.dev, page, 0,
> > (PAGE_SIZE << pool->p.order),
> > pool->p.dma_dir, DMA_ATTR_SKIP_CPU_SYNC);
> >
> > "order", will be at least 1 and then mapping the page can cause overlap
> > ?
>
> well the API is calling the map with the correct page, page offset (0) and size
> right? I don't see any overlapping here. Aren't we mapping what we allocate?
>
> Why do you need higher order pages? Jumbo frames? Can we do a quick test with
> the order being 0?
Yes, it's for Jumbo frames that can be as large as 16k.
From Jon logs it can be seen that buffers are 8k but frames are 1500 max
so it is using order = 1.
Jon, I was able to replicate (at some level) your setup:
# dmesg | grep -i arm-smmu
[ 1.337322] arm-smmu 70040000.iommu: probing hardware
configuration...
[ 1.337330] arm-smmu 70040000.iommu: SMMUv2 with:
[ 1.337338] arm-smmu 70040000.iommu: stage 1 translation
[ 1.337346] arm-smmu 70040000.iommu: stage 2 translation
[ 1.337354] arm-smmu 70040000.iommu: nested translation
[ 1.337363] arm-smmu 70040000.iommu: stream matching with 128
register groups
[ 1.337374] arm-smmu 70040000.iommu: 1 context banks (0
stage-2 only)
[ 1.337383] arm-smmu 70040000.iommu: Supported page sizes:
0x61311000
[ 1.337393] arm-smmu 70040000.iommu: Stage-1: 48-bit VA ->
48-bit IPA
[ 1.337402] arm-smmu 70040000.iommu: Stage-2: 48-bit IPA ->
48-bit PA
# dmesg | grep -i stmmac
[ 1.344106] stmmaceth 70000000.ethernet: Adding to iommu group 0
[ 1.344233] stmmaceth 70000000.ethernet: no reset control found
[ 1.348276] stmmaceth 70000000.ethernet: User ID: 0x10, Synopsys ID:
0x51
[ 1.348285] stmmaceth 70000000.ethernet: DWMAC4/5
[ 1.348293] stmmaceth 70000000.ethernet: DMA HW capability register
supported
[ 1.348302] stmmaceth 70000000.ethernet: RX Checksum Offload Engine
supported
[ 1.348311] stmmaceth 70000000.ethernet: TX Checksum insertion
supported
[ 1.348320] stmmaceth 70000000.ethernet: TSO supported
[ 1.348328] stmmaceth 70000000.ethernet: Enable RX Mitigation via HW
Watchdog Timer
[ 1.348337] stmmaceth 70000000.ethernet: TSO feature enabled
[ 1.348409] libphy: stmmac: probed
[ 4159.140990] stmmaceth 70000000.ethernet eth0: PHY [stmmac-0:01]
driver [Generic PHY]
[ 4159.141005] stmmaceth 70000000.ethernet eth0: phy: setting supported
00,00000000,000062ff advertising 00,00000000,000062ff
[ 4159.142359] stmmaceth 70000000.ethernet eth0: No Safety Features
support found
[ 4159.142369] stmmaceth 70000000.ethernet eth0: IEEE 1588-2008 Advanced
Timestamp supported
[ 4159.142429] stmmaceth 70000000.ethernet eth0: registered PTP clock
[ 4159.142439] stmmaceth 70000000.ethernet eth0: configuring for
phy/gmii link mode
[ 4159.142452] stmmaceth 70000000.ethernet eth0: phylink_mac_config:
mode=phy/gmii/Unknown/Unknown adv=00,00000000,000062ff pause=10 link=0
an=1
[ 4159.142466] stmmaceth 70000000.ethernet eth0: phy link up
gmii/1Gbps/Full
[ 4159.142475] stmmaceth 70000000.ethernet eth0: phylink_mac_config:
mode=phy/gmii/1Gbps/Full adv=00,00000000,00000000 pause=0f link=1 an=0
[ 4159.142481] stmmaceth 70000000.ethernet eth0: Link is Up - 1Gbps/Full
- flow control rx/tx
The only missing point is the NFS boot that I can't replicate with this
setup. But I did some sanity checks:
Remote Enpoint:
# dd if=/dev/urandom of=output.dat bs=128M count=1
# nc -c 192.168.0.2 1234 < output.dat
# md5sum output.dat
fde9e0818281836e4fc0edfede2b8762 output.dat
DUT:
# nc -l -c -p 1234 > output.dat
# md5sum output.dat
fde9e0818281836e4fc0edfede2b8762 output.dat
---
Thanks,
Jose Miguel Abreu
^ permalink raw reply
* [PATCH] net/ipv4: cleanup error condition testing
From: Pavel Machek @ 2019-07-24 10:06 UTC (permalink / raw)
To: davem, kuznet, yoshfuji, netdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 761 bytes --]
Cleanup testing for error condition.
Signed-off-by: Pavel Machek <pavel@denx.de>
diff --git a/net/ipv4/inet_fragment.c b/net/ipv4/inet_fragment.c
index d666756..a999451 100644
--- a/net/ipv4/inet_fragment.c
+++ b/net/ipv4/inet_fragment.c
@@ -331,7 +331,7 @@ struct inet_frag_queue *inet_frag_find(struct fqdir *fqdir, void *key)
prev = rhashtable_lookup(&fqdir->rhashtable, key, fqdir->f->rhash_params);
if (!prev)
fq = inet_frag_create(fqdir, key, &prev);
- if (prev && !IS_ERR(prev)) {
+ if (!IS_ERR_OR_NULL(prev)) {
fq = prev;
if (!refcount_inc_not_zero(&fq->refcnt))
fq = NULL;
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply related
* Re: [PATCH 4.4 stable net] net: tcp: Fix use-after-free in tcp_write_xmit
From: Eric Dumazet @ 2019-07-24 10:13 UTC (permalink / raw)
To: Mao Wenan, davem, gregkh, netdev, linux-kernel
In-Reply-To: <badce2b6-b75e-db01-39c8-d68a0161c101@gmail.com>
On 7/24/19 12:01 PM, Eric Dumazet wrote:
>
>
> On 7/24/19 11:17 AM, Mao Wenan wrote:
>> There is one report about tcp_write_xmit use-after-free with version 4.4.136:
>
> Current stable 4.4 is 4.4.186
>
> Can you check the bug is still there ?
>
BTW, I tried the C repro and another bug showed up.
It looks like 4.4.186 misses other fixes :/
[ 180.811610] skbuff: skb_under_panic: text:ffffffff825ec6ea len:156 put:84 head:ffff8837dd1f0990 data:ffff8837dd1f098c tail:0x98 end:0xc0 dev:ip6gre0
[ 180.825037] ------------[ cut here ]------------
[ 180.829688] kernel BUG at net/core/skbuff.c:104!
[ 180.834316] invalid opcode: 0000 [#1] SMP KASAN
[ 180.839305] gsmi: Log Shutdown Reason 0x03
[ 180.843426] Modules linked in: ipip bonding bridge stp llc tun veth w1_therm wire i2c_mux_pca954x i2c_mux cdc_acm ehci_pci ehci_hcd ip_gre mlx4_en ib_uverbs mlx4_ib ib_sa ib_mad ib_core ib_addr mlx4_core
[ 180.862052] CPU: 22 PID: 1619 Comm: kworker/22:1 Not tainted 4.4.186-smp-DEV #41
[ 180.869475] Hardware name: Intel BIOS 2.56.0 10/19/2018
[ 180.876463] Workqueue: ipv6_addrconf addrconf_dad_work
[ 180.881658] task: ffff8837f1f59d80 ti: ffff8837eeeb8000 task.ti: ffff8837eeeb8000
[ 180.889171] RIP: 0010:[<ffffffff821ef26f>] [<ffffffff821ef26f>] skb_panic+0x14f/0x210
[ 180.897162] RSP: 0018:ffff8837eeebf4b8 EFLAGS: 00010282
[ 180.902504] RAX: 0000000000000088 RBX: ffff8837eeeeb600 RCX: 0000000000000000
[ 180.909645] RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffffffff83508c00
[ 180.916854] RBP: ffff8837eeebf520 R08: 0000000000000016 R09: 0000000000000000
[ 180.924029] R10: ffff881fc8abf038 R11: 0000000000000007 R12: ffff881fc8abe720
[ 180.931213] R13: ffffffff82aa9e80 R14: 00000000000000c0 R15: 0000000000000098
[ 180.938390] FS: 0000000000000000(0000) GS:ffff8837ff280000(0000) knlGS:0000000000000000
[ 180.946519] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 180.952290] CR2: 00007f519426f530 CR3: 00000037d37f2000 CR4: 0000000000160670
[ 180.959447] Stack:
[ 180.961458] ffff8837dd1f098c 0000000000000098 00000000000000c0 ffff881fc8abe720
[ 180.968909] ffffea00df747c00 ffff881fff404b40 ffff8837ff2a1a20 ffff8837eeebf5b8
[ 180.976371] ffff8837eeeeb600 ffffffff825ec6ea 1ffff106fddd7eb6 ffff8837eeeeb600
[ 180.983848] Call Trace:
[ 180.986297] [<ffffffff825ec6ea>] ? ip6gre_header+0xba/0xd50
[ 180.991962] [<ffffffff821f0e01>] skb_push+0xc1/0x100
[ 180.997023] [<ffffffff825ec6ea>] ip6gre_header+0xba/0xd50
[ 181.002519] [<ffffffff8158dc16>] ? memcpy+0x36/0x40
[ 181.007509] [<ffffffff825ec630>] ? ip6gre_changelink+0x6d0/0x6d0
[ 181.013629] [<ffffffff82550741>] ? ndisc_constructor+0x5b1/0x770
[ 181.019728] [<ffffffff82666861>] ? _raw_write_unlock_bh+0x41/0x50
[ 181.025924] [<ffffffff8226540b>] ? __neigh_create+0xe6b/0x1670
[ 181.031851] [<ffffffff8225817f>] neigh_connected_output+0x23f/0x480
[ 181.038219] [<ffffffff824f61ec>] ip6_finish_output2+0x74c/0x1a90
[ 181.044324] [<ffffffff810f1d33>] ? print_context_stack+0x73/0xf0
[ 181.050429] [<ffffffff824f5aa0>] ? ip6_xmit+0x1700/0x1700
[ 181.055933] [<ffffffff82304a28>] ? nf_hook_slow+0x118/0x1b0
[ 181.061617] [<ffffffff82502d7a>] ip6_finish_output+0x2ba/0x580
[ 181.067546] [<ffffffff82503179>] ip6_output+0x139/0x380
[ 181.072884] [<ffffffff82503040>] ? ip6_finish_output+0x580/0x580
[ 181.079004] [<ffffffff82502ac0>] ? ip6_fragment+0x31b0/0x31b0
[ 181.084852] [<ffffffff82251b51>] ? dst_init+0x4b1/0x820
[ 181.090172] [<ffffffff8158da45>] ? kasan_unpoison_shadow+0x35/0x50
[ 181.096437] [<ffffffff8158da45>] ? kasan_unpoison_shadow+0x35/0x50
[ 181.102712] [<ffffffff8254f3ca>] NF_HOOK_THRESH.constprop.22+0xca/0x180
[ 181.109421] [<ffffffff8254f300>] ? ndisc_alloc_skb+0x340/0x340
[ 181.115338] [<ffffffff8254d820>] ? compat_ipv6_setsockopt+0x180/0x180
[ 181.121874] [<ffffffff8254fbc2>] ndisc_send_skb+0x742/0xd10
[ 181.127550] [<ffffffff8254f480>] ? NF_HOOK_THRESH.constprop.22+0x180/0x180
[ 181.134516] [<ffffffff821f2440>] ? skb_complete_tx_timestamp+0x280/0x280
[ 181.141311] [<ffffffff8254e2b3>] ? ndisc_fill_addr_option+0x193/0x260
[ 181.147844] [<ffffffff82553bd9>] ndisc_send_rs+0x179/0x2d0
[ 181.153426] [<ffffffff8251e7df>] addrconf_dad_completed+0x41f/0x7c0
[ 181.159795] [<ffffffff81297f78>] ? pick_next_entity+0x198/0x470
[ 181.165807] [<ffffffff8251e3c0>] ? addrconf_rs_timer+0x4a0/0x4a0
[ 181.171918] [<ffffffff81aab928>] ? find_next_bit+0x18/0x20
[ 181.177504] [<ffffffff81a99ec9>] ? prandom_seed+0xd9/0x160
[ 181.183095] [<ffffffff8251eef5>] addrconf_dad_work+0x375/0x9e0
[ 181.189024] [<ffffffff8251eb80>] ? addrconf_dad_completed+0x7c0/0x7c0
[ 181.195576] [<ffffffff81249d8f>] process_one_work+0x52f/0xf60
[ 181.201468] [<ffffffff8124a89d>] worker_thread+0xdd/0xe80
[ 181.206977] [<ffffffff8265cf0a>] ? __schedule+0x73a/0x16d0
[ 181.212550] [<ffffffff8124a7c0>] ? process_one_work+0xf60/0xf60
[ 181.218572] [<ffffffff8125a115>] kthread+0x205/0x2b0
[ 181.223633] [<ffffffff81259f10>] ? kthread_worker_fn+0x4e0/0x4e0
[ 181.229743] [<ffffffff81259f10>] ? kthread_worker_fn+0x4e0/0x4e0
[ 181.235834] [<ffffffff8266726f>] ret_from_fork+0x3f/0x70
[ 181.241232] [<ffffffff81259f10>] ? kthread_worker_fn+0x4e0/0x4e0
^ permalink raw reply
* Re: [PATCH] net: dsa: sja1105: sja1105_main: Add of_node_put()
From: Vladimir Oltean @ 2019-07-24 10:17 UTC (permalink / raw)
To: David Miller
Cc: nishkadg.linux, Andrew Lunn, Vivien Didelot, Florian Fainelli,
netdev, lkml
In-Reply-To: <20190723.133856.860402214064308020.davem@davemloft.net>
On Tue, 23 Jul 2019 at 23:38, David Miller <davem@davemloft.net> wrote:
>
> From: Nishka Dasgupta <nishkadg.linux@gmail.com>
> Date: Tue, 23 Jul 2019 16:14:48 +0530
>
> > Each iteration of for_each_child_of_node puts the previous node, but in
> > the case of a return from the middle of the loop, there is no put, thus
> > causing a memory leak. Hence add an of_node_put before the return.
> > Issue found with Coccinelle.
> >
> > Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
>
> Applied.
>
> Again, the semantics of these looping constructs are terrible.
Strange.
Thanks for the fix.
-Vladimir
^ permalink raw reply
* Re: [PATCH 4.4 stable net] net: tcp: Fix use-after-free in tcp_write_xmit
From: maowenan @ 2019-07-24 10:36 UTC (permalink / raw)
To: Eric Dumazet, davem, gregkh, netdev, linux-kernel
In-Reply-To: <badce2b6-b75e-db01-39c8-d68a0161c101@gmail.com>
Actually, I have tested 4.4.184, UAF still happen.
On 2019/7/24 18:01, Eric Dumazet wrote:
>
>
> On 7/24/19 11:17 AM, Mao Wenan wrote:
>> There is one report about tcp_write_xmit use-after-free with version 4.4.136:
>
> Current stable 4.4 is 4.4.186
>
> Can you check the bug is still there ?
>
> List of patches between 4.4.136 and 4.4.186 (this list is not exhaustive)
>
> 46c7b5d6f2a51c355b29118814fbfbdb79c35656 tcp: refine memory limit test in tcp_fragment()
> f938ae0ce5ef7b693125b918509b941281afc957 tcp: enforce tcp_min_snd_mss in tcp_mtu_probing()
> e757d052f3b8ce739d068a1e890643376c16b7a9 tcp: add tcp_min_snd_mss sysctl
> ad472d3a9483abc155e1644ad740cd8c039b5170 tcp: tcp_fragment() should apply sane memory limits
> 4657ee0fe05e15ab572b157f13a82e080d4b7d73 tcp: limit payload size of sacked skbs
> b6d37bba0f7a7492427d7518d4be485dcdd9d5d1 tcp: tcp_grow_window() needs to respect tcp_space()
> 68337354043a3d5207cd4f055e5a8342ec4eec0f tcp: Ensure DCTCP reacts to losses
> 7ed7c0386ef2a5cbe58e15af5014c9302d3593eb tcp/dccp: drop SYN packets if accept queue is full
> 191aa19ab8c1459c11a5c541801f17e01dda17de tcp: handle inet_csk_reqsk_queue_add() failures
> a466589807a13da2b7fbb2776e01634b38a4233b tcp: clear icsk_backoff in tcp_write_queue_purge()
> 122e4a30779336643614fe0f81e1f3fcbd0a371c tcp: tcp_v4_err() should be more careful
> ed7748bcf290ad8f80020217d832f458ac9bae7f tcp: fix NULL ref in tail loss probe
> eee1af4e268e10fecb76bce42a8d7343aeb2a5e6 tcp: add tcp_ooo_try_coalesce() helper
> be288481479ca8c1beba02a7e779ffeaa11f1597 tcp: call tcp_drop() from tcp_data_queue_ofo()
> 352b66932a23fb11f0a7c316361220648bca3c79 tcp: free batches of packets in tcp_prune_ofo_queue()
> e747775172a2d4dc4dae794f248f9687ba793f54 tcp: fix a stale ooo_last_skb after a replace
> 4666b6e2b27d91e05a5b8459e40e4a05dbc1c7b0 tcp: use an RB tree for ooo receive queue
> ec7055c62714326c56dabcf7757069ac7f276bda tcp: increment sk_drops for dropped rx packets
> 86a0a00794c21b35c72d767a98fb917b5b76b513 tcp: do not restart timewait timer on rst reception
> 81970da69122fe4bf2af5bb1bb4c7f62d4744e79 tcp: identify cryptic messages as TCP seq # bugs
> 43707aa8c55fb165a1a56f590e0defb198ebdde9 tcp: remove DELAYED ACK events in DCTCP
> 42962538cd9fe281a6e8602f22c7b1e218ed812a tcp: Fix missing range_truesize enlargement in the backport
> 27a0762cb570834dc44155363c118cabdd024c3c tcp: add one more quick ack after after ECN events
> cd760ab9f4e13aedccc80f19a0b7863d5c0b3c8c tcp: refactor tcp_ecn_check_ce to remove sk type cast
> 96b792d199d17545d6a53faf44b9c91d038f1ab3 tcp: do not aggressively quick ack after ECN events
> 2b30c04bc6f9e7be2d9a5e1b504faa904154c7da tcp: add max_quickacks param to tcp_incr_quickack and tcp_enter_quickack_mode
> e2f337e2bd4efe32051a496a7fcdd94ea67c0cfa tcp: do not force quickack when receiving out-of-order packets
> dc6ae4dffd656811dee7151b19545e4cd839d378 tcp: detect malicious patterns in tcp_collapse_ofo_queue()
> 5fbec4801264cb3279ef6ac9c70bcbe2aaef89d5 tcp: avoid collapses in tcp_prune_queue() if possible
> 255924ea891f647451af3acbc40a3730dcb3255e tcp: do not delay ACK in DCTCP upon CE status change
> 0b1d40e9e7738e3396ce414b1c62b911c285dfa3 tcp: do not cancel delay-AcK on DCTCP special ACK
> 17fea38e74ab24afb06970bbd9dc52db11a8034b tcp: helpers to send special DCTCP ack
> 500e03f463835e74c75890d56d9a7ab63755aa2d tcp: fix dctcp delayed ACK schedule
> 61c66cc52d42f78bbdd8f2e40b7c0bb9b936a12d tcp: prevent bogus FRTO undos with non-SACK flows
> 48ffbdea28808354b89447fac2d8524c29ce7ab4 tcp: verify the checksum of the first data segment in a new connection
> 4dff97920e13af3e92180eefa6b7712d4eac5e58 tcp: do not overshoot window_clamp in tcp_rcv_space_adjust()
>
>
> .
>
^ permalink raw reply
* Re: [PATCH 4.4 stable net] net: tcp: Fix use-after-free in tcp_write_xmit
From: maowenan @ 2019-07-24 10:38 UTC (permalink / raw)
To: Eric Dumazet, davem, gregkh, netdev, linux-kernel
In-Reply-To: <be1aebb5-fee7-e079-d864-a2e4aa13007f@gmail.com>
On 2019/7/24 18:13, Eric Dumazet wrote:
>
>
> On 7/24/19 12:01 PM, Eric Dumazet wrote:
>>
>>
>> On 7/24/19 11:17 AM, Mao Wenan wrote:
>>> There is one report about tcp_write_xmit use-after-free with version 4.4.136:
>>
>> Current stable 4.4 is 4.4.186
>>
>> Can you check the bug is still there ?
>>
>
> BTW, I tried the C repro and another bug showed up.
>
> It looks like 4.4.186 misses other fixes :/
I will try 4.4.186.
>
> [ 180.811610] skbuff: skb_under_panic: text:ffffffff825ec6ea len:156 put:84 head:ffff8837dd1f0990 data:ffff8837dd1f098c tail:0x98 end:0xc0 dev:ip6gre0
> [ 180.825037] ------------[ cut here ]------------
> [ 180.829688] kernel BUG at net/core/skbuff.c:104!
> [ 180.834316] invalid opcode: 0000 [#1] SMP KASAN
> [ 180.839305] gsmi: Log Shutdown Reason 0x03
> [ 180.843426] Modules linked in: ipip bonding bridge stp llc tun veth w1_therm wire i2c_mux_pca954x i2c_mux cdc_acm ehci_pci ehci_hcd ip_gre mlx4_en ib_uverbs mlx4_ib ib_sa ib_mad ib_core ib_addr mlx4_core
> [ 180.862052] CPU: 22 PID: 1619 Comm: kworker/22:1 Not tainted 4.4.186-smp-DEV #41
> [ 180.869475] Hardware name: Intel BIOS 2.56.0 10/19/2018
> [ 180.876463] Workqueue: ipv6_addrconf addrconf_dad_work
> [ 180.881658] task: ffff8837f1f59d80 ti: ffff8837eeeb8000 task.ti: ffff8837eeeb8000
> [ 180.889171] RIP: 0010:[<ffffffff821ef26f>] [<ffffffff821ef26f>] skb_panic+0x14f/0x210
> [ 180.897162] RSP: 0018:ffff8837eeebf4b8 EFLAGS: 00010282
> [ 180.902504] RAX: 0000000000000088 RBX: ffff8837eeeeb600 RCX: 0000000000000000
> [ 180.909645] RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffffffff83508c00
> [ 180.916854] RBP: ffff8837eeebf520 R08: 0000000000000016 R09: 0000000000000000
> [ 180.924029] R10: ffff881fc8abf038 R11: 0000000000000007 R12: ffff881fc8abe720
> [ 180.931213] R13: ffffffff82aa9e80 R14: 00000000000000c0 R15: 0000000000000098
> [ 180.938390] FS: 0000000000000000(0000) GS:ffff8837ff280000(0000) knlGS:0000000000000000
> [ 180.946519] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 180.952290] CR2: 00007f519426f530 CR3: 00000037d37f2000 CR4: 0000000000160670
> [ 180.959447] Stack:
> [ 180.961458] ffff8837dd1f098c 0000000000000098 00000000000000c0 ffff881fc8abe720
> [ 180.968909] ffffea00df747c00 ffff881fff404b40 ffff8837ff2a1a20 ffff8837eeebf5b8
> [ 180.976371] ffff8837eeeeb600 ffffffff825ec6ea 1ffff106fddd7eb6 ffff8837eeeeb600
> [ 180.983848] Call Trace:
> [ 180.986297] [<ffffffff825ec6ea>] ? ip6gre_header+0xba/0xd50
> [ 180.991962] [<ffffffff821f0e01>] skb_push+0xc1/0x100
> [ 180.997023] [<ffffffff825ec6ea>] ip6gre_header+0xba/0xd50
> [ 181.002519] [<ffffffff8158dc16>] ? memcpy+0x36/0x40
> [ 181.007509] [<ffffffff825ec630>] ? ip6gre_changelink+0x6d0/0x6d0
> [ 181.013629] [<ffffffff82550741>] ? ndisc_constructor+0x5b1/0x770
> [ 181.019728] [<ffffffff82666861>] ? _raw_write_unlock_bh+0x41/0x50
> [ 181.025924] [<ffffffff8226540b>] ? __neigh_create+0xe6b/0x1670
> [ 181.031851] [<ffffffff8225817f>] neigh_connected_output+0x23f/0x480
> [ 181.038219] [<ffffffff824f61ec>] ip6_finish_output2+0x74c/0x1a90
> [ 181.044324] [<ffffffff810f1d33>] ? print_context_stack+0x73/0xf0
> [ 181.050429] [<ffffffff824f5aa0>] ? ip6_xmit+0x1700/0x1700
> [ 181.055933] [<ffffffff82304a28>] ? nf_hook_slow+0x118/0x1b0
> [ 181.061617] [<ffffffff82502d7a>] ip6_finish_output+0x2ba/0x580
> [ 181.067546] [<ffffffff82503179>] ip6_output+0x139/0x380
> [ 181.072884] [<ffffffff82503040>] ? ip6_finish_output+0x580/0x580
> [ 181.079004] [<ffffffff82502ac0>] ? ip6_fragment+0x31b0/0x31b0
> [ 181.084852] [<ffffffff82251b51>] ? dst_init+0x4b1/0x820
> [ 181.090172] [<ffffffff8158da45>] ? kasan_unpoison_shadow+0x35/0x50
> [ 181.096437] [<ffffffff8158da45>] ? kasan_unpoison_shadow+0x35/0x50
> [ 181.102712] [<ffffffff8254f3ca>] NF_HOOK_THRESH.constprop.22+0xca/0x180
> [ 181.109421] [<ffffffff8254f300>] ? ndisc_alloc_skb+0x340/0x340
> [ 181.115338] [<ffffffff8254d820>] ? compat_ipv6_setsockopt+0x180/0x180
> [ 181.121874] [<ffffffff8254fbc2>] ndisc_send_skb+0x742/0xd10
> [ 181.127550] [<ffffffff8254f480>] ? NF_HOOK_THRESH.constprop.22+0x180/0x180
> [ 181.134516] [<ffffffff821f2440>] ? skb_complete_tx_timestamp+0x280/0x280
> [ 181.141311] [<ffffffff8254e2b3>] ? ndisc_fill_addr_option+0x193/0x260
> [ 181.147844] [<ffffffff82553bd9>] ndisc_send_rs+0x179/0x2d0
> [ 181.153426] [<ffffffff8251e7df>] addrconf_dad_completed+0x41f/0x7c0
> [ 181.159795] [<ffffffff81297f78>] ? pick_next_entity+0x198/0x470
> [ 181.165807] [<ffffffff8251e3c0>] ? addrconf_rs_timer+0x4a0/0x4a0
> [ 181.171918] [<ffffffff81aab928>] ? find_next_bit+0x18/0x20
> [ 181.177504] [<ffffffff81a99ec9>] ? prandom_seed+0xd9/0x160
> [ 181.183095] [<ffffffff8251eef5>] addrconf_dad_work+0x375/0x9e0
> [ 181.189024] [<ffffffff8251eb80>] ? addrconf_dad_completed+0x7c0/0x7c0
> [ 181.195576] [<ffffffff81249d8f>] process_one_work+0x52f/0xf60
> [ 181.201468] [<ffffffff8124a89d>] worker_thread+0xdd/0xe80
> [ 181.206977] [<ffffffff8265cf0a>] ? __schedule+0x73a/0x16d0
> [ 181.212550] [<ffffffff8124a7c0>] ? process_one_work+0xf60/0xf60
> [ 181.218572] [<ffffffff8125a115>] kthread+0x205/0x2b0
> [ 181.223633] [<ffffffff81259f10>] ? kthread_worker_fn+0x4e0/0x4e0
> [ 181.229743] [<ffffffff81259f10>] ? kthread_worker_fn+0x4e0/0x4e0
> [ 181.235834] [<ffffffff8266726f>] ret_from_fork+0x3f/0x70
> [ 181.241232] [<ffffffff81259f10>] ? kthread_worker_fn+0x4e0/0x4e0
>
>
> .
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox