Stack-based buffer overflow in NConvert 4.92, GFL SDK 2.82, and XnView 1.93.6 on Windows and 1.70 on Linux and FreeBSD allows user-assisted remote attackers to execute arbitrary code via a crafted format keyword in a Sun TAAC file.
IBM Security SOAR 51.0.2.0 could allow an authenticated user to execute malicious code loaded from a specially crafted script. IBM X-Force ID: 294830.
A flaw was found in Keycloak 4.2.1.Final, 4.3.0.Final. When TOPT enabled, an improper implementation of the Brute Force detection algorithm will not enforce its protection measures.
A vulnerability was found in OpenImageIO, where a heap buffer overflow exists in the src/gif.imageio/gifinput.cpp file. This flaw allows a remote attacker to pass a specially crafted file to the application, which triggers a heap-based buffer overflow and could cause a crash, leading to a denial of service.
A vulnerability was found in the RHEL7.2 kernel. When RHEL 7.2 is booted with UEFI Secure Boot enabled, securelevel is set. The kernel uses the state of securelevel to prevent userspace from inserting untrusted privileged code at runtime.
The ACPI tables provided by firmware can be overwritten using the initrd. From the kernel documentation:
If the ACPIINITRDTABLEOVERRIDE compile option is true, it is possible to override nearly any ACPI table provided by the BIOS with an instrumented, modified one.
RHEL 7.2 has CONFIGACPIINITRDTABLEOVERRIDE kernel config option enabled, and will load ACPI tables appended to the initrd, even if booted with UEFI Secure Boot enabled and securelevel set.
Upstream patch:
https://github.com/mjg59/linux/commit/a4a5ed2835e8ea042868b7401dced3f517cafa76
Due issue described in https://bugzilla.redhat.com/showbug.cgi?id=313681
open(OATOMICLOOKUP) leaks the dentry on the filesystems where drevalidate is implemented. i.e open ("/proc/self/exe", ORDONLY); open ("/proc/self/exe", ORDONLY | 02000000);
leaks one dentry.
By this way it's possible to eat all the memory on the node or overflow dentry->dcount.
Both RHEL4 and RHEL5 kernels are vulnerabled
Acknowledgements:
Red Hat would like to credit Vasily Averin for reporting this issue.
Description of problem: Reported by our customer, via IT#371682.
a flaw was found in the sctprcvootb() function in the Linux kernel Stream Control Transmission Protocol (SCTP) implementation. A remote attacker could send a specially-crafted SCTP packet to a target system, resulting in a denial of service.
Acknowledgements:
Red Hat would like to thank Telesys Software for responsibly reporting this issue.
Description of problem: When creating a high number of Bluetooth sockets (L2CAP, SCO and RFCOMM) it is possible to scribble repeatedly on arbitrary pages of memory. Ensure that the content of these sysfs files is always less than one page. Even if this means truncating. The files in question are scheduled to be moved over to debugfs in the future anyway.
Upstream patch: http://git.kernel.org/linus/101545f6fef4a0a3ea8daf0b5b880df2c6a92a69
Acknowledgements:
Red Hat would like to thank Neil Brown for reporting this issue.
Description of problem: The handling functions for sending and receiving messages, in rdspagecopyuser(), use the unchecked copyuserinatomic functions without any access checks on user-provided pointers. As a result, by passing a kernel address as an iovec base address in recvmsg-style calls, a local user can overwrite arbitrary kernel memory, which can easily be used to escalate privileges to root.
Introduced via 7875e18e (v2.6.30-rc1).
Acknowledgements:
Red Hat would like to thank Dan Rosenberg of Virtual Security Research for reporting this issue.
A race condition flaw has been found in the way asynchronous I/O and fallocate interacted which can lead to exposure of stale data -- that is, an extent which should have had the "uninitialized" bit set indicating that its blocks have not yet been written and thus contain data from a deleted file. An unprivileged local user could use this flaw to cause an information leak.
Acknowledgements:
Red Hat would like to thank Theodore Ts'o for reporting this issue. Upstream acknowledges Dmitry Monakhov as the original reporter.
References:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=dee1f973ca341c266229faa5a1a5bb268bed3531
A flaw was found in the way Linux kernel's iSCSI target processed large keys. If a key was larger than 64 bytes, as checked by iscsicheckkey(), the error response packet, generated by iscsiaddnotunderstoodresponse(), would still attempt to copy the entire key into the packet, overflowing the structure on the heap.
A remote attacker could use this flaw to escalate their privileges on the system.
Acknowledgements:
Red Hat would like to thank Kees Cook for reporting this issue.
The default vhost configuration file in Puppet before 3.6.2 does not include the SSLCARevocationCheck directive, which might allow remote attackers to obtain sensitive information via a revoked certificate when a Puppet master runs with Apache 2.4.
An uncontrolled resource consumption flaw has been discovered in redhat-certification in the way documents are loaded in DocumentBase:loadFiltered in the documentbase.py file. A remote attacker may provide an existing but invalid XML file which would be opened and never closed, possibly producing a Denial of Service.
A vulnerability was found in PHP where setting the environment variable PHPCLISERVERWORKERS to a large value leads to a heap buffer overflow.
A remote unauthorized disclosure of information vulnerability was identified in HPE Service Governance Framework (SGF) version 4.2, 4.3. A race condition under high load in SGF exists where SGF transferred different parameter to the enabler.
Keybase Desktop Client before 5.6.0 on Windows and macOS, and before 5.6.1 on Linux, allows an attacker to obtain potentially sensitive media (such as private pictures) in the Cache and uploadtemps directories. It fails to effectively clear cached pictures, even after deletion via normal methodology within the client, or by utilizing the "Explode message/Explode now" functionality. Local filesystem access is needed by the attacker.
A flaw was found in Keycloak 3.4.3.Final, 4.0.0.Beta2, 4.3.0.Final. When using 'responsemode=formpost' it is possible to inject arbitrary Javascript-Code via the 'state'-parameter in the authentication URL. This allows an XSS-Attack upon succesfully login.
IBM Resilient OnPrem could allow a local privileged attacker to obtain sensitive information due to improper or nonexisting encryption.
IBM Resilient OnPrem uses incomplete blocklisting for input validation which allows attackers to bypass application controls resulting in direct impact to the system and data integrity.
IBM Resilient SOAR V38.0 users may experience a denial of service of the SOAR Platform due to a insufficient input validation. IBM X-Force ID: 165589.
On systems with invept instruction support (corresponding bit in IA32VMXEPTVPIDCAP MSR is set) guest invocation of invept causes vm exit, which is currently not handled and causes unknown exit error to be propagated to userspace.
A local unprivileged guest user could use this flaw to crash the guest.
Upstream fix:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=bfd0a56b90005f8c8a004baf407ad90045c2b11e
Acknowledgements:
Red Hat would like to thank the Advanced Threat Research team at Intel Security for reporting this issue.
It was found that procnsfollowlink() doesn't return LASTBIND (unlike procpidfollowlink()) which leads to the slab corruption caused by (excessive) putname() in dofilpopen().
The slab corruption later manifests itself in the form of BUG() in cacheallocrefill() when performing "$ echo > /proc/$$/ns/pid" --
kernel BUG at mm/slab.c:3069! invalid opcode: 0000 [#1] SMP last sysfs file: /sys/devices/system/node/node0/meminfo CPU 1 Modules linked in: Pid: 2249, comm: bash Not tainted 2.6.32-431.5.1.el6.x8664 #1 RIP: 0010:[<ffffffff8116ed14>] [<ffffffff8116ed14>] cacheallocrefill+0x1e4/0x240 RSP: 0018:ffff88007b69fe38 EFLAGS: 00010082 RAX: 000000000000000c RBX: ffff88007ec30f00 RCX: 00000000ffffffff RDX: 000000000000000c RSI: 0000000000000000 RDI: ffff88007fa96580 RBP: ffff88007b69fe98 R08: 0000000000000000 R09: 000000000000002a R10: 0000000000000076 R11: 0000000000000000 R12: ffff88007fa96580 R13: ffff88007fae8c40 R14: 000000000000000c R15: ffff88007d9386c0 FS: 00007f6f8819b700(0000) GS:ffff88000c420000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000006d3d88 CR3: 00000000374d1000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process bash (pid: 2249, threadinfo ffff88007b69e000, task ffff8800379a5540) Stack: ffff88007b69fe58 00000000811a1edf ffff88007fae8c80 000412d07bdf1500 ffff88007fae8c60 ffff88007fae8c50 ffff88007b69feb8 0000000001440530 00000000000000d0 ffff88007ec30f00 00000000000000d0 0000000000000246 Call Trace: [<ffffffff8116fdcf>] kmemcachealloc+0x15f/0x190 [<ffffffff81196ff7>] getname+0x47/0x240 [<ffffffff81185ce2>] dosysopen+0x32/0x140 [<ffffffff81185e30>] sysopen+0x20/0x30 [<ffffffff8100b072>] systemcallfastpath+0x16/0x1b Code: 89 ff e8 70 57 12 00 eb 99 66 0f 1f 44 00 00 41 c7 45 60 01 00 00 00 4d 8b 7d 20 4c 39 7d c0 0f 85 f2 fe ff ff eb 84 0f 0b eb fe <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 eb f4 8b 55 ac 8b 75 bc 31 RIP [<ffffffff8116ed14>] cacheallocrefill+0x1e4/0x240 RSP <ffff88007b69fe38>
An unprivileged local user could use this flaw to crash the system. Upstream fix: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=86acdca1b63e6890540fa19495cfc708beff3d8b
Acknowledgements:
Red Hat would like to thank Vladimir Davydov of Parallels for reporting this issue.
Description of problem: The problem seams to be located in fs/binfmtelf.c:loadelfbinary(). It calls SETPERSONALITY() prior checking that the ELF interpreter is available. This in turn makes the previously 32 bit process a 64 bit one which would be fine if execve() would succeed. But after the SETPERSONALITY() the openexec() call fails (because it cannot find the interpreter) and execve() almost instantly returns with an error. If you now look at /proc/PID/maps you'll see, that it has the vsyscall page mapped which shouldn't be. But the process is not dead yet, it's still running. By now generating a segmentation fault and in turn trying to generate a core dump the kernel just dies.
Steps to Reproduce: 1. Enable core dumps 2. Start an 32 bit program that tries to execve() an 64 bit program 3. The 64 bit program cannot be started by the kernel because it can't find the interpreter, i.e. execve returns with an error 4. Generate a segmentation fault 5. panic
(EDIT: This is triggerable on 2.6.31.9-174.fc12.x8664).
Upstream commit: http://git.kernel.org/linus/221af7f87b97431e3ee21ce4b0e77d5411cf1549
Discussions: http://marc.info/?t=126466700200002&r=1&w=2
Acknowledgements:
Red Hat would like to thank Mathias Krause for reporting this issue.
Description of problem: A problem was found in the drivers/connector/connector.c code where users could send/allocate arbitrary amounts of NETLINKCONNECTOR messages to the kernel, causing OOM condition, killing selected processes or halting the system.
This is fixed in mainline commit f98bfbd78c37c5946cc53089da32a5f741efdeb7 by removing the code.
commit f98bfbd78c37c5946cc53089da32a5f741efdeb7 Author: Evgeniy Polyakov <zbr> Date: Tue Feb 2 15:58:48 2010 -0800
connector: Delete buggy notification code.
On Tue, Feb 02, 2010 at 02:57:14PM -0800, Greg KH (gregkh) wrote: > > There are at least two ways to fix it: using a big cannon and a small > > one. The former way is to disable notification registration, since it is > > not used by anyone at all. Second way is to check whether calling > > process is root and its destination group is -1 (kind of priveledged > > one) before command is dispatched to workqueue. > > Well if no one is using it, removing it makes the most sense, right? > > No objection from me, care to make up a patch either way for this?
Getting it is not used, let's drop support for notifications about (un)registered events from connector. Another option was to check credentials on receiving, but we can always restore it without bugs if needed, but genetlink has a wider code base and none complained, that userspace can not get notification when some other clients were (un)registered.
Kudos for Sebastian Krahmer <krahmer>, who found a bug in the code.
Signed-off-by: Evgeniy Polyakov <zbr> Acked-by: Greg Kroah-Hartman <gregkh> Signed-off-by: David S. Miller <davem>
Acknowledgements:
Red Hat would like to thank Sebastian Krahmer for reporting this issue.
Description of problem: Calling ETHTOOLGRXCLSRLALL with a large rulecnt will allocate kernel heap without clearing it. For the one driver (niu) that implements it, it will leave the unused portion of heap unchanged and copy the full contents back to userspace.
This is different from CVE-2010-2478, but was introduced at the same time (0853ad66, 2.6.27-rc1).
Upstream commit: http://git.kernel.org/linus/ae6df5f96a51818d6376da5307d773baeece4014
Acknowledgements:
Red Hat would like to thank Kees Cook for reporting this issue.
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.
Currently skbgroheaderslow unconditionally resets frag0 and frag0len. However, when we can't pull on the skb this leaves the GRO fields in an inconsistent state.
This patch fixes this by only resetting those fields after the pskbmaypull test.
Upstream commit: http://git.kernel.org/linus/17dd759c67f21e34f2156abcf415e1f60605a188
Acknowledgements: Red Hat would like to thank Brent Meshier for reporting this issue.
A signedness issue has been found in nextpidmap() function when the "last" parameter is negative as nextpidmap() just quietly accepted whatever "last" pid that was passed in, which is not all that safe when one of the users is /proc.
Setting fpos to negative value when accessing /proc via readdir()/getdents() resulted in sign extension of this value when map pointer was being constructed.
This later lead to #GP becasue the final pointer was not cannonical (x8664).
map = &pidns->pidmap[(last + 1)/BITSPERPAGE]; ffffffff810ac3b4: 48 63 f6 movslq %esi,%rsi <- sign extension (fpos+-) ffffffff810ac3b7: 81 e2 ff 7f 00 00 and $0x7fff,%edx ffffffff810ac3bd: 48 c1 ee 0f shr $0xf,%rsi ffffffff810ac3c1: 48 c1 e6 04 shl $0x4,%rsi ffffffff810ac3c5: 48 8d 5c 37 08 lea 0x8(%rdi,%rsi,1),%rbx ... if (unlikely(!map->page)) ffffffff810ac3cc: 48 8b 7b 08 mov 0x8(%rbx),%rdi <- #GP
Only x8664 architecture seems to be vulnerable to this particular issue (tested ppc64, s390x, ia64).
Reference: http://groups.google.com/group/fa.linux.kernel/browsethread/thread/93c1088451fd3522/4a28ecb7f755a88d?#4a28ecb7f755a88d
Upstream commit: http://git.kernel.org/linus/c78193e9 http://git.kernel.org/linus/d8bdc59f
Acknowledgements:
Red Hat would like to thank Robert Swiecki for reporting this issue.
On a corrupted file system the ->len field could be wrong leading to a buffer overflow.
https://lkml.org/lkml/2011/11/9/303
Upstream commit: http://git.kernel.org/linus/bc5b8a9003132ae44559edd63a1623
Acknowledgements:
Red Hat would like to thank Clement Lecigne for reporting this issue.