PSA: Update your kernel (local privilege escalation in AppArmor parser)

forest · March 15

In case anyone hasn't done so already, update your kernels if you are on a system with AppArmor (e.g. Debian) as there is a local privilege escalation vulnerability (among other vulnerabilities):

https://cdn2.qualys.com/advisory/2026/03/10/crack-armor.txt

A quick-and-dirty (and non-persistent) mitigation would probably be chmod go-rwx /sys/kernel/security/.

jsg · March 15

Da sakkurity of linux' sakkurity layer!

rpqu · March 15

Sigh, it took 8 months. I guess the maintainers doesn't think it's critical

yoursunny · March 15

We have 22 KVM servers and 4 hardware devices.
We've been working on this for the past 6 hours, for the protection of yoursunny summer host customers and AS200690 peers.

18 KVM servers are on Debian trixie and have been upgraded.
1 KVM server and DELL 7040 Micro have been upgraded from Debian bookworm to trixie.
3 KVM servers on Debian bookworm and the Raspberry 400 on Ubuntu noble have no upgrades available, so we ran the mitigation command.
Beaglebone Black and GL-AR750 do not have AppArmor kernel module so these are safe.

We hereby request our upstream providers to apply these kernel patches, as we haven't seen reboots.
@Advin @DigiRDP @hosthatch @NDTN @crunchbits @Hassan @DartNode
@EvolutionHost @neeon @Lyphiard @VirMach @Hosteroid @host_c @hostbrr @labze
@ksoutar @f4net @admax @Francisco @heartbeat_IT @ParadoxNetworks @HostDoc

kait · March 15

(async function() {
  'use strict';
  let comments = document.querySelectorAll('[id^="Comment"]');

  comments.forEach((e) => {
    if (e.querySelector(".Username").href.endsWith("yoursunny")) {
      e.hidden = true;
    }
  });
})();

ksoutar · March 15

@yoursunny said:
We have 22 KVM servers and 4 hardware devices.
We've been working on this for the past 6 hours, for the protection of yoursunny summer host customers and AS200690 peers.

18 KVM servers are on Debian trixie and have been upgraded.

1 KVM server and DELL 7040 Micro have been upgraded from Debian bookworm to trixie.

3 KVM servers on Debian bookworm and the Raspberry 400 on Ubuntu noble have no upgrades available, so we ran the mitigation command.

Beaglebone Black and GL-AR750 do not have AppArmor kernel module so these are safe.

We hereby request our upstream providers to apply these kernel patches, as we haven't seen reboots.

Did some more digging into this, since we are only running VMs on top of debian, with only our staff (who already have root) having access to local accounts on debian itself, this is not a huge risk, the primary risk is for those shared use or container based systems. We however, will schedule a maintenance window to process reboots on all our DC infra that is running debian.

Thanks for the heads up.

host_c · March 15

@forest

THX on the heads UP!.

@yoursunny

The kernel currently running on our nodes is from December 2025, and we will move the patching schedule forward rather than waiting for the originally planned June–July window.

That said, based on our current setup, this issue does not affect us in practice. We do not expose these nodes directly to the internet, and we do not run LXC. For security reasons, I cannot go into more detail than that, but as of today this does not present a risk to our environment.

We will schedule this with some Security Bulletins of our own that are published under Active Issues on our Knowledgebase.

As some may already know, we usually perform two major update cycles per year, even if that comes at the expense low uptime statistics many users dislike to see. I think that the days of 500+ days uptime has passed, as the modern age does require frequent changes and upgrades that eventually needs a complete node reboot.

If this trend keeps up, the difference between Windows and Linux will eventually be zero. - no offens meant to anyone, nor do i wish to open that can of worms.

HOST-C

forest · March 16

@ksoutar said: Did some more digging into this, since we are only running VMs on top of debian, with only our staff (who already have root) having access to local accounts on debian itself, this is not a huge risk, the primary risk is for those shared use or container based systems. We however, will schedule a maintenance window to process reboots on all our DC infra that is running debian.

@host_c said: That said, based on our current setup, this issue does not affect us in practice. We do not expose these nodes directly to the internet, and we do not run LXC. For security reasons, I cannot go into more detail than that, but as of today this does not present a risk to our environment.

So in other words, you're saying that you're comfortable running all processes on your system as effective root because all your admins already have root? And that any exploited non-root network-connected daemons can be comfortably elevated to root and that it would not count as a security issue in your view? If someone manages to exploit QEMU, you're comfortable with them being able to break out of the QEMU sandbox and obtain kernelmode privileges? Even if the system is on a separate network, you don't want to turn lateral movement into free privesc.

If you just don't want the downtime of rebooting, set the relevant directory mode 700 until your next reboot.

ksoutar · March 16

@forest said:

@ksoutar said: Did some more digging into this, since we are only running VMs on top of debian, with only our staff (who already have root) having access to local accounts on debian itself, this is not a huge risk, the primary risk is for those shared use or container based systems. We however, will schedule a maintenance window to process reboots on all our DC infra that is running debian.

@host_c said: That said, based on our current setup, this issue does not affect us in practice. We do not expose these nodes directly to the internet, and we do not run LXC. For security reasons, I cannot go into more detail than that, but as of today this does not present a risk to our environment.

So in other words, you're saying that you're comfortable running all processes on your system as effective root because all your admins already have root? And that any exploited non-root network-connected daemons can be comfortably elevated to root and that it would not count as a security issue in your view?

No, not at all, it certainly is a security issue, and we appreciate you bringing it up & finding it. It was more to the point of what @yoursunny said, who tagged me into the conversation, mentioning that it was critical that we run a restart immediately. After reviewing the risks here, we deemed it best to schedule out a time to reboot these systems to apply updates instead of immediately based on the threat level.

