In the Linux kernel, the following vulnerability has been resolved:
ipv6: icmp: clear skb2->cb[] in ip6errgenicmpv6unreach()
Sashiko AI-review observed:
In ip6errgenicmpv6unreach(), the skb is an outer IPv4 ICMP error packet where its cb contains an IPv4 inetskbparm. When skb is cloned into skb2 and passed to icmp6send(), it uses IP6CB(skb2).
IP6CB interprets the IPv4 inetskbparm as an inet6skbparm. The cipso offset in inetskbparm.opt directly overlaps with dsthao in inet6skbparm at offset 18.
If an attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao would be a non-zero offset. Inside icmp6send(), mip6addrswap() is called and uses ipv6findtlv(skb, opt->dsthao, IPV6TLVHAO).
This would scan the inner, attacker-controlled IPv6 packet starting at that offset, potentially returning a fake TLV without checking if the remaining packet length can hold the full 18-byte struct ipv6destopthao.
Could mip6addrswap() then perform a 16-byte swap that extends past the end of the packet data into skbsharedinfo?
Should the cb array also be cleared in ip6errgenicmpv6unreach() and ip6ip6err() to prevent this?
This patch implements the first suggestion.
I am not sure if ip6ip6err() needs to be changed. A separate patch would be better anyway.
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
Last updated 24 July 2024
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.
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
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.
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
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.
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
Last updated 24 July 2024