A use-after-free flaw was found in vhostnetsetbackend in drivers/vhost/net.c in virtio network subcomponent in the Linux kernel due to a double fget. This flaw could allow a local attacker to crash the system, and could even lead to a kernel information leak problem.

A use-after-free flaw was found in btsdioremove in drivers\bluetooth\btsdio.c in the Linux Kernel. A call to btsdioremove with an unfinished job may cause a race problem which leads to a UAF on hdev devices.

In the Linux kernel, the following vulnerability has been resolved:

vsock/virtio: Initialization of the dangling pointer occurring in vsk->trans

During loopback communication, a dangling pointer can be created in vsk->trans, potentially leading to a Use-After-Free condition. This issue is resolved by initializing vsk->trans to NULL.

In the Linux kernel, the following vulnerability has been resolved:

ALSA: usb-audio: Fix out of bounds reads when finding clock sources

The current USB-audio driver code doesn't check bLength of each descriptor at traversing for clock descriptors. That is, when a device provides a bogus descriptor with a shorter bLength, the driver might hit out-of-bounds reads.

For addressing it, this patch adds sanity checks to the validator functions for the clock descriptor traversal. When the descriptor length is shorter than expected, it's skipped in the loop.

For the clock source and clock multiplier descriptors, we can just check bLength against the sizeof() of each descriptor type. OTOH, the clock selector descriptor of UAC2 and UAC3 has an array of bNrInPins elements and two more fields at its tail, hence those have to be checked in addition to the sizeof() check.

In the Linux kernel, the following vulnerability has been resolved:

ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox devices

A bogus device can provide a bNumConfigurations value that exceeds the initial value used in usbgetconfiguration for allocating dev->config.

This can lead to out-of-bounds accesses later, e.g. in usbdestroyconfiguration.

In the Linux kernel, the following vulnerability has been resolved:

posix-cpu-timers: fix race between handleposixcputimers() and posixcputimerdel()

If an exiting non-autoreaping task has already passed exitnotify() and calls handleposixcputimers() from IRQ, it can be reaped by its parent or debugger right after unlocktasksighand().

If a concurrent posixcputimerdel() runs at that moment, it won't be able to detect timer->it.cpu.firing != 0: cputimertaskrcu() and/or locktasksighand() will fail.

Add the tsk->exitstate check into runposixcputimers() to fix this.

This fix is not needed if CONFIGPOSIXCPUTIMERSTASKWORK=y, because exittaskwork() is called before exitnotify(). But the check still makes sense, taskworkadd(&tsk->posixcputimerswork.work) will fail anyway in this case.

In the Linux kernel, the following vulnerability has been resolved:

media: dvbdev: prevent the risk of out of memory access

The dvbdev contains a static variable used to store dvb minors.

The behavior of it depends if CONFIGDVBDYNAMICMINORS is set or not. When not set, dvbregisterdevice() won't check for boundaries, as it will rely that a previous call to dvbregisteradapter() would already be enforcing it.

On a similar way, dvbdeviceopen() uses the assumption that the register functions already did the needed checks.

This can be fragile if some device ends using different calls. This also generate warnings on static check analysers like Coverity.

So, add explicit guards to prevent potential risk of OOM issues.

An issue was discovered in l2capsockrelease in net/bluetooth/l2capsock.c in the Linux kernel before 6.4.10. There is a use-after-free because the children of an sk are mishandled.

A remote denial of service vulnerability was found in the Linux kernel’s TIPC kernel module. The while loop in tipclinkxmit() hits an unknown state while attempting to parse SKBs, which are not in the queue. Sending two small UDP packets to a system with a UDP bearer results in the CPU utilization for the system to instantly spike to 100%, causing a denial of service condition.

A flaw in the Linux Kernel found. There are use-after-free vulnerabilities in drivers/media/rc/eneir.c of linux that allow attacker to crash linux kernel without any privilege by detaching rc device.

When the rc device is detaching, function eneremove() will be called. But the synchronizations in eneremove() are bad. The situations that may lead to race conditions are shown below.

Firstly, the rx receiver is disabled with enerxdisable() before rcunregisterdevice() in eneremove(), which means it can be enabled again if a process opens /dev/lirc0 between enerxdisable() and rcunregisterdevice().

(cleanup routine) | (open routine) eneremove() | enerxdisable(dev); | eneopen() | enerxenable(dev); //re-enable!

Secondly, the irqaction descriptor is freed by freeirq() before the rc device is unregistered, which means irqaction descriptor may be accessed again after it is deallocated.

