On Tue, Apr 2, 2024 at 1:08 AM Christian König <christian.koenig@xxxxxxx> wrote: > > Am 02.04.24 um 08:49 schrieb zhiguojiang: > >> As far as I can see that's not because of the DMA-buf code, but > >> because you are somehow using this interface incorrectly. > >> > >> When dma_buf_poll() is called it is mandatory for the caller to hold > >> a reference to the file descriptor on which the poll operation is > >> executed. > >> > >> So adding code like "if (!file_count(file))" in the beginning of > >> dma_buf_poll() is certainly broken. > >> > >> My best guess is that you have some unbalanced > >> dma_buf_get()/dma_buf_put() somewhere instead. > >> > >> > > Hi Christian, > > > > The kernel dma_buf_poll() code shound not cause system crashes due to > > the user mode usage logical issues ? > > What user mode logical issues are you talking about? Closing a file > while polling on it is perfectly valid. > > dma_buf_poll() is called by the filesystem layer and it's the filesystem > layer which should make sure that a file can't be closed while polling > for an event. > > If that doesn't work then you have stumbled over a massive bug in the fs > layer. And I have some doubts that this is actually the case. > > What is more likely is that some driver messes up the reference count > and because of this you see an UAF. > > Anyway as far as I can see the DMA-buf code is correct regarding this. > > Regards, > Christian. I tried to reproduce this problem but I couldn't. What I see is a ref get taken when poll is first called. So subsequently closing the fd in userspace while it's being polled doesn't take the refcount all the way to 0. That happens when dma_buf_poll_cb fires, either due to an event or when the fd is closed upon timeout. I don't really see how this could be triggered from userspace so I am also suspicious of dma_buf_get/put.
