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] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 4 Jun 2021 07:52:35 -0700
From:   Bart Van Assche <bvanassche@....org>
To:     Changheun Lee <nanich.lee@...sung.com>, damien.lemoal@....com
Cc:     Avri.Altman@....com, Johannes.Thumshirn@....com,
        alex_y_xu@...oo.ca, alim.akhtar@...sung.com,
        asml.silence@...il.com, axboe@...nel.dk, bgoncalv@...hat.com,
        cang@...eaurora.org, gregkh@...uxfoundation.org, hch@...radead.org,
        jaegeuk@...nel.org, jejb@...ux.ibm.com, jisoo2146.oh@...sung.com,
        junho89.kim@...sung.com, linux-block@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org,
        martin.petersen@...cle.com, ming.lei@...hat.com,
        mj0123.lee@...sung.com, osandov@...com, patchwork-bot@...nel.org,
        seunghwan.hyun@...sung.com, sookwan7.kim@...sung.com,
        tj@...nel.org, tom.leiming@...il.com, woosung2.lee@...sung.com,
        yi.zhang@...hat.com, yt0928.kim@...sung.com
Subject: Re: [PATCH v12 1/3] bio: control bio max size

On 6/4/21 12:34 AM, Changheun Lee wrote:
>> On 2021/06/04 14:22, Changheun Lee wrote:
>>> +unsigned int bio_max_bytes(struct bio *bio)
>>> +{
>>> +	struct block_device *bdev = bio->bi_bdev;
>>> +
>>> +	return bdev ? bdev->bd_disk->queue->limits.max_bio_bytes : UINT_MAX;
>>> +}
>>
>> unsigned int bio_max_bytes(struct bio *bio)
>> {
>> 	struct block_device *bdev = bio->bi_bdev;
>>
>> 	if (!bdev)
>> 		return UINT_MAX;
>> 	return bdev->bd_disk->queue->limits.max_bio_bytes;
>> }
>>
>> is a lot more readable...
>> Also, I remember there was some problems with bd_disk possibly being null. Was
>> that fixed ?
> 
> Thank you for review. But I'd like current style, and it's readable enough
> now I think. Null of bd_disk was just suspicion. bd_disk is not null if bdev
> is not null.
 Damien is right. bd_disk can be NULL. From
https://lore.kernel.org/linux-block/20210425043020.30065-1-bvanassche@acm.org/:
"bio_max_size() may get called before device_add_disk() and hence needs to
check whether or not the block device pointer is NULL. [ ... ]
This patch prevents that bio_max_size() triggers the following kernel
crash during a SCSI LUN scan:\
BUG: KASAN: null-ptr-deref in bio_add_hw_page+0xa6/0x310
Read of size 8 at addr 00000000000005a8 by task kworker/u16:0/7
Workqueue: events_unbound async_run_entry_fn
Call Trace:
 show_stack+0x52/0x58
 dump_stack+0x9d/0xcf
 kasan_report.cold+0x4b/0x50
 __asan_load8+0x69/0x90
 bio_add_hw_page+0xa6/0x310
 bio_add_pc_page+0xaa/0xe0
 bio_map_kern+0xdc/0x1a0
 blk_rq_map_kern+0xcd/0x2d0
 __scsi_execute+0x9a/0x290 [scsi_mod]
 scsi_probe_lun.constprop.0+0x17c/0x660 [scsi_mod]
 scsi_probe_and_add_lun+0x178/0x750 [scsi_mod]
 __scsi_add_device+0x18c/0x1a0 [scsi_mod]
 ata_scsi_scan_host+0xe5/0x260 [libata]
 async_port_probe+0x94/0xb0 [libata]
 async_run_entry_fn+0x7d/0x2d0
 process_one_work+0x582/0xac0
 worker_thread+0x8f/0x5a0
 kthread+0x222/0x250
 ret_from_fork+0x1f/0x30"

Bart.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