Control: tag -1 moreinfo On Tuesday, 21 June 2022 08:10:54 CEST Thorsten Glaser wrote: > Package: src:linux > Version: 4.19.235-1 > Severity: critical > Tags: upstream > Justification: breaks the whole system > > A recent upstream “stable” upgrade backported the removal of the > qdisc_destroy() function (which, in itself, is questionable enough > already and caused no small amount of fun) using qdisc_put() instead. > > However, qdisc_put() does not accept NULL pointers, causing oopses > in several qdiscs that can be configured on a system. This breaks > sudo (su works), networking and even deconfiguration is not possible, > only /proc/sysrq-trigger makes it possible to recover. > > https://www.mail-archive.com/netdev@vger.kernel.org/msg314288.html > fixes this but was not backported along. https://lore.kernel.org/all/20190921063607.GA1083276@kroah.com/ is about the 4.19.75 release and that contains that change in commit 7a1bad565cebfbf6956f9bb36dba734a48fa31d4 titled "net_sched: let qdisc_put() accept NULL pointer" which actually modifies the qdisc_destroy function https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/net/sched/sch_generic.c?h=linux-4.19.y#n1004 OTOH, does indeed not have that NULL check. In commit 92833e8b5db6c209e9311ac8c6a44d3bf1856659, part of v4.19.221, titled "net: sched: rename qdisc_destroy() to qdisc_put()" wasn't actually a straight rename, but some code moved around into a new qdisc_put function, which doesn't have the NULL check. In Debian, the release before 4.19.235-1 was 4.19.232-1 which should also have this bug. The release before that was 4.19.208-1, which shouldn't. Can you verify that? So I'm inclined to think that 92833e8b5db6c209e9311ac8c6a44d3bf1856659 is the commit which brought the bug back.
Attachment:
signature.asc
Description: This is a digitally signed message part.