Publicus/cvefixes-security-ir-graphrag huggingface dataset:
CVE-2013-1979: Permissions, Privileges, and Access Controls (CWE-264)
value: The scm_set_cred function in include/net/scm.h in the Linux kernel before 3.8.11 uses incorrect uid and gid values during credentials passing, which allows local users to gain privileges via a crafted application.
CWE description: Weaknesses in this category are related to the management of permissions, privileges, and other security features that are used to perform access control.
Published: 2013-05-03T11:57Z
Repository: https://github.com/torvalds/linux
Language: C
Files changed: include/net/scm.h
Commit date: 2013-04-20 16:56:42 -0400
Commit message: net: fix incorrect credentials passing

Commit 257b5358b32f ("scm: Capture the full credentials of the scm
sender") changed the credentials passing code to pass in the effective
uid/gid instead of the real uid/gid.

Obviously this doesn't matter most of the time (since normally they are
the same), but it results in differences for suid binaries when the wrong
uid/gid ends up being used.

This just undoes that (presumably unintentional) part of the commit.

Reported-by: Andy Lutomirski <luto@amacapital.net>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Serge E. Hallyn <serge@hallyn.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Diff: diff --git a/include/net/scm.h b/include/net/scm.h
index 975cca01048bee..b11708105681e0 100644
--- a/include/net/scm.h
+++ b/include/net/scm.h
@@ -54,12 +54,12 @@ static __inline__ void scm_set_cred(struct scm_cookie *scm,
 				    struct pid *pid, const struct cred *cred)
 {
 	scm->pid  = get_pid(pid);
 	scm->cred = cred ? get_cred(cred) : NULL;
 	scm->creds.pid = pid_vnr(pid);
-	scm->creds.uid = cred ? cred->euid : INVALID_UID;
-	scm->creds.gid = cred ? cred->egid : INVALID_GID;
+	scm->creds.uid = cred ? cred->uid : INVALID_UID;
+	scm->creds.gid = cred ? cred->gid : INVALID_GID;
 }
 
 static __inline__ void scm_destroy_cred(struct scm_cookie *scm)
 {
 	put_pid(scm->pid);

Vulnerable code: 	scm->creds.uid = cred ? cred->euid : INVALID_UID;
	scm->creds.gid = cred ? cred->egid : INVALID_GID;
Fixed code: 	scm->creds.uid = cred ? cred->uid : INVALID_UID;
	scm->creds.gid = cred ? cred->gid : INVALID_GID;
CVE-2016-4580: Exposure of Sensitive Information to an Unauthorized Actor (CWE-200)
value: The x25_negotiate_facilities function in net/x25/x25_facilities.c in the Linux kernel before 4.5.5 does not properly initialize a certain data structure, which allows attackers to obtain sensitive information from kernel stack memory via an X.25 Call Request.
CWE description: The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
CVSS v3 base score: 7.5
Published: 2016-05-23T10:59Z
Repository: https://github.com/torvalds/linux
Language: C
Files changed: net/x25/x25_facilities.c
Commit date: 2016-05-09 22:45:33 -0400
Commit message: net: fix a kernel infoleak in x25 module

Stack object "dte_facilities" is allocated in x25_rx_call_request(),
which is supposed to be initialized in x25_negotiate_facilities.
However, 5 fields (8 bytes in total) are not initialized. This
object is then copied to userland via copy_to_user, thus infoleak
occurs.

Signed-off-by: Kangjie Lu <kjlu@gatech.edu>
Signed-off-by: David S. Miller <davem@davemloft.net>

Diff: diff --git a/net/x25/x25_facilities.c b/net/x25/x25_facilities.c
index 7ecd04c213609..997ff7b2509b4 100644
--- a/net/x25/x25_facilities.c
+++ b/net/x25/x25_facilities.c
@@ -275,10 +275,11 @@ int x25_negotiate_facilities(struct sk_buff *skb, struct sock *sk,
 	struct x25_facilities theirs;
 	int len;
 
 	memset(&theirs, 0, sizeof(theirs));
 	memcpy(new, ours, sizeof(*new));
+	memset(dte, 0, sizeof(*dte));
 
 	len = x25_parse_facilities(skb, &theirs, dte, &x25->vc_facil_mask);
 	if (len < 0)
 		return len;
 

Fixed code: 	memset(dte, 0, sizeof(*dte));
CVE-2012-0207: Divide By Zero (CWE-369)
value: The igmp_heard_query function in net/ipv4/igmp.c in the Linux kernel before 3.2.1 allows remote attackers to cause a denial of service (divide-by-zero error and panic) via IGMP packets.
CWE description: The product divides a value by zero.
CVSS v3 base score: 7.5
Published: 2012-05-17T11:00Z
Repository: https://github.com/torvalds/linux
Language: C
Files changed: net/ipv4/igmp.c
Commit date: 2012-01-09 14:06:46 -0800
Commit message: igmp: Avoid zero delay when receiving odd mixture of IGMP queries

Commit 5b7c84066733c5dfb0e4016d939757b38de189e4 ('ipv4: correct IGMP
behavior on v3 query during v2-compatibility mode') added yet another
case for query parsing, which can result in max_delay = 0.  Substitute
a value of 1, as in the usual v3 case.

Reported-by: Simon McVittie <smcv@debian.org>
References: http://bugs.debian.org/654876
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>

Diff: diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index fa057d105befe..5104bc0bbdbe7 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -878,10 +878,12 @@ static void igmp_heard_query(struct in_device *in_dev, struct sk_buff *skb,
 		 * A real v2 host would use ih_code directly, while v3 has a
 		 * different encoding. We use the v3 encoding as more likely
 		 * to be intended in a v3 query.
 		 */
 		max_delay = IGMPV3_MRC(ih3->code)*(HZ/IGMP_TIMER_SCALE);
+		if (!max_delay)
+			max_delay = 1;	/* can't mod w/ 0 */
 	} else { /* v3 */
 		if (!pskb_may_pull(skb, sizeof(struct igmpv3_query)))
 			return;
 
 		ih3 = igmpv3_query_hdr(skb);

Fixed code: 		if (!max_delay)
			max_delay = 1;	/* can't mod w/ 0 */
CVE-2010-5332: Improper Restriction of Operations within the Bounds of a Memory Buffer (CWE-119)
value: In the Linux kernel before 2.6.37, an out of bounds array access happened in drivers/net/mlx4/port.c. When searching for a free entry in either mlx4_register_vlan() or mlx4_register_mac(), and there is no free entry, the loop terminates without updating the local variable free thus causing out of array bounds access.
CWE description: 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.
CVSS v3 base score: 5.6
Published: 2019-07-27T22:15Z
Repository: https://github.com/torvalds/linux
Language: C
Files changed: drivers/net/mlx4/port.c
Commit date: 2010-10-25 12:14:11 -0700
Commit message: mlx4_en: Fix out of bounds array access

When searching for a free entry in either mlx4_register_vlan() or
mlx4_register_mac(), and there is no free entry, the loop terminates without
updating the local variable free thus causing out of array bounds access. Fix
this by adding a proper check outside the loop.

Signed-off-by: Eli Cohen <eli@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>

Diff: diff --git a/drivers/net/mlx4/port.c b/drivers/net/mlx4/port.c
index 606aa58afdea..8674ad5764c4 100644
--- a/drivers/net/mlx4/port.c
+++ b/drivers/net/mlx4/port.c
@@ -109,10 +109,16 @@ int mlx4_register_mac(struct mlx4_dev *dev, u8 port, u64 mac, int *index)
 			*index = i;
 			++table->refs[i];
 			goto out;
 		}
 	}
+
+	if (free < 0) {
+		err = -ENOMEM;
+		goto out;
+	}
+
 	mlx4_dbg(dev, "Free MAC index is %d\n", free);
 
 	if (table->total == table->max) {
 		/* No free mac entries */
 		err = -ENOSPC;
@@ -203,10 +209,15 @@ int mlx4_register_vlan(struct mlx4_dev *dev, u8 port, u16 vlan, int *index)
 			++table->refs[i];
 			goto out;
 		}
 	}
 
+	if (free < 0) {
+		err = -ENOMEM;
+		goto out;
+	}
+
 	if (table->total == table->max) {
 		/* No free vlan entries */
 		err = -ENOSPC;
 		goto out;
 	}

Fixed code: 
	if (free < 0) {
		err = -ENOMEM;
		goto out;
	}

	if (free < 0) {
		err = -ENOMEM;
		goto out;
	}
CVE-2013-1959: Permissions, Privileges, and Access Controls (CWE-264)
value: kernel/user_namespace.c in the Linux kernel before 3.8.9 does not have appropriate capability requirements for the uid_map and gid_map files, which allows local users to gain privileges by opening a file within an unprivileged process and then modifying the file within a privileged process.
CWE description: Weaknesses in this category are related to the management of permissions, privileges, and other security features that are used to perform access control.
Published: 2013-05-03T11:57Z
Repository: https://github.com/torvalds/linux
Language: C
Files changed: kernel/user_namespace.c
Commit date: 2013-04-14 18:11:31 -0700
Commit message: userns: Check uid_map's opener's fsuid, not the current fsuid

Signed-off-by: Andy Lutomirski <luto@amacapital.net>

Diff: diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
index e2d4ace4481bb0..5c16f3aa757a03 100644
--- a/kernel/user_namespace.c
+++ b/kernel/user_namespace.c
@@ -795,16 +795,16 @@ static bool new_idmap_permitted(const struct file *file,
 	/* Allow mapping to your own filesystem ids */
 	if ((new_map->nr_extents == 1) && (new_map->extent[0].count == 1)) {
 		u32 id = new_map->extent[0].lower_first;
 		if (cap_setid == CAP_SETUID) {
 			kuid_t uid = make_kuid(ns->parent, id);
-			if (uid_eq(uid, current_fsuid()))
+			if (uid_eq(uid, file->f_cred->fsuid))
 				return true;
 		}
 		else if (cap_setid == CAP_SETGID) {
 			kgid_t gid = make_kgid(ns->parent, id);
-			if (gid_eq(gid, current_fsgid()))
+			if (gid_eq(gid, file->f_cred->fsgid))
 				return true;
 		}
 	}
 
 	/* Allow anyone to set a mapping that doesn't require privilege */

Vulnerable code: 			if (uid_eq(uid, current_fsuid()))
			if (gid_eq(gid, current_fsgid()))
Fixed code: 			if (uid_eq(uid, file->f_cred->fsuid))
			if (gid_eq(gid, file->f_cred->fsgid))
CVE-2012-6541: Exposure of Sensitive Information to an Unauthorized Actor (CWE-200)
value: The ccid3_hc_tx_getsockopt function in net/dccp/ccids/ccid3.c in the Linux kernel before 3.6 does not initialize a certain structure, which allows local users to obtain sensitive information from kernel stack memory via a crafted application.
CWE description: The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
Published: 2013-03-15T20:55Z
Repository: https://github.com/torvalds/linux
Language: C
Files changed: net/dccp/ccids/ccid3.c
Commit date: 2012-08-15 21:36:31 -0700
Commit message: dccp: fix info leak via getsockopt(DCCP_SOCKOPT_CCID_TX_INFO)

The CCID3 code fails to initialize the trailing padding bytes of struct
tfrc_tx_info added for alignment on 64 bit architectures. It that for
potentially leaks four bytes kernel stack via the getsockopt() syscall.
Add an explicit memset(0) before filling the structure to avoid the
info leak.

Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>

Diff: diff --git a/net/dccp/ccids/ccid3.c b/net/dccp/ccids/ccid3.c
index d65e98798ecaf..119c04317d48e 100644
--- a/net/dccp/ccids/ccid3.c
+++ b/net/dccp/ccids/ccid3.c
@@ -533,10 +533,11 @@ static int ccid3_hc_tx_getsockopt(struct sock *sk, const int optname, int len,
 
 	switch (optname) {
 	case DCCP_SOCKOPT_CCID_TX_INFO:
 		if (len < sizeof(tfrc))
 			return -EINVAL;
+		memset(&tfrc, 0, sizeof(tfrc));
 		tfrc.tfrctx_x	   = hc->tx_x;
 		tfrc.tfrctx_x_recv = hc->tx_x_recv;
 		tfrc.tfrctx_x_calc = hc->tx_x_calc;
 		tfrc.tfrctx_rtt	   = hc->tx_rtt;
 		tfrc.tfrctx_p	   = hc->tx_p;

Fixed code: 		memset(&tfrc, 0, sizeof(tfrc));
CVE-2017-17857: Improper Restriction of Operations within the Bounds of a Memory Buffer (CWE-119)
value: The check_stack_boundary function in kernel/bpf/verifier.c in the Linux kernel through 4.14.8 allows local users to cause a denial of service (memory corruption) or possibly have unspecified other impact by leveraging mishandling of invalid variable stack read operations.
CWE description: 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.
CVSS v3 base score: 7.8
Published: 2017-12-27T17:08Z
Repository: https://github.com/torvalds/linux
Language: C
Files changed: kernel/bpf/verifier.c
Commit date: 2017-12-21 02:15:41 +0100
Commit message: bpf: fix missing error return in check_stack_boundary()

Prevent indirect stack accesses at non-constant addresses, which would
permit reading and corrupting spilled pointers.

Fixes: f1174f77b50c ("bpf/verifier: rework value tracking")
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>

Diff: diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index ecdc265244ca1d..77e4b5223867a2 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -1301,10 +1301,11 @@ static int check_stack_boundary(struct bpf_verifier_env *env, int regno,
 		char tn_buf[48];
 
 		tnum_strn(tn_buf, sizeof(tn_buf), regs[regno].var_off);
 		verbose(env, "invalid variable stack read R%d var_off=%s\n",
 			regno, tn_buf);
+		return -EACCES;
 	}
 	off = regs[regno].off + regs[regno].var_off.value;
 	if (off >= 0 || off < -MAX_BPF_STACK || off + access_size > 0 ||
 	    access_size < 0 || (access_size == 0 && !zero_size_allowed)) {
 		verbose(env, "invalid stack type R%d off=%d access_size=%d\n",

Fixed code: 		return -EACCES;
CVE-2016-1583: Improper Restriction of Operations within the Bounds of a Memory Buffer (CWE-119)
value: The ecryptfs_privileged_open function in fs/ecryptfs/kthread.c in the Linux kernel before 4.6.3 allows local users to gain privileges or cause a denial of service (stack memory consumption) via vectors involving crafted mmap calls for /proc pathnames, leading to recursive pagefault handling.
CWE description: 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.
CVSS v3 base score: 7.8
Published: 2016-06-27T10:59Z
Repository: https://github.com/torvalds/linux
Language: Unknown
Commit date: 2016-06-10 12:10:02 -0700
Commit message: Merge branch 'stacking-fixes' (vfs stacking fixes from Jann)

Merge filesystem stacking fixes from Jann Horn.

* emailed patches from Jann Horn <jannh@google.com>:
  sched: panic on corrupted stack end
  ecryptfs: forbid opening files without mmap handler
  proc: prevent stacking filesystems on top
CVE-2013-1826: Other (NVD-CWE-Other)
value: The xfrm_state_netlink function in net/xfrm/xfrm_user.c in the Linux kernel before 3.5.7 does not properly handle error conditions in dump_one_state function calls, which allows local users to gain privileges or cause a denial of service (NULL pointer dereference and system crash) by leveraging the CAP_NET_ADMIN capability.
CWE description: NVD is only using a subset of CWE for mapping instead of the entire CWE, and the weakness type is not covered by that subset.
Published: 2013-03-22T11:59Z
Repository: https://github.com/torvalds/linux
Language: C
Files changed: net/xfrm/xfrm_user.c
Commit date: 2012-09-18 16:13:45 -0400
Commit message: xfrm_user: return error pointer instead of NULL

When dump_one_state() returns an error, e.g. because of a too small
buffer to dump the whole xfrm state, xfrm_state_netlink() returns NULL
instead of an error pointer. But its callers expect an error pointer
and therefore continue to operate on a NULL skbuff.

This could lead to a privilege escalation (execution of user code in
kernel context) if the attacker has CAP_NET_ADMIN and is able to map
address 0.

Signed-off-by: Mathias Krause <minipli@googlemail.com>
Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Diff: diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index e75d8e47f35ca..dac08e2a5a93e 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -876,23 +876,25 @@ static int xfrm_dump_sa(struct sk_buff *skb, struct netlink_callback *cb)
 static struct sk_buff *xfrm_state_netlink(struct sk_buff *in_skb,
 					  struct xfrm_state *x, u32 seq)
 {
 	struct xfrm_dump_info info;
 	struct sk_buff *skb;
+	int err;
 
 	skb = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_ATOMIC);
 	if (!skb)
 		return ERR_PTR(-ENOMEM);
 
 	info.in_skb = in_skb;
 	info.out_skb = skb;
 	info.nlmsg_seq = seq;
 	info.nlmsg_flags = 0;
 
-	if (dump_one_state(x, 0, &info)) {
+	err = dump_one_state(x, 0, &info);
+	if (err) {
 		kfree_skb(skb);
-		return NULL;
+		return ERR_PTR(err);
 	}
 
 	return skb;
 }
 

Vulnerable code: 	if (dump_one_state(x, 0, &info)) {
		return NULL;
Fixed code: 	int err;
	err = dump_one_state(x, 0, &info);
	if (err) {
		return ERR_PTR(err);
CVE-2013-3231: Exposure of Sensitive Information to an Unauthorized Actor (CWE-200)
value: The llc_ui_recvmsg function in net/llc/af_llc.c in the Linux kernel before 3.9-rc7 does not initialize a certain length variable, which allows local users to obtain sensitive information from kernel stack memory via a crafted recvmsg or recvfrom system call.
CWE description: The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
Published: 2013-04-22T11:41Z
Repository: https://github.com/torvalds/linux
Language: C
Files changed: net/llc/af_llc.c
Commit date: 2013-04-07 16:28:01 -0400
Commit message: llc: Fix missing msg_namelen update in llc_ui_recvmsg()

For stream sockets the code misses to update the msg_namelen member
to 0 and therefore makes net/socket.c leak the local, uninitialized
sockaddr_storage variable to userland -- 128 bytes of kernel stack
memory. The msg_namelen update is also missing for datagram sockets
in case the socket is shutting down during receive.

Fix both issues by setting msg_namelen to 0 early. It will be
updated later if we're going to fill the msg_name member.

Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Diff: diff --git a/net/llc/af_llc.c b/net/llc/af_llc.c
index 88709882c4641f..48aaa89253e037 100644
--- a/net/llc/af_llc.c
+++ b/net/llc/af_llc.c
@@ -718,10 +718,12 @@ static int llc_ui_recvmsg(struct kiocb *iocb, struct socket *sock,
 	u32 *seq;
 	unsigned long used;
 	int target;	/* Read at least this many bytes */
 	long timeo;
 
+	msg->msg_namelen = 0;
+
 	lock_sock(sk);
 	copied = -ENOTCONN;
 	if (unlikely(sk->sk_type == SOCK_STREAM && sk->sk_state == TCP_LISTEN))
 		goto out;
 

Fixed code: 	msg->msg_namelen = 0;
CVE-2014-9904: Other (NVD-CWE-Other)
value: The snd_compress_check_input function in sound/core/compress_offload.c in the ALSA subsystem in the Linux kernel before 3.17 does not properly check for an integer overflow, which allows local users to cause a denial of service (insufficient memory allocation) or possibly have unspecified other impact via a crafted SNDRV_COMPRESS_SET_PARAMS ioctl call.
CWE description: NVD is only using a subset of CWE for mapping instead of the entire CWE, and the weakness type is not covered by that subset.
CVSS v3 base score: 7.8
Published: 2016-06-27T10:59Z
Repository: https://github.com/torvalds/linux
Language: C
Files changed: sound/core/compress_offload.c
Commit date: 2014-07-16 15:27:03 +0200
Commit message: ALSA: compress: fix an integer overflow check

I previously added an integer overflow check here but looking at it now,
it's still buggy.

The bug happens in snd_compr_allocate_buffer().  We multiply
".fragments" and ".fragment_size" and that doesn't overflow but then we
save it in an unsigned int so it truncates the high bits away and we
allocate a smaller than expected size.

Fixes: b35cc8225845 ('ALSA: compress_core: integer overflow in snd_compr_allocate_buffer()')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Diff: diff --git a/sound/core/compress_offload.c b/sound/core/compress_offload.c
index 7403f348ed1425..89028fab64fdd2 100644
--- a/sound/core/compress_offload.c
+++ b/sound/core/compress_offload.c
@@ -489,11 +489,11 @@ static int snd_compr_allocate_buffer(struct snd_compr_stream *stream,
 
 static int snd_compress_check_input(struct snd_compr_params *params)
 {
 	/* first let's check the buffer parameter's */
 	if (params->buffer.fragment_size == 0 ||
-			params->buffer.fragments > SIZE_MAX / params->buffer.fragment_size)
+	    params->buffer.fragments > INT_MAX / params->buffer.fragment_size)
 		return -EINVAL;
 
 	/* now codec parameters */
 	if (params->codec.id == 0 || params->codec.id > SND_AUDIOCODEC_MAX)
 		return -EINVAL;

Vulnerable code: 			params->buffer.fragments > SIZE_MAX / params->buffer.fragment_size)
Fixed code: 	    params->buffer.fragments > INT_MAX / params->buffer.fragment_size)
CVE-2015-8962: Double Free (CWE-415)
value: Double free vulnerability in the sg_common_write function in drivers/scsi/sg.c in the Linux kernel before 4.4 allows local users to gain privileges or cause a denial of service (memory corruption and system crash) by detaching a device during an SG_IO ioctl call.
CWE description: The product calls free() twice on the same memory address, potentially leading to modification of unexpected memory locations.
CVSS v3 base score: 7.3
Published: 2016-11-16T05:59Z
Repository: https://github.com/torvalds/linux
Language: C
Files changed: drivers/scsi/sg.c
Commit date: 2015-11-02 23:51:25 -0500
Commit message: sg: Fix double-free when drives detach during SG_IO

In sg_common_write(), we free the block request and return -ENODEV if
the device is detached in the middle of the SG_IO ioctl().

Unfortunately, sg_finish_rem_req() also tries to free srp->rq, so we
end up freeing rq->cmd in the already free rq object, and then free
the object itself out from under the current user.

This ends up corrupting random memory via the list_head on the rq
object. The most common crash trace I saw is this:

  ------------[ cut here ]------------
  kernel BUG at block/blk-core.c:1420!
  Call Trace:
  [<ffffffff81281eab>] blk_put_request+0x5b/0x80
  [<ffffffffa0069e5b>] sg_finish_rem_req+0x6b/0x120 [sg]
  [<ffffffffa006bcb9>] sg_common_write.isra.14+0x459/0x5a0 [sg]
  [<ffffffff8125b328>] ? selinux_file_alloc_security+0x48/0x70
  [<ffffffffa006bf95>] sg_new_write.isra.17+0x195/0x2d0 [sg]
  [<ffffffffa006cef4>] sg_ioctl+0x644/0xdb0 [sg]
  [<ffffffff81170f80>] do_vfs_ioctl+0x90/0x520
  [<ffffffff81258967>] ? file_has_perm+0x97/0xb0
  [<ffffffff811714a1>] SyS_ioctl+0x91/0xb0
  [<ffffffff81602afb>] tracesys+0xdd/0xe2
    RIP [<ffffffff81281e04>] __blk_put_request+0x154/0x1a0

The solution is straightforward: just set srp->rq to NULL in the
failure branch so that sg_finish_rem_req() doesn't attempt to re-free
it.

Additionally, since sg_rq_end_io() will never be called on the object
when this happens, we need to free memory backing ->cmd if it isn't
embedded in the object itself.

KASAN was extremely helpful in finding the root cause of this bug.

Signed-off-by: Calvin Owens <calvinowens@fb.com>
Acked-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

Diff: diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index 9d7b7db75e4b96..503ab8b46c0b4e 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -785,12 +785,18 @@ sg_common_write(Sg_fd * sfp, Sg_request * srp,
 			"sg_common_write: start_req err=%d\n", k));
 		sg_finish_rem_req(srp);
 		return k;	/* probably out of space --> ENOMEM */
 	}
 	if (atomic_read(&sdp->detaching)) {
-		if (srp->bio)
+		if (srp->bio) {
+			if (srp->rq->cmd != srp->rq->__cmd)
+				kfree(srp->rq->cmd);
+
 			blk_end_request_all(srp->rq, -EIO);
+			srp->rq = NULL;
+		}
+
 		sg_finish_rem_req(srp);
 		return -ENODEV;
 	}
 
 	hp->duration = jiffies_to_msecs(jiffies);

Vulnerable code: 		if (srp->bio)
Fixed code: 		if (srp->bio) {
			if (srp->rq->cmd != srp->rq->__cmd)
				kfree(srp->rq->cmd);

			srp->rq = NULL;
		}
CVE-2014-2889: Numeric Errors (CWE-189)
value: Off-by-one error in the bpf_jit_compile function in arch/x86/net/bpf_jit_comp.c in the Linux kernel before 3.1.8, when BPF JIT is enabled, allows local users to cause a denial of service (system crash) or possibly gain privileges via a long jump after a conditional jump.
CWE description: Weaknesses in this category are related to improper calculation or conversion of numbers.
Published: 2014-04-27T00:55Z
Repository: https://github.com/torvalds/linux
Language: C
Files changed: arch/x86/net/bpf_jit_comp.c
Commit date: 2011-12-19 15:47:29 -0500
Commit message: net: bpf_jit: fix an off-one bug in x86_64 cond jump target

x86 jump instruction size is 2 or 5 bytes (near/long jump), not 2 or 6
bytes.

In case a conditional jump is followed by a long jump, conditional jump
target is one byte past the start of target instruction.

Signed-off-by: Markus Kötter <nepenthesdev@gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Diff: diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index bfab3fa10edc63..7b65f752c5f8fd 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -566,12 +566,12 @@ cond_branch:			f_offset = addrs[i + filter[i].jf] - addrs[i];
 						EMIT1_off32(0xa9, K); /* test imm32,%eax */
 					}
 					break;
 				}
 				if (filter[i].jt != 0) {
-					if (filter[i].jf)
-						t_offset += is_near(f_offset) ? 2 : 6;
+					if (filter[i].jf && f_offset)
+						t_offset += is_near(f_offset) ? 2 : 5;
 					EMIT_COND_JMP(t_op, t_offset);
 					if (filter[i].jf)
 						EMIT_JMP(f_offset);
 					break;
 				}

Vulnerable code: 					if (filter[i].jf)
						t_offset += is_near(f_offset) ? 2 : 6;
Fixed code: 					if (filter[i].jf && f_offset)
						t_offset += is_near(f_offset) ? 2 : 5;
CVE-2014-9729: Insufficient Information (NVD-CWE-noinfo)
value: The udf_read_inode function in fs/udf/inode.c in the Linux kernel before 3.18.2 does not ensure a certain data-structure size consistency, which allows local users to cause a denial of service (system crash) via a crafted UDF filesystem image.
CWE description: There is insufficient information about the issue to classify it; details are unkown or unspecified.
Published: 2015-08-31T10:59Z
Repository: https://github.com/torvalds/linux
Language: C
Files changed: fs/udf/inode.c
Commit date: 2014-12-19 13:13:05 +0100
Commit message: udf: Verify i_size when loading inode

Verify that inode size is sane when loading inode with data stored in
ICB. Otherwise we may get confused later when working with the inode and
inode size is too big.

CC: stable@vger.kernel.org
Reported-by: Carl Henrik Lunde <chlunde@ping.uio.no>
Signed-off-by: Jan Kara <jack@suse.cz>

Diff: diff --git a/fs/udf/inode.c b/fs/udf/inode.c
index c9b4df5810d525..5bc71d9a674a7e 100644
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -1487,10 +1487,24 @@ static int udf_read_inode(struct inode *inode, bool hidden_inode)
 		iinfo->i_lenAlloc = le32_to_cpu(efe->lengthAllocDescs);
 		iinfo->i_checkpoint = le32_to_cpu(efe->checkpoint);
 	}
 	inode->i_generation = iinfo->i_unique;
 
+	/* Sanity checks for files in ICB so that we don't get confused later */
+	if (iinfo->i_alloc_type == ICBTAG_FLAG_AD_IN_ICB) {
+		/*
+		 * For file in ICB data is stored in allocation descriptor
+		 * so sizes should match
+		 */
+		if (iinfo->i_lenAlloc != inode->i_size)
+			goto out;
+		/* File in ICB has to fit in there... */
+		if (inode->i_size > inode->i_sb->s_blocksize -
+					udf_file_entry_alloc_offset(inode))
+			goto out;
+	}
+
 	switch (fe->icbTag.fileType) {
 	case ICBTAG_FILE_TYPE_DIRECTORY:
 		inode->i_op = &udf_dir_inode_operations;
 		inode->i_fop = &udf_dir_operations;
 		inode->i_mode |= S_IFDIR;

Fixed code: 	/* Sanity checks for files in ICB so that we don't get confused later */
	if (iinfo->i_alloc_type == ICBTAG_FLAG_AD_IN_ICB) {
		/*
		 * For file in ICB data is stored in allocation descriptor
		 * so sizes should match
		 */
		if (iinfo->i_lenAlloc != inode->i_size)
			goto out;
		/* File in ICB has to fit in there... */
		if (inode->i_size > inode->i_sb->s_blocksize -
					udf_file_entry_alloc_offset(inode))
			goto out;
	}
CVE-2014-9683: Numeric Errors (CWE-189)
value: Off-by-one error in the ecryptfs_decode_from_filename function in fs/ecryptfs/crypto.c in the eCryptfs subsystem in the Linux kernel before 3.18.2 allows local users to cause a denial of service (buffer overflow and system crash) or possibly gain privileges via a crafted filename.
CWE description: Weaknesses in this category are related to improper calculation or conversion of numbers.
Published: 2015-03-03T11:59Z
Repository: https://github.com/torvalds/linux
Language: C
Files changed: fs/ecryptfs/crypto.c
Commit date: 2014-11-26 15:55:02 -0600
Commit message: eCryptfs: Remove buggy and unnecessary write in file name decode routine

Dmitry Chernenkov used KASAN to discover that eCryptfs writes past the
end of the allocated buffer during encrypted filename decoding. This
fix corrects the issue by getting rid of the unnecessary 0 write when
the current bit offset is 2.

Signed-off-by: Michael Halcrow <mhalcrow@google.com>
Reported-by: Dmitry Chernenkov <dmitryc@google.com>
Suggested-by: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org # v2.6.29+: 51ca58d eCryptfs: Filename Encryption: Encoding and encryption functions
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>

Diff: diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c
index 2f6735dbf1a9de..31b148f3e7729d 100644
--- a/fs/ecryptfs/crypto.c
+++ b/fs/ecryptfs/crypto.c
@@ -1915,11 +1915,10 @@ ecryptfs_decode_from_filename(unsigned char *dst, size_t *dst_size,
 			dst[dst_byte_offset] = (src_byte << 6);
 			current_bit_offset = 2;
 			break;
 		case 2:
 			dst[dst_byte_offset++] |= (src_byte);
-			dst[dst_byte_offset] = 0;
 			current_bit_offset = 0;
 			break;
 		}
 		src_byte_offset++;
 	}

Vulnerable code: 			dst[dst_byte_offset] = 0;
CVE-2016-3140: Other (NVD-CWE-Other)
value: The digi_port_init function in drivers/usb/serial/digi_acceleport.c in the Linux kernel before 4.5.1 allows physically proximate attackers to cause a denial of service (NULL pointer dereference and system crash) via a crafted endpoints value in a USB device descriptor.
CWE description: NVD is only using a subset of CWE for mapping instead of the entire CWE, and the weakness type is not covered by that subset.
CVSS v3 base score: 4.6
Published: 2016-05-02T10:59Z
Repository: https://github.com/torvalds/linux
Language: C
Files changed: drivers/usb/serial/digi_acceleport.c
Commit date: 2016-03-31 09:28:46 -0700
Commit message: USB: digi_acceleport: do sanity checking for the number of ports

The driver can be crashed with devices that expose crafted descriptors
with too few endpoints.

See: http://seclists.org/bugtraq/2016/Mar/61

Signed-off-by: Oliver Neukum <ONeukum@suse.com>
[johan: fix OOB endpoint check and add error messages ]
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Diff: diff --git a/drivers/usb/serial/digi_acceleport.c b/drivers/usb/serial/digi_acceleport.c
index 010a42a926889..16e8e37b3b36d 100644
--- a/drivers/usb/serial/digi_acceleport.c
+++ b/drivers/usb/serial/digi_acceleport.c
@@ -1249,12 +1249,31 @@ static int digi_port_init(struct usb_serial_port *port, unsigned port_num)
 	return 0;
 }
 
 static int digi_startup(struct usb_serial *serial)
 {
+	struct device *dev = &serial->interface->dev;
 	struct digi_serial *serial_priv;
 	int ret;
+	int i;
+
+	/* check whether the device has the expected number of endpoints */
+	if (serial->num_port_pointers < serial->type->num_ports + 1) {
+		dev_err(dev, "OOB endpoints missing\n");
+		return -ENODEV;
+	}
+
+	for (i = 0; i < serial->type->num_ports + 1 ; i++) {
+		if (!serial->port[i]->read_urb) {
+			dev_err(dev, "bulk-in endpoint missing\n");
+			return -ENODEV;
+		}
+		if (!serial->port[i]->write_urb) {
+			dev_err(dev, "bulk-out endpoint missing\n");
+			return -ENODEV;
+		}
+	}
 
 	serial_priv = kzalloc(sizeof(*serial_priv), GFP_KERNEL);
 	if (!serial_priv)
 		return -ENOMEM;
 

Fixed code: 	struct device *dev = &serial->interface->dev;
	int i;

	/* check whether the device has the expected number of endpoints */
	if (serial->num_port_pointers < serial->type->num_ports + 1) {
		dev_err(dev, "OOB endpoints missing\n");
		return -ENODEV;
	}

	for (i = 0; i < serial->type->num_ports + 1 ; i++) {
		if (!serial->port[i]->read_urb) {
			dev_err(dev, "bulk-in endpoint missing\n");
			return -ENODEV;
		}
		if (!serial->port[i]->write_urb) {
			dev_err(dev, "bulk-out endpoint missing\n");
			return -ENODEV;
		}
	}
CVE-2015-6252: Resource Management Errors (CWE-399)
value: The vhost_dev_ioctl function in drivers/vhost/vhost.c in the Linux kernel before 4.1.5 allows local users to cause a denial of service (memory consumption) via a VHOST_SET_LOG_FD ioctl call that triggers permanent file-descriptor allocation.
CWE description: Weaknesses in this category are related to improper management of system resources.
Published: 2015-10-19T10:59Z
Repository: https://github.com/torvalds/linux
Language: C
Files changed: drivers/vhost/vhost.c
Commit date: 2015-07-27 18:04:58 +0300
Commit message: vhost: actually track log eventfd file

While reviewing vhost log code, I found out that log_file is never
set. Note: I haven't tested the change (QEMU doesn't use LOG_FD yet).

Cc: stable@vger.kernel.org
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Diff: diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index a9fe859f43c874..95bdb90fd7f06a 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -993,10 +993,11 @@ long vhost_dev_ioctl(struct vhost_dev *d, unsigned int ioctl, void __user *argp)
 			r = PTR_ERR(eventfp);
 			break;
 		}
 		if (eventfp != d->log_file) {
 			filep = d->log_file;
+			d->log_file = eventfp;
 			ctx = d->log_ctx;
 			d->log_ctx = eventfp ?
 				eventfd_ctx_fileget(eventfp) : NULL;
 		} else
 			filep = eventfp;

Fixed code: 			d->log_file = eventfp;
CVE-2016-3951: Other (NVD-CWE-Other)
value: Double free vulnerability in drivers/net/usb/cdc_ncm.c in the Linux kernel before 4.5 allows physically proximate attackers to cause a denial of service (system crash) or possibly have unspecified other impact by inserting a USB device with an invalid USB descriptor.
CWE description: NVD is only using a subset of CWE for mapping instead of the entire CWE, and the weakness type is not covered by that subset.
CVSS v3 base score: 4.6
Published: 2016-05-02T10:59Z
Repository: https://github.com/torvalds/linux
Language: C
Files changed: drivers/net/usb/usbnet.c
Commit date: 2016-03-07 11:40:16 -0500
Commit message: usbnet: cleanup after bind() in probe()

In case bind() works, but a later error forces bailing
in probe() in error cases work and a timer may be scheduled.
They must be killed. This fixes an error case related to
the double free reported in
http://www.spinics.net/lists/netdev/msg367669.html
and needs to go on top of Linus' fix to cdc-ncm.

Signed-off-by: Oliver Neukum <ONeukum@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Diff: diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 0b0ba7ef14e4e..10798128c03fc 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -1767,10 +1767,17 @@ usbnet_probe (struct usb_interface *udev, const struct usb_device_id *prod)
 	usb_free_urb(dev->interrupt);
 out3:
 	if (info->unbind)
 		info->unbind (dev, udev);
 out1:
+	/* subdrivers must undo all they did in bind() if they
+	 * fail it, but we may fail later and a deferred kevent
+	 * may trigger an error resubmitting itself and, worse,
+	 * schedule a timer. So we kill it all just in case.
+	 */
+	cancel_work_sync(&dev->kevent);
+	del_timer_sync(&dev->delay);
 	free_netdev(net);
 out:
 	return status;
 }
 EXPORT_SYMBOL_GPL(usbnet_probe);

