Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1690972 > unrolled thread

Re: 4.12 NULL pointer dereference in kmem_cache_free on USB storage removal

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: 4.12 NULL pointer dereference in kmem_cache_free on USB storage  removal Yagmur Oymak <yagmur.oymak@gmail.com> - 2017-07-19 07:20 +0200
    Re: 4.12 NULL pointer dereference in kmem_cache_free on USB storage  removal Bart Van Assche <Bart.VanAssche@wdc.com> - 2017-07-19 18:10 +0200

#1690972 — Re: 4.12 NULL pointer dereference in kmem_cache_free on USB storage removal

Hello,

That patch fixes the problem, as far as I tested. However, it still is
not included in stable by 4.12.2. The problem persists there, and is
fixed when this patch is applied on top of it. What to to about it?

Thanks,

Yagmur Oymak.


On 07/14/2017 12:07 AM, Bart Van Assche wrote:
> On Thu, 2017-07-13 at 23:24 +0300, Meelis Roos wrote:
>> [258062.320700] RIP: 0010:kmem_cache_free+0x12/0x160
>> [258062.320886] Call Trace:
>> [258062.320897]  scsi_exit_rq+0x4d/0x60
>> [258062.320909]  free_request_size+0x1c/0x30
>> [258062.320923]  mempool_destroy+0x1d/0x60
>> [258062.320935]  blk_exit_rl+0x1b/0x40
>> [258062.320946]  __blk_release_queue+0x7d/0x120
>> [258062.320959]  process_one_work+0x1af/0x340
>> [258062.320972]  worker_thread+0x43/0x3e0
>> [258062.320984]  kthread+0xfe/0x130
>> [258062.320995]  ? create_worker+0x170/0x170
>> [258062.321007]  ? kthread_create_on_node+0x40/0x40
>> [258062.321022]  ret_from_fork+0x22/0x30
> Hello Meelis,
>
> Thank you for your report. Can you apply commit 8e6882545d8c ("scsi: Avoid
> that scsi_exit_rq() triggers a use-after-free") on top of kernel v4.12 and
> retest? That commit has been tagged "Cc: stable" so I hope that this patch
> will be included in kernel v4.12.1. However, that kernel is not yet available
> unfortunately ...
>
> Thanks,
>
> Bart.

[toc] | [next] | [standalone]

#1691983

On Wed, 2017-07-19 at 08:13 +0300, Yagmur Oymak wrote:
> On 07/14/2017 12:07 AM, Bart Van Assche wrote:
> > On Thu, 2017-07-13 at 23:24 +0300, Meelis Roos wrote:
> > > [258062.320700] RIP: 0010:kmem_cache_free+0x12/0x160
> > > [258062.320886] Call Trace:
> > > [258062.320897]  scsi_exit_rq+0x4d/0x60
> > > [258062.320909]  free_request_size+0x1c/0x30
> > > [258062.320923]  mempool_destroy+0x1d/0x60
> > > [258062.320935]  blk_exit_rl+0x1b/0x40
> > > [258062.320946]  __blk_release_queue+0x7d/0x120
> > > [258062.320959]  process_one_work+0x1af/0x340
> > > [258062.320972]  worker_thread+0x43/0x3e0
> > > [258062.320984]  kthread+0xfe/0x130
> > > [258062.320995]  ? create_worker+0x170/0x170
> > > [258062.321007]  ? kthread_create_on_node+0x40/0x40
> > > [258062.321022]  ret_from_fork+0x22/0x30
> > 
> > Thank you for your report. Can you apply commit 8e6882545d8c ("scsi: Avoid
> > that scsi_exit_rq() triggers a use-after-free") on top of kernel v4.12 and
> > retest? That commit has been tagged "Cc: stable" so I hope that this patch
> > will be included in kernel v4.12.1. However, that kernel is not yet available
> > unfortunately ...
> 
> That patch fixes the problem, as far as I tested. However, it still is
> not included in stable by 4.12.2. The problem persists there, and is
> fixed when this patch is applied on top of it. What to to about it? 
 
Hello Yagmur,

[ Please don't top-post -- this is considered annoying in the Linux community ]

Since kernel v4.13-rc1 has been released and since commit 8e6882545d8c is included
in v4.13-rc1 I assume that it won't take long before a stable kernel is released
that includes that commit. BTW, Greg just announced that that commit will be included
in the next v4.11 stable kernel. See also https://lkml.org/lkml/2017/7/19/494.

Bart.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web