From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 79C94372EDA for ; Mon, 27 Apr 2026 08:56:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777280162; cv=none; b=JLPuvkJ3hhYG3jxTPkU+95zroHT2N9bkIzGIAA9T/ylvP94ukuZvgS4omNi74ZAX+SX9CKdpaZc8Xad7Wtxut5qexk9yU04sEOORO7zHOZfqbBEDLTELxy5Kj482itIRYdHlM09nLsyzlhzY4CY/n68sWw7egjvjVF5q6GOK2DI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777280162; c=relaxed/simple; bh=nSyNAYP9VF/vH2DSSAUwmYJlU6QfNhzTTn25r5ShNpc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=gTESMfiXMB79Nn08upmd/wuJ+ax9793L6JTsal2YhDvr105levH0vxl+lssD6sD2cOMPbAUwFQrj02P5lMr1LWkDH5bq39BkZJ9xoyvvxJaf2DL5DH/PA+/mply+qiDY8Mk9kBtuUCL1tU7jHWw7JYTlv99zJmO9l1P274AJ4aA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Pqy3ZDz1; arc=none smtp.client-ip=209.85.128.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Pqy3ZDz1" Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-483487335c2so97194385e9.2 for ; Mon, 27 Apr 2026 01:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777280159; x=1777884959; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=gg8xcE5nVzUCLwlpOgMSnuz5hEr/6m+rEcYGBUox7Sc=; b=Pqy3ZDz1tTR/rf+VytVOaA6RPcjXIe33Qh/JhNFS5gRt8z44ExeSONgjfycO92+tHx hnVv3K48lGvo/gnrVk/t1+BmIKatXrVd2MEko20CZxecm/i3MMr3ejHbntqP2024TgYn xvP3lSS+Lmxd7IjADHxmNiAEt/0zEeXKfAxtnqNqzO4HNX5vzgFaJos2jY/DpV/+PeT8 P5SRX/cAf25frpEx0Ofiinc/WZ2O1ifpNvBfr/gN5hI/i9Uc0WGnBSsNyslbXOOOPNiU aKZs9+Hi3hdBRx2r4roWEXUfCzYf5BVpJPdG+2Zyo7K+nqmhRQm146+Hd2a4Y0LCAKR3 ChyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777280159; x=1777884959; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=gg8xcE5nVzUCLwlpOgMSnuz5hEr/6m+rEcYGBUox7Sc=; b=aLQtJFKMf4MACwD91gn5zb6iYMK8cZRVp27rxw3s1TyAbvRbhLhUkz/TNFqDqE+kkI 2dVdE96QrOtcsVFjF+RJQdJPFb2xKBHQrtqWeXlSAfMdbgWRA0aUWKY8MEMqBu4biyZx HPI8l2YBNhuzi9XGVBFHeRBA1nDTOU44VhAoY4W7x8oyeSUPc84ZyhtBU8c2ZfBPRZ01 3wwoKABu5YrztUjGPIIaRmhdXFpl/xibZ/q3yV+cYlxwegbXRsaXMZJr5BQI3KcWN2j7 7nKwnYHhiSkI9KWSY3uGN/HoLkjD1AzlKA3hz9quGq2AtHJDK4xY6iWsBfFn9yr7u2Y/ rU6A== X-Forwarded-Encrypted: i=1; AFNElJ+6Pgm1L17AmNWafNEVLc5zx+YSIl3WWU/n8b8zC4FbqbCkbpiJrCUXgj640dBWPEfG9ptzP2fIs8EsYvU=@vger.kernel.org X-Gm-Message-State: AOJu0Yw+jwukjoYRIpo8jOYz+lLxceYbq71L65zK5y+iO0F4x/yVn49x 4M2QA+5fCpcEcrL3tzzu86oQMksqNt/vMeAmE4Zel8Nm+zfKLJC7RUM8 X-Gm-Gg: AeBDieuUzZ+cRZ0pAZJscHzjq7PeiGNJI1ffRoQUnwfl1M6UQd+JmK6d4FZy2aGyjQL BCqD4iko93OEsTCQnxn4v2mk1aj3bS7zo6DD7eCfC4z9JG2ZLdYrQeHKt7R64MXlodj1BwFlXTC Bl9ajI3tMHVlkWkIKc9hpDpz4BHrQNjAJPLUqb1tQMUecTkOeUlhUCGXP2ERarkk9h34JmH880t LPGXN+ne4ybb1zkLOY5zD0e3ePwGQFwRz7KAyCx08UO/l/M1+adpzLl7CuBeEaaZvAexEN6GOrf sWMXz2W302la7PjAKE+R9s2emz1rkLN7s9fF1EPCMTNl3pqDsIAn85AYDwJLQ48dnfBNjv2dMUg EQEX2yi6VL/AA++ByL9xymZPnJ2yMxKQsKekcW0NGhWwhMZQ9zMzGVaj+A5BCKdURizma3ypZG9 CKE8EELm2fmWzPaP6AVZcLnhDCQiY3KYOMddK9ZRgT3ts4XpXOGXAs/7nHswNSTZATELJmnAxCR Ptl2KbFhROqvcfNFYcr1VwjRSu7ijNv8gN7ZOInjByYDdbeSCIlr5zDryyIVZp+QtQKvck= X-Received: by 2002:a05:600c:19d3:b0:489:1ae1:4eb9 with SMTP id 5b1f17b1804b1-4891ae14f23mr447767705e9.28.1777280158625; Mon, 27 Apr 2026 01:55:58 -0700 (PDT) Received: from [10.30.6.33] (93-47-80-68.ip112.fastwebnet.it. [93.47.80.68]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43fe4e3a7b4sm73703654f8f.22.2026.04.27.01.55.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Apr 2026 01:55:58 -0700 (PDT) Message-ID: <12c2bec8-ffb9-4b01-8bea-819c6ec77c5e@gmail.com> Date: Mon, 27 Apr 2026 09:55:54 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] io_uring: fix missing submitter_task ownership check in bpf_io_reg() To: Ali Raza Cc: axboe@kernel.dk, bpf@vger.kernel.org, io-uring@vger.kernel.org, krisman@suse.de, linux-kernel@vger.kernel.org References: <20260423084024.31721-1-elirazamumtaz@gmail.com> Content-Language: en-US From: Pavel Begunkov In-Reply-To: <20260423084024.31721-1-elirazamumtaz@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/23/26 09:40, Ali Raza wrote: > On 4/22/26 10:20 PM, Gabriel Krisman Bertazi wrote: >> How is this a protection? I thought ctx->submitter_task is about >> IORING_SETUP_SINGLE_ISSUER. there is no permission or capability over >> it against other processes. > > You are correct. submitter_task is a SINGLE_ISSUER mechanism, not a > cross-process security boundary. The "parallel path" framing in the > commit message was inaccurate. > > The code confirms it - submitter_task is only assigned under > IORING_SETUP_SINGLE_ISSUER, either at ring creation [1]: > > if (ctx->flags & IORING_SETUP_SINGLE_ISSUER > && !(ctx->flags & IORING_SETUP_R_DISABLED)) > ctx->submitter_task = get_task_struct(current); > > or deferred to IORING_REGISTER_ENABLE_RINGS [2]: > > if (ctx->flags & IORING_SETUP_SINGLE_ISSUER) { > ctx->submitter_task = get_task_struct(current); > > The check at [3] I cited returns -EEXIST to prevent a second process from > registering on a SINGLE_ISSUER ring - it has the effect of blocking > cross-process access but that is not its purpose. > > The commit message's Requires: line was also incomplete: > IORING_SETUP_R_DISABLED is a prerequisite but was omitted. Without > R_DISABLED, submitter_task is assigned to the ring creator immediately > at [1], so the attacker who creates the ring already satisfies > submitter_task == current - no timing window exists and the attack is > impossible regardless of whether the check is present. > >> I'd argue this is a non-issue. If you have CAP_PERFMON, you are able to >> mess with the process in many ways beyond this. Otherwise, how a >> process would be able to get the fd in the first place? > > On CAP_PERFMON I'd push back slightly: it is narrow (BPF program loading, > perf monitoring) and does not grant ptrace, arbitrary file write, or > process control. The BPF struct_ops path is specifically what > CAP_PERFMON enables here, not a general process manipulation capability. > > But the fd acquisition question is the real barrier, and on that point > you, Jens, and Pavel are all correct. As Pavel noted, any application > that accepts a ring fd from an untrusted source and calls ENABLE_RINGS on > it is already catastrophically broken - the BPF vector is just one of > many things an attacker could do in that scenario. There is no realistic > path to get a privileged process into that state without it already being > compromised by other means. > > The fix itself closes a genuine asymmetry - bpf_io_reg() is the only Not a fix, submitter_task was not made to be a security mechanism in the first place. > registration path without this guard. I can resubmit with an elaborated > commit message, if Pavel thinks it's worth applying. That might be fine to add. I omitted it because it happens off the bpf syscall path and not through the io_uring registration syscall, i.e. it'll break if bpf folks decide to defer registration to a worker thread for some reason. It's of low probability to be a problem, so it might be okay. If you're rebasing, don't forget to use the latest branch and look up how it checks ctx->flags around submitter task. -- Pavel Begunkov