Page 200 of 3866 results (0.008 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: libceph: fix race between delayed_work() and ceph_monc_stop() The way the delayed work is handled in ceph_monc_stop() is prone to races with mon_fault() and possibly also finish_hunting(). Both of these can requeue the delayed work which wouldn't be canceled by any of the following code in case that happens after cancel_delayed_work_sync() runs -- __close_session() doesn't mess with the delayed work in order to avoid interfering with the hunting interval logic. This part was missed in commit b5d91704f53e ("libceph: behave in mon_fault() if cur_mon < 0") and use-after-free can still ensue on monc and objects that hang off of it, with monc->auth and monc->monmap being particularly susceptible to quickly being reused. To fix this: - clear monc->cur_mon and monc->hunting as part of closing the session in ceph_monc_stop() - bail from delayed_work() if monc->cur_mon is cleared, similar to how it's done in mon_fault() and finish_hunting() (based on monc->hunting) - call cancel_delayed_work_sync() after the session is closed • https://git.kernel.org/stable/c/1177afeca833174ba83504688eec898c6214f4bf https://git.kernel.org/stable/c/63e5d035e3a7ab7412a008f202633c5e6a0a28ea https://git.kernel.org/stable/c/34b76d1922e41da1fa73d43b764cddd82ac9733c https://git.kernel.org/stable/c/20cf67dcb7db842f941eff1af6ee5e9dc41796d7 https://git.kernel.org/stable/c/2d33654d40a05afd91ab24c9a73ab512a0670a9a https://git.kernel.org/stable/c/9525af1f58f67df387768770fcf6d6a8f23aee3d https://git.kernel.org/stable/c/33d38c5da17f8db2d80e811b7829d2822c10625e https://git.kernel.org/stable/c/69c7b2fe4c9cc1d3b1186d1c5606627ec •

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

In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: fix calc_available_free_space() for zoned mode calc_available_free_space() returns the total size of metadata (or system) block groups, which can be allocated from unallocated disk space. The logic is wrong on zoned mode in two places. First, the calculation of data_chunk_size is wrong. We always allocate one zone as one chunk, and no partial allocation of a zone. So, we should use zone_size (= data_sinfo->chunk_size) as it is. Second, the result "avail" may not be zone aligned. Since we always allocate one zone as one chunk on zoned mode, returning non-zone size aligned bytes will result in less pressure on the async metadata reclaim process. This is serious for the nearly full state with a large zone size device. Allowing over-commit too much will result in less async reclaim work and end up in ENOSPC. • https://git.kernel.org/stable/c/cb6cbab79055ca207ad88bc54226b48ececdcef0 https://git.kernel.org/stable/c/8548903b1999bba02a2b894ad750ab8eb1f40307 https://git.kernel.org/stable/c/64d2c847ba380e07b9072d65a50aa6469d2aa43f •

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

In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Fix scv instruction crash with kexec kexec on pseries disables AIL (reloc_on_exc), required for scv instruction support, before other CPUs have been shut down. This means they can execute scv instructions after AIL is disabled, which causes an interrupt at an unexpected entry location that crashes the kernel. Change the kexec sequence to disable AIL after other CPUs have been brought down. As a refresher, the real-mode scv interrupt vector is 0x17000, and the fixed-location head code probably couldn't easily deal with implementing such high addresses so it was just decided not to support that interrupt at all. • https://git.kernel.org/stable/c/7fa95f9adaee7e5cbb195d3359741120829e488b https://git.kernel.org/stable/c/c550679d604798d9fed8a5b2bb5693448a25407c https://git.kernel.org/stable/c/d10e3c39001e9194b9a1bfd6979bd3fa19dccdc5 https://git.kernel.org/stable/c/8c6506616386ce37e59b2745fc481c6713fae4f3 https://git.kernel.org/stable/c/21a741eb75f80397e5f7d3739e24d7d75e619011 •

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

In the Linux kernel, the following vulnerability has been resolved: crypto: aead,cipher - zeroize key buffer after use I.G 9.7.B for FIPS 140-3 specifies that variables temporarily holding cryptographic information should be zeroized once they are no longer needed. Accomplish this by using kfree_sensitive for buffers that previously held the private key. • https://git.kernel.org/stable/c/9db8c299a521813630fcb4154298cb60c37f3133 https://git.kernel.org/stable/c/71dd428615375e36523f4d4f7685ddd54113646d https://git.kernel.org/stable/c/28c8d274848feba552e95c5c2a7e3cfe8f15c534 https://git.kernel.org/stable/c/b502d4a08875ea2b4ea5d5b28dc7c991c8b90cfb https://git.kernel.org/stable/c/f58679996a831754a356974376f248aa0af2eb8e https://git.kernel.org/stable/c/23e4099bdc3c8381992f9eb975c79196d6755210 •

CVSS: 6.3EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc Initialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001. V2: To really improve the handling we would actually need to have a separate value of 0xffffffff.(Christian) A vulnerability was found in the Linux kernel's amdgpu driver in the amdgpu_vce_ring_parse_cs() function where the size variable is initialized with a pointer that may not be properly set before use. This issue could lead to unpredictable behavior in the system. • https://git.kernel.org/stable/c/d35cf41c8eb5d9fe95b21ae6ee2910f9ba4878e8 https://git.kernel.org/stable/c/3b505759447637dcccb50cbd98ec6f8d2a04fc46 https://git.kernel.org/stable/c/df02642c21c984303fe34c3f7d72965792fb1a15 https://git.kernel.org/stable/c/da6a85d197888067e8d38b5d22c986b5b5cab712 https://git.kernel.org/stable/c/9ee1534ecdd5b4c013064663502d7fde824d2144 https://git.kernel.org/stable/c/855ae72c20310e5402b2317fc537d911e87537ef https://git.kernel.org/stable/c/f8f120b3de48b8b6bdf8988a9b334c2d61c17440 https://git.kernel.org/stable/c/88a9a467c548d0b3c7761b4fd54a68e70 • CWE-457: Use of Uninitialized Variable •