From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (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 C720F44BCAC for ; Tue, 14 Jul 2026 14:33:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784039605; cv=none; b=opfh0NkNDlZoWsX6UNfouCiftF65/iqHPyjscStdR6Xi+T2Ri3ahtsb9KMca+B4+F2CW8QKzflRijgoWUjL1y5hqbhsnu5Dh1K+wPcO5LIu6Aa4AR43Cve2Y4R9aQs3XmuXJKB0ZSXNJhiIGhMlRnBqL2B+VTBlPfrdpHmmmGjk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784039605; c=relaxed/simple; bh=t3+FgGxIANUdTs4dodfcPA0vqCjpmZzzbODy8MT0F5Y=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=QrSyeUqueIPjbITDMuXPYWeAyJkYRkpaLyuySIKsCz37qAt6/AM8LH2LXIxIZ7Q8T9hp+KjsWi8IrTDa6LeO5ZMuz5prJPqDQGgocXk4d1vMOFtP0tAwKjMDCVlfUYAxPaVe1qcJgPEImtrj+EJ5Sjj57tRj9xSd6df22qpLWKw= 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=b7paIVOD; arc=none smtp.client-ip=209.85.128.52 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="b7paIVOD" Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-493f2e39e81so18035355e9.2 for ; Tue, 14 Jul 2026 07:33:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784039602; x=1784644402; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=yqr76+rJ8iwHayK7NjLGqhPMmOMQyjm2NesJQTgS2Xo=; b=b7paIVODVxIpb40kzN5mRJBFqqVsZcioNrHpT1aNmYqxF8tVuz2kyfOREywwF1RHFQ 7tEi//lXOT01O3qB0l/BU6dC55LcgsIScWk3TXPB8FxDnCVGCZxlu+Gbl0wBvweX/LIj zChGMtezvGI1H+DeGyD+toHJ1qteKG0Wq4EAiMZ8aXlTITdgcC5hpg7/a2ZwA4KiGRDu Cts/RJ1FcUJo0FybUBGRuiT/DGIbIVL/rgRiD7dnDig+Dc216f9HNuaUcWjxiwsbHXel UZcsedff2r/R2Sci3a2Be8y2Bul9M57oqQclxArFE54HcbUddHPFJ6KPkoVBlWAQm6JM 6emg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784039602; x=1784644402; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=yqr76+rJ8iwHayK7NjLGqhPMmOMQyjm2NesJQTgS2Xo=; b=bfsYIo6I1LcN4Nl1WdsysdakWpiX/c6XrV1ELFEgGzcSITp+GDUe5Jk/DYHc2mEydb w4egEfoEboQWnSyLP3B+ct1yuf1T8SDqb0xqA3RwRmYYnXTu2lTR9tKi1m8QnQBzcH4K AbwOoQ/yJasUfwBJ18usQj+b/m1R6v5qfxUuv3cYzETn1g5WHgC2FYkOqic1D6XG/o3b LyaiUcgLMVW3LXIi6WhN1GOFzLxAo3MluFLOCTiDy+ijIcd//ZejLuY3A6ZevT+tON05 YHQx+Ruyz34RDKMta6RXRaVXjq1hfxrfzU5COZlg5RBzhEqyT1vUlZrz/hEDv/qEJcz/ vMIw== X-Forwarded-Encrypted: i=1; AHgh+RroatvzwNlSg2+S/CGmx6qrzFaIZHTODVmrA4YIIVlQzDQxI+evl44e/rsBpO2UyvqcidO59d4KX9oFQ+s=@vger.kernel.org X-Gm-Message-State: AOJu0Yy+Vug8Ls70/4ZBgCYaUYJohcSj23pr3otjYEkp3PbhFwpOAwIu XS42t7/wB+faOvWtfLmMjuehTT1AnMoq7zfm8cwoQc71/umrzU2BJn8o X-Gm-Gg: AfdE7cmcWcT5+dBdvMCmf+HQ5K6TH6CXKazjCSX8e9rJ6yPAtuftU7dqugdDbrl3QBW N8TlPUUyFteE6Mi5DwK/gbTf7xh9QwF91FR85w7JnBWF76/afTn2u6dxGIMFefjjY916daPvqCg jpDlhMiBYwmH8ZsgNWqQoyhRDGkJEnPmK1p7tAT8FVdctwe0XDOMc5lHVkA4cuNvVZgm8Nr9t13 zwqSuz2de+LRiBGyZl0cFtIoqIMCKTouv3Akrz65Nz6HlJVu3CFgS7mrv8gt0F4EKtxkUa8LJae DFtazYf2x8FC8Ag6YLixByjG1PcxKqn4pKQDuDhKRZ6Nz+Xq1dQw/ioXGQACMcjplpHMm3tgMew 8DYTIOAyFcZZyIt0vOTa42bD4e4g8HJuMwyC3q4Ofp37BbOSFeFP6cgAXU+Nns1iDy4DxWlg+Oe WmgiDbRlnUrWmSIfRmo57agt+iRxMofzTwLT3T6IJquuLG7P4m1Q== X-Received: by 2002:a05:600c:3e1b:b0:493:e890:9e0b with SMTP id 5b1f17b1804b1-493f883157bmr144382565e9.26.1784039601550; Tue, 14 Jul 2026 07:33:21 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-493f2e0f165sm270374515e9.0.2026.07.14.07.33.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jul 2026 07:33:20 -0700 (PDT) Date: Tue, 14 Jul 2026 15:33:19 +0100 From: David Laight To: =?UTF-8?B?5a+/5p+P6IO9?= Cc: Sumit Semwal , Christian =?UTF-8?B?S8O2bmln?= , "T . J . Mercier" , Benjamin Gaignard , Brian Starkey , John Stultz , Sandeep Patil , "Andrew F . Davis" , Srinivas Kandagatla , stable@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org Subject: Re: [PATCH v3 1/2] dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds Message-ID: <20260714153319.07b2b1e1@pumpkin> In-Reply-To: References: <20260714114654.3885457-1-shoubaineng@gmail.com> <20260714114654.3885457-2-shoubaineng@gmail.com> <20260714141359.7758575d@pumpkin> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, 14 Jul 2026 21:38:07 +0800 =E5=AF=BF=E6=9F=8F=E8=83=BD wrote: > Hi David, >=20 > Thanks for the feedback. >=20 > The concern is not just about the EFAULT return =E2=80=94 it's about the = race > window between fd_install() and copy_to_user(). Once fd_install() > returns, the fd is immediately observable by other threads in the same > process (via /proc/self/fd, SCM_RIGHTS, etc.), even before > copy_to_user() has a chance to fail. The triggering condition is a > deliberate mprotect() flip, not a corrupted heap. That is what makes doing the close wrong. But that is a program aggressively trying to hit the timing window, not a normal program that has managed to pass an invalid pointer. The most likely reason for a real program passing an invalid pointer is a corrupted heap (assuming the stupid coding errors are fixed). It is really no different from the sockopt code that receives SCM_RIGHTS messages. In that case once you've removed the FILE from the socket (or similar) you really don't want to have to put it back because the write to the sockopt buffer or length field fails. The chance of correctly reverting the kernel state is small - and won't be tested. David >=20 > The fix itself is small and follows the standard kernel idiom: > get_unused_fd_flags() reserves the fd without publishing it, so the > window between reservation and install is entirely under kernel control. >=20 > Baineng >=20 > David Laight =E4=BA=8E2026=E5=B9=B47=E6=9C= =8814=E6=97=A5=E5=91=A8=E4=BA=8C 21:14=E5=86=99=E9=81=93=EF=BC=9A >=20 > > On Tue, 14 Jul 2026 19:46:53 +0800 > > Baineng Shou wrote: > > =20 > > > DMA_HEAP_IOCTL_ALLOC allocates a dma-buf and installs an fd into the > > > caller's fd table via dma_buf_fd() -> fd_install() before > > > dma_heap_ioctl() copies the result back to userspace. If the trailing > > > copy_to_user() fails, userspace never learns the fd number, but the > > > fd (and the underlying dma-buf reference) are already visible to > > > other threads in the same process and are leaked for the lifetime of > > > the process. > > > > > > The obvious "close it on the failure path" fix is unsafe: once > > > fd_install() has run, another thread can already dup() the fd, send > > > it via SCM_RIGHTS, or close() it and let its number be reused, so a > > > subsequent close_fd() from the ioctl path can operate on an unrelated > > > file. This was pointed out by Christian K=C3=B6nig on v1 [1]. =20 > > ... > > > > My 2c: > > > > The other option is just to leave it as a 'problem for user space'. > > No reasonable program is going to handle the EFAULT return by doing > > anything other than exiting. > > Even getting an EFAULT is really an indication that the application > > is already in a real mess - most likely with a badly corrupted heap. > > > > Anything else leaves error recovery code in the kernel that is pretty > > much never executed and open to a variety of bugs. > > While the recovery here is probably ok, there are some sockopt calls > > where it is all more complicated. > > > > David > > =20