Page 276 of 2647 results (0.009 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: powerpc/64s: Fix crashes when toggling entry flush barrier The entry flush mitigation can be enabled/disabled at runtime via a debugfs file (entry_flush), which causes the kernel to patch itself to enable/disable the relevant mitigations. However depending on which mitigation we're using, it may not be safe to do that patching while other CPUs are active. For example the following crash: sleeper[15639]: segfault (11) at c000000000004c20 nip c000000000004c20 lr c000000000004c20 Shows that we returned to userspace with a corrupted LR that points into the kernel, due to executing the partially patched call to the fallback entry flush (ie. we missed the LR restore). Fix it by doing the patching under stop machine. The CPUs that aren't doing the patching will be spinning in the core of the stop machine logic. That is currently sufficient for our purposes, because none of the patching we do is to that code or anywhere in the vicinity. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: powerpc/64s: soluciona fallas al alternar la barrera de descarga de entrada. • https://git.kernel.org/stable/c/4a1e90af718d1489ffcecc8f52486c4f5dc0f7a6 https://git.kernel.org/stable/c/fa4bf9f38184ed7ca4916eb64f8c767d1e279c1f https://git.kernel.org/stable/c/db01cad9efe3c3838a6b3a3f68affd295c4b92d6 https://git.kernel.org/stable/c/f69bb4e51f41973fb7594be1479fa689831efe1a https://git.kernel.org/stable/c/b65458b6be8032c5179d4f562038575d7b3a6be3 https://git.kernel.org/stable/c/f79643787e0a0762d2409b7b8334e83f22d85695 https://git.kernel.org/stable/c/e590b36718d6e740b7b19514f710402a6499164c https://git.kernel.org/stable/c/8382b15864e5014261b4f36c2aa897236 •

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

In the Linux kernel, the following vulnerability has been resolved: userfaultfd: release page in error path to avoid BUG_ON Consider the following sequence of events: 1. Userspace issues a UFFD ioctl, which ends up calling into shmem_mfill_atomic_pte(). We successfully account the blocks, we shmem_alloc_page(), but then the copy_from_user() fails. We return -ENOENT. We don't release the page we allocated. 2. • https://git.kernel.org/stable/c/cb658a453b9327ce96ce5222c24d162b5b65b564 https://git.kernel.org/stable/c/319116227e52d49eee671f0aa278bac89b3c1b69 https://git.kernel.org/stable/c/07c9b834c97d0fa3402fb7f3f3b32df370a6ff1f https://git.kernel.org/stable/c/b3f1731c6d7fbc1ebe3ed8eff6d6bec56d76ff43 https://git.kernel.org/stable/c/140cfd9980124aecb6c03ef2e69c72d0548744de https://git.kernel.org/stable/c/ad53127973034c63b5348715a1043d0e80ceb330 https://git.kernel.org/stable/c/2d59a0ed8b26b8f3638d8afc31f839e27759f1f6 https://git.kernel.org/stable/c/7ed9d238c7dbb1fdb63ad96a618498515 •

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

In the Linux kernel, the following vulnerability has been resolved: ACPI: scan: Fix a memory leak in an error handling path If 'acpi_device_set_name()' fails, we must free 'acpi_device_bus_id->bus_id' or there is a (potential) memory leak. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ACPI: scan: Corregir pérdida de memoria en una ruta de manejo de errores Si falla 'acpi_device_set_name()' debemos liberar 'acpi_device_bus_id->bus_id' o hay una (potencial) memoria filtración. • https://git.kernel.org/stable/c/e5cdbe419004e172f642e876a671a9ff1c52f8bb https://git.kernel.org/stable/c/717d9d88fbd956ab03fad97266f6ce63a036e7f8 https://git.kernel.org/stable/c/7385e438e1f31af5b86f72fd19b0dcd2738502c9 https://git.kernel.org/stable/c/bc0b1a2036dd8072106ec81a8685ecb901f72ed6 https://git.kernel.org/stable/c/4a5891992c680d69d7e490e4d0428d17779d8e85 https://git.kernel.org/stable/c/321dbe6c0b551f9f8030becc6900f77cf9bbb9ad https://git.kernel.org/stable/c/eb50aaf960e3bedfef79063411ffd670da94b84b https://git.kernel.org/stable/c/6901a4f795e0e8d65ae779cb37fc22e0b •

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

In the Linux kernel, the following vulnerability has been resolved: nbd: Fix NULL pointer in flush_workqueue Open /dev/nbdX first, the config_refs will be 1 and the pointers in nbd_device are still null. Disconnect /dev/nbdX, then reference a null recv_workq. The protection by config_refs in nbd_genl_disconnect is useless. [ 656.366194] BUG: kernel NULL pointer dereference, address: 0000000000000020 [ 656.368943] #PF: supervisor write access in kernel mode [ 656.369844] #PF: error_code(0x0002) - not-present page [ 656.370717] PGD 10cc87067 P4D 10cc87067 PUD 1074b4067 PMD 0 [ 656.371693] Oops: 0002 [#1] SMP [ 656.372242] CPU: 5 PID: 7977 Comm: nbd-client Not tainted 5.11.0-rc5-00040-g76c057c84d28 #1 [ 656.373661] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ 656.375904] RIP: 0010:mutex_lock+0x29/0x60 [ 656.376627] Code: 00 0f 1f 44 00 00 55 48 89 fd 48 83 05 6f d7 fe 08 01 e8 7a c3 ff ff 48 83 05 6a d7 fe 08 01 31 c0 65 48 8b 14 25 00 6d 01 00 <f0> 48 0f b1 55 d [ 656.378934] RSP: 0018:ffffc900005eb9b0 EFLAGS: 00010246 [ 656.379350] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 656.379915] RDX: ffff888104cf2600 RSI: ffffffffaae8f452 RDI: 0000000000000020 [ 656.380473] RBP: 0000000000000020 R08: 0000000000000000 R09: ffff88813bd6b318 [ 656.381039] R10: 00000000000000c7 R11: fefefefefefefeff R12: ffff888102710b40 [ 656.381599] R13: ffffc900005eb9e0 R14: ffffffffb2930680 R15: ffff88810770ef00 [ 656.382166] FS: 00007fdf117ebb40(0000) GS:ffff88813bd40000(0000) knlGS:0000000000000000 [ 656.382806] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 656.383261] CR2: 0000000000000020 CR3: 0000000100c84000 CR4: 00000000000006e0 [ 656.383819] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 656.384370] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 656.384927] Call Trace: [ 656.385111] flush_workqueue+0x92/0x6c0 [ 656.385395] nbd_disconnect_and_put+0x81/0xd0 [ 656.385716] nbd_genl_disconnect+0x125/0x2a0 [ 656.386034] genl_family_rcv_msg_doit.isra.0+0x102/0x1b0 [ 656.386422] genl_rcv_msg+0xfc/0x2b0 [ 656.386685] ? nbd_ioctl+0x490/0x490 [ 656.386954] ? • https://git.kernel.org/stable/c/e9e006f5fcf2bab59149cb38a48a4817c1b538b4 https://git.kernel.org/stable/c/0b584bf573ae59021069c056c22d65d5721910cb https://git.kernel.org/stable/c/d1db913b044f0a0693d8ee283d26b81d536efcd5 https://git.kernel.org/stable/c/9f0f39c92e4f50189155dfb13bb5524372e40eba https://git.kernel.org/stable/c/e83a26a49356a3dbd4f54102abe17fc594643698 https://git.kernel.org/stable/c/92ec11cccb7fc14331e000ab2337f60aa433433e https://git.kernel.org/stable/c/b3ead320dce6c7d7206103deca766b317591c286 https://git.kernel.org/stable/c/1c4962df938891af9ab4775f5224ef860 •

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

In the Linux kernel, the following vulnerability has been resolved: i2c: cadence: fix reference leak when pm_runtime_get_sync fails The PM reference count is not expected to be incremented on return in functions cdns_i2c_master_xfer and cdns_reg_slave. However, pm_runtime_get_sync will increment pm usage counter even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: i2c: cadencia: corrige la fuga de referencia cuando falla pm_runtime_get_sync No se espera que el recuento de referencias de PM aumente al regresar en las funciones cdns_i2c_master_xfer y cdns_reg_slave. Sin embargo, pm_runtime_get_sync incrementará el contador de uso de pm incluso si falla. Olvidarse de poner en funcionamiento resultará en una fuga de referencia aquí. • https://git.kernel.org/stable/c/7fa32329ca03148fb2c07b4ef3247b8fc0488d6a https://git.kernel.org/stable/c/30410519328c94367e561fd878e5f0d3a0303585 https://git.kernel.org/stable/c/d57ff04e0ed6f3be1682ae861ead33f879225e07 https://git.kernel.org/stable/c/a45fc41beed8e0fe31864619c34aa00797fb60c1 https://git.kernel.org/stable/c/23ceb8462dc6f4b4decdb5536a7e5fc477cdf0b6 •