From: Eric Dumazet <eric.dumazet@gmail.com>
To: Eric Dumazet <eric.dumazet@gmail.com>,
Paolo Abeni <pabeni@redhat.com>,
Marcel Hellwig <mhellwig@mut-group.com>,
"'davem@davemloft.net'" <davem@davemloft.net>,
"'kuznet@ms2.inr.ac.ru'" <kuznet@ms2.inr.ac.ru>,
"'yoshfuji@linux-ipv6.org'" <yoshfuji@linux-ipv6.org>,
"'andrew@lunn.ch'" <andrew@lunn.ch>
Cc: "'netdev@vger.kernel.org'" <netdev@vger.kernel.org>,
"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>,
Matthias Wystrik <mwystrik@mut-group.com>
Subject: Re: AW: AW: PROBLEM: Kernel Oops in UDP stack
Date: Wed, 1 Aug 2018 04:25:19 -0700 [thread overview]
Message-ID: <b727135a-a428-72bc-fa04-dbd64095b21e@gmail.com> (raw)
In-Reply-To: <cd53c2fe-5349-c0e2-c6f5-8bcebdef7024@gmail.com>
On 08/01/2018 03:49 AM, Eric Dumazet wrote:
>
>
> On 08/01/2018 03:44 AM, Paolo Abeni wrote:
>> On Wed, 2018-08-01 at 10:35 +0000, Marcel Hellwig wrote:
>>>>> [<c0228adc>] (udp_recvmsg+0x284/0x33c) from [<c02306e0>] (inet_recvmsg+0x38/0x4c): net/ipv4/udp.c:1234
>>>>
>>>> sin->sin_addr.s_addr = ip_hdr(skb)->saddr;
>>>>
>>>> Unaligned access trap (virtual address c14fe63a), so either sin or ip_hdr(skb) are not on a 32bit alignment
>>>>
>>>> Can you produce the disassembly of the trapping instruction ?
>>>
>>> https://gist.github.com/hellow554/6b11c6c0827d5db80a7e66f71f5636ff#file-net_uipv4_udp-lst-L1892-L1895
>>>
>>> sin->sin_addr.s_addr = ip_hdr(skb)->saddr;
>>> c0228ad8: e5943080 ldr r3, [r4, #128] ; 0x80
>>> c0228adc: e593300c ldr r3, [r3, #12]
>>> c0228ae0: e5823004 str r3, [r2, #4]
>>
>> I *think* pskb_trim_rcsum() in __udp4_lib_rcv() can copy the ipv4
>> header to an unaligned address, for cloned skbs. If I understood
>> correctly the relevant socket is a mcast one, so cloned skbs can land
>> there.
>>
>
> kmalloc() should return aligned pointer.
>
> pskb_expand_head() should allocate aligned skb->head
>
> So pskb_expand_head() should keep whatever offset was provided in the source skb
>
> ( Driver called skb_reserve() or similar function)
>
I suspect the following patch my need to be backported, please Marcel git it a try.
Another way to spot the problem would be to add a check in pskb_expand_head()
commit 5e2afba4ecd7931ea06e6fa116ab28e6943dbd42
Author: Paul Guo <ggang@tilera.com>
Date: Mon Nov 14 19:00:54 2011 +0800
netfilter: possible unaligned packet header in ip_route_me_harder
This patch tries to fix the following issue in netfilter:
In ip_route_me_harder(), we invoke pskb_expand_head() that
rellocates new header with additional head room which can break
the alignment of the original packet header.
In one of my NAT test case, the NIC port for internal hosts is
configured with vlan and the port for external hosts is with
general configuration. If we ping an external "unknown" hosts from an
internal host, an icmp packet will be sent. We find that in
icmp_send()->...->ip_route_me_harder()->pskb_expand_head(), hh_len=18
and current headroom (skb_headroom(skb)) of the packet is 16. After
calling pskb_expand_head() the packet header becomes to be unaligned
and then our system (arch/tile) panics immediately.
Signed-off-by: Paul Guo <ggang@tilera.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
diff --git a/net/ipv4/netfilter.c b/net/ipv4/netfilter.c
index 9899619ab9b8db0f9d8d02c8005c0e6bb01fda94..4f47e064e262c2f24e7cb13eacfcebff0fad86a3 100644
--- a/net/ipv4/netfilter.c
+++ b/net/ipv4/netfilter.c
@@ -64,7 +64,8 @@ int ip_route_me_harder(struct sk_buff *skb, unsigned addr_type)
/* Change in oif may mean change in hh_len. */
hh_len = skb_dst(skb)->dev->hard_header_len;
if (skb_headroom(skb) < hh_len &&
- pskb_expand_head(skb, hh_len - skb_headroom(skb), 0, GFP_ATOMIC))
+ pskb_expand_head(skb, HH_DATA_ALIGN(hh_len - skb_headroom(skb)),
+ 0, GFP_ATOMIC))
return -1;
return 0;
next prev parent reply other threads:[~2018-08-01 11:25 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-31 15:06 PROBLEM: Kernel Oops in UDP stack Marcel Hellwig
2018-07-31 15:59 ` Eric Dumazet
2018-08-01 5:55 ` AW: " Marcel Hellwig
2018-08-01 10:20 ` Eric Dumazet
2018-08-01 10:35 ` AW: " Marcel Hellwig
2018-08-01 10:44 ` Paolo Abeni
2018-08-01 10:49 ` Eric Dumazet
2018-08-01 11:25 ` Eric Dumazet [this message]
2018-08-01 11:31 ` AW: " Marcel Hellwig
2018-08-01 13:27 ` Marcel Hellwig
2018-08-02 11:02 ` Marcel Hellwig
2018-08-02 13:05 ` Eric Dumazet
2018-08-02 9:17 ` David Laight
2018-08-02 13:13 ` Eric Dumazet
2018-08-02 13:18 ` David Laight
2018-08-02 13:57 ` AW: " Marcel Hellwig
2018-08-02 15:07 ` Eric Dumazet
2018-08-03 8:24 ` AW: " Marcel Hellwig
2018-08-07 13:42 ` Marcel Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b727135a-a428-72bc-fa04-dbd64095b21e@gmail.com \
--to=eric.dumazet@gmail.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=mhellwig@mut-group.com \
--cc=mwystrik@mut-group.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=yoshfuji@linux-ipv6.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).