February 2023 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1207920] VUL-0: CVE-2021-3643: sox: buffer overflow read vulnerability
by bugzilla_noreply＠suse.com 06 Feb '23

06 Feb '23

1 0

[Bug 1202933] VUL-0: CVE-2022-3560: pesign: pesign-authorize ExecStartPost script allows privilege escalation from pesign to root
by bugzilla_noreply＠suse.com 06 Feb '23

06 Feb '23

https://bugzilla.suse.com/show_bug.cgi?id=1202933 https://bugzilla.suse.com/show_bug.cgi?id=1202933#c20 --- Comment #20 from Gary Ching-Pang Lin <glin(a)suse.com> --- While backporting the patch to SLE15, I'm thinking about removing the pesign-authorize-users/groups scripts completely. For SLE/openSUSE, we never use the daemon mode to sign EFI images, and the signing script for the customers also just uses pesign directly. Besides, there was no complaint about the broken path in pesign.service.in, so I wonder if there is any real SLE/openSUSE user of daemon mode. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1207901] [Build 20230203] snapper_cleanup does not return in time
by bugzilla_noreply＠suse.com 06 Feb '23

06 Feb '23

https://bugzilla.suse.com/show_bug.cgi?id=1207901 Arvin Schnell <aschnell(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aschnell(a)suse.com, | |dsterba(a)suse.com -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1201089] [META] GCC 13 package failures
by bugzilla_noreply＠suse.com 06 Feb '23

06 Feb '23

https://bugzilla.suse.com/show_bug.cgi?id=1201089 https://bugzilla.suse.com/show_bug.cgi?id=1201089#c10 --- Comment #10 from Michael Chang <mchang(a)suse.com> --- (In reply to Michael Chang from comment #9) > (In reply to Martin Li��ka from comment #2) > > grub2 issue: > > https://github.com/rhboot/grub2/pull/115 > > I think we should fix 0002-AUDIT-0-http-boot-tracker-bug.patch to use > HTTP_MAX_CHUNK_SIZE = GRUB_INT_MAX and making port range check not to be > 0x80000000 inclusive. The patch is part of efi https support which's not > upstreamed yet. It now works for gcc13 and will be submitted to factory later today. https://build.opensuse.org/package/live_build_log/home:michael-chang:branch… -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1207314] nvidia G06 525.86.05 on TW 20230118: sddm-greeter dumps core, no login screen
by bugzilla_noreply＠suse.com 05 Feb '23

05 Feb '23

