Re: Help needed with solving an axcall-related problem
Hello,
David, thank you for your Mail.
My questions is:
which kernel versioon is affected, and at which cpu architecture? And what's the debian release?
The described problem seems to me a kernel issue (-> not a problem of libax25 or call).
The setsockopt call fails.
And we remember the exterrnal kernel patch in kernel 5.9x that arrived in 2020, that broke exactly the setsockopt function in 64bit systems.
-> This is the point where would start to search.
Sinice debian comes with many installable kernels, I think it's worth too test with downgrading the kernel to below 5.9x.
I've not searched which kernel version has integrated the fix for the setsockopt bug.
See appendix below.
> Am 14.01.2022 um 16:58 schrieb David Ranch <dranch@trinnet.net>:
>
>
> Hello Ralf, Thomas,
>
> It's looking like one of these recent untested Linux kernel commits, accepted by random non-packet developers, has made part of the Linux AX.25 stack toxic. Work is going on to bisect which kernel started the issue but I wanted to forward this directly on since I don't know if any of you are on the debian-hams list:
>
> https://lists.debian.org/debian-hams/2022/01/msg00106.html
>
> and it seems this user has also posted the issue in the Fedora tracker as well:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2039199
>
>
> Is it possible that one of you can give this a look? I'm still hoping that there is a way to get some level of unit tests put into some form of a Linux kernel CI process but I still haven't heard of any solution available.
>
> --David
> KI6ZHD
>
vy 73,
- Thomas dl9sau
Appendix: kernel fix for the setsockopt stuff.
> Von: Ralf Baechle <ralf@linux-mips.org>
> Betreff: [PATCH v2 1/2] ax25: Fix use of copy_from_sockptr() in ax25_setsockopt()
> Datum: 12. Oktober 2021 um 22:05:29 MESZ
> An: netdev@vger.kernel.org
> Kopie: "David S. Miller" <davem@davemloft.net>, Jakub Kicinski <kuba@kernel.org>, Christoph Hellwig <hch@lst.de>, Thomas Osterried <thomas@osterried.de>, linux-hams@vger.kernel.org
> Message-Id: <2dea23e9208d008e74faddf92acf4ef557f97a85.1634069168.git.ralf@linux-mips.org>
>
> The destination pointer passed to copy_from_sockptr() is an unsigned long *
> but the source in userspace is an unsigned int.
>
> This happens to work on 32 bit but breaks 64-bit where bytes 4..7 will not
> be initialized. By luck it may work on little endian but on big endian
> where the userspace data is copied to the upper 32 bit of the destination
> it's most likely going to break.
>
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
> Fixes: a7b75c5a8c41 ("net: pass a sockptr_t into ->setsockopt")
> ---
> net/ax25/af_ax25.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c
> index 2631efc6e359..5e7ab76f7f9b 100644
> --- a/net/ax25/af_ax25.c
> +++ b/net/ax25/af_ax25.c
> @@ -534,7 +534,7 @@ static int ax25_setsockopt(struct socket *sock, int level, int optname,
> ax25_cb *ax25;
> struct net_device *dev;
> char devname[IFNAMSIZ];
> - unsigned long opt;
> + unsigned int opt;
> int res = 0;
>
> if (level != SOL_AX25)
> @@ -566,7 +566,7 @@ static int ax25_setsockopt(struct socket *sock, int level, int optname,
> break;
>
> case AX25_T1:
> - if (opt < 1 || opt > ULONG_MAX / HZ) {
> + if (opt < 1 || opt > UINT_MAX / HZ) {
> res = -EINVAL;
> break;
> }
> @@ -575,7 +575,7 @@ static int ax25_setsockopt(struct socket *sock, int level, int optname,
> break;
>
> case AX25_T2:
> - if (opt < 1 || opt > ULONG_MAX / HZ) {
> + if (opt < 1 || opt > UINT_MAX / HZ) {
> res = -EINVAL;
> break;
> }
> @@ -591,7 +591,7 @@ static int ax25_setsockopt(struct socket *sock, int level, int optname,
> break;
>
> case AX25_T3:
> - if (opt < 1 || opt > ULONG_MAX / HZ) {
> + if (opt < 1 || opt > UINT_MAX / HZ) {
> res = -EINVAL;
> break;
> }
> @@ -599,7 +599,7 @@ static int ax25_setsockopt(struct socket *sock, int level, int optname,
> break;
>
> case AX25_IDLE:
> - if (opt > ULONG_MAX / (60 * HZ)) {
> + if (opt > UINT_MAX / (60 * HZ)) {
> res = -EINVAL;
> break;
> }
> --
> 2.31.1
>
>
>
Reply to: