[PATCH 1/1 linux-next] ipc/msg.c: fix memory leak in do_msgsnd()

[PATCH 1/1 linux-next] ipc/msg.c: fix memory leak in do_msgsnd()

[Fabian Frederick]

Running LTP msgsnd06 with kmemleak gives the following:

cat /sys/kernel/debug/kmemleak

unreferenced object 0xffff88003c0a11f8 (size 8):
  comm "msgsnd06", pid 1645, jiffies 4294672526 (age 6.549s)
  hex dump (first 8 bytes):
    1b 00 00 00 01 00 00 00                          ........
  backtrace:
    [<ffffffff818e2c43>] kmemleak_alloc+0x23/0x40
    [<ffffffff81177f31>] kmem_cache_alloc_trace+0xe1/0x180
    [<ffffffff812d42af>] selinux_msg_queue_alloc_security+0x3f/0xd0
    [<ffffffff812cc6be>] security_msg_queue_alloc+0x2e/0x40
    [<ffffffff812b94ee>] newque+0x4e/0x150
    [<ffffffff812b8cb9>] ipcget+0x159/0x1b0
    [<ffffffff812b98d9>] SyS_msgget+0x39/0x40
    [<ffffffff818e7bdb>] entry_SYSCALL_64_fastpath+0x13/0x8f
    [<ffffffffffffffff>] 0xffffffffffffffff

ipc_rcu_free() was given to ipc_rcu_putref() instead of msg_rcu_free()
which does security cleaning.

Signed-off-by: Fabian Frederick <fabf@skynet.be>
---
 ipc/msg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ipc/msg.c b/ipc/msg.c
index 59559a2..43e9631 100644
--- a/ipc/msg.c
+++ b/ipc/msg.c
@@ -681,7 +681,7 @@ long do_msgsnd(int msqid, long mtype, void __user *mtext,
 		rcu_read_lock();
 		ipc_lock_object(&msq->q_perm);
 
-		ipc_rcu_putref(msq, ipc_rcu_free);
+		ipc_rcu_putref(msq, msg_rcu_free);
 		/* raced with RMID? */
 		if (!ipc_valid_object(&msq->q_perm)) {
 			err = -EIDRM;
-- 
2.8.1

Re: [PATCH 1/1 linux-next] ipc/msg.c: fix memory leak in do_msgsnd()

[Manfred Spraul]

Hi Fabian,

On 07/29/2016 10:15 AM, Fabian Frederick wrote:
> Running LTP msgsnd06 with kmemleak gives the following:
>
> cat /sys/kernel/debug/kmemleak
>
> unreferenced object 0xffff88003c0a11f8 (size 8):
>    comm "msgsnd06", pid 1645, jiffies 4294672526 (age 6.549s)
>    hex dump (first 8 bytes):
>      1b 00 00 00 01 00 00 00                          ........
>    backtrace:
>      [<ffffffff818e2c43>] kmemleak_alloc+0x23/0x40
>      [<ffffffff81177f31>] kmem_cache_alloc_trace+0xe1/0x180
>      [<ffffffff812d42af>] selinux_msg_queue_alloc_security+0x3f/0xd0
>      [<ffffffff812cc6be>] security_msg_queue_alloc+0x2e/0x40
>      [<ffffffff812b94ee>] newque+0x4e/0x150
>      [<ffffffff812b8cb9>] ipcget+0x159/0x1b0
>      [<ffffffff812b98d9>] SyS_msgget+0x39/0x40
>      [<ffffffff818e7bdb>] entry_SYSCALL_64_fastpath+0x13/0x8f
>      [<ffffffffffffffff>] 0xffffffffffffffff
>
> ipc_rcu_free() was given to ipc_rcu_putref() instead of msg_rcu_free()
> which does security cleaning.
Good catch!

 From a quick look:
- The same bug appears to exist in sem.c. Do you want to fix it as well?
- Did you check when it was introduced? I would add cc stable.

--
     Manfred

Re: [PATCH 1/1 linux-next] ipc/msg.c: fix memory leak in do_msgsnd()

[Fabian Frederick]

> On 31 July 2016 at 16:36 Manfred Spraul <manfred@colorfullife.com> wrote:
>
>
> Hi Fabian,
>
> On 07/29/2016 10:15 AM, Fabian Frederick wrote:
> > Running LTP msgsnd06 with kmemleak gives the following:
> >
> > cat /sys/kernel/debug/kmemleak
> >
> > unreferenced object 0xffff88003c0a11f8 (size 8):
> >    comm "msgsnd06", pid 1645, jiffies 4294672526 (age 6.549s)
> >    hex dump (first 8 bytes):
> >      1b 00 00 00 01 00 00 00                          ........
> >    backtrace:
> >      [] kmemleak_alloc+0x23/0x40
> >      [] kmem_cache_alloc_trace+0xe1/0x180
> >      [] selinux_msg_queue_alloc_security+0x3f/0xd0
> >      [] security_msg_queue_alloc+0x2e/0x40
> >      [] newque+0x4e/0x150
> >      [] ipcget+0x159/0x1b0
> >      [] SyS_msgget+0x39/0x40
> >      [] entry_SYSCALL_64_fastpath+0x13/0x8f
> >      [] 0xffffffffffffffff
> >
> > ipc_rcu_free() was given to ipc_rcu_putref() instead of msg_rcu_free()
> > which does security cleaning.
> Good catch!
>
>  From a quick look:
> - The same bug appears to exist in sem.c. Do you want to fix it as well?
> - Did you check when it was introduced? I would add cc stable.

Hi Manfred,

Thanks for your advices. I hope the second version is ok. I'll have a look at
sem.c to do the same.

Regards,
Fabian

>
> --
>      Manfred
>