A use-after-free read flaw was found in sockgetsockopt() in net/core/sock.c due to SOPEERCRED and SOPEERGROUPS race with listen() (and connect()) in the Linux kernel. In this flaw, an attacker with a user privilege may lead to a system crash or a leak of internal kernel information.

In this, if the creds are replaced and freed at the wrong time, a use-after-free read occurs.

References:

https://lore.kernel.org/netdev/20210929225750.2548112-1-eric.dumazet@gmail.com/T/ https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=35306eb23814 https://bugs.chromium.org/p/project-zero/issues/detail?id=2230&can=7&q=modified-after%3Atoday-30&sort=-modified&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary%20Modified%20Cve&cells=tiles&redir=1

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

net: mctp: ensure our nlmsg responses are initialised

Syed Faraz Abrar (@farazsth98) from Zellic, and Pumpkin (@u1f383) from DEVCORE Research Team working with Trend Micro Zero Day Initiative report that a RTMGETNEIGH will return uninitalised data in the pad bytes of the ndmsg data.

Ensure we're initialising the netlink data to zero, in the link, addr and neigh response messages.

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

afunix: Clear stale u->oobskb.

syzkaller started to report deadlock of unixgclock after commit 4090fa373f0e ("afunix: Replace garbage collection algorithm."), but it just uncovers the bug that has been there since commit 314001f0bf92 ("afunix: Add OOB support").

The repro basically does the following.

from socket import from array import array

c1, c2 = socketpair(AFUNIX, SOCKSTREAM) c1.sendmsg([b'a'], [(SOLSOCKET, SCMRIGHTS, array("i", [c2.fileno()]))], MSGOOB) c2.recv(1) # blocked as no normal data in recv queue

c2.close() # done async and unblock recv() c1.close() # done async and trigger GC

A socket sends its file descriptor to itself as OOB data and tries to receive normal data, but finally recv() fails due to async close().

The problem here is wrong handling of OOB skb in manageoob(). When recvmsg() is called without MSGOOB, manageoob() is called to check if the peeked skb is OOB skb. In such a case, manageoob() pops it out of the receive queue but does not clear unixsock(sk)->oobskb. This is wrong in terms of uAPI.

Let's say we send "hello" with MSGOOB, and "world" without MSGOOB. The 'o' is handled as OOB data. When recv() is called twice without MSGOOB, the OOB data should be lost.

>>> from socket import >>> c1, c2 = socketpair(AFUNIX, SOCKSTREAM, 0) >>> c1.send(b'hello', MSGOOB) # 'o' is OOB data 5 >>> c1.send(b'world') 5 >>> c2.recv(5) # OOB data is not received b'hell' >>> c2.recv(5) # OOB date is skipped b'world' >>> c2.recv(5, MSGOOB) # This should return an error b'o'

In the same situation, TCP actually returns -EINVAL for the last recv().

Also, if we do not clear unixsk(sk)->oobskb, unixpoll() always set EPOLLPRI even though the data has passed through by previous recv().

To avoid these issues, we must clear unixsk(sk)->oobskb when dequeuing it from recv queue.

The reason why the old GC did not trigger the deadlock is because the old GC relied on the receive queue to detect the loop.

When it is triggered, the socket with OOB data is marked as GC candidate because file refcount == inflight count (1). However, after traversing all inflight sockets, the socket still has a positive inflight count (1), thus the socket is excluded from candidates. Then, the old GC lose the chance to garbage-collect the socket.

With the old GC, the repro continues to create true garbage that will never be freed nor detected by kmemleak as it's linked to the global inflight list. That's why we couldn't even notice the issue.

fsdax: Fix infinite loop in daxiomaprw()

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

KVM: VMX: Always clear vmx->fail on emulationrequired

Revert a relatively recent change that set vmx->fail if the vCPU is in L2 and emulationrequired is true, as that behavior is completely bogus. Setting vmx->fail and synthesizing a VM-Exit is contradictory and wrong:

(a) it's impossible to have both a VM-Fail and VM-Exit (b) vmcs.EXITREASON is not modified on VM-Fail (c) emulationrequired refers to guest state and guest state checks are always VM-Exits, not VM-Fails.

For KVM specifically, emulationrequired is handled before nested exits in vmxhandleexit(), thus setting vmx->fail has no immediate effect, i.e. KVM calls into handleinvalidgueststate() and vmx->fail is ignored. Setting vmx->fail can ultimately result in a WARN in nestedvmxvmexit() firing when tearing down the VM as KVM never expects vmx->fail to be set when L2 is active, KVM always reflects those errors into L1.

