hitoshura25/cvefixes huggingface dataset:
CVE-2018-19824 (C, published 2018-12-03T17:29Z)
Description: value: In the Linux kernel through 4.19.6, a local user could exploit a use-after-free in the ALSA driver by supplying a malicious USB Sound device (with zero interfaces) that is mishandled in usb_audio_probe in sound/usb/card.c.
Severity: MEDIUM (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:
sound/usb/card.c
Commit message: ALSA: usb-audio: Fix UAF decrement if card has no live interfaces in card.c

If a USB sound card reports 0 interfaces, an error condition is triggered
and the function usb_audio_probe errors out. In the error path, there was a
use-after-free vulnerability where the memory object of the card was first
freed, followed by a decrement of the number of active chips. Moving the
decrement above the atomic_dec fixes the UAF.

[ The original problem was introduced in 3.1 kernel, while it was
  developed in a different form.  The Fixes tag below indicates the
  original commit but it doesn't mean that the patch is applicable
  cleanly. -- tiwai ]

Fixes: 362e4e49abe5 ("ALSA: usb-audio - clear chip->probing on error exit")
Reported-by: Hui Peng <benquike@gmail.com>
Reported-by: Mathias Payer <mathias.payer@nebelwelt.net>
Signed-off-by: Hui Peng <benquike@gmail.com>
Signed-off-by: Mathias Payer <mathias.payer@nebelwelt.net>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>


Vulnerable code:
		atomic_dec(&chip->active);

Fixed code:
		/* chip->active is inside the chip->card object,
		 * decrement before memory is possibly returned.
		 */
		atomic_dec(&chip->active);
CVE-2017-9605 (C, published 2017-06-13T19:29Z)
Description: value: The vmw_gb_surface_define_ioctl function (accessible via DRM_IOCTL_VMW_GB_SURFACE_CREATE) in drivers/gpu/drm/vmwgfx/vmwgfx_surface.c in the Linux kernel through 4.11.4 defines a backup_handle variable but does not give it an initial value. If one attempts to create a GB surface, with a previously allocated DMA buffer to be used as a backup buffer, the backup_handle variable does not get written to and is then later returned to user space, allowing local users to obtain sensitive information from uninitialized kernel memory via a crafted ioctl call.
Severity: MEDIUM (CVSS v3 base score: 5.5)
Weakness: CWE-200 \u2014 Exposure of Sensitive Information to an Unauthorized Actor
The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
Repository: https://github.com/torvalds/linux
Files changed:
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
Commit message: drm/vmwgfx: Make sure backup_handle is always valid

When vmw_gb_surface_define_ioctl() is called with an existing buffer,
we end up returning an uninitialized variable in the backup_handle.

The fix is to first initialize backup_handle to 0 just to be sure, and
second, when a user-provided buffer is found, we will use the
req->buffer_handle as the backup_handle.

Cc: <stable@vger.kernel.org>
Reported-by: Murray McAllister <murray.mcallister@insomniasec.com>
Signed-off-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>


Vulnerable code:
	uint32_t backup_handle;
		if (ret == 0 && res->backup->base.num_pages * PAGE_SIZE <
		    res->backup_size) {
			DRM_ERROR("Surface backup buffer is too small.\n");
			vmw_dmabuf_unreference(&res->backup);
			ret = -EINVAL;
			goto out_unlock;

Fixed code:
	uint32_t backup_handle = 0;
		if (ret == 0) {
			if (res->backup->base.num_pages * PAGE_SIZE <
			    res->backup_size) {
				DRM_ERROR("Surface backup buffer is too small.\n");
				vmw_dmabuf_unreference(&res->backup);
				ret = -EINVAL;
				goto out_unlock;
			} else {
				backup_handle = req->buffer_handle;
			}
CVE-2021-3772 (Unknown, published 2022-03-02T23:15Z)
Description: value: A flaw was found in the Linux SCTP stack. A blind attacker may be able to kill an existing SCTP association through invalid chunks if the attacker knows the IP-addresses and port numbers being used and the attacker can send packets with spoofed IP addresses.
Severity: MEDIUM (CVSS v3 base score: 6.5)
Weakness: CWE-354 \u2014 Improper Validation of Integrity Check Value
The product does not validate or incorrectly validates the integrity check values or "checksums" of a message. This may prevent it from detecting if the data has been modified or corrupted in transmission.
Repository: https://github.com/torvalds/linux
Files changed:
Commit message: Merge branch 'sctp-enhancements-for-the-verification-tag'

Xin Long says:

====================
sctp: enhancements for the verification tag

This patchset is to address CVE-2021-3772:

  A flaw was found in the Linux SCTP stack. A blind attacker may be able to
  kill an existing SCTP association through invalid chunks if the attacker
  knows the IP-addresses and port numbers being used and the attacker can
  send packets with spoofed IP addresses.

This is caused by the missing VTAG verification for the received chunks
and the incorrect vtag for the ABORT used to reply to these invalid
chunks.

This patchset is to go over all processing functions for the received
chunks and do:

1. Make sure sctp_vtag_verify() is called firstly to verify the vtag from
   the received chunk and discard this chunk if it fails. With some
   exceptions:

   a. sctp_sf_do_5_1B_init()/5_2_2_dupinit()/9_2_reshutack(), processing
      INIT chunk, as sctphdr vtag is always 0 in INIT chunk.

   b. sctp_sf_do_5_2_4_dupcook(), processing dupicate COOKIE_ECHO chunk,
      as the vtag verification will be done by sctp_tietags_compare() and
      then it takes right actions according to the return.

   c. sctp_sf_shut_8_4_5(), processing SHUTDOWN_ACK chunk for cookie_wait
      and cookie_echoed state, as RFC demand sending a SHUTDOWN_COMPLETE
      even if the vtag verification failed.

   d. sctp_sf_ootb(), called in many types of chunks for closed state or
      no asoc, as the same reason to c.

2. Always use the vtag from the received INIT chunk to make the response
   ABORT in sctp_ootb_pkt_new().

3. Fix the order for some checks and add some missing checks for the
   received chunk.

This patch series has been tested with SCTP TAHI testing to make sure no
regression caused on protocol conformance.
====================

Link: https://lore.kernel.org/r/cover.1634730082.git.lucien.xin@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>


Vulnerable code:

Fixed code:
CVE-2019-19071 (C, published 2019-11-18T06:15Z)
Description: value: A memory leak in the rsi_send_beacon() function in drivers/net/wireless/rsi/rsi_91x_mgmt.c in the Linux kernel through 5.3.11 allows attackers to cause a denial of service (memory consumption) by triggering rsi_prepare_beacon() failures, aka CID-d563131ef23c.
Severity: HIGH (CVSS v3 base score: 7.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/net/wireless/rsi/rsi_91x_mgmt.c
Commit message: rsi: release skb if rsi_prepare_beacon fails

In rsi_send_beacon, if rsi_prepare_beacon fails the allocated skb should
be released.

Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>


Vulnerable code:

Fixed code:
		dev_kfree_skb(skb);
CVE-2019-19067 (C, published 2019-11-18T06:15Z)
Description: value: Four memory leaks in the acp_hw_init() function in drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c in the Linux kernel before 5.3.8 allow attackers to cause a denial of service (memory consumption) by triggering mfd_add_hotplug_devices() or pm_genpd_add_device() failures, aka CID-57be09c6e874. NOTE: third parties dispute the relevance of this because the attacker must already have privileges for module loading
Severity: MEDIUM (CVSS v3 base score: 4.4)
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/gpu/drm/amd/amdgpu/amdgpu_acp.c
Commit message: drm/amdgpu: fix multiple memory leaks in acp_hw_init

In acp_hw_init there are some allocations that needs to be released in
case of failure:

1- adev->acp.acp_genpd should be released if any allocation attemp for
adev->acp.acp_cell, adev->acp.acp_res or i2s_pdata fails.
2- all of those allocations should be released if
mfd_add_hotplug_devices or pm_genpd_add_device fail.
3- Release is needed in case of time out values expire.

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


Vulnerable code:
	struct i2s_platform_data *i2s_pdata;
	if (adev->acp.acp_cell == NULL)
		return -ENOMEM;
		kfree(adev->acp.acp_cell);
		return -ENOMEM;
		kfree(adev->acp.acp_res);
		kfree(adev->acp.acp_cell);
		return -ENOMEM;
		return r;
			return r;
			return -ETIMEDOUT;
			return -ETIMEDOUT;

Fixed code:
	struct i2s_platform_data *i2s_pdata = NULL;
	if (adev->acp.acp_cell == NULL) {
		r = -ENOMEM;
		goto failure;
	}
		r = -ENOMEM;
		goto failure;
		r = -ENOMEM;
		goto failure;
		goto failure;
			goto failure;
			r = -ETIMEDOUT;
			goto failure;
			r = -ETIMEDOUT;
			goto failure;

failure:
	kfree(i2s_pdata);
	kfree(adev->acp.acp_res);
	kfree(adev->acp.acp_cell);
	kfree(adev->acp.acp_genpd);
	return r;
CVE-2021-38205 (C, published 2021-08-08T20:15Z)
Description: value: drivers/net/ethernet/xilinx/xilinx_emaclite.c in the Linux kernel before 5.13.3 makes it easier for attackers to defeat an ASLR protection mechanism because it prints a kernel pointer (i.e., the real IOMEM pointer).
Severity: LOW (CVSS v3 base score: 3.3)
Weakness: CWE-824 \u2014 Access of Uninitialized Pointer
The product accesses or uses a pointer that has not been initialized.
Repository: https://github.com/torvalds/linux
Files changed:
drivers/net/ethernet/xilinx/xilinx_emaclite.c
Commit message: net: xilinx_emaclite: Do not print real IOMEM pointer

Printing kernel pointers is discouraged because they might leak kernel
memory layout.  This fixes smatch warning:

drivers/net/ethernet/xilinx/xilinx_emaclite.c:1191 xemaclite_of_probe() warn:
 argument 4 to %08lX specifier is cast from pointer

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>


Vulnerable code:
		 "Xilinx EmacLite at 0x%08lX mapped to 0x%08lX, irq=%d\n",
		 (unsigned long __force)ndev->mem_start,
		 (unsigned long __force)lp->base_addr, ndev->irq);

Fixed code:
		 "Xilinx EmacLite at 0x%08lX mapped to 0x%p, irq=%d\n",
		 (unsigned long __force)ndev->mem_start, lp->base_addr, ndev->irq);
CVE-2021-3764 (C, published 2022-08-23T16:15Z)
Description: value: A memory leak flaw was found in the Linux kernel's ccp_run_aes_gcm_cmd() function that allows an attacker to cause a denial of service. The vulnerability is similar to the older CVE-2019-18808. The highest threat from this vulnerability is to system availability.
Severity: nan (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/crypto/ccp/ccp-ops.c
Commit message: crypto: ccp - fix resource leaks in ccp_run_aes_gcm_cmd()

There are three bugs in this code:

1) If we ccp_init_data() fails for &src then we need to free aad.
   Use goto e_aad instead of goto e_ctx.
2) The label to free the &final_wa was named incorrectly as "e_tag" but
   it should have been "e_final_wa".  One error path leaked &final_wa.
3) The &tag was leaked on one error path.  In that case, I added a free
   before the goto because the resource was local to that block.

