libxl: update flex output files

Libxl ships output files from flex (libxlu_*_l.{c,h}). We use the flex
shipped in Debian to generate those files. Debian just patched their
flex (DSA 3653-1) to fix CVE-2016-6354, which is a buffer overrun bug.

Note that libxl is _NOT_ vulnerable to that CVE. See below for Ian's
analysis to security@xen.

It would still be nice that we update our shipped flex output files to
avoid confusion.

===QUOTE===

The bug is that with input >16K[1] flex would usually fail to resize
the input buffer, and then overrun it.

I have read the code in libxlu_cfg_l.c to try to understand the
implications for libxl.

AFAICT
 - libxl always does config file reading _from the file_ itself, and
   provides flex with a string or buffer.
 - so we always call whatever_yy_scan_bytes, not any other flex setup
   function to set up a `buffer' (as flex calls it)
 - yy_scan_bytes calls yy_scan_buffer to set up the buffer
 - yy_scan_buffer sets b->yy_fill_buffer
 - The effect of this is that yy_get_next_buffer will always
   return early, rather than continuing on to the vulnerable code.

So I think libxl is not vulnerable, regardless of the contents of the
configuration file.

[1] the default buffer size, or whatever other buffer size is
configured (but we don't change it)

===ENDQUOTE===

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

tools/libxl/libxlu_cfg_l.c

@@ -1173,7 +1173,7 @@ static int yy_get_next_buffer (yyscan_t yyscanner)
 
 	else
 		{
-			yy_size_t num_to_read =
+			int num_to_read =
 			YY_CURRENT_BUFFER_LVALUE->yy_buf_size - number_to_move - 1;
 
 		while ( num_to_read <= 0 )

tools/libxl/libxlu_disk_l.h

@@ -348,7 +348,7 @@ extern int xlu__disk_yylex (yyscan_t yyscanner);
 #undef YY_DECL
 #endif
 
-#line 258 "libxlu_disk_l.l"
+#line 277 "libxlu_disk_l.l"
 
 #line 354 "libxlu_disk_l.h"
 #undef xlu__disk_yyIN_HEADER