bpf: Fix stack-out-of-bounds write in devmap

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

KVM: arm64: Fix ID register initialization for non-protected pKVM guests

In protected mode, the hypervisor maintains a separate instance of the kvm structure for each VM. For non-protected VMs, this structure is initialized from the host's kvm state.

Currently, pkvminitfeaturesfromhost() copies the KVMARCHFLAGIDREGSINITIALIZED flag from the host without the underlying idregs data being initialized. This results in the hypervisor seeing the flag as set while the ID registers remain zeroed.

Consequently, kvmhasfeat() checks at EL2 fail (return 0) for non-protected VMs. This breaks logic that relies on feature detection, such as ctxthastcrx() for TCR2EL1 support. As a result, certain system registers (e.g., TCR2EL1, PIREL1, POREL1) are not saved/restored during the world switch, which could lead to state corruption.

Fix this by explicitly copying the ID registers from the host kvm to the hypervisor kvm for non-protected VMs during initialization, since we trust the host with its non-protected guests' features. Also ensure KVMARCHFLAGIDREGSINITIALIZED is cleared initially in pkvminitfeaturesfromhost so that vmcopyidregs can properly initialize them and set the flag once done.

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

Bluetooth: L2CAP: Fix use-after-free in l2capunregisteruser

After commit ab4eedb790ca ("Bluetooth: L2CAP: Fix corrupted list in hcichandel"), l2capconndel() uses conn->lock to protect access to conn->users. However, l2capregisteruser() and l2capunregisteruser() don't use conn->lock, creating a race condition where these functions can access conn->users and conn->hchan concurrently with l2capconndel().

This can lead to use-after-free and list corruption bugs, as reported by syzbot.

Fix this by changing l2capregisteruser() and l2capunregisteruser() to use conn->lock instead of hcidevlock(), ensuring consistent locking for the l2capconn structure.

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

Bluetooth: HIDP: Fix possible UAF

This fixes the following trace caused by not dropping l2capconn reference when user->remove callback is called:

[ 97.809249] l2capconnfree: freeing conn ffff88810a171c00 [ 97.809907] CPU: 1 UID: 0 PID: 1419 Comm: reprostandalon Not tainted 7.0.0-rc1-dirty #14 PREEMPT(lazy) [ 97.809935] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 97.809947] Call Trace: [ 97.809954] <TASK> [ 97.809961] dumpstacklvl (lib/dumpstack.c:122) [ 97.809990] l2capconnfree (net/bluetooth/l2capcore.c:1808) [ 97.810017] l2capconndel (./include/linux/kref.h:66 net/bluetooth/l2capcore.c:1821 net/bluetooth/l2capcore.c:1798) [ 97.810055] l2capdisconncfm (net/bluetooth/l2capcore.c:7347 (discriminator 1) net/bluetooth/l2capcore.c:7340 (discriminator 1)) [ 97.810086] ? pfxl2capdisconncfm (net/bluetooth/l2capcore.c:7341) [ 97.810117] hciconnhashflush (./include/net/bluetooth/hcicore.h:2152 (discriminator 2) net/bluetooth/hciconn.c:2644 (discriminator 2)) [ 97.810148] hcidevclosesync (net/bluetooth/hcisync.c:5360) [ 97.810180] ? pfxhcidevclosesync (net/bluetooth/hcisync.c:5285) [ 97.810212] ? srsoaliasreturnthunk (arch/x86/lib/retpoline.S:221) [ 97.810242] ? upwrite (./arch/x86/include/asm/atomic6464.h:87 (discriminator 5) ./include/linux/atomic/atomic-arch-fallback.h:2852 (discriminator 5) ./include/linux/atomic/atomic-long.h:268 (discriminator 5) ./include/linux/atomic/atomic-instrumented.h:3391 (discriminator 5) kernel/locking/rwsem.c:1385 (discriminator 5) kernel/locking/rwsem.c:1643 (discriminator 5)) [ 97.810267] ? srsoaliasreturnthunk (arch/x86/lib/retpoline.S:221) [ 97.810290] ? rcuiswatching (./arch/x86/include/asm/atomic.h:23 ./include/linux/atomic/atomic-arch-fallback.h:457 ./include/linux/contexttracking.h:128 kernel/rcu/tree.c:752) [ 97.810320] hciunregisterdev (net/bluetooth/hcicore.c:504 net/bluetooth/hcicore.c:2716) [ 97.810346] vhcirelease (drivers/bluetooth/hcivhci.c:691) [ 97.810375] ? pfxvhcirelease (drivers/bluetooth/hcivhci.c:678) [ 97.810404] fput (fs/filetable.c:470) [ 97.810430] taskworkrun (kernel/taskwork.c:235) [ 97.810451] ? pfxtaskworkrun (kernel/taskwork.c:201) [ 97.810472] ? srsoaliasreturnthunk (arch/x86/lib/retpoline.S:221) [ 97.810495] ? dorawspinunlock (./include/asm-generic/qspinlock.h:128 (discriminator 5) kernel/locking/spinlockdebug.c:142 (discriminator 5)) [ 97.810527] doexit (kernel/exit.c:972) [ 97.810547] ? srsoaliasreturnthunk (arch/x86/lib/retpoline.S:221) [ 97.810574] ? pfxdoexit (kernel/exit.c:897) [ 97.810594] ? lockacquire (kernel/locking/lockdep.c:470 (discriminator 6) kernel/locking/lockdep.c:5870 (discriminator 6) kernel/locking/lockdep.c:5825 (discriminator 6)) [ 97.810616] ? srsoaliasreturnthunk (arch/x86/lib/retpoline.S:221) [ 97.810639] ? dorawspinlock (kernel/locking/spinlockdebug.c:95 (discriminator 4) kernel/locking/spinlockdebug.c:118 (discriminator 4)) [ 97.810664] ? srsoaliasreturnthunk (arch/x86/lib/retpoline.S:221) [ 97.810688] ? findheldlock (kernel/locking/lockdep.c:5350 (discriminator 1)) [ 97.810721] dogroupexit (kernel/exit.c:1093) [ 97.810745] getsignal (kernel/signal.c:3007 (discriminator 1)) [ 97.810772] ? securityfilepermission (./arch/x86/include/asm/jumplabel.h:37 security/security.c:2366) [ 97.810803] ? srsoaliasreturnthunk (arch/x86/lib/retpoline.S:221) [ 97.810826] ? vfsread (fs/readwrite.c:555) [ 97.810854] ? pfxgetsignal (kernel/signal.c:2800) [ 97.810880] ? srsoaliasreturnthunk (arch/x86/lib/retpoline.S:221) [ 97.810905] ? pfxvfsread (fs/readwrite.c:555) [ 97.810932] ? srsoaliasreturnthunk (arch/x86/lib/retpoline.S:221) [ 97.810960] archdosignalorrestart (arch/ ---truncated---

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

ksmbd: unset conn->binding on failed binding request

When a multichannel SMB2SESSIONSETUP request with SMB2SESSIONREQFLAGBINDING fails ksmbd sets conn->binding = true but never clears it on the error path. This leaves the connection in a binding state where all subsequent ksmbdsessionlookupall() calls fall back to the global sessions table. This fix it by clearing conn->binding = false in the error path.

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

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

ksmbd: fix potencial OOB in getfileallinfo() for compound requests

When a compound request consists of QUERYDIRECTORY + QUERYINFO (FILEALLINFORMATION) and the first command consumes nearly the entire maxtranssize, getfileallinfo() would blindly call smbConvertToUTF16() with PATHMAX, causing out-of-bounds write beyond the response buffer. In getfileallinfo(), there was a missing validation check for the client-provided OutputBufferLength before copying the filename into FileName field of the smb2fileallinfo structure. If the filename length exceeds the available buffer space, it could lead to potential buffer overflows or memory corruption during smbConvertToUTF16 conversion. This calculating the actual free buffer size using smb2calcmaxoutbuflen() and returning -EINVAL if the buffer is insufficient and updating smbConvertToUTF16 to use the actual filename length (clamped by PATHMAX) to ensure a safe copy operation.

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

ksmbd: fix OOB write in QUERYINFO for compound requests

When a compound request such as READ + QUERYINFO(Security) is received, and the first command (READ) consumes most of the response buffer, ksmbd could write beyond the allocated buffer while building a security descriptor.

The root cause was that smb2getinfosec() checked buffer space using ppntsdsize from xattr, while buildsecdesc() often synthesized a significantly larger descriptor from POSIX ACLs.

This patch introduces smbaclsecdescscratchlen() to accurately compute the final descriptor size beforehand, performs proper buffer checking with smb2calcmaxoutbuflen(), and uses exact-sized allocation + iov pinning.

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

netfs: Fix read abandonment during retry

Under certain circumstances, all the remaining subrequests from a read request will get abandoned during retry. The abandonment process expects the 'subreq' variable to be set to the place to start abandonment from, but it doesn't always have a useful value (it will be uninitialised on the first pass through the loop and it may point to a deleted subrequest on later passes).

Fix the first jump to "abandon:" to set subreq to the start of the first subrequest expected to need retry (which, in this abandonment case, turned out unexpectedly to no longer have NEEDRETRY set).

Also clear the subreq pointer after discarding superfluous retryable subrequests to cause an oops if we do try to access it.

ext4: publish jinode after initialization

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

LoongArch: KVM: Make kvmgetvcpubycpuid() more robust

kvmgetvcpubycpuid() takes a cpuid parameter whose type is int, so cpuid can be negative. Let kvmgetvcpubycpuid() return NULL for this case so as to make it more robust.

This fix an out-of-bounds access to kvmarch::phyidmap::physmap[].

can: gw: fix OOB heap access in cgwcsumcrc8rel()

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

KVM: arm64: Fix the descriptor address in kvmatswapdesc()

Using "(u64 user )hva + offset" to get the virtual addresses of S1/S2 descriptors looks really wrong, if offset is not zero. What we want to get for swapping is hva + offset, not hva + offset8. ;-)

Fix it.

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

iommupt: Fix short gather if the unmap goes into a large mapping

unmap has the odd behavior that it can unmap more than requested if the ending point lands within the middle of a large or contiguous IOPTE.

In this case the gather should flush everything unmapped which can be larger than what was requested to be unmapped. The gather was only flushing the range requested to be unmapped, not extending to the extra range, resulting in a short invalidation if the caller hits this special condition.

This was found by the new invalidation/gather test I am adding in preparation for ARMv8. Claude deduced the root cause.

As far as I remember nothing relies on unmapping a large entry, so this is likely not a triggerable bug.

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

crypto: tegra - Add missing CRYPTOALGASYNC

The tegra crypto driver failed to set the CRYPTOALGASYNC on its asynchronous algorithms, causing the crypto API to select them for users that request only synchronous algorithms. This causes crashes (at least). Fix this by adding the flag like what the other drivers do. Also remove the unnecessary CRYPTOALGTYPE flags, since those just get ignored and overridden by the registration function anyway.

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

Bluetooth: hcievent: fix potential UAF in hcileremoteconnparamreqevt

hciconn lookup and field access must be covered by hdev lock in hcileremoteconnparamreqevt, otherwise it's possible it is freed concurrently.

Extend the hcidevlock critical section to cover all conn usage.

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

Bluetooth: SMP: derive legacy responder STK authentication from MITM state

The legacy responder path in smprandom() currently labels the stored STK as authenticated whenever pendingseclevel is BTSECURITYHIGH. That reflects what the local service requested, not what the pairing flow actually achieved.

For Just Works/Confirm legacy pairing, SMPFLAGMITMAUTH stays clear and the resulting STK should remain unauthenticated even if the local side requested HIGH security. Use the established MITM state when storing the responder STK so the key metadata matches the pairing result.

This also keeps the legacy path aligned with the Secure Connections code, which already treats JUSTWORKS/JUSTCFM as unauthenticated.

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

HID: core: Mitigate potential OOB by removing bogus memset()

The memset() in hidreportrawevent() has the good intention of clearing out bogus data by zeroing the area from the end of the incoming data string to the assumed end of the buffer. However, as we have previously seen, doing so can easily result in OOB reads and writes in the subsequent thread of execution.

The current suggestion from one of the HID maintainers is to remove the memset() and simply return if the incoming event buffer size is not large enough to fill the associated report.

Suggested-by Benjamin Tissoires <bentiss@kernel.org>

[bentiss: changed the return value]

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

wifi: brcmfmac: validate bsscfg indices in IF events

brcmffwehhandleifevent() validates the firmware-provided interface index before it touches drvr->iflist[], but it still uses the raw bsscfgidx field as an array index without a matching range check.

Reject IF events whose bsscfg index does not fit in drvr->iflist[] before indexing the interface array.

[add missing wifi prefix]

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

wifi: wl1251: validate packet IDs before indexing txframes

wl1251txpacketcb() uses the firmware completion ID directly to index the fixed 16-entry wl->txframes[] array. The ID is a raw u8 from the completion block, and the callback does not currently verify that it fits the array before dereferencing it.

Reject completion IDs that fall outside wl->txframes[] and keep the existing NULL check in the same guard. This keeps the fix local to the trust boundary and avoids touching the rest of the completion flow.

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

fs/smb/client: fix out-of-bounds read in cifssanitizeprepath

When cifssanitizeprepath is called with an empty string or a string containing only delimiters (e.g., "/"), the current logic attempts to check (cursor2 - 1) before cursor2 has advanced. This results in an out-of-bounds read.

This patch adds an early exit check after stripping prepended delimiters. If no path content remains, the function returns NULL.

The bug was identified via manual audit and verified using a standalone test case compiled with AddressSanitizer, which triggered a SEGV on affected inputs.

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

Bluetooth: hcisync: Fix UAF in lereadfeaturescomplete

This fixes the following backtrace caused by hciconn being freed before lereadfeaturescomplete but after hcilereadremotefeaturessync so hciconndel -> hcicmdsyncdequeue is not able to prevent it:

================================================================== BUG: KASAN: slab-use-after-free in instrumentatomicreadwrite include/linux/instrumented.h:96 [inline] BUG: KASAN: slab-use-after-free in atomicdecandtest include/linux/atomic/atomic-instrumented.h:1383 [inline] BUG: KASAN: slab-use-after-free in hciconndrop include/net/bluetooth/hcicore.h:1688 [inline] BUG: KASAN: slab-use-after-free in lereadfeaturescomplete+0x5b/0x340 net/bluetooth/hcisync.c:7344 Write of size 4 at addr ffff8880796b0010 by task kworker/u9:0/52

CPU: 0 UID: 0 PID: 52 Comm: kworker/u9:0 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Workqueue: hci0 hcicmdsyncwork Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x116/0x1f0 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xcd/0x630 mm/kasan/report.c:482 kasanreport+0xe0/0x110 mm/kasan/report.c:595 checkregioninline mm/kasan/generic.c:194 [inline] kasancheckrange+0x100/0x1b0 mm/kasan/generic.c:200 instrumentatomicreadwrite include/linux/instrumented.h:96 [inline] atomicdecandtest include/linux/atomic/atomic-instrumented.h:1383 [inline] hciconndrop include/net/bluetooth/hcicore.h:1688 [inline] lereadfeaturescomplete+0x5b/0x340 net/bluetooth/hcisync.c:7344 hcicmdsyncwork+0x1ff/0x430 net/bluetooth/hcisync.c:334 processonework+0x9ba/0x1b20 kernel/workqueue.c:3257 processscheduledworks kernel/workqueue.c:3340 [inline] workerthread+0x6c8/0xf10 kernel/workqueue.c:3421 kthread+0x3c5/0x780 kernel/kthread.c:463 retfromfork+0x983/0xb10 arch/x86/kernel/process.c:158 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:246 </TASK>

Allocated by task 5932: kasansavestack+0x33/0x60 mm/kasan/common.c:56 kasansavetrack+0x14/0x30 mm/kasan/common.c:77 poisonkmallocredzone mm/kasan/common.c:400 [inline] kasankmalloc+0xaa/0xb0 mm/kasan/common.c:417 kmallocnoprof include/linux/slab.h:957 [inline] kzallocnoprof include/linux/slab.h:1094 [inline] hciconnadd+0xf8/0x1c70 net/bluetooth/hciconn.c:963 hciconnaddunset+0x76/0x100 net/bluetooth/hciconn.c:1084 leconncompleteevt+0x639/0x1f20 net/bluetooth/hcievent.c:5714 hcileenhconncompleteevt+0x23d/0x380 net/bluetooth/hcievent.c:5861 hcilemetaevt+0x357/0x5e0 net/bluetooth/hcievent.c:7408 hcieventfunc net/bluetooth/hcievent.c:7716 [inline] hcieventpacket+0x685/0x11c0 net/bluetooth/hcievent.c:7773 hcirxwork+0x2c9/0xeb0 net/bluetooth/hcicore.c:4076 processonework+0x9ba/0x1b20 kernel/workqueue.c:3257 processscheduledworks kernel/workqueue.c:3340 [inline] workerthread+0x6c8/0xf10 kernel/workqueue.c:3421 kthread+0x3c5/0x780 kernel/kthread.c:463 retfromfork+0x983/0xb10 arch/x86/kernel/process.c:158 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:246

Freed by task 5932: kasansavestack+0x33/0x60 mm/kasan/common.c:56 kasansavetrack+0x14/0x30 mm/kasan/common.c:77 kasansavefreeinfo+0x3b/0x60 mm/kasan/generic.c:587 kasansavefreeinfo mm/kasan/kasan.h:406 [inline] poisonslabobject mm/kasan/common.c:252 [inline] kasanslabfree+0x5f/0x80 mm/kasan/common.c:284 kasanslabfree include/linux/kasan.h:234 [inline] slabfreehook mm/slub.c:2540 [inline] slabfree mm/slub.c:6663 [inline] kfree+0x2f8/0x6e0 mm/slub.c:6871 devicerelease+0xa4/0x240 drivers/base/core.c:2565 kobjectcleanup lib/kobject.c:689 [inline] kobjectrelease lib/kobject.c:720 [inline] krefput include/linux/kref.h:65 [inline] kobjectput+0x1e7/0x590 lib/kobject. ---truncated---

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

Bluetooth: SMP: force responder MITM requirements before building the pairing response

smpcmdpairingreq() currently builds the pairing response from the initiator authreq before enforcing the local BTSECURITYHIGH requirement. If the initiator omits SMPAUTHMITM, the response can also omit it even though the local side still requires MITM.

tkrequest() then sees an auth value without SMPAUTHMITM and may select JUSTCFM, making method selection inconsistent with the pairing policy the responder already enforces.

When the local side requires HIGH security, first verify that MITM can be achieved from the IO capabilities and then force SMPAUTHMITM in the response in both rsp.authreq and auth. This keeps the responder auth bits and later method selection aligned.

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

nsfs: tighten permission checks for ns iteration ioctls

Even privileged services should not necessarily be able to see other privileged service's namespaces so they can't leak information to each other. Use mayseeallnamespaces() helper that centralizes this policy until the nstree adapts.

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

nsfs: tighten permission checks for handle opening

Even privileged services should not necessarily be able to see other privileged service's namespaces so they can't leak information to each other. Use mayseeallnamespaces() helper that centralizes this policy until the nstree adapts.

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

netfilter: nfconntracksip: fix Content-Length u32 truncation in siphelptcp()

siphelptcp() parses the SIP Content-Length header with simplestrtoul(), which returns unsigned long, but stores the result in unsigned int clen. On 64-bit systems, values exceeding UINTMAX are silently truncated before computing the SIP message boundary.

For example, Content-Length 4294967328 (2^32 + 32) is truncated to 32, causing the parser to miscalculate where the current message ends. The loop then treats trailing data in the TCP segment as a second SIP message and processes it through the SDP parser.

Fix this by changing clen to unsigned long to match the return type of simplestrtoul(), and reject Content-Length values that exceed the remaining TCP payload length.

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

KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE

When installing an emulated MMIO SPTE, do so after dropping/zapping the existing SPTE (if it's shadow-present). While commit a54aa15c6bda3 was right about it being impossible to convert a shadow-present SPTE to an MMIO SPTE due to a guest write, it failed to account for writes to guest memory that are outside the scope of KVM.

E.g. if host userspace modifies a shadowed gPTE to switch from a memslot to emulted MMIO and then the guest hits a relevant page fault, KVM will install the MMIO SPTE without first zapping the shadow-present SPTE.

------------[ cut here ]------------ isshadowpresentpte(sptep) WARNING: arch/x86/kvm/mmu/mmu.c:484 at markmmiospte+0xb2/0xc0 [kvm], CPU#0: vmxeptstaler/4292 Modules linked in: kvmintel kvm irqbypass CPU: 0 UID: 1000 PID: 4292 Comm: vmxeptstaler Not tainted 7.0.0-rc2-eafebd2d2ab0-sink-vm #319 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:markmmiospte+0xb2/0xc0 [kvm] Call Trace: <TASK> mmusetspte+0x237/0x440 [kvm] eptpagefault+0x535/0x7f0 [kvm] kvmmmudopagefault+0xee/0x1f0 [kvm] kvmmmupagefault+0x8d/0x620 [kvm] vmxhandleexit+0x18c/0x5a0 [kvmintel] kvmarchvcpuioctlrun+0xc55/0x1c20 [kvm] kvmvcpuioctl+0x2d5/0x980 [kvm] x64sysioctl+0x8a/0xd0 dosyscall64+0xb5/0x730 entrySYSCALL64afterhwframe+0x4b/0x53 RIP: 0033:0x47fa3f </TASK> ---[ end trace 0000000000000000 ]---

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

xen/privcmd: restrict usage in unprivileged domU

The Xen privcmd driver allows to issue arbitrary hypercalls from user space processes. This is normally no problem, as access is usually limited to root and the hypervisor will deny any hypercalls affecting other domains.

In case the guest is booted using secure boot, however, the privcmd driver would be enabling a root user process to modify e.g. kernel memory contents, thus breaking the secure boot feature.

The only known case where an unprivileged domU is really needing to use the privcmd driver is the case when it is acting as the device model for another guest. In this case all hypercalls issued via the privcmd driver will target that other guest.

Fortunately the privcmd driver can already be locked down to allow only hypercalls targeting a specific domain, but this mode can be activated from user land only today.

The target domain can be obtained from Xenstore, so when not running in dom0 restrict the privcmd driver to that target domain from the beginning, resolving the potential problem of breaking secure boot.

This is XSA-482

--- V2: - defer reading from Xenstore if Xenstore isn't ready yet (Jan Beulich) - wait in open() if target domain isn't known yet - issue message in case no target domain found (Jan Beulich)

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

iptunnel: adapt iptunnelxmitstats() to NETDEVPCPUSTATDSTATS

Blamed commits forgot that vxlan/geneve use udptunnel[6]xmitskb() which call iptunnelxmitstats().

iptunnelxmitstats() was assuming tunnels were only using NETDEVPCPUSTATTSTATS.

@syncp offset in pcpuswnetstats and pcpudstats is different.

32bit kernels would either have corruptions or freezes if the syncp sequence was overwritten.

This patch also moves pcpustattype closer to dev->{t,d}stats to avoid a potential cache line miss since iptunnelxmitstats() needs to read it.

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

netfilter: nfconntrackh323: fix OOB read in decodeint() CONS case

In decodeint(), the CONS case calls getbits(bs, 2) to read a length value, then calls getuint(bs, len) without checking that len bytes remain in the buffer. The existing boundary check only validates the 2 bits for getbits(), not the subsequent 1-4 bytes that getuint() reads. This allows a malformed H.323/RAS packet to cause a 1-4 byte slab-out-of-bounds read.

Add a boundary check for len bytes after getbits() and before getuint().