Description of problem: blkid crashes on a server with more than 128 storage devices Version-Release number of selected component (if applicable): upstream How reproducible: always Steps to Reproduce: 1.blkid -c /dev/<list of storage device, more than 128> Actual results: craash Expected results: should'nt crash Additional info: $ vim e2fsprogs-1.39/misc/blkid.c 92 int main(int argc, char **argv) 93 { 94 blkid_cache cache = NULL; 95 char *devices[128] = { NULL, }; 96 char *show[128] = { NULL, }; <--- bad mojo, 128 device artificial limit. 97 char *search_type = NULL, *search_value = NULL; 98 char *read = NULL; update the limit to a higher value ( say 8192) as shown below 95 char *devices[8192] = { NULL, }; 96 char *show[8192] = { NULL, };
Yep, that's no good. We'll need something more flexible than just increasing the artificial limit, though.
I've sent a patch upstream (to util-linux-ng) for this, and kzak committed it. Once it shows up in git I'll pull it back & put it into rhel5. Also, will dup this to rhel6. The "show" array is OK, because: case 's': if (numtag + 1 >= sizeof(show) / sizeof(*show)) { fprintf(stderr, "Too many tags specified\n"); usage(err); } show[numtag++] = optarg; show[numtag] = NULL; break; if the index grows past the size of the array, it will error out.
From: Eric Sandeen <sandeen> Date: Tue, 8 Feb 2011 05:44:26 +0000 (-0600) Subject: blkid: dynamically allocate devicename array X-Git-Url: http://git.kernel.org/?p=utils%2Futil-linux%2Futil-linux.git;a=commitdiff_plain;h=ea51c09c11f7110eca54fa35ab5ac51a7635c8c2 blkid: dynamically allocate devicename array If more than 128 devices are specified on the blkid cmdline, the devices[] array will overflow. We can dynamically allocate the devices[] array based on number of arguments to avoid this problem. [kzak: - add "if (optind < argc)" check] Signed-off-by: Eric Sandeen <sandeen> Signed-off-by: Karel Zak <kzak> ---
Built & tagged in e2fsprogs-1.39-30.el5
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-1080.html