- openSUSE Bugs

[Bug 1233752] [Build E.84.3] openQA test fails in trup_smoke -- TPM failure in 6.12
by bugzilla_noreply＠suse.com 18 Dec '24

18 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1233752 https://bugzilla.suse.com/show_bug.cgi?id=1233752#c51 --- Comment #51 from OBSbugzilla Bot <bwiedemann+obsbugzillabot(a)suse.com> --- This is an autogenerated message for OBS integration: This bug (1233752) was mentioned in https://build.opensuse.org/request/show/1231884 Factory / systemd -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1233752] New: [Build E.84.3] openQA test fails in trup_smoke
by bugzilla_noreply＠suse.com 18 Dec '24

18 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1233752 Bug ID: 1233752 Summary: [Build E.84.3] openQA test fails in trup_smoke Classification: openSUSE Product: openSUSE Distribution Version: Leap 16.0 Hardware: Other URL: https://openqa.opensuse.org/tests/4657304/modules/trup _smoke/steps/26 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: jslaby(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: openQA Blocker: Yes ## Observation openQA test in scenario microos-Staging:E-Staging-MicroOS-Image-sdboot-x86_64-microos-wizard-tpm@uefi-staging fails in [trup_smoke](https://openqa.opensuse.org/tests/4657304/modules/trup_smoke/st… ## Test suite description Like MicroOS, but use neither combustion nor ignition for the intial configuration, so jeos-firstboot runs. ## Reproducible Fails since (at least) Build [E.84.3](https://openqa.opensuse.org/tests/4657304) (current job) ## Expected result Last good: [E.83.16](https://openqa.opensuse.org/tests/4648526) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=microos… -- You are receiving this mail because: You are on the CC list for the bug.

1 46

[Bug 1234586] New: VUL-0: CVE-2024-45337: caddy: golang.org/x/crypto/ssh: Misuse of ServerConfig.PublicKeyCallback may cause authorization bypass in golang.org/x/crypto
by bugzilla_noreply＠suse.com 18 Dec '24

18 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1234586 Bug ID: 1234586 Summary: VUL-0: CVE-2024-45337: caddy: golang.org/x/crypto/ssh: Misuse of ServerConfig.PublicKeyCallback may cause authorization bypass in golang.org/x/crypto Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: Other URL: https://smash.suse.de/issue/432234/ OS: Other Status: NEW Whiteboard: CVSSv3.1:SUSE:CVE-2024-45337:8.1:(AV:N/AC:H/PR:N/UI:N/ S:U/C:H/I:H/A:H) Severity: Normal Priority: P5 - None Component: Security Assignee: alexandre.vicenzi(a)suse.com Reporter: andrea.mattiazzo(a)suse.com QA Contact: security-team(a)suse.de Blocks: 1234482 Target Milestone: --- Found By: --- Blocker: --- Applications and libraries which misuse the ServerConfig.PublicKeyCallback callback may be susceptible to an authorization bypass. The documentation for ServerConfig.PublicKeyCallback says that "A call to this function does not guarantee that the key offered is in fact used to authenticate." Specifically, the SSH protocol allows clients to inquire about whether a public key is acceptable before proving control of the corresponding private key. PublicKeyCallback may be called with multiple keys, and the order in which the keys were provided cannot be used to infer which key the client successfully authenticated with, if any. Some applications, which store the key(s) passed to PublicKeyCallback (or derived information) and make security relevant determinations based on it once the connection is established, may make incorrect assumptions. For example, an attacker may send public keys A and B, and then authenticate with A. PublicKeyCallback would be called only twice, first with A and then with B. A vulnerable application may then make authorization decisions based on key B for which the attacker does not actually control the private key. Since this API is widely misused, as a partial mitigation golang.org/x/cry...@v0.31.0 enforces the property that, when successfully authenticating via public key, the last key passed to ServerConfig.PublicKeyCallback will be the key used to authenticate the connection. PublicKeyCallback will now be called multiple times with the same key, if necessary. Note that the client may still not control the last key passed to PublicKeyCallback if the connection is then authenticated with a different method, such as PasswordCallback, KeyboardInteractiveCallback, or NoClientAuth. Users should be using the Extensions field of the Permissions return value from the various authentication callbacks to record data associated with the authentication attempt instead of referencing external state. Once the connection is established the state corresponding to the successful authentication attempt can be retrieved via the ServerConn.Permissions field. Note that some third-party libraries misuse the Permissions type by sharing it across authentication attempts; users of third-party libraries should refer to the relevant projects for guidance. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-45337 https://www.cve.org/CVERecord?id=CVE-2024-45337 https://github.com/golang/crypto/commit/b4f1988a35dee11ec3e05d6bf3e90b695fb… https://go.dev/cl/635315 https://go.dev/issue/70779 https://groups.google.com/g/golang-announce/c/-nPEi39gI4Q/m/cGVPJCqdAQAJ https://pkg.go.dev/vuln/GO-2024-3321 http://www.openwall.com/lists/oss-security/2024/12/11/2 https://bugzilla.redhat.com/show_bug.cgi?id=2331720 https://github.com/CVEProject/cvelistV5/blob/main//cves/2024/45xxx/CVE-2024… -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1234583] New: VUL-0: CVE-2024-45337: chezmoi: golang.org/x/crypto/ssh: Misuse of ServerConfig.PublicKeyCallback may cause authorization bypass in golang.org/x/crypto
by bugzilla_noreply＠suse.com 18 Dec '24

