A flaw was found in the way memory was being allocated on the stack for user space binaries. If heap and stack memory regions were adjacent to each other, an attacker could use this flaw to jump over the heap/stack gap, cause controlled memory corruption on process stack or heap, and thus increase their privileges on the system.
This is a tracking bug for the glibc part of the mitigation.
Last updated 24 July 2024
A vulnerability was found in the Linux kernel. Payloads of NM entries are not supposed to contain NUL. When such entry is processed, only the part prior to the first NUL goes into the concatenation (i.e. the directory entry name being encoded by a bunch of NM entries). The process stops when the amount collected so far + the claimed amount in the current NM entry exceed 254.
However, the value returned as the total length is the sum of claimed sizes, not the actual amount collected. And that can grow pretty large - not unlimited, since you'd need to put CE entries in between to be able to get more than the maximum that could be contained in one isofs directory entry / continuation chunk and the process stops once it had encountered 32 CEs, but you can get about 8Kb easily. And that's what will be passed to readdir callback as the name length. 8Kb copytouser() from a buffer allocated by getfreepage()
References, CVE-ID request and response:
http://seclists.org/oss-sec/2016/q2/363
http://seclists.org/oss-sec/2016/q2/365
Upstream fix:
https://git.kernel.org/linus/99d825822eade8d827a1817357cbf3f889a552d6
A use after free vulnerability was found in pppunregisterchannel function. This is triggered when network namespace is removed while pppasync channel is still registered in it and pppunregisterchannel() tries to access its per-netns data in the defunct namespace.
An attacker who could control this memory that is being used in the defunct namespace could create a denial of service by spinlocking a CPU.
An unprivileged local user could use this flaw to induce kernel memory corruption on the system, leading to a crash. Due to the nature of the flaw, privilege escalation cannot be fully ruled out, although we believe it is unlikely.
Upstream patch:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1f461dcdd296eecedaffffc6bae2bfa90bd7eb89
CVE request:
http://seclists.org/oss-sec/2016/q2/319
An information leak vulnerability in [llc] module was found in "net/llc/afllc.c". The stack object "info" has a total size of 12 bytes. Its last byte is padding which is not initialized and leaked via putcmsg().
Public via:
http://marc.info/?l=linux-kernel&m=146230753506235&w=2
http://marc.info/?l=linux-netdev&m=146230754406241&w=2
CVE-ID request and assignment:
http://seclists.org/oss-sec/2016/q2/233
http://seclists.org/oss-sec/2016/q2/236
Upstream patch:
https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=b8670c09f37bdf2847cc44f36511a53afc6161fd
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b8670c09f37bdf2847cc44f36511a53afc6161fd
Adam Gowdiak (Security Explorations) reported that the fix for IBM JDK issue CVE-2013-5456 (bug 1027748), also known as "Issue 70", did not correctly address the problem. Applied fix only restricted access to the vulnerable package, rather then addressing the underlying problem of running untrusted code inside doPrivileged block.
Report:
http://seclists.org/fulldisclosure/2016/Apr/43
Write-up of the issue:
http://www.security-explorations.com/materials/SE-2012-01-IBM-5.pdf
Proof-of-concept code:
http://www.security-explorations.com/materials/se-2012-01-70.2.zip
It was reported that the IBM fix for the issue 67 from this document http://www.security-explorations.com/materials/SE-2012-01-IBM-2.pdf didn't address the problem properly.
References:
http://seclists.org/fulldisclosure/2016/Apr/3
Full report:
http://www.security-explorations.com/materials/SE-2012-01-IBM-4.pdf
In the marksourcechains function (net/ipv4/netfilter/iptables.c) it is possible for a user-supplied iptentry structure to have a large nextoffset field. This field is not bounds checked prior to writing a counter value at the supplied offset.
Proposed fix:
patch v1 message: http://marc.info/?l=netfilter-devel&m=145757134822741&w=2 patch v2 thread: http://marc.info/?t=145757149500006&r=1&w=2
patch v2 message: http://marc.info/?l=netfilter-devel&m=145762719008418&w=2 patch v2 thread: (none yet) http://marc.info/?l=netfilter-devel&r=4&b=201603&w=2
CVE request and assignment:
http://seclists.org/oss-sec/2016/q1/581 http://seclists.org/oss-sec/2016/q1/619
Audit done by netfilter team found several related bugs, patches to better validate rulesets are currently queued in pablos nf-next tree upstream (use "parent" link to cycle to next one - there are 17 additional patches):
https://git.kernel.org/cgit/linux/kernel/git/pablo/nf-next.git/commit/?id=d7591f0c41ce3e67600a982bab6989ef0f07b3ce
Quickly plugging in and unplugging a USB hub can lead to a null pointer dereference in kernel (local denial of service) or the USB port to which the hub is connected becomes unusable, for kernel versions 2.6.32 < 4.4. The issue occurs when the USB hub gets disconnected before or while the routine for USB hub activation is running - hubactivate() function.
Upstream patch:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e50293ef9775c5
External references:
http://www.spinics.net/lists/linux-usb/msg132311.html
CVE-ID request and assignment:
http://seclists.org/oss-sec/2016/q1/404
http://seclists.org/oss-sec/2016/q1/413
A stack-based buffer overflow was found in libresolv when invoked from nssdns, allowing specially crafted DNS responses to seize control of EIP in the DNS client.
The buffer overflow occurs in the functions senddg (send datagram) and sendvc (send TCP) for the NSS module libnssdns.so.2 when calling getaddrinfo with AFUNSPEC family, or in some cases AFINET6 family. The use of AFUNSPEC (or AFINET6 in some cases) triggers the low-level resolver code to send out two parallel queries for A and AAAA. A mismanagement of the buffers used for those queries could result in the response of a query writing beyond the alloca allocated buffer created by resnquery.