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
