readykernel-patch-85.17-82.0-1.vl7

An excessive resource consumption issue was found in the way the Linux kernel's networking subsystem processed TCP Selective Acknowledgment (SACK) segments. While processing SACK segments, the Linux kernel's socket buffer (SKB) data structure becomes fragmented, which leads to increased resource utilization to traverse and process these fragments as further SACK segments are received on the same TCP connection. A remote attacker could use this flaw to cause a denial of service (DoS) by sending a crafted sequence of SACK segments on a TCP connection.

An integer overflow was found in the way the Linux kernel's networking subsystem processed TCP Selective Acknowledgment (SACK) segments. While processing SACK segments, the Linux kernel's socket buffer (SKB) data structure becomes fragmented. Each fragment is about TCP maximum segment size (MSS) bytes. To efficiently process SACK blocks, the Linux kernel merges multiple fragmented SKBs into one, potentially overflowing the variable holding the number of segments. A remote attacker could use this flaw to crash the Linux kernel by sending a crafted sequence of SACK segments on a TCP connection with small value of TCP MSS, resulting in a denial of service.

If the amount of free memory is low, OOM killer would kill the tasks from cgroups without memory guarantees first. However, it seems more reasonable to kill the tasks from cgroups exceeding their guarantees the most.

It was discovered that inode tables created during online resize of an ext4 filesystem were not zeroed after that. This could potentially result in lower performance of the filesystem.

It was found that if no PMU counters were exposed to guest, KVM skipped the whole remaining PMU-related initialization, including filling of LBR-related data. As it turned out, Windows Server 2016 Essentials tried to access these data during the installation and failed to install as a result.

It was discovered that a certain sequence of operations related to IPv4 routing could trigger a kernel memory leak. An attacker could potentially exploit that from a container to cause a denial of service.

Freeing of a memory cgroup took longer than needed in certain cases.

It was found that the memcg ID number of a cgroup was released earlier than needed and could then be reused by a different cgroup. As a result, certain reference counters could be corrupted, leading to a kernel crash in memcg_css_release_check_kmem().

It was found that if a ploop image was revoked and then replaced using 'ploop replace', 'abort' flag was not cleared. As a result, subsequent I/O operations would fail.