hitoshura25/cvefixes huggingface dataset:
CVE-2023-3212 (C, published 2023-06-23T20:15Z)
Description: value: A NULL pointer dereference issue was found in the gfs2 file system in the Linux kernel. It occurs on corrupt gfs2 file systems when the evict code tries to reference the journal descriptor structure after it has been freed and set to NULL. A privileged local user could use this flaw to cause a kernel panic.
Severity: nan (CVSS v3 base score: 4.4)
Weakness: CWE-476 \u2014 NULL Pointer Dereference
The product dereferences a pointer that it expects to be valid but is NULL.
Repository: https://github.com/torvalds/linux
Files changed:
fs/gfs2/super.c
Commit message: gfs2: Don't deref jdesc in evict

On corrupt gfs2 file systems the evict code can try to reference the
journal descriptor structure, jdesc, after it has been freed and set to
NULL. The sequence of events is:

init_journal()
...
fail_jindex:
   gfs2_jindex_free(sdp); <------frees journals, sets jdesc = NULL
      if (gfs2_holder_initialized(&ji_gh))
         gfs2_glock_dq_uninit(&ji_gh);
fail:
   iput(sdp->sd_jindex); <--references jdesc in evict_linked_inode
      evict()
         gfs2_evict_inode()
            evict_linked_inode()
               ret = gfs2_trans_begin(sdp, 0, sdp->sd_jdesc->jd_blocks);
<------references the now freed/zeroed sd_jdesc pointer.

The call to gfs2_trans_begin is done because the truncate_inode_pages
call can cause gfs2 events that require a transaction, such as removing
journaled data (jdata) blocks from the journal.

This patch fixes the problem by adding a check for sdp->sd_jdesc to
function gfs2_evict_inode. In theory, this should only happen to corrupt
gfs2 file systems, when gfs2 detects the problem, reports it, then tries
to evict all the system inodes it has read in up to that point.

Reported-by: Yang Lan <lanyang0908@gmail.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>


Vulnerable code:

Fixed code:
	/*
	 * In case of an incomplete mount, gfs2_evict_inode() may be called for
	 * system files without having an active journal to write to.  In that
	 * case, skip the filesystem evict.
	 */
	if (!sdp->sd_jdesc)
		goto out;
CVE-2022-3170 (C, published 2022-09-13T16:15Z)
Description: value: An out-of-bounds access issue was found in the Linux kernel sound subsystem. It could occur when the 'id->name' provided by the user did not end with '\0'. A privileged local user could pass a specially crafted name through ioctl() interface and crash the system or potentially escalate their privileges on the system.
Severity: nan (CVSS v3 base score: 7.8)
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:
sound/core/control.c
Commit message: ALSA: control: Re-order bounds checking in get_ctl_id_hash()

These two checks are in the reverse order so it might read one element
beyond the end of the array.  First check if the "i" is within bounds
before using it.

Fixes: 6ab55ec0a938 ("ALSA: control: Fix an out-of-bounds bug in get_ctl_id_hash()")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/YwjgNh/gkG1hH7po@kili
Signed-off-by: Takashi Iwai <tiwai@suse.de>


Vulnerable code:
	for (i = 0; id->name[i] && i < SNDRV_CTL_ELEM_ID_NAME_MAXLEN; i++)

Fixed code:
	for (i = 0; i < SNDRV_CTL_ELEM_ID_NAME_MAXLEN && id->name[i]; i++)
CVE-2023-23003 (C, published 2023-03-01T20:15Z)
Description: value: In the Linux kernel before 5.16, tools/perf/util/expr.c lacks a check for the hashmap__new return value.
Severity: nan (CVSS v3 base score: 4)
Weakness: CWE-252 \u2014 Unchecked Return Value
The product does not check the return value from a method or function, which can prevent it from detecting unexpected states and conditions.
Repository: https://github.com/torvalds/linux
Files changed:
tools/perf/util/expr.c
Commit message: perf expr: Fix missing check for return value of hashmap__new()

