óÐÉÓÏË ÉÚÍÅÎÅÎÉÊ × Linux 4.14.266

 
cgroup-v1: Require capabilities to set release_agent [+ + +]
Author: Eric W. Biederman <[email protected]>
Date:   Thu Jan 20 11:04:01 2022 -0600

    cgroup-v1: Require capabilities to set release_agent
    
    commit 24f6008564183aa120d07c03d9289519c2fe02af upstream.
    
    The cgroup release_agent is called with call_usermodehelper.  The function
    call_usermodehelper starts the release_agent with a full set fo capabilities.
    Therefore require capabilities when setting the release_agaent.
    
    Reported-by: Tabitha Sable <[email protected]>
    Tested-by: Tabitha Sable <[email protected]>
    Fixes: 81a6a5cdd2c5 ("Task Control Groups: automatic userspace notification of idle cgroups")
    Cc: [email protected] # v2.6.24+
    Signed-off-by: "Eric W. Biederman" <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>
    [mkoutny: Adjust for pre-fs_context, duplicate mount/remount check, drop log messages.]
    Acked-by: Michal Koutný <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
 
Linux: Linux 4.14.266 [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Fri Feb 11 08:43:36 2022 +0100

    Linux 4.14.266
    
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Jon Hunter <[email protected]>
    Tested-by: Linux Kernel Functional Testing <[email protected]>
    Tested-by: Slade Watkins <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
moxart: fix potential use-after-free on remove path [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Thu Jan 27 08:16:38 2022 +0100

    moxart: fix potential use-after-free on remove path
    
    commit bd2db32e7c3e35bd4d9b8bbff689434a50893546 upstream.
    
    It was reported that the mmc host structure could be accessed after it
    was freed in moxart_remove(), so fix this by saving the base register of
    the device and using it instead of the pointer dereference.
    
    Cc: Ulf Hansson <[email protected]>
    Cc: Xiyu Yang <[email protected]>
    Cc: Xin Xiong <[email protected]>
    Cc: Xin Tan <[email protected]>
    Cc: Tony Lindgren <[email protected]>
    Cc: Yang Li <[email protected]>
    Cc: [email protected]
    Cc: stable <[email protected]>
    Reported-by: whitehat002 <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
tipc: improve size validations for received domain records [+ + +]
Author: Jon Maloy <[email protected]>
Date:   Sat Feb 5 14:11:18 2022 -0500

    tipc: improve size validations for received domain records
    
    commit 9aa422ad326634b76309e8ff342c246800621216 upstream.
    
    The function tipc_mon_rcv() allows a node to receive and process
    domain_record structs from peer nodes to track their views of the
    network topology.
    
    This patch verifies that the number of members in a received domain
    record does not exceed the limit defined by MAX_MON_DOMAIN, something
    that may otherwise lead to a stack overflow.
    
    tipc_mon_rcv() is called from the function tipc_link_proto_rcv(), where
    we are reading a 32 bit message data length field into a uint16.  To
    avert any risk of bit overflow, we add an extra sanity check for this in
    that function.  We cannot see that happen with the current code, but
    future designers being unaware of this risk, may introduce it by
    allowing delivery of very large (> 64k) sk buffers from the bearer
    layer.  This potential problem was identified by Eric Dumazet.
    
    This fixes CVE-2022-0435
    
    Reported-by: Samuel Page <[email protected]>
    Reported-by: Eric Dumazet <[email protected]>
    Fixes: 35c55c9877f8 ("tipc: add neighbor monitoring framework")
    Signed-off-by: Jon Maloy <[email protected]>
    Reviewed-by: Xin Long <[email protected]>
    Reviewed-by: Samuel Page <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
x86/mm, mm/hwpoison: Fix the unmap kernel 1:1 pages check condition [+ + +]
Author: luofei <[email protected]>
Date:   Mon Feb 7 22:20:28 2022 -0500

    x86/mm, mm/hwpoison: Fix the unmap kernel 1:1 pages check condition
    
    When fd0e786d9d09 ("x86/mm, mm/hwpoison: Don't unconditionally unmap
    kernel 1:1 pages") was backported to 4.14.y, the logic was reversed when
    calling memory_failure() to determine whether it needs to unmap the
    kernel page. Only when memory_failure() returns successfully, the kernel
    page can be unmapped.
    
    Signed-off-by: luofei <[email protected]>
    Cc: [email protected] #v4.14.x
    Cc: [email protected] #v4.15.x
    Signed-off-by: Greg Kroah-Hartman <[email protected]>