From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8628 invoked by alias); 6 Apr 2011 16:50:22 -0000 Received: (qmail 8613 invoked by uid 22791); 6 Apr 2011 16:50:21 -0000 X-SWARE-Spam-Status: No, hits=-1.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-qw0-f41.google.com (HELO mail-qw0-f41.google.com) (209.85.216.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 06 Apr 2011 16:50:16 +0000 Received: by qwa26 with SMTP id 26so1302875qwa.0 for ; Wed, 06 Apr 2011 09:50:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.18.77 with SMTP id v13mr1079809qca.56.1302108615935; Wed, 06 Apr 2011 09:50:15 -0700 (PDT) Received: by 10.229.97.206 with HTTP; Wed, 6 Apr 2011 09:50:15 -0700 (PDT) Date: Wed, 06 Apr 2011 16:50:00 -0000 Message-ID: Subject: [patch bfd]: Prevent possible buffer overflow on pdata-section sorting From: Kai Tietz To: Binutils Cc: Nick Clifton Content-Type: multipart/mixed; boundary=0015176f0bb883090304a042c9d3 X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2011-04/txt/msg00066.txt.bz2 --0015176f0bb883090304a042c9d3 Content-Type: text/plain; charset=ISO-8859-1 Content-length: 455 Hello, this issue was reported by H. Becker to me. He found that the code in peXXigen.c about pdata-section sorting might cause a buffer-overrun for large pdata-data. By working in private allocated buffer - instead of using the pfinfo->contents - avoids this. ChangeLog 2011-04-06 Kai Tietz * peXXigen.c (_bfd_XXi_final_link_postscripte): Sort pdata in temporary buffer. Tested for x86_64-w64-mingw32. Ok for apply? Regards, Kai --0015176f0bb883090304a042c9d3 Content-Type: text/plain; charset=US-ASCII; name="pdata_x64_sort.txt" Content-Disposition: attachment; filename="pdata_x64_sort.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gm6hucnk0 Content-length: 1456 SW5kZXg6IHNyYy9iZmQvcGVYWGlnZW4uYwo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09Ci0tLSBzcmMub3JpZy9iZmQvcGVYWGlnZW4uYwkyMDEwLTEyLTIxIDE5 OjMzOjA3LjAwMDAwMDAwMCArMDEwMAorKysgc3JjL2JmZC9wZVhYaWdlbi5j CTIwMTEtMDQtMDYgMTg6MTk6NDUuOTQ1Mzk0ODAwICswMjAwCkBAIC0yNDU5 LDE0ICsyNDU5LDIyIEBAIF9iZmRfWFhpX2ZpbmFsX2xpbmtfcG9zdHNjcmlw dCAoYmZkICogYWIKICAgICBpZiAoc2VjKQogICAgICAgewogCWJmZF9zaXpl X3R5cGUgeCA9IHNlYy0+cmF3c2l6ZSA/IHNlYy0+cmF3c2l6ZSA6IHNlYy0+ c2l6ZTsKKwliZmRfYnl0ZSAqdG1wX2RhdGEgPSBOVUxMOwogCi0JaWYgKHgg JiYgYmZkX2dldF9zZWN0aW9uX2NvbnRlbnRzIChhYmZkLCBzZWMsIHBmaW5m by0+Y29udGVudHMsIDAsIHgpKQorCWlmICh4KQorCSAgdG1wX2RhdGEgPSBi ZmRfbWFsbG9jICh4KTsKKworCWlmICh0bXBfZGF0YSAhPSBOVUxMKQogCSAg ewotCSAgICBxc29ydCAocGZpbmZvLT5jb250ZW50cywKLQkgICAgCSAgIChz aXplX3QpICgoc2VjLT5zaXplIDx4ID8gc2VjLT5zaXplIDogeCkgLyAxMiks Ci0JICAgIAkgICAxMiwgc29ydF94NjRfcGRhdGEpOwotCSAgICBiZmRfc2V0 X3NlY3Rpb25fY29udGVudHMgKHBmaW5mby0+b3V0cHV0X2JmZCwgc2VjLAot CSAgICAJCQkgICAgICBwZmluZm8tPmNvbnRlbnRzLCAwLCB4KTsKKwkgICAg aWYgKGJmZF9nZXRfc2VjdGlvbl9jb250ZW50cyAoYWJmZCwgc2VjLCB0bXBf ZGF0YSwgMCwgeCkpCisJICAgICAgeworCQlxc29ydCAodG1wX2RhdGEsCisJ CSAgICAgICAoc2l6ZV90KSAoKHNlYy0+c2l6ZSA8eCA/IHNlYy0+c2l6ZSA6 IHgpIC8gMTIpLAorCQkgICAgICAgMTIsIHNvcnRfeDY0X3BkYXRhKTsKKwkJ YmZkX3NldF9zZWN0aW9uX2NvbnRlbnRzIChwZmluZm8tPm91dHB1dF9iZmQs IHNlYywKKwkJCQkJICB0bXBfZGF0YSwgMCwgeCk7CisJICAgICAgfQorCSAg ICBmcmVlICh0bXBfZGF0YSk7CiAJICB9CiAgICAgICB9CiAgIH0K --0015176f0bb883090304a042c9d3--