APPLIED/cmnt: [SRU][Xenial][Bionic][Cosmic][PATCH] Fix for LP:#1801878

[Khaled Elmously]

Applied to all target branches, but xenial didn't apply cleanly as the function xfrm_output_one() is slightly different in xenial from the other two, so needed some adjustment



On 2018-11-06 22:46:33 , Gavin Guo wrote:
> BugLink: https://bugs.launchpad.net/bugs/1801878
> 
> [Impact]
> 
> NULL pointer access happens when trying to access dst_orig->ops.
> 
> The function xfrm_lookup() calls xfrm_lookup_with_ifid() and there is 
> a line inside trying to access dst_orig->ops and it's exactly where the 
> panicing happens: 
> 
> u16 family = dst_orig->ops->family; 
> 
> As you can see that the symbol offset of ops is about 32(0x20) which 
> definitely is the error message shows in the kern.log: 
> 
> [267265.140511] BUG: unable to handle kernel NULL pointer dereference 
> at 0000000000000020 
> 
> struct dst_entry { 
> struct callback_head callback_head; /* 0 16 */ 
> struct dst_entry * child; /* 16 8 */ 
> struct net_device * dev; /* 24 8 */ 
> struct dst_ops * ops; <-- /* 32 8 */ 
> 
> The oops:
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 
> IP: xfrm_lookup+0x31/0x870 
> PGD 0 P4D 0 
> Oops: 0000 [#1] SMP PTI 
> CPU: 5 PID: 0 Comm: swapper/5 Not tainted 4.15.0-36-generic #39~16.04.1-Ubuntu 
> Hardware name: Xen HVM domU, BIOS 4.2.amazon 08/24/2006 
> RIP: 0010:xfrm_lookup+0x31/0x870 
> RSP: 0018:ffff98b542343a48 EFLAGS: 00010246 
> RAX: 0000000000000000 RBX: ffff98b542343ac8 RCX: 0000000000000000 
> RDX: ffff98b542343ac8 RSI: 0000000000000000 RDI: ffffffffb39e4380 
> RBP: ffff98b542343ab8 R08: 0000000000000002 R09: 0000000000000000 
> R10: 0000000000000020 R11: 000000007fb56465 R12: 0000000000000000 
> R13: ffffffffb39e4380 R14: 0000000000000002 R15: ffffffffb39e4380 
> FS: 0000000000000000(0000) GS:ffff98b542340000(0000) knlGS:0000000000000000 
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 
> CR2: 0000000000000020 CR3: 00000004ed40a001 CR4: 00000000001606e0 
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 
> Call Trace: 
> <IRQ> 
> ? __xfrm_policy_check+0x41d/0x630 
> __xfrm_route_forward+0xa3/0x110 
> ip_forward+0x38c/0x470 
> ? ip_route_input_noref+0x28/0x40 
> ip_rcv_finish+0x124/0x410 
> ip_rcv+0x28e/0x3b0 
> ? inet_del_offload+0x40/0x40 
> __netif_receive_skb_core+0x879/0xba0 
> ? __skb_checksum+0x188/0x2c0 
> __netif_receive_skb+0x18/0x60 
> ? __netif_receive_skb+0x18/0x60 
> netif_receive_skb_internal+0x37/0xe0 
> ? tcp4_gro_complete+0x86/0x90 
> napi_gro_complete+0x73/0x90 
> dev_gro_receive+0x2ee/0x5c0 
> napi_gro_frags+0xa3/0x230 
> ena_clean_rx_irq+0x486/0x7c0 [ena] 
> ena_io_poll+0x41d/0x770 [ena] 
> net_rx_action+0x265/0x3b0 
> __do_softirq+0xf5/0x28f 
> irq_exit+0xb8/0xc0 
> xen_evtchn_do_upcall+0x30/0x40 
> xen_hvm_callback_vector+0x84/0x90 
> 
> [Fix]
> The patch tries to avoid the NULL pointer access before the line
> mentioned "dst_orig->ops->family" in function __xfrm_route_forward.
> And the function calling sequence is: 
> 
> __xfrm_route_forward -> xfrm_lookup -> xfrm_lookup_with_ifid 
> 
> It definitely avoids the NULL pointer access in the 
> xfrm_lookup_with_ifid.
> 
> commit c5e39ef174ad34cd4d26af3a83bdbccddd2ad9d6
> Author: Steffen Klassert <steffen.klassert at secunet.com>
> Date:   Tue Sep 11 10:31:15 2018 +0200
> 
>     xfrm: Fix NULL pointer dereference when skb_dst_force clears the dst_entry.
>     
>     Since commit 222d7dbd258d ("net: prevent dst uses after free")
>     skb_dst_force() might clear the dst_entry attached to the skb.
>     The xfrm code don't expect this to happen, so we crash with
>     a NULL pointer dereference in this case. Fix it by checking
>     skb_dst(skb) for NULL after skb_dst_force() and drop the packet
>     in cast the dst_entry was cleared.
>     
> [Test]
> The fix has been tested in the production system with the IPSec enabled.
> 
> Steffen Klassert (1):
>   xfrm: Fix NULL pointer dereference when skb_dst_force clears the
>     dst_entry.
> 
>  net/xfrm/xfrm_output.c | 4 ++++
>  net/xfrm/xfrm_policy.c | 4 ++++
>  2 files changed, 8 insertions(+)
> 
> -- 
> 2.7.4
> 
> 
> -- 
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team