Where
AND
AND
-Infinity
0
Severity
5.5
CVSS:3.1/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: nftables: clone set on flush only

Syzbot with fault injection triggered a failing memory allocation with GFPKERNEL which results in a WARN splat:

iter.err WARNING: net/netfilter/nftablesapi.c:845 at nftmapdeactivate+0x34e/0x3c0 net/netfilter/nftablesapi.c:845, CPU#0: syz.0.17/5992 Modules linked in: CPU: 0 UID: 0 PID: 5992 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026 RIP: 0010:nftmapdeactivate+0x34e/0x3c0 net/netfilter/nftablesapi.c:845 Code: 8b 05 86 5a 4e 09 48 3b 84 24 a0 00 00 00 75 62 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc e8 63 6d fa f7 90 <0f> 0b 90 43 +80 7c 35 00 00 0f 85 23 fe ff ff e9 26 fe ff ff 89 d9 RSP: 0018:ffffc900045af780 EFLAGS: 00010293 RAX: ffffffff89ca45bd RBX: 00000000fffffff4 RCX: ffff888028111e40 RDX: 0000000000000000 RSI: 00000000fffffff4 RDI: 0000000000000000 RBP: ffffc900045af870 R08: 0000000000400dc0 R09: 00000000ffffffff R10: dffffc0000000000 R11: fffffbfff1d141db R12: ffffc900045af7e0 R13: 1ffff920008b5f24 R14: dffffc0000000000 R15: ffffc900045af920 FS: 000055557a6a5500(0000) GS:ffff888125496000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb5ea271fc0 CR3: 000000003269e000 CR4: 00000000003526f0 Call Trace: <TASK> nftreleasetable+0xceb/0x11f0 net/netfilter/nftablesapi.c:12115 nftrcvnlevent+0xc25/0xdb0 net/netfilter/nftablesapi.c:12187 notifiercallchain+0x19d/0x3a0 kernel/notifier.c:85 blockingnotifiercallchain+0x6a/0x90 kernel/notifier.c:380 netlinkrelease+0x123b/0x1ad0 net/netlink/afnetlink.c:761 sockrelease net/socket.c:662 [inline] sockclose+0xc3/0x240 net/socket.c:1455

Restrict set clone to the flush set command in the preparation phase. Add NFTITERUPDATECLONE and use it for this purpose, update the rbtree and pipapo backends to only clone the set when this iteration type is used.

As for the existing NFTITERUPDATE type, update the pipapo backend to use the existing set clone if available, otherwise use the existing set representation. After this update, there is no need to clone a set that is being deleted, this includes bound anonymous set.

An alternative approach to NFTITERUPDATECLONE is to add a .clone interface and call it from the flush set path.

1 / 2
Source: MITRE
First published (updated )
Severity
5.5
CVSS:3.1/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:

xfrmuser: fix info leak in buildmapping()

struct xfrmusersaid has a one-byte padding hole after the proto field, which ends up never getting set to zero before copying out to userspace. Fix that up by zeroing out the whole structure before setting individual variables.

First published (updated )
Severity
5.5
CVSS:3.1/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: nfnetlinklog: initialize nfgenmsg in NLMSGDONE terminator

When batching multiple NFLOG messages (inst->qlen > 1), nfulnlsend() appends an NLMSGDONE terminator with sizeof(struct nfgenmsg) payload via nlmsgput(), but never initializes the nfgenmsg bytes. The nlmsgput() helper only zeroes alignment padding after the payload, not the payload itself, so four bytes of stale kernel heap data are leaked to userspace in the NLMSGDONE message body.

Use nfnlmsgput() to build the NLMSGDONE terminator, which initializes the nfgenmsg payload via nfnlfillhdr(), consistent with how buildpacketmessage() already constructs NFULNLMSGPACKET headers.

First published (updated )
Severity
5.5
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: xtmultiport: validate range encoding in checkentry

portsmatchv1() treats any non-zero pflags entry as the start of a port range and unconditionally consumes the next ports[] element as the range end.

The checkentry path currently validates protocol, flags and count, but it does not validate the range encoding itself. As a result, malformed rules can mark the last slot as a range start or place two range starts back to back, leaving portsmatchv1() to step past the last valid ports[] element while interpreting the rule.

