hitoshura25/cvefixes huggingface dataset:
CVE-2016-10229 (C, published 2017-04-04T05:59Z)
Description: value: 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 MSG_PEEK flag.
Severity: HIGH (CVSS v3 base score: 9.8)
Weakness: CWE-358 \u2014 Improperly Implemented Security Check for Standard
The product does not implement or incorrectly implements one or more security-relevant checks as specified by the design of a standardized algorithm, protocol, or technique.
Repository: https://github.com/torvalds/linux
Files changed:
net/ipv4/udp.c
net/ipv6/udp.c
Commit message: udp: properly support MSG_PEEK with truncated buffers

Backport of this upstream commit into stable kernels :
89c22d8c3b27 ("net: Fix skb csum races when peeking")
exposed a bug in udp stack vs MSG_PEEK support, when user provides
a buffer smaller than skb payload.

In this case,
skb_copy_and_csum_datagram_iovec(skb, sizeof(struct udphdr),
                                 msg->msg_iov);
returns -EFAULT.

This bug does not happen in upstream kernels since Al Viro did a great
job to replace this into :
skb_copy_and_csum_datagram_msg(skb, sizeof(struct udphdr), msg);
This variant is safe vs short buffers.

For the time being, instead reverting Herbert Xu patch and add back
skb->ip_summed invalid changes, simply store the result of
udp_lib_checksum_complete() so that we avoid computing the checksum a
second time, and avoid the problematic
skb_copy_and_csum_datagram_iovec() call.

This patch can be applied on recent kernels as it avoids a double
checksumming, then backported to stable kernels as a bug fix.

Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>


Vulnerable code:
		if (udp_lib_checksum_complete(skb))
	if (skb_csum_unnecessary(skb))
		if (udp_lib_checksum_complete(skb))
	if (skb_csum_unnecessary(skb))

Fixed code:
	bool checksum_valid = false;
		checksum_valid = !udp_lib_checksum_complete(skb);
		if (!checksum_valid)
	if (checksum_valid || skb_csum_unnecessary(skb))
	bool checksum_valid = false;
		checksum_valid = !udp_lib_checksum_complete(skb);
		if (!checksum_valid)
	if (checksum_valid || skb_csum_unnecessary(skb))
CVE-2016-8630 (C, published 2016-11-28T03:59Z)
Description: value: The x86_decode_insn function in arch/x86/kvm/emulate.c in the Linux kernel before 4.8.7, when KVM is enabled, allows local users to cause a denial of service (host OS crash) via a certain use of a ModR/M byte in an undefined instruction.
Severity: MEDIUM (CVSS v3 base score: 5.5)
Weakness: CWE-284 \u2014 Improper Access Control
The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.
Repository: https://github.com/torvalds/linux
Files changed:
arch/x86/kvm/emulate.c
Commit message: kvm: x86: Check memopp before dereference (CVE-2016-8630)

Commit 41061cdb98 ("KVM: emulate: do not initialize memopp") removes a
check for non-NULL under incorrect assumptions. An undefined instruction
with a ModR/M byte with Mod=0 and R/M-5 (e.g. 0xc7 0x15) will attempt
to dereference a null pointer here.

Fixes: 41061cdb98a0bec464278b4db8e894a3121671f5
Message-Id: <1477592752-126650-2-git-send-email-osh@google.com>
Signed-off-by: Owen Hofmann <osh@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


Vulnerable code:
	if (ctxt->rip_relative)

Fixed code:
	if (ctxt->rip_relative && likely(ctxt->memopp))
CVE-2017-16643 (C, published 2017-11-07T23:29Z)
Description: value: The parse_hid_report_descriptor function in drivers/input/tablet/gtco.c in the Linux kernel before 4.13.11 allows local users to cause a denial of service (out-of-bounds read and system crash) or possibly have unspecified other impact via a crafted USB device.
Severity: HIGH (CVSS v3 base score: 6.6)
Weakness: CWE-125 \u2014 Out-of-bounds Read
The product reads data past the end, or before the beginning, of the intended buffer.
Repository: https://github.com/torvalds/linux
Files changed:
drivers/input/tablet/gtco.c
Commit message: Input: gtco - fix potential out-of-bound access

