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

Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>

1 files changed, 13 insertions, 2 deletions

diff --git a/networking/udhcp/common.c b/networking/udhcp/common.c
index bc41c8d4d..680852ce4 100644
--- a/networking/udhcp/common.c
+++ b/networking/udhcp/common.c
@@ -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).
+         */
 };