May 2022 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1190037] New: VUL-0: CVE-2021-39163: matrix-synapse: Adding a private/unlisted room to a community exposes room metadata in an unauthorised manner
by bugzilla_noreply＠suse.com 24 Nov '22

24 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1190037 Bug ID: 1190037 Summary: VUL-0: CVE-2021-39163: matrix-synapse: Adding a private/unlisted room to a community exposes room metadata in an unauthorised manner Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: Other URL: https://smash.suse.de/issue/308826/ OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: mrueckert(a)suse.com Reporter: rfrohl(a)suse.com QA Contact: security-team(a)suse.de CC: asarai(a)suse.com Found By: Security Response Team Blocker: --- rh#1999846 Matrix is an ecosystem for open federated Instant Messaging and Voice over IP. In versions 1.41.0 and prior, unauthorised users can access the name, avatar, topic and number of members of a room if they know the ID of the room. This vulnerability is limited to homeservers where the vulnerable homeserver is in the room and untrusted users are permitted to create groups (communities). By default, only homeserver administrators can create groups. However, homeserver administrators can already access this information in the database or using the admin API. As a result, only homeservers where the configuration setting `enable_group_creation` has been set to `true` are impacted. Server administrators should upgrade to 1.41.1 or higher to patch the vulnerability. There are two potential workarounds. Server administrators can set `enable_group_creation` to `false` in their homeserver configuration (this is the default value) to prevent creation of groups by non-administrators. Administrators that are using a reverse proxy could, with partial loss of group functionality, block the endpoints `/_matrix/client/r0/groups/{group_id}/rooms` and `/_matrix/client/unstable/groups/{group_id}/rooms`. https://github.com/matrix-org/synapse/security/advisories/GHSA-jj53-8fmw-f2… https://github.com/matrix-org/synapse/releases/tag/v1.41.1 https://github.com/matrix-org/synapse/commit/cb35df940a References: https://bugzilla.redhat.com/show_bug.cgi?id=1999846 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-39163 https://github.com/matrix-org/synapse/security/advisories/GHSA-jj53-8fmw-f2… http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-39163 https://github.com/matrix-org/synapse/releases/tag/v1.41.1 https://github.com/matrix-org/synapse/commit/cb35df940a -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1096833] New: VUL-0: matrix-synapse: event visibility rules not applied correctly
by bugzilla_noreply＠novell.com 24 Nov '22

24 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1096833 Bug ID: 1096833 Summary: VUL-0: matrix-synapse: event visibility rules not applied correctly Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: okurz(a)suse.com Reporter: astieger(a)suse.com QA Contact: security-team(a)suse.de Found By: --- Blocker: --- from https://github.com/matrix-org/synapse/releases/tag/v0.31.1 Changes in synapse v0.31.1 (2018-06-08) v0.31.1 fixes a security bug in the get_missing_events federation API where event visibility rules were not applied correctly. We are not aware of it being actively exploited but please upgrade asap. Bug Fixes: Fix event filtering in get_missing_events handler (PR #3371) https://github.com/matrix-org/synapse/commit/ad9edd1d968f19dd4d7c65102fe552… -- You are receiving this mail because: You are on the CC list for the bug.

2 3

[Bug 1029190] New: Support for package variants according to the evaluation of bigger regular expressions
by bugzilla_noreply＠novell.com 24 Nov '22

24 Nov '22

http://bugzilla.suse.com/show_bug.cgi?id=1029190 Bug ID: 1029190 Summary: Support for package variants according to the evaluation of bigger regular expressions Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: All OS: All Status: NEW Severity: Enhancement Priority: P5 - None Component: Development Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: Markus.Elfring(a)web.de QA Contact: qa-bugs(a)suse.de CC: astieger(a)suse.com Found By: --- Blocker: --- I noticed that the parameter “--with-link-size=2” is used so far in a package specification. https://build.opensuse.org/package/view_file/openSUSE:Factory/pcre2/pcre2.s… This setting limits the size of regular expressions. I would like to work with bigger search patterns occasionally. So I suggest to generate also variants for this software with an internal link size of 3 (and 4) for the data processing with 8 and 16 bit characters. See also: Selection of system properties for the regular expressions engine at run time https://bugs.exim.org/show_bug.cgi?id=1922 By the way: How do you think about to use the specifications “LDFLAGS“ und “%{?_smp_mflags}“ as parameters for the script “%configure“ there? -- You are receiving this mail because: You are on the CC list for the bug.

