[LU-9687] kernel update [RHEL6.9 2.6.32-696.3.2.el6] Created: 19/Jun/17  Updated: 14/Jul/17  Resolved: 14/Jul/17

Status: Resolved
Project: Lustre
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Bob Glossman (Inactive) Assignee: Bob Glossman (Inactive)
Resolution: Won't Fix Votes: 0
Labels: None

Issue Links:
Related
is related to LU-9572 kernel update [RHEL6.9 2.6.32-696.3.1... Resolved
is related to LU-9763 kernel update [RHEL6.9 2.6.32-696.6.3... Resolved
Severity: 3
Rank (Obsolete): 9223372036854775807

 Description   

Security Fix(es):

  • A flaw was found in the way memory was being allocated on the stack for user
    space binaries. If heap (or different memory region) and stack memory regions
    were adjacent to each other, an attacker could use this flaw to jump over the
    stack guard gap, cause controlled memory corruption on process stack or the
    adjacent memory region, and thus increase their privileges on the system. This
    is a kernel-side mitigation which increases the stack guard gap size from one
    page to 1 MiB to make successful exploitation of this issue more difficult.
    (CVE-2017-1000364, Important)

Bugs fixed (https://bugzilla.redhat.com/):

1461333 - CVE-2017-1000364 kernel: heap/stack gap jumping via unbounded stack allocations



 Comments   
Comment by Gerrit Updater [ 20/Jun/17 ]

Bob Glossman (bob.glossman@intel.com) uploaded a new patch: https://review.whamcloud.com/27735
Subject: LU-9687 kernel: kernel update RHEL6.9 [2.6.32-696.3.2.el6]
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: ee1a77dd6ef131c643006d71f748bc81000bb798

Comment by Bob Glossman (Inactive) [ 21/Jun/17 ]

el6 support of lustre on master is currently broken, as reported in LU-20
This mod will never give +test for results using ldiskfs on el6.9 without a solution to that problem or reverting the offending mod.

Comment by Bob Glossman (Inactive) [ 14/Jul/17 ]

This ticket is now obsolete. Replaced by LU-9763.

Generated at Sat Feb 10 02:28:21 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.