Fedora has issued an advisory today (February 9): https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/GDNOV2RNQ7XMOQZ3PV7PHYP2FMJHV2AB/ Upstream advisory: https://github.com/tpm2-software/tpm2-tss/security/advisories/GHSA-4j3v-fh23-vx67 Mageia 8 is also affected.
Whiteboard: (none) => MGA8TOO
Assinging to the registered tpm2-tss maintainer
Assignee: bugsquad => geiger.david68210CC: (none) => marja11
seems fixed in 4.0.1 release: https://github.com/tpm2-software/tpm2-tss/releases/tag/4.0.1
Done for mga8 updating to 3.2.2 release fixes!
libtss2-esys0-3.2.2-1.mga8 libtss2-fapi1-3.2.2-1.mga8 libtpm2-tss-devel-3.2.2-1.mga8 libtss2-sys1-3.2.2-1.mga8 libtss2-mu0-3.2.2-1.mga8 tpm2-tss-3.2.2-1.mga8 libtss2-tctildr0-3.2.2-1.mga8 libtss2-tcti-cmd0-3.2.2-1.mga8 libtss2-tcti-pcap0-3.2.2-1.mga8 libtss2-tcti-mssim0-3.2.2-1.mga8 libtss2-rc0-3.2.2-1.mga8 libtss2-tcti-swtpm0-3.2.2-1.mga8 libtss2-esys0-3.2.2-1.mga8 libtss2-fapi1-3.2.2-1.mga8 libtpm2-tss-devel-3.2.2-1.mga8 libtss2-sys1-3.2.2-1.mga8 libtss2-mu0-3.2.2-1.mga8 tpm2-tss-3.2.2-1.mga8 libtss2-tctildr0-3.2.2-1.mga8 libtss2-tcti-cmd0-3.2.2-1.mga8 libtss2-tcti-pcap0-3.2.2-1.mga8 libtss2-tcti-mssim0-3.2.2-1.mga8 libtss2-rc0-3.2.2-1.mga8 libtss2-tcti-swtpm0-3.2.2-1.mga8 libtss2-tcti-device0-3.2.2-1.mga8 from tpm2-tss-3.2.2-1.mga8.src.rpm
Version: Cauldron => 8CC: (none) => geiger.david68210Source RPM: tpm2-tss-4.0.1-1.mga9.src.rpm => tpm2-tss-3.0.3-1.1.mga8.src.rpmWhiteboard: MGA8TOO => (none)Assignee: geiger.david68210 => qa-bugs
Previous updates to tpm2-tss and the related tpm-tools were OKed on a clean install, mostly because using urpmq --whatrequires didn't turn up anything useful as a test platform, even if "-recursive" was added to the command. I was about to do the same, but decided to try urpmq on some of the libraries. Nothing much at first, but when I added "-recursive" the results for some of the libraries came up with, among others, Discover, gnome-software, and openconnect. Openconnect enters the world of VPNs, something I keep threatening to explore but haven't yet, and gnome-software is designed for Gnome (of course), something I avoid whenever possible. That leaves Discover, the KDE package manager. I have a mga8-64 Plasma test system with Discover already installed and configured from a previous update test, so I used that. Several of the packages in comment 4 were listed twice, but fortunately Qarepo is able to handle that. I only installed/updated the packages already on the system: The following 4 packages are going to be installed: - lib64tss2-esys0-3.2.2-1.mga8.x86_64 - lib64tss2-mu0-3.2.2-1.mga8.x86_64 - lib64tss2-sys1-3.2.2-1.mga8.x86_64 - tpm2-tss-3.2.2-1.mga8.x86_64 There were no installation issues. I ran Discover, which is configured to use the Mageia 8 repos as the default, but also to use flathub. I installed four games from flathub, played them, and removed three. (I kept the Space Cadet 3D Pinball game because it's fun to play.) There were no issues noted. I installed all the above packages plus dependencies in a VirtualBox Plasma guest, then updated, with no issues. Then I installed gnome-software (and dependencies), used information from the Web to configure it to use flathub, ran it, installed a game, and played the game. Everything worked as it should. I'm going to call that good enough. I suppose it would be better if someone could try it out with openconnect, but that's beyond my capabilities. Validating.
Whiteboard: (none) => MGA8-64-OKCC: (none) => andrewsfarm, sysadmin-bugsKeywords: (none) => validated_update
Took a look at this one and decided to test it further. tpm provides hardware encryption and related tools using keys hardcoded into the tpm chip. It's typically used for encryption such that the hard drive can only be decrypted by that one computer, and to make it easier for companies such as m$ to ensure a licensed copy of their software can not be used on another computer. tpm2-tss sits in between the application and the hardware drivers. It requires a relatively new cpu/motherboard. Support for it was added to vb about a year ago. Lack of hardware and vb support is why we previously only checked for a clean install. One of the tools tpm provides is a hardware random number generator that vb can emulate. In an x86_64 vb guest settings, System, Motherboard, changed TPM from none to 2.0, and installed tpm2-tools (as tpm2-tss is installed by default) and started the guest. # journalctl -b --no-h|grep tpm Feb 11 18:43:12 kernel: tpm_tis MSFT0101:00: 2.0 TPM (device-id 0x0, rev-id 1) Feb 11 18:43:12 kernel: tpm tpm0: A TPM error (256) occurred attempting the self test Feb 11 18:43:12 kernel: tpm tpm0: starting up the TPM manually I couldn't find out what causes the error 256, but it seems not to be stopping it from working. # ll /dev/tpm* crw-rw---- 1 tss root 10, 224 Feb 11 18:43 /dev/tpm0 crw-rw---- 1 tss tss 244, 65536 Feb 11 18:43 /dev/tpmrm0 # tpm2_getrandom --hex 32 94cf643d88b10195bd40a65df0cb8ec2a6dc4ebb31429eaff67f8f3e29e23745 Installed the update. Repeated the above tests before and after rebooting. Same messages in the journal, and similar output from the tpm2_getrandom command, as expected.
Keywords: (none) => has_procedureCC: (none) => davidwhodgins
Keywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2023-0050.html
Status: NEW => RESOLVEDResolution: (none) => FIXED