hitoshura25/cvefixes huggingface dataset:
CVE-2016-9084 (C, published 2016-11-28T03:59Z)
Description: value: drivers/vfio/pci/vfio_pci_intrs.c in the Linux kernel through 4.8.11 misuses the kzalloc function, which allows local users to cause a denial of service (integer overflow) or have unspecified other impact by leveraging access to a vfio PCI device file.
Severity: MEDIUM (CVSS v3 base score: 7.8)
Weakness: CWE-190 \u2014 Integer Overflow or Wraparound
The product performs a calculation that can
         produce an integer overflow or wraparound when the logic
         assumes that the resulting value will always be larger than
         the original value. This occurs when an integer value is
         incremented to a value that is too large to store in the
         associated representation. When this occurs, the value may
         become a very small or negative number.
Repository: https://github.com/torvalds/linux
Files changed:
drivers/vfio/pci/vfio_pci.c
drivers/vfio/pci/vfio_pci_intrs.c
Commit message: vfio/pci: Fix integer overflows, bitmask check

The VFIO_DEVICE_SET_IRQS ioctl did not sufficiently sanitize
user-supplied integers, potentially allowing memory corruption. This
patch adds appropriate integer overflow checks, checks the range bounds
for VFIO_IRQ_SET_DATA_NONE, and also verifies that only single element
in the VFIO_IRQ_SET_DATA_TYPE_MASK bitmask is set.
VFIO_IRQ_SET_ACTION_TYPE_MASK is already correctly checked later in
vfio_pci_set_irqs_ioctl().

Furthermore, a kzalloc is changed to a kcalloc because the use of a
kzalloc with an integer multiplication allowed an integer overflow
condition to be reached without this patch. kcalloc checks for overflow
and should prevent a similar occurrence.

Signed-off-by: Vlad Tsyrklevich <vlad@tsyrklevich.net>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>


Vulnerable code:
		int ret = 0;
		if (!(hdr.flags & VFIO_IRQ_SET_DATA_NONE)) {
			size_t size;
			int max = vfio_pci_get_irq_count(vdev, hdr.index);
			if (hdr.flags & VFIO_IRQ_SET_DATA_BOOL)
				size = sizeof(uint8_t);
			else if (hdr.flags & VFIO_IRQ_SET_DATA_EVENTFD)
				size = sizeof(int32_t);
			else
				return -EINVAL;
			if (hdr.argsz - minsz < hdr.count * size ||
			    hdr.start >= max || hdr.start + hdr.count > max)
	vdev->ctx = kzalloc(nvec * sizeof(struct vfio_pci_irq_ctx), GFP_KERNEL);

Fixed code:
		size_t size;
		int max, ret = 0;
		    hdr.count >= (U32_MAX - hdr.start) ||
		max = vfio_pci_get_irq_count(vdev, hdr.index);
		if (hdr.start >= max || hdr.start + hdr.count > max)
			return -EINVAL;
		switch (hdr.flags & VFIO_IRQ_SET_DATA_TYPE_MASK) {
		case VFIO_IRQ_SET_DATA_NONE:
			size = 0;
			break;
		case VFIO_IRQ_SET_DATA_BOOL:
			size = sizeof(uint8_t);
			break;
		case VFIO_IRQ_SET_DATA_EVENTFD:
			size = sizeof(int32_t);
			break;
		default:
			return -EINVAL;
		}
		if (size) {
			if (hdr.argsz - minsz < hdr.count * size)
	vdev->ctx = kcalloc(nvec, sizeof(struct vfio_pci_irq_ctx), GFP_KERNEL);
CVE-2014-6416 (C, published 2014-09-28T10:55Z)
Description: value: Buffer overflow in net/ceph/auth_x.c in Ceph, as used in the Linux kernel before 3.16.3, allows remote attackers to cause a denial of service (memory corruption and panic) or possibly have unspecified other impact via a long unencrypted auth ticket.
Severity: HIGH (CVSS v3 base score: )
Weakness: CWE-119 \u2014 Improper Restriction of Operations within the Bounds of a Memory Buffer
The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.
Repository: https://github.com/torvalds/linux
Files changed:
net/ceph/auth_x.c
Commit message: libceph: do not hard code max auth ticket len

We hard code cephx auth ticket buffer size to 256 bytes.  This isn't
enough for any moderate setups and, in case tickets themselves are not
encrypted, leads to buffer overflows (ceph_x_decrypt() errors out, but
ceph_decode_copy() doesn't - it's just a memcpy() wrapper).  Since the
buffer is allocated dynamically anyway, allocated it a bit later, at
the point where we know how much is going to be needed.

Fixes: http://tracker.ceph.com/issues/8979

Cc: stable@vger.kernel.org
Signed-off-by: Ilya Dryomov <ilya.dryomov@inktank.com>
Reviewed-by: Sage Weil <sage@redhat.com>


Vulnerable code:
#define TEMP_TICKET_BUF_LEN	256

			  void **p, void *end, void *obuf, size_t olen)
	ret = ceph_decrypt2(secret, &head, &head_len, obuf, &olen,
			    *p, len);
			      void **p, void *end,
			      void *dbuf, void *ticket_buf)
	dlen = ceph_x_decrypt(secret, p, end, dbuf,
			      TEMP_TICKET_BUF_LEN);
	tp = ticket_buf;
		dlen = ceph_x_decrypt(&old_key, p, end, ticket_buf,
				      TEMP_TICKET_BUF_LEN);
	char *dbuf;
	char *ticket_buf;
	dbuf = kmalloc(TEMP_TICKET_BUF_LEN, GFP_NOFS);
	if (!dbuf)
		return -ENOMEM;

	ret = -ENOMEM;
	ticket_buf = kmalloc(TEMP_TICKET_BUF_LEN, GFP_NOFS);
	if (!ticket_buf)
		goto out_dbuf;

		ret = process_one_ticket(ac, secret, &p, end,
					 dbuf, ticket_buf);
			goto out;
	ret = 0;