(free routine) | (use routine) eneremove() | enerxenable() freeirq(dev->irq, ...); //FREE | enerxenablehw() | enewritereg(..., dev->irq << 1) //USE |

Thirdly, the timer can call enetxsample() that can write to the io ports, which means the io ports could be accessed again after they are deallocated by releaseregion().

(free routine) | (use routine) eneremove() | enetxsample() releaseregion(dev->hwio, ...); //FREE | enewritereg() | outb(..., dev->hwio + ENEIO) //USE

Fourthly, there is no function to cancel txsimtimer in eneremove(), the timer handler enetxirqsim() could race with eneremove(). As a result, the UAF bugs could happen, the process is shown below.

(free routine) | (use routine) | modtimer(&dev->txsimtimer, ..) eneremove() | (wait a time) kfree(dev) //FREE | enetxirqsim() | dev->hwlock //USE | enetxsample(dev) //USE

------------------------------------------

Reference: https://github.com/torvalds/linux/commit/29b0589a865b6f66d141d79b2dd1373e4e50fe17

An issue was discovered in flsetgeneveopt in net/sched/clsflower.c in the Linux kernel before 6.3.7. It allows an out-of-bounds write in the flower classifier code via TCAFLOWERKEYENCOPTSGENEVE packets. This may result in denial of service or privilege escalation.

A use-after-free vulnerability in the Linux kernel's afunix component can be exploited to achieve local privilege escalation.

The unixstreamsendpage() function tries to add data to the last skb in the peer's recv queue without locking the queue. Thus there is a race where unixstreamsendpage() could access an skb locklessly that is being released by garbage collection, resulting in use-after-free.

We recommend upgrading past commit 790c2f9d15b594350ae9bca7b236f2b1859de02c (or backported equivalents).

drm/dp: Fix OOB read when handling Post Cursor2 register

In the Linux kernel, the following vulnerability has been resolved:

net: dsa: free routing table on probe failure

If complete = true in dsatreesetup(), it means that we are the last switch of the tree which is successfully probing, and we should be setting up all switches from our probe path.

