CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-46707 – KVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3
https://notcve.org/view.php?id=CVE-2024-46707
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3 On a system with a GICv3, if a guest hasn't been configured with GICv3 and that the host is not capable of GICv2 emulation, a write to any of the ICC_*SGI*_EL1 registers is trapped to EL2. We therefore try to emulate the SGI access, only to hit a NULL pointer as no private interrupt is allocated (no GIC, remember?). The obvious fix is to give the guest what it deserves, in the shape of a UNDEF exception. • https://git.kernel.org/stable/c/15818af2f7aa55eff375333cb7689df15d3f24ef https://git.kernel.org/stable/c/96b076e8ee5bc3a1126848c8add0f74bd30dc9d1 https://git.kernel.org/stable/c/94d4fbad01b19ec5eab3d6b50aaec4f9db8b2d8d https://git.kernel.org/stable/c/9d7629bec5c3f80bd0e3bf8103c06a2f7046bd92 https://git.kernel.org/stable/c/2073132f6ed3079369e857a8deb33d11bdd983bc https://git.kernel.org/stable/c/3e6245ebe7ef341639e9a7e402b3ade8ad45a19f •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-46705 – drm/xe: reset mmio mappings with devm
https://notcve.org/view.php?id=CVE-2024-46705
In the Linux kernel, the following vulnerability has been resolved: drm/xe: reset mmio mappings with devm Set our various mmio mappings to NULL. This should make it easier to catch something rogue trying to mess with mmio after device removal. For example, we might unmap everything and then start hitting some mmio address which has already been unmamped by us and then remapped by something else, causing all kinds of carnage. • https://git.kernel.org/stable/c/b1c9fbed3884d3883021d699c7cdf5253a65543a https://git.kernel.org/stable/c/c7117419784f612d59ee565145f722e8b5541fe6 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-46702 – thunderbolt: Mark XDomain as unplugged when router is removed
https://notcve.org/view.php?id=CVE-2024-46702
In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Mark XDomain as unplugged when router is removed I noticed that when we do discrete host router NVM upgrade and it gets hot-removed from the PCIe side as a result of NVM firmware authentication, if there is another host connected with enabled paths we hang in tearing them down. This is due to fact that the Thunderbolt networking driver also tries to cleanup the paths and ends up blocking in tb_disconnect_xdomain_paths() waiting for the domain lock. However, at this point we already cleaned the paths in tb_stop() so there is really no need for tb_disconnect_xdomain_paths() to do that anymore. Furthermore it already checks if the XDomain is unplugged and bails out early so take advantage of that and mark the XDomain as unplugged when we remove the parent router. • https://git.kernel.org/stable/c/747bc154577de6e6af4bc99abfa859b8419bb4d8 https://git.kernel.org/stable/c/23ce6ba3b95488a2b9e9f6d43b340da0c15395dc https://git.kernel.org/stable/c/80ac8d194831eca0c2f4fd862f7925532fda320c https://git.kernel.org/stable/c/18b3ad2a3cc877dd4b16f48d84aa27b78d53bf1d https://git.kernel.org/stable/c/7ca24cf9163c112bb6b580c6fb57c04a1f8b76e1 https://git.kernel.org/stable/c/e2006140ad2e01a02ed0aff49cc2ae3ceeb11f8d •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-46695 – selinux,smack: don't bypass permissions check in inode_setsecctx hook
https://notcve.org/view.php?id=CVE-2024-46695
In the Linux kernel, the following vulnerability has been resolved: selinux,smack: don't bypass permissions check in inode_setsecctx hook Marek Gresko reports that the root user on an NFS client is able to change the security labels on files on an NFS filesystem that is exported with root squashing enabled. The end of the kerneldoc comment for __vfs_setxattr_noperm() states: * This function requires the caller to lock the inode's i_mutex before it * is executed. It also assumes that the caller will make the appropriate * permission checks. nfsd_setattr() does do permissions checking via fh_verify() and nfsd_permission(), but those don't do all the same permissions checks that are done by security_inode_setxattr() and its related LSM hooks do. Since nfsd_setattr() is the only consumer of security_inode_setsecctx(), simplest solution appears to be to replace the call to __vfs_setxattr_noperm() with a call to __vfs_setxattr_locked(). This fixes the above issue and has the added benefit of causing nfsd to recall conflicting delegations on a file when a client tries to change its security label. • https://git.kernel.org/stable/c/2dbc4b7bac60b02cc6e70d05bf6a7dfd551f9dda https://git.kernel.org/stable/c/fe0cd53791119f6287b6532af8ce41576d664930 https://git.kernel.org/stable/c/eebec98791d0137e455cc006411bb92a54250924 https://git.kernel.org/stable/c/459584258d47ec3cc6245a82e8a49c9d08eb8b57 https://git.kernel.org/stable/c/f71ec019257ba4f7ab198bd948c5902a207bad96 https://git.kernel.org/stable/c/76a0e79bc84f466999fa501fce5bf7a07641b8a7 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-46689 – soc: qcom: cmd-db: Map shared memory as WC, not WB
https://notcve.org/view.php?id=CVE-2024-46689
In the Linux kernel, the following vulnerability has been resolved: soc: qcom: cmd-db: Map shared memory as WC, not WB Linux does not write into cmd-db region. This region of memory is write protected by XPU. XPU may sometime falsely detect clean cache eviction as "write" into the write protected region leading to secure interrupt which causes an endless loop somewhere in Trust Zone. The only reason it is working right now is because Qualcomm Hypervisor maps the same region as Non-Cacheable memory in Stage 2 translation tables. The issue manifests if we want to use another hypervisor (like Xen or KVM), which does not know anything about those specific mappings. Changing the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WC removes dependency on correct mappings in Stage 2 tables. This patch fixes the issue by updating the mapping to MEMREMAP_WC. I tested this on SA8155P with Xen. • https://git.kernel.org/stable/c/312416d9171a1460b7ed8d182b5b540c910ce80d https://git.kernel.org/stable/c/0ee9594c974368a17e85a431e9fe1c14fb65c278 https://git.kernel.org/stable/c/f5a5a5a0e95f36e2792d48e6e4b64e665eb01374 https://git.kernel.org/stable/c/eaff392c1e34fb77cc61505a31b0191e5e46e271 https://git.kernel.org/stable/c/d9d48d70e922b272875cda60d2ada89291c840cf https://git.kernel.org/stable/c/ef80520be0ff78ae5ed44cb6eee1525e65bebe70 https://git.kernel.org/stable/c/62c2d63605ca25b5db78a347ed303c0a0a77d5b4 https://git.kernel.org/stable/c/f9bb896eab221618927ae6a2f1d566567 •