Reject malformed multiport v1 rules in checkentry by validating that each range start has a following element and that the following element is not itself marked as another range start.

1 / 2
Source: MITRE
First published (updated )
Severity
5.5
CVSS:3.1/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:

nftables: nftdynset: fix possible stateful expression memleak in error path

If cloning the second stateful expression in the element via GFPATOMIC fails, then the first stateful expression remains in place without being released.

unreferenced object (percpu) 0x607b97e9cab8 (size 16):     comm "softirq", pid 0, jiffies 4294931867     hex dump (first 16 bytes on cpu 3):       00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00     backtrace (crc 0):       pcpuallocnoprof+0x453/0xd80       nftcounterclone+0x9c/0x190 [nftables]       nftexprclone+0x8f/0x1b0 [nftables]       nftdynsetnew+0x2cb/0x5f0 [nftables]       nftrhashupdate+0x236/0x11c0 [nftables]       nftdynseteval+0x11f/0x670 [nftables]       nftdochain+0x253/0x1700 [nftables]       nftdochainipv4+0x18d/0x270 [nftables]       nfhookslow+0xaa/0x1e0       iplocaldeliver+0x209/0x330

First published (updated )
Severity
5.5
CVSS:3.1/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:

net: sched: clsapi: fix tcchainfillnode to initialize tcminfo to zero to prevent an info-leak

When building netlink messages, tcchainfillnode() never initializes the tcminfo field of struct tcmsg. Since the allocation is not zeroed, kernel heap memory is leaked to userspace through this 4-byte field.

The fix simply zeroes tcminfo alongside the other fields that are already initialized.

First published (updated )
Severity
5.5
CVSS:3.1/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: ctnetlink: zero expect NAT fields when CTAEXPECTNAT absent

ctnetlinkallocexpect() allocates expectations from a non-zeroing slab cache via nfctexpectalloc(). When CTAEXPECTNAT is not present in the netlink message, savedaddr and savedproto are never initialized. Stale data from a previous slab occupant can then be dumped to userspace by ctnetlinkexpdumpexpect(), which checks these fields to decide whether to emit CTAEXPECTNAT.

The safe sibling nfctexpectinit(), used by the packet path, explicitly zeroes these fields.

Zero savedaddr, savedproto and dir in the else branch, guarded by ISENABLED(CONFIGNFNAT) since these fields only exist when NAT is enabled.

Confirmed by priming the expect slab with NAT-bearing expectations, freeing them, creating a new expectation without CTAEXPECTNAT, and observing that the ctnetlink dump emits a spurious CTAEXPECTNAT containing stale data from the prior allocation.

First published (updated )
Severity
5.5
CVSS:3.1/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: nftables: reject immediate NFQUEUE verdict

nftqueue is always used from userspace nftables to deliver the NFQUEUE verdict. Immediately emitting an NFQUEUE verdict is never used by the userspace nft tools, so reject immediate NFQUEUE verdicts.

The arp family does not provide queue support, but such an immediate verdict is still reachable. Globally reject NFQUEUE immediate verdicts to address this issue.

First published (updated )
Severity
5.5
CVSS:3.1/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:

bridge: brndsend: validate ND option lengths

brndsend() walks ND options according to option-provided lengths. A malformed option can make the parser advance beyond the computed option span or use a too-short source LLADDR option payload.

Validate option lengths against the remaining NS option area before advancing, and only read source LLADDR when the option is large enough for an Ethernet address.

First published (updated )
Severity
5.5
CVSS:3.1/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:

net: ftgmac100: fix ring allocation unwind on open failure

ftgmac100allocrings() allocates rxskbs, txskbs, rxdes, txdes, and rxscratch in stages. On intermediate failures it returned -ENOMEM directly, leaking resources allocated earlier in the function.

Rework the failure path to use staged local unwind labels and free allocated resources in reverse order before returning -ENOMEM. This matches common netdev allocation cleanup style.

First published (updated )
Severity
5.5
CVSS:3.1/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:

xfrmuser: fix info leak in buildreport()

struct xfrmuserreport is a u8 proto field followed by a struct xfrmselector which means there is three "empty" bytes of padding, but the padding is never zeroed before copying to userspace. Fix that up by zeroing the structure before setting individual member variables.

