Page 692 of 4633 results (0.027 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: Fix TPM reservation for seal/unseal The original patch 8c657a0590de ("KEYS: trusted: Reserve TPM for seal and unseal operations") was correct on the mailing list: https://lore.kernel.org/linux-integrity/20210128235621.127925-4-jarkko@kernel.org/ But somehow got rebased so that the tpm_try_get_ops() in tpm2_seal_trusted() got lost. This causes an imbalanced put of the TPM ops and causes oopses on TIS based hardware. This fix puts back the lost tpm_try_get_ops() En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KEYS: de confianza: corrige la reserva de TPM para sellar/dessellar El parche original 8c657a0590de ("KEYS: de confianza: reservar TPM para operaciones de sellar y dessellar") era correcto en la lista de correo: https ://lore.kernel.org/linux-integrity/20210128235621.127925-4-jarkko@kernel.org/ Pero de alguna manera se modificó la base para que tpm_try_get_ops() en tpm2_seal_trusted() se perdiera. Esto provoca un desequilibrio en las operaciones de TPM y provoca fallos en el hardware basado en TIS. Esta solución devuelve el tpm_try_get_ops() perdido • https://git.kernel.org/stable/c/67118bb78d72aab5b831f054a74ae856339a1974 https://git.kernel.org/stable/c/498b8fc1cdc13b57b02dd28544b18323900fae10 https://git.kernel.org/stable/c/bf84ef2dd2ccdcd8f2658476d34b51455f970ce4 https://git.kernel.org/stable/c/39c8d760d44cb3fa0d67e8cd505df81cf4d80999 https://git.kernel.org/stable/c/9d5171eab462a63e2fbebfccf6026e92be018f20 •

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

In the Linux kernel, the following vulnerability has been resolved: locking/qrwlock: Fix ordering in queued_write_lock_slowpath() While this code is executed with the wait_lock held, a reader can acquire the lock without holding wait_lock. The writer side loops checking the value with the atomic_cond_read_acquire(), but only truly acquires the lock when the compare-and-exchange is completed successfully which isn’t ordered. This exposes the window between the acquire and the cmpxchg to an A-B-A problem which allows reads following the lock acquisition to observe values speculatively before the write lock is truly acquired. We've seen a problem in epoll where the reader does a xchg while holding the read lock, but the writer can see a value change out from under it. Writer | Reader -------------------------------------------------------------------------------- ep_scan_ready_list() | |- write_lock_irq() | |- queued_write_lock_slowpath() | |- atomic_cond_read_acquire() | | read_lock_irqsave(&ep->lock, flags); --> (observes value before unlock) | chain_epi_lockless() | | epi->next = xchg(&ep->ovflist, epi); | | read_unlock_irqrestore(&ep->lock, flags); | | | atomic_cmpxchg_relaxed() | |-- READ_ONCE(ep->ovflist); | A core can order the read of the ovflist ahead of the atomic_cmpxchg_relaxed(). Switching the cmpxchg to use acquire semantics addresses this issue at which point the atomic_cond_read can be switched to use relaxed semantics. [peterz: use try_cmpxchg()] En el kernel de Linux, se resolvió la siguiente vulnerabilidad: lock/qrwlock: corrige el orden en queued_write_lock_slowpath() Mientras este código se ejecuta con wait_lock retenido, un lector puede adquirir el bloqueo sin mantener wait_lock. El lado del escritor realiza un bucle para verificar el valor con atomic_cond_read_acquire(), pero solo adquiere realmente el bloqueo cuando la comparación e intercambio se completa con éxito, lo cual no está ordenado. • https://git.kernel.org/stable/c/b519b56e378ee82caf9b079b04f5db87dedc3251 https://git.kernel.org/stable/c/5902f9453a313be8fe78cbd7e7ca9dba9319fc6e https://git.kernel.org/stable/c/82808cc026811fbc3ecf0c0b267a12a339eead56 https://git.kernel.org/stable/c/82fa9ced35d88581cffa4a1c856fc41fca96d80a https://git.kernel.org/stable/c/d558fcdb17139728347bccc60a16af3e639649d2 https://git.kernel.org/stable/c/84a24bf8c52e66b7ac89ada5e3cfbe72d65c1896 • CWE-668: Exposure of Resource to Wrong Sphere •

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

In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Fix clobbering of SWERR overflow bit on writeback Current code blindly writes over the SWERR and the OVERFLOW bits. Write back the bits actually read instead so the driver avoids clobbering the OVERFLOW bit that comes after the register is read. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dmaengine: idxd: corrige el problema del bit de desbordamiento SWERR en la reescritura El código actual escribe ciegamente sobre los bits SWERR y OVERFLOW. En su lugar, vuelva a escribir los bits realmente leídos para que el controlador evite dañar el bit OVERFLOW que viene después de leer el registro. • https://git.kernel.org/stable/c/bfe1d56091c1a404b3d4ce7e9809d745fc4453bb https://git.kernel.org/stable/c/a5ad12d5d69c63af289a37f05187a0c6fe93553d https://git.kernel.org/stable/c/02981a44a0e402089775416371bd2e0c935685f8 https://git.kernel.org/stable/c/ea941ac294d75d0ace50797aebf0056f6f8f7a7f •

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

In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: fix wq size store permission state WQ size can only be changed when the device is disabled. Current code allows change when device is enabled but wq is disabled. Change the check to detect device state. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dmaengine: idxd: corregir el tamaño de wq estado del permiso de almacenamiento El tamaño de WQ solo se puede cambiar cuando el dispositivo está deshabilitado. El código actual permite cambios cuando el dispositivo está habilitado pero wq está deshabilitado. • https://git.kernel.org/stable/c/c52ca478233c172b2d322b5241d6279a8661cbba https://git.kernel.org/stable/c/4ecf25595273203010bc8318c4aee60ad64037ae https://git.kernel.org/stable/c/05b7791c4c4aa8304368fdc55ae911f6b34e7281 https://git.kernel.org/stable/c/0fff71c5a311e1264988179f7dcc217fda15fadd •

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

In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: clear MSIX permission entry on shutdown Add disabling/clearing of MSIX permission entries on device shutdown to mirror the enabling of the MSIX entries on probe. Current code left the MSIX enabled and the pasid entries still programmed at device shutdown. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dmaengine: idxd: borrar entrada de permiso MSIX al apagar Agregue la desactivación/borrado de entradas de permiso MSIX al apagar el dispositivo para reflejar la habilitación de las entradas MSIX en la sonda. El código actual dejó el MSIX habilitado y las entradas pasivas aún programadas al apagar el dispositivo. • https://git.kernel.org/stable/c/8e50d392652f20616a136165dff516b86baf5e49 https://git.kernel.org/stable/c/c84b8982d7aa9b4717dc36a1c6cbc93ee153b500 https://git.kernel.org/stable/c/6df0e6c57dfc064af330071f372f11aa8c584997 •