[From nobody Thu Apr 23 13:53:07 2026
Received: (at submit) by bugs.debian.org; 23 Apr 2026 10:36:00 +0000
X-Spam-Checker-Version: SpamAssassin 4.0.1-bugs.debian.org_2005_01_02
 (2024-03-25) on buxtehude.debian.org
X-Spam-Level: 
X-Spam-Status: No, score=-116.2 required=4.0 tests=BAYES_00,
 BODY_INCLUDES_PACKAGE,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,
 DKIM_VALID_AU,DKIM_VALID_EF,FROMDEVELOPER,HAS_PACKAGE,SPF_HELO_NONE,
 SPF_NONE,UNPARSEABLE_RELAY,USER_IN_DKIM_WELCOMELIST autolearn=ham
 autolearn_force=no version=4.0.1-bugs.debian.org_2005_01_02
X-Spam-Bayes: score:0.0000 Tokens: new, 17; hammy, 150; neutral, 85; spammy,
 0. spammytokens:
 hammytokens:0.000-+--Hx-spam-relays-external:sk:stravin,
 0.000-+--H*RT:sk:stravin, 0.000-+--Hx-spam-relays-external:311,
 0.000-+--H*RT:311, 0.000-+--H*RT:108
Return-path: <smcv@debian.org>
Received: from stravinsky.debian.org ([2001:41b8:202:deb::311:108]:44924)
 by buxtehude.debian.org with esmtps
 (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256)
 (Exim 4.96) (envelope-from <smcv@debian.org>) id 1wFrPb-00Cf9Y-38
 for submit@bugs.debian.org; Thu, 23 Apr 2026 10:36:00 +0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; 
 s=smtpauto.stravinsky;
 h=X-Debian-User:Content-Type:MIME-Version:Message-ID:
 Subject:To:From:Date:Reply-To:Cc:Content-Transfer-Encoding:Content-ID:
 Content-Description:In-Reply-To:References;
 bh=hJWkSt2zUJStSFxOzv21N9BYNQJypJqq7gzKJClvn30=; b=qZ9i/Z1OFbQ3nKOqxvs7dtzWu8
 RAHlzgPjihKsIX1jZvtkQKRM+H3YKFkJA666N8Nzy/Qd5QpoJ01RBE0ARSXYegtYxfIWv1zNF1Hta
 HQ9ER2L+c98adTiIV1liqTtdVLRv6BRJk4X3KMs+6cuoOuVlQc3/oj3/T7WmGn9MIUi0+7/Ps7m9R
 aoHULmpXPiIjp9pGh/Qop5sgye6giiERYcrBKBFdLY++dyCRn/PbGuWesJhsit93MAkeoZVMASwGN
 9EME/LBWG78i7KlNMJAUG5s7UK3xLHobxRMcoimkiVOzIh++G7syiJJKOMAtH9Elq2RNlk1SPDrx0
 WG5kAxsw==;
Received: from authenticated user by stravinsky.debian.org with esmtpsa
 (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256)
 (Exim 4.96) (envelope-from <smcv@debian.org>) id 1wFrPZ-002L5T-2t
 for submit@bugs.debian.org; Thu, 23 Apr 2026 10:35:58 +0000
Date: Thu, 23 Apr 2026 11:35:55 +0100
From: Simon McVittie <smcv@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: bubblewrap: CVE-2026-41163: Privilege escalation if setuid root, via
 ptrace
Message-ID: <aen2C5WPbf-GHkh3@definition.pseudorandom.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Mutt-Fcc: =.lists.debian/
X-Reportbug-Version: 13.2.0
X-Debian-User: smcv
Delivered-To: submit@bugs.debian.org

Package: bubblewrap
Version: 0.11.0-1
Severity: grave
Tags: security
X-Debbugs-Cc: Debian Security Team <team@security.debian.org>

bubblewrap >= 0.11.0 has a security vulnerability **if** installed 
setuid root:

>If bubblewrap is installed in setuid mode then the user can use ptrace
>to attach to bubblewrap and control the unprivileged part of the sandbox
>setup phase. This allows it the attacker to arbitrarily use the
>privileged operations, and in particular the "overlay mount" operation,
>allowing the creation of overlay mounts which is otherwise not allowed
>in the setuid version of bubblewrap.

A significant mitigation is that Debian hasn't installed bubblewrap as 
setuid root by default since 0.4.1-3 (2021, shortly before Debian 11). 
It only needs to be setuid root if the 
/proc/sys/kernel/unprivileged_userns_clone sysctl is turned off, but 
that sysctl has been on-by-default since Debian 11.

In stable, obviously we should fix the vulnerability in case someone is 
still using it as setuid. I've reported this as RC out of an abundance 
of caution, but I'm not sure whether the security team will want to do 
this as a DSA or not - thoughts?

Upstream have now deprecated the ability to install bubblewrap as setuid 
root. In the 0.11.2 upstream release that fixes the vulnerability, 
there's a new compile-time option for whether to support setuid (off by 
default), and if it's disabled, bubblewrap will just refuse to run if it 
detects that it has been made setuid (real uid != effective uid). Future 
upstream releases are expected to remove the option, and make it 
unconditionally refuse to run setuid.

My intention is to make it refuse to be setuid in testing/unstable 
(probably one more upload with setuid-root discouraged but possible, and 
then the next upload after that will disable it altogether) but I think 
that's probably too much of a regression risk for stable.

    smcv
]