April 2022 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1198197] [Build 20220406] Yast canot process current bootloader configuration
by bugzilla_noreply＠suse.com 07 Apr '22

07 Apr '22

https://bugzilla.suse.com/show_bug.cgi?id=1198197 https://bugzilla.suse.com/show_bug.cgi?id=1198197#c2 Steffen Winterfeldt <snwint(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Steffen Winterfeldt <snwint(a)suse.com> --- pr merged, thanks! -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1198197] New: [Build 20220406] Yast canot process current bootloader configuration
by bugzilla_noreply＠suse.com 07 Apr '22

07 Apr '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1198197 Bug ID: 1198197 Summary: [Build 20220406] Yast canot process current bootloader configuration Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/2284856/modules/yast 2_bootloader/steps/6 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Bootloader Assignee: screening-team-bugs(a)suse.de Reporter: dimstar(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: openQA Blocker: Yes ## Observation openQA test in scenario opensuse-Tumbleweed-NET-x86_64-zdup-Leap-15.2-gnome@64bit fails in [yast2_bootloader](https://openqa.opensuse.org/tests/2284856/modules/yast2_b… The issue is appearing on all 15.x -> TW update tests, as openQA was reconfigured to add an RNG device (resulting in /dev/by-path changes for disks) Insofar, this is 'ok' to be strange. But we so far managed to identify at least one other bug in perl-Bootloader, based on the logs: 2022-04-07 04:44:58 <3> update-bootloader-9310 run_command.294: '/usr/lib/bootloader/grub2/install' failed with exit code 1, output: <<<<<<<<<<<<<<<< target = i386-pc /dev/disk/by-path/pci-0000:00:08.0: not a block device grub_installdevice missing or invalid determining suitable boot device disk device(/boot) kernel device = vda2 disk(vda2) = vda disk = vda + /usr/sbin/grub2-install --target=i386-pc --force --skip-fs-probe /dev/vda Installing for i386-pc platform. Installation finished. No error reported. >>>>>>>>>>>>>>>> This is inconsistent in that it reports 'Installation finished. No error reported' while returning with exit code 1. This in turn was traced down to: https://github.com/openSUSE/perl-bootloader/blob/master/grub2/install#L176 The script tries to identify the device, 'fails', sets err=1 and then goes into an error handler to recover from the situation. In this case though, irrespective of the result of the error handler, the final result is error (which seems wrong, if the code could recover and correct) ## Test suite description ## Reproducible Fails since (at least) Build [20220406](https://openqa.opensuse.org/tests/2284856) (current job) ## Expected result Last good: [20220405](https://openqa.opensuse.org/tests/2284393) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensus… -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1195608] YAST status halts from beginning.
by bugzilla_noreply＠suse.com 07 Apr '22

07 Apr '22

https://bugzilla.suse.com/show_bug.cgi?id=1195608 https://bugzilla.suse.com/show_bug.cgi?id=1195608#c23 Stefan Hundhammer <shundhammer(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED --- Comment #23 from Stefan Hundhammer <shundhammer(a)suse.com> --- Notice that the changes for SLE-15-SP4 are going to the maintenance branch so they will be released later with a maintenance update together with other fixes. PRs for factory / TW: https://github.com/yast/yast-packager/pull/612 (yast2-packager-4.5.1) https://github.com/yast/yast-yast2/pull/1252 (yast2-4.5.1) -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1198096] New: 'zypper -n in 389-ds sssd sssd-ldap openssl' failed with code 107 (ZYPPER_EXIT_INF_RPM_SCRIPT_FAILED)
by bugzilla_noreply＠suse.com 07 Apr '22

07 Apr '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1198096 Bug ID: 1198096 Summary: 'zypper -n in 389-ds sssd sssd-ldap openssl' failed with code 107 (ZYPPER_EXIT_INF_RPM_SCRIPT_FAILED) Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: aarch64 URL: https://openqa.opensuse.org/tests/2282748/modules/tls_ 389ds_sssd_client/steps/11 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: libzypp Assignee: zypp-maintainers(a)suse.de Reporter: guillaume.gardet(a)arm.com QA Contact: qa-bugs(a)suse.de Found By: openQA Blocker: Yes Created attachment 857824 --> http://bugzilla.opensuse.org/attachment.cgi?id=857824&action=edit zypper.log ## Observation openQA test in scenario opensuse-Tumbleweed-DVD-aarch64-security_389ds_sssd_client@aarch64 fails in [tls_389ds_sssd_client](https://openqa.opensuse.org/tests/2282748/modules/tl… 'zypper -n in 389-ds sssd sssd-ldap openssl' failed with code 107 (ZYPPER_EXIT_INF_RPM_SCRIPT_FAILED) ## Test suite description Maintainer: rfan1 ## Reproducible Fails since (at least) Build [20220403](https://openqa.opensuse.org/tests/2282298) ## Expected result Last good: [20220331](https://openqa.opensuse.org/tests/2275620) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=aarch64&distri=opensu… -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1198187] New: VUL-1: CVE-2022-1240: Heap buffer overflow in libr/bin/format/mach0/mach0.c
by bugzilla_noreply＠suse.com 07 Apr '22

