emo/busybox
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

udhcpc: fix OPTION_6RD parsing (could overflow its malloced buffer)

Browse Source 
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
This commit is contained in:
Denys Vlasenko
2016-02-26 15:54:56 +01:00
parent 5bec08cebd
commit 352f79acbd
2 changed files with 15 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
networking/udhcp/common.c
View File

@ -142,7 +142,7 @@ const char dhcp_option_strings[] ALIGN1 =
* udhcp_str2optset: to determine how many bytes to allocate.
* xmalloc_optname_optval: to estimate string length
* from binary option length: (option[LEN] / dhcp_option_lengths[opt_type])
* is the number of elements, multiply in by one element's string width
* is the number of elements, multiply it by one element's string width
* (len_of_option_as_string[opt_type]) and you know how wide string you need.
*/
const uint8_t dhcp_option_lengths[] ALIGN1 = {
@ -162,7 +162,18 @@ const uint8_t dhcp_option_lengths[] ALIGN1 = {
[OPTION_S32] = 4,
/* Just like OPTION_STRING, we use minimum length here */
[OPTION_STATIC_ROUTES] = 5,
[OPTION_6RD] = 22, /* ignored by udhcp_str2optset */
[OPTION_6RD] = 12, /* ignored by udhcp_str2optset */
/* The above value was chosen as follows:
* len_of_option_as_string[] for this option is >60: it's a string of the form
* "32 128 ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff 255.255.255.255 ".
* Each additional ipv4 address takes 4 bytes in binary option and appends
* another "255.255.255.255 " 16-byte string. We can set [OPTION_6RD] = 4
* but this severely overestimates string length: instead of 16 bytes,
* it adds >60 for every 4 bytes in binary option.
* We cheat and declare here that option is in units of 12 bytes.
* This adds more than 60 bytes for every three ipv4 addresses - more than enough.
* (Even 16 instead of 12 should work, but let's be paranoid).
*/
};