January 2024 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1213659] New: VUL-0: CVE-2023-38496: apptainer: Ineffective privileges drop when requesting container network
by bugzilla_noreply＠suse.com 22 Jul '24

22 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1213659 Bug ID: 1213659 Summary: VUL-0: CVE-2023-38496: apptainer: Ineffective privileges drop when requesting container network Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: Other URL: https://smash.suse.de/issue/373431/ OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: cgoll(a)suse.com Reporter: gianluca.gabrielli(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Apptainer is an open source container platform. Version 1.2.0-rc.2 introduced an ineffective privilege drop when requesting container network setup, therefore subsequent functions are called with root privileges, the attack surface is rather limited for users but an attacker could possibly craft a starter config to delete any directory on the host filesystems. A security fix has been included in Apptainer 1.2.1. There is no known workaround outside of upgrading to Apptainer 1.2.1. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-38496 https://bugzilla.redhat.com/show_bug.cgi?id=2226582 https://www.cve.org/CVERecord?id=CVE-2023-38496 http://www.cvedetails.com/cve/CVE-2023-38496/ https://github.com/apptainer/apptainer/pull/1523 https://github.com/apptainer/apptainer/pull/1578 https://github.com/apptainer/apptainer/security/advisories/GHSA-mmx5-32m4-w… -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1218581] New: Version of mesa and mesa-drivers different
by bugzilla_noreply＠suse.com 20 Jul '24

20 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1218581 Bug ID: 1218581 Summary: Version of mesa and mesa-drivers different Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: Other OS: SUSE Other Status: NEW Severity: Normal Priority: P5 - None Component: X.Org Assignee: gfx-bugs(a)suse.de Reporter: ecsos(a)schirra.net QA Contact: gfx-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Version of mesa and mesa-drivers different. This means that not a single package can be built in the build service that mesa requires. Message in OBS: The build can not begin, because required packages are either missing or not explicitly defined. Build jobs exist for the repository unresolvable: nothing provides Mesa = 22.3.5 needed by Mesa-dri, (got version 23.3.2-lp156.1520.1) -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1218387] New: VUL-0: CVE-2023-51766: exim: SMTP smuggling attack
by bugzilla_noreply＠suse.com 20 Jul '24

20 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1218387 Bug ID: 1218387 Summary: VUL-0: CVE-2023-51766: exim: SMTP smuggling attack Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: Other URL: https://smash.suse.de/issue/389285/ OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: poeml(a)cmdline.net Reporter: smash_bz(a)suse.de QA Contact: security-team(a)suse.de CC: meissner(a)suse.com Target Milestone: --- Found By: Security Response Team Blocker: --- Exim through 4.97 allows SMTP smuggling in certain configurations. Remote attackers can use a published exploitation technique to inject e-mail messages that appear to originate from the Exim server, allowing bypass of an SPF protection mechanism. This occurs because Exim supports <LF>.<CR><LF> but some other popular e-mail servers do not. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-51766 -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1217414] New: changing default umask for new users homedir sets the current umask for ALL users including root
by bugzilla_noreply＠suse.com 19 Jul '24

19 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1217414 Bug ID: 1217414 Summary: changing default umask for new users homedir sets the current umask for ALL users including root Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: joergboe44(a)googlemail.com QA Contact: jsrain(a)suse.com Target Milestone: --- Found By: --- Blocker: --- When I change the default umask for new users home dir, the umask for all users (including root) is changed after login. This is not what I expect and may be dangerousö. OS version: openSUSE Tumbleweed 20231121 Steps to reproduce: 1. Check the umask setting for a user or root: su --login test2 Password: test2@localhost:~> umask 0022 2. Change the umask for home directory of new users: Yast->User and group management->Defaults for new users: Change umask for home directory to 002 3. Login as a user or root e.g 'su --login' su --login test2 Password: test2@localhost:~> umask 0002 The umask is changed for all users. This bug is almost the same as in Bugzilla – Bug 606249. But the behavior is obviously changed since then. In the current Tumbleweed version the YAST changes the UMASK in file /etc/login.defs.d/70-yast.defs And this seems to be enough to change the umask for the next login. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1217306] New: distrobox stuck at starting container
by bugzilla_noreply＠suse.com 18 Jul '24

18 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1217306 Bug ID: 1217306 Summary: distrobox stuck at starting container Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Containers Assignee: containers-bugowner(a)suse.de Reporter: lubos.kocman(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 870843 --> https://bugzilla.suse.com/attachment.cgi?id=870843&action=edit few seconds of strace -p 5212 2>&1 | tee /tmp/strace-out.log Following happened on Leap 15.6 lkocman@localhost:~/Workspace> distrobox enter mirror Error: no such container mirror Cannot find container mirror Creating the container with command: /usr/bin/distrobox-create -i registry.opensuse.org/opensuse/distrobox:latest -n mirror Trying to pull registry.opensuse.org/opensuse/distrobox:latest... Getting image source signatures Copying blob 942e611a39d7 done Copying blob 1517c1ea8bb6 done Copying config 8372decf75 done Writing manifest to image destination 8372decf752e74665fcb94d31b9b378dd1790233ab36b03d37f63dac462e0fbc Creating 'mirror' using image registry.opensuse.org/opensuse/distrobox:latest [ OK ] Distrobox 'mirror' successfully created. To enter, run: distrobox enter mirror Container mirror is not running. Starting container mirror run this command to follow along: podman logs -f mirror Starting container... # Stuck here for 30 minutes or so lkocman@localhost:~/Workspace> ps aux | grep distro lkocman 5210 0.0 0.0 11096 3328 pts/0 S+ 08:13 0:00 /bin/sh /usr/bin/distrobox enter mirror lkocman 5212 2.1 0.0 11224 3840 pts/0 S+ 08:13 0:53 /bin/sh /usr/bin/distrobox-enter mirror lkocman 27424 0.0 0.0 8212 2304 pts/1 S+ 08:56 0:00 grep --color=auto distro Strace seems that the program itself is busy Not sure if this isn't an issue rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=27782, si_uid=1000, si_status=0, si_utime=2, si_stime=0} --- wait4(-1, 0x7ffc3cd5bbd0, WNOHANG, NULL) = -1 ECHILD (No child processes) rt_sigreturn({mask=[]}) = 0 openat(AT_FDCWD, "/home/lkocman/.cache/.mirror.fifo", O_RDONLY) = 3 fcntl(0, F_GETFD) = 0 fcntl(0, F_DUPFD, 10) = 10 fcntl(0, F_GETFD) = 0 fcntl(10, F_SETFD, FD_CLOEXEC) = 0 dup2(3, 0) = 0 close(3) = 0 ioctl(0, TCGETS, 0x7ffc3cd5c4f0) = -1 ENOTTY (Inappropriate ioctl for device) -- You are receiving this mail because: You are on the CC list for the bug.

1 22

[Bug 1218122] New: Aeon: Unable to load any usable ISO8859 font
by bugzilla_noreply＠suse.com 17 Jul '24

17 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1218122 Bug ID: 1218122 Summary: Aeon: Unable to load any usable ISO8859 font Classification: openSUSE Product: openSUSE Aeon Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Base Assignee: rbrown(a)suse.com Reporter: alexlevinb(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:120.0) Gecko/20100101 Firefox/120.0 Build Identifier: I am getting Unable to load any usable ISO8859 font error when installing Veracrypt with ./veracrypt-1.26.7-setup-gtk3-gui-x64 Same error when running xmessage test: alex@dell-desktop:~> xmessage test Warning: Unable to load any usable ISO8859 font Error: Aborting: no font found I am getting the sam Reproducible: Always Steps to Reproduce: Run xmessage test -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1213595] New: Live ISO does not creates Persistent storage
by bugzilla_noreply＠suse.com 16 Jul '24

