deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2022-49219
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

vfio/pci: fix memory leak during D3hot to D0 transition

If 'vfio_pci_core_device::needs_pm_restore' is set (PCI device does
not have No_Soft_Reset bit set in its PMCSR config register), then
the current PCI state will be saved locally in
'vfio_pci_core_device::pm_save' during D0->D3hot transition and same
will be restored back during D3hot->D0 transition.
For saving the PCI state locally, pci_store_saved_state() is being
used and the pci_load_and_free_saved_state() will free the allocated
memory.

But for reset related IOCTLs, vfio driver calls PCI reset-related
API's which will internally change the PCI power state back to D0. So,
when the guest resumes, then it will get the current state as D0 and it
will skip the call to vfio_pci_set_power_state() for changing the
power state to D0 explicitly. In this case, the memory pointed by
'pm_save' will never be freed. In a malicious sequence, the state changing
to D3hot followed by VFIO_DEVICE_RESET/VFIO_DEVICE_PCI_HOT_RESET can be
run in a loop and it can cause an OOM situation.

This patch frees the earlier allocated memory first before overwriting
'pm_save' to prevent the mentioned memory leak.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/26ddd196e9eb264da8e1bdc4df8a94d62581c8b5; https://git.kernel.org/stable/c/4319f17fb8264ba39352b611dfa913a4d8c1d1a0; https://git.kernel.org/stable/c/c8a1f8bd586ee31020614b8d48b702ece3e2ae44
CVE: CVE-2022-49220
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

dax: make sure inodes are flushed before destroy cache

A bug can be triggered by following command

$ modprobe nd_pmem && modprobe -r nd_pmem

[   10.060014] BUG dax_cache (Not tainted): Objects remaining in dax_cache on __kmem_cache_shutdown()
[   10.060938] Slab 0x[PII_REDACTED]b729ac objects=9 used=1 fp=0x000000004f5ae469 flags=0x[PII_REDACTED]10200(slab|head|node)
[   10.062433] Call Trace:
[   10.062673]  dump_stack_lvl+0x34/0x44
[   10.062865]  slab_err+0x90/0xd0
[   10.063619]  __kmem_cache_shutdown+0x13b/0x2f0
[   10.063848]  kmem_cache_destroy+0x4a/0x110
[   10.064058]  __x64_sys_delete_module+0x265/0x300

This is caused by dax_fs_exit() not flushing inodes before destroy cache.
To fix this issue, call rcu_barrier() before destroy cache.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/770d42fff12d8595adda9025a0b92091f543e775; https://git.kernel.org/stable/c/a7e8de822e0b1979f08767c751f6c8a9c1d4ad86; https://git.kernel.org/stable/c/b786abe7c67c6ef71410c8e23292b3091d616ad1
CVE: CVE-2022-49221
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/msm/dp: populate connector of struct dp_panel

DP CTS test case 4.2.2.6 has valid edid with bad checksum on purpose
and expect DP source return correct checksum. During drm edid read,
correct edid checksum is calculated and stored at
connector::real_edid_checksum.

The problem is struct dp_panel::connector never be assigned, instead the
connector is stored in struct msm_dp::connector. When we run compliance
testing test case 4.2.2.6 dp_panel_handle_sink_request() won't have a valid
edid set in struct dp_panel::edid so we'll try to use the connectors
real_edid_checksum and hit a NULL pointer dereference error because the
connector pointer is never assigned.

Changes in V2:
-- populate panel connector at msm_dp_modeset_init() instead of at dp_panel_read_sink_caps()

Changes in V3:
-- remove unhelpful kernel crash trace commit text
-- remove renaming dp_display parameter to dp

Changes in V4:
-- add more details to commit text

Changes in v10:
--  group into one series

Changes in v11:
-- drop drm/msm/dp: dp_link_parse_sink_count() return immediately if aux read

