Page 83 of 4099 results (0.022 seconds)

CVSS: -EPSS: 0%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: 0%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: 0%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/231c235d2f7a66f018f172e26ffd47c363f244ef https://git.kernel.org/stable/c/4494bccb52ffda22ce5a1163a776d970e6229e08 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/392f6a97fcbecc64f0c00058b2db5bb0e4b8cc3e https://git.kernel.org/stable/c/16ff0895283058b0f96d4fe277aa25ee096f0ea8 https://git.kernel.org/stable/c/5d537b8d900514509622ce92330b70d2e •

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 •