crypto: algifaead - Revert to operating out-of-place
Last updated 4 July 2026
The bufferslowrealign function in HAProxy 1.5.x before 1.5.14 and 1.6-dev does not properly realign a buffer that is used for pending outgoing data, which allows remote attackers to obtain sensitive information (uninitialized memory contents of previous requests) via a crafted request.
Last updated 24 July 2024
Last updated 24 July 2024
A flaw was found in the way pi to pi futex requeueing was handled.
A local unprivileged user can use this flaw to increase their privileges on the system.
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
It was discovered that libtasn1 library function asn1getbitder() could incorrectly report negative bit length of the value read from ASN.1 input. This could possibly lead to an out of bounds access in an application using libtasn1, for example in case if application tried to terminate read value with NUL byte.
The following upstream commit corrects the issue and causes the function to report error rather than return negative length value: http://git.savannah.gnu.org/cgit/libtasn1.git/commit/?id=1c3ccb3e040bf13e342ee60bc23b21b97b11923f
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
A flaw was found in the way the Linux kernel's floppy driver handled user space provided data in certain error code paths while processing FDRAWCMD IOCTL commands. A local user with write access to /dev/fdX could use this flaw to free (using the kfree() function) arbitrary kernel memory. (CVE-2014-1737, Important) It was found that the Linux kernel's floppy driver leaked internal kernel memory addresses to user space during the processing of the FDRAWCMD IOCTL command. A local user with write access to /dev/fdX could use this flaw to obtain information about the kernel heap arrangement. (CVE-2014-1738, Low) Note: A local user with write access to /dev/fdX could use these two flaws (CVE-2014-1737 in combination with CVE-2014-1738) to escalate their privileges on the system.
A flaw was found in the way Linux kernel's floppy driver treated userspace provided data in certain error code path while processing FDRAWCMD ioctl command. An local user with write access to /dev/fdX could use this flaw to kfree() arbitrary data. (CVE-2014-1737)
It was found that Linux kernel's floppy driver leaked internal kernel memory addresses to userspace during processing of FDRAWCMD ioctl command. An local user with write access to /dev/fdX could use this flaw to get information about kernel heap arrangment. (CVE-2014-1738)
An local user with write access to /dev/fdX could use these two flaws (CVE-2014-1737 in combination with CVE-2014-1738) to escalate their privileges on the system.
Acknowledgements:
Red Hat would like to thank Matthew Daley for reporting these issues.
A Linux kernel built with a Generic IEEE 802.11 Networking Stack (CONFIGMAC80211) is vulnerable to a crash caused by a race condition in frame transmission path and station wakeup event, in case when it's sleeping. The crash occurs because, mac80211 stack buffers frames when the station is sleeping, and the same are transmitted upon the station's(STA) wakeup. At this point, a buffered TX frame list is being emptied, while a new frame is being added to the RX list.
A remote unprivileged user/program could use this flaw to crash the system kernel, resulting in DoS.
Upstream fix: ------------- -> https://git.kernel.org/linus/1d147bfa64293b2723c4fec50922168658e613ba
Reference: ---------- -> http://seclists.org/oss-sec/2014/q2/7
Multiple directory traversal vulnerabilities in (1) modevhost and (2) modsimplevhost in lighttpd before 1.4.35 allow remote attackers to read arbitrary files via a .. (dot dot) in the host name, related to requestcheckhostname.
SQL injection vulnerability in modmysqlvhost.c in lighttpd before 1.4.35 allows remote attackers to execute arbitrary SQL commands via the host name, related to requestcheckhostname.
Last updated 24 July 2024
Last updated 24 July 2024
Last updated 24 July 2024
Last updated 24 July 2024
arch/x86/kvm/x86.c in the Linux kernel before 2.6.36.2 does not initialize certain structure members, which allows local users to obtain potentially sensitive information from kernel stack memory via read operations on the /dev/kvm device.
Description of problem: It requires debugfs to be mounted on a local system
$ mount | grep debugfs none on /sys/kernel/debug type debugfs (rw) none on /var/lib/ureadahead/debugfs type debugfs (rw,relatime)
Tested with Ubuntu Maverick 10.04.1 with kernel 2.6.32-24-generic-pae. It's probably not exploitable in any meaningful way, although it produces page fault in kernel mode, and makes subsequent processes opening /sys/kernel/debug/tracing/setftracefilter (or setftracenotrace) unkillable, so it's a little bit of a DoS (or at least, annoyance).
Found via one of Tavis Ormandy's tools, I just quickly analyzed it and provided a testcase.
Acknowledgements:
Red Hat would like to thank Robert Swiecki of Google Security Team for reporting this issue.
Description of problem: Discovered by Ben Hawkes, this patch adds a limit for nframes as the number of frames in TXSETUP and RXSETUP are derived from a single byte multiplex value by default. Use-cases that would require to send/filter more than 256 CAN frames should be implemented in userspace for complexity reasons anyway. Additionally the assignments of unsigned values from userspace to signed values in kernelspace and vice versa are fixed by using unsigned values in kernelspace consistently.
Upstream commit: http://git.kernel.org/linus/5b75c4973ce779520b9d1e392483207d6f842cde
Description of problem: There is a problem with the ioctl subsystem for drm, though it is most explicitly exposed by the intel GEM driver. Under driver-defined ioctls, drm does not sanitize the ioctl command, allowing the caller to specify how much memory should be kmalloc'd and copied back to the caller, regardless of what the driver ioctl actually does (it doesn't even need to succeed).
drivers/gpu/drm/drmdrv.c
long drmioctl(struct file filp, unsigned int cmd, unsigned long arg) ... unsigned int nr = DRMIOCTLNR(cmd); ... if ((nr >= DRMCOMMANDBASE) && (nr < DRMCOMMANDEND) && (nr < DRMCOMMANDBASE + dev->driver->numioctls)) ioctl = &dev->driver->ioctls[nr - DRMCOMMANDBASE]; ... if (cmd & (IOCIN | IOCOUT)) { if (IOCSIZE(cmd) <= sizeof(stackkdata)) { kdata = stackkdata; } else { kdata = kmalloc(IOCSIZE(cmd), GFPKERNEL); ... } } ... retcode = func(dev, kdata, filepriv); ... if (cmd & IOCOUT) { if (copytouser((void user )arg, kdata, IOCSIZE(cmd)) != 0) retcode = -EFAULT; }
"cmd" is caller-controlled, and can do whatever it likes for IOCSIZE(cmd), IOCIN and IOCOUT, resulting in leakage of previously freed kernel heap memory contents up to 16K in size.
Description of problem: The problem was in the way the gfs2 directory code was trying to re-use sentinel directory entries.
In the failing case, gfs2's rename function was renaming a file to another name that had the same non-trivial length. The file being renamed happened to be the first directory entry on the leaf block.
First, the rename code (gfs2rename in opsinode.c) found the original directory entry and decided it could do its job by simply replacing the directory entry with another. Therefore it determined correctly that no block allocations were needed.
Next, the rename code deleted the old directory entry prior to replacing it with the new name. Therefore, the soon-to-be replaced directory entry was temporarily made into a directory entry "sentinel" or a place holder at the start of a leaf block.
Lastly, it went to re-add the replacement directory entry in that leaf block. However, when gfs2direntfindspace was looking for space in the leaf block, it used the wrong value for the sentinel. That threw off its calculations so later it decides it can't really re-use the sentinel and therefore must allocate a new leaf block. But because it previously decided to re-use the directory entry, it didn't waste the time to grab a new block allocation for the inode. Therefore, the inode's ialloc pointer was still NULL and it crashes trying to reference it.
In the case of sentinel directory entries, the entire dirent is reused, not just the "free space" portion of it, and therefore the function gfs2direntfindspace should use the value 0 rather than GFS2DIRENTSIZE(0) for the actual dirent size.
Fixing this calculation enables the reproducer programs to work properly.
Description of problem: When transmitting L2TP frames, we derive the outgoing interface's UDP checksum hardware assist capabilities from the tunnel dst dev. This can sometimes be NULL, especially when routing protocols are used and routing changes occur. This patch just checks for NULL dst or dev pointers when checking for netdev hardware assist features. BUG: unable to handle kernel NULL pointer dereference at 0000000c IP: [<f89d074c>] pppol2tpxmit+0x341/0x4da [pppol2tp] pde = 00000000 Oops: 0000 [#1] SMP last sysfs file: /sys/class/net/lo/operstate Modules linked in: pppol2tp pppox pppgeneric slhc ipv6 dummy loop sndhdacodecatihdmi sndhdaintel sndhdacodec snd [...] Code: 8d 45 08 f0 ff 45 08 89 6b 08 c7 43 68 7e fb 9c f8 8a 45 24 83 e0 0c 3c 04 75 09 80 63 64 f3 e9 b4 00 00 00 8b 43 1 EIP: [<f89d074c>] pppol2tpxmit+0x341/0x4da [pppol2tp] SS:ESP 0068:f70a9cac CR2: 000000000000000c
Introduced in ffcebb16 (v2.6.29-rc1~581), fixed in 3feec909 (fixed in v2.6.34-rc2).
Upstream commit: http://git.kernel.org/linus/ffcebb16 http://git.kernel.org/linus/3feec909
Description of problem: Reported by Toshiyuki Okajima. With linux-2.6.34-rc5, findkeyringbyname() can gain the keyring which has been already freed. And then, its space (which is gained by findkeyringbyname()) is broken by accessing the freed keyring as the available keyring:
1) If the space of the freed keyring is reallocated for other purpose (ie. filp SLUB), the data of the filp object may be destroyed by the user of the freed keyring. (SLUB configuration can share the freed space with other same-size slabs.)
2) If the slab space of the freed keyring is released into the system, the system panic may happen because accessing the space of the freed keyring causes the page-fault.
Example: (we can easily confirm this problem if CONFIGSLUB is "y".) [1] with CONFIGSLUBDEBUGON While we are executing my reproducer (which is attached), we can notice that the user of the freed keyring breaks its space: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ./reproducer & ... dmesg ... ============================================================================= BUG keyjar: Poison overwritten -----------------------------------------------------------------------------
INFO: 0xffff880197a7e200-0xffff880197a7e200. First byte 0x6a instead of 0x6b INFO: Allocated in keyalloc+0x10b/0x35f age=25 cpu=1 pid=5086 INFO: Freed in keycleanup+0xd0/0xd5 age=12 cpu=1 pid=10 INFO: Slab 0xffffea000592cb90 objects=16 used=2 fp=0xffff880197a7e200 flags=0x200000000000c3 INFO: Object 0xffff880197a7e200 @offset=512 fp=0xffff880197a7e300
Bytes b4 0xffff880197a7e1f0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ Object 0xffff880197a7e200: 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b jkkkkkkkkkkkkkkk Object 0xffff880197a7e210: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff880197a7e220: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff880197a7e230: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff880197a7e240: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff880197a7e250: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff880197a7e260: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff880197a7e270: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff880197a7e280: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object 0xffff880197a7e290: 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkk� Redzone 0xffff880197a7e298: bb bb bb bb bb bb bb bb �������� Padding 0xffff880197a7e2d8: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ Padding 0xffff880197a7e2e8: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ Padding 0xffff880197a7e2f8: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ Pid: 5090, comm: su Not tainted 2.6.34-rc5-nofixed #1 Call Trace: [<ffffffff810e3e9c>] ? checkbytesandreport+0xb5/0xe6 [<ffffffff81152994>] ? keyalloc+0x10b/0x35f [<ffffffff810e3f8f>] ? checkobject+0xc2/0x1a4 [<ffffffff810e5c09>] ? slaballoc+0x2ff/0x3a6 [<ffffffff81152994>] ? keyalloc+0x10b/0x35f [<ffffffff81152780>] ? keyuserlookup+0x78/0x181 [<ffffffff81152994>] ? keyalloc+0x10b/0x35f [<ffffffff810e658a>] ? kmemcachealloc+0x75/0xe9 [<ffffffff81152994>] ? keyalloc+0x10b/0x35f [<ffffffff8115360a>] ? keyringalloc+0x29/0x61 [<ffffffff81155897>] ? installuserkeyrings+0x99/0x168 [<ffffffff81155ae6>] ? lookupuserkey+0x180/0x30a [<ffffffff81153eaf>] ? keyctlgetkeyringID+0x15/0x38 [<ffffffff81008a02>] ? systemcallfastpath+0x16/0x1b FIX keyjar: Restoring 0xffff880197a7e200-0xffff880197a7e200=0x6b
FIX keyjar: Marking all objects used ============================================================================= BUG keyjar: Poison overwritten ----------------------------------------------------------------------------- ... - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[2] without CONFIGSLUBDEBUGON While we are executing my reproducer (which is attached), we may find such the back-trace at the system panic: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ls -l /sys/kernel/slab total 0 drwxr-xr-x 2 root root 0 Apr 21 00:45 :at-0000016 ... lrwxrwxrwx 1 root root 0 Apr 21 00:45 credjar -> :t-0000192 ... lrwxrwxrwx 1 root root 0 Apr 21 00:45 filp -> :t-0000192 ... lrwxrwxrwx 1 root root 0 Apr 21 00:45 keyjar -> :t-0000192 ... lrwxrwxrwx 1 root root 0 Apr 21 00:45 kmalloc-192 -> :t-0000192 ...
./reproducer.sh (PANIC) <1>BUG: unable to handle kernel NULL pointer dereference at 0000000000000001 <1>IP: [<ffffffff810e61a3>] kmemcachealloc+0x5b/0xe9 <4>PGD 6b2b4067 PUD 6a80d067 PMD 0 <0>Oops: 0000 [#1] SMP <0>last sysfs file: /sys/kernel/kexeccrashloaded <4>CPU 1 <4>Modules linked in: nfsd lockd nfsacl authrpcgss exportfs sunrpc autofs4 ipv6 ext4 jbd2 dmmirror dmregionhash dmlog dmmul tipath uinput shpchp i2ci801 ppdev parportpc e752xedac edaccore i2ccore tg3 iTCOwdt iTCOvendorsupport parport pcspkr ext3 jbd mbcache atageneric pataacpi megaraidmbox megaraidmm atapiix floppy dmmod [last unloaded: scsiwaitscan] <4>Pid: 31245, comm: su Not tainted 2.6.34-rc5-nofixed-nodebug #2 D2089/PRIMERGY <4>RIP: 0010:[<ffffffff810e61a3>] [<ffffffff810e61a3>] kmemcachealloc+0x5b/0xe9 <4>RSP: 0018:ffff88006af3bd98 EFLAGS: 00010002 <4>RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88007d19900b <4>RDX: 0000000100000000 RSI: 00000000000080d0 RDI: ffffffff81828430 <4>RBP: ffffffff81828430 R08: ffff88000a293750 R09: 0000000000000000 <4>R10: 0000000000000001 R11: 0000000000100000 R12: 00000000000080d0 <4>R13: 00000000000080d0 R14: 0000000000000296 R15: ffffffff810f20ce <4>FS: 00007f97116bc700(0000) GS:ffff88000a280000(0000) knlGS:0000000000000000 <4>CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>CR2: 0000000000000001 CR3: 000000006a91c000 CR4: 00000000000006e0 <4>DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 <4>DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 <4>Process su (pid: 31245, threadinfo ffff88006af3a000, task ffff8800374414c0) <0>Stack: <4> 0000000512e0958e 0000000000008000 ffff880037f8d180 0000000000000001 <4><0> 0000000000000000 0000000000008001 ffff88007d199000 ffffffff810f20ce <4><0> 0000000000008000 ffff88006af3be48 0000000000000024 ffffffff810face3 <0>Call Trace: <4> [<ffffffff810f20ce>] ? getemptyfilp+0x70/0x12f <4> [<ffffffff810face3>] ? dofilpopen+0x145/0x590 <4> [<ffffffff810ce208>] ? tlbfinishmmu+0x2a/0x33 <4> [<ffffffff810ce43c>] ? unmapregion+0xd3/0xe2 <4> [<ffffffff810e4393>] ? virttoheadpage+0x9/0x2d <4> [<ffffffff81103916>] ? allocfd+0x69/0x10e <4> [<ffffffff810ef4ed>] ? dosysopen+0x56/0xfc <4> [<ffffffff81008a02>] ? systemcallfastpath+0x16/0x1b <0>Code: 0f 1f 44 00 00 49 89 c6 fa 66 0f 1f 44 00 00 65 4c 8b 04 25 60 e8 00 00 48 8b 45 00 49 01 c0 49 8b 18 48 85 db 74 0d 48 63 45 18 <48> 8b 04 03 49 89 00 eb 14 4c 89 f9 83 ca ff 44 89 e6 48 89 ef <1>RIP [<ffffffff810e61a3>] kmemcachealloc+0x5b/0xe9 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[reproducer.sh] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - #!/bin/sh
LOOP=100000 USER=dummyuser add /bin/su -c "exit;" $USER || { /usr/sbin/adduser -m $USER; add=1; }
for ((i=0; i<LOOP; i++)) do /bin/su -c "echo '$i' > /dev/null" $USER done
del (( add == 1 )) && /usr/sbin/userdel -r $USER exit - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
I created the patch which fixes this problem. (I attach it into the following mail. And I couldn't see the "Poison" lines of dmesg with the fixed kernel while I was executing my reproducer. So, this problem seems to be fixed by this patch.) This problem is serious because it may trigger the user data destructions.