07 Apr '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1198187 Bug ID: 1198187 Summary: VUL-1: CVE-2022-1240: Heap buffer overflow in libr/bin/format/mach0/mach0.c Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: Other URL: https://smash.suse.de/issue/328285/ OS: Other Status: NEW Severity: Minor Priority: P5 - None Component: Security Assignee: stefan.bruens(a)rwth-aachen.de Reporter: cathy.hu(a)suse.com QA Contact: security-team(a)suse.de Found By: Security Response Team Blocker: --- CVE-2022-1240 Heap buffer overflow in libr/bin/format/mach0/mach0.c in GitHub repository radareorg/radare2 prior to 5.8.6. If address sanitizer is disabled during the compiling, the program should executes into the `r_str_ncpy` function. Therefore I think it is very likely to be exploitable. For more general description of heap buffer overflow, see [CWE](https://cwe.mitre.org/data/definitions/122.html). References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-1240 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1240 https://github.com/radareorg/radare2/commit/ca8d8b39f3e34a4fd943270330b80f1… https://huntr.dev/bounties/e589bd97-4c74-4e79-93b5-0951a281facc -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1198195] New: VUL-0: CVE-2022-26110: htcondor: mishandled privileges allow possible command injection
by bugzilla_noreply＠suse.com 07 Apr '22

07 Apr '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1198195 Bug ID: 1198195 Summary: VUL-0: CVE-2022-26110: htcondor: mishandled privileges allow possible command injection Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: Other URL: https://smash.suse.de/issue/328131/ OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: cgoll(a)suse.com Reporter: cathy.hu(a)suse.com QA Contact: security-team(a)suse.de Found By: Security Response Team Blocker: --- rh#2072029 An attacker need only have READ-level authorization to a vulnerable daemon using the CLAIMTOBE authentication method. This means they are able to run tools like condor_q or condor_status. Many pools do not restrict who can issue READ-level commands, and CLAIMTOBE is allowed for READ-level commands in the default configuration. Thus, it is likely that an attacker could execute this command remotely from an untrusted network, unless prevented by a firewall or other network-level access controls. Reference: https://htcondor.org/security/vulnerabilities/HTCONDOR-2022-0003 References: https://bugzilla.redhat.com/show_bug.cgi?id=2072029 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-26110 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-26110 http://www.cvedetails.com/cve/CVE-2022-26110/ https://research.cs.wisc.edu/htcondor/security/vulnerabilities/HTCONDOR-202… -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1198167] modprobe: ERROR: could not insert 'libafs': Key was rejected by service
by bugzilla_noreply＠suse.com 07 Apr '22

07 Apr '22

https://bugzilla.suse.com/show_bug.cgi?id=1198167 https://bugzilla.suse.com/show_bug.cgi?id=1198167#c3 Marcus Meissner <meissner(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from Marcus Meissner <meissner(a)suse.com> --- clumsy, but works for me -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1198167] modprobe: ERROR: could not insert 'libafs': Key was rejected by service
by bugzilla_noreply＠suse.com 07 Apr '22

07 Apr '22

https://bugzilla.suse.com/show_bug.cgi?id=1198167 https://bugzilla.suse.com/show_bug.cgi?id=1198167#c2 Marcus Meissner <meissner(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |meissner(a)suse.com --- Comment #2 from Marcus Meissner <meissner(a)suse.com> --- actually when you first install opensUSE Leap 15.3 and reboot, you would be presented by the MOK Manager Dialog. you can reenforce this by: zypper in -f openSUSE-signing-cert reboot ... acknowledge the new key in the MOK dialog ... This package will ask the MOK Manager to enroll the openSUSE signing key into the MOK. After that you can do modprobe libafs. (This should be happening during installation, but people might not see tzhe mok manager as it runs just once and has a 10 second timeout.) -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1187864] Semantic interposition inhibits optimization of shared libraries
by bugzilla_noreply＠suse.com 07 Apr '22

07 Apr '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1187864 Martin Jambor <mjambor(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mjambor(a)suse.com -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1134289] ghostscript should not have a hard dependency on AppArmor via "Requires: apparmor-abstractions"
by bugzilla_noreply＠suse.com 07 Apr '22

07 Apr '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1134289 http://bugzilla.opensuse.org/show_bug.cgi?id=1134289#c6 Frederic Crozat <fcrozat(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fcrozat(a)suse.com --- Comment #6 from Frederic Crozat <fcrozat(a)suse.com> --- While installing apparmor policy is fine for ghostscript, having hard requirements on the apparmor "infrastructure" isn't. It forces apparmor to be installed on MicroOS Desktop, which uses selinux. -- You are receiving this mail because: You are on the CC list for the bug.

1 0