arm64: sigaltstack fails with MINSIGSTKSZ for 32-bit processes

Bug #1844155 reported by Adam Conrad on 2019-09-16
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Debian)
Fix Released
linux (Ubuntu)

Bug Description


The arm64 kernel allows one to run aarch32 processes on an aarch64 processor, using the standard 32/64-bit syscall compatibility. However this compat layer does not correctly validate the arguments of the sigaltstack syscall which can result in process failures.

[Test Case]

The simple reproducer from triggers a memory allocation error with the current Xenial 4.4 kernel.


Backport the following two upstream commits:
24951465cbd2 arm64: compat: Provide definition for COMPAT_SIGMINSTKSZ
22839869f21a signal: Introduce COMPAT_SIGMINSTKSZ for use in compat_sys_sigaltstack

With these two commits, the reproducer no longer fails.

[Regression Potential]

Low. the modifications are trivial and the two patches have been in upstream for quite a while.

[Original Description]

This seems to have been fixed in 4.15 (finally), but is still an issue in the 4.4 kernel used on our builders, and possibly others as well (needs investigation).

The original Debian bug report linked has more info, as well as the patchset on lkml at

Andy Whitcroft (apw) on 2019-09-16
Changed in linux (Ubuntu):
status: New → Confirmed
Changed in linux (Debian):
status: Unknown → Fix Released
Adam Conrad (adconrad) wrote :

Confirmed that this is fixed in 4.15 as of (at least) 4.15.0-62-generic.

Changed in linux (Ubuntu Xenial):
status: New → Confirmed
Juerg Haefliger (juergh) wrote :

Relevant patches (from upstream v4.20):
24951465cbd2 arm64: compat: Provide definition for COMPAT_SIGMINSTKSZ
22839869f21a signal: Introduce COMPAT_SIGMINSTKSZ for use in compat_sys_sigaltstack

Applied to Bionic Ubuntu-4.15.0-59.66.

Juerg Haefliger (juergh) on 2019-10-01
description: updated
Khaled El Mously (kmously) wrote :

Marking the bug as Fix-committed based on this:

Changed in linux (Ubuntu Xenial):
status: Confirmed → Fix Committed

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 for documentation how to enable and use -proposed. Thank you!

tags: added: verification-needed-xenial
Adam Conrad (adconrad) wrote :

I completely missed the verification ping here in the sea of other kernel bug mail that I get. Will work with the LP team to get this verified as quickly as I can, but if you need to make a revert/ship call before I can, the patches should be pretty harmless even if they don't fix the bug, so I'd vote for keep and ship and we can fix later if we missed a bit.

Khaled El Mously (kmously) wrote :

Thanks @adconrad

This is the only outstanding issue for Xenial. I think we can wait another day or so before we have to make a final decision. I'll wait until tomorrow and then mark it as verified if you haven't already done so by then.

Adam Conrad (adconrad) wrote :

With previous xenial kernels:

XFAIL: nptl/tst-signal6
XFAIL: nptl/tst-thread-exit-clobber
XFAIL: signal/tst-minsigstksz-1
XFAIL: signal/tst-minsigstksz-2
XFAIL: signal/tst-minsigstksz-3
XFAIL: signal/tst-minsigstksz-3a
XFAIL: signal/tst-minsigstksz-4
XFAIL: support/tst-xsigstack

With the kernel in xenial-proposed:

XPASS: nptl/tst-signal6
XPASS: nptl/tst-thread-exit-clobber
XPASS: signal/tst-minsigstksz-1
XPASS: signal/tst-minsigstksz-2
XPASS: signal/tst-minsigstksz-3
XPASS: signal/tst-minsigstksz-3a
XPASS: signal/tst-minsigstksz-4
XPASS: support/tst-xsigstack

I declare this a resounding success and will adjust the tags accordingly.

tags: added: verification-done-xenial
removed: verification-needed-xenial
Changed in linux (Ubuntu):
status: Confirmed → Fix Released
Launchpad Janitor (janitor) wrote :
Download full text (18.6 KiB)

