CVEs have been assigned for two issues fixed in dosfstools 4.0: http://openwall.com/lists/oss-security/2016/05/14/1 Neither patch applies cleanly to 3.0.27, so if we're going to fix these, it might be best to just update to 4.0 (sync with Cauldron).
Assigning to all packagers collectively, since there is no maintainer for this package.
CC: (none) => marja11Assignee: bugsquad => pkg-bugs
CC: (none) => makowski.mageia
fedora 22 just fixed their 3.0.27 release applying three patches: http://pkgs.fedoraproject.org/cgit/rpms/dosfstools.git/commit/?h=f22 testing locally and seems fine!
CC: (none) => geiger.david68210
(In reply to David GEIGER from comment #2) > fedora 22 just fixed their 3.0.27 release applying three patches: > > http://pkgs.fedoraproject.org/cgit/rpms/dosfstools.git/commit/?h=f22 > > testing locally and seems fine! Fantastic! Feel free to commit and push it.
Done!
Advisory: ======================== Updated dosfstools package fixes security vulnerabilities: In dosfstools before 4.0, if the third to last entry was written on a FAT12 filesystem with an odd number of clusters, the second to last entry would be corrupted. This corruption may also lead to invalid memory accesses when the corrupted entry becomes out of bounds and is used later (CVE-2015-8872). In dosfstools before 4.0, the variable used for storing the FAT size (in bytes) was an unsigned int. Since the size in sectors read from the BPB was not sufficiently checked, this could end up being zero after multiplying it with the sector size while some offsets still stayed excessive. Ultimately it would cause segfaults when accessing FAT entries for which no memory was allocated (CVE-2016-4804). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-8872 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-4804 http://openwall.com/lists/oss-security/2016/05/14/1 ======================== Updated packages in core/updates_testing: ======================== dosfstools-3.0.27-1.1.mga5 from dosfstools-3.0.27-1.1.mga5.src.rpm
Assignee: pkg-bugs => qa-bugs
URL: (none) => http://lwn.net/Vulnerabilities/687591/
Testing M5 x64: dosfstools-3.0.27-1.1.mga5 The nearest thing I have to a FAT filesystem is a 1Gb USB stick, vfat - but certainly not FAT12. I deleted what was curently on it, then copied a complex directory if mixed files onto it. As far as I could tell, the two file sets were the same - certainly at the broad level of number of (sub)directories & files with tree & ls -R. Random browsing of the vfat collection was correct. I would prefer to have done actual file size total comparisions, but could not discover the 'ls' command to give that. BTAIM I am OKing this update - unless someone can do better with a real FAT disc partition.
CC: (none) => lewyssmith
You can make a filesystem image file with dd, format it with mkfs.fat and mount it as a loopback device, if you don't want to reformat a physical device as FAT.
Before update... $ fallocate -l 10M /tmp/foo.img $ /sbin/mkfs.fat /tmp/foo.img mkfs.fat 3.0.27 (2014-11-12) $ mkdir /tmp/foo # mount -t msdos -o loop /tmp/foo.img /tmp/foo # echo this is a file > /tmp/foo/test $ cat /tmp/foo/test this is a file # umount /tmp/foo $ /sbin/fsck.fat /tmp/foo.img fsck.fat 3.0.27 (2014-11-12) /tmp/foo.img: 1 files, 1/5101 clusters %%% install updated dosfstools package %%% $ /sbin/fsck.fat /tmp/foo.img fsck.fat 3.0.27 (2014-11-12) /tmp/foo.img: 1 files, 1/5101 clusters # mount -t msdos -o loop /tmp/foo.img /tmp/foo $ cat /tmp/foo/test this is a file # umount /tmp/foo (note that commands preceded with a # were run as root)
Whiteboard: (none) => has_procedure MGA5-32-OK
Validating.
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
Whiteboard: has_procedure MGA5-32-OK => has_procedure advisory MGA5-32-OK
An update for this issue has been pushed to the Mageia Updates repository. http://advisories.mageia.org/MGASA-2016-0184.html
Status: NEW => RESOLVEDResolution: (none) => FIXED