After "complete" becomes true, dsatreesetupcpuports() or any subsequent function may fail. If that happens, the entire tree setup is in limbo: the first N-1 switches have successfully finished probing (doing nothing but having allocated persistent memory in the tree's dst->ports, and maybe dst->rtable), and switch N failed to probe, ending the tree setup process before anything is tangible from the user's PoV.

If switch N fails to probe, its memory (ports) will be freed and removed from dst->ports. However, the dst->rtable elements pointing to its ports, as created by dsalinktouch(), will remain there, and will lead to use-after-free if dereferenced.

If dsatreesetupswitches() returns -EPROBEDEFER, which is entirely possible because that is where ds->ops->setup() is, we get a kasan report like this:

================================================================== BUG: KASAN: slab-use-after-free in mv88e6xxxsetupupstreamport+0x240/0x568 Read of size 8 at addr ffff000004f56020 by task kworker/u8:3/42

Call trace: asanreportload8noabort+0x20/0x30 mv88e6xxxsetupupstreamport+0x240/0x568 mv88e6xxxsetup+0xebc/0x1eb0 dsaregisterswitch+0x1af4/0x2ae0 mv88e6xxxregisterswitch+0x1b8/0x2a8 mv88e6xxxprobe+0xc4c/0xf60 mdioprobe+0x78/0xb8 reallyprobe+0x2b8/0x5a8 driverprobedevice+0x164/0x298 driverprobedevice+0x78/0x258 deviceattachdriver+0x274/0x350

Allocated by task 42: kasankmalloc+0x84/0xa0 kmalloccachenoprof+0x298/0x490 dsaswitchtouchports+0x174/0x3d8 dsaregisterswitch+0x800/0x2ae0 mv88e6xxxregisterswitch+0x1b8/0x2a8 mv88e6xxxprobe+0xc4c/0xf60 mdioprobe+0x78/0xb8 reallyprobe+0x2b8/0x5a8 driverprobedevice+0x164/0x298 driverprobedevice+0x78/0x258 deviceattachdriver+0x274/0x350

Freed by task 42: kasanslabfree+0x48/0x68 kfree+0x138/0x418 dsaregisterswitch+0x2694/0x2ae0 mv88e6xxxregisterswitch+0x1b8/0x2a8 mv88e6xxxprobe+0xc4c/0xf60 mdioprobe+0x78/0xb8 reallyprobe+0x2b8/0x5a8 driverprobedevice+0x164/0x298 driverprobedevice+0x78/0x258 deviceattachdriver+0x274/0x350

The simplest way to fix the bug is to delete the routing table in its entirety. dsatreesetuproutingtable() has no problem in regenerating it even if we deleted links between ports other than those of switch N, because dsalinktouch() first checks whether the port pair already exists in dst->rtable, allocating if not.

The deletion of the routing table in its entirety already exists in dsatreeteardown(), so refactor that into a function that can also be called from the tree setup error path.

In my analysis of the commit to blame, it is the one which added dsalink elements to dst->rtable. Prior to that, each switch had its own ds->rtable which is freed when the switch fails to probe. But the tree is potentially persistent memory.

In the Linux kernel, the following vulnerability has been resolved:

netfilter: flowtable: strictly check for maximum number of actions

The maximum number of flowtable hardware offload actions in IPv6 is:

ethernet mangling (4 payload actions, 2 for each ethernet address) SNAT (4 payload actions) DNAT (4 payload actions) Double VLAN (4 vlan actions, 2 for popping vlan, and 2 for pushing) for QinQ. Redirect (1 action)

Which makes 17, while the maximum is 16. But actct supports for tunnels actions too. Note that payload action operates at 32-bit word level, so mangling an IPv6 address takes 4 payload actions.

Update flowactionentrynext() calls to check for the maximum number of supported actions.

While at it, rise the maximum number of actions per flow from 16 to 24 so this works fine with IPv6 setups.

A flaw was found in the Linux kernel. This flaw allows an attacker to crash the Linux kernel by simulating amateur radio from the user space, resulting in a null-ptr-deref vulnerability and a use-after-free vulnerability.

drivers/usb/gadget/legacy/inode.c in the Linux kernel through 5.16.8 mishandles dev->buf release.

A flaw in the Linux Kernel found. A use-after-free vulnerability in the Linux kernel's net/sched: clsu32 component can be exploited to achieve local privilege escalation. If tcfchangeindev() fails, u32setparms() will immediately return an error after incrementing or decrementing the reference counter in tcfbindfilter(). If an attacker can control the reference counter and set it to zero, they can cause the reference to be freed, leading to a use-after-free vulnerability.

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=04c55383fa5689357bcdd2c8036725a55ed632bc

futex: Clear stale exiting pointer in futexlockpi() retry path

In the Linux kernel, the following vulnerability has been resolved:

SUNRPC: svcauthgss: avoid NULL deref on zero length gsstoken in gssreadproxyverf

A zero length gsstoken results in pages == 0 and intoken->pages[0] is NULL. The code unconditionally evaluates pageaddress(intoken->pages[0]) for the initial memcpy, which can dereference NULL even when the copy length is 0. Guard the first memcpy so it only runs when length > 0.

In the Linux kernel, the following vulnerability has been resolved:

tcp: Clear tcpsk(sk)->fastopenrsk in tcpdisconnect().

syzbot reported the splat below where a socket had tcpsk(sk)->fastopenrsk in the TCPESTABLISHED state. [0]

syzbot reused the server-side TCP Fast Open socket as a new client before the TFO socket completes 3WHS:

1. accept() 2. connect(AFUNSPEC) 3. connect() to another destination

As of accept(), sk->skstate is TCPSYNRECV, and tcpdisconnect() changes it to TCPCLOSE and makes connect() possible, which restarts timers.

Since tcpdisconnect() forgot to clear tcpsk(sk)->fastopenrsk, the retransmit timer triggered the warning and the intended packet was not retransmitted.

Let's call reqskfastopenremove() in tcpdisconnect().

[0]: WARNING: CPU: 2 PID: 0 at net/ipv4/tcptimer.c:542 tcpretransmittimer (net/ipv4/tcptimer.c:542 (discriminator 7)) Modules linked in: CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:tcpretransmittimer (net/ipv4/tcptimer.c:542 (discriminator 7)) Code: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 <0f> 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3e RSP: 0018:ffffc900002f8d40 EFLAGS: 00010293 RAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017 RDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400 RBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8 R10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540 R13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0 FS: 0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0 Call Trace: <IRQ> tcpwritetimer (net/ipv4/tcptimer.c:738) calltimerfn (kernel/time/timer.c:1747) runtimers (kernel/time/timer.c:1799 kernel/time/timer.c:2372) timerexpireremote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135) tmigrhandleremoteup (kernel/time/timermigration.c:944 kernel/time/timermigration.c:1035) walkgroups.isra.0 (kernel/time/timermigration.c:533 (discriminator 1)) tmigrhandleremote (kernel/time/timermigration.c:1096) handlesoftirqs (./arch/x86/include/asm/jumplabel.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580) irqexitrcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696) sysvecapictimerinterrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35)) </IRQ>