Hope this makes sense, and sorry for any confusion.

forest · March 16

@ksoutar said: we deemed it best to schedule out a time to reboot these systems to apply updates instead of immediately based on the threat level.

That's fair. It is an issue of defense in depth. It's important, but not critical to do it immediately if doing so causes downtime. I would, however, strongly recommend you at least chmod that directory until that maintenance window.

ksoutar · March 16

@forest said:

@ksoutar said: we deemed it best to schedule out a time to reboot these systems to apply updates instead of immediately based on the threat level.

That's fair. It is an issue of defense in depth. It's important, but not critical to do it immediately if doing so causes downtime. I would, however, strongly recommend you at least chmod that directory until that maintenance window.

Yes, we have already applied the patch on all systems, and scheduled a maintenance window, emails will be going out to our customers tomorrow to list when scheduled updates will be happening based on their server location.

Neoon · March 16

For this reason, we got livepatch on microLXC.
So far we should be good.

yoursunny · March 16

@ksoutar said:
It was more to the point of what @yoursunny said, who tagged me into the conversation, mentioning that it was critical that we run a restart immediately.

We did not demand anyone to perform an immediate restart.
We only want our upstream providers to be informed of this situation and assess their risks.

host_c · March 16

@forest

This AppArmor issue is a local host side privilege escalation/policy management flaw.

For a normal KVM/QEMU VM guest the guest runs its own kernel, while AppArmor is a host Linux Security Module that applies to host tasks/processes.

The QEMU docs also describe AppArmor/SELinux as mechanisms that restrict the QEMU process on the host, not something a guest can directly manipulate from inside the VM

A regular VM guest cannot use this alone to reach the node.
An LXC/container is different because it shares the host kernel - thoes using LXC are exposed to this flaw
A VM could only benefit indirectly if the attacker already has some host-side foothold or a separate VM-escape/QEMU bug.

This is a real security issue, don't get me wrong, but guest exploits does not mean atacker instantly gets node kernel access, it is not the case here, hence my reply to you in the first place that this will get scheduled in an early as possible maintenance window as we do need to notify customers upfront, and we cannot just unplug all vm's the next day in the morning.

If this would had been a life and death serous flaw that the VM can get access to the node via any type of exploit, then yes, your vm's would had been already rebooted by now.

This vulnerability does not magically enable lateral movement unless an attacker already:

has local execution on the host
or a container escape
or a QEMU exploit

Without that, the bug cannot be triggered.

As a hosting company:

Emergency reboots are normally reserved for:

VM → host escapes
remote kernel RCE
hypervisor breakouts/flaws/hangs

Again, the issue is serious, that is why it has to be dealt with a plan, not just apply patch, reboot, then fuck, half of them don't boot as the new version of XYZ conflicts with the VM config file/or other, now we have to redo manually 500 services, or worse.

Hope you get my point.

EDIT:

We will apply the fix, but I prefer to do a minimal testing before we rush in and do this, as usuall, it will mess up other things

Again. THX for the heads-up

nghialele · March 16

@kait said:

(async function() {
  'use strict';
  let comments = document.querySelectorAll('[id^="Comment"]');

  comments.forEach((e) => {
    if (e.querySelector(".Username").href.endsWith("yoursunny")) {
      e.hidden = true;
    }
  });
})();

Instruction unclear now my pc ping nihao777.cn

tinokun · March 16

@onidel Just checking to see if you're considering a maintenance window for this? Also, it would be amazing if you could bundle in the latest microcode updates for your Turin ranges to address the Zen 5 RDSEED bug, EntrySign, and the recent SEV-SNP advisories. It would be really nice to have all of these ironed out at once!

onidel · March 16

@tinokun said:
@onidel Just checking to see if you're considering a maintenance window for this? Also, it would be amazing if you could bundle in the latest microcode updates for your Turin ranges to address the Zen 5 RDSEED bug, EntrySign, and the recent SEV-SNP advisories. It would be really nice to have all of these ironed out at once!

most nodes in Singapore have already received the kernel update, and we are currently working on updating the remaining ones. Other locations will follow after that.

VMs were live-migrated during this process, so there was no downtime. The only exception is VMs with SEV-SNP enabled, which cannot be live-migrated. For those VMs, we will send an email notification in the next couple of days.

forest · March 19

@host_c said: but guest exploits does not mean atacker instantly gets node kernel access

@host_c said: This vulnerability does not magically enable lateral movement unless an attacker already:

or a QEMU exploit

QEMU exploits are not particularly uncommon. QEMU has a huge surface area, much larger than that of KVM from within the guest. If a guest exploits QEMU on a secured host node, there isn't much they can do because they'll be trapped running as that user, hopefully with at least the seccomp sandbox enabled. But if the host node has this vulnerability, now they can exploit the host kernel as well.

I agree that it's not a life-or-death emergency update. This isn't the next Meltdown or DirtyCOW, for sure, but it shouldn't be downplayed either. After all, it's essentially the same situation as running QEMU itself as root on the host, which no provider should ever do.

@host_c said: that is why it has to be dealt with a plan, not just apply patch, reboot

That's why I suggested the chmod mitigation to hosts in general. Then the issue is completely mitigated without reboot and you can take your time to plan for the next maintenance window.

Howdy, Stranger!

Categories

In this Discussion

PSA: Update your kernel (local privilege escalation in AppArmor parser)

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

PSA: Update your kernel (local privilege escalation in AppArmor parser)

Comments