Fixed code: 	/* subdrivers must undo all they did in bind() if they
	 * fail it, but we may fail later and a deferred kevent
	 * may trigger an error resubmitting itself and, worse,
	 * schedule a timer. So we kill it all just in case.
	 */
	cancel_work_sync(&dev->kevent);
	del_timer_sync(&dev->delay);
CVE-2016-7912: Use After Free (CWE-416)
value: Use-after-free vulnerability in the ffs_user_copy_worker function in drivers/usb/gadget/function/f_fs.c in the Linux kernel before 4.5.3 allows local users to gain privileges by accessing an I/O data structure after a certain callback call.
CWE description: The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.
CVSS v3 base score: 7.8
Published: 2016-11-16T05:59Z
Repository: https://github.com/torvalds/linux
Language: C
Files changed: drivers/usb/gadget/function/f_fs.c
Commit date: 2016-04-20 10:38:06 +0300
Commit message: usb: gadget: f_fs: Fix use-after-free

When using asynchronous read or write operations on the USB endpoints the
issuer of the IO request is notified by calling the ki_complete() callback
of the submitted kiocb when the URB has been completed.

Calling this ki_complete() callback will free kiocb. Make sure that the
structure is no longer accessed beyond that point, otherwise undefined
behaviour might occur.

Fixes: 2e4c7553cd6f ("usb: gadget: f_fs: add aio support")
Cc: <stable@vger.kernel.org> # v3.15+
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>

