Page 512 of 3342 results (0.011 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: NFC: st21nfca: Fix memory leak in device probe and remove 'phy->pending_skb' is alloced when device probe, but forgot to free in the error handling path and remove path, this cause memory leak as follows: unreferenced object 0xffff88800bc06800 (size 512): comm "8", pid 11775, jiffies 4295159829 (age 9.032s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000d66c09ce>] __kmalloc_node_track_caller+0x1ed/0x450 [<00000000c93382b3>] kmalloc_reserve+0x37/0xd0 [<000000005fea522c>] __alloc_skb+0x124/0x380 [<0000000019f29f9a>] st21nfca_hci_i2c_probe+0x170/0x8f2 Fix it by freeing 'pending_skb' in error and remove. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: NFC: st21nfca: corrige la pérdida de memoria en la sonda del dispositivo y elimina 'phy-&gt;pending_skb' cuando se asigna la sonda del dispositivo, pero olvidó liberarla en la ruta de manejo de errores y eliminar la ruta, esto causa pérdida de memoria de la siguiente manera: objeto sin referencia 0xffff88800bc06800 (tamaño 512): comunicación "8", pid 11775, santiago 4295159829 (edad 9.032 s) volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................. backtrace: [&lt;00000000d66c09ce&gt;] __kmalloc_node_track_caller+0x1ed/0x450 [&lt;00000000c93382b3&gt;] kmalloc_reserve+0x37/0xd0 [&lt;000000005fea522c&gt;] __alloc_skb+0x124/0x380 [ &lt;0000000019f29f9a&gt;] st21nfca_hci_i2c_probe+0x170/0x8f2 Solucionarlo liberando 'pending_skb' por error y elimínelo. • https://git.kernel.org/stable/c/68957303f44a501af5cf37913208a2acaa6bcdf1 https://git.kernel.org/stable/c/38c3e320e7ff46f2dc67bc5045333e63d9f8918d https://git.kernel.org/stable/c/a1e0080a35a16ce3808f7040fe0c3a8fdb052349 https://git.kernel.org/stable/c/1cd4063dbc91cf7965d73a6a3855e2028cd4613b https://git.kernel.org/stable/c/e553265ea56482da5700f56319fda9ff53e7dcb4 https://git.kernel.org/stable/c/238920381b8925d070d32d73cd9ce52ab29896fe https://git.kernel.org/stable/c/1b9dadba502234eea7244879b8d5d126bfaf9f0c • CWE-401: Missing Release of Memory after Effective Lifetime •

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

In the Linux kernel, the following vulnerability has been resolved: fs/mount_setattr: always cleanup mount_kattr Make sure that finish_mount_kattr() is called after mount_kattr was succesfully built in both the success and failure case to prevent leaking any references we took when we built it. We returned early if path lookup failed thereby risking to leak an additional reference we took when building mount_kattr when an idmapped mount was requested. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/mount_setattr: limpiar siempre mount_kattr. Asegúrese de que se llame a finish_mount_kattr() después de que mount_kattr se haya compilado con éxito tanto en el caso de éxito como en el de fracaso para evitar que se filtren las referencias que tomamos cuando lo compilamos. Regresamos temprano si falla la búsqueda de ruta, por lo que corremos el riesgo de filtrar una referencia adicional que tomamos al compilar mount_kattr cuando se solicitó un montaje con idmapped. • https://git.kernel.org/stable/c/9caccd41541a6f7d6279928d9f971f6642c361af https://git.kernel.org/stable/c/47b5d0a7532d39e42a938f81e3904268145c341d https://git.kernel.org/stable/c/012e332286e2bb9f6ac77d195f17e74b2963d663 • CWE-668: Exposure of Resource to Wrong Sphere •

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 •