Signee-off-by: Kuogee Hsieh <quic_khsieh@quicinc.com>
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/104074ebc0c3f358dd1ee944fbcde92c6e5a21dd; https://git.kernel.org/stable/c/413c62697b61226a236c8b1f5cd64dcf42bcc12f; https://git.kernel.org/stable/c/5e602f5156910c7b[PII_REDACTED]cb6e3fb94fab9
CVE: CVE-2022-49222
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/bridge: anx7625: Fix overflow issue on reading EDID

The length of EDID block can be longer than 256 bytes, so we should use
`int` instead of `u8` for the `edid_pos` variable.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190
References: https://git.kernel.org/stable/c/64c06df2428bb7bb3d8cf[PII_REDACTED]af42d94dd; https://git.kernel.org/stable/c/d5c6f647aec9ed524aedd04a3aec5ebc21d39007; https://git.kernel.org/stable/c/db1c47d299298a7c52ccb201905d6be979fd7507
CVE: CVE-2022-49223
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

cxl/port: Hold port reference until decoder release

KASAN + DEBUG_KOBJECT_RELEASE reports a potential use-after-free in
cxl_decoder_release() where it goes to reference its parent, a cxl_port,
to free its id back to port->decoder_ida.

 BUG: KASAN: use-after-free in to_cxl_port+0x18/0x90 [cxl_core]
 Read of size 8 at addr ffff[PII_REDACTED]08 by task kworker/35:2/379

 CPU: 35 PID: 379 Comm: kworker/35:2 Tainted: G           OE     5.17.0-rc2+ #198
 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
 Workqueue: events kobject_delayed_cleanup
 Call Trace:
  <TASK>
  dump_stack_lvl+0x59/0x73
  print_address_description.constprop.0+0x1f/0x150
  ? to_cxl_port+0x18/0x90 [cxl_core]
  kasan_report.cold+0x83/0xdf
  ? to_cxl_port+0x18/0x90 [cxl_core]
  to_cxl_port+0x18/0x90 [cxl_core]
  cxl_decoder_release+0x2a/0x60 [cxl_core]
  device_release+0x5f/0x100
  kobject_cleanup+0x80/0x1c0

The device core only guarantees parent lifetime until all children are
unregistered. If a child needs a parent to complete its ->release()
callback that child needs to hold a reference to extend the lifetime of
the parent.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/49f2dab77a5e1354f5da6ccdc9346a8212697be2; https://git.kernel.org/stable/c/518bb[PII_REDACTED]2b48b0a9842f2864249b565f6; https://git.kernel.org/stable/c/74be98774dfbc5b8b795db726bd772e735d2edd4
CVE: CVE-2022-49224
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

power: supply: ab8500: Fix memory leak in ab8500_fg_sysfs_init

kobject_init_and_add() takes reference even when it fails.
According to the doc of kobject_init_and_add()：

   If this function returns an error, kobject_put() must be called to
   properly clean up the memory associated with the object.

Fix memory leak by calling kobject_put().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/19aa3c98ed7b2616e105946cec804f897837ab84; https://git.kernel.org/stable/c/261041097ab3470f1120b7733cbf472712304d1e; https://git.kernel.org/stable/c/31cdf7897dba1f096b74f69d840f0575b8cdb9ae
CVE: CVE-2022-49225
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

mt76: mt7921s: fix a possible memory leak in mt7921_load_patch

Always release fw data at the end of mt7921_load_patch routine.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/11005b18f453aa192d035d410c11d07edcba5a45; https://git.kernel.org/stable/c/b301043384c5c[PII_REDACTED]be9a536c2026d8ad0
CVE: CVE-2022-49226
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

net: asix: add proper error handling of usb read errors

Syzbot once again hit uninit value in asix driver. The problem still the
same -- asix_read_cmd() reads less bytes, than was requested by caller.

Since all read requests are performed via asix_read_cmd() let's catch
usb related error there and add __must_check notation to be sure all
callers actually check return value.

So, this patch adds sanity check inside asix_read_cmd(), that simply
checks if bytes read are not less, than was requested and adds missing
error handling of asix_read_cmd() all across the driver code.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/662ff765470ad0d11a1153d6d8e99d69a98e60b4; https://git.kernel.org/stable/c/920a9fa27e7805499cfe78491b36fed2322c02ec; https://git.kernel.org/stable/c/9ea8d2fca8fea3b17005b4dc02f8ef15f7a2fb97
CVE: CVE-2022-49227
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