18 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1234583 Bug ID: 1234583 Summary: VUL-0: CVE-2024-45337: chezmoi: golang.org/x/crypto/ssh: Misuse of ServerConfig.PublicKeyCallback may cause authorization bypass in golang.org/x/crypto Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: Other URL: https://smash.suse.de/issue/432234/ OS: Other Status: NEW Whiteboard: CVSSv3.1:SUSE:CVE-2024-45337:8.1:(AV:N/AC:H/PR:N/UI:N/ S:U/C:H/I:H/A:H) Severity: Normal Priority: P5 - None Component: Security Assignee: filippo.bonazzi(a)suse.com Reporter: andrea.mattiazzo(a)suse.com QA Contact: security-team(a)suse.de Blocks: 1234482 Target Milestone: --- Found By: --- Blocker: --- Applications and libraries which misuse the ServerConfig.PublicKeyCallback callback may be susceptible to an authorization bypass. The documentation for ServerConfig.PublicKeyCallback says that "A call to this function does not guarantee that the key offered is in fact used to authenticate." Specifically, the SSH protocol allows clients to inquire about whether a public key is acceptable before proving control of the corresponding private key. PublicKeyCallback may be called with multiple keys, and the order in which the keys were provided cannot be used to infer which key the client successfully authenticated with, if any. Some applications, which store the key(s) passed to PublicKeyCallback (or derived information) and make security relevant determinations based on it once the connection is established, may make incorrect assumptions. For example, an attacker may send public keys A and B, and then authenticate with A. PublicKeyCallback would be called only twice, first with A and then with B. A vulnerable application may then make authorization decisions based on key B for which the attacker does not actually control the private key. Since this API is widely misused, as a partial mitigation golang.org/x/cry...@v0.31.0 enforces the property that, when successfully authenticating via public key, the last key passed to ServerConfig.PublicKeyCallback will be the key used to authenticate the connection. PublicKeyCallback will now be called multiple times with the same key, if necessary. Note that the client may still not control the last key passed to PublicKeyCallback if the connection is then authenticated with a different method, such as PasswordCallback, KeyboardInteractiveCallback, or NoClientAuth. Users should be using the Extensions field of the Permissions return value from the various authentication callbacks to record data associated with the authentication attempt instead of referencing external state. Once the connection is established the state corresponding to the successful authentication attempt can be retrieved via the ServerConn.Permissions field. Note that some third-party libraries misuse the Permissions type by sharing it across authentication attempts; users of third-party libraries should refer to the relevant projects for guidance. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-45337 https://www.cve.org/CVERecord?id=CVE-2024-45337 https://github.com/golang/crypto/commit/b4f1988a35dee11ec3e05d6bf3e90b695fb… https://go.dev/cl/635315 https://go.dev/issue/70779 https://groups.google.com/g/golang-announce/c/-nPEi39gI4Q/m/cGVPJCqdAQAJ https://pkg.go.dev/vuln/GO-2024-3321 http://www.openwall.com/lists/oss-security/2024/12/11/2 https://bugzilla.redhat.com/show_bug.cgi?id=2331720 https://github.com/CVEProject/cvelistV5/blob/main//cves/2024/45xxx/CVE-2024… -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Bug 1234605] Userspace crashes on parallels VM
by bugzilla_noreply＠suse.com 18 Dec '24

18 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1234605 https://bugzilla.suse.com/show_bug.cgi?id=1234605#c3 --- Comment #3 from Ivan Ivanov <ivan.ivanov(a)suse.com> --- SLE15-SP5 will need fix too... -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1234605] Userspace crashes on parallels VM
by bugzilla_noreply＠suse.com 18 Dec '24

18 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1234605 https://bugzilla.suse.com/show_bug.cgi?id=1234605#c2 Ivan Ivanov <ivan.ivanov(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|IN_PROGRESS |RESOLVED --- Comment #2 from Ivan Ivanov <ivan.ivanov(a)suse.com> --- Merged in SLE15-SP6 with eb067539dc2620b2ddcb2119576c06e4c0ec4fb3 Merged in SUSE-2025 with fc264097ad13ae2a5596102654cc8816a5c768df -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1234010] Unable to unlock multiple encrypted partitions with FIDO2 Key, Systemdboot+LUKS
by bugzilla_noreply＠suse.com 18 Dec '24

18 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1234010 https://bugzilla.suse.com/show_bug.cgi?id=1234010#c3 Alberto Planas Dominguez <aplanas(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CONFIRMED --- Comment #3 from Alberto Planas Dominguez <aplanas(a)suse.com> --- Sorry for the delay. Reading your logs I am able to reproduce it: ``` Dec 01 18:25:45 localhost kernel: hid-generic 0003:26CE:01A2.0001: input,hidraw0: USB HID v1.10 Device [ASRock LED Controller] on usb-0000:02:00.0-8/input0 Dec 01 18:25:45 localhost kernel: hid-generic 0003:1050:0120.0002: hiddev96,hidraw1: USB HID v1.10 Device [Yubico Security Key by Yubico] on usb-0000:02:00.0-2.2/input0 Dec 01 18:25:45 localhost kernel: usb 1-2.4.1: new full-speed USB device number 7 using xhci_hcd Dec 01 18:25:45 localhost systemd-cryptsetup[790]: Failed to open FIDO2 device /dev/hidraw1: FIDO_ERR_RX Dec 01 18:25:45 localhost systemd-cryptsetup[790]: Token returned error during pre-flight: Input/output error Dec 01 18:25:45 localhost systemd-cryptsetup[790]: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/disk/by-uuid/1b692ff9-23f5-4d84-86ee-51b3c3cb72c4. Dec 01 18:25:45 localhost systemd-cryptsetup[790]: Specified device /dev/hidraw1 is not a FIDO2 device. Dec 01 18:25:45 localhost systemd-cryptsetup[790]: Security token not present for unlocking volume Samsung SSD 990 PRO with Heatsink 1TB (cr_swap), please plug it in. Dec 01 18:25:45 localhost systemd-cryptsetup[790]: Specified device /dev/hidraw1 is not a FIDO2 device. Dec 01 18:25:45 localhost systemd-cryptsetup[789]: Asking FIDO2 token for authentication. Dec 01 18:25:45 localhost systemd-cryptsetup[789]: Please confirm presence on security token to unlock. ``` It is a race condition in systemd. Both cr_root and cr_swap are trying to access to the FIDO2 key, causing problems. I filled an issue upstream: https://github.com/systemd/systemd/issues/35671 We need to add somehow an ordering in the unlock -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1234513] New: VUL-0: : traefik: golang.org/x/crypto/ssh: Misuse of ServerConfig.PublicKeyCallback may cause authorization bypass in golang.org/x/crypto
by bugzilla_noreply＠suse.com 18 Dec '24

