Re: [PATCH] staging: android: ashmem: Fix possible deadlock in ashmem_ioctl

[Greg KH]

On Mon, Mar 19, 2018 at 03:16:51PM -0700, Joel Fernandes (Google) wrote:
> On Tue, Feb 27, 2018 at 10:59 PM, Yisheng Xie  wrote:
> > ashmem_mutex may create a chain of dependencies like:
> >
> > CPU0CPU1
> >  mmap syscall   ioctl syscall
> >  -> mmap_sem (acquired) -> ashmem_ioctl
> >  -> ashmem_mmap-> ashmem_mutex (acquired)
> > -> ashmem_mutex (try to acquire)   -> copy_from_user
> >   -> mmap_sem (try to acquire)
> >
> > There is a lock odering problem between mmap_sem and ashmem_mutex causing
> > a lockdep splat[1] during a syzcaller test. This patch fixes the problem
> > by move copy_from_user out of ashmem_mutex.
> >
> > [1] https://www.spinics.net/lists/kernel/msg2733200.html
> >
> > Fixes: ce8a3a9e76d0 (staging: android: ashmem: Fix a race condition in pin 
> > ioctls)
> > Reported-by: syzbot+d7a918a7a8e1c952b...@syzkaller.appspotmail.com
> > Signed-off-by: Yisheng Xie 
> 
> Greg,
> Could you take this patch for the stable trees? I do see it in staging
> already. I couldn't find it in stable so wanted to bring it to your
> attention. If you already aware of it, please ignore my note.

Ah, I didn't realize this needed to be added to the stable trees, I'll
queue it up after this current round of releases happen in a few days.

thanks,

greg k-h

Re: [PATCH] staging: android: ashmem: Fix possible deadlock in ashmem_ioctl

[Greg KH]

On Mon, Mar 19, 2018 at 03:16:51PM -0700, Joel Fernandes (Google) wrote:
> On Tue, Feb 27, 2018 at 10:59 PM, Yisheng Xie  wrote:
> > ashmem_mutex may create a chain of dependencies like:
> >
> > CPU0CPU1
> >  mmap syscall   ioctl syscall
> >  -> mmap_sem (acquired) -> ashmem_ioctl
> >  -> ashmem_mmap-> ashmem_mutex (acquired)
> > -> ashmem_mutex (try to acquire)   -> copy_from_user
> >   -> mmap_sem (try to acquire)
> >
> > There is a lock odering problem between mmap_sem and ashmem_mutex causing
> > a lockdep splat[1] during a syzcaller test. This patch fixes the problem
> > by move copy_from_user out of ashmem_mutex.
> >
> > [1] https://www.spinics.net/lists/kernel/msg2733200.html
> >
> > Fixes: ce8a3a9e76d0 (staging: android: ashmem: Fix a race condition in pin 
> > ioctls)
> > Reported-by: syzbot+d7a918a7a8e1c952b...@syzkaller.appspotmail.com
> > Signed-off-by: Yisheng Xie 
> 
> Greg,
> Could you take this patch for the stable trees? I do see it in staging
> already. I couldn't find it in stable so wanted to bring it to your
> attention. If you already aware of it, please ignore my note.

Ah, I didn't realize this needed to be added to the stable trees, I'll
queue it up after this current round of releases happen in a few days.

thanks,

greg k-h

Re: [PATCH] staging: android: ashmem: Fix possible deadlock in ashmem_ioctl

[Joel Fernandes (Google)]

On Tue, Feb 27, 2018 at 10:59 PM, Yisheng Xie  wrote:
> ashmem_mutex may create a chain of dependencies like:
>
> CPU0CPU1
>  mmap syscall   ioctl syscall
>  -> mmap_sem (acquired) -> ashmem_ioctl
>  -> ashmem_mmap-> ashmem_mutex (acquired)
> -> ashmem_mutex (try to acquire)   -> copy_from_user
>   -> mmap_sem (try to acquire)
>
> There is a lock odering problem between mmap_sem and ashmem_mutex causing
> a lockdep splat[1] during a syzcaller test. This patch fixes the problem
> by move copy_from_user out of ashmem_mutex.
>
> [1] https://www.spinics.net/lists/kernel/msg2733200.html
>
> Fixes: ce8a3a9e76d0 (staging: android: ashmem: Fix a race condition in pin 
> ioctls)
> Reported-by: syzbot+d7a918a7a8e1c952b...@syzkaller.appspotmail.com
> Signed-off-by: Yisheng Xie 

Greg,
Could you take this patch for the stable trees? I do see it in staging
already. I couldn't find it in stable so wanted to bring it to your
attention. If you already aware of it, please ignore my note.

Thanks,
- Joel

Re: [PATCH] staging: android: ashmem: Fix possible deadlock in ashmem_ioctl

[Joel Fernandes (Google)]

