Patch 9e143793 has landed in D/E as well, mark this bug as fix-released.

** Changed in: linux (Ubuntu)
       Status: Incomplete => Fix Released

You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.

  NULL pointer dereference at 0000000000000020 when access
  dst_orig->ops->family in function  xfrm_lookup_with_ifid()

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Released
Status in linux source package in Bionic:
  Fix Released
Status in linux source package in Cosmic:
  Fix Released

Bug description:

  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 
  Hardware name: Xen HVM domU, BIOS 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: 
  ? __xfrm_policy_check+0x41d/0x630 
  ? ip_route_input_noref+0x28/0x40 
  ? inet_del_offload+0x40/0x40 
  ? __skb_checksum+0x188/0x2c0 
  ? __netif_receive_skb+0x18/0x60 
  ? tcp4_gro_complete+0x86/0x90 
  ena_clean_rx_irq+0x486/0x7c0 [ena] 
  ena_io_poll+0x41d/0x770 [ena] 

  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 

  commit c5e39ef174ad34cd4d26af3a83bdbccddd2ad9d6
  Author: Steffen Klassert <>
  Date:   Tue Sep 11 10:31:15 2018 +0200

      xfrm: Fix NULL pointer dereference when skb_dst_force clears the 
      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.
  The fix has been tested in the production system with the IPSec enabled.

To manage notifications about this bug go to:

Mailing list:
Post to     :
Unsubscribe :
More help   :

Reply via email to