18 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1234513 Bug ID: 1234513 Summary: VUL-0: : traefik: golang.org/x/crypto/ssh: Misuse of ServerConfig.PublicKeyCallback may cause authorization bypass in golang.org/x/crypto Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: Other URL: https://smash.suse.de/issue/432234/ OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: alexandre.vicenzi(a)suse.com Reporter: gianluca.gabrielli(a)suse.com QA Contact: security-team(a)suse.de Blocks: 1234482 Target Milestone: --- Found By: --- Blocker: --- Applications and libraries which misuse the ServerConfig.PublicKeyCallback callback may be susceptible to an authorization bypass. The documentation for ServerConfig.PublicKeyCallback says that "A call to this function does not guarantee that the key offered is in fact used to authenticate." Specifically, the SSH protocol allows clients to inquire about whether a public key is acceptable before proving control of the corresponding private key. PublicKeyCallback may be called with multiple keys, and the order in which the keys were provided cannot be used to infer which key the client successfully authenticated with, if any. Some applications, which store the key(s) passed to PublicKeyCallback (or derived information) and make security relevant determinations based on it once the connection is established, may make incorrect assumptions. For example, an attacker may send public keys A and B, and then authenticate with A. PublicKeyCallback would be called only twice, first with A and then with B. A vulnerable application may then make authorization decisions based on key B for which the attacker does not actually control the private key. Since this API is widely misused, as a partial mitigation golang.org/x/cry...@v0.31.0 enforces the property that, when successfully authenticating via public key, the last key passed to ServerConfig.PublicKeyCallback will be the key used to authenticate the connection. PublicKeyCallback will now be called multiple times with the same key, if necessary. Note that the client may still not control the last key passed to PublicKeyCallback if the connection is then authenticated with a different method, such as PasswordCallback, KeyboardInteractiveCallback, or NoClientAuth. Users should be using the Extensions field of the Permissions return value from the various authentication callbacks to record data associated with the authentication attempt instead of referencing external state. Once the connection is established the state corresponding to the successful authentication attempt can be retrieved via the ServerConn.Permissions field. Note that some third-party libraries misuse the Permissions type by sharing it across authentication attempts; users of third-party libraries should refer to the relevant projects for guidance. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-45337 https://www.cve.org/CVERecord?id=CVE-2024-45337 https://github.com/golang/crypto/commit/b4f1988a35dee11ec3e05d6bf3e90b695fb… https://go.dev/cl/635315 https://go.dev/issue/70779 https://groups.google.com/g/golang-announce/c/-nPEi39gI4Q/m/cGVPJCqdAQAJ https://pkg.go.dev/vuln/GO-2024-3321 http://www.openwall.com/lists/oss-security/2024/12/11/2 https://bugzilla.redhat.com/show_bug.cgi?id=2331720 https://github.com/CVEProject/cvelistV5/blob/main//cves/2024/45xxx/CVE-2024… -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1233246] Random Soft Lockup on Lenovo Yoga Pro 7 14ASP9 with AMD GPU
by bugzilla_noreply＠suse.com 18 Dec '24

18 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1233246 https://bugzilla.suse.com/show_bug.cgi?id=1233246#c5 --- Comment #5 from Zhang <2835365572zty(a)gmail.com> --- No, it didn't fix. It happens again. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1233016] memory buff/cache issue with qemu
by bugzilla_noreply＠suse.com 18 Dec '24

18 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1233016 https://bugzilla.suse.com/show_bug.cgi?id=1233016#c26 --- Comment #26 from Jiri Slaby <jslaby(a)suse.com> --- (In reply to Krueger from comment #25) > Where can I register for api.opensuse.org? > I was asked for Username [api.opensuse.org] Sign Up at: https://build.opensuse.org/ -- You are receiving this mail because: You are on the CC list for the bug.

1 0