| Message ID | 20210310223021.423155-1-tyreld@linux.ibm.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Bjorn Helgaas |
| Headers | show |
| Series | rpadlpar: fix potential drc_name corruption in store functions | expand |
On Wed, Mar 10, 2021 at 04:30:21PM -0600, Tyrel Datwyler wrote: > Both add_slot_store() and remove_slot_store() try to fix up the drc_name > copied from the store buffer by placing a NULL terminator at nbyte + 1 > or in place of a '\n' if present. However, the static buffer that we > copy the drc_name data into is not zeored and can contain anything past > the n-th byte. This is problematic if a '\n' byte appears in that buffer > after nbytes and the string copied into the store buffer was not NULL > terminated to start with as the strchr() search for a '\n' byte will mark > this incorrectly as the end of the drc_name string resulting in a drc_name > string that contains garbage data after the n-th byte. The following > debugging shows an example of the drmgr utility writing "PHB 4543" to > the add_slot sysfs attribute, but add_slot_store logging a corrupted > string value. > > [135823.702864] drmgr: drmgr: -c phb -a -s PHB 4543 -d 1 > [135823.702879] add_slot_store: drc_name = PHB 4543°|<82>!, rc = -19 > > Fix this by NULL terminating the string when we copy it into our static > buffer by coping nbytes + 1 of data from the store buffer. The code has Why is it OK to copy nbytes + 1 and why is it expected that the buffer contains a nul after the content? Isn't it much saner to just nul terminate the string after copying? diff --git a/drivers/pci/hotplug/rpadlpar_sysfs.c b/drivers/pci/hotplug/rpadlpar_sysfs.c index cdbfa5df3a51..cfbad67447da 100644 --- a/drivers/pci/hotplug/rpadlpar_sysfs.c +++ b/drivers/pci/hotplug/rpadlpar_sysfs.c @@ -35,11 +35,11 @@ static ssize_t add_slot_store(struct kobject *kobj, struct kobj_attribute *attr, return 0; memcpy(drc_name, buf, nbytes); + &drc_name[nbytes] = '\0'; end = strchr(drc_name, '\n'); - if (!end) - end = &drc_name[nbytes]; - *end = '\0'; + if (end) + *end = '\0'; rc = dlpar_add_slot(drc_name); if (rc) @@ -66,11 +66,11 @@ static ssize_t remove_slot_store(struct kobject *kobj, return 0; memcpy(drc_name, buf, nbytes); + &drc_name[nbytes] = '\0'; end = strchr(drc_name, '\n'); - if (!end) - end = &drc_name[nbytes]; - *end = '\0'; + if (end) + *end = '\0'; rc = dlpar_remove_slot(drc_name); if (rc) Thanks Michal > already made sure that nbytes is not >= MAX_DRC_NAME_LEN and the store > buffer is guaranteed to be zeroed beyond the nth-byte of data copied > from the user. Further, since the string is now NULL terminated the code > only needs to change '\n' to '\0' when present. > > Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com> > --- > drivers/pci/hotplug/rpadlpar_sysfs.c | 14 ++++++-------- > 1 file changed, 6 insertions(+), 8 deletions(-) > > diff --git a/drivers/pci/hotplug/rpadlpar_sysfs.c b/drivers/pci/hotplug/rpadlpar_sysfs.c > index cdbfa5df3a51..375087921284 100644 > --- a/drivers/pci/hotplug/rpadlpar_sysfs.c > +++ b/drivers/pci/hotplug/rpadlpar_sysfs.c > @@ -34,12 +34,11 @@ static ssize_t add_slot_store(struct kobject *kobj, struct kobj_attribute *attr, > if (nbytes >= MAX_DRC_NAME_LEN) > return 0; > > - memcpy(drc_name, buf, nbytes); > + memcpy(drc_name, buf, nbytes + 1); > > end = strchr(drc_name, '\n'); > - if (!end) > - end = &drc_name[nbytes]; > - *end = '\0'; > + if (end) > + *end = '\0'; > > rc = dlpar_add_slot(drc_name); > if (rc) > @@ -65,12 +64,11 @@ static ssize_t remove_slot_store(struct kobject *kobj, > if (nbytes >= MAX_DRC_NAME_LEN) > return 0; > > - memcpy(drc_name, buf, nbytes); > + memcpy(drc_name, buf, nbytes + 1); > > end = strchr(drc_name, '\n'); > - if (!end) > - end = &drc_name[nbytes]; > - *end = '\0'; > + if (end) > + *end = '\0'; > > rc = dlpar_remove_slot(drc_name); > if (rc) > -- > 2.27.0 >
On 3/13/21 1:17 AM, Michal Suchánek wrote: > On Wed, Mar 10, 2021 at 04:30:21PM -0600, Tyrel Datwyler wrote: >> Both add_slot_store() and remove_slot_store() try to fix up the drc_name >> copied from the store buffer by placing a NULL terminator at nbyte + 1 >> or in place of a '\n' if present. However, the static buffer that we >> copy the drc_name data into is not zeored and can contain anything past >> the n-th byte. This is problematic if a '\n' byte appears in that buffer >> after nbytes and the string copied into the store buffer was not NULL >> terminated to start with as the strchr() search for a '\n' byte will mark >> this incorrectly as the end of the drc_name string resulting in a drc_name >> string that contains garbage data after the n-th byte. The following >> debugging shows an example of the drmgr utility writing "PHB 4543" to >> the add_slot sysfs attribute, but add_slot_store logging a corrupted >> string value. >> >> [135823.702864] drmgr: drmgr: -c phb -a -s PHB 4543 -d 1 >> [135823.702879] add_slot_store: drc_name = PHB 4543°|<82>!, rc = -19 >> >> Fix this by NULL terminating the string when we copy it into our static >> buffer by coping nbytes + 1 of data from the store buffer. The code has > Why is it OK to copy nbytes + 1 and why is it expected that the buffer > contains a nul after the content? It is my understanding that the store function buffer is allocated as a zeroed-page which the kernel copies up to at most (PAGE_SIZE - 1) of user data into. Anything after nbytes would therefore be zeroed. > > Isn't it much saner to just nul terminate the string after copying? At the cost of an extra line of code, sure. -Tyrel > > diff --git a/drivers/pci/hotplug/rpadlpar_sysfs.c b/drivers/pci/hotplug/rpadlpar_sysfs.c > index cdbfa5df3a51..cfbad67447da 100644 > --- a/drivers/pci/hotplug/rpadlpar_sysfs.c > +++ b/drivers/pci/hotplug/rpadlpar_sysfs.c > @@ -35,11 +35,11 @@ static ssize_t add_slot_store(struct kobject *kobj, struct kobj_attribute *attr, > return 0; > > memcpy(drc_name, buf, nbytes); > + &drc_name[nbytes] = '\0'; > > end = strchr(drc_name, '\n'); > - if (!end) > - end = &drc_name[nbytes]; > - *end = '\0'; > + if (end) > + *end = '\0'; > > rc = dlpar_add_slot(drc_name); > if (rc) > @@ -66,11 +66,11 @@ static ssize_t remove_slot_store(struct kobject *kobj, > return 0; > > memcpy(drc_name, buf, nbytes); > + &drc_name[nbytes] = '\0'; > > end = strchr(drc_name, '\n'); > - if (!end) > - end = &drc_name[nbytes]; > - *end = '\0'; > + if (end) > + *end = '\0'; > > rc = dlpar_remove_slot(drc_name); > if (rc) > > Thanks > > Michal > >> already made sure that nbytes is not >= MAX_DRC_NAME_LEN and the store >> buffer is guaranteed to be zeroed beyond the nth-byte of data copied >> from the user. Further, since the string is now NULL terminated the code >> only needs to change '\n' to '\0' when present. >> >> Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com> >> --- >> drivers/pci/hotplug/rpadlpar_sysfs.c | 14 ++++++-------- >> 1 file changed, 6 insertions(+), 8 deletions(-) >> >> diff --git a/drivers/pci/hotplug/rpadlpar_sysfs.c b/drivers/pci/hotplug/rpadlpar_sysfs.c >> index cdbfa5df3a51..375087921284 100644 >> --- a/drivers/pci/hotplug/rpadlpar_sysfs.c >> +++ b/drivers/pci/hotplug/rpadlpar_sysfs.c >> @@ -34,12 +34,11 @@ static ssize_t add_slot_store(struct kobject *kobj, struct kobj_attribute *attr, >> if (nbytes >= MAX_DRC_NAME_LEN) >> return 0; >> >> - memcpy(drc_name, buf, nbytes); >> + memcpy(drc_name, buf, nbytes + 1); >> >> end = strchr(drc_name, '\n'); >> - if (!end) >> - end = &drc_name[nbytes]; >> - *end = '\0'; >> + if (end) >> + *end = '\0'; >> >> rc = dlpar_add_slot(drc_name); >> if (rc) >> @@ -65,12 +64,11 @@ static ssize_t remove_slot_store(struct kobject *kobj, >> if (nbytes >= MAX_DRC_NAME_LEN) >> return 0; >> >> - memcpy(drc_name, buf, nbytes); >> + memcpy(drc_name, buf, nbytes + 1); >> >> end = strchr(drc_name, '\n'); >> - if (!end) >> - end = &drc_name[nbytes]; >> - *end = '\0'; >> + if (end) >> + *end = '\0'; >> >> rc = dlpar_remove_slot(drc_name); >> if (rc) >> -- >> 2.27.0 >>
Tyrel Datwyler <tyreld@linux.ibm.com> writes: > On 3/13/21 1:17 AM, Michal Suchánek wrote: >> On Wed, Mar 10, 2021 at 04:30:21PM -0600, Tyrel Datwyler wrote: >>> Both add_slot_store() and remove_slot_store() try to fix up the drc_name >>> copied from the store buffer by placing a NULL terminator at nbyte + 1 >>> or in place of a '\n' if present. However, the static buffer that we >>> copy the drc_name data into is not zeored and can contain anything past >>> the n-th byte. This is problematic if a '\n' byte appears in that buffer >>> after nbytes and the string copied into the store buffer was not NULL >>> terminated to start with as the strchr() search for a '\n' byte will mark >>> this incorrectly as the end of the drc_name string resulting in a drc_name >>> string that contains garbage data after the n-th byte. The following >>> debugging shows an example of the drmgr utility writing "PHB 4543" to >>> the add_slot sysfs attribute, but add_slot_store logging a corrupted >>> string value. >>> >>> [135823.702864] drmgr: drmgr: -c phb -a -s PHB 4543 -d 1 >>> [135823.702879] add_slot_store: drc_name = PHB 4543°|<82>!, rc = -19 >>> >>> Fix this by NULL terminating the string when we copy it into our static >>> buffer by coping nbytes + 1 of data from the store buffer. The code has >> Why is it OK to copy nbytes + 1 and why is it expected that the buffer >> contains a nul after the content? > > It is my understanding that the store function buffer is allocated as a > zeroed-page which the kernel copies up to at most (PAGE_SIZE - 1) of user data > into. Anything after nbytes would therefore be zeroed. I think that's true, but it would be nice if we didn't have to rely on that obscure detail in order for this code to be correct & understandable. >> Isn't it much saner to just nul terminate the string after copying? > > At the cost of an extra line of code, sure. Is there a reason we can't use strscpy()? That should deal with all the corner cases around the string copy, and then all you have to do is look for a newline and turn it into nul. cheers
On 3/14/21 7:52 PM, Michael Ellerman wrote: > Tyrel Datwyler <tyreld@linux.ibm.com> writes: >> On 3/13/21 1:17 AM, Michal Suchánek wrote: >>> On Wed, Mar 10, 2021 at 04:30:21PM -0600, Tyrel Datwyler wrote: >>>> Both add_slot_store() and remove_slot_store() try to fix up the drc_name >>>> copied from the store buffer by placing a NULL terminator at nbyte + 1 >>>> or in place of a '\n' if present. However, the static buffer that we >>>> copy the drc_name data into is not zeored and can contain anything past >>>> the n-th byte. This is problematic if a '\n' byte appears in that buffer >>>> after nbytes and the string copied into the store buffer was not NULL >>>> terminated to start with as the strchr() search for a '\n' byte will mark >>>> this incorrectly as the end of the drc_name string resulting in a drc_name >>>> string that contains garbage data after the n-th byte. The following >>>> debugging shows an example of the drmgr utility writing "PHB 4543" to >>>> the add_slot sysfs attribute, but add_slot_store logging a corrupted >>>> string value. >>>> >>>> [135823.702864] drmgr: drmgr: -c phb -a -s PHB 4543 -d 1 >>>> [135823.702879] add_slot_store: drc_name = PHB 4543°|<82>!, rc = -19 >>>> >>>> Fix this by NULL terminating the string when we copy it into our static >>>> buffer by coping nbytes + 1 of data from the store buffer. The code has >>> Why is it OK to copy nbytes + 1 and why is it expected that the buffer >>> contains a nul after the content? >> >> It is my understanding that the store function buffer is allocated as a >> zeroed-page which the kernel copies up to at most (PAGE_SIZE - 1) of user data >> into. Anything after nbytes would therefore be zeroed. > > I think that's true, but it would be nice if we didn't have to rely on > that obscure detail in order for this code to be correct & understandable. I think its a security guarantee, but I guess barring a comment that explicitly outlines the correctness it probably isn't obvious. > >>> Isn't it much saner to just nul terminate the string after copying? >> >> At the cost of an extra line of code, sure. > > Is there a reason we can't use strscpy()? That should deal with all the > corner cases around the string copy, and then all you have to do is look > for a newline and turn it into nul. Fine with me. I'll spin v2 with strscpy(). -Tyrel > > cheers >
diff --git a/drivers/pci/hotplug/rpadlpar_sysfs.c b/drivers/pci/hotplug/rpadlpar_sysfs.c index cdbfa5df3a51..375087921284 100644 --- a/drivers/pci/hotplug/rpadlpar_sysfs.c +++ b/drivers/pci/hotplug/rpadlpar_sysfs.c @@ -34,12 +34,11 @@ static ssize_t add_slot_store(struct kobject *kobj, struct kobj_attribute *attr, if (nbytes >= MAX_DRC_NAME_LEN) return 0; - memcpy(drc_name, buf, nbytes); + memcpy(drc_name, buf, nbytes + 1); end = strchr(drc_name, '\n'); - if (!end) - end = &drc_name[nbytes]; - *end = '\0'; + if (end) + *end = '\0'; rc = dlpar_add_slot(drc_name); if (rc) @@ -65,12 +64,11 @@ static ssize_t remove_slot_store(struct kobject *kobj, if (nbytes >= MAX_DRC_NAME_LEN) return 0; - memcpy(drc_name, buf, nbytes); + memcpy(drc_name, buf, nbytes + 1); end = strchr(drc_name, '\n'); - if (!end) - end = &drc_name[nbytes]; - *end = '\0'; + if (end) + *end = '\0'; rc = dlpar_remove_slot(drc_name); if (rc)
Both add_slot_store() and remove_slot_store() try to fix up the drc_name copied from the store buffer by placing a NULL terminator at nbyte + 1 or in place of a '\n' if present. However, the static buffer that we copy the drc_name data into is not zeored and can contain anything past the n-th byte. This is problematic if a '\n' byte appears in that buffer after nbytes and the string copied into the store buffer was not NULL terminated to start with as the strchr() search for a '\n' byte will mark this incorrectly as the end of the drc_name string resulting in a drc_name string that contains garbage data after the n-th byte. The following debugging shows an example of the drmgr utility writing "PHB 4543" to the add_slot sysfs attribute, but add_slot_store logging a corrupted string value. [135823.702864] drmgr: drmgr: -c phb -a -s PHB 4543 -d 1 [135823.702879] add_slot_store: drc_name = PHB 4543°|<82>!, rc = -19 Fix this by NULL terminating the string when we copy it into our static buffer by coping nbytes + 1 of data from the store buffer. The code has already made sure that nbytes is not >= MAX_DRC_NAME_LEN and the store buffer is guaranteed to be zeroed beyond the nth-byte of data copied from the user. Further, since the string is now NULL terminated the code only needs to change '\n' to '\0' when present. Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com> --- drivers/pci/hotplug/rpadlpar_sysfs.c | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-)