parse_hid_report_descriptor() has a while (i < length) loop, which
only guarantees that there's at least 1 byte in the buffer, but the
loop body can read multiple bytes which causes out-of-bounds access.

Reported-by: Andrey Konovalov <andreyknvl@google.com>
Reviewed-by: Andrey Konovalov <andreyknvl@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Vulnerable code:
		prefix = report[i];

		/* Skip over prefix */
		i++;
		size = PREF_SIZE(prefix);
		case 3:
			size = 4;

Fixed code:
		prefix = report[i++];
		size = (1U << PREF_SIZE(prefix)) >> 1;
		if (i + size > length) {
			dev_err(ddev,
				"Not enough data (need %d, have %d)\n",
				i + size, length);
			break;
		}

		case 4:
CVE-2017-10810 (C, published 2017-07-04T20:29Z)
Description: value: Memory leak in the virtio_gpu_object_create function in drivers/gpu/drm/virtio/virtgpu_object.c in the Linux kernel through 4.11.8 allows attackers to cause a denial of service (memory consumption) by triggering object-initialization failures.
Severity: HIGH (CVSS v3 base score: 7.5)
Weakness: CWE-772 \u2014 Missing Release of Resource after Effective Lifetime
The product does not release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed.
Repository: https://github.com/torvalds/linux
Files changed:
drivers/gpu/drm/virtio/virtgpu_object.c
Commit message: drm/virtio: don't leak bo on drm_gem_object_init failure

Reported-by: 李强 <liqiang6-s@360.cn>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170406155941.458-1-kraxel@redhat.com


Vulnerable code:
	if (ret != 0)

Fixed code:
	if (ret != 0) {
		kfree(bo);
	}
CVE-2017-2671 (C, published 2017-04-05T06:59Z)
Description: value: The ping_unhash function in net/ipv4/ping.c in the Linux kernel through 4.10.8 is too late in obtaining a certain lock and consequently cannot ensure that disconnect function calls are safe, which allows local users to cause a denial of service (panic) by leveraging access to the protocol value of IPPROTO_ICMP in a socket system call.
Severity: MEDIUM (CVSS v3 base score: 5.5)
Weakness: NVD-CWE-noinfo \u2014 Insufficient Information
There is insufficient information about the issue to classify it; details are unkown or unspecified.
Repository: https://github.com/torvalds/linux
Files changed:
net/ipv4/ping.c
Commit message: ping: implement proper locking

We got a report of yet another bug in ping

http://www.openwall.com/lists/oss-security/2017/03/24/6

->disconnect() is not called with socket lock held.

Fix this by acquiring ping rwlock earlier.

Thanks to Daniel, Alexander and Andrey for letting us know this problem.

Fixes: c319b4d76b9e ("net: ipv4: add IPPROTO_ICMP socket kind")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Daniel Jiang <danieljiang0415@gmail.com>
Reported-by: Solar Designer <solar@openwall.com>
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>


Vulnerable code:
		write_lock_bh(&ping_table.lock);
		write_unlock_bh(&ping_table.lock);

Fixed code:

	write_lock_bh(&ping_table.lock);
	write_unlock_bh(&ping_table.lock);
CVE-2015-1805 (C, published 2015-08-08T10:59Z)
Description: value: The (1) pipe_read and (2) pipe_write implementations in fs/pipe.c in the Linux kernel before 3.16 do not properly consider the side effects of failed __copy_to_user_inatomic and __copy_from_user_inatomic calls, which allows local users to cause a denial of service (system crash) or possibly gain privileges via a crafted application, aka an "I/O vector array overrun."
Severity: HIGH (CVSS v3 base score: )
Weakness: CWE-17 \u2014 DEPRECATED: Code
This entry has been deprecated.  It was originally used for organizing the Development View (CWE-699) and some other views, but it introduced unnecessary complexity and depth to the resulting tree.
Repository: https://github.com/torvalds/linux
Files changed:
fs/pipe.c
Commit message: switch pipe_read() to copy_page_to_iter()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>