2 4

[Bug 1052740] New: convert X keyboards into kbd and set unicode console font for languages with non-Latin alphabets
by bugzilla_noreply＠novell.com 22 Nov '22

22 Nov '22

http://bugzilla.suse.com/show_bug.cgi?id=1052740 Bug ID: 1052740 Summary: convert X keyboards into kbd and set unicode console font for languages with non-Latin alphabets Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: All OS: openSUSE Factory Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: opensuse.lietuviu.kalba(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Now openSUSE for languages with Latin alphabets use converted keyboard layouts from X into kbd, also use unicode console font (as converted layouts supports it). Remaining task is to do same transition for non-Latin console keyboard layouts and set appropriate console font. Perhaps we should preconfigure option to switch between native and US QWERTY in console for these non-Latin languages and keyboard layouts. As noted in https://bugzilla.suse.com/show_bug.cgi?id=942896#c70 , As noted in https://bugzilla.suse.com/show_bug.cgi?id=942896#c69 Greek seems not have converted console keyboard layout from X into kbd. For Greek perhaps we can use eurlatgr console font (like for Latin alphabets) All Cyrillic layouts now use UniCyr_8x16.psf font, but this font seems to be compatible with cp866, cp1251, iso8859-5 and koi8-r (according http://www.tldp.org/HOWTO/Belarusian-HOWTO/x28.html) and not compatible with unicode per se. But openSUSE seems don't provide converted layouts for Russian, Ukrainian, Serbian, Bulgarian, Tajik. For Cyrillic alphabets we should use LatArCyrHeb-14, LatArCyrHeb-16+ or LatArCyrHeb-16 console font, that support unicode. -- You are receiving this mail because: You are on the CC list for the bug.

2 6

[Bug 1178338] New: [installation] Support for 64-bit processors on motherboards with 32-bit UEFI (mixed-mode support)
by bugzilla_noreply＠suse.com 22 Nov '22

22 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1178338 Bug ID: 1178338 Summary: [installation] Support for 64-bit processors on motherboards with 32-bit UEFI (mixed-mode support) Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: 64bit OS: All Status: NEW Severity: Enhancement Priority: P5 - None Component: Installation Assignee: yast2-maintainers(a)suse.de Reporter: jslaby(a)suse.com QA Contact: jsrain(a)suse.com CC: glin(a)suse.com, jens(a)krieger-juhnke.de, jlee(a)suse.com, jslaby(a)suse.com, mbenes(a)suse.com, mchang(a)suse.com, tiwai(a)suse.com Blocks: 1172292 Found By: --- Blocker: --- +++ This bug was initially created as a clone of Bug #1172292 +++ On some devices (In my case a Lenovo Ideapad 100s-11iby) have 64 bit processors, but a 32-bit UEFI, so the 64-bit installation mediums are not recognized by it. Steps to Reproduce: 1. Grab a device with a 64-bit processor and a 32-bit UEFI 2. Try to boot from a 64-bit installation medium Actual Results: The installation medium is not listed in the boot menu. Expected Results: The installation medium is listed correctly, just like on a machine with a 64-bit UEFI. I did a bit of research, and found out the following: Fedora has natively supported 32-bit UEFI for 64 bit installs since Fedora 27. There seems to be a a workaround, but this is not very practical for new users, which adds a file from Github (https://github.com/hirotakaster/baytail-bootia32.efi) to the installation medium. ===================== Could x86_64 installation media contain this file on the installation media in the EFI partition: EFI/boot/bootia32.efi ? It should be copied from /usr/share/efi/i586/grub.efi from grub2-i386-efi package, the same as is EFI/boot/bootx64.efi from grub2-x86_64-efi. This will add support for 32bit FW with 64-bit CPUs. It used to work fine when I tried last time on such a machine. I had EFI/boot/bootia32.efi on an USB stick and loaded config from a DVD. Then continued the installation the usual way. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1196085] New: Calling external programs from YaST fragile with full paths
by bugzilla_noreply＠suse.com 21 Nov '22

