A vulnerability was found in PHP where setting the environment variable PHPCLISERVERWORKERS to a large value leads to a heap buffer overflow.

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.

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.

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.

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.

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.

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.

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

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.

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 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.

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.

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.

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.

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.

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.

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.

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.

While mm->startstack was protected from cross-uid viewing (commit f83ce3e6b02d5e48b3a43b001390e2b58820389d), the startcode and endcode values were not. This would allow the text location of a PIE binary to leak, defeating ASLR.

Note that the value "1" is used instead of "0" for a protected value since "ps", "killall", and likely other readers of /proc/pid/stat, take startcode of "0" to mean a kernel thread and will misbehave. Thanks to Brad Spengler for pointing this out.

https://lkml.org/lkml/2011/3/11/380

Acknowledgements:

Red Hat would like to thank Kees Cook 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.