In the Linux kernel, the following vulnerability has been resolved:

dm-pcache: validate segid fields from persistent memory

cacheposdecode(), cachekeydecode() and the last-kset branches of cachereplay(), the writeback worker and the GC worker take a cache segment id from the cache device metadata and index cache->segments[] with it without checking it against cache->nsegs. That metadata is only CRC-protected with a fixed public seed, so whoever supplies the cache device on a table load (CAPSYSADMIN) controls the id; an out-of-range value forms a wild pcachecachesegment pointer that is dereferenced and written through -- an out-of-bounds read and write driven by on-disk data.

Add cachesegidvalid() and reject an out-of-range id at each decode site, failing the operation with -EIO instead of indexing past the array. Bound the id against the initialized-segment count (cacheinfo.nsegs) rather than the physical device total. A forged cacheinfo.nsegs below segnum otherwise leaves segments[cacheinfo.nsegs..segnum) as zeroed structs whose data pointer is NULL, so a forged id in that window would still be dereferenced. A later patch guarantees cacheinfo.nsegs <= segnum, and a driver-created cache sets the two equal, so valid images are unaffected.

In the Linux kernel, the following vulnerability has been resolved:

KVM: SEV: Compute the correct max length of the in-GHCB scratch area

When setting the length of the GHCB scratch area, and the area is in the GHCB shared buffer, set the effective length of the scratch area to the max possible size given the start of the guest-provided pointer, and the end of the shared buffer.

The code was "fine" when first introduced, as KVM doesn't consult the length of the buffer when emulating MMIO, because the passed in @len always specifies the max size required. But for PSC requests, the incoming @len is just the minimum length (to process the header), and KVM needs to know the full size of the scratch area to avoid buffer overflows (spoiler alert).

Opportunistically rename @len => @minlen to better reflect its role.

Integer overflow in the hrtimerforward function (hrtimer.c) in Linux kernel 2.6.21-rc4, when running on 64-bit systems, allows local users to cause a denial of service (infinite loop) via a timer with a large expiry value, which causes the timer to always be expired.