CVE-2026-80672: ntfs: fix u16 truncation of restart-area length check

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

ntfs: fix u16 truncation of restart-area length check

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

u16 raofs, ralen, caofs; ... ralen = caofs + le16tocpu(ra->logclients) sizeof(struct logclientrecord); if (raofs + ralen > le32tocpu(rp->systempagesize) || ...) return false;

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

ntfschecklogclientarray() then walks the array bounded only by the on-disk logclients count:

cr = ca + idx; if (cr->prevclient != LOGFILENOCLIENT) ...

For logclients 410 it dereferences records up to ca + 409 160, ~64 KiB past the kvzalloc(systempagesize) restart-page buffer -- an out-of-bounds read of attacker-controlled extent, reachable when a crafted NTFS image is mounted (loadandchecklogfile() 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 raofs and caofs to u32 as well: both are loaded from le16 on-disk fields and every comparison already promotes to int/sizet, so this changes no result and keeps the declaration uniform.