| Summary: | boost new security issue CVE-2012-2677 | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | David Walser <luigiwalser> |
| Component: | Security | Assignee: | QA Team <qa-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | davidwhodgins, sysadmin-bugs, tmb |
| Version: | 2 | Keywords: | validated_update |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://lwn.net/Vulnerabilities/504070/ | ||
| Whiteboard: | MGA1TOO, mga1-32-OK, mga2-32-OK, mga1-64-OK mga2-64-OK | ||
| Source RPM: | boost-1.48.0-9.mga2.src.rpm | CVE: | |
| Status comment: | |||
| Attachments: |
test_bug_6701.cpp
test_bug_6701-mga1.cpp |
||
|
Description
David Walser
2012-06-29 18:19:04 CEST
David Walser
2012-06-29 18:19:18 CEST
Whiteboard:
(none) =>
MGA1TOO The patch to fix this includes a "reproducer" program that can be used to verify the bug and the fix. It tested correctly for me on mga1 and mga2 i586. If you have libboost-devel installed, you can compile the program with g++ and then run the resulting binary. With the bug present, it will exit with an assertion error. With the bug fixed, it will produce no output. Created attachment 2521 [details]
test_bug_6701.cpp
This is the reproducer program from the original patch. It works on Mageia 2.
Created attachment 2522 [details]
test_bug_6701-mga1.cpp
This is a slightly modified version to work with boost 1.44 on Mageia 1.
Testing mga1 64 Thanks for the testcase and procedure David, that really saves some time. To get g++ # urpmi gcc-c++ Before ------ $ g++ test_bug_6701-mga1.cpp $ ./a.out a.out: test_bug_6701-mga1.cpp:21: int main(): Assertion `std::numeric_limits<size_t>::max() / 1024 >= p.get_next_size()' failed. Aborted After ----- $ g++ test_bug_6701-mga1.cpp $ ./a.out $ Not sure how to properly test libboost yet, looking into libboost-examples. Testing complete on Mageia 1 i586. Will test Mageia 2 i586 shortly. CC:
(none) =>
davidwhodgins Testing complete on Mageia 2 i586. Also added mga1-64-OK based on comment 4. :-) Whiteboard:
MGA1TOO, mga1-32-OK =>
MGA1TOO, mga1-32-OK, mga2-32-OK, mga1-64-OK Testing complete mga2 64 This doesn't seem affected but no regression after the update Validating See comment 0 for Advisory and SRPM's for mga1 and 2. Could sysadmin please push from core/updates_testing to core/updates This also seems affected by bug 2317 ---------------------------------------- Running checks for "lib64boost-devel" using media "Core Release" and "Core Updates Testing". ---------------------------------------- Mageia release 2 (Official) for x86_64 Latest version found in "Core Release" is lib64boost-devel-1.48.0-9.mga2 Latest version found in "Core Updates Testing" is lib64boost-devel-1.48.0-9.1.mga2 ---------------------------------------- The following packages will require linking: lib64uClibc-zlib-devel-1.2.6-1.mga2 (Core Release) lib64zlib-devel-1.2.6-1.mga2 (Core Release) ---------------------------------------- On mga1 it seems to pick up on some which most packages are.. ---------------------------------------- Running checks for "lib64boost-devel" using media "Core Release" and "Core Updates Testing". ---------------------------------------- Mageia release 1 (Official) for x86_64 Latest version found in "Core Release" is lib64boost-devel-1.44.0-6.mga1 Latest version found in "Core Updates Testing" is lib64boost-devel-1.44.0-6.1.mga1 ---------------------------------------- The following packages will require linking: notification-daemon-0.5.0-2.mga1 (Core 32bit Release) notification-daemon-0.5.0-2.mga1 (Core Release) xfce4-notifyd-0.2.1-3.mga1 (Core 32bit Release) xfce4-notifyd-0.2.1-3.mga1 (Core Release) ---------------------------------------- Done. Keywords:
(none) =>
validated_update Why would any packages require linking when no new Requires/Suggests were added to the package? It is recursive requires David. To properly find the minimum number of packages requiring linking depcheck would need completely rewriting but that seems self defeating. As it is it uses urpmq --whatrequires-recursive .. What it would need to do to find minimal packages would be to distinguish added recursive requires from added suggests and then search only for added recursive requires of the added suggests instead of searching without the --no-suggests option. Then add those to the results of finding added recursive requires. It is more sensible to spend that effort in fixing the actual bug rather than improving the workaround though. Depends on:
(none) =>
2317 sorry --requires-recursive not --whatrequires-recursive So additional requires or suggests must have been added to dependencies of boost in other updates? Oh that crazy Bug 2317 :o) (In reply to comment #11) > So additional requires or suggests must have been added to dependencies of > boost in other updates? Oh that crazy Bug 2317 :o) But wait, if that was true, wouldn't they have been linked already? These ones have cropped up before so when others are linked this will not be directly affected. It's the links which are the problem rather than any specific package. Once done then anything affected by them will be OK. I think Thomas is trying to wait and see what happens with bug 2317 as there are some with an enormous number of links required. new depcheck found no links required so removing the depends. Depends on:
2317 =>
(none) Update pushed: https://wiki.mageia.org/en/Support/Advisories/MGASA-2012-0151 Status:
NEW =>
RESOLVED |