out:
	kfree(ticket_buf);
out_dbuf:
	kfree(dbuf);
	return ret;
	ret = -EINVAL;
	goto out;
	ret = ceph_x_decrypt(&th->session_key, &p, end, &reply, sizeof(reply));

Fixed code:
			  void **p, void *end, void **obuf, size_t olen)
	if (*obuf == NULL) {
		*obuf = kmalloc(len, GFP_NOFS);
		if (!*obuf)
			return -ENOMEM;
		olen = len;
	}

	ret = ceph_decrypt2(secret, &head, &head_len, *obuf, &olen, *p, len);
			      void **p, void *end)
	void *dbuf = NULL;
	void *ticket_buf = NULL;
	dlen = ceph_x_decrypt(secret, p, end, &dbuf, 0);
		dlen = ceph_x_decrypt(&old_key, p, end, &ticket_buf, 0);
		tp = ticket_buf;
		ticket_buf = kmalloc(dlen, GFP_NOFS);
		if (!ticket_buf) {
			ret = -ENOMEM;
			goto out;
		}
		tp = ticket_buf;
	kfree(ticket_buf);
	kfree(dbuf);
		ret = process_one_ticket(ac, secret, &p, end);
			return ret;
	return 0;
	return -EINVAL;
	void *preply = &reply;
	ret = ceph_x_decrypt(&th->session_key, &p, end, &preply, sizeof(reply));
CVE-2014-0038 (C, published 2014-02-06T22:55Z)
Description: value: The compat_sys_recvmmsg function in net/compat.c in the Linux kernel before 3.13.2, when CONFIG_X86_X32 is enabled, allows local users to gain privileges via a recvmmsg system call with a crafted timeout pointer parameter.
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:
net/compat.c
Commit message: x86, x32: Correct invalid use of user timespec in the kernel