fs/buffer: fix use-after-free when call bhread() helper

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nfconncount: Fully initialize struct nfconncounttuple in inserttree()

Since commit b36e4523d4d5 ("netfilter: nfconncount: fix garbage collection confirm race"), cpu and jiffies32 were introduced to the struct nfconncounttuple.

The commit made nfconncountadd() initialize conn->cpu and conn->jiffies32 when allocating the struct. In contrast, counttree() was not changed to initialize them.

By commit 34848d5c896e ("netfilter: nfconncount: Split insert and traversal"), counttree() was split and the relevant allocation code now resides in inserttree(). Initialize conn->cpu and conn->jiffies32 in inserttree().

BUG: KMSAN: uninit-value in findorevict net/netfilter/nfconncount.c:117 [inline] BUG: KMSAN: uninit-value in nfconncountadd+0xd9c/0x2850 net/netfilter/nfconncount.c:143 findorevict net/netfilter/nfconncount.c:117 [inline] nfconncountadd+0xd9c/0x2850 net/netfilter/nfconncount.c:143 counttree net/netfilter/nfconncount.c:438 [inline] nfconncountcount+0x82f/0x1e80 net/netfilter/nfconncount.c:521 connlimitmt+0x7f6/0xbd0 net/netfilter/xtconnlimit.c:72 nftmatcheval net/netfilter/nftcompat.c:403 [inline] nftmatcheval+0x1a5/0x300 net/netfilter/nftcompat.c:433 exprcallopseval net/netfilter/nftablescore.c:240 [inline] nftdochain+0x426/0x2290 net/netfilter/nftablescore.c:288 nftdochainipv4+0x1a5/0x230 net/netfilter/nftchainfilter.c:23 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xf4/0x400 net/netfilter/core.c:626 nfhookslowlist+0x24d/0x860 net/netfilter/core.c:663 NFHOOKLIST include/linux/netfilter.h:350 [inline] ipsublistrcv+0x17b7/0x17f0 net/ipv4/ipinput.c:633 iplistrcv+0x9ef/0xa40 net/ipv4/ipinput.c:669 netifreceiveskblistptype net/core/dev.c:5936 [inline] netifreceiveskblistcore+0x15c5/0x1670 net/core/dev.c:5983 netifreceiveskblist net/core/dev.c:6035 [inline] netifreceiveskblistinternal+0x1085/0x1700 net/core/dev.c:6126 netifreceiveskblist+0x5a/0x460 net/core/dev.c:6178 xdprecvframes net/bpf/testrun.c:280 [inline] xdptestrunbatch net/bpf/testrun.c:361 [inline] bpftestrunxdplive+0x2e86/0x3480 net/bpf/testrun.c:390 bpfprogtestrunxdp+0xf1d/0x1ae0 net/bpf/testrun.c:1316 bpfprogtestrun+0x5e5/0xa30 kernel/bpf/syscall.c:4407 sysbpf+0x6aa/0xd90 kernel/bpf/syscall.c:5813 dosysbpf kernel/bpf/syscall.c:5902 [inline] sesysbpf kernel/bpf/syscall.c:5900 [inline] ia32sysbpf+0xa0/0xe0 kernel/bpf/syscall.c:5900 ia32syscall+0x394d/0x4180 arch/x86/include/generated/asm/syscalls32.h:358 dosyscall32irqson arch/x86/entry/common.c:165 [inline] dofastsyscall32+0xb0/0x110 arch/x86/entry/common.c:387 dofastsyscall32+0x38/0x80 arch/x86/entry/common.c:412 doSYSENTER32+0x1f/0x30 arch/x86/entry/common.c:450 entrySYSENTERcompatafterhwframe+0x84/0x8e

