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
| ||
|
Message-ID: <CANn89iKcmSfWgvZjzNGbsrndmCch2HC_EPZ7qmGboDNaWoviNQ@mail.gmail.com> Date: Wed, 20 Jul 2022 19:09:59 +0200 From: Eric Dumazet <edumazet@...gle.com> To: Jakub Kicinski <kuba@...nel.org> Cc: David Miller <davem@...emloft.net>, netdev <netdev@...r.kernel.org>, Paolo Abeni <pabeni@...hat.com>, Boris Pismenny <borisp@...dia.com>, John Fastabend <john.fastabend@...il.com>, Maxim Mikityanskiy <maximmi@...dia.com>, Tariq Toukan <tariqt@...dia.com>, vfedorenko@...ek.ru Subject: Re: [PATCH net-next v2 01/11] tls: rx: allow only one reader at a time On Wed, Jul 20, 2022 at 6:59 PM Jakub Kicinski <kuba@...nel.org> wrote: > > On Wed, 20 Jul 2022 10:37:02 +0200 Eric Dumazet wrote: > > > + if (!timeo) > > > + return -EAGAIN; > > > > We return with socket lock held, and callers seem to not release the lock. > > > > > + if (signal_pending(current)) > > > + return sock_intr_errno(timeo); > > > > same here. > > Thanks a lot for catching these. > > > Let's wait for syzbot to catch up :) > > I'll send the fixes later today. This is just a passing comment, right? > There isn't a report you know is coming? Otherwise I can wait to give > syzbot credit, too. I now have a full syzbot report, with a repro and bisection, I am releasing it now. > > I have two additional questions while I have you :) > > Is the timeo supposed to be for the entire operation? Right now TLS > seems to use a fresh timeo every time it goes to wait so the cumulative > wait can be much longer, as long as some data keeps coming in :/ Good question. I am not sure how this timeout is used in applications, but I would think it serves as a way to make sure a stall is detected. So restarting the timeout every time there is progress would make sense. Application needing a different behavior can still use regular timer, independent of networking, ( alarm() being the most simple one) > > Last one - I posted a bit of a disemboweling patch for TCP, LMK if it's > no bueno: > > https://lore.kernel.org/all/20220719231129.1870776-6-kuba@kernel.org/
Powered by blists - more mailing lists