All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ming Lei <ming.lei@redhat.com>
To: Tyrel Datwyler <tyreld@linux.ibm.com>
Cc: "Martin K . Petersen" <martin.petersen@oracle.com>,
	linux-scsi@vger.kernel.org, Bart Van Assche <bvanassche@acm.org>,
	John Garry <john.garry@huawei.com>,
	Hannes Reinecke <hare@suse.de>
Subject: Re: [PATCH 1/4] scsi: core: fix error handling of scsi_host_alloc
Date: Wed, 30 Jun 2021 08:11:37 +0800	[thread overview]
Message-ID: <YNu2uZAqrXuMqAFB@T590> (raw)
In-Reply-To: <57f7bb8a-cd21-e553-8f42-f154b9e232f5@linux.ibm.com>

On Tue, Jun 29, 2021 at 12:23:04PM -0700, Tyrel Datwyler wrote:
> On 6/2/21 6:30 AM, Ming Lei wrote:
> > After device is initialized via device_initialize(), or its name is
> > set via dev_set_name(), the device has to be freed via put_device(),
> > otherwise device name will be leaked because it is allocated
> > dynamically in dev_set_name().
> > 
> > Fixes the issue by replacing kfree(shost) via put_device(&shost->shost_gendev)
> > which can help to free dev_name(&shost->shost_dev) when host state is
> > in SHOST_CREATED. Meantime needn't to remove IDA and stop the kthread of
> > shost->ehandler in the error handling code.
> 
> This statement is incorrect for kthread. If error handler thread failed to spawn
> the value of shost->ehandler will be ERR_PTR(-ENOMEM) which will pass the "if
> (shost->ehandler)" check in scsi_host_dev_release() resulting in a
> kthread_stop() call for a non-existant kthread which triggers a bad pointer
> dereference. Here is an example splat:
> 
> scsi host11: error handler thread failed to spawn, error = -4
> Kernel attempted to read user page (10c) - exploit attempt? (uid: 0)
> BUG: Kernel NULL pointer dereference on read at 0x0000010c
> Faulting instruction address: 0xc00000000818e9a8
> Oops: Kernel access of bad area, sig: 11 [#1]
> LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
> Modules linked in: ibmvscsi(+) scsi_transport_srp dm_multipath dm_mirror dm_region
>  hash dm_log dm_mod fuse overlay squashfs loop
> CPU: 12 PID: 274 Comm: systemd-udevd Not tainted 5.13.0-rc7 #1
> NIP:  c00000000818e9a8 LR: c0000000089846e8 CTR: 0000000000007ee8
> REGS: c000000037d12ea0 TRAP: 0300   Not tainted  (5.13.0-rc7)
> MSR:  800000000280b033 &lt;SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE&gt;  CR: 28228228
> XER: 20040001
> CFAR: c0000000089846e4 DAR: 000000000000010c DSISR: 40000000 IRQMASK: 0
> GPR00: c0000000089846e8 c000000037d13140 c000000009cc1100 fffffffffffffffc
> GPR04: 0000000000000001 0000000000000000 0000000000000000 c000000037dc0000
> GPR08: 0000000000000000 c000000037dc0000 0000000000000001 00000000fffff7ff
> GPR12: 0000000000008000 c00000000a049000 c000000037d13d00 000000011134d5a0
> GPR16: 0000000000001740 c0080000190d0000 c0080000190d1740 c000000009129288
> GPR20: c000000037d13bc0 0000000000000001 c000000037d13bc0 c0080000190b7898
> GPR24: c0080000190b7708 0000000000000000 c000000033bb2c48 0000000000000000
> GPR28: c000000046b28280 0000000000000000 000000000000010c fffffffffffffffc
> NIP [c00000000818e9a8] kthread_stop+0x38/0x230
> LR [c0000000089846e8] scsi_host_dev_release+0x98/0x160
> Call Trace:
> [c000000033bb2c48] 0xc000000033bb2c48 (unreliable)
> [c0000000089846e8] scsi_host_dev_release+0x98/0x160
> [c00000000891e960] device_release+0x60/0x100
> [c0000000087e55c4] kobject_release+0x84/0x210
> [c00000000891ec78] put_device+0x28/0x40
> [c000000008984ea4] scsi_host_alloc+0x314/0x430
> [c0080000190b38bc] ibmvscsi_probe+0x54/0xad0 [ibmvscsi]
> [c000000008110104] vio_bus_probe+0xa4/0x4b0
> [c00000000892a860] really_probe+0x140/0x680
> [c00000000892aefc] driver_probe_device+0x15c/0x200
> [c00000000892b63c] device_driver_attach+0xcc/0xe0
> [c00000000892b740] __driver_attach+0xf0/0x200
> [c000000008926f28] bus_for_each_dev+0xa8/0x130
> [c000000008929ce4] driver_attach+0x34/0x50
> [c000000008928fc0] bus_add_driver+0x1b0/0x300
> [c00000000892c798] driver_register+0x98/0x1a0
> [c00000000810eb60] __vio_register_driver+0x80/0xe0
> [c0080000190b4a30] ibmvscsi_module_init+0x9c/0xdc [ibmvscsi]
> [c0000000080121d0] do_one_initcall+0x60/0x2d0
> [c000000008261abc] do_init_module+0x7c/0x320
> [c000000008265700] load_module+0x2350/0x25b0
> [c000000008265cb4] __do_sys_finit_module+0xd4/0x160
> [c000000008031110] system_call_exception+0x150/0x2d0
> [c00000000800d35c] system_call_common+0xec/0x278
> 
> 
> I'm happy to send a fix, but I see two possible approaches.
> 
> 1.) Set shost->ehandler = NULL if kthread_run() fails in scsi_host_alloc()
> 
> or
> 
> 2.) Test that (shost->ehandler && !IS_ERR(shost->ehandler)) before calling
> kthread_stop in scsi_host_dev_release()

