[2.597534]
==
[2.597694] BUG: KASAN: use-after-free in bt_iter+0x29b/0x310
[2.597813] Read of size 8 at addr 8881d44a1780 by task kworker/u4:0/7
[2.597929]
[2.598042] CPU: 1 PID: 7 Comm: kworker/u4:0 Not tainted
4.20.0
On Wed, 2018-04-04 at 19:26 -0600, Jens Axboe wrote:
> Leaving the whole trace here, but I'm having a hard time making sense of it.
> It complains about a user-after-free in the inflight iteration, which is only
> working on the queue, request, and on-stack mi data. None of these would be
> freed.
On 4/4/18 5:28 PM, Ming Lei wrote:
> Hi,
>
> The following warning is observed once when running dbench on NVMe with
> the linus tree(top commit is 642e7fd23353).
>
> [ 1446.882043]
> ======
> [ 1446.886884] BU
Hi,
The following warning is observed once when running dbench on NVMe with
the linus tree(top commit is 642e7fd23353).
[ 1446.882043]
==
[ 1446.886884] BUG: KASAN: use-after-free in bt_for_each+0x1ea/0x29f
[ 1446.888045] Read
On Tue, 2017-05-02 at 16:41 +0200, Jan Kara wrote:
> So I'm also not aware of any particular breakage this would cause. However
> logically the freeing of request mempools really belongs to
> blk_release_queue() so it seems a bit dumb to move blk_exit_rl() just
> because SCSI stores the fact from
On Fri 28-04-17 17:46:47, Tejun Heo wrote:
> On Fri, Apr 21, 2017 at 09:49:17PM +, Bart Van Assche wrote:
> > On Thu, 2017-04-20 at 15:18 -0600, Scott Bauer wrote:
> > > [ 642.638860] BUG: KASAN: use-after-free in scsi_exit_rq+0xf3/0x120 at
> > > addr 8802b
On Thu, 2017-04-20 at 15:18 -0600, Scott Bauer wrote:
> [ 642.638860] BUG: KASAN: use-after-free in scsi_exit_rq+0xf3/0x120 at addr
> 8802b7fedf00
> [ 642.639362] Read of size 1 by task rcuos/5/53
> [ 642.639713] CPU: 7 PID: 53 Comm: rcuos/6 Not tainted 4.11.0-rc5+ #13
>
]
==
[ 642.638860] BUG: KASAN: use-after-free in scsi_exit_rq+0xf3/0x120 at addr
8802b7fedf00
[ 642.639362] Read of size 1 by task rcuos/5/53
[ 642.639713] CPU: 7 PID: 53 Comm: rcuos/6 Not tainted 4.11.0-rc5+ #13
[ 642.640170
On 01/24/2017 02:34 PM, Christoph Hellwig wrote:
> On Tue, Jan 24, 2017 at 11:01:42AM +0100, Matias Bjørling wrote:
>> Yup. That fixes it. Should I put together the patch, or will you take
>> care of it?
>
> I'll send it out. Of course with proper reporting credits for you.
>
Awesome. Thanks
On Tue, Jan 24, 2017 at 11:01:42AM +0100, Matias Bjørling wrote:
> Yup. That fixes it. Should I put together the patch, or will you take
> care of it?
I'll send it out. Of course with proper reporting credits for you.
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
On 01/24/2017 10:52 AM, Christoph Hellwig wrote:
> On Tue, Jan 24, 2017 at 10:32:11AM +0100, Matias Bjørling wrote:
>> *(gdb) list *blkdev_direct_IO+0x50c
>> 0x8142ab8c is in blkdev_direct_IO (fs/block_dev.c:401).
>> 396 submit_bio(bio);
>> 397 bio =
On Tue, Jan 24, 2017 at 10:32:11AM +0100, Matias Bjørling wrote:
> *(gdb) list *blkdev_direct_IO+0x50c
> 0x8142ab8c is in blkdev_direct_IO (fs/block_dev.c:401).
> 396 submit_bio(bio);
> 397 bio = bio_alloc(GFP_KERNEL, nr_pages);
> 398 }
> 399
s it
>> prematurely.
>
> Can you reproduce anything like this with a normal block device?
Looks like bcache has something similar with a get/put in it. I'll look
a bit more.
>
>>
>> The KASAN error report:
>>
>> [ 14.645916]
>> =
?
>
> The KASAN error report:
>
> [ 14.645916]
> ==================
> [ 14.648027] BUG: KASAN: use-after-free in
> blkdev_direct_IO+0x50c/0x600 at addr 8801ef30ea14
Can you resolve that address for me, please?
> Which
the bio is put twice, which leads to
modules that rely on the bio after biodev_bio_end_io() to access it
prematurely.
The KASAN error report:
[ 14.645916]
==
[ 14.648027] BUG: KASAN: use-after-free in
blkdev_direct_IO+0x50c/0x600
15 matches
Mail list logo
