[PATCH] uhttpd/file: fix string out of buffer range on uh_defer_script
if a url path length is multiple of 8, tailing zero will be trimed out on
uh_defer_script, cause a strangle error.
it's simple to reproduce.
1. create a luci controller, register a entry with path length multiple of 8
(including '/cgi-bin/'), for example, '/cgi-bin/luci/admin/system/admin'.
2. set uhttpd max_requests to 1, and restart uhttpd
3. request '/cgi-bin/luci/admin/system/admin' with at least 2 process
4. some responses will produce a error:
```
Unable to launch the requested CGI program:
/www/cgi-bin/luci: No such file or directory
```
Signed-off-by: Liangbin Lian
---
file.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/file.c b/file.c
index ac781c1..d117387 100644
--- a/file.c
+++ b/file.c
@@ -797,7 +797,7 @@ uh_defer_script(struct client *cl, struct dispatch_handler
*d, char *url, struct
/* allocate enough memory to duplicate all path_info strings in
one block */
#undef _field
#define _field(_name) &_##_name, field_len(pi->_name),
- dr = calloc_a(sizeof(*dr), &_url, strlen(url), path_info_fields
NULL);
+ dr = calloc_a(sizeof(*dr), &_url, strlen(url) + 1,
path_info_fields NULL);
memcpy(>pi, pi, sizeof(*pi));
dr->path = true;
@@ -807,7 +807,7 @@ uh_defer_script(struct client *cl, struct dispatch_handler
*d, char *url, struct
#define _field(_name) if (pi->_name) dr->pi._name = strcpy(_##_name,
pi->_name);
path_info_fields
} else {
- dr = calloc_a(sizeof(*dr), &_url, strlen(url), NULL);
+ dr = calloc_a(sizeof(*dr), &_url, strlen(url) + 1, NULL);
}
cl->dispatch.req_data = dr;
--
2.37.1 (Apple Git-137.1)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] package/uhttpd: fix string out of buffer range on uh_defer_script
Oh, I should send uhttpd patch, not the openwrt patch, sorry for that. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] uhttpd/file: fix string out of buffer range on uh_defer_script
if a url path length is multiple of 4, tailing zero will be trimed out on
uh_defer_script, cause a strangle error.
it's simple to reproduce.
1. create a luci controller, register a entry with path length multiple of 4
(including '/cgi-bin/'), for example, '/cgi-bin/luci/admin/system/admin'.
2. set uhttpd max_requests to 1, and restart uhttpd
3. request '/cgi-bin/luci/admin/system/admin' with at least 2 process
4. some responses will produce a error:
```
Unable to launch the requested CGI program:
/www/cgi-bin/luci: No such file or directory
```
Signed-off-by: Liangbin Lian
---
file.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/file.c b/file.c
index ac781c1..d117387 100644
--- a/file.c
+++ b/file.c
@@ -797,7 +797,7 @@ uh_defer_script(struct client *cl, struct dispatch_handler
*d, char *url, struct
/* allocate enough memory to duplicate all path_info strings in
one block */
#undef _field
#define _field(_name) &_##_name, field_len(pi->_name),
- dr = calloc_a(sizeof(*dr), &_url, strlen(url), path_info_fields
NULL);
+ dr = calloc_a(sizeof(*dr), &_url, strlen(url) + 1,
path_info_fields NULL);
memcpy(>pi, pi, sizeof(*pi));
dr->path = true;
@@ -807,7 +807,7 @@ uh_defer_script(struct client *cl, struct dispatch_handler
*d, char *url, struct
#define _field(_name) if (pi->_name) dr->pi._name = strcpy(_##_name,
pi->_name);
path_info_fields
} else {
- dr = calloc_a(sizeof(*dr), &_url, strlen(url), NULL);
+ dr = calloc_a(sizeof(*dr), &_url, strlen(url) + 1, NULL);
}
cl->dispatch.req_data = dr;
--
2.37.1 (Apple Git-137.1)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Virtualization issues w/ recent images
Hi, I built an image today for x86_64/generic with a recent sync to master on openwrt and packages. I dd'd the image (squashfs-combined) to the raw disk, zero padded the disk to grow it, and booted. The VM comes up with the following devices: 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000\link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: ip6tnl0@NONE: mtu 1452 qdisc noop state DOWN mode DEFAULT group default qlen 1000\link/tunnel6 :: brd :: permaddr 6efb:55c3:e992:: 3: tunl0@NONE: mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000\link/ipip 0.0.0.0 brd 0.0.0.0 4: sit0@NONE: mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000\link/sit 0.0.0.0 brd 0.0.0.0 5: dummy0: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000\link/ether 96:e1:89:d6:a2:3e brd ff:ff:ff:ff:ff:ff 6: eth0: mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000\link/ether 52:54:00:e0:53:8c brd ff:ff:ff:ff:ff:ff 7: eth1: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000\link/ether 52:54:00:b0:7f:fa brd ff:ff:ff:ff:ff:ff 8: gre0@NONE: mtu 1476 qdisc noop state DOWN mode DEFAULT group default qlen 1000\link/gre 0.0.0.0 brd 0.0.0.0 9: gretap0@NONE: mtu 1462 qdisc noop state DOWN mode DEFAULT group default qlen 1000\link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 10: erspan0@NONE: mtu 1450 qdisc noop state DOWN mode DEFAULT group default qlen 1000\link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 11: ip6gre0@NONE: mtu 1448 qdisc noop state DOWN mode DEFAULT group default qlen 1000\link/gre6 :: brd :: permaddr e61c:48fa:cb53:: 12: teql0: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 100\link/void But looking at the console: [4.063546] igbvf: Intel(R) Gigabit Virtual Function Network Driver [4.065506] igbvf: Copyright (c) 2009 - 2012 Intel Corporation. [4.075553] ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver [4.077456] ixgbe: Copyright (c) 1999-2016 Intel Corporation. [4.081776] ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function Network Driver [4.084057] ixgbevf: Copyright (c) 2009 - 2018 Intel Corporation. [4.101502] ixgbevf :00:03.0: 52:54:00:e0:53:8c [4.103049] ixgbevf :00:03.0: MAC: 4 [4.104268] ixgbevf :00:03.0: Intel(R) 82599 Virtual Function [4.121116] ixgbevf :00:04.0: 52:54:00:b0:7f:fa [4.122630] ixgbevf :00:04.0: MAC: 4 [4.123839] ixgbevf :00:04.0: Intel(R) 82599 Virtual Function ... [6.538991] 8021q: adding VLAN 0 to HW filter on device eth0 [6.541444] ixgbevf :00:03.0: NIC Link is Up 10 Gbps [6.542867] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready It seems like "eth0" is only ever getting tickled, not "eth1". Is there a way to debug this and figure out what's going on? I can bring up the interface just fine manually: root@OpenWrt-bios2:~# ip addr add 24.116.100.91/255.255.255.248 broadcast 24.116.100.95 dev eth1 root@OpenWrt-bios2:~# ip link set up dev eth1 root@OpenWrt-bios2:~# ip route add 0/0 via 24.116.100.89 dev eth1 proto static root@OpenWrt-bios2:~# ping -c5 24.116.100.89 PING 24.116.100.89 (24.116.100.89): 56 data bytes 64 bytes from 24.116.100.89: seq=0 ttl=64 time=1.160 ms 64 bytes from 24.116.100.89: seq=1 ttl=64 time=1.475 ms 64 bytes from 24.116.100.89: seq=2 ttl=64 time=1.809 ms 64 bytes from 24.116.100.89: seq=3 ttl=64 time=1.610 ms 64 bytes from 24.116.100.89: seq=4 ttl=64 time=0.731 ms --- 24.116.100.89 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 0.731/1.357/1.809 ms root@OpenWrt-bios2:~# What am I missing? Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] package/uhttpd: fix string out of buffer range on uh_defer_script
if a url path length is multiple of 8, tailing zero will be trimed out on
uh_defer_script, cause a strangle error.
it's simple to reproduce.
1. create a luci controller, register a entry with path length multiple of 8
(including '/cgi-bin/'), for example, '/cgi-bin/luci/admin/system/admin'.
2. set uhttpd max_requests to 1, and restart uhttpd
3. request '/cgi-bin/luci/admin/system/admin' with at least 2 processes
4. some responses will produce a error:
```
Unable to launch the requested CGI program:
/www/cgi-bin/luci: No such file or directory
```
Signed-off-by: Liangbin Lian
---
package/network/services/uhttpd/Makefile | 2 +-
.../001-fix-string-out-of-buffer-range.patch | 47 +++
2 files changed, 48 insertions(+), 1 deletion(-)
create mode 100644
package/network/services/uhttpd/patches/001-fix-string-out-of-buffer-range.patch
diff --git a/package/network/services/uhttpd/Makefile
b/package/network/services/uhttpd/Makefile
index 3923e55b07..f47a964dbc 100644
--- a/package/network/services/uhttpd/Makefile
+++ b/package/network/services/uhttpd/Makefile
@@ -8,7 +8,7 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=uhttpd
-PKG_RELEASE:=1
+PKG_RELEASE:=2
PKG_SOURCE_PROTO:=git
PKG_SOURCE_URL=$(PROJECT_GIT)/project/uhttpd.git
diff --git
a/package/network/services/uhttpd/patches/001-fix-string-out-of-buffer-range.patch
b/package/network/services/uhttpd/patches/001-fix-string-out-of-buffer-range.patch
new file mode 100644
index 00..39566c353a
--- /dev/null
+++
b/package/network/services/uhttpd/patches/001-fix-string-out-of-buffer-range.patch
@@ -0,0 +1,47 @@
+From c0e6e4393b4284d7287c3edbedbbd23da51b8da5 Mon Sep 17 00:00:00 2001
+From: Liangbin Lian
+Date: Fri, 14 Apr 2023 02:19:38 +0800
+Subject: [PATCH] file: fix string out of buffer range on uh_defer_script
+
+if a url path length is multiple of 8, tailing zero will be trimed out on
uh_defer_script, cause a strangle error.
+it's simple to reproduce.
+
+1. create a luci controller, register a entry with path length multiple of 8
(including '/cgi-bin/'), for example, '/cgi-bin/luci/admin/system/admin'.
+2. set uhttpd max_requests to 1, and restart uhttpd
+3. request '/cgi-bin/luci/admin/system/admin' with at least 2 processes
+4. some responses will produce a error:
+```
+Unable to launch the requested CGI program:
+ /www/cgi-bin/luci: No such file or directory
+```
+
+Signed-off-by: Liangbin Lian
+---
+ file.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/file.c b/file.c
+index ac781c1..d117387 100644
+--- a/file.c
b/file.c
+@@ -797,7 +797,7 @@ uh_defer_script(struct client *cl, struct dispatch_handler
*d, char *url, struct
+ /* allocate enough memory to duplicate all path_info strings in
one block */
+ #undef _field
+ #define _field(_name) &_##_name, field_len(pi->_name),
+- dr = calloc_a(sizeof(*dr), &_url, strlen(url), path_info_fields
NULL);
++ dr = calloc_a(sizeof(*dr), &_url, strlen(url) + 1,
path_info_fields NULL);
+
+ memcpy(>pi, pi, sizeof(*pi));
+ dr->path = true;
+@@ -807,7 +807,7 @@ uh_defer_script(struct client *cl, struct dispatch_handler
*d, char *url, struct
+ #define _field(_name) if (pi->_name) dr->pi._name = strcpy(_##_name,
pi->_name);
+ path_info_fields
+ } else {
+- dr = calloc_a(sizeof(*dr), &_url, strlen(url), NULL);
++ dr = calloc_a(sizeof(*dr), &_url, strlen(url) + 1, NULL);
+ }
+
+ cl->dispatch.req_data = dr;
+--
+2.31.0
+
--
2.37.1 (Apple Git-137.1)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Build problems with packages which are using openssl
I don't know if it's related, but syslog-ng-3.38.1 and now -4.1.1 keep crashing in libssl.so. [ 7263.710130] syslog-ng[6648]: segfault at 180 ip 7fe55725dd43 sp 7de33ed8 error 6 in libssl.so.3[7fe557252000+45000] [ 7263.715174] Code: e8 03 00 ff 15 8e dc 05 00 31 d2 31 c0 be 11 01 00 00 bf 14 00 00 00 ff 15 f2 d8 05 00 31 c0 5a c3 89 d1 48 8d 87 88 01 00 00 <48> 89 8f 80 01 00 00 48 39 f0 73 09 48 8d 14 08 48 39 d6 eb 0c 48 [ 7296.292439] syslog-ng[6767]: segfault at 180 ip 7fa446859d43 sp 7ffcb4e2dac8 error 6 in libssl.so.3[7fa44684e000+45000] [ 7296.297398] Code: e8 03 00 ff 15 8e dc 05 00 31 d2 31 c0 be 11 01 00 00 bf 14 00 00 00 ff 15 f2 d8 05 00 31 c0 5a c3 89 d1 48 8d 87 88 01 00 00 <48> 89 8f 80 01 00 00 48 39 f0 73 09 48 8d 14 08 48 39 d6 eb 0c 48 [ 7313.742858] syslog-ng[6832]: segfault at 180 ip 7f81280f0d43 sp 7fffcebbf898 error 6 in libssl.so.3[7f81280e5000+45000] [ 7313.747486] Code: e8 03 00 ff 15 8e dc 05 00 31 d2 31 c0 be 11 01 00 00 bf 14 00 00 00 ff 15 f2 d8 05 00 31 c0 5a c3 89 d1 48 8d 87 88 01 00 00 <48> 89 8f 80 01 00 00 48 39 f0 73 09 48 8d 14 08 48 39 d6 eb 0c 48 [ 7378.425765] syslog-ng[6916]: segfault at 180 ip 7f3c036a7d43 sp 7ffc825fd898 error 6 in libssl.so.3[7f3c0369c000+45000] [ 7378.430827] Code: e8 03 00 ff 15 8e dc 05 00 31 d2 31 c0 be 11 01 00 00 bf 14 00 00 00 ff 15 f2 d8 05 00 31 c0 5a c3 89 d1 48 8d 87 88 01 00 00 <48> 89 8f 80 01 00 00 48 39 f0 73 09 48 8d 14 08 48 39 d6 eb 0c 48 I'm having to switch over to rsyslog until we get this figured out. > On Apr 23, 2023, at 3:56 PM, e9hack wrote: > > Hi, > > in the past, it was possible to build packages, which are using crypto > libraries like openssl, wolfssl or mbedtls, in parallel. One was build for > the image, selected as , the others were build as module selected as . > > This doesn't work any more, if a package is selected for usage of openssl > with and any other crypto library is selected with . > > Compiling is successful, but installation complains about to install a binary > twice from two different packages. > > I'm not sure, since when this does occur, but I assume, it was introduced > with the openssl update to 3.0.x. > > Regards, > Hartmut > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Build problems with packages which are using openssl
Hi, in the past, it was possible to build packages, which are using crypto libraries like openssl, wolfssl or mbedtls, in parallel. One was build for the image, selected as , the others were build as module selected as . This doesn't work any more, if a package is selected for usage of openssl with and any other crypto library is selected with . Compiling is successful, but installation complains about to install a binary twice from two different packages. I'm not sure, since when this does occur, but I assume, it was introduced with the openssl update to 3.0.x. Regards, Hartmut ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[sdwalker/sdwalker.github.io] c9abf3: This week's update
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Branch: refs/heads/master Home: https://github.com/sdwalker/sdwalker.github.io Commit: c9abf32270a051840fea0bf97b22231c8874 https://github.com/sdwalker/sdwalker.github.io/commit/c9abf32270a051840fea0bf97b22231c8874 Author: Stephen Walker Date: 2023-04-23 (Sun, 23 Apr 2023) Changed paths: M uscan/index-21.02.html M uscan/index-22.03.html M uscan/index.html Log Message: --- This week's update --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ramips: fix green LED for D-Link DAP-X1860
Reviewed-by: Philip Prindeville
> On Apr 23, 2023, at 7:40 AM, Sebastian Schaper
> wrote:
>
> It was found this device uses a single tri-color power/status LED
> rather than individual red/orange LEDs, which also supports green.
>
> Add GPIO for green color and use with `boot` and `running` aliases.
>
> Signed-off-by: Sebastian Schaper
> ---
> .../linux/ramips/dts/mt7621_dlink_dap-x1860-a1.dts | 13 +
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/target/linux/ramips/dts/mt7621_dlink_dap-x1860-a1.dts
> b/target/linux/ramips/dts/mt7621_dlink_dap-x1860-a1.dts
> index 1aa3f7c91b..818d2d8c41 100644
> --- a/target/linux/ramips/dts/mt7621_dlink_dap-x1860-a1.dts
> +++ b/target/linux/ramips/dts/mt7621_dlink_dap-x1860-a1.dts
> @@ -15,9 +15,9 @@
>
> aliases {
> label-mac-device =
> - led-boot = _power_orange;
> + led-boot = _power_green;
> led-failsafe = _power_red;
> - led-running = _power_orange;
> + led-running = _power_green;
> led-upgrade = _power_red;
> };
>
> @@ -40,15 +40,20 @@
> leds {
> compatible = "gpio-leds";
>
> + led_power_green: power_green {
> + label = "green:power";
> + gpios = < 3 GPIO_ACTIVE_LOW>;
> + default-state = "on";
> + };
> +
> led_power_red: power_red {
> label = "red:power";
> gpios = < 7 GPIO_ACTIVE_LOW>;
> };
>
> - led_power_orange: power_orange {
> + power_orange {
> label = "orange:power";
> gpios = < 8 GPIO_ACTIVE_LOW>;
> - default-state = "on";
> };
>
> rssihigh {
> --
> 2.34.1
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] ramips: fix green LED for D-Link DAP-X1860
It was found this device uses a single tri-color power/status LED
rather than individual red/orange LEDs, which also supports green.
Add GPIO for green color and use with `boot` and `running` aliases.
Signed-off-by: Sebastian Schaper
---
.../linux/ramips/dts/mt7621_dlink_dap-x1860-a1.dts | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/target/linux/ramips/dts/mt7621_dlink_dap-x1860-a1.dts
b/target/linux/ramips/dts/mt7621_dlink_dap-x1860-a1.dts
index 1aa3f7c91b..818d2d8c41 100644
--- a/target/linux/ramips/dts/mt7621_dlink_dap-x1860-a1.dts
+++ b/target/linux/ramips/dts/mt7621_dlink_dap-x1860-a1.dts
@@ -15,9 +15,9 @@
aliases {
label-mac-device =
- led-boot = _power_orange;
+ led-boot = _power_green;
led-failsafe = _power_red;
- led-running = _power_orange;
+ led-running = _power_green;
led-upgrade = _power_red;
};
@@ -40,15 +40,20 @@
leds {
compatible = "gpio-leds";
+ led_power_green: power_green {
+ label = "green:power";
+ gpios = < 3 GPIO_ACTIVE_LOW>;
+ default-state = "on";
+ };
+
led_power_red: power_red {
label = "red:power";
gpios = < 7 GPIO_ACTIVE_LOW>;
};
- led_power_orange: power_orange {
+ power_orange {
label = "orange:power";
gpios = < 8 GPIO_ACTIVE_LOW>;
- default-state = "on";
};
rssihigh {
--
2.34.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
