Re: Help needed with solving an axcall-related problem
Am Sun, Jan 16, 2022 at 07:44:00PM +0100 schrieb Thomas Osterried:
> > Am 14.01.2022 um 16:58 schrieb David Ranch <dranch@trinnet.net>:
[...]
> > 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, thank you for your Mail.
>
> My questions is: which kernel versioon is affected, and at
> which cpu architecture? And what's the debian release?
Hello,
I'm the person who originally posted to the debian-hams list
about the problem with axcall. I'm running Debian/sid a.k.a.
"unstable", i.e. Debian's development branch.
$ uname -v
#1 SMP Debian 5.15.5-2 (2021-12-18)
$ uname -m
x86_64
> 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 now built kernel 5.8.9 for testing purposes and indeed with
kernel 5.8.9 axcall doesn't show the error.
> I've not searched which kernel version has integrated the fix
> for the setsockopt bug.
> Appendix: kernel fix for the setsockopt stuff.
AFAICS it this fix is not yet contained in any official kernel
release, but a functionally equivalent patch seems to be queued
up for 5.17:
https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git/commit/?id=9371937092d5fd502032c1bb4475b36b39b1f1b3
I'll try building 5.16.1 with the patch applied and will then
report back. That might take a bit, though - this box is old
and slow :-).
Kind regards and many thanks for everybody's help,
Karsten
> > 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
> >
--
Hiermit widerspreche ich ausdrücklich der Nutzung sowie der Weitergabe
meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt-
oder Meinungsforschung.
Reply to: