deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2021-47024
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

vsock/virtio: free queued packets when closing socket

As reported by syzbot [1], there is a memory leak while closing the
socket. We partially solved this issue with commit ac03046ece2b
("vsock/virtio: free packets during the socket release"), but we
forgot to drain the RX queue when the socket is definitely closed by
the scheduled work.

To avoid future issues, let's use the new virtio_transport_remove_sock()
to drain the RX queue before removing the socket from the af_vsock lists
calling vsock_remove_sock().

[1] https://syzkaller.appspot.com/bug?extid=24452624fc4c571eedd9
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/[PII_REDACTED]5e74a45034a9dccf1150cf1894763a; https://git.kernel.org/stable/c/37c38674ef2f8d7e8629e5d433c37d6c1273d16b; https://git.kernel.org/stable/c/8432b[PII_REDACTED]f42e070a16118a7f750de9d39
CVE: CVE-2021-47025
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

iommu/mediatek: Always enable the clk on resume

In mtk_iommu_runtime_resume always enable the clk, even
if m4u_dom is null. Otherwise the 'suspend' cb might
disable the clk which is already disabled causing the warning:

[    1.586104] infra_m4u already disabled
[    1.586133] WARNING: CPU: 0 PID: 121 at drivers/clk/clk.c:952 clk_core_disable+0xb0/0xb8
[    1.594391] mtk-iommu 10205000.iommu: bound 18001000.larb (ops mtk_smi_larb_component_ops)
[    1.598108] Modules linked in:
[    1.598114] CPU: 0 PID: 121 Comm: kworker/0:2 Not tainted 5.12.0-rc5 #69
[    1.609246] mtk-iommu 10205000.iommu: bound 14027000.larb (ops mtk_smi_larb_component_ops)
[    1.617487] Hardware name: Google Elm (DT)
[    1.617491] Workqueue: pm pm_runtime_work
[    1.620545] mtk-iommu 10205000.iommu: bound 19001000.larb (ops mtk_smi_larb_component_ops)

[    1.627229] pstate: 60000085 (nZCv daIf -PAN -UAO -TCO BTYPE=--)
[    1.659297] pc : clk_core_disable+0xb0/0xb8
[    1.663475] lr : clk_core_disable+0xb0/0xb8
[    1.667652] sp : ffff800011b9bbe0
[    1.670959] x29: ffff800011b9bbe0 x28: [PII_REDACTED]
[    1.676267] x27: ffff[PII_REDACTED]00 x26: ffff8000100cfd98
[    1.681574] x25: ffff800011b9bd48 x24: [PII_REDACTED]
[    1.686882] x23: [PII_REDACTED] x22: ffff8000106fad90
[    1.692189] x21:[PII_REDACTED]00000a x20: ffff0000c0048500
[    1.697496] x19: ffff0000c0048500 x18: ffffffffffffffff
[    1.702804] x17: [PII_REDACTED] x16: [PII_REDACTED]
[    1.708112] x15: ffff[PII_REDACTED]00 x14: fffffffffffe0000
[    1.713420] x13: ffff[PII_REDACTED]d8 x12: [PII_REDACTED]
[    1.718727] x11: [PII_REDACTED] x10: [PII_REDACTED]
[    1.724035] x9 : ffff800011b9bbe0 x8 : ffff800011b9bbe0
[    1.729342] x7 : [PII_REDACTED] x6 : ffff8000114b8328
[    1.734649] x5 : [PII_REDACTED] x4 : [PII_REDACTED]
[    1.739956] x3 : 00000000ffffffff x2 : ffff[PII_REDACTED]98
[    1.745263] x1 : 1af1d7de276f4500 x0 : [PII_REDACTED]
[    1.750572] Call trace:
[    1.753010]  clk_core_disable+0xb0/0xb8
[    1.756840]  clk_core_disable_lock+0x24/0x40
[    1.761105]  clk_disable+0x20/0x30
[    1.764501]  mtk_iommu_runtime_suspend+0x88/0xa8
[    1.769114]  pm_generic_runtime_suspend+0x2c/0x48
[    1.773815]  __rpm_callback+0xe0/0x178
[    1.777559]  rpm_callback+0x24/0x88
[    1.781041]  rpm_suspend+0xdc/0x470
[    1.784523]  rpm_idle+0x12c/0x170
[    1.787831]  pm_runtime_work+0xa8/0xc0
[    1.791573]  process_one_work+0x1e8/0x360
[    1.795580]  worker_thread+0x44/0x478
[    1.799237]  kthread+0x150/0x158
[    1.802460]  ret_from_fork+0x10/0x30
[    1.806034] ---[ end trace 82402920ef64573b ]---
[    1.810728] ------------[ cut here ]------------

In addition, we now don't need to enable the clock from the
function mtk_iommu_hw_init since it is already enabled by the resume.
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/5cad9e2caa9613fdcd246bd4ebf0ffbec1cba2ca; https://git.kernel.org/stable/c/b34ea31fe013569d42b7e8681ef3f717f77c5b72; https://git.kernel.org/stable/c/5cad9e2caa9613fdcd246bd4ebf0ffbec1cba2ca
CVE: CVE-2021-47026
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/rtrs-clt: destroy sysfs after removing session from active list

A session can be removed dynamically by sysfs interface "remove_path" that
eventually calls rtrs_clt_remove_path_from_sysfs function.  The current
rtrs_clt_remove_path_from_sysfs first removes the sysfs interfaces and
frees sess->stats object. Second it removes the session from the active
list.

Therefore some functions could access non-connected session and access the
freed sess->stats object even-if they check the session status before
accessing the session.

For instance rtrs_clt_request and get_next_path_min_inflight check the
session status and try to send IO to the session.  The session status
could be changed when they are trying to send IO but they could not catch
the change and update the statistics information in sess->stats object,
and generate use-after-free problem.
(see: "RDMA/rtrs-clt: Check state of the rtrs_clt_sess before reading its
stats")

This patch changes the rtrs_clt_remove_path_from_sysfs to remove the
session from the active session list and then destroy the sysfs
interfaces.

Each function still should check the session status because closing or
error recovery paths can change the status.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/676171f9405dcaa45a33d18241c32f387dbaae39; https://git.kernel.org/stable/c/7f4a8592ff29f19c5a2ca549d[PII_REDACTED]afaad; https://git.kernel.org/stable/c/b64415c6b3476cf9fa4d0aea3807065b8403a937
CVE: CVE-2021-47027
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

mt76: mt7921: fix kernel crash when the firmware fails to download

Fix kernel crash when the firmware is missing or fails to download.

[    9.444758] kernel BUG at drivers/pci/msi.c:375!
[    9.449363] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[    9.501033] pstate: a0400009 (NzCv daif +PAN -UAO)
[    9.505814] pc : free_msi_irqs+0x180/0x184
[    9.509897] lr : free_msi_irqs+0x40/0x184
[    9.513893] sp : ffffffc015193870
[    9.517194] x29: ffffffc015193870 x28: 00000000f0e94fa2
[    9.522492] x27:[PII_REDACTED]000acd x26:[PII_REDACTED]00009a
[    9.527790] x25: ffffffc0152cee58 x24: ffffffdbb383e0d8
[    9.533087] x23: ffffffdbb38628d0 x22: [PII_REDACTED]
[    9.538384] x21: ffffff8cf7de7318 x20: ffffff8cd65a2480
[    9.543681] x19: ffffff8cf7de7000 x18: [PII_REDACTED]
[    9.548979] x17: ffffff8cf9ca03b4 x16: ffffffdc13ad9a34
[    9.554277] x15: [PII_REDACTED] x14: [PII_REDACTED]
[    9.559575] x13: ffffff8cd65a2980 x12: [PII_REDACTED]
[    9.564873] x11: ffffff8cfa45d820 x10: ffffff8cfa45d6d0
[    9.570171] x9 : [PII_REDACTED] x8 : ffffff8ccef1b780
[    9.575469] x7 : aaaaaaaaaaaaaaaa x6 : [PII_REDACTED]
[    9.580766] x5 : ffffffdc13824900 x4 : ffffff8ccefe0000
[    9.586063] x3 : [PII_REDACTED] x2 : [PII_REDACTED]
[    9.591362] x1 : [PII_REDACTED] x0 : ffffff8ccefe0000
[    9.596660] Call trace:
[    9.599095]  free_msi_irqs+0x180/0x184
[    9.602831]  pci_disable_msi+0x100/0x130
[    9.606740]  pci_free_irq_vectors+0x24/0x30
[    9.610915]  mt7921_pci_probe+0xbc/0x250 [mt7921e]
[    9.615693]  pci_device_probe+0xd4/0x14c
[    9.619604]  really_probe+0x134/0x2ec
[    9.623252]  driver_probe_device+0x64/0xfc
[    9.627335]  device_driver_attach+0x4c/0x6c
[    9.631506]  __driver_attach+0xac/0xc0
[    9.635243]  bus_for_each_dev+0x8c/0xd4
[    9.639066]  driver_attach+0x2c/0x38
[    9.642628]  bus_add_driver+0xfc/0x1d0
[    9.646365]  driver_register+0x64/0xf8
[    9.650101]  __pci_register_driver+0x6c/0x7c
[    9.654360]  init_module+0x28/0xfdc [mt7921e]
[    9.658704]  do_one_initcall+0x13c/0x2d0
[    9.662615]  do_init_module+0x58/0x1e8
[    9.666351]  load_module+0xd80/0xeb4
[    9.669912]  __arm64_sys_finit_module+0xa8/0xe0
[    9.674430]  el0_svc_common+0xa4/0x16c
[    9.678168]  el0_svc_compat_handler+0x2c/0x40
[    9.682511]  el0_svc_compat+0x8/0x10
[    9.686076] Code: a94257f6 f9400bf7 a8c47bfd d65f03c0 (d4210000)
[    9.692155] ---[ end trace 7621f966afbf0a29 ]---
[    9.697385] Kernel panic - not syncing: Fatal exception
[    9.702599] SMP: stopping secondary CPUs
[    9.706549] Kernel Offset: 0x1c03600000 from 0xffffffc010000000
[    9.712456] PHYS_OFFSET: 0xfffffff440000000
[    9.716625] CPU features: 0x080026,2a80aa18
[    9.720795] Memory Limit: none
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/a46b536cd60c0dbd4bf767c62a8774dec52bf099; https://git.kernel.org/stable/c/e230f0c44f011f3270680a506b19b7e84c5e8923; https://git.kernel.org/stable/c/a46b536cd60c0dbd4bf767c62a8774dec52bf099
CVE: CVE-2021-47028
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

mt76: mt7915: fix txrate reporting

Properly check rate_info to fix unexpected reporting.

[ 1215.161863] Call trace:
[ 1215.164307]  cfg80211_calculate_bitrate+0x124/0x200 [cfg80211]
[ 1215.170139]  ieee80211s_update_metric+0x80/0xc0 [mac80211]
[ 1215.175624]  ieee80211_tx_status_ext+0x508/0x838 [mac80211]
[ 1215.181190]  mt7915_mcu_get_rx_rate+0x28c/0x8d0 [mt7915e]
[ 1215.186580]  mt7915_mac_tx_free+0x324/0x7c0 [mt7915e]
[ 1215.191623]  mt7915_queue_rx_skb+0xa8/0xd0 [mt7915e]
[ 1215.196582]  mt76_dma_cleanup+0x7b0/0x11d0 [mt76]
[ 1215.201276]  __napi_poll+0x38/0xf8
[ 1215.204668]  napi_workfn+0x40/0x80
[ 1215.208062]  process_one_work+0x1fc/0x390
[ 1215.212062]  worker_thread+0x48/0x4d0
[ 1215.215715]  kthread+0x120/0x128
[ 1215.218935]  ret_from_fork+0x10/0x1c
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/4bd926e5ca88eac4d95eacb806b229f8729bc62e; https://git.kernel.org/stable/c/dfc8a71448c7d4fec38fb22bdc8a76d79c14b6da; https://git.kernel.org/stable/c/f43b941fd61003659a3f0e039595e5e525917aa8
CVE: CVE-2021-47029
Published: 2024-02-28
Description: 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: [PII_REDACTED]
[  508.127785] x15: [PII_REDACTED] x14: ffffff801d704000
[  508.133087] x13: [PII_REDACTED] x12: [PII_REDACTED]
[  508.138389] x11:[PII_REDACTED]00000c x10: [PII_REDACTED]
[  508.143691] x9 : [PII_REDACTED] x8 : [PII_REDACTED]
[  508.148992] x7 : [PII_REDACTED] x6 : [PII_REDACTED]
[  508.154294] x5 : ffffff801c7eaee8 x4 : [PII_REDACTED]
[  508.159596] x3 : [PII_REDACTED] x2 : [PII_REDACTED]
[  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 ]------------
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2554b9cb4b5e097c6071ec3ed5bc7c665c477ca7; https://git.kernel.org/stable/c/c996f0346e40e3b1ac2ebaf0681df898fb157f60; https://git.kernel.org/stable/c/2554b9cb4b5e097c6071ec3ed5bc7c665c477ca7
CVE: CVE-2021-47030
Published: 2024-02-28
Description: 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.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/49cc85059a2cb656f96ff3693f891e8fe8f669a9; https://git.kernel.org/stable/c/54b989653c5531bc4416ced33f146b9cb633d978; https://git.kernel.org/stable/c/49cc85059a2cb656f96ff3693f891e8fe8f669a9
CVE: CVE-2021-47031
Published: 2024-02-28
Description: 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.
CVSS Score: 4.3 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/[PII_REDACTED]453607175ea057777faa7e7f752204; https://git.kernel.org/stable/c/782b3e86ea970e899f8e723db9f64708a15ca30e; https://git.kernel.org/stable/c/[PII_REDACTED]453607175ea057777faa7e7f752204
CVE: CVE-2021-47032
Published: 2024-02-28
Description: 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
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/4a9dcd6efb2a268fc5707dcfb3b0c412975c4462; https://git.kernel.org/stable/c/4e7914ce23306b28d377ec395e00e5fde0e6f96e; https://git.kernel.org/stable/c/7dcf3c04f0aca746517a77433b33d40868ca4749
CVE: CVE-2021-47033
Published: 2024-02-28
Description: 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
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/75bc5f779a7664d1fc19cb915039439c6e58bb94; https://git.kernel.org/stable/c/821ae236ccea989a1fcc6abfc4d5b74ad4ba39d2; https://git.kernel.org/stable/c/a025277a80add18c33d01042525a74fe5b875f25
CVE: CVE-2021-47035
Published: 2024-02-28
Description: 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.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/25faff[PII_REDACTED]4c678c7fc78f7c0340fa04a0; https://git.kernel.org/stable/c/66c24699f266ff310381a9552d3576eea8ad6e20; https://git.kernel.org/stable/c/89bd620798704a8805fc9db0d71d7f812cf5b3d2
CVE: CVE-2021-47036
Published: 2024-02-28
Description: 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
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/18f25dc399901426dff61e676ba603ff52c666f7; https://git.kernel.org/stable/c/450687386cd16d081b58cd7a342acff370a96078; https://git.kernel.org/stable/c/18f25dc399901426dff61e676ba603ff52c666f7
CVE: CVE-2021-47037
Published: 2024-02-28
Description: 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.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2202e87fc19440cecfd4f7b4f60a7d48bc2e236c; https://git.kernel.org/stable/c/62413972f[PII_REDACTED]a36fd15160397b211fa74; https://git.kernel.org/stable/c/6893df3753beafa5f7351228a9dd8157a57d7492
CVE: CVE-2021-47039
Published: 2024-02-28
Description: 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.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/07f86aa8f4fe077be1b018cc177eb8c6573e5671; https://git.kernel.org/stable/c/1ffec389a6431782a8a28805830b6fae9bf00af1; https://git.kernel.org/stable/c/2a3a8bbca28b899806844c00d49ed1b7ccb50957
CVE: CVE-2021-47040
Published: 2024-02-28
Description: 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.
CVSS Score: 7.8 (HIGH)
CWE: CWE-120
References: https://git.kernel.org/stable/c/38134ada0ceea3e848fe993263c0ff6207fd46e7; https://git.kernel.org/stable/c/51bf90901952aaac564bbdb36b2b503050c53dd9; https://git.kernel.org/stable/c/84b8c266c4bfe9ed5128e13253c388deb74b1b03
CVE: CVE-2021-47042
Published: 2024-02-28
Description: 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[PII_REDACTED] (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]
[<[PII_REDACTED]94d1f3>] amdgpu_dm_init+0x18e/0x17a0 [amdgpu]
[<00000000bec048fd>] dm_hw_init+0x12/0x20 [amdgpu]
[<00000000a2bb7cf6>] amdgpu_device_init+0x1463/0x1e60 [amdgpu]
[<[PII_REDACTED]d3bb13>] amdgpu_driver_load_kms+0x5b/0x330 [amdgpu]
[<00000000a27834f9>] amdgpu_pci_probe+0x192/0x280 [amdgpu]
[<00000000fec7d291>] local_pci_probe+0x47/0xa0
[<[PII_REDACTED]dbbfa7>] pci_device_probe+0xe3/0x180
[<[PII_REDACTED]5da970>] 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
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/296443139f893b554dddd56a99ba8471ab5802d4; https://git.kernel.org/stable/c/616cf23b6cf40ad6f03ffbddfa1b6c4eb68d8ae1; https://git.kernel.org/stable/c/296443139f893b554dddd56a99ba8471ab5802d4
CVE: CVE-2021-47043
Published: 2024-02-28
Description: 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.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/00b68a7478343afdf83f30c43e64db[PII_REDACTED]; https://git.kernel.org/stable/c/5a465c5391a856a0c1e9554964d660676c35d1b2; https://git.kernel.org/stable/c/711acdf0228dc71601247f28b56f13e850e395c8
CVE: CVE-2021-47044
Published: 2024-02-28
Description: 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.
CVSS Score: 7.7 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/2f3eab368e313dba35fc2f51ede778bf7b030b54; https://git.kernel.org/stable/c/39a2a6eb5c9b66ea7c[PII_REDACTED]b3aa681b49a5; https://git.kernel.org/stable/c/805cea93e66ca7deaaf6ad3b67224ce47c104c2f