[LU-9763] kernel update [RHEL6.9 2.6.32-696.6.3.el6] Created: 11/Jul/17  Updated: 22/Aug/17  Resolved: 29/Jul/17

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

Type: Bug Priority: Minor
Reporter: Bob Glossman (Inactive) Assignee: WC Triage
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Related
is related to LU-9687 kernel update [RHEL6.9 2.6.32-696.3.2... Resolved
is related to LU-9903 kernel update [RHEL6.9 2.6.32-696.10.... Resolved
Severity: 3
Rank (Obsolete): 9223372036854775807

 Description   

Security Fix(es):

  • The NFSv2 and NFSv3 server implementations in the Linux kernel through 4.10.13
    lacked certain checks for the end of a buffer. A remote attacker could trigger a
    pointer-arithmetic error or possibly cause other unspecified impacts using
    crafted requests related to fs/nfsd/nfs3xdr.c and fs/nfsd/nfsxdr.c.
    (CVE-2017-7895, Important)

Bug Fix(es):

  • If several file operations were started after a mounted NFS share had got idle
    and its Transmission Control Protocol (TCP) connection had therefore been
    terminated, these operations could cause multiple TCP SYN packets coming from
    the NFS client instead of one. With this update, the reconnection logic has been
    fixed, and only one TCP SYN packet is now sent in the described situation.
    (BZ#1450850)
  • When the ixgbe driver was loaded for a backplane-connected network card, a
    kernel panic could occur, because the ops.setup_fc function pointer was used
    before the initialization. With this update, ops.setup_fc is initialized
    earlier. As a result, ixgbe no longer panics on load. (BZ#1457347)
  • When setting an Access Control List (ACL) with 190 and more Access Control
    Entries (ACEs) on a NFSv4 directory, a kernel crash could previously occur. This
    update fixes the nfs4_getfacl() function, and the kernel no longer crashes under
    the described circumstances. (BZ#1449096)
  • When upgrading to kernel with the fix for stack guard flaw, a crash could
    occur in Java Virtual Machine (JVM) environments, which attempted to implement
    their own stack guard page. With this update, the underlying source code has
    been fixed to consider the PROT_NONE mapping as a part of the stack, and the
    crash in JVM no longer occurs under the described circumstances. (BZ#1466667)
  • When a program receives IPv6 packets using the raw socket, the ioctl(FIONREAD)
    and ioctl(SIOCINQ) functions can incorrectly return zero waiting bytes. This
    update fixes the ip6_input_finish() function to check the raw payload size
    properly. As a result, the ioctl() function now returns bytes waiting in the raw
    socket correctly. (BZ#1450870)
  • Previously, listing a directory on a non-standard XFS filesystem (with
    non-default multi-fsb directory blocks) could lead to a soft lock up due to
    array index overrun in the xfs_dir2_leaf_readbuf() function. This update fixes
    xfs_dir2_leaf_readbuf(), and the soft lock up no longer occurs under the
    described circumstances. (BZ#1445179)
  • Previously, aborts from the array after the Storage Area Network (SAN) fabric
    back-pressure led to premature reuse of still valid sequence with the same
    OX_ID. Consequently, an error message and data corruption could occur. This
    update fixes the libfc driver to isolate the timed out OX_IDs, thus fixing this
    bug. (BZ#1455550)
  • Previously, a kernel panic occurred when the mcelog daemon executed a huge
    page memory offline. This update fixes the HugeTLB feature of the Linux kernel
    to check for the Page Table Entry (PTE) NULL pointer in the page_check_address()
    function. As a result, the kernel panic no longer occurs under the described
    circumstances. (BZ#1444351)

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

1446103 - CVE-2017-7895 kernel: NFSv3 server does not properly handle payload bounds checking of WRITE requests



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

test of el6.9 on master will fail due to LU-9698.
possible solutions:

  1. don't test on el6 at all by removing Test-Paramters from the commit
  2. revert https://review.whamcloud.com/27549, that created the problem
  3. add an extra kernel patch to export kallsyms_lookup_name
Comment by James A Simmons [ 12/Jul/17 ]

4. land patch https://review.whamcloud.com/#/c/27874

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

James,
solution 4) will allow running on el6 without a fail at ldiskfs module load time, but won't support test. It pretends there is no kallsyms lookup even though there really is. This disables the dev_rdonly feature needed to allow test.

Comment by Gerrit Updater [ 13/Jul/17 ]

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

Comment by Gerrit Updater [ 29/Jul/17 ]

Oleg Drokin (oleg.drokin@intel.com) merged in patch https://review.whamcloud.com/28029/
Subject: LU-9763 kernel: kernel update RHEL6.9 [2.6.32-696.6.3.el6]
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 603b53c9736bd21c48f059794dd7d28f8d6ba1a0

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