Uninit was created at: slabpostallochook mm/slub.c:4121 [inline] slaballocnode mm/slub.c:4164 [inline] kmemcacheallocnoprof+0x915/0xe10 mm/slub.c:4171 inserttree net/netfilter/nfconncount.c:372 [inline] counttree net/netfilter/nfconncount.c:450 [inline] nfconncountcount+0x1415/0x1e80 net/netfilter/nfconncount.c:521 connlimitmt+0x7f6/0xbd0 net/netfilter/xtconnlimit.c:72 nftmatcheval net/netfilter/nftcompat.c:403 [inline] nftmatcheval+0x1a5/0x300 net/netfilter/nftcompat.c:433 exprcallopseval net/netfilter/nftablescore.c:240 [inline] nftdochain+0x426/0x2290 net/netfilter/nftablescore.c:288 nftdochainipv4+0x1a5/0x230 net/netfilter/nftchainfilter.c:23 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xf4/0x400 net/netfilter/core.c:626 nfhookslowlist+0x24d/0x860 net/netfilter/core.c:663 NFHOOKLIST include/linux/netfilter.h:350 [inline] ipsublistrcv+0x17b7/0x17f0 net/ipv4/ipinput.c:633 iplistrcv+0x9ef/0xa40 net/ip ---truncated---

In the Linux kernel, the following vulnerability has been resolved:

net: gso: fix ownership in udpgsosegment

In udpgsosegment the skb destructor is removed before segmenting the skb but the socket reference is kept as-is. This is an issue if the original skb is later orphaned as we can hit the following bug:

kernel BUG at ./include/linux/skbuff.h:3312! (skborphan) RIP: 0010:iprcvcore+0x8b2/0xca0 Call Trace: iprcv+0xab/0x6e0 netifreceiveskbonecore+0x168/0x1b0 processbacklog+0x384/0x1100 napipoll.constprop.0+0xa1/0x370 netrxaction+0x925/0xe50

The above can happen following a sequence of events when using OpenVSwitch, when an OVSACTIONATTRUSERSPACE action precedes an OVSACTIONATTROUTPUT action:

1. OVSACTIONATTRUSERSPACE is handled (in doexecuteactions): the skb goes through queuegsopackets and then udpgsosegment, where its destructor is removed. 2. The segments' data are copied and sent to userspace. 3. OVSACTIONATTROUTPUT is handled (in doexecuteactions) and the same original skb is sent to its path. 4. If it later hits skborphan, we hit the bug.

Fix this by also removing the reference to the socket in udpgsosegment.

In the Linux kernel, the following vulnerability has been resolved:

ipv6: use RCU protection in ip6defaultadvmss()

ip6defaultadvmss() needs rcu protection to make sure the net structure it reads does not disappear.

In the Linux kernel, the following vulnerability has been resolved:

ndisc: use RCU protection in ndiscallocskb()

ndiscallocskb() can be called without RTNL or RCU being held.

Add RCU protection to avoid possible UAF.

In the Linux kernel, the following vulnerability has been resolved:

ndisc: extend RCU protection in ndiscsendskb()

ndiscsendskb() can be called without RTNL or RCU held.

Acquire rcureadlock() earlier, so that we can use devnetrcu() and avoid a potential UAF.

In the Linux kernel, the following vulnerability has been resolved:

nbd: don't allow reconnect after disconnect

Following process can cause nbdconfig UAF:

1) grab nbdconfig temporarily;

2) nbdgenldisconnect() flush all recvwork() and release the initial reference:

nbdgenldisconnect nbddisconnectandput nbddisconnect flushworkqueue(nbd->recvworkq) if (testandclearbit(NBDRTHASCONFIGREF, ...)) nbdconfigput -> due to step 1), reference is still not zero

3) nbdgenlreconfigure() queue recvwork() again;

nbdgenlreconfigure config = nbdgetconfigunlocked(nbd) if (!config) -> succeed if (!testbit(NBDRTBOUND, ...)) -> succeed nbdreconnectsocket queuework(nbd->recvworkq, &args->work)

4) step 1) release the reference;

5) Finially, recvwork() will trigger UAF:

recvwork nbdconfigput(nbd) -> nbdconfig is freed atomicdec(&config->recvthreads) -> UAF

Fix the problem by clearing NBDRTBOUND in nbdgenldisconnect(), so that nbdgenlreconfigure() will fail.

In the Linux kernel, the following vulnerability has been resolved:

pfifotailenqueue: Drop new packet when sch->limit == 0

Expected behaviour: In case we reach scheduler's limit, pfifotailenqueue() will drop a packet in scheduler's queue and decrease scheduler's qlen by one. Then, pfifotailenqueue() enqueue new packet and increase scheduler's qlen by one. Finally, pfifotailenqueue() return NETXMITCN status code.

