From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f42.google.com (mail-ot1-f42.google.com [209.85.210.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 7ABAD2DAFB0 for ; Sun, 7 Jun 2026 21:38:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780868338; cv=none; b=BGHukume1hDY6E6w3YUcZHplQOukFGZRgwUOmcjrBgsexjODkucab7JIOTFipC7qGDs+xptz5n6dy/HWu1VgciGntHKTk+BImfvUWHBM3zSJ/h2XiYNmYU6YiMec3kneqAPE8HleixT21tTYTy8UFsWpVNlVUXX+p9lnm+76Jvk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780868338; c=relaxed/simple; bh=RSilU2t/ZER4YCl5+tSWK0ZW203lZyAlex34mPOIeMA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=F+zdtHE9wqX8Nm9zMzmuwt/p+WGwI2LdRnJpC/BvNS2bRUDNgcFPWEABI9gSnEEfSu2/AcPzOvcNbTP++5K0a8nVgKdXZBHO7M2euaw2QVwvRz1zw/O7ZoJwnb83vXDB7qwepzWnnMGpQlKybO5iDwQgiUNUhQYTw19gcatAUPI= 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=BoRmB7qH; arc=none smtp.client-ip=209.85.210.42 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="BoRmB7qH" Received: by mail-ot1-f42.google.com with SMTP id 46e09a7af769-7e6ec655c80so1964007a34.0 for ; Sun, 07 Jun 2026 14:38:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20251104.gappssmtp.com; s=20251104; t=1780868335; x=1781473135; 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=ZJ2+eSNrZVDWt0D+Gk83Gowj8MGt1KeKbFMXJpG6Hlk=; b=BoRmB7qHGs694fdS68DcXsWEsglUx7QnP3fi7EUrEUVTlESrbGsC9dFT+4s08nJDxf zrRE02FCDB6CkCoruHo5UU5BX9ZCTqpUU3shceL+MLhVYor2z0LgDCQwQ/xGO/zcuu1a A0ob3G5WDfSHyyjWCtkwMxd2pigfyZBsDMUGKYasAXgOvA0KSLvcdZ2zo9Zz/fdqQ66R YJVmQcLGsAI2jZUDwpRPJhKlVk0nvFagVmt9L4OJVmC+aFBSrET/TbmHKxca7eNa6Yfx VLnX1L6OgeuAthgGBqakj9oK3WwlUQGjlVhVkmeLXryhLykKUsvcjNpHCVLD3vELPKcy Khog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780868335; x=1781473135; 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=ZJ2+eSNrZVDWt0D+Gk83Gowj8MGt1KeKbFMXJpG6Hlk=; b=em2WwpLA3EQ/mwb9z4KlsWetjAhyJGPIdPBldNa/QddarXjws6sB4JSzekXnRzMFNk vfUy+OTGH78xJeNw2J1ktxHOCEXV46YE06cCZJnp4gXUDIfuSHglSgH46m6AxNFcu/sP UtxpR7jzQ1GMmzdrOqDTStIKV+4I/cZUE6vBdPPMPbEHKuWF20GIyf/+uNrSVQkTcb3+ 81TGjlhJX2s+brT2cRFhF7u95c+ufWpOzJ+TKb3/FuIG+va7BUoMoeNPetqWu3oQ+xDF wmeOCd8XnTuY7sFJTYvW7t5Fr8oz5jYuPnxOJqctUN1wHzpGHd/SCILYwKN9m5mInmsk rNcw== X-Forwarded-Encrypted: i=1; AFNElJ9OJaw4RddTFURBPoARlqieB4RZtu4JvX6UdqKvv4jTghCHQ/tnL3K8gvHnAfrkI3LaqsareeisaBvLGrM=@vger.kernel.org X-Gm-Message-State: AOJu0YzJUPsMpbZOPGlIBVQPKlDKOtkAgjZg6bg4CLz7krsvid9+LNVw AmbtArp8M2KzXuRcG/lowSLyPGYv9hCriMDsQ0IR6MfwyNxFsokgkNVbFc2l88Gy9TR1ko9VCGk bckXt X-Gm-Gg: Acq92OFJYxdIU06p/IIjYqm6J2wtfUThTLPCGSRpUGzOJ7Newx+SwlGiftjUe7qaAJD TIYQ6vF2eT8v4+DkBXtXjuIPWyaEhSarRvhYMB2kNogGOYAN8Un9PTMkDMdVwaLgxSlGuyc+Mul YuDsOoHrqNmQB6FuuYkdo9YmPysOHIvWkC4w4FqMt7AXkmOIbf8a7FM1Y9Fvrs6yGlSHvNuDTju H2aT8pegTbMQmNYNXlADCOqKaCJBTuHSq3mQ0s1S7jC1m2chyya6GjiVMDefljM2RHXlzGjxbQs uJ5l8tuV3/GSVWpu1MJolSVZE3+WlEPUiAOyXsoupzHZY7WLpYJoJFe5CKsQ4tju0eZ75jG/imV jgq37JAGG44kU00jjeFO2CfyaSBkK1GUdH5/99FHTgb0600jHKY8xGyUQ86EsekxZtdIKe8jzTD XFLUJDMbyapUu6QxWABu/6LY2/Q5kQF7z33Y88CZ4MH8JR5sLBHKFkGuBQ+nXS45Q6bB/KII4C2 YL6GiSQxu/iBg8rtpcM X-Received: by 2002:a05:6830:6d28:b0:7e3:d7d6:a4b7 with SMTP id 46e09a7af769-7e70c6884e7mr7674159a34.3.1780868335552; Sun, 07 Jun 2026 14:38:55 -0700 (PDT) Received: from [192.168.1.150] ([198.8.77.157]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7e6e746a50bsm10658361a34.2.2026.06.07.14.38.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Jun 2026 14:38:54 -0700 (PDT) Message-ID: <36351bf5-fb6a-4712-ae27-5b907452bdab@kernel.dk> Date: Sun, 7 Jun 2026 15:38:53 -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 To: Federico Brasili Cc: io-uring@vger.kernel.org, linux-kernel@vger.kernel.org References: <71417fb0-4060-4823-8e4f-f216ce0235d4@kernel.dk> Content-Language: en-US From: Jens Axboe In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 6/7/26 2:08 PM, Federico Brasili wrote: > Hi Jens, > > Sure, attaching the minimal reproducer and the output from my Ubuntu > 7.0.0-22-generic test system. Great thanks, I'll take a look. For the record, please don't top post reply. It makes a mess of conversations on the mailing list. > 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. -- Jens Axboe