Re: memory leak in qrtr_tun_open
gt; [<89fdef83>] do_sys_openat2+0xed/0x230 fs/open.c:1168 > [<4cd3d1c0>] do_sys_open fs/open.c:1184 [inline] > [<4cd3d1c0>] __do_sys_openat fs/open.c:1200 [inline] > [<4cd3d1c0>] __se_sys_openat fs/open.c:1195 [inline] > [<4cd3d1c0>] __x64_sys_openat+0x7f/0xe0 fs/open.c:1195 > [<d6a554a2>] do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 > [<99a4af52>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > BUG: memory leak > unreferenced object 0x888117d40180 (size 64): > comm "syz-executor845", pid 10294, jiffies 4295034653 (age 32.850s) > hex dump (first 32 bytes): > c0 24 04 84 ff ff ff ff 00 00 00 00 00 00 00 00 .$.. > 90 01 d4 17 81 88 ff ff 90 01 d4 17 81 88 ff ff > backtrace: > [<fcfbf0c5>] kmalloc include/linux/slab.h:552 [inline] > [<fcfbf0c5>] kzalloc include/linux/slab.h:664 [inline] > [<fcfbf0c5>] qrtr_tun_open+0x22/0x90 net/qrtr/tun.c:35 > [<3dd258a0>] misc_open+0x19c/0x1e0 drivers/char/misc.c:141 > [<c462f734>] chrdev_open+0x10d/0x340 fs/char_dev.c:414 > [<6a388b0e>] do_dentry_open+0x1e6/0x620 fs/open.c:817 > [<757d8e01>] do_open fs/namei.c:3252 [inline] > [<757d8e01>] path_openat+0x74a/0x1b00 fs/namei.c:3369 > [<b8d1608f>] do_filp_open+0xa0/0x190 fs/namei.c:3396 > [<89fdef83>] do_sys_openat2+0xed/0x230 fs/open.c:1168 > [<4cd3d1c0>] do_sys_open fs/open.c:1184 [inline] > [<4cd3d1c0>] __do_sys_openat fs/open.c:1200 [inline] > [<4cd3d1c0>] __se_sys_openat fs/open.c:1195 [inline] > [<4cd3d1c0>] __x64_sys_openat+0x7f/0xe0 fs/open.c:1195 > [<d6a554a2>] do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 > [<99a4af52>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > BUG: memory leak > unreferenced object 0x888117d40180 (size 64): > comm "syz-executor845", pid 10294, jiffies 4295034653 (age 32.930s) > hex dump (first 32 bytes): > c0 24 04 84 ff ff ff ff 00 00 00 00 00 00 00 00 .$.. > 90 01 d4 17 81 88 ff ff 90 01 d4 17 81 88 ff ff > backtrace: > [<fcfbf0c5>] kmalloc include/linux/slab.h:552 [inline] > [<fcfbf0c5>] kzalloc include/linux/slab.h:664 [inline] > [<fcfbf0c5>] qrtr_tun_open+0x22/0x90 net/qrtr/tun.c:35 > [<3dd258a0>] misc_open+0x19c/0x1e0 drivers/char/misc.c:141 > [<c462f734>] chrdev_open+0x10d/0x340 fs/char_dev.c:414 > [<6a388b0e>] do_dentry_open+0x1e6/0x620 fs/open.c:817 > [<757d8e01>] do_open fs/namei.c:3252 [inline] > [<757d8e01>] path_openat+0x74a/0x1b00 fs/namei.c:3369 > [<b8d1608f>] do_filp_open+0xa0/0x190 fs/namei.c:3396 > [<89fdef83>] do_sys_openat2+0xed/0x230 fs/open.c:1168 > [<4cd3d1c0>] do_sys_open fs/open.c:1184 [inline] > [<4cd3d1c0>] __do_sys_openat fs/open.c:1200 [inline] > [<4cd3d1c0>] __se_sys_openat fs/open.c:1195 [inline] > [<4cd3d1c0>] __x64_sys_openat+0x7f/0xe0 fs/open.c:1195 > [<d6a554a2>] do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 > [<99a4af52>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > write to /proc/sys/kernel/hung_task_check_interval_secs failed: No such file > or directory > write to /proc/sys/kernel/softlockup_all_cpu_backtrace failed: No such file > or directory > write to /proc/sys/fs/mount-max failed: Bad address > write to /proc/sys/kernel/hung_task_check_interval_secs failed: No such file > or directory > write to /proc/sys/kernel/softlockup_all_cpu_backtrace failed: No such file > or directory > write to /proc/sys/fs/mount-max failed: Bad address > write to /proc/sys/kernel/hung_task_check_interval_secs failed: No such file > or directory > write to /proc/sys/kernel/softlockup_all_cpu_backtrace failed: No such file > or directory > write to /proc/sys/fs/mount-max failed: Bad address > write to /proc/sys/kernel/hung_task_check_interval_secs failed: No such file > or directory > write to /proc/sys/kernel/softlockup_all_cpu_backtrace failed: No such file > or directory > write to /proc/sys/fs/mount-max failed: Bad address > write to /proc/sys/kernel/hung_task_check_interval_secs failed: No such file > or directory > write to /proc/sys/kernel/softlockup_all_cpu_backtrace failed: No such file > or directory > write to
Re: memory leak in copy_net_ns
#syz test: https://github.com/google/kasan.git 43b815c6
>From 366b85e1555a8ef4d0f0759c2da8d8dff4598ace Mon Sep 17 00:00:00 2001
From: Takeshi Misawa
Date: Sat, 19 Oct 2019 11:44:45 +0900
Subject: [PATCH] keys: Fix memory leak in copy_net_ns
If copy_net_ns() failed after net_alloc(), net->key_domain is leaked.
Fix this, by freeing key_domain in error path.
syzbot report:
BUG: memory leak
unreferenced object 0x8881175007e0 (size 32):
comm "syz-executor902", pid 7069, jiffies 4294944350 (age 28.400s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
backtrace:
[<a83ed741>] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline]
[<a83ed741>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<a83ed741>] slab_alloc mm/slab.c:3326 [inline]
[<a83ed741>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553
[<59fc92b9>] kmalloc include/linux/slab.h:547 [inline]
[<59fc92b9>] kzalloc include/linux/slab.h:742 [inline]
[<59fc92b9>] net_alloc net/core/net_namespace.c:398 [inline]
[<59fc92b9>] copy_net_ns+0xb2/0x220 net/core/net_namespace.c:445
[<a9d74bbc>] create_new_namespaces+0x141/0x2a0 kernel/nsproxy.c:103
[<8047d645>] unshare_nsproxy_namespaces+0x7f/0x100 kernel/nsproxy.c:202
[<5993ea6e>] ksys_unshare+0x236/0x490 kernel/fork.c:2674
[<19417e75>] __do_sys_unshare kernel/fork.c:2742 [inline]
[<19417e75>] __se_sys_unshare kernel/fork.c:2740 [inline]
[<19417e75>] __x64_sys_unshare+0x16/0x20 kernel/fork.c:2740
[<f4c5f2c8>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:296
[<38550184>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
syzbot reported other leak in copy_net_ns -> setup_net.
This problem is already fixed by cf47a0b882a4e5f6b34c7949d7b293e9287f1972.
sysbot link:
https://syzkaller.appspot.com/bug?id=3babacc2ed6bddb8e168d022ef77d32db0e05ea6
Fixes: 9b242610514f ("keys: Network namespace domain tag")
Reported-by: syzbot+3b3296d032353c331...@syzkaller.appspotmail.com
Signed-off-by: Takeshi Misawa
---
net/core/net_namespace.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
index a0e0d298c991..b88905792795 100644
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -478,6 +478,7 @@ struct net *copy_net_ns(unsigned long flags,
if (rv < 0) {
put_userns:
+ key_remove_domain(net->key_domain);
put_user_ns(user_ns);
net_drop_ns(net);
dec_ucounts:
--
2.17.1
Re: memory leak in ppp_write
#syz test: https://github.com/google/kasan.git 6525771f
>From e4ff0d04a4b8dd6da3dfb9135235ae5360ce86e6 Mon Sep 17 00:00:00 2001
From: Takeshi Misawa
Date: Wed, 11 Sep 2019 22:18:43 +0900
Subject: [PATCH] ppp: Fix memory leak in ppp_write
When ppp is closing, __ppp_xmit_process() failed to enqueue skb
and skb allocated in ppp_write() is leaked.
syzbot reported :
BUG: memory leak
unreferenced object 0x88812a17bc00 (size 224):
comm "syz-executor673", pid 6952, jiffies 4294942888 (age 13.040s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
backtrace:
[<d110fff9>] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline]
[<d110fff9>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<d110fff9>] slab_alloc_node mm/slab.c:3262 [inline]
[<d110fff9>] kmem_cache_alloc_node+0x163/0x2f0 mm/slab.c:3574
[<2d616113>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:197
[<0167fc45>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<0167fc45>] ppp_write+0x48/0x120 drivers/net/ppp/ppp_generic.c:502
[<9ab42c0b>] __vfs_write+0x43/0xa0 fs/read_write.c:494
[<086b2e22>] vfs_write fs/read_write.c:558 [inline]
[<086b2e22>] vfs_write+0xee/0x210 fs/read_write.c:542
[<a2b70ef9>] ksys_write+0x7c/0x130 fs/read_write.c:611
[<ce5e0fdd>] __do_sys_write fs/read_write.c:623 [inline]
[<ce5e0fdd>] __se_sys_write fs/read_write.c:620 [inline]
[<ce5e0fdd>] __x64_sys_write+0x1e/0x30 fs/read_write.c:620
[<d9d7b370>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:296
[<06e6d506>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fix this by freeing skb, if ppp is closing.
Reported-by: syzbot+d9c8bf24e56416d7c...@syzkaller.appspotmail.com
Signed-off-by: Takeshi Misawa
---
drivers/net/ppp/ppp_generic.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c
index a30e41a56085..9a1b006904a7 100644
--- a/drivers/net/ppp/ppp_generic.c
+++ b/drivers/net/ppp/ppp_generic.c
@@ -1415,6 +1415,8 @@ static void __ppp_xmit_process(struct ppp *ppp, struct sk_buff *skb)
netif_wake_queue(ppp->dev);
else
netif_stop_queue(ppp->dev);
+ } else {
+ kfree_skb(skb);
}
ppp_xmit_unlock(ppp);
}
--
2.17.1
[PATCH] tomoyo: Fix incorrect return value from tomoyo_find_next_domain()
When filename exceeds PATH_MAX,
tomoyo_find_next_domain() retval is not ENAMETOOLONG, but ENOENT.
Fix this by retuen kern_path() error.
Signed-off-by: Takeshi Misawa
---
Dear Tetsuo Handa
I found unexpected return value from TOMOYO and try to create a patch.
If this is not acceptable for security reason, please discard this patch.
Regards.
---
security/tomoyo/domain.c | 7 +--
security/tomoyo/realpath.c | 9 +++--
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/security/tomoyo/domain.c b/security/tomoyo/domain.c
index 8526a0a74023..3d8034701344 100644
--- a/security/tomoyo/domain.c
+++ b/security/tomoyo/domain.c
@@ -723,8 +723,10 @@ int tomoyo_find_next_domain(struct linux_binprm *bprm)
/* Get symlink's pathname of program. */
retval = -ENOENT;
exename.name = tomoyo_realpath_nofollow(original_name);
- if (!exename.name)
+ if (IS_ERR(exename.name)) {
+ retval = PTR_ERR(exename.name);
goto out;
+ }
tomoyo_fill_path_info(&exename);
retry:
/* Check 'aggregator' directive. */
@@ -870,7 +872,8 @@ int tomoyo_find_next_domain(struct linux_binprm *bprm)
s->domain_info = domain;
atomic_inc(&domain->users);
}
- kfree(exename.name);
+ if (!IS_ERR(exename.name))
+ kfree(exename.name);
if (!retval) {
ee->r.domain = domain;
retval = tomoyo_environ(ee);
diff --git a/security/tomoyo/realpath.c b/security/tomoyo/realpath.c
index e7832448d721..d73e66be05ef 100644
--- a/security/tomoyo/realpath.c
+++ b/security/tomoyo/realpath.c
@@ -332,10 +332,15 @@ char *tomoyo_realpath_from_path(const struct path *path)
char *tomoyo_realpath_nofollow(const char *pathname)
{
struct path path;
+ char *buf = NULL;
+ int err;
- if (pathname && kern_path(pathname, 0, &path) == 0) {
- char *buf = tomoyo_realpath_from_path(&path);
+ if (pathname) {
+ err = kern_path(pathname, 0, &path);
+ if (unlikely(err))
+ return ERR_PTR(err);
+ buf = tomoyo_realpath_from_path(&path);
path_put(&path);
return buf;
}
--
2.17.1
[PATCH v2] tracing: Fix memory leak in tracing_err_log_open()
If tracing_err_log_open() call seq_open(), allocated memory is not freed.
kmemleak report:
unreferenced object 0x92c0781d1100 (size 128):
comm "tail", pid 15116, jiffies 4295163855 (age 22.704s)
hex dump (first 32 bytes):
00 f0 08 e5 c0 92 ff ff 00 10 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
backtrace:
[<0d0687d5>] kmem_cache_alloc+0x11f/0x1e0
[<3e3039a8>] seq_open+0x2f/0x90
[<8dd36b7d>] tracing_err_log_open+0x67/0x140
[<5a431ae2>] do_dentry_open+0x1df/0x3a0
[<a2910603>] vfs_open+0x2f/0x40
[<38b0a383>] path_openat+0x2e8/0x1690
[<fe025bda>] do_filp_open+0x9b/0x110
[<483a5091>] do_sys_open+0x1ba/0x260
[<c558b5fd>] __x64_sys_openat+0x20/0x30
[<6881ec07>] do_syscall_64+0x5a/0x130
[<571c2e94>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fix this by calling seq_release() in tracing_err_log_fops.release().
Signed-off-by: Takeshi Misawa
---
Dear Steven Rostedt
Thanks for reviewing.
> Actually, I think it is safer to have the condition be:
>
> if (file->f_mode & FMODE_READ)
>
> As that would match the open.
>
> Can you send a v2?
I send a v2 patch.
Regards.
---
kernel/trace/trace.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 83e08b78dbee..4122ccde6ec2 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -7126,12 +7126,24 @@ static ssize_t tracing_err_log_write(struct file *file,
return count;
}
+static int tracing_err_log_release(struct inode *inode, struct file *file)
+{
+ struct trace_array *tr = inode->i_private;
+
+ trace_array_put(tr);
+
+ if (file->f_mode & FMODE_READ)
+ seq_release(inode, file);
+
+ return 0;
+}
+
static const struct file_operations tracing_err_log_fops = {
.open = tracing_err_log_open,
.write = tracing_err_log_write,
.read = seq_read,
.llseek = seq_lseek,
- .release= tracing_release_generic_tr,
+ .release= tracing_err_log_release,
};
static int tracing_buffers_open(struct inode *inode, struct file *filp)
--
2.17.1
[PATCH] tracing: Fix memory leak in tracing_err_log_open()
If tracing_err_log_open() call seq_open(), allocated memory is not freed.
kmemleak report:
unreferenced object 0x92c0781d1100 (size 128):
comm "tail", pid 15116, jiffies 4295163855 (age 22.704s)
hex dump (first 32 bytes):
00 f0 08 e5 c0 92 ff ff 00 10 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
backtrace:
[<0d0687d5>] kmem_cache_alloc+0x11f/0x1e0
[<3e3039a8>] seq_open+0x2f/0x90
[<8dd36b7d>] tracing_err_log_open+0x67/0x140
[<5a431ae2>] do_dentry_open+0x1df/0x3a0
[<a2910603>] vfs_open+0x2f/0x40
[<38b0a383>] path_openat+0x2e8/0x1690
[<fe025bda>] do_filp_open+0x9b/0x110
[<483a5091>] do_sys_open+0x1ba/0x260
[<c558b5fd>] __x64_sys_openat+0x20/0x30
[<6881ec07>] do_syscall_64+0x5a/0x130
[<571c2e94>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fix this by calling seq_release() in tracing_err_log_fops.release().
Signed-off-by: Takeshi Misawa
---
Dear Steven Rostedt
I found kmemleak in tracing subsystem, and try to create a patch.
Please consider this memory leak and patch.
Regards.
---
kernel/trace/trace.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 83e08b78dbee..574648798978 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -7126,12 +7126,24 @@ static ssize_t tracing_err_log_write(struct file *file,
return count;
}
+static int tracing_err_log_release(struct inode *inode, struct file *file)
+{
+ struct trace_array *tr = inode->i_private;
+
+ trace_array_put(tr);
+
+ if (file->private_data)
+ seq_release(inode, file);
+
+ return 0;
+}
+
static const struct file_operations tracing_err_log_fops = {
.open = tracing_err_log_open,
.write = tracing_err_log_write,
.read = seq_read,
.llseek = seq_lseek,
- .release= tracing_release_generic_tr,
+ .release= tracing_err_log_release,
};
static int tracing_buffers_open(struct inode *inode, struct file *filp)
--
2.17.1
[PATCH] trace: fix memory leak in create_filter()
In create_filter(), pe variable is leaked.
Since commit 80765597bc58 ("tracing: Rewrite filter logic to be simpler
and faster"), create_filter_finish() is missing.
kmemleak:
unreferenced object 0x90148ba9c790 (size 8):
comm "bash", pid 1378, jiffies 4294731025 (age 15.258s)
hex dump (first 8 bytes):
00 00 00 00 00 00 00 00
backtrace:
[<d9a25450>] create_filter+0x47/0xc0
[<84514f08>] set_trigger_filter+0x87/0x130
[<17f6c9ef>] event_trigger_callback+0x114/0x220
[<5096f447>] event_trigger_write+0x113/0x1b0
[<a5f767d1>] __vfs_write+0x36/0x1a0
[<ca62b71e>] vfs_write+0xa5/0x1a0
[<fdbd8005>] ksys_write+0x4f/0xb0
[<ec6e3711>] do_syscall_64+0x5b/0x160
[<3ad36bb4>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[<00007a35f0f5>] 0x
Fix this.
Signed-off-by: Takeshi Misawa
---
I found kmemleak in tracing subsystem.
Please consider this patch.
Regards.
---
kernel/trace/trace_events_filter.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/trace/trace_events_filter.c
b/kernel/trace/trace_events_filter.c
index 84a65173b1e9..fb4ba08163ba 100644
--- a/kernel/trace/trace_events_filter.c
+++ b/kernel/trace/trace_events_filter.c
@@ -1719,6 +1719,8 @@ static int create_filter(struct trace_event_call *call,
if (err && set_str)
append_filter_err(pe, *filterp);
+ create_filter_finish(pe);
+
return err;
}
--
2.19.1
