June 2024 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1216739] New: sssd: support configs and drop-ins in /usr
by bugzilla_noreply＠suse.com 21 Jan '25

21 Jan '25

https://bugzilla.suse.com/show_bug.cgi?id=1216739 Bug ID: 1216739 Summary: sssd: support configs and drop-ins in /usr Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: scabrero(a)suse.com Reporter: lnussel(a)suse.com QA Contact: qa-bugs(a)suse.de CC: ckowalczyk(a)suse.com, jengelh(a)inai.de, scabrero(a)suse.com Target Milestone: --- Found By: --- Blocker: --- sssd ships configs in /etc. In order to be able to ship configs as packages, support for having configs in /usr is desireable as well. Any chance to simplement /usr/etc support? -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1221429] New: Presence dialog for ssh id_ed25519_sk keys not showing up
by bugzilla_noreply＠suse.com 21 Jan '25

21 Jan '25

https://bugzilla.suse.com/show_bug.cgi?id=1221429 Bug ID: 1221429 Summary: Presence dialog for ssh id_ed25519_sk keys not showing up Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE Workspace (Plasma) Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: felix.niederwanger(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- When logging in via ssh using a id_ed25519_sk key (e.g. Yubikey), typically ssh prompts a dialog, prompting the user to push the presence key on the hardware dongle. In Plasma6 when doing ssh against a host that requires this presence button to be pushed, the dialog does not show up. The login still works, ssh just blocks and when I push the button it works, but the confirmation dialog does not show up anymore. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1222473] New: VUL-0: CVE-2024-22189: dnscrypt-proxy: quic-go: memory exhaustion attack against QUIC's connection ID mechanism
by bugzilla_noreply＠suse.com 20 Jan '25

20 Jan '25

https://bugzilla.suse.com/show_bug.cgi?id=1222473 Bug ID: 1222473 Summary: VUL-0: CVE-2024-22189: dnscrypt-proxy: quic-go: memory exhaustion attack against QUIC's connection ID mechanism Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://smash.suse.de/issue/400376/ OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Security Assignee: cunix(a)mail.de Reporter: camila.matos(a)suse.com QA Contact: qa-bugs(a)suse.de CC: camila.matos(a)suse.com, security-team(a)suse.de, smash_bz(a)suse.de Blocks: 1222461 Target Milestone: --- Found By: Security Response Team Blocker: --- +++ This bug was initially created as a clone of Bug #1222461 +++ quic-go is an implementation of the QUIC protocol in Go. Prior to version 0.42.0, an attacker can cause its peer to run out of memory sending a large number of `NEW_CONNECTION_ID` frames that retire old connection IDs. The receiver is supposed to respond to each retirement frame with a `RETIRE_CONNECTION_ID` frame. The attacker can prevent the receiver from sending out (the vast majority of) these `RETIRE_CONNECTION_ID` frames by collapsing the peers congestion window (by selectively acknowledging received packets) and by manipulating the peer's RTT estimate. Version 0.42.0 contains a patch for the issue. No known workarounds are available. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-22189 https://www.cve.org/CVERecord?id=CVE-2024-22189 https://github.com/quic-go/quic-go/commit/4a99b816ae3ab03ae5449d15aac45147c… https://github.com/quic-go/quic-go/security/advisories/GHSA-c33x-xqrf-c478 https://seemann.io/posts/2024-03-19-exploiting-quics-connection-id-manageme… https://www.youtube.com/watch?v=JqXtYcZAtIA&t=3683s https://bugzilla.redhat.com/show_bug.cgi?id=2273513 -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1225863] New: Chromium crashes on startup
by bugzilla_noreply＠suse.com 19 Jan '25

19 Jan '25

https://bugzilla.suse.com/show_bug.cgi?id=1225863 Bug ID: 1225863 Summary: Chromium crashes on startup Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Major Priority: P5 - None Component: Network Assignee: screening-team-bugs(a)suse.de Reporter: dev(a)dominik-schmidt.de QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- After updating openSUSE Tumbleweed the other day Chromium is now crashing for me on startup (i.e. I don't get to see a window at all). My system is completely up to date, I switched all packages from packman to repo-oss. When running Chromium in GDB I can retrieve this backtrace: > 0x000055555e2ec853 in partition_alloc::internal::FreelistCorruptionDetected(unsigned long) () > (gdb) bt > #0 0x000055555e2ec853 in partition_alloc::internal::FreelistCorruptionDetected(unsigned long) () > #1 0x000055555e2fc487 in allocator_shim::internal::PartitionMalloc(allocator_shim::AllocatorDispatch const*, unsigned long, void*) () > #2 0x000055555dc170f2 in base::allocator::dispatcher::internal::DispatcherImpl<base::PoissonAllocationSampler>::AllocFn(allocator_shim::AllocatorDispatch const*, unsigned long, void*) () > #3 0x000055555e2fba1b in malloc () > #4 0x00007ffff36aa75e in strdup () at /lib64/libc.so.6 > #5 0x00007ffff72a7439 in () at /lib64/libfontconfig.so.1 > #6 0x00007ffff72a8f3c in () at /lib64/libfontconfig.so.1 > #7 0x00007ffff72ad2c5 in () at /lib64/libfontconfig.so.1 > #8 0x00007ffff71ce988 in () at /lib64/libexpat.so.1 > #9 0x00007ffff71cb7c4 in () at /lib64/libexpat.so.1 > #10 0x00007ffff71cdc49 in () at /lib64/libexpat.so.1 > #11 0x00007ffff71c2258 in () at /lib64/libexpat.so.1 > #12 0x00007ffff71ca3e5 in XML_ParseBuffer () at /lib64/libexpat.so.1 > #13 0x00007ffff72a97d5 in () at /lib64/libfontconfig.so.1 > #14 0x00007ffff72aa11e in () at /lib64/libfontconfig.so.1 > #15 0x00007ffff72924ef in () at /lib64/libfontconfig.so.1 > #16 0x00007ffff728d5b9 in () at /lib64/libfontconfig.so.1 > #17 0x00007ffff72927d9 in FcInit () at /lib64/libfontconfig.so.1 > #18 0x000055555f0e7a78 in base::NoDestructor<gfx::(anonymous namespace)::GlobalFontConfig>::NoDestructor<>() () > #19 0x000055555f0e7a06 in base::internal::Invoker<base::internal::FunctorTraits<gfx::InitializeGlobalFontConfigAsync()::$_0&&>, base::internal::BindState<false, false, false, gfx::InitializeGlobalFontConfigAsync()::$_0>, void ()>::RunOnce(base::internal::BindStateBase*) () > #20 0x000055555e236f4b in base::TaskAnnotator::RunTaskImpl(base::PendingTask&) () > #21 0x000055555e25aef8 in base::internal::TaskTracker::RunTaskImpl(base::internal::Task&, base::TaskTraits const&, base::internal::TaskSource*, base::internal::SequenceToken const&) () > #22 0x000055555e25afc1 in base::internal::TaskTracker::RunSkipOnShutdown(base::internal::Task&, base::TaskTraits const&, base::internal::TaskSource*, base::internal::SequenceToken const&) () > #23 0x000055555e25abf3 in base::internal::TaskTracker::RunTask(base::internal::Task, base::internal::TaskSource*, base::TaskTraits const&) () > #24 0x000055555e25a717 in base::internal::TaskTracker::RunAndPopNextTask(base::internal::RegisteredTaskSource) () > #25 0x000055555e26d2df in base::internal::WorkerThread::RunWorker() () > #26 0x000055555e26ceaa in base::internal::WorkerThread::RunPooledWorker() () > #27 0x000055555e26cd2a in base::internal::WorkerThread::ThreadMain() () > #28 0x000055555e28a08a in base::(anonymous namespace)::ThreadFunc(void*) () > #29 0x00007ffff3692ba2 in start_thread () at /lib64/libc.so.6 > #30 0x00007ffff371400c in clone3 () at /lib64/libc.so.6 I also tried 125.0.6422.141-1965.1-x86_64 from network:chromium/chromium, but it shows the same behavior. As it looks related to fontconfig, I ran > fc-cache -f -v as user and root with no success either. Happy to provide any additional system information, logs, outputs... Thanks in advance -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1222505] New: ckermit: cannot create lock file in /var/lock
by bugzilla_noreply＠suse.com 17 Jan '25

17 Jan '25