16 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1213595 Bug ID: 1213595 Summary: Live ISO does not creates Persistent storage Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: x86-64 OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Live Medium Assignee: fvogt(a)suse.com Reporter: sehsuvarselmanoglu(a)hotmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 868398 --> https://bugzilla.suse.com/attachment.cgi?id=868398&action=edit 7z File for some logs Hi, I downloaded OpenSUSE Leap ISO (openSUSE-Leap-15.5-KDE-Live-x86_64-Build10.40-Media.iso) at 08/06/2023 (as soon as released) then I “dd” to USB stick and plugged to computer and it worked fine. At first boot, it did create the persistent storage cow (boot.log : [ 22.002982] dracut-initqueue[877]: mke2fs 1.46.4 (18-Aug-2021) ) Few days later I download again this time build number was different (openSUSE-Leap-15.5-KDE-Live-x86_64-Build10.57-Media.iso). At first boot, it did not create persistent storage. dracut says (boot.log : [ 21.489260] dracut-initqueue[769]: Warning: Falling back to temporary overlay) same as the new release (openSUSE-Leap-15.5-KDE-Live-x86_64-Build10.73-Media.iso) Any release after 10.40 does not creates persistent storage (neither 10.53 nor 10.73) I tried with different CPU (AMD, Core Duo, I5) and different USB stick (4GB 8GB 16GB and 32GB) even with different port (USB2 USB3) with different USB s and so on. No matter what I tried don't work. Releases after 10.40 (10.57 or 10.73) do not creates the persistent storage. So I open discussion on the forums.opensuse.org and someone suggested that I need to open bug report. and he/she wrote "It is not something you can fix without recreating initrd. The script that is used here comes from kiwi dracut module.". I also add the 7zip file for each ISO "....10.40", "...10.57", "...10.73" that contains some log files. "boot.log" : "sudo cp /var/log/boot.log" "boot.msg" : "cp /var/log/boot.msg" "dmesg.txt" : Output of "dmesg" right after the first boot "fdisk.txt" : 0utput of "fdisk -l" right after first boot "journal.txt" : Output of "sudo journalctl --no-pager --full -b" Thank you very much. -- You are receiving this mail because: You are on the CC list for the bug.

1 14

[Bug 1214353] New: mhi: Enabling broadband connecting not working
by bugzilla_noreply＠suse.com 16 Jul '24

