Bug#1050256: autopkgtest fails on debci
On 9/4/23 12:32, Michael Biebl wrote: Am 04.09.23 um 20:23 schrieb Mathias Gibbens: On Mon, 2023-09-04 at 01:00 -0700, John Johansen wrote: I took a quick look through v6.1..v6.3.1 there is a patch that I think is the likely fix, it first landed in v6.2 1cf26c3d2c4c apparmor: fix apparmor mediating locking non-fs unix sockets Thanks for the pointer John -- I think that is the fix we've been looking for! Commit 1cf26c3d2c4c doesn't apply cleanly to the v6.1 tree due to the other commits from the patchset of Oct 3, 2022 that modified a bunch of the apparmor code. Because I couldn't quickly cherry-pick all the changes without amassing a large diff, I made the small proof-of- concept patch at the end of this message and applied it to the 6.1.38- 4 kernel from bookworm. Booting with the patched kernel allows services to start up in containers without any issues. :) So, I think the next step should be to get that commit properly backported to the v6.1 longterm tree and included in an upstream release. Hopefully that would be able to happen in enough time so that it is bundled with the kernel updates for bookworm's point release next month. If not, we should be sure to get it into Debian's packaging so at least there's a proper fix available. Thanks for the update Mathias, this looks very promising. A stable update of the Linux 6.1.x kernel would obviously be the ideal solution. John, could you help with getting this fix into 6.1.x? yes, I am working on a patch.
Bug#1050256: autopkgtest fails on debci
I took a quick look through v6.1..v6.3.1 there is a patch that I think is the likely fix, it first landed in v6.2 1cf26c3d2c4c apparmor: fix apparmor mediating locking non-fs unix sockets it matches up the reported audit logs. Unfortunately it does not have a Fixes tag but as best I can figure it should be applied all the way back to. 56974a6fcfef apparmor: add base infastructure for socket mediation how/where this bug surfaces partly depends on the userspace policy and compiler which combines the features set supported by the kernel with what policy claims to support. So it is possible to have an affected kernel but not trigger the bug.
Bug#963493: Repeatable hard lockup running strace testsuite on 4.19.98+ onwards
On 6/26/20 9:50 AM, Steve McIntyre wrote:
> Hi Jann,
>
> On Fri, Jun 26, 2020 at 04:25:59PM +0200, Jann Horn wrote:
>> On Fri, Jun 26, 2020 at 3:41 PM Greg KH wrote:
>>> On Fri, Jun 26, 2020 at 12:35:58PM +0100, Steve McIntyre wrote:
>
> ...
>
Considering I'm running strace build tests to provoke this bug,
finding the failure in a commit talking about ptrace changes does look
very suspicious...!
Annoyingly, I can't reproduce this on my disparate other machines
here, suggesting it's maybe(?) timing related.
>>
>> Does "hard lockup" mean that the HARDLOCKUP_DETECTOR infrastructure
>> prints a warning to dmesg? If so, can you share that warning?
>
> I mean the machine locks hard - X stops updating, the mouse/keyboard
> stop responding. No pings, etc. When I reboot, there's nothing in the
> logs.
>
>> If you don't have any way to see console output, and you don't have a
>> working serial console setup or such, you may want to try re-running
>> those tests while the kernel is booted with netconsole enabled to log
>> to a different machine over UDP (see
>> https://www.kernel.org/doc/Documentation/networking/netconsole.txt).
>
> ACK, will try that now for you.
>
>> You may want to try setting the sysctl kernel.sysrq=1 , then when the
>> system has locked up, press ALT+PRINT+L (to generate stack traces for
>> all active CPUs from NMI context), and maybe also ALT+PRINT+T and
>> ALT+PRINT+W (to collect more information about active tasks).
>
> Nod.
>
>> (If you share stack traces from these things with us, it would be
>> helpful if you could run them through scripts/decode_stacktrace.pl
>>from the kernel tree first, to add line number information.)
>
> ACK.
>
>> Trying to isolate the problem:
>>
>> __end_current_label_crit_section and end_current_label_crit_section
>> are aliases of each other (via #define), so that line change can't
>> have done anything.
>>
>> That leaves two possibilities AFAICS:
>> - the might_sleep() call by itself is causing issues for one of the
>> remaining users of begin_current_label_crit_section() (because it
>> causes preemption to happen more often where it didn't happen on
>> PREEMPT_VOLUNTARY before, or because it's trying to print a warning
>> message with the runqueue lock held, or something like that)
>> - the lack of "if (aa_replace_current_label(label) == 0)
>> aa_put_label(label);" in __begin_current_label_crit_section() is
>> somehow causing issues
>>
>> You could try to see whether just adding the might_sleep(), or just
>> replacing the begin_current_label_crit_section() call with
>> __begin_current_label_crit_section(), triggers the bug.
>>
>>
>> If you could recompile the kernel with CONFIG_DEBUG_ATOMIC_SLEEP - if
>> that isn't already set in your kernel config -, that might help track
>> down the problem, unless it magically makes the problem stop
>> triggering (which I guess would be conceivable if this indeed is a
>> race).
>
> OK, will try that second...
>
I have not been able to reproduce but
So looking at linux-4.19.y it looks like
1f8266ff5884 apparmor: don't try to replace stale label in ptrace access check
was picked without
ca3fde5214e1 apparmor: don't try to replace stale label in ptraceme check
Both of them are marked as
Fixes: b2d09ae449ced ("apparmor: move ptrace checks to using labels")
so I would expect them to be picked together.
ptraceme is potentially updating the task's cred while the access check is
running.
Try building after picking
ca3fde5214e1 apparmor: don't try to replace stale label in ptraceme check
Bug#679597: apparmor: AppArmor totally broken
On 07/01/2012 03:02 PM, intrigeri wrote: > tags 679597 + patch > thanks > > Hi, > > John Johansen wrote (30 Jun 2012 07:30:20 GMT) : >> Fix the parser so it checks for the presence of the network feature in the >> compatibility interface. Previously it was assuming that if the compatibility >> interface was present that network rules where also present, this is not >> necessarily true and causes apparmor to break when only the compatibility >> patch is applied. > > Thanks for this patch. > > It works fine for me with the current sid kernel > (linux-image-3.2.0-3-amd64 3.2.21-3). > > However, on a kernel that both the compat + network patches applied > (that is, not the current sid kernel), installing the apparmor > userspace tools with this patch applied results in reloading all > profiles (I guess this is normal postinst operation), which triggers > tons of such error messages: > > Warning from /etc/apparmor.d/usr.bin.evince > (/etc/apparmor.d/usr.bin.evince line 148): profile sanitized_helper > network rules not enforced > > And then, it seems like the applications covered by these profile are > denied access to the network entirely: > > type=1400 audit(1341176452.889:291): apparmor="DENIED" > operation="create" parent=1 profile="/usr/sbin/ntpd" pid=6748 > comm="ntpd" family="inet" sock_type="dgram" protocol=0 > > (I've not tried rebooting and see what happens, though.) > > So I'm not too sure the network feature detection was fixed entirely. > > But well, in any case, the patch fixes the actual, current bug, > which is great! > Gah, yes I didn't test this patch in the case of a kernel without the networking patch followed by a kernel with it. What is happening is it is applying the check against both the kernel and cached policy feature set, and turning off networking based on what is stored in the cached policy. Which in turn causes it to generate the new cache without networking support. The only way to fix this with the original patch is to remove the cache and then regenerate it. Sorry about that The check just needs to be moved a little. The initial patch should be reversed and the following patch should be applied. With the caveat that I haven't had a chance to finish testing it yet. Though I should have that done in a few hours. === modified file 'parser/parser_main.c' --- parser/parser_main.c2012-07-01 08:35:05 + +++ parser/parser_main.c2012-07-02 07:49:14 + @@ -1187,7 +1182,12 @@ write_cache = 0; skip_read_cache = 1; return; - } + } else if (strstr(flags_string, "network")) + kernel_supports_network = 1; + else + kernel_supports_network = 0; + + /* * Deal with cache directory versioning: -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#679597: apparmor: AppArmor totally broken
On 06/29/2012 07:54 PM, intrig...@debian.org wrote: > Package: apparmor > Version: 2.7.103-3 > Severity: grave > X-Debbugs-CC: john.johan...@canonical.com, k...@debian.org, mi...@riseup.net > > Hi, > > (following-up on #676515) > > John Johansen wrote (26 Jun 2012 17:48:38 GMT) : >> Okay, there are 4 kernel patches, not all of them are needed depending on >> whether >> the network patch is applied or not. > >> If you don't want to apply the networking patch >> 0001-apparmor-remove-advertising-the-support-of-network-r.patch > >> Stops the kernel interface from incorrectly advertising that it >> supports network rules. A further patch (not attached) to >> userspace will also have to be applied > > Thanks, John, for your work on this. > > For those who did not follow the entire saga, this patch was applied > in the linux 3.2.21-3 source package, to complement the incomplete > AppArmor compatibility patch, so Debian bug #676515 was closed, > as the kernel side is now sorted out. So far, so good. > > However, as expected, this is not enough to make AppArmor usable, so > the current state in current sid is still a regression compared to > when the compatibility patch was not applied to the kernel: it used to > be bad, but relatively usable, and it's now totally unusable. > > This bug is here to track the additional patch against userspace, > that John mentioned was needed, which is confirmed by my experience. > > Sorry I meant to have attached this patch already as a separate comment when I posted the kernel patches. --- Fix the parser so it checks for the presence of the network feature in the compatibility interface. Previously it was assuming that if the compatibility interface was present that network rules where also present, this is not necessarily true and causes apparmor to break when only the compatibility patch is applied. Signed-off-by: John Johansen === modified file 'parser/parser_main.c' --- parser/parser_main.c2012-04-11 23:03:21 + +++ parser/parser_main.c2012-06-30 06:31:05 + @@ -873,6 +873,11 @@ //fprintf(stderr, "flags string: %s\n", flags_string); //fprintf(stderr, "changehat %d\n", flag_changehat_version); } + if (strstr(flags_string, "network")) + kernel_supports_network = 1; + else + kernel_supports_network = 0; + return; fail: -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