https://bugzilla.suse.com/show_bug.cgi?id=1222505 Bug ID: 1222505 Summary: ckermit: cannot create lock file in /var/lock Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: ceggers(a)arri.de QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Kermit needs to create a lock file for the used serial port (e.g. /dev/ttyUSB0) under /var/lock (symlink to /run/lock). Until Leap 15.5, that directory was owned by group "lock", so it was sufficient to add the current user to the "lock" group. But now the directory is owned by group "root", so using the "lock" group is not sufficient anymore. Reproducible: Always Steps to Reproduce: 1. Add current user to "dialout" group (and create re-login after that). 2. Ensure that step 1. was successful (e.g. by using the "id" command). 3. kermit -l /dev/ttyUSB0 Actual Results: Kermit gives an error "can't open device". Using "set line /dev/ttyUSB0" in kermit's interactive mode gives a more precise error message: "Sorry, write access to UUCP lockfile directory denied." Expected Results: kermit should have created the lock file and open /dev/ttyUSB0 A workaround is to change the group of /run/lock to "dialout" (and to add the current user to this group). But this change is lost after every reboot. Possibly related to https://bugzilla.opensuse.org/show_bug.cgi?id=624290 ("ckermit from contrib repository does not use lockdev, so cannot write to /var/lock"). The packet installed is: $ rpm -q ckermit --info Name : ckermit Version : 9.0.302 Release : 150000.3.3.1 Architecture: x86_64 Install Date: Mo 08 Apr 2024 09:44:42 CEST Group : Hardware/Modem Size : 2621762 License : BSD-3-Clause Signature : RSA/SHA256, Fr 01 Apr 2022 13:39:36 CEST, Key ID 70af9e8139db7c82 Source RPM : ckermit-9.0.302-150000.3.3.1.src.rpm Build Date : Fr 01 Apr 2022 13:39:14 CEST Build Host : goat10 Relocations : (not relocatable) Packager : https://www.suse.com/ Vendor : SUSE LLC <https://www.suse.com/> URL : http://www.kermitproject.org/ Summary : A Combined Serial and Network Communication Software Package Description : C-Kermit is a combined serial and network communication software package offering a consistent, medium-independent, and cross-platform approach to connection establishment, terminal sessions, file transfer, character-set translation, and automation of communication tasks. Distribution: SUSE Linux Enterprise 15 -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1226392] New: lxqt-config-monitor crashes with kscreen on login, wakeup, launch
by bugzilla_noreply＠suse.com 17 Jan '25

17 Jan '25

https://bugzilla.suse.com/show_bug.cgi?id=1226392 Bug ID: 1226392 Summary: lxqt-config-monitor crashes with kscreen on login, wakeup, launch Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: LXQt Assignee: lxqt-bugs(a)suse.de Reporter: brbigam(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- lxqt-config-monitor crashes on every login, every wake from sleep, and every user launch of the settings module. It segfaults and coredumps, with kscreen. Steps to Reproduce Log in to an LXQt session, or wake from sleep within one (not just from screen lock) OR open l-c-monitor Check journalctl and look in /var/lib/systemd/coredump/ folder See the coredump and sefault reports from those times Expected Behavior l-c-monitor doesn't crash and coredump in any standard usage. If kscreen crashes, l-c-monitor errors rather than crashing and coredumping. Current Behavior I don't have any particular need for l-c-monitor, since I use only one monitor, my laptop display. But opening it shows a window that's blank as if there's no detected display, and when I close it, it and kscreen segfault and coredump. If I check journalctl, it shows similar segfaults and coredumps for l-c-monitor on my user session login or wake from sleep, and the coredumps pile up in /var/lib/systemd/coredump/ Since there's no user-facing option to disable l-c-monitor, the coredumps just keep piling up. System Information Distribution & Version: openSUSE Tumbleweed 20240612 Kernel: 6.9.3 Qt Version: 6.7.1 liblxqt Version: 2.0.0 lxqt-build-tools Version: not installed Package version: lxqt-config 2.0.0; libkf6screen8 6.0.5 Openbox Other info: I wish there was a UI option to disable l-c-monitor. This bug has also been filed upstream: https://github.com/lxqt/lxqt-config/issues/1004 -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1225509] New: AUDIT-FIND: 4Pane: predictable /tmp path in PreviewPopup::DisplayImage
by bugzilla_noreply＠suse.com 16 Jan '25

16 Jan '25

