Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
bl() when error occurs to fix the memory leak. References: - https://git.kernel.org/stable/c/79ce50dddaf28b5c57911ecc80a2be17a0b17f83 - https://git.kernel.org/stable/c/7e647a8d5fc0a2c8e0f36f585a6388286a25bb15 - https://git.kernel.org/stable/c/07ba048df306dc93fc4d2ef670b9e24644a2069f - https://git.kernel.org/stable/c/b4c9f7db9f0148423557539af0fdf513338efe08 - https://git.kernel.org/stable/c/b3236a64ddd125a455ef5b5316c1b9051b732974
CVE ID: CVE-2022-50139 State: PUBLISHED Published: 2025-06-18T11:03:02.318Z Last Updated: 2025-06-18T11:03:02.318Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: aspeed-vhub: Fix refcount leak bug in ast_vhub_init_desc() We should call of_node_put() for the reference returned by of_get_child_by_name() which has increased the refcount. References: - https://git.kernel.org/stable/c/e6db5780c2bf6e23be7b315809ef349b4b4f2213 - https://git.kernel.org/stable/c/4070f3c83cd28267f469a59751480ad39435f26a - https://git.kernel.org/stable/c/0e0a40c803643f4edc30f0660f2f3bea4d57a99a - https://git.kernel.org/stable/c/3503305225ca24c3229414
it.kernel.org/stable/c/0e0a40c803643f4edc30f0660f2f3bea4d57a99a - https://git.kernel.org/stable/c/3503305225ca24c3229414c769323fb8bf39b4bf - https://git.kernel.org/stable/c/220fafb4ed04187e9c17be4152da5a7f2ffbdd8c
CVE ID: CVE-2022-50140 State: PUBLISHED Published: 2025-06-18T11:03:03.027Z Last Updated: 2025-06-18T11:03:03.027Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: memstick/ms_block: Fix a memory leak 'erased_blocks_bitmap' is never freed. As it is allocated at the same time as 'used_blocks_bitmap', it is likely that it should be freed also at the same time. Add the corresponding bitmap_free() in msb_data_clear(). References: - https://git.kernel.org/stable/c/efd675246aec045507b9425c67b548cc2d782d8f - https://git.kernel.org/stable/c/37958980eb4cd71ae594ace093c11b6a91e165e8 - https://git.kernel.org/stable/c/9d8b911fe3c3ed788c66edb
t.kernel.org/stable/c/37958980eb4cd71ae594ace093c11b6a91e165e8 - https://git.kernel.org/stable/c/9d8b911fe3c3ed788c66edba7c90e32a4a7a5f53 - https://git.kernel.org/stable/c/9260a154b3b5e387dbceec7c0ac441470646bc6f - https://git.kernel.org/stable/c/961d7d12080fe70847f944d656e36cd0dd0214ba - https://git.kernel.org/stable/c/16e07966638717416abf45393d6a80a5a1034429 - https://git.kernel.org/stable/c/39be95d1ff7b44c1e969af72ba9da7332dfcc1da - https://git.kernel.org/stable/c/54eb7a55be6779c4d0c25eaf5056498a28595049
CVE ID: CVE-2022-50141 State: PUBLISHED Published: 2025-06-18T11:03:03.704Z Last Updated: 2025-06-18T11:03:03.704Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mmc: sdhci-of-esdhc: Fix refcount leak in esdhc_signal_voltage_switch of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. of_node_put() checks null pointer. References: - https://git.kernel.org/stable/c/a63d5d01e83b984b1b9c7ae8fc9c8c93697a3820 - https://git.kernel.org/stable/c/547db1dd98d1815574ebea7358015a17199a93bc - https://git.kernel.org/
ae8fc9c8c93697a3820 - https://git.kernel.org/stable/c/547db1dd98d1815574ebea7358015a17199a93bc - https://git.kernel.org/stable/c/4c472a2c9ed6ea9d272268d7f484d4303c549f1a - https://git.kernel.org/stable/c/b305475df756256a186623f0991d05a816de881a - https://git.kernel.org/stable/c/352377cf74710bc3368dddf78f17210dfe456933 - https://git.kernel.org/stable/c/b074f1e8060836baeb0ee91181f4194b9a0ee16a - https://git.kernel.org/stable/c/8b902840f6a3584f702bcb59834691b30f3d7c5a - https://git.kernel.org/stable/c/b5899a3e2f783a27b268e38d37f9b24c71bddf45
CVE ID: CVE-2022-50142 State: PUBLISHED Published: 2025-06-18T11:03:04.333Z Last Updated: 2025-06-18T11:03:04.333Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: intel_th: msu: Fix vmalloced buffers After commit f5ff79fddf0e ("dma-mapping: remove CONFIG_DMA_REMAP") there's a chance of DMA buffer getting allocated via vmalloc(), which messes up the mmapping code: > RIP: msc_mmap_fault [intel_th_msu] > Call Trace: > <TASK> > __do_fault > do_fault ... Fix this by accounting for vmalloc possibility. References: - https://git.kernel.org/stable/c/b5d924cb4c7b952eaa61622f14427723a78137a3 - https://git.kernel.org/stable/c/6ae2881c1d1fa
https://git.kernel.org/stable/c/b5d924cb4c7b952eaa61622f14427723a78137a3 - https://git.kernel.org/stable/c/6ae2881c1d1fa0e33f4763b7c786f8ef05a9c828 - https://git.kernel.org/stable/c/566887bad7ff2297d6b3f9659c702ba075f3d62d - https://git.kernel.org/stable/c/0ed72c6bc632cbf8d979ac60f982ff84b7bb610a - https://git.kernel.org/stable/c/4914c50670b6a531e2cb17cd984cc565b4681312 - https://git.kernel.org/stable/c/ac12ad3ccf6d386e64a9d6a890595a2509d24edd
CVE ID: CVE-2022-50143 State: PUBLISHED Published: 2025-06-18T11:03:05.025Z Last Updated: 2025-06-18T11:03:05.025Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: intel_th: Fix a resource leak in an error handling path If an error occurs after calling 'pci_alloc_irq_vectors()', 'pci_free_irq_vectors()' must be called as already done in the remove function. References: - https://git.kernel.org/stable/c/859342220accd0d332864fafbf4e3d2d0492bc3f - https://git.kernel.org/stable/c/a8f3b78b1f8e959d06801ae82149f140a75724e8 - https://git.kernel.org/stable/c/9b5469573a274729bdb04b60a8d71f8d09940a31 - https://git.kernel.org/stable/c/ed4d5e
24e8 - https://git.kernel.org/stable/c/9b5469573a274729bdb04b60a8d71f8d09940a31 - https://git.kernel.org/stable/c/ed4d5ecb7d7fd80336afb2f9ac6685651a6aa32f - https://git.kernel.org/stable/c/fae9da7d4c2ccad3792de03e3cac1fe2bfabb73d - https://git.kernel.org/stable/c/086c28ab7c5699256aced0049aae9c42f1410313
CVE ID: CVE-2022-50144 State: PUBLISHED Published: 2025-06-18T11:03:05.638Z Last Updated: 2025-06-18T11:03:05.638Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: soundwire: revisit driver bind/unbind and callbacks In the SoundWire probe, we store a pointer from the driver ops into the 'slave' structure. This can lead to kernel oopses when unbinding codec drivers, e.g. with the following sequence to remove machine driver and codec driver. /sbin/modprobe -r snd_soc_sof_sdw /sbin/modprobe -r snd_soc_rt711 The full details can be found in the BugLink below, for reference the two following examples show different cases of driver ops
l details can be found in the BugLink below, for reference the two following examples show different cases of driver ops/callbacks being invoked after the driver .remove(). kernel: BUG: kernel NULL pointer dereference, address: 0000000000000150 kernel: Workqueue: events cdns_update_slave_status_work [soundwire_cadence] kernel: RIP: 0010:mutex_lock+0x19/0x30 kernel: Call Trace: kernel: ? sdw_handle_slave_status+0x426/0xe00 [soundwire_bus 94ff184bf398570c3f8ff7efe9e32529f532e4ae] kernel: ? newidle_balance+0x26a/0x400 kernel: ? cdns_update_slave_status_work+0x1e9/0x200 [soundwire_cadence 1bcf98eebe5ba9833cd433323769ac923c9c6f82] kernel: BUG: unable to handle page fault for address: ffffffffc076
ire_cadence 1bcf98eebe5ba9833cd433323769ac923c9c6f82] kernel: BUG: unable to handle page fault for address: ffffffffc07654c8 kernel: Workqueue: pm pm_runtime_work kernel: RIP: 0010:sdw_bus_prep_clk_stop+0x6f/0x160 [soundwire_bus] kernel: Call Trace: kernel: <TASK> kernel: sdw_cdns_clock_stop+0xb5/0x1b0 [soundwire_cadence 1bcf98eebe5ba9833cd433323769ac923c9c6f82] kernel: intel_suspend_runtime+0x5f/0x120 [soundwire_intel aca858f7c87048d3152a4a41bb68abb9b663a1dd] kernel: ? dpm_sysfs_remove+0x60/0x60 This was not detected earlier in Intel tests since the tests first remove the parent PCI device and shut down the bus. The sequence above is a corner case which keeps the bus operational but without
parent PCI device and shut down the bus. The sequence above is a corner case which keeps the bus operational but without a driver bound. While trying to solve this kernel oopses, it became clear that the existing SoundWire bus does not deal well with the unbind case. Commit 528be501b7d4a ("soundwire: sdw_slave: add probe_complete structure and new fields") added a 'probed' status variable and a 'probe_complete' struct completion. This status is however not reset on remove and likewise the 'probe complete' is not re-initialized, so the bind/unbind/bind test cases would fail. The timeout used before the 'update_status' callback was also a bad idea in hindsight, there should really be no timing
The timeout used before the 'update_status' callback was also a bad idea in hindsight, there should really be no timing assumption as to if and when a driver is bound to a device. An initial draft was based on device_lock() and device_unlock() was tested. This proved too complicated, with deadlocks created during the suspend-resume sequences, which also use the same device_lock/unlock() as the bind/unbind sequences. On a CometLake device, a bad DSDT/BIOS caused spurious resumes and the use of device_lock() caused hangs during suspend. After multiple weeks or testing and painful reverse-engineering of deadlocks on different devices, we looked for alternatives that did not interfere with the
inful reverse-engineering of deadlocks on different devices, we looked for alternatives that did not interfere with the device core. A bus notifier was used successfully to keep track of DRIVER_BOUND and DRIVER_UNBIND events. This solved the bind-unbind-bind case in tests, but it can still be defeated with a theoretical corner case where the memory is freed by a .remove while the callback is in use. The notifier only helps make sure the driver callbacks are valid, but not that the memory allocated in probe remains valid while the callbacks are invoked. This patch suggests the introduction of a new 'sdw_dev_lock' mutex protecting probe/remove and all driver callbacks. Since this mutex is 'loc
he introduction of a new 'sdw_dev_lock' mutex protecting probe/remove and all driver callbacks. Since this mutex is 'local' to SoundWire only, it does not interfere with existing locks and does not create deadlocks. In addition, this patch removes the 'probe_complete' completion, instead we directly invoke the 'update_status' from the probe routine. That removes any sort of timing dependency and a much better support for the device/driver model, the driver could be bound before the bus started, or eons after the bus started and the hardware would be properly initialized in all cases. BugLink: https://github.com/thesofproject/linux/is ---truncated--- References: - https://git.kernel.org/stabl
all cases. BugLink: https://github.com/thesofproject/linux/is ---truncated--- References: - https://git.kernel.org/stable/c/250b46505175889c6b5958c3829f610f52199f5f - https://git.kernel.org/stable/c/8fd6b03646b9a9e16d1ec19bd724cd6bd78e0ea5 - https://git.kernel.org/stable/c/432b30f08ca3303d2ebb22352cb04c4b6cfefe65 - https://git.kernel.org/stable/c/bd29c00edd0a5dac8b6e7332bb470cd50f92e893
CVE ID: CVE-2022-50145 State: PUBLISHED Published: 2025-06-18T11:03:06.312Z Last Updated: 2025-06-18T11:03:06.312Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dmaengine: sf-pdma: Add multithread support for a DMA channel When we get a DMA channel and try to use it in multiple threads it will cause oops and hanging the system. % echo 64 > /sys/module/dmatest/parameters/threads_per_chan % echo 10000 > /sys/module/dmatest/parameters/iterations % echo 1 > /sys/module/dmatest/parameters/run [ 89.480664] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0 [ 89.488725] Oops [#1] [ 89.494708] CPU: 2
o handle kernel NULL pointer dereference at virtual address 00000000000000a0 [ 89.488725] Oops [#1] [ 89.494708] CPU: 2 PID: 1008 Comm: dma0chan0-copy0 Not tainted 5.17.0-rc5 [ 89.509385] epc : vchan_find_desc+0x32/0x46 [ 89.513553] ra : sf_pdma_tx_status+0xca/0xd6 This happens because of data race. Each thread rewrite channels's descriptor as soon as device_prep_dma_memcpy() is called. It leads to the situation when the driver thinks that it uses right descriptor that actually is freed or substituted for other one. With current fixes a descriptor changes its value only when it has been used. A new descriptor is acquired from vc->desc_issued queue that is already filled with descriptors that
n it has been used. A new descriptor is acquired from vc->desc_issued queue that is already filled with descriptors that are ready to be sent. Threads have no direct access to DMA channel descriptor. Now it is just possible to queue a descriptor for further processing. References: - https://git.kernel.org/stable/c/b9b4992f897be9b0b9e3a3b956cab6b75ccc3f11 - https://git.kernel.org/stable/c/5ab2782c944e324008ef5d658f2494a9f0e3c5ac - https://git.kernel.org/stable/c/4c7350b1dd8a192af844de32fc99b9e34c876fda - https://git.kernel.org/stable/c/a93b3f1e11971a91b6441b6d47488f4492cc113f - https://git.kernel.org/stable/c/b2cc5c465c2cb8ab697c3fd6583c614e3f6cfbcc
CVE ID: CVE-2022-50146 State: PUBLISHED Published: 2025-06-18T11:03:07.031Z Last Updated: 2025-06-18T11:03:07.031Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: PCI: dwc: Deallocate EPC memory on dw_pcie_ep_init() errors If dw_pcie_ep_init() fails to perform any action after the EPC memory is initialized and the MSI memory region is allocated, the latter parts won't be undone thus causing a memory leak. Add a cleanup-on-error path to fix these leaks. [bhelgaas: commit log] References: - https://git.kernel.org/stable/c/e7599a5974d4c64eaae8009c3f2e47b9e3223e07 - https://git.kernel.org/stable/c/b03a8f1264ea8c363bec9ef6e37b467f27c
/stable/c/e7599a5974d4c64eaae8009c3f2e47b9e3223e07 - https://git.kernel.org/stable/c/b03a8f1264ea8c363bec9ef6e37b467f27cb04ea - https://git.kernel.org/stable/c/2d546db5c80c45cac3ccd929550244fd58f4ff58 - https://git.kernel.org/stable/c/3b453f5d06d1f1d6b20a75ea51dc7b53ae78f479 - https://git.kernel.org/stable/c/8161e9626b50892eaedbd8070ecb1586ecedb109
CVE ID: CVE-2022-50147 State: PUBLISHED Published: 2025-06-18T11:03:07.759Z Last Updated: 2025-06-18T11:03:07.759Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/mempolicy: fix get_nodes out of bound access When user specified more nodes than supported, get_nodes will access nmask array out of bounds. References: - https://git.kernel.org/stable/c/44652154484e7e3d12008802cfb6c28a8aa16d85 - https://git.kernel.org/stable/c/8176f6a0d9c1b06bc7af7c3d6acd4a66448939df - https://git.kernel.org/stable/c/d1b5113674c3e95bb53c601ce2ea4719e851c74d - https://git.kernel.org/stable/c/000eca5d044d1ee23b4ca311793cf3fc528da6c6
CVE ID: CVE-2022-50148 State: PUBLISHED Published: 2025-06-18T11:03:08.462Z Last Updated: 2025-06-18T11:03:08.462Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: kernfs: fix potential NULL dereference in __kernfs_remove When lockdep is enabled, lockdep_assert_held_write would cause potential NULL pointer dereference. Fix the following smatch warnings: fs/kernfs/dir.c:1353 __kernfs_remove() warn: variable dereferenced before check 'kn' (see line 1346) References: - https://git.kernel.org/stable/c/b871986d9d3071f5082664ac274d93f08db257cd - https://git.kernel.org/stable/c/4a9f35b8729c5bf13ea671c908c17ed74c48fc50 - https://git.kern
f5082664ac274d93f08db257cd - https://git.kernel.org/stable/c/4a9f35b8729c5bf13ea671c908c17ed74c48fc50 - https://git.kernel.org/stable/c/72b5d5aef246a0387cefa23121dd90901c7a691a
CVE ID: CVE-2022-50149 State: PUBLISHED Published: 2025-06-18T11:03:09.099Z Last Updated: 2025-06-18T11:03:09.099Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: driver core: fix potential deadlock in __driver_attach In __driver_attach function, There are also AA deadlock problem, like the commit b232b02bf3c2 ("driver core: fix deadlock in __device_attach"). stack like commit b232b02bf3c2 ("driver core: fix deadlock in __device_attach"). list below: In __driver_attach function, The lock holding logic is as follows: ... __driver_attach if (driver_allows_async_probing(drv)) device_lock(dev) // get lock dev async_schedule_dev(__dr
lows: ... __driver_attach if (driver_allows_async_probing(drv)) device_lock(dev) // get lock dev async_schedule_dev(__driver_attach_async_helper, dev); // func async_schedule_node async_schedule_node_domain(func) entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC); /* when fail or work limit, sync to execute func, but __driver_attach_async_helper will get lock dev as will, which will lead to A-A deadlock. */ if (!entry || atomic_read(&entry_count) > MAX_WORK) { func; else queue_work_node(node, system_unbound_wq, &entry->work) device_unlock(dev) As above show, when it is allowed to do async probes, because of out of memory or work limit, async work is not be allowed, to do sync execute in
allowed to do async probes, because of out of memory or work limit, async work is not be allowed, to do sync execute instead. it will lead to A-A deadlock because of __driver_attach_async_helper getting lock dev. Reproduce: and it can be reproduce by make the condition (if (!entry || atomic_read(&entry_count) > MAX_WORK)) untenable, like below: [ 370.785650] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 370.787154] task:swapper/0 state:D stack: 0 pid: 1 ppid: 0 flags:0x00004000 [ 370.788865] Call Trace: [ 370.789374] <TASK> [ 370.789841] __schedule+0x482/0x1050 [ 370.790613] schedule+0x92/0x1a0 [ 370.791290] schedule_preempt_disabled+0x2c/0x50 [ 370.792256] __m
edule+0x482/0x1050 [ 370.790613] schedule+0x92/0x1a0 [ 370.791290] schedule_preempt_disabled+0x2c/0x50 [ 370.792256] __mutex_lock.isra.0+0x757/0xec0 [ 370.793158] __mutex_lock_slowpath+0x1f/0x30 [ 370.794079] mutex_lock+0x50/0x60 [ 370.794795] __device_driver_lock+0x2f/0x70 [ 370.795677] ? driver_probe_device+0xd0/0xd0 [ 370.796576] __driver_attach_async_helper+0x1d/0xd0 [ 370.797318] ? driver_probe_device+0xd0/0xd0 [ 370.797957] async_schedule_node_domain+0xa5/0xc0 [ 370.798652] async_schedule_node+0x19/0x30 [ 370.799243] __driver_attach+0x246/0x290 [ 370.799828] ? driver_allows_async_probing+0xa0/0xa0 [ 370.800548] bus_for_each_dev+0x9d/0x130 [ 370.801132] driver_attach+0x22/0x30 [ 370.801
allows_async_probing+0xa0/0xa0 [ 370.800548] bus_for_each_dev+0x9d/0x130 [ 370.801132] driver_attach+0x22/0x30 [ 370.801666] bus_add_driver+0x290/0x340 [ 370.802246] driver_register+0x88/0x140 [ 370.802817] ? virtio_scsi_init+0x116/0x116 [ 370.803425] scsi_register_driver+0x1a/0x30 [ 370.804057] init_sd+0x184/0x226 [ 370.804533] do_one_initcall+0x71/0x3a0 [ 370.805107] kernel_init_freeable+0x39a/0x43a [ 370.805759] ? rest_init+0x150/0x150 [ 370.806283] kernel_init+0x26/0x230 [ 370.806799] ret_from_fork+0x1f/0x30 To fix the deadlock, move the async_schedule_dev outside device_lock, as we can see, in async_schedule_node_domain, the parameter of queue_work_node is system_unbound_wq, so it can a
e_lock, as we can see, in async_schedule_node_domain, the parameter of queue_work_node is system_unbound_wq, so it can accept concurrent operations. which will also not change the code logic, and will not lead to deadlock. References: - https://git.kernel.org/stable/c/8191b6cd9ada09b675f17446d5872eb1f77685cb - https://git.kernel.org/stable/c/a93f33aeef4e6a94ae9c9d3f5b2f9085ad0572ec - https://git.kernel.org/stable/c/733ab0c19bf17f6ad7c2b580ede006e369d5ab1b - https://git.kernel.org/stable/c/779b634714c51d05baaeff4868ce2fd9fc7399bf - https://git.kernel.org/stable/c/37f908038402c9b8325763f306a1c65d88757e15 - https://git.kernel.org/stable/c/70fe758352cafdee72a7b13bf9db065f9613ced8
CVE ID: CVE-2022-50150 State: REJECTED Published: 2025-06-18T11:03:09.885Z Last Updated: 2025-06-18T13:58:47.027Z Description: No description available.
CVE ID: CVE-2022-50151 State: PUBLISHED Published: 2025-06-18T11:03:10.569Z Last Updated: 2025-06-19T13:10:52.036Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: fix random warning message when driver load Warning log: [ 4.141392] Unexpected gfp: 0x4 (GFP_DMA32). Fixing up to gfp: 0xa20 (GFP_ATOMIC). Fix your code! [ 4.150340] CPU: 1 PID: 175 Comm: 1-0050 Not tainted 5.15.5-00039-g2fd9ae1b568c #20 [ 4.158010] Hardware name: Freescale i.MX8QXP MEK (DT) [ 4.163155] Call trace: [ 4.165600] dump_backtrace+0x0/0x1b0 [ 4.169286] show_stack+0x18/0x68 [ 4.172611] dump_stack_lvl+0x68/0x84 [ 4.176286] dump_stack+0x18/0x34 [ 4
ace+0x0/0x1b0 [ 4.169286] show_stack+0x18/0x68 [ 4.172611] dump_stack_lvl+0x68/0x84 [ 4.176286] dump_stack+0x18/0x34 [ 4.179613] kmalloc_fix_flags+0x60/0x88 [ 4.183550] new_slab+0x334/0x370 [ 4.186878] ___slab_alloc.part.108+0x4d4/0x748 [ 4.191419] __slab_alloc.isra.109+0x30/0x78 [ 4.195702] kmem_cache_alloc+0x40c/0x420 [ 4.199725] dma_pool_alloc+0xac/0x1f8 [ 4.203486] cdns3_allocate_trb_pool+0xb4/0xd0 pool_alloc_page(struct dma_pool *pool, gfp_t mem_flags) { ... page = kmalloc(sizeof(*page), mem_flags); page->vaddr = dma_alloc_coherent(pool->dev, pool->allocation, &page->dma, mem_flags); ... } kmalloc was called with mem_flags, which is passed down in cdns3_allocate_trb_pool() and have GFP_
ma, mem_flags); ... } kmalloc was called with mem_flags, which is passed down in cdns3_allocate_trb_pool() and have GFP_DMA32 flags. kmall_fix_flags() report warning. GFP_DMA32 is not useful at all. dma_alloc_coherent() will handle DMA memory region correctly by pool->dev. GFP_DMA32 can be removed safely. References: - https://git.kernel.org/stable/c/8e142744f0e96abc69ccd99e6d6c7eb662267f21 - https://git.kernel.org/stable/c/960a8a35a6027a08c4b511435bf59609b5d5e5cd - https://git.kernel.org/stable/c/8659ab3d936fcf0084676f98b75b317017aa8f82
CVE ID: CVE-2022-50152 State: PUBLISHED Published: 2025-06-18T11:03:11.233Z Last Updated: 2025-06-18T11:03:11.233Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: ohci-nxp: Fix refcount leak in ohci_hcd_nxp_probe of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. References: - https://git.kernel.org/stable/c/591ab8dbf6c21927f23f83ddb90691f48b86d136 - https://git.kernel.org/stable/c/4db00c2fa6f8c9876a7e20511dccf43b50be9006 - https://git.kernel.org/stable/c/65d36ec409b635dfc2f95f0d7c5877c9d0cb7630 - htt
db00c2fa6f8c9876a7e20511dccf43b50be9006 - https://git.kernel.org/stable/c/65d36ec409b635dfc2f95f0d7c5877c9d0cb7630 - https://git.kernel.org/stable/c/d35903e9650f4fa79426ce390db8678dbf5ac432 - https://git.kernel.org/stable/c/59026d5cc615da28e0c9806a71bf07065c906464 - https://git.kernel.org/stable/c/a0fbac3bf26a11f084233519ddf3fd5e5bb28939 - https://git.kernel.org/stable/c/50238c4b54c2ac6c2da7a84a4a2b0a570e3da0e2 - https://git.kernel.org/stable/c/302970b4cad3ebfda2c05ce06c322ccdc447d17e
CVE ID: CVE-2022-50153 State: PUBLISHED Published: 2025-06-18T11:03:11.877Z Last Updated: 2025-06-18T11:03:11.877Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: host: Fix refcount leak in ehci_hcd_ppc_of_probe of_find_compatible_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. References: - https://git.kernel.org/stable/c/b9c4a480cb0ada07154debf681454cbb55e30b59 - https://git.kernel.org/stable/c/038453b17fe30ea38f0f3c916e2ae2b7f8cef84e - https://git.kernel.org/stable/c/8cbc3870ff356366842af3228dd8e7bc278e5edd - https://g