Bug 18462

Assigning to all packagers collectively, since there is no maintainer for this package.

CC: (none) => marja11
Assignee: bugsquad => pkg-bugs

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

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_update
CC: (none) => sysadmin-bugs

An update for this issue has been pushed to the Mageia Updates repository.

http://advisories.mageia.org/MGASA-2016-0184.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED