The asn1 implementation in (a) the Linux kernel 2.4 before 2.4.36.6 and 2.6 before 2.6.25.5, as used in the cifs and ipnatsnmpbasic modules; and (b) the gxsnmp package; does not properly validate length values during decoding of ASN.1 BER data, which allows remote attackers to cause a denial of service (crash) or execute arbitrary code via (1) a length greater than the working buffer, which can lead to an unspecified overflow; (2) an oid length of zero, which can lead to an off-by-one error; or (3) an indefinite length for a primitive encoding.

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

atm: idt77252: prevent use after free in dequeuerx()

We can't dereference "skb" after calling vcc->push() because the skb is released.

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

nfsd: fix heap overflow in NFSv4.0 LOCK replay cache

The NFSv4.0 replay cache uses a fixed 112-byte inline buffer (rpibuf[NFSD4REPLAYISIZE]) to store encoded operation responses. This size was calculated based on OPEN responses and does not account for LOCK denied responses, which include the conflicting lock owner as a variable-length field up to 1024 bytes (NFS4OPAQUELIMIT).

When a LOCK operation is denied due to a conflict with an existing lock that has a large owner, nfsd4encodeoperation() copies the full encoded response into the undersized replay buffer via readbytesfromxdrbuf() with no bounds check. This results in a slab-out-of-bounds write of up to 944 bytes past the end of the buffer, corrupting adjacent heap memory.

This can be triggered remotely by an unauthenticated attacker with two cooperating NFSv4.0 clients: one sets a lock with a large owner string, then the other requests a conflicting lock to provoke the denial.

We could fix this by increasing NFSD4REPLAYISIZE to allow for a full opaque, but that would increase the size of every stateowner, when most lockowners are not that large.

Instead, fix this by checking the encoded response length against NFSD4REPLAYISIZE before copying into the replay buffer. If the response is too large, set rpbuflen to 0 to skip caching the replay payload. The status is still cached, and the client already received the correct response on the original request.

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

media: dvb-net: fix OOB access in ULE extension header tables

The ulemandatoryexthandlers[] and uleoptionalexthandlers[] tables in handleoneuleextension() are declared with 255 elements (valid indices 0-254), but the index htype is derived from network-controlled data as (ulesndutype & 0x00FF), giving a range of 0-255. When htype equals 255, an out-of-bounds read occurs on the function pointer table, and the OOB value may be called as a function pointer.

Add a bounds check on htype against the array size before either table is accessed. Out-of-range values now cause the SNDU to be discarded.

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

net/x25: Fix potential double free of skb

When allocskb fails in x25queuerxframe it calls kfreeskb(skb) at line 48 and returns 1 (error). This error propagates back through the call chain:

x25queuerxframe returns 1 | v x25state3machine receives the return value 1 and takes the else branch at line 278, setting queued=0 and returning 0 | v x25processrxframe returns queued=0 | v x25backlogrcv at line 452 sees queued=0 and calls kfreeskb(skb) again

This would free the same skb twice. Looking at x25backlogrcv:

net/x25/x25in.c:x25backlogrcv() { ... queued = x25processrxframe(sk, skb); ... if (!queued) kfreeskb(skb); }

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

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

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

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

netrom: check buffer length before accessing it

Syzkaller reports an uninit value read from ax25cmp when sending raw message through ieee802154 implementation.

===================================================== BUG: KMSAN: uninit-value in ax25cmp+0x3a5/0x460 net/ax25/ax25addr.c:119 ax25cmp+0x3a5/0x460 net/ax25/ax25addr.c:119 nrdevget+0x20e/0x450 net/netrom/nrroute.c:601 nrrouteframe+0x1a2/0xfc0 net/netrom/nrroute.c:774 nrxmit+0x5a/0x1c0 net/netrom/nrdev.c:144 netdevstartxmit include/linux/netdevice.h:4940 [inline] netdevstartxmit include/linux/netdevice.h:4954 [inline] xmitone net/core/dev.c:3548 [inline] devhardstartxmit+0x247/0xa10 net/core/dev.c:3564 devqueuexmit+0x33b8/0x5130 net/core/dev.c:4349 devqueuexmit include/linux/netdevice.h:3134 [inline] rawsendmsg+0x654/0xc10 net/ieee802154/socket.c:299 ieee802154socksendmsg+0x91/0xc0 net/ieee802154/socket.c:96 socksendmsgnosec net/socket.c:730 [inline] socksendmsg net/socket.c:745 [inline] syssendmsg+0x9c2/0xd60 net/socket.c:2584 syssendmsg+0x28d/0x3c0 net/socket.c:2638 syssendmsg net/socket.c:2667 [inline] dosyssendmsg net/socket.c:2676 [inline] sesyssendmsg net/socket.c:2674 [inline] x64syssendmsg+0x307/0x490 net/socket.c:2674 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x44/0x110 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b

Uninit was created at: slabpostallochook+0x129/0xa70 mm/slab.h:768 slaballocnode mm/slub.c:3478 [inline] kmemcacheallocnode+0x5e9/0xb10 mm/slub.c:3523 kmallocreserve+0x13d/0x4a0 net/core/skbuff.c:560 allocskb+0x318/0x740 net/core/skbuff.c:651 allocskb include/linux/skbuff.h:1286 [inline] allocskbwithfrags+0xc8/0xbd0 net/core/skbuff.c:6334 sockallocsendpskb+0xa80/0xbf0 net/core/sock.c:2780 sockallocsendskb include/net/sock.h:1884 [inline] rawsendmsg+0x36d/0xc10 net/ieee802154/socket.c:282 ieee802154socksendmsg+0x91/0xc0 net/ieee802154/socket.c:96 socksendmsgnosec net/socket.c:730 [inline] socksendmsg net/socket.c:745 [inline] syssendmsg+0x9c2/0xd60 net/socket.c:2584 syssendmsg+0x28d/0x3c0 net/socket.c:2638 syssendmsg net/socket.c:2667 [inline] dosyssendmsg net/socket.c:2676 [inline] sesyssendmsg net/socket.c:2674 [inline] x64syssendmsg+0x307/0x490 net/socket.c:2674 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x44/0x110 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b

CPU: 0 PID: 5037 Comm: syz-executor166 Not tainted 6.7.0-rc7-syzkaller-00003-gfbafc3e621c3 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 =====================================================

This issue occurs because the skb buffer is too small, and it's actual allocation is aligned. This hides an actual issue, which is that nrrouteframe does not validate the buffer size before using it.

Fix this issue by checking skb->len before accessing any fields in skb->data.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

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

netfilter: ip6teui64: reject invalid MAC header for all packets

eui64mt6() derives a modified EUI-64 from the Ethernet source address and compares it with the low 64 bits of the IPv6 source address.

The existing guard only rejects an invalid MAC header when par->fragoff != 0. For packets with par->fragoff == 0, eui64mt6() can still reach ethhdr(skb) even when the MAC header is not valid.

Fix this by removing the par->fragoff != 0 condition so that packets with an invalid MAC header are rejected before accessing ethhdr(skb).

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

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

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

hfsplus: fix slab-out-of-bounds in hfsplusbnoderead()

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

netfilter: bridge: confirm multicast packets before passing them up the stack

conntrack nfconfirm logic cannot handle cloned skbs referencing the same nfconn entry, which will happen for multicast (broadcast) frames on bridges.

Example: macvlan0 | br0 / \ ethX ethY

ethX (or Y) receives a L2 multicast or broadcast packet containing an IP packet, flow is not yet in conntrack table.

1. skb passes through bridge and fake-ip (brnetfilter)Prerouting. -> skb->nfct now references a unconfirmed entry 2. skb is broad/mcast packet. bridge now passes clones out on each bridge interface. 3. skb gets passed up the stack. 4. In macvlan case, macvlan driver retains clone(s) of the mcast skb and schedules a work queue to send them out on the lower devices.

The clone skb->nfct is not a copy, it is the same entry as the original skb. The macvlan rx handler then returns RXHANDLERPASS. 5. Normal conntrack hooks (in NFINETLOCALIN) confirm the orig skb.

The Macvlan broadcast worker and normal confirm path will race.

This race will not happen if step 2 already confirmed a clone. In that case later steps perform skbclone() with skb->nfct already confirmed (in hash table). This works fine.

But such confirmation won't happen when eb/ip/nftables rules dropped the packets before they reached the nfconfirm step in postrouting.

Pablo points out that nfconntrackbridge doesn't allow use of stateful nat, so we can safely discard the nfconn entry and let inet call conntrack again.

This doesn't work for bridge netfilter: skb could have a nat transformation. Also bridge nf prevents re-invocation of inet prerouting via 'sabotagein' hook.

Work around this problem by explicit confirmation of the entry at LOCALIN time, before upper layer has a chance to clone the unconfirmed entry.

The downside is that this disables NAT and conntrack helpers.

Alternative fix would be to add locking to all code parts that deal with unconfirmed packets, but even if that could be done in a sane way this opens up other problems, for example:

-m physdev --physdev-out eth0 -j SNAT --snat-to 1.2.3.4 -m physdev --physdev-out eth1 -j SNAT --snat-to 1.2.3.5

For multicast case, only one of such conflicting mappings will be created, conntrack only handles 1:1 NAT mappings.

Users should set create a setup that explicitly marks such traffic NOTRACK (conntrack bypass) to avoid this, but we cannot auto-bypass them, ruleset might have accept rules for untracked traffic already, so user-visible behaviour would change.

ax25: fix use-after-free bugs caused by ax25dsdeltimer

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

rose: fix dangling neighbour pointers in rosertdevicedown()

There are two bugs in rosertdevicedown() that can cause use-after-free:

1. The loop bound t->count is modified within the loop, which can cause the loop to terminate early and miss some entries.

2. When removing an entry from the neighbour array, the subsequent entries are moved up to fill the gap, but the loop index i is still incremented, causing the next entry to be skipped.

For example, if a node has three neighbours (A, A, B) with count=3 and A is being removed, the second A is not checked.

i=0: (A, A, B) -> (A, B) with count=2 ^ checked i=1: (A, B) -> (A, B) with count=2 ^ checked (B, not A!) i=2: (doesn't occur because i < count is false)

This leaves the second A in the array with count=2, but the roseneigh structure has been freed. Code that accesses these entries assumes that the first count entries are valid pointers, causing a use-after-free when it accesses the dangling pointer.

Fix both issues by iterating over the array in reverse order with a fixed loop bound. This ensures that all entries are examined and that the removal of an entry doesn't affect subsequent iterations.

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

net: rose: include node references in roseneigh refcount

Current implementation maintains two separate reference counting mechanisms: the 'count' field in struct roseneigh tracks references from rosenode structures, while the 'use' field (now refcountt) tracks references from rosesock.

This patch merges these two reference counting systems using 'use' field for proper reference management. Specifically, this patch adds incrementing and decrementing of roseneigh->use when roseneigh->count is incremented or decremented.

This patch also modifies rosertfree(), rosertdevicedown() and roseclearroute() to properly release references to roseneigh objects before freeing a rosenode through roseremovenode().

These changes ensure roseneigh structures are properly freed only when all references, including those from rosenode structures, are released. As a result, this resolves a slab-use-after-free issue reported by Syzbot.

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

net: rose: convert 'use' field to refcountt

The 'use' field in struct roseneigh is used as a reference counter but lacks atomicity. This can lead to race conditions where a roseneigh structure is freed while still being referenced by other code paths.

For example, when roseneigh->use becomes zero during an ioctl operation via rosertioctl(), the structure may be removed while its timer is still active, potentially causing use-after-free issues.

This patch changes the type of 'use' from unsigned short to refcountt and updates all code paths to use roseneighhold() and roseneighput() which operate reference counts atomically.

ax25: properly unshare skbs in ax25kissrcv()

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

netrom: fix double-free in nrrouteframe()

In nrrouteframe(), oldskb is immediately freed without checking if nrneigh->ax25 pointer is NULL. Therefore, if nrneigh->ax25 is NULL, the caller function will free oldskb again, causing a double-free bug.

Therefore, to prevent this, we need to modify it to check whether nrneigh->ax25 is NULL before freeing oldskb.

Bluetooth: SCO: Fix use-after-free in scorecvframe() due to missing sockhold

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

xfs: delete attr leaf freemap entries when empty

Back in commit 2a2b5932db6758 ("xfs: fix attr leaf header freemap.size underflow"), Brian Foster observed that it's possible for a small freemap at the end of the end of the xattr entries array to experience a size underflow when subtracting the space consumed by an expansion of the entries array. There are only three freemap entries, which means that it is not a complete index of all free space in the leaf block.

This code can leave behind a zero-length freemap entry with a nonzero base. Subsequent setxattr operations can increase the base up to the point that it overlaps with another freemap entry. This isn't in and of itself a problem because the code in leafadd that finds free space ignores any freemap entry with zero size.

However, there's another bug in the freemap update code in leafadd, which is that it fails to update a freemap entry that begins midway through the xattr entry that was just appended to the array. That can result in the freemap containing two entries with the same base but different sizes (0 for the "pushed-up" entry, nonzero for the entry that's actually tracking free space). A subsequent leafadd can then allocate xattr namevalue entries on top of the entries array, leading to data loss. But fixing that is for later.

For now, eliminate the possibility of confusion by zeroing out the base of any freemap entry that has zero size. Because the freemap is not intended to be a complete index of free space, a subsequent failure to find any free space for a new xattr will trigger block compaction, which regenerates the freemap.

It looks like this bug has been in the codebase for quite a long time.

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

xfs: fix freemap adjustments when adding xattrs to leaf blocks

xfs/592 and xfs/794 both trip this assertion in the leaf block freemap adjustment code after ~20 minutes of running on my test VMs:

ASSERT(ichdr->firstused >= ichdr->count sizeof(xfsattrleafentryt) + xfsattr3leafhdrsize(leaf));

Upon enabling quite a lot more debugging code, I narrowed this down to fsstress trying to set a local extended attribute with namelen=3 and valuelen=71. This results in an entry size of 80 bytes.

At the start of xfsattr3leafaddwork, the freemap looks like this:

i 0 base 448 size 0 rhs 448 count 46 i 1 base 388 size 132 rhs 448 count 46 i 2 base 2120 size 4 rhs 448 count 46 firstused = 520

where "rhs" is the first byte past the end of the leaf entry array. This is inconsistent -- the entries array ends at byte 448, but freemap[1] says there's free space starting at byte 388!

By the end of the function, the freemap is in worse shape:

i 0 base 456 size 0 rhs 456 count 47 i 1 base 388 size 52 rhs 456 count 47 i 2 base 2120 size 4 rhs 456 count 47 firstused = 440

Important note: 388 is not aligned with the entries array element size of 8 bytes.

Based on the incorrect freemap, the name area starts at byte 440, which is below the end of the entries array! That's why the assertion triggers and the filesystem shuts down.

How did we end up here? First, recall from the previous patch that the freemap array in an xattr leaf block is not intended to be a comprehensive map of all free space in the leaf block. In other words, it's perfectly legal to have a leaf block with:

376 bytes in use by the entries array freemap[0] has [base = 376, size = 8] freemap[1] has [base = 388, size = 1500] the space between 376 and 388 is free, but the freemap stopped tracking that some time ago

If we add one xattr, the entries array grows to 384 bytes, and freemap[0] becomes [base = 384, size = 0]. So far, so good. But if we add a second xattr, the entries array grows to 392 bytes, and freemap[0] gets pushed up to [base = 392, size = 0]. This is bad, because freemap[1] hasn't been updated, and now the entries array and the free space claim the same space.

The fix here is to adjust all freemap entries so that none of them collide with the entries array. Note that this fix relies on commit 2a2b5932db6758 ("xfs: fix attr leaf header freemap.size underflow") and the previous patch that resets zero length freemap entries to have base = 0.

Bluetooth: serialize acceptq access

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

Bluetooth: bnep: Fix UAF read of dev->name

bnepaddconnection() needs to keep holding the bnepsessionsem while reading dev->name (just like bnepgetconnlist() does); otherwise the bnepsession() thread can concurrently free the netdevice, which can for example be triggered by a concurrent bnepdelconnection().

(This UAF is fairly uninteresting from a security perspective; calling bnepaddconnection() requires passing a capable(CAPNETADMIN) check. It also requires completely tearing down a netdev during a fairly tight race window.)

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

net: atm: fix use after free in lecsend()

The ->send() operation frees skb so save the length before calling ->send() to avoid a use after free.

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

pptp: ensure minimal skb length in pptpxmit()

Commit aabc6596ffb3 ("net: ppp: Add bound checking for skb data on pppsynctxmung") fixed pppsynctxmunge()

We need a similar fix in pptpxmit(), otherwise we might read uninit data as reported by syzbot.

BUG: KMSAN: uninit-value in pptpxmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 pptpxmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 pppchannelbridgeinput drivers/net/ppp/pppgeneric.c:2290 [inline] pppinput+0x1d6/0xe60 drivers/net/ppp/pppgeneric.c:2314 pppoercvcore+0x1e8/0x760 drivers/net/ppp/pppoe.c:379 skbacklogrcv+0x142/0x420 include/net/sock.h:1148 releasesock+0x1d3/0x330 net/core/sock.c:3213 releasesock+0x6b/0x270 net/core/sock.c:3767 pppoesendmsg+0x15d/0xcb0 drivers/net/ppp/pppoe.c:904 socksendmsgnosec net/socket.c:712 [inline] socksendmsg+0x330/0x3d0 net/socket.c:727 syssendmsg+0x893/0xd80 net/socket.c:2566 syssendmsg+0x271/0x3b0 net/socket.c:2620 syssendmmsg+0x2d9/0x7c0 net/socket.c:2709

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

udf: reject descriptors with oversized CRC length

udfreadtagged() skips CRC verification when descCRCLength + sizeof(struct tag) exceeds the block size. A crafted UDF image can set descCRCLength to an oversized value to bypass CRC validation entirely; the descriptor is then accepted based solely on the 8-bit tag checksum, which is trivially recomputable.

Reject such descriptors instead of silently accepting them. A legitimate single-block descriptor should never have a CRC length that exceeds the block.

hdlcppp: sync per-proto timers before freeing hdlc state