[Kernel-packages] [Bug 1801878] Re: NULL pointer dereference at 0000000000000020 when access dst_orig->ops->family in function xfrm_lookup_with_ifid()
** Tags added: cscc
--
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 0020 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:
[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 0020
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 0020
IP: xfrm_lookup+0x31/0x870
PGD 0 P4D 0
Oops: [#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:98b542343a48 EFLAGS: 00010246
RAX: RBX: 98b542343ac8 RCX:
RDX: 98b542343ac8 RSI: RDI: b39e4380
RBP: 98b542343ab8 R08: 0002 R09:
R10: 0020 R11: 7fb56465 R12:
R13: b39e4380 R14: 0002 R15: b39e4380
FS: () GS:98b54234() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 0020 CR3: 0004ed40a001 CR4: 001606e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
? __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
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
[Kernel-packages] [Bug 1801878] Re: NULL pointer dereference at 0000000000000020 when access dst_orig->ops->family in function xfrm_lookup_with_ifid()
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.
https://bugs.launchpad.net/bugs/1801878
Title:
NULL pointer dereference at 0020 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:
[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 0020
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 0020
IP: xfrm_lookup+0x31/0x870
PGD 0 P4D 0
Oops: [#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:98b542343a48 EFLAGS: 00010246
RAX: RBX: 98b542343ac8 RCX:
RDX: 98b542343ac8 RSI: RDI: b39e4380
RBP: 98b542343ab8 R08: 0002 R09:
R10: 0020 R11: 7fb56465 R12:
R13: b39e4380 R14: 0002 R15: b39e4380
FS: () GS:98b54234() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 0020 CR3: 0004ed40a001 CR4: 001606e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
? __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
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
[Kernel-packages] [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.4.0-140.166 --- linux (4.4.0-140.166) xenial; urgency=medium * linux: 4.4.0-140.166 -proposed tracker (LP: #1802776) * 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 * 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 * crash in ENA driver on removing an interface (LP: #1802341) - SAUCE: net: ena: fix crash during ena_remove() * xenial guest on arm64 drops to busybox under openstack bionic-rocky (LP: #1797092) - [Config] CONFIG_PCI_ECAM=y - PCI: Provide common functions for ECAM mapping - PCI: generic, thunder: Use generic ECAM API - PCI, of: Move PCI I/O space management to PCI core code - PCI: Move ecam.h to linux/include/pci-ecam.h - PCI: Add parent device field to ECAM struct pci_config_window - PCI: Add pci_unmap_iospace() to unmap I/O resources - PCI/ACPI: Support I/O resources when parsing host bridge resources - [Config] CONFIG_ACPI_MCFG=y - PCI/ACPI: Add generic MCFG table handling - PCI: Refactor pci_bus_assign_domain_nr() for CONFIG_PCI_DOMAINS_GENERIC - PCI: Factor DT-specific pci_bus_find_domain_nr() code out - ARM64: PCI: Add acpi_pci_bus_find_domain_nr() - ARM64: PCI: ACPI support for legacy IRQs parsing and consolidation with DT code - ARM64: PCI: Support ACPI-based PCI host controller * [GLK/CLX] Enhanced IBRS (LP: #1786139) - x86/speculation: Remove SPECTRE_V2_IBRS in enum spectre_v2_mitigation - x86/speculation: Support Enhanced IBRS on future CPUs * Update ENA driver to version 2.0.1K (LP: #1798182) - net: ena: remove ndo_poll_controller - net: ena: fix warning in rmmod caused by double iounmap - net: ena: fix rare bug when failed restart/resume is followed by driver removal - net: ena: fix NULL dereference due to untimely napi initialization - net: ena: fix auto casting to boolean - net: ena: minor performance improvement - net: ena: complete host info to match latest ENA spec - net: ena: introduce Low Latency Queues data structures according to ENA spec - net: ena: add functions for handling Low Latency Queues in ena_com - net: ena: add functions for handling Low Latency Queues in ena_netdev - net: ena: use CSUM_CHECKED device indication to report skb's checksum status - net: ena: explicit casting and initialization, and clearer error handling - net: ena: limit refill Rx threshold to 256 to avoid latency issues - net: ena: change rx copybreak default to reduce kernel memory pressure - net: ena: remove redundant parameter in ena_com_admin_init() - net: ena: update driver version to 2.0.1 - net: ena: fix indentations in ena_defs for better readability - net: ena: Fix Kconfig dependency on X86 - net: ena: enable Low Latency Queues - net: ena: fix compilation error in xtensa architecture * Xenial update: 4.4.162 upstream stable release (LP: #1801900) - ASoC: wm8804: Add ACPI support - ASoC: sigmadsp: safeload should not have lower byte limit - selftests/efivarfs: add required kernel configs - mfd: omap-usb-host: Fix dts probe of children - sound: enable interrupt after dma buffer initialization - stmmac: fix valid numbers of unicast filter entries - net: macb: disable scatter-gather for macb on sama5d3 - ARM: dts: at91: add new compatibility string for macb on sama5d3 - drm/amdgpu: Fix SDMA HQD destroy error on gfx_v7 - ext4: add corruption check in ext4_xattr_set_entry() - mm/vmstat.c: fix outdated vmstat_text - mach64: detect the dot clock divider correctly on sparc - perf script python: Fix export-to-postgresql.py occasional failure - i2c: i2c-scmi: fix for i2c_smbus_write_block_data - xhci: Don't print a warning when setting link state for disabled ports - jffs2: return -ERANGE when xattr buffer is too small - bnxt_en: Fix TX timeout during netpoll. - bonding: avoid possible dead-lock - ip6_tunnel: be careful when accessing the inner header - ip_tunnel: be careful when accessing the inner header - ipv4: fix use-after-free in ip_cmsg_recv_dstaddr() - net: ipv4: update fnhe_pmtu when first hop's MTU changes - net/ipv6: Display all addresses in output of /proc/net/if_inet6 - netlabel: check for IPV4MASK in addrinfo_get - net/usb: cancel pending work when unbinding smsc75xx - qlcnic: fix Tx descriptor corruption on 82xx devices - team: Forbid enslaving team device to itself - net: mvpp2: Extract the correct ethtype from the skb for tx csum offload - net: systemport: Fix wake-up interrupt race during
[Kernel-packages] [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 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 Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1801878
Title:
NULL pointer dereference at 0020 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 0020
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 0020
IP: xfrm_lookup+0x31/0x870
PGD 0 P4D 0
Oops: [#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:98b542343a48 EFLAGS: 00010246
RAX: RBX: 98b542343ac8 RCX:
RDX: 98b542343ac8 RSI:
[Kernel-packages] [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.18.0-12.13 --- linux (4.18.0-12.13) cosmic; urgency=medium * linux: 4.18.0-12.13 -proposed tracker (LP: #1802743) * [FEAT] Guest-dedicated Crypto Adapters (LP: #1787405) - 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 - 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 - [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 * crash in ENA driver on removing an interface (LP: #1802341) - SAUCE: net: ena: fix crash during ena_remove() * Ubuntu 18.04.1 - [s390x] Kernel panic while stressing network bonding (LP: #1797367) - s390/qeth: reduce hard-coded access to ccw channels - s390/qeth: sanitize strings in debug messages * Add checksum offload and TSO support for HiNIC adapters (LP: #1800664) - net-next/hinic: add checksum offload and TSO support * smartpqi updates for ubuntu 18.04.2 (LP: #1798208) - scsi: smartpqi: improve handling for sync requests - scsi: smartpqi: improve error checking for sync requests - scsi: smartpqi: add inspur advantech ids - scsi: smartpqi: fix critical ARM issue reading PQI index registers - scsi: smartpqi: bump driver version to 1.1.4-130 * [GLK/CLX] Enhanced IBRS (LP: #1786139) - x86/speculation: Remove SPECTRE_V2_IBRS in enum spectre_v2_mitigation - x86/speculation: Support Enhanced IBRS on future CPUs * Enable keyboard wakeup for S2Idle laptops (LP: #1798552) - Input: i8042 - enable keyboard wakeups by default when s2idle is used * Overlayfs in user namespace leaks directory content of inaccessible directories (LP: #1793458) // CVE-2018-6559 - SAUCE: overlayfs: ensure mounter privileges when reading directories * Update ENA driver to version 2.0.1K (LP: #1798182) - net: ena: remove ndo_poll_controller - net: ena: fix auto casting to boolean - net: ena: minor performance improvement - net: ena: complete host info to match latest ENA spec - net: ena: introduce Low Latency Queues data structures according to ENA spec - net: ena: add functions for handling Low Latency Queues in ena_com - net: ena: add functions for handling Low Latency Queues in ena_netdev - net: ena: use CSUM_CHECKED device indication to report skb's checksum status - net: ena: explicit casting and initialization, and clearer error handling - net: ena: limit refill Rx threshold to 256 to avoid latency issues - net: ena: change rx copybreak default to reduce kernel memory pressure - net: ena: remove redundant
[Kernel-packages] [Bug 1801878] Re: NULL pointer dereference at 0000000000000020 when access dst_orig->ops->family in function xfrm_lookup_with_ifid()
** Tags removed: verification-needed-bionic verification-needed-cosmic
verification-needed-xenial
** Tags added: verification-done-bionic verification-done-cosmic
verification-done-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 0020 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 0020
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 0020
IP: xfrm_lookup+0x31/0x870
PGD 0 P4D 0
Oops: [#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:98b542343a48 EFLAGS: 00010246
RAX: RBX: 98b542343ac8 RCX:
RDX: 98b542343ac8 RSI: RDI: b39e4380
RBP: 98b542343ab8 R08: 0002 R09:
R10: 0020 R11: 7fb56465 R12:
R13: b39e4380 R14: 0002 R15: b39e4380
FS: () GS:98b54234() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 0020 CR3: 0004ed40a001 CR4: 001606e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
? __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
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
[Kernel-packages] [Bug 1801878] Re: NULL pointer dereference at 0000000000000020 when access dst_orig->ops->family in function xfrm_lookup_with_ifid()
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 0020 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 0020
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 0020
IP: xfrm_lookup+0x31/0x870
PGD 0 P4D 0
Oops: [#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:98b542343a48 EFLAGS: 00010246
RAX: RBX: 98b542343ac8 RCX:
RDX: 98b542343ac8 RSI: RDI: b39e4380
RBP: 98b542343ab8 R08: 0002 R09:
R10: 0020 R11: 7fb56465 R12:
R13: b39e4380 R14: 0002 R15: b39e4380
FS: () GS:98b54234() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 0020 CR3: 0004ed40a001 CR4: 001606e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
? __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
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 :
[Kernel-packages] [Bug 1801878] Re: NULL pointer dereference at 0000000000000020 when access dst_orig->ops->family in function xfrm_lookup_with_ifid()
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-
cosmic' to 'verification-done-cosmic'. If the problem still exists,
change the tag 'verification-needed-cosmic' to 'verification-failed-
cosmic'.
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-cosmic
--
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 0020 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 0020
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 0020
IP: xfrm_lookup+0x31/0x870
PGD 0 P4D 0
Oops: [#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:98b542343a48 EFLAGS: 00010246
RAX: RBX: 98b542343ac8 RCX:
RDX: 98b542343ac8 RSI: RDI: b39e4380
RBP: 98b542343ab8 R08: 0002 R09:
R10: 0020 R11: 7fb56465 R12:
R13: b39e4380 R14: 0002 R15: b39e4380
FS: () GS:98b54234() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 0020 CR3: 0004ed40a001 CR4: 001606e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
? __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
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 :
[Kernel-packages] [Bug 1801878] Re: NULL pointer dereference at 0000000000000020 when access dst_orig->ops->family in function xfrm_lookup_with_ifid()
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-
bionic' to 'verification-done-bionic'. If the problem still exists,
change the tag 'verification-needed-bionic' to 'verification-failed-
bionic'.
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-bionic
--
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 0020 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 0020
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 0020
IP: xfrm_lookup+0x31/0x870
PGD 0 P4D 0
Oops: [#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:98b542343a48 EFLAGS: 00010246
RAX: RBX: 98b542343ac8 RCX:
RDX: 98b542343ac8 RSI: RDI: b39e4380
RBP: 98b542343ab8 R08: 0002 R09:
R10: 0020 R11: 7fb56465 R12:
R13: b39e4380 R14: 0002 R15: b39e4380
FS: () GS:98b54234() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 0020 CR3: 0004ed40a001 CR4: 001606e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
? __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
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 :
[Kernel-packages] [Bug 1801878] Re: NULL pointer dereference at 0000000000000020 when access dst_orig->ops->family in function xfrm_lookup_with_ifid()
** 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
--
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 0020 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 0020
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 0020
IP: xfrm_lookup+0x31/0x870
PGD 0 P4D 0
Oops: [#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:98b542343a48 EFLAGS: 00010246
RAX: RBX: 98b542343ac8 RCX:
RDX: 98b542343ac8 RSI: RDI: b39e4380
RBP: 98b542343ab8 R08: 0002 R09:
R10: 0020 R11: 7fb56465 R12:
R13: b39e4380 R14: 0002 R15: b39e4380
FS: () GS:98b54234() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 0020 CR3: 0004ed40a001 CR4: 001606e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
? __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
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
[Kernel-packages] [Bug 1801878] Re: NULL pointer dereference at 0000000000000020 when access dst_orig->ops->family in function xfrm_lookup_with_ifid()
** Also affects: linux (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Cosmic)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Xenial)
Importance: Undecided
Status: New
--
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 0020 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:
New
Status in linux source package in Bionic:
New
Status in linux source package in Cosmic:
New
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 0020
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 0020
IP: xfrm_lookup+0x31/0x870
PGD 0 P4D 0
Oops: [#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:98b542343a48 EFLAGS: 00010246
RAX: RBX: 98b542343ac8 RCX:
RDX: 98b542343ac8 RSI: RDI: b39e4380
RBP: 98b542343ab8 R08: 0002 R09:
R10: 0020 R11: 7fb56465 R12:
R13: b39e4380 R14: 0002 R15: b39e4380
FS: () GS:98b54234() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 0020 CR3: 0004ed40a001 CR4: 001606e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
? __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
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
[Kernel-packages] [Bug 1801878] Re: NULL pointer dereference at 0000000000000020 when access dst_orig->ops->family in function xfrm_lookup_with_ifid()
** Description changed:
- [267265.140511] BUG: unable to handle kernel NULL pointer dereference at
0020
- [267265.144406] IP: xfrm_lookup+0x31/0x870
- [267265.146224] PGD 0 P4D 0
- [267265.147469] Oops: [#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:98b542343a48 EFLAGS: 00010246
- [267265.191743] RAX: RBX: 98b542343ac8 RCX:
- [267265.195048] RDX: 98b542343ac8 RSI: RDI:
b39e4380
- [267265.198524] RBP: 98b542343ab8 R08: 0002 R09:
- [267265.201930] R10: 0020 R11: 7fb56465 R12:
- [267265.205235] R13: b39e4380 R14: 0002 R15:
b39e4380
- [267265.208567] FS: () GS:98b54234()
knlGS:
- [267265.212404] CS: 0010 DS: ES: CR0: 80050033
- [267265.215084] CR2: 0020 CR3: 0004ed40a001 CR4:
001606e0
- [267265.218442] DR0: DR1: DR2:
- [267265.221769] DR3: DR6: fffe0ff0 DR7:
0400
- [267265.225063] Call Trace:
- [267265.226280]
- [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 0020
+
+ 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 0020
+ IP: xfrm_lookup+0x31/0x870
+ PGD 0 P4D 0
+ Oops: [#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:98b542343a48 EFLAGS: 00010246
+ RAX: RBX: 98b542343ac8 RCX:
+ RDX: 98b542343ac8 RSI: RDI: b39e4380
+ RBP: 98b542343ab8 R08: 0002 R09:
+ R10: 0020 R11: 7fb56465 R12:
+ R13: b39e4380 R14: 0002 R15: b39e4380
+ FS: () GS:98b54234() knlGS:
+ CS: 0010 DS: ES: CR0: 80050033
+ CR2: 0020 CR3: 0004ed40a001 CR4: 001606e0
+ DR0:
