From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f54.google.com (mail-ot1-f54.google.com [209.85.210.54]) (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 57BDA32BF44 for ; Sun, 7 Jun 2026 21:52:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780869172; cv=none; b=PwFOR8wk58FAHwJPxqxr/47PFVfMttmG84pxvLxJWl3ntN+l8XCJCERsGQz9mihUGWBzyyqAM5g1GHdizAVPStfOvQMYof4e4LUJeXolbx1/9Wwf6Wmo59okWlZOInAw6KEU+zEeesdHjbHOjPetyFdBCZL83JjGwYpiRqQ+XzI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780869172; c=relaxed/simple; bh=VMy1dZmfUA5UZgNMJi9p32GTQf9/JqJFmX1Zue6eSK8=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=RCIdr/A3/IA4Sk5LCGclmaUEYCo0yFLK6GPNlFPYaHdu+TDWieD1nipWO5SJMDsK7hgigW0BC3B2PV7CVMNtIYKInS7cHXeQQP/LieC2NmLhl2V1gWsxVYdK7j7VdQDTaUAxahQ/axprKpEU/tVc1mhEa9I2E0bMxJNvVVGbCbQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk; spf=pass smtp.mailfrom=kernel.dk; dkim=pass (2048-bit key) header.d=kernel-dk.20251104.gappssmtp.com header.i=@kernel-dk.20251104.gappssmtp.com header.b=EOuRu+kl; arc=none smtp.client-ip=209.85.210.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=kernel.dk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel-dk.20251104.gappssmtp.com header.i=@kernel-dk.20251104.gappssmtp.com header.b="EOuRu+kl" Received: by mail-ot1-f54.google.com with SMTP id 46e09a7af769-7e6cdd78fe6so1891711a34.2 for ; Sun, 07 Jun 2026 14:52:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20251104.gappssmtp.com; s=20251104; t=1780869169; x=1781473969; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:from:subject:user-agent:mime-version:date:message-id:from:to :cc:subject:date:message-id:reply-to; bh=cDuiH5+HkfPGF8muV7E4tlFpe77YBCNs+BTGIbVbpds=; b=EOuRu+klLO2jJVxS/M5y7KsSS3LOwX+tF9bHIge4LBv8649kJ/t9EcWmqyRu5OK90C OrL0V2Zea8MrzvpJIjYjjZdF5oNLa51Z75BiUPG5FAxqm1YkgOGWkfAfcUKEWkuENECx T8ZAHpIiLKbXcGPQxXnn/LMr1zTf2iWWAYkKD78Z8JFaG775ko5ifUqdRHhfIEomNzJp 9FYs8pLkNyq+MosCtPr0YY45CpeAvDDT6dg/1lSjuEPNBC6Ix6r2Mt9uopzIdMuElTHo o5XU/NwBqatuy4+D3Lw0l00uuYFBWATJQGiehrnIfa0KfKuloV3Zc199i/f1xHmQpR5W OHdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780869169; x=1781473969; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:from: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=cDuiH5+HkfPGF8muV7E4tlFpe77YBCNs+BTGIbVbpds=; b=oCj8B1BzsrX/eXdPw6H96+m+6miocSUifHJv0u16MFFyaCIG5NdjdXCh5qXkjDuiG/ 2d3epzSGi8BHnYmk68ukLVC/0cha8/dLe1/axyMq56mnHD6n7jCpMlECogaDjF2L6/Kl aOKD7rNlaKmGsGt7au9DCaC/YTlfT1UvRG68yxTWpezB4REYu4JASCHGQXY4AePV1gvO kh1RY/xQOIAeBSKJBDlQnKI8qOD65evQciOoTp/20G4x8502PgGknkdr05duweqF+qMW +2KjtSuYrveHFK1YtUkY2jl7vqG9jqGmemyK5GRxZsosEoqD9X35ua72HOLulSdUYiGD 9mIA== X-Forwarded-Encrypted: i=1; AFNElJ+QMxEZ/88icAgoq8ddnjKy4UcDP2UQ7/0Dm/WOR2lyUUR8EW67qV3cZxxqIWbCmLS00MceIXtuctGZHJg=@vger.kernel.org X-Gm-Message-State: AOJu0YwQUVcNOh27EDYiE5i9uvh2PoDK1GfHRaPZSNELNBi7Hu8Q5AhZ XxNSwT2Jsl/irzgCSDS5Kutpj8s9m7ioNUst4+4l294/lqhC9OZOopLeVWzLmRgdHx5pdZ0C4oL IthgQ X-Gm-Gg: Acq92OF8Sex/+IaDNQF+a3gzDWixKcNVjgeQ4Nhu7XU4vnLJZ9hxEKhKnUNo2T5XWV2 5XAy3SH3tgycNsB7iCrNQevDJl0TlTLZLyyFOIfbygDspe0Tin+Etrh3cXkJakqKLbnd2OAnhNq SiUi6Eb79i8XKhsClWdrtIgp/SSqwyBXug9YQ/bkVAwHbYKTMRuzg/91wX/jy1HtDEw23gPZ8CV BSWiR1D3wEwQp34Gr1DL0Ya9V2PEyCj5YH/0g/QF51IIsD/TNJvzMqyrNv3u3zx35WA5C/a4mDk PWEA8QeSCkl56KHjInOerhuzbG8avcbph2UjJ7ZnJEsAy+6yajt7C6ZcH5aUyQufadfHlhm0Z2X jn6/gMea7Kz7Fl2fFlcVC7VMlF7WPqP1pnuMcQkgmjj/P4I+cRXDgt4MKDYunB0DWmHbqL9sSgw azsW9DcXmbl8cQ2P6sPvzvWVRl6OHWygM5TXpVD2u3AlnAScveyynz+EXYVA0aTlB5+LwHeW8b2 +77BK/76wzlAk6nGoFb X-Received: by 2002:a05:6830:398b:b0:7d7:d100:2613 with SMTP id 46e09a7af769-7e70c603508mr8191077a34.1.1780869169427; Sun, 07 Jun 2026 14:52:49 -0700 (PDT) Received: from [192.168.1.150] ([198.8.77.157]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7e6e7468fa7sm10632133a34.1.2026.06.07.14.52.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Jun 2026 14:52:48 -0700 (PDT) Message-ID: Date: Sun, 7 Jun 2026 15:52:47 -0600 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: [BUG io_uring] Failed RECVSEND_BUNDLE can persistently shrink non-INC pbuf ring len and affect later READ operations From: Jens Axboe To: Federico Brasili Cc: io-uring@vger.kernel.org, linux-kernel@vger.kernel.org References: <71417fb0-4060-4823-8e4f-f216ce0235d4@kernel.dk> <36351bf5-fb6a-4712-ae27-5b907452bdab@kernel.dk> Content-Language: en-US In-Reply-To: <36351bf5-fb6a-4712-ae27-5b907452bdab@kernel.dk> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 6/7/26 3:38 PM, Jens Axboe wrote: >> The reproducer runs unprivileged and demonstrates: >> >> 1. non-INC provided-buffer ring with entry0.len = 4096 and entry1.len = 4096 >> 2. IORING_OP_RECV + IOSQE_BUFFER_SELECT + IORING_RECVSEND_BUNDLE on an >> empty SOCK_DGRAM socket >> 3. CQE returns -EAGAIN, but entry0.len is changed from 4096 to 1 >> 4. a later unrelated IORING_OP_READ from a pipe using the same buffer >> group returns 1 byte instead of 4096 >> 5. a second READ uses entry1 and returns 4096, so head/bid accounting >> appears coherent in this repro >> >> I am not claiming privilege escalation from this. The demonstrated >> issue is persistent provided-buffer descriptor length corruption after >> a failed/no-data RECV_BUNDLE, affecting a later READ operation. > > Right, I believe you already mentioned in the first email. It's just > a bug that can cause the app to (rightfully) get confused about the > state of a buffer. > > And it's not a corruption in the sense that something else writes > to this buffer length field, the kernel is deliberately writing > to that valid piece of memory. It just misses restoring it when > the operation fails. IOW, it's a consistency issue. Words like unprivileged are tossed around here, but the app could've just written this memory without even the kernel to do it, it's application memory. There's absolutely nothing privileged going on here, kernel isn't touching anything that the application couldn't just have done itself, without involving the kernel. The kernel _should_ not do it for this case, that's the bug. And from a quick look, the fix would just be to remove that buf->len assignment in this case. For the normal case of eg wanting to read 32b where the length would've been truncated to 32b in the buffer, it should be fine to leave it at 4096 or whatever size it is. For bundles, userspace must iterate the buffers when it gets a completion for X bytes. But the iteration should always be: unsigned this_len = min(buf->len, left); and hence it should not matter if buf->len remains at the untouched length, for a truncated end buffer. -- Jens Axboe