[LU-10088] kernel update [RHEL6.9 2.6.32-696.13.2.el6] Created: 05/Oct/17  Updated: 13/Dec/17  Resolved: 17/Nov/17

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

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-10037 kernel update [RHEL6.9 2.6.32-696.10.... Resolved
is related to LU-10241 kernel update [RHEL6.9 2.6.32-696.16.... Resolved
Severity: 3
Rank (Obsolete): 9223372036854775807

 Description   

Security Fix(es):

Kernel memory corruption due to a buffer overflow was found in brcmf_cfg80211_mgmt_tx() function in Linux kernels from v3.9-rc1 to v4.13-rc1. The vulnerability can be triggered by sending a crafted NL80211_CMD_FRAME packet via netlink. This flaw is unlikely to be triggered remotely as certain userspace code is needed for this. An unprivileged local user could use this flaw to induce kernel memory corruption on the system, leading to a crash. Due to the nature of the flaw, privilege escalation cannot be fully ruled out, although it is unlikely. (CVE-2017-7541, Moderate)

Bug Fix(es):

Previously, removal of a rport during ISCSI target scanning could cause a kernel panic. This was happening because addition of STARGET_REMOVE to the rport state introduced a race condition to the SCSI code. This update adds the STARGET_CREATED_REMOVE state as a possible state of the rport and appropriate handling of that state, thus fixing the bug. As a result, the kernel panic no longer occurs under the described circumstances. (BZ#1472127)
Previously, GFS2 contained multiple bugs where the wrong inode was assigned to GFS2 cluster-wide locks (glocks), or the assigned inode was cleared incorrectly. Consequently, kernel panic could occur when using GFS2. With this update, GFS2 has been fixed, and the kernel no longer panics due to those bugs. (BZ#1479397)
Previously, VMs with memory larger than 64GB running on Hyper-V with Windows Server hosts reported potential memory size of 4TB and more, but could not use more than 64GB. This was happening because the Memory Type Range Register (MTRR) for memory above 64GB was omitted. With this update, the /proc/mtrr file has been fixed to show correct base/size if they are more than 44 bit wide. As a result, the whole size of memory is now available as expected under the described circumstances. (BZ#1482855)

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

BZ - 1473198 - CVE-2017-7541 kernel: Possible heap buffer overflow in brcmf_cfg80211_mgmt_tx()



 Comments   
Comment by Gerrit Updater [ 07/Oct/17 ]

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

Comment by Gerrit Updater [ 07/Oct/17 ]

Bob Glossman (bob.glossman@intel.com) uploaded a new patch: https://review.whamcloud.com/29362
Subject: LU-10088 kernel: kernel update RHEL6.9 [2.6.32-696.13.2.el6]
Project: fs/lustre-release
Branch: b2_10
Current Patch Set: 1
Commit: 46a26b308e49185789acb2cbbd292b7d60e0b4d4

Comment by Gerrit Updater [ 11/Oct/17 ]

John L. Hammond (john.hammond@intel.com) merged in patch https://review.whamcloud.com/29362/
Subject: LU-10088 kernel: kernel update RHEL6.9 [2.6.32-696.13.2.el6]
Project: fs/lustre-release
Branch: b2_10
Current Patch Set:
Commit: b0b667ac681064f1e8bd8877dc000c6f526800ef

Comment by Bob Glossman (Inactive) [ 17/Nov/17 ]

replaced by LU-10241, a later kernel version update

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