Diff: diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c
index e21ca2bd6839e..15b648cbc75c4 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -644,10 +644,11 @@ static void ffs_user_copy_worker(struct work_struct *work)
 {
 	struct ffs_io_data *io_data = container_of(work, struct ffs_io_data,
 						   work);
 	int ret = io_data->req->status ? io_data->req->status :
 					 io_data->req->actual;
+	bool kiocb_has_eventfd = io_data->kiocb->ki_flags & IOCB_EVENTFD;
 
 	if (io_data->read && ret > 0) {
 		use_mm(io_data->mm);
 		ret = copy_to_iter(io_data->buf, ret, &io_data->data);
 		if (iov_iter_count(&io_data->data))
@@ -655,17 +656,15 @@ static void ffs_user_copy_worker(struct work_struct *work)
 		unuse_mm(io_data->mm);
 	}
 
 	io_data->kiocb->ki_complete(io_data->kiocb, ret, ret);
 
-	if (io_data->ffs->ffs_eventfd &&
-	    !(io_data->kiocb->ki_flags & IOCB_EVENTFD))
+	if (io_data->ffs->ffs_eventfd && !kiocb_has_eventfd)
 		eventfd_signal(io_data->ffs->ffs_eventfd, 1);
 
 	usb_ep_free_request(io_data->ep, io_data->req);
 
-	io_data->kiocb->private = NULL;
 	if (io_data->read)
 		kfree(io_data->to_free);
 	kfree(io_data->buf);
 	kfree(io_data);
 }