------------[ cut here ]------------ WARNING: CPU: 0 PID: 21158 at arch/x86/kvm/vmx/nested.c:4548 nestedvmxvmexit+0x16bd/0x17e0 arch/x86/kvm/vmx/nested.c:4547 Modules linked in: CPU: 0 PID: 21158 Comm: syz-executor.1 Not tainted 5.16.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:nestedvmxvmexit+0x16bd/0x17e0 arch/x86/kvm/vmx/nested.c:4547 Code: <0f> 0b e9 2e f8 ff ff e8 57 b3 5d 00 0f 0b e9 00 f1 ff ff 89 e9 80 Call Trace: vmxleavenested arch/x86/kvm/vmx/nested.c:6220 [inline] nestedvmxfreevcpu+0x83/0xc0 arch/x86/kvm/vmx/nested.c:330 vmxfreevcpu+0x11f/0x2a0 arch/x86/kvm/vmx/vmx.c:6799 kvmarchvcpudestroy+0x6b/0x240 arch/x86/kvm/x86.c:10989 kvmvcpudestroy+0x29/0x90 arch/x86/kvm/../../../virt/kvm/kvmmain.c:441 kvmfreevcpus arch/x86/kvm/x86.c:11426 [inline] kvmarchdestroyvm+0x3ef/0x6b0 arch/x86/kvm/x86.c:11545 kvmdestroyvm arch/x86/kvm/../../../virt/kvm/kvmmain.c:1189 [inline] kvmputkvm+0x751/0xe40 arch/x86/kvm/../../../virt/kvm/kvmmain.c:1220 kvmvcpurelease+0x53/0x60 arch/x86/kvm/../../../virt/kvm/kvmmain.c:3489 fput+0x3fc/0x870 fs/filetable.c:280 taskworkrun+0x146/0x1c0 kernel/taskwork.c:164 exittaskwork include/linux/taskwork.h:32 [inline] doexit+0x705/0x24f0 kernel/exit.c:832 dogroupexit+0x168/0x2d0 kernel/exit.c:929 getsignal+0x1740/0x2120 kernel/signal.c:2852 archdosignalorrestart+0x9c/0x730 arch/x86/kernel/signal.c:868 handlesignalwork kernel/entry/common.c:148 [inline] exittousermodeloop kernel/entry/common.c:172 [inline] exittousermodeprepare+0x191/0x220 kernel/entry/common.c:207 syscallexittousermodework kernel/entry/common.c:289 [inline] syscallexittousermode+0x2e/0x70 kernel/entry/common.c:300 dosyscall64+0x53/0xd0 arch/x86/entry/common.c:86 entrySYSCALL64afterhwframe+0x44/0xae

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

IB/qib: Fix memory leak in qibusersdmaqueuepkts()

The wrong goto label was used for the error case and missed cleanup of the pkt allocation.

Addresses-Coverity-ID: 1493352 ("Resource leak")

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

fs/ntfs3: Fix an NULL dereference bug

The issue here is when this is called from ntfsloadattrlist(). The "size" comes from le32tocpu(attr->res.datasize) so it can't overflow on a 64bit systems but on 32bit systems the "+ 1023" can overflow and the result is zero. This means that the kmalloc will succeed by returning the ZEROSIZEPTR and then the memcpy() will crash with an Oops on the next line.

A memory leak flaw was found in the Linux kernel's ccprunaesgcmcmd() function that allows an attacker to cause a denial of service. The vulnerability is similar to the older CVE-2019-18808. The highest threat from this vulnerability is to system availability.

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

interconnect: qcom: sc8180x: Mark CO0 BCM keepalive

The CO0 BCM needs to be up at all times, otherwise some hardware (like the UFS controller) loses its connection to the rest of the SoC, resulting in a hang of the platform, accompanied by a spectacular logspam.

Mark it as keepalive to prevent such cases.

A flaw was found in sctpmakestrresetreq in net/sctp/smmakechunk.c in SCTP network protocol in the Linux kernel. In this flaw, an attempt to use more buffer than was allocated triggers BUGON to cause a denial of service (DOS).

References: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a2d859e3fc97e79d907761550dbc03ff1b36479c

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