Vulnerable code:
static int
pipe_iov_copy_to_user(struct iovec *iov, const void *from, unsigned long len,
		      int atomic)
{
	unsigned long copy;

	while (len > 0) {
		while (!iov->iov_len)
			iov++;
		copy = min_t(unsigned long, len, iov->iov_len);

		if (atomic) {
			if (__copy_to_user_inatomic(iov->iov_base, from, copy))
				return -EFAULT;
		} else {
			if (copy_to_user(iov->iov_base, from, copy))
				return -EFAULT;
		}
		from += copy;
		len -= copy;
		iov->iov_base += copy;
		iov->iov_len -= copy;
	}
	return 0;
}

/*
 * Attempt to pre-fault in the user memory, so we can use atomic copies.
 * Returns the number of bytes not faulted in.
 */
static int iov_fault_in_pages_write(struct iovec *iov, unsigned long len)
{
	while (!iov->iov_len)
		iov++;

	while (len > 0) {
		unsigned long this_len;

		this_len = min_t(unsigned long, len, iov->iov_len);
		if (fault_in_pages_writeable(iov->iov_base, this_len))
			break;

		len -= this_len;
		iov++;
	}

	return len;
}

			void *addr;
			int error, atomic;
			atomic = !iov_fault_in_pages_write(iov, chars);
