Page 118 of 5051 results (0.008 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: drm/lima: fix shared irq handling on driver remove lima uses a shared interrupt, so the interrupt handlers must be prepared to be called at any time. At driver removal time, the clocks are disabled early and the interrupts stay registered until the very end of the remove process due to the devm usage. This is potentially a bug as the interrupts access device registers which assumes clocks are enabled. A crash can be triggered by removing the driver in a kernel with CONFIG_DEBUG_SHIRQ enabled. This patch frees the interrupts at each lima device finishing callback so that the handlers are already unregistered by the time we fully disable clocks. • https://git.kernel.org/stable/c/0d60c43df59ef01c08dc7b0c45495178f9d05a13 https://git.kernel.org/stable/c/25d0d9b83d855cbc5d5aa5ae3cd79d55ea0c84a8 https://git.kernel.org/stable/c/17fe8b75aaf0bb1bdc31368963446b421c22d0af https://git.kernel.org/stable/c/0a487e977cb8897ae4c51ecd34bbaa2b005266c9 https://git.kernel.org/stable/c/04d531b9a1875846d4f89953b469ad463aa7a770 https://git.kernel.org/stable/c/b5daf9217a50636a969bc1965f827878aeb09ffe https://git.kernel.org/stable/c/a6683c690bbfd1f371510cb051e8fa49507f3f5e •

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

In the Linux kernel, the following vulnerability has been resolved: powerpc: Avoid nmi_enter/nmi_exit in real mode interrupt. nmi_enter()/nmi_exit() touches per cpu variables which can lead to kernel crash when invoked during real mode interrupt handling (e.g. early HMI/MCE interrupt handler) if percpu allocation comes from vmalloc area. Early HMI/MCE handlers are called through DEFINE_INTERRUPT_HANDLER_NMI() wrapper which invokes nmi_enter/nmi_exit calls. We don't see any issue when percpu allocation is from the embedded first chunk. However with CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK enabled there are chances where percpu allocation can come from the vmalloc area. With kernel command line "percpu_alloc=page" we can force percpu allocation to come from vmalloc area and can see kernel crash in machine_check_early: [ 1.215714] NIP [c000000000e49eb4] rcu_nmi_enter+0x24/0x110 [ 1.215717] LR [c0000000000461a0] machine_check_early+0xf0/0x2c0 [ 1.215719] --- interrupt: 200 [ 1.215720] [c000000fffd73180] [0000000000000000] 0x0 (unreliable) [ 1.215722] [c000000fffd731b0] [0000000000000000] 0x0 [ 1.215724] [c000000fffd73210] [c000000000008364] machine_check_early_common+0x134/0x1f8 Fix this by avoiding use of nmi_enter()/nmi_exit() in real mode if percpu first chunk is not embedded. • https://git.kernel.org/stable/c/fb6675db04c4b79883373edc578d5df7bbc84848 https://git.kernel.org/stable/c/e2afb26615adf6c3ceaaa7732aa839bcd587a057 https://git.kernel.org/stable/c/8d3f83dfb23674540c827a8d65fba20aa300b252 https://git.kernel.org/stable/c/0f37946c62c48a907625348cbc720a7a0c547d1e https://git.kernel.org/stable/c/2c78c9411e685dbc9eac8c2845111b03501975b8 https://git.kernel.org/stable/c/0db880fc865ffb522141ced4bfa66c12ab1fbb70 •

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

In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: fw: scan offload prohibit all 6 GHz channel if no 6 GHz sband We have some policy via BIOS to block uses of 6 GHz. In this case, 6 GHz sband will be NULL even if it is WiFi 7 chip. So, add NULL handling here to avoid crash. • https://git.kernel.org/stable/c/ce4ba62f8bc5195a9a0d49c6235a9c99e619cadc https://git.kernel.org/stable/c/bb38626f3f97e16e6d368a9ff6daf320f3fe31d9 https://access.redhat.com/security/cve/CVE-2024-42125 https://bugzilla.redhat.com/show_bug.cgi?id=2301490 • CWE-476: NULL Pointer Dereference •

CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: scsi: qedf: Make qedf_execute_tmf() non-preemptible Stop calling smp_processor_id() from preemptible code in qedf_execute_tmf90. This results in BUG_ON() when running an RT kernel. [ 659.343280] BUG: using smp_processor_id() in preemptible [00000000] code: sg_reset/3646 [ 659.343282] caller is qedf_execute_tmf+0x8b/0x360 [qedf] • https://git.kernel.org/stable/c/4f314aadeed8cdf42c8cf30769425b5e44702748 https://git.kernel.org/stable/c/5ceb40cdee721e13cbe15a0515cacf984e11236b https://git.kernel.org/stable/c/0a8a91932b2772e75bf3f6d133ca4225d1d3e920 https://git.kernel.org/stable/c/fa49c65a1cec6a3901ef884fdb24d98068b63493 https://git.kernel.org/stable/c/b6ded5316ec56e973dcf5f9997945aad01a9f062 https://git.kernel.org/stable/c/2b9c7787cfcd1e76d873a78f16cf45bfa4b100ea https://git.kernel.org/stable/c/0d8b637c9c5eeaa1a4e3dfb336f3ff918eb64fec https://access.redhat.com/security/cve/CVE-2024-42124 • CWE-372: Incomplete Internal State Distinction •

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

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix double free err_addr pointer warnings In amdgpu_umc_bad_page_polling_timeout, the amdgpu_umc_handle_bad_pages will be run many times so that double free err_addr in some special case. So set the err_addr to NULL to avoid the warnings. A vulnerability was found in the amdgpu_umc_handle_bad_pages() function in the Linux kernel's amdgpu driver. If the function is called multiple times in quick succession, a double free error can occur because the err_data->err_addr pointer that is being freed is not being set to NULL in between calls. This could lead to memory corruption or crashes. • https://git.kernel.org/stable/c/8e24beb3c2b08a4763f920399a9cc577ed440a1a https://git.kernel.org/stable/c/506c245f3f1cd989cb89811a7f06e04ff8813a0d https://access.redhat.com/security/cve/CVE-2024-42123 https://bugzilla.redhat.com/show_bug.cgi?id=2301488 • CWE-415: Double Free •