The x32 case for the recvmsg() timout handling is broken:

  asmlinkage long compat_sys_recvmmsg(int fd, struct compat_mmsghdr __user *mmsg,
                                      unsigned int vlen, unsigned int flags,
                                      struct compat_timespec __user *timeout)
  {
          int datagrams;
          struct timespec ktspec;

          if (flags & MSG_CMSG_COMPAT)
                  return -EINVAL;

          if (COMPAT_USE_64BIT_TIME)
                  return __sys_recvmmsg(fd, (struct mmsghdr __user *)mmsg, vlen,
                                        flags | MSG_CMSG_COMPAT,
                                        (struct timespec *) timeout);
          ...

The timeout pointer parameter is provided by userland (hence the __user
annotation) but for x32 syscalls it's simply cast to a kernel pointer
and is passed to __sys_recvmmsg which will eventually directly
dereference it for both reading and writing.  Other callers to
__sys_recvmmsg properly copy from userland to the kernel first.

The bug was introduced by commit ee4fa23c4bfc ("compat: Use
COMPAT_USE_64BIT_TIME in net/compat.c") and should affect all kernels
since 3.4 (and perhaps vendor kernels if they backported x32 support
along with this code).

Note that CONFIG_X86_X32_ABI gets enabled at build time and only if
CONFIG_X86_X32 is enabled and ld can build x32 executables.

Other uses of COMPAT_USE_64BIT_TIME seem fine.

This addresses CVE-2014-0038.

Signed-off-by: PaX Team <pageexec@freemail.hu>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Cc: <stable@vger.kernel.org> # v3.4+
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


Vulnerable code:
	if (COMPAT_USE_64BIT_TIME)
		return __sys_recvmmsg(fd, (struct mmsghdr __user *)mmsg, vlen,
				      flags | MSG_CMSG_COMPAT,
				      (struct timespec *) timeout);

	if (get_compat_timespec(&ktspec, timeout))
	if (datagrams > 0 && put_compat_timespec(&ktspec, timeout))

Fixed code:
	if (compat_get_timespec(&ktspec, timeout))
	if (datagrams > 0 && compat_put_timespec(&ktspec, timeout))
CVE-2015-2672 (C, published 2016-05-02T10:59Z)
Description: value: The xsave/xrstor implementation in arch/x86/include/asm/xsave.h in the Linux kernel before 3.19.2 creates certain .altinstr_replacement pointers and consequently does not provide any protection against instruction faulting, which allows local users to cause a denial of service (panic) by triggering a fault, as demonstrated by an unaligned memory operand or a non-canonical address memory operand.
Severity: MEDIUM (CVSS v3 base score: 5.5)
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:
arch/x86/include/asm/xsave.h
Commit message: x86/fpu/xsaves: Fix improper uses of __ex_table

Commit:

  f31a9f7c7169 ("x86/xsaves: Use xsaves/xrstors to save and restore xsave area")

introduced alternative instructions for XSAVES/XRSTORS and commit:

  adb9d526e982 ("x86/xsaves: Add xsaves and xrstors support for booting time")

added support for the XSAVES/XRSTORS instructions at boot time.

Unfortunately both failed to properly protect them against faulting:

The 'xstate_fault' macro will use the closest label named '1'
backward and that ends up in the .altinstr_replacement section
rather than in .text. This means that the kernel will never find
in the __ex_table the .text address where this instruction might
fault, leading to serious problems if userspace manages to
trigger the fault.

Signed-off-by: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Signed-off-by: Jamie Iles <jamie.iles@oracle.com>
[ Improved the changelog, fixed some whitespace noise. ]
Acked-by: Borislav Petkov <bp@alien8.de>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: <stable@vger.kernel.org>
Cc: Allan Xavier <mr.a.xavier@gmail.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: adb9d526e982 ("x86/xsaves: Add xsaves and xrstors support for booting time")
Fixes: f31a9f7c7169 ("x86/xsaves: Use xsaves/xrstors to save and restore xsave area")
Signed-off-by: Ingo Molnar <mingo@kernel.org>


Vulnerable code:
			: : "D" (fx), "m" (*fx), "a" (lmask), "d" (hmask)
			: : "D" (fx), "m" (*fx), "a" (lmask), "d" (hmask)

	asm volatile(xstate_fault
		     : "0" (0)
		     : "memory");

			: : "D" (fx), "m" (*fx), "a" (lmask), "d" (hmask)
			: : "D" (fx), "m" (*fx), "a" (lmask), "d" (hmask)

	asm volatile(xstate_fault
		     : "0" (0)
		     : "memory");

		"1:"XSAVEOPT,
		"1:"XSAVES,
		"1: " XRSTORS,

Fixed code:
			     xstate_fault
			: "D" (fx), "m" (*fx), "a" (lmask), "d" (hmask)
			     xstate_fault
			: "D" (fx), "m" (*fx), "a" (lmask), "d" (hmask)
			     xstate_fault
			: "D" (fx), "m" (*fx), "a" (lmask), "d" (hmask)
			     xstate_fault
			: "D" (fx), "m" (*fx), "a" (lmask), "d" (hmask)
		XSAVEOPT,
		XSAVES,
		XRSTORS,
CVE-2016-7425 (C, published 2016-10-16T21:59Z)
Description: value: The arcmsr_iop_message_xfer function in drivers/scsi/arcmsr/arcmsr_hba.c in the Linux kernel through 4.8.2 does not restrict a certain length field, which allows local users to gain privileges or cause a denial of service (heap-based buffer overflow) via an ARCMSR_MESSAGE_WRITE_WQBUFFER control code.
Severity: HIGH (CVSS v3 base score: 7.8)
Weakness: CWE-119 \u2014 Improper Restriction of Operations within the Bounds of a Memory Buffer
The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.
Repository: https://github.com/torvalds/linux
Files changed:
drivers/scsi/arcmsr/arcmsr_hba.c
Commit message: scsi: arcmsr: Buffer overflow in arcmsr_iop_message_xfer()

We need to put an upper bound on "user_len" so the memcpy() doesn't
overflow.

Cc: <stable@vger.kernel.org>
Reported-by: Marco Grassi <marco.gra@gmail.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Tomas Henzl <thenzl@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>


Vulnerable code:
		int32_t user_len, cnt2end;

Fixed code:
		uint32_t user_len;
		int32_t cnt2end;
		if (user_len > ARCMSR_API_DATA_BUFLEN) {
			retvalue = ARCMSR_MESSAGE_FAIL;
			kfree(ver_addr);
			goto message_out;
		}
CVE-2015-8785 (C, published 2016-02-08T03:59Z)
Description: value: The fuse_fill_write_pages function in fs/fuse/file.c in the Linux kernel before 4.4 allows local users to cause a denial of service (infinite loop) via a writev system call that triggers a zero length for the first segment of an iov.
Severity: MEDIUM (CVSS v3 base score: 6.2)
Weakness: CWE-835 \u2014 Loop with Unreachable Exit Condition ('Infinite Loop')
The product contains an iteration or loop with an exit condition that cannot be reached, i.e., an infinite loop.
Repository: https://github.com/torvalds/linux
Files changed:
fs/fuse/file.c
Commit message: fuse: break infinite loop in fuse_fill_write_pages()

I got a report about unkillable task eating CPU. Further
investigation shows, that the problem is in the fuse_fill_write_pages()
function. If iov's first segment has zero length, we get an infinite
loop, because we never reach iov_iter_advance() call.

Fix this by calling iov_iter_advance() before repeating an attempt to
copy data from userspace.

A similar problem is described in 124d3b7041f ("fix writev regression:
pan hanging unkillable and un-straceable"). If zero-length segmend
is followed by segment with invalid address,
iov_iter_fault_in_readable() checks only first segment (zero-length),
iov_iter_copy_from_user_atomic() skips it, fails at second and
returns zero -> goto again without skipping zero-length segment.

Patch calls iov_iter_advance() before goto again: we'll skip zero-length
segment at second iteraction and iov_iter_fault_in_readable() will detect
invalid address.

Special thanks to Konstantin Khlebnikov, who helped a lot with the commit
description.

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Maxim Patlasov <mpatlasov@parallels.com>
Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Fixes: ea9b9907b82a ("fuse: implement perform_write")
Cc: <stable@vger.kernel.org>


Vulnerable code:
		iov_iter_advance(ii, tmp);

Fixed code:
		iov_iter_advance(ii, tmp);
CVE-2012-4467 (C, published 2012-10-10T21:55Z)
Description: value: The (1) do_siocgstamp and (2) do_siocgstampns functions in net/socket.c in the Linux kernel before 3.5.4 use an incorrect argument order, which allows local users to obtain sensitive information from kernel memory or cause a denial of service (system crash) via a crafted ioctl call.
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/socket.c
Commit message: Fix order of arguments to compat_put_time[spec|val]

Commit 644595f89620 ("compat: Handle COMPAT_USE_64BIT_TIME in
net/socket.c") introduced a bug where the helper functions to take
either a 64-bit or compat time[spec|val] got the arguments in the wrong
order, passing the kernel stack pointer off as a user pointer (and vice
versa).

Because of the user address range check, that in turn then causes an
EFAULT due to the user pointer range checking failing for the kernel
address.  Incorrectly resuling in a failed system call for 32-bit
processes with a 64-bit kernel.

On odder architectures like HP-PA (with separate user/kernel address
spaces), it can be used read kernel memory.

Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


Vulnerable code:
		err = compat_put_timeval(up, &ktv);
		err = compat_put_timespec(up, &kts);

Fixed code:
		err = compat_put_timeval(&ktv, up);
		err = compat_put_timespec(&kts, up);
CVE-2013-4512 (C, published 2013-11-12T14:35Z)
Description: value: Buffer overflow in the exitcode_proc_write function in arch/um/kernel/exitcode.c in the Linux kernel before 3.12 allows local users to cause a denial of service or possibly have unspecified other impact by leveraging root privileges for a write operation.
Severity: MEDIUM (CVSS v3 base score: )
Weakness: CWE-119 \u2014 Improper Restriction of Operations within the Bounds of a Memory Buffer
The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.
Repository: https://github.com/torvalds/linux
Files changed:
arch/um/kernel/exitcode.c
Commit message: uml: check length in exitcode_proc_write()

We don't cap the size of buffer from the user so we could write past the
end of the array here.  Only root can write to this file.

Reported-by: Nico Golde <nico@ngolde.de>
Reported-by: Fabian Yamaguchi <fabs@goesec.de>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


Vulnerable code:
	if (copy_from_user(buf, buffer, count))

Fixed code:
	size_t size;
	size = min(count, sizeof(buf));
	if (copy_from_user(buf, buffer, size))
CVE-2015-3331 (C, published 2015-05-27T10:59Z)
Description: value: The __driver_rfc4106_decrypt function in arch/x86/crypto/aesni-intel_glue.c in the Linux kernel before 3.19.3 does not properly determine the memory locations used for encrypted data, which allows context-dependent attackers to cause a denial of service (buffer overflow and system crash) or possibly execute arbitrary code by triggering a crypto API call, as demonstrated by use of a libkcapi test program with an AF_ALG(aead) socket.
Severity: HIGH (CVSS v3 base score: )
Weakness: CWE-119 \u2014 Improper Restriction of Operations within the Bounds of a Memory Buffer
The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.
Repository: https://github.com/torvalds/linux
Files changed:
arch/x86/crypto/aesni-intel_glue.c
Commit message: crypto: aesni - fix memory usage in GCM decryption

The kernel crypto API logic requires the caller to provide the
length of (ciphertext || authentication tag) as cryptlen for the
AEAD decryption operation. Thus, the cipher implementation must
calculate the size of the plaintext output itself and cannot simply use
cryptlen.

The RFC4106 GCM decryption operation tries to overwrite cryptlen memory
in req->dst. As the destination buffer for decryption only needs to hold
the plaintext memory but cryptlen references the input buffer holding
(ciphertext || authentication tag), the assumption of the destination
buffer length in RFC4106 GCM operation leads to a too large size. This
patch simply uses the already calculated plaintext size.

In addition, this patch fixes the offset calculation of the AAD buffer
pointer: as mentioned before, cryptlen already includes the size of the
tag. Thus, the tag does not need to be added. With the addition, the AAD
will be written beyond the already allocated buffer.

Note, this fixes a kernel crash that can be triggered from user space
via AF_ALG(aead) -- simply use the libkcapi test application
from [1] and update it to use rfc4106-gcm-aes.

Using [1], the changes were tested using CAVS vectors to demonstrate
that the crypto operation still delivers the right results.

[1] http://www.chronox.de/libkcapi.html

CC: Tadeusz Struk <tadeusz.struk@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Stephan Mueller <smueller@chronox.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>


Vulnerable code:
		assoc = (src + req->cryptlen + auth_tag_len);
		scatterwalk_map_and_copy(dst, req->dst, 0, req->cryptlen, 1);

Fixed code:
		assoc = (src + req->cryptlen);
		scatterwalk_map_and_copy(dst, req->dst, 0, tempCipherLen, 1);
CVE-2011-3363 (C, published 2012-05-24T23:55Z)
Description: value: The setup_cifs_sb function in fs/cifs/connect.c in the Linux kernel before 2.6.39 does not properly handle DFS referrals, which allows remote CIFS servers to cause a denial of service (system crash) by placing a referral at the root of a share.
Severity: MEDIUM (CVSS v3 base score: 6.5)
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/cifs/connect.c
Commit message: cifs: always do is_path_accessible check in cifs_mount

Currently, we skip doing the is_path_accessible check in cifs_mount if
there is no prefixpath. I have a report of at least one server however
that allows a TREE_CONNECT to a share that has a DFS referral at its
root. The reporter in this case was using a UNC that had no prefixpath,
so the is_path_accessible check was not triggered and the box later hit
a BUG() because we were chasing a DFS referral on the root dentry for
the mount.

This patch fixes this by removing the check for a zero-length
prefixpath.  That should make the is_path_accessible check be done in
this situation and should allow the client to chase the DFS referral at
mount time instead.

Cc: stable@kernel.org
Reported-and-Tested-by: Yogesh Sharma <ysharma@cymer.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>


Vulnerable code:
	if (!rc && cifs_sb->prepathlen && tcon) {

Fixed code:
	if (!rc && tcon) {
CVE-2017-18379 (C, published 2019-07-27T22:15Z)
Description: value: In the Linux kernel before 4.14, an out of boundary access happened in drivers/nvme/target/fc.c.
Severity: HIGH (CVSS v3 base score: 9.8)
Weakness: CWE-119 \u2014 Improper Restriction of Operations within the Bounds of a Memory Buffer
The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.
Repository: https://github.com/torvalds/linux
Files changed:
drivers/nvme/target/fc.c
Commit message: nvmet-fc: ensure target queue id within range.

When searching for queue id's ensure they are within the expected range.

Signed-off-by: James Smart <james.smart@broadcom.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>


Vulnerable code:

Fixed code:
	if (qid > NVMET_NR_QUEUES)
		return NULL;