203777 2007-12-30 14:49 0000 dev-libs/libcdio < 0.78.2-r4 Buffer overflow via long filename in Joliet (CVE-2007-6613) 2008-01-20 00:44:34 0000 1 1 1 Unclassified Gentoo Security Vulnerabilities unspecified All Linux RESOLVED FIXED http://savannah.gnu.org/bugs/?21910 B2 [glsa] P2 normal --- 1 devon.miller@verizon.net security@gentoo.org arm@gentoo.org devon.miller@verizon.net flameeyes@gentoo.org lars@chaotika.org media-video@gentoo.org devon.miller@verizon.net 2007-12-30 14:49:01 0000 dev-libs/libcdio-0.78.2 provides iso-info and cd-info both exhibit this vulnerability. A properly formatted iso image can produce a coredump and may allow for malicious code injection. Reproducible: Always Steps to Reproduce: 1. mkdir -p tmp/dir1 2. echo file_with_really_really_long_silly_name_to_test_iso_info_buffer 3. mkisofs -J -R -volid My_Image -o test.iso tmp 4. iso-info -l test.iso Actual Results: iso-info lists files and directories up to the ver long file name at which point it segfaults. Expected Results: a listing of the directories in src/iso-info.c, in function "print_iso9660_recurse" there is a block of code that begins: _CDIO_LIST_FOREACH (entnode, entlist) { iso9660_stat_t *p_statbuf = _cdio_list_node_data (entnode); char *psz_iso_name = p_statbuf->filename; char _fullname[4096] = { 0, }; char translated_name[MAX_ISONAME+1]; if (yep != p_statbuf->rr.b3_rock || 1 == opts.no_rock_ridge) { iso9660_name_translate_ext(psz_iso_name, translated_name, i_joliet_level); snprintf (_fullname, sizeof (_fullname), "%s%s", psz_path, translated_name); } else { snprintf (_fullname, sizeof (_fullname), "%s%s", psz_path, psz_iso_name); I believe either the test "yep != p_statbuf->rr.b3_rock" is incorrect, or possibly the code in lib/iso9660 that sets "b3_rock". The field "b3_rock" is an enumeration with the values "nope", "yep", "dunno". The test would be valid if "b3_rock" was a boolean, but the additional "dunno" state causes a problem. When the iso is created with the options given above, the value of "b3_rock" is "dunno" (integer 2). This causes the code to enter the "iso9660_name_translate_ext" which writes beyond the end of "translated_name" and corrupts the stack. I have also submitted this upstream as bug #21910 rbu@gentoo.org 2007-12-30 15:30:31 0000 The upstream bug report is marked private, so I restricted this bug for now. Please be aware that this vulnerability cannot be considered confidential anymore, as it was public in this bugtracker before. Diego, please advise. devon.miller@verizon.net 2007-12-30 16:36:02 0000 Sorry about that, I didn't see an obvious way to enter a private bug. It's currently fixed in upstream CVS (iso-info.c:1.36, cd-info.c:1.150). I'm attaching a patch that fixes the current ebuild rbu@gentoo.org 2007-12-30 17:07:05 0000 To enter restricted bugs, just click the "Only users in all of the selected groups can view this bug: Gentoo Security" checkbox in the expert bug filing page. flameeyes@gentoo.org 2007-12-30 18:21:50 0000 I don't really know what to advise on such short notice as I didn't even know of this before. I can tell there are quite some changes in libcdio CVS, good ones mostly but I wouldn't fast track to stable a new release of it right now (and I say this because I did make some of the changes ;)), so I'd suppose extracting the commit patch would probably be the best thing. rbu@gentoo.org 2007-12-30 18:43:09 0000 Created an attachment (id=139644) libcdio-info-buffer.patch Upstream committed patch rbu@gentoo.org 2007-12-30 18:48:15 0000 Diego, sounds good -- find the patch attached. As it is already in the upstream CVS, please prepare an ebuild. flameeyes@gentoo.org 2007-12-30 19:20:51 0000 libcdio-0.78.2-r2 added to portage.. although I'm not the libcdio ebuild maintainer since almost an year ;) Please when you add arches add also mips so that they can keyword a recent version, thanks. rbu@gentoo.org 2007-12-30 19:35:58 0000 Arch Security Liaisons, please test and mark stable dev-libs/libcdio-0.78.2-r2. Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 sh sparc x86" CC'ing current Liaisons: alpha : ferdy amd64 : welp hppa : jer ppc : dertobi123 ppc64 : corsair sparc : fmccor x86 : opfer fauli@gentoo.org 2007-12-30 21:53:04 0000 (In reply to comment #8) > Arch Security Liaisons, please test and mark stable dev-libs/libcdio-0.78.2-r2. > Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 sh sparc x86" Works on x86, but I am not able to commit to other directories than profiles at the moment...crappy lappy. Anyway, anyone is free to fix it for x86. jer@gentoo.org 2007-12-31 06:16:57 0000 Stable for HPPA and x86 (comment #9). corsair@gentoo.org 2007-12-31 14:30:42 0000 adding ranger because my machine is down. ranger: comment #8 ranger@gentoo.org 2007-12-31 16:05:47 0000 ppc64 done welp@gentoo.org 2007-12-31 17:40:27 0000 amd64 done. flameeyes@gentoo.org 2007-12-31 20:52:26 0000 Rocky mailed this on libcdio-dev so it's now public. I'll mail the patch for this in a few minutes and then work toward a new release, although I still want 0.78.2-r2 as target stable ;) rbu@gentoo.org 2008-01-01 15:46:15 0000 public via http://lists.gnu.org/archive/html/libcdio-devel/2007-12/msg00009.html Arches, please test and mark stable dev-libs/libcdio-0.78.2-r2. Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 sh sparc x86" Already stabled : "amd64 hppa ppc x86" Missing keywords: "alpha arm ia64 ppc64 sh sparc" armin76@gentoo.org 2008-01-01 15:57:43 0000 alpha/ia64/sparc stable ranger@gentoo.org 2008-01-01 18:00:01 0000 ppc64 done rbu@gentoo.org 2008-01-01 22:06:02 0000 request filed bannedit0@gmail.com 2008-01-03 03:34:49 0000 (In reply to comment #0) > dev-libs/libcdio-0.78.2 provides iso-info and cd-info both exhibit this > vulnerability. > > A properly formatted iso image can produce a coredump and may allow for > malicious code injection. > > Reproducible: Always > > Steps to Reproduce: > 1. mkdir -p tmp/dir1 > 2. echo file_with_really_really_long_silly_name_to_test_iso_info_buffer > 3. mkisofs -J -R -volid My_Image -o test.iso tmp > 4. iso-info -l test.iso > > Actual Results: > iso-info lists files and directories up to the ver long file name at which > point it segfaults. > > Expected Results: > a listing of the directories > > in src/iso-info.c, in function "print_iso9660_recurse" there is a block of code > that begins: > > _CDIO_LIST_FOREACH (entnode, entlist) > { > iso9660_stat_t *p_statbuf = _cdio_list_node_data (entnode); > char *psz_iso_name = p_statbuf->filename; > char _fullname[4096] = { 0, }; > char translated_name[MAX_ISONAME+1]; > > > if (yep != p_statbuf->rr.b3_rock || 1 == opts.no_rock_ridge) { > iso9660_name_translate_ext(psz_iso_name, translated_name, > i_joliet_level); > snprintf (_fullname, sizeof (_fullname), "%s%s", psz_path, > translated_name); > } else { > snprintf (_fullname, sizeof (_fullname), "%s%s", psz_path, > psz_iso_name); > > > I believe either the test "yep != p_statbuf->rr.b3_rock" is incorrect, or > possibly the code in lib/iso9660 that sets "b3_rock". The field "b3_rock" is an > enumeration with the values "nope", "yep", "dunno". The test would be valid if > "b3_rock" was a boolean, but the additional "dunno" state causes a problem. > > When the iso is created with the options given above, the value of "b3_rock" is > "dunno" (integer 2). This causes the code to enter the > "iso9660_name_translate_ext" which writes beyond the end of "translated_name" > and corrupts the stack. > > I have also submitted this upstream as bug #21910 > (In reply to comment #5) > Created an attachment (id=139644) [edit] > libcdio-info-buffer.patch > > Upstream committed patch > Shouldn't the +1 go outside the strlen bracets? Likely won't cause a problem now that things are on the heap but... worth mentioning I think devon.miller@verizon.net 2008-01-03 13:15:28 0000 (In reply to comment #19) > > char translated_name[MAX_ISONAME+1]; > > > > (In reply to comment #5) > > Created an attachment (id=139644) [edit] > > libcdio-info-buffer.patch > > > > Upstream committed patch > > > > Shouldn't the +1 go outside the strlen bracets? Likely won't cause a problem > now that things are on the heap but... worth mentioning I think > Yes, good catch, As it is, the alloca'd string may be 2 bytes too small.I have updated the upstream bug report with this information, devon.miller@verizon.net 2008-01-03 13:24:39 0000 Created an attachment (id=139967) Buffer patch with correction for +1 in the wrong place Moved the +1 outside the strlen call so the size is the length of the string plus 1, not the length of the string minus 1. flameeyes@gentoo.org 2008-01-03 13:45:09 0000 I think it the original version was by design: the translation strings remove ;1 suffix from filenames, so strlen(foo+1) is equivalent to writing strlen(foo)-1, just making strlen faster (afair, strlen() is O(n)). devon.miller@verizon.net 2008-01-04 03:12:36 0000 Created an attachment (id=140011) Upstream patch for misplaced +1 Patch from upstream cvs repo. devon.miller@verizon.net 2008-01-04 03:14:49 0000 (In reply to comment #22) > I think it the original version was by design: the translation strings remove > ;1 suffix from filenames, so strlen(foo+1) is equivalent to writing > strlen(foo)-1, just making strlen faster (afair, strlen() is O(n)). Negative. Upstream has confirmed and patched. See attachment #140011 rbu@gentoo.org 2008-01-04 03:35:57 0000 media-video, your ball. py@gentoo.org 2008-01-04 22:35:05 0000 *** Bug 204333 has been marked as a duplicate of this bug. *** flameeyes@gentoo.org 2008-01-04 23:21:53 0000 Committed 0.78.2-r3 straight-to-stable for those who already stabled -r2. rbu@gentoo.org 2008-01-04 23:38:02 0000 Arches, please test and mark stable dev-libs/libcdio-0.78.2-r3. Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 sh sparc x86" Already stabled : "alpha amd64 hppa ia64 ppc ppc64 sparc x86" Missing keywords: "arm sh" rbu@gentoo.org 2008-01-08 22:56:27 0000 Stanislav Brabec from SUSE pointed out that allocating a larger string on the stack might easier lead to stack exhaustion, which can be shown by using some ten thousand files with long file names. Not sure on whether upstream will apply his patches, but would you consider this a regression (media-video/Diego)? rbu@gentoo.org 2008-01-09 21:11:06 0000 Diego, do you consider this a regression? If not, we'd glsa this now, otherwise we'll go stabling a new ebuild. The patch has been committed to the upstream CVS. bannedit0@gmail.com 2008-01-10 22:57:55 0000 (In reply to comment #29) > Stanislav Brabec from SUSE pointed out that allocating a larger string on the > stack might easier lead to stack exhaustion, which can be shown by using some > ten thousand files with long file names. > Not sure on whether upstream will apply his patches, but would you consider > this a regression (media-video/Diego)? > I was looking at this scenario just recently. From the alloca() man page: RETURN VALUE The alloca() function returns a pointer to the beginning of the allo- cated space. If the allocation causes stack overflow, program behavior is undefined. In some cases I think this could cause some major problems even further security issues. In the simplest case this will only cause stability issues. My suggestion would be to use the heap rather than alloca(). jaervosz@gentoo.org 2008-01-13 14:08:14 0000 Seems like we should go back to ebuild to get this fixed? flameeyes@gentoo.org 2008-01-13 14:37:35 0000 Sorry I was out of order because of the cold/fever, I'll see to handle this today. flameeyes@gentoo.org 2008-01-13 16:17:59 0000 0.78.2-r4 and 0.79-r1 are in tree. I didn't commit straight to stable this time, just for safety. jaervosz@gentoo.org 2008-01-13 16:39:33 0000 Thx Diego. Arches please test and mark stable. Target keywords are: libcdio-0.78.2-r4.ebuild:KEYWORDS="alpha amd64 arm hppa ia64 ppc ppc64 sh sparc ~sparc-fbsd x86 ~x86-fbsd" ranger@gentoo.org 2008-01-13 17:56:54 0000 ppc64 done dertobi123@gentoo.org 2008-01-13 20:19:39 0000 ppc stable maekke@gentoo.org 2008-01-13 20:55:15 0000 x86 stable fmccor@gentoo.org 2008-01-14 14:16:09 0000 Sparc stable. armin76@gentoo.org 2008-01-14 20:12:44 0000 alpha/ia64 stable jer@gentoo.org 2008-01-14 20:38:05 0000 Stable for HPPA. rbu@gentoo.org 2008-01-15 17:42:58 0000 amd64 stable, [glsa] again. rbu@gentoo.org 2008-01-20 00:44:34 0000 GLSA 200801-08, thanks. 139644 2007-12-30 18:43 0000 libcdio-info-buffer.patch libcdio-info-buffer.patch text/plain ZGlmZiAtTmF1ciBsaWJjZGlvLTAuNzguMi1vcmlnL3dvcmsvbGliY2Rpby0wLjc4LjIvc3JjL2Nk LWluZm8uYyBsaWJjZGlvLTAuNzguMi93b3JrL2xpYmNkaW8tMC43OC4yL3NyYy9jZC1pbmZvLmMK LS0tIGxpYmNkaW8tMC43OC4yLW9yaWcvd29yay9saWJjZGlvLTAuNzguMi9zcmMvY2QtaW5mby5j CTIwMDYtMDMtMTcgMTQ6Mzc6MDguMDAwMDAwMDAwIC0wNTAwCisrKyBsaWJjZGlvLTAuNzguMi93 b3JrL2xpYmNkaW8tMC43OC4yL3NyYy9jZC1pbmZvLmMJMjAwNy0xMi0zMCAxMDo0OTo0MC4wMDAw MDAwMDAgLTA1MDAKQEAgLTUzOSw3ICs1MzksNyBAQAogICAgICAgaXNvOTY2MF9zdGF0X3QgKnBf c3RhdGJ1ZiA9IF9jZGlvX2xpc3Rfbm9kZV9kYXRhIChlbnRub2RlKTsKICAgICAgIGNoYXIgKnBz el9pc29fbmFtZSA9IHBfc3RhdGJ1Zi0+ZmlsZW5hbWU7CiAgICAgICBjaGFyIF9mdWxsbmFtZVs0 MDk2XSA9IHsgMCwgfTsKLSAgICAgIGNoYXIgdHJhbnNsYXRlZF9uYW1lW01BWF9JU09OQU1FKzFd OworICAgICAgY2hhciAqdHJhbnNsYXRlZF9uYW1lID0gKGNoYXIgKikgYWxsb2NhKHN0cmxlbihw c3pfaXNvX25hbWUrMSkpOwogCiAgICAgICBpZiAoeWVwICE9IHBfc3RhdGJ1Zi0+cnIuYjNfcm9j ayB8fCAxID09IG9wdHMubm9fcm9ja19yaWRnZSkgewogCWlzbzk2NjBfbmFtZV90cmFuc2xhdGVf ZXh0KHBzel9pc29fbmFtZSwgdHJhbnNsYXRlZF9uYW1lLCAKZGlmZiAtTmF1ciBsaWJjZGlvLTAu NzguMi1vcmlnL3dvcmsvbGliY2Rpby0wLjc4LjIvc3JjL2lzby1pbmZvLmMgbGliY2Rpby0wLjc4 LjIvd29yay9saWJjZGlvLTAuNzguMi9zcmMvaXNvLWluZm8uYwotLS0gbGliY2Rpby0wLjc4LjIt b3JpZy93b3JrL2xpYmNkaW8tMC43OC4yL3NyYy9pc28taW5mby5jCTIwMDYtMDMtMTcgMTQ6Mzc6 MDguMDAwMDAwMDAwIC0wNTAwCisrKyBsaWJjZGlvLTAuNzguMi93b3JrL2xpYmNkaW8tMC43OC4y L3NyYy9pc28taW5mby5jCTIwMDctMTItMzAgMTA6NDk6NTAuMDAwMDAwMDAwIC0wNTAwCkBAIC0y MjQsNyArMjI0LDggQEAKICAgICAgIGlzbzk2NjBfc3RhdF90ICpwX3N0YXRidWYgPSBfY2Rpb19s aXN0X25vZGVfZGF0YSAoZW50bm9kZSk7CiAgICAgICBjaGFyICpwc3pfaXNvX25hbWUgPSBwX3N0 YXRidWYtPmZpbGVuYW1lOwogICAgICAgY2hhciBfZnVsbG5hbWVbNDA5Nl0gPSB7IDAsIH07Ci0g ICAgICBjaGFyIHRyYW5zbGF0ZWRfbmFtZVtNQVhfSVNPTkFNRSsxXTsKKyAgICAgIGNoYXIgKnRy YW5zbGF0ZWRfbmFtZSA9IChjaGFyICopIGFsbG9jYShzdHJsZW4ocHN6X2lzb19uYW1lKzEpKTsK KwogCiAgICAgICBpZiAoeWVwICE9IHBfc3RhdGJ1Zi0+cnIuYjNfcm9jayB8fCAxID09IG9wdHMu bm9fcm9ja19yaWRnZSkgewogCWlzbzk2NjBfbmFtZV90cmFuc2xhdGVfZXh0KHBzel9pc29fbmFt ZSwgdHJhbnNsYXRlZF9uYW1lLCAK 139967 2008-01-03 13:24 0000 Buffer patch with correction for +1 in the wrong place libcdio.patch text/plain ZGlmZiAtTmF1ciBsaWJjZGlvLTAuNzguMi1vcmlnL3dvcmsvbGliY2Rpby0wLjc4LjIvc3JjL2Nk LWluZm8uYyBsaWJjZGlvLTAuNzguMi93b3JrL2xpYmNkaW8tMC43OC4yL3NyYy9jZC1pbmZvLmMK LS0tIGxpYmNkaW8tMC43OC4yLW9yaWcvd29yay9saWJjZGlvLTAuNzguMi9zcmMvY2QtaW5mby5j CTIwMDYtMDMtMTcgMTQ6Mzc6MDguMDAwMDAwMDAwIC0wNTAwCisrKyBsaWJjZGlvLTAuNzguMi93 b3JrL2xpYmNkaW8tMC43OC4yL3NyYy9jZC1pbmZvLmMJMjAwOC0wMS0wMyAwNzo1NToyNy4wMDAw MDAwMDAgLTA1MDAKQEAgLTUzOSw3ICs1MzksNyBAQAogICAgICAgaXNvOTY2MF9zdGF0X3QgKnBf c3RhdGJ1ZiA9IF9jZGlvX2xpc3Rfbm9kZV9kYXRhIChlbnRub2RlKTsKICAgICAgIGNoYXIgKnBz el9pc29fbmFtZSA9IHBfc3RhdGJ1Zi0+ZmlsZW5hbWU7CiAgICAgICBjaGFyIF9mdWxsbmFtZVs0 MDk2XSA9IHsgMCwgfTsKLSAgICAgIGNoYXIgKnRyYW5zbGF0ZWRfbmFtZSA9IChjaGFyICopIGFs bG9jYShzdHJsZW4ocHN6X2lzb19uYW1lKzEpKTsKKyAgICAgIGNoYXIgKnRyYW5zbGF0ZWRfbmFt ZSA9IChjaGFyICopIGFsbG9jYShzdHJsZW4ocHN6X2lzb19uYW1lKSsxKTsKIAogICAgICAgaWYg KHllcCAhPSBwX3N0YXRidWYtPnJyLmIzX3JvY2sgfHwgMSA9PSBvcHRzLm5vX3JvY2tfcmlkZ2Up IHsKIAlpc285NjYwX25hbWVfdHJhbnNsYXRlX2V4dChwc3pfaXNvX25hbWUsIHRyYW5zbGF0ZWRf bmFtZSwgCmRpZmYgLU5hdXIgbGliY2Rpby0wLjc4LjItb3JpZy93b3JrL2xpYmNkaW8tMC43OC4y L3NyYy9pc28taW5mby5jIGxpYmNkaW8tMC43OC4yL3dvcmsvbGliY2Rpby0wLjc4LjIvc3JjL2lz by1pbmZvLmMKLS0tIGxpYmNkaW8tMC43OC4yLW9yaWcvd29yay9saWJjZGlvLTAuNzguMi9zcmMv aXNvLWluZm8uYwkyMDA2LTAzLTE3IDE0OjM3OjA4LjAwMDAwMDAwMCAtMDUwMAorKysgbGliY2Rp by0wLjc4LjIvd29yay9saWJjZGlvLTAuNzguMi9zcmMvaXNvLWluZm8uYwkyMDA3LTEyLTMwIDEw OjQ5OjUwLjAwMDAwMDAwMCAtMDUwMApAQCAtMjI0LDcgKzIyNCw3IEBACiAgICAgICBpc285NjYw X3N0YXRfdCAqcF9zdGF0YnVmID0gX2NkaW9fbGlzdF9ub2RlX2RhdGEgKGVudG5vZGUpOwogICAg ICAgY2hhciAqcHN6X2lzb19uYW1lID0gcF9zdGF0YnVmLT5maWxlbmFtZTsKICAgICAgIGNoYXIg X2Z1bGxuYW1lWzQwOTZdID0geyAwLCB9OwotICAgICAgY2hhciAqdHJhbnNsYXRlZF9uYW1lID0g KGNoYXIgKikgYWxsb2NhKHN0cmxlbihwc3pfaXNvX25hbWUrMSkpOworICAgICAgY2hhciAqdHJh bnNsYXRlZF9uYW1lID0gKGNoYXIgKikgYWxsb2NhKHN0cmxlbihwc3pfaXNvX25hbWUpKzEpOwog CiAKICAgICAgIGlmICh5ZXAgIT0gcF9zdGF0YnVmLT5yci5iM19yb2NrIHx8IDEgPT0gb3B0cy5u b19yb2NrX3JpZGdlKSB7Cg== 140011 2008-01-04 03:12 0000 Upstream patch for misplaced +1 libcdio-buffer-offbyone.patch text/plain LS0tIGNkLWluZm8uYwkyMDA3LzEyLzMwIDE1OjA5OjAwCTEuMTUwCisrKyBjZC1pbmZvLmMJMjAw OC8wMS8wMyAxNDozOToyOQkxLjE1MQpAQCAtMSw3ICsxLDcgQEAKIC8qCi0gICAgJElkOiBjZC1p bmZvLmMsdiAxLjE1MCAyMDA3LzEyLzMwIDE1OjA5OjAwIHJvY2t5IEV4cCAkCisgICAgJElkOiBj ZC1pbmZvLmMsdiAxLjE1MSAyMDA4LzAxLzAzIDE0OjM5OjI5IHJvY2t5IEV4cCAkCiAKLSAgICBD b3B5cmlnaHQgKEMpIDIwMDMsIDIwMDQsIDIwMDUsIDIwMDcgUm9ja3kgQmVybnN0ZWluIDxyb2Nr eUBnbnUub3JnPgorICAgIENvcHlyaWdodCAoQykgMjAwMywgMjAwNCwgMjAwNSwgMjAwNywgMjAw OCBSb2NreSBCZXJuc3RlaW4gPHJvY2t5QGdudS5vcmc+CiAgICAgQ29weXJpZ2h0IChDKSAxOTk2 LCAxOTk3LCAxOTk4ICBHZXJkIEtub3JyIDxrcmF4ZWxAYnl0ZXNleC5vcmc+CiAgICAgICAgICBh bmQgSGVpa28gRWnfZmVsZHQgPGhlaWtvQGhleGNvLmRlPgogCkBAIC01MzksNyArNTM5LDcgQEAK ICAgICAgIGlzbzk2NjBfc3RhdF90ICpwX3N0YXRidWYgPSBfY2Rpb19saXN0X25vZGVfZGF0YSAo ZW50bm9kZSk7CiAgICAgICBjaGFyICpwc3pfaXNvX25hbWUgPSBwX3N0YXRidWYtPmZpbGVuYW1l OwogICAgICAgY2hhciBfZnVsbG5hbWVbNDA5Nl0gPSB7IDAsIH07Ci0gICAgICBjaGFyICp0cmFu c2xhdGVkX25hbWUgPSAoY2hhciAqKSBhbGxvY2Eoc3RybGVuKHBzel9pc29fbmFtZSsxKSk7Cisg ICAgICBjaGFyICp0cmFuc2xhdGVkX25hbWUgPSAoY2hhciAqKSBhbGxvY2Eoc3RybGVuKHBzel9p c29fbmFtZSkrMSk7CiAKICAgICAgIGlmICh5ZXAgIT0gcF9zdGF0YnVmLT5yci5iM19yb2NrIHx8 IDEgPT0gb3B0cy5ub19yb2NrX3JpZGdlKSB7CiAJaXNvOTY2MF9uYW1lX3RyYW5zbGF0ZV9leHQo cHN6X2lzb19uYW1lLCB0cmFuc2xhdGVkX25hbWUsIAotLS0gaXNvLWluZm8uYwkyMDA3LzEyLzMw IDE1OjA5OjAwCTEuMzYKKysrIGlzby1pbmZvLmMJMjAwOC8wMS8wMyAxNDozOToyOQkxLjM3CkBA IC0xLDUgKzEsNSBAQAogLyoKLSAgICAkSWQ6IGlzby1pbmZvLmMsdiAxLjM2IDIwMDcvMTIvMzAg MTU6MDk6MDAgcm9ja3kgRXhwICQKKyAgICAkSWQ6IGlzby1pbmZvLmMsdiAxLjM3IDIwMDgvMDEv MDMgMTQ6Mzk6Mjkgcm9ja3kgRXhwICQKIAogICAgIENvcHlyaWdodCAoQykgMjAwNCwgMjAwNSwg MjAwNiBSb2NreSBCZXJuc3RlaW4gPHJvY2t5QHBhbml4LmNvbT4KIApAQCAtMjI0LDcgKzIyNCw3 IEBACiAgICAgICBpc285NjYwX3N0YXRfdCAqcF9zdGF0YnVmID0gX2NkaW9fbGlzdF9ub2RlX2Rh dGEgKGVudG5vZGUpOwogICAgICAgY2hhciAqcHN6X2lzb19uYW1lID0gcF9zdGF0YnVmLT5maWxl bmFtZTsKICAgICAgIGNoYXIgX2Z1bGxuYW1lWzQwOTZdID0geyAwLCB9OwotICAgICAgY2hhciAq dHJhbnNsYXRlZF9uYW1lID0gKGNoYXIgKikgYWxsb2NhKHN0cmxlbihwc3pfaXNvX25hbWUrMSkp OworICAgICAgY2hhciAqdHJhbnNsYXRlZF9uYW1lID0gKGNoYXIgKikgYWxsb2NhKHN0cmxlbihw c3pfaXNvX25hbWUpKzEpOwogCiAgICAgICBpZiAoeWVwICE9IHBfc3RhdGJ1Zi0+cnIuYjNfcm9j ayB8fCAxID09IG9wdHMubm9fcm9ja19yaWRnZSkgewogCWlzbzk2NjBfbmFtZV90cmFuc2xhdGVf ZXh0KHBzel9pc29fbmFtZSwgdHJhbnNsYXRlZF9uYW1lLCAKCg==