rainbutterfly/cve_corpus huggingface dataset:
CVE-2021-47029 mt76: connac: fix kernel warning adding monitor interface
In the Linux kernel, the following vulnerability has been resolved:

mt76: connac: fix kernel warning adding monitor interface

Fix the following kernel warning adding a monitor interface in
mt76_connac_mcu_uni_add_dev routine.

[  507.984882] ------------[ cut here ]------------
[  507.989515] WARNING: CPU: 1 PID: 3017 at mt76_connac_mcu_uni_add_dev+0x178/0x190 [mt76_connac_lib]
[  508.059379] CPU: 1 PID: 3017 Comm: ifconfig Not tainted 5.4.98 #0
[  508.065461] Hardware name: MT7622_MT7531 RFB (DT)
[  508.070156] pstate: 80000005 (Nzcv daif -PAN -UAO)
[  508.074939] pc : mt76_connac_mcu_uni_add_dev+0x178/0x190 [mt76_connac_lib]
[  508.081806] lr : mt7921_eeprom_init+0x1288/0x1cb8 [mt7921e]
[  508.087367] sp : ffffffc013a33930
[  508.090671] x29: ffffffc013a33930 x28: ffffff801e628ac0
[  508.095973] x27: ffffff801c7f1200 x26: ffffff801c7eb008
[  508.101275] x25: ffffff801c7eaef0 x24: ffffff801d025610
[  508.106577] x23: ffffff801d022990 x22: ffffff801d024de8
[  508.111879] x21: ffffff801d0226a0 x20: ffffff801c7eaee8
[  508.117181] x19: ffffff801d0226a0 x18: 000000005d00b000
[  508.122482] x17: 00000000ffffffff x16: 0000000000000000
[  508.127785] x15: 0000000000000080 x14: ffffff801d704000
[  508.133087] x13: 0000000000000040 x12: 0000000000000002
[  508.138389] x11: 000000000000000c x10: 0000000000000000
[  508.143691] x9 : 0000000000000020 x8 : 0000000000000001
[  508.148992] x7 : 0000000000000000 x6 : 0000000000000000
[  508.154294] x5 : ffffff801c7eaee8 x4 : 0000000000000006
[  508.159596] x3 : 0000000000000001 x2 : 0000000000000000
[  508.164898] x1 : ffffff801c7eac08 x0 : ffffff801d0226a0
[  508.170200] Call trace:
[  508.172640]  mt76_connac_mcu_uni_add_dev+0x178/0x190 [mt76_connac_lib]
[  508.179159]  mt7921_eeprom_init+0x1288/0x1cb8 [mt7921e]
[  508.184394]  drv_add_interface+0x34/0x88 [mac80211]
[  508.189271]  ieee80211_add_virtual_monitor+0xe0/0xb48 [mac80211]
[  508.195277]  ieee80211_do_open+0x86c/0x918 [mac80211]
[  508.200328]  ieee80211_do_open+0x900/0x918 [mac80211]
[  508.205372]  __dev_open+0xcc/0x150
[  508.208763]  __dev_change_flags+0x134/0x198
[  508.212937]  dev_change_flags+0x20/0x60
[  508.216764]  devinet_ioctl+0x3e8/0x748
[  508.220503]  inet_ioctl+0x1e4/0x350
[  508.223983]  sock_do_ioctl+0x48/0x2a0
[  508.227635]  sock_ioctl+0x310/0x4f8
[  508.231116]  do_vfs_ioctl+0xa4/0xac0
[  508.234681]  ksys_ioctl+0x44/0x90
[  508.237985]  __arm64_sys_ioctl+0x1c/0x48
[  508.241901]  el0_svc_common.constprop.1+0x7c/0x100
[  508.246681]  el0_svc_handler+0x18/0x20
[  508.250421]  el0_svc+0x8/0x1c8
[  508.253465] ---[ end trace c7b90fee13d72c39 ]---
[  508.261278] ------------[ cut here ]------------
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-02-28T08:13:39.603Z
CVE-2021-47030 mt76: mt7615: fix memory leak in mt7615_coredump_work
In the Linux kernel, the following vulnerability has been resolved:

mt76: mt7615: fix memory leak in mt7615_coredump_work

Similar to the issue fixed in mt7921_coredump_work, fix a possible memory
leak in mt7615_coredump_work routine.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-02-28T08:13:40.211Z
CVE-2021-47031 mt76: mt7921: fix memory leak in mt7921_coredump_work
In the Linux kernel, the following vulnerability has been resolved:

mt76: mt7921: fix memory leak in mt7921_coredump_work

Fix possible memory leak in mt7921_coredump_work.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-02-28T08:13:40.822Z
CVE-2021-47032 mt76: mt7915: fix tx skb dma unmap
In the Linux kernel, the following vulnerability has been resolved:

mt76: mt7915: fix tx skb dma unmap

The first pointer in the txp needs to be unmapped as well, otherwise it will
leak DMA mapping entries
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-02-28T08:13:41.452Z
CVE-2021-47033 mt76: mt7615: fix tx skb dma unmap
In the Linux kernel, the following vulnerability has been resolved:

mt76: mt7615: fix tx skb dma unmap

The first pointer in the txp needs to be unmapped as well, otherwise it will
leak DMA mapping entries
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-02-28T08:13:42.072Z
CVE-2021-47035 iommu/vt-d: Remove WO permissions on second-level paging entries
In the Linux kernel, the following vulnerability has been resolved:

iommu/vt-d: Remove WO permissions on second-level paging entries

When the first level page table is used for IOVA translation, it only
supports Read-Only and Read-Write permissions. The Write-Only permission
is not supported as the PRESENT bit (implying Read permission) should
always set. When using second level, we still give separate permissions
that allows WriteOnly which seems inconsistent and awkward. We want to
have consistent behavior. After moving to 1st level, we don't want things
to work sometimes, and break if we use 2nd level for the same mappings.
Hence remove this configuration.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-02-28T08:13:43.404Z
CVE-2021-47036 udp: skip L4 aggregation for UDP tunnel packets
In the Linux kernel, the following vulnerability has been resolved:

udp: skip L4 aggregation for UDP tunnel packets

If NETIF_F_GRO_FRAGLIST or NETIF_F_GRO_UDP_FWD are enabled, and there
are UDP tunnels available in the system, udp_gro_receive() could end-up
doing L4 aggregation (either SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST) at
the outer UDP tunnel level for packets effectively carrying and UDP
tunnel header.

That could cause inner protocol corruption. If e.g. the relevant
packets carry a vxlan header, different vxlan ids will be ignored/
aggregated to the same GSO packet. Inner headers will be ignored, too,
so that e.g. TCP over vxlan push packets will be held in the GRO
engine till the next flush, etc.

Just skip the SKB_GSO_UDP_L4 and SKB_GSO_FRAGLIST code path if the
current packet could land in a UDP tunnel, and let udp_gro_receive()
do GRO via udp_sk(sk)->gro_receive.

The check implemented in this patch is broader than what is strictly
needed, as the existing UDP tunnel could be e.g. configured on top of
a different device: we could end-up skipping GRO at-all for some packets.

Anyhow, that is a very thin corner case and covering it will add quite
a bit of complexity.

v1 -> v2:
 - hopefully clarify the commit message
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-02-28T08:13:44.034Z
CVE-2021-47037 ASoC: q6afe-clocks: fix reprobing of the driver
In the Linux kernel, the following vulnerability has been resolved:

ASoC: q6afe-clocks: fix reprobing of the driver

Q6afe-clocks driver can get reprobed. For example if the APR services
are restarted after the firmware crash. However currently Q6afe-clocks
driver will oops because hw.init will get cleared during first _probe
call. Rewrite the driver to fill the clock data at runtime rather than
using big static array of clocks.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-02-28T08:13:44.683Z
CVE-2021-47039 ataflop: potential out of bounds in do_format()
In the Linux kernel, the following vulnerability has been resolved:

ataflop: potential out of bounds in do_format()

The function uses "type" as an array index:

	q = unit[drive].disk[type]->queue;

Unfortunately the bounds check on "type" isn't done until later in the
function.  Fix this by moving the bounds check to the start.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-02-28T08:13:45.937Z
CVE-2021-47040 io_uring: fix overflows checks in provide buffers
In the Linux kernel, the following vulnerability has been resolved:

io_uring: fix overflows checks in provide buffers

Colin reported before possible overflow and sign extension problems in
io_provide_buffers_prep(). As Linus pointed out previous attempt did nothing
useful, see d81269fecb8ce ("io_uring: fix provide_buffers sign extension").

Do that with help of check_<op>_overflow helpers. And fix struct
io_provide_buf::len type, as it doesn't make much sense to keep it
signed.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-02-28T08:13:46.557Z
CVE-2021-47042 drm/amd/display: Free local data after use
In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Free local data after use

