linux-kernel - N_HDLC line discipline: Race condition

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240424173114.035ddd7b@gato.skoll.ca>
Date: Wed, 24 Apr 2024 17:31:14 -0400
From: Dianne Skoll <dianne@...ll.ca>
To: linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby
 <jirislaby@...nel.org>
Subject: N_HDLC line discipline: Race condition

Hi,

I'm reposting here (originally emailed GregKH and Jiri Slaby directly
as they are listed as tty maintainers) as well as responding to a
reply from Greg.

Original mail:

Some people have been reporting bugs using synchronous PPP with the
rp-pppoe user-space program.  See for example
https://github.com/dfskoll/rp-pppoe/issues/32

I've narrowed this down to the N_HDLC line discipline sometimes
concatenating two packets on the write side into a single read on the
other side.  I have attached a proof-of-concept program illustrating
the problem.

If you run:

/test_n_hdlc

with no arguments, then the program makes two writes in quick succession
to the tty followed by a read.  It generally only takes one or two tries
on my computer before I see both writes being combined in a single read.

On the other hand, if you run:

/test_n_hdlc foo

with a single argument, then the program sleeps for 0.1s between writes,
and I never see them being combined in a single read, even after 20 tries.

I'm running mainline kernel 6.8.7 on amd64; the processor model name
per cpuinfo is: AMD Ryzen Threadripper 3970X 32-Core Processor

Regards,

Dianne.

Greg's reply with my responses inline:

> What is wrong with that?  Does the N_HDLC line discipline somewhere
> state that this is not possible to happen?  Normal write combining
> happens for other tty ldiscs.  Userspace should be able to handle
> this, unless again, the N_HDLC ldisc somehow says that this should
> never happen.

> Ok, I looked at the comments at the top of the the ldisc, and it says
> this should not happen, so something is odd, I agree.

Right.  It's done that way so a PPP 'pty' helper always gets exactly one
frame when it reads from the tty file dscriptor.

> Did this change recently?  Or has this always been the case?  Meaning
> did something in the kernel change to cause this to break?

I haven't used this mode of PPP in over a decade, so I know it used to work,
but no longer does.  I'm sorry I can't narrow down more precisely as to
when it stopped working.

> Also, please cc: the linux-serial list for tty issues, doing stuff in
> private is generally not a good idea.

OK, sorry about that... I misread the bug reporting instructions and
forgot to Cc the lists.

Regards,

Dianne.

Download attachment "test_n_hdlc.tar.gz" of type "application/gzip" (1085 bytes)