16 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1214353 Bug ID: 1214353 Summary: mhi: Enabling broadband connecting not working Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: x86-64 OS: openSUSE Leap 15.5 Status: NEW Severity: Normal Priority: P5 - None Component: Network Assignee: screening-team-bugs(a)suse.de Reporter: holgi(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 868851 --> https://bugzilla.suse.com/attachment.cgi?id=868851&action=edit hwinfo.txt When trying to use broadband connecting with network manager, I can not get beyond entering SIM code - starting connection does not work System Slot: #36 Designation: "M.2 WWAN Connector (J3702)" Type: 0xa6 (Other) Bus Width: 0x08 (Other) Status: 0x03 (Available) Length: 0x04 (Long) Slot ID: 4 Characteristics: 0x0704 (3.3 V, PME#, Hot-Plug) -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[Bug 1214364] New: net-snmp: new release 5.9.4
by bugzilla_noreply＠suse.com 09 Jul '24

09 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1214364 Bug ID: 1214364 Summary: net-snmp: new release 5.9.4 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: abergmann(a)suse.com Reporter: abergmann(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- https://github.com/net-snmp/net-snmp/blob/v5.9.4/CHANGES *5.9.4*: IMPORTANT: SNMP over TLS and/or DTLS are not functioning properly in this release with various versions of OpenSSL and will be fixed in a future release. libsnmp: - Remove the SNMP_SWIPE_MEM() macro Remove this macro since it is not used in the Net-SNMP code base. - DISPLAY-HINT fixes - Miscellanious improvements to the transports - Handle multiple oldEngineID configuration lines - fixes for DNS names longer than 63 characters agent: - Added a ignoremount configuration option for the HOST-MIB - disallow SETs with a NULL varbind - fix the --enable-minimalist build apps: - snmpset: allow SET with NULL varbind for testing - snmptrapd: improved MySQL logging code general: - configure: Remove -Wno-deprecated as it is no longer needed - miscellanious ther bug fixes, build fixes and cleanups -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 1217688] New: mariadb: a table is missing inserted entries from concurrent processes
by bugzilla_noreply＠suse.com 08 Jul '24

08 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1217688 Bug ID: 1217688 Summary: mariadb: a table is missing inserted entries from concurrent processes Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://jira.mariadb.org/browse/MDEV-32871 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: danilo.spinella(a)suse.com Reporter: jslaby(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 871082 --> https://bugzilla.suse.com/attachment.cgi?id=871082&action=edit db inserter With mariadb: 11.0.2, 11.1.2 and 11.1.3 (from server:database): From my c++ code, using connector-c, I do: SET autocommit=0 CREATE TABLE IF NOT EXISTS sources(id INTEGER AUTO_INCREMENT PRIMARY KEY, src VARCHAR(1024) NOT NULL UNIQUE) INSERT IGNORE INTO sources(src) VALUES (?) START TRANSACTION And then a lot of: INSERT IGNORE INTO sources(src) VALUES ('src-003431-00001') src is composed of pid and values from 0 to 49. So they are all unique. Finally, I do: COMMIT If I run 10 instances in parallel like: for aa in {1..10} ; do ./db & done ; wait I see: select count(id), substr(src,5,6) as sss from sources group by sss; +-----------+--------+ | count(id) | sss | +-----------+--------+ | 50 | 003430 | | 50 | 003431 | | 50 | 003432 | | 40 | 003433 | | 50 | 003434 | | 50 | 003435 | | 50 | 003436 | | 50 | 003437 | | 50 | 003438 | | 50 | 003439 | +-----------+--------+ I.e. Some of pids stored only last 40 values, numbers 0..9 are missing in the table: select src from sources where src like '%003433%' order by src ; +------------------+ | src | +------------------+ | src-003433-00010 | | src-003433-00011 | | src-003433-00012 | | src-003433-00013 | | src-003433-00014 | | src-003433-00015 | | src-003433-00016 | | src-003433-00017 | | src-003433-00018 | | src-003433-00019 | | src-003433-00020 | | src-003433-00021 | | src-003433-00022 | | src-003433-00023 | | src-003433-00024 | | src-003433-00025 | | src-003433-00026 | | src-003433-00027 | | src-003433-00028 | | src-003433-00029 | | src-003433-00030 | | src-003433-00031 | | src-003433-00032 | | src-003433-00033 | | src-003433-00034 | | src-003433-00035 | | src-003433-00036 | | src-003433-00037 | | src-003433-00038 | | src-003433-00039 | | src-003433-00040 | | src-003433-00041 | | src-003433-00042 | | src-003433-00043 | | src-003433-00044 | | src-003433-00045 | | src-003433-00046 | | src-003433-00047 | | src-003433-00048 | | src-003433-00049 | +------------------+ Is this a bug in my program (attached) or the db? If I look into the general log, I see the inserts which apparently did not get into the table: grep src-003433 /tmp/glog 24 Execute INSERT IGNORE INTO sources(src) VALUES ('src-003433-00000') 24 Execute INSERT IGNORE INTO sources(src) VALUES ('src-003433-00000') 24 Execute INSERT IGNORE INTO sources(src) VALUES ('src-003433-00000') 24 Execute INSERT IGNORE INTO sources(src) VALUES ('src-003433-00000') 24 Execute INSERT IGNORE INTO sources(src) VALUES ('src-003433-00000') 24 Execute INSERT IGNORE INTO sources(src) VALUES ('src-003433-00001') 24 Execute INSERT IGNORE INTO sources(src) VALUES ('src-003433-00002') 24 Execute INSERT IGNORE INTO sources(src) VALUES ('src-003433-00003') 24 Execute INSERT IGNORE INTO sources(src) VALUES ('src-003433-00004') 24 Execute INSERT IGNORE INTO sources(src) VALUES ('src-003433-00005') 24 Execute INSERT IGNORE INTO sources(src) VALUES ('src-003433-00006') 24 Execute INSERT IGNORE INTO sources(src) VALUES ('src-003433-00007') 24 Execute INSERT IGNORE INTO sources(src) VALUES ('src-003433-00008') 24 Execute INSERT IGNORE INTO sources(src) VALUES ('src-003433-00009') 24 Execute INSERT IGNORE INTO sources(src) VALUES ('src-003433-00010') 24 Execute INSERT IGNORE INTO sources(src) VALUES ('src-003433-00010') 24 Execute INSERT IGNORE INTO sources(src) VALUES ('src-003433-00011') 24 Execute INSERT IGNORE INTO sources(src) VALUES ('src-003433-00012') Note also the repeated inserts. They come from a deadlock, so I repeat the exec in a loop (see the code). Dockers with mariadb:latest (11.2.2) mariadb:11.1.3 mariadb:11.1.2 all run FINE too. -- You are receiving this mail because: You are on the CC list for the bug.

1 14