Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2022-49213 State: PUBLISHED Published: 2025-02-26T01:55:49.176Z Last Updated: 2025-10-01T19:47:05.827Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ath10k: Fix error handling in ath10k_setup_msa_resources 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. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/315772133a4b960859e4f5efe0e738e347188cdc - https://git.kernel.org/stable/c/3293918
es: - https://git.kernel.org/stable/c/315772133a4b960859e4f5efe0e738e347188cdc - https://git.kernel.org/stable/c/32939187f254171a5666badc058bc3787fe454af - https://git.kernel.org/stable/c/74b1d41e1b6410eed5c76d00eedb262036e9eff5 - https://git.kernel.org/stable/c/4ed37d611ea5d222c3ecb3549e4c2d34b8f3c335 - https://git.kernel.org/stable/c/9747a78d5f758a5284751a10aee13c30d02bd5f1
CVE ID: CVE-2022-49214 State: PUBLISHED Published: 2025-02-26T01:55:49.677Z Last Updated: 2025-05-04T08:32:31.260Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: powerpc/64s: Don't use DSISR for SLB faults Since commit 46ddcb3950a2 ("powerpc/mm: Show if a bad page fault on data is read or write.") we use page_fault_is_write(regs->dsisr) in __bad_page_fault() to determine if the fault is for a read or write, and change the message printed accordingly. But SLB faults, aka Data Segment Interrupts, don't set DSISR (Data Storage Interrupt Status Register) to a useful value. All ISA versions from v2.03 through v3.1 specify that the D
(Data Storage Interrupt Status Register) to a useful value. All ISA versions from v2.03 through v3.1 specify that the Data Segment Interrupt sets DSISR "to an undefined value". As far as I can see there's no mention of SLB faults setting DSISR in any BookIV content either. This manifests as accesses that should be a read being incorrectly reported as writes, for example, using the xmon "dump" command: 0:mon> d 0x5deadbeef0000000 5deadbeef0000000 [359526.415354][ C6] BUG: Unable to handle kernel data access on write at 0x5deadbeef0000000 [359526.415611][ C6] Faulting instruction address: 0xc00000000010a300 cpu 0x6: Vector: 380 (Data SLB Access) at [c00000000ffbf400] pc: c00000000010a300: mre
ction address: 0xc00000000010a300 cpu 0x6: Vector: 380 (Data SLB Access) at [c00000000ffbf400] pc: c00000000010a300: mread+0x90/0x190 If we disassemble the PC, we see a load instruction: 0:mon> di c00000000010a300 c00000000010a300 89490000 lbz r10,0(r9) We can also see in exceptions-64s.S that the data_access_slb block doesn't set IDSISR=1, which means it doesn't load DSISR into pt_regs. So the value we're using to determine if the fault is a read/write is some stale value in pt_regs from a previous page fault. Rework the printing logic to separate the SLB fault case out, and only print read/write in the cases where we can determine it. The result looks like eg: 0:mon> d 0x5deadbeef0000000 5
nd only print read/write in the cases where we can determine it. The result looks like eg: 0:mon> d 0x5deadbeef0000000 5deadbeef0000000 [ 721.779525][ C6] BUG: Unable to handle kernel data access at 0x5deadbeef0000000 [ 721.779697][ C6] Faulting instruction address: 0xc00000000014cbe0 cpu 0x6: Vector: 380 (Data SLB Access) at [c00000000ffbf390] 0:mon> d 0 0000000000000000 [ 742.793242][ C6] BUG: Kernel NULL pointer dereference at 0x00000000 [ 742.793316][ C6] Faulting instruction address: 0xc00000000014cbe0 cpu 0x6: Vector: 380 (Data SLB Access) at [c00000000ffbf390] References: - https://git.kernel.org/stable/c/4a852ff9b7bea9c640540e2c1bc70bd3ba455d61 - https://git.kernel.org/stable/c/a3dae
nces: - https://git.kernel.org/stable/c/4a852ff9b7bea9c640540e2c1bc70bd3ba455d61 - https://git.kernel.org/stable/c/a3dae36d632b2cf6eb20314273e512a96cb43c9a - https://git.kernel.org/stable/c/093449bb182db885dae816d62874cccab7a4c42a - https://git.kernel.org/stable/c/d4679ac8ea2e5078704aa1c026db36580cc1bf9a
CVE ID: CVE-2022-49215 State: PUBLISHED Published: 2025-02-26T01:55:50.154Z Last Updated: 2025-10-01T19:47:05.649Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: xsk: Fix race at socket teardown Fix a race in the xsk socket teardown code that can lead to a NULL pointer dereference splat. The current xsk unbind code in xsk_unbind_dev() starts by setting xs->state to XSK_UNBOUND, sets xs->dev to NULL and then waits for any NAPI processing to terminate using synchronize_net(). After that, the release code starts to tear down the socket state and free allocated memory. BUG: kernel NULL pointer dereference, address: 00000000000000c0
to tear down the socket state and free allocated memory. BUG: kernel NULL pointer dereference, address: 00000000000000c0 PGD 8000000932469067 P4D 8000000932469067 PUD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 25 PID: 69132 Comm: grpcpp_sync_ser Tainted: G I 5.16.0+ #2 Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.2.10 03/09/2015 RIP: 0010:__xsk_sendmsg+0x2c/0x690 [...] RSP: 0018:ffffa2348bd13d50 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000040 RCX: ffff8d5fc632d258 RDX: 0000000000400000 RSI: ffffa2348bd13e10 RDI: ffff8d5fc5489800 RBP: ffffa2348bd13db0 R08: 0000000000000000 R09: 00007ffffffff000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d5fc5489800 R13: ffff8d5fc
0000000000000000 R09: 00007ffffffff000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d5fc5489800 R13: ffff8d5fcb0f5140 R14: ffff8d5fcb0f5140 R15: 0000000000000000 FS: 00007f991cff9400(0000) GS:ffff8d6f1f700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000c0 CR3: 0000000114888005 CR4: 00000000001706e0 Call Trace: <TASK> ? aa_sk_perm+0x43/0x1b0 xsk_sendmsg+0xf0/0x110 sock_sendmsg+0x65/0x70 __sys_sendto+0x113/0x190 ? debug_smp_processor_id+0x17/0x20 ? fpregs_assert_state_consistent+0x23/0x50 ? exit_to_user_mode_prepare+0xa5/0x1d0 __x64_sys_sendto+0x29/0x30 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae There are two
re+0xa5/0x1d0 __x64_sys_sendto+0x29/0x30 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae There are two problems with the current code. First, setting xs->dev to NULL before waiting for all users to stop using the socket is not correct. The entry to the data plane functions xsk_poll(), xsk_sendmsg(), and xsk_recvmsg() are all guarded by a test that xs->state is in the state XSK_BOUND and if not, it returns right away. But one process might have passed this test but still have not gotten to the point in which it uses xs->dev in the code. In this interim, a second process executing xsk_unbind_dev() might have set xs->dev to NULL which will lead to a crash for the first process.
cond process executing xsk_unbind_dev() might have set xs->dev to NULL which will lead to a crash for the first process. The solution here is just to get rid of this NULL assignment since it is not used anymore. Before commit 42fddcc7c64b ("xsk: use state member for socket synchronization"), xs->dev was the gatekeeper to admit processes into the data plane functions, but it was replaced with the state variable xs->state in the aforementioned commit. The second problem is that synchronize_net() does not wait for any process in xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() to complete, which means that the state they rely on might be cleaned up prematurely. This can happen when the notifier gets
omplete, which means that the state they rely on might be cleaned up prematurely. This can happen when the notifier gets called (at driver unload for example) as it uses xsk_unbind_dev(). Solve this by extending the RCU critical region from just the ndo_xsk_wakeup to the whole functions mentioned above, so that both the test of xs->state == XSK_BOUND and the last use of any member of xs is covered by the RCU critical section. This will guarantee that when synchronize_net() completes, there will be no processes left executing xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() and state can be cleaned up safely. Note that we need to drop the RCU lock for the skb xmit path as it uses functions that mi
tate can be cleaned up safely. Note that we need to drop the RCU lock for the skb xmit path as it uses functions that might sleep. Due to this, we have to retest the xs->state after we grab the mutex that protects the skb xmit code from, among a number of things, an xsk_unbind_dev() being executed from the notifier at the same time. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/ad7219cd8751bd258b9d1e69ae0654ec00f71875 - https://git.kernel.org/stable/c/d1579253ffce39986e7a6ab757ac93b2680a665f - https://git.kernel.org/stable/c/8a2dea162b92c322f3e42eae0c4a74b8d20aa7a9 - https://git.kernel.org/stable/c/18b1ab7aa76bde181bdb1ab19a87fa9523c32f21
CVE ID: CVE-2022-49216 State: PUBLISHED Published: 2025-02-26T01:55:50.651Z Last Updated: 2025-10-01T19:47:04.954Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Fix reference leak in tegra_dsi_ganged_probe The reference taken by 'of_find_device_by_node()' must be released when not needed anymore. Add put_device() call to fix this. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/0e2f4e434e71dffd1085c3dccd676514bd71d316 - https://git.kernel.org/stable/c/5e8fdb6392d945d33fef959eab73f8c34bc0a63b - https://git.kernel.org/stable/c/2d6ae8b747fe55f54de4a4441d636974aa53f56a -
c/5e8fdb6392d945d33fef959eab73f8c34bc0a63b - https://git.kernel.org/stable/c/2d6ae8b747fe55f54de4a4441d636974aa53f56a - https://git.kernel.org/stable/c/a725070701883fe62266ee6d2f31d67e6cdd31df - https://git.kernel.org/stable/c/1e06710c43a090f14bb67714265a01cd1d7a37c5 - https://git.kernel.org/stable/c/852c1f5f3119a38ee68e319bab10277fc1ab06b7 - https://git.kernel.org/stable/c/cd78b74031cbc94133965f1017deb822657fc1a6 - https://git.kernel.org/stable/c/f3c99c686e098300c246e5e8a1474133e3dacb05 - https://git.kernel.org/stable/c/221e3638feb8bc42143833c9a704fa89b6c366bb
CVE ID: CVE-2022-49217 State: PUBLISHED Published: 2025-02-26T01:55:51.156Z Last Updated: 2025-05-04T08:32:34.514Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Fix abort all task initialization In pm80xx_send_abort_all(), the n_elem field of the ccb used is not initialized to 0. This missing initialization sometimes lead to the task completion path seeing the ccb with a non-zero n_elem resulting in the execution of invalid dma_unmap_sg() calls in pm8001_ccb_task_free(), causing a crash such as: [ 197.676341] RIP: 0010:iommu_dma_unmap_sg+0x6d/0x280 [ 197.700204] RSP: 0018:ffff889bbcf89c88 EFLAGS: 00010012 [ 197.7
[ 197.676341] RIP: 0010:iommu_dma_unmap_sg+0x6d/0x280 [ 197.700204] RSP: 0018:ffff889bbcf89c88 EFLAGS: 00010012 [ 197.705485] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff83d0bda0 [ 197.712687] RDX: 0000000000000002 RSI: 0000000000000000 RDI: ffff88810dffc0d0 [ 197.719887] RBP: 0000000000000000 R08: 0000000000000000 R09: ffff8881c790098b [ 197.727089] R10: ffffed1038f20131 R11: 0000000000000001 R12: 0000000000000000 [ 197.734296] R13: ffff88810dffc0d0 R14: 0000000000000010 R15: 0000000000000000 [ 197.741493] FS: 0000000000000000(0000) GS:ffff889bbcf80000(0000) knlGS:0000000000000000 [ 197.749659] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 197.755459] CR2: 00007f16c1b4273
knlGS:0000000000000000 [ 197.749659] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 197.755459] CR2: 00007f16c1b42734 CR3: 0000000004814000 CR4: 0000000000350ee0 [ 197.762656] Call Trace: [ 197.765127] <IRQ> [ 197.767162] pm8001_ccb_task_free+0x5f1/0x820 [pm80xx] [ 197.772364] ? do_raw_spin_unlock+0x54/0x220 [ 197.776680] pm8001_mpi_task_abort_resp+0x2ce/0x4f0 [pm80xx] [ 197.782406] process_oq+0xe85/0x7890 [pm80xx] [ 197.786817] ? lock_acquire+0x194/0x490 [ 197.790697] ? handle_irq_event+0x10e/0x1b0 [ 197.794920] ? mpi_sata_completion+0x2d70/0x2d70 [pm80xx] [ 197.800378] ? __wake_up_bit+0x100/0x100 [ 197.804340] ? lock_is_held_type+0x98/0x110 [ 197.808565] pm80xx_chip_isr+0x94/0x130 [pm8
] ? __wake_up_bit+0x100/0x100 [ 197.804340] ? lock_is_held_type+0x98/0x110 [ 197.808565] pm80xx_chip_isr+0x94/0x130 [pm80xx] [ 197.813243] tasklet_action_common.constprop.0+0x24b/0x2f0 [ 197.818785] __do_softirq+0x1b5/0x82d [ 197.822485] ? do_raw_spin_unlock+0x54/0x220 [ 197.826799] __irq_exit_rcu+0x17e/0x1e0 [ 197.830678] irq_exit_rcu+0xa/0x20 [ 197.834114] common_interrupt+0x78/0x90 [ 197.840051] </IRQ> [ 197.844236] <TASK> [ 197.848397] asm_common_interrupt+0x1e/0x40 Avoid this issue by always initializing the ccb n_elem field to 0 in pm8001_send_abort_all(), pm8001_send_read_log() and pm80xx_send_abort_all(). References: - https://git.kernel.org/stable/c/9914461db82caee6c519acfbe10a86fe1
_read_log() and pm80xx_send_abort_all(). References: - https://git.kernel.org/stable/c/9914461db82caee6c519acfbe10a86fe11bcdeca - https://git.kernel.org/stable/c/d6ec4471550cc53e96485a7124c5891e6a38d1c3 - https://git.kernel.org/stable/c/1824a21b2cedc5774a5adfa74f5f7b90472d8677 - https://git.kernel.org/stable/c/765674e3b30121782a2b792684554baa48c61f5e - https://git.kernel.org/stable/c/279f318bd7d6e04e6e0bc7b8cd8e190da8fa37a4 - https://git.kernel.org/stable/c/c8db786858d895ac58342f67767b4999ae6538fa - https://git.kernel.org/stable/c/326d894adf89f3c707b7784becbe241830daaab6 - https://git.kernel.org/stable/c/16cd02e0951b520bef324adb9a35afcc92501caf - https://git.kernel.org/stable/c/7f12845c83898
https://git.kernel.org/stable/c/16cd02e0951b520bef324adb9a35afcc92501caf - https://git.kernel.org/stable/c/7f12845c8389855dbcc67baa068b6832dc4a396e
CVE ID: CVE-2022-49218 State: PUBLISHED Published: 2025-02-26T01:55:51.646Z Last Updated: 2025-10-01T19:47:04.533Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/dp: Fix OOB read when handling Post Cursor2 register The link_status array was not large enough to read the Adjust Request Post Cursor2 register, so remove the common helper function to avoid an OOB read, found with a -Warray-bounds build: drivers/gpu/drm/drm_dp_helper.c: In function 'drm_dp_get_adjust_request_post_cursor': drivers/gpu/drm/drm_dp_helper.c:59:27: error: array subscript 10 is outside array bounds of 'const u8[6]' {aka 'const unsigned char[6]'} [-Werr
helper.c:59:27: error: array subscript 10 is outside array bounds of 'const u8[6]' {aka 'const unsigned char[6]'} [-Werror=array-bounds] 59 | return link_status[r - DP_LANE0_1_STATUS]; | ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/drm_dp_helper.c:147:51: note: while referencing 'link_status' 147 | u8 drm_dp_get_adjust_request_post_cursor(const u8 link_status[DP_LINK_STATUS_SIZE], | ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Replace the only user of the helper with an open-coded fetch and decode, similar to drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/aeaed9a9fe694f8b1462fb81e2d33298c92
nalyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/aeaed9a9fe694f8b1462fb81e2d33298c929180b - https://git.kernel.org/stable/c/a2151490cc6c57b368d7974ffd447a8b36ade639
CVE ID: CVE-2022-49219 State: PUBLISHED Published: 2025-02-26T01:55:52.131Z Last Updated: 2025-11-03T19:27:50.105Z Vendors: Linux Products: Linux 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() wil
ion. 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 fre
ed 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. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/da426ad86027b849b877d4628b277ffbbd2f5325 - https://git.kernel.org/stable/c/4319f17fb8264ba39352b611dfa913a4d8c1d1a0 - https://git.kernel.org/stable/c/26ddd196e9eb264da8e1bdc4df8a94d62581c8b5 - https://git.kernel.org/stable/c/c8a1f8bd586ee31020614b8d48b702ece3e2ae44 - https://git.kernel.org/stable/c/eadf88ecf6ac7d6a9f47a76c6055d9a1987a8991
CVE ID: CVE-2022-49220 State: PUBLISHED Published: 2025-02-26T01:55:52.821Z Last Updated: 2025-05-04T08:32:44.211Z Vendors: Linux Products: Linux 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 0x0000000085b729ac objects=9 used=1 fp=0x000000004f5ae469 flags=0x200000000010200(slab|head|node) [ 10.062433] Call Trace: [ 10.062673] dump_stack_lvl+0x34/0x44 [ 10.062865] slab_err+0x90/0xd0 [ 10.063619] __kmem_c
de) [ 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. References: - https://git.kernel.org/stable/c/770d42fff12d8595adda9025a0b92091f543e775 - https://git.kernel.org/stable/c/ec376f5c11c88c0215d173599db8449cd4196759 - https://git.kernel.org/stable/c/e2951eaa9398415ac054b7bd80b8163b6838ead4 - https://git.kernel.org/stable/c/f2a1e0eb70c2d954176c07d75d28742bde30e9f3 - https://git.ke
415ac054b7bd80b8163b6838ead4 - https://git.kernel.org/stable/c/f2a1e0eb70c2d954176c07d75d28742bde30e9f3 - https://git.kernel.org/stable/c/b786abe7c67c6ef71410c8e23292b3091d616ad1 - https://git.kernel.org/stable/c/a7e8de822e0b1979f08767c751f6c8a9c1d4ad86
CVE ID: CVE-2022-49221 State: PUBLISHED Published: 2025-02-26T01:55:53.318Z Last Updated: 2025-10-01T19:47:04.278Z Vendors: Linux Products: Linux 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
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 immed
ext 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> Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/413c62697b61226a236c8b1f5cd64dcf42bcc12f - https://git.kernel.org/stable/c/9525b8bcae8b99188990b56484799cf4b1b43786 - https://git.kernel.org/stable/c/fbba600f432a360b42452fee79d1fb35d3aa8aeb - https://git.kernel.org/stable/c/104074ebc0c3f358dd1ee944fbcde92c6e5a21dd - https://git.kernel.org/stable/c/5e602f5156910c7b19661699896cb6e3fb94fab9
CVE ID: CVE-2022-49222 State: PUBLISHED Published: 2025-02-26T01:55:53.799Z Last Updated: 2025-05-04T08:32:46.609Z Vendors: Linux Products: Linux 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. References: - https://git.kernel.org/stable/c/64c06df2428bb7bb3d8cf5691416001af42d94dd - https://git.kernel.org/stable/c/f0d5d938d51af4eb08d9d8684fd9903425a0a87d - https://git.kernel.org/stable/c/db1c47d299298a7c52ccb201905d6be979fd7507 - https://git.kernel.org/stable/c/d5c6f647aec9ed524aedd04
t.kernel.org/stable/c/db1c47d299298a7c52ccb201905d6be979fd7507 - https://git.kernel.org/stable/c/d5c6f647aec9ed524aedd04a3aec5ebc21d39007
CVE ID: CVE-2022-49223 State: PUBLISHED Published: 2025-02-26T01:55:54.274Z Last Updated: 2025-05-04T08:32:47.808Z Vendors: Linux Products: Linux 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 ffff888119270908 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
/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 e
e 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. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/518bb96367123062b48b0a9842f2864249b565f6 - https://git.kernel.org/stable/c/b0022ca445d5fc4d0c89d15dcd0f855977b22c1d - https://git.kernel.org/stable/c/49f2dab77a5e1354f5da6ccdc9346a8212697be2 - https://git.kernel.org/stable/c/74be98774dfbc5b8b795db726bd772e735d2edd4