All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: syzbot <syzbot+44e64397bd81d5e84cba@syzkaller.appspotmail.com>
Cc: hverkuil@xs4all.nl, linux-media@vger.kernel.org,
	linux-usb@vger.kernel.org, mchehab@kernel.org,
	syzkaller-bugs@googlegroups.com
Subject: Re: memory leak in hub_event
Date: Mon, 23 Nov 2020 17:24:28 -0500	[thread overview]
Message-ID: <20201123222428.GB721643@rowland.harvard.edu> (raw)
In-Reply-To: <0000000000004b629f05b4cd7124@google.com>

On Mon, Nov 23, 2020 at 02:09:05PM -0800, syzbot wrote:
> Hello,
> 
> syzbot has tested the proposed patch but the reproducer is still triggering an issue:
> memory leak in rxrpc_lookup_local
> 
> BUG: memory leak
> unreferenced object 0xffff888117ab9900 (size 256):
>   comm "syz-executor.0", pid 8883, jiffies 4294943811 (age 433.620s)
>   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 0a 00 00 00 00 80 cb 17 81 88 ff ff  ................
>   backtrace:
>     [<000000009003383a>] kmalloc include/linux/slab.h:552 [inline]
>     [<000000009003383a>] kzalloc include/linux/slab.h:664 [inline]
>     [<000000009003383a>] rxrpc_alloc_local net/rxrpc/local_object.c:79 [inline]
>     [<000000009003383a>] rxrpc_lookup_local+0x1c1/0x760 net/rxrpc/local_object.c:244
>     [<00000000609410d3>] rxrpc_bind+0x174/0x240 net/rxrpc/af_rxrpc.c:149
>     [<00000000661f73ad>] afs_open_socket+0xdb/0x200 fs/afs/rxrpc.c:64
>     [<00000000e3eb5768>] afs_net_init+0x2b4/0x340 fs/afs/main.c:126
>     [<000000002c6bf109>] ops_init+0x4e/0x190 net/core/net_namespace.c:152
>     [<000000009ce0aa62>] setup_net+0xdb/0x2d0 net/core/net_namespace.c:342
>     [<00000000db8c8dc2>] copy_net_ns+0x14b/0x320 net/core/net_namespace.c:483
>     [<00000000b04b70a8>] create_new_namespaces+0x199/0x4e0 kernel/nsproxy.c:110
>     [<000000005dc01eb8>] unshare_nsproxy_namespaces+0x9b/0x120 kernel/nsproxy.c:231
>     [<00000000422ec6bd>] ksys_unshare+0x2fe/0x5c0 kernel/fork.c:2949
>     [<0000000042f77bee>] __do_sys_unshare kernel/fork.c:3017 [inline]
>     [<0000000042f77bee>] __se_sys_unshare kernel/fork.c:3015 [inline]
>     [<0000000042f77bee>] __x64_sys_unshare+0x12/0x20 kernel/fork.c:3015
>     [<00000000e58e69f9>] do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
>     [<000000000a67195e>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

Okay, that confirms it.  This is a completely different memory leak, as 
can be seen by comparing the stack trace with the previous one.  The 
problem with the gspca driver is gone.

Mauro/Hans, what should I do with the patch?

Alan Stern

  reply	other threads:[~2020-11-23 22:24 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-20 15:15 memory leak in hub_event syzbot
2020-11-20 16:56 ` Alan Stern
2020-11-20 16:56   ` syzbot
2020-11-20 17:00     ` Alan Stern
2020-11-23 18:29       ` Andrey Konovalov
2020-11-23 18:44         ` syzbot
2020-11-23 19:32           ` Alan Stern
2020-11-23 19:42             ` syzbot
2020-11-23 19:53               ` Alan Stern
2020-11-23 20:01                 ` syzbot
2020-11-23 20:38                   ` Alan Stern
2020-11-23 20:48                     ` syzbot
2020-11-23 21:53                       ` Alan Stern
2020-11-23 22:09                         ` syzbot
2020-11-23 22:24                           ` Alan Stern [this message]
2020-11-24 11:38                             ` Hans Verkuil
2020-11-24 16:00                               ` [PATCH] media: gspca: Fix memory leak in probe Alan Stern
2020-12-02  8:58                                 ` Hans Verkuil
2020-12-02 17:20                                   ` [PATCH v2] " Alan Stern
2020-12-02 16:22                           ` memory leak in hub_event Alan Stern
2020-12-02 16:37                             ` syzbot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201123222428.GB721643@rowland.harvard.edu \
    --to=stern@rowland.harvard.edu \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=syzbot+44e64397bd81d5e84cba@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.