From rep.dot.nop at gmail.com Sat Mar 2 16:03:37 2024 From: rep.dot.nop at gmail.com (Bernhard Reutner-Fischer) Date: Sat, 2 Mar 2024 17:03:37 +0100 Subject: [git commit] awk: fix segfault when compiled by clang Message-ID: <20240302160636.E190D87E1A@busybox.osuosl.org> commit: https://git.busybox.net/busybox/commit/?id=e1a68741067167dc4837e0a26d3d5c318a631fc7 branch: https://git.busybox.net/busybox/commit/?id=refs/heads/master A 32-bit build of BusyBox using clang segfaulted in the test "awk assign while assign". Specifically, on line 7 of the test input where the adjustment of the L.v pointer when the Fields array was reallocated L.v += Fields - old_Fields_ptr; was out by 4 bytes. Rearrange to code so both gcc and clang generate code that works. Signed-off-by: Ron Yorston Signed-off-by: Bernhard Reutner-Fischer --- editors/awk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/editors/awk.c b/editors/awk.c index aa485c782..0981c6735 100644 --- a/editors/awk.c +++ b/editors/awk.c @@ -3006,7 +3006,7 @@ static var *evaluate(node *op, var *res) if (old_Fields_ptr) { //if (old_Fields_ptr != Fields) // debug_printf_eval("L.v moved\n"); - L.v += Fields - old_Fields_ptr; + L.v = Fields + (L.v - old_Fields_ptr); } if (opinfo & OF_STR2) { R.s = getvar_s(R.v); From rep.dot.nop at gmail.com Sat Mar 2 16:03:37 2024 From: rep.dot.nop at gmail.com (Bernhard Reutner-Fischer) Date: Sat, 2 Mar 2024 17:03:37 +0100 Subject: [git commit] crond: log5 fix typo, replace log level '4' with '5' Message-ID: <20240302160636.D2E9287E17@busybox.osuosl.org> commit: https://git.busybox.net/busybox/commit/?id=01f2b5976d03fb50229d28297cf5ebd8be533203 branch: https://git.busybox.net/busybox/commit/?id=refs/heads/master log5() with crondlog(5, msg, va) seems making logging more consistent. function old new delta ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0) Total: 0 bytes Signed-off-by: Jones Syue Signed-off-by: Bernhard Reutner-Fischer --- miscutils/crond.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/miscutils/crond.c b/miscutils/crond.c index 3bbb5ac83..b3762d327 100644 --- a/miscutils/crond.c +++ b/miscutils/crond.c @@ -190,7 +190,7 @@ static void log5(const char *msg, ...) { va_list va; va_start(va, msg); - crondlog(4, msg, va); + crondlog(5, msg, va); va_end(va); } From bugzilla at busybox.net Sun Mar 3 16:02:03 2024 From: bugzilla at busybox.net (bugzilla at busybox.net) Date: Sun, 03 Mar 2024 16:02:03 +0000 Subject: [Bug 15679] wget with amazon.com fails with TLS handshake failure on Debian 12 In-Reply-To: References: Message-ID: https://bugs.busybox.net/show_bug.cgi?id=15679 --- Comment #2 from Ron Yorston --- The problem seems to be with the x86_64 assembly language code for sp_256_sub_8_p256_mod() in networking/tls_sp_c32.c. If I use the C code instead, wget works. Unfortunately I don't speak x86_64 assembly language, so I've no idea what the real problem is. -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla at busybox.net Mon Mar 4 14:45:29 2024 From: bugzilla at busybox.net (bugzilla at busybox.net) Date: Mon, 04 Mar 2024 14:45:29 +0000 Subject: [Bug 15967] New: The wget applet leaks defunct ssl_client processes when requesting https pages Message-ID: https://bugs.busybox.net/show_bug.cgi?id=15967 Bug ID: 15967 Summary: The wget applet leaks defunct ssl_client processes when requesting https pages Product: Busybox Version: 1.31.x Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 Component: Other Assignee: unassigned at busybox.net Reporter: mail at alessandrodistefano.eu CC: busybox-cvs at busybox.net Target Milestone: --- When running busybox wget in a docker container to request an SSL page, there is a leak of defunct ssl_client processes. Version: amd64 v1.31.1 tested in the alpine:3.19,3.18.3.16 and ubuntu:latest images from Docker Hub arm64 v1.31.1 tested in the alpine:3.19 Steps to reproduce 1. docker run --name mycontainer -it --rm alpine:3.19 /bin/sleep inf 2. docker exec -it mycontainer ps aux PID USER TIME COMMAND 1 root 0:00 /bin/sleep inf 7 root 0:00 ps aux 3. docker exec -it mycontainer wget https://google.com 4. docker exec -it mycontainer ps aux PID USER TIME COMMAND 1 root 0:00 /bin/sleep inf 19 root 0:00 [ssl_client] 20 root 0:00 [ssl_client] 21 root 0:00 ps aux Additional info: If the container's PID1 is /bin/sh (i.e., docker run -it --name mycontainer alpine:3.19 /bin/sh), the issue is not reproducible (because it handles SIGCHLD?). -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla at busybox.net Tue Mar 5 11:27:16 2024 From: bugzilla at busybox.net (bugzilla at busybox.net) Date: Tue, 05 Mar 2024 11:27:16 +0000 Subject: [Bug 15970] New: ash: "wait -n" does not return when first pid exits Message-ID: https://bugs.busybox.net/show_bug.cgi?id=15970 Bug ID: 15970 Summary: ash: "wait -n" does not return when first pid exits Product: Busybox Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: Other Assignee: unassigned at busybox.net Reporter: bastian at bastian-friedrich.de CC: busybox-cvs at busybox.net Target Milestone: --- Hi, busybox 1.31 introduced the bashism "wait -n". However, that command does not behave the way I expect it to. Bash's "wait -n" will return when the *first* pid returns; this is not the case for the busybox ash. In bash, the following script prints "5". In busybox ash, it prints "10". ``` #!/bin/sh sleep 5 & pid1=$! sleep 10 & pid2=$! before=$(date +%s) wait -n $pid1 $pid2 after=$(date +%s) duration=$(( after - before )) echo $duration ``` -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla at busybox.net Wed Mar 6 21:02:25 2024 From: bugzilla at busybox.net (bugzilla at busybox.net) Date: Wed, 06 Mar 2024 21:02:25 +0000 Subject: [Bug 15216] There is a stack overflower in ash of busybox. Here is asan report. In-Reply-To: References: Message-ID: https://bugs.busybox.net/show_bug.cgi?id=15216 --- Comment #4 from John Ata --- I am still getting a segault on busybox 1.36.1 running the expression "echo ${0::0/0~09J}" on busybox ash built on Linux (e.g. Centos 7) with the following configuration MATH variables turned off and the other MATH variables turned on: CONFIG_FEATURE_SH_MATH_64 is not set CONFIG_FEATURE_SH_MATH_BASE is not set It seems that perhaps the fix is not comprehensively complete. If these MATH variables are turned on along with the other MATH variables, there is no problem. We seem to be claiming that CVE-2022-48174 does not exist in 1.36.1 (fixed in 1.35). But this does not seem to be necessarily true. -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla at busybox.net Wed Mar 6 21:49:18 2024 From: bugzilla at busybox.net (bugzilla at busybox.net) Date: Wed, 06 Mar 2024 21:49:18 +0000 Subject: [Bug 15216] There is a stack overflower in ash of busybox. Here is asan report. In-Reply-To: References: Message-ID: https://bugs.busybox.net/show_bug.cgi?id=15216 --- Comment #5 from John Ata --- It seems that 1.36.1 did not have the patch that fixes the problem even though the bug was marked as resolved fixed. I suspect that the various symbol definitions just moved things on the stack to sometimes cause problems with the incorrect allocation size. So I wonder why the CVE was marked as fixed in 1.35. -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla at busybox.net Mon Mar 11 11:07:38 2024 From: bugzilla at busybox.net (bugzilla at busybox.net) Date: Mon, 11 Mar 2024 11:07:38 +0000 Subject: [Bug 15967] The wget applet leaks defunct ssl_client processes when requesting https pages In-Reply-To: References: Message-ID: https://bugs.busybox.net/show_bug.cgi?id=15967 --- Comment #1 from Natanael Copa --- This is the docker pid 1 and zombies problem. In linux pid 1 is special and is expected to reap orphaned child processes. The pid 1 (bin/sleep) is not doing this. The fix is to add --init to docker run: $ docker run --init --name mycontainer -it --rm alpine:3.19 /bin/sleep inf -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla at busybox.net Mon Mar 11 11:16:11 2024 From: bugzilla at busybox.net (bugzilla at busybox.net) Date: Mon, 11 Mar 2024 11:16:11 +0000 Subject: [Bug 15982] New: wget https://netfilter.org fails due to missing 'Accept:' header Message-ID: https://bugs.busybox.net/show_bug.cgi?id=15982 Bug ID: 15982 Summary: wget https://netfilter.org fails due to missing 'Accept:' header Product: Busybox Version: 1.36.x Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 Component: Networking Assignee: unassigned at busybox.net Reporter: ncopa at alpinelinux.org CC: busybox-cvs at busybox.net Target Milestone: --- $ busybox wget https://netfilter.org Connecting to netfilter.org ([2001:4b98:dc0:43:216:3eff:fe87:a456]:443) wget: server returned error: HTTP/1.1 403 Forbidden GNU wget works: $ wget https://netfilter.org --2024-03-11 12:13:00-- https://netfilter.org/ Resolving netfilter.org (netfilter.org)... 2001:4b98:dc0:43:216:3eff:fe87:a456, 92.243.18.11 Connecting to netfilter.org (netfilter.org)|2001:4b98:dc0:43:216:3eff:fe87:a456|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 21803 (21K) [text/html] Saving to: 'index.html' index.html 100%[==================================>] 21.29K --.-KB/s in 0.04s 2024-03-11 12:13:00 (542 KB/s) - 'index.html' saved [21803/21803] Adding --header 'Accept: */*' makes busybox wget work as well: $ busybox wget --header 'Accept: */*' h ttps://netfilter.org Connecting to netfilter.org ([2001:4b98:dc0:43:216:3eff:fe87:a456]:443) saving to 'index.html' index.html 100% |****************************************************| 21803 0:00:00 ETA 'index.html' saved Both GNU wget and curl adds 'Accept: */*'. -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla at busybox.net Mon Mar 11 22:08:23 2024 From: bugzilla at busybox.net (bugzilla at busybox.net) Date: Mon, 11 Mar 2024 22:08:23 +0000 Subject: [Bug 15985] New: tar with multiple -C incorrectly processes them Message-ID: https://bugs.busybox.net/show_bug.cgi?id=15985 Bug ID: 15985 Summary: tar with multiple -C incorrectly processes them Product: Busybox Version: unspecified Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 Component: Standard Compliance Assignee: unassigned at busybox.net Reporter: yuriastrakhan at gmail.com CC: busybox-cvs at busybox.net Target Milestone: --- The standard tar can take multiple `-C` params (change dir before compressing), so if I have multiple files in multiple dirs, I can tar them all by prepending each subset of files with their directory: ``` tar -czf newfile.tar.gz \ -C $PWD/dir1 file1 file2 \ -C $PWD/dir2 file3 file4 ``` Busybox tar ignores all but the last `-C`, which results in `file1` and `file2` not found. -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla at busybox.net Tue Mar 12 10:59:37 2024 From: bugzilla at busybox.net (bugzilla at busybox.net) Date: Tue, 12 Mar 2024 10:59:37 +0000 Subject: [Bug 15967] The wget applet leaks defunct ssl_client processes when requesting https pages In-Reply-To: References: Message-ID: https://bugs.busybox.net/show_bug.cgi?id=15967 --- Comment #2 from aleskandro --- Isn't adding --init, i.e., having a parent process with reaping "capabilities", a workaround? Yes, it solves, but shouldn't the wget applet be able to join the ssl_client before it becomes an orphaned process? -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla at busybox.net Wed Mar 13 19:17:33 2024 From: bugzilla at busybox.net (bugzilla at busybox.net) Date: Wed, 13 Mar 2024 19:17:33 +0000 Subject: [Bug 15994] New: findfs reports first match only Message-ID: https://bugs.busybox.net/show_bug.cgi?id=15994 Bug ID: 15994 Summary: findfs reports first match only Product: Busybox Version: 1.36.x Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P5 Component: Other Assignee: unassigned at busybox.net Reporter: bitfreak at yopmail.com CC: busybox-cvs at busybox.net Target Milestone: --- when listing filesystems you can see in this example that "findfs" only lists the first match. root at arm7l:~$ blkid /dev/mmcblk1p1: LABEL="rootfs" UUID="4daf4461-edd1-4e20-9ca8-742ef64cfa05" TYPE="ext4" /dev/mmcblk1p3: LABEL="data" UUID="00fe39aa-8f68-425d-b225-062fa1e1e142" TYPE="ext4" /dev/mmcblk1p2: LABEL="rootfs" UUID="4daf4461-edd1-4e20-9ca8-742ef64cfa05" TYPE="ext4" /dev/mmcblk0p1: LABEL="rootfs" UUID="199ca64f-bd96-4778-ad56-648ff19b66ef" TYPE="ext4" root at arm7l:~$ findfs LABEL=rootfs /dev/mmcblk1p1 root at arm7l:~$ -- You are receiving this mail because: You are on the CC list for the bug.