igc: avoid kernel warning when changing RX ring parameters

Calling ethtool changing the RX ring parameters like this:

  $ ethtool -G eth0 rx 1024

on igc triggers kernel warnings like this:

[  225.198467] ------------[ cut here ]------------
[  225.198473] Missing unregister, handled but fix driver
[  225.198485] WARNING: CPU: 7 PID: 959 at net/core/xdp.c:168
xdp_rxq_info_reg+0x79/0xd0
[...]
[  225.198601] Call Trace:
[  225.198604]  <TASK>
[  225.198609]  igc_setup_rx_resources+0x3f/0xe0 [igc]
[  225.198617]  igc_ethtool_set_ringparam+0x30e/0x450 [igc]
[  225.198626]  ethnl_set_rings+0x18a/0x250
[  225.198631]  genl_family_rcv_msg_doit+0xca/0x110
[  225.198637]  genl_rcv_msg+0xce/0x1c0
[  225.198640]  ? rings_prepare_data+0x60/0x60
[  225.198644]  ? genl_get_cmd+0xd0/0xd0
[  225.198647]  netlink_rcv_skb+0x4e/0xf0
[  225.198652]  genl_rcv+0x24/0x40
[  225.198655]  netlink_unicast+0x20e/0x330
[  225.198659]  netlink_sendmsg+0x23f/0x480
[  225.198663]  sock_sendmsg+0x5b/0x60
[  225.198667]  __sys_sendto+0xf0/0x160
[  225.198671]  ? handle_mm_fault+0xb2/0x280
[  225.198676]  ? do_user_addr_fault+0x1eb/0x690
[  225.198680]  __x64_sys_sendto+0x20/0x30
[  225.198683]  do_syscall_64+0x38/0x90
[  225.198687]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[  225.198693] RIP: 0033:0x7f7ae38ac3aa

igc_ethtool_set_ringparam() copies the igc_ring structure but neglects to
reset the xdp_rxq_info member before calling igc_setup_rx_resources().
This in turn calls xdp_rxq_info_reg() with an already registered xdp_rxq_info.

Make sure to unregister the xdp_rxq_info structure first in
igc_setup_rx_resources.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3ddb49af08094ebee250b461172ee7b8e27a35d3; https://git.kernel.org/stable/c/453307b569a0d41bddd07f26bf41b784cd82a4c9; https://git.kernel.org/stable/c/65aebcf1e05bd97d2e7ffcdff36efea1757c9450
CVE: CVE-2022-49228
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix a btf decl_tag bug when tagging a function

