Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
e pointed by priv_req, but priv_req is used in the following list_del_init(). This patch move list_del_init() before cdns3_gadget_ep_free_request(). References: - https://git.kernel.org/stable/c/e65d9b7147d7be3504893ca7dfb85286bda83d40 - https://git.kernel.org/stable/c/6d7ac60098b206d0472475b666cb09d556bec03d - https://git.kernel.org/stable/c/c3c1dbad3a2db32ecf371c97f2058491b8ba0f9a - https://git.kernel.org/stable/c/6fd50446e7c9a98b4bcf96815f5c9602a16ea472 - https://git.kernel.org/stable/c/7d602f30149a117eea260208b1661bc404c21dfd
CVE ID: CVE-2022-50035 State: PUBLISHED Published: 2025-06-18T11:01:37.123Z Last Updated: 2025-06-18T11:01:37.123Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix use-after-free on amdgpu_bo_list mutex If amdgpu_cs_vm_handling returns r != 0, then it will unlock the bo_list_mutex inside the function amdgpu_cs_vm_handling and again on amdgpu_cs_parser_fini. This problem results in the following use-after-free problem: [ 220.280990] ------------[ cut here ]------------ [ 220.281000] refcount_t: underflow; use-after-free. [ 220.281019] WARNING: CPU: 1 PID: 3746 at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110
derflow; use-after-free. [ 220.281019] WARNING: CPU: 1 PID: 3746 at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110 [ 220.281029] ------------[ cut here ]------------ [ 220.281415] CPU: 1 PID: 3746 Comm: chrome:cs0 Tainted: G W L ------- --- 5.20.0-0.rc0.20220812git7ebfc85e2cd7.10.fc38.x86_64 #1 [ 220.281421] Hardware name: System manufacturer System Product Name/ROG STRIX X570-I GAMING, BIOS 4403 04/27/2022 [ 220.281426] RIP: 0010:refcount_warn_saturate+0xba/0x110 [ 220.281431] Code: 01 01 e8 79 4a 6f 00 0f 0b e9 42 47 a5 00 80 3d de 7e be 01 00 75 85 48 c7 c7 f8 98 8e 98 c6 05 ce 7e be 01 01 e8 56 4a 6f 00 <0f> 0b e9 1f 47 a5 00 80 3d b9 7e be 01 00 0f 85 5e ff ff ff 48 c7 [ 220.281437
98 c6 05 ce 7e be 01 01 e8 56 4a 6f 00 <0f> 0b e9 1f 47 a5 00 80 3d b9 7e be 01 00 0f 85 5e ff ff ff 48 c7 [ 220.281437] RSP: 0018:ffffb4b0d18d7a80 EFLAGS: 00010282 [ 220.281443] RAX: 0000000000000026 RBX: 0000000000000003 RCX: 0000000000000000 [ 220.281448] RDX: 0000000000000001 RSI: ffffffff988d06dc RDI: 00000000ffffffff [ 220.281452] RBP: 00000000ffffffff R08: 0000000000000000 R09: ffffb4b0d18d7930 [ 220.281457] R10: 0000000000000003 R11: ffffa0672e2fffe8 R12: ffffa058ca360400 [ 220.281461] R13: ffffa05846c50a18 R14: 00000000fffffe00 R15: 0000000000000003 [ 220.281465] FS: 00007f82683e06c0(0000) GS:ffffa066e2e00000(0000) knlGS:0000000000000000 [ 220.281470] CS: 0010 DS: 0000 ES: 0000 CR0
FS: 00007f82683e06c0(0000) GS:ffffa066e2e00000(0000) knlGS:0000000000000000 [ 220.281470] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 220.281475] CR2: 00003590005cc000 CR3: 00000001fca46000 CR4: 0000000000350ee0 [ 220.281480] Call Trace: [ 220.281485] <TASK> [ 220.281490] amdgpu_cs_ioctl+0x4e2/0x2070 [amdgpu] [ 220.281806] ? amdgpu_cs_find_mapping+0xe0/0xe0 [amdgpu] [ 220.282028] drm_ioctl_kernel+0xa4/0x150 [ 220.282043] drm_ioctl+0x21f/0x420 [ 220.282053] ? amdgpu_cs_find_mapping+0xe0/0xe0 [amdgpu] [ 220.282275] ? lock_release+0x14f/0x460 [ 220.282282] ? _raw_spin_unlock_irqrestore+0x30/0x60 [ 220.282290] ? _raw_spin_unlock_irqrestore+0x30/0x60 [ 220.282297] ? lockdep_hardirqs_on+0x7
nlock_irqrestore+0x30/0x60 [ 220.282290] ? _raw_spin_unlock_irqrestore+0x30/0x60 [ 220.282297] ? lockdep_hardirqs_on+0x7d/0x100 [ 220.282305] ? _raw_spin_unlock_irqrestore+0x40/0x60 [ 220.282317] amdgpu_drm_ioctl+0x4a/0x80 [amdgpu] [ 220.282534] __x64_sys_ioctl+0x90/0xd0 [ 220.282545] do_syscall_64+0x5b/0x80 [ 220.282551] ? futex_wake+0x6c/0x150 [ 220.282568] ? lock_is_held_type+0xe8/0x140 [ 220.282580] ? do_syscall_64+0x67/0x80 [ 220.282585] ? lockdep_hardirqs_on+0x7d/0x100 [ 220.282592] ? do_syscall_64+0x67/0x80 [ 220.282597] ? do_syscall_64+0x67/0x80 [ 220.282602] ? lockdep_hardirqs_on+0x7d/0x100 [ 220.282609] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 220.282616] RIP: 0033:0x7f8282a4f8bf
dep_hardirqs_on+0x7d/0x100 [ 220.282609] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 220.282616] RIP: 0033:0x7f8282a4f8bf [ 220.282639] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 18 48 8b 44 24 18 64 48 2b 04 25 28 00 00 [ 220.282644] RSP: 002b:00007f82683df410 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 220.282651] RAX: ffffffffffffffda RBX: 00007f82683df588 RCX: 00007f8282a4f8bf [ 220.282655] RDX: 00007f82683df4d0 RSI: 00000000c0186444 RDI: 0000000000000018 [ 220.282659] RBP: 00007f82683df4d0 R08: 00007f82683df5e0 R09: 00007f82683df4b0 [ 220.282663] R10: 00001d04000a0600 R11:
[ 220.282659] RBP: 00007f82683df4d0 R08: 00007f82683df5e0 R09: 00007f82683df4b0 [ 220.282663] R10: 00001d04000a0600 R11: 0000000000000246 R12: 00000000c0186444 [ 220.282667] R13: 0000000000000018 R14: 00007f82683df588 R15: 0000000000000003 [ 220.282689] </TASK> [ 220.282693] irq event stamp: 6232311 [ 220.282697] hardirqs last enabled at (6232319): [<ffffffff9718cd7e>] __up_console_sem+0x5e/0x70 [ 220.282704] hardirqs last disabled at (6232326): [<ffffffff9718cd63>] __up_console_sem+0x43/0x70 [ 220.282709] softirqs last enabled at (6232072): [<ffffffff970ff669>] __irq_exit_rcu+0xf9/0x170 [ 220.282716] softirqs last disabled at (6232061): [<ffffffff97 ---truncated--- References: - https://git
rcu+0xf9/0x170 [ 220.282716] softirqs last disabled at (6232061): [<ffffffff97 ---truncated--- References: - https://git.kernel.org/stable/c/1b38e3b423f0bb41ee6abae5ca9deec1546ba227 - https://git.kernel.org/stable/c/bbca24d0a3c11193bafb9e174f89f52a379006e3
CVE ID: CVE-2022-50036 State: PUBLISHED Published: 2025-06-18T11:01:37.844Z Last Updated: 2025-06-18T11:01:37.844Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/sun4i: dsi: Prevent underflow when computing packet sizes Currently, the packet overhead is subtracted using unsigned arithmetic. With a short sync pulse, this could underflow and wrap around to near the maximal u16 value. Fix this by using signed subtraction. The call to max() will correctly handle any negative numbers that are produced. Apply the same fix to the other timings, even though those subtractions are less likely to underflow. References: - https://git.
e same fix to the other timings, even though those subtractions are less likely to underflow. References: - https://git.kernel.org/stable/c/a1e7908f78f5a7f53f8cd83c7dcdfec974c95f26 - https://git.kernel.org/stable/c/98e28de472ef248352f04f87e29e634ebb0ec240 - https://git.kernel.org/stable/c/fb837f5b83461624e525727a8f4add14b201147e - https://git.kernel.org/stable/c/82a1356a933d8443139f8886f11b63c974a09a67
CVE ID: CVE-2022-50037 State: PUBLISHED Published: 2025-06-18T11:01:38.534Z Last Updated: 2025-06-18T11:01:38.534Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/i915/ttm: don't leak the ccs state The kernel only manages the ccs state with lmem-only objects, however the kernel should still take care not to leak the CCS state from the previous user. (cherry picked from commit 353819d85f87be46aeb9c1dd929d445a006fc6ec) References: - https://git.kernel.org/stable/c/b431cffb4883b9e90d48f0c408674c50fef428a5 - https://git.kernel.org/stable/c/232d150fa15606e96c0e01e5c7a2d4e03f621787
CVE ID: CVE-2022-50038 State: PUBLISHED Published: 2025-06-18T11:01:39.487Z Last Updated: 2025-06-18T11:01:39.487Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/meson: Fix refcount bugs in meson_vpu_has_available_connectors() In this function, there are two refcount leak bugs: (1) when breaking out of for_each_endpoint_of_node(), we need call the of_node_put() for the 'ep'; (2) we should call of_node_put() for the reference returned by of_graph_get_remote_port() when it is not used anymore. References: - https://git.kernel.org/stable/c/6a758f0ba11699837af9e1a0f7cbac6ef765a23e - https://git.kernel.org/stable/c/fc1fc2abfcb92
https://git.kernel.org/stable/c/6a758f0ba11699837af9e1a0f7cbac6ef765a23e - https://git.kernel.org/stable/c/fc1fc2abfcb9235d0ece9a4d858426fb617cfa66 - https://git.kernel.org/stable/c/d58ef256781398ad115aef44de0a02ad27ea6c3a - https://git.kernel.org/stable/c/3aa710e96747c8b4e52ba12ffe09edcb2755897c - https://git.kernel.org/stable/c/fe71d84c1a6c0d54657431e8eeaefc9d24895304 - https://git.kernel.org/stable/c/8dec38e19f6928235d4009ce55f7add8af34e5c7 - https://git.kernel.org/stable/c/91b3c8dbe898df158fd2a84675f3a284ff6666f7
CVE ID: CVE-2022-50039 State: PUBLISHED Published: 2025-06-18T11:01:40.500Z Last Updated: 2025-06-18T11:01:40.500Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: stmmac: intel: Add a missing clk_disable_unprepare() call in intel_eth_pci_remove() Commit 09f012e64e4b ("stmmac: intel: Fix clock handling on error and remove paths") removed this clk_disable_unprepare() This was partly revert by commit ac322f86b56c ("net: stmmac: Fix clock handling on remove path") which removed this clk_disable_unprepare() because: " While unloading the dwmac-intel driver, clk_disable_unprepare() is being called twice in stmmac_dvr_remove() and inte
" While unloading the dwmac-intel driver, clk_disable_unprepare() is being called twice in stmmac_dvr_remove() and intel_eth_pci_remove(). This causes kernel panic on the second call. " However later on, commit 5ec55823438e8 ("net: stmmac: add clocks management for gmac driver") has updated stmmac_dvr_remove() which do not call clk_disable_unprepare() anymore. So this call should now be called from intel_eth_pci_remove(). References: - https://git.kernel.org/stable/c/02f3642d8e657c05f382729c165bed46745dc18c - https://git.kernel.org/stable/c/47129531196054b374017555165b47a43cdb6f41 - https://git.kernel.org/stable/c/9400aeb419d35e718e90aa14a97c11229d0a40bc - https://git.kernel.org/stable/c/5c
3cdb6f41 - https://git.kernel.org/stable/c/9400aeb419d35e718e90aa14a97c11229d0a40bc - https://git.kernel.org/stable/c/5c23d6b717e4e956376f3852b90f58e262946b50
CVE ID: CVE-2022-50040 State: PUBLISHED Published: 2025-06-18T11:01:41.420Z Last Updated: 2025-06-18T11:01:41.420Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: dsa: sja1105: fix buffer overflow in sja1105_setup_devlink_regions() If an error occurs in dsa_devlink_region_create(), then 'priv->regions' array will be accessed by negative index '-1'. Found by Linux Verification Center (linuxtesting.org) with SVACE. References: - https://git.kernel.org/stable/c/7983e1e44cb322eba6af84160b6d18df80603fb8 - https://git.kernel.org/stable/c/e84c6321f3578c38cb3c24258db91a92672b17a8 - https://git.kernel.org/stable/c/79f86b862416126a2e
://git.kernel.org/stable/c/e84c6321f3578c38cb3c24258db91a92672b17a8 - https://git.kernel.org/stable/c/79f86b862416126a2e826cb74224180d6625a32f - https://git.kernel.org/stable/c/fd8e899cdb5ecaf8e8ee73854a99e10807eef1de
CVE ID: CVE-2022-50041 State: PUBLISHED Published: 2025-06-18T11:01:42.544Z Last Updated: 2025-06-18T11:01:42.544Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ice: Fix call trace with null VSI during VF reset During stress test with attaching and detaching VF from KVM and simultaneously changing VFs spoofcheck and trust there was a call trace in ice_reset_vf that VF's VSI is null. [145237.352797] WARNING: CPU: 46 PID: 840629 at drivers/net/ethernet/intel/ice/ice_vf_lib.c:508 ice_reset_vf+0x3d6/0x410 [ice] [145237.352851] Modules linked in: ice(E) vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio iavf dm_mod xt_CHECKSU
145237.352851] Modules linked in: ice(E) vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio iavf dm_mod xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink tun bridge stp llc sunrpc intel_rapl_msr intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm iTCO_wdt iTC O_vendor_support irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel rapl ipmi_si intel_cstate ipmi_devintf joydev intel_uncore m ei_me ipmi_msghandler i2c_i801 pcspkr mei lpc_ich ioatdma i2c_smbus acpi_pad acpi_power_meter ip_tables xfs libcrc32c i2c_algo_bit drm_sh mem_helper dr
pcspkr mei lpc_ich ioatdma i2c_smbus acpi_pad acpi_power_meter ip_tables xfs libcrc32c i2c_algo_bit drm_sh mem_helper drm_kms_helper sd_mod t10_pi crc64_rocksoft syscopyarea crc64 sysfillrect sg sysimgblt fb_sys_fops drm i40e ixgbe ahci libahci libata crc32c_intel mdio dca wmi fuse [last unloaded: ice] [145237.352917] CPU: 46 PID: 840629 Comm: kworker/46:2 Tainted: G S W I E 5.19.0-rc6+ #24 [145237.352921] Hardware name: Intel Corporation S2600WTT/S2600WTT, BIOS SE5C610.86B.01.01.0008.021120151325 02/11/2015 [145237.352923] Workqueue: ice ice_service_task [ice] [145237.352948] RIP: 0010:ice_reset_vf+0x3d6/0x410 [ice] [145237.352984] Code: 30 ec f3 cc e9 28 fd ff ff 0f b7 4b 50 48 c7 c2 48 19
48] RIP: 0010:ice_reset_vf+0x3d6/0x410 [ice] [145237.352984] Code: 30 ec f3 cc e9 28 fd ff ff 0f b7 4b 50 48 c7 c2 48 19 9c c0 4c 89 ee 48 c7 c7 30 fe 9e c0 e8 d1 21 9d cc 31 c0 e9 a 9 fe ff ff <0f> 0b b8 ea ff ff ff e9 c1 fc ff ff 0f 0b b8 fb ff ff ff e9 91 fe [145237.352987] RSP: 0018:ffffb453e257fdb8 EFLAGS: 00010246 [145237.352990] RAX: ffff8bd0040181c0 RBX: ffff8be68db8f800 RCX: 0000000000000000 [145237.352991] RDX: 000000000000ffff RSI: 0000000000000000 RDI: ffff8be68db8f800 [145237.352993] RBP: ffff8bd0040181c0 R08: 0000000000001000 R09: ffff8bcfd520e000 [145237.352995] R10: 0000000000000000 R11: 00008417b5ab0bc0 R12: 0000000000000005 [145237.352996] R13: ffff8bcee061c0d0 R14: ffff8bd
95] R10: 0000000000000000 R11: 00008417b5ab0bc0 R12: 0000000000000005 [145237.352996] R13: ffff8bcee061c0d0 R14: ffff8bd004019640 R15: 0000000000000000 [145237.352998] FS: 0000000000000000(0000) GS:ffff8be5dfb00000(0000) knlGS:0000000000000000 [145237.353000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [145237.353002] CR2: 00007fd81f651d68 CR3: 0000001a0fe10001 CR4: 00000000001726e0 [145237.353003] Call Trace: [145237.353008] <TASK> [145237.353011] ice_process_vflr_event+0x8d/0xb0 [ice] [145237.353049] ice_service_task+0x79f/0xef0 [ice] [145237.353074] process_one_work+0x1c8/0x390 [145237.353081] ? process_one_work+0x390/0x390 [145237.353084] worker_thread+0x30/0x360 [145237.353087] ? p
+0x1c8/0x390 [145237.353081] ? process_one_work+0x390/0x390 [145237.353084] worker_thread+0x30/0x360 [145237.353087] ? process_one_work+0x390/0x390 [145237.353090] kthread+0xe8/0x110 [145237.353094] ? kthread_complete_and_exit+0x20/0x20 [145237.353097] ret_from_fork+0x22/0x30 [145237.353103] </TASK> Remove WARN_ON() from check if VSI is null in ice_reset_vf. Add "VF is already removed\n" in dev_dbg(). This WARN_ON() is unnecessary and causes call trace, despite that call trace, driver still works. There is no need for this warn because this piece of code is responsible for disabling VF's Tx/Rx queues when VF is disabled, but when VF is already removed there is no need to do reset or disable
disabling VF's Tx/Rx queues when VF is disabled, but when VF is already removed there is no need to do reset or disable queues. References: - https://git.kernel.org/stable/c/af1b0d1547dd1686ae842cac7f3678649a5cbd89 - https://git.kernel.org/stable/c/cf90b74341eecc32ceef0c136954a1668e43b1e7
CVE ID: CVE-2022-50042 State: PUBLISHED Published: 2025-06-18T11:01:43.264Z Last Updated: 2025-06-18T11:01:43.264Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: genl: fix error path memory leak in policy dumping If construction of the array of policies fails when recording non-first policy we need to unwind. netlink_policy_dump_add_policy() itself also needs fixing as it currently gives up on error without recording the allocated pointer in the pstate pointer. References: - https://git.kernel.org/stable/c/83411c9f05d5a8b637293b3389eca3d378197c04 - https://git.kernel.org/stable/c/b0672895d8be5d19d4b05ac83f807026fc791037 -
c/83411c9f05d5a8b637293b3389eca3d378197c04 - https://git.kernel.org/stable/c/b0672895d8be5d19d4b05ac83f807026fc791037 - https://git.kernel.org/stable/c/26b6acd365823e99e46be3b27500f5dc235dda5e - https://git.kernel.org/stable/c/249801360db3dec4f73768c502192020bfddeacc
CVE ID: CVE-2022-50043 State: PUBLISHED Published: 2025-06-18T11:01:44.186Z Last Updated: 2025-06-18T11:01:44.186Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: fix potential refcount leak in ndisc_router_discovery() The issue happens on specific paths in the function. After both the object `rt` and `neigh` are grabbed successfully, when `lifetime` is nonzero but the metric needs change, the function just deletes the route and set `rt` to NULL. Then, it may try grabbing `rt` and `neigh` again if above conditions hold. The function simply overwrite `neigh` if succeeds or returns if fails, without decreasing the reference c
nditions hold. The function simply overwrite `neigh` if succeeds or returns if fails, without decreasing the reference count of previous `neigh`. This may result in memory leaks. Fix it by decrementing the reference count of `neigh` in place. References: - https://git.kernel.org/stable/c/ffb15594433391fd7885eb88ce5a7f7bdeefbb15 - https://git.kernel.org/stable/c/7998043d31d000c3a93f46182e6569dd0eecda34 - https://git.kernel.org/stable/c/7396ba87f1edf549284869451665c7c4e74ecd4f
CVE ID: CVE-2022-50044 State: PUBLISHED Published: 2025-06-18T11:01:45.296Z Last Updated: 2025-06-18T11:01:45.296Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: qrtr: start MHI channel after endpoit creation MHI channel may generates event/interrupt right after enabling. It may leads to 2 race conditions issues. 1) Such event may be dropped by qcom_mhi_qrtr_dl_callback() at check: if (!qdev || mhi_res->transaction_status) return; Because dev_set_drvdata(&mhi_dev->dev, qdev) may be not performed at this moment. In this situation qrtr-ns will be unable to enumerate services in device. ---------------------------------------
oment. In this situation qrtr-ns will be unable to enumerate services in device. --------------------------------------------------------------- 2) Such event may come at the moment after dev_set_drvdata() and before qrtr_endpoint_register(). In this case kernel will panic with accessing wrong pointer at qcom_mhi_qrtr_dl_callback(): rc = qrtr_endpoint_post(&qdev->ep, mhi_res->buf_addr, mhi_res->bytes_xferd); Because endpoint is not created yet. -------------------------------------------------------------- So move mhi_prepare_for_transfer_autoqueue after endpoint creation to fix it. References: - https://git.kernel.org/stable/c/c682fb70a7dfc25b848a4ff3a385b0471b470606 - https://git.kernel.or
o fix it. References: - https://git.kernel.org/stable/c/c682fb70a7dfc25b848a4ff3a385b0471b470606 - https://git.kernel.org/stable/c/a1a75f78a2937567946b1b756f82462874b5ca20 - https://git.kernel.org/stable/c/68a838b84effb7b57ba7d50b1863fc6ae35a54ce
CVE ID: CVE-2022-50045 State: PUBLISHED Published: 2025-06-18T11:01:46.233Z Last Updated: 2025-06-18T11:01:46.233Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: powerpc/pci: Fix get_phb_number() locking The recent change to get_phb_number() causes a DEBUG_ATOMIC_SLEEP warning on some systems: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 1 lock held by swapper/1: #0: c157efb0 (hose_spinlock){+.+.}-{2:2}, at: pcibios_alloc_controller+0x64/0x220 Preemption disable
held by swapper/1: #0: c157efb0 (hose_spinlock){+.+.}-{2:2}, at: pcibios_alloc_controller+0x64/0x220 Preemption disabled at: [<00000000>] 0x0 CPU: 0 PID: 1 Comm: swapper Not tainted 5.19.0-yocto-standard+ #1 Call Trace: [d101dc90] [c073b264] dump_stack_lvl+0x50/0x8c (unreliable) [d101dcb0] [c0093b70] __might_resched+0x258/0x2a8 [d101dcd0] [c0d3e634] __mutex_lock+0x6c/0x6ec [d101dd50] [c0a84174] of_alias_get_id+0x50/0xf4 [d101dd80] [c002ec78] pcibios_alloc_controller+0x1b8/0x220 [d101ddd0] [c140c9dc] pmac_pci_init+0x198/0x784 [d101de50] [c140852c] discover_phbs+0x30/0x4c [d101de60] [c0007fd4] do_one_initcall+0x94/0x344 [d101ded0] [c1403b40] kernel_init_freeable+0x1a8/0x22c [d101df10] [c00086
101de60] [c0007fd4] do_one_initcall+0x94/0x344 [d101ded0] [c1403b40] kernel_init_freeable+0x1a8/0x22c [d101df10] [c00086e0] kernel_init+0x34/0x160 [d101df30] [c001b334] ret_from_kernel_thread+0x5c/0x64 This is because pcibios_alloc_controller() holds hose_spinlock but of_alias_get_id() takes of_mutex which can sleep. The hose_spinlock protects the phb_bitmap, and also the hose_list, but it doesn't need to be held while get_phb_number() calls the OF routines, because those are only looking up information in the device tree. So fix it by having get_phb_number() take the hose_spinlock itself, only where required, and then dropping the lock before returning. pcibios_alloc_controller() then needs
spinlock itself, only where required, and then dropping the lock before returning. pcibios_alloc_controller() then needs to take the lock again before the list_add() but that's safe, the order of the list is not important. References: - https://git.kernel.org/stable/c/6f75057c21eab12c6ccb7f06f859641a6edfab99 - https://git.kernel.org/stable/c/5db5ce0f1963c6c8275719a80cb65e9c98d32726 - https://git.kernel.org/stable/c/ccb0a42d3f40c436295e0fef57ab613ae5b925a4 - https://git.kernel.org/stable/c/a868f771ee41c97a25a04b8c632a7f06689b307b - https://git.kernel.org/stable/c/1d9e75c3d8cdf7c96a94cb77450d4ee070279e6a - https://git.kernel.org/stable/c/90f195c01a2e8d8da6281791617e21109719c981 - https://git.k
df7c96a94cb77450d4ee070279e6a - https://git.kernel.org/stable/c/90f195c01a2e8d8da6281791617e21109719c981 - https://git.kernel.org/stable/c/8d48562a2729742f767b0fdd994d6b2a56a49c63
CVE ID: CVE-2022-50046 State: PUBLISHED Published: 2025-06-18T11:01:47.155Z Last Updated: 2025-06-18T11:01:47.155Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net/sunrpc: fix potential memory leaks in rpc_sysfs_xprt_state_change() The issue happens on some error handling paths. When the function fails to grab the object `xprt`, it simply returns 0, forgetting to decrease the reference count of another object `xps`, which is increased by rpc_sysfs_xprt_kobj_get_xprt_switch(), causing refcount leaks. Also, the function forgets to check whether `xps` is valid before using it, which may result in NULL-dereferencing issues. Fix i
e function forgets to check whether `xps` is valid before using it, which may result in NULL-dereferencing issues. Fix it by adding proper error handling code when either `xprt` or `xps` is NULL. References: - https://git.kernel.org/stable/c/c0434f0e058648649250b8ed6078b66d773de723 - https://git.kernel.org/stable/c/76fbeb1662b1c56514325118a07fba74dc4c79fe - https://git.kernel.org/stable/c/bfc48f1b0505ffcb03a6d749139b7577d6b81ae0
CVE ID: CVE-2022-50047 State: PUBLISHED Published: 2025-06-18T11:01:48.080Z Last Updated: 2025-06-18T11:01:48.080Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6060: prevent crash on an unused port If the port isn't a CPU port nor a user port, 'cpu_dp' is a null pointer and a crash happened on dereferencing it in mv88e6060_setup_port(): [ 9.575872] Unable to handle kernel NULL pointer dereference at virtual address 00000014 ... [ 9.942216] mv88e6060_setup from dsa_register_switch+0x814/0xe84 [ 9.948616] dsa_register_switch from mdio_probe+0x2c/0x54 [ 9.954433] mdio_probe from really_probe.part.0+0x98/0x2a0 [ 9.