Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4FF4ACC3.9030301@redhat.com>
Date: Wed, 04 Jul 2012 14:51:15 -0600
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security@...ts.openwall.com
CC: Timo Warns <warns@...-sense.de>
Subject: Re: CVE Request: Stability fixes in UDF Logical Volume
 Descriptor handling

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/03/2012 02:46 PM, Timo Warns wrote:
> Am 03.07.2012 20:58, schrieb Kurt Seifried:
>> On 07/03/2012 07:22 AM, Marcus Meissner wrote:
>> 
>>> People (do not know who) reported to the kernel security team
>>> and Jan Kara some UDF filesystem crashes.
>> 
>>> Jan Kara did some fixes in the UDF fs and they were committed
>>> to mainline already, both actual bugfixes and some more sanity
>>>  checking for hardening.
>>> 
>>> I think a single CVE is sufficient.
>> 
>> Were they discovered by the same person or different people?
> 
> I reported the following issue for sparing tables on 2012-06-17 to 
> security@...nel.org. Eugene Teo informed Jan Kara, who is the
> maintainer for the UDF filesystem, on the same day. Jan had a
> closer look at the UDF code and identified all other issues
> addressed by the patches.
> 
> | udf_load_logicalvol() in fs/udf/super.c parses the number of
> sparing | tables and stores the sparing tables on the heap: | |
> (1286)  for (j = 0; j < spm->numSparingTables; j++) { | [...] |
> (1293)    map->s_type_specific.s_sparing. | (1294)
> s_spar_map[j] = bh2; | | map is of type udf_part_map, whose |
> s_type_specific.s_sparing.s_spar_map | member can only hold 4
> pointers to buffer_head structs. | | spm->numSparingTables is read
> from the file system and not further | validated. A corrupted file
> system with numSparingTables > 4 causes | a heap overflow.
> 
> Regards, Timo
> 

Just a placeholder: I'm waiting for a reply from Steve to see if we
can violate CVE assignment guidelines and put this under one CVE (it
should probably be two but sorting it out seems like it might not be
worthwhile).

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJP9KzDAAoJEBYNRVNeJnmTvbgP/jSW/zU8uclVkHT3Ptrk1e8c
bieZ0Bq5HRU4j+aAgXOu/EALADfc9rpvg5UslKWWeWZM/UiVSP2bR82Ol+z5B15m
AHvNBN11nU+v1vCwQBqxFie4qd9wA8iCzvm8RJ/NYhpfs7XzC/BsbVJJvIu0v4/d
AExQqh97ICLiPC/tVXfFaO0o8WpCcgAbqKUZdXb5OpZSvON4HznNL1HntKo2yVRN
Q1bghF1Ya+EhPqgtUqL43euU2EUg0utWb97guolRKwtlKcrVOnjYj3ntESbmxTQj
xFt11H8DG11OrrvagqXmyiZ5g8jBslJTF12/8Eyx6Oya4A8FFoQ2E5MSVOSNIT3I
5yPTfNsUqrtJxdg4h9V2SsE/yd2BCycMbc4V4TlQ7BqhV6v6P6xJO4FVEGDJQhDK
Upo1SizihICXRMphDrNpru0TFEAGFgFOoWyMXZD1o897PSPDxZPDqIa0lZKyuTmt
b81VkEntKOU0KD6aC0GWYiqMvDFWrzO0E9840WNUZJ+wcXi1D/TYz6pZtAnuZx30
iD4e2eeXZjOSO/J9fIN3arQBZs3NLZx7TzeMQ6j5e0x72w8wl4IEGtzxxIQM0gvv
jYJq/8cbFUUv7xx8s/yhqQmAYstKIYLdRYGNeEhGcz01m4Wbms5bu1grW01Kuwf5
T/dQmJDH9MMoWdT8PkSc
=XqIW
-----END PGP SIGNATURE-----

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.