Re: [PATCH v5 2/5] misc: fastrpc: Remove buffer from list prior to unmap operation
From: Dmitry Baryshkov
Date: Mon May 25 2026 - 04:29:51 EST
On Mon, May 25, 2026 at 07:06:37AM +0200, Greg KH wrote:
> On Mon, May 25, 2026 at 11:30:43AM +0800, Jianping Li wrote:
> >
> > On 5/22/2026 3:03 PM, Greg KH wrote:
> > > On Fri, May 22, 2026 at 02:55:29PM +0800, Jianping Li wrote:
> > > > On 5/15/2026 9:36 PM, Dmitry Baryshkov wrote:
> > > > > On Fri, May 15, 2026 at 08:42:14PM +0800, Jianping Li wrote:
> > > > > > From: Ekansh Gupta<ekansh.gupta@xxxxxxxxxxxxxxxx>
> > > > > >
> > > > > > fastrpc_req_munmap_impl() is called to unmap any buffer. The buffer is
> > > > > > getting removed from the list after it is unmapped from DSP. This can
> > > > > > create potential race conditions if any other thread removes the entry
> > > > > > from list while unmap operation is ongoing. Remove the entry before
> > > > > How can it remove the entry from the list?
> > > > Multiple threads sharing the same file descriptor may invoke unmap concurrently.
> > > multiple threads sharing the same file descriptor is a horrible
> > > userspace bug. If you do that, you get what you deserve :)
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> > I agree that concurrent unmap on the same buffer from multiple threads
> > is a userspace bug.
> >
> > However, the fastrpc driver is exposed via ioctl, and any userspace
> > (including any random apk) can map directly and then call multiple unmap.
>
> So there is no userspace selinux permissions settings on the fasterpc
> device node at all?
>
> > This patch is not intended to support incorrect userspace usage,
> > but to ensure that the driver remains robust against invalid or
> > racy inputs.
>
> Isn't control to this device an "admin only" thing?
No, it's being used by normal user apps. Also, there are systems without
SELinux being enabled / used.
>
> thanks,
>
> greg k-h
--
With best wishes
Dmitry