https://bugzilla.suse.com/show_bug.cgi?id=1225509 Bug ID: 1225509 Summary: AUDIT-FIND: 4Pane: predictable /tmp path in PreviewPopup::DisplayImage Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: security-team(a)suse.de Reporter: wolfgang.frisch(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- 4Pane uses predictable /tmp paths in PreviewPopup::DisplayImage() > 2054 pngfilepath = "/tmp/" + fn.GetName() + ".png"; > 2055 if (SvgToPng(filepath, pngfilepath, handle)) > 2056 image = wxImage(pngfilepath); > 2057 wxRemoveFile(pngfilepath); If fs.protected_symlinks=1, an unprivileged user can prevent 4Pane from displaying previews for SVG images. If fs.protected_symlinks=0, an unprivileged user can overwrite arbitrary world-readable files owned by the 4Pane user. Steps to reproduce: nobody@localhost:/tmp> ln -s /home/user/somefile foo.png # ... wait until the user previews a file named foo.svg # somefile will be overwritten An attacker can pre-create symlinks for the names of all existing SVG files on the system to increase the likelihood of triggering the bug. -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1223420] New: VUL-0: CVE-2024-31755: cJSON: NULL pointer dereference via cJSON_SetValuestring()
by bugzilla_noreply＠suse.com 15 Jan '25

15 Jan '25

https://bugzilla.suse.com/show_bug.cgi?id=1223420 Bug ID: 1223420 Summary: VUL-0: CVE-2024-31755: cJSON: NULL pointer dereference via cJSON_SetValuestring() Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: Other URL: https://smash.suse.de/issue/403222/ OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Security Assignee: mardnh(a)gmx.de Reporter: smash_bz(a)suse.de QA Contact: security-team(a)suse.de CC: carlos.lopez(a)suse.com Target Milestone: --- Found By: Security Response Team Blocker: --- cJSON v1.7.17 was discovered to contain a segmentation violation, which can trigger through the second parameter of function cJSON_SetValuestring at cJSON.c. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-31755 https://www.cve.org/CVERecord?id=CVE-2024-31755 https://github.com/DaveGamble/cJSON/issues/839 https://bugzilla.redhat.com/show_bug.cgi?id=2277268 -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1226110] New: After plasma upgrade sessions are no longer saved and restored when logging out
by bugzilla_noreply＠suse.com 14 Jan '25

14 Jan '25

https://bugzilla.suse.com/show_bug.cgi?id=1226110 Bug ID: 1226110 Summary: After plasma upgrade sessions are no longer saved and restored when logging out Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE Workspace (Plasma) Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: jhtaylor20(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- After the plasma upgrade to plasma5-workspace|5.27.9-bp155.2.6.1 on 06/06/24 sessions are no longer saved on logging out or restored on logging back in. Login comes up with an empty session. Changing Desktop Session from "on last logout" to something else and back makes no difference. Although I don't use it "When sessions was manually saved" does not seem to be working correctly either. If you check it and log out with two kconsole windows open when you log back in it asks for roots password for both and opens them as root instead of the user. -- You are receiving this mail because: You are on the CC list for the bug.

1 23

[Bug 1221095] New: Go application packages can no longer set CGO_ENABLED=0 if external linker will be used
by bugzilla_noreply＠suse.com 14 Jan '25

14 Jan '25

https://bugzilla.suse.com/show_bug.cgi?id=1221095 Bug ID: 1221095 Summary: Go application packages can no longer set CGO_ENABLED=0 if external linker will be used Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Development Assignee: screening-team-bugs(a)suse.de Reporter: jkowalczyk(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Per Go upstream change https://go-review.googlesource.com/c/website/+/569296, as of go1.21.8+ and go1.22.1+ go build commands cannot set CGO_ENABLED=0 if the external linker will be used. (Cgo lets Go packages call C code, see https://go.dev/blog/cgo, 2011) The most commonly used option that triggers the external linker is -buildmode=pie, which we aspirationally use in most Go application packages behind conditionals for architectures where it is unsupported, currently only ppc64le. We first encountered this issue when trying to set the go metapackage from go1.21 to go1.22. Approximately 40+ Go application packages in Factory set CGO_ENABLED=0 and -buildmode=pie together. On arch i586, builds started to fail with error: -buildmode=pie requires external (cgo) linking, but cgo is not enabled This tracking bug will be referenced for SR submissions to Go application packages to adapt to the new requirements. Most of these submissions will to remove CGO_ENABLED=0 absent a requirement for its use by a specific package. Upstream comments from the above change: https://go.dev/issue/31544, CL 477839 When using an external (C) linker with cgo enabled, the `runtime/cgo` package is now supplied to the Go linker as an additional dependency to ensure that the Go runtime is compatible with any additional libraries added by the C linker. https://go.dev/issue/46330, CL 522239 go build commands that invoke the linker now error out if an external (C) linker will be used but cgo is not enabled. (The Go runtime requires cgo support to ensure that it is compatible with any additional libraries added by the C linker.) -- You are receiving this mail because: You are on the CC list for the bug.

1 3