Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1504078 > unrolled thread
| Started by | Leon Yu <chianglungyu@gmail.com> |
|---|---|
| First post | 2016-10-19 18:30 +0200 |
| Last post | 2016-10-21 14:50 +0200 |
| Articles | 8 — 3 participants |
Back to article view | Back to linux.kernel
[PATCH] proc: fix NULL dereference when reading /proc/<pid>/auxv Leon Yu <chianglungyu@gmail.com> - 2016-10-19 18:30 +0200
Re: [PATCH] proc: fix NULL dereference when reading /proc/<pid>/auxv Michal Hocko <mhocko@kernel.org> - 2016-10-19 19:20 +0200
Re: [PATCH] proc: fix NULL dereference when reading /proc/<pid>/auxv Leon Yu <chianglungyu@gmail.com> - 2016-10-20 14:40 +0200
Re: [PATCH] proc: fix NULL dereference when reading /proc/<pid>/auxv Michal Hocko <mhocko@kernel.org> - 2016-10-20 14:50 +0200
[PATCH v2] proc: fix NULL dereference when reading /proc/<pid>/auxv Leon Yu <chianglungyu@gmail.com> - 2016-10-20 14:30 +0200
Re: [PATCH v2] proc: fix NULL dereference when reading /proc/<pid>/auxv Oleg Nesterov <oleg@redhat.com> - 2016-10-20 19:10 +0200
Re: [PATCH v2] proc: fix NULL dereference when reading /proc/<pid>/auxv Michal Hocko <mhocko@kernel.org> - 2016-10-20 21:30 +0200
Re: [PATCH v2] proc: fix NULL dereference when reading /proc/<pid>/auxv Leon Yu <chianglungyu@gmail.com> - 2016-10-21 14:50 +0200
| From | Leon Yu <chianglungyu@gmail.com> |
|---|---|
| Date | 2016-10-19 18:30 +0200 |
| Subject | [PATCH] proc: fix NULL dereference when reading /proc/<pid>/auxv |
| Message-ID | <su02u-2rf-51@gated-at.bofh.it> |
Reading auxv of any kernel thread results in NULL pointer dereferencing in
auxv_read() where mm can be NULL or even error code. Fix that by testing mm
with IS_ERR_OR_NULL() helper. This is also the original behavior changed by
recent commit c5317167854e ("proc: switch auxv to use of __mem_open()").
/ # cat /proc/2/auxv
[ 8.964445] Unable to handle kernel NULL pointer dereference at virtual address 000000a8
[ 8.972555] pgd = e99e0000
[ 8.975282] [000000a8] *pgd=399e6835, *pte=00000000, *ppte=00000000
[ 8.981572] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
[ 8.986967] Modules linked in:
[ 8.990029] CPU: 3 PID: 113 Comm: cat Not tainted 4.9.0-rc1-ARCH+ #1
[ 8.996379] Hardware name: BCM2709
[ 8.999778] task: ea3b0b00 task.stack: e99b2000
[ 9.004314] PC is at auxv_read+0x24/0x4c
[ 9.008241] LR is at do_readv_writev+0x2fc/0x37c
[ 9.012860] pc : [<b0135f80>] lr : [<b00e5900>] psr: 80070013
[ 9.012860] sp : e99b3d08 ip : 00000000 fp : 00000000
[ 9.024337] r10: 00000000 r9 : b0135f5c r8 : e99b3d24
[ 9.029561] r7 : 00001000 r6 : 00000000 r5 : 00000000 r4 : 00000000
[ 9.036087] r3 : 00000008 r2 : e99b3de0 r1 : 00001000 r0 : e98ea000
[ 9.042615] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 9.049750] Control: 10c5387d Table: 399e006a DAC: 00000055
[ 9.055495] Process cat (pid: 113, stack limit = 0xe99b2210)
[ 9.061152] Stack: (0xe99b3d08 to 0xe99b4000)
[ 9.065513] 3d00: 00000000 00000000 ea0d46c0 b00e5900 e99b3d20 e99b3d24
[ 9.073696] 3d20: e9960b80 00000002 00000000 00010000 e9960b80 00000010 00000000 024200ca
[ 9.081878] 3d40: ea8855f0 00000000 e9cac8f0 00000000 ffffffff e9960c00 0000000f 00001000
[ 9.090060] 3d60: b0407b68 024200c0 b05494c0 00010000 e9960c00 b020863c 01000000 e99b3ddc
[ 9.098243] 3d80: e99b3dd8 e99651c0 e9960c00 00000000 00010000 b020aca0 e9c041e8 00000010
[ 9.106424] 3da0: e99b3e00 ffffe000 00000000 e99b3ec0 e99b3e00 b00e59c0 e99b3de0 00000000
[ 9.114606] 3dc0: e9960c00 b010eed4 00000000 00020000 ea0d46c0 af000000 e99651c0 00000000
[ 9.122788] 3de0: 00000000 00000000 e99b2000 00000008 00000000 01000000 e9960c00 00000000
[ 9.130970] 3e00: e98ea000 00001000 e9970000 00001000 e9975000 00001000 e9971000 00001000
[ 9.139152] 3e20: e99e5000 00001000 e98e8000 00001000 e9976000 00001000 e9977000 00001000
[ 9.147334] 3e40: e9978000 00001000 e9979000 00001000 e997a000 00001000 e997b000 00001000
[ 9.155516] 3e60: e9a03000 00001000 e99d6000 00001000 e99d7000 00001000 e9a14000 00001000
[ 9.163698] 3e80: 01000000 e9960c00 e99b3ef0 01000000 00000000 ea0d46c0 00000000 00000000
[ 9.171880] 3ea0: 00000000 b010eb4c 00000000 e98f2700 00000817 00000000 b010e268 00000000
[ 9.180061] 3ec0: 00000000 00000000 00000000 e9964480 01000000 e99b3f50 e99b3f48 ea0d46c0
[ 9.188244] 3ee0: 00000000 e99b3f50 01000000 b010ed6c 01000000 01000000 00000000 e9964480
[ 9.196425] 3f00: 00000000 00000000 e99b3f50 00000000 00000000 00000000 00000400 ea0d46c0
[ 9.204607] 3f20: ea0d46c0 7fffffff 00000000 e9964480 e9964480 b00e5e38 01000000 00000000
[ 9.212788] 3f40: 00000000 ea0f21b8 00000000 00000000 00000000 00000000 ea0d46c8 00000000
[ 9.220970] 3f60: 00000000 01000000 000000ef b000f4a4 e99b2000 00000000 00000000 b00e67d4
[ 9.229152] 3f80: 7fffffff 00000000 e99b2000 00000000 01000000 00000000 01000000 000000ef
[ 9.237334] 3fa0: b000f4a4 b000f300 01000000 00000000 00000001 00000003 00000000 01000000
[ 9.245515] 3fc0: 01000000 00000000 01000000 000000ef 00000001 00000000 00000001 00000000
[ 9.253698] 3fe0: a6ee73c0 aeeaecf4 00014bbc a6ee73cc 60070010 00000001 55555555 55555555
[ 9.261895] [<b0135f80>] (auxv_read) from [<b00e5900>] (do_readv_writev+0x2fc/0x37c)
[ 9.269651] [<b00e5900>] (do_readv_writev) from [<b00e59c0>] (vfs_readv+0x40/0x58)
[ 9.277234] [<b00e59c0>] (vfs_readv) from [<b010eed4>] (default_file_splice_read+0x140/0x240)
[ 9.285769] [<b010eed4>] (default_file_splice_read) from [<b010eb4c>] (splice_direct_to_actor+0xa0/0x230)
[ 9.295345] [<b010eb4c>] (splice_direct_to_actor) from [<b010ed6c>] (do_splice_direct+0x90/0xb8)
[ 9.304140] [<b010ed6c>] (do_splice_direct) from [<b00e5e38>] (do_sendfile+0x1a0/0x308)
[ 9.312155] [<b00e5e38>] (do_sendfile) from [<b00e67d4>] (SyS_sendfile64+0xd4/0xe8)
[ 9.319823] [<b00e67d4>] (SyS_sendfile64) from [<b000f300>] (ret_fast_syscall+0x0/0x34)
[ 9.327829] Code: e1a01002 e1a02003 e1a03004 e2833008 (e593e0a0)
[ 9.333973] ---[ end trace d3f50081f24b99ce ]---
Fixes: c5317167854e ("proc: switch auxv to use of __mem_open()")
Signed-off-by: Leon Yu <chianglungyu@gmail.com>
---
fs/proc/base.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index c2964d890c9a..598d08936a3c 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -1007,6 +1007,9 @@ static ssize_t auxv_read(struct file *file, char __user *buf,
{
struct mm_struct *mm = file->private_data;
unsigned int nwords = 0;
+
+ if (IS_ERR_OR_NULL(mm))
+ return PTR_ERR(mm);
do {
nwords += 2;
} while (mm->saved_auxv[nwords - 2] != 0); /* AT_NULL */
--
2.10.0
[toc] | [next] | [standalone]
| From | Michal Hocko <mhocko@kernel.org> |
|---|---|
| Date | 2016-10-19 19:20 +0200 |
| Message-ID | <su2GZ-4ip-15@gated-at.bofh.it> |
| In reply to | #1504078 |
So here is my RFC as an alternative. Thoughts? Please note that we
currently have only very few users of use_mm() API in the kernel
so a risk of a regression is not really high. usb/gadget are using it
only temporarily. The remaining is vhost which operates on a remote mm
and I have no idea whether somebody might abuse /proc/vhost/mem or
anything - let's add Michael to the CC list. I am pretty sure nobody
abuse oom_reaper proc directory as this one is pretty new and such a
usage would be pretty much undefined as the reaper unmaps the address
space.
---
From 6a1a9fca2871ada365b465382a3f89a1506c312d Mon Sep 17 00:00:00 2001
From: Michal Hocko <mhocko@suse.com>
Date: Wed, 19 Oct 2016 19:02:25 +0200
Subject: [PATCH] proc: do not allow to open file requiring mm for kernel
threads
Leon Yu has reported the following NULL ptr oops
$ cat /proc/2/auxv
[ 8.964445] Unable to handle kernel NULL pointer dereference at virtual address 000000a8
[ 8.972555] pgd = e99e0000
[ 8.975282] [000000a8] *pgd=399e6835, *pte=00000000, *ppte=00000000
[ 8.981572] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
[ 8.986967] Modules linked in:
[ 8.990029] CPU: 3 PID: 113 Comm: cat Not tainted 4.9.0-rc1-ARCH+ #1
[ 8.996379] Hardware name: BCM2709
[ 8.999778] task: ea3b0b00 task.stack: e99b2000
[ 9.004314] PC is at auxv_read+0x24/0x4c
[ 9.008241] LR is at do_readv_writev+0x2fc/0x37c
[...]
[ 9.261895] [<b0135f80>] (auxv_read) from [<b00e5900>] (do_readv_writev+0x2fc/0x37c)
[ 9.269651] [<b00e5900>] (do_readv_writev) from [<b00e59c0>] (vfs_readv+0x40/0x58)
[ 9.277234] [<b00e59c0>] (vfs_readv) from [<b010eed4>] (default_file_splice_read+0x140/0x240)
[ 9.285769] [<b010eed4>] (default_file_splice_read) from [<b010eb4c>] (splice_direct_to_actor+0xa0/0x230)
[ 9.295345] [<b010eb4c>] (splice_direct_to_actor) from [<b010ed6c>] (do_splice_direct+0x90/0xb8)
[ 9.304140] [<b010ed6c>] (do_splice_direct) from [<b00e5e38>] (do_sendfile+0x1a0/0x308)
[ 9.319823] [<b00e67d4>] (SyS_sendfile64) from [<b000f300>] (ret_fast_syscall+0x0/0x34)
[ 9.327829] Code: e1a01002 e1a02003 e1a03004 e2833008 (e593e0a0)
[ 9.333973] ---[ end trace d3f50081f24b99ce ]---
This has been introduced by c5317167854e ("proc: switch auxv to use
of __mem_open()") but it shows a deeper problem we have had for a
longer time. __mem_open resp. proc_mem_open allows to open a file which
requires the address space even when there is none. This means that all
kernel code paths which use __mem_open have to check for mm!=NULL. This
is error prone as the above shows and also doesn't make much sense in
general. A task doesn't have an mm even when it is already exiting or
when it is a kernel thread. The later will not have an mm unless it
hijacks it from another task when the output might be really misleading
without a deeper knowledge of the particular kernel thread.
Chane proc_mem_open to disallow opening a file if the mm is NULL and
return ESRCH. This is an user visible change theoretically but every
user other than /proc/self/$file has to cope with ESRCH already and
relying on kthread giving any output is just an abuse of the interface.
This will make users f proc_mem_open less error prone as well.
Fixes: c5317167854e ("proc: switch auxv to use of __mem_open()")
Reported-by: Leon Yu <chianglungyu@gmail.com>
Signed-off-by: Michal Hocko <mhocko@suse.com>
---
fs/proc/base.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 5ef2ae81f623..d34d33dbf1b2 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -804,10 +804,10 @@ static const struct file_operations proc_single_file_operations = {
struct mm_struct *proc_mem_open(struct inode *inode, unsigned int mode)
{
struct task_struct *task = get_proc_task(inode);
- struct mm_struct *mm = ERR_PTR(-ESRCH);
+ struct mm_struct *ret = ERR_PTR(-ESRCH);
if (task) {
- mm = mm_access(task, mode | PTRACE_MODE_FSCREDS);
+ struct mm_struct *mm = mm_access(task, mode | PTRACE_MODE_FSCREDS);
put_task_struct(task);
if (!IS_ERR_OR_NULL(mm)) {
@@ -815,10 +815,11 @@ struct mm_struct *proc_mem_open(struct inode *inode, unsigned int mode)
atomic_inc(&mm->mm_count);
/* but do not pin its memory */
mmput(mm);
+ ret = mm;
}
}
- return mm;
+ return ret;
}
static int __mem_open(struct inode *inode, struct file *file, unsigned int mode)
--
2.9.3
--
Michal Hocko
SUSE Labs
[toc] | [prev] | [next] | [standalone]
| From | Leon Yu <chianglungyu@gmail.com> |
|---|---|
| Date | 2016-10-20 14:40 +0200 |
| Message-ID | <sukNA-7z7-15@gated-at.bofh.it> |
| In reply to | #1504154 |
On Thu, Oct 20, 2016 at 1:17 AM, Michal Hocko <mhocko@kernel.org> wrote: > So here is my RFC as an alternative. Thoughts? Please note that we > currently have only very few users of use_mm() API in the kernel > so a risk of a regression is not really high. usb/gadget are using it > only temporarily. The remaining is vhost which operates on a remote mm > and I have no idea whether somebody might abuse /proc/vhost/mem or > anything - let's add Michael to the CC list. I am pretty sure nobody > abuse oom_reaper proc directory as this one is pretty new and such a > usage would be pretty much undefined as the reaper unmaps the address > space. With this patch I cannot tell the difference between a) the thread is exiting and b) it's a kernel thread, besides, getting "no such process" while the kthread does exist is a bit confusing. IMO, reading /proc/<kthread_pid>/auxv and getting empty output are quite straightforward, it doesn't seem to be that "abusive". -Leon
[toc] | [prev] | [next] | [standalone]
| From | Michal Hocko <mhocko@kernel.org> |
|---|---|
| Date | 2016-10-20 14:50 +0200 |
| Message-ID | <sukXf-7Cr-3@gated-at.bofh.it> |
| In reply to | #1504855 |
On Thu 20-10-16 20:32:43, Leon Yu wrote: > On Thu, Oct 20, 2016 at 1:17 AM, Michal Hocko <mhocko@kernel.org> wrote: > > So here is my RFC as an alternative. Thoughts? Please note that we > > currently have only very few users of use_mm() API in the kernel > > so a risk of a regression is not really high. usb/gadget are using it > > only temporarily. The remaining is vhost which operates on a remote mm > > and I have no idea whether somebody might abuse /proc/vhost/mem or > > anything - let's add Michael to the CC list. I am pretty sure nobody > > abuse oom_reaper proc directory as this one is pretty new and such a > > usage would be pretty much undefined as the reaper unmaps the address > > space. > > With this patch I cannot tell the difference between a) the thread is > exiting and b) it's a kernel thread, > besides, getting "no such process" while the kthread does exist is a > bit confusing. Do we really need to distinguish those two cases? In other words under which conditions something would fail when seeing a pid directory and ESRCH when opening a file? > IMO, reading /proc/<kthread_pid>/auxv and getting empty output are > quite straightforward, > it doesn't seem to be that "abusive". Then we need to teach all those implementations to check for kthread explicitly and return an empty output rather than relying on mm == NULL because that, as explained, might belong to some process. -- Michal Hocko SUSE Labs
[toc] | [prev] | [next] | [standalone]
| From | Leon Yu <chianglungyu@gmail.com> |
|---|---|
| Date | 2016-10-20 14:30 +0200 |
| Subject | [PATCH v2] proc: fix NULL dereference when reading /proc/<pid>/auxv |
| Message-ID | <sukDV-7vO-73@gated-at.bofh.it> |
| In reply to | #1504078 |
Reading auxv of any kernel thread results in NULL pointer dereferencing in
auxv_read() where mm can be NULL. Fix that by checking for NULL mm and
bailing out early. This is also the original behavior changed by recent
commit c5317167854e ("proc: switch auxv to use of __mem_open()").
/ # cat /proc/2/auxv
[ 8.964445] Unable to handle kernel NULL pointer dereference at virtual address 000000a8
[ 8.972555] pgd = e99e0000
[ 8.975282] [000000a8] *pgd=399e6835, *pte=00000000, *ppte=00000000
[ 8.981572] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
[ 8.986967] Modules linked in:
[ 8.990029] CPU: 3 PID: 113 Comm: cat Not tainted 4.9.0-rc1-ARCH+ #1
[ 8.996379] Hardware name: BCM2709
[ 8.999778] task: ea3b0b00 task.stack: e99b2000
[ 9.004314] PC is at auxv_read+0x24/0x4c
[ 9.008241] LR is at do_readv_writev+0x2fc/0x37c
[ 9.012860] pc : [<b0135f80>] lr : [<b00e5900>] psr: 80070013
[ 9.012860] sp : e99b3d08 ip : 00000000 fp : 00000000
[ 9.024337] r10: 00000000 r9 : b0135f5c r8 : e99b3d24
[ 9.029561] r7 : 00001000 r6 : 00000000 r5 : 00000000 r4 : 00000000
[ 9.036087] r3 : 00000008 r2 : e99b3de0 r1 : 00001000 r0 : e98ea000
[ 9.042615] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 9.049750] Control: 10c5387d Table: 399e006a DAC: 00000055
[ 9.055495] Process cat (pid: 113, stack limit = 0xe99b2210)
[ 9.061152] Stack: (0xe99b3d08 to 0xe99b4000)
[ 9.065513] 3d00: 00000000 00000000 ea0d46c0 b00e5900 e99b3d20 e99b3d24
[ 9.073696] 3d20: e9960b80 00000002 00000000 00010000 e9960b80 00000010 00000000 024200ca
[ 9.081878] 3d40: ea8855f0 00000000 e9cac8f0 00000000 ffffffff e9960c00 0000000f 00001000
[ 9.090060] 3d60: b0407b68 024200c0 b05494c0 00010000 e9960c00 b020863c 01000000 e99b3ddc
[ 9.098243] 3d80: e99b3dd8 e99651c0 e9960c00 00000000 00010000 b020aca0 e9c041e8 00000010
[ 9.106424] 3da0: e99b3e00 ffffe000 00000000 e99b3ec0 e99b3e00 b00e59c0 e99b3de0 00000000
[ 9.114606] 3dc0: e9960c00 b010eed4 00000000 00020000 ea0d46c0 af000000 e99651c0 00000000
[ 9.122788] 3de0: 00000000 00000000 e99b2000 00000008 00000000 01000000 e9960c00 00000000
[ 9.130970] 3e00: e98ea000 00001000 e9970000 00001000 e9975000 00001000 e9971000 00001000
[ 9.139152] 3e20: e99e5000 00001000 e98e8000 00001000 e9976000 00001000 e9977000 00001000
[ 9.147334] 3e40: e9978000 00001000 e9979000 00001000 e997a000 00001000 e997b000 00001000
[ 9.155516] 3e60: e9a03000 00001000 e99d6000 00001000 e99d7000 00001000 e9a14000 00001000
[ 9.163698] 3e80: 01000000 e9960c00 e99b3ef0 01000000 00000000 ea0d46c0 00000000 00000000
[ 9.171880] 3ea0: 00000000 b010eb4c 00000000 e98f2700 00000817 00000000 b010e268 00000000
[ 9.180061] 3ec0: 00000000 00000000 00000000 e9964480 01000000 e99b3f50 e99b3f48 ea0d46c0
[ 9.188244] 3ee0: 00000000 e99b3f50 01000000 b010ed6c 01000000 01000000 00000000 e9964480
[ 9.196425] 3f00: 00000000 00000000 e99b3f50 00000000 00000000 00000000 00000400 ea0d46c0
[ 9.204607] 3f20: ea0d46c0 7fffffff 00000000 e9964480 e9964480 b00e5e38 01000000 00000000
[ 9.212788] 3f40: 00000000 ea0f21b8 00000000 00000000 00000000 00000000 ea0d46c8 00000000
[ 9.220970] 3f60: 00000000 01000000 000000ef b000f4a4 e99b2000 00000000 00000000 b00e67d4
[ 9.229152] 3f80: 7fffffff 00000000 e99b2000 00000000 01000000 00000000 01000000 000000ef
[ 9.237334] 3fa0: b000f4a4 b000f300 01000000 00000000 00000001 00000003 00000000 01000000
[ 9.245515] 3fc0: 01000000 00000000 01000000 000000ef 00000001 00000000 00000001 00000000
[ 9.253698] 3fe0: a6ee73c0 aeeaecf4 00014bbc a6ee73cc 60070010 00000001 55555555 55555555
[ 9.261895] [<b0135f80>] (auxv_read) from [<b00e5900>] (do_readv_writev+0x2fc/0x37c)
[ 9.269651] [<b00e5900>] (do_readv_writev) from [<b00e59c0>] (vfs_readv+0x40/0x58)
[ 9.277234] [<b00e59c0>] (vfs_readv) from [<b010eed4>] (default_file_splice_read+0x140/0x240)
[ 9.285769] [<b010eed4>] (default_file_splice_read) from [<b010eb4c>] (splice_direct_to_actor+0xa0/0x230)
[ 9.295345] [<b010eb4c>] (splice_direct_to_actor) from [<b010ed6c>] (do_splice_direct+0x90/0xb8)
[ 9.304140] [<b010ed6c>] (do_splice_direct) from [<b00e5e38>] (do_sendfile+0x1a0/0x308)
[ 9.312155] [<b00e5e38>] (do_sendfile) from [<b00e67d4>] (SyS_sendfile64+0xd4/0xe8)
[ 9.319823] [<b00e67d4>] (SyS_sendfile64) from [<b000f300>] (ret_fast_syscall+0x0/0x34)
[ 9.327829] Code: e1a01002 e1a02003 e1a03004 e2833008 (e593e0a0)
[ 9.333973] ---[ end trace d3f50081f24b99ce ]---
Fixes: c5317167854e ("proc: switch auxv to use of __mem_open()")
Signed-off-by: Leon Yu <chianglungyu@gmail.com>
---
Changes in v2:
- remove the bogus test for IS_ERR() case which can't happen after
passing __mem_open().
fs/proc/base.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 8e654468ab67..0baf7f8a5d2d 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -1014,6 +1014,9 @@ static ssize_t auxv_read(struct file *file, char __user *buf,
{
struct mm_struct *mm = file->private_data;
unsigned int nwords = 0;
+
+ if (!mm)
+ return 0;
do {
nwords += 2;
} while (mm->saved_auxv[nwords - 2] != 0); /* AT_NULL */
--
2.10.0
[toc] | [prev] | [next] | [standalone]
| From | Oleg Nesterov <oleg@redhat.com> |
|---|---|
| Date | 2016-10-20 19:10 +0200 |
| Subject | Re: [PATCH v2] proc: fix NULL dereference when reading /proc/<pid>/auxv |
| Message-ID | <sup0R-21Y-15@gated-at.bofh.it> |
| In reply to | #1504848 |
On 10/20, Leon Yu wrote:
>
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -1014,6 +1014,9 @@ static ssize_t auxv_read(struct file *file, char __user *buf,
> {
> struct mm_struct *mm = file->private_data;
> unsigned int nwords = 0;
> +
> + if (!mm)
> + return 0;
> do {
> nwords += 2;
> } while (mm->saved_auxv[nwords - 2] != 0); /* AT_NULL */
Michal disagrees and I won't argue with his patch which makes __mem_open()
fail if ->mm == NULL. Even if I don't really understand why should we change
the old behaviour, this _can_ break or at least confuse something/someone.
However, even if we do the change above, personally I do think we should
fix the trivial bug first, then surprise the user-space.
Acked-by: Oleg Nesterov <oleg@redhat.com>
[toc] | [prev] | [next] | [standalone]
| From | Michal Hocko <mhocko@kernel.org> |
|---|---|
| Date | 2016-10-20 21:30 +0200 |
| Subject | Re: [PATCH v2] proc: fix NULL dereference when reading /proc/<pid>/auxv |
| Message-ID | <surcm-3mp-41@gated-at.bofh.it> |
| In reply to | #1505104 |
On Thu 20-10-16 19:04:39, Oleg Nesterov wrote:
> On 10/20, Leon Yu wrote:
> >
> > --- a/fs/proc/base.c
> > +++ b/fs/proc/base.c
> > @@ -1014,6 +1014,9 @@ static ssize_t auxv_read(struct file *file, char __user *buf,
> > {
> > struct mm_struct *mm = file->private_data;
> > unsigned int nwords = 0;
> > +
> > + if (!mm)
> > + return 0;
> > do {
> > nwords += 2;
> > } while (mm->saved_auxv[nwords - 2] != 0); /* AT_NULL */
>
> Michal disagrees and I won't argue with his patch which makes __mem_open()
> fail if ->mm == NULL. Even if I don't really understand why should we change
> the old behaviour, this _can_ break or at least confuse something/someone.
>
> However, even if we do the change above, personally I do think we should
> fix the trivial bug first, then surprise the user-space.
I am not objecting to this particular patch as it is obviously correct.
I was just hoping to have a more generic solution. The issue was
introduced in this merge window so it is not like we would need as
minimalistic approach possible. If the __mem_open approach sounds too
dangerous I will not pursue it.
Anyway feel free to add
Acked-by: Michal Hocko <mhocko@suse.com>
for this patch.
--
Michal Hocko
SUSE Labs
[toc] | [prev] | [next] | [standalone]
| From | Leon Yu <chianglungyu@gmail.com> |
|---|---|
| Date | 2016-10-21 14:50 +0200 |
| Subject | Re: [PATCH v2] proc: fix NULL dereference when reading /proc/<pid>/auxv |
| Message-ID | <suHqO-5zP-33@gated-at.bofh.it> |
| In reply to | #1505206 |
On Fri, Oct 21, 2016 at 3:21 AM, Michal Hocko <mhocko@kernel.org> wrote:
> On Thu 20-10-16 19:04:39, Oleg Nesterov wrote:
>> On 10/20, Leon Yu wrote:
>> >
>> > --- a/fs/proc/base.c
>> > +++ b/fs/proc/base.c
>> > @@ -1014,6 +1014,9 @@ static ssize_t auxv_read(struct file *file, char __user *buf,
>> > {
>> > struct mm_struct *mm = file->private_data;
>> > unsigned int nwords = 0;
>> > +
>> > + if (!mm)
>> > + return 0;
>> > do {
>> > nwords += 2;
>> > } while (mm->saved_auxv[nwords - 2] != 0); /* AT_NULL */
>>
>> Michal disagrees and I won't argue with his patch which makes __mem_open()
>> fail if ->mm == NULL. Even if I don't really understand why should we change
>> the old behaviour, this _can_ break or at least confuse something/someone.
>>
>> However, even if we do the change above, personally I do think we should
>> fix the trivial bug first, then surprise the user-space.
>
> I am not objecting to this particular patch as it is obviously correct.
> I was just hoping to have a more generic solution. The issue was
> introduced in this merge window so it is not like we would need as
> minimalistic approach possible. If the __mem_open approach sounds too
> dangerous I will not pursue it.
>
> Anyway feel free to add
> Acked-by: Michal Hocko <mhocko@suse.com>
> for this patch.
Many thanks to all reviewers involved in this discussion for your valueable
time and feedback.
-Leon
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web