Page 4 of 3151 results (0.009 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: crypto: stm32/cryp - call finalize with bh disabled The finalize operation in interrupt mode produce a produces a spinlock recursion warning. The reason is the fact that BH must be disabled during this process. • https://git.kernel.org/stable/c/d93a2f86b0a998aa1f0870c85a2a60a0771ef89a https://git.kernel.org/stable/c/5d734665cd5d93270731e0ff1dd673fec677f447 https://git.kernel.org/stable/c/56ddb9aa3b324c2d9645b5a7343e46010cf3f6ce •

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

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Correct the defined value for AMDGPU_DMUB_NOTIFICATION_MAX [Why & How] It actually exposes '6' types in enum dmub_notification_type. Not 5. Using smaller number to create array dmub_callback & dmub_thread_offload has potential to access item out of array bound. Fix it. • https://git.kernel.org/stable/c/9f404b0bc2df3880758fb3c3bc7496f596f347d7 https://git.kernel.org/stable/c/800a5ab673c4a61ca220cce177386723d91bdb37 https://git.kernel.org/stable/c/c592b6355b9b57b8e59fc5978ce1e14f64488a98 https://git.kernel.org/stable/c/ad28d7c3d989fc5689581664653879d664da76f0 •

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

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Disable DMCUB timeout for DCN35 [Why] DMCUB can intermittently take longer than expected to process commands. Old ASIC policy was to continue while logging a diagnostic error - which works fine for ASIC without IPS, but with IPS this could lead to a race condition where we attempt to access DCN state while it's inaccessible, leading to a system hang when the NIU port is not disabled or register accesses that timeout and the display configuration in an undefined state. [How] We need to investigate why these accesses take longer than expected, but for now we should disable the timeout on DCN35 to avoid this race condition. Since the waits happen only at lower interrupt levels the risk of taking too long at higher IRQ and causing a system watchdog timeout are minimal. • https://git.kernel.org/stable/c/31c254c9cd4b122a10db297124f867107a696d83 https://git.kernel.org/stable/c/7c70e60fbf4bff1123f0e8d5cb1ae71df6164d7f •

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

In the Linux kernel, the following vulnerability has been resolved: fou: fix initialization of grc The grc must be initialize first. There can be a condition where if fou is NULL, goto out will be executed and grc would be used uninitialized. • https://git.kernel.org/stable/c/d7567f098f54cb53ee3cee1c82e3d0ed9698b6b3 https://git.kernel.org/stable/c/1df42be305fe478ded1ee0c1d775f4ece713483b https://git.kernel.org/stable/c/c46cd6aaca81040deaea3500ba75126963294bd9 https://git.kernel.org/stable/c/231c235d2f7a66f018f172e26ffd47c363f244ef https://git.kernel.org/stable/c/4494bccb52ffda22ce5a1163a776d970e6229e08 https://git.kernel.org/stable/c/5d537b8d900514509622ce92330b70d2e581d409 https://git.kernel.org/stable/c/7ae890ee19479eeeb87724cca8430b5cb3660c74 https://git.kernel.org/stable/c/aca06c617c83295f0caa486ad608fbef7 •

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

In the Linux kernel, the following vulnerability has been resolved: usbnet: ipheth: do not stop RX on failing RX callback RX callbacks can fail for multiple reasons: * Payload too short * Payload formatted incorrecly (e.g. bad NCM framing) * Lack of memory None of these should cause the driver to seize up. Make such failures non-critical and continue processing further incoming URBs. • https://git.kernel.org/stable/c/4d1cfa3afb8627435744ecdc6d8b58bc72ee0f4c https://git.kernel.org/stable/c/08ca800b0cd56d5e26722f68b18bbbf6840bf44b https://git.kernel.org/stable/c/74efed51e0a4d62f998f806c307778b47fc73395 •