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.