* Re: [PATCH mlx5-next] net/mlx5: Fix modify_cq_in alignment
From: Leon Romanovsky @ 2019-07-25 3:02 UTC (permalink / raw)
To: Saeed Mahameed
Cc: davem@davemloft.net, Jason Gunthorpe, Yishai Hadas,
netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
dledford@redhat.com, Edward Srouji
In-Reply-To: <5447fded90dfd133ef002177b77bfd3685bf8b42.camel@mellanox.com>
On Wed, Jul 24, 2019 at 08:56:08PM +0000, Saeed Mahameed wrote:
> On Tue, 2019-07-23 at 22:04 +0300, Leon Romanovsky wrote:
> > On Tue, Jul 23, 2019 at 11:28:50AM -0700, David Miller wrote:
> > > From: Leon Romanovsky <leon@kernel.org>
> > > Date: Tue, 23 Jul 2019 10:12:55 +0300
> > >
> > > > From: Edward Srouji <edwards@mellanox.com>
> > > >
> > > > Fix modify_cq_in alignment to match the device specification.
> > > > After this fix the 'cq_umem_valid' field will be in the right
> > > > offset.
> > > >
> > > > Cc: <stable@vger.kernel.org> # 4.19
> > > > Fixes: bd37197554eb ("net/mlx5: Update mlx5_ifc with DEVX UID
> > > > bits")
>
> Leon, I applied this patch to my tree, it got marked for -stable 4.20
> and not 4.19, i checked manually and indeed the offending patch came to
> light only on 4.20
Thanks
>
^ permalink raw reply
* Re: [PATCH net-next] netfilter: nf_table_offload: Fix zero prio of flow_cls_common_offload
From: wenxu @ 2019-07-25 3:03 UTC (permalink / raw)
To: Marcelo Ricardo Leitner; +Cc: pablo, davem, netfilter-devel, netdev
In-Reply-To: <20190724235151.GB4063@localhost.localdomain>
On 7/25/2019 7:51 AM, Marcelo Ricardo Leitner wrote:
> On Thu, Jul 11, 2019 at 04:03:30PM +0800, wenxu@ucloud.cn wrote:
>> From: wenxu <wenxu@ucloud.cn>
>>
>> The flow_cls_common_offload prio should be not zero
>>
>> It leads the invalid table prio in hw.
>>
>> # nft add table netdev firewall
>> # nft add chain netdev firewall acl { type filter hook ingress device mlx_pf0vf0 priority - 300 \; }
>> # nft add rule netdev firewall acl ip daddr 1.1.1.7 drop
>> Error: Could not process rule: Invalid argument
>>
>> kernel log
>> mlx5_core 0000:81:00.0: E-Switch: Failed to create FDB Table err -22 (table prio: 65535, level: 0, size: 4194304)
>>
>> Fixes: c9626a2cbdb2 ("netfilter: nf_tables: add hardware offload support")
>> Signed-off-by: wenxu <wenxu@ucloud.cn>
>> ---
>> net/netfilter/nf_tables_offload.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/net/netfilter/nf_tables_offload.c b/net/netfilter/nf_tables_offload.c
>> index 2c33028..01d8133 100644
>> --- a/net/netfilter/nf_tables_offload.c
>> +++ b/net/netfilter/nf_tables_offload.c
>> @@ -7,6 +7,8 @@
>> #include <net/netfilter/nf_tables_offload.h>
>> #include <net/pkt_cls.h>
>>
>> +#define FLOW_OFFLOAD_DEFAUT_PRIO 1U
>> +
>> static struct nft_flow_rule *nft_flow_rule_alloc(int num_actions)
>> {
>> struct nft_flow_rule *flow;
>> @@ -107,6 +109,7 @@ static void nft_flow_offload_common_init(struct flow_cls_common_offload *common,
>> struct netlink_ext_ack *extack)
>> {
>> common->protocol = proto;
>> + common->prio = TC_H_MAKE(FLOW_OFFLOAD_DEFAUT_PRIO << 16, 0);
> Note that tc semantics for this is to auto-generate a priority in such
> cases, instead of using a default.
>
> @tc_new_tfilter():
> if (prio == 0) {
> /* If no priority is provided by the user,
> * we allocate one.
> */
> if (n->nlmsg_flags & NLM_F_CREATE) {
> prio = TC_H_MAKE(0x80000000U, 0U);
> prio_allocate = true;
> ...
> if (prio_allocate)
> prio = tcf_auto_prio(tcf_chain_tp_prev(chain,
> &chain_info));
Yes,The tc auto-generate a priority. But if there is no pre tcf_proto, the priority is also set as a default.
In nftables each rule no priortiy for each other. So It is enough to set a default value which is similar as the
tc.
static inline u32 tcf_auto_prio(struct tcf_proto *tp)
{
u32 first = TC_H_MAKE(0xC0000000U, 0U);
if (tp)
first = tp->prio - 1;
return TC_H_MAJ(first);
}
^ permalink raw reply
* [PATCH] ipip: validate header length in ipip_tunnel_xmit
From: Haishuang Yan @ 2019-07-25 3:07 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov; +Cc: netdev, linux-kernel, Haishuang Yan
In-Reply-To: <1564024076-13764-1-git-send-email-yanhaishuang@cmss.chinamobile.com>
We need the same checks introduced by commit cb9f1b783850
("ip: validate header length on virtual device xmit") for
ipip tunnel.
Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
---
net/ipv4/ipip.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/ipv4/ipip.c b/net/ipv4/ipip.c
index 43adfc1..2f01cf6 100644
--- a/net/ipv4/ipip.c
+++ b/net/ipv4/ipip.c
@@ -275,6 +275,9 @@ static netdev_tx_t ipip_tunnel_xmit(struct sk_buff *skb,
const struct iphdr *tiph = &tunnel->parms.iph;
u8 ipproto;
+ if (!pskb_inet_may_pull(skb))
+ goto tx_error;
+
switch (skb->protocol) {
case htons(ETH_P_IP):
ipproto = IPPROTO_IPIP;
--
1.8.3.1
^ permalink raw reply related
* [PATCH] ipip: validate header length in ipip_tunnel_xmit
From: Haishuang Yan @ 2019-07-25 3:07 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov; +Cc: netdev, linux-kernel, Haishuang Yan
We need the same checks introduced by commit cb9f1b783850
("ip: validate header length on virtual device xmit") for
ipip tunnel.
Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
---
net/ipv4/ipip.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/ipv4/ipip.c b/net/ipv4/ipip.c
index 43adfc1..2f01cf6 100644
--- a/net/ipv4/ipip.c
+++ b/net/ipv4/ipip.c
@@ -275,6 +275,9 @@ static netdev_tx_t ipip_tunnel_xmit(struct sk_buff *skb,
const struct iphdr *tiph = &tunnel->parms.iph;
u8 ipproto;
+ if (!pskb_inet_may_pull(skb))
+ goto tx_error;
+
switch (skb->protocol) {
case htons(ETH_P_IP):
ipproto = IPPROTO_IPIP;
--
1.8.3.1
^ permalink raw reply related
* Re: Reminder: 99 open syzbot bugs in net subsystem
From: Theodore Y. Ts'o @ 2019-07-25 3:39 UTC (permalink / raw)
To: David Miller
Cc: ebiggers, eric.dumazet, dvyukov, netdev, fw, i.maximets, edumazet,
dsahern, linux-kernel, syzkaller-bugs
In-Reply-To: <20190724.130928.1854327585456756387.davem@davemloft.net>
On Wed, Jul 24, 2019 at 01:09:28PM -0700, David Miller wrote:
> From: Eric Biggers <ebiggers@kernel.org>
> Date: Wed, 24 Jul 2019 11:37:12 -0700
>
> > We can argue about what words to use to describe this situation, but
> > it doesn't change the situation itself.
>
> And we should argue about those words because it matters to humans and
> effects how they feel, and humans ultimately fix these bugs.
>
> So please stop with the hyperbole.
Perhaps it would be better to call them, "syzbot reports". Not all
syzbot reports are bugs. In fact, Dmitry has steadfastly refused to
add features which any basic bug-tracking system would have, claiming
that syzbot should not be a bug-tracking system, and something like
bugzilla should be forcibly imposed on all kernel developers. So I
don't consider syzkaller reports as bugs --- they are just reports.
In order for developers to want to engage with "syzbot reports", we
need to reduce developer toil which syzbot imposes on developers, such
that it is a net benefit, instead of it being just a source of
annoying e-mails, some of which are actionable, and some of which are
noise.
In particular, asking developers to figure out which syzbot reports
should be closed, because developers found the problem independently,
and fixed it without hearing about from syzbot first, really isn't a
fair thing to ask. Especially if we can automate away the problem.
If there is a reproducer, it should be possible to automatically
categorize the reproducer as a reliable reproducer or a flakey one.
If it is a reliable reproducer on version X, and it fails to be
reliably reproduce on version X+N, then it should be able to figure
out that it has been fixed, instead of requesting that a human confirm
it. If you really want a human to look at it, now that syzkaller has
a bisection feature, it should be possible to use the reliable
reproducer to do a negative bisection search to report a candidate
fix. This would significantly reproduce the developer toil imposed as
a tax on developers. And if Dmitry doesn't want to auto-close those
reports that appear to be fixed already, at the very least they should
be down-prioritized on Eric's reports, so people who don't want to
waste their time on "bureaucracy" can do so.
Cheers,
- Ted
P.S. Another criteria I'd suggest down-prioritizing on is, "does it
require root privileges?" After all, since root has so many different
ways of crashing a system already, and if we're all super-busy, we
need to prioritize which reports should be addressed first.
^ permalink raw reply
* Re: [PATCH net-next] netfilter: nf_table_offload: Fix zero prio of flow_cls_common_offload
From: Marcelo Ricardo Leitner @ 2019-07-25 3:45 UTC (permalink / raw)
To: wenxu; +Cc: pablo, davem, netfilter-devel, netdev
In-Reply-To: <9775e2da-78ce-95f8-c215-b35b464ea5a9@ucloud.cn>
On Thu, Jul 25, 2019 at 11:03:52AM +0800, wenxu wrote:
>
> On 7/25/2019 7:51 AM, Marcelo Ricardo Leitner wrote:
> > On Thu, Jul 11, 2019 at 04:03:30PM +0800, wenxu@ucloud.cn wrote:
> >> From: wenxu <wenxu@ucloud.cn>
> >>
> >> The flow_cls_common_offload prio should be not zero
> >>
> >> It leads the invalid table prio in hw.
> >>
> >> # nft add table netdev firewall
> >> # nft add chain netdev firewall acl { type filter hook ingress device mlx_pf0vf0 priority - 300 \; }
> >> # nft add rule netdev firewall acl ip daddr 1.1.1.7 drop
> >> Error: Could not process rule: Invalid argument
> >>
> >> kernel log
> >> mlx5_core 0000:81:00.0: E-Switch: Failed to create FDB Table err -22 (table prio: 65535, level: 0, size: 4194304)
> >>
> >> Fixes: c9626a2cbdb2 ("netfilter: nf_tables: add hardware offload support")
> >> Signed-off-by: wenxu <wenxu@ucloud.cn>
> >> ---
> >> net/netfilter/nf_tables_offload.c | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> diff --git a/net/netfilter/nf_tables_offload.c b/net/netfilter/nf_tables_offload.c
> >> index 2c33028..01d8133 100644
> >> --- a/net/netfilter/nf_tables_offload.c
> >> +++ b/net/netfilter/nf_tables_offload.c
> >> @@ -7,6 +7,8 @@
> >> #include <net/netfilter/nf_tables_offload.h>
> >> #include <net/pkt_cls.h>
> >>
> >> +#define FLOW_OFFLOAD_DEFAUT_PRIO 1U
> >> +
> >> static struct nft_flow_rule *nft_flow_rule_alloc(int num_actions)
> >> {
> >> struct nft_flow_rule *flow;
> >> @@ -107,6 +109,7 @@ static void nft_flow_offload_common_init(struct flow_cls_common_offload *common,
> >> struct netlink_ext_ack *extack)
> >> {
> >> common->protocol = proto;
> >> + common->prio = TC_H_MAKE(FLOW_OFFLOAD_DEFAUT_PRIO << 16, 0);
> > Note that tc semantics for this is to auto-generate a priority in such
> > cases, instead of using a default.
> >
> > @tc_new_tfilter():
> > if (prio == 0) {
> > /* If no priority is provided by the user,
> > * we allocate one.
> > */
> > if (n->nlmsg_flags & NLM_F_CREATE) {
> > prio = TC_H_MAKE(0x80000000U, 0U);
> > prio_allocate = true;
> > ...
> > if (prio_allocate)
> > prio = tcf_auto_prio(tcf_chain_tp_prev(chain,
> > &chain_info));
>
> Yes,The tc auto-generate a priority. But if there is no pre
> tcf_proto, the priority is also set as a default.
After the first filter, there will be a tcf_proto. Please see the test below.
>
> In nftables each rule no priortiy for each other. So It is enough to
> set a default value which is similar as the tc.
Yep, maybe it works for nftables. I'm just highlighting this because
it is reusing tc infrastructure and will expose a different behavior
to the user. But if nftables already has this defined, that probably
takes precedence by now and all that is left to do is to make sure any
documentation on it is updated. Pablo?
>
> static inline u32 tcf_auto_prio(struct tcf_proto *tp)
> {
> u32 first = TC_H_MAKE(0xC0000000U, 0U);
^^^^ base default prio, 0xC0000 = 49152
>
> if (tp)
> first = tp->prio - 1;
>
> return TC_H_MAJ(first);
> }
# tc qdisc add dev veth1 ingress
# tc filter add dev veth1 ingress proto ip flower src_mac ec:13:db:00:00:00 action drop
1st filter --^^
# tc filter add dev veth1 ingress proto ip flower src_mac ec:13:db:00:00:01 action drop
2nd filter --^^
# tc filter add dev veth1 ingress proto ip flower src_mac ec:13:db:00:00:02 action drop
With no 'prio X' parameter, it uses 0 as default, and when dumped:
# tc filter show dev veth1 ingress
filter protocol ip pref 49150 flower
filter protocol ip pref 49150 flower handle 0x1
src_mac ec:13:db:00:00:02
eth_type ipv4
not_in_hw
action order 1: gact action drop
random type none pass val 0
index 40003 ref 1 bind 1
filter protocol ip pref 49151 flower
filter protocol ip pref 49151 flower handle 0x1
^vv^^---- 2nd filter
src_mac ec:13:db:00:00:01
eth_type ipv4
not_in_hw
action order 1: gact action drop
random type none pass val 0
index 40002 ref 1 bind 1
filter protocol ip pref 49152 flower
filter protocol ip pref 49152 flower handle 0x1
^vv^^---- 1st filter
src_mac ec:13:db:00:00:00
eth_type ipv4
not_in_hw
action order 1: gact action drop
random type none pass val 0
index 40001 ref 1 bind 1
^ permalink raw reply
* Re: [PATCH net] net: hns: fix LED configuration for marvell phy
From: Andrew Lunn @ 2019-07-25 4:28 UTC (permalink / raw)
To: liuyonglong
Cc: David Miller, netdev, linux-kernel, linuxarm, salil.mehta,
yisen.zhuang, shiju.jose
In-Reply-To: <72061222-411f-a58c-5873-ad873394cdb5@huawei.com>
On Thu, Jul 25, 2019 at 11:00:08AM +0800, liuyonglong wrote:
> > Revert "net: hns: fix LED configuration for marvell phy"
> > This reverts commit f4e5f775db5a4631300dccd0de5eafb50a77c131.
> >
> > Andrew Lunn says this should be handled another way.
> >
> > Signed-off-by: David S. Miller <davem@davemloft.net>
>
>
> Hi Andrew:
>
> I see this patch have been reverted, can you tell me the better way to do this?
> Thanks very much!
Please take a look at the work Matthias Kaehlcke is doing. It has not
got too far yet, but when it is complete, it should define a generic
way to configure PHY LEDs.
Andrew
^ permalink raw reply
* Re: [PATCH 4.4 stable net] net: tcp: Fix use-after-free in tcp_write_xmit
From: maowenan @ 2019-07-25 4:29 UTC (permalink / raw)
To: Eric Dumazet, davem, gregkh, netdev, linux-kernel
In-Reply-To: <44f0ba0d-fd19-d44b-9c5c-686e2f8ef988@gmail.com>
On 2019/7/24 22:07, Eric Dumazet wrote:
>
>
> On 7/24/19 12:46 PM, maowenan wrote:
>>
>>
>> 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?
>
>
> It does call tcp_disconnect(), by one of the connect() call.
yes, __inet_stream_connect will call tcp_disconnect when sa_family == AF_UNSPEC, in c repro if it
passes sa_family with AF_INET it won't call disconnect, and then sk_send_head won't be NULL when tcp_connect.
#define MSG_FASTOPEN 0x20000000 /* Send data in TCP SYN */
...
case 2:
*(uint16_t*)0x20e68000 = 2;
*(uint16_t*)0x20e68002 = htobe16(0x4e23);
*(uint8_t*)0x20e68004 = 0xac;
*(uint8_t*)0x20e68005 = 0x14;
*(uint8_t*)0x20e68006 = 0x14;
*(uint8_t*)0x20e68007 = 0xaa;
*(uint8_t*)0x20e68008 = 0;
*(uint8_t*)0x20e68009 = 0;
*(uint8_t*)0x20e6800a = 0;
*(uint8_t*)0x20e6800b = 0;
*(uint8_t*)0x20e6800c = 0;
*(uint8_t*)0x20e6800d = 0;
*(uint8_t*)0x20e6800e = 0;
*(uint8_t*)0x20e6800f = 0;
syscall(__NR_sendto, r[0], 0x20a88f88, 0xfffffffffffffe6e, 0x20000000, //with fastopen, it will call __inet_stream_connect
0x20e68000, 0x10);
break;
case 3:
memcpy((void*)0x20000140, "\x7f", 1);
syscall(__NR_write, r[0], 0x20000140, 1);
break;
case 4:
*(uint16_t*)0x200012c0 = 0; //sa_family
*(uint16_t*)0x200012c2 = 0;
*(uint32_t*)0x200012c4 = 0;
*(uint32_t*)0x200012c8 = 0;
syscall(__NR_connect, r[0], 0x200012c0, 0x80);
break;
case 5:
*(uint16_t*)0x20000040 = 2; //sa_family
*(uint16_t*)0x20000042 = htobe16(0x4e23);
*(uint8_t*)0x20000044 = 0xac;
*(uint8_t*)0x20000045 = 0x14;
*(uint8_t*)0x20000046 = 0x14;
*(uint8_t*)0x20000047 = 0xaa;
*(uint8_t*)0x20000048 = 0;
*(uint8_t*)0x20000049 = 0;
*(uint8_t*)0x2000004a = 0;
*(uint8_t*)0x2000004b = 0;
*(uint8_t*)0x2000004c = 0;
*(uint8_t*)0x2000004d = 0;
*(uint8_t*)0x2000004e = 0;
*(uint8_t*)0x2000004f = 0;
syscall(__NR_connect, r[0], 0x20000040, 0x10);
break;
...
>
>
> .
>
^ permalink raw reply
* Re: Reminder: 99 open syzbot bugs in net subsystem
From: Eric Biggers @ 2019-07-25 4:40 UTC (permalink / raw)
To: Theodore Y. Ts'o, David Miller, eric.dumazet, dvyukov, netdev,
fw, i.maximets, edumazet, dsahern, linux-kernel, syzkaller-bugs
In-Reply-To: <20190725033913.GB13651@mit.edu>
On Wed, Jul 24, 2019 at 11:39:13PM -0400, Theodore Y. Ts'o wrote:
> On Wed, Jul 24, 2019 at 01:09:28PM -0700, David Miller wrote:
> > From: Eric Biggers <ebiggers@kernel.org>
> > Date: Wed, 24 Jul 2019 11:37:12 -0700
> >
> > > We can argue about what words to use to describe this situation, but
> > > it doesn't change the situation itself.
> >
> > And we should argue about those words because it matters to humans and
> > effects how they feel, and humans ultimately fix these bugs.
> >
> > So please stop with the hyperbole.
>
> Perhaps it would be better to call them, "syzbot reports". Not all
> syzbot reports are bugs. In fact, Dmitry has steadfastly refused to
> add features which any basic bug-tracking system would have, claiming
> that syzbot should not be a bug-tracking system, and something like
> bugzilla should be forcibly imposed on all kernel developers. So I
> don't consider syzkaller reports as bugs --- they are just reports.
>
> In order for developers to want to engage with "syzbot reports", we
> need to reduce developer toil which syzbot imposes on developers, such
> that it is a net benefit, instead of it being just a source of
> annoying e-mails, some of which are actionable, and some of which are
> noise.
>
> In particular, asking developers to figure out which syzbot reports
> should be closed, because developers found the problem independently,
> and fixed it without hearing about from syzbot first, really isn't a
> fair thing to ask. Especially if we can automate away the problem.
>
> If there is a reproducer, it should be possible to automatically
> categorize the reproducer as a reliable reproducer or a flakey one.
> If it is a reliable reproducer on version X, and it fails to be
> reliably reproduce on version X+N, then it should be able to figure
> out that it has been fixed, instead of requesting that a human confirm
> it. If you really want a human to look at it, now that syzkaller has
> a bisection feature, it should be possible to use the reliable
> reproducer to do a negative bisection search to report a candidate
> fix. This would significantly reproduce the developer toil imposed as
> a tax on developers. And if Dmitry doesn't want to auto-close those
> reports that appear to be fixed already, at the very least they should
> be down-prioritized on Eric's reports, so people who don't want to
> waste their time on "bureaucracy" can do so.
>
> Cheers,
>
> - Ted
>
> P.S. Another criteria I'd suggest down-prioritizing on is, "does it
> require root privileges?" After all, since root has so many different
> ways of crashing a system already, and if we're all super-busy, we
> need to prioritize which reports should be addressed first.
>
I agree with all this. Fix bisection would be really useful. I think what we'd
actually need to do to get decent results, though, is consider many different
signals (days since last occurred, repro type, fix bisected, bug bisected,
occurred in mainline or not, does the repro work as root, is it clearly a "bad"
bug like use-after-free, etc.) and compute an appropriate timeout based on that.
However, I'd like to emphasize that in my reminder emails, I've *already*
considered many of these factors when sorting the bug reports, and in particular
the bugs/reports that have been seen recently are strongly weighted towards
being listed first, especially if they were seen in mainline. In this
particular reminder email, for example, the first 18 bugs/reports have *all*
been seen in the last 4 days.
These first 18 bugs/reports are ready to be worked on and fixed now. It's
unclear to me what is most impeding this. Is it part of the syzbot process?
Bad reproducers? Too much noise? Or is it no funding? Not enough qualified
people? No maintainers? Not enough reminders? Lack of CVEs and demonstrable
exploits? What is most impeding these 18 bugs from being fixed?
- Eric
^ permalink raw reply
* Re: [PATCH] [v2 net-next] ipvs: reduce kernel stack usage
From: Julian Anastasov @ 2019-07-25 5:03 UTC (permalink / raw)
To: Arnd Bergmann
Cc: David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI,
Wensong Zhang, Simon Horman, Pablo Neira Ayuso, Jozsef Kadlecsik,
Florian Westphal, Jacky Hu, Matteo Croce, netdev, lvs-devel,
linux-kernel, netfilter-devel, coreteam
In-Reply-To: <20190722113009.2704377-1-arnd@arndb.de>
Hello,
On Mon, 22 Jul 2019, Arnd Bergmann wrote:
> With the new CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL option, the stack
> usage in the ipvs debug output grows because each instance of
> IP_VS_DBG_BUF() now has its own buffer of 160 bytes that add up
> rather than reusing the stack slots:
>
> net/netfilter/ipvs/ip_vs_core.c: In function 'ip_vs_sched_persist':
> net/netfilter/ipvs/ip_vs_core.c:427:1: error: the frame size of 1052 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
> net/netfilter/ipvs/ip_vs_core.c: In function 'ip_vs_new_conn_out':
> net/netfilter/ipvs/ip_vs_core.c:1231:1: error: the frame size of 1048 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
> net/netfilter/ipvs/ip_vs_ftp.c: In function 'ip_vs_ftp_out':
> net/netfilter/ipvs/ip_vs_ftp.c:397:1: error: the frame size of 1104 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
> net/netfilter/ipvs/ip_vs_ftp.c: In function 'ip_vs_ftp_in':
> net/netfilter/ipvs/ip_vs_ftp.c:555:1: error: the frame size of 1200 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
>
> Since printk() already has a way to print IPv4/IPv6 addresses using
> the %pISc format string, use that instead, combined with a macro that
> creates a local sockaddr structure on the stack. These will still
> add up, but the stack frames are now under 200 bytes.
>
> So far I have also only added three files that caused the warning
> messages to be reported. There are still a lot of other instances of
> IP_VS_DBG_BUF() that could be converted the same way after the
> basic idea is confirmed.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> v2:
> - use compressed ipv6 format
> - fix port number endianess
Thanks! Some comments below...
> ---
> include/net/ip_vs.h | 59 ++++++++++++++++-----------------
> net/netfilter/ipvs/ip_vs_core.c | 44 ++++++++++++------------
> net/netfilter/ipvs/ip_vs_ftp.c | 20 +++++------
> 3 files changed, 60 insertions(+), 63 deletions(-)
>
> diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
> index 3759167f91f5..eace4374e69f 100644
> --- a/include/net/ip_vs.h
> +++ b/include/net/ip_vs.h
> @@ -227,6 +227,16 @@ static inline const char *ip_vs_dbg_addr(int af, char *buf, size_t buf_len,
> sizeof(ip_vs_dbg_buf), addr, \
> &ip_vs_dbg_idx)
>
> +#define IP_VS_DBG_SOCKADDR4(fam, addr, port) \
> + (struct sockaddr*)&(struct sockaddr_in) \
> + { .sin_family = (fam), .sin_addr = (addr)->in, .sin_port = (port) }
> +#define IP_VS_DBG_SOCKADDR6(fam, addr, port) \
> + (struct sockaddr*)&(struct sockaddr_in6) \
> + { .sin6_family = (fam), .sin6_addr = (addr)->in6, .sin6_port = (port) }
> +#define IP_VS_DBG_SOCKADDR(fam, addr, port) (fam == AF_INET ? \
> + IP_VS_DBG_SOCKADDR4(fam, addr, port) : \
> + IP_VS_DBG_SOCKADDR6(fam, addr, port))
> +
> #define IP_VS_DBG(level, msg, ...) \
> do { \
> if (level <= ip_vs_get_debug_level()) \
> @@ -251,6 +261,7 @@ static inline const char *ip_vs_dbg_addr(int af, char *buf, size_t buf_len,
> #else /* NO DEBUGGING at ALL */
> #define IP_VS_DBG_BUF(level, msg...) do {} while (0)
> #define IP_VS_ERR_BUF(msg...) do {} while (0)
> +#define IP_VS_DBG_SOCKADDR(fam, addr, port) NULL
> #define IP_VS_DBG(level, msg...) do {} while (0)
> #define IP_VS_DBG_RL(msg...) do {} while (0)
> #define IP_VS_DBG_PKT(level, af, pp, skb, ofs, msg) do {} while (0)
> @@ -1244,31 +1255,23 @@ static inline void ip_vs_control_del(struct ip_vs_conn *cp)
> {
> struct ip_vs_conn *ctl_cp = cp->control;
> if (!ctl_cp) {
> - IP_VS_ERR_BUF("request control DEL for uncontrolled: "
> - "%s:%d to %s:%d\n",
> - IP_VS_DBG_ADDR(cp->af, &cp->caddr),
> - ntohs(cp->cport),
> - IP_VS_DBG_ADDR(cp->af, &cp->vaddr),
> - ntohs(cp->vport));
> + pr_err("request control DEL for uncontrolled: "
> + "%pISpc to %pISpcn",
Backslash was lost
> + IP_VS_DBG_SOCKADDR(cp->af, &cp->caddr, cp->cport),
> + IP_VS_DBG_SOCKADDR(cp->af, &cp->vaddr, cp->vport));
>
> return;
> }
>
> - IP_VS_DBG_BUF(7, "DELeting control for: "
> - "cp.dst=%s:%d ctl_cp.dst=%s:%d\n",
> - IP_VS_DBG_ADDR(cp->af, &cp->caddr),
> - ntohs(cp->cport),
> - IP_VS_DBG_ADDR(cp->af, &ctl_cp->caddr),
> - ntohs(ctl_cp->cport));
> + IP_VS_DBG(7, "DELeting control for: cp.dst=%pISpc ctl_cp.dst=%pISpc\n",
> + IP_VS_DBG_SOCKADDR(cp->af, &cp->caddr, cp->cport),
> + IP_VS_DBG_SOCKADDR(cp->af, &ctl_cp->caddr, ctl_cp->cport));
>
> cp->control = NULL;
> if (atomic_read(&ctl_cp->n_control) == 0) {
> - IP_VS_ERR_BUF("BUG control DEL with n=0 : "
> - "%s:%d to %s:%d\n",
> - IP_VS_DBG_ADDR(cp->af, &cp->caddr),
> - ntohs(cp->cport),
> - IP_VS_DBG_ADDR(cp->af, &cp->vaddr),
> - ntohs(cp->vport));
> + pr_err("BUG control DEL with n=0 : %pISpc to %pISpc\n",
We can remove the space before colon
> + IP_VS_DBG_SOCKADDR(cp->af, &cp->caddr, cp->cport),
> + IP_VS_DBG_SOCKADDR(cp->af, &cp->vaddr, cp->vport));
>
> return;
> }
> @@ -1279,22 +1282,18 @@ static inline void
> ip_vs_control_add(struct ip_vs_conn *cp, struct ip_vs_conn *ctl_cp)
> {
> if (cp->control) {
> - IP_VS_ERR_BUF("request control ADD for already controlled: "
> - "%s:%d to %s:%d\n",
> - IP_VS_DBG_ADDR(cp->af, &cp->caddr),
> - ntohs(cp->cport),
> - IP_VS_DBG_ADDR(cp->af, &cp->vaddr),
> - ntohs(cp->vport));
> + pr_err("request control ADD for already controlled: "
> + "%pISpc to %pISpc\n",
> + IP_VS_DBG_SOCKADDR(cp->af, &cp->caddr, cp->cport),
> + IP_VS_DBG_SOCKADDR(cp->af, &cp->vaddr, cp->vport));
>
> ip_vs_control_del(cp);
> }
>
> - IP_VS_DBG_BUF(7, "ADDing control for: "
> - "cp.dst=%s:%d ctl_cp.dst=%s:%d\n",
> - IP_VS_DBG_ADDR(cp->af, &cp->caddr),
> - ntohs(cp->cport),
> - IP_VS_DBG_ADDR(cp->af, &ctl_cp->caddr),
> - ntohs(ctl_cp->cport));
> + IP_VS_DBG(7, "ADDing control for: "
> + "cp.dst=%pISpc ctl_cp.dst=%pISpc\n",
May be we can join above lines
> + IP_VS_DBG_SOCKADDR(cp->af, &cp->caddr, cp->cport),
> + IP_VS_DBG_SOCKADDR(cp->af, &ctl_cp->caddr, ctl_cp->cport));
>
> cp->control = ctl_cp;
> atomic_inc(&ctl_cp->n_control);
> diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
> index 46f06f92ab8f..06ab0bf9ae08 100644
> --- a/net/netfilter/ipvs/ip_vs_core.c
> +++ b/net/netfilter/ipvs/ip_vs_core.c
> @@ -52,7 +52,6 @@
> #include <net/ip_vs.h>
> #include <linux/indirect_call_wrapper.h>
>
> -
> EXPORT_SYMBOL(register_ip_vs_scheduler);
> EXPORT_SYMBOL(unregister_ip_vs_scheduler);
> EXPORT_SYMBOL(ip_vs_proto_name);
> @@ -295,11 +294,11 @@ ip_vs_sched_persist(struct ip_vs_service *svc,
> #endif
> snet.ip = src_addr->ip & svc->netmask;
>
> - IP_VS_DBG_BUF(6, "p-schedule: src %s:%u dest %s:%u "
> - "mnet %s\n",
> - IP_VS_DBG_ADDR(svc->af, src_addr), ntohs(src_port),
> - IP_VS_DBG_ADDR(svc->af, dst_addr), ntohs(dst_port),
> - IP_VS_DBG_ADDR(svc->af, &snet));
> + IP_VS_DBG(6, "p-schedule: src %pISpc dest %pISpc "
> + "mnet %pIS\n",
Join? mnet %pISc ?
> + IP_VS_DBG_SOCKADDR(svc->af, src_addr, src_port),
> + IP_VS_DBG_SOCKADDR(svc->af, dst_addr, dst_port),
> + IP_VS_DBG_SOCKADDR(svc->af, &snet, 0));
>
> /*
> * As far as we know, FTP is a very complicated network protocol, and
> @@ -567,12 +566,12 @@ ip_vs_schedule(struct ip_vs_service *svc, struct sk_buff *skb,
> }
> }
>
> - IP_VS_DBG_BUF(6, "Schedule fwd:%c c:%s:%u v:%s:%u "
> - "d:%s:%u conn->flags:%X conn->refcnt:%d\n",
> + IP_VS_DBG(6, "Schedule fwd:%c c:%pISpc v:%pISpc "
> + "d:%pISp conn->flags:%X conn->refcnt:%d\n",
d:%pISpc
> ip_vs_fwd_tag(cp),
> - IP_VS_DBG_ADDR(cp->af, &cp->caddr), ntohs(cp->cport),
> - IP_VS_DBG_ADDR(cp->af, &cp->vaddr), ntohs(cp->vport),
> - IP_VS_DBG_ADDR(cp->daf, &cp->daddr), ntohs(cp->dport),
> + IP_VS_DBG_SOCKADDR(cp->af, &cp->caddr, cp->cport),
> + IP_VS_DBG_SOCKADDR(cp->af, &cp->vaddr, cp->vport),
> + IP_VS_DBG_SOCKADDR(cp->daf, &cp->daddr, cp->dport),
> cp->flags, refcount_read(&cp->refcnt));
>
> ip_vs_conn_stats(cp, svc);
> @@ -886,8 +885,8 @@ static int handle_response_icmp(int af, struct sk_buff *skb,
> /* Ensure the checksum is correct */
> if (!skb_csum_unnecessary(skb) && ip_vs_checksum_complete(skb, ihl)) {
> /* Failed checksum! */
> - IP_VS_DBG_BUF(1, "Forward ICMP: failed checksum from %s!\n",
> - IP_VS_DBG_ADDR(af, snet));
> + IP_VS_DBG(1, "Forward ICMP: failed checksum from %pISc!\n",
> + IP_VS_DBG_SOCKADDR(af, snet, 0));
> goto out;
> }
>
> @@ -1220,13 +1219,13 @@ struct ip_vs_conn *ip_vs_new_conn_out(struct ip_vs_service *svc,
> ip_vs_conn_stats(cp, svc);
>
> /* return connection (will be used to handle outgoing packet) */
> - IP_VS_DBG_BUF(6, "New connection RS-initiated:%c c:%s:%u v:%s:%u "
> - "d:%s:%u conn->flags:%X conn->refcnt:%d\n",
> - ip_vs_fwd_tag(cp),
> - IP_VS_DBG_ADDR(cp->af, &cp->caddr), ntohs(cp->cport),
> - IP_VS_DBG_ADDR(cp->af, &cp->vaddr), ntohs(cp->vport),
> - IP_VS_DBG_ADDR(cp->af, &cp->daddr), ntohs(cp->dport),
> - cp->flags, refcount_read(&cp->refcnt));
> + IP_VS_DBG(6, "New connection RS-initiated:%c c:%pISpc v:%pISpc "
> + "d:%pISp conn->flags:%X conn->refcnt:%d\n",
d:%pISpc
> + ip_vs_fwd_tag(cp),
> + IP_VS_DBG_SOCKADDR(cp->af, &cp->caddr, cp->cport),
> + IP_VS_DBG_SOCKADDR(cp->af, &cp->vaddr, cp->vport),
> + IP_VS_DBG_SOCKADDR(cp->af, &cp->daddr, cp->dport),
> + cp->flags, refcount_read(&cp->refcnt));
> LeaveFunction(12);
> return cp;
> }
> @@ -1969,7 +1968,6 @@ static int ip_vs_in_icmp_v6(struct netns_ipvs *ipvs, struct sk_buff *skb,
> }
> #endif
>
> -
> /*
> * Check if it's for virtual services, look it up,
> * and send it on its way...
> @@ -1998,10 +1996,10 @@ ip_vs_in(struct netns_ipvs *ipvs, unsigned int hooknum, struct sk_buff *skb, int
> hooknum != NF_INET_LOCAL_OUT) ||
> !skb_dst(skb))) {
> ip_vs_fill_iph_skb(af, skb, false, &iph);
> - IP_VS_DBG_BUF(12, "packet type=%d proto=%d daddr=%s"
> + IP_VS_DBG(12, "packet type=%d proto=%d daddr=%pISc"
> " ignored in hook %u\n",
> skb->pkt_type, iph.protocol,
> - IP_VS_DBG_ADDR(af, &iph.daddr), hooknum);
> + IP_VS_DBG_SOCKADDR(af, &iph.daddr, 0), hooknum);
> return NF_ACCEPT;
> }
> /* ipvs enabled in this netns ? */
> diff --git a/net/netfilter/ipvs/ip_vs_ftp.c b/net/netfilter/ipvs/ip_vs_ftp.c
> index cf925906f59b..22099c42e184 100644
> --- a/net/netfilter/ipvs/ip_vs_ftp.c
> +++ b/net/netfilter/ipvs/ip_vs_ftp.c
> @@ -306,9 +306,9 @@ static int ip_vs_ftp_out(struct ip_vs_app *app, struct ip_vs_conn *cp,
> &start, &end) != 1)
> return 1;
>
> - IP_VS_DBG_BUF(7, "EPSV response (%s:%u) -> %s:%u detected\n",
> - IP_VS_DBG_ADDR(cp->af, &from), ntohs(port),
> - IP_VS_DBG_ADDR(cp->af, &cp->caddr), 0);
> + IP_VS_DBG(7, "EPSV response (%pISpc) -> %pISc detected\n",
> + IP_VS_DBG_SOCKADDR(cp->af, &from, port),
> + IP_VS_DBG_SOCKADDR(cp->af, &cp->caddr, 0));
> } else {
> return 1;
> }
> @@ -510,15 +510,15 @@ static int ip_vs_ftp_in(struct ip_vs_app *app, struct ip_vs_conn *cp,
> &to, &port, cp->af,
> &start, &end) == 1) {
>
> - IP_VS_DBG_BUF(7, "EPRT %s:%u detected\n",
> - IP_VS_DBG_ADDR(cp->af, &to), ntohs(port));
> + IP_VS_DBG(7, "EPRT %pISpc detected\n",
> + IP_VS_DBG_SOCKADDR(cp->af, &to, port));
>
> /* Now update or create a connection entry for it */
> - IP_VS_DBG_BUF(7, "protocol %s %s:%u %s:%u\n",
> - ip_vs_proto_name(ipvsh->protocol),
> - IP_VS_DBG_ADDR(cp->af, &to), ntohs(port),
> - IP_VS_DBG_ADDR(cp->af, &cp->vaddr),
> - ntohs(cp->vport)-1);
> + IP_VS_DBG(7, "protocol %s %pISpc %pISpc\n",
> + ip_vs_proto_name(ipvsh->protocol),
> + IP_VS_DBG_SOCKADDR(cp->af, &to, port),
> + IP_VS_DBG_SOCKADDR(cp->af, &cp->vaddr,
> + htons(ntohs(cp->vport)-1)));
> } else {
> return 1;
> }
> --
> 2.20.0
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: Reminder: 99 open syzbot bugs in net subsystem
From: Eric Dumazet @ 2019-07-25 5:04 UTC (permalink / raw)
To: David Miller, eric.dumazet, dvyukov, netdev, fw, i.maximets,
edumazet, dsahern, linux-kernel, syzkaller-bugs
In-Reply-To: <20190724210950.GH213255@gmail.com>
On 7/24/19 11:09 PM, Eric Biggers wrote:
> On Wed, Jul 24, 2019 at 01:09:28PM -0700, David Miller wrote:
>> From: Eric Biggers <ebiggers@kernel.org>
>> Date: Wed, 24 Jul 2019 11:37:12 -0700
>>
>>> We can argue about what words to use to describe this situation, but
>>> it doesn't change the situation itself.
>>
>> And we should argue about those words because it matters to humans and
>> effects how they feel, and humans ultimately fix these bugs.
>>
>> So please stop with the hyperbole.
>>
>> Thank you.
>
> Okay, there are 151 bugs that syzbot saw on the mainline Linux kernel in the
> last 7 days (90.1% with reproducers). Of those, 59 were reported over 3 months
> ago (89.8% with reproducers). Of those, 12 were reported over a year ago (83.3%
> with reproducers).
>
> No opinion on whether those are small/medium/large numbers, in case it would
> hurt someone's feelings.
>
> These numbers do *not* include bugs that are still valid but weren't seen on
> mainline in last 7 days, e.g.:
>
> - Bugs that are seen only rarely, so by chance weren't seen in last 7 days.
> - Bugs only in linux-next and/or subsystem branches.
> - Bugs that were seen in mainline more than 7 days ago, and then only on
> linux-next or subsystem branch in last 7 days.
> - Bugs that stopped being seen due to a change in syzkaller.
> - Bugs that stopped being seen due to a change in kernel config.
> - Bugs that stopped being seen due to other environment changes such as kernel
> command line parameters.
> - Bugs that stopped being seen due to a kernel change that hid the bug but
> didn't actually fix it, i.e. still reachable in other ways.
>
We do not doubt syzkaller is an incredible tool.
But netdev@ and lkml@ are mailing lists for humans to interact,
exchange ideas, send patches and review them.
To me, an issue that was reported to netdev by a real user is _way_ more important
than potential issues that a bot might have found doing crazy things.
We need to keep optimal S/N on mailing lists, so any bots trying to interact
with these lists must be very cautious and damn smart.
When I have time to spare and can work on syzbot reports, I am going to a web
page where I can see them and select the ones it makes sense to fix.
I hate having to set up email filters.
^ permalink raw reply
* [PATCH] hv_sock: use HV_HYP_PAGE_SIZE instead of PAGE_SIZE_4K
From: Himadri Pandya @ 2019-07-25 5:11 UTC (permalink / raw)
To: mikelley, kys, haiyangz, sthemmin, sashal, davem
Cc: linux-hyperv, netdev, linux-kernel, Himadri Pandya
Older windows hosts require the hv_sock ring buffer to be defined
using 4K pages. This was achieved by using the symbol PAGE_SIZE_4K
defined specifically for this purpose. But now we have a new symbol
HV_HYP_PAGE_SIZE defined in hyperv-tlfs which can be used for this.
This patch removes the definition of symbol PAGE_SIZE_4K and replaces
its usage with the symbol HV_HYP_PAGE_SIZE. This patch also aligns
sndbuf and rcvbuf to hyper-v specific page size using HV_HYP_PAGE_SIZE
instead of the guest page size(PAGE_SIZE) as hyper-v expects the page
size to be 4K and it might not be the case on ARM64 architecture.
Signed-off-by: Himadri Pandya <himadri18.07@gmail.com>
---
net/vmw_vsock/hyperv_transport.c | 21 +++++++++++----------
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c
index f2084e3f7aa4..ecb5d72d8010 100644
--- a/net/vmw_vsock/hyperv_transport.c
+++ b/net/vmw_vsock/hyperv_transport.c
@@ -13,15 +13,16 @@
#include <linux/hyperv.h>
#include <net/sock.h>
#include <net/af_vsock.h>
+#include <asm/hyperv-tlfs.h>
/* Older (VMBUS version 'VERSION_WIN10' or before) Windows hosts have some
- * stricter requirements on the hv_sock ring buffer size of six 4K pages. Newer
- * hosts don't have this limitation; but, keep the defaults the same for compat.
+ * stricter requirements on the hv_sock ring buffer size of six 4K pages.
+ * hyperv-tlfs defines HV_HYP_PAGE_SIZE as 4K. Newer hosts don't have this
+ * limitation; but, keep the defaults the same for compat.
*/
-#define PAGE_SIZE_4K 4096
-#define RINGBUFFER_HVS_RCV_SIZE (PAGE_SIZE_4K * 6)
-#define RINGBUFFER_HVS_SND_SIZE (PAGE_SIZE_4K * 6)
-#define RINGBUFFER_HVS_MAX_SIZE (PAGE_SIZE_4K * 64)
+#define RINGBUFFER_HVS_RCV_SIZE (HV_HYP_PAGE_SIZE * 6)
+#define RINGBUFFER_HVS_SND_SIZE (HV_HYP_PAGE_SIZE * 6)
+#define RINGBUFFER_HVS_MAX_SIZE (HV_HYP_PAGE_SIZE * 64)
/* The MTU is 16KB per the host side's design */
#define HVS_MTU_SIZE (1024 * 16)
@@ -54,7 +55,7 @@ struct hvs_recv_buf {
* ringbuffer APIs that allow us to directly copy data from userspace buffer
* to VMBus ringbuffer.
*/
-#define HVS_SEND_BUF_SIZE (PAGE_SIZE_4K - sizeof(struct vmpipe_proto_header))
+#define HVS_SEND_BUF_SIZE (HV_HYP_PAGE_SIZE - sizeof(struct vmpipe_proto_header))
struct hvs_send_buf {
/* The header before the payload data */
@@ -388,10 +389,10 @@ static void hvs_open_connection(struct vmbus_channel *chan)
} else {
sndbuf = max_t(int, sk->sk_sndbuf, RINGBUFFER_HVS_SND_SIZE);
sndbuf = min_t(int, sndbuf, RINGBUFFER_HVS_MAX_SIZE);
- sndbuf = ALIGN(sndbuf, PAGE_SIZE);
+ sndbuf = ALIGN(sndbuf, HV_HYP_PAGE_SIZE);
rcvbuf = max_t(int, sk->sk_rcvbuf, RINGBUFFER_HVS_RCV_SIZE);
rcvbuf = min_t(int, rcvbuf, RINGBUFFER_HVS_MAX_SIZE);
- rcvbuf = ALIGN(rcvbuf, PAGE_SIZE);
+ rcvbuf = ALIGN(rcvbuf, HV_HYP_PAGE_SIZE);
}
ret = vmbus_open(chan, sndbuf, rcvbuf, NULL, 0, hvs_channel_cb,
@@ -662,7 +663,7 @@ static ssize_t hvs_stream_enqueue(struct vsock_sock *vsk, struct msghdr *msg,
ssize_t ret = 0;
ssize_t bytes_written = 0;
- BUILD_BUG_ON(sizeof(*send_buf) != PAGE_SIZE_4K);
+ BUILD_BUG_ON(sizeof(*send_buf) != HV_HYP_PAGE_SIZE);
send_buf = kmalloc(sizeof(*send_buf), GFP_KERNEL);
if (!send_buf)
--
2.17.1
^ permalink raw reply related
* Re: [PATCH bpf-next 01/10] libbpf: add .BTF.ext offset relocation section loading
From: Song Liu @ 2019-07-25 5:20 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Andrii Nakryiko, bpf, Networking, Alexei Starovoitov,
Daniel Borkmann, Yonghong Song, Kernel Team
In-Reply-To: <CAEf4BzZsU8qXa08neQ=nrFFTXpSWsxrZuZz=kVjS2BXNUoofUw@mail.gmail.com>
> On Jul 24, 2019, at 5:37 PM, Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
>
> On Wed, Jul 24, 2019 at 5:00 PM Song Liu <songliubraving@fb.com> wrote:
>>
>>
>>
>>> On Jul 24, 2019, at 12:27 PM, Andrii Nakryiko <andriin@fb.com> wrote:
>>>
>>> Add support for BPF CO-RE offset relocations. Add section/record
>>> iteration macros for .BTF.ext. These macro are useful for iterating over
>>> each .BTF.ext record, either for dumping out contents or later for BPF
>>> CO-RE relocation handling.
>>>
>>> To enable other parts of libbpf to work with .BTF.ext contents, moved
>>> a bunch of type definitions into libbpf_internal.h.
>>>
>>> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
>>> ---
>>> tools/lib/bpf/btf.c | 64 +++++++++--------------
>>> tools/lib/bpf/btf.h | 4 ++
>>> tools/lib/bpf/libbpf_internal.h | 91 +++++++++++++++++++++++++++++++++
>>> 3 files changed, 118 insertions(+), 41 deletions(-)
>>>
>
> [...]
>
>>> +
>>> static int btf_ext_parse_hdr(__u8 *data, __u32 data_size)
>>> {
>>> const struct btf_ext_header *hdr = (struct btf_ext_header *)data;
>>> @@ -1004,6 +979,13 @@ struct btf_ext *btf_ext__new(__u8 *data, __u32 size)
>>> if (err)
>>> goto done;
>>>
>>> + /* check if there is offset_reloc_off/offset_reloc_len fields */
>>> + if (btf_ext->hdr->hdr_len < sizeof(struct btf_ext_header))
>>
>> This check will break when we add more optional sections to btf_ext_header.
>> Maybe use offsetof() instead?
>
> I didn't do it, because there are no fields after offset_reloc_len.
> But now I though that maybe it would be ok to add zero-sized marker
> field, kind of like marking off various versions of btf_ext header?
>
> Alternatively, I can add offsetofend() macro somewhere in libbpf_internal.h.
>
> Do you have any preference?
We only need a stable number to compare against. offsetofend() works.
Or we can simply have something like
if (btf_ext->hdr->hdr_len <= offsetof(struct btf_ext_header, offset_reloc_off))
goto done;
or
if (btf_ext->hdr->hdr_len < offsetof(struct btf_ext_header, offset_reloc_len))
goto done;
Does this make sense?
Thanks,
Song
^ permalink raw reply
* Re: [PATCH 5/6] vhost: mark dirty pages during map uninit
From: Michael S. Tsirkin @ 2019-07-25 5:21 UTC (permalink / raw)
To: Jason Wang; +Cc: kvm, virtualization, netdev, linux-kernel
In-Reply-To: <a670cd0d-581d-1aba-41bd-c643c19f9604@redhat.com>
On Tue, Jul 23, 2019 at 09:19:33PM +0800, Jason Wang wrote:
>
> On 2019/7/23 下午5:17, Michael S. Tsirkin wrote:
> > On Tue, Jul 23, 2019 at 03:57:17AM -0400, Jason Wang wrote:
> > > We don't mark dirty pages if the map was teared down outside MMU
> > > notifier. This will lead untracked dirty pages. Fixing by marking
> > > dirty pages during map uninit.
> > >
> > > Reported-by: Michael S. Tsirkin<mst@redhat.com>
> > > Fixes: 7f466032dc9e ("vhost: access vq metadata through kernel virtual address")
> > > Signed-off-by: Jason Wang<jasowang@redhat.com>
> > > ---
> > > drivers/vhost/vhost.c | 22 ++++++++++++++++------
> > > 1 file changed, 16 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> > > index 89c9f08b5146..5b8821d00fe4 100644
> > > --- a/drivers/vhost/vhost.c
> > > +++ b/drivers/vhost/vhost.c
> > > @@ -306,6 +306,18 @@ static void vhost_map_unprefetch(struct vhost_map *map)
> > > kfree(map);
> > > }
> > > +static void vhost_set_map_dirty(struct vhost_virtqueue *vq,
> > > + struct vhost_map *map, int index)
> > > +{
> > > + struct vhost_uaddr *uaddr = &vq->uaddrs[index];
> > > + int i;
> > > +
> > > + if (uaddr->write) {
> > > + for (i = 0; i < map->npages; i++)
> > > + set_page_dirty(map->pages[i]);
> > > + }
> > > +}
> > > +
> > > static void vhost_uninit_vq_maps(struct vhost_virtqueue *vq)
> > > {
> > > struct vhost_map *map[VHOST_NUM_ADDRS];
> > > @@ -315,8 +327,10 @@ static void vhost_uninit_vq_maps(struct vhost_virtqueue *vq)
> > > for (i = 0; i < VHOST_NUM_ADDRS; i++) {
> > > map[i] = rcu_dereference_protected(vq->maps[i],
> > > lockdep_is_held(&vq->mmu_lock));
> > > - if (map[i])
> > > + if (map[i]) {
> > > + vhost_set_map_dirty(vq, map[i], i);
> > > rcu_assign_pointer(vq->maps[i], NULL);
> > > + }
> > > }
> > > spin_unlock(&vq->mmu_lock);
> > > @@ -354,7 +368,6 @@ static void vhost_invalidate_vq_start(struct vhost_virtqueue *vq,
> > > {
> > > struct vhost_uaddr *uaddr = &vq->uaddrs[index];
> > > struct vhost_map *map;
> > > - int i;
> > > if (!vhost_map_range_overlap(uaddr, start, end))
> > > return;
> > > @@ -365,10 +378,7 @@ static void vhost_invalidate_vq_start(struct vhost_virtqueue *vq,
> > > map = rcu_dereference_protected(vq->maps[index],
> > > lockdep_is_held(&vq->mmu_lock));
> > > if (map) {
> > > - if (uaddr->write) {
> > > - for (i = 0; i < map->npages; i++)
> > > - set_page_dirty(map->pages[i]);
> > > - }
> > > + vhost_set_map_dirty(vq, map, index);
> > > rcu_assign_pointer(vq->maps[index], NULL);
> > > }
> > > spin_unlock(&vq->mmu_lock);
> > OK and the reason it's safe is because the invalidate counter
> > got incremented so we know page will not get mapped again.
> >
> > But we*do* need to wait for page not to be mapped.
> > And if that means waiting for VQ processing to finish,
> > then I worry that is a very log time.
> >
>
> I'm not sure I get you here. If we don't have such map, we will fall back to
> normal uaccess helper. And in the memory accessor, the rcu critical section
> is pretty small.
>
> Thanks
>
OK. So the trick is that page_mkclean invokes mmu notifiers.
--
MST
^ permalink raw reply
* Re: general protection fault in rose_transmit_clear_request
From: Dmitry Vyukov @ 2019-07-25 5:30 UTC (permalink / raw)
To: syzbot, Ralf Baechle, David Miller, linux-hams, netdev
Cc: LKML, syzkaller-bugs
In-Reply-To: <0000000000004f0309058e722b24@google.com>
On Wed, Jul 24, 2019 at 9:18 PM syzbot
<syzbot+a1c743815982d9496393@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: c6dd78fc Merge branch 'x86-urgent-for-linus' of git://git...
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=10656fa4600000
> kernel config: https://syzkaller.appspot.com/x/.config?x=7937b718ddac333b
> dashboard link: https://syzkaller.appspot.com/bug?extid=a1c743815982d9496393
> compiler: clang version 9.0.0 (/home/glider/llvm/clang
> 80fee25776c2fb61e74c1ecb1a523375c2500b69)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16f6d348600000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12cad91fa00000
>
> Bisection is inconclusive: the bug happens on the oldest tested release.
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1164f2f4600000
> console output: https://syzkaller.appspot.com/x/log.txt?x=1564f2f4600000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+a1c743815982d9496393@syzkaller.appspotmail.com
+net/rose/rose_link.c maintainers
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault: 0000 [#1] SMP KASAN
> CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.2.0+ #37
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:rose_send_frame /net/rose/rose_link.c:101 [inline]
> RIP: 0010:rose_transmit_clear_request+0x1ee/0x460 /net/rose/rose_link.c:255
> Code: fc ff df 80 3c 08 00 74 12 4c 89 f7 e8 8b 57 dd fa 48 b9 00 00 00 00
> 00 fc ff df bb 50 03 00 00 49 03 1e 48 89 d8 48 c1 e8 03 <80> 3c 08 00 74
> 12 48 89 df e8 64 57 dd fa 48 b9 00 00 00 00 00 fc
> RSP: 0018:ffff8880aeb09a28 EFLAGS: 00010206
> RAX: 000000000000006a RBX: 0000000000000350 RCX: dffffc0000000000
> RDX: 0000000080000101 RSI: 0000000000000000 RDI: 0000000000000000
> RBP: ffff8880aeb09a70 R08: ffffffff86d3c4c5 R09: ffffed101255690d
> R10: ffffed101255690d R11: 0000000000000000 R12: ffff8882167bec80
> R13: ffff888092ab47dc R14: ffff8882167beca0 R15: ffff888092ab47de
> FS: 0000000000000000(0000) GS:ffff8880aeb00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000020000190 CR3: 000000009c1e1000 CR4: 00000000001406e0
> Call Trace:
> <IRQ>
> rose_rx_call_request+0xadb/0x1b00 /net/rose/af_rose.c:998
> rose_loopback_timer+0x2f8/0x480 /net/rose/rose_loopback.c:100
> call_timer_fn+0xec/0x200 /kernel/time/timer.c:1322
> expire_timers /kernel/time/timer.c:1366 [inline]
> __run_timers+0x7cd/0x9c0 /kernel/time/timer.c:1685
> run_timer_softirq+0x1d/0x40 /kernel/time/timer.c:1698
> __do_softirq+0x307/0x774 /./arch/x86/include/asm/paravirt.h:778
> invoke_softirq /kernel/softirq.c:373 [inline]
> irq_exit+0x1e9/0x1f0 /kernel/softirq.c:413
> exiting_irq /./arch/x86/include/asm/apic.h:537 [inline]
> smp_apic_timer_interrupt+0xcc/0x220 /arch/x86/kernel/apic/apic.c:1095
> apic_timer_interrupt+0xf/0x20 /arch/x86/entry/entry_64.S:828
> </IRQ>
> RIP: 0010:native_safe_halt+0xe/0x10 /./arch/x86/include/asm/irqflags.h:61
> Code: 38 46 0a fa eb ae 89 d9 80 e1 07 80 c1 03 38 c1 7c ba 48 89 df e8 22
> 46 0a fa eb b0 e9 07 00 00 00 0f 00 2d e6 b0 5b 00 fb f4 <c3> 90 e9 07 00
> 00 00 0f 00 2d d6 b0 5b 00 f4 c3 90 90 55 48 89 e5
> RSP: 0018:ffff8880a98c7d38 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13
> RAX: 1ffffffff11950f3 RBX: ffff8880a98bc340 RCX: dffffc0000000000
> RDX: 0000000000000000 RSI: ffffffff812cd3ea RDI: ffff8880a98bcb38
> RBP: ffff8880a98c7d40 R08: ffff8880a98bcb50 R09: ffffed1015317869
> R10: ffffed1015317869 R11: 0000000000000000 R12: 1ffff11015317868
> R13: 0000000000000001 R14: dffffc0000000000 R15: 1ffffffff11950f1
> arch_cpu_idle+0xa/0x10 /arch/x86/kernel/process.c:571
> default_idle_call+0x59/0xa0 /kernel/sched/idle.c:94
> cpuidle_idle_call /kernel/sched/idle.c:154 [inline]
> do_idle+0x174/0x770 /kernel/sched/idle.c:263
> cpu_startup_entry+0x25/0x30 /kernel/sched/idle.c:354
> start_secondary+0x3f4/0x490 /arch/x86/kernel/smpboot.c:264
> secondary_startup_64+0xa4/0xb0 /arch/x86/kernel/head_64.S:241
> Modules linked in:
> ---[ end trace fd2ad3b72484e5c3 ]---
> RIP: 0010:rose_send_frame /net/rose/rose_link.c:101 [inline]
> RIP: 0010:rose_transmit_clear_request+0x1ee/0x460 /net/rose/rose_link.c:255
> Code: fc ff df 80 3c 08 00 74 12 4c 89 f7 e8 8b 57 dd fa 48 b9 00 00 00 00
> 00 fc ff df bb 50 03 00 00 49 03 1e 48 89 d8 48 c1 e8 03 <80> 3c 08 00 74
> 12 48 89 df e8 64 57 dd fa 48 b9 00 00 00 00 00 fc
> RSP: 0018:ffff8880aeb09a28 EFLAGS: 00010206
> RAX: 000000000000006a RBX: 0000000000000350 RCX: dffffc0000000000
> RDX: 0000000080000101 RSI: 0000000000000000 RDI: 0000000000000000
> RBP: ffff8880aeb09a70 R08: ffffffff86d3c4c5 R09: ffffed101255690d
> R10: ffffed101255690d R11: 0000000000000000 R12: ffff8882167bec80
> R13: ffff888092ab47dc R14: ffff8882167beca0 R15: ffff888092ab47de
> FS: 0000000000000000(0000) GS:ffff8880aeb00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000020000190 CR3: 000000009c1e1000 CR4: 00000000001406e0
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/0000000000004f0309058e722b24%40google.com.
^ permalink raw reply
* KASAN: use-after-free Read in tls_sk_proto_cleanup
From: syzbot @ 2019-07-25 5:32 UTC (permalink / raw)
To: aviadye, borisp, daniel, davejwatson, davem, john.fastabend,
linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 9e6dfe80 Add linux-next specific files for 20190724
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=16797ef0600000
kernel config: https://syzkaller.appspot.com/x/.config?x=6cbb8fc2cf2842d7
dashboard link: https://syzkaller.appspot.com/bug?extid=42f653cb62d6b4f1c97b
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+42f653cb62d6b4f1c97b@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: use-after-free in tls_sk_proto_cleanup+0x37f/0x3e0
net/tls/tls_main.c:299
Read of size 1 at addr ffff88808adaacd4 by task syz-executor.2/10709
CPU: 1 PID: 10709 Comm: syz-executor.2 Not tainted 5.3.0-rc1-next-20190724
#50
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
print_address_description.cold+0xd4/0x306 mm/kasan/report.c:351
__kasan_report.cold+0x1b/0x36 mm/kasan/report.c:482
kasan_report+0x12/0x17 mm/kasan/common.c:612
__asan_report_load1_noabort+0x14/0x20 mm/kasan/generic_report.c:129
tls_sk_proto_cleanup+0x37f/0x3e0 net/tls/tls_main.c:299
tls_sk_proto_unhash+0x90/0x3f0 net/tls/tls_main.c:330
tcp_set_state+0x5b9/0x7d0 net/ipv4/tcp.c:2235
tcp_done+0xe2/0x320 net/ipv4/tcp.c:3824
tcp_reset+0x132/0x500 net/ipv4/tcp_input.c:4080
tcp_validate_incoming+0xa2d/0x1660 net/ipv4/tcp_input.c:5440
tcp_rcv_established+0x6b5/0x1e70 net/ipv4/tcp_input.c:5648
tcp_v6_do_rcv+0x41e/0x12c0 net/ipv6/tcp_ipv6.c:1356
sk_backlog_rcv include/net/sock.h:945 [inline]
__release_sock+0x129/0x390 net/core/sock.c:2418
release_sock+0x59/0x1c0 net/core/sock.c:2934
sk_stream_wait_memory+0x65a/0xfc0 net/core/stream.c:149
tls_sw_sendmsg+0x673/0x17b0 net/tls/tls_sw.c:1054
inet6_sendmsg+0x9e/0xe0 net/ipv6/af_inet6.c:576
sock_sendmsg_nosec net/socket.c:637 [inline]
sock_sendmsg+0xd7/0x130 net/socket.c:657
__sys_sendto+0x262/0x380 net/socket.c:1952
__do_sys_sendto net/socket.c:1964 [inline]
__se_sys_sendto net/socket.c:1960 [inline]
__x64_sys_sendto+0xe1/0x1a0 net/socket.c:1960
do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x459829
Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f9e6411bc78 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 0000000000459829
RDX: ffffffffffffffc1 RSI: 00000000200005c0 RDI: 0000000000000005
RBP: 000000000075bf20 R08: 0000000000000000 R09: 1201000000003618
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f9e6411c6d4
R13: 00000000004c7669 R14: 00000000004dcc70 R15: 00000000ffffffff
Allocated by task 10709:
save_stack+0x23/0x90 mm/kasan/common.c:69
set_track mm/kasan/common.c:77 [inline]
__kasan_kmalloc mm/kasan/common.c:487 [inline]
__kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:460
kasan_kmalloc+0x9/0x10 mm/kasan/common.c:501
kmem_cache_alloc_trace+0x158/0x790 mm/slab.c:3550
kmalloc include/linux/slab.h:552 [inline]
kzalloc include/linux/slab.h:748 [inline]
create_ctx+0x46/0x260 net/tls/tls_main.c:657
tls_init net/tls/tls_main.c:851 [inline]
tls_init+0x134/0x560 net/tls/tls_main.c:830
__tcp_set_ulp net/ipv4/tcp_ulp.c:139 [inline]
tcp_set_ulp+0x330/0x640 net/ipv4/tcp_ulp.c:160
do_tcp_setsockopt.isra.0+0x363/0x24f0 net/ipv4/tcp.c:2810
tcp_setsockopt+0xbe/0xe0 net/ipv4/tcp.c:3137
sock_common_setsockopt+0x94/0xd0 net/core/sock.c:3130
__sys_setsockopt+0x261/0x4c0 net/socket.c:2084
__do_sys_setsockopt net/socket.c:2100 [inline]
__se_sys_setsockopt net/socket.c:2097 [inline]
__x64_sys_setsockopt+0xbe/0x150 net/socket.c:2097
do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 16209:
save_stack+0x23/0x90 mm/kasan/common.c:69
set_track mm/kasan/common.c:77 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/common.c:449
kasan_slab_free+0xe/0x10 mm/kasan/common.c:457
__cache_free mm/slab.c:3425 [inline]
kfree+0x10a/0x2c0 mm/slab.c:3756
tls_ctx_free.part.0+0x3a/0x40 net/tls/tls_main.c:261
tls_ctx_free net/tls/tls_main.c:256 [inline]
tls_ctx_free_deferred+0x9f/0x130 net/tls/tls_main.c:282
process_one_work+0x9af/0x1740 kernel/workqueue.c:2269
worker_thread+0x98/0xe40 kernel/workqueue.c:2415
kthread+0x361/0x430 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
The buggy address belongs to the object at ffff88808adaacc0
which belongs to the cache kmalloc-512 of size 512
The buggy address is located 20 bytes inside of
512-byte region [ffff88808adaacc0, ffff88808adaaec0)
The buggy address belongs to the page:
page:ffffea00022b6a80 refcount:1 mapcount:0 mapping:ffff8880aa400a80
index:0xffff88808adaa540
flags: 0x1fffc0000000200(slab)
raw: 01fffc0000000200 ffffea0002617408 ffffea00024ed248 ffff8880aa400a80
raw: ffff88808adaa540 ffff88808adaa040 0000000100000005 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88808adaab80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88808adaac00: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
> ffff88808adaac80: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
^
ffff88808adaad00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88808adaad80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
^ permalink raw reply
* general protection fault in tls_trim_both_msgs
From: syzbot @ 2019-07-25 5:32 UTC (permalink / raw)
To: ast, aviadye, borisp, bpf, daniel, davejwatson, davem,
john.fastabend, kafai, linux-kernel, netdev, songliubraving,
syzkaller-bugs, yhs
Hello,
syzbot found the following crash on:
HEAD commit: 9e6dfe80 Add linux-next specific files for 20190724
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1046971fa00000
kernel config: https://syzkaller.appspot.com/x/.config?x=6cbb8fc2cf2842d7
dashboard link: https://syzkaller.appspot.com/bug?extid=0e0fedcad708d12d3032
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+0e0fedcad708d12d3032@syzkaller.appspotmail.com
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 15517 Comm: syz-executor.4 Not tainted 5.3.0-rc1-next-20190724
#50
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:tls_trim_both_msgs+0x54/0x130 net/tls/tls_sw.c:268
Code: 48 c1 ea 03 80 3c 02 00 0f 85 e3 00 00 00 4d 8b b5 b0 06 00 00 48 b8
00 00 00 00 00 fc ff df 49 8d 7e 28 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f
85 b3 00 00 00 48 b8 00 00 00 00 00 fc ff df 49 8b
RSP: 0018:ffff8880612cfac0 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: ffff8880a8794340 RCX: ffffc9000e7b9000
RDX: 0000000000000005 RSI: ffffffff86298656 RDI: 0000000000000028
RBP: ffff8880612cfae0 R08: ffff88805ae4c580 R09: fffffbfff14a8155
R10: fffffbfff14a8154 R11: ffffffff8a540aa7 R12: 0000000000000000
R13: ffff888061d82e00 R14: 0000000000000000 R15: 00000000ffffffe0
FS: 00007f7d33516700(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b2fa2f000 CR3: 000000009fcf1000 CR4: 00000000001406e0
Call Trace:
tls_sw_sendmsg+0xe38/0x17b0 net/tls/tls_sw.c:1057
inet6_sendmsg+0x9e/0xe0 net/ipv6/af_inet6.c:576
sock_sendmsg_nosec net/socket.c:637 [inline]
sock_sendmsg+0xd7/0x130 net/socket.c:657
__sys_sendto+0x262/0x380 net/socket.c:1952
__do_sys_sendto net/socket.c:1964 [inline]
__se_sys_sendto net/socket.c:1960 [inline]
__x64_sys_sendto+0xe1/0x1a0 net/socket.c:1960
do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x459829
Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f7d33515c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 0000000000459829
RDX: ffffffffffffffc1 RSI: 00000000200005c0 RDI: 0000000000000003
RBP: 000000000075bf20 R08: 0000000000000000 R09: 1201000000003618
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f7d335166d4
R13: 00000000004c7669 R14: 00000000004dcc70 R15: 00000000ffffffff
Modules linked in:
---[ end trace 2dd728cceb39a185 ]---
RIP: 0010:tls_trim_both_msgs+0x54/0x130 net/tls/tls_sw.c:268
Code: 48 c1 ea 03 80 3c 02 00 0f 85 e3 00 00 00 4d 8b b5 b0 06 00 00 48 b8
00 00 00 00 00 fc ff df 49 8d 7e 28 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f
85 b3 00 00 00 48 b8 00 00 00 00 00 fc ff df 49 8b
RSP: 0018:ffff8880612cfac0 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: ffff8880a8794340 RCX: ffffc9000e7b9000
RDX: 0000000000000005 RSI: ffffffff86298656 RDI: 0000000000000028
RBP: ffff8880612cfae0 R08: ffff88805ae4c580 R09: fffffbfff14a8155
R10: fffffbfff14a8154 R11: ffffffff8a540aa7 R12: 0000000000000000
R13: ffff888061d82e00 R14: 0000000000000000 R15: 00000000ffffffe0
FS: 00007f7d33516700(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000019dbe80 CR3: 000000009fcf1000 CR4: 00000000001406e0
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
^ permalink raw reply
* Re: [PATCH bpf-next 5/7] sefltests/bpf: support FLOW_DISSECTOR_F_PARSE_1ST_FRAG
From: Song Liu @ 2019-07-25 5:36 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: Stanislav Fomichev, Networking, bpf, David S . Miller,
Alexei Starovoitov, Daniel Borkmann, Willem de Bruijn,
Petar Penkov
In-Reply-To: <20190724235254.GB3500@mini-arch>
On Wed, Jul 24, 2019 at 4:52 PM Stanislav Fomichev <sdf@fomichev.me> wrote:
>
> On 07/24, Song Liu wrote:
> > On Wed, Jul 24, 2019 at 10:11 AM Stanislav Fomichev <sdf@google.com> wrote:
> > >
> > > bpf_flow.c: exit early unless FLOW_DISSECTOR_F_PARSE_1ST_FRAG is passed
> > > in flags. Also, set ip_proto earlier, this makes sure we have correct
> > > value with fragmented packets.
> > >
> > > Add selftest cases to test ipv4/ipv6 fragments and skip eth_get_headlen
> > > tests that don't have FLOW_DISSECTOR_F_PARSE_1ST_FRAG flag.
> > >
> > > eth_get_headlen calls flow dissector with
> > > FLOW_DISSECTOR_F_PARSE_1ST_FRAG flag so we can't run tests that
> > > have different set of input flags against it.
> > >
> > > Cc: Willem de Bruijn <willemb@google.com>
> > > Cc: Petar Penkov <ppenkov@google.com>
> > > Signed-off-by: Stanislav Fomichev <sdf@google.com>
> > > ---
> > > .../selftests/bpf/prog_tests/flow_dissector.c | 129 ++++++++++++++++++
> > > tools/testing/selftests/bpf/progs/bpf_flow.c | 28 +++-
> > > 2 files changed, 151 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/tools/testing/selftests/bpf/prog_tests/flow_dissector.c b/tools/testing/selftests/bpf/prog_tests/flow_dissector.c
> > > index c938283ac232..966cb3b06870 100644
> > > --- a/tools/testing/selftests/bpf/prog_tests/flow_dissector.c
> > > +++ b/tools/testing/selftests/bpf/prog_tests/flow_dissector.c
> > > @@ -5,6 +5,10 @@
> > > #include <linux/if_tun.h>
> > > #include <sys/uio.h>
> > >
> > > +#ifndef IP_MF
> > > +#define IP_MF 0x2000
> > > +#endif
> > > +
> > > #define CHECK_FLOW_KEYS(desc, got, expected) \
> > > CHECK_ATTR(memcmp(&got, &expected, sizeof(got)) != 0, \
> > > desc, \
> > > @@ -49,6 +53,18 @@ struct ipv6_pkt {
> > > struct tcphdr tcp;
> > > } __packed;
> > >
> > > +struct ipv6_frag_pkt {
> > > + struct ethhdr eth;
> > > + struct ipv6hdr iph;
> > > + struct frag_hdr {
> > > + __u8 nexthdr;
> > > + __u8 reserved;
> > > + __be16 frag_off;
> > > + __be32 identification;
> > > + } ipf;
> > > + struct tcphdr tcp;
> > > +} __packed;
> > > +
> > > struct dvlan_ipv6_pkt {
> > > struct ethhdr eth;
> > > __u16 vlan_tci;
> > > @@ -65,9 +81,11 @@ struct test {
> > > struct ipv4_pkt ipv4;
> > > struct svlan_ipv4_pkt svlan_ipv4;
> > > struct ipv6_pkt ipv6;
> > > + struct ipv6_frag_pkt ipv6_frag;
> > > struct dvlan_ipv6_pkt dvlan_ipv6;
> > > } pkt;
> > > struct bpf_flow_keys keys;
> > > + __u32 flags;
> > > };
> > >
> > > #define VLAN_HLEN 4
> > > @@ -143,6 +161,102 @@ struct test tests[] = {
> > > .n_proto = __bpf_constant_htons(ETH_P_IPV6),
> > > },
> > > },
> > > + {
> > > + .name = "ipv4-frag",
> > > + .pkt.ipv4 = {
> > > + .eth.h_proto = __bpf_constant_htons(ETH_P_IP),
> > > + .iph.ihl = 5,
> > > + .iph.protocol = IPPROTO_TCP,
> > > + .iph.tot_len = __bpf_constant_htons(MAGIC_BYTES),
> > > + .iph.frag_off = __bpf_constant_htons(IP_MF),
> > > + .tcp.doff = 5,
> > > + .tcp.source = 80,
> > > + .tcp.dest = 8080,
> > > + },
> > > + .keys = {
> > > + .flags = FLOW_DISSECTOR_F_PARSE_1ST_FRAG,
> > > + .nhoff = ETH_HLEN,
> > > + .thoff = ETH_HLEN + sizeof(struct iphdr),
> > > + .addr_proto = ETH_P_IP,
> > > + .ip_proto = IPPROTO_TCP,
> > > + .n_proto = __bpf_constant_htons(ETH_P_IP),
> > > + .is_frag = true,
> > > + .is_first_frag = true,
> > > + .sport = 80,
> > > + .dport = 8080,
> > > + },
> > > + .flags = FLOW_DISSECTOR_F_PARSE_1ST_FRAG,
> > > + },
> > > + {
> > > + .name = "ipv4-no-frag",
> > > + .pkt.ipv4 = {
> > > + .eth.h_proto = __bpf_constant_htons(ETH_P_IP),
> > > + .iph.ihl = 5,
> > > + .iph.protocol = IPPROTO_TCP,
> > > + .iph.tot_len = __bpf_constant_htons(MAGIC_BYTES),
> > > + .iph.frag_off = __bpf_constant_htons(IP_MF),
> > > + .tcp.doff = 5,
> > > + .tcp.source = 80,
> > > + .tcp.dest = 8080,
> > > + },
> > > + .keys = {
> > > + .nhoff = ETH_HLEN,
> > > + .thoff = ETH_HLEN + sizeof(struct iphdr),
> > > + .addr_proto = ETH_P_IP,
> > > + .ip_proto = IPPROTO_TCP,
> > > + .n_proto = __bpf_constant_htons(ETH_P_IP),
> > > + .is_frag = true,
> > > + .is_first_frag = true,
> > > + },
> > > + },
> > > + {
> > > + .name = "ipv6-frag",
> > > + .pkt.ipv6_frag = {
> > > + .eth.h_proto = __bpf_constant_htons(ETH_P_IPV6),
> > > + .iph.nexthdr = IPPROTO_FRAGMENT,
> > > + .iph.payload_len = __bpf_constant_htons(MAGIC_BYTES),
> > > + .ipf.nexthdr = IPPROTO_TCP,
> > > + .tcp.doff = 5,
> > > + .tcp.source = 80,
> > > + .tcp.dest = 8080,
> > > + },
> > > + .keys = {
> > > + .flags = FLOW_DISSECTOR_F_PARSE_1ST_FRAG,
> > > + .nhoff = ETH_HLEN,
> > > + .thoff = ETH_HLEN + sizeof(struct ipv6hdr) +
> > > + sizeof(struct frag_hdr),
> > > + .addr_proto = ETH_P_IPV6,
> > > + .ip_proto = IPPROTO_TCP,
> > > + .n_proto = __bpf_constant_htons(ETH_P_IPV6),
> > > + .is_frag = true,
> > > + .is_first_frag = true,
> > > + .sport = 80,
> > > + .dport = 8080,
> > > + },
> > > + .flags = FLOW_DISSECTOR_F_PARSE_1ST_FRAG,
> > > + },
> > > + {
> > > + .name = "ipv6-no-frag",
> > > + .pkt.ipv6_frag = {
> > > + .eth.h_proto = __bpf_constant_htons(ETH_P_IPV6),
> > > + .iph.nexthdr = IPPROTO_FRAGMENT,
> > > + .iph.payload_len = __bpf_constant_htons(MAGIC_BYTES),
> > > + .ipf.nexthdr = IPPROTO_TCP,
> > > + .tcp.doff = 5,
> > > + .tcp.source = 80,
> > > + .tcp.dest = 8080,
> > > + },
> > > + .keys = {
> > > + .nhoff = ETH_HLEN,
> > > + .thoff = ETH_HLEN + sizeof(struct ipv6hdr) +
> > > + sizeof(struct frag_hdr),
> > > + .addr_proto = ETH_P_IPV6,
> > > + .ip_proto = IPPROTO_TCP,
> > > + .n_proto = __bpf_constant_htons(ETH_P_IPV6),
> > > + .is_frag = true,
> > > + .is_first_frag = true,
> > > + },
> > > + },
> > > };
> > >
> > > static int create_tap(const char *ifname)
> > > @@ -225,6 +339,13 @@ void test_flow_dissector(void)
> > > .data_size_in = sizeof(tests[i].pkt),
> > > .data_out = &flow_keys,
> > > };
> > > + static struct bpf_flow_keys ctx = {};
> > > +
> > > + if (tests[i].flags) {
> > > + tattr.ctx_in = &ctx;
> > > + tattr.ctx_size_in = sizeof(ctx);
> > > + ctx.flags = tests[i].flags;
> > > + }
> > >
> > > err = bpf_prog_test_run_xattr(&tattr);
> > > CHECK_ATTR(tattr.data_size_out != sizeof(flow_keys) ||
> > > @@ -255,6 +376,14 @@ void test_flow_dissector(void)
> > > struct bpf_prog_test_run_attr tattr = {};
> > > __u32 key = 0;
> > >
> > > + /* Don't run tests that are not marked as
> > > + * FLOW_DISSECTOR_F_PARSE_1ST_FRAG; eth_get_headlen
> > > + * sets this flag.
> > > + */
> > > +
> > > + if (tests[i].flags != FLOW_DISSECTOR_F_PARSE_1ST_FRAG)
> > > + continue;
> >
> > Maybe test flags & FLOW_DISSECTOR_F_PARSE_1ST_FRAG == 0 instead?
> > It is not necessary now, but might be useful in the future.
> I'm not sure about this one. We want flags here to match flags
> from eth_get_headlen:
>
> const unsigned int flags = FLOW_DISSECTOR_F_PARSE_1ST_FRAG;
> ...
> if (!skb_flow_dissect_flow_keys_basic(..., flags))
>
> Otherwise the test might break unexpectedly. So I'd rather manually
> adjust a test here if eth_get_headlen flags change.
Could we have
flags == FLOW_DISSECTOR_F_PARSE_1ST_FRAG | some_other_flag
in the future? This flag is not equal to FLOW_DISSECTOR_F_PARSE_1ST_FRAG.
>
> Maybe I should clarify the comment to signify that dependency? Because
> currently it might be read as if we only care about
> FLOW_DISSECTOR_F_PARSE_1ST_FRAG, but we really care about all flags
> in eth_get_headlen; it just happens that it only has one right now.
Some clarification will be great.
Thanks,
Song
^ permalink raw reply
* Re: [PATCH v2 2/2] mwifiex: Make use of the new sdio_trigger_replug() API to reset
From: Kalle Valo @ 2019-07-25 5:56 UTC (permalink / raw)
To: Doug Anderson
Cc: Ulf Hansson, Adrian Hunter, Ganapathi Bhat, linux-wireless,
Andreas Fenkart, Brian Norris, Amitkumar Karwar,
open list:ARM/Rockchip SoC..., Wolfram Sang, Nishant Sarmukadam,
netdev, Avri Altman, Linux MMC List, David Miller, Xinming Hu,
LKML
In-Reply-To: <CAD=FV=WAsrBV9PzUz1qPzQru+AkOYZ5hsaWdhNYRTNqUfDeOmQ@mail.gmail.com>
Doug Anderson <dianders@chromium.org> writes:
> Hi,
>
> On Wed, Jul 24, 2019 at 4:35 AM Kalle Valo <kvalo@codeaurora.org> wrote:
>>
>> Douglas Anderson <dianders@chromium.org> wrote:
>>
>> > As described in the patch ("mmc: core: Add sdio_trigger_replug()
>> > API"), the current mwifiex_sdio_card_reset() is broken in the cases
>> > where we're running Bluetooth on a second SDIO func on the same card
>> > as WiFi. The problem goes away if we just use the
>> > sdio_trigger_replug() API call.
>> >
>> > NOTE: Even though with this new solution there is less of a reason to
>> > do our work from a workqueue (the unplug / plug mechanism we're using
>> > is possible for a human to perform at any time so the stack is
>> > supposed to handle it without it needing to be called from a special
>> > context), we still need a workqueue because the Marvell reset function
>> > could called from a context where sleeping is invalid and thus we
>> > can't claim the host. One example is Marvell's wakeup_timer_fn().
>> >
>> > Cc: Andreas Fenkart <afenkart@gmail.com>
>> > Cc: Brian Norris <briannorris@chromium.org>
>> > Fixes: b4336a282db8 ("mwifiex: sdio: reset adapter using mmc_hw_reset")
>> > Signed-off-by: Douglas Anderson <dianders@chromium.org>
>> > Reviewed-by: Brian Norris <briannorris@chromium.org>
>>
>> I assume this is going via some other tree so I'm dropping this from my
>> queue. If I should apply this please resend once the dependency is in
>> wireless-drivers-next.
>>
>> Patch set to Not Applicable.
>
> Thanks. For now I'll assume that Ulf will pick it up if/when he is
> happy with patch #1 in this series. Would you be willing to provide
> your Ack on this patch to make it clear to Ulf you're OK with that?
Sure, I was planning to do that already in my previous email but forgot.
Acked-by: Kalle Valo <kvalo@codeaurora.org>
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 4.4 stable net] net: tcp: Fix use-after-free in tcp_write_xmit
From: Eric Dumazet @ 2019-07-25 6:19 UTC (permalink / raw)
To: maowenan, Eric Dumazet, davem, gregkh, netdev, linux-kernel
In-Reply-To: <9a8d6a5a-9a9d-9cb5-caa9-5c12ba04a43c@huawei.com>
On 7/25/19 6:29 AM, maowenan wrote:
>
>>>>> 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)
>>>>>
>>
>> It does call tcp_disconnect(), by one of the connect() call.
>
> yes, __inet_stream_connect will call tcp_disconnect when sa_family == AF_UNSPEC, in c repro if it
> passes sa_family with AF_INET it won't call disconnect, and then sk_send_head won't be NULL when tcp_connect.
>
Look again at the Syzkaller reproducer()
It definitely uses tcp_disconnect()
Do not be fooled by connect$unix(), this is a connect() call really, with AF_UNSPEC
^ permalink raw reply
* [PATCH] ath10k: Fix HOST capability QMI incompatibility
From: Bjorn Andersson @ 2019-07-25 6:31 UTC (permalink / raw)
To: Kalle Valo, David S. Miller, Rob Herring, Mark Rutland
Cc: linux-wireless, netdev, devicetree, linux-kernel, ath10k, stable
The introduction of 768ec4c012ac ("ath10k: update HOST capability QMI
message") served the purpose of supporting the new and extended HOST
capability QMI message.
But while the new message adds a slew of optional members it changes the
data type of the "daemon_support" member, which means that older
versions of the firmware will fail to decode the incoming request
message.
There is no way to detect this breakage from Linux and there's no way to
recover from sending the wrong message (i.e. we can't just try one
format and then fallback to the other), so a quirk is introduced in
DeviceTree to indicate to the driver that the firmware requires the 8bit
version of this message.
Cc: stable@vger.kernel.org
Fixes: 768ec4c012ac ("ath10k: update HOST capability qmi message")
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
.../bindings/net/wireless/qcom,ath10k.txt | 6 +++++
drivers/net/wireless/ath/ath10k/qmi.c | 13 ++++++++---
.../net/wireless/ath/ath10k/qmi_wlfw_v01.c | 22 +++++++++++++++++++
.../net/wireless/ath/ath10k/qmi_wlfw_v01.h | 1 +
drivers/net/wireless/ath/ath10k/snoc.c | 11 ++++++++++
drivers/net/wireless/ath/ath10k/snoc.h | 1 +
6 files changed, 51 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
index ae661e65354e..f9499b20d840 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
@@ -81,6 +81,12 @@ Optional properties:
Definition: Name of external front end module used. Some valid FEM names
for example: "microsemi-lx5586", "sky85703-11"
and "sky85803" etc.
+- qcom,snoc-host-cap-8bit-quirk:
+ Usage: Optional
+ Value type: <empty>
+ Definition: Quirk specifying that the firmware expects the 8bit version
+ of the host capability QMI request
+
Example (to supply PCI based wifi block details):
diff --git a/drivers/net/wireless/ath/ath10k/qmi.c b/drivers/net/wireless/ath/ath10k/qmi.c
index 3b63b6257c43..545ac1f06997 100644
--- a/drivers/net/wireless/ath/ath10k/qmi.c
+++ b/drivers/net/wireless/ath/ath10k/qmi.c
@@ -581,22 +581,29 @@ static int ath10k_qmi_host_cap_send_sync(struct ath10k_qmi *qmi)
{
struct wlfw_host_cap_resp_msg_v01 resp = {};
struct wlfw_host_cap_req_msg_v01 req = {};
+ struct qmi_elem_info *req_ei;
struct ath10k *ar = qmi->ar;
+ struct ath10k_snoc *ar_snoc = ath10k_snoc_priv(ar);
struct qmi_txn txn;
int ret;
req.daemon_support_valid = 1;
req.daemon_support = 0;
- ret = qmi_txn_init(&qmi->qmi_hdl, &txn,
- wlfw_host_cap_resp_msg_v01_ei, &resp);
+ ret = qmi_txn_init(&qmi->qmi_hdl, &txn, wlfw_host_cap_resp_msg_v01_ei,
+ &resp);
if (ret < 0)
goto out;
+ if (test_bit(ATH10K_SNOC_FLAG_8BIT_HOST_CAP_QUIRK, &ar_snoc->flags))
+ req_ei = wlfw_host_cap_8bit_req_msg_v01_ei;
+ else
+ req_ei = wlfw_host_cap_req_msg_v01_ei;
+
ret = qmi_send_request(&qmi->qmi_hdl, NULL, &txn,
QMI_WLFW_HOST_CAP_REQ_V01,
WLFW_HOST_CAP_REQ_MSG_V01_MAX_MSG_LEN,
- wlfw_host_cap_req_msg_v01_ei, &req);
+ req_ei, &req);
if (ret < 0) {
qmi_txn_cancel(&txn);
ath10k_err(ar, "failed to send host capability request: %d\n", ret);
diff --git a/drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.c b/drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.c
index 1fe05c6218c3..86fcf4e1de5f 100644
--- a/drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.c
+++ b/drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.c
@@ -1988,6 +1988,28 @@ struct qmi_elem_info wlfw_host_cap_req_msg_v01_ei[] = {
{}
};
+struct qmi_elem_info wlfw_host_cap_8bit_req_msg_v01_ei[] = {
+ {
+ .data_type = QMI_OPT_FLAG,
+ .elem_len = 1,
+ .elem_size = sizeof(u8),
+ .array_type = NO_ARRAY,
+ .tlv_type = 0x10,
+ .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
+ daemon_support_valid),
+ },
+ {
+ .data_type = QMI_UNSIGNED_1_BYTE,
+ .elem_len = 1,
+ .elem_size = sizeof(u8),
+ .array_type = NO_ARRAY,
+ .tlv_type = 0x10,
+ .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
+ daemon_support),
+ },
+ {}
+};
+
struct qmi_elem_info wlfw_host_cap_resp_msg_v01_ei[] = {
{
.data_type = QMI_STRUCT,
diff --git a/drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.h b/drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.h
index bca1186e1560..4d107e1364a8 100644
--- a/drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.h
+++ b/drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.h
@@ -575,6 +575,7 @@ struct wlfw_host_cap_req_msg_v01 {
#define WLFW_HOST_CAP_REQ_MSG_V01_MAX_MSG_LEN 189
extern struct qmi_elem_info wlfw_host_cap_req_msg_v01_ei[];
+extern struct qmi_elem_info wlfw_host_cap_8bit_req_msg_v01_ei[];
struct wlfw_host_cap_resp_msg_v01 {
struct qmi_response_type_v01 resp;
diff --git a/drivers/net/wireless/ath/ath10k/snoc.c b/drivers/net/wireless/ath/ath10k/snoc.c
index b491361e6ed4..fc15a0037f0e 100644
--- a/drivers/net/wireless/ath/ath10k/snoc.c
+++ b/drivers/net/wireless/ath/ath10k/snoc.c
@@ -1261,6 +1261,15 @@ static int ath10k_snoc_resource_init(struct ath10k *ar)
return ret;
}
+static void ath10k_snoc_quirks_init(struct ath10k *ar)
+{
+ struct ath10k_snoc *ar_snoc = ath10k_snoc_priv(ar);
+ struct device *dev = &ar_snoc->dev->dev;
+
+ if (of_property_read_bool(dev->of_node, "qcom,snoc-host-cap-8bit-quirk"))
+ set_bit(ATH10K_SNOC_FLAG_8BIT_HOST_CAP_QUIRK, &ar_snoc->flags);
+}
+
int ath10k_snoc_fw_indication(struct ath10k *ar, u64 type)
{
struct ath10k_snoc *ar_snoc = ath10k_snoc_priv(ar);
@@ -1678,6 +1687,8 @@ static int ath10k_snoc_probe(struct platform_device *pdev)
ar->ce_priv = &ar_snoc->ce;
msa_size = drv_data->msa_size;
+ ath10k_snoc_quirks_init(ar);
+
ret = ath10k_snoc_resource_init(ar);
if (ret) {
ath10k_warn(ar, "failed to initialize resource: %d\n", ret);
diff --git a/drivers/net/wireless/ath/ath10k/snoc.h b/drivers/net/wireless/ath/ath10k/snoc.h
index d62f53501fbb..9db823e46314 100644
--- a/drivers/net/wireless/ath/ath10k/snoc.h
+++ b/drivers/net/wireless/ath/ath10k/snoc.h
@@ -63,6 +63,7 @@ enum ath10k_snoc_flags {
ATH10K_SNOC_FLAG_REGISTERED,
ATH10K_SNOC_FLAG_UNREGISTERING,
ATH10K_SNOC_FLAG_RECOVERY,
+ ATH10K_SNOC_FLAG_8BIT_HOST_CAP_QUIRK,
};
struct ath10k_snoc {
--
2.18.0
^ permalink raw reply related
* [PATCH net-next] can: sja1000: f81601: remove unused including <linux/version.h>
From: YueHaibing @ 2019-07-25 6:59 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde, Ji-Ze Hong (Peter Hong)
Cc: YueHaibing, linux-can, netdev, kernel-janitors
Remove including <linux/version.h> that don't need it.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/can/sja1000/f81601.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/can/sja1000/f81601.c b/drivers/net/can/sja1000/f81601.c
index 362a9d4f44d5..8f25e95814ef 100644
--- a/drivers/net/can/sja1000/f81601.c
+++ b/drivers/net/can/sja1000/f81601.c
@@ -14,7 +14,6 @@
#include <linux/pci.h>
#include <linux/can/dev.h>
#include <linux/io.h>
-#include <linux/version.h>
#include "sja1000.h"
^ permalink raw reply related
* [PATCH net-next] can: ti_hecc: remove set but not used variable 'mbx_mask'
From: YueHaibing @ 2019-07-25 7:00 UTC (permalink / raw)
To: Wolfgang Grandegger, Jeroen Hofstee, Marc Kleine-Budde
Cc: YueHaibing, linux-can, netdev, kernel-janitors, Hulk Robot
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/can/ti_hecc.c: In function 'ti_hecc_mailbox_read':
drivers/net/can/ti_hecc.c:533:12: warning:
variable 'mbx_mask' set but not used [-Wunused-but-set-variable]
It is never used so can be removed.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/can/ti_hecc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/can/ti_hecc.c b/drivers/net/can/ti_hecc.c
index b62f75fa03f0..e63e2f86c289 100644
--- a/drivers/net/can/ti_hecc.c
+++ b/drivers/net/can/ti_hecc.c
@@ -530,9 +530,8 @@ static unsigned int ti_hecc_mailbox_read(struct can_rx_offload *offload,
u32 *timestamp, unsigned int mbxno)
{
struct ti_hecc_priv *priv = rx_offload_to_priv(offload);
- u32 data, mbx_mask;
+ u32 data;
- mbx_mask = BIT(mbxno);
data = hecc_read_mbx(priv, mbxno, HECC_CANMID);
if (data & HECC_CANMID_IDE)
cf->can_id = (data & CAN_EFF_MASK) | CAN_EFF_FLAG;
^ permalink raw reply related
* [PATCH net-next] can: kvaser_pciefd: Remove unused including <linux/version.h>
From: YueHaibing @ 2019-07-25 7:02 UTC (permalink / raw)
To: Wolfgang Grandegger, Henning Colliander, Marc Kleine-Budde
Cc: YueHaibing, linux-can, netdev, kernel-janitors, Hulk Robot
Remove including <linux/version.h> that don't need it.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/can/kvaser_pciefd.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/can/kvaser_pciefd.c b/drivers/net/can/kvaser_pciefd.c
index 3af747cbbde4..952a022b8343 100644
--- a/drivers/net/can/kvaser_pciefd.c
+++ b/drivers/net/can/kvaser_pciefd.c
@@ -7,7 +7,6 @@
*/
#include <linux/kernel.h>
-#include <linux/version.h>
#include <linux/module.h>
#include <linux/device.h>
#include <linux/pci.h>
^ permalink raw reply related
* Re: [PATCH net] net: hns: fix LED configuration for marvell phy
From: liuyonglong @ 2019-07-25 6:56 UTC (permalink / raw)
To: Andrew Lunn
Cc: David Miller, netdev, linux-kernel, linuxarm, salil.mehta,
yisen.zhuang, shiju.jose
In-Reply-To: <20190725042829.GB14276@lunn.ch>
On 2019/7/25 12:28, Andrew Lunn wrote:
> On Thu, Jul 25, 2019 at 11:00:08AM +0800, liuyonglong wrote:
>>> Revert "net: hns: fix LED configuration for marvell phy"
>>> This reverts commit f4e5f775db5a4631300dccd0de5eafb50a77c131.
>>>
>>> Andrew Lunn says this should be handled another way.
>>>
>>> Signed-off-by: David S. Miller <davem@davemloft.net>
>>
>>
>> Hi Andrew:
>>
>> I see this patch have been reverted, can you tell me the better way to do this?
>> Thanks very much!
>
> Please take a look at the work Matthias Kaehlcke is doing. It has not
> got too far yet, but when it is complete, it should define a generic
> way to configure PHY LEDs.
>
> Andrew
>
Hi Andrew
https://lore.kernel.org/patchwork/patch/1097185/
You are discussing about the DT configuration, is Matthias Kaehlcke's work
also provide a generic way to configure PHY LEDS using ACPI?
^ 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