Fixes the following memory leak in dc_link_construct():

unreferenced object 0xffffa03e81471400 (size 1024):
comm "amd_module_load", pid 2486, jiffies 4294946026 (age 10.544s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 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:
[<000000000bdf5c4a>] kmem_cache_alloc_trace+0x30a/0x4a0
[<00000000e7c59f0e>] link_create+0xce/0xac0 [amdgpu]
[<000000002fb6c072>] dc_create+0x370/0x720 [amdgpu]
[<000000000094d1f3>] amdgpu_dm_init+0x18e/0x17a0 [amdgpu]
[<00000000bec048fd>] dm_hw_init+0x12/0x20 [amdgpu]
[<00000000a2bb7cf6>] amdgpu_device_init+0x1463/0x1e60 [amdgpu]
[<0000000032d3bb13>] amdgpu_driver_load_kms+0x5b/0x330 [amdgpu]
[<00000000a27834f9>] amdgpu_pci_probe+0x192/0x280 [amdgpu]
[<00000000fec7d291>] local_pci_probe+0x47/0xa0
[<0000000055dbbfa7>] pci_device_probe+0xe3/0x180
[<00000000815da970>] really_probe+0x1c4/0x4e0
[<00000000b4b6974b>] driver_probe_device+0x62/0x150
[<000000000f9ecc61>] device_driver_attach+0x58/0x60
[<000000000f65c843>] __driver_attach+0xd6/0x150
[<000000002f5e3683>] bus_for_each_dev+0x6a/0xc0
[<00000000a1cfc897>] driver_attach+0x1e/0x20
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-02-28T08:13:47.809Z
CVE-2021-47043 media: venus: core: Fix some resource leaks in the error path of 'venus_probe()'
In the Linux kernel, the following vulnerability has been resolved:

media: venus: core: Fix some resource leaks in the error path of 'venus_probe()'

If an error occurs after a successful 'of_icc_get()' call, it must be
undone.

Use 'devm_of_icc_get()' instead of 'of_icc_get()' to avoid the leak.
Update the remove function accordingly and axe the now unneeded
'icc_put()' calls.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-02-28T08:13:48.440Z
CVE-2021-47044 sched/fair: Fix shift-out-of-bounds in load_balance()
In the Linux kernel, the following vulnerability has been resolved:

sched/fair: Fix shift-out-of-bounds in load_balance()

Syzbot reported a handful of occurrences where an sd->nr_balance_failed can
grow to much higher values than one would expect.

A successful load_balance() resets it to 0; a failed one increments
it. Once it gets to sd->cache_nice_tries + 3, this *should* trigger an
active balance, which will either set it to sd->cache_nice_tries+1 or reset
it to 0. However, in case the to-be-active-balanced task is not allowed to
run on env->dst_cpu, then the increment is done without any further
modification.

This could then be repeated ad nauseam, and would explain the absurdly high
values reported by syzbot (86, 149). VincentG noted there is value in
letting sd->cache_nice_tries grow, so the shift itself should be
fixed. That means preventing:

  """
  If the value of the right operand is negative or is greater than or equal
  to the width of the promoted left operand, the behavior is undefined.
  """

Thus we need to cap the shift exponent to
  BITS_PER_TYPE(typeof(lefthand)) - 1.

I had a look around for other similar cases via coccinelle:

  @expr@
  position pos;
  expression E1;
  expression E2;
  @@
  (
  E1 >> E2@pos
  |
  E1 >> E2@pos
  )

  @cst depends on expr@
  position pos;
  expression expr.E1;
  constant cst;
  @@
  (
  E1 >> cst@pos
  |
  E1 << cst@pos
  )

  @script:python depends on !cst@
  pos << expr.pos;
  exp << expr.E2;
  @@
  # Dirty hack to ignore constexpr
  if exp.upper() != exp:
     coccilib.report.print_report(pos[0], "Possible UB shift here")

The only other match in kernel/sched is rq_clock_thermal() which employs
sched_thermal_decay_shift, and that exponent is already capped to 10, so
that one is fine.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-02-28T08:13:49.087Z
CVE-2021-47045 scsi: lpfc: Fix null pointer dereference in lpfc_prep_els_iocb()
In the Linux kernel, the following vulnerability has been resolved:

scsi: lpfc: Fix null pointer dereference in lpfc_prep_els_iocb()

It is possible to call lpfc_issue_els_plogi() passing a did for which no
matching ndlp is found. A call is then made to lpfc_prep_els_iocb() with a
null pointer to a lpfc_nodelist structure resulting in a null pointer
dereference.

Fix by returning an error status if no valid ndlp is found. Fix up comments
regarding ndlp reference counting.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-02-28T08:13:49.708Z
CVE-2021-47046 drm/amd/display: Fix off by one in hdmi_14_process_transaction()
In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix off by one in hdmi_14_process_transaction()

The hdcp_i2c_offsets[] array did not have an entry for
HDCP_MESSAGE_ID_WRITE_CONTENT_STREAM_TYPE so it led to an off by one
read overflow.  I added an entry and copied the 0x0 value for the offset
from similar code in drivers/gpu/drm/amd/display/modules/hdcp/hdcp_ddc.c.

I also declared several of these arrays as having HDCP_MESSAGE_ID_MAX
entries.  This doesn't change the code, but it's just a belt and
suspenders approach to try future proof the code.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-02-28T08:13:50.320Z
CVE-2021-47047 spi: spi-zynqmp-gqspi: return -ENOMEM if dma_map_single fails
In the Linux kernel, the following vulnerability has been resolved:

spi: spi-zynqmp-gqspi: return -ENOMEM if dma_map_single fails

The spi controller supports 44-bit address space on AXI in DMA mode,
so set dma_addr_t width to 44-bit to avoid using a swiotlb mapping.
In addition, if dma_map_single fails, it should return immediately
instead of continuing doing the DMA operation which bases on invalid
address.

This fixes the following crash which occurs in reading a big block
from flash:

[  123.633577] zynqmp-qspi ff0f0000.spi: swiotlb buffer is full (sz: 4194304 bytes), total 32768 (slots), used 0 (slots)
[  123.644230] zynqmp-qspi ff0f0000.spi: ERR:rxdma:memory not mapped
[  123.784625] Unable to handle kernel paging request at virtual address 00000000003fffc0
[  123.792536] Mem abort info:
[  123.795313]   ESR = 0x96000145
[  123.798351]   EC = 0x25: DABT (current EL), IL = 32 bits
[  123.803655]   SET = 0, FnV = 0
[  123.806693]   EA = 0, S1PTW = 0
[  123.809818] Data abort info:
[  123.812683]   ISV = 0, ISS = 0x00000145
[  123.816503]   CM = 1, WnR = 1
[  123.819455] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000805047000
[  123.825887] [00000000003fffc0] pgd=0000000803b45003, p4d=0000000803b45003, pud=0000000000000000
[  123.834586] Internal error: Oops: 96000145 [#1] PREEMPT SMP
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-02-28T08:13:50.931Z
CVE-2021-47048 spi: spi-zynqmp-gqspi: fix use-after-free in zynqmp_qspi_exec_op
In the Linux kernel, the following vulnerability has been resolved:

spi: spi-zynqmp-gqspi: fix use-after-free in zynqmp_qspi_exec_op

When handling op->addr, it is using the buffer "tmpbuf" which has been
freed. This will trigger a use-after-free KASAN warning. Let's use
temporary variables to store op->addr.val and op->cmd.opcode to fix
this issue.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-02-28T08:13:51.551Z
CVE-2021-47049 Drivers: hv: vmbus: Use after free in __vmbus_open()
In the Linux kernel, the following vulnerability has been resolved:

Drivers: hv: vmbus: Use after free in __vmbus_open()

The "open_info" variable is added to the &vmbus_connection.chn_msg_list,
but the error handling frees "open_info" without removing it from the
list.  This will result in a use after free.  First remove it from the
list, and then free it.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-02-28T08:13:52.168Z
CVE-2021-47050 memory: renesas-rpc-if: fix possible NULL pointer dereference of resource
In the Linux kernel, the following vulnerability has been resolved:

memory: renesas-rpc-if: fix possible NULL pointer dereference of resource

The platform_get_resource_byname() can return NULL which would be
immediately dereferenced by resource_size().  Instead dereference it
after validating the resource.

Addresses-Coverity: Dereference null return value
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-02-28T08:13:52.801Z
CVE-2021-47051 spi: fsl-lpspi: Fix PM reference leak in lpspi_prepare_xfer_hardware()
In the Linux kernel, the following vulnerability has been resolved:

spi: fsl-lpspi: Fix PM reference leak in lpspi_prepare_xfer_hardware()

pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
Fix it by replacing it with pm_runtime_resume_and_get to keep usage
counter balanced.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-02-28T08:13:53.461Z
CVE-2021-47052 crypto: sa2ul - Fix memory leak of rxd
In the Linux kernel, the following vulnerability has been resolved:

crypto: sa2ul - Fix memory leak of rxd

There are two error return paths that are not freeing rxd and causing
memory leaks.  Fix these.

Addresses-Coverity: ("Resource leak")
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-02-28T08:13:54.083Z
CVE-2021-47053 crypto: sun8i-ss - Fix memory leak of pad
In the Linux kernel, the following vulnerability has been resolved:

crypto: sun8i-ss - Fix memory leak of pad

It appears there are several failure return paths that don't seem
to be free'ing pad. Fix these.

Addresses-Coverity: ("Resource leak")
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-02-28T08:13:54.711Z
CVE-2021-47054 bus: qcom: Put child node before return
In the Linux kernel, the following vulnerability has been resolved:

bus: qcom: Put child node before return

Put child node before return to fix potential reference count leak.
Generally, the reference count of child is incremented and decremented
automatically in the macro for_each_available_child_of_node() and should
be decremented manually if the loop is broken in loop body.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-02-29T22:37:29.140Z
CVE-2021-47055 mtd: require write permissions for locking and badblock ioctls
In the Linux kernel, the following vulnerability has been resolved:

mtd: require write permissions for locking and badblock ioctls

MEMLOCK, MEMUNLOCK and OTPLOCK modify protection bits. Thus require
write permission. Depending on the hardware MEMLOCK might even be
write-once, e.g. for SPI-NOR flashes with their WP# tied to GND. OTPLOCK
is always write-once.

MEMSETBADBLOCK modifies the bad block table.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-02-29T22:37:30.071Z
CVE-2021-47056 crypto: qat - ADF_STATUS_PF_RUNNING should be set after adf_dev_init
In the Linux kernel, the following vulnerability has been resolved:

crypto: qat - ADF_STATUS_PF_RUNNING should be set after adf_dev_init

ADF_STATUS_PF_RUNNING is (only) used and checked by adf_vf2pf_shutdown()
before calling adf_iov_putmsg()->mutex_lock(vf2pf_lock), however the
vf2pf_lock is initialized in adf_dev_init(), which can fail and when it
fail, the vf2pf_lock is either not initialized or destroyed, a subsequent
use of vf2pf_lock will cause issue.
To fix this issue, only set this flag if adf_dev_init() returns 0.

[    7.178404] BUG: KASAN: user-memory-access in __mutex_lock.isra.0+0x1ac/0x7c0
[    7.180345] Call Trace:
[    7.182576]  mutex_lock+0xc9/0xd0
[    7.183257]  adf_iov_putmsg+0x118/0x1a0 [intel_qat]
[    7.183541]  adf_vf2pf_shutdown+0x4d/0x7b [intel_qat]
[    7.183834]  adf_dev_shutdown+0x172/0x2b0 [intel_qat]
[    7.184127]  adf_probe+0x5e9/0x600 [qat_dh895xccvf]
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-02-29T22:37:31.086Z
CVE-2021-47057 crypto: sun8i-ss - Fix memory leak of object d when dma_iv fails to map
In the Linux kernel, the following vulnerability has been resolved:

crypto: sun8i-ss - Fix memory leak of object d when dma_iv fails to map

In the case where the dma_iv mapping fails, the return error path leaks
the memory allocated to object d.  Fix this by adding a new error return
label and jumping to this to ensure d is free'd before the return.

Addresses-Coverity: ("Resource leak")
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-02-29T22:37:32.216Z
CVE-2021-47058 regmap: set debugfs_name to NULL after it is freed
In the Linux kernel, the following vulnerability has been resolved:

regmap: set debugfs_name to NULL after it is freed

There is a upstream commit cffa4b2122f5("regmap:debugfs:
Fix a memory leak when calling regmap_attach_dev") that
adds a if condition when create name for debugfs_name.
With below function invoking logical, debugfs_name is
freed in regmap_debugfs_exit(), but it is not created again
because of the if condition introduced by above commit.
regmap_reinit_cache()
	regmap_debugfs_exit()
	...
	regmap_debugfs_init()
So, set debugfs_name to NULL after it is freed.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-02-29T22:37:33.232Z
CVE-2021-47059 crypto: sun8i-ss - fix result memory leak on error path
In the Linux kernel, the following vulnerability has been resolved:

crypto: sun8i-ss - fix result memory leak on error path

This patch fixes a memory leak on an error path.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-02-29T22:37:34.052Z