It was found that a malicious guest user could submit more requests than the virtqueue size permits, resulting in a crash of the host QEMU process.
The guest could submit requests without bothering to wait for completion and is therefore not bound by virtqueue size. This requires reusing vring descriptors in more than one request, which is incorrect but possible. Processing a request allocates a VirtQueueElement and therefore causes unbounded memory allocation controlled by the guest.
Exit with an error if the guest provides more requests than the virtqueue size permits. This bounds memory allocation and makes the buggy guest visible to the user.
Upstream patch -------------- -> git.qemu.org/?p=qemu.git;a=commit;h=afd9096eb1882f23929f5b5c177898ed231bac66
It was discovered that OpenSSL did not always use constant time operations when computing Digital Signature Algorithm (DSA) signatures. A local attacker could possibly use this flaw to obtain a private DSA key belonging to another user or service running on the same system.
A memory leak vulnerability was found in the way OpenSSL parsed PKCS#7 and CMS data. A remote attacker could use this flaw to cause an application that parses PKCS#7 or CMS data from untrusted sources to use an excessive amount of memory and possibly crash.
It was found that the Linux kernel KVM subsystem's sysenter instruction emulation was not sufficient.
An unprivileged guest user could use this flaw to escalate their privileges by tricking the hypervisor to emulate a SYSENTER instruction in 16-bit mode, if the guest OS does not initialize the SYSENTER MSRs.
Please note that the Red Hat Enterprise Linux with KVM certified guest operating systems do initialize the SYSENTER MSRs and are thus not vulnerable to this issue when running on KVM hypervisor.
References: http://www.openwall.com/lists/oss-security/2015/01/27/6
Upstream patch: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f3747379accba8e95d70cec0eae0582c8c182050
Acknowledgements:
Red Hat would like to thank Nadav Amit 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.
Last updated 24 July 2024
Unspecified vulnerability in Oracle Linux 4 and 5 allows remote authenticated users to affect confidentiality and integrity via unknown vectors related to "Oracle validated."