Vulnerable code: 	if (io_data->ffs->ffs_eventfd &&
	    !(io_data->kiocb->ki_flags & IOCB_EVENTFD))
	io_data->kiocb->private = NULL;
Fixed code: 	bool kiocb_has_eventfd = io_data->kiocb->ki_flags & IOCB_EVENTFD;
	if (io_data->ffs->ffs_eventfd && !kiocb_has_eventfd)
CVE-2013-3227: Exposure of Sensitive Information to an Unauthorized Actor (CWE-200)
value: The caif_seqpkt_recvmsg function in net/caif/caif_socket.c in the Linux kernel before 3.9-rc7 does not initialize a certain length variable, which allows local users to obtain sensitive information from kernel stack memory via a crafted recvmsg or recvfrom system call.
CWE description: The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
Published: 2013-04-22T11:41Z
Repository: https://github.com/torvalds/linux
Language: C
Files changed: net/caif/caif_socket.c
Commit date: 2013-04-07 16:28:01 -0400
Commit message: caif: Fix missing msg_namelen update in caif_seqpkt_recvmsg()

The current code does not fill the msg_name member in case it is set.
It also does not set the msg_namelen member to 0 and therefore makes
net/socket.c leak the local, uninitialized sockaddr_storage variable
to userland -- 128 bytes of kernel stack memory.

