group.of.nepali.translators team mailing list archive
-
group.of.nepali.translators team
-
Mailing list archive
-
Message #27353
[Bug 1801878] Re: NULL pointer dereference at 0000000000000020 when access dst_orig->ops->family in function xfrm_lookup_with_ifid()
This bug was fixed in the package linux - 4.15.0-42.45
---------------
linux (4.15.0-42.45) bionic; urgency=medium
* linux: 4.15.0-42.45 -proposed tracker (LP: #1803592)
* [FEAT] Guest-dedicated Crypto Adapters (LP: #1787405)
- KVM: s390: reset crypto attributes for all vcpus
- KVM: s390: vsie: simulate VCPU SIE entry/exit
- KVM: s390: introduce and use KVM_REQ_VSIE_RESTART
- KVM: s390: refactor crypto initialization
- s390: vfio-ap: base implementation of VFIO AP device driver
- s390: vfio-ap: register matrix device with VFIO mdev framework
- s390: vfio-ap: sysfs interfaces to configure adapters
- s390: vfio-ap: sysfs interfaces to configure domains
- s390: vfio-ap: sysfs interfaces to configure control domains
- s390: vfio-ap: sysfs interface to view matrix mdev matrix
- KVM: s390: interface to clear CRYCB masks
- s390: vfio-ap: implement mediated device open callback
- s390: vfio-ap: implement VFIO_DEVICE_GET_INFO ioctl
- s390: vfio-ap: zeroize the AP queues
- s390: vfio-ap: implement VFIO_DEVICE_RESET ioctl
- KVM: s390: Clear Crypto Control Block when using vSIE
- KVM: s390: vsie: Do the CRYCB validation first
- KVM: s390: vsie: Make use of CRYCB FORMAT2 clear
- KVM: s390: vsie: Allow CRYCB FORMAT-2
- KVM: s390: vsie: allow CRYCB FORMAT-1
- KVM: s390: vsie: allow CRYCB FORMAT-0
- KVM: s390: vsie: allow guest FORMAT-0 CRYCB on host FORMAT-1
- KVM: s390: vsie: allow guest FORMAT-1 CRYCB on host FORMAT-2
- KVM: s390: vsie: allow guest FORMAT-0 CRYCB on host FORMAT-2
- KVM: s390: device attrs to enable/disable AP interpretation
- KVM: s390: CPU model support for AP virtualization
- s390: doc: detailed specifications for AP virtualization
- KVM: s390: fix locking for crypto setting error path
- KVM: s390: Tracing APCB changes
- s390: vfio-ap: setup APCB mask using KVM dedicated function
- s390/zcrypt: Add ZAPQ inline function.
- s390/zcrypt: Review inline assembler constraints.
- s390/zcrypt: Integrate ap_asm.h into include/asm/ap.h.
- s390/zcrypt: fix ap_instructions_available() returncodes
- s390/zcrypt: remove VLA usage from the AP bus
- s390/zcrypt: Remove deprecated ioctls.
- s390/zcrypt: Remove deprecated zcrypt proc interface.
- s390/zcrypt: Support up to 256 crypto adapters.
- [Config:] Enable CONFIG_S390_AP_IOMMU and set CONFIG_VFIO_AP to module.
* Bypass of mount visibility through userns + mount propagation (LP: #1789161)
- mount: Retest MNT_LOCKED in do_umount
- mount: Don't allow copying MNT_UNBINDABLE|MNT_LOCKED mounts
* CVE-2018-18955: nested user namespaces with more than five extents
incorrectly grant privileges over inode (LP: #1801924) // CVE-2018-18955
- userns: also map extents in the reverse map to kernel IDs
* kdump fail due to an IRQ storm (LP: #1797990)
- SAUCE: x86/PCI: Export find_cap() to be used in early PCI code
- SAUCE: x86/quirks: Add parameter to clear MSIs early on boot
- SAUCE: x86/quirks: Scan all busses for early PCI quirks
-- Thadeu Lima de Souza Cascardo <cascardo@xxxxxxxxxxxxx> Thu, 15 Nov
2018 17:01:46 -0200
** Changed in: linux (Ubuntu Bionic)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
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 Released
Status in linux source package in Cosmic:
Fix Released
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.klassert@xxxxxxxxxxx>
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