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 vulnerability was found in Linux kernel. There is an information leak in file "sound/core/timer.c" of the latest mainline Linux kernel, the stack object “tread” has a total size of 32 bytes. It contains a 8-bytes padding, which is not initialized but sent to user via copytouser(), resulting a kernel leak.
An information leak vulnerability in rtnetlink subsystem in Linux kernel was found in "net/core/rtnetlink.c". The stack object "map" has a total size of 32 bytes. Its last 4 bytes are padding generated by compiler. These padding bytes are not initialized and sent out via nlaput().
Public via:
http://marc.info/?l=linux-kernel&m=146230821206492&w=2
http://marc.info/?l=linux-netdev&m=146230822606494&w=2
CVE-ID request and assignment:
http://seclists.org/oss-sec/2016/q2/234
http://seclists.org/oss-sec/2016/q2/237
Upstream patch:
https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=5f8e44741f9f216e33736ea4ec65ca9ac03036e6
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5f8e44741f9f216e33736ea4ec65ca9ac03036e6
Last updated 24 July 2024
Destroy of network interface with huge number of ipv4 addresses keeps rtnllock for a very long time (up to hour). It blocks many network related operations, including for example creation of new incoming ssh connections.
The problem is especially important for containers, container owner have enough permission to enable this trigger and then can block network access on whole host node.
Upstream fix:
http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=fbd40ea0180a2d328c5adc61414dc8bab9335ce2
References:
http://seclists.org/oss-sec/2016/q1/643
CVE assignment:
http://seclists.org/oss-sec/2016/q1/647
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
A flaw was found in in the Linux kernel's USB device management code which could cause a crash when a device which required iowarrior driver. The kernel would panic causing null pointer dereference attempting to access non existent endpoints.
Product bug:
https://bugzilla.redhat.com/showbug.cgi?id=1283390
A flaw was found in in the Linux kernel's USB device management code which could cause a crash when a device which required powermate driver. The kernel would panic causing null pointer dereference attempting to access non existent endpoints.
Product bug:
https://bugzilla.redhat.com/showbug.cgi?id=1283384
Public via:
http://seclists.org/bugtraq/2016/Mar/85
This was assigned CVE-2016-2186 by Red Hat.
A flaw was found in in the Linux kernel's USB device management code which could cause a kernel panic when a device which required atiremote2 kernel module. The kernel would panic causing null pointer dereference attempting to access a non existent interface descriptor. The atiremote2 driver assumes that there will be at least two interface-descriptors with associated endpoint-descriptors.
Product bugs:
https://bugzilla.redhat.com/showbug.cgi?id=1283362 https://bugzilla.redhat.com/showbug.cgi?id=1283363
Public via:
http://seclists.org/bugtraq/2016/Mar/90
Red Hat assigned CVE-2016-2185 to this issue.
Upstream patch:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=950336ba3e4a1ffd2ca60d29f6ef386dd2c7351d
A flaw was found in in the Linux kernel's USB device management code which could cause a crash when a device which required cypressm8 driver. The kernel would panic causing null pointer dereference.
Product bug:
https://bugzilla.redhat.com/showbug.cgi?id=1283368
Kernel crash occurs when presented a buggy USB device which requires digiacceleport driver, causing null pointer dereference.
Product bug:
https://bugzilla.redhat.com/showbug.cgi?id=1283378
A flaw was found in the Linux kernel handling when a buggy USB device is attached attempting to use the cdcacm kernel module. This flaw would cause the kernel to panic by a null pointer dereference.
Public via:
http://seclists.org/bugtraq/2016/Mar/54
CVE-ID request and assignment:
http://seclists.org/oss-sec/2016/q1/605
http://seclists.org/oss-sec/2016/q1/622
Upstream patch:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8835ba4a39cf53f705417b3b3a94eb067673f2c9
fs/pipe.c in the Linux kernel before 4.5 does not limit the amount of unread data in pipes, which allows local users to cause a denial of service (memory consumption) by creating many pipes with non-default sizes.