Hi, The luksmeta 10-2 changelog says:
* Cherry-pick "fix gap allocator bounds checking". Closes: #1151196 [CVE-2026-111555] But according to the security tracker and upstream, that commit fixes the other luksmeta CVE: CVE-2026-107565 (#1150649): Fixed by https://www.google.com/url?q=https://github.com/latchset/luksmeta/commit/ba140c8f628237ed12e47e9829fec9c62fc5f89a&source=gmail&ust=1793799895372000&sa=E "libluksmeta: fix gap allocator bounds checking" (upstream PR #19) -> this is debian/patches/1791451386.v10-1-gba140c8.libluksmeta-fix-gap-allocator-bounds-checking.patch CVE-2026-111555 (#1151196): Fixed by https://www.google.com/url?q=https://github.com/latchset/luksmeta/commit/62b6491e8318b17ad8472a724ccab8324ec00aae&source=gmail&ust=1793799895372000&sa=E "libluksmeta: reject occupied slot ranges that extend past the gap" (upstream PR #21, in tag v11) I checked the 10-2 source on https://www.google.com/url?q=http://sources.debian.org&source=gmail&ust=1793799895372000&sa=E : - All added lines of ba140c8 are present in libluksmeta.c and test-lm-gap.c, and the removed lines are gone. So CVE-2026-107565 is fixed in 10-2. - 62b6491e is not there. read_header() in 10-2 checks "s->offset > sizeof(lm_t)" and "s->length <= maxlen" separately, but not the new r = (uint64_t) s->offset + s->length <= *length ? 0 : -EINVAL; So a checksum-valid header with an occupied slot extending past the gap is still accepted, which is CVE-2026-111555. - The libluksmeta.c hunk of 62b6491e applies cleanly to 10-2 (patch --dry-run). The rest of the commit adds a test case to test-lm-gap.c and links it against https://www.google.com/url?q=http://libcrc32c.la&source=gmail&ust=1793799895373000&sa=E in Makefile.am. So I think #1151196 should be reopened (or found in 10-2), and #1150649 can be closed with 10-2. Alternatively, upstream v11 contains both fixes. Static source check only; nothing was built or run. Regards
