linux-5.19.2

[Bruce Dubbs]

New point version.

[Douglas R. Reno]

See ​https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2 for release notes

Unfortunately, this does contain some security fixes.

CVE-2022-2588 (net_sched)

    net_sched: cls_route: remove from list when handle is 0
    
    commit 9ad36309e2719a884f946678e0296be10f0bb4c1 upstream.
    
    When a route filter is replaced and the old filter has a 0 handle, the old
    one won't be removed from the hashtable, while it will still be freed.
    
    The test was there since before commit 1109c00547fc ("net: sched: RCU
    cls_route"), when a new filter was not allocated when there was an old one.
    The old filter was reused and the reinserting would only be necessary if an
    old filter was replaced. That was still wrong for the same case where the
    old handle was 0.
    
    Remove the old filter from the list independently from its handle value.
    
    This fixes CVE-2022-2588, also reported as ZDI-CAN-17440.

CVE-2022-1184 (ext4 filesystem)

commit 193fc6f0de44a884fd4db82a9a368dafcd2c9bed
Author: Lukas Czerner <lczerner@redhat.com>
Date:   Mon Jul 4 16:27:20 2022 +0200

    ext4: check if directory block is within i_size
    
    [ Upstream commit 65f8ea4cd57dbd46ea13b41dc8bac03176b04233 ]
    
    Currently ext4 directory handling code implicitly assumes that the
    directory blocks are always within the i_size. In fact ext4_append()
    will attempt to allocate next directory block based solely on i_size and
    the i_size is then appropriately increased after a successful
    allocation.
    
    However, for this to work it requires i_size to be correct. If, for any
    reason, the directory inode i_size is corrupted in a way that the
    directory tree refers to a valid directory block past i_size, we could
    end up corrupting parts of the directory tree structure by overwriting
    already used directory blocks when modifying the directory.
    
    Fix it by catching the corruption early in __ext4_read_dirblock().

    Addresses Red-Hat-Bugzilla: #2070205
    CVE: CVE-2022-1184

CVE-2022-2586 (netfilter/nftables)

commit 0d07039397527361850c554c192e749cfc879ea9
Author: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Date:   Tue Aug 9 14:01:46 2022 -0300

    netfilter: nf_tables: do not allow SET_ID to refer to another table
    
    commit 470ee20e069a6d05ae549f7d0ef2bdbcee6a81b2 upstream.
    
    When doing lookups for sets on the same batch by using its ID, a set from a
    different table can be used.
    
    Then, when the table is removed, a reference to the set may be kept after
    the set is freed, leading to a potential use-after-free.
    
    When looking for sets by ID, use the table that was used for the lookup by
    name, and only return sets belonging to that same table.
    
    This fixes CVE-2022-2586, also reported as ZDI-CAN-17470.

[Xi Ruoyao]

A fourth vulnerability CVE-2022-2585, which is actually more dangerous (can be exploited by a completely unpriviledged user):

    posix-cpu-timers: Cleanup CPU timers before freeing them during exec
    
    Commit 55e8c8eb2c7b ("posix-cpu-timers: Store a reference to a pid not a
    task") started looking up tasks by PID when deleting a CPU timer.
    
    When a non-leader thread calls execve, it will switch PIDs with the leader
    process. Then, as it calls exit_itimers, posix_cpu_timer_del cannot find
    the task because the timer still points out to the old PID.
    
    That means that armed timers won't be disarmed, that is, they won't be
    removed from the timerqueue_list. exit_itimers will still release their
    memory, and when that list is later processed, it leads to a
    use-after-free.
    
    Clean up the timers from the de-threaded task before freeing them. This
    prevents a reported use-after-free.

[Xi Ruoyao]

Fixed at r11.1-169-gf2af13d7a.

SA 11.1-099 is published.