syzbot reported a btf decl_tag bug with stack trace below:

  general protection fault, probably for non-canonical address 0xdffffc[PII_REDACTED]: 0000 [#1] PREEMPT SMP KASAN
  KASAN: null-ptr-deref in range [0x[PII_REDACTED]000000-0x[PII_REDACTED]000007]
  CPU: 0 PID: 3592 Comm: syz-executor914 Not tainted 5.16.0-syzkaller-11424-gb7892f7d5cb2 #0
  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
  RIP: 0010:btf_type_vlen include/linux/btf.h:231 [inline]
  RIP: 0010:btf_decl_tag_resolve+0x83e/0xaa0 kernel/bpf/btf.c:3910
  ...
  Call Trace:
   <TASK>
   btf_resolve+0x251/0x1020 kernel/bpf/btf.c:4198
   btf_check_all_types kernel/bpf/btf.c:4239 [inline]
   btf_parse_type_sec kernel/bpf/btf.c:4280 [inline]
   btf_parse kernel/bpf/btf.c:4513 [inline]
   btf_new_fd+0x19fe/0x2370 kernel/bpf/btf.c:6047
   bpf_btf_load kernel/bpf/syscall.c:4039 [inline]
   __sys_bpf+0x1cbb/0x5970 kernel/bpf/syscall.c:4679
   __do_sys_bpf kernel/bpf/syscall.c:4738 [inline]
   __se_sys_bpf kernel/bpf/syscall.c:4736 [inline]
   __x64_sys_bpf+0x75/0xb0 kernel/bpf/syscall.c:4736
   do_syscall_x64 arch/x86/entry/common.c:50 [inline]
   do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
   entry_SYSCALL_64_after_hwframe+0x44/0xae

The kasan error is triggered with an illegal BTF like below:
   type 0: void
   type 1: int
   type 2: decl_tag to func type 3
   type 3: func to func_proto type 8
The total number of types is 4 and the type 3 is illegal
since its func_proto type is out of range.

Currently, the target type of decl_tag can be struct/union, var or func.
Both struct/union and var implemented their own 'resolve' callback functions
and hence handled properly in kernel.
But func type doesn't have 'resolve' callback function. When
btf_decl_tag_resolve() tries to check func type, it tries to get
vlen of its func_proto type, which triggered the above kasan error.

To fix the issue, btf_decl_tag_resolve() needs to do btf_func_check()
before trying to accessing func_proto type.
In the current implementation, func type is checked with
btf_func_check() in the main checking function btf_check_all_types().
To fix the above kasan issue, let us implement 'resolve' callback
func type properly. The 'resolve' callback will be also called
in btf_check_all_types() for func types.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/796d5666f6422ddadc938fb888044fcc16f2dbe3; https://git.kernel.org/stable/c/a3bcd2110c087bc62e90fddd4a93237b049d6e68; https://git.kernel.org/stable/c/d7e7b42f4f956f2c68ad8cda87d750093dbba737
CVE: CVE-2022-49229
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ptp: unregister virtual clocks when unregistering physical clock.

When unregistering a physical clock which has some virtual clocks,
unregister the virtual clocks with it.

This fixes the following oops, which can be triggered by unloading
a driver providing a PTP clock when it has enabled virtual clocks:

BUG: unable to handle page fault for address: ffffffffc04fc4d8
Oops: 0000 [#1] PREEMPT SMP NOPTI
RIP: 0010:ptp_vclock_read+0x31/0xb0
Call Trace:
 timecounter_read+0xf/0x50
 ptp_vclock_refresh+0x2c/0x50
 ? ptp_clock_release+0x40/0x40
 ptp_aux_kworker+0x17/0x30
 kthread_worker_fn+0x9b/0x240
 ? kthread_should_park+0x30/0x30
 kthread+0xe2/0x110
 ? kthread_complete_and_exit+0x20/0x20
 ret_from_fork+0x22/0x30
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/9c796a57cbb5daf124a665689f0b2bc9262e0ced; https://git.kernel.org/stable/c/b2dea2a696d09163da4cd33cb598ce1f73e86597; https://git.kernel.org/stable/c/bfcbb76b0f595ea9ede9f7a218086fef85242f10
CVE: CVE-2022-49230
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

mt76: mt7915: fix possible memory leak in mt7915_mcu_add_sta

Free allocated skb in mt7915_mcu_add_sta routine in case of failures.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/a43736cd12d82913102eb49cb56787a5553e028f; https://git.kernel.org/stable/c/b334a245ff1d76b1e97af8cea648ea6798b9eb87; https://git.kernel.org/stable/c/daf02c7e3c3dc82ffa925999597bd455cf799551
CVE: CVE-2022-49231
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

rtw88: fix memory overrun and memory leak during hw_scan

Previously we allocated less memory than actual required, overwrite
to the buffer causes the mm module to complaint and raise access
violation faults. Along with potential memory leaks when returned
early. Fix these by passing the correct size and proper deinit flow.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/d95984b5580dcb8b1c0036577c52b609990a1dab; https://git.kernel.org/stable/c/ec5da191bfcd5fd22b95459b623694f66c1cc10b
CVE: CVE-2022-49232
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix a NULL pointer dereference in amdgpu_dm_connector_add_common_modes()

In amdgpu_dm_connector_add_common_modes(), amdgpu_dm_create_common_mode()
is assigned to mode and is passed to drm_mode_probed_add() directly after
that. drm_mode_probed_add() passes &mode->head to list_add_tail(), and
there is a dereference of it in list_add_tail() without recoveries, which
could lead to NULL pointer dereference on failure of
amdgpu_dm_create_common_mode().

Fix this by adding a NULL check of mode.

This bug was found by a static analyzer.

Builds with 'make allyesconfig' show no new warnings,
and our static analyzer no longer warns about this code.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/19a7eba284790cfbba2945deb2363cf03ce41648; https://git.kernel.org/stable/c/2c729dec8c1e3e2892fde5ce[PII_REDACTED]914e74; https://git.kernel.org/stable/c/57f4ad5e286fe4599c8fc63cf89f85f9eec7f9c9
CVE: CVE-2022-49233
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Call dc_stream_release for remove link enc assignment

[Why]
A porting error resulted in the stream assignment for the link
being retained without being released - a memory leak.

[How]
Fix the porting error by adding back the dc_stream_release() intended
as part of the original patch.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/a28b7b6a0c827ce672edcdb5b2b5916b0beebe03; https://git.kernel.org/stable/c/f2bde8349c35d01d7c50456ea06a5c7d5e0e5ed0
CVE: CVE-2022-49234
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

net: dsa: Avoid cross-chip syncing of VLAN filtering

Changes to VLAN filtering are not applicable to cross-chip
notifications.

On a system like this:

.-----.   .-----.   .-----.
| sw1 +---+ sw2 +---+ sw3 |
'-1-2-'   '-1-2-'   '-1-2-'

Before this change, upon sw1p1 leaving a bridge, a call to
dsa_port_vlan_filtering would also be made to sw2p1 and sw3p1.

In this scenario:

.---------.   .-----.   .-----.
|   sw1   +---+ sw2 +---+ sw3 |
'-1-2-3-4-'   '-1-2-'   '-1-2-'

When sw1p4 would leave a bridge, dsa_port_vlan_filtering would be
called for sw2 and sw3 with a non-existing port - leading to array
out-of-bounds accesses and crashes on mv88e6xxx.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/108dc8741c203e9d6ce4e973367f1bac20c7192b; https://git.kernel.org/stable/c/e1f2a4dd8d433eec393d09273a78a3d3551339cf
CVE: CVE-2022-49235
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ath9k_htc: fix uninit value bugs

Syzbot reported 2 KMSAN bugs in ath9k. All of them are caused by missing
field initialization.

In htc_connect_service() svc_meta_len and pad are not initialized. Based
on code it looks like in current skb there is no service data, so simply
initialize svc_meta_len to 0.

htc_issue_send() does not initialize htc_frame_hdr::control array. Based
on firmware code, it will initialize it by itself, so simply zero whole
array to make KMSAN happy

Fail logs:

BUG: KMSAN: kernel-usb-infoleak in usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430
 usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430
 hif_usb_send_regout drivers/net/wireless/ath/ath9k/hif_usb.c:127 [inline]
 hif_usb_send+0x5f0/0x16f0 drivers/net/wireless/ath/ath9k/hif_usb.c:479
 htc_issue_send drivers/net/wireless/ath/ath9k/htc_hst.c:34 [inline]
 htc_connect_service+0x143e/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:275
...

Uninit was created at:
 slab_post_alloc_hook mm/slab.h:524 [inline]
 slab_alloc_node mm/slub.c:3251 [inline]
 __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974
 kmalloc_reserve net/core/skbuff.c:354 [inline]
 __alloc_skb+0x545/0xf90 net/core/skbuff.c:426
 alloc_skb include/linux/skbuff.h:1126 [inline]
 htc_connect_service+0x1029/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:258
...

Bytes 4-7 of 18 are uninitialized
Memory access of size 18 starts at ffff888027377e00

BUG: KMSAN: kernel-usb-infoleak in usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430
 usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430
 hif_usb_send_regout drivers/net/wireless/ath/ath9k/hif_usb.c:127 [inline]
 hif_usb_send+0x5f0/0x16f0 drivers/net/wireless/ath/ath9k/hif_usb.c:479
 htc_issue_send drivers/net/wireless/ath/ath9k/htc_hst.c:34 [inline]
 htc_connect_service+0x143e/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:275
...

Uninit was created at:
 slab_post_alloc_hook mm/slab.h:524 [inline]
 slab_alloc_node mm/slub.c:3251 [inline]
 __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974
 kmalloc_reserve net/core/skbuff.c:354 [inline]
 __alloc_skb+0x545/0xf90 net/core/skbuff.c:426
 alloc_skb include/linux/skbuff.h:1126 [inline]
 htc_connect_service+0x1029/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:258
...

Bytes 16-17 of 18 are uninitialized
Memory access of size 18 starts at ffff888027377e00
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908, CWE-908
References: https://git.kernel.org/stable/c/0b700f7d06492de34964b6f[PII_REDACTED]64f8191; https://git.kernel.org/stable/c/11f11ac281f0c0b363d2940204f28bae0422ed71; https://git.kernel.org/stable/c/4d244b731188e0b63fc40a9d2dec72e9181fb37c
CVE: CVE-2022-49237
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ath11k: add missing of_node_put() to avoid leak

The node pointer is returned by of_find_node_by_type()
or of_parse_phandle() with refcount incremented. Calling
of_node_put() to aovid the refcount leak.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3d38faef0de1756994b3d95e47b2302842f729e2; https://git.kernel.org/stable/c/7d51cb010b20d70b16dc6e4341bf29d6c5b32564
CVE: CVE-2022-49239
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: codecs: wcd934x: Add missing of_node_put() in wcd934x_codec_parse_data

The device_node pointer is returned by of_parse_phandle()  with refcount
incremented. We should use of_node_put() on it when done.
This is similar to commit 64b92de9603f
("ASoC: wcd9335: fix a leaked reference by adding missing of_node_put")
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1f24716e38220fc9e52e208d20591d2bc9b7f020; https://git.kernel.org/stable/c/2f44eca78cc6d4e1779eb95765ec79e433accab4; https://git.kernel.org/stable/c/9531a631379169d57756b2411178c6238655df88
CVE: CVE-2022-49240
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: mediatek: mt8195: Fix error handling in mt8195_mt6359_rt1019_rt5682_dev_probe

The device_node pointer is returned by of_parse_phandle()  with refcount
incremented. We should use of_node_put() on it when done.

This function only calls of_node_put() in the regular path.
And it will cause refcount leak in error path.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/c4b7174fe5bb875a09a78674a14a1589d1a672f3; https://git.kernel.org/stable/c/c652f8f0875b569f8afa80b8cf9762828fd6187b
CVE: CVE-2022-49241
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: atmel: Fix error handling in sam9x5_wm8731_driver_probe

The device_node pointer is returned by of_parse_phandle()  with refcount
incremented. We should use of_node_put() on it when done.

This function only calls of_node_put() in the regular path.
And it will cause refcount leak in error path.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/[PII_REDACTED]a0854b1de23e5b4fe8bdeeca9683b; https://git.kernel.org/stable/c/740dc3e846537c3743da98bf106f376023fd085c; https://git.kernel.org/stable/c/90ac679aa6a01841da90ec5a4aaa4b5e0badddf0
CVE: CVE-2022-49242
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: mxs: Fix error handling in mxs_sgtl5000_probe

This function only calls of_node_put() in the regular path.
And it will cause refcount leak in error paths.
For example, when codec_np is NULL, saif_np[0] and saif_np[1]
are not NULL, it will cause leaks.

of_node_put() will check if the node pointer is NULL, so we can
call it directly to release the refcount of regular pointers.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/44acdaf7acb60054d872bed18ce0e7db8ce900ce; https://git.kernel.org/stable/c/67e12f1cb2f97468c12b59e21975eaa0f332e7d2; https://git.kernel.org/stable/c/6ae0a4d8fec551ec581d620f0eb1fe31f755551c