Fixes: 36cf515b9bbe ("crypto: ccp - Enable support for AES GCM on v5 CCPs")
Reported-by: "minihanshen(沈明航)" <minihanshen@tencent.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: John Allen <john.allen@amd.com>
Tested-by: John Allen <john.allen@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>


Vulnerable code:
			goto e_ctx;
		goto e_dst;
			goto e_tag;
		if (ret)
			goto e_tag;
e_tag:

Fixed code:
			goto e_aad;
		goto e_final_wa;
			goto e_final_wa;
		if (ret) {
			ccp_dm_free(&tag);
			goto e_final_wa;
		}
e_final_wa:
CVE-2022-42895 (C, published 2022-11-23T15:15Z)
Description: value: There is an infoleak vulnerability in the Linux kernel's net/bluetooth/l2cap_core.c's l2cap_parse_conf_req function which can be used to leak kernel pointers remotely.
We recommend upgrading past commit  https://github.com/torvalds/linux/commit/b1a2cd50c0357f243b7435a732b4e62ba3157a2e https://www.google.com/url 


Severity: nan (CVSS v3 base score: 6.5)
Weakness: CWE-824 \u2014 Access of Uninitialized Pointer
The product accesses or uses a pointer that has not been initialized.
Repository: https://github.com/torvalds/linux
Files changed:
net/bluetooth/l2cap_core.c
Commit message: Bluetooth: L2CAP: Fix attempting to access uninitialized memory

