From bugzilla at busybox.net Thu Aug 3 14:29:49 2023 From: bugzilla at busybox.net (bugzilla at busybox.net) Date: Thu, 03 Aug 2023 14:29:49 +0000 Subject: [Bug 15712] New: setpriv uid/gid support Message-ID: https://bugs.busybox.net/show_bug.cgi?id=15712 Bug ID: 15712 Summary: setpriv uid/gid support Product: Busybox Version: 1.35.x Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 Component: Standard Compliance Assignee: unassigned at busybox.net Reporter: pestaa at pestaa.hu CC: busybox-cvs at busybox.net Target Milestone: --- util-linux variant supports the following options: --ruid set real uid --euid set effective uid --rgid set real gid --egid set effective gid --reuid set real and effective uid --regid set real and effective gid https://github.com/util-linux/util-linux/blob/master/sys-utils/setpriv.1.adoc -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla at busybox.net Fri Aug 4 06:23:49 2023 From: bugzilla at busybox.net (bugzilla at busybox.net) Date: Fri, 04 Aug 2023 06:23:49 +0000 Subject: [Bug 15712] setpriv uid/gid support In-Reply-To: References: Message-ID: https://bugs.busybox.net/show_bug.cgi?id=15712 --- Comment #1 from bitstreamout --- Not to forget ``` --keep-groups Preserve supplementary groups. Only useful in conjunction with --rgid, --egid, or --regid. --init-groups Initialize supplementary groups using initgroups3. Only useful in conjunction with --ruid or --reuid. ``` this in combination is used e.g. in cron jobs as well as in rpm scriplets to create e.g. symbolic links or crate/clean files for system users/groups. -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla at busybox.net Fri Aug 4 08:37:33 2023 From: bugzilla at busybox.net (bugzilla at busybox.net) Date: Fri, 04 Aug 2023 08:37:33 +0000 Subject: [Bug 15712] setpriv uid/gid support In-Reply-To: References: Message-ID: https://bugs.busybox.net/show_bug.cgi?id=15712 bitstreamout changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugzilla.opensuse.o | |rg/show_bug.cgi?id=1212571 -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla at busybox.net Tue Aug 15 04:01:54 2023 From: bugzilla at busybox.net (bugzilla at busybox.net) Date: Tue, 15 Aug 2023 04:01:54 +0000 Subject: [Bug 15724] New: sendmail creating non-RFC-compliant headers with PHP8 Message-ID: https://bugs.busybox.net/show_bug.cgi?id=15724 Bug ID: 15724 Summary: sendmail creating non-RFC-compliant headers with PHP8 Product: Busybox Version: 1.35.x Hardware: All OS: Linux Status: NEW Severity: major Priority: P5 Component: Standard Compliance Assignee: unassigned at busybox.net Reporter: axllent at gmail.com CC: busybox-cvs at busybox.net Target Milestone: --- As of PHP8.0, email headers are separated with a (`\r\n`) rather than (`\n`) as seen in older versions of PHP. This is causing all sorts of issues when used in conjunction with busybox's sendmail implementation in conjunction with an RFC-complaint SMTP server. I am no C expert, but from what I can see, busybox splits lines using xmalloc_fgetline() which trims the trailing `\n` (https://git.busybox.net/busybox/tree/libbb/get_line_from_file.c#n172), and then rebuilds the headers using send_r_n() (https://git.busybox.net/busybox/tree/mailutils/mail.c#n85) which appends a `\r\n` to each line. This results in header lines with a non-RFC-compliant `\r\r\n`. This issue was first raised with with a project of mine (https://github.com/axllent/mailpit/issues/87), which led me to a a PHP bug reported (https://github.com/php/php-src/issues/8086) relating to the same thing. I would have assumed this issue would have been reported to busybox by now, but I can't see any reference to it. Whilst there are some work-arounds, this isn't always an option, so fixing this at the sendmail level is the best approach as that appears to be where the issue is stemming from here. -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla at busybox.net Wed Aug 16 16:59:09 2023 From: bugzilla at busybox.net (bugzilla at busybox.net) Date: Wed, 16 Aug 2023 16:59:09 +0000 Subject: [Bug 15727] New: insmod return code is broken with MODPROBE_SMALL=y Message-ID: https://bugs.busybox.net/show_bug.cgi?id=15727 Bug ID: 15727 Summary: insmod return code is broken with MODPROBE_SMALL=y Product: Busybox Version: unspecified Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 Component: Other Assignee: unassigned at busybox.net Reporter: douglas.raillard at arm.com CC: busybox-cvs at busybox.net Target Milestone: --- insmod (from version 1.31.1 at least to 1.36.1 at least) does not forward the return code of the kernel module init function properly when compiled with MODPROBE_SMALL=y. This is problematic for callers expecting to distinguish different issues based on that. The code with MODPROBE_SMALL=y is: modutils/modprobe-small.c if (init_module(map, len, (IF_FEATURE_CMDLINE_MODULE_OPTIONS(options ? options : ) "") ) != 0 ) { bb_error_msg_and_die("can't insert '%s': %s", *argv, moderror(errno)); } So it's quite clear that all non-zero return values for init_module() are treated exactly the same. In contrast, modutils/insmod.c forwards the return value correctly: rc = bb_init_module(filename, parse_cmdline_module_options(argv, /*quote_spaces:*/ 0)); if (rc) bb_error_msg("can't insert '%s': %s", filename, moderror(rc)); return rc; To fix that, modprobe-small.c should return "errno" instead of dying with a generic error code. -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla at busybox.net Tue Aug 22 20:11:53 2023 From: bugzilla at busybox.net (bugzilla at busybox.net) Date: Tue, 22 Aug 2023 20:11:53 +0000 Subject: [Bug 15739] New: strings in auto_string will not be freed even if CONFIG_FEATURE_CLEAN_UP is enabled Message-ID: https://bugs.busybox.net/show_bug.cgi?id=15739 Bug ID: 15739 Summary: strings in auto_string will not be freed even if CONFIG_FEATURE_CLEAN_UP is enabled Product: Busybox Version: unspecified Hardware: All OS: Other Status: NEW Severity: normal Priority: P5 Component: Other Assignee: unassigned at busybox.net Reporter: vsfos at qq.com CC: busybox-cvs at busybox.net Target Milestone: --- As the summary, I run some memory check on busybox, and get some memory leaks, after debug, I found the leaks are the strings in auto_string. I'm using busybox on a memory constrained hardware, with 320K heap size, which is enough for elf busybox, but need CONFIG_FEATURE_CLEAN_UP working. -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla at busybox.net Fri Aug 25 21:49:40 2023 From: bugzilla at busybox.net (bugzilla at busybox.net) Date: Fri, 25 Aug 2023 21:49:40 +0000 Subject: [Bug 15742] New: ip flush fails on bridge with multiple addresses Message-ID: https://bugs.busybox.net/show_bug.cgi?id=15742 Bug ID: 15742 Summary: ip flush fails on bridge with multiple addresses Product: Busybox Version: unspecified Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 Component: Networking Assignee: unassigned at busybox.net Reporter: rakslice at gmail.com CC: busybox-cvs at busybox.net Target Milestone: --- On a system with a bridge with multiple addresses: # busybox ip a s ... snip ... 2: eth0: mtu 1500 qdisc pfifo_fast master br0 state UP qlen 1000 link/ether 08:00:27:fe:f5:38 brd ff:ff:ff:ff:ff:ff inet6 fe80::a00:27ff:fefe:f538/64 scope link valid_lft forever preferred_lft forever 43: br0: mtu 1500 qdisc noqueue state UP qlen 1000 link/ether 08:00:27:fe:f5:38 brd ff:ff:ff:ff:ff:ff inet 10.0.2.15/24 scope global br0 valid_lft forever preferred_lft forever inet 10.0.2.16/24 scope global secondary br0 valid_lft forever preferred_lft forever inet 10.0.2.17/24 scope global secondary br0 valid_lft forever preferred_lft forever inet6 fe80::a00:27ff:fefe:f538/64 scope link valid_lft forever preferred_lft forever Flushing the addresses exits with an error: # busybox ip addr flush br0 ip: can't send flush request: Address not available By contrast iproute2 would just ignore EADDRNOTAVAIL and succeed. System info: Alpine 3.18 x86_64 BusyBox v1.36.1 (2023-07-27 17:12:24 UTC) multi-call binary. config is the one at https://gitlab.alpinelinux.org/alpine/aports/-/blob/6f6dd7120ded4f70ab3cc41384c170ca5cb6a3d0/main/busybox/busyboxconfig -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla at busybox.net Fri Aug 25 21:51:42 2023 From: bugzilla at busybox.net (bugzilla at busybox.net) Date: Fri, 25 Aug 2023 21:51:42 +0000 Subject: [Bug 15742] ip flush fails on bridge with multiple addresses In-Reply-To: References: Message-ID: https://bugs.busybox.net/show_bug.cgi?id=15742 --- Comment #1 from Andrew Tonner --- # uname -a Linux iptest 6.1.47-0-lts #1-Alpine SMP PREEMPT_DYNAMIC Thu, 24 Aug 2023 10:24:14 +0000 x86_64 Linux -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla at busybox.net Tue Aug 29 07:55:02 2023 From: bugzilla at busybox.net (bugzilla at busybox.net) Date: Tue, 29 Aug 2023 07:55:02 +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 Radoslav Kolev changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Radoslav Kolev --- This has been fixed by a different approach in https://git.busybox.net/busybox/commit/?id=d417193cf -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla at busybox.net Wed Aug 30 07:43:57 2023 From: bugzilla at busybox.net (bugzilla at busybox.net) Date: Wed, 30 Aug 2023 07:43:57 +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 #3 from captainaye at protonmail.com --- This issue started being reported as CRITICAL by security tools such as snyk https://security.snyk.io/vuln/SNYK-DEBIANUNSTABLE-BUSYBOX-5853744 For what I see the fix is not released in any version yet. What are the plans for releasing it? -- You are receiving this mail because: You are on the CC list for the bug. From vda.linux at googlemail.com Thu Aug 31 00:20:19 2023 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 31 Aug 2023 02:20:19 +0200 Subject: [git commit] ash: initialize basepf.buf in ash Message-ID: <20230831012429.9AFF7866F7@busybox.osuosl.org> commit: https://git.busybox.net/busybox/commit/?id=ed4a24dfd10539e144ed4b7de008f8791d09a551 branch: https://git.busybox.net/busybox/commit/?id=refs/heads/master When I planned to print the command in read_line_input, I found that after the system started, the command printed for the first time was always garbled. After analysis, it is found that in the init() function of ash, the variable basepf.buf is not initialized after applying for memory, resulting in garbled initial data. Then assign it to the global variable g_parsefile->buf in ash.c, and then pass g_parsefile->buf to the parameter command of the function read_line_input in the function preadfd(), and finally cause it to be garbled when the command is printed by read_line_input. The call stack is as follows: #0 read_line_input (st=0xb6fff220, prompt=0xb6ffc910 "\\[\\033[32m\\]\\h \\w\\[\\033[m\\] \\$ ", command=command at entry=0xb6ffc230 "P\325\377\266P\325\377\266", maxsize=maxsize at entry=1024) at libbb/lineedit.c:2461 #1 0x0043ef8c in preadfd () at shell/ash.c:10812 #2 preadbuffer () at shell/ash.c:10914 #3 pgetc () at shell/ash.c:10997 #4 0x00440c20 in pgetc_eatbnl () at shell/ash.c:11039 #5 0x00440cbc in xxreadtoken () at shell/ash.c:13157 #6 0x00440f40 in readtoken () at shell/ash.c:13268 #7 0x00441234 in list (nlflag=nlflag at entry=1) at shell/ash.c:11782 #8 0x004420e8 in parsecmd (interact=) at shell/ash.c:13344 #9 0x00442c34 in cmdloop (top=top at entry=1) at shell/ash.c:13549 #10 0x00444e4c in ash_main (argc=, argv=0x444e4c ) at shell/ash.c:14747 #11 0x00407954 in run_applet_no_and_exit (applet_no=9, name=, argv=0xbefffd34) at libbb/appletlib.c:1024 #12 0x00407b68 in run_applet_and_exit (name=0xbefffe56 "ash", argv=0x9) at libbb/appletlib.c:1047 #13 0x00407f88 in main (argc=, argv=0xbefffd34) at libbb/appletlib.c:1181 Fixes: 82dd14a510ca ("ash: use CONFIG_FEATURE_EDITING_MAX_LEN") Signed-off-by: zhuyan Signed-off-by: Denys Vlasenko --- shell/ash.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/shell/ash.c b/shell/ash.c index e1d93da73..771fc8bf9 100644 --- a/shell/ash.c +++ b/shell/ash.c @@ -14484,7 +14484,7 @@ static NOINLINE void init(void) { /* we will never free this */ - basepf.next_to_pgetc = basepf.buf = ckmalloc(IBUFSIZ); + basepf.next_to_pgetc = basepf.buf = ckzalloc(IBUFSIZ); basepf.linno = 1; sigmode[SIGCHLD - 1] = S_DFL; /* ensure we install handler even if it is SIG_IGNed */ From bugzilla at busybox.net Thu Aug 31 07:15:14 2023 From: bugzilla at busybox.net (bugzilla at busybox.net) Date: Thu, 31 Aug 2023 07:15:14 +0000 Subject: [Bug 15748] New: with leading quote, printf prints value of first byte of a character instead of its numeric value in the codset Message-ID: https://bugs.busybox.net/show_bug.cgi?id=15748 Bug ID: 15748 Summary: with leading quote, printf prints value of first byte of a character instead of its numeric value in the codset Product: Busybox Version: 1.35.x Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 Component: Standard Compliance Assignee: unassigned at busybox.net Reporter: cslycord at gmail.com CC: busybox-cvs at busybox.net Target Milestone: --- According to posix standard for printf: If the leading character is a single-quote or double-quote, the value shall be the numeric value in the underlying codeset of the character following the single-quote or double-quote. This implies that it should be the character's codepoint, which is what is used in coreutils and bash. In busybox, instead it can return the value of the first of byte of the character. Examples: * ? HEX codepoint: BC14 DEC codepoint: 48148 Hex UTF-8 bytes: EB B0 94 (UTF-8 bytes converted to DEC): 235 176 148 https://www.cogsci.ed.ac.uk/~richard/utf-8.cgi?input=%EB%B0%94&mode=char * ? HEX codepoint: D559 DEC codepoint: 54617 Hex UTF-8 bytes: ED 95 99 (UTF-8 bytes converted to DEC): 237 149 153 https://www.cogsci.ed.ac.uk/~richard/utf-8.cgi?input=%ED%95%99&mode=char # busybox printf '%X' "'?" EB busybox printf '%X' "'?" ED # busybox printf '%d' "'?" 235 # busybox printf '%d' "'?" 237 (these are the HEX and DEC values of the first byte of the character) Then the printf from coreutils/bash # printf '%X' "'?" BC14 # printf '%X' "'?" D559 # printf '%d' "'?" 48148 # printf '%d' "'?" 54617 (which are the HEX and DEC values of the character's codepoint) Same happens with multibyte Chinese characters. # (coreutils) printf '%X' "'?" 4F20 # busybox printf '%X' "'?" E4 ? has HEX codepoint 4F20 and Hex UTF-8 bytes: E4 BC A0 -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla at busybox.net Thu Aug 31 07:24:53 2023 From: bugzilla at busybox.net (bugzilla at busybox.net) Date: Thu, 31 Aug 2023 07:24:53 +0000 Subject: [Bug 15748] with leading quote, printf prints value of first byte of a character instead of its numeric value in the codset In-Reply-To: References: Message-ID: https://bugs.busybox.net/show_bug.cgi?id=15748 --- Comment #1 from Chris Slycord --- Seems to happen for any multibyte character. # (coreutils) printf '%X' "'?" 754 # busybox printf '%X' "'?" DD ? has Hex code point: 0754 and Hex UTF-8 bytes: DD 94 -- You are receiving this mail because: You are on the CC list for the bug. From vda.linux at googlemail.com Thu Aug 31 07:41:53 2023 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 31 Aug 2023 09:41:53 +0200 Subject: [git commit] tsort: avoid use-after-free Message-ID: <20230831074806.BDA3B866EE@busybox.osuosl.org> commit: https://git.busybox.net/busybox/commit/?id=2cc9d436e80632157b99e18d413a62b2d44d321a branch: https://git.busybox.net/busybox/commit/?id=refs/heads/master When the input data contained a cycle it was possible for tsort to attempt to access freed nodes. This sometimes resulted in the test case 'echo a b b a | tsort' crashing. Don't free nodes when they're removed from the graph. function old new delta tsort_main 621 596 -25 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-25) Total: -25 bytes Signed-off-by: Ron Yorston Signed-off-by: Denys Vlasenko --- coreutils/tsort.c | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-) diff --git a/coreutils/tsort.c b/coreutils/tsort.c index a451ed2ff..e1ee6bcd7 100644 --- a/coreutils/tsort.c +++ b/coreutils/tsort.c @@ -101,6 +101,10 @@ int tsort_main(int argc UNUSED_PARAM, char **argv) ssize_t len; struct node *a; int cycles; + unsigned i; +#if ENABLE_FEATURE_CLEAN_UP + unsigned max_len; +#endif INIT_G(); @@ -152,9 +156,11 @@ int tsort_main(int argc UNUSED_PARAM, char **argv) * - if any nodes are left, they form cycles. */ cycles = 0; +#if ENABLE_FEATURE_CLEAN_UP + max_len = G.nodes_len; +#endif while (G.nodes_len) { struct node *n; - unsigned i; /* Search for first node with no incoming edges */ for (i = 0; i < G.nodes_len; i++) { @@ -173,16 +179,24 @@ int tsort_main(int argc UNUSED_PARAM, char **argv) /* Remove the node (need no longer maintain sort) */ n = G.nodes[i]; G.nodes[i] = G.nodes[--G.nodes_len]; +#if ENABLE_FEATURE_CLEAN_UP + /* Keep reference to removed node so it can be freed */ + G.nodes[G.nodes_len] = n; +#endif /* And remove its outgoing edges */ for (i = 0; i < n->out_count; i++) n->out[i]->in_count--; - free(n->out); puts(n->name); - free(n); + } +#if ENABLE_FEATURE_CLEAN_UP + for (i = 0; i < max_len; i++) { + free(G.nodes[i]->out); + free(G.nodes[i]); } free(G.nodes); +#endif fflush_stdout_and_exit(cycles ? 1 : 0); } From bugzilla at busybox.net Thu Aug 31 09:28:05 2023 From: bugzilla at busybox.net (bugzilla at busybox.net) Date: Thu, 31 Aug 2023 09:28:05 +0000 Subject: [Bug 15751] New: `time` function reports more `maxrss` usage than GNU time Message-ID: https://bugs.busybox.net/show_bug.cgi?id=15751 Bug ID: 15751 Summary: `time` function reports more `maxrss` usage than GNU time Product: Busybox Version: 1.34.x Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P5 Component: Other Assignee: unassigned at busybox.net Reporter: herano1999 at gmail.com CC: busybox-cvs at busybox.net Target Milestone: --- use the binary from this C++ file produces: ``` // add.cpp #include char bulk[1 << 20]; int main() { for (int i = 1; i < 1048576; i++) bulk[i] = bulk[i - 1] + 'a'; printf("hello, world\n"); return 0; } ``` and compile it with ``` g++ add.cpp -o add -O2 -static ``` using GNU time 1.7 to monitor the usage ``` /usr/bin/time -v ./add ``` it reports that `add` uses ~1800 kbytes of maxrss, but uses busybox 1.34.1 ``` time -v ./add ``` it reports that `add` uses ~7300 kbytes of maxrss. It's rather 4x more than the GNU time gives. I think there should not be too much gap between the two `time` functions. -- You are receiving this mail because: You are on the CC list for the bug.