redo:
			if (atomic)
				addr = kmap_atomic(buf->page);
			else
				addr = kmap(buf->page);
			error = pipe_iov_copy_to_user(iov, addr + buf->offset, chars, atomic);
			if (atomic)
				kunmap_atomic(addr);
			else
				kunmap(buf->page);
			if (unlikely(error)) {
				/*
				 * Just retry with the slow path if we failed.
				 */
				if (atomic) {
					atomic = 0;
					goto redo;
				}
					ret = error;

Fixed code:
	struct iov_iter iter;
	iov_iter_init(&iter, iov, nr_segs, total_len, 0);

			size_t written;
			int error;
			written = copy_page_to_iter(buf->page, buf->offset, chars, &iter);
			if (unlikely(written < chars)) {
					ret = -EFAULT;
CVE-2013-1848 (C, published 2013-03-22T11:59Z)
Description: value: fs/ext3/super.c in the Linux kernel before 3.8.4 uses incorrect arguments to functions in certain circumstances related to printk input, which allows local users to conduct format-string attacks and possibly gain privileges via a crafted application.
Severity: MEDIUM (CVSS v3 base score: )
Weakness: CWE-20 \u2014 Improper Input Validation
The product receives input or data, but it does
        not validate or incorrectly validates that the input has the
        properties that are required to process the data safely and
        correctly.
Repository: https://github.com/torvalds/linux
Files changed:
fs/ext3/super.c
Commit message: ext3: Fix format string issues

ext3_msg() takes the printk prefix as the second parameter and the
format string as the third parameter. Two callers of ext3_msg omit the
prefix and pass the format string as the second parameter and the first
parameter to the format string as the third parameter. In both cases
this string comes from an arbitrary source. Which means the string may
contain format string characters, which will
lead to undefined and potentially harmful behavior.

The issue was introduced in commit 4cf46b67eb("ext3: Unify log messages
in ext3") and is fixed by this patch.

CC: stable@vger.kernel.org
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jan Kara <jack@suse.cz>


Vulnerable code:
	ext3_msg(sb, "error: failed to open journal device %s: %ld",
		ext3_msg(sb, "error: invalid sb specification: %s",

Fixed code:
	ext3_msg(sb, KERN_ERR, "error: failed to open journal device %s: %ld",
		ext3_msg(sb, KERN_ERR, "error: invalid sb specification: %s",
CVE-2016-8666 (C, published 2016-10-16T21:59Z)
Description: value: The IP stack in the Linux kernel before 4.6 allows remote attackers to cause a denial of service (stack consumption and panic) or possibly have unspecified other impact by triggering use of the GRO path for packets with tunnel stacking, as demonstrated by interleaved IPv4 headers and GRE headers, a related issue to CVE-2016-7039.
Severity: HIGH (CVSS v3 base score: 7.5)
Weakness: CWE-400 \u2014 Uncontrolled Resource Consumption
The product does not properly control the allocation and maintenance of a limited resource, thereby enabling an actor to influence the amount of resources consumed, eventually leading to the exhaustion of available resources.
Repository: https://github.com/torvalds/linux
Files changed:
include/linux/netdevice.h
net/core/dev.c
net/ipv4/af_inet.c
net/ipv4/gre_offload.c
net/ipv4/udp_offload.c
net/ipv6/ip6_offload.c
Commit message: tunnels: Don't apply GRO to multiple layers of encapsulation.

When drivers express support for TSO of encapsulated packets, they
only mean that they can do it for one layer of encapsulation.
Supporting additional levels would mean updating, at a minimum,
more IP length fields and they are unaware of this.

No encapsulation device expresses support for handling offloaded
encapsulated packets, so we won't generate these types of frames
in the transmit path. However, GRO doesn't have a check for
multiple levels of encapsulation and will attempt to build them.

UDP tunnel GRO actually does prevent this situation but it only
handles multiple UDP tunnels stacked on top of each other. This
generalizes that solution to prevent any kind of tunnel stacking
that would cause problems.

Fixes: bf5a755f ("net-gre-gro: Add GRE support to the GRO stack")
Signed-off-by: Jesse Gross <jesse@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>


Vulnerable code:
	/* Used in udp_gro_receive */
	u8	udp_mark:1;
		NAPI_GRO_CB(skb)->udp_mark = 0;
		.gro_receive	= inet_gro_receive,
	if (NAPI_GRO_CB(skb)->udp_mark ||
	/* mark that this skb passed once through the udp gro layer */
	NAPI_GRO_CB(skb)->udp_mark = 1;
		.gro_receive    = ipv6_gro_receive,

Fixed code:
	/* Used in tunnel GRO receive */
	u8	encap_mark:1;
		NAPI_GRO_CB(skb)->encap_mark = 0;
static struct sk_buff **ipip_gro_receive(struct sk_buff **head,
					 struct sk_buff *skb)
{
	if (NAPI_GRO_CB(skb)->encap_mark) {
		NAPI_GRO_CB(skb)->flush = 1;
		return NULL;
	}

	NAPI_GRO_CB(skb)->encap_mark = 1;

	return inet_gro_receive(head, skb);
}

		.gro_receive	= ipip_gro_receive,
	if (NAPI_GRO_CB(skb)->encap_mark)
		goto out;

	NAPI_GRO_CB(skb)->encap_mark = 1;

	if (NAPI_GRO_CB(skb)->encap_mark ||
	/* mark that this skb passed once through the tunnel gro layer */
	NAPI_GRO_CB(skb)->encap_mark = 1;
static struct sk_buff **sit_gro_receive(struct sk_buff **head,
					struct sk_buff *skb)
{
	if (NAPI_GRO_CB(skb)->encap_mark) {
		NAPI_GRO_CB(skb)->flush = 1;
		return NULL;
	}

	NAPI_GRO_CB(skb)->encap_mark = 1;

	return ipv6_gro_receive(head, skb);
}

		.gro_receive    = sit_gro_receive,
CVE-2013-1798 (C, published 2013-03-22T11:59Z)
Description: value: The ioapic_read_indirect function in virt/kvm/ioapic.c in the Linux kernel through 3.8.4 does not properly handle a certain combination of invalid IOAPIC_REG_SELECT and IOAPIC_REG_WINDOW operations, which allows guest OS users to obtain sensitive information from host OS memory or cause a denial of service (host OS OOPS) via a crafted application.
Severity: MEDIUM (CVSS v3 base score: )
Weakness: CWE-20 \u2014 Improper Input Validation
The product receives input or data, but it does
        not validate or incorrectly validates that the input has the
        properties that are required to process the data safely and
        correctly.
Repository: https://github.com/torvalds/linux
Files changed:
virt/kvm/ioapic.c
Commit message: KVM: Fix bounds checking in ioapic indirect register reads (CVE-2013-1798)

If the guest specifies a IOAPIC_REG_SELECT with an invalid value and follows
that with a read of the IOAPIC_REG_WINDOW KVM does not properly validate
that request.  ioapic_read_indirect contains an
ASSERT(redir_index < IOAPIC_NUM_PINS), but the ASSERT has no effect in
non-debug builds.  In recent kernels this allows a guest to cause a kernel
oops by reading invalid memory.  In older kernels (pre-3.3) this allows a
guest to read from large ranges of host memory.

Tested: tested against apic unit tests.

Signed-off-by: Andrew Honig <ahonig@google.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>


Vulnerable code:
			ASSERT(redir_index < IOAPIC_NUM_PINS);
			redir_content = ioapic->redirtbl[redir_index].bits;

Fixed code:
			if (redir_index < IOAPIC_NUM_PINS)
				redir_content =
					ioapic->redirtbl[redir_index].bits;
			else
				redir_content = ~0ULL;
CVE-2010-5331 (C, published 2019-07-27T22:15Z)
Description: value: In the Linux kernel before 2.6.34, a range check issue in drivers/gpu/drm/radeon/atombios.c could cause an off by one (buffer overflow) problem. NOTE: At least one Linux maintainer believes that this CVE is incorrectly assigned and should be rejected because the value is hard coded and are not user-controllable where it is used
Severity: MEDIUM (CVSS v3 base score: 7.8)
Weakness: CWE-193 \u2014 Off-by-one Error
A product calculates or uses an incorrect maximum or minimum value that is 1 more, or 1 less, than the correct value.
Repository: https://github.com/torvalds/linux
Files changed:
drivers/gpu/drm/radeon/atombios.h
drivers/gpu/drm/radeon/radeon_atombios.c
Commit message: drivers/gpu/drm/radeon/radeon_atombios.c: range check issues

This change makes the array larger, "MAX_SUPPORTED_TV_TIMING_V1_2" is 3
and the original size "MAX_SUPPORTED_TV_TIMING" is 2.

Also there were checks that were off by one.

Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>


Vulnerable code:
  ATOM_DTD_FORMAT          aModeTimings[MAX_SUPPORTED_TV_TIMING];
		if (index > MAX_SUPPORTED_TV_TIMING)
		if (index > MAX_SUPPORTED_TV_TIMING_V1_2)

Fixed code:
  ATOM_DTD_FORMAT          aModeTimings[MAX_SUPPORTED_TV_TIMING_V1_2];
		if (index >= MAX_SUPPORTED_TV_TIMING)
		if (index >= MAX_SUPPORTED_TV_TIMING_V1_2)
CVE-2012-2669 (C, published 2012-12-27T11:47Z)
Description: value: The main function in tools/hv/hv_kvp_daemon.c in hypervkvpd, as distributed in the Linux kernel before 3.4.5, does not validate the origin of Netlink messages, which allows local users to spoof Netlink communication via a crafted connector message.
Severity: LOW (CVSS v3 base score: )
Weakness: CWE-20 \u2014 Improper Input Validation
The product receives input or data, but it does
        not validate or incorrectly validates that the input has the
        properties that are required to process the data safely and
        correctly.
Repository: https://github.com/torvalds/linux
Files changed:
tools/hv/hv_kvp_daemon.c
Commit message: Tools: hv: verify origin of netlink connector message

The SuSE security team suggested to use recvfrom instead of recv to be
certain that the connector message is originated from kernel.

CVE-2012-2669

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Marcus Meissner <meissner@suse.de>
Signed-off-by: Sebastian Krahmer <krahmer@suse.de>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>


Vulnerable code:
		len = recv(fd, kvp_recv_buffer, sizeof(kvp_recv_buffer), 0);
		if (len < 0) {
			syslog(LOG_ERR, "recv failed; error:%d", len);

Fixed code:
		struct sockaddr *addr_p = (struct sockaddr *) &addr;
		socklen_t addr_l = sizeof(addr);
		len = recvfrom(fd, kvp_recv_buffer, sizeof(kvp_recv_buffer), 0,
				addr_p, &addr_l);
		if (len < 0 || addr.nl_pid) {
			syslog(LOG_ERR, "recvfrom failed; pid:%u error:%d %s",
					addr.nl_pid, errno, strerror(errno));
CVE-2013-4125 (C, published 2013-07-15T20:55Z)
Description: value: The fib6_add_rt2node function in net/ipv6/ip6_fib.c in the IPv6 stack in the Linux kernel through 3.10.1 does not properly handle Router Advertisement (RA) messages in certain circumstances involving three routes that initially qualified for membership in an ECMP route set until a change occurred for one of the first two routes, which allows remote attackers to cause a denial of service (system crash) via a crafted sequence of messages.
Severity: MEDIUM (CVSS v3 base score: )
Weakness: CWE-399 \u2014 Resource Management Errors
Weaknesses in this category are related to improper management of system resources.
Repository: https://github.com/torvalds/linux
Files changed:
net/ipv6/ip6_fib.c
Commit message: ipv6: only static routes qualify for equal cost multipathing

Static routes in this case are non-expiring routes which did not get
configured by autoconf or by icmpv6 redirects.

To make sure we actually get an ecmp route while searching for the first
one in this fib6_node's leafs, also make sure it matches the ecmp route
assumptions.

v2:
a) Removed RTF_EXPIRE check in dst.from chain. The check of RTF_ADDRCONF
   already ensures that this route, even if added again without
   RTF_EXPIRES (in case of a RA announcement with infinite timeout),
   does not cause the rt6i_nsiblings logic to go wrong if a later RA
   updates the expiration time later.

v3:
a) Allow RTF_EXPIRES routes to enter the ecmp route set. We have to do so,
   because an pmtu event could update the RTF_EXPIRES flag and we would
   not count this route, if another route joins this set. We now filter
   only for RTF_GATEWAY|RTF_ADDRCONF|RTF_DYNAMIC, which are flags that
   don't get changed after rt6_info construction.

Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>


Vulnerable code:
			if (rt->rt6i_flags & RTF_GATEWAY &&
			    !(rt->rt6i_flags & RTF_EXPIRES) &&
			    !(iter->rt6i_flags & RTF_EXPIRES))
			if (sibling->rt6i_metric == rt->rt6i_metric) {

Fixed code:
static inline bool rt6_qualify_for_ecmp(struct rt6_info *rt)
{
	return (rt->rt6i_flags & (RTF_GATEWAY|RTF_ADDRCONF|RTF_DYNAMIC)) ==
	       RTF_GATEWAY;
}

	bool rt_can_ecmp = rt6_qualify_for_ecmp(rt);
			if (rt_can_ecmp &&
			    rt6_qualify_for_ecmp(iter))
			if (sibling->rt6i_metric == rt->rt6i_metric &&
			    rt6_qualify_for_ecmp(sibling)) {
CVE-2012-0879 (C, published 2012-05-17T11:00Z)
Description: value: The I/O implementation for block devices in the Linux kernel before 2.6.33 does not properly handle the CLONE_IO feature, which allows local users to cause a denial of service (I/O instability) by starting multiple processes that share an I/O context.
Severity: MEDIUM (CVSS v3 base score: 5.5)
Weakness: CWE-400 \u2014 Uncontrolled Resource Consumption
The product does not properly control the allocation and maintenance of a limited resource, thereby enabling an actor to influence the amount of resources consumed, eventually leading to the exhaustion of available resources.
Repository: https://github.com/torvalds/linux
Files changed:
block/blk-ioc.c
include/linux/iocontext.h
kernel/exit.c
kernel/fork.c
Commit message: block: Fix io_context leak after failure of clone with CLONE_IO

With CLONE_IO, parent's io_context->nr_tasks is incremented, but never
decremented whenever copy_process() fails afterwards, which prevents
exit_io_context() from calling IO schedulers exit functions.

Give a task_struct to exit_io_context(), and call exit_io_context() instead of
put_io_context() in copy_process() cleanup path.

Signed-off-by: Louis Rilling <louis.rilling@kerlabs.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>


Vulnerable code:
void exit_io_context(void)
	task_lock(current);
	ioc = current->io_context;
	current->io_context = NULL;
	task_unlock(current);
void exit_io_context(void);
static inline void exit_io_context(void)
		exit_io_context();
	put_io_context(p->io_context);

Fixed code:
void exit_io_context(struct task_struct *task)
	task_lock(task);
	ioc = task->io_context;
	task->io_context = NULL;
	task_unlock(task);
struct task_struct;
void exit_io_context(struct task_struct *task);
static inline void exit_io_context(struct task_struct *task)
		exit_io_context(tsk);
	if (p->io_context)
		exit_io_context(p);