NULL pointer dereference at 0000000000000020 when access dst_orig->ops->family in function xfrm_lookup_with_ifid()
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Fix Released
|
Undecided
|
Gavin Guo | ||
Xenial |
Fix Released
|
Undecided
|
Unassigned | ||
Bionic |
Fix Released
|
Undecided
|
Unassigned | ||
Cosmic |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[Impact]
NULL pointer access happens when trying to access dst_orig->ops.
The function xfrm_lookup() calls xfrm_lookup_
a line inside trying to access dst_orig->ops and it's exactly where the
panicing happens:
u16 family = dst_orig-
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+
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_
RSP: 0018:ffff98b542
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: 000000000000000
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_
__xfrm_
ip_forward+
? ip_route_
ip_rcv_
ip_rcv+0x28e/0x3b0
? inet_del_
__netif_
? __skb_checksum+
__netif_
? __netif_
netif_receive_
? tcp4_gro_
napi_gro_
dev_gro_
napi_gro_
ena_clean_
ena_io_
net_rx_
__do_softirq+
irq_exit+0xb8/0xc0
xen_evtchn_
xen_hvm_
[Fix]
The patch tries to avoid the NULL pointer access before the line
mentioned "dst_orig-
And the function calling sequence is:
__xfrm_
It definitely avoids the NULL pointer access in the
xfrm_lookup_
commit c5e39ef174ad34c
Author: Steffen Klassert <email address hidden>
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.
CVE References
description: | updated |
Changed in linux (Ubuntu Xenial): | |
status: | New → Fix Committed |
Changed in linux (Ubuntu Bionic): | |
status: | New → Fix Committed |
Changed in linux (Ubuntu Cosmic): | |
status: | New → Fix Committed |
tags: |
added: verification-done-bionic verification-done-cosmic verification-done-xenial removed: verification-needed-bionic verification-needed-cosmic verification-needed-xenial |
tags: | added: cscc |
This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:
apport-collect 1801878
and then change the status of the bug to 'Confirmed'.
If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.
This change has been made by an automated script, maintained by the Ubuntu Kernel Team.