| Message ID | 20210226144144.9252-7-nmanthey@amazon.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Code analysis fixes | expand |
On 26/02/2021 14:41, Norbert Manthey wrote: > The read value could be larger than a signed 32bit integer. As -1 is > used as error value, we should not rely on using the full 32 bits. > Hence, when reading the port number, we should make sure we only return > valid values. > > This change sanity checks the input. > The issue is that the value for the port is > 1. transmitted as a string, with a fixed amount of digits. > 2. Next, this string is parsed by a function that can deal with strings > representing 64bit integers > 3. A 64bit integer is returned, and will be truncated to it's lower > 32bits, resulting in a wrong port number (in case the sender of the > string decides to craft a suitable 64bit value). > > The value is typically provided by the kernel, which has this value hard > coded in the proper range. As we use the function strtoul, non-digit > character are considered as end of the input, and hence do not require > checking. Therefore, this change only covers the corner case to make > sure we stay in the 32 bit range. > > This bug was discovered and resolved using Coverity Static Analysis > Security Testing (SAST) by Synopsys, Inc. > > Signed-off-by: Norbert Manthey <nmanthey@amazon.de> > Reviewed-by: Thomas Friebel <friebelt@amazon.de> > Reviewed-by: Julien Grall <jgrall@amazon.co.uk> Port numbers are currently limited at 2^17, with easy extension to 2^29 (iirc), but the entire event channel infrastructure would have to undergo another redesign to get beyond that. I think we can reasonably make an ABI statement saying that a port number will never exceed 2^31. This is already pseudo-encoded in the evtchn_port_or_error_t mouthful. ~Andrew
On 26.02.21 16:36, Andrew Cooper wrote: > On 26/02/2021 14:41, Norbert Manthey wrote: >> The read value could be larger than a signed 32bit integer. As -1 is >> used as error value, we should not rely on using the full 32 bits. >> Hence, when reading the port number, we should make sure we only return >> valid values. >> >> This change sanity checks the input. >> The issue is that the value for the port is >> 1. transmitted as a string, with a fixed amount of digits. >> 2. Next, this string is parsed by a function that can deal with strings >> representing 64bit integers >> 3. A 64bit integer is returned, and will be truncated to it's lower >> 32bits, resulting in a wrong port number (in case the sender of the >> string decides to craft a suitable 64bit value). >> >> The value is typically provided by the kernel, which has this value hard >> coded in the proper range. As we use the function strtoul, non-digit >> character are considered as end of the input, and hence do not require >> checking. Therefore, this change only covers the corner case to make >> sure we stay in the 32 bit range. >> >> This bug was discovered and resolved using Coverity Static Analysis >> Security Testing (SAST) by Synopsys, Inc. >> >> Signed-off-by: Norbert Manthey <nmanthey@amazon.de> >> Reviewed-by: Thomas Friebel <friebelt@amazon.de> >> Reviewed-by: Julien Grall <jgrall@amazon.co.uk> > > Port numbers are currently limited at 2^17, with easy extension to 2^29 > (iirc), but the entire event channel infrastructure would have to > undergo another redesign to get beyond that. > > I think we can reasonably make an ABI statement saying that a port > number will never exceed 2^31. This is already pseudo-encoded in the > evtchn_port_or_error_t mouthful. I agree. There is no need for this patch. Juergen
On 3/2/21 6:15 AM, Jürgen Groß wrote: > On 26.02.21 16:36, Andrew Cooper wrote: >> On 26/02/2021 14:41, Norbert Manthey wrote: >>> The read value could be larger than a signed 32bit integer. As -1 is >>> used as error value, we should not rely on using the full 32 bits. >>> Hence, when reading the port number, we should make sure we only return >>> valid values. >>> >>> This change sanity checks the input. >>> The issue is that the value for the port is >>> 1. transmitted as a string, with a fixed amount of digits. >>> 2. Next, this string is parsed by a function that can deal with >>> strings >>> representing 64bit integers >>> 3. A 64bit integer is returned, and will be truncated to it's lower >>> 32bits, resulting in a wrong port number (in case the sender of >>> the >>> string decides to craft a suitable 64bit value). >>> >>> The value is typically provided by the kernel, which has this value >>> hard >>> coded in the proper range. As we use the function strtoul, non-digit >>> character are considered as end of the input, and hence do not require >>> checking. Therefore, this change only covers the corner case to make >>> sure we stay in the 32 bit range. >>> >>> This bug was discovered and resolved using Coverity Static Analysis >>> Security Testing (SAST) by Synopsys, Inc. >>> >>> Signed-off-by: Norbert Manthey <nmanthey@amazon.de> >>> Reviewed-by: Thomas Friebel <friebelt@amazon.de> >>> Reviewed-by: Julien Grall <jgrall@amazon.co.uk> >> >> Port numbers are currently limited at 2^17, with easy extension to 2^29 >> (iirc), but the entire event channel infrastructure would have to >> undergo another redesign to get beyond that. >> >> I think we can reasonably make an ABI statement saying that a port >> number will never exceed 2^31. This is already pseudo-encoded in the >> evtchn_port_or_error_t mouthful. > > I agree. There is no need for this patch. I understand, and am fine with dropping this patch. Out of curiosity, if the actual limit is lower than what the patch currently enforces, would it make sense to adapt the bound check to that number? Best, Norbert > > > Juergen > Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879
On 02.03.21 08:48, Norbert Manthey wrote: > On 3/2/21 6:15 AM, Jürgen Groß wrote: >> On 26.02.21 16:36, Andrew Cooper wrote: >>> On 26/02/2021 14:41, Norbert Manthey wrote: >>>> The read value could be larger than a signed 32bit integer. As -1 is >>>> used as error value, we should not rely on using the full 32 bits. >>>> Hence, when reading the port number, we should make sure we only return >>>> valid values. >>>> >>>> This change sanity checks the input. >>>> The issue is that the value for the port is >>>> 1. transmitted as a string, with a fixed amount of digits. >>>> 2. Next, this string is parsed by a function that can deal with >>>> strings >>>> representing 64bit integers >>>> 3. A 64bit integer is returned, and will be truncated to it's lower >>>> 32bits, resulting in a wrong port number (in case the sender of >>>> the >>>> string decides to craft a suitable 64bit value). >>>> >>>> The value is typically provided by the kernel, which has this value >>>> hard >>>> coded in the proper range. As we use the function strtoul, non-digit >>>> character are considered as end of the input, and hence do not require >>>> checking. Therefore, this change only covers the corner case to make >>>> sure we stay in the 32 bit range. >>>> >>>> This bug was discovered and resolved using Coverity Static Analysis >>>> Security Testing (SAST) by Synopsys, Inc. >>>> >>>> Signed-off-by: Norbert Manthey <nmanthey@amazon.de> >>>> Reviewed-by: Thomas Friebel <friebelt@amazon.de> >>>> Reviewed-by: Julien Grall <jgrall@amazon.co.uk> >>> >>> Port numbers are currently limited at 2^17, with easy extension to 2^29 >>> (iirc), but the entire event channel infrastructure would have to >>> undergo another redesign to get beyond that. >>> >>> I think we can reasonably make an ABI statement saying that a port >>> number will never exceed 2^31. This is already pseudo-encoded in the >>> evtchn_port_or_error_t mouthful. >> >> I agree. There is no need for this patch. > > I understand, and am fine with dropping this patch. > > Out of curiosity, if the actual limit is lower than what the patch > currently enforces, would it make sense to adapt the bound check to that > number? No, I don't think so. Especially as the boundary to check against isn't known by Xenstore (the boundary value depends on 2-level or fifo events being used, and this information is not exported to user land). The value is coming from the kernel, and it is used with another kernel interface. So if the kernel wants to play dirty tricks with Xenstore, it doesn't need to deliver a wrong event channel number, it can just play those games in the event channel driver. Juergen
diff --git a/tools/xenstore/xenstored_posix.c b/tools/xenstore/xenstored_posix.c --- a/tools/xenstore/xenstored_posix.c +++ b/tools/xenstore/xenstored_posix.c @@ -116,7 +116,7 @@ evtchn_port_t xenbus_evtchn(void) { int fd; int rc; - evtchn_port_t port; + uint64_t port; char str[20]; fd = open(XENSTORED_PORT_DEV, O_RDONLY); @@ -136,6 +136,10 @@ evtchn_port_t xenbus_evtchn(void) port = strtoul(str, NULL, 0); close(fd); + + if (port >= UINT32_MAX) + return -1; + return port; }
The read value could be larger than a signed 32bit integer. As -1 is used as error value, we should not rely on using the full 32 bits. Hence, when reading the port number, we should make sure we only return valid values. This change sanity checks the input. The issue is that the value for the port is 1. transmitted as a string, with a fixed amount of digits. 2. Next, this string is parsed by a function that can deal with strings representing 64bit integers 3. A 64bit integer is returned, and will be truncated to it's lower 32bits, resulting in a wrong port number (in case the sender of the string decides to craft a suitable 64bit value). The value is typically provided by the kernel, which has this value hard coded in the proper range. As we use the function strtoul, non-digit character are considered as end of the input, and hence do not require checking. Therefore, this change only covers the corner case to make sure we stay in the 32 bit range. This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc. Signed-off-by: Norbert Manthey <nmanthey@amazon.de> Reviewed-by: Thomas Friebel <friebelt@amazon.de> Reviewed-by: Julien Grall <jgrall@amazon.co.uk> --- tools/xenstore/xenstored_posix.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)