thermal: Fix NULL pointer dereferences in ofthermal functions

ofparsethermalzones() parses the thermal-zones node and registers a thermalzone device for each subnode. However, if a thermal zone is consuming a thermal sensor and that thermal sensor device hasn't probed yet, an attempt to set trippointtemp for that thermal zone device can cause a NULL pointer dereference. Fix it.

console:/sys/class/thermal/thermalzone87 # echo 120000 > trippoint0temp ... Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... Call trace: ofthermalsettriptemp+0x40/0xc4 trippointtempstore+0xc0/0x1dc devattrstore+0x38/0x88 sysfskfwrite+0x64/0xc0 kernfsfopwriteiter+0x108/0x1d0 vfswrite+0x2f4/0x368 ksyswrite+0x7c/0xec arm64syswrite+0x20/0x30 el0svccommon.llvm.7279915941325364641+0xbc/0x1bc doel0svc+0x28/0xa0 el0svc+0x14/0x24 el0synchandler+0x88/0xec el0sync+0x1c0/0x200

While at it, fix the possible NULL pointer dereference in other functions as well: ofthermalgettemp(), ofthermalsetemultemp(), ofthermalgettrend().

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

gpio: mockup: Fix potential resource leakage when register a chip

If creation of software node fails, the locally allocated string array is left unfreed. Free it on error path.

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

pciiounmap(): Fix MMIO mapping leak

The #ifdef ARCHHASGENERICIOPORTMAP accidentally also guards iounmap(), which means MMIO mappings are leaked.

Move the guard so we call iounmap() for MMIO mappings.

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

net: mctp: take ownership of skb in mctplocaloutput

Currently, mctplocaloutput only takes ownership of skb on success, and we may leak an skb if mctplocaloutput fails in specific states; the skb ownership isn't transferred until the actual output routing occurs.

Instead, make mctplocaloutput free the skb on all error paths up to the route action, so it always consumes the passed skb.

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

drm/msm: Fix mmap to include VMIO and VMDONTDUMP

In commit 510410bfc034 ("drm/msm: Implement mmap as GEM object function") we switched to a new/cleaner method of doing things. That's good, but we missed a little bit.

Before that commit, we used to first run through the drmgemmmapobj() case where obj->funcs->mmap() was NULL. That meant that we ran:

vma->vmflags |= VMIO | VMPFNMAP | VMDONTEXPAND | VMDONTDUMP; vma->vmpageprot = pgprotwritecombine(vmgetpageprot(vma->vmflags)); vma->vmpageprot = pgprotdecrypted(vma->vmpageprot);

...and then we modified those mappings with our own. Now that obj->funcs->mmap() is no longer NULL we don't run the default code. It looks like the fact that the vmflags got VMIO / VMDONTDUMP was important because we're now getting crashes on Chromebooks that use ARC++ while logging out. Specifically a crash that looks like this (this is on a 5.10 kernel w/ relevant backports but also seen on a 5.15 kernel):

Unable to handle kernel paging request at virtual address ffffffc008000000 Mem abort info: ESR = 0x96000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 swapper pgtable: 4k pages, 39-bit VAs, pgdp=000000008293d000 [ffffffc008000000] pgd=00000001002b3003, p4d=00000001002b3003, pud=00000001002b3003, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP [...] CPU: 7 PID: 15734 Comm: crashdump64 Tainted: G W 5.10.67 #1 [...] Hardware name: Qualcomm Technologies, Inc. sc7280 IDP SKU2 platform (DT) pstate: 80400009 (Nzcv daif +PAN -UAO -TCO BTYPE=--) pc : archcopytouser+0xc0/0x30c lr : copyout+0xac/0x14c [...] Call trace: archcopytouser+0xc0/0x30c copypagetoiter+0x1a0/0x294 processvmrwcore+0x240/0x408 processvmrw+0x110/0x16c arm64sysprocessvmreadv+0x30/0x3c el0svccommon+0xf8/0x250 doel0svc+0x30/0x80 el0svc+0x10/0x1c el0synchandler+0x78/0x108 el0sync+0x184/0x1c0 Code: f8408423 f80008c3 910020c6 36100082 (b8404423)

Let's add the two flags back in.

While we're at it, the fact that we aren't running the default means that we don't need to clear out VMPFNMAP, so remove that and save an instruction.

NOTE: it was confirmed that VMIO was the important flag to fix the problem I was seeing, but adding back VMDONTDUMP seems like a sane thing to do so I'm doing that too.

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

