ALT-PU-2021-4997-1
Package kernel-image-std-def updated to version 5.10.33-alt1 for branch sisyphus in task 270904.
Closed vulnerabilities
Modified: 2024-12-06
BDU:2024-01723
Уязвимость функции hso_serial_tty_unregister драйвера USB HSO (High Speed Options) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-00830
Уязвимость функции queued_write_lock_slowpath() компонента locking/qrwlock.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-02865
Уязвимость функции tpm2_seal_trusted() модуля security/keys/trusted-keys/trusted_tpm2.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2024-11-21
CVE-2021-46905
In the Linux kernel, the following vulnerability has been resolved: net: hso: fix NULL-deref on disconnect regression Commit 8a12f8836145 ("net: hso: fix null-ptr-deref during tty device unregistration") fixed the racy minor allocation reported by syzbot, but introduced an unconditional NULL-pointer dereference on every disconnect instead. Specifically, the serial device table must no longer be accessed after the minor has been released by hso_serial_tty_unregister().
- https://git.kernel.org/stable/c/0c71d4c89559f72cec2592d078681a843bce570e
- https://git.kernel.org/stable/c/0f000005da31f6947f843ce6b3e3a960540c6e00
- https://git.kernel.org/stable/c/24b699bea7553fc0b98dad9d864befb6005ac7f1
- https://git.kernel.org/stable/c/2ad5692db72874f02b9ad551d26345437ea4f7f3
- https://git.kernel.org/stable/c/41c44e1f3112d7265dae522c026399b2a42d19ef
- https://git.kernel.org/stable/c/5871761c5f0f20d6e98bf3b6bd7486d857589554
- https://git.kernel.org/stable/c/5c17cfe155d21954b4c7e2a78fa771cebcd86725
- https://git.kernel.org/stable/c/90642ee9eb581a13569b1c0bd57e85d962215273
- https://git.kernel.org/stable/c/d7fad2ce15bdbbd0fec3ebe999fd7cab2267f53e
- https://git.kernel.org/stable/c/0c71d4c89559f72cec2592d078681a843bce570e
- https://git.kernel.org/stable/c/0f000005da31f6947f843ce6b3e3a960540c6e00
- https://git.kernel.org/stable/c/24b699bea7553fc0b98dad9d864befb6005ac7f1
- https://git.kernel.org/stable/c/2ad5692db72874f02b9ad551d26345437ea4f7f3
- https://git.kernel.org/stable/c/41c44e1f3112d7265dae522c026399b2a42d19ef
- https://git.kernel.org/stable/c/5871761c5f0f20d6e98bf3b6bd7486d857589554
- https://git.kernel.org/stable/c/5c17cfe155d21954b4c7e2a78fa771cebcd86725
- https://git.kernel.org/stable/c/90642ee9eb581a13569b1c0bd57e85d962215273
- https://git.kernel.org/stable/c/d7fad2ce15bdbbd0fec3ebe999fd7cab2267f53e
Modified: 2024-11-21
CVE-2021-46921
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()]
- 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/84a24bf8c52e66b7ac89ada5e3cfbe72d65c1896
- https://git.kernel.org/stable/c/d558fcdb17139728347bccc60a16af3e639649d2
- 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/84a24bf8c52e66b7ac89ada5e3cfbe72d65c1896
- https://git.kernel.org/stable/c/d558fcdb17139728347bccc60a16af3e639649d2
Modified: 2024-11-21
CVE-2021-46922
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()
- https://git.kernel.org/stable/c/39c8d760d44cb3fa0d67e8cd505df81cf4d80999
- https://git.kernel.org/stable/c/9d5171eab462a63e2fbebfccf6026e92be018f20
- https://git.kernel.org/stable/c/bf84ef2dd2ccdcd8f2658476d34b51455f970ce4
- https://git.kernel.org/stable/c/39c8d760d44cb3fa0d67e8cd505df81cf4d80999
- https://git.kernel.org/stable/c/9d5171eab462a63e2fbebfccf6026e92be018f20
- https://git.kernel.org/stable/c/bf84ef2dd2ccdcd8f2658476d34b51455f970ce4
