** Description changed:
- [267265.140511] BUG: unable to handle kernel NULL pointer dereference at
0000000000000020
- [267265.144406] IP: xfrm_lookup+0x31/0x870
- [267265.146224] PGD 0 P4D 0
- [267265.147469] Oops: 0000 [#1] SMP PTI
- [267265.149141] Modules linked in: xt_iprange xt_nat ipt_MASQUERADE
nf_nat_masquerade_ipv4 iptable_mangle xt_limit nf_log_ipv4 nf_log_common xt_LOG
xt_mark ipt_REJECT nf_reject_ipv4 xt_tcpudp xt_conntrack veth overlay vxlan
ip6_udp_tunnel udp_tunnel xfs binfmt_misc xfrm4_mode_transport xfrm_user
xfrm4_tunnel tunnel4 iptable_nat nf_conntrack_ipv4 ipcomp nf_defrag_ipv4
xfrm_ipcomp nf_nat_ipv4 nf_nat esp4 nf_conntrack ah4 libcrc32c af_key xfrm_algo
iptable_filter ip_tables x_tables intel_rapl sb_edac crct10dif_pclmul
crc32_pclmul ghash_clmulni_intel pcbc aesni_intel input_leds aes_x86_64
i2c_piix4 crypto_simd glue_helper cryptd mac_hid serio_raw intel_rapl_perf
autofs4 cirrus ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops
psmouse pata_acpi ena drm floppy
- [267265.180439] CPU: 5 PID: 0 Comm: swapper/5 Not tainted 4.15.0-36-generic
#39~16.04.1-Ubuntu
- [267265.184285] Hardware name: Xen HVM domU, BIOS 4.2.amazon 08/24/2006
- [267265.187224] RIP: 0010:xfrm_lookup+0x31/0x870
- [267265.189246] RSP: 0018:ffff98b542343a48 EFLAGS: 00010246
- [267265.191743] RAX: 0000000000000000 RBX: ffff98b542343ac8 RCX:
0000000000000000
- [267265.195048] RDX: ffff98b542343ac8 RSI: 0000000000000000 RDI:
ffffffffb39e4380
- [267265.198524] RBP: ffff98b542343ab8 R08: 0000000000000002 R09:
0000000000000000
- [267265.201930] R10: 0000000000000020 R11: 000000007fb56465 R12:
0000000000000000
- [267265.205235] R13: ffffffffb39e4380 R14: 0000000000000002 R15:
ffffffffb39e4380
- [267265.208567] FS: 0000000000000000(0000) GS:ffff98b542340000(0000)
knlGS:0000000000000000
- [267265.212404] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
- [267265.215084] CR2: 0000000000000020 CR3: 00000004ed40a001 CR4:
00000000001606e0
- [267265.218442] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
- [267265.221769] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
0000000000000400
- [267265.225063] Call Trace:
- [267265.226280] <IRQ>
- [267265.227291] ? __xfrm_policy_check+0x41d/0x630
- [267265.229412] __xfrm_route_forward+0xa3/0x110
- [267265.231475] ip_forward+0x38c/0x470
- [267265.233140] ? ip_route_input_noref+0x28/0x40
- [267265.235214] ip_rcv_finish+0x124/0x410
- [267265.237041] ip_rcv+0x28e/0x3b0
- [267265.238572] ? inet_del_offload+0x40/0x40
- [267265.240487] __netif_receive_skb_core+0x879/0xba0
- [267265.242734] ? __skb_checksum+0x188/0x2c0
- [267265.244631] __netif_receive_skb+0x18/0x60
- [267265.246591] ? __netif_receive_skb+0x18/0x60
- [267265.248625] netif_receive_skb_internal+0x37/0xe0
- [267265.252142] ? tcp4_gro_complete+0x86/0x90
- [267265.255313] napi_gro_complete+0x73/0x90
- [267265.258432] dev_gro_receive+0x2ee/0x5c0
- [267265.261560] napi_gro_frags+0xa3/0x230
- [267265.264583] ena_clean_rx_irq+0x486/0x7c0 [ena]
- [267265.267981] ena_io_poll+0x41d/0x770 [ena]
- [267265.271189] net_rx_action+0x265/0x3b0
- [267265.274134] __do_softirq+0xf5/0x28f
- [267265.276933] irq_exit+0xb8/0xc0
- [267265.279648] xen_evtchn_do_upcall+0x30/0x40
- [267265.282691] xen_hvm_callback_vector+0x84/0x90
+ [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 <[email protected]>
+ 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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to 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()
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1801878/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