On l2cap_parse_conf_req the variable efs is only initialized if
remote_efs has been set.

CVE: CVE-2022-42895
CC: stable@vger.kernel.org
Reported-by: Tamás Koczka <poprdi@google.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Reviewed-by: Tedd Ho-Jeong An <tedd.an@intel.com>


Vulnerable code:
			if (test_bit(FLAG_EFS_ENABLE, &chan->flags)) {

Fixed code:
			if (remote_efs &&
			    test_bit(FLAG_EFS_ENABLE, &chan->flags)) {
CVE-2022-26490 (C, published 2022-03-06T04:15Z)
Description: value: st21nfca_connectivity_event_received in drivers/nfc/st21nfca/se.c in the Linux kernel through 5.16.12 has EVT_TRANSACTION buffer overflows because of untrusted length parameters.
Severity: MEDIUM (CVSS v3 base score: 7.8)
Weakness: CWE-120 \u2014 Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
The product copies an input buffer to an output buffer without verifying that the size of the input buffer is less than the size of the output buffer, leading to a buffer overflow.
Repository: https://github.com/torvalds/linux
Files changed:
drivers/nfc/st21nfca/se.c
Commit message: nfc: st21nfca: Fix potential buffer overflows in EVT_TRANSACTION

It appears that there are some buffer overflows in EVT_TRANSACTION.
This happens because the length parameters that are passed to memcpy
come directly from skb->data and are not guarded in any way.

Signed-off-by: Jordy Zomer <jordy@pwning.systems>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>


Vulnerable code:

Fixed code:

		/* Checking if the length of the AID is valid */
		if (transaction->aid_len > sizeof(transaction->aid))
			return -EINVAL;


		/* Total size is allocated (skb->len - 2) minus fixed array members */
		if (transaction->params_len > ((skb->len - 2) - sizeof(struct nfc_evt_transaction)))
			return -EINVAL;
CVE-2023-6915 (C, published 2024-01-15T10:15Z)
Description: value: A Null pointer dereference problem was found in ida_free in lib/idr.c in the Linux Kernel. This issue may allow an attacker using this library to cause a denial of service problem due to a missing check at a function return.
Severity: nan (CVSS v3 base score: 5.5)
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:
lib/idr.c
lib/test_ida.c
Commit message: ida: Fix crash in ida_free when the bitmap is empty

The IDA usually detects double-frees, but that detection failed to
consider the case when there are no nearby IDs allocated and so we have a
NULL bitmap rather than simply having a clear bit.  Add some tests to the
test-suite to be sure we don't inadvertently reintroduce this problem.
Unfortunately they're quite noisy so include a message to disregard
the warnings.

Reported-by: Zhenghan Wang <wzhmmmmm@gmail.com>
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


Vulnerable code:
		if (!test_bit(bit, bitmap->bitmap))

Fixed code:
		if (!bitmap || !test_bit(bit, bitmap->bitmap))
/*
 * Check various situations where we attempt to free an ID we don't own.
 */
static void ida_check_bad_free(struct ida *ida)
{
	unsigned long i;

	printk("vvv Ignore \"not allocated\" warnings\n");
	/* IDA is empty; all of these will fail */
	ida_free(ida, 0);
	for (i = 0; i < 31; i++)
		ida_free(ida, 1 << i);

	/* IDA contains a single value entry */
	IDA_BUG_ON(ida, ida_alloc_min(ida, 3, GFP_KERNEL) != 3);
	ida_free(ida, 0);
	for (i = 0; i < 31; i++)
		ida_free(ida, 1 << i);

	/* IDA contains a single bitmap */
	IDA_BUG_ON(ida, ida_alloc_min(ida, 1023, GFP_KERNEL) != 1023);
	ida_free(ida, 0);
	for (i = 0; i < 31; i++)
		ida_free(ida, 1 << i);

	/* IDA contains a tree */
	IDA_BUG_ON(ida, ida_alloc_min(ida, (1 << 20) - 1, GFP_KERNEL) != (1 << 20) - 1);
	ida_free(ida, 0);
	for (i = 0; i < 31; i++)
		ida_free(ida, 1 << i);
	printk("^^^ \"not allocated\" warnings over\n");

	ida_free(ida, 3);
	ida_free(ida, 1023);
	ida_free(ida, (1 << 20) - 1);

	IDA_BUG_ON(ida, !ida_is_empty(ida));
}

	ida_check_bad_free(&ida);
CVE-2023-23005 (C, published 2023-03-01T20:15Z)
Description: value: In the Linux kernel before 6.2, mm/memory-tiers.c misinterprets the alloc_memory_type return value (expects it to be NULL in the error case, whereas it is actually an error pointer). NOTE: this is disputed by third parties because there are no realistic cases in which a user can cause the alloc_memory_type error case to be reached.
Severity: nan (CVSS v3 base score: 5.5)
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:
mm/memory-tiers.c
Commit message: mm/demotion: fix NULL vs IS_ERR checking in memory_tier_init

alloc_memory_type() returns error pointers on error instead of NULL.  Use
IS_ERR() to check the return value to fix this.

Link: https://lkml.kernel.org/r/20221110030751.1627266-1-linmq006@gmail.com
Fixes: 7b88bda3761b ("mm/demotion/dax/kmem: set node's abstract distance to MEMTIER_DEFAULT_DAX_ADISTANCE")
Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
Reviewed-by: "Huang, Ying" <ying.huang@intel.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Wei Xu <weixugc@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>


Vulnerable code:
	if (!default_dram_type)

Fixed code:
	if (IS_ERR(default_dram_type))
CVE-2019-16994 (C, published 2019-09-30T13:15Z)
Description: value: In the Linux kernel before 5.0, a memory leak exists in sit_init_net() in net/ipv6/sit.c when register_netdev() fails to register sitn->fb_tunnel_dev, which may cause denial of service, aka CID-07f12b26e21a.
Severity: MEDIUM (CVSS v3 base score: 4.7)
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:
net/ipv6/sit.c
Commit message: net: sit: fix memory leak in sit_init_net()

If register_netdev() is failed to register sitn->fb_tunnel_dev,
it will go to err_reg_dev and forget to free netdev(sitn->fb_tunnel_dev).

BUG: memory leak
unreferenced object 0xffff888378daad00 (size 512):
  comm "syz-executor.1", pid 4006, jiffies 4295121142 (age 16.115s)
  hex dump (first 32 bytes):
    00 e6 ed c0 83 88 ff ff 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
backtrace:
    [<00000000d6dcb63e>] kvmalloc include/linux/mm.h:577 [inline]
    [<00000000d6dcb63e>] kvzalloc include/linux/mm.h:585 [inline]
    [<00000000d6dcb63e>] netif_alloc_netdev_queues net/core/dev.c:8380 [inline]
    [<00000000d6dcb63e>] alloc_netdev_mqs+0x600/0xcc0 net/core/dev.c:8970
    [<00000000867e172f>] sit_init_net+0x295/0xa40 net/ipv6/sit.c:1848
    [<00000000871019fa>] ops_init+0xad/0x3e0 net/core/net_namespace.c:129
    [<00000000319507f6>] setup_net+0x2ba/0x690 net/core/net_namespace.c:314
    [<0000000087db4f96>] copy_net_ns+0x1dc/0x330 net/core/net_namespace.c:437
    [<0000000057efc651>] create_new_namespaces+0x382/0x730 kernel/nsproxy.c:107
    [<00000000676f83de>] copy_namespaces+0x2ed/0x3d0 kernel/nsproxy.c:165
    [<0000000030b74bac>] copy_process.part.27+0x231e/0x6db0 kernel/fork.c:1919
    [<00000000fff78746>] copy_process kernel/fork.c:1713 [inline]
    [<00000000fff78746>] _do_fork+0x1bc/0xe90 kernel/fork.c:2224
    [<000000001c2e0d1c>] do_syscall_64+0xc8/0x580 arch/x86/entry/common.c:290
    [<00000000ec48bd44>] entry_SYSCALL_64_after_hwframe+0x49/0xbe
    [<0000000039acff8a>] 0xffffffffffffffff

Signed-off-by: Mao Wenan <maowenan@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>


Vulnerable code:

Fixed code:
	free_netdev(sitn->fb_tunnel_dev);
CVE-2020-36766 (C, published 2023-09-18T09:15Z)
Description: value: An issue was discovered in the Linux kernel before 5.8.6. drivers/media/cec/core/cec-api.c leaks one byte of kernel memory on specific hardware to unprivileged users, because of directly assigning log_addrs with a hole in the struct.
Severity: nan (CVSS v3 base score: 3.3)
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/media/cec/core/cec-api.c
Commit message: cec-api: prevent leaking memory through hole in structure

Fix this smatch warning:

drivers/media/cec/core/cec-api.c:156 cec_adap_g_log_addrs() warn: check that 'log_addrs' doesn't leak information (struct has a hole after
'features')

Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>


Vulnerable code:
	log_addrs = adap->log_addrs;

Fixed code:
	/*
	 * We use memcpy here instead of assignment since there is a
	 * hole at the end of struct cec_log_addrs that an assignment
	 * might ignore. So when we do copy_to_user() we could leak
	 * one byte of memory.
	 */
	memcpy(&log_addrs, &adap->log_addrs, sizeof(log_addrs));