Weird behaviour: In case we set sch->limit == 0 and trigger pfifotailenqueue() on a scheduler that has no packet, the 'drop a packet' step will do nothing. This means the scheduler's qlen still has value equal 0. Then, we continue to enqueue new packet and increase scheduler's qlen by one. In summary, we can leverage pfifotailenqueue() to increase qlen by one and return NETXMITCN status code.

The problem is: Let's say we have two qdiscs: QdiscA and QdiscB. - QdiscA's type must have '->graft()' function to create parent/child relationship. Let's say QdiscA's type is hfsc. Enqueue packet to this qdisc will trigger hfscenqueue. - QdiscB's type is pfifoheaddrop. Enqueue packet to this qdisc will trigger pfifotailenqueue. - QdiscB is configured to have sch->limit == 0. - QdiscA is configured to route the enqueued's packet to QdiscB.

Enqueue packet through QdiscA will lead to: - hfscenqueue(QdiscA) -> pfifotailenqueue(QdiscB) - QdiscB->q.qlen += 1 - pfifotailenqueue() return NETXMITCN - hfscenqueue() check for NETXMITSUCCESS and see NETXMITCN => hfscenqueue() don't increase qlen of QdiscA.

The whole process lead to a situation where QdiscA->q.qlen == 0 and QdiscB->q.qlen == 1. Replace 'hfsc' with other type (for example: 'drr') still lead to the same problem. This violate the design where parent's qlen should equal to the sum of its childrens'qlen.

Bug impact: This issue can be used for user->kernel privilege escalation when it is reachable.

In the Linux kernel, the following vulnerability has been resolved:

pps: Fix a use-after-free

On a board running ntpd and gpsd, I'm seeing a consistent use-after-free in sysexit() from gpsd when rebooting:

pps pps1: removed ------------[ cut here ]------------ kobject: '(null)' (00000000db4bec24): is not initialized, yet kobjectput() is being called. WARNING: CPU: 2 PID: 440 at lib/kobject.c:734 kobjectput+0x120/0x150 CPU: 2 UID: 299 PID: 440 Comm: gpsd Not tainted 6.11.0-rc6-00308-gb31c44928842 #1 Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : kobjectput+0x120/0x150 lr : kobjectput+0x120/0x150 sp : ffffffc0803d3ae0 x29: ffffffc0803d3ae0 x28: ffffff8042dc9738 x27: 0000000000000001 x26: 0000000000000000 x25: ffffff8042dc9040 x24: ffffff8042dc9440 x23: ffffff80402a4620 x22: ffffff8042ef4bd0 x21: ffffff80405cb600 x20: 000000000008001b x19: ffffff8040b3b6e0 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 696e6920746f6e20 x14: 7369203a29343263 x13: 205d303434542020 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: kobjectput+0x120/0x150 cdevput+0x20/0x3c fput+0x2c4/0x2d8 fput+0x1c/0x38 taskworkrun+0x70/0xfc doexit+0x2a0/0x924 dogroupexit+0x34/0x90 getsignal+0x7fc/0x8c0 dosignal+0x128/0x13b4 donotifyresume+0xdc/0x160 el0svc+0xd4/0xf8 el0t64synchandler+0x140/0x14c el0t64sync+0x190/0x194 ---[ end trace 0000000000000000 ]---

...followed by more symptoms of corruption, with similar stacks:

refcountt: underflow; use-after-free. kernel BUG at lib/listdebug.c:62! Kernel panic - not syncing: Oops - BUG: Fatal exception

This happens because ppsdevicedestruct() frees the ppsdevice with the embedded cdev immediately after calling cdevdel(), but, as the comment above cdevdel() notes, fops for previously opened cdevs are still callable even after cdevdel() returns. I think this bug has always been there: I can't explain why it suddenly started happening every time I reboot this particular board.

In commit d953e0e837e6 ("pps: Fix a use-after free bug when unregistering a source."), George Spelvin suggested removing the embedded cdev. That seems like the simplest way to fix this, so I've implemented his suggestion, using registerchrdev() with ppsidr becoming the source of truth for which minor corresponds to which device.

But now that ppsidr defines userspace visibility instead of cdevadd(), we need to be sure the pps->dev refcount can't reach zero while userspace can still find it again. So, the idrremove() call moves to ppsunregistercdev(), and ppsidr now holds a reference to pps->dev.

ppscore: source serial1 got cdev (251:1) <...> pps pps1: removed ppscore: unregistering pps1 ppscore: deallocating pps1