linux-kernel - Re: scsi: memory leak in sg_start

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1515688107.2752.12.camel@wdc.com>
Date:   Thu, 11 Jan 2018 16:28:28 +0000
From:   Bart Van Assche <Bart.VanAssche@....com>
To:     "syzkaller@...glegroups.com" <syzkaller@...glegroups.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
        "dgilbert@...erlog.com" <dgilbert@...erlog.com>,
        "martin.petersen@...cle.com" <martin.petersen@...cle.com>,
        "dvyukov@...gle.com" <dvyukov@...gle.com>,
        "axboe@...nel.dk" <axboe@...nel.dk>,
        "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
        "jejb@...ux.vnet.ibm.com" <jejb@...ux.vnet.ibm.com>
Subject: Re: scsi: memory leak in sg_start_req

On Thu, 2018-01-11 at 01:04 -0500, Douglas Gilbert wrote:
> Monitoring that program with 'free' from another terminal I see
> about 2.5 GBytes of ram "swallowed" almost immediately when the test
> program runs. When the program exits (about 50 seconds later) as far
> as I can see all that ram is given back.

Hello Doug,

There is probably something that's leaking memory in one of the functions in
the reported call stack. kmemleak reports the following in my tests (I haven't
had the time yet to analyze this further):

unreferenced object 0xffff880363c09088 (size 192): 
 comm "multipath", pid 20088, jiffies 4295034706 (age 6544.980s) 
 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 20 00 00 00 12 01 00 00 00 00 00 00  .... ........... 
 backtrace: 
   [<ffffffff81659e1a>] kmemleak_alloc+0x4a/0xa0 
   [<ffffffff811f51fe>] __kmalloc+0x16e/0x320 
   [<ffffffff812e4848>] bio_alloc_bioset+0x198/0x1f0 
   [<ffffffff812e51b9>] bio_map_user_iov+0x129/0x3f0 
   [<ffffffff812f5863>] blk_rq_map_user_iov+0x123/0x210 
   [<ffffffff812f5a02>] blk_rq_map_user+0x52/0x60 
   [<ffffffff8130b7b5>] sg_io+0x385/0x3c0 
   [<ffffffff8130bad3>] scsi_cmd_ioctl+0x2e3/0x450 
   [<ffffffff8130bc82>] scsi_cmd_blk_ioctl+0x42/0x50 
   [<ffffffff8148d835>] sd_ioctl+0x85/0x110 
   [<ffffffff81302bfb>] blkdev_ioctl+0x4db/0x970 
   [<ffffffff812660fd>] block_ioctl+0x3d/0x50 
   [<ffffffff812348d4>] do_vfs_ioctl+0x94/0x670 
   [<ffffffff81234ef1>] SyS_ioctl+0x41/0x70 
   [<ffffffff81001e5c>] do_syscall_64+0x5c/0x110 
   [<ffffffff81667564>] return_from_SYSCALL_64+0x0/0x7a

Bart.