From brandon.maier at collins.com Fri Dec 2 15:50:29 2022 From: brandon.maier at collins.com (Brandon Maier) Date: Fri, 2 Dec 2022 09:50:29 -0600 Subject: [PATCH 1/1] xxd: fix typo in trivial usage Message-ID: <20221202155029.2420-1-brandon.maier@collins.com> Signed-off-by: Brandon Maier --- util-linux/hexdump_xxd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/util-linux/hexdump_xxd.c b/util-linux/hexdump_xxd.c index 6629407de..45391b565 100644 --- a/util-linux/hexdump_xxd.c +++ b/util-linux/hexdump_xxd.c @@ -41,7 +41,7 @@ // -u use upper case hex letters. //usage:#define xxd_trivial_usage -//usage: "[-pri] [-g N] [-c N] [-n LEN] [-s OFS] [-o OFS] [FILE]" +//usage: "[-pri] [-g N] [-c N] [-l LEN] [-s OFS] [-o OFS] [FILE]" //usage:#define xxd_full_usage "\n\n" //usage: "Hex dump FILE (or stdin)\n" //usage: "\n -g N Bytes per group" -- 2.38.1 From hauke at hauke-m.de Mon Dec 5 23:26:00 2022 From: hauke at hauke-m.de (Hauke Mehrtens) Date: Tue, 6 Dec 2022 00:26:00 +0100 Subject: [PATCH 0/2] Fix CVE-2022-28391 In-Reply-To: <20220719155332.18440-1-radoslav.kolev@suse.com> References: <20220719155332.18440-1-radoslav.kolev@suse.com> Message-ID: <75e825fa-a3fa-de55-d5d7-c6c926b2ffa7@hauke-m.de> On 7/19/22 17:53, Radoslav Kolev wrote: > The following two patches fix CVE-2022-2839 preventing netstat, > traceroute and nslookup from sending escape sequences to the terminal. > Note that the problem is only reproducible when using musl libc, but > not with glibc. > > More information can be found at: > https://gitlab.alpinelinux.org/alpine/aports/-/issues/13661 Hi Denys, Could you please have a look at these fixes. They should fix some "security" problems which got a CVE assigned. Hauke From vda.linux at googlemail.com Thu Dec 8 16:19:22 2022 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 8 Dec 2022 17:19:22 +0100 Subject: [PATCH 1/1] xxd: fix typo in trivial usage In-Reply-To: <20221202155029.2420-1-brandon.maier@collins.com> References: <20221202155029.2420-1-brandon.maier@collins.com> Message-ID: Applied, thank you On Fri, Dec 2, 2022 at 4:54 PM Brandon Maier wrote: > > Signed-off-by: Brandon Maier > --- > util-linux/hexdump_xxd.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/util-linux/hexdump_xxd.c b/util-linux/hexdump_xxd.c > index 6629407de..45391b565 100644 > --- a/util-linux/hexdump_xxd.c > +++ b/util-linux/hexdump_xxd.c > @@ -41,7 +41,7 @@ > // -u use upper case hex letters. > > //usage:#define xxd_trivial_usage > -//usage: "[-pri] [-g N] [-c N] [-n LEN] [-s OFS] [-o OFS] [FILE]" > +//usage: "[-pri] [-g N] [-c N] [-l LEN] [-s OFS] [-o OFS] [FILE]" > //usage:#define xxd_full_usage "\n\n" > //usage: "Hex dump FILE (or stdin)\n" > //usage: "\n -g N Bytes per group" > -- > 2.38.1 > From vda.linux at googlemail.com Mon Dec 12 15:22:19 2022 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 12 Dec 2022 16:22:19 +0100 Subject: [PATCH v4 1/9] loop:refactor: extract subfunction open_file() In-Reply-To: <20221121135819.413-2-nixiaoming@huawei.com> References: <20221121135819.413-1-nixiaoming@huawei.com> <20221121135819.413-2-nixiaoming@huawei.com> Message-ID: On Mon, Nov 21, 2022 at 2:58 PM Xiaoming Ni wrote: > +static int open_file(const char *file, unsigned flags, int *mode) > +{ > + int ffd; > + /* open the file. barf if this doesn't work. */ > + *mode = (flags & BB_LO_FLAGS_READ_ONLY) ? O_RDONLY : O_RDWR; > + retry_open_ffd: > + ffd = open(file, *mode); > + if (ffd < 0) { > + if (*mode != O_RDONLY) { > + *mode = O_RDONLY; > + goto retry_open_ffd; > + } > + } > + return ffd; > +} > + > /* Returns opened fd to the loop device, <0 on error. > * *device is loop device to use, or if *device==NULL finds a loop device to > * mount it on and sets *device to a strdup of that loop device name. > @@ -109,15 +125,8 @@ int FAST_FUNC set_loop(char **device, const char *file, unsigned long long offse > struct stat statbuf; > int i, lfd, ffd, mode, rc; > > - /* Open the file. Barf if this doesn't work. */ > - mode = (flags & BB_LO_FLAGS_READ_ONLY) ? O_RDONLY : O_RDWR; > - open_ffd: > - ffd = open(file, mode); > + ffd = open_file(file, flags, &mode); > if (ffd < 0) { > - if (mode != O_RDONLY) { > - mode = O_RDONLY; > - goto open_ffd; > - } open_file() name is not describing what function actually does - "open RW or RO". The change seems to not be needed by any further patches. The change makes the code less efficient by now requiring "mode" to live on stack, unless compiler inlines the single-use static and figures out that in fact, the "&mode" can be proven to not need a memory-addressable location. The current compilers usually are good enough to do so, but why do it anyway? From vda.linux at googlemail.com Mon Dec 12 18:08:11 2022 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 12 Dec 2022 19:08:11 +0100 Subject: [PATCH v4 2/9] loop:refactor: extract subfunction get_next_free_loop() In-Reply-To: <20221121135819.413-3-nixiaoming@huawei.com> References: <20221121135819.413-1-nixiaoming@huawei.com> <20221121135819.413-3-nixiaoming@huawei.com> Message-ID: Applied with some changes, thank you On Mon, Nov 21, 2022 at 2:58 PM Xiaoming Ni wrote: > > Step 2 of micro-refactoring the set_loop function () > Extract subfunction get_next_free_loop() from set_loop() > > Also fix miss free(try) when stat(try) and mknod fail > > function old new delta > set_loop 758 734 -24 > ------------------------------------------------------------------------------ > (add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-24) Total: -24 bytes > > Fixes: 3448914e8cc5 ("mount,losetup: use /dev/loop-control is it exists") > Signed-off-by: Xiaoming Ni > --- > libbb/loop.c | 58 +++++++++++++++++++++++++--------------------------- > 1 file changed, 28 insertions(+), 30 deletions(-) > > diff --git a/libbb/loop.c b/libbb/loop.c > index c517ceb13..6c28e683a 100644 > --- a/libbb/loop.c > +++ b/libbb/loop.c > @@ -9,6 +9,7 @@ > */ > #include "libbb.h" > #include > +#include > > #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0) > > @@ -96,6 +97,22 @@ int FAST_FUNC get_free_loop(void) > return loopdevno; /* can be -1 if error */ > } > > +static int get_next_free_loop(char *dev, __attribute__((unused)) size_t dev_size, int id) > +{ > + int loopdevno; > + assert(dev_size >= LOOP_NAMESIZE); > + loopdevno = get_free_loop(); > + if (loopdevno >= 0) { > + sprintf(dev, LOOP_FORMAT, loopdevno); > + return 1; /* use /dev/loop-control */ > + } > + if (loopdevno == -2) { > + sprintf(dev, LOOP_FORMAT, id); > + return 2; > + } > + return -1; /* no free loop devices */ > +} > + > static int open_file(const char *file, unsigned flags, int *mode) > { > int ffd; > @@ -132,30 +149,26 @@ int FAST_FUNC set_loop(char **device, const char *file, unsigned long long offse > > try = *device; > if (!try) { > - get_free_loopN: > - i = get_free_loop(); > - if (i == -1) { > - close(ffd); > - return -1; /* no free loop devices */ > - } > - if (i >= 0) { > - try = xasprintf(LOOP_FORMAT, i); > - goto open_lfd; > - } > - /* i == -2: no /dev/loop-control. Do an old-style search for a free device */ > try = dev; > } > > /* Find a loop device */ > /* 0xfffff is a max possible minor number in Linux circa 2010 */ > for (i = 0; i <= 0xfffff; i++) { > - sprintf(dev, LOOP_FORMAT, i); > + if (!*device) { > + rc = get_next_free_loop(dev, sizeof(dev), i); > + if (rc == -1) { > + break; /* no free loop devices */ > + } else if (rc == 1) { > + goto open_lfd; > + } > + } > > IF_FEATURE_MOUNT_LOOP_CREATE(errno = 0;) > if (stat(try, &statbuf) != 0 || !S_ISBLK(statbuf.st_mode)) { > if (ENABLE_FEATURE_MOUNT_LOOP_CREATE > && errno == ENOENT > - && try == dev > + && (!*device) > ) { > /* Node doesn't exist, try to create it */ > if (mknod(dev, S_IFBLK|0644, makedev(7, i)) == 0) > @@ -188,13 +201,10 @@ int FAST_FUNC set_loop(char **device, const char *file, unsigned long long offse > /* Associate free loop device with file */ > if (ioctl(lfd, LOOP_SET_FD, ffd)) { > /* Ouch. Are we racing with other mount? */ > - if (!*device /* yes */ > - && try != dev /* tried a _kernel-offered_ loopN? */ > - ) { > - free(try); > + if (!*device) { > close(lfd); > //TODO: add "if (--failcount != 0) ..."? > - goto get_free_loopN; > + continue; > } > goto close_and_try_next_loopN; > } > @@ -218,8 +228,6 @@ int FAST_FUNC set_loop(char **device, const char *file, unsigned long long offse > } > if (rc == 0) { > /* SUCCESS! */ > - if (try != dev) /* tried a kernel-offered free loopN? */ > - *device = try; /* malloced */ > if (!*device) /* was looping in search of free "/dev/loopN"? */ > *device = xstrdup(dev); > rc = lfd; /* return this */ > @@ -227,16 +235,6 @@ int FAST_FUNC set_loop(char **device, const char *file, unsigned long long offse > } > /* failure, undo LOOP_SET_FD */ > ioctl(lfd, LOOP_CLR_FD, 0); // actually, 0 param is unnecessary > - } else { > - /* device is not free (rc == 0), or error other than ENXIO */ > - if (rc == 0 /* device is not free? */ > - && !*device /* racing with other mount? */ > - && try != dev /* tried a _kernel-offered_ loopN? */ > - ) { > - free(try); > - close(lfd); > - goto get_free_loopN; > - } > } > close_and_try_next_loopN: > close(lfd); > -- > 2.27.0 > From vda.linux at googlemail.com Mon Dec 12 18:09:55 2022 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 12 Dec 2022 19:09:55 +0100 Subject: [PATCH v4 3/9] loop:refactor: del close_and_try_next_loopN In-Reply-To: <20221121135819.413-4-nixiaoming@huawei.com> References: <20221121135819.413-1-nixiaoming@huawei.com> <20221121135819.413-4-nixiaoming@huawei.com> Message-ID: On Mon, Nov 21, 2022 at 2:57 PM Xiaoming Ni wrote: > > Step 3 of micro-refactoring the set_loop() function: > Delete close_and_try_next_loopN. > > (add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0) Total: 0 bytes > > Signed-off-by: Xiaoming Ni > --- > libbb/loop.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/libbb/loop.c b/libbb/loop.c > index 6c28e683a..c7687052b 100644 > --- a/libbb/loop.c > +++ b/libbb/loop.c > @@ -200,13 +200,14 @@ int FAST_FUNC set_loop(char **device, const char *file, unsigned long long offse > if (rc && errno == ENXIO) { > /* Associate free loop device with file */ > if (ioctl(lfd, LOOP_SET_FD, ffd)) { > + close(lfd); > /* Ouch. Are we racing with other mount? */ > if (!*device) { > - close(lfd); > //TODO: add "if (--failcount != 0) ..."? > continue; > + } else { > + break; > } > - goto close_and_try_next_loopN; > } if (ioctl(lfd, LOOP_SET_FD, ffd)) goto close_and_try_next_loopN; will work as well: the code at that label checks for "if (!*device)" case too. Applied, thank you. From vda.linux at googlemail.com Tue Dec 13 14:22:47 2022 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 13 Dec 2022 15:22:47 +0100 Subject: [PATCH v4 9/9] loop: Add LOOP_CONFIGURE ioctl In-Reply-To: <20221121135819.413-10-nixiaoming@huawei.com> References: <20221121135819.413-1-nixiaoming@huawei.com> <20221121135819.413-10-nixiaoming@huawei.com> Message-ID: > +config LOOP_CONFIGURE > + bool "always uses LOOP_CONFIGURE, kernel version >= 5.8" > + > +config NO_LOOP_CONFIGURE > + bool "never uses LOOP_CONFIGURE, kernel version < 5.8" > + > +config TRY_LOOP_CONFIGURE > + bool "try LOOP_CONFIGURE, kernel version is unknown" The descriptions need improvement. > +static int set_loop_configure(int ffd, int lfd, const bb_loop_info *loopinfo) > +{ > + int rc; > + struct loop_config config; > + > + memset(&config, 0, sizeof(config)); > + config.fd = ffd; > + memcpy(&config.info, loopinfo, sizeof(config.info)); This copying of the struct can be eliminated, a-la: +#if ENABLE_TRY_LOOP_CONFIGURE || ENABLE_LOOP_CONFIGURE + struct loop_config lconfig; +# define loopinfo lconfig.info +#else bb_loop_info loopinfo; +#endif I reworked and applied it. Please try current git. From vda.linux at googlemail.com Tue Dec 13 15:22:04 2022 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 13 Dec 2022 16:22:04 +0100 Subject: udhcpc6 missing source address In-Reply-To: References: Message-ID: On Fri, Dec 9, 2022 at 5:09 PM John Lemonovich wrote: > Hello Denys, > > I am working on an embedded Linux project using an intel Arria 10 FPGA and have been using IPv4 for a long time, and now need IPv6. I found your email online searching for help. I have many things working with IPv6, but the one thing I can?t get to work is udhcpc6 ? it will not acquire an IP address via DHCPv6 (tried with multiple servers). I?m really stuck and looking for any help ? even a pointer to documentation maybe I?m missing? Sorry, I myself have no DHPCv6 server to test against... > If I look at the tcpdump output ? the solicit packets go out with a null source address (all 0?s - just as :: ) Which kind of makes sense, if you think about it. DHCP client does not _have_ an IP address yet, this is the whole point of DHCP: to obtain an address... > and the server doesn?t know how to reply (unreachable). I would imagine server can/should reply with a broadcast, right? > My link local address is set to: > inet6 fe80::da80:39ff:fed8:90a0 prefixlen 64 scopeid 0x20 > but yet udhcpc6 seems to put just :: in for the source address. But what if the iface has no link-local address either? Then udhcpc6 would have no choice but leave it not filled. And a good server implementation should deal with such incoming packets. > If there?s a better place to post this - please let me know. CCed to busybox ML. From David.Laight at ACULAB.COM Tue Dec 13 15:41:54 2022 From: David.Laight at ACULAB.COM (David Laight) Date: Tue, 13 Dec 2022 15:41:54 +0000 Subject: udhcpc6 missing source address In-Reply-To: References: Message-ID: <9f5e019210284f64bcd6671517dc159e@AcuMS.aculab.com> From: Denys Vlasenko > Sent: 13 December 2022 15:22 > > On Fri, Dec 9, 2022 at 5:09 PM John Lemonovich > wrote: > > Hello Denys, > > > > I am working on an embedded Linux project using an intel Arria 10 FPGA and have been using IPv4 for > a long time, and now need IPv6. I found your email online searching for help. I have many things > working with IPv6, but the one thing I can?t get to work is udhcpc6 ? it will not acquire an IP > address via DHCPv6 (tried with multiple servers). I?m really stuck and looking for any help ? even a > pointer to documentation maybe I?m missing? > > Sorry, I myself have no DHPCv6 server to test against... > > > If I look at the tcpdump output ? the solicit packets go out with a null source address (all 0?s - > just as :: ) > > Which kind of makes sense, if you think about it. DHCP client does not > _have_ an IP address yet, > this is the whole point of DHCP: to obtain an address... They do need to go out from the link-local address. Whatever starts udhcp6 needs to wait for it to be created. I don't remember any issues getting the initial response though. You will need to write a proper IPv6 version of the script that actually does the work. Also dhcp6 only gives you an address, the 'router advertise' stuff also has to be enabled (autoconf can be left disabled, but you need to be on a network where it would work). David > > > and the server doesn?t know how to reply (unreachable). > > I would imagine server can/should reply with a broadcast, right? > > > My link local address is set to: > > inet6 fe80::da80:39ff:fed8:90a0 prefixlen 64 scopeid 0x20 > > but yet udhcpc6 seems to put just :: in for the source address. > > But what if the iface has no link-local address either? > Then udhcpc6 would have no choice but leave it not filled. > And a good server implementation should deal with such incoming packets. > > > If there?s a better place to post this - please let me know. > > CCed to busybox ML. > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://lists.busybox.net/mailman/listinfo/busybox - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) From David.Laight at ACULAB.COM Tue Dec 13 16:18:38 2022 From: David.Laight at ACULAB.COM (David Laight) Date: Tue, 13 Dec 2022 16:18:38 +0000 Subject: udhcpc6 missing source address In-Reply-To: References: <9f5e019210284f64bcd6671517dc159e@AcuMS.aculab.com> Message-ID: <2c22ad7112f547e195621c170e96d1ba@AcuMS.aculab.com> From: John Lemonovich > Sent: 13 December 2022 15:59 > > Thanks for the replies. Yes David, it's also my understanding per the spec, that the client's link- > local address must be included for the solicit message. The reply from the server is unicast. What > do you mean by the proper IPv6 version of the script...to which script are you referring to? Can you > possibly show an example? The one that probably ends up in /usr/share/udhcpc/default.script and is passed to udhcpc6 with the -s option. Not the least of the problems is that you need to explicitly delete the old IPv6 address (in deconfig). I think the script I started from deleted the IPv4 address! There is also the issue that you need to do a 'mark and scan' pass over the routes (even in IPv4) to ensure the system isn't left with an invalid routing table during renew processing. > Just out of curiosity, has it ever been tested or known to work with a DHCPv6 server then? Works for us (in testing anyway). There has also been a bug to do with release renewal. Might have been fixed. If any of our customers decide to use IPv6 I'll need to check - they clearly haven't on the previous product! (The lack of bugs is a pretty good hint.) I presume you are running a reasonably recent kernel. Anything really archaic might be buggy - but you should have a few years. Are you actually running Linux on a nios2? I can't actually imagine that being fast enough for anything useful. (Or does the arria10 contain an arm core?) We do use nios cpu - but only running a few kb of code. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) From vda.linux at googlemail.com Tue Dec 13 23:47:16 2022 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 14 Dec 2022 00:47:16 +0100 Subject: udhcpc6 missing source address In-Reply-To: References: <9f5e019210284f64bcd6671517dc159e@AcuMS.aculab.com> Message-ID: On Tue, Dec 13, 2022 at 4:58 PM John Lemonovich wrote: > > Thanks for the replies. Yes David, it's also my understanding per the spec, that the client's link-local address must be included for the solicit message. Where does it say that in https://www.rfc-editor.org/rfc/rfc3315 ? > The reply from the server is unicast. What do you mean by the proper IPv6 version of the script...to which script are you referring to? Can you possibly show an example? > > Just out of curiosity, has it ever been tested or known to work with a DHCPv6 server then? I wrote the code based on IPv4. Couldn't test it. Surprisingly, people reported that it did work on the first try (with a number of bugs quickly discovered and hopefully fixed). I have no doubt it still has obvious bugs due to limited exposure. > I've tried with 3 different DHCP servers and they all seem to NOT want to reply with a broadcast and are expecting to receive an address (e.g.: the link local address) for a reply. My windows machines and my Ubuntu/Cent-OS machines are doing it this way - they are not sending all 0's for the source address for their requests. Here you mean "source address of the IPv6 packet", or some DHCPv6 option? Can you tcpdump clients which do acquire a lease from these servers? From nicolas.cavallari at green-communications.fr Wed Dec 14 07:54:48 2022 From: nicolas.cavallari at green-communications.fr (Nicolas Cavallari) Date: Wed, 14 Dec 2022 08:54:48 +0100 Subject: udhcpc6 missing source address In-Reply-To: References: <9f5e019210284f64bcd6671517dc159e@AcuMS.aculab.com> Message-ID: <8ea89b54-74f6-c577-7011-29e17d19edfe@green-communications.fr> On 14/12/2022 00:47, Denys Vlasenko wrote: > On Tue, Dec 13, 2022 at 4:58 PM John Lemonovich > wrote: >> >> Thanks for the replies. Yes David, it's also my understanding per the spec, that the client's link-local address must be included for the solicit message. > > Where does it say that in https://www.rfc-editor.org/rfc/rfc3315 ? 1.1. Protocols and Addressing Clients and servers exchange DHCP messages using UDP [15]. The client uses a link-local address or addresses determined through other mechanisms for transmitting and receiving DHCP messages. Also, RFC 3315 is obsoleted by RFC 8415, but the wording is the same in section 5. From David.Laight at ACULAB.COM Wed Dec 14 09:52:49 2022 From: David.Laight at ACULAB.COM (David Laight) Date: Wed, 14 Dec 2022 09:52:49 +0000 Subject: udhcpc6 missing source address In-Reply-To: References: <9f5e019210284f64bcd6671517dc159e@AcuMS.aculab.com> <2c22ad7112f547e195621c170e96d1ba@AcuMS.aculab.com> Message-ID: <489896a4d9014806a8ad49fcbac90bf4@AcuMS.aculab.com> From: John Lemonovich > Sent: 13 December 2022 20:35 > > How are you getting a solicit message through with :: as the source address, which I've found no > server likes as I've tested 3 of them? Or is mine not using the link local address because I'm not > doing anything with the default.script? > > The kernel is 5.4.13 I've just run a quick test. strace of uhdcpc6 shows it doing something with a routing socket, creating an IPv6 UDP socket, binding (probably to the interface) and then doing s sendto() that specifies the multicast MAC. (It puts the mcast address in the bind as well - probably ignored?) The kernel is providing the source IPv6 address as part of its normal UDP routing operations - the same as it does for any other outbound packet. tcpdump then shows the packet being sent from the link-local address - as expected. Three messages are sent, no reply received (I don't have a server here and there is absolutely nothing else on that network segment). The script is run 'leasefail' and it all retries a short time later. On a network with a server it gets a response. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) From vda.linux at googlemail.com Wed Dec 14 09:58:51 2022 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 14 Dec 2022 10:58:51 +0100 Subject: udhcpc6 missing source address In-Reply-To: <8ea89b54-74f6-c577-7011-29e17d19edfe@green-communications.fr> References: <9f5e019210284f64bcd6671517dc159e@AcuMS.aculab.com> <8ea89b54-74f6-c577-7011-29e17d19edfe@green-communications.fr> Message-ID: On Wed, Dec 14, 2022 at 8:55 AM Nicolas Cavallari wrote: > > On 14/12/2022 00:47, Denys Vlasenko wrote: > > On Tue, Dec 13, 2022 at 4:58 PM John Lemonovich > > wrote: > >> > >> Thanks for the replies. Yes David, it's also my understanding per the spec, that the client's link-local address must be included for the solicit message. > > > > Where does it say that in https://www.rfc-editor.org/rfc/rfc3315 ? > > 1.1. Protocols and Addressing > > Clients and servers exchange DHCP messages using UDP [15]. The > client uses a link-local address or addresses determined through > other mechanisms for transmitting and receiving DHCP messages. > > Also, RFC 3315 is obsoleted by RFC 8415, but the wording is the same in > section 5. Looking at the code. d6_send_raw_packet_from_client_data_ifindex() fills in source address like this: d6_send_raw_packet_from_client_data_ifindex( packet, (end - (uint8_t*) packet), /*src*/ &client6_data.ll_ip6, CLIENT_PORT6, ... &client6_data.ll_ip6 is passed as "src_ipv6" parameter into it, and... if (src_ipv6) packet.ip6.ip6_src = *src_ipv6; /* struct copy */ it is used as above. client6_data.ll_ip6 is populated by periodic calls to d6_read_interface(...&client6_data.ll_ip6,...) which looks at all addresses and should be finding our link-local address, if it exists: int FAST_FUNC d6_read_interface( const char *interface, int *ifindex, struct in6_addr *nip6, uint8_t *mac) ... getifaddrs(&ifap); for (ifa = ifap; ifa; ifa = ifa->ifa_next) { struct sockaddr_in6 *sip6; if (!ifa->ifa_addr || (strcmp(ifa->ifa_name, interface) != 0)) continue; ... sip6 = (void*)(ifa->ifa_addr); if (ifa->ifa_addr->sa_family == AF_INET6 && IN6_IS_ADDR_LINKLOCAL(&sip6->sin6_addr) ) { *nip6 = sip6->sin6_addr; /* struct copy */ log1( "IPv6 %02x%02x:%02x%02x:%02x%02x:%02x%02x:%02x%02x:%02x%02x:%02x%02x:%02x%02x", nip6->s6_addr[0], nip6->s6_addr[1], nip6->s6_addr[2], nip6->s6_addr[3], nip6->s6_addr[4], nip6->s6_addr[5], nip6->s6_addr[6], nip6->s6_addr[7], nip6->s6_addr[8], nip6->s6_addr[9], nip6->s6_addr[10], nip6->s6_addr[11], nip6->s6_addr[12], nip6->s6_addr[13], nip6->s6_addr[14], nip6->s6_addr[15] ); retval &= (3 - (1<<1)); } Do you reach this code? You can know it if you enabled logging at least to level 1 (udhcpc6 -v) and you see "IPv6 xx:xx:xx:...:xx" message. From vda.linux at googlemail.com Wed Dec 14 10:04:09 2022 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 14 Dec 2022 11:04:09 +0100 Subject: udhcpc6 missing source address In-Reply-To: <489896a4d9014806a8ad49fcbac90bf4@AcuMS.aculab.com> References: <9f5e019210284f64bcd6671517dc159e@AcuMS.aculab.com> <2c22ad7112f547e195621c170e96d1ba@AcuMS.aculab.com> <489896a4d9014806a8ad49fcbac90bf4@AcuMS.aculab.com> Message-ID: On Wed, Dec 14, 2022 at 10:52 AM David Laight wrote: > > From: John Lemonovich > > Sent: 13 December 2022 20:35 > > > > How are you getting a solicit message through with :: as the source address, which I've found no > > server likes as I've tested 3 of them? Or is mine not using the link local address because I'm not > > doing anything with the default.script? > > > > The kernel is 5.4.13 > > I've just run a quick test. > > strace of uhdcpc6 shows it doing something with a routing socket, > creating an IPv6 UDP socket, binding (probably to the interface) > and then doing s sendto() that specifies the multicast MAC. > (It puts the mcast address in the bind as well - probably ignored?) This code? int FAST_FUNC d6_send_raw_packet_from_client_data_ifindex( struct d6_packet *d6_pkt, unsigned d6_pkt_size, struct in6_addr *src_ipv6, int source_port, struct in6_addr *dst_ipv6, int dest_port, const uint8_t *dest_arp) { struct sockaddr_ll dest_sll; struct ip6_udp_d6_packet packet; int fd; int result = -1; const char *msg; fd = socket(PF_PACKET, SOCK_DGRAM, htons(ETH_P_IPV6)); if (fd < 0) { msg = "socket(%s)"; goto ret_msg; } memset(&dest_sll, 0, sizeof(dest_sll)); memset(&packet, 0, offsetof(struct ip6_udp_d6_packet, data)); packet.data = *d6_pkt; /* struct copy */ dest_sll.sll_family = AF_PACKET; dest_sll.sll_protocol = htons(ETH_P_IPV6); dest_sll.sll_ifindex = client_data.ifindex; /*dest_sll.sll_hatype = ARPHRD_???;*/ /*dest_sll.sll_pkttype = PACKET_???;*/ dest_sll.sll_halen = 6; memcpy(dest_sll.sll_addr, dest_arp, 6); if (bind(fd, (struct sockaddr *)&dest_sll, sizeof(dest_sll)) < 0) { msg = "bind(%s)"; goto ret_close; } > The kernel is providing the source IPv6 address as part of its > normal UDP routing operations - the same as it does for any > other outbound packet. If it's the code from the above, then no, kernel will not fill in any IPv6 source addresses, as it does not even know it's an IPv6/UDP packet - we use raw sockets here, and we format UDP packet "by hand": packet.ip6.ip6_vfc = (6 << 4); /* 4 bits version, top 4 bits of tclass */ if (src_ipv6) packet.ip6.ip6_src = *src_ipv6; /* struct copy */ ^^^^^^^^^^^^^^^^^^^^^^^^^ this is where source IPv6 address filled in packet.ip6.ip6_dst = *dst_ipv6; /* struct copy */ packet.udp.source = htons(source_port); packet.udp.dest = htons(dest_port); /* size, excluding IP header: */ packet.udp.len = htons(sizeof(struct udphdr) + d6_pkt_size); packet.ip6.ip6_plen = packet.udp.len; /* * Someone was smoking weed (at least) while inventing UDP checksumming: * UDP checksum skips first four bytes of IPv6 header. * 'next header' field should be summed as if it is one more byte * to the right, therefore we write its value (IPPROTO_UDP) * into ip6_hlim, and its 'real' location remains zero-filled for now. */ packet.ip6.ip6_hlim = IPPROTO_UDP; packet.udp.check = inet_cksum( (uint8_t *)&packet + 4, offsetof(struct ip6_udp_d6_packet, data) - 4 + d6_pkt_size ); /* fix 'hop limit' and 'next header' after UDP checksumming */ packet.ip6.ip6_hlim = 1; /* observed Windows machines to use hlim=1 */ packet.ip6.ip6_nxt = IPPROTO_UDP; d6_dump_packet(d6_pkt); result = sendto(fd, &packet, offsetof(struct ip6_udp_d6_packet, data) + d6_pkt_size, /*flags:*/ 0, (struct sockaddr *) &dest_sll, sizeof(dest_sll) From David.Laight at ACULAB.COM Wed Dec 14 10:29:34 2022 From: David.Laight at ACULAB.COM (David Laight) Date: Wed, 14 Dec 2022 10:29:34 +0000 Subject: udhcpc6 missing source address In-Reply-To: References: <9f5e019210284f64bcd6671517dc159e@AcuMS.aculab.com> <2c22ad7112f547e195621c170e96d1ba@AcuMS.aculab.com> <489896a4d9014806a8ad49fcbac90bf4@AcuMS.aculab.com> Message-ID: From: Denys Vlasenko > Sent: 14 December 2022 10:04 > > On Wed, Dec 14, 2022 at 10:52 AM David Laight wrote: ... > If it's the code from the above, then no, kernel will not fill in > any IPv6 source addresses, as it does not even know it's > an IPv6/UDP packet - we use raw sockets here, > and we format UDP packet "by hand": Not enough coffee this morning to quickly interpret the strace output :-( I'm pretty sure there is a way of sending UDP multicast packets and that dhcpc6 could use it. (It is harder for IPv4 because there isn't a valid source IP.) We've got some code that sends UDP from RAWIP sockets. That allows the sender to change the source port for every message. For IPv6 the kernel can calculate the UDP checksum after doing the packet routing - so we don't have to build the IPv6 header. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) From vda.linux at googlemail.com Wed Dec 14 14:54:42 2022 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 14 Dec 2022 15:54:42 +0100 Subject: [PATCH] more: accept and ignore -e In-Reply-To: <20221121130957.8794-1-ncopa@alpinelinux.org> References: <20221121130957.8794-1-ncopa@alpinelinux.org> Message-ID: Applied, thank you. On Mon, Nov 21, 2022 at 2:20 PM Natanael Copa wrote: > > Accept and ignore -e which is specified in POSIX. > https://pubs.opengroup.org/onlinepubs/9699919799/utilities/more.html > --- > util-linux/more.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/util-linux/more.c b/util-linux/more.c > index eea69da06..a830dcbc1 100644 > --- a/util-linux/more.c > +++ b/util-linux/more.c > @@ -84,11 +84,12 @@ int more_main(int argc UNUSED_PARAM, char **argv) > /* Parse options */ > /* Accepted but ignored: */ > /* -d Display help instead of ringing bell */ > + /* -e Exit immediately after writing the last line */ > /* -f Count logical lines (IOW: long lines are not folded) */ > /* -l Do not pause after any line containing a ^L (form feed) */ > /* -s Squeeze blank lines into one */ > /* -u Suppress underlining */ > - getopt32(argv, "dflsu"); > + getopt32(argv, "deflsu"); > argv += optind; > > /* Another popular pager, most, detects when stdout > -- > 2.38.1 > > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://lists.busybox.net/mailman/listinfo/busybox From vda.linux at googlemail.com Wed Dec 14 21:17:16 2022 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 14 Dec 2022 22:17:16 +0100 Subject: udhcpc6 missing source address In-Reply-To: References: <9f5e019210284f64bcd6671517dc159e@AcuMS.aculab.com> <2c22ad7112f547e195621c170e96d1ba@AcuMS.aculab.com> <489896a4d9014806a8ad49fcbac90bf4@AcuMS.aculab.com> Message-ID: On Wed, Dec 14, 2022 at 8:59 PM John Lemonovich wrote: > Thank you all for the replies so far. I am admittedly an FPGA designer/hardware guy, and an embedded software/networking person only enough to be able to get the hardware working ? > > > Here is a the wireshark (via tcpdump) of the solicit msg from my Intel SOC device running udhcpc6: > > 5 2.848295 :: ff02::1:2 DHCPv6 96 Solicit XID: 0x286846 CID: 00030001d88039d890a0 For comparison, this is how DHCPv4 looks on the wire: 28:df:eb:11:48:92 > Broadcast, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 28:df:eb:11:48:92, length 300, xid 0x158e8233, Flags [none] Client-Ethernet-Address 28:df:eb:11:48:92 ... 40:3f:8c:7c:7a:2d > 28:df:eb:11:48:92, ethertype IPv4 (0x0800), length 342: (tos 0xc0, ttl 64, id 41793, offset 0, flags [none], proto UDP (17), length 328) 192.168.1.1.bootps > 192.168.1.193.bootpc: BOOTP/DHCP, Reply, length 300, xid 0x158e8233, Flags [none] Your-IP 192.168.1.193 Server-IP 192.168.1.1 Not only the server is unfazed by source IP of 0.0.0.0, it nevertheless sends _unicast_ reply, because it saw client's MAC address. (It even filled our would-be IP in the destination IP field, to be extra nice). > And here is the dhcp.log at the server for the udhcpc6 client: > > 2022:12:06-09:29:52 access dhcpd6: Solicit message from :: port 546, transaction ID 0x541D1C00 > 2022:12:06-09:29:52 access dhcpd6: Picking pool address 2002:189a:af04:40::fb50 > 2022:12:06-09:29:52 access dhcpd6: Advertise NA: address 2002:189a:af04:40::fb50 to client with duid 00:03:00:01:d8:80:39:d8:90:a0 iaid = -1564778168 valid for 300 seconds > 2022:12:06-09:29:52 access dhcpd6: Sending Advertise to :: port 546 > 2022:12:06-09:29:52 access dhcpd6: send_packet6: Network is unreachable Tries to send to all-zero IPv6. I wonder whether we can fool it by having broadcast IPv6 source address in our solicit :] > It's possible there might be clients that are working for me here that do have the source address set to :: (not certain). I need to get the tcpdump for these. I was assuming from the difference in log messages at the server that the source is always non-zero when it's working, but I need more information to prove that. Can you instrument d6_read_interface() in networking/udhcp/d6_socket.c for (ifa = ifap; ifa; ifa = ifa->ifa_next) { struct sockaddr_in6 *sip6; getifaddrs(&ifap); if (!ifa->ifa_addr || (strcmp(ifa->ifa_name, interface) != 0)) continue; +bb_error_msg("iface:'%s' sa_family:%u", interface, ifa->ifa_addr->sa_family ); if (ifa->ifa_addr->sa_family == AF_PACKET) { to see whether we do get any address info? > Section 4.1 > Every IPv6 interface on which DHCPv6 can reasonably be useful has a link-local address Fukushima's emergency manual stated that total loss of power is so unlikely that this scenario is not considered. My machine right now has all IPv6 addresses deleted by my firewall script. Why shouldn't it be able to get a DHCPv6 one? Anyway. The code DOES try to find client's own IPv6 address, and use it. Somehow, this does not work on your machine. Add debugging to d6_read_interface() to find out why. From David.Laight at ACULAB.COM Wed Dec 14 22:23:52 2022 From: David.Laight at ACULAB.COM (David Laight) Date: Wed, 14 Dec 2022 22:23:52 +0000 Subject: udhcpc6 missing source address In-Reply-To: References: <9f5e019210284f64bcd6671517dc159e@AcuMS.aculab.com> <2c22ad7112f547e195621c170e96d1ba@AcuMS.aculab.com> <489896a4d9014806a8ad49fcbac90bf4@AcuMS.aculab.com> Message-ID: <45070758679341acbca0945f8a73c225@AcuMS.aculab.com> From: Denys Vlasenko > Sent: 14 December 2022 21:17 ... > For comparison, this is how DHCPv4 looks on the wire: > > 28:df:eb:11:48:92 > Broadcast, ethertype IPv4 (0x0800), length 342: > (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length > 328) > 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from > 28:df:eb:11:48:92, length 300, xid 0x158e8233, Flags [none] > Client-Ethernet-Address 28:df:eb:11:48:92 > ... > 40:3f:8c:7c:7a:2d > 28:df:eb:11:48:92, ethertype IPv4 (0x0800), length > 342: (tos 0xc0, ttl 64, id 41793, offset 0, flags [none], proto UDP > (17), length 328) > 192.168.1.1.bootps > 192.168.1.193.bootpc: BOOTP/DHCP, Reply, > length 300, xid 0x158e8233, Flags [none] > Your-IP 192.168.1.193 > Server-IP 192.168.1.1 > > Not only the server is unfazed by source IP of 0.0.0.0, it > nevertheless sends _unicast_ reply, > because it saw client's MAC address. (It even filled our would-be IP > in the destination IP field, > to be extra nice). The 0.0.0.0 source IP is just a fudge, there is nothing else that can be put in the field. And you'll probably find the both the dchp client and server side are using the raw packet interface (with a BPF filter) to receive the packets. A Linux system that runs the dhcp client never reports any received ethernet packets as 'discarded by software' because they all get passed to dhcp! (At least one time I looked anyway) The IPv6 broadcast UDP packet (from the link-local address) is much more of a standard UDP packet than anything dhcp4 uses. Quite why the system in failing to allocate/return it's link-local address is another matter entirely. I think there is a standard wrapped that waits for the link-local address to appear before starting udhcpc6, we use this shell code: wait_link_local() { # Wait for the ipv6 link local address to appear. # Probably needed for dhcp6 to work at all. eth=$1 shift while ip_addr=$(ip "$@" address show dev "$eth" scope link 2>/dev/null) || return 1 [ "${ip_addr#*inet6 fe80}" = "$ip_addr" ] do sleep 0.5 done return 0 } We do have the full 'ip' command, not just the busybox version. I'm not sure what happens if you try to start udhcpc6 too soon. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) From vda.linux at googlemail.com Wed Dec 14 23:31:18 2022 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 15 Dec 2022 00:31:18 +0100 Subject: udhcpc6 missing source address In-Reply-To: <45070758679341acbca0945f8a73c225@AcuMS.aculab.com> References: <9f5e019210284f64bcd6671517dc159e@AcuMS.aculab.com> <2c22ad7112f547e195621c170e96d1ba@AcuMS.aculab.com> <489896a4d9014806a8ad49fcbac90bf4@AcuMS.aculab.com> <45070758679341acbca0945f8a73c225@AcuMS.aculab.com> Message-ID: On Wed, Dec 14, 2022 at 11:23 PM David Laight wrote: > From: Denys Vlasenko > > Sent: 14 December 2022 21:17 > A Linux system that runs the dhcp client never reports any > received ethernet packets as 'discarded by software' because > they all get passed to dhcp! > (At least one time I looked anyway) Shouldn't be doing that. After the lease is acquired and before renew time is reached, dhcp client just sleeps. It does not receive any packets. From Akash.Hadke at kpit.com Wed Dec 21 15:04:58 2022 From: Akash.Hadke at kpit.com (Akash Hadke) Date: Wed, 21 Dec 2022 15:04:58 +0000 Subject: [PATCH] zcip: add support for DoIP/ISO 13400 timings In-Reply-To: References: Message-ID: Hello, Is there any update on this? Best Regards, Akash Hadke ________________________________ From: Akash Hadke Sent: 05 September 2022 18:10 To: busybox at busybox.net Subject: [PATCH] zcip: add support for DoIP/ISO 13400 timings Package: busybox Version: v1.36.0 Severity: wishlist DoIP requires fast IP assignment, faster than what RFC 3927 can guarantee, and so it defines its' own AutoIP timing parameters Add a compile-time option to use DoIP timing parameters instead of default RFC 3927 parameters. This option is helpful for the use of zcip in automotive use cases. In practice, it decreases AutoIP allocation time from ~10s to ~2s, at the expense of less resilience to collisions Best Regards, Akash Hadke -------------- next part -------------- An HTML attachment was scrubbed... URL: From soeren at soeren-tempel.net Thu Dec 22 14:22:57 2022 From: soeren at soeren-tempel.net (=?UTF-8?Q?S=C3=B6ren?= Tempel) Date: Thu, 22 Dec 2022 15:22:57 +0100 Subject: [PATCH] ed: don't use memcpy with overlapping memory regions In-Reply-To: <34KG665IX3UJS.3FW56Z09RA3AK@8pit.net> References: <20220208192930.15089-1-soeren@soeren-tempel.net> <21PHGKH89PGCJ.3P3652PG9R9MG@8pit.net> <34KG665IX3UJS.3FW56Z09RA3AK@8pit.net> Message-ID: <31SAK73EXP4VU.3IXCK0OYH8096@8pit.net> PING. Any love for good old ed(1)? S?ren Tempel wrote: > Pinging again as this is still unfixed and the proposed fix is rather trivial. > > S?ren Tempel wrote: > > Ping. > > > > soeren at soeren-tempel.net wrote: > > > From: S?ren Tempel > > > > > > The memcpy invocations in the subCommand function, modified by this > > > commit, previously used memcpy with overlapping memory regions. This is > > > undefined behavior. On Alpine Linux, it causes BusyBox ed to crash since > > > we compile BusyBox with -D_FORTIFY_SOURCE=2 and our fortify-headers > > > implementation catches this source of undefined behavior [0]. The issue > > > can only be triggered if the replacement string is the same size or > > > shorter than the old string. > > > > > > Looking at the code, it seems to me that a memmove(3) is what was > > > actually intended here, this commit modifies the code accordingly. > > > > > > [0]: https://gitlab.alpinelinux.org/alpine/aports/-/issues/13504 > > > --- > > > editors/ed.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/editors/ed.c b/editors/ed.c > > > index 209ce9942..4a84f7433 100644 > > > --- a/editors/ed.c > > > +++ b/editors/ed.c > > > @@ -720,7 +720,7 @@ static void subCommand(const char *cmd, int num1, int num2) > > > if (deltaLen <= 0) { > > > memcpy(&lp->data[offset], newStr, newLen); > > > if (deltaLen) { > > > - memcpy(&lp->data[offset + newLen], > > > + memmove(&lp->data[offset + newLen], > > > &lp->data[offset + oldLen], > > > lp->len - offset - oldLen); > > > > > > _______________________________________________ > > > busybox mailing list > > > busybox at busybox.net > > > http://lists.busybox.net/mailman/listinfo/busybox > > _______________________________________________ > > busybox mailing list > > busybox at busybox.net > > http://lists.busybox.net/mailman/listinfo/busybox > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://lists.busybox.net/mailman/listinfo/busybox From David.Laight at ACULAB.COM Thu Dec 22 14:36:47 2022 From: David.Laight at ACULAB.COM (David Laight) Date: Thu, 22 Dec 2022 14:36:47 +0000 Subject: [PATCH] ed: don't use memcpy with overlapping memory regions In-Reply-To: <31SAK73EXP4VU.3IXCK0OYH8096@8pit.net> References: <20220208192930.15089-1-soeren@soeren-tempel.net> <21PHGKH89PGCJ.3P3652PG9R9MG@8pit.net> <34KG665IX3UJS.3FW56Z09RA3AK@8pit.net> <31SAK73EXP4VU.3IXCK0OYH8096@8pit.net> Message-ID: <1e9470cd7df542e2909c438d436ab7f1@AcuMS.aculab.com> From: S?ren Tempel > Sent: 22 December 2022 14:23 > > PING. > > Any love for good old ed(1)? Some versions of glibc will also do 'not strictly increasing' memcpy() on some x86 cpu. Just copying the last 4/8 bytes first and then doing a forwards copy is enough to break things. David > > S?ren Tempel wrote: > > Pinging again as this is still unfixed and the proposed fix is rather trivial. > > > > S?ren Tempel wrote: > > > Ping. > > > > > > soeren at soeren-tempel.net wrote: > > > > From: S?ren Tempel > > > > > > > > The memcpy invocations in the subCommand function, modified by this > > > > commit, previously used memcpy with overlapping memory regions. This is > > > > undefined behavior. On Alpine Linux, it causes BusyBox ed to crash since > > > > we compile BusyBox with -D_FORTIFY_SOURCE=2 and our fortify-headers > > > > implementation catches this source of undefined behavior [0]. The issue > > > > can only be triggered if the replacement string is the same size or > > > > shorter than the old string. > > > > > > > > Looking at the code, it seems to me that a memmove(3) is what was > > > > actually intended here, this commit modifies the code accordingly. > > > > > > > > [0]: https://gitlab.alpinelinux.org/alpine/aports/-/issues/13504 > > > > --- > > > > editors/ed.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/editors/ed.c b/editors/ed.c > > > > index 209ce9942..4a84f7433 100644 > > > > --- a/editors/ed.c > > > > +++ b/editors/ed.c > > > > @@ -720,7 +720,7 @@ static void subCommand(const char *cmd, int num1, int num2) > > > > if (deltaLen <= 0) { > > > > memcpy(&lp->data[offset], newStr, newLen); > > > > if (deltaLen) { > > > > - memcpy(&lp->data[offset + newLen], > > > > + memmove(&lp->data[offset + newLen], > > > > &lp->data[offset + oldLen], > > > > lp->len - offset - oldLen); > > > > > > > > _______________________________________________ > > > > busybox mailing list > > > > busybox at busybox.net > > > > http://lists.busybox.net/mailman/listinfo/busybox > > > _______________________________________________ > > > busybox mailing list > > > busybox at busybox.net > > > http://lists.busybox.net/mailman/listinfo/busybox > > _______________________________________________ > > busybox mailing list > > busybox at busybox.net > > http://lists.busybox.net/mailman/listinfo/busybox > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://lists.busybox.net/mailman/listinfo/busybox - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) From rmy at pobox.com Thu Dec 29 13:45:51 2022 From: rmy at pobox.com (Ron Yorston) Date: Thu, 29 Dec 2022 13:45:51 +0000 Subject: [PATCH] shell: avoid segfault on ${0::0/0~09J}. Closes 15216 Message-ID: <63ad9a0f.MQrBKX7zM8Pqj639%rmy@pobox.com> Both ash and hush segfault when asked to evaluate ${0::0/0~09J}. The stack for integer values in the arithmetic code was too small: '09J' results in three integers. The leading zero starts an octal number but '9' isn't an octal digit so '0', '9' and the variable 'Z' are placed on the stack. Signed-off-by: Ron Yorston --- shell/math.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/shell/math.c b/shell/math.c index 76d22c9bd..83ef85c0c 100644 --- a/shell/math.c +++ b/shell/math.c @@ -588,7 +588,8 @@ evaluate_string(arith_state_t *math_state, const char *expr) /* The proof that there can be no more than strlen(startbuf)/2+1 * integers in any given correct or incorrect expression * is left as an exercise to the reader. */ - var_or_num_t *const numstack = alloca((expr_len / 2) * sizeof(numstack[0])); + /* Counterexample: 09J results in three integers. */ + var_or_num_t *const numstack = alloca((expr_len - 2) * sizeof(numstack[0])); var_or_num_t *numstackptr = numstack; /* Stack of operator tokens */ operator *const stack = alloca(expr_len * sizeof(stack[0])); -- 2.38.1 From steffen at sdaoden.eu Thu Dec 29 17:20:08 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 29 Dec 2022 18:20:08 +0100 Subject: [PATCH] shell: avoid segfault on ${0::0/0~09J}. Closes 15216 In-Reply-To: <63ad9a0f.MQrBKX7zM8Pqj639%rmy@pobox.com> References: <63ad9a0f.MQrBKX7zM8Pqj639%rmy@pobox.com> Message-ID: <20221229172008.iwlL3%steffen@sdaoden.eu> Ron Yorston wrote in <63ad9a0f.MQrBKX7zM8Pqj639%rmy at pobox.com>: |Both ash and hush segfault when asked to evaluate ${0::0/0~09J}. ... | shell/math.c | 3 ++- ... Without hurry or pressure or any of such sort, but to be more explicit than in the patch commit message of the thing i had sent, it must be said that the $(()) evaluator currently in use is broken in some ways. There are explicitly disabled tests. But more than what is tested. (And the ?: problem is not easy fixable with Dijkstra, a recursive descendent thing like bash is however also not a small solution.) I am sorry that the one i posted (too often) adds 2000 bytes, i would have thought it shrinks a bit when fully integrated. All i could offer for that is to introduce another configuration switch which disables the very costy and large ?: conditional branch evaluation, i would assume doing so would bring costs down by a large amount, while keeping the benefit of the (hopefully) graceful parser and evaluator. (And ?: is not standardized (yet); like &&, || etc. etc., but these are all simple binary operators.) P.S.: the only change since then is that i added some more tests, maybe grazy stuff e "<$((0||0||0||0||0||0||0||0||0||0))>" e "<$((0||0||0||0||0||0||0||0||0||3||0||0))>" e "<$((0||0||0||0||0||0||0||0||0||3||0&&0))>" e "<$((0||0||0||0||0||0||0||0||0||3&&0))>" e "<$(((0||0||0||0||0||0||0||0||0||3||0)&&0))>" e "<$(((0||0||0||0||0||0||0||0||0||3||0)&&3))>" s I1=10 I2=20;p "<$((I1+=I2+=I2))>";e "<$I1><$I2>" s I1=10 I2=20;p "<$((I1+=I2+=I1))>";e "<$I1><$I2>" s I1=10 I2=20;p "<$((I1+=I2+=I1+=I2))>";e "<$I1><$I2>" s I1=10 I2=20;p "<$((I1+=I2+=I1+=I1))>";e "<$I1><$I2>" --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From rmy at pobox.com Sat Dec 31 08:48:24 2022 From: rmy at pobox.com (Ron Yorston) Date: Sat, 31 Dec 2022 08:48:24 +0000 Subject: [PATCH] build system: fix linking on Red Hat systems Message-ID: <63aff758.hD7odp6w7lUTfEMG%rmy@pobox.com> Commit 77216c368 (Fix non-Linux builds) made linking with libresolv conditional on the output of 'gcc -dumpmachine' containing 'gnu'. This broke builds on Red Hat systems (Fedora, RHEL) and derivatives (CentOS, Rocky). Such systems report a machine type of the form 'x86_64-redhat-linux'. Check for 'linux' as well as 'gnu'. Signed-off-by: Ron Yorston --- Makefile.flags | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Makefile.flags b/Makefile.flags index 50137a78e..e484ab6c7 100644 --- a/Makefile.flags +++ b/Makefile.flags @@ -186,6 +186,8 @@ endif ifeq ($(CONFIG_FEATURE_NSLOOKUP_BIG),y) ifneq (,$(findstring gnu,$(shell $(CC) $(CFLAGS) -dumpmachine))) LDLIBS += resolv +else ifneq (,$(findstring linux,$(shell $(CC) $(CFLAGS) -dumpmachine))) +LDLIBS += resolv endif endif -- 2.38.1 From mjt at tls.msk.ru Sat Dec 31 09:43:38 2022 From: mjt at tls.msk.ru (Michael Tokarev) Date: Sat, 31 Dec 2022 12:43:38 +0300 Subject: [PATCH] build system: fix linking on Red Hat systems In-Reply-To: <63aff758.hD7odp6w7lUTfEMG%rmy@pobox.com> References: <63aff758.hD7odp6w7lUTfEMG%rmy@pobox.com> Message-ID: <4678f4af-cb8b-097a-1a81-2e3967c462d0@msgid.tls.msk.ru> 31.12.2022 11:48, Ron Yorston wrote: > Commit 77216c368 (Fix non-Linux builds) made linking with libresolv > conditional on the output of 'gcc -dumpmachine' containing 'gnu'. > > This broke builds on Red Hat systems (Fedora, RHEL) and derivatives > (CentOS, Rocky). Such systems report a machine type of the form > 'x86_64-redhat-linux'. > > Check for 'linux' as well as 'gnu'. This is - in my opinion - both wrong test to begin with, and a wrong fix. -lresolv is needed when nslookup applet is enabled, because it uses res_XXX functions, - this is regardless of the system, I think. I submitted a patch about this a few months ago. If anything, this can be made a test whenever we actually have and need -lresolv by doing a small compile test. Also, conditionals around linux are also wrong in my opinion, it should check (maybe with dumpmachine, - I used cpp check for __linux__ define instead) if it is being compiled for linux, and disable a bunch of linux-only applets as it has been before 2015 iirc. I also submitted a fix for this a few months back. /mjt > Signed-off-by: Ron Yorston > --- > Makefile.flags | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Makefile.flags b/Makefile.flags > index 50137a78e..e484ab6c7 100644 > --- a/Makefile.flags > +++ b/Makefile.flags > @@ -186,6 +186,8 @@ endif > ifeq ($(CONFIG_FEATURE_NSLOOKUP_BIG),y) > ifneq (,$(findstring gnu,$(shell $(CC) $(CFLAGS) -dumpmachine))) > LDLIBS += resolv > +else ifneq (,$(findstring linux,$(shell $(CC) $(CFLAGS) -dumpmachine))) > +LDLIBS += resolv > endif > endif > From David.Laight at ACULAB.COM Sat Dec 31 11:23:14 2022 From: David.Laight at ACULAB.COM (David Laight) Date: Sat, 31 Dec 2022 11:23:14 +0000 Subject: [PATCH] build system: fix linking on Red Hat systems In-Reply-To: <4678f4af-cb8b-097a-1a81-2e3967c462d0@msgid.tls.msk.ru> References: <63aff758.hD7odp6w7lUTfEMG%rmy@pobox.com> <4678f4af-cb8b-097a-1a81-2e3967c462d0@msgid.tls.msk.ru> Message-ID: From: Michael Tokarev > Sent: 31 December 2022 09:44 > > 31.12.2022 11:48, Ron Yorston wrote: > > Commit 77216c368 (Fix non-Linux builds) made linking with libresolv > > conditional on the output of 'gcc -dumpmachine' containing 'gnu'. > > > > This broke builds on Red Hat systems (Fedora, RHEL) and derivatives > > (CentOS, Rocky). Such systems report a machine type of the form > > 'x86_64-redhat-linux'. > > > > Check for 'linux' as well as 'gnu'. > > This is - in my opinion - both wrong test to begin with, and a wrong > fix. -lresolv is needed when nslookup applet is enabled, because it > uses res_XXX functions, - this is regardless of the system, I think. > I submitted a patch about this a few months ago. If anything, this > can be made a test whenever we actually have and need -lresolv by > doing a small compile test. You don't need to check whether libresolv is needed just whether it exists. The linker won't (usually) add the NEEDED entry unless the library actually defines some undefined symbols. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) From mjt at tls.msk.ru Sat Dec 31 13:41:16 2022 From: mjt at tls.msk.ru (Michael Tokarev) Date: Sat, 31 Dec 2022 16:41:16 +0300 Subject: [PATCH] build system: fix linking on Red Hat systems In-Reply-To: References: <63aff758.hD7odp6w7lUTfEMG%rmy@pobox.com> <4678f4af-cb8b-097a-1a81-2e3967c462d0@msgid.tls.msk.ru> Message-ID: <3c292a5c-eb81-7814-bcf5-6a672ed8bc78@msgid.tls.msk.ru> 31.12.2022 14:23, David Laight wrote: [] > You don't need to check whether libresolv is needed just whether > it exists. We only need to worry about all this only if nslookup applet is in use (this is already the case in the Makefile), - this is what I mean, if we don't have nslookup we don't have to check for -lresolv. Checking for -lresolv existance is done by trying to link with -lresolv because it can be in different system-specific place which is known by the linker but not by the Makefile. > The linker won't (usually) add the NEEDED entry unless the library > actually defines some undefined symbols. It is only true when --when-needed is in effect. Historically, for many decades, it werent. I think ubuntu turned it on some years back (maybe when switching from ld to gold), but that's details. FWIW. /mjt