Page 21 of 6301 results (0.011 seconds)

CVSS: -EPSS: 0%CPEs: 2EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Disable preemption while updating GPU stats We forgot to disable preemption around the write_seqcount_begin/end() pair while updating GPU stats: [ ] WARNING: CPU: 2 PID: 12 at include/linux/seqlock.h:221 __seqprop_assert.isra.0+0x128/0x150 [v3d] [ ] Workqueue: v3d_bin drm_sched_run_job_work [gpu_sched] <...snip...> [ ] Call trace: [ ] __seqprop_assert.isra.0+0x128/0x150 [v3d] [ ] v3d_job_start_stats.isra.0+0x90/0x218 [v3d] [ ] v3d_bin_job_run+0x23c/0x388 [v3d] [ ] drm_sched_run_job_work+0x520/0x6d0 [gpu_sched] [ ] process_one_work+0x62c/0xb48 [ ] worker_thread+0x468/0x5b0 [ ] kthread+0x1c4/0x1e0 [ ] ret_from_fork+0x10/0x20 Fix it. • https://git.kernel.org/stable/c/6abe93b621ab12e93cf0eb7e42a609b36be32da1 https://git.kernel.org/stable/c/1e93467ef20308da5a94cde548ee17d523e8ba7b https://git.kernel.org/stable/c/9d824c7fce58f59982228aa85b0376b113cdfa35 •

CVSS: -EPSS: 0%CPEs: 3EXPL: 0

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: 0

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: 0

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: 3EXPL: 0

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/459584258d47ec3cc6245a82e8a49c9d08eb8b57 https://git.kernel.org/stable/c/f71ec019257ba4f7ab198bd948c5902a207bad96 https://git.kernel.org/stable/c/76a0e79bc84f466999fa501fce5bf7a07641b8a7 •