Either one looks fine for me, please go ahead to make a patch, and thanks for
the catch!

-- 
Ming


  reply	other threads:[~2021-06-30  0:11 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-02 13:30 [PATCH 0/4] scsi: fix failure handling of alloc/add host Ming Lei
2021-06-02 13:30 ` [PATCH 1/4] scsi: core: fix error handling of scsi_host_alloc Ming Lei
2021-06-03  2:26   ` Bart Van Assche
2021-06-03 15:40   ` John Garry
2021-06-07 11:39   ` Hannes Reinecke
2021-06-29 19:23   ` Tyrel Datwyler
2021-06-30  0:11     ` Ming Lei [this message]
2021-06-02 13:30 ` [PATCH 2/4] scsi: core: fix failure handling of scsi_add_host_with_dma Ming Lei
2021-06-03  2:32   ` Bart Van Assche
2021-06-03 15:40   ` John Garry
2021-06-07 11:37   ` Hannes Reinecke
2021-06-02 13:30 ` [PATCH 3/4] scsi: core: put .shost_dev in failure path if host state becomes running Ming Lei
2021-06-03  3:06   ` Bart Van Assche
2021-06-03  3:22     ` Ming Lei
2021-06-03 15:41   ` John Garry
2021-06-07 11:40   ` Hannes Reinecke
2021-06-02 13:30 ` [PATCH 4/4] scsi: core: only put parent device if host state isn't in SHOST_CREATED Ming Lei
2021-06-03  3:08   ` Bart Van Assche
2021-06-03 15:38   ` John Garry
2021-06-07 11:41   ` Hannes Reinecke
2021-06-07 11:56     ` Ming Lei
2021-06-03 15:43 ` [PATCH 0/4] scsi: fix failure handling of alloc/add host John Garry
2021-06-08  3:04 ` Martin K. Petersen

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=YNu2uZAqrXuMqAFB@T590 \
    --to=ming.lei@redhat.com \
    --cc=bvanassche@acm.org \
    --cc=hare@suse.de \
    --cc=john.garry@huawei.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=tyreld@linux.ibm.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.