CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-46698 – video/aperture: optionally match the device in sysfb_disable()
https://notcve.org/view.php?id=CVE-2024-46698
In the Linux kernel, the following vulnerability has been resolved: video/aperture: optionally match the device in sysfb_disable() In aperture_remove_conflicting_pci_devices(), we currently only call sysfb_disable() on vga class devices. This leads to the following problem when the pimary device is not VGA compatible: 1. A PCI device with a non-VGA class is the boot display 2. That device is probed first and it is not a VGA device so sysfb_disable() is not called, but the device resources are freed by aperture_detach_platform_device() 3. Non-primary GPU has a VGA class and it ends up calling sysfb_disable() 4. • https://git.kernel.org/stable/c/5ae3716cfdcd286268133867f67d0803847acefc https://git.kernel.org/stable/c/485ec8f8e1d8ae12aa1daa5ad345ba8940ad2db7 https://git.kernel.org/stable/c/17e78f43de0c6da34204cc858b4cc05671ea9acf https://git.kernel.org/stable/c/b49420d6a1aeb399e5b107fc6eb8584d0860fbd7 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-46697 – nfsd: ensure that nfsd4_fattr_args.context is zeroed out
https://notcve.org/view.php?id=CVE-2024-46697
In the Linux kernel, the following vulnerability has been resolved: nfsd: ensure that nfsd4_fattr_args.context is zeroed out If nfsd4_encode_fattr4 ends up doing a "goto out" before we get to checking for the security label, then args.context will be set to uninitialized junk on the stack, which we'll then try to free. Initialize it early. • https://git.kernel.org/stable/c/f59388a579c6a395de8f7372b267d3abecd8d6bf https://git.kernel.org/stable/c/dd65b324174a64558a16ebbf4c3266e5701185d0 https://git.kernel.org/stable/c/f58bab6fd4063913bd8321e99874b8239e9ba726 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-46696 – nfsd: fix potential UAF in nfsd4_cb_getattr_release
https://notcve.org/view.php?id=CVE-2024-46696
In the Linux kernel, the following vulnerability has been resolved: nfsd: fix potential UAF in nfsd4_cb_getattr_release Once we drop the delegation reference, the fields embedded in it are no longer safe to access. Do that last. • https://git.kernel.org/stable/c/c5967721e1063648b0506481585ba7e2e49a075e https://git.kernel.org/stable/c/e0b66698a5ae41078f7490e8b3527013f5fccd6c https://git.kernel.org/stable/c/1116e0e372eb16dd907ec571ce5d4af325c55c10 •
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: 5EXPL: 0CVE-2024-46694 – drm/amd/display: avoid using null object of framebuffer
https://notcve.org/view.php?id=CVE-2024-46694
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: avoid using null object of framebuffer Instead of using state->fb->obj[0] directly, get object from framebuffer by calling drm_gem_fb_get_obj() and return error code when object is null to avoid using null object of framebuffer. (cherry picked from commit 73dd0ad9e5dad53766ea3e631303430116f834b3) • https://git.kernel.org/stable/c/5d945cbcd4b16a29d6470a80dfb19738f9a4319f https://git.kernel.org/stable/c/c46dda486e4f9b86eeac40aaea65a6f93dc44dad https://git.kernel.org/stable/c/093ee72ed35c2338c87c26b6ba6f0b7789c9e14e https://git.kernel.org/stable/c/f6f5e39a3fe7cbdba190f42b28b40bdff03c8cf0 https://git.kernel.org/stable/c/49e1b214f3239b78967c6ddb8f8ec47ae047b051 https://git.kernel.org/stable/c/3b9a33235c773c7a3768060cf1d2cf8a9153bc37 •