https://bugzilla.suse.com/show_bug.cgi?id=1207314 https://bugzilla.suse.com/show_bug.cgi?id=1207314#c38 Ra�l Osuna <rosuna(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rosuna(a)suse.com --- Comment #38 from Ra�l Osuna <rosuna(a)suse.com> --- I faced the same problem for quite some time. I think for the workaround it's important to say that it needs to be done with the X server stopped. First try did not work for me: rpm -e nvidia-driver-G06-kmp-default --nodeps zypper in nvidia-driver-G06-kmp-default <reboot> **not working** prime-select nvidia <reboot> **not working** init 3 rpm -e nvidia-driver-G06-kmp-default --nodeps zypper in nvidia-driver-G06-kmp-default prime-select nvidia not even a reboot rcxdm restart **Working!!** I've noticed the full solution is not persistent within reboots. But now I only need a restart of the X server, and then I can log in, fortunately control-alt-backspace works, but still not perfect. Any suggestion what could be going wrong? Some info: laptop:~ # rpm -qa | grep ^nvidia nvidia-compute-G06-32bit-525.85.05-6.1.x86_64 nvidia-video-G06-525.85.05-6.1.x86_64 nvidia-compute-utils-G06-525.85.05-6.1.x86_64 nvidia-video-G06-32bit-525.85.05-6.1.x86_64 nvidia-gl-G06-32bit-525.85.05-6.1.x86_64 nvidia-utils-G06-525.85.05-6.1.x86_64 nvidia-compute-G06-525.85.05-6.1.x86_64 nvidia-gl-G06-525.85.05-6.1.x86_64 nvidia-driver-G06-kmp-default-525.85.05_k6.1.6_1-6.1.x86_64 laptop:~ # lsmod | grep nvidia nvidia_drm 73728 33 nvidia_modeset 1220608 68 nvidia_drm nvidia_uvm 2883584 0 nvidia 56414208 3214 nvidia_uvm,nvidia_modeset video 69632 3 thinkpad_acpi,i915,nvidia_modeset laptop:~ # find /lib/modules | grep nvidia /lib/modules/6.1.4-1-default/kernel/drivers/i2c/busses/i2c-nvidia-gpu.ko.zst /lib/modules/6.1.4-1-default/kernel/drivers/net/ethernet/nvidia /lib/modules/6.1.4-1-default/kernel/drivers/net/ethernet/nvidia/forcedeth.ko.zst /lib/modules/6.1.4-1-default/kernel/drivers/platform/x86/nvidia-wmi-ec-backlight.ko.zst /lib/modules/6.1.4-1-default/kernel/drivers/usb/typec/altmodes/typec_nvidia.ko.zst /lib/modules/6.1.8-1-default/updates/nvidia-drm.ko /lib/modules/6.1.8-1-default/updates/nvidia-modeset.ko /lib/modules/6.1.8-1-default/updates/nvidia-peermem.ko /lib/modules/6.1.8-1-default/updates/nvidia-uvm.ko /lib/modules/6.1.8-1-default/updates/nvidia.ko /lib/modules/6.1.8-1-default/kernel/drivers/i2c/busses/i2c-nvidia-gpu.ko.zst /lib/modules/6.1.8-1-default/kernel/drivers/net/ethernet/nvidia /lib/modules/6.1.8-1-default/kernel/drivers/net/ethernet/nvidia/forcedeth.ko.zst /lib/modules/6.1.8-1-default/kernel/drivers/platform/x86/nvidia-wmi-ec-backlight.ko.zst /lib/modules/6.1.8-1-default/kernel/drivers/usb/typec/altmodes/typec_nvidia.ko.zst laptop:~ # glxinfo -B | grep "OpenGL renderer" OpenGL renderer string: NVIDIA T1200 Laptop GPU/PCIe/SSE2 laptop:~ # prime-select get-current Driver configured: nvidia NVIDIA modules are loaded laptop:~ # lspci |grep -i vga 00:02.0 VGA compatible controller: Intel Corporation TigerLake-H GT1 [UHD Graphics] (rev 01) 01:00.0 VGA compatible controller: NVIDIA Corporation TU117GLM [T1200 Laptop GPU] (rev a1) -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1207555] Transmission can't open Bittorrent v2 torrents
by bugzilla_noreply＠suse.com 05 Feb '23

05 Feb '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1207555 http://bugzilla.opensuse.org/show_bug.cgi?id=1207555#c3 --- Comment #3 from Luca Beltrame <lbeltrame(a)kde.org> --- Sorry! Wrong BR. Please ignore, I had another tab open. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1207555] Transmission can't open Bittorrent v2 torrents
by bugzilla_noreply＠suse.com 05 Feb '23

05 Feb '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1207555 Luca Beltrame <lbeltrame(a)kde.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also|https://github.com/transmis | |sion/transmission/issues/47 | |16 | -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1207555] Transmission can't open Bittorrent v2 torrents
by bugzilla_noreply＠suse.com 05 Feb '23

05 Feb '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1207555 http://bugzilla.opensuse.org/show_bug.cgi?id=1207555#c2 Luca Beltrame <lbeltrame(a)kde.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lbeltrame(a)kde.org See Also| |https://github.com/transmis | |sion/transmission/issues/47 | |16 --- Comment #2 from Luca Beltrame <lbeltrame(a)kde.org> --- As far as I know, transmission uses RC4 as cipher algorithm (cf https://github.com/termux/termux-packages/issues/10814#issuecomment-1157320…) However, this is not enabled by default in openSSL 3. This means that as soon as transmission starts, tries to load it, does not find it and promptly crashes: Thread 3 "transmission-da" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff66a66c0 (LWP 19992)] 0x00007ffff799180f in EVP_CIPHER_CTX_set_key_length (c=c@entry=0x0, keylen=keylen@entry=20) at crypto/evp/evp_enc.c:994 Downloading 0.05 MB source file /usr/src/debug/openssl-3.0.7/crypto/evp/evp_enc.c 994 if (c->cipher->prov != NULL) { (gdb) print c $1 = (EVP_CIPHER_CTX *) 0x0 As detailed in the linked thread, the legacy provider (where RC4 is) should be enabled in openSSL 3 by adding [legacy_provider] activate = 1 I'm not sure if there's an issue upstream for transmission regarding this. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1186027] New: VUL-1: CVE-2021-32917,CVE-2021-32918,CVE-2021-32919,CVE-2021-32920,CVE-2021-32921: Prosody XMPP server advisory 2021-05-12 (multiple vulnerabilities)
by bugzilla_noreply＠suse.com 05 Feb '23