On Tue, Feb 27, 2018 at 10:59 PM, Yisheng Xie  wrote:
> ashmem_mutex may create a chain of dependencies like:
>
> CPU0CPU1
>  mmap syscall   ioctl syscall
>  -> mmap_sem (acquired) -> ashmem_ioctl
>  -> ashmem_mmap-> ashmem_mutex (acquired)
> -> ashmem_mutex (try to acquire)   -> copy_from_user
>   -> mmap_sem (try to acquire)
>
> There is a lock odering problem between mmap_sem and ashmem_mutex causing
> a lockdep splat[1] during a syzcaller test. This patch fixes the problem
> by move copy_from_user out of ashmem_mutex.
>
> [1] https://www.spinics.net/lists/kernel/msg2733200.html
>
> Fixes: ce8a3a9e76d0 (staging: android: ashmem: Fix a race condition in pin 
> ioctls)
> Reported-by: syzbot+d7a918a7a8e1c952b...@syzkaller.appspotmail.com
> Signed-off-by: Yisheng Xie 

Greg,
Could you take this patch for the stable trees? I do see it in staging
already. I couldn't find it in stable so wanted to bring it to your
attention. If you already aware of it, please ignore my note.

Thanks,
- Joel

[PATCH] staging: android: ashmem: Fix possible deadlock in ashmem_ioctl

[Yisheng Xie]

ashmem_mutex may create a chain of dependencies like:

CPU0CPU1
 mmap syscall   ioctl syscall
 -> mmap_sem (acquired) -> ashmem_ioctl
 -> ashmem_mmap-> ashmem_mutex (acquired)
-> ashmem_mutex (try to acquire)   -> copy_from_user
  -> mmap_sem (try to acquire)

There is a lock odering problem between mmap_sem and ashmem_mutex causing
a lockdep splat[1] during a syzcaller test. This patch fixes the problem
by move copy_from_user out of ashmem_mutex.

[1] https://www.spinics.net/lists/kernel/msg2733200.html

Fixes: ce8a3a9e76d0 (staging: android: ashmem: Fix a race condition in pin 
ioctls)
Reported-by: syzbot+d7a918a7a8e1c952b...@syzkaller.appspotmail.com
Signed-off-by: Yisheng Xie 
---
 drivers/staging/android/ashmem.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c
index 6dbba5a..8c55706 100644
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -702,16 +702,14 @@ static int ashmem_pin_unpin(struct ashmem_area *asma, 
unsigned long cmd,
size_t pgstart, pgend;
int ret = -EINVAL;
 
+   if (unlikely(copy_from_user(, p, sizeof(pin
+   return -EFAULT;
+
mutex_lock(_mutex);
 
if (unlikely(!asma->file))
goto out_unlock;
 
-   if (unlikely(copy_from_user(, p, sizeof(pin {
-   ret = -EFAULT;
-   goto out_unlock;
-   }
-
/* per custom, you can pass zero for len to mean "everything onward" */
if (!pin.len)
pin.len = PAGE_ALIGN(asma->size) - pin.offset;
-- 
1.7.12.4

[PATCH] staging: android: ashmem: Fix possible deadlock in ashmem_ioctl

[Yisheng Xie]

ashmem_mutex may create a chain of dependencies like:

CPU0CPU1
 mmap syscall   ioctl syscall
 -> mmap_sem (acquired) -> ashmem_ioctl
 -> ashmem_mmap-> ashmem_mutex (acquired)
-> ashmem_mutex (try to acquire)   -> copy_from_user
  -> mmap_sem (try to acquire)

There is a lock odering problem between mmap_sem and ashmem_mutex causing
a lockdep splat[1] during a syzcaller test. This patch fixes the problem
by move copy_from_user out of ashmem_mutex.

[1] https://www.spinics.net/lists/kernel/msg2733200.html

Fixes: ce8a3a9e76d0 (staging: android: ashmem: Fix a race condition in pin 
ioctls)
Reported-by: syzbot+d7a918a7a8e1c952b...@syzkaller.appspotmail.com
Signed-off-by: Yisheng Xie 
---
 drivers/staging/android/ashmem.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c
index 6dbba5a..8c55706 100644
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -702,16 +702,14 @@ static int ashmem_pin_unpin(struct ashmem_area *asma, 
unsigned long cmd,
size_t pgstart, pgend;
int ret = -EINVAL;
 
+   if (unlikely(copy_from_user(, p, sizeof(pin
+   return -EFAULT;
+
mutex_lock(_mutex);
 
if (unlikely(!asma->file))
goto out_unlock;
 
-   if (unlikely(copy_from_user(, p, sizeof(pin {
-   ret = -EFAULT;
-   goto out_unlock;
-   }
-
/* per custom, you can pass zero for len to mean "everything onward" */
if (!pin.len)
pin.len = PAGE_ALIGN(asma->size) - pin.offset;
-- 
1.7.12.4