[pkg-apparmor] Bug#1121917: apparmor: Kernel version out of sync / doesn't conform to protocol

[intrigeri]

Hi,

Thanks! I'm trying to understand if I can merely wait for 5.0 to be
stable, or if this bug deserves backporting the upstream fixes
earlier. For this I have a few questions for you inline below:

C. W. (2026-02-09):
> To make it short, good news: The bug still exists with the latest sid packages,
> but Mr. Johansens upstream commits/merges over the last few weeks fixes it. As
> there is a v5.0.0-alpha6 around, probably we'll see a new release soon, and
> putting that into sid will resolve everything.

Do you have a pointer to these upstream parser fixes?

> As I found some time on the weekend to narrow it down, just to notice the fix
> later: For the record, the actual main bug was in userland apparmor_parser, but
> happens only if the kernel apparmorfs exposes
> /sys/kernel/security/apparmor/features/policy/permstable32_version > 1, which
> happens with kernel commit 2e12c5f060176ede209673e4f63ea5d0e3c5814c . Current
> stable kernel doesn't do this yet.

FTR, I see Linux 6.17 and newer have this commit. I understand this is
why testing & sid are currently affected. It's good to know that
stable (Trixie) is not. But stable-backports has newer kernels so
depending on the answer to my next question, we might want to consider
getting the fix into Trixie.

> If this is the case, the parser compiles
> some types of rulesets wrong, in a way that make the kernel checks on importing
> fail (in policy_unpack.c, function unpack_perms_table, the AA_ARRAYEND part). I
> can upload some example file if someone still wants one, but as mentioned,
> there's a fix already.

Are you aware of any AppArmor policy shipped in Debian that triggers
this bug? Or did you notice this bug only with third-party policy so far?

Cheers,
-- 
intrigeri