In the Linux kernel, the following vulnerability has been resolved:
Input: aiptek - properly check endpoint type
Syzbot reported warning in usbsubmiturb() which is caused by wrong endpoint type. There was a check for the number of endpoints, but not for the type of endpoint.
Fix it by replacing old desc.bNumEndpoints check with usbfindcommonendpoints() helper for finding endpoints
Fail log:
usb 5-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 2 PID: 48 at drivers/usb/core/urb.c:502 usbsubmiturb+0xed2/0x18a0 drivers/usb/core/urb.c:502 Modules linked in: CPU: 2 PID: 48 Comm: kworker/2:2 Not tainted 5.17.0-rc6-syzkaller-00226-g07ebd38a0da2 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Workqueue: usbhubwq hubevent ... Call Trace: aiptekopen+0xd5/0x130 drivers/input/tablet/aiptek.c:830 inputopendevice+0x1bb/0x320 drivers/input/input.c:629 kbdconnect+0xfe/0x160 drivers/tty/vt/keyboard.c:1593
arm64: probes: Fix uprobes for big-endian kernels
In the Linux kernel, the following vulnerability has been resolved:
ipv6: add NULL checks for idev in SRv6 paths
in6devget() can return NULL when the device has no IPv6 configuration (e.g. MTU < IPV6MINMTU or after NETDEVUNREGISTER).
Add NULL checks for idev returned by in6devget() in both seg6hmacvalidateskb() and ipv6srhrcv() to prevent potential NULL pointer dereferences.
In the Linux kernel, the following vulnerability has been resolved:
powerpc/xics: fix refcount leak in icpopalinit()
The offindcompatiblenode() function returns a node pointer with refcount incremented, use ofnodeput() on it when done.
In the Linux kernel, the following vulnerability has been resolved:
usbnet: fix memory leak in error case
usbnetwritecmdasync() mixed up which buffers need to be freed in which error case.
v2: add Fixes tag v3: fix uninitialized buf pointer
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftfib: fix stale stack leak via the OIFNAME register
For NFTFIBRESULTOIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTNLOCAL and oif-mismatch paths nftfib{4,6}eval() only writes one register via "dest = 0". The remaining three registers are left as whatever was on the stack in nftdochain()'s struct nftregs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace.
The NFTAFIBFPRESENT existence check has the same shape: it is only meaningful for NFTFIBRESULTOIF, yet it was accepted for any result type while the eval stores a single byte via nftregstore8(), leaving the rest of the declared span stale.
Fix both:
- replace the bare "dest = 0" in the eval with nftfibstoreresult(), which strscpypad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and
- restrict NFTAFIBFPRESENT to NFTFIBRESULTOIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes.
In the Linux kernel, the following vulnerability has been resolved:
misc/vmwvmci: fix an infoleak in vmcihostdoreceivedatagram()
struct vmcieventqp allocated by qpnotifypeer() contains padding, which may carry uninitialized data to the userspace, as observed by KMSAN:
BUG: KMSAN: kernel-infoleak in instrumentcopytouser ./include/linux/instrumented.h:121 instrumentcopytouser ./include/linux/instrumented.h:121 copytouser+0x5f/0xb0 lib/usercopy.c:33 copytouser ./include/linux/uaccess.h:169 vmcihostdoreceivedatagram drivers/misc/vmwvmci/vmcihost.c:431 vmcihostunlockedioctl+0x33d/0x43d0 drivers/misc/vmwvmci/vmcihost.c:925 vfsioctl fs/ioctl.c:51 ...
Uninit was stored to memory at: kmemdup+0x74/0xb0 mm/util.c:131 dgdispatchashost drivers/misc/vmwvmci/vmcidatagram.c:271 vmcidatagramdispatch+0x4f8/0xfc0 drivers/misc/vmwvmci/vmcidatagram.c:339 qpnotifypeer+0x19a/0x290 drivers/misc/vmwvmci/vmciqueuepair.c:1479 qpbrokerattach drivers/misc/vmwvmci/vmciqueuepair.c:1662 qpbrokeralloc+0x2977/0x2f30 drivers/misc/vmwvmci/vmciqueuepair.c:1750 vmciqpbrokeralloc+0x96/0xd0 drivers/misc/vmwvmci/vmciqueuepair.c:1940 vmcihostdoallocqueuepair drivers/misc/vmwvmci/vmcihost.c:488 vmcihostunlockedioctl+0x24fd/0x43d0 drivers/misc/vmwvmci/vmcihost.c:927 ...
Local variable ev created at: qpnotifypeer+0x54/0x290 drivers/misc/vmwvmci/vmciqueuepair.c:1456 qpbrokerattach drivers/misc/vmwvmci/vmciqueuepair.c:1662 qpbrokeralloc+0x2977/0x2f30 drivers/misc/vmwvmci/vmciqueuepair.c:1750
Bytes 28-31 of 48 are uninitialized Memory access of size 48 starts at ffff888035155e00 Data copied to user address 0000000020000100
Use memset() to prevent the infoleaks.
Also speculatively fix qpnotifypeerlocal(), which may suffer from the same problem.
In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid resizing to a partial cluster size
This patch avoids an attempt to resize the filesystem to an unaligned cluster boundary. An online resize to a size that is not integral to cluster size results in the last iteration attempting to grow the fs by a negative amount, which trips a BUGON and leaves the fs with a corrupted in-memory superblock.
In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Don't BUG if userspace injects an interrupt with GIF=0
Don't BUG/WARN on interrupt injection due to GIF being cleared, since it's trivial for userspace to force the situation via KVMSETVCPUEVENTS (even if having at least a WARN there would be correct for KVM internally generated injections).
kernel BUG at arch/x86/kvm/svm/svm.c:3386! invalid opcode: 0000 [#1] SMP CPU: 15 PID: 926 Comm: smmtest Not tainted 5.17.0-rc3+ #264 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:svminjectirq+0xab/0xb0 [kvmamd] Code: <0f> 0b 0f 1f 00 0f 1f 44 00 00 80 3d ac b3 01 00 00 55 48 89 f5 53 RSP: 0018:ffffc90000b37d88 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88810a234ac0 RCX: 0000000000000006 RDX: 0000000000000000 RSI: ffffc90000b37df7 RDI: ffff88810a234ac0 RBP: ffffc90000b37df7 R08: ffff88810a1fa410 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff888109571000 R14: ffff88810a234ac0 R15: 0000000000000000 FS: 0000000001821380(0000) GS:ffff88846fdc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f74fc550008 CR3: 000000010a6fe000 CR4: 0000000000350ea0 Call Trace: <TASK> injectpendingevent+0x2f7/0x4c0 [kvm] kvmarchvcpuioctlrun+0x791/0x17a0 [kvm] kvmvcpuioctl+0x26d/0x650 [kvm] x64sysioctl+0x82/0xb0 dosyscall64+0x3b/0xc0 entrySYSCALL64afterhwframe+0x44/0xae </TASK>
In the Linux kernel, the following vulnerability has been resolved:
iio: sca3000: Fix a resource leak in sca3000probe()
spi->irq from requestthreadedirq() not released when iiodeviceregister() fails. Add an return value check and jump to a common error handler when iiodeviceregister() fails.
In the Linux kernel, the following vulnerability has been resolved:
tracepoint: balance regfunc() on funcadd() failure in tracepointaddfunc()
When a tracepoint goes through the 0 -> 1 transition, tracepointaddfunc() invokes the subsystem's ext->regfunc() before attempting to install the new probe via funcadd(). If funcadd() then fails (for example, when allocateprobes() cannot allocate a new probe array under memory pressure and returns -ENOMEM), the function returns the error without calling the matching ext->unregfunc(), leaving the side effects of regfunc() behind with no installed probe to justify them.
For syscall tracepoints this is particularly unpleasant: syscallregfunc() bumps systracepointrefcount and sets SYSCALLTRACEPOINT on every task. After a leaked failure, the refcount is stuck at a non-zero value with no consumer, and every task continues paying the syscall trace entry/exit overhead until reboot. Other subsystems providing regfunc()/unregfunc() pairs exhibit similarly scoped persistent state.
Mirror the existing 1 -> 0 cleanup and call ext->unregfunc() in the funcadd() error path, gated on the same condition used there so the unwind is symmetric with the registration.
An out-of-bounds memory write flaw in the Linux kernel’s USB Monitor component was found in how a user with access to the /dev/usbmon can trigger it by an incorrect write to the memory of the usbmon. This flaw allows a local user to crash or potentially escalate their privileges on the system.
A use-after-free flaw was found in usbsgcancel in drivers/usb/core/message.c in USB core subsystem. This flaw could allow a local attacker with special user privilege (or root) to crash the system due to a race problem in scatter-gather cancellation and transfer completion in usbsgwait. This vulnerability can even lead to a kernel information leak problem .
Here usbsgcancel() does not take any reference to the transfer and there is nothing to prevent the URBs from being deallocated while the routine is trying to use them.
Taking a reference by incrementing the transfer's io->count field while the cancellation is in progress and decrementing it afterwards can be way to address this. The transfer's URBs are not deallocated until io->complete is triggered, which happens when io->count reaches zero. ~~~ BUG: KASAN: use-after-free in atomicread include/asm-generic/atomic-instrumented.h:26 [inline] BUG: KASAN: use-after-free in usbhcdunlinkurb+0x5f/0x170 drivers/usb/core/hcd.c:1607 Read of size 4 at addr ffff888065379610 by task kworker/u4:1/27 ~~~
References: https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.6.8 https://lkml.org/lkml/2020/3/23/52
Upstream commit: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=056ad39ee9253873522f6469c3364964a322912b
A flaw was found in the way Linux kernel's KVM hypervisor handled deferred TLB flush requests from guest. A race condition may occur between guest issuing a deferred TLB flush request to KVM and KVM handling and acknowledging it. This may result in invalid address translations from TLB being used to access guest memory, leading to potential information leakage issue.
A guest user/process may use this flaw to access guest memory locations which it should not have access to.
Upstream patches: ----------------- -> https://git.kernel.org/linus/a6bd811f1209fe1c64c9f6fd578101d6436c6b6e -> https://git.kernel.org/linus/b043138246a41064527cf019a3d51d9f015e9796 -> https://git.kernel.org/linus/917248144db5d7320655dbb41d3af0b8a0f3d589 -> https://git.kernel.org/linus/1eff70a9abd46f175defafd29bc17ad456f398a7 -> https://git.kernel.org/linus/8c6de56a42e0c657955e12b882a81ef07d1d073e -> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=grep&q=CVE-2019-3016
An issue was discovered in the Linux kernel before 5.0.9. There is a use-after-free in atalkprocexit, related to net/appletalk/atalkproc.c, net/appletalk/ddp.c, and net/appletalk/sysctlnetatalk.c.
An error in the "sctpmakechunk()" function (net/sctp/smmakechunk.c) when handling SCTP packets length can be exploited by a malicious local user to cause a kernel crash and a DoS.
References:
https://packetstormsecurity.com/files/146620/secunia-sctpmakechunkdos.txt
https://marc.info/?t=151818093200004&r=1&w=2
https://marc.info/?t=151818682600001&r=1&w=2
An upstream patch:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=07f2c7ab6f8d0a7e7c5764c4e6cc9c52951b9d9c
A flaw was discovered in the Linux kernel's USB subsystem in the usbgetextradescriptor() function in the drivers/usb/core/usb.c which mishandles a size check during the reading of an extra descriptor data. By using a specially crafted USB device which sends a forged extra descriptor, an unprivileged user with physical access to the system can potentially cause a privilege escalation or trigger a system crash or lock up and thus to cause a denial of service (DoS).
A flaw was found in the latest Linux kernel. A out-of-bounds write of kernel address space may be triggered via uncontrolled userland provided offset in ebtentry struct in netfilter/ebtables.c.
References:
https://marc.info/?l=linux-netdev&m=152023808817590&w=2
https://marc.info/?l=linux-netdev&m=152025888924151&w=2
An upsteam patch:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b71812168571fa55e44cdd0254471331b9c4c4c6
https://github.com/torvalds/linux/commit/b71812168571fa55e44cdd0254471331b9c4c4c6
A flaw was found in the Linux kernel present since v4.0-rc1 and through v4.13-rc4. A crafted network packet sent remotely by an attacker may force the kernel to enter an infinite loop in the cipsov4optptr() function in net/ipv4/cipsoipv4.c leading to a denial-of-service. A certain non-default configuration of LSM (Linux Security Module) and NetLabel should be set up on a system before an attacker could leverage this flaw.
Last updated 4 October 2024
net/sctp/socket.c in the Linux kernel through 4.10.1 does not properly restrict association peel-off operations during certain wait states, which allows local users to cause a denial of service (invalid unlock and double free) via a multithreaded application. NOTE: this vulnerability exists because of an incorrect fix for CVE-2017-5986.
Last updated 4 July 2026
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: core: Check for unset descriptor
Make sure the descriptor has been set before looking at maxpacket. This fixes a null pointer panic in this case.
This may happen if the gadget doesn't properly set up the endpoint for the current speed, or the gadget descriptors are malformed and the descriptor for the speed/endpoint are not found.
No current gadget driver is known to have this problem, but this may cause a hard-to-find bug during development of new gadgets.
In the Linux kernel, the following vulnerability has been resolved:
USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor
Syzbot has identified a bug in usbcore (see the Closes: tag below) caused by our assumption that the reserved bits in an endpoint descriptor's bEndpointAddress field will always be 0. As a result of the bug, the endpointisduplicate() routine in config.c (and possibly other routines as well) may believe that two descriptors are for distinct endpoints, even though they have the same direction and endpoint number. This can lead to confusion, including the bug identified by syzbot (two descriptors with matching endpoint numbers and directions, where one was interrupt and the other was bulk).
To fix the bug, we will clear the reserved bits in bEndpointAddress when we parse the descriptor. (Note that both the USB-2.0 and USB-3.1 specs say these bits are "Reserved, reset to zero".) This requires us to make a copy of the descriptor earlier in usbparseendpoint() and use the copy instead of the original when checking for duplicates.
In the Linux kernel, the following vulnerability has been resolved:
ip6tunnel: fix NEXTHDRFRAGMENT handling in ip6tnlparsetlvenclim()
syzbot pointed out [1] that NEXTHDRFRAGMENT handling is broken.
Reading fragoff can only be done if we pulled enough bytes to skb->head. Currently we might access garbage.
[1] BUG: KMSAN: uninit-value in ip6tnlparsetlvenclim+0x94f/0xbb0 ip6tnlparsetlvenclim+0x94f/0xbb0 ipxip6tnlxmit net/ipv6/ip6tunnel.c:1326 [inline] ip6tnlstartxmit+0xab2/0x1a70 net/ipv6/ip6tunnel.c:1432 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] neighconnectedoutput+0x569/0x660 net/core/neighbour.c:1592 neighoutput include/net/neighbour.h:542 [inline] ip6finishoutput2+0x23a9/0x2b30 net/ipv6/ip6output.c:137 ip6finishoutput+0x855/0x12b0 net/ipv6/ip6output.c:222 NFHOOKCOND include/linux/netfilter.h:303 [inline] ip6output+0x323/0x610 net/ipv6/ip6output.c:243 dstoutput include/net/dst.h:451 [inline] ip6localout+0xe9/0x140 net/ipv6/outputcore.c:155 ip6sendskb net/ipv6/ip6output.c:1952 [inline] ip6pushpendingframes+0x1f9/0x560 net/ipv6/ip6output.c:1972 rawv6pushpendingframes+0xbe8/0xdf0 net/ipv6/raw.c:582 rawv6sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920 inetsendmsg+0x105/0x190 net/ipv4/afinet.c:847 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+0x5c9/0x970 mm/slub.c:3517 dokmallocnode mm/slabcommon.c:1006 [inline] kmallocnodetrackcaller+0x118/0x3c0 mm/slabcommon.c:1027 kmallocreserve+0x249/0x4a0 net/core/skbuff.c:582 pskbexpandhead+0x226/0x1a00 net/core/skbuff.c:2098 pskbpulltail+0x13b/0x2310 net/core/skbuff.c:2655 pskbmaypullreason include/linux/skbuff.h:2673 [inline] pskbmaypull include/linux/skbuff.h:2681 [inline] ip6tnlparsetlvenclim+0x901/0xbb0 net/ipv6/ip6tunnel.c:408 ipxip6tnlxmit net/ipv6/ip6tunnel.c:1326 [inline] ip6tnlstartxmit+0xab2/0x1a70 net/ipv6/ip6tunnel.c:1432 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] neighconnectedoutput+0x569/0x660 net/core/neighbour.c:1592 neighoutput include/net/neighbour.h:542 [inline] ip6finishoutput2+0x23a9/0x2b30 net/ipv6/ip6output.c:137 ip6finishoutput+0x855/0x12b0 net/ipv6/ip6output.c:222 NFHOOKCOND include/linux/netfilter.h:303 [inline] ip6output+0x323/0x610 net/ipv6/ip6output.c:243 dstoutput include/net/dst.h:451 [inline] ip6localout+0xe9/0x140 net/ipv6/outputcore.c:155 ip6sendskb net/ipv6/ip6output.c:1952 [inline] ip6pushpendingframes+0x1f9/0x560 net/ipv6/ip6output.c:1972 rawv6pushpendingframes+0xbe8/0xdf0 net/ipv6/raw.c:582 rawv6sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920 inetsendmsg+0x105/0x190 net/ipv4/afinet.c:847 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] dosyssendms ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: Fix PCI device refcount leak in radeonatrmgetbios()
As comment of pcigetclass() says, it returns a pcidevice with its refcount increased and decreased the refcount for the input parameter @from if it is not NULL.
If we break the loop in radeonatrmgetbios() with 'pdev' not NULL, we need to call pcidevput() to decrease the refcount. Add the missing pcidevput() to avoid refcount leak.
In the Linux kernel, the following vulnerability has been resolved:
mm,hugetlb: take hugetlblock before decrementing h->resvhugepages
The h->hugepages counters are protected by the hugetlblock, but allochugepage has a corner case where it can decrement the counter outside of the lock.
This could lead to a corrupted value of h->resvhugepages, which we have observed on our systems.
Take the hugetlblock before decrementing h->resvhugepages to avoid a potential race.
In the Linux kernel, the following vulnerability has been resolved:
pnode: terminate at peers of source
The propagatemnt() function handles mount propagation when creating mounts and propagates the source mount tree @sourcemnt to all applicable nodes of the destination propagation mount tree headed by @destmnt.
Unfortunately it contains a bug where it fails to terminate at peers of @sourcemnt when looking up copies of the source mount that become masters for copies of the source mount tree mounted on top of slaves in the destination propagation tree causing a NULL dereference.
Once the mechanics of the bug are understood it's easy to trigger. Because of unprivileged user namespaces it is available to unprivileged users.
While fixing this bug we've gotten confused multiple times due to unclear terminology or missing concepts. So let's start this with some clarifications:
The terms "master" or "peer" denote a shared mount. A shared mount belongs to a peer group.
A peer group is a set of shared mounts that propagate to each other. They are identified by a peer group id. The peer group id is available in @sharedmnt->mntgroupid. Shared mounts within the same peer group have the same peer group id. The peers in a peer group can be reached via @sharedmnt->mntshare.
The terms "slave mount" or "dependent mount" denote a mount that receives propagation from a peer in a peer group. IOW, shared mounts may have slave mounts and slave mounts have shared mounts as their master. Slave mounts of a given peer in a peer group are listed on that peers slave list available at @sharedmnt->mntslavelist.
The term "master mount" denotes a mount in a peer group. IOW, it denotes a shared mount or a peer mount in a peer group. The term "master mount" - or "master" for short - is mostly used when talking in the context of slave mounts that receive propagation from a master mount. A master mount of a slave identifies the closest peer group a slave mount receives propagation from. The master mount of a slave can be identified via @slavemount->mntmaster. Different slaves may point to different masters in the same peer group.
Multiple peers in a peer group can have non-empty ->mntslavelists. Non-empty ->mntslavelists of peers don't intersect. Consequently, to ensure all slave mounts of a peer group are visited the ->mntslavelists of all peers in a peer group have to be walked.
Slave mounts point to a peer in the closest peer group they receive propagation from via @slavemnt->mntmaster (see above). Together with these peers they form a propagation group (see below). The closest peer group can thus be identified through the peer group id @slavemnt->mntmaster->mntgroupid of the peer/master that a slave mount receives propagation from.
A shared-slave mount is a slave mount to a peer group pg1 while also a peer in another peer group pg2. IOW, a peer group may receive propagation from another peer group.
If a peer group pg1 is a slave to another peer group pg2 then all peers in peer group pg1 point to the same peer in peer group pg2 via ->mntmaster. IOW, all peers in peer group pg1 appear on the same ->mntslavelist. IOW, they cannot be slaves to different peer groups.
A pure slave mount is a slave mount that is a slave to a peer group but is not a peer in another peer group.
A propagation group denotes the set of mounts consisting of a single peer group pg1 and all slave mounts and shared-slave mounts that point to a peer in that peer group via ->mntmaster. IOW, all slave mounts such that @slavemnt->mntmaster->mntgroupid is equal to @sharedmnt->mntgroupid.
The concept of a propagation group makes it easier to talk about a single propagation level in a propagation tree.
For example, in propagatemnt() the immediate peers of @destmnt and all slaves of @destmnt's peer group form a propagation group pr ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
net/x25: Fix skb leak in x25lapbreceiveframe()
x25lapbreceiveframe() using skbcopy() to get a private copy of skb, the new skb should be freed in the undersized/fragmented skb error handling path. Otherwise there is a memory leak.
In the Linux kernel, the following vulnerability has been resolved:
perf/core: Fix data race between perfeventsetoutput() and perfmmapclose()
Yang Jihing reported a race between perfeventsetoutput() and perfmmapclose():
CPU1 CPU2
perfmmapclose(e2) if (atomicdecandtest(&e2->rb->mmapcount)) // 1 - > 0 detachrest = true
ioctl(e1, IOCSETOUTPUT, e2) perfeventsetoutput(e1, e2)
... listforeachentryrcu(e, &e2->rb->eventlist, rbentry) ringbufferattach(e, NULL); // e1 isn't yet added and // therefore not detached
ringbufferattach(e1, e2->rb) listaddrcu(&e1->rbentry, &e2->rb->eventlist)
After this; e1 is attached to an unmapped rb and a subsequent perfmmap() will loop forever more:
again: mutexlock(&e->mmapmutex); if (event->rb) { ... if (!atomicincnotzero(&e->rb->mmapcount)) { ... mutexunlock(&e->mmapmutex); goto again; } }
The loop in perfmmapclose() holds e2->mmapmutex, while the attach in perfeventsetoutput() holds e1->mmapmutex. As such there is no serialization to avoid this race.
Change perfeventsetoutput() to take both e1->mmapmutex and e2->mmapmutex to alleviate that problem. Additionally, have the loop in perfmmap() detach the rb directly, this avoids having to wait for the concurrent perfmmapclose() to get around to doing it to make progress.