Where
AND
AND
-Infinity
0
Severity
7.5
Use After Free, Null Pointer Dereference
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

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.

1 / 3
First published (updated )
Severity
7.8
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

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

1 / 2
Source: Launchpad
First published (updated )
Severity
7.8
Use After Free
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

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

1 / 7
Source: Red Hat
First published (updated )
Severity
7.8
Use After Free
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

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.

1 / 6
Source: MITRE
First published (updated )
Severity
7.8
Race Condition
AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

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.

1 / 3
Source: Red Hat
First published (updated )
Severity
7
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

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

1 / 2
Source: Microsoft
First published (updated )
Severity
7.5
Null Pointer Dereference
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

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.

First published (updated )
Severity
7.8
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H/E:U

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>

1 / 3
Source: Red Hat
First published (updated )
Severity
7.8
Use After Free
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H

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

1 / 2
Source: Microsoft
First published (updated )
Severity
7.3
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

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---

1 / 2
Source: MITRE
First published (updated )
Severity
7.8
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

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.

1 / 2
Source: NVD
First published (updated )
Severity
8.1
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

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.

First published (updated )
Severity
7.8
Use After Free
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

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.

1 / 2
Source: Red Hat
First published (updated )
Severity
8.1
Use After Free
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

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.

1 / 2
Source: MITRE
First published (updated )
Severity
7.8
Use After Free
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

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.

1 / 2
Source: MITRE
First published (updated )
Severity
7.8
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

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.

1 / 5
Source: NVD
First published (updated )
Severity
7.8
Use After Free
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

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

1 / 2
Source: Red Hat
First published (updated )
Severity
7.8
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

bpf: Prevent tail call between progs attached to different hooks

1 / 5
Source: Microsoft
First published (updated )
Severity
7.8
Use After Free, XEE
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

drm/amd/display: Fix slab-use-after-free in hdcp

1 / 2
Source: Microsoft
First published (updated )
Severity
7.8
Use After Free
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H

HID: lg-g15: cancel pending work on remove to fix a use-after-free

1 / 2
Source: Microsoft
First published (updated )
Severity
7.8
Use After Free
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

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

usb: typec: ucsi: ccg: Fix use-after-free of ucsi on remove

The threaded IRQ handler ccgirqhandler() calls ucsinotifycommon(), which on a connector-change event calls ucsiconnectorchange() and schedules connector work. In ucsiccgremove(), ucsidestroy() frees uc->ucsi (kfree) before freeirq() is called, so a handler invocation already in flight may access the freed object after ucsidestroy().

CPU 0 (remove) | CPU 1 (threaded IRQ) ucsidestroy(uc->ucsi) | ccgirqhandler() kfree(ucsi) // FREE | ucsinotifycommon(uc->ucsi) // USE

Move freeirq() before ucsidestroy() in the remove path. It is kept after ucsiunregister(): ucsiunregister() cancels connector work whose handler issues GETCONNECTORSTATUS through ucsisendcommandcommon(), which waits for a completion that is signalled from the IRQ handler, so the IRQ must stay active until that work has been cancelled.

The probe error path already orders freeirq() before ucsidestroy().

This bug was found by static analysis.

First published (updated )
Severity
7.8
Buffer Overflow
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

A heap buffer overflow flaw was found in IPsec ESP transformation code in net/ipv4/esp4.c and net/ipv6/esp6.c. This flaw allows a local attacker with a normal user privilege to overwrite kernel heap objects and may cause a local privilege escalation threat.

1 / 3
First published (updated )
Severity
7.8
Buffer Overflow
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Last updated 25 April 2025

1 / 2
Source: Ubuntu
First published (updated )
Severity
8.1
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H

An out-of-bounds (OOB) memory access flaw was found in fs/f2fs/node.c in the f2fs module in the Linux kernel in versions before 5.12.0-rc4. A bounds check failure allows a local attacker to gain access to out-of-bounds memory leading to a system crash or a leak of internal kernel information. The highest threat from this vulnerability is to system availability.

1 / 4
First published (updated )
Severity
7.1
Null Pointer Dereference
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H

A NULL pointer dereference flaw was found in btrfsrmdevice function in fs/btrfs/volumes.c in Linux Kernel, where triggering the bug requires ‘CAPSYSADMIN’. This could allow a local attacker to crash the system or leak kernel internal information.

References: https://lore.kernel.org/linux-btrfs/CAFcO6XO5TC5sEo-C9JGC75JkNAzkOSSLA3a=bwQqXFFbRTZ7Gw@mail.gmail.com/T/#md4b850f33616b7364f86e6fed144abc925f3669c https://lore.kernel.org/linux-btrfs/20210806102415.304717-1-wqu@suse.com/T/#u

1 / 3
Source: Red Hat
First published (updated )
Severity
7.1
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H

An out of bounds (OOB) memory access flaw was found in the Linux kernel in relayfilereadstartpos in kernel/relay.c in the relayfs. This flaw could allow a local attacker to crash the system or leak kernel internal information.

1 / 4
Source: Launchpad
First published (updated )
Severity
7.8
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

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.

First published (updated )
Severity
7.8
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

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

NFS: Fix filehandle bounds checking in nfsfhtodentry()

The function needs to check the minimal filehandle length before it can access the embedded filehandle.

1 / 2
Source: MITRE
First published (updated )
Severity
7.8
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

ALSA: usb-audio: Validate UAC3 cluster segment descriptors

1 / 2
Source: Microsoft
First published (updated )
Severity
8.8
Integer Underflow
AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

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

wifi: mwifiex: Fix OOB and integer underflow when rx packets

Make sure mwifiexprocessmgmtpacket, mwifiexprocessstarxpacket and mwifiexprocessuaprxpacket, mwifiexuapqueuebridgedpkt and mwifiexprocessrxpacket not out-of-bounds access the skb->data buffer.

1 / 2
Source: Red Hat
First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203