The hashmap__new() function may return ERR_PTR(-ENOMEM) when malloc()
fails, add IS_ERR() checking for ctx->ids.

Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lore.kernel.org/lkml/20211212062504.25841-1-linmq006@gmail.com
[ s/kfree()/free()/ and add missing linux/err.h include ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>


Vulnerable code:

Fixed code:
#include <linux/err.h>
	if (IS_ERR(ctx->ids)) {
		free(ctx);
		return NULL;
	}
CVE-2017-6348 (C, published 2017-03-01T20:59Z)
Description: value: The hashbin_delete function in net/irda/irqueue.c in the Linux kernel before 4.9.13 improperly manages lock dropping, which allows local users to cause a denial of service (deadlock) via crafted operations on IrDA devices.
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/irda/irqueue.c
Commit message: irda: Fix lockdep annotations in hashbin_delete().

A nested lock depth was added to the hasbin_delete() code but it
doesn't actually work some well and results in tons of lockdep splats.

Fix the code instead to properly drop the lock around the operation
and just keep peeking the head of the hashbin queue.

Reported-by: Dmitry Vyukov <dvyukov@google.com>
Tested-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>


Vulnerable code:
#ifdef CONFIG_LOCKDEP
static int hashbin_lock_depth = 0;
#endif
	if ( hashbin->hb_type & HB_LOCK ) {
		spin_lock_irqsave_nested(&hashbin->hb_spinlock, flags,
					 hashbin_lock_depth++);
	}
		queue = dequeue_first((irda_queue_t**) &hashbin->hb_queue[i]);
		while (queue ) {
			if (free_func)
				(*free_func)(queue);
			queue = dequeue_first(
				(irda_queue_t**) &hashbin->hb_queue[i]);
	if ( hashbin->hb_type & HB_LOCK) {
#ifdef CONFIG_LOCKDEP
		hashbin_lock_depth--;
#endif
	}

Fixed code:
	if (hashbin->hb_type & HB_LOCK)
		spin_lock_irqsave(&hashbin->hb_spinlock, flags);
		while (1) {
			queue = dequeue_first((irda_queue_t**) &hashbin->hb_queue[i]);

			if (!queue)
				break;

			if (free_func) {
				if (hashbin->hb_type & HB_LOCK)
					spin_unlock_irqrestore(&hashbin->hb_spinlock, flags);
				free_func(queue);
				if (hashbin->hb_type & HB_LOCK)
					spin_lock_irqsave(&hashbin->hb_spinlock, flags);
			}
	if (hashbin->hb_type & HB_LOCK)
CVE-2017-7277 (C, published 2017-03-28T06:59Z)
Description: value: The TCP stack in the Linux kernel through 4.10.6 mishandles the SCM_TIMESTAMPING_OPT_STATS feature, which allows local users to obtain sensitive information from the kernel's internal socket data structures or cause a denial of service (out-of-bounds read) via crafted system calls, related to net/core/skbuff.c and net/socket.c.
Severity: MEDIUM (CVSS v3 base score: 7.1)
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:
net/core/skbuff.c
net/socket.c
Commit message: tcp: fix SCM_TIMESTAMPING_OPT_STATS for normal skbs

__sock_recv_timestamp can be called for both normal skbs (for
receive timestamps) and for skbs on the error queue (for transmit
timestamps).

Commit 1c885808e456
(tcp: SOF_TIMESTAMPING_OPT_STATS option for SO_TIMESTAMPING)
assumes any skb passed to __sock_recv_timestamp are from
the error queue, containing OPT_STATS in the content of the skb.
This results in accessing invalid memory or generating junk
data.

To fix this, set skb->pkt_type to PACKET_OUTGOING for packets
on the error queue. This is safe because on the receive path
on local sockets skb->pkt_type is never set to PACKET_OUTGOING.
With that, copy OPT_STATS from a packet, only if its pkt_type
is PACKET_OUTGOING.

Fixes: 1c885808e456 ("tcp: SOF_TIMESTAMPING_OPT_STATS option for SO_TIMESTAMPING")
Reported-by: JongHwan Kim <zzoru007@gmail.com>
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>


Vulnerable code:
		if (skb->len && (sk->sk_tsflags & SOF_TIMESTAMPING_OPT_STATS))

Fixed code:
static void skb_set_err_queue(struct sk_buff *skb)
{
	/* pkt_type of skbs received on local sockets is never PACKET_OUTGOING.
	 * So, it is safe to (mis)use it to mark skbs on the error queue.
	 */
	skb->pkt_type = PACKET_OUTGOING;
	BUILD_BUG_ON(PACKET_OUTGOING == 0);
}

	skb_set_err_queue(skb);
static bool skb_is_err_queue(const struct sk_buff *skb)
{
	/* pkt_type of skbs enqueued on the error queue are set to
	 * PACKET_OUTGOING in skb_set_err_queue(). This is only safe to do
	 * in recvmsg, since skbs received on a local socket will never
	 * have a pkt_type of PACKET_OUTGOING.
	 */
	return skb->pkt_type == PACKET_OUTGOING;
}

		if (skb_is_err_queue(skb) && skb->len &&
		    (sk->sk_tsflags & SOF_TIMESTAMPING_OPT_STATS))
CVE-2023-22995 (C, published 2023-02-28T05:15Z)
Description: value: In the Linux kernel before 5.17, an error path in dwc3_qcom_acpi_register_core in drivers/usb/dwc3/dwc3-qcom.c lacks certain platform_device_put and kfree calls.
Severity: nan (CVSS v3 base score: 7.8)
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:
drivers/usb/dwc3/dwc3-qcom.c
Commit message: usb: dwc3: dwc3-qcom: Add missing platform_device_put() in dwc3_qcom_acpi_register_core

Add the missing platform_device_put() before return from
dwc3_qcom_acpi_register_core in the error handling case.

Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
Link: https://lore.kernel.org/r/20211231113641.31474-1-linmq006@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>


Vulnerable code:
	if (!child_res)

Fixed code:
	if (!child_res) {
		platform_device_put(qcom->dwc3);
	}
		goto out;
	kfree(child_res);
	return 0;
	platform_device_put(qcom->dwc3);
CVE-2023-51042 (C, published 2024-01-23T11:15Z)
Description: value: In the Linux kernel before 6.4.12, amdgpu_cs_wait_all_fences in drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c has a fence use-after-free.
Severity: nan (CVSS v3 base score: 7.8)
Weakness: CWE-416 \u2014 Use After Free
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.
Repository: https://github.com/torvalds/linux
Files changed:
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
Commit message: drm/amdgpu: Fix potential fence use-after-free v2

fence Decrements the reference count before exiting.
Avoid Race Vulnerabilities for fence use-after-free.

v2 (chk): actually fix the use after free and not just move it.

Signed-off-by: shanzhulig <shanzhulig@gmail.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


Vulnerable code:

		if (fence->error)
			return fence->error;

Fixed code:
		if (r > 0 && fence->error)
			r = fence->error;
CVE-2018-6927 (C, published 2018-02-12T19:29Z)
Description: value: The futex_requeue function in kernel/futex.c in the Linux kernel before 4.14.15 might allow attackers to cause a denial of service (integer overflow) or possibly have unspecified other impact by triggering a negative wake or requeue value.
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:
kernel/futex.c
Commit message: futex: Prevent overflow by strengthen input validation

UBSAN reports signed integer overflow in kernel/futex.c:

 UBSAN: Undefined behaviour in kernel/futex.c:2041:18
 signed integer overflow:
 0 - -2147483648 cannot be represented in type 'int'

Add a sanity check to catch negative values of nr_wake and nr_requeue.

Signed-off-by: Li Jinyue <lijinyue@huawei.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: peterz@infradead.org
Cc: dvhart@infradead.org
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/1513242294-31786-1-git-send-email-lijinyue@huawei.com



Vulnerable code:

Fixed code:
	if (nr_wake < 0 || nr_requeue < 0)
		return -EINVAL;
CVE-2022-27950 (C, published 2022-03-28T04:15Z)
Description: value: In drivers/hid/hid-elo.c in the Linux kernel before 5.16.11, a memory leak exists for a certain hid_parse error condition.
Severity: LOW (CVSS v3 base score: 5.5)
Weakness: CWE-401 \u2014 Missing Release of Memory after Effective Lifetime
The product does not sufficiently track and release allocated memory after it has been used, which slowly consumes remaining memory.
Repository: https://github.com/torvalds/linux
Files changed:
drivers/hid/hid-elo.c
Commit message: HID: elo: fix memory leak in elo_probe

When hid_parse() in elo_probe() fails, it forgets to call usb_put_dev to
decrease the refcount.

Fix this by adding usb_put_dev() in the error handling code of elo_probe().

Fixes: fbf42729d0e9 ("HID: elo: update the reference count of the usb device structure")
Reported-by: syzkaller <syzkaller@googlegroups.com>
Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>


Vulnerable code:

Fixed code:
	usb_put_dev(udev);
CVE-2022-3424 (C, published 2023-03-06T23:15Z)
Description: value: A use-after-free flaw was found in the Linux kernel’s SGI GRU driver in the way the first gru_file_unlocked_ioctl function is called by the user, where a fail pass occurs in the gru_check_chiplet_assignment function. This flaw allows a local user to crash or potentially escalate their privileges on the system.
Severity: nan (CVSS v3 base score: 7.8)
Weakness: CWE-416 \u2014 Use After Free
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.
Repository: https://github.com/torvalds/linux
Files changed:
drivers/misc/sgi-gru/grufault.c
drivers/misc/sgi-gru/grumain.c
drivers/misc/sgi-gru/grutables.h
Commit message: misc: sgi-gru: fix use-after-free error in gru_set_context_option, gru_fault and gru_handle_user_call_os

In some bad situation, the gts may be freed gru_check_chiplet_assignment.
The call chain can be gru_unload_context->gru_free_gru_context->gts_drop
and kfree finally. However, the caller didn't know if the gts is freed
or not and use it afterwards. This will trigger a Use after Free bug.

Fix it by introducing a return value to see if it's in error path or not.
Free the gts in caller if gru_check_chiplet_assignment check failed.

Fixes: 55484c45dbec ("gru: allow users to specify gru chiplet 2")
Signed-off-by: Zheng Wang <zyytlz.wz@163.com>
Acked-by: Dimitri Sivanich <sivanich@hpe.com>
Link: https://lore.kernel.org/r/20221110035033.19498-1-zyytlz.wz@163.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>


Vulnerable code:
	gru_check_context_placement(gts);
			gru_check_context_placement(gts);
void gru_check_context_placement(struct gru_thread_state *gts)
		return;
		gru_unload_context(gts, 1);
	gru_check_context_placement(gts);
extern void gru_check_context_placement(struct gru_thread_state *gts);

Fixed code:
again:
	if (gru_check_context_placement(gts)) {
		gru_unlock_gts(gts);
		gru_unload_context(gts, 1);
		goto again;
	}
			if (gru_check_context_placement(gts)) {
				gru_unlock_gts(gts);
				gru_unload_context(gts, 1);
				return ret;
			}
int gru_check_context_placement(struct gru_thread_state *gts)
	int ret = 0;
	/*
	 * If gru or gts->ts_tgid_owner isn't initialized properly, return
	 * success to indicate that the caller does not need to unload the
	 * gru context.The caller is responsible for their inspection and
	 * reinitialization if needed.
	 */
		return ret;
		ret = -EINVAL;

	return ret;
	if (gru_check_context_placement(gts)) {
		preempt_enable();
		mutex_unlock(&gts->ts_ctxlock);
		gru_unload_context(gts, 1);
		return VM_FAULT_NOPAGE;
	}
extern int gru_check_context_placement(struct gru_thread_state *gts);
CVE-2020-11669 (Other, published 2020-04-10T15:15Z)
Description: value: An issue was discovered in the Linux kernel before 5.2 on the powerpc platform. arch/powerpc/kernel/idle_book3s.S does not have save/restore functionality for PNV_POWERSAVE_AMR, PNV_POWERSAVE_UAMOR, and PNV_POWERSAVE_AMOR, aka CID-53a712bae5dd.
Severity: LOW (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:
arch/powerpc/kernel/idle_book3s.S
Commit message: powerpc/powernv/idle: Restore AMR/UAMOR/AMOR after idle

In order to implement KUAP (Kernel Userspace Access Protection) on
Power9 we will be using the AMR, and therefore indirectly the
UAMOR/AMOR.

So save/restore these regs in the idle code.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>


Vulnerable code:
/* Reuse an unused pt_regs slot for IAMR */
	/* IAMR was saved in pnv_powersave_common() */
	 * We don't need an isync here because the upcoming mtmsrd is
	 * execution synchronizing.

Fixed code:
/* Reuse some unused pt_regs slots for AMR/IAMR/UAMOR/UAMOR */
#define PNV_POWERSAVE_AMR	_TRAP
#define PNV_POWERSAVE_UAMOR	_DSISR
#define PNV_POWERSAVE_AMOR	RESULT
	mfspr	r4, SPRN_AMR
	mfspr	r6, SPRN_UAMOR
	std	r4, PNV_POWERSAVE_AMR(r1)
	std	r6, PNV_POWERSAVE_UAMOR(r1)
BEGIN_FTR_SECTION_NESTED(42)
	mfspr	r7, SPRN_AMOR
	std	r7, PNV_POWERSAVE_AMOR(r1)
END_FTR_SECTION_NESTED_IFSET(CPU_FTR_HVMODE, 42)
	/* These regs were saved in pnv_powersave_common() */
	ld	r4, PNV_POWERSAVE_AMR(r1)
	ld	r6, PNV_POWERSAVE_UAMOR(r1)
	mtspr	SPRN_AMR, r4
	mtspr	SPRN_UAMOR, r6
BEGIN_FTR_SECTION_NESTED(42)
	ld	r7, PNV_POWERSAVE_AMOR(r1)
	mtspr	SPRN_AMOR, r7
END_FTR_SECTION_NESTED_IFSET(CPU_FTR_HVMODE, 42)
	 * We don't need an isync here after restoring IAMR because the upcoming
	 * mtmsrd is execution synchronizing.
CVE-2021-32399 (C, published 2021-05-10T22:15Z)
Description: value: net/bluetooth/hci_request.c in the Linux kernel through 5.12.2 has a race condition for removal of the HCI controller.
Severity: MEDIUM (CVSS v3 base score: 7)
Weakness: CWE-362 \u2014 Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
The product contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently.
Repository: https://github.com/torvalds/linux
Files changed:
net/bluetooth/hci_request.c
Commit message: bluetooth: eliminate the potential race condition when removing the HCI controller

There is a possible race condition vulnerability between issuing a HCI
command and removing the cont.  Specifically, functions hci_req_sync()
and hci_dev_do_close() can race each other like below:

thread-A in hci_req_sync()      |   thread-B in hci_dev_do_close()
                                |   hci_req_sync_lock(hdev);
test_bit(HCI_UP, &hdev->flags); |
...                             |   test_and_clear_bit(HCI_UP, &hdev->flags)
hci_req_sync_lock(hdev);        |
                                |
In this commit we alter the sequence in function hci_req_sync(). Hence,
the thread-A cannot issue th.

Signed-off-by: Lin Ma <linma@zju.edu.cn>
Cc: Marcel Holtmann <marcel@holtmann.org>
Fixes: 7c6a329e4447 ("[Bluetooth] Fix regression from using default link policy")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>


Vulnerable code:
	if (!test_bit(HCI_UP, &hdev->flags))
		return -ENETDOWN;

	ret = __hci_req_sync(hdev, req, opt, timeout, hci_status);

Fixed code:
	/* check the state after obtaing the lock to protect the HCI_UP
	 * against any races from hci_dev_do_close when the controller
	 * gets removed.
	 */
	if (test_bit(HCI_UP, &hdev->flags))
		ret = __hci_req_sync(hdev, req, opt, timeout, hci_status);
	else
		ret = -ENETDOWN;
CVE-2022-36879 (C, published 2022-07-27T04:15Z)
Description: value: An issue was discovered in the Linux kernel through 5.18.14. xfrm_expand_policies in net/xfrm/xfrm_policy.c can cause a refcount to be dropped twice.
Severity: nan (CVSS v3 base score: 5.5)
Weakness: NVD-CWE-Other \u2014 Other
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.
Repository: https://github.com/torvalds/linux
Files changed:
net/xfrm/xfrm_policy.c
Commit message: xfrm: xfrm_policy: fix a possible double xfrm_pols_put() in xfrm_bundle_lookup()

xfrm_policy_lookup() will call xfrm_pol_hold_rcu() to get a refcount of
pols[0]. This refcount can be dropped in xfrm_expand_policies() when
xfrm_expand_policies() return error. pols[0]'s refcount is balanced in
here. But xfrm_bundle_lookup() will also call xfrm_pols_put() with
num_pols == 1 to drop this refcount when xfrm_expand_policies() return
error.

This patch also fix an illegal address access. pols[0] will save a error
point when xfrm_policy_lookup fails. This lead to xfrm_pols_put to resolve
an illegal address in xfrm_bundle_lookup's error path.

Fix these by setting num_pols = 0 in xfrm_expand_policies()'s error path.

Fixes: 80c802f3073e ("xfrm: cache bundles instead of policies for outgoing flows")
Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>


Vulnerable code:
	if (IS_ERR(pols[0]))

Fixed code:
	if (IS_ERR(pols[0])) {
		*num_pols = 0;
	}
				*num_pols = 0;