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).
+	 */
 };