Re: AW: AW: PROBLEM: Kernel Oops in UDP stack

[Eric Dumazet <eric.dumazet@gmail.com>]

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)