21 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1196085 Bug ID: 1196085 Summary: Calling external programs from YaST fragile with full paths Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: All OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: shundhammer(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- After a security audit some years ago we changed all calls to external programs in YaST to use the full path, i.e. from "foobar" to "/sbin/foobar". The rationale was that this would prevent a potential attacker from manipulating the $PATH to include some directory containing a malicious version of the program, i.e. a "/my/hacked/foobar" with $PATH also containing "/my/hacked". With the transition from /bin to /usr/bin and /sbin to /usr/sbin that turned out to be a bad idea since now we need to update those full paths in the YaST code whenever any of those binaries makes that transition, i.e. it's moved from /sbin to /usr/sbin. Worse, if the transition is done in one supported product like Tumbleweed or Leap, yet another one like SLES still uses the old path, we would have to maintain different paths (and not forget to adapt them when that other product makes that transition as well); or we would need to create our own fallback logic to search all the possible paths which one to invoke. But that fallback logic exists, and if handled correctly, it's just as secure as using a full path; but more flexible and not fragile against tools being moved from one system location to another: It's $PATH. We need to make sure that $PATH only contains directories that are not writeable by non-privileged users, and of course not "." (the current directory) or any path that starts with "."; e.g. export PATH="/usr/sbin:/usr/bin:/sbin:/bin" And we already do that in YaST code. So we should migrate calls to external programs back to calling them without the full path and use our secure $PATH instead. For a more in-depth discussion, see also https://github.com/yast/yast-iscsi-client/issues/111 -- You are receiving this mail because: You are on the CC list for the bug.

1 18

[Bug 1190524] New: baloo keeps my laptop hot
by bugzilla_noreply＠suse.com 21 Nov '22

21 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1190524 Bug ID: 1190524 Summary: baloo keeps my laptop hot Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: KDE Workspace (Plasma) Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: saba(a)sabanet.at QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0 Build Identifier: Baloo file indexer is running since days at 100% CPU and I'm not sure if it will ever finish. Reproducible: Always Steps to Reproduce: 1. Installed Tumbleweed from scratch on a brand new notebook (LG gram 2021 i7-1165G7) 2. Copied my home directory from my old laptop (approx. 700GB of data) 3. Watch baloo running at 100% CPU for days/weeks Actual Results: Baloo seems to get slower and slower: gram:~> balooctl status ; sleep 3600 ; balooctl status Baloo File Indexer is running Indexer state: Indexing file content Total files indexed: 3,683,585 Files waiting for content indexing: 160,364 Files failed to index: 0 Current size of index is 71.48 GiB Baloo File Indexer is running Indexer state: Indexing file content Total files indexed: 3,683,065 Files waiting for content indexing: 159,844 Files failed to index: 0 Current size of index is 71.48 GiB This means in one hour the number of files waiting to be indexed decreased only by 520 (which would mean 7 seconds to add a single file to the index). At this speed, I'd need to wait another 300 hours before the indexer completed its job. Expected Results: Indexing should complete *much* faster. -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1193838] New: LXC /etc/systemd/system.conf is marked executable??
by bugzilla_noreply＠suse.com 21 Nov '22