05 Feb '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1186027 Bug ID: 1186027 Summary: VUL-1: CVE-2021-32917,CVE-2021-32918,CVE-2021-32919,CVE-2021- 32920,CVE-2021-32921: Prosody XMPP server advisory 2021-05-12 (multiple vulnerabilities) Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: Other URL: https://smash.suse.de/issue/284222/ OS: Other Status: NEW Severity: Minor Priority: P5 - None Component: Other Assignee: mvetter(a)suse.com Reporter: gianluca.gabrielli(a)suse.com QA Contact: security-team(a)suse.de Found By: Security Response Team Blocker: --- Prosody security advisory 2021-05-12 ==================================== Project : Prosody XMPP server URL : https://prosody.im/ Date : 2021-05-12 This advisory details 5 new security vulnerabilities discovered in the Prosody.im XMPP server software. All issues are fixed in the 0.11.9 release default configuration. **References** - Release announcement: https://blog.prosody.im/prosody-0.11.9-released/ - Advisory (HTML): https://prosody.im/security/advisory_20210512/ - Advisory (text): https://prosody.im/security/advisory_20210512.txt 1/5: DoS via insufficient memory consumption controls ----------------------------------------------------- CVE : CVE-2021-32918 CVSS : 7.0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H/E:F/RL:O/RC:C) CWEs : CWE-400 Affected versions : All versions prior to 0.11.9 Fixed versions : 0.11.9, 0.11 nightly build 130, trunk nightly build 1434 **Description** It was discovered that default settings leave Prosody susceptible to remote unauthenticated denial-of-service (DoS) attacks via memory exhaustion when running under Lua 5.2 or Lua 5.3. Lua 5.2 is the default and recommended Lua version for Prosody 0.11.x series. **Affected configurations** The default configuration is susceptible to this issue. Configurations with stricter settings for stanza size limits, rate limits and garbage collection parameters are at decreased risk from this attack. For more details please review the 'Mitigation' section for recommended values. **Mitigation** Mitigation is possible through configuration changes (on 0.11.7+). All the configuration changes described in this section are applied by default in Prosody 0.11.9. 1) Enable more aggressive garbage collection On Lua 5.2 and 5.3, the garbage collector does not free unused memory fast enough by default. This allowed Prosody's memory usage to grow excessively during certain traffic patterns. It is recommended to set a garbage collection speed of at least 500 in the global section of your configuration file: ``` gc = { speed = 500; } ``` Be aware that this setting may increase CPU usage if the other mitigations in this section are not applied. 2) Enable stricter stanza size limits By default Prosody ships with extremely permissive stanza size limits (up to 10MB). This value was introduced as a way to place a limit on memory usage without affecting legitimate use of the server. However testing demonstrates that the default limit is too high for most deployments. Our recommendation (and the default in 0.11.9) is to adopt the same default size limits that are already enforced by ejabberd, one of the other major XMPP servers on the network. To enable the new limits explicitly, add to the global section of your configuration file the following options: c2s_stanza_size_limit = 256 * 1024 s2s_stanza_size_limit = 512 * 1024 Be aware that reducing limits has the potential to introduce interoperability issues with deployments that do not enforce the same size limits. For example, remote contacts with large avatars. 3) Enable rate limits By default Prosody does not enable any rate limits. However we recommend enabling them for all production and public deployments to ensure fair consumption of resources across all connections. First, ensure that mod_limits is enabled by adding "limits" to your global modules_enabled configuration option: ``` modules_enabled = { ... "limits"; ... } ``` Next, configure the limits: ``` limits = { c2s = { rate = "10kb/s"; }; s2sin = { rate = "30kb/s"; } } ``` **Advice** All public deployments should upgrade to 0.11.9 or apply the above configuration changes. Deployments using nightly builds should upgrade to the latest available builds. **Credits** Many thanks to Travis Burtrum (moparisthebest) for discovering and reporting this issue, and providing a test case. **Commits** - https://hg.prosody.im/trunk/rev/db8e41eb6eff - https://hg.prosody.im/trunk/rev/b0d8920ed5e5 - https://hg.prosody.im/trunk/rev/929de6ade6b6 - https://hg.prosody.im/trunk/rev/63fd4c8465fb - https://hg.prosody.im/trunk/rev/1937b3c3efb5 - https://hg.prosody.im/trunk/rev/3413fea9e6db ---------------------------------------------------------------------------- 2/5: DoS via repeated TLS renegotiation causing excessive CPU consumption ---------------------------------------------------------------------------- CVE : CVE-2021-32920 CVSS : 5.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L/E:H/RL:O/RC:C) CWEs : CWE-400 Affected versions : All versions prior to 0.11.9 Fixed versions : 0.11.9, 0.11 nightly build 130, trunk nightly build 1434 **Description** It was discovered that Prosody does not disable SSL/TLS renegotiation, even though this is not used in XMPP. A malicious client may flood a connection with renegotiation requests to consume excessive CPU resources on the server. Support for disabling renegotiation depends on OpenSSL 1.1.1+ and LuaSec 0.7+. **Affected configurations** The default configuration is susceptible to this issue. **Temporary mitigation** Ensure you have OpenSSL 1.1.1 or higher and LuaSec 0.7 or higher, and set the following ssl option (or add to your existing one if you have one): ``` ssl = { options = { no_renegotiation = true; } } ``` This configuration is applied by default in 0.11.9. **Advice** All public deployments should upgrade to 0.11.9 or apply the above configuration changes. Deployments using nightly builds should upgrade to the latest available builds. **Credits** This flaw was discovered by Kim Alvefur, a member of the Prosody team. **Commits** - https://hg.prosody.im/trunk/rev/55ef50d6cf65 - https://hg.prosody.im/trunk/rev/5a484bd050a7 - https://hg.prosody.im/trunk/rev/aaf9c6b6d18d ----------------------------------------------------------------------- 3/5: Use of timing-dependent string comparison with sensitive values ----------------------------------------------------------------------- CVE : CVE-2021-32921 CVSS : 4.7 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N/E:U/RL:O/RC:U) CWEs : CWE-1254 Affected versions : All versions prior to 0.11.9 Fixed versions : 0.11.9, 0.11 nightly build 130, trunk nightly build 1434 **Description** It was discovered that Prosody does not use a constant-time algorithm for comparing certain secret strings when running under Lua 5.2 or later. This can potentially be used in a timing attack to reveal the contents of secret strings to an attacker. Lua 5.1 utilizes a technique called "string interning", which protected string comparisons from timing attacks. In Lua 5.2 and later versions, strings over 40 bytes in length are excluded from interning. With Prosody running under Lua 5.2, this makes any secret string over 40 bytes in length vulnerable to potential discovery via timing attacks. Note that if a secret string contains non-ASCII (unicode) characters, it may be longer than 40 bytes when encoded as UTF-8 (Prosody's internal encoding) even if it is fewer than 40 characters long. It should be noted that to successfully perform a timing attack, a significant number of failed attempts must typically be made to "guess" at the contents of the secret string. We are not aware of any attempts to exploit this vulnerability (which would likely be noticeable), and no known proof-of-concept exploit exists. **Affected configurations** This flaw affects the following modules: - mod_auth_internal_plain (disabled by default) mod_auth_internal_plain performs a timing-dependent comparison to the user's password if the user's password is longer than 40 bytes. This may allow an attacker to discover a user's password via a timing attack. We do not generally recommend mod_auth_internal_plain for new deployments, and mod_auth_internal_hashed has been the default for Prosody 0.11.x. - mod_muc (disabled by default) mod_muc supports password-protection of MUCs. The password validity check is performed using a timing-dependent comparison, which may allow an attacker to discover the MUC password via a timing attack if the password is longer than 40 bytes. We do not generally recommend using password-protected MUCs. Instead use affiliations to directly grant access to specific JIDs whenever possible. - mod_auth_internal_hashed (enabled by default but not typically vulnerable) mod_auth_internal_hashed has been updated for safety, but it is not vulnerable in the default configuration of Lua 5.2 as the password hashes it compares do not exceed 40 bytes. - mod_dialback (enabled by default but not typically vulnerable) mod_dialback has been updated for safety, but due to the single-use nature of s2s dialback verification strings a timing attack on this module is not believed to be possible, or to grant an attacker any advantage if it were. **Temporary mitigation** mod_auth_internal_plain: we recommend that people upgrade to mod_auth_internal_hashed due to this and also to benefit from its other security properties. mod_muc: use affiliations to grant access to a MUC instead of passwords. If passwords must be used, ensure they are shorter than 40 bytes. Rate limits can greatly lengthen the amount of time required to successfully complete a timing attack. Enable and configure mod_limits. **Advice** All deployments should upgrade to 0.11.9. Deployments using nightly builds should upgrade to the latest available builds. **Credits** This flaw was discovered by Matthew Wild, a member of the Prosody team. The issue with MUC passwords was also previously identified by Robert Gr��sser. **Commits** - https://hg.prosody.im/trunk/rev/c98aebe601f9 - https://hg.prosody.im/trunk/rev/13b84682518e - https://hg.prosody.im/trunk/rev/6f56170ea986 ------------------------------------------------------------------- 4/5: Use of mod_proxy65 is unrestricted in default configuration ------------------------------------------------------------------- CVE : CVE-2021-32917 CVSS : 5.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L/E:H/RL:O/RC:C) CWEs : CWE-862, CWE-400 Affected versions : All versions prior to 0.11.9 Fixed versions : 0.11.9, 0.11 nightly build 130, trunk nightly build 1434 **Description** mod_proxy65 is a file transfer proxy provided with Prosody to facilitate the transfer of files and other data between XMPP clients. It was discovered that the proxy65 component of Prosody allows open access by default, even if neither of the users have an XMPP account on the local server, allowing unrestricted use of the server's bandwidth. **Affected configurations** The default configuration does not enable mod_proxy65 and is not affected. With mod_proxy65 enabled, all configurations without a 'proxy65_acl' setting configured are affected. **Temporary mitigation** Configure 'proxy65_acl' to a list of XMPP domains that should be allowed to use the file transfer proxy. **Advice** All deployments should upgrade to 0.11.9 and/or configure a 'proxy65_acl' as desired. Deployments using nightly builds should upgrade to the latest available builds. The default behaviour in 0.11.9 allows all local clients to initiate a data stream through the proxy if proxy65_acl is unconfigured. **Credits** This flaw was discovered by the Prosody team. **Commits** - https://hg.prosody.im/trunk/rev/65dcc175ef5b -------------------------------------------------------------- 5/5: Undocumented dialback-without-dialback option insecure -------------------------------------------------------------- CVE : CVE-2021-32919 Affected versions : Prosody 0.10.x, Prosody 0.11.x prior to 0.11.9 Fixed versions : 0.11.9, 0.11 nightly build 130, trunk nightly build 1434 **Description** The undocumented option 'dialback_without_dialback' enabled an experimental feature for server-to-server authentication. A flaw in this feature meant it did not correctly authenticate remote servers, allowing a remote server to impersonate another server when this option is enabled. **Affected configurations** The default configuration is not affected. Configurations with the setting 'dialback_without_dialback' set to true are affected. **Temporary mitigation** Remove or disable the 'dialback_without_dialback' option. **Advice** All deployments should upgrade to 0.11.9 or disable this feature. Deployments using nightly builds should upgrade to the latest available builds. The affected feature has been removed in 0.11.9. **Credits** This flaw was discovered by the Prosody team. **Commits** - https://hg.prosody.im/trunk/rev/6be890ca492e - https://hg.prosody.im/trunk/rev/d0e9ffccdef9 -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1207897] New: MicroOS, Raspberry Pi 4, 8Gb RAM, boot fail after zypper dup
by bugzilla_noreply＠suse.com 05 Feb '23

05 Feb '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1207897 Bug ID: 1207897 Summary: MicroOS, Raspberry Pi 4, 8Gb RAM, boot fail after zypper dup Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: aarch64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: olivpass(a)web.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 864710 --> http://bugzilla.opensuse.org/attachment.cgi?id=864710&action=edit picture of uboot messages Hi, MicroOS image from about beginning January 2023, boots and works fine with my Pi 4, 8Gb RAM. After a full zypper dup it stops boot at uboot stage with following Message: ... Found EFI removable media binary efi/boot/bootaa64.efi ** Reading file would overwrite reserved memory ** Failed to load 'efi/boot/bootaa64.efi' ... Attached is a image of this. By the way, my Raspberry Pi 4 with 4Gb RAM works/boots fine. Thank you, Oliver -- You are receiving this mail because: You are on the CC list for the bug.

1 2