Exim 4.72 and earlier allows local users to gain privileges by leveraging the ability of the exim user account to specify an alternate configuration file with a directive that contains arbitrary commands, as demonstrated by the spooldirectory directive.
Double free vulnerability in libxml2 2.7.8 and other versions, as used in Google Chrome before 8.0.552.215 and other products, allows remote attackers to cause a denial of service or possibly have unspecified other impact via vectors related to XPath handling.
Description of problem: On parsing malformed X.25 facilities, decrementing the remaining length may cause it to underflow. Since the length is an unsigned integer, this will result in the loop continuing until the kernel crashes.
This patch adds checks to ensure decrementing the remaining length does not cause it to wrap around.
http://marc.info/?l=linux-netdev&m=128951543005554&w=2
Acknowledgements:
Red Hat would like to thank Dan Rosenberg for reporting this issue.
Statement:
This issue did not affect the versions of Linux kernel as shipped with Red Hat Enterprise Linux 4, 5, 6 and Red Hat Enterprise MRG as they did not include support for CCITT X.25 Packet Layer.
Description of problem:
When parsing a peer's supported HMAC authentication options in the sctpauthasocgethmac() function, a malicious peer can craft their HMAC array in such a way as to cause memory corruption (out-of-bounds read followed by use of retrieved out-of-bounds data), which at the very least could cause a denial of service via kernel panic, and possibly worse. It appears this could be triggered remotely when connecting to a malicious peer, or locally by a user acting as both endpoints. In both cases, the "authenable" sysctl must be set in order to trigger the bug.
References: http://marc.info/?l=oss-security&m=128619854321910&w=1 http://marc.info/?l=linux-kernel&m=128596992418814&w=2
Description of problem: sctppacketconfig() is called when getting the packet ready for appending of chunks. The function should not touch the current state, since it's possible to ping-pong between two transports when sending, and that can result packet corruption followed by skb overlfow crash.
Upstream commit: http://git.kernel.org/linus/4bdab43323b459900578b200a4b8cf9713ac8fab
Reference: http://marc.info/?l=linux-netdev&m=128453869227715&w=3 http://www.spinics.net/lists/linux-sctp/msg01051.html
Essentially, we are resetting the contents of the packet when it's not empty.
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: 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.
Sauli Pahlman of CERT-FI provided us with fuzzed PDF file which causes xpdf / poppler PDF parser to crash.
The crash is caused by an attempt to dereference uninitialized Gfx::parser pointer in Gfx::getPos(), which assumes parser is either NULL or valid Parser pointer.
http://cgit.freedesktop.org/poppler/poppler/tree/poppler/Gfx.cc?id=71063d51#n879
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.
Description of problem: Reported by Ang Way Chuang, Mauro Carvalho informed Red Hat about a security issue in the ULE decapsulation code.
ULE (Unidirectional Lightweight Encapsulation RFC 4326) decapsulation has a bug that causes endless loop when Payload Pointer of MPEG2-TS frame is 182 or 183. Anyone who sends malicious MPEG2-TS frame will cause the receiver of ULE SNDU to go into endless loop.
Acknowledgements:
Red Hat would like to thank Ang Way Chuang for reporting this issue.
Description of problem: The VM/VFS does not allow mapping->aops->invalidatepage() to fail. Unfortunately, nfswbpagecancel() may fail if a fatal signal occurs. Since the NFS code assumes that the page stays mapped for as long as the writeback is active, we can end up Oopsing (among other things).
The only safe fix here is to convert nfswaitonrequest(), so as to make it uninterruptible (as is already the case with waitonpagewriteback()).
Upstream commit: http://git.kernel.org/linus/9f557cd8073104b39528794d44e129331ded649f
The personality subsystem in the Linux kernel before 2.6.31-rc3 has a PERCLEARONSETID setting that does not clear the ADDRCOMPATLAYOUT and MMAPPAGEZERO flags when executing a setuid or setgid program, which makes it easier for local users to leverage the details of memory usage to (1) conduct NULL pointer dereference attacks, (2) bypass the mmapminaddr protection mechanism, or (3) defeat address space layout randomization (ASLR).
The streamreqbodycl function in modproxyhttp.c in the modproxy module in the Apache HTTP Server before 2.3.3, when a reverse proxy is configured, does not properly handle an amount of streamed data that exceeds the Content-Length value, which allows remote attackers to cause a denial of service (CPU consumption) via crafted requests.
François Guerraz reported in Debian BTS a possible DoS (CPU consumption) a DoS with moddeflate since it does not stop to compress large files even after the network connection has been closed. This allows to use large amounts of CPU if there is a largish file available that has moddeflate enabled.
Original report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534712
Post to the apache-httpd-dev mailing list: http://marc.info/?l=apache-httpd-dev&m=124621326524824&w=2
Multiple buffer overflows in the cifs subsystem in the Linux kernel before 2.6.29.4 allow remote CIFS servers to cause a denial of service (memory corruption) and possibly have unspecified other impact via (1) a malformed Unicode string, related to Unicode string area alignment in fs/cifs/sess.c; or (2) long Unicode characters, related to fs/cifs/cifssmb.c and the cifsreaddir function in fs/cifs/readdir.c.
A privilege escalation flaw was found in the way udev used to check for the origin of messages sent from the NETLINK service. An attacker could use this flaw to escalate his privileges by sending the NETLINK message from userspace process, instead of from the kernel.
Acknowledgements:
Red Hat would like to thank Sebastian Krahmer of the SUSE Security Team for responsibly reporting this flaw.
The Device Mapper multipathing driver (aka multipath-tools or device-mapper-multipath) 0.4.8, as used in SUSE openSUSE, SUSE Linux Enterprise Server (SLES), Fedora, and possibly other operating systems, uses world-writable permissions for the socket file (aka /var/run/multipathd.sock), which allows local users to send arbitrary commands to the multipath daemon.
From vendor-sec: Christian Borntraeger found a security relevant problem with the Linux system calls argument passing for at least s390, powerpc, sparc64 and mips:
The ABI for some architectures defines that the caller of a function has to sign extend each parameter to full register width. This is a problem in Linux system call handling.
For example with this system call on 64 bit:
asmlinkage long sysexample(unsigned int index) { if (index > 5) return -EINVAL; return examplearray[index]; }
It would mean that the caller has to sign extend index to 64 bit. In this case the caller is userspace. So we cannot rely on a correct sign extension.
But actually we just pass userspace delivered parameters unmodified to the system call function.
The above example could break like this:
The compiler can create code that will only test the lower 32 bits of the register that contain index to make sure its value is <= 5. However to access the memory location to get the value out of the array it can use the same unmodified (64 bit) register as index register, since the caller had to make sure that the upper 32 bits of the register contain zeroes. But since the value came from user space this isn't guaranteed and can lead to an addressing exception. Or userspace reads or even writes from/to memory locations it is not allowed to have access to.
Please note that this has nothing to do with compat system calls. This is an issue with 64 bit kernel and 64 bit userspace but 32 bit arguments.
Unfortunately the issue must be considered to be already public:
http://marc.info/?l=linux-kernel&m=123155111608910&w=2
Logic error in the SID/Name translation functionality in smbd in Samba 3.0.23d through 3.0.25pre2 allows local users to gain temporary privileges and execute SMB/CIFS protocol operations via unspecified vectors that cause the daemon to transition to the root user.