CVE-2026-80672

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

ntfs: fix u16 truncation of restart-area length check

ntfs check restart area() validates that the $LogFile restart area and its trailing log client record array fit within the system page size:

u16 ra ofs, ra len, ca ofs;
...
ra len = ca ofs + le16 to cpu(ra->log clients) *
        sizeof(struct log client record);
if (ra ofs + ra len > le32 to cpu(rp->system page size) || ...)
    return false;

ra len is u16, but the right-hand side is computed in size t (sizeof(struct log client record) == 160). Both ca ofs and log clients come straight from the on-disk restart area. With an on-disk log clients of 410 the product 410 * 160 = 65600; adding ca ofs and storing into the u16 ra len truncates modulo 65536 (e.g. ca ofs 64 gives ra len 128), so the "fits in the page" check passes even though the client array described by log clients extends far beyond the page.

ntfs check log client array() then walks the array bounded only by the on-disk log clients count:

cr = ca + idx;
if (cr->prev client != LOGFILE NO CLIENT) ...

For log clients 410 it dereferences records up to ca + 409 * 160, ~64 KiB past the kvzalloc(system page size) restart-page buffer -- an out-of-bounds read of attacker-controlled extent, reachable when a crafted NTFS image is mounted (load and check logfile() at mount time). This is the in-kernel analogue of CVE-2022-30789, fixed in the ntfs-3g userspace driver but never in this revived classic driver.

Compute the restart-area length in a u32 so the existing bounds check rejects an over-large client array instead of being defeated by the truncation. Widen ra ofs and ca ofs to u32 as well: both are loaded from le16 on-disk fields and every comparison already promotes to int/size t, so this changes no result and keeps the declaration uniform.