This bug was fixed in the package linux - 4.4.0-168.197

linux (4.4.0-168.197) xenial; urgency=medium

  * CVE-2018-12207
    - KVM: x86: MMU: Encapsulate the type of rmap-chain head in a new struct
    - KVM: x86: MMU: Consolidate quickly_check_mmio_pf() and is_mmio_page_fault()
    - KVM: x86: MMU: Move handle_mmio_page_fault() call to kvm_mmu_page_fault()
    - KVM: MMU: rename has_wrprotected_page to mmu_gfn_lpage_is_disallowed
    - KVM: MMU: introduce kvm_mmu_gfn_{allow,disallow}_lpage
    - KVM: x86: MMU: Make mmu_set_spte() return emulate value
    - KVM: x86: MMU: Move initialization of parent_ptes out from
    - KVM: x86: MMU: always set accessed bit in shadow PTEs
    - KVM: x86: MMU: Move parent_pte handling from kvm_mmu_get_page() to
    - KVM: x86: MMU: Remove unused parameter parent_pte from kvm_mmu_get_page()
    - KVM: x86: simplify ept_misconfig
    - KVM: x86: extend usage of RET_MMIO_PF_* constants
    - KVM: MMU: drop vcpu param in gpte_access
    - kvm: Convert kvm_lock to a mutex
    - kvm: x86: Do not release the page inside mmu_set_spte()
    - KVM: x86: make FNAME(fetch) and __direct_map more similar
    - KVM: x86: remove now unneeded hugepage gfn adjustment
    - KVM: x86: change kvm_mmu_page_get_gfn BUG_ON to WARN_ON
    - KVM: x86: add tracepoints around __direct_map and FNAME(fetch)
    - SAUCE: KVM: vmx, svm: always run with EFER.NXE=1 when shadow paging is
    - SAUCE: x86: Add ITLB_MULTIHIT bug infrastructure
    - SAUCE: kvm: mmu: ITLB_MULTIHIT mitigation
    - SAUCE: kvm: Add helper function for creating VM worker threads
    - SAUCE: kvm: x86: mmu: Recovery of shattered NX large pages
    - SAUCE: cpu/speculation: Uninline and export CPU mitigations helpers
    - SAUCE: kvm: x86: mmu: Apply global mitigations knob to ITLB_MULTIHIT

  * CVE-2019-11135
    - KVM: x86: Emulate MSR_IA32_ARCH_CAPABILITIES on AMD hosts
    - KVM: x86: use Intel speculation bugs and features as derived in generic x86
    - x86/msr: Add the IA32_TSX_CTRL MSR
    - x86/cpu: Add a helper function x86_read_arch_cap_msr()
    - x86/cpu: Add a "tsx=" cmdline option with TSX disabled by default
    - x86/speculation/taa: Add mitigation for TSX Async Abort
    - x86/speculation/taa: Add sysfs reporting for TSX Async Abort
    - kvm/x86: Export MDS_NO=0 to guests when TSX is enabled
    - x86/tsx: Add "auto" option to the tsx= cmdline parameter
    - x86/speculation/taa: Add documentation for TSX Async Abort
    - x86/tsx: Add config options to set tsx=on|off|auto
    - SAUCE: x86/speculation/taa: Call tsx_init()
    - SAUCE: x86/cpu: Include cpu header from bugs.c
    - [Config] Disable TSX by default when possible

  * CVE-2019-0154
    - SAUCE: i915_bpo: drm/i915: Lower RM timeout to avoid DSI hard hangs
    - SAUCE: i915_bpo: drm/i915/gen8+: Add RC6 CTX corruption WA
    - SAUCE: drm/i915/gen8+: Add RC6 CTX corruption WA

  * CVE-2019-0155
    - SAUCE: i915_bpo: drm/i915/gtt: Add read only pages to gen8_pte_encode
    - SAUCE: i915_bpo: drm/i915/gtt: Read-only pages for insert_entries on bdw+
    - SAUCE: i915_bpo: drm/i915/gtt: Disable read-on...

Changed in linux (Ubuntu Xenial):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.