Fix that by simply setting msg_namelen to 0 as obviously nobody cared
about caif_seqpkt_recvmsg() not filling the msg_name in case it was
set.

Cc: Sjur Braendeland <sjur.brandeland@stericsson.com>
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Diff: diff --git a/net/caif/caif_socket.c b/net/caif/caif_socket.c
index 095259f839023a..ff2ff3ce6965a7 100644
--- a/net/caif/caif_socket.c
+++ b/net/caif/caif_socket.c
@@ -284,10 +284,12 @@ static int caif_seqpkt_recvmsg(struct kiocb *iocb, struct socket *sock,
 
 	ret = -EOPNOTSUPP;
 	if (m->msg_flags&MSG_OOB)
 		goto read_error;
 
+	m->msg_namelen = 0;
+
 	skb = skb_recv_datagram(sk, flags, 0 , &ret);
 	if (!skb)
 		goto read_error;
 	copylen = skb->len;
 	if (len < copylen) {

Fixed code: 	m->msg_namelen = 0;
CVE-2013-3226: Exposure of Sensitive Information to an Unauthorized Actor (CWE-200)
value: The sco_sock_recvmsg function in net/bluetooth/sco.c in the Linux kernel before 3.9-rc7 does not initialize a certain length variable, which allows local users to obtain sensitive information from kernel stack memory via a crafted recvmsg or recvfrom system call.
CWE description: The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
Published: 2013-04-22T11:41Z
Repository: https://github.com/torvalds/linux
Language: C
Files changed: net/bluetooth/sco.c
Commit date: 2013-04-07 16:28:01 -0400
Commit message: Bluetooth: SCO - Fix missing msg_namelen update in sco_sock_recvmsg()

If the socket is in state BT_CONNECT2 and BT_SK_DEFER_SETUP is set in
the flags, sco_sock_recvmsg() returns early with 0 without updating the
possibly set msg_namelen member. This, in turn, leads to a 128 byte
kernel stack leak in net/socket.c.

Fix this by updating msg_namelen in this case. For all other cases it
will be handled in bt_sock_recvmsg().

Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Diff: diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
index fad0302bdb325e..fb6192c9812e81 100644
--- a/net/bluetooth/sco.c
+++ b/net/bluetooth/sco.c
@@ -663,10 +663,11 @@ static int sco_sock_recvmsg(struct kiocb *iocb, struct socket *sock,
 
 	if (sk->sk_state == BT_CONNECT2 &&
 	    test_bit(BT_SK_DEFER_SETUP, &bt_sk(sk)->flags)) {
 		hci_conn_accept(pi->conn->hcon, 0);
 		sk->sk_state = BT_CONFIG;
+		msg->msg_namelen = 0;
 
 		release_sock(sk);
 		return 0;
 	}
 

Fixed code: 		msg->msg_namelen = 0;
CVE-2014-9728: Improper Restriction of Operations within the Bounds of a Memory Buffer (CWE-119)
value: The UDF filesystem implementation in the Linux kernel before 3.18.2 does not validate certain lengths, which allows local users to cause a denial of service (buffer over-read and system crash) via a crafted filesystem image, related to fs/udf/inode.c and fs/udf/symlink.c.
CWE description: 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.
Published: 2015-08-31T10:59Z
Repository: https://github.com/torvalds/linux
Language: C
Files changed: fs/udf/inode.c
Commit date: 2014-12-19 13:13:05 +0100
Commit message: udf: Verify i_size when loading inode

Verify that inode size is sane when loading inode with data stored in
ICB. Otherwise we may get confused later when working with the inode and
inode size is too big.

CC: stable@vger.kernel.org
Reported-by: Carl Henrik Lunde <chlunde@ping.uio.no>
Signed-off-by: Jan Kara <jack@suse.cz>

Diff: diff --git a/fs/udf/inode.c b/fs/udf/inode.c
index c9b4df5810d525..5bc71d9a674a7e 100644
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -1487,10 +1487,24 @@ static int udf_read_inode(struct inode *inode, bool hidden_inode)
 		iinfo->i_lenAlloc = le32_to_cpu(efe->lengthAllocDescs);
 		iinfo->i_checkpoint = le32_to_cpu(efe->checkpoint);
 	}
 	inode->i_generation = iinfo->i_unique;
 
+	/* Sanity checks for files in ICB so that we don't get confused later */
+	if (iinfo->i_alloc_type == ICBTAG_FLAG_AD_IN_ICB) {
+		/*
+		 * For file in ICB data is stored in allocation descriptor
+		 * so sizes should match
+		 */
+		if (iinfo->i_lenAlloc != inode->i_size)
+			goto out;
+		/* File in ICB has to fit in there... */
+		if (inode->i_size > inode->i_sb->s_blocksize -
+					udf_file_entry_alloc_offset(inode))
+			goto out;
+	}
+
 	switch (fe->icbTag.fileType) {
 	case ICBTAG_FILE_TYPE_DIRECTORY:
 		inode->i_op = &udf_dir_inode_operations;
 		inode->i_fop = &udf_dir_operations;
 		inode->i_mode |= S_IFDIR;

Fixed code: 	/* Sanity checks for files in ICB so that we don't get confused later */
	if (iinfo->i_alloc_type == ICBTAG_FLAG_AD_IN_ICB) {
		/*
		 * For file in ICB data is stored in allocation descriptor
		 * so sizes should match
		 */
		if (iinfo->i_lenAlloc != inode->i_size)
			goto out;
		/* File in ICB has to fit in there... */
		if (inode->i_size > inode->i_sb->s_blocksize -
					udf_file_entry_alloc_offset(inode))
			goto out;
	}
CVE-2013-3230: Exposure of Sensitive Information to an Unauthorized Actor (CWE-200)
value: The l2tp_ip6_recvmsg function in net/l2tp/l2tp_ip6.c in the Linux kernel before 3.9-rc7 does not initialize a certain structure member, which allows local users to obtain sensitive information from kernel stack memory via a crafted recvmsg or recvfrom system call.
CWE description: The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
Published: 2013-04-22T11:41Z
Repository: https://github.com/torvalds/linux
Language: C
Files changed: net/l2tp/l2tp_ip6.c
Commit date: 2013-04-07 16:28:01 -0400
Commit message: l2tp: fix info leak in l2tp_ip6_recvmsg()

The L2TP code for IPv6 fails to initialize the l2tp_conn_id member of
struct sockaddr_l2tpip6 and therefore leaks four bytes kernel stack
in l2tp_ip6_recvmsg() in case msg_name is set.

Initialize l2tp_conn_id with 0 to avoid the info leak.

Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Diff: diff --git a/net/l2tp/l2tp_ip6.c b/net/l2tp/l2tp_ip6.c
index c74f5a91ff6a32..b8a6039314e868 100644
--- a/net/l2tp/l2tp_ip6.c
+++ b/net/l2tp/l2tp_ip6.c
@@ -688,10 +688,11 @@ static int l2tp_ip6_recvmsg(struct kiocb *iocb, struct sock *sk,
 		lsa->l2tp_family = AF_INET6;
 		lsa->l2tp_unused = 0;
 		lsa->l2tp_addr = ipv6_hdr(skb)->saddr;
 		lsa->l2tp_flowinfo = 0;
 		lsa->l2tp_scope_id = 0;
+		lsa->l2tp_conn_id = 0;
 		if (ipv6_addr_type(&lsa->l2tp_addr) & IPV6_ADDR_LINKLOCAL)
 			lsa->l2tp_scope_id = IP6CB(skb)->iif;
 	}
 
 	if (np->rxopt.all)

Fixed code: 		lsa->l2tp_conn_id = 0;