net: dsa: felix: Fix memory leak in felixsetupmmiofiltering

Avoid a memory leak if there is not a CPU port defined.

Addresses-Coverity-ID: 1492897 ("Resource leak") Addresses-Coverity-ID: 1492899 ("Resource leak")

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

drm/msm/devfreq: Fix OPP refcnt leak

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

drm/msm: Fix waitfence submitqueue leak

We weren't dropping the submitqueue reference in all paths. In particular, when the fence has already been signalled. Split out a helper to simplify handling this in the various different return paths.

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

ethtool: ioctl: fix potential NULL deref in ethtoolsetcoalesce()

ethtoolsetcoalesce() now uses both the .getcoalesce() and .setcoalesce() callbacks. But the check for their availability is buggy, so changing the coalesce settings on a device where the driver provides only one of the callbacks results in a NULL pointer dereference instead of an -EOPNOTSUPP.

Fix the condition so that the availability of both callbacks is ensured. This also matches the netlink code.

Note that reproducing this requires some effort - it only affects the legacy ioctl path, and needs a specific combination of driver options: - have .getcoalesce() and .coalescesupported but no .setcoalesce(), or - have .setcoalesce() but no .getcoalesce(). Here eg. ethtool doesn't cause the crash as it first attempts to call ethtoolgetcoalesce() and bails out on error.

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

staging: r8188eu: fix a memory leak in rtwwxread32()

Free "ptmp" before returning -EINVAL.

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

ksmbd: fix memleak in getfilestreaminfo()

Fix memleak in getfilestreaminfo()

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

iouring: fail cancellation for EXITING tasks

WARNING: CPU: 1 PID: 20 at fs/iouring.c:6269 iotrycanceluserdata+0x3c5/0x640 fs/iouring.c:6269 CPU: 1 PID: 20 Comm: kworker/1:0 Not tainted 5.16.0-rc1-syzkaller #0 Workqueue: events iofallbackreqfunc RIP: 0010:iotrycanceluserdata+0x3c5/0x640 fs/iouring.c:6269 Call Trace: <TASK> ioreqtasklinktimeout+0x6b/0x1e0 fs/iouring.c:6886 iofallbackreqfunc+0xf9/0x1ae fs/iouring.c:1334 processonework+0x9b2/0x1690 kernel/workqueue.c:2298 workerthread+0x658/0x11f0 kernel/workqueue.c:2445 kthread+0x405/0x4f0 kernel/kthread.c:327 retfromfork+0x1f/0x30 arch/x86/entry/entry64.S:295 </TASK>

We need original task's context to do cancellations, so if it's dying and the callback is executed in a fallback mode, fail the cancellation attempt.

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

net: hns3: fix kernel crash when devlink reload during pf initialization

The devlink reload process will access the hardware resources, but the register operation is done before the hardware is initialized. So, processing the devlink reload during initialization may lead to kernel crash. This patch fixes this by taking devllock during initialization.

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

scsi: qla2xxx: Fix off by one in qlaedifappgetstats()

The appreply->elem[] array is allocated earlier in this function and it has appreq.numports elements. Thus this > comparison needs to be >= to prevent memory corruption.

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

ipv6: fib6rules: avoid possible NULL dereference in fib6ruleaction()

syzbot is able to trigger the following crash [1], caused by unsafe ip6dstidev() use.

Indeed ip6dstidev() can return NULL, and must always be checked.