21 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1193838 Bug ID: 1193838 Summary: LXC /etc/systemd/system.conf is marked executable?? Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: dev.dorrejo(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hello, i am practicing LXC, and have the next issue: zypper in --no-recommends lxc Configuration file /etc/systemd/system.conf is marked executable. Please remove executable permission bits. Proceeding anyway. ll /etc/systemd/system.conf -rw-r--r-- 1 root root 1993 Nov 24 19:14 /etc/systemd/system.conf getfacl /etc/systemd/system.conf # file: etc/systemd/system.conf # owner: root # group: root user::rw- group::r-- other::r-- Environment: - VMs using tumbleweed up-to-date - Disabled AppArmor - cgroup systemd.unified_cgroup_hierarchy=0 -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1196335] New: [Build C.520.1] kdump failed to start: device or resource busy
by bugzilla_noreply＠suse.com 21 Nov '22

21 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1196335 Bug ID: 1196335 Summary: [Build C.520.1] kdump failed to start: device or resource busy Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: Other URL: https://openqa.opensuse.org/tests/2204439/modules/jour nal_check/steps/22 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: dimstar(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: openQA Blocker: Yes ## Observation openQA test in scenario microos-Staging:C-Staging-DVD-x86_64-container-host-microos@64bit-2G-HD40G fails in [journal_check](https://openqa.opensuse.org/tests/2204439/modules/journal_ch… This error appears sporadic, rerunning the test might or might not show the same error: Feb 23 09:28:47.073824 localhost.localdomain systemd[1]: Failed to start Load kdump kernel and initrd. Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: kexec_load failed: Device or resource busy Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: entry = 0x7f554760 flags = 0x3e0001 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: nr_segments = 6 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[0].buf = 0x7f8e0c0ae010 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[0].bufsz = 0x13fbbb4 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[0].mem = 0x7a804000 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[0].memsz = 0x13fc000 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[1].buf = 0x7f8e0d4ade10 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[1].bufsz = 0xb0bdb0 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[1].mem = 0x7bc00000 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[1].memsz = 0x37b4000 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[2].buf = 0x5649202ba900 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[2].bufsz = 0x3fc7 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[2].mem = 0x7f550000 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[2].memsz = 0x4000 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[3].buf = 0x5649202b36c0 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[3].bufsz = 0x70e0 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[3].mem = 0x7f554000 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[3].memsz = 0x9000 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[4].buf = 0x5649202b1860 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[4].bufsz = 0x400 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[4].mem = 0x7f55d000 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[4].memsz = 0x4000 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[5].buf = 0x7f8e0c00f010 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[5].bufsz = 0x9ec00 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[5].mem = 0x7f561000 Feb 23 09:28:47.066939 localhost.localdomain load.sh[562]: segment[5].memsz = 0x9f000 Feb 23 09:28:47.071528 localhost.localdomain kdump[991]: FAILED to load kdump kernel: /sbin/kexec -p /boot/vmlinuz-5.16.10-5-default --append=" rd.timeout=60 rd.retry=45 console=ttyS0 console=tty kernel.softlockup_panic=1 swapaccount=1 quiet security=selinux selinux=1 enforcing=1 mitigations=auto elevator=deadline sysrq=yes reset_devices acpi_no_memhotplug cgroup_disable=memory nokaslr numa=off irqpoll nr_cpus=1 root=kdump rootflags=bind rd.udev.children-max=8 disable_cpu_apicid=0 panic=1" --initrd=/boot/initrd-kdump , Result: kexec_load failed: Device or resource busy entry = 0x7f554760 flags = 0x3e0001 nr_segments = 6 segment[0].buf = 0x7f8e0c0ae010 segment[0].bufsz = 0x13fbbb4 segment[0].mem = 0x7a804000 segment[0].memsz = 0x13fc000 segment[1].buf = 0x7f8e0d4ade10 segment[1].bufsz = 0xb0bdb0 segment[1].mem = 0x7bc00000 segment[1].memsz = 0x37b4000 segment[2].buf = 0x5649202ba900 segment[2].bufsz = 0x3fc7 segment[2].mem = 0x7f550000 segment[2].memsz = 0x4000 segment[3].buf = 0x5649202b36c0 segment[3].bufsz = 0x70e0 segment[3].mem = 0x7f554 Feb 23 09:28:47.073246 localhost.localdomain systemd[1]: kdump.service: Main process exited, code=exited, status=255/EXCEPTION Feb 23 09:28:47.073509 localhost.localdomain systemd[1]: kdump.service: Failed with result 'exit-code'. ## Test suite description ## Reproducible Fails since (at least) Build [C.520.1](https://openqa.opensuse.org/tests/2204217) ## Expected result Last good: [C.519.7](https://openqa.opensuse.org/tests/2203451) (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 7

[Bug 1082318] New: Packages must not mark license files as %doc
by bugzilla_noreply＠novell.com 21 Nov '22

21 Nov '22

http://bugzilla.suse.com/show_bug.cgi?id=1082318 Bug ID: 1082318 Summary: Packages must not mark license files as %doc Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: All OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: fvogt(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Certain licenses require that license files must be shipped together with the binaries in all cases. By using the %doc marker, this is no longer guaranteed (e.g. by enabling excludedocs). Thus it is important that for such cases, %license is used instead of %doc. The effect is that the file is always installed, stored in a different directory (/usr/share/licenses/<pkg>/) and can be queried using rpm (e.g. "rpm -qL kernel-firmware"). -- You are receiving this mail because: You are on the CC list for the bug.

2 249