CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-43829 – drm/qxl: Add check for drm_cvt_mode
https://notcve.org/view.php?id=CVE-2024-43829
In the Linux kernel, the following vulnerability has been resolved: drm/qxl: Add check for drm_cvt_mode Add check for the return value of drm_cvt_mode() and return the error if it fails in order to avoid NULL pointer dereference. • https://git.kernel.org/stable/c/1b043677d4be206c96b51811855502e50057f343 https://git.kernel.org/stable/c/62ef8d7816c8e4a6088275553818b9afc0ffaa03 https://git.kernel.org/stable/c/4e87f592a46bb804d8f833da6ce702ae4b55053f https://git.kernel.org/stable/c/3efe34f95b1ac8c138a46b14ce75956db0d6ee7c https://git.kernel.org/stable/c/f28b353c0c6c7831a70ccca881bf2db5e6785cdd https://git.kernel.org/stable/c/4b1f303bdeceac049e56e4b20eb5280bd9e02f4f https://git.kernel.org/stable/c/d4c57354a06cb4a77998ff8aa40af89eee30e07b https://git.kernel.org/stable/c/7bd09a2db0f617377027a2bb0b9179e69 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-43828 – ext4: fix infinite loop when replaying fast_commit
https://notcve.org/view.php?id=CVE-2024-43828
In the Linux kernel, the following vulnerability has been resolved: ext4: fix infinite loop when replaying fast_commit When doing fast_commit replay an infinite loop may occur due to an uninitialized extent_status struct. ext4_ext_determine_insert_hole() does not detect the replay and calls ext4_es_find_extent_range(), which will return immediately without initializing the 'es' variable. Because 'es' contains garbage, an integer overflow may happen causing an infinite loop in this function, easily reproducible using fstest generic/039. This commit fixes this issue by unconditionally initializing the structure in function ext4_es_find_extent_range(). Thanks to Zhang Yi, for figuring out the real problem! • https://git.kernel.org/stable/c/8016e29f4362e285f0f7e38fadc61a5b7bdfdfa2 https://git.kernel.org/stable/c/5ed0496e383cb6de120e56991385dce70bbb87c1 https://git.kernel.org/stable/c/0619f7750f2b178a1309808832ab20d85e0ad121 https://git.kernel.org/stable/c/181e63cd595c688194e07332f9944b3a63193de2 https://git.kernel.org/stable/c/c6e67df64783e99a657ef2b8c834ba2bf54c539c https://git.kernel.org/stable/c/81f819c537d29932e4b9267f02411cbc8b355178 https://git.kernel.org/stable/c/907c3fe532253a6ef4eb9c4d67efb71fab58c706 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-43824 – PCI: endpoint: pci-epf-test: Make use of cached 'epc_features' in pci_epf_test_core_init()
https://notcve.org/view.php?id=CVE-2024-43824
In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-test: Make use of cached 'epc_features' in pci_epf_test_core_init() Instead of getting the epc_features from pci_epc_get_features() API, use the cached pci_epf_test::epc_features value to avoid the NULL check. Since the NULL check is already performed in pci_epf_test_bind(), having one more check in pci_epf_test_core_init() is redundant and it is not possible to hit the NULL pointer dereference. Also with commit a01e7214bef9 ("PCI: endpoint: Remove "core_init_notifier" flag"), 'epc_features' got dereferenced without the NULL check, leading to the following false positive Smatch warning: drivers/pci/endpoint/functions/pci-epf-test.c:784 pci_epf_test_core_init() error: we previously assumed 'epc_features' could be null (see line 747) Thus, remove the redundant NULL check and also use the epc_features:: {msix_capable/msi_capable} flags directly to avoid local variables. [kwilczynski: commit log] • https://git.kernel.org/stable/c/5e50ee27d4a52a817ab152128c48690ec7c5cdf1 https://git.kernel.org/stable/c/af4ad016abb1632ff7ee598a6037952b495e5b80 https://git.kernel.org/stable/c/5a5095a8bd1bd349cce1c879e5e44407a34dda8a •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-43823 – PCI: keystone: Fix NULL pointer dereference in case of DT error in ks_pcie_setup_rc_app_regs()
https://notcve.org/view.php?id=CVE-2024-43823
In the Linux kernel, the following vulnerability has been resolved: PCI: keystone: Fix NULL pointer dereference in case of DT error in ks_pcie_setup_rc_app_regs() If IORESOURCE_MEM is not provided in Device Tree due to any error, resource_list_first_type() will return NULL and pci_parse_request_of_pci_ranges() will just emit a warning. This will cause a NULL pointer dereference. Fix this bug by adding NULL return check. Found by Linux Verification Center (linuxtesting.org) with SVACE. • https://git.kernel.org/stable/c/0f71c60ffd26943fa9646aa73ad7889ace116ce2 https://git.kernel.org/stable/c/bbba48ad67c53feea05936ea1e029dcca8057506 https://git.kernel.org/stable/c/0a6f1b5fe8ef8268aaa069035639968ceeea0a23 https://git.kernel.org/stable/c/dbcdd1863ba2ec9b76ec131df25d797709e05597 https://git.kernel.org/stable/c/a231707a91f323af1e5d9f1722055ec2fc1c7775 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-43819 – kvm: s390: Reject memory region operations for ucontrol VMs
https://notcve.org/view.php?id=CVE-2024-43819
In the Linux kernel, the following vulnerability has been resolved: kvm: s390: Reject memory region operations for ucontrol VMs This change rejects the KVM_SET_USER_MEMORY_REGION and KVM_SET_USER_MEMORY_REGION2 ioctls when called on a ucontrol VM. This is necessary since ucontrol VMs have kvm->arch.gmap set to 0 and would thus result in a null pointer dereference further in. Memory management needs to be performed in userspace and using the ioctls KVM_S390_UCAS_MAP and KVM_S390_UCAS_UNMAP. Also improve s390 specific documentation for KVM_SET_USER_MEMORY_REGION and KVM_SET_USER_MEMORY_REGION2. [frankja@linux.ibm.com: commit message spelling fix, subject prefix fix] • https://git.kernel.org/stable/c/27e0393f15fc8bc855c6a888387ff5ffd2181089 https://git.kernel.org/stable/c/49c9945c054df4c22008e2bf87ca74d3e2507aa6 https://git.kernel.org/stable/c/7816e58967d0e6cadce05c8540b47ed027dc2499 •