From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) (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 092D4371860 for ; Wed, 22 Apr 2026 21:58:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776895103; cv=none; b=Oxm27wNgv8vPzgNECWVs+VB5aIJZD8by8mZGPQeaAgbe7h9Ywu/dZt8MjOXs+wpvCZCHUtKwU3Otn2FUgVvLAJ7j+Uvnm1M2fkWXClfiDyiv493VPnO0mcGQyDxb03Z8tDzQfHc9C2bBU82Dh+Lpduw4KrM95v19YDl4Vst1/uI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776895103; c=relaxed/simple; bh=GzHVAmsLzPuelQXQHQrVV3DAhz1JSgmFcYw+FXXnjMA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=MHFzUmb+orTVBjo2FsSiV6MF25/lqn3qiCUvvu+7F7xawX9FTCqgop3h9LNdQtH2PrBn7Bn+I3yceiSvkawhJ39TnaSDuW72+MfRveR9lFZS6PYjhLpyhb3X/oEs3ku7wPQzFa1urKpbjwpY8cg45EhZw7+0K0sjgamlescxvBY= 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=gf2kU7R+; arc=none smtp.client-ip=209.85.128.42 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="gf2kU7R+" Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-488af96f6b2so76284185e9.0 for ; Wed, 22 Apr 2026 14:58:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776895100; x=1777499900; 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=kuCrp9vHvm93F/m655sREzL7Gh/S5uVZ2N8F50ItWVg=; b=gf2kU7R+8lACzlYkqVPilvWZl2tDRZVw0hnN5jBkNpPdEFKWwacioM4kKJmTOyJK0X jZwtCI+HdAQOBx9GWEMc497zBYLerTdCmx38x5zG4mXLPGxwdNBbBthE7uobBu4LLaJJ cEFexorEi7XI4VyGGBBWA7n+53ubTSD+dhZR95aAxDULN5NZY9SwvC+CymhUJR5qkS5q 7esGZp0krCHGqa+A2goYFZWxEgEm0jWjv9FZOT7sra3rJGOsbA+H597BRzwnaYRLiDBL uMGtJm6oToEfomuBQhvOGa/RNa24v+jQtH//aeeSuaEi+4WUPc4TSCPQVSTA/zJp8yaV nyPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776895100; x=1777499900; 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=kuCrp9vHvm93F/m655sREzL7Gh/S5uVZ2N8F50ItWVg=; b=q+RLhgAmayGIVkxoA5Gembm6P1CGovzUY3tfdNvp+vOw79DKiUodZdnEcn06ILPHDX g1TDvPZNBbmjGGvdI3aO5J4VCzoUi5R2cNbTufYwgw+WcbqPDNap6zh6Q4Ci3fDGsbML /nt3mHYuNfouNBpOH0I1vkyrQBqn6dlYKxu7QrscuQ7xNP8UyLqHbvdOwGP8dYPMuJGG Dp9LwXbcPmJSJ4nz9z9OczdQiFZZV8xxVZHQ1AUDY8nmTbURTxIFFwEPvtwVPqGZEyGn 0HTV1DUoIMz3ArjS7IxL1QfkZvBsiAztu1JuWzGQjbhc76cys+oR6FqDxpBa3qxdvHzg AoVw== X-Forwarded-Encrypted: i=1; AFNElJ/Nf015jWhw6bbs0KRqKyhlCwUxza8gBxRIhFcUZ3+g0f2FdfTnYjBDcKOg3Md/P/ij9xUKFZyG3zfDDkI=@vger.kernel.org X-Gm-Message-State: AOJu0YzhiykrrYtR8rTmI6xgHWpE9ZOBQQ5Wdh/Sb3B4VONhcXNqoZ2L t11CrYOvcSK7P+UbMpIs4xk1BaR7f/r/RFtZTTANFKmpJrlnICSCh3dY X-Gm-Gg: AeBDieuuc8qbASzqpC94YkcmJdsOV9aDXexoXP+0PljoyBCFetGBpPS/f/WLjwneuZl H8ewWKU63nOpz5+T4BWMJJGsoWd/EyuF53EEcMxbb5+ayJCJavH0HXl5jzha4RhFD0ga6DwHXFk exXoUV9W8LLZSrU34rxlDmBQcJLB6dXb9CRycyZOlmIp2Ejw1yuUmZm8he34FbRD5BJvmoD5Nol oMNSBfbu2U9Hq3Oonle6MMOC8F6aInV9BA7dHlyCRRRhKR4YfvxPBEVaMbsiWzO0FtVhOfBvUqQ XukEyqWeUMSKl3cs/DFathTV7BaUfQlDIt0LPI9jJ29D1xBd/GpK2O/ZqECD4mVAroyC0930dd5 8yQul8Sav8j+TdiFeeHLdlgQWLDrC6WpnktpfPdGq1uERJYq9I0GOtklMA0ZxhlRn4eLBrlF6g/ JhhEoGBVd8891oego2bz4QrscEcDFGAZXLQsE01EPTbM7WI5z2orsQYWXrIGJKBcBP5VnWF2zKC RuBCWtrxfwqPYOJ3MASGI6gzcurEyFuY6OuOC4Aerm/yEYVFc08EnI8SGuYbkeb/84aqv3NlihD +jsn7HUEEwcN X-Received: by 2002:a05:600c:468c:b0:48a:56d5:16f2 with SMTP id 5b1f17b1804b1-48a56d5179amr120772365e9.7.1776895100454; Wed, 22 Apr 2026 14:58:20 -0700 (PDT) Received: from ?IPV6:2a01:4b00:bd21:4f00:7cc6:d3ca:494:116c? ([2a01:4b00:bd21:4f00:7cc6:d3ca:494:116c]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4891cc7b2efsm151827445e9.0.2026.04.22.14.58.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Apr 2026 14:58:19 -0700 (PDT) Message-ID: Date: Wed, 22 Apr 2026 22:58:37 +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: Gabriel Krisman Bertazi , Ali Raza Cc: Jens Axboe , io-uring@vger.kernel.org, linux-kernel@vger.kernel.org, bpf@vger.kernel.org References: <20260422-master-v1-1-e82f47558345@gmail.com> <87eck6ofo8.fsf@mailhost.krisman.be> Content-Language: en-US From: Pavel Begunkov In-Reply-To: <87eck6ofo8.fsf@mailhost.krisman.be> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/22/26 22:20, Gabriel Krisman Bertazi wrote: > Ali Raza writes: > >> bpf_io_reg() installs a BPF struct_ops loop_step on any io_uring ring >> the caller holds a file descriptor for. io_uring_ctx_get_file() only >> validates that the fd resolves to an io_uring file; it does not verify >> the caller has authority over the ring's submitter_task. >> >> A parallel path in io_uring_register() already enforces this: >> >> if (ctx->submitter_task && ctx->submitter_task != current) >> return -EEXIST; /* register.c:733 */ > > 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. > >> Without the equivalent check in bpf_io_reg(), a local user with >> CAP_PERFMON can exploit IORING_SETUP_R_DISABLED -- which defers > > I'd argue this is a non-issue. Right, it involves receiving a ring from an untrusted source and then using it. Any application doing that is extremely broken, even without any bpf you can use that to do some pretty nasty things 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? -- Pavel Begunkov