1 / 2
Source: MITRE
First published (updated )
Severity
5.5
CVSS:3.1/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:

net: rfkill: prevent unlimited numbers of rfkill events from being created

Userspace can create an unlimited number of rfkill events if the system is so configured, while not consuming them from the rfkill file descriptor, causing a potential out of memory situation. Prevent this from bounding the number of pending rfkill events at a "large" number (i.e. 1000) to prevent abuses like this.

1 / 2
Source: MITRE
First published (updated )
Severity
5.5
CVSS:3.1/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:

xfrm: clear trailing padding in buildpolexpire()

buildexpire() clears the trailing padding bytes of struct xfrmuserexpire after setting the hard field via memsetafter(), but the analogous function buildpolexpire() does not do this for struct xfrmuserpolexpire.

The padding bytes after the u8 hard field are left uninitialized from the heap allocation, and are then sent to userspace via netlink multicast to XFRMNLGRPEXPIRE listeners, leaking kernel heap memory contents.

Add the missing memsetafter() call, matching buildexpire().

1 / 2
Source: MITRE
First published (updated )
Severity
5.5
Use After Free, Null Pointer Dereference
CVSS:3.1/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:

mmc: vub300: fix NULL-deref on disconnect

Make sure to deregister the controller before dropping the reference to the driver data on disconnect to avoid NULL-pointer dereferences or use-after-free.

1 / 2
Source: MITRE
First published (updated )
Severity
5.5
CVSS:3.1/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:

rxrpc: fix reference count leak in rxrpcserverkeyring()

This patch fixes a reference count leak in rxrpcserverkeyring() by checking if rx->securities is already set.

1 / 2
Source: MITRE
First published (updated )
Severity
5.5
CVSS:3.1/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:

RDMA/irdma: Fix deadlock during netdev reset with active connections

Resolve deadlock that occurs when user executes netdev reset while RDMA applications (e.g., rping) are active. The netdev reset causes ice driver to remove irdma auxiliary driver, triggering devicedelete and subsequent client removal. During client removal, uverbsclient waits for QP reference count to reach zero while cmaclient holds the final reference, creating circular dependency and indefinite wait in iWARP mode. Skip QP reference count wait during device reset to prevent deadlock.

1 / 2
Source: MITRE
First published (updated )
Severity
5.5
Null Pointer Dereference
CVSS:3.1/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:

net: bonding: fix NULL deref in bonddebugrlbhashshow

rlbclearslave intentionally keeps RLB hash-table entries on the rxhashtblusedhead list with slave set to NULL when no replacement slave is available. However, bonddebugrlbhashshow visites clientinfo->slave without checking if it's NULL.

Other used-list iterators in bondalb.c already handle this NULL-slave state safely:

- rlbupdateclient returns early on !clientinfo->slave - rlbrequpdateslaveclients, rlbclearslave, and rlbrebalance compare slave values before visiting - lbrequpdatesubnetclients continues if slave is NULL

The following NULL deref crash can be trigger in bonddebugrlbhashshow:

[ 1.289791] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 1.292058] RIP: 0010:bonddebugrlbhashshow (drivers/net/bonding/bonddebugfs.c:41) [ 1.293101] RSP: 0018:ffffc900004a7d00 EFLAGS: 00010286 [ 1.293333] RAX: 0000000000000000 RBX: ffff888102b48200 RCX: ffff888102b48204 [ 1.293631] RDX: ffff888102b48200 RSI: ffffffff839daad5 RDI: ffff888102815078 [ 1.293924] RBP: ffff888102815078 R08: ffff888102b4820e R09: 0000000000000000 [ 1.294267] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888100f929c0 [ 1.294564] R13: ffff888100f92a00 R14: 0000000000000001 R15: ffffc900004a7ed8 [ 1.294864] FS: 0000000001395380(0000) GS:ffff888196e75000(0000) knlGS:0000000000000000 [ 1.295239] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.295480] CR2: 0000000000000000 CR3: 0000000102adc004 CR4: 0000000000772ef0 [ 1.295897] Call Trace: [ 1.296134] seqreaditer (fs/seqfile.c:231) [ 1.296341] seqread (fs/seqfile.c:164) [ 1.296493] fullproxyread (fs/debugfs/file.c:378 (discriminator 1)) [ 1.296658] vfsread (fs/readwrite.c:572) [ 1.296981] ksysread (fs/readwrite.c:717) [ 1.297132] dosyscall64 (arch/x86/entry/syscall64.c:63 (discriminator 1) arch/x86/entry/syscall64.c:94 (discriminator 1)) [ 1.297325] entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130)

Add a NULL check and print "(none)" for entries with no assigned slave.

First published (updated )
Severity
5.5
CVSS:3.1/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:

udp: Fix wildcard bind conflict check when using hash2

When binding a udpsock to a local address and port, UDP uses two hashes (udptable->hash and udptable->hash2) for collision detection. The current code switches to "hash2" when hslot->count > 10.

"hash2" is keyed by local address and local port. "hash" is keyed by local port only.

The issue can be shown in the following bind sequence (pseudo code):

bind(fd1, "[fd00::1]:8888") bind(fd2, "[fd00::2]:8888") bind(fd3, "[fd00::3]:8888") bind(fd4, "[fd00::4]:8888") bind(fd5, "[fd00::5]:8888") bind(fd6, "[fd00::6]:8888") bind(fd7, "[fd00::7]:8888") bind(fd8, "[fd00::8]:8888") bind(fd9, "[fd00::9]:8888") bind(fd10, "[fd00::10]:8888")

/ Correctly return -EADDRINUSE because "hash" is used instead of "hash2". udpliblportinuse() detects the conflict. / bind(failfd, "[::]:8888")

/ After one more socket is bound to "[fd00::11]:8888", hslot->count exceeds 10 and "hash2" is used instead. / bind(fd11, "[fd00::11]:8888") bind(failfd, "[::]:8888") / succeeds unexpectedly /

The same issue applies to the IPv4 wildcard address "0.0.0.0" and the IPv4-mapped wildcard address "::ffff:0.0.0.0". For example, if there are existing sockets bound to "192.168.1.[1-11]:8888", then binding "0.0.0.0:8888" or "[::ffff:0.0.0.0]:8888" can also miss the conflict when hslot->count > 10.

TCP inetcskgetport() already has the correct check in inetusebhash2onbind(). Rename it to inetusehash2onbind() and move it to inethashtables.h so udp.c can reuse it in this fix.

1 / 2
Source: MITRE
First published (updated )
Severity
5.5
CVSS:3.1/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: nfconntrackexpect: skip expectations in other netns via proc

Skip expectations that do not reside in this netns.

Similar to e77e6ff502ea ("netfilter: conntrack: do not dump other netns's conntrack entries via proc").

1 / 2
Source: MITRE
First published (updated )
Severity
5.5
CVSS:3.1/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: ctnetlink: use netlink policy range checks

Replace manual range and mask validations with netlink policy annotations in ctnetlink code paths, so that the netlink core rejects invalid values early and can generate extack errors.

- CTAPROTOINFOTCPSTATE: reject values > TCPCONNTRACKSYNSENT2 at policy level, removing the manual >= TCPCONNTRACKMAX check. - CTAPROTOINFOTCPWSCALEORIGINAL/REPLY: reject values > TCPMAXWSCALE (14). The normal TCP option parsing path already clamps to this value, but the ctnetlink path accepted 0-255, causing undefined behavior when used as a u32 shift count. - CTAFILTERORIGFLAGS/REPLYFLAGS: use NLAPOLICYMASK with CTAFILTERFALL, removing the manual mask checks. - CTAEXPECTFLAGS: use NLAPOLICYMASK with NFCTEXPECTMASK, adding a new mask define grouping all valid expect flags.

Extracted from a broader nf-next patch by Florian Westphal, scoped to ctnetlink for the fixes tree.

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

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

mm/hugememory: fix folio isn't locked in softleaftofolio()

On arm64 server, we found folio that get from migration entry isn't locked in softleaftofolio(). This issue triggers when mTHP splitting and zapnonpresentptes() races, and the root cause is lack of memory barrier in softleaftofolio(). The race is as follows:

CPU0 CPU1

deferredsplitscan() zapnonpresentptes() lock folio splitfolio() unmapfolio() change ptes to migration entries splitfoliotoorder() softleaftofolio() set flags(including PGlocked) for tail pages folio = pfnfolio(softleaftopfn(entry)) smpwmb() VMWARNONONCE(!foliotestlocked(folio)) prepcompoundpage() for tail pages

In splitfoliotoorder(), smpwmb() guarantees page flags of tail pages are visible before the tail page becomes non-compound. smpwmb() should be paired with smprmb() in softleaftofolio(), which is missed. As a result, if zapnonpresentptes() accesses migration entry that stores tail pfn, softleaftofolio() may see the updated compoundhead of tail page before page->flags.

This issue will trigger VMWARNONONCE() in pfnswapentryfolio() because of the race between folio split and zapnonpresentptes() leading to a folio incorrectly undergoing modification without a folio lock being held.

This is a BUGON() before commit 93976a20345b ("mm: eliminate further swapops predicates"), which in merged in v6.19-rc1.

To fix it, add missing smprmb() if the softleaf entry is migration entry in softleaftofolio() and softleaftopage().

[tujinjiang@huawei.com: update function name and comments]

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

dmaengine: idxd: Fix memory leak when a wq is reset

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

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

netfilter: nfnetlinklog: fix uninitialized padding leak in NFULAPAYLOAD

buildpacketmessage() manually constructs the NFULAPAYLOAD netlink attribute using skbput() and skbcopybits(), bypassing the standard nlareserve()/nlaput() helpers. While nlatotalsize(datalen) bytes are allocated (including NLA alignment padding), only datalen bytes of actual packet data are copied. The trailing nlapadlen(datalen) bytes (1-3 when datalen is not 4-byte aligned) are never initialized, leaking stale heap contents to userspace via the NFLOG netlink socket.

Replace the manual attribute construction with nlareserve(), which handles the tailroom check, header setup, and padding zeroing via nlareserve(). The subsequent skbcopybits() fills in the payload data on top of the properly initialized attribute.

1 / 2
Source: MITRE
First published (updated )
Severity
5.5
Null Pointer Dereference
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: xtables: restrict xtcheckmatch/xtchecktarget extensions for NFPROTOARP

Weiming Shi says:

xtmatch and xttarget structs registered with NFPROTOUNSPEC can be loaded by any protocol family through nftcompat. When such a match/target sets .hooks to restrict which hooks it may run on, the bitmask uses NFINET constants. This is only correct for families whose hook layout matches NFINET: IPv4, IPv6, INET, and bridge all share the same five hooks (PREROUTING ... POSTROUTING).

ARP only has three hooks (IN=0, OUT=1, FORWARD=2) with different semantics. Because NFARPOUT == 1 == NFINETLOCALIN, the .hooks validation silently passes for the wrong reasons, allowing matches to run on ARP chains where the hook assumptions (e.g. state->in being set on input hooks) do not hold. This leads to NULL pointer dereferences; xtdevgroup is one concrete example:

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000044: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227] RIP: 0010:devgroupmt+0xff/0x350 Call Trace: <TASK> nftmatcheval (net/netfilter/nftcompat.c:407) nftdochain (net/netfilter/nftablescore.c:285) nftdochainarp (net/netfilter/nftchainfilter.c:61) nfhookslow (net/netfilter/core.c:623) arpxmit (net/ipv4/arp.c:666) </TASK> Kernel panic - not syncing: Fatal exception in interrupt

Fix it by restricting arptables to NFPROTOARP extensions only. Note that arptables-legacy only supports:

- arptCLASSIFY - arptmangle - arptMARK

that provide explicit NFPROTOARP match/target declarations.

1 / 2
Source: MITRE
First published (updated )
Severity
5.5
Divide by Zero
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:

net/sched: schhfsc: fix divide-by-zero in rtscmin()

m2sm() converts a u32 slope to a u64 scaled value. For large inputs (e.g. m1=4000000000), the result can reach 2^32. rtscmin() stores the difference of two such u64 values in a u32 variable dsm and uses it as a divisor. When the difference is exactly 2^32 the truncation yields zero, causing a divide-by-zero oops in the concave-curve intersection path:

Oops: divide error: 0000 RIP: 0010:rtscmin (net/sched/schhfsc.c:601) Call Trace: inited (net/sched/schhfsc.c:629) hfscenqueue (net/sched/schhfsc.c:1569) [...]

Widen dsm to u64 and replace dodiv() with div64u64() so the full difference is preserved.

