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 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 PHP where setting the environment variable PHPCLISERVERWORKERS to a large value leads to a heap buffer overflow.
IBM Resilient OnPrem could allow a local privileged attacker to obtain sensitive information due to improper or nonexisting encryption.
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.
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.
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.
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 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.
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.
It was found that EINJ, error injection mechanism, is allowed even if securelevel, a prevention from userspace performing actions that undermine trust in the platform, is enabled. This can have undesirable side-effects, such as causing the platform to mark hardware as needing replacement.
Product bug:
https://bugzilla.redhat.com/showbug.cgi?id=1321639
Upstream patch:
https://github.com/mjg59/linux/commit/d7a6be58edc01b1c66ecd8fcc91236bfbce0a420
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
It was reported that attempt to move page mapped by aio ring buffer to other node triggers NULL pointer dereference at tracewritebackdirtypage(), because aiofsbackingdevinfo.dev is 0.
Product bug (contains reproducer):
https://bugzilla.redhat.com/showbug.cgi?id=1306851
Upstream patch:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=42cb14b110a5698ccf26ce59c4441722605a3743
A vulnerability was found in kexec, allowing the attacker to bypass the security mechanism of securelevel/secureboot combination.
When the kernel was booted with UEFI Secure Boot enabled, securelevel is set. If kexec (either through crash or admin action) is then used to load the same kernel, after reboot securelevel is disabled. In this state, the system is missing the protections provided by securelevel, for example kexec may be used to load an unsigned kernel via the legacy system call kexecload. In the securelevel patchset, the state of UEFI Secure Boot is queried in the EFI stub, and sets a bootparams flag to indicate the state of UEFI Secure Boot. This flag is then used in setuparch() to determine the correct state of securelevel. If the kernel is not booted via the EFI stub, securelevel is not set even if UEFI Secure Boot is enabled.
Patch can be found in product bug:
https://bugzilla.redhat.com/showbug.cgi?id=1243998#c3
Upstream patch:
https://github.com/mjg59/linux/commit/4b2b64d5a6ebc84214755ebccd599baef7c1b798
CVE assignment:
http://seclists.org/oss-sec/2015/q4/85
It was found that if an NMI occurred immediately after a SYSCALL or before a SYSRET with the user RSP pointing to the NMI IST stack, the kernel could skip that NMI.
Upstream fix: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=810bc075f78ff2c221536eb3008eac6a492dba2d
Acknowledgements:
Red Hat would like to thank Andy Lutomirski for reporting this issue.
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.
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.
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.
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.
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 has been found in the way Linux kernel's KVM subsystem handled vcpu->arch.cr4 X86CR4OSXSAVE bit set upon guest enter. On hosts without the XSAVE feature an unprivileged local user could use this flaw to crash the system.
Acknowledgements:
Red Hat would like to thank Jon Howell for reporting this issue.
Description of the problem: The uname() syscall since 3.0 with the UNAME26 personality leaks kernel stack memory contents.
Acknowledgements:
Red Hat would like to thank Kees Cook for reporting this issue.
Dereferencing a user pointer directly from kernel-space without going through the copyfromuser family of functions is a bad idea. Two of such usages can be found in the sendmsg code path called from sendmmsg, added by upstream commit c71d8ebe7a4496fb7231151cb70a6baa0cb56f9a. Usages are performed through memcmp() and memcpy() directly.
Upstream fix: http://git.kernel.org/linus/bc909d9ddbf7778371e36a651d6e4194b1cc7d4c
Acknowledgements:
Red Hat would like to thank Tetsuo Handa for reporting this issue. Upstream acknowledges Mathieu Desnoyers as the original reporter.
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.
nfs4getfacl decoding causes a kernel Oops when a server returns more than 2 GETATTR bitmap words in response to the FATTR4ACL attribute request.
While the NFS client only asks for one attribute (FATTR4ACL) in the first bitmap word, the NFSv4 protocol allows for the server to return unbounded bitmaps.
Upstream commit: e5012d1f3861d18c7f3814e757c1c3ab3741dbcd - incomplete, handles only the case when 2 words are expected and 3 are returned
Proposed complete upstream patch: http://www.spinics.net/lists/linux-nfs/msg25288.html
Acknowledgements:
Red Hat would like to thank Andy Adamson for reporting this issue.
When interface is put in promiscuous mode and it receives VLAN packets, but no VLANS are configured on that interface , then the kernel crashes in the 8021q module.
Acknowledgements:
Red Hat would like to thank Somnath Kotur for reporting this issue.
Dan Kaminsky pointed out that using partial MD4 and using that to generate a sequence number, of which only 24-bits are truly unguessable, seriously undermine the goals of random sequence number generation.
In particular, with only 24-bits being truly unguessable, packet injection into a session using even something like brute force is a real potential possibility.
We only use 24-bits because we regenerate the random number every 5 minutes "just in case." But what does is trade a "we don't know" kind of theoretical issue for a provably real one (brute force attack).
Therefore [Dave Miller] moving us more in line with RFC1948 (as well as OpenBSD and Solaris), to use MD5 and a full 32-bit result in the generated sequence number.
MD5 was selected as a compromise between performance loss and theoretical ability to be compromised. Willy Tarreau did extensive testing and SHA1 was found to harm performance too much to be considered seriously at this time.
We may later add a sysctl for various modes (ie. a "super secure" mode that uses SHA1 if people want that, and an "insecure" mode that doesn't use cryptographic hashing at all for people in protected environments where that might be safe to do).
[Dave Miller] also moved the sequence number generators out of random.c (they never really belonged there, and are only there due to historical artifacts), and fixed a bug in DCCP sequence number generation (on ipv6 the 43-bit sequence number was truncated to 32-bits).
Acknowledgements:
Red Hat would like to thank Dan Kaminsky 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.
Andrea Righi reported a case where an exiting task can race against ksmd.
ksmscan.mmslot == the only registered mm CPU 1 (bug program) CPU 2 (ksmd) listempty() is false lock ksmscan.mmslot listdel unlock slot == &ksmmmhead (but list is now empty)
Close this race by revalidating that the new slot is not simply the list head again.
Reproducer: http://www.spinics.net/lists/linux-mm/msg20233.html Proposed patch: http://www.spinics.net/lists/linux-mm/msg20301.html
Acknowledgements:
Red Hat would like to thank Andrea Righi for reporting this issue.