[1]

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 31648 Comm: syz-executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:fib6ruleaction net/ipv6/fib6rules.c:237 [inline] RIP: 0010:fib6ruleaction+0x241/0x7b0 net/ipv6/fib6rules.c:267 Code: 02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b 48 89 d8 48 c1 e8 03 <42> 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4c RSP: 0018:ffffc9000fc1f2f0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700 RDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760 RBP: ffff8880673fb980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bd R10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000 R13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00 FS: 00007f55e82ca6c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> fibruleslookup+0x62c/0xdb0 net/core/fibrules.c:317 fib6rulelookup+0x1fd/0x790 net/ipv6/fib6rules.c:108 ip6routeoutputflagsnoref net/ipv6/route.c:2637 [inline] ip6routeoutputflags+0x38e/0x610 net/ipv6/route.c:2649 ip6routeoutput include/net/ip6route.h:93 [inline] ip6dstlookuptail+0x189/0x11a0 net/ipv6/ip6output.c:1120 ip6dstlookupflow+0xb9/0x180 net/ipv6/ip6output.c:1250 sctpv6getdst+0x792/0x1e20 net/sctp/ipv6.c:326 sctptransportroute+0x12c/0x2e0 net/sctp/transport.c:455 sctpassocaddpeer+0x614/0x15c0 net/sctp/associola.c:662 sctpconnectnewasoc+0x31d/0x6c0 net/sctp/socket.c:1099 sctpconnect+0x66d/0xe30 net/sctp/socket.c:1197 sctpconnect net/sctp/socket.c:4819 [inline] sctpinetconnect+0x149/0x1f0 net/sctp/socket.c:4834 sysconnectfile net/socket.c:2048 [inline] sysconnect+0x2df/0x310 net/socket.c:2065 dosysconnect net/socket.c:2075 [inline] sesysconnect net/socket.c:2072 [inline] x64sysconnect+0x7a/0x90 net/socket.c:2072 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf5/0x240 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

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

net: hns3: fix kernel crash when devlink reload during initialization

The devlink reload process will access the hardware resources, but the register operation is done before the hardware is initialized. So, processing the devlink reload during initialization may lead to kernel crash.

This patch fixes this by registering the devlink after hardware initialization.

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

net/mlx5: Reload only IB representors upon lag disable/enable

On lag disable, the bond IB device along with all of its representors are destroyed, and then the slaves' representors get reloaded.

In case the slave IB representor load fails, the eswitch error flow unloads all representors, including ethernet representors, where the netdevs get detached and removed from lag bond. Such flow is inaccurate as the lag driver is not responsible for loading/unloading ethernet representors. Furthermore, the flow described above begins by holding lag lock to prevent bond changes during disable flow. However, when reaching the ethernet representors detachment from lag, the lag lock is required again, triggering the following deadlock:

Call trace: switchto+0xf4/0x148 schedule+0x2c8/0x7d0 schedule+0x50/0xe0 schedulepreemptdisabled+0x18/0x28 mutexlock.isra.13+0x2b8/0x570 mutexlockslowpath+0x1c/0x28 mutexlock+0x4c/0x68 mlx5lagremovenetdev+0x3c/0x1a0 [mlx5core] mlx5euplinkrepdisable+0x70/0xa0 [mlx5core] mlx5edetachnetdev+0x6c/0xb0 [mlx5core] mlx5enetdevchangeprofile+0x44/0x138 [mlx5core] mlx5enetdevattachnicprofile+0x28/0x38 [mlx5core] mlx5evportrepunload+0x184/0x1b8 [mlx5core] mlx5eswoffloadsrepload+0xd8/0xe0 [mlx5core] mlx5eswitchreloadreps+0x74/0xd0 [mlx5core] mlx5disablelag+0x130/0x138 [mlx5core] mlx5lagdisablechange+0x6c/0x70 [mlx5core] // hold ldev->lock mlx5devlinkeswitchmodeset+0xc0/0x410 [mlx5core] devlinknlcmdeswitchsetdoit+0xdc/0x180 genlfamilyrcvmsgdoit.isra.17+0xe8/0x138 genlrcvmsg+0xe4/0x220 netlinkrcvskb+0x44/0x108 genlrcv+0x40/0x58 netlinkunicast+0x198/0x268 netlinksendmsg+0x1d4/0x418 socksendmsg+0x54/0x60 syssendto+0xf4/0x120 arm64syssendto+0x30/0x40 el0svccommon+0x8c/0x120 doel0svc+0x30/0xa0 el0svc+0x20/0x30 el0synchandler+0x90/0xb8 el0sync+0x160/0x180

Thus, upon lag enable/disable, load and unload only the IB representors of the slaves preventing the deadlock mentioned above.

While at it, refactor the mlx5eswoffloadsrepload() function to have a static helper method for its internal logic, in symmetry with the representor unload design.

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

drm: mxsfb: Fix NULL pointer dereference

mxsfb should not ever dereference the NULL pointer which drmatomicgetnewbridgestate is allowed to return. Assume a fixed format instead.

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

RDMA/siw: Fix refcounting leak in siwcreateqp()

The atomicinc() needs to be paired with an atomicdec() on the error path.

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

fs/ntfs3: Use 64 bit variable to avoid 32 bit overflow

For example, in the expression: vbo = 2 vbo + skip