1 / 2
Source: MITRE
First published (updated )
Severity
5.5
Null Pointer Dereference
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:

net/sched: clsflow: fix NULL pointer dereference on shared blocks

flowchange() calls tcfblockq() and dereferences q->handle to derive a default baseclass. Shared blocks leave block->q NULL, causing a NULL deref when a flow filter without a fully qualified baseclass is created on a shared block.

Check tcfblockshared() before accessing block->q and return -EINVAL for shared blocks. This avoids the null-deref shown below:

======================================================================= KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP: 0010:flowchange (net/sched/clsflow.c:508) Call Trace: tcnewtfilter (net/sched/clsapi.c:2432) rtnetlinkrcvmsg (net/core/rtnetlink.c:6980) [...] =======================================================================

1 / 2
Source: MITRE
First published (updated )
Severity
5.5
Null Pointer Dereference
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:

net/sched: clsfw: fix NULL pointer dereference on shared blocks

The old-method path in fwclassify() calls tcfblockq() and dereferences q->handle. Shared blocks leave block->q NULL, causing a NULL deref when an empty clsfw filter is attached to a shared block and a packet with a nonzero major skb mark is classified.

Reject the configuration in fwchange() when the old method (no TCAOPTIONS) is used on a shared block, since fwclassify()'s old-method path needs block->q which is NULL for shared blocks.

The fixed null-ptr-deref calling stack: KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP: 0010:fwclassify (net/sched/clsfw.c:81) Call Trace: tcfclassify (./include/net/tcwrapper.h:197 net/sched/clsapi.c:1764 net/sched/clsapi.c:1860) tcrun (net/core/dev.c:4401) devqueuexmit (net/core/dev.c:4535 net/core/dev.c:4790)

1 / 2
Source: MITRE
First published (updated )
Severity
5.5
CVSS:3.1/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:

ipv6: avoid overflows in ip6datagramsendctl()

Yiming Qian reported : <quote> I believe I found a locally triggerable kernel bug in the IPv6 sendmsg ancillary-data path that can panic the kernel via skbunderpanic() (local DoS).

The core issue is a mismatch between:

- a 16-bit length accumulator (struct ipv6txoptions::optflen, type u16) and - a pointer to the last provided destination-options header (opt->dst1opt)

when multiple IPV6DSTOPTS control messages (cmsgs) are provided.

- include/net/ipv6.h: - struct ipv6txoptions::optflen is u16 (wrap possible). (lines 291-307, especially 298) - net/ipv6/datagram.c:ip6datagramsendctl(): - Accepts repeated IPV6DSTOPTS and accumulates into optflen without rejecting duplicates. (lines 909-933) - net/ipv6/ip6output.c:ip6appenddata(): - Uses opt->optflen + opt->optnflen to compute header sizes/headroom decisions. (lines 1448-1466, especially 1463-1465) - net/ipv6/ip6output.c:ip6makeskb(): - Calls ipv6pushfragopts() if opt->optflen is non-zero. (lines 1930-1934) - net/ipv6/exthdrs.c:ipv6pushfragopts() / ipv6pushexthdr(): - Push size comes from ipv6optlen(opt->dst1opt) (based on the pointed-to header). (lines 1179-1185 and 1206-1211)

1. optflen is a 16-bit accumulator:

- include/net/ipv6.h:298 defines u16 optflen; / after fragment hdr /.

2. ip6datagramsendctl() accepts repeated IPV6DSTOPTS cmsgs and increments optflen each time:

- In net/ipv6/datagram.c:909-933, for IPV6DSTOPTS: - It computes len = ((hdr->hdrlen + 1) << 3); - It checks CAPNETRAW using nscapable(net->userns, CAPNETRAW). (line 922) - Then it does: - opt->optflen += len; (line 927) - opt->dst1opt = hdr; (line 928)

There is no duplicate rejection here (unlike the legacy IPV62292DSTOPTS path which rejects duplicates at net/ipv6/datagram.c:901-904).

If enough large IPV6DSTOPTS cmsgs are provided, optflen wraps while dst1opt still points to a large (2048-byte) destination-options header.

In the attached PoC (poc.c):

- 32 cmsgs with hdrlen=255 => len = (255+1)8 = 2048 - 1 cmsg with hdrlen=0 => len = 8 - Total increment: 322048 + 8 = 65544, so (u16)optflen == 8 - The last cmsg is 2048 bytes, so dst1opt points to a 2048-byte header.

3. The transmit path sizes headers using the wrapped optflen:

- In net/ipv6/ip6output.c:1463-1465: - headersize = sizeof(struct ipv6hdr) + (opt ? opt->optflen + opt->optnflen : 0) + ...;

With wrapped optflen, headersize/headroom decisions underestimate what will be pushed later.

4. When building the final skb, the actual push length comes from dst1opt and is not limited by wrapped optflen:

- In net/ipv6/ip6output.c:1930-1934: - if (opt->optflen) proto = ipv6pushfragopts(skb, opt, proto); - In net/ipv6/exthdrs.c:1206-1211, ipv6pushfragopts() pushes dst1opt via ipv6pushexthdr(). - In net/ipv6/exthdrs.c:1179-1184, ipv6pushexthdr() does: - skbpush(skb, ipv6optlen(opt)); - memcpy(h, opt, ipv6optlen(opt));

With insufficient headroom, skbpush() underflows and triggers skbunderpanic() -> BUG():

- net/core/skbuff.c:2669-2675 (skbpush() calls skbunderpanic()) - net/core/skbuff.c:207-214 (skbpanic() ends in BUG())

- The IPV6DSTOPTS cmsg path requires CAPNETRAW in the target netns user namespace (nscapable(net->userns, CAPNETRAW)). - Root (or any task with CAPNETRAW) can trigger this without user namespaces. - An unprivileged uid=1000 user can trigger this if unprivileged user namespaces are enabled and it can create a userns+netns to obtain namespaced CAPNETRAW (the attached PoC does this).

- Local denial of service: kernel BUG/panic (system crash). - ---truncated---

First published (updated )
Severity
5.5
Null Pointer Dereference
CVSS:3.1/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:

net: atm: fix crash due to unvalidated vcc pointer in sigdsend()

Reproducer available at [1].

The ATM send path (sendmsg -> vccsendmsg -> sigdsend) reads the vcc pointer from msg->vcc and uses it directly without any validation. This pointer comes from userspace via sendmsg() and can be arbitrarily forged:

int fd = socket(AFATMSVC, SOCKDGRAM, 0); ioctl(fd, ATMSIGDCTRL); // become ATM signaling daemon struct msghdr msg = { .msgiov = &iov, ... }; (unsigned long )(buf + 4) = 0xdeadbeef; // fake vcc pointer sendmsg(fd, &msg, 0); // kernel dereferences 0xdeadbeef

In normal operation, the kernel sends the vcc pointer to the signaling daemon via sigdenq() when processing operations like connect(), bind(), or listen(). The daemon is expected to return the same pointer when responding. However, a malicious daemon can send arbitrary pointer values.

Fix this by introducing findgetvcc() which validates the pointer by searching through vcchash (similar to how sigdclose() iterates over all VCCs), and acquires a reference via sockhold() if found.

Since struct atmvcc embeds struct sock as its first member, they share the same lifetime. Therefore using sockhold/sockput is sufficient to keep the vcc alive while it is being used.

Note that there may be a race with sigdclose() which could mark the vcc with various flags (e.g., ATMVFRELEASED) after findgetvcc() returns. However, sockhold() guarantees the memory remains valid, so this race only affects the logical state, not memory safety.

[1]: https://gist.github.com/mrpre/1ba5949c45529c511152e2f4c755b0f3

First published (updated )
Severity
5.5
CVSS:3.1/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:

net: usb: aqc111: Do not perform PM inside suspend callback

syzbot reports "task hung in rpmresume"

This is caused by aqc111suspend calling the PM variant of its writecmd routine.

The simplified call trace looks like this:

rpmsuspend() usbsuspendboth() - here udev->dev.power.runtimestatus == RPMSUSPENDING aqc111suspend() - called for the usb device interface aqc111write32cmd() usbautopmgetinterface() pmruntimeresumeandget() rpmresume() - here we call rpmresume() on our parent rpmresume() - Here we wait for a status change that will never happen.

At this point we block another task which holds rtnllock and locks up the whole networking stack.

Fix this by replacing the writecmd calls with their nopm variants

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