* [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
* [PATCH] net: 9p: Fix possible null-pointer dereferences in p9_cm_event_handler()
From: Jia-Ju Bai @ 2019-07-24 10:39 UTC (permalink / raw)
To: ericvh, lucho, asmadeus, davem
Cc: v9fs-developer, netdev, linux-kernel, Jia-Ju Bai
In p9_cm_event_handler(), there is an if statement on 260 to check
whether rdma is NULL, which indicates that rdma can be NULL.
If so, using rdma->xxx may cause a possible null-pointer dereference.
To fix these bugs, rdma is checked before being used.
These bugs are found by a static analysis tool STCheck written by us.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
net/9p/trans_rdma.c | 24 ++++++++++++++++--------
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/net/9p/trans_rdma.c b/net/9p/trans_rdma.c
index bac8dad5dd69..eba3c5fc2731 100644
--- a/net/9p/trans_rdma.c
+++ b/net/9p/trans_rdma.c
@@ -242,18 +242,24 @@ p9_cm_event_handler(struct rdma_cm_id *id, struct rdma_cm_event *event)
struct p9_trans_rdma *rdma = c->trans;
switch (event->event) {
case RDMA_CM_EVENT_ADDR_RESOLVED:
- BUG_ON(rdma->state != P9_RDMA_INIT);
- rdma->state = P9_RDMA_ADDR_RESOLVED;
+ if (rdma) {
+ BUG_ON(rdma->state != P9_RDMA_INIT);
+ rdma->state = P9_RDMA_ADDR_RESOLVED;
+ }
break;
case RDMA_CM_EVENT_ROUTE_RESOLVED:
- BUG_ON(rdma->state != P9_RDMA_ADDR_RESOLVED);
- rdma->state = P9_RDMA_ROUTE_RESOLVED;
+ if (rdma) {
+ BUG_ON(rdma->state != P9_RDMA_ADDR_RESOLVED);
+ rdma->state = P9_RDMA_ROUTE_RESOLVED;
+ }
break;
case RDMA_CM_EVENT_ESTABLISHED:
- BUG_ON(rdma->state != P9_RDMA_ROUTE_RESOLVED);
- rdma->state = P9_RDMA_CONNECTED;
+ if (rdma) {
+ BUG_ON(rdma->state != P9_RDMA_ROUTE_RESOLVED);
+ rdma->state = P9_RDMA_CONNECTED;
+ }
break;
case RDMA_CM_EVENT_DISCONNECTED:
@@ -277,12 +283,14 @@ p9_cm_event_handler(struct rdma_cm_id *id, struct rdma_cm_event *event)
case RDMA_CM_EVENT_ADDR_ERROR:
case RDMA_CM_EVENT_UNREACHABLE:
c->status = Disconnected;
- rdma_disconnect(rdma->cm_id);
+ if (rdma)
+ rdma_disconnect(rdma->cm_id);
break;
default:
BUG();
}
- complete(&rdma->cm_done);
+ if (rdma)
+ complete(&rdma->cm_done);
return 0;
}
--
2.17.0
^ 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:44 UTC (permalink / raw)
To: maowenan, Eric Dumazet, davem, gregkh, netdev, linux-kernel
In-Reply-To: <8e02f190-ec3a-6308-8c59-e5ae9ca39f5d@huawei.com>
On 7/24/19 12:36 PM, maowenan wrote:
> Actually, I have tested 4.4.184, UAF still happen.
>
>
Thanks for testing.
Acked-by: Eric Dumazet <edumazet@google.com>
^ 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:46 UTC (permalink / raw)
To: Eric Dumazet, davem, gregkh, netdev, linux-kernel
In-Reply-To: <2e09f4d1-8a47-27e9-60f9-63d3b19a98ec@gmail.com>
On 2019/7/24 17:45, 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:
>>
>> 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.
>
syzkaller reproduce program duplicate one socket that have multiple skb in write queue,
and new socket have purged skb but original socket still try to send skb. In this program,
it does not call tcp_disconnect?
>
> I suspect there is another root cause.
>
>
>
> .
>
^ permalink raw reply
* RE: [PATCH v3 6/7] net: Rename skb_frag_t size to bv_len
From: David Laight @ 2019-07-24 10:49 UTC (permalink / raw)
To: 'Matthew Wilcox', davem@davemloft.net
Cc: hch@lst.de, netdev@vger.kernel.org
In-Reply-To: <20190723030831.11879-7-willy@infradead.org>
From: Matthew Wilcox
> Sent: 23 July 2019 04:09
> Improved compatibility with bvec
>
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> ---
> include/linux/skbuff.h | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index 8076e2ba8349..e849e411d1f3 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -312,7 +312,7 @@ typedef struct skb_frag_struct skb_frag_t;
>
> struct skb_frag_struct {
> struct page *bv_page;
> - __u32 size;
> + unsigned int bv_len;
> __u32 page_offset;
> };
This is 'just plain stupid'.
The 'bv_' prefix of the members of 'struct bvec' is there so that 'grep'
(etc) can be used to find the uses of the members.
In a 'struct skb_frag_struct' a sensible prefix might be 'sf_'.
OTOH it might be sensible to use (or embed) a 'struct bvec'
instead of 'skb_frag_struct'.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [PATCH 4.4 stable net] net: tcp: Fix use-after-free in tcp_write_xmit
From: Greg KH @ 2019-07-24 11:05 UTC (permalink / raw)
To: Mao Wenan; +Cc: stable, davem, netdev, linux-kernel
In-Reply-To: <20190724091715.137033-1-maowenan@huawei.com>
On Wed, Jul 24, 2019 at 05:17:15PM +0800, Mao Wenan wrote:
> There is one report about tcp_write_xmit use-after-free with version 4.4.136:
>
> BUG: KASAN: use-after-free in tcp_skb_pcount include/net/tcp.h:796 [inline]
> BUG: KASAN: use-after-free in tcp_init_tso_segs net/ipv4/tcp_output.c:1619 [inline]
> BUG: KASAN: use-after-free in tcp_write_xmit+0x3fc2/0x4cb0 net/ipv4/tcp_output.c:2056
> Read of size 2 at addr ffff8801d6fc87b0 by task syz-executor408/4195
>
> CPU: 0 PID: 4195 Comm: syz-executor408 Not tainted 4.4.136-gfb7e319 #59
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> 0000000000000000 7d8f38ecc03be946 ffff8801d73b7710 ffffffff81e0edad
> ffffea00075bf200 ffff8801d6fc87b0 0000000000000000 ffff8801d6fc87b0
> dffffc0000000000 ffff8801d73b7748 ffffffff815159b6 ffff8801d6fc87b0
> Call Trace:
> [<ffffffff81e0edad>] __dump_stack lib/dump_stack.c:15 [inline]
> [<ffffffff81e0edad>] dump_stack+0xc1/0x124 lib/dump_stack.c:51
> [<ffffffff815159b6>] print_address_description+0x6c/0x216 mm/kasan/report.c:252
> [<ffffffff81515cd5>] kasan_report_error mm/kasan/report.c:351 [inline]
> [<ffffffff81515cd5>] kasan_report.cold.7+0x175/0x2f7 mm/kasan/report.c:408
> [<ffffffff814f9784>] __asan_report_load2_noabort+0x14/0x20 mm/kasan/report.c:427
> [<ffffffff83286582>] tcp_skb_pcount include/net/tcp.h:796 [inline]
> [<ffffffff83286582>] tcp_init_tso_segs net/ipv4/tcp_output.c:1619 [inline]
> [<ffffffff83286582>] tcp_write_xmit+0x3fc2/0x4cb0 net/ipv4/tcp_output.c:2056
> [<ffffffff83287a40>] __tcp_push_pending_frames+0xa0/0x290 net/ipv4/tcp_output.c:2307
> [<ffffffff8328e966>] tcp_send_fin+0x176/0xab0 net/ipv4/tcp_output.c:2883
> [<ffffffff8324c0d0>] tcp_close+0xca0/0xf70 net/ipv4/tcp.c:2112
> [<ffffffff832f8d0f>] inet_release+0xff/0x1d0 net/ipv4/af_inet.c:435
> [<ffffffff82f1a156>] sock_release+0x96/0x1c0 net/socket.c:586
> [<ffffffff82f1a296>] sock_close+0x16/0x20 net/socket.c:1037
> [<ffffffff81522da5>] __fput+0x235/0x6f0 fs/file_table.c:208
> [<ffffffff815232e5>] ____fput+0x15/0x20 fs/file_table.c:244
> [<ffffffff8118bd7f>] task_work_run+0x10f/0x190 kernel/task_work.c:115
> [<ffffffff81135285>] exit_task_work include/linux/task_work.h:21 [inline]
> [<ffffffff81135285>] do_exit+0x9e5/0x26b0 kernel/exit.c:759
> [<ffffffff8113b1d1>] do_group_exit+0x111/0x330 kernel/exit.c:889
> [<ffffffff8115e5cc>] get_signal+0x4ec/0x14b0 kernel/signal.c:2321
> [<ffffffff8100e02b>] do_signal+0x8b/0x1d30 arch/x86/kernel/signal.c:712
> [<ffffffff8100360a>] exit_to_usermode_loop+0x11a/0x160 arch/x86/entry/common.c:248
> [<ffffffff81006535>] prepare_exit_to_usermode arch/x86/entry/common.c:283 [inline]
> [<ffffffff81006535>] syscall_return_slowpath+0x1b5/0x1f0 arch/x86/entry/common.c:348
> [<ffffffff838c29b5>] int_ret_from_sys_call+0x25/0xa3
>
> Allocated by task 4194:
> [<ffffffff810341d6>] save_stack_trace+0x26/0x50 arch/x86/kernel/stacktrace.c:63
> [<ffffffff814f8873>] save_stack+0x43/0xd0 mm/kasan/kasan.c:512
> [<ffffffff814f8b57>] set_track mm/kasan/kasan.c:524 [inline]
> [<ffffffff814f8b57>] kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:616
> [<ffffffff814f9122>] kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:554
> [<ffffffff814f4c1e>] slab_post_alloc_hook mm/slub.c:1349 [inline]
> [<ffffffff814f4c1e>] slab_alloc_node mm/slub.c:2615 [inline]
> [<ffffffff814f4c1e>] slab_alloc mm/slub.c:2623 [inline]
> [<ffffffff814f4c1e>] kmem_cache_alloc+0xbe/0x2a0 mm/slub.c:2628
> [<ffffffff82f380a6>] kmem_cache_alloc_node include/linux/slab.h:350 [inline]
> [<ffffffff82f380a6>] __alloc_skb+0xe6/0x600 net/core/skbuff.c:218
> [<ffffffff832466c3>] alloc_skb_fclone include/linux/skbuff.h:856 [inline]
> [<ffffffff832466c3>] sk_stream_alloc_skb+0xa3/0x5d0 net/ipv4/tcp.c:833
> [<ffffffff83249164>] tcp_sendmsg+0xd34/0x2b00 net/ipv4/tcp.c:1178
> [<ffffffff83300ef3>] inet_sendmsg+0x203/0x4d0 net/ipv4/af_inet.c:755
> [<ffffffff82f1e1fc>] sock_sendmsg_nosec net/socket.c:625 [inline]
> [<ffffffff82f1e1fc>] sock_sendmsg+0xcc/0x110 net/socket.c:635
> [<ffffffff82f1eedc>] SYSC_sendto+0x21c/0x370 net/socket.c:1665
> [<ffffffff82f21560>] SyS_sendto+0x40/0x50 net/socket.c:1633
> [<ffffffff838c2825>] entry_SYSCALL_64_fastpath+0x22/0x9e
>
> Freed by task 4194:
> [<ffffffff810341d6>] save_stack_trace+0x26/0x50 arch/x86/kernel/stacktrace.c:63
> [<ffffffff814f8873>] save_stack+0x43/0xd0 mm/kasan/kasan.c:512
> [<ffffffff814f91a2>] set_track mm/kasan/kasan.c:524 [inline]
> [<ffffffff814f91a2>] kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:589
> [<ffffffff814f632e>] slab_free_hook mm/slub.c:1383 [inline]
> [<ffffffff814f632e>] slab_free_freelist_hook mm/slub.c:1405 [inline]
> [<ffffffff814f632e>] slab_free mm/slub.c:2859 [inline]
> [<ffffffff814f632e>] kmem_cache_free+0xbe/0x340 mm/slub.c:2881
> [<ffffffff82f3527f>] kfree_skbmem+0xcf/0x100 net/core/skbuff.c:635
> [<ffffffff82f372fd>] __kfree_skb+0x1d/0x20 net/core/skbuff.c:676
> [<ffffffff83288834>] sk_wmem_free_skb include/net/sock.h:1447 [inline]
> [<ffffffff83288834>] tcp_write_queue_purge include/net/tcp.h:1460 [inline]
> [<ffffffff83288834>] tcp_connect_init net/ipv4/tcp_output.c:3122 [inline]
> [<ffffffff83288834>] tcp_connect+0xb24/0x30c0 net/ipv4/tcp_output.c:3261
> [<ffffffff8329b991>] tcp_v4_connect+0xf31/0x1890 net/ipv4/tcp_ipv4.c:246
> [<ffffffff832f9ca9>] __inet_stream_connect+0x2a9/0xc30 net/ipv4/af_inet.c:615
> [<ffffffff832fa685>] inet_stream_connect+0x55/0xa0 net/ipv4/af_inet.c:676
> [<ffffffff82f1eb78>] SYSC_connect+0x1b8/0x300 net/socket.c:1557
> [<ffffffff82f214b4>] SyS_connect+0x24/0x30 net/socket.c:1538
> [<ffffffff838c2825>] entry_SYSCALL_64_fastpath+0x22/0x9e
>
> Syzkaller reproducer():
> r0 = socket$packet(0x11, 0x3, 0x300)
> r1 = socket$inet_tcp(0x2, 0x1, 0x0)
> bind$inet(r1, &(0x7f0000000300)={0x2, 0x4e21, @multicast1}, 0x10)
> connect$inet(r1, &(0x7f0000000140)={0x2, 0x1000004e21, @loopback}, 0x10)
> recvmmsg(r1, &(0x7f0000001e40)=[{{0x0, 0x0, &(0x7f0000000100)=[{&(0x7f00000005c0)=""/88, 0x58}], 0x1}}], 0x1, 0x40000000, 0x0)
> sendto$inet(r1, &(0x7f0000000000)="e2f7ad5b661c761edf", 0x9, 0x8080, 0x0, 0x0)
> r2 = fcntl$dupfd(r1, 0x0, r0)
> connect$unix(r2, &(0x7f00000001c0)=@file={0x0, './file0\x00'}, 0x6e)
>
> C repro link: https://syzkaller.appspot.com/text?tag=ReproC&x=14db474f800000
>
> This is because when tcp_connect_init call tcp_write_queue_purge, it will
> kfree all the skb in the write_queue, but the sk->sk_send_head forget to set NULL,
> then tcp_write_xmit try to send skb, which has freed in tcp_write_queue_purge, UAF happens.
>
> Signed-off-by: Mao Wenan <maowenan@huawei.com>
> ---
> include/net/tcp.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index bf8a0dae977a..8f8aace28cf8 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -1457,6 +1457,7 @@ static inline void tcp_write_queue_purge(struct sock *sk)
>
> while ((skb = __skb_dequeue(&sk->sk_write_queue)) != NULL)
> sk_wmem_free_skb(sk, skb);
> + sk->sk_send_head = NULL;
> sk_mem_reclaim(sk);
> tcp_clear_all_retrans_hints(tcp_sk(sk));
> inet_csk(sk)->icsk_backoff = 0;
Does this corrispond with a specific commit that is already in Linus's
tree? If not, why, did we change/mess something up when doing
backports, or is the code just that different?
Also, is this needed in 4.9.y, 4.14.y, 4.19.y, and/or 5.2.y? Why just
4.4.y?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool
From: Jon Hunter @ 2019-07-24 11:10 UTC (permalink / raw)
To: Jose Abreu, Ilias Apalodimas
Cc: David Miller, robin.murphy@arm.com, lists@bofh.nu,
Joao.Pinto@synopsys.com, alexandre.torgue@st.com,
maxime.ripard@bootlin.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com, wens@csie.org,
mcoquelin.stm32@gmail.com, linux-tegra@vger.kernel.org,
peppe.cavallaro@st.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <BYAPR12MB3269C5766F553438ECFF2C9BD3C60@BYAPR12MB3269.namprd12.prod.outlook.com>
On 24/07/2019 11:04, Jose Abreu wrote:
...
> Jon, I was able to replicate (at some level) your setup:
>
> # dmesg | grep -i arm-smmu
> [ 1.337322] arm-smmu 70040000.iommu: probing hardware
> configuration...
> [ 1.337330] arm-smmu 70040000.iommu: SMMUv2 with:
> [ 1.337338] arm-smmu 70040000.iommu: stage 1 translation
> [ 1.337346] arm-smmu 70040000.iommu: stage 2 translation
> [ 1.337354] arm-smmu 70040000.iommu: nested translation
> [ 1.337363] arm-smmu 70040000.iommu: stream matching with 128
> register groups
> [ 1.337374] arm-smmu 70040000.iommu: 1 context banks (0
> stage-2 only)
> [ 1.337383] arm-smmu 70040000.iommu: Supported page sizes:
> 0x61311000
> [ 1.337393] arm-smmu 70040000.iommu: Stage-1: 48-bit VA ->
> 48-bit IPA
> [ 1.337402] arm-smmu 70040000.iommu: Stage-2: 48-bit IPA ->
> 48-bit PA
>
> # dmesg | grep -i stmmac
> [ 1.344106] stmmaceth 70000000.ethernet: Adding to iommu group 0
> [ 1.344233] stmmaceth 70000000.ethernet: no reset control found
> [ 1.348276] stmmaceth 70000000.ethernet: User ID: 0x10, Synopsys ID:
> 0x51
> [ 1.348285] stmmaceth 70000000.ethernet: DWMAC4/5
> [ 1.348293] stmmaceth 70000000.ethernet: DMA HW capability register
> supported
> [ 1.348302] stmmaceth 70000000.ethernet: RX Checksum Offload Engine
> supported
> [ 1.348311] stmmaceth 70000000.ethernet: TX Checksum insertion
> supported
> [ 1.348320] stmmaceth 70000000.ethernet: TSO supported
> [ 1.348328] stmmaceth 70000000.ethernet: Enable RX Mitigation via HW
> Watchdog Timer
> [ 1.348337] stmmaceth 70000000.ethernet: TSO feature enabled
> [ 1.348409] libphy: stmmac: probed
> [ 4159.140990] stmmaceth 70000000.ethernet eth0: PHY [stmmac-0:01]
> driver [Generic PHY]
> [ 4159.141005] stmmaceth 70000000.ethernet eth0: phy: setting supported
> 00,00000000,000062ff advertising 00,00000000,000062ff
> [ 4159.142359] stmmaceth 70000000.ethernet eth0: No Safety Features
> support found
> [ 4159.142369] stmmaceth 70000000.ethernet eth0: IEEE 1588-2008 Advanced
> Timestamp supported
> [ 4159.142429] stmmaceth 70000000.ethernet eth0: registered PTP clock
> [ 4159.142439] stmmaceth 70000000.ethernet eth0: configuring for
> phy/gmii link mode
> [ 4159.142452] stmmaceth 70000000.ethernet eth0: phylink_mac_config:
> mode=phy/gmii/Unknown/Unknown adv=00,00000000,000062ff pause=10 link=0
> an=1
> [ 4159.142466] stmmaceth 70000000.ethernet eth0: phy link up
> gmii/1Gbps/Full
> [ 4159.142475] stmmaceth 70000000.ethernet eth0: phylink_mac_config:
> mode=phy/gmii/1Gbps/Full adv=00,00000000,00000000 pause=0f link=1 an=0
> [ 4159.142481] stmmaceth 70000000.ethernet eth0: Link is Up - 1Gbps/Full
> - flow control rx/tx
>
> The only missing point is the NFS boot that I can't replicate with this
> setup. But I did some sanity checks:
>
> Remote Enpoint:
> # dd if=/dev/urandom of=output.dat bs=128M count=1
> # nc -c 192.168.0.2 1234 < output.dat
> # md5sum output.dat
> fde9e0818281836e4fc0edfede2b8762 output.dat
>
> DUT:
> # nc -l -c -p 1234 > output.dat
> # md5sum output.dat
> fde9e0818281836e4fc0edfede2b8762 output.dat
On my setup, if I do not use NFS to mount the rootfs, but then manually
mount the NFS share after booting, I do not see any problems reading or
writing to files on the share. So I am not sure if it is some sort of
race that is occurring when mounting the NFS share on boot. It is 100%
reproducible when using NFS for the root file-system.
I am using the Jetson TX2 devkit [0] to test this.
Cheers
Jon
[0] https://developer.nvidia.com/embedded/jetson-tx2-developer-kit
--
nvpublic
^ permalink raw reply
* Re: [PATCH] wlcore/wl18xx: Add invert-irq OF property for physically inverted IRQ
From: Kalle Valo @ 2019-07-24 11:14 UTC (permalink / raw)
To: Eugeniu Rosca
Cc: Geert Uytterhoeven, Simon Horman, David S. Miller,
Greg Kroah-Hartman, Randy Dunlap, Tony Lindgren, Ulf Hansson,
John Stultz, linux-wireless, netdev, linux-kernel,
Spyridon Papageorgiou, Joshua Frkuska, George G . Davis,
Andrey Gusakov, Linux-Renesas, Eugeniu Rosca, Eugeniu Rosca
In-Reply-To: <20190607172958.20745-1-erosca@de.adit-jv.com>
Eugeniu Rosca <erosca@de.adit-jv.com> wrote:
> The wl1837mod datasheet [1] says about the WL_IRQ pin:
>
> ---8<---
> SDIO available, interrupt out. Active high. [..]
> Set to rising edge (active high) on powerup.
> ---8<---
>
> That's the reason of seeing the interrupt configured as:
> - IRQ_TYPE_EDGE_RISING on HiKey 960/970
> - IRQ_TYPE_LEVEL_HIGH on a number of i.MX6 platforms
>
> We assert that all those platforms have the WL_IRQ pin connected
> to the SoC _directly_ (confirmed on HiKey 970 [2]).
>
> That's not the case for R-Car Kingfisher extension target, which carries
> a WL1837MODGIMOCT IC. There is an SN74LV1T04DBVR inverter present
> between the WLAN_IRQ pin of the WL18* chip and the SoC, effectively
> reversing the requirement quoted from [1]. IOW, in Kingfisher DTS
> configuration we would need to use IRQ_TYPE_EDGE_FALLING or
> IRQ_TYPE_LEVEL_LOW.
>
> Unfortunately, v4.2-rc1 commit bd763482c82ea2 ("wl18xx: wlan_irq:
> support platform dependent interrupt types") made a special case out
> of these interrupt types. After this commit, it is impossible to provide
> an IRQ configuration via DTS which would describe an inverter present
> between the WL18* chip and the SoC, generating the need for workarounds
> like [3].
>
> Create a boolean OF property, called "invert-irq" to specify that
> the WLAN_IRQ pin of WL18* is connected to the SoC via an inverter.
>
> This solution has been successfully tested on R-Car H3ULCB-KF-M06 using
> the DTS configuration [4] combined with the "invert-irq" property.
>
> [1] http://www.ti.com/lit/ds/symlink/wl1837mod.pdf
> [2] https://www.96boards.org/documentation/consumer/hikey/hikey970/hardware-docs/
> [3] https://github.com/CogentEmbedded/meta-rcar/blob/289fbd4f8354/meta-rcar-gen3-adas/recipes-kernel/linux/linux-renesas/0024-wl18xx-do-not-invert-IRQ-on-WLxxxx-side.patch
> [4] https://patchwork.kernel.org/patch/10895879/
> ("arm64: dts: ulcb-kf: Add support for TI WL1837")
>
> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Based on the discussion I'm dropping this. Please resend once there's a
conclusion.
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/10982491/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH net-next 1/4] sctp: check addr_size with sa_family_t size in __sctp_setsockopt_connectx
From: Neil Horman @ 2019-07-24 11:22 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, Marcelo Ricardo Leitner, davem
In-Reply-To: <CADvbK_eiS26aMZcPrj2oNvZh_42phWiY71M7=UNvjEeB-B9bDQ@mail.gmail.com>
On Wed, Jul 24, 2019 at 03:21:12PM +0800, Xin Long wrote:
> On Tue, Jul 23, 2019 at 11:25 PM Neil Horman <nhorman@tuxdriver.com> wrote:
> >
> > On Tue, Jul 23, 2019 at 01:37:57AM +0800, Xin Long wrote:
> > > Now __sctp_connect() is called by __sctp_setsockopt_connectx() and
> > > sctp_inet_connect(), the latter has done addr_size check with size
> > > of sa_family_t.
> > >
> > > In the next patch to clean up __sctp_connect(), we will remove
> > > addr_size check with size of sa_family_t from __sctp_connect()
> > > for the 1st address.
> > >
> > > So before doing that, __sctp_setsockopt_connectx() should do
> > > this check first, as sctp_inet_connect() does.
> > >
> > > Signed-off-by: Xin Long <lucien.xin@gmail.com>
> > > ---
> > > net/sctp/socket.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> > > index aa80cda..5f92e4a 100644
> > > --- a/net/sctp/socket.c
> > > +++ b/net/sctp/socket.c
> > > @@ -1311,7 +1311,7 @@ static int __sctp_setsockopt_connectx(struct sock *sk,
> > > pr_debug("%s: sk:%p addrs:%p addrs_size:%d\n",
> > > __func__, sk, addrs, addrs_size);
> > >
> > > - if (unlikely(addrs_size <= 0))
> > > + if (unlikely(addrs_size < sizeof(sa_family_t)))
> > I don't think this is what you want to check for here. sa_family_t is
> > an unsigned short, and addrs_size is the number of bytes in the addrs
> > array. The addrs array should be at least the size of one struct
> > sockaddr (16 bytes iirc), and, if larger, should be a multiple of
> > sizeof(struct sockaddr)
> sizeof(struct sockaddr) is not the right value to check either.
>
> The proper check will be done later in __sctp_connect():
>
> af = sctp_get_af_specific(daddr->sa.sa_family);
> if (!af || af->sockaddr_len > addrs_size)
> return -EINVAL;
>
> So the check 'addrs_size < sizeof(sa_family_t)' in this patch is
> just to make sure daddr->sa.sa_family is accessible. the same
> check is also done in sctp_inet_connect().
>
That doesn't make much sense, if the proper check is done in __sctp_connect with
the size of the families sockaddr_len, then we don't need this check at all, we
can just let memdup_user take the fault on copy_to_user and return -EFAULT. If
we get that from memdup_user, we know its not accessible, and can bail out.
About the only thing we need to check for here is that addr_len isn't some
absurdly high value (i.e. a negative value), so that we avoid trying to kmalloc
upwards of 2G in memdup_user. Your change does that just fine, but its no
better or worse than checking for <=0
Neil
> >
> > Neil
> >
> > > return -EINVAL;
> > >
> > > kaddrs = memdup_user(addrs, addrs_size);
> > > --
> > > 2.1.0
> > >
> > >
>
^ permalink raw reply
* [PATCH net-next 00/10] Use dev_get_drvdata where possible
From: Chuhong Yuan @ 2019-07-24 11:25 UTC (permalink / raw)
Cc: Mirko Lindner, Stephen Hemminger, Jiri Slaby, Nick Kossifidis,
Luis Chamberlain, Stanislaw Gruszka, Kalle Valo,
QCA ath9k Development, Maya Erez, Johannes Berg,
Emmanuel Grumbach, Luca Coelho, Amitkumar Karwar,
Nishant Sarmukadam, Ganapathi Bhat, Xinming Hu, Igor Mitsyanko,
Avinash Patil, Sergey Matyukevich, Ping-Ke Shih,
Intel Linux Wireless, David S . Miller,
Solarflare linux maintainers, Edward Cree, Martin Habets, netdev,
wil6210, linux-wireless, linux-kernel, Chuhong Yuan
These patches use dev_get_drvdata instead of
using to_pci_dev + pci_get_drvdata to make
code simpler.
Chuhong Yuan (10):
net: marvell: Use dev_get_drvdata where possible
forcedeth: Use dev_get_drvdata where possible
sfc: Use dev_get_drvdata where possible
sfc-falcon: Use dev_get_drvdata where possible
ath: Use dev_get_drvdata where possible
iwlegacy: Use dev_get_drvdata where possible
iwlwifi: Use dev_get_drvdata where possible
mwifiex: pcie: Use dev_get_drvdata
qtnfmac_pcie: Use dev_get_drvdata
rtlwifi: rtl_pci: Use dev_get_drvdata
drivers/net/ethernet/marvell/skge.c | 6 ++----
drivers/net/ethernet/marvell/sky2.c | 3 +--
drivers/net/ethernet/nvidia/forcedeth.c | 3 +--
drivers/net/ethernet/sfc/ef10.c | 4 ++--
drivers/net/ethernet/sfc/efx.c | 10 +++++-----
drivers/net/ethernet/sfc/falcon/efx.c | 6 +++---
drivers/net/ethernet/sfc/falcon/falcon_boards.c | 4 ++--
drivers/net/wireless/ath/ath5k/pci.c | 3 +--
drivers/net/wireless/ath/ath9k/pci.c | 5 ++---
drivers/net/wireless/ath/wil6210/pcie_bus.c | 6 ++----
drivers/net/wireless/intel/iwlegacy/common.c | 3 +--
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 12 ++++--------
drivers/net/wireless/marvell/mwifiex/pcie.c | 8 ++------
drivers/net/wireless/quantenna/qtnfmac/pcie/pcie.c | 4 ++--
drivers/net/wireless/realtek/rtlwifi/pci.c | 6 ++----
15 files changed, 32 insertions(+), 51 deletions(-)
--
2.20.1
^ permalink raw reply
* [PATCH net-next 01/10] net: marvell: Use dev_get_drvdata where possible
From: Chuhong Yuan @ 2019-07-24 11:26 UTC (permalink / raw)
Cc: Mirko Lindner, Stephen Hemminger, David S . Miller, netdev,
linux-kernel, Chuhong Yuan
Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
---
drivers/net/ethernet/marvell/skge.c | 6 ++----
drivers/net/ethernet/marvell/sky2.c | 3 +--
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/marvell/skge.c b/drivers/net/ethernet/marvell/skge.c
index 9ac854c2b371..06dffee81e02 100644
--- a/drivers/net/ethernet/marvell/skge.c
+++ b/drivers/net/ethernet/marvell/skge.c
@@ -4078,8 +4078,7 @@ static void skge_remove(struct pci_dev *pdev)
#ifdef CONFIG_PM_SLEEP
static int skge_suspend(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct skge_hw *hw = pci_get_drvdata(pdev);
+ struct skge_hw *hw = dev_get_drvdata(dev);
int i;
if (!hw)
@@ -4103,8 +4102,7 @@ static int skge_suspend(struct device *dev)
static int skge_resume(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct skge_hw *hw = pci_get_drvdata(pdev);
+ struct skge_hw *hw = dev_get_drvdata(dev);
int i, err;
if (!hw)
diff --git a/drivers/net/ethernet/marvell/sky2.c b/drivers/net/ethernet/marvell/sky2.c
index f518312ffe69..762fe0821923 100644
--- a/drivers/net/ethernet/marvell/sky2.c
+++ b/drivers/net/ethernet/marvell/sky2.c
@@ -5160,8 +5160,7 @@ static void sky2_remove(struct pci_dev *pdev)
static int sky2_suspend(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct sky2_hw *hw = pci_get_drvdata(pdev);
+ struct sky2_hw *hw = dev_get_drvdata(dev);
int i;
if (!hw)
--
2.20.1
^ permalink raw reply related
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