A NULL pointer dereference flaw was found in libtasn1's asn1readvaluetype() / asn1readvalue() function. If an application called the function with a NULL value for an ivalue argument to determine the amount of memory needed to store data to be read from the ASN.1 input, libtasn1 could incorrectly attempt to dereference the NULL pointer, causing an application using the library to crash.
The libtasn1 library is used by the GnuTLS library to parse X.509 certificates. The gnutls packages in Red Hat Enterprise Linux 5 and earlier use bundled libtasn1, packages in Red Hat Enterprise Linux 6 and later depend on the library provided by a separate libtasn1 package.
Upstream commits: http://git.savannah.gnu.org/cgit/libtasn1.git/commit/lib/element.c?id=a8b3e14f84174e01755bfd1be5448fffce7c9ffa http://git.savannah.gnu.org/cgit/libtasn1.git/commit/lib/element.c?id=3d6a02f19ff15a38dae9686033e37499b3968256 http://git.savannah.gnu.org/cgit/libtasn1.git/commit/lib/element.c?id=53958290ab731c8486531a3bdef54a933533579d
Multiple buffer boundary check issues were discovered in libtasn1 library, causing it to read beyond the boundary of an allocated buffer. An untrusted ASN.1 input could cause an application using the library to crash.
The libtasn1 library is used by the GnuTLS library to parse X.509 certificates. The gnutls packages in Red Hat Enterprise Linux 5 and earlier use bundled libtasn1, packages in Red Hat Enterprise Linux 6 and later depend on the library provided by a separate libtasn1 package.
Upstream commits: http://git.savannah.gnu.org/cgit/libtasn1.git/commit/?id=ff3b5c68cc32e30d19edbbc3a962b2266029f3cc http://git.savannah.gnu.org/cgit/libtasn1.git/commit/?id=0e80d79db71747644394fe3472dad28cd3e7b00b http://git.savannah.gnu.org/cgit/libtasn1.git/commit/?id=154909136c12cfa5c60732b7210827dfb1ec6aee http://git.savannah.gnu.org/cgit/libtasn1.git/commit/?id=37a16434131c6ad8745b9accefec5cecb4cbb5b7 http://git.savannah.gnu.org/cgit/libtasn1.git/commit/?id=cc10a8c5443c751d920cfaca1f104089e43296be http://git.savannah.gnu.org/cgit/libtasn1.git/commit/?id=6fee6745b1bd1a82f16ae9b607855a3e3ab39fc6 http://git.savannah.gnu.org/cgit/libtasn1.git/commit/?id=af0e8cd0bacf47ecce049165d3bc1ed9e861df1c http://git.savannah.gnu.org/cgit/libtasn1.git/commit/?id=609d5c1366fb424f6150c4eed358d246e61cf204 http://git.savannah.gnu.org/cgit/libtasn1.git/commit/?id=51612fca32dda445056ca9a7533bae258acd3ecb
The pngdecompresschunk function in pngrutil.c in libpng 1.0.x before 1.0.53, 1.2.x before 1.2.43, and 1.4.x before 1.4.1 does not properly handle compressed ancillary-chunk data that has a disproportionately large uncompressed representation, which allows remote attackers to cause a denial of service (memory and CPU consumption, and application hang) via a crafted PNG file, as demonstrated by use of the deflate compression method on data composed of many occurrences of the same character, related to a "decompression bomb" attack.
Last updated 24 July 2024
The kgacceptkrb5 function in krb5/acceptseccontext.c in the GSS-API library in MIT Kerberos 5 (aka krb5) through 1.7.1 and 1.8 before 1.8.2, as used in kadmind and other applications, does not properly check for invalid GSS-API tokens, which allows remote authenticated users to cause a denial of service (NULL pointer dereference and daemon crash) via an AP-REQ message in which the authenticator's checksum field is missing.
A memory leak was found in the way libpng processed malformed Portable Network Graphics (PNG) images with Physical Scale (sCAL) extension. A remote attacker could create a specially-crafted PNG image and trick the local user into opening it in an application, using the libpng library, leading to denial of service (relevant libpng-based application crash).
References: [1] http://www.libpng.org/pub/png/libpng.html
CVE Request: [2] http://www.openwall.com/lists/oss-security/2010/06/28/2
It was reported [1] that iptables can allow protocols that do not have a protocol handler kernel module loaded.
Given following iptables ruleset: -P FORWARD DROP -A FORWARD -m sctp --dport 9 -j ACCEPT -A FORWARD -p tcp --dport 80 -j ACCEPT -A FORWARD -p tcp -m conntrack -m state ESTABLISHED,RELATED -j ACCEPT
One would assume that this allows SCTP on port 9 and TCP on port 80. Unfortunately, if the SCTP conntrack module is not loaded, this allows all SCTP communication to pass through, i.e. -p sctp -j ACCEPT
[1]: http://www.spinics.net/lists/netfilter-devel/msg33430.html
Integer overflow in the btrfsioctlclone function in fs/btrfs/ioctl.c in the Linux kernel before 2.6.35 might allow local users to obtain sensitive information via a BTRFSIOCCLONERANGE ioctl call.
Description of problem: BUG: unable to handle kernel NULL pointer dereference at 00000004 IP: [<f7f06dca>] hashbindelete+0x14/0xad [irda] pdpt = 0000000000a57001 pde = 0000000000000000 Oops: 0000 [#1] SMP last sysfs file: /sys/devices/virtual/dmi/id/sysvendor Modules linked in: irda crcccitt fuse ip6tREJECT nfconntrackipv6 ip6tablefilter ip6tables ipv6 vmblock vsock vmmemctl vmhgfs uinput pcnet32 ppdev vmxnet microcode parportpc parport mii vmci i2cpiix4 i2ccore mptspi mptscsih mptbase scsitransportspi [last unloaded: scsiwaitscan]
Pid: 2403, comm: a.out Not tainted 2.6.33.6-147.2.4.fc13.i686.PAE #1 440BX Desktop Reference Platform/VMware Virtual Platform EIP: 0060:[<f7f06dca>] EFLAGS: 00010282 CPU: 0 EIP is at hashbindelete+0x14/0xad [irda] EAX: 00000000 EBX: 00000000 ECX: f2f97f4c EDX: f7f084aa ESI: df1b8800 EDI: f7f084aa EBP: eb19bd78 ESP: eb19bd64 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Process a.out (pid: 2403, ti=eb19a000 task=f2ed9980 task.ti=eb19a000) Stack: 00000000 00000202 eb0df2c0 df1b8800 df1a6770 eb19bd84 f7f085f5 eb0df2c0 <0> eb19bd90 f7f0861f eb20c400 eb19bda4 f7f0a958 df1b8800 f7f0ebe4 df1a6770 <0> eb19bdb4 c06ef16e f2e21100 00000008 eb19bdbc c06ef1cf eb19bde0 c04d183a Call Trace: [<f7f085f5>] ? iriasdeleteobject+0x1b/0x2c [irda] [<f7f0861f>] ? iriasdeleteobject+0x19/0x1e [irda] [<f7f0a958>] ? irdarelease+0x65/0x127 [irda] [<c06ef16e>] ? sockrelease+0x14/0x59 [<c06ef1cf>] ? sockclose+0x1c/0x20 [<c04d183a>] ? fput+0xea/0x181 [<c04d18e4>] ? fput+0x13/0x15 [<c04cef5f>] ? filpclose+0x51/0x5b [<c043f260>] ? putfilesstruct+0x5f/0xb3 [<c043f2e8>] ? exitfiles+0x34/0x38 [<c0440a1b>] ? doexit+0x200/0x615 [<c044c4c0>] ? dequeuesignal+0xb1/0x120 [<c0440e9b>] ? dogroupexit+0x6b/0x94 [<c044c89d>] ? getsignaltodeliver+0x36e/0x389 [<c0407cd4>] ? dosignal+0x5a/0x6f4 [<c078359d>] ? apictimerinterrupt+0x31/0x38 [<c0455f57>] ? hrtimernanosleep+0x94/0xdc [<c04d7376>] ? pathput+0x15/0x18 [<c047c6a6>] ? auditsyscallexit+0xfa/0x10f [<c040838d>] ? donotifyresume+0x1f/0x79 [<c07831e4>] ? worknotifysig+0x13/0x1b Code: 04 01 74 0b 8b 55 f0 8d 43 0c e8 b8 bf 87 c8 83 c4 0c 5b 5e 5f 5d c3 55 89 e5 57 89 d7 56 53 89 c3 83 ec 08 c7 45 ec 00 00 00 00 <f6> 40 04 01 74 0b 8d 40 0c e8 40 bf 87 c8 89 45 ec 89 de c7 45 EIP: [<f7f06dca>] hashbindelete+0x14/0xad [irda] SS:ESP 0068:eb19bd64 CR2: 0000000000000004 ---[ end trace 8c5fb89ec896b3a8 ]--- Fixing recursive fault but reboot is needed!
Acknowledgements:
Red Hat would like to thank Tavis Ormandy for reporting this issue.
drivers/media/video/v4l2-compat-ioctl32.c in the Video4Linux (V4L) implementation in the Linux kernel before 2.6.36 on 64-bit platforms does not validate the destination of a memory copy operation, which allows local users to write to arbitrary kernel memory locations, and consequently gain privileges, via a VIDIOCSTUNER ioctl call on a /dev/video device, followed by a VIDIOCSMICROCODE ioctl call on this device.
Last updated 24 July 2024
Description of problem: Upstream commit dab5855 ("perfcounter: Add mmap event hooks to mprotect()") is fundamentally wrong as mprotectfixup() can free 'vma' due to merging. Fix the problem by moving perfeventmmap() hook to mprotectfixup(). In certain scenario, a local, unprivileged user could use this flaw to trigger a denial of service.
Upstream commit: http://git.kernel.org/linus/63bfd7384b119409685a17d5c58f0b56e5dc03da
By submitting certain I/O requests with 0 length, a local user could cause a kernel panic.
Proposed patch: http://git.kernel.org/?p=linux/kernel/git/axboe/linux-2.6-block.git;a=commit;h=9284bcf4e335e5f18a8bc7b26461c33ab60d0689
Acknowledgements:
Red Hat would like to thank Dan Rosenberg for reporting this issue.
Due to integer underflow and overflow issues when determining the number of pages required for maliciously crafted I/O requests, a local user could send a device ioctl that results in the sequential allocation of a very large number of pages, causing the OOM killer to be invoked and crashing the system:
Proposed patch: http://git.kernel.org/?p=linux/kernel/git/axboe/linux-2.6-block.git;a=commit;h=cb4644cac4a2797afc847e6c92736664d4b0ea34
Acknowledgements:
Red Hat would like to thank Dan Rosenberg for reporting this issue.
Last updated 24 July 2024
Description of problem: gdthioctlalloc() takes the size variable as an int. copyfromuser() takes the size variable as an unsigned long. gen.datalen and gen.senselen are unsigned longs. On x8664 longs are 64 bit and ints are 32 bit.
We could pass in a very large number and the allocation would truncate the size to 32 bits and allocate a small buffer. Then when we do the copyfromuser(), it would result in a memory corruption.
Reference: http://ns3.spinics.net/lists/linux-scsi/msg47361.html
Upstream: http://git.kernel.org/linus/f63ae56e4e97fb12053590e41a4fa59e7daa74a4
Description of problem: Both PPPoL2TP (in net/l2tp/l2tpppp.c, pppol2tpsendmsg()) and IPoL2TP (in net/l2tp/l2tpip.c, l2tpipsendmsg()) make calls to sockwmalloc() that perform arithmetic on the size argument without any maximum bound. As a result, by issuing sendto() calls with very large sizes, this allocation size will wrap and result in a small buffer being allocated, leading to ugliness immediately after (probably kernel panics due to bad skbuff tail position, but possibly kernel heap corruption).
Reference: http://www.spinics.net/lists/netdev/msg145673.html
Acknowledgements:
Red Hat would like to thank Dan Rosenberg for reporting this issue.
Description of problem: In bcmconnect() (in net/can/bcm.c), there is the following code:
sprintf(bo->procname, "%p", sock);
"procname" is a 9-byte char array. On 64-bit platforms, up to 17 bytes may be copied into the buffer. Fortunately, structure padding will most likely prevent this from being a problem, except for the trailing NULL byte, which may overwrite the first byte of the next heap object.
Reference: http://www.spinics.net/lists/netdev/msg145791.html
Acknowledgements:
Red Hat would like to thank Dan Rosenberg for reporting this issue.
Description of problem: The PKTCTRLCMDSTATUS device ioctl retrieves a pointer to a pktcdvddevice from the global pktdevs array. The index into this array is provided directly by the user and is a signed integer, so the comparison to ensure that it falls within the bounds of this array will fail when provided with a negative index.
This can be used to read arbitrary kernel memory or cause a crash due to an invalid pointer dereference. This can be exploited by users with permission to open /dev/pktcdvd/control (on many distributions, this is readable by group "cdrom").
Upstream commit: http://git.kernel.org/linus/252a52aa4fa22a668f019e55b3aac3ff71ec1c29
Last updated 24 July 2024
Description of problem: If the donor file is an append-only file, we should not allow the operation to proceed, lest we end up overwriting the contents of an append-only file.
Upstream commit: http://git.kernel.org/linus/1f5a81e41f8b1a782c68d3843e9ec1bfaadf7d72
The jpccrggetparms function in libjasper/jpc/jpccs.c in JasPer 1.900.1 uses an incorrect data type during a certain size calculation, which allows remote attackers to trigger a heap-based buffer overflow and execute arbitrary code, or cause a denial of service (heap memory corruption), via a crafted component registration (CRG) marker segment in a JPEG2000 file.
Integer signedness error in the pixmanfillsse2 function in pixman-sse2.c in Pixman, as distributed with Cairo and used in Mozilla Firefox before 20.0, Firefox ESR 17.x before 17.0.5, Thunderbird before 17.0.5, Thunderbird ESR 17.x before 17.0.5, SeaMonkey before 2.17, and other products, allows remote attackers to execute arbitrary code via crafted values that trigger attempted use of a (1) negative box boundary or (2) negative box size, leading to an out-of-bounds write operation.
The kdump implementation is missing the host key verification in the kdump and mkdumprd OpenSSH integration of kdump prior to version 2012-01-20. This is similar to CVE-2011-3588, but different in that the kdump implementation is specific to SUSE. A remote malicious kdump server could use this flaw to impersonate the correct kdump server to obtain security sensitive information (kdump core files).
NetworkManager 0.9.x does not pin a certificate's subject to an ESSID when 802.11X authentication is used.
libxml2 before 2.7.8, as used in Google Chrome before 7.0.517.44, Apple Safari 5.0.2 and earlier, and other products, reads from invalid memory locations during processing of malformed XPath expressions, which allows context-dependent attackers to cause a denial of service (application crash) via a crafted XML document.
Cross-site scripting (XSS) vulnerability in editing/markup.cpp in WebCore in WebKit in Google Chrome before 5.0.375.70 allows remote attackers to inject arbitrary web script or HTML via vectors related to the node.innerHTML property of a TEXTAREA element. NOTE: this might overlap CVE-2010-1762.
A number of vulnerabilities were found and reported by CERT in JasPer which may allow a remote unauthenticated attacker to execute arbitrary code.
Reference: http://www.kb.cert.org/vuls/id/887409
Integer overflow in libpng, as used in Google Chrome before 17.0.963.56, allows remote attackers to cause a denial of service or possibly have unspecified other impact via unknown vectors that trigger an integer truncation.
ftpd.c in the GSS-API FTP daemon in MIT Kerberos Version 5 Applications (aka krb5-appl) 1.0.1 and earlier does not check the krb5setegid return value, which allows remote authenticated users to bypass intended group access restrictions, and create, overwrite, delete, or read files, via standard FTP commands, related to missing autoconf tests in a configure script.