Quoting from URL:
The libraries for the scientific data file format, Common Data Format (CDF) version 3.2 and earlier, have the potential for a buffer overflow vulnerability when reading specially-crafted (invalid) CDF files. If successful, this could trigger execution of arbitrary code within the context of the CDF-reading program that could be exploited to compromise a system, or otherwise crash the program. While it's unlikely that you would open CDFs from untrusted sources, we recommend everyone upgrade to the latest CDF libraries on their systems, including the IDL and Matlab plugins. Most worrisome is any service that enables the general public to submit CDF files for processing.
The vulnerability is in the CDF library routines not properly checking the length tags on a CDF file before copying data to a stack buffer. Exploitation requires the user to explicitly open a specially-crafted file. CDF users should not open files from untrusted third parties until the patch is applied (and continue then to exercise normal caution for files from untrusted third parties).
CDF 3.2.1 addresses this vulnerability and introduces further usability fixes. Updates for Perl, IDL, Matlab and Java WebStart are also available. Java WebStart applications that refer to http://sscweb.gsfc.nasa.gov/skteditor/cdf/cdf-latest.jnlp, will automatically be updated to include this fix the next time the application is started while connected to the Internet.
This is public now:
cdf-3.2.1.ebuild just committed. cdf-3.2 removed, and waiting for fast-track stabilization on 3.2.1 to remove cdf-3.1.
(In reply to comment #4)
> cdf-3.2.1.ebuild just committed. cdf-3.2 removed, and waiting for fast-track
> stabilization on 3.2.1 to remove cdf-3.1.
Thanks much Sebastien! I was just in the middle of fixing this myself;)
Why on earth didn't upstream at least rename their tarballs to to 3.2.1
instead of just re-distributing a patched 3.2 version?
Arches, please test and mark stable:
Target keywords : "amd64 ppc release x86"
*** Bug 220591 has been marked as a duplicate of this bug. ***
did they change the tarballs again?
ftp://cdaweb.gsfc.nasa.gov/pub/cdf/dist/cdf321/unix/ changed date on 2008-05-06 which was yesterday...
# emerge --fetchonly cdf
Calculating dependencies... done!
>>> Emerging (1 of 1) sci-libs/cdf-3.2.1 to /
>>> Downloading 'ftp://cdaweb.gsfc.nasa.gov/pub/cdf/dist/cdf321/unix/cdf32-dist-cdf.tar.gz'
--2008-05-07 21:58:04-- ftp://cdaweb.gsfc.nasa.gov/pub/cdf/dist/cdf321/unix/cdf32-dist-cdf.tar.gz
Resolving cdaweb.gsfc.nasa.gov... 188.8.131.52
Connecting to cdaweb.gsfc.nasa.gov|184.108.40.206|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD /pub/cdf/dist/cdf321/unix ... done.
==> SIZE cdf32-dist-cdf.tar.gz ... 966514
==> PASV ... done. ==> RETR cdf32-dist-cdf.tar.gz ... done.
Length: 966514 (944K)
100%[===================================================================================================================>] 966,514 226K/s in 4.5s
2008-05-07 21:58:28 (208 KB/s) - `/usr/portage/distfiles/cdf32-dist-cdf.tar.gz' saved 
('Filesize does not match recorded size', 966514L, 966480)
!!! Fetched file: cdf32-dist-cdf.tar.gz VERIFY FAILED!
!!! Reason: Filesize does not match recorded size
!!! Got: 966514
!!! Expected: 966480
Refetching... File renamed to '/usr/portage/distfiles/cdf32-dist-cdf.tar.gz._checksum_failure_.lJLiKk'
!!! Couldn't download 'cdf32-dist-cdf.tar.gz'. Aborting.
(In reply to comment #9)
> did they change the tarballs again?
Yes they did! I removed the mirror restriction and suggested upstream to fix this.
Please go for stabilization on cdf-3.2.1-r1 I've just committed.
Upstream finally changed their tar balls, and 3.2.1 had a bad patch.
Fixed in release snapshot.
GLSA request filed.