This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed- xenial' to 'verification-done-xenial'. If the problem still exists, change the tag 'verification-needed-xenial' to 'verification-failed- xenial'.
If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: verification-needed-xenial -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1801878 Title: NULL pointer dereference at 0000000000000020 when access dst_orig->ops->family in function xfrm_lookup_with_ifid() Status in linux package in Ubuntu: Incomplete Status in linux source package in Xenial: Fix Committed Status in linux source package in Bionic: Fix Committed Status in linux source package in Cosmic: Fix Committed Bug description: [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.klass...@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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1801878/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp