The tcpmssmanglepacket function in net/netfilter/xtTCPMSS.c in the Linux kernel before 4.11, and 4.9.x before 4.9.36, allows remote attackers to cause a denial of service (use-after-free and memory corruption) or possibly have unspecified other impact by leveraging the presence of xtTCPMSS in an iptables action.
udp.c in the Linux kernel before 4.5 allows remote attackers to execute arbitrary code via UDP traffic that triggers an unsafe second checksum calculation during execution of a recv system call with the MSGPEEK flag.
An issue was found in the Linux kernel ipv6 implementation of GRE tunnels which allows a remote attacker to trigger an out-of-bounds access. At this time we understand no trust barrier has been crossed and there is no security implications in this flaw.
References:
http://seclists.org/oss-sec/2017/q1/323
Upstream patch:
https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=7892032cfe67f4bde6fc2ee967e45a8fbaf33756
A flaw was found in the Linux kernels implementation of sctp protocol in which a remote attacker can trigger an out of bounds read with an offset of up to 64kB. This may panic the machine with a page-fault and the out-of-bounds data does not seem to be returned to the remote attacker.
For this attack to be sucessful, the kernel needs to have both the SCTP protocol module loaded and a process listening as an SCTP server.
Upstream patch:
https://github.com/torvalds/linux/commit/bf911e985d6bbaa328c20c3e05f4eb03de11fdd6
CVE assignment:
http://seclists.org/oss-sec/2016/q4/509
A use after free vulnerability was found in the kernels socket recvmsg subsystem. This may allows remote attackers to corrupt memory and may allow execution of arbitrary code. This corruption takes place during the error handling routines within sysrecvmmsg() function.
To attack the kernel using this method the system must be running application using the UDP recvmmsg syscall().
Upstream patch:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=34b88a68f26a75e4fded796f1a49c40f82234b7d
Upstream discussion: https://patchwork.kernel.org/patch/8093221/
Additional Write up: https://blog.lizzie.io/notes-about-cve-2016-7117.html
Last updated 24 July 2024
A flaw was found in the CXGB3 kernel driver when the network was considered congested. The kernel would incorrectly misinterpret the congestion as an error condition and incorrectly free/clean up the skb. When the device would then send the skb's queued, these structures would be referenced and may panic the system or allow an attacker to escalate privileges in a use-after-free scenario.
From the patch:
----
The cxgb3send() functions return NETXMIT values, which are positive integers values. So don't treat positive return values as an error. ----
Upstream commit: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=67f1aee6f45059fd6b0f5b0ecb2c97ad0451f6b3
CVE assignment: http://seclists.org/oss-sec/2016/q1/311
An use after free flaw was found in the Linux kernel SCTP implementation handled auth keys reference counting during INIT collisions.
A remote user could use this flaw to crash the system or, though unlikely, escalate their privileges on the system.
Upstream patch:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=600ddd6825543962fb807884169e57b580dba208
Acknowledgements:
This issue was discovered by Sun Baoliang of Red Hat.
Description of the problem:
Some occurences in the netfilter tree use skbheaderpointer() in the following way ...
struct dccphdr dh, dh; ... skbheaderpointer(skb, dataoff, sizeof(dh), &dh);
... where dh itself is a pointer that is being passed as the copy buffer. Instead, we need to use &dh as the forth argument so that we're copying the data into an actual buffer that sits on the stack.
A remote attacker could use this flaw to crash the system or, potentially, escalate their privileges on the system.
References: http://www.openwall.com/lists/oss-security/2014/03/17/3
Introduced by: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2bc780499aa3
Upstream fix: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b22f5126a24b
Description of the problem:
A very subtle race condition between inetfragevictor, inetfragintern and the IPv4/6 fragqueue and expire functions (basically the users of inetfragkill/inetfragput) was found.
What happens is that after a fragment has been added to the hash chain but before it's been added to the lrulist (inetfraglruadd), it may get deleted (either by an expired timer if the system load is high or the timer sufficiently low, or by the fraqqueue function for different reasons) before it's added to the lrulist, then after it gets added it's a matter of time for the evictor to get to a piece of memory which has been freed leading to a number of different bugs depending on what's left there.
Introduced by: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3ef0eb0d
Acknowledgements:
This issue was discovered by Nikolay Aleksandrov of Red Hat.