CVE-2026-68458: binder: cache secctx size before release zeroes it

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

binder: cache secctx size before release zeroes it

bindertransaction() bounds the scatter-gather buffer area with sgbufendoffset and subtracts the aligned LSM context size because the secctx is written at the tail of that area. The subtraction reads lsmctx.len, but that field has already been cleared by the time the line runs:

securitysecidtosecctx(secid, &lsmctx) / lsmctx.len set / lsmctxalignedsize = ALIGN(lsmctx.len, sizeof(u64)) extrabufferssize += lsmctxalignedsize ... securityreleasesecctx(&lsmctx) / memset zeroes len / ... sgbufendoffset = sgbufoffset + extrabufferssize - ALIGN(lsmctx.len, sizeof(u64)) / ALIGN(0,8) /

securityreleasesecctx() does memset(cp, 0, sizeof(cp)), so lsmctx.len reads back as 0 and the subtraction contributes nothing, leaving sgbufendoffset too large by the aligned secctx size on every transaction to a txnsecurityctx node.

Each BINDERTYPEPTR object then derives bufleft = sgbufendoffset - sgbufoffset as the sole upper bound on its copy, so the inflated end offset lets the copy run into the bytes that already hold the secctx.

The aligned size must therefore be cached before release rather than re-read from the now-cleared field. Fix by caching it in lsmctxalignedsize at function scope when it is first computed and subtracting lsmctxalignedsize instead of re-reading lsmctx.len after release. Reuse the same value for the earlier bufoffset computation.