| Message ID | 20170830122106.dmdfril4kwi4p5e5@mwanda (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
On Wed, Aug 30, 2017 at 08:28:52PM +0800, shqking wrote: > Hi, > > Glad to see it is fixed. > > Can I apply for a CVE ID for this bug? > We don't handle that on this list. You'd need to ask on oss-security@lists.openwall.com. regards, dan carpenter
On Wed, Aug 30, 2017 at 03:21:07PM +0300, Dan Carpenter wrote: > The value of "size" comes from the user. When we add "start + size" > it could lead to an integer overflow bug. > > It means we vmalloc() a lot more memory than we had intended. I believe > that on 64 bit systems vmalloc() can succeed even if we ask it to > allocate huge 4GB buffers. So we would get memory corruption and likely > a crash when we call ha->isp_ops->write_optrom() and ->read_optrom(). > > Only root can trigger this bug. > > Fixes: b7cc176c9eb3 ("[SCSI] qla2xxx: Allow region-based flash-part accesses.") > Reported-by: shqking <shqking@gmail.com> > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: stable <stable@vger.kernel.org> perhaps? thanks, greg k-h
On Wed, Aug 30, 2017 at 6:12 AM, Greg KH <greg@kroah.com> wrote: > On Wed, Aug 30, 2017 at 03:21:07PM +0300, Dan Carpenter wrote: >> The value of "size" comes from the user. When we add "start + size" >> it could lead to an integer overflow bug. >> >> It means we vmalloc() a lot more memory than we had intended. I believe >> that on 64 bit systems vmalloc() can succeed even if we ask it to >> allocate huge 4GB buffers. So we would get memory corruption and likely >> a crash when we call ha->isp_ops->write_optrom() and ->read_optrom(). >> >> Only root can trigger this bug. >> >> Fixes: b7cc176c9eb3 ("[SCSI] qla2xxx: Allow region-based flash-part accesses.") >> Reported-by: shqking <shqking@gmail.com> >> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> > > > Cc: stable <stable@vger.kernel.org> > > perhaps? > > thanks, > > greg k-h Also a link to https://bugzilla.kernel.org/show_bug.cgi?id=194061 since shqking did a fair bit of analysis, not only report the bug. Thanks.
diff --git a/drivers/scsi/qla2xxx/qla_attr.c b/drivers/scsi/qla2xxx/qla_attr.c index 75c4b312645e..9ce28c4f9812 100644 --- a/drivers/scsi/qla2xxx/qla_attr.c +++ b/drivers/scsi/qla2xxx/qla_attr.c @@ -318,6 +318,8 @@ qla2x00_sysfs_write_optrom_ctl(struct file *filp, struct kobject *kobj, return -EINVAL; if (start > ha->optrom_size) return -EINVAL; + if (size > ha->optrom_size - start) + size = ha->optrom_size - start; mutex_lock(&ha->optrom_mutex); switch (val) { @@ -343,8 +345,7 @@ qla2x00_sysfs_write_optrom_ctl(struct file *filp, struct kobject *kobj, } ha->optrom_region_start = start; - ha->optrom_region_size = start + size > ha->optrom_size ? - ha->optrom_size - start : size; + ha->optrom_region_size = start + size; ha->optrom_state = QLA_SREADING; ha->optrom_buffer = vmalloc(ha->optrom_region_size); @@ -417,8 +418,7 @@ qla2x00_sysfs_write_optrom_ctl(struct file *filp, struct kobject *kobj, } ha->optrom_region_start = start; - ha->optrom_region_size = start + size > ha->optrom_size ? - ha->optrom_size - start : size; + ha->optrom_region_size = start + size; ha->optrom_state = QLA_SWRITING; ha->optrom_buffer = vmalloc(ha->optrom_region_size);
The value of "size" comes from the user. When we add "start + size" it could lead to an integer overflow bug. It means we vmalloc() a lot more memory than we had intended. I believe that on 64 bit systems vmalloc() can succeed even if we ask it to allocate huge 4GB buffers. So we would get memory corruption and likely a crash when we call ha->isp_ops->write_optrom() and ->read_optrom(). Only root can trigger this bug. Fixes: b7cc176c9eb3 ("[SCSI] qla2xxx: Allow region-based flash-part accesses.") Reported-by: shqking <shqking@gmail.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>