OESA-2024-1692

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

net: usb: fix possible use-after-free in smsc75xx_bind

The commit 46a8b29c6306 ("net: usb: fix memory leak in smsc75xxbind") fails to clean up the work scheduled in smsc75xxreset-> smsc75xxsetmulticast, which leads to use-after-free if the work is scheduled to start after the deallocation. In addition, this patch also removes a dangling pointer - dev->data[0].

This patch calls cancelworksync to cancel the scheduled work and set the dangling pointer to NULL.(CVE-2021-47239)

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

RDMA: Verify port when creating flow rule

Validate port value provided by the user and with that remove no longer needed validation by the driver. The missing check in the mlx5_ib driver could cause to the below oops.

Call trace: createflowrule+0x2d4/0xf28 [mlx5ib] mlx5ibcreateflow+0x2d0/0x5b0 [mlx5ib] ibuverbsexcreateflow+0x4cc/0x624 [ibuverbs] ibuverbshandlerUVERBSMETHODINVOKEWRITE+0xd4/0x150 [ibuverbs] ibuverbscmdverbs.isra.7+0xb28/0xc50 [ibuverbs] ibuverbsioctl+0x158/0x1d0 [ibuverbs] dovfsioctl+0xd0/0xaf0 ksysioctl+0x84/0xb4 _arm64sysioctl+0x28/0xc4 el0svccommon.constprop.3+0xa4/0x254 el0svchandler+0x84/0xa0 el0svc+0x10/0x26c Code: b9401260 f9615681 51000400 8b001c20 (f9403c1a)(CVE-2021-47265)

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

bcache: avoid oversized read request in cache missing code path

In the cache missing code path of cached device, if a proper location from the internal B+ tree is matched for a cache miss range, function cacheddevcachemiss() will be called in cachelookupfn() in the following code block, [code block 1] 526 unsigned int sectors = KEYINODE(k) == s->iop.inode 527 ? mint(uint64t, INTMAX, 528 KEYSTART(k) - bio->biiter.bisector) 529 : INTMAX; 530 int ret = s->d->cachemiss(b, s, bio, sectors);

Here s->d->cachemiss() is the call backfunction pointer initialized as cacheddevcachemiss(), the last parameter 'sectors' is an important hint to calculate the size of read request to backing device of the missing cache data.

Current calculation in above code block may generate oversized value of 'sectors', which consequently may trigger 2 different potential kernel panics by BUG() or BUG_ON() as listed below,

1) BUGON() inside bchbtreeinsertkey(), [code block 2] 886 BUGON(b->ops->isextents && !KEYSIZE(k)); 2) BUG() inside biovecslab(), [code block 3] 51 default: 52 BUG(); 53 return NULL;

All the above panics are original from cacheddevcache_miss() by the oversized parameter 'sectors'.

Inside cacheddevcachemiss(), parameter 'sectors' is used to calculate the size of data read from backing device for the cache missing. This size is stored in s->insertbiosectors by the following lines of code, [code block 4] 909 s->insertbiosectors = min(sectors, biosectors(bio) + reada);

Then the actual key inserting to the internal B+ tree is generated and stored in s->iop.replacekey by the following lines of code, [code block 5] 911 s->iop.replacekey = KEY(s->iop.inode, 912 bio->biiter.bisector + s->insertbiosectors, 913 s->insertbiosectors); The oversized parameter 'sectors' may trigger panic 1) by BUG_ON() from the above code block.

And the bio sending to backing device for the missing data is allocated with hint from s->insertbiosectors by the following lines of code, [code block 6] 926 cachebio = bioallocbioset(GFPNOWAIT, 927 DIVROUNDUP(s->insertbiosectors, PAGESECTORS), 928 &dc->disk.biosplit); The oversized parameter 'sectors' may trigger panic 2) by BUG() from the agove code block.

Now let me explain how the panics happen with the oversized 'sectors'. In code block 5, replacekey is generated by macro KEY(). From the definition of macro KEY(), [code block 7] 71 #define KEY(inode, offset, size) \ 72 ((struct bkey) { \ 73 .high = (1ULL << 63) | ((_u64) (size) << 20) | (inode), \ 74 .low = (offset) \ 75 })

Here 'size' is 16bits width embedded in 64bits member 'high' of struct bkey. But in code block 1, if "KEYSTART(k) - bio->biiter.bisector" is very probably to be larger than (1<<16) - 1, which makes the bkey size calculation in code block 5 is overflowed. In one bug report the value of parameter 'sectors' is 131072 (= 1 << 17), the overflowed 'sectors' results the overflowed s->insertbiosectors in code block 4, then makes size field of s->iop.replacekey to be 0 in code block 5. Then the 0- sized s->iop.replacekey is inserted into the internal B+ tree as cache missing check key (a special key to detect and avoid a racing between normal write request and cache missing read request) as, [code block 8] 915 ret = bchbtreeinsertcheckkey(b, &s->op, &s->iop.replacekey);

Then the 0-sized s->iop.replacekey as 3rd parameter triggers the bkey size check BUGON() in code block 2, and causes the kernel panic 1).

Another ke ---truncated---(CVE-2021-47275)

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

kvm: avoid speculation-based attacks from out-of-range memslot accesses

KVM's mechanism for accessing guest memory translates a guest physical address (gpa) to a host virtual address using the right-shifted gpa (also known as gfn) and a struct kvmmemoryslot. The translation is performed in _gfntohvamemslot using the following formula:

  hva = slot->userspace_addr + (gfn - slot->base_gfn) * PAGE_SIZE

It is expected that gfn falls within the boundaries of the guest's physical memory. However, a guest can access invalid physical addresses in such a way that the gfn is invalid.

_gfntohvamemslot is called from kvmvcpugfntohvaprot, which first retrieves a memslot through _gfntomemslot. While _gfnto_memslot does check that the gfn falls within the boundaries of the guest's physical memory or not, a CPU can speculate the result of the check and continue execution speculatively using an illegal gfn. The speculation can result in calculating an out-of-bounds hva. If the resulting host virtual address is used to load another guest physical address, this is effectively a Spectre gadget consisting of two consecutive reads, the second of which is data dependent on the first.

Right now it's not clear if there are any cases in which this is exploitable. One interesting case was reported by the original author of this patch, and involves visiting guest page tables on x86. Right now these are not vulnerable because the hva read goes through getuser(), which contains an LFENCE speculation barrier. However, there are patches in progress for x86 uaccess.h to mask kernel addresses instead of using LFENCE; once these land, a guest could use speculation to read from the VMM's ring 3 address space. Other architectures such as ARM already use the address masking method, and would be susceptible to this same kind of data-dependent access gadgets. Therefore, this patch proactively protects from these attacks by masking out-of-bounds gfns in _gfntohva_memslot, which blocks speculation of invalid hvas.

Sean Christopherson noted that this patch does not cover kvmreadguestoffsetcached. This however is limited to a few bytes past the end of the cache, and therefore it is unlikely to be useful in the context of building a chain of data dependent accesses.(CVE-2021-47277)

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

net: fix uninit-value in caifseqpktsendmsg

When nrsegs equal to zero in iovecfromuser, the object msg->msgiter.iov is uninit stack memory in caifseqpktsendmsg which is defined in _syssendmsg. So we cann't just judge msg->msgiter.iov->base directlly. We can use nrsegs to judge msg in caifseqpkt_sendmsg whether has data buffers.

===================================================== BUG: KMSAN: uninit-value in caifseqpktsendmsg+0x693/0xf60 net/caif/caifsocket.c:542 Call Trace: dumpstack lib/dumpstack.c:77 [inline] dumpstack+0x1c9/0x220 lib/dumpstack.c:118 kmsanreport+0xf7/0x1e0 mm/kmsan/kmsanreport.c:118 _msanwarning+0x58/0xa0 mm/kmsan/kmsaninstr.c:215 caifseqpktsendmsg+0x693/0xf60 net/caif/caifsocket.c:542 socksendmsgnosec net/socket.c:652 [inline] socksendmsg net/socket.c:672 [inline] syssendmsg+0x12b6/0x1350 net/socket.c:2343 _syssendmsg net/socket.c:2397 [inline] _syssendmmsg+0x808/0xc90 net/socket.c:2480 _compatsys_sendmmsg net/compat.c:656 inline

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

memory: fsl_ifc: fix leak of private memory on probe failure

On probe error the driver should free the memory allocated for private structure. Fix this by using resource-managed allocation.(CVE-2021-47314)

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

watchdog: sc520wdt: Fix possible use-after-free in wdtturnoff()

This module's remove path calls del_timer(). However, that function does not wait until the timer handler finishes. This means that the timer handler may still be running after the driver's remove function has finished, which would result in a use-after-free.

Fix by calling deltimersync(), which makes sure the timer handler has finished, and unable to re-schedule itself.(CVE-2021-47323)

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

tty: serial: 8250: serial_cs: Fix a memory leak in error handling path

In the probe function, if the final 'serial_config()' fails, 'info' is leaking.

Add a resource handling path to free this memory.(CVE-2021-47330)

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

powerpc/mm: Fix lockup on kernel exec fault

The powerpc kernel is not prepared to handle exec faults from kernel. Especially, the function isexecfault() will return 'false' when an exec fault is taken by kernel, because the check is based on reading current->thread.regs->trap which contains the trap from user.

For instance, when provoking a LKDTM EXECUSERSPACE test, current->thread.regs->trap is set to SYSCALL trap (0xc00), and the fault taken by the kernel is not seen as an exec fault by setaccessflagsfilter().

Commit d7df2443cd5f ("powerpc/mm: Fix spurious segfaults on radix with autonuma") made it clear and handled it properly. But later on commit d3ca587404b3 ("powerpc/mm: Fix reporting of kernel execute faults") removed that handling, introducing test based on error_code. And here is the problem, because on the 603 all upper bits of SRR1 get cleared when the TLB instruction miss handler bails out to ISI.

Until commit cbd7e6ca0210 ("powerpc/fault: Avoid heavy searchexceptiontables() verification"), an exec fault from kernel at a userspace address was indirectly caught by the lack of entry for that address in the exception tables. But after that commit the kernel mainly relies on KUAP or on core mm handling to catch wrong user accesses. Here the access is not wrong, so mm handles it. It is a minor fault because PAGEEXEC is not set, setaccessflagsfilter() should set PAGEEXEC and voila. But as isexecfault() returns false as explained in the beginning, setaccessflagsfilter() bails out without setting PAGE_EXEC flag, which leads to a forever minor exec fault.

As the kernel is not prepared to handle such exec faults, the thing to do is to fire in badkernelfault() for any exec fault taken by the kernel, as it was prior to commit d3ca587404b3.(CVE-2021-47350)

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

udf: Fix NULL pointer dereference in udf_symlink function

In function udfsymlink, epos.bh is assigned with the value returned by udftgetblk. The function udftgetblk is defined in udf/misc.c and returns the value of sbgetblk function that could be NULL. Then, epos.bh is used without any check, causing a possible NULL pointer dereference when sb_getblk fails.

This fix adds a check to validate the value of epos.bh.(CVE-2021-47353)

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

atm: nicstar: Fix possible use-after-free in nicstar_cleanup()

This module's remove path calls del_timer(). However, that function does not wait until the timer handler finishes. This means that the timer handler may still be running after the driver's remove function has finished, which would result in a use-after-free.

Fix by calling deltimersync(), which makes sure the timer handler has finished, and unable to re-schedule itself.(CVE-2021-47355)

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

mISDN: fix possible use-after-free in HFC_cleanup()

This module's remove path calls del_timer(). However, that function does not wait until the timer handler finishes. This means that the timer handler may still be running after the driver's remove function has finished, which would result in a use-after-free.

Fix by calling deltimersync(), which makes sure the timer handler has finished, and unable to re-schedule itself.(CVE-2021-47356)

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

atm: iphase: fix possible use-after-free in iamoduleexit()

This module's remove path calls del_timer(). However, that function does not wait until the timer handler finishes. This means that the timer handler may still be running after the driver's remove function has finished, which would result in a use-after-free.

Fix by calling deltimersync(), which makes sure the timer handler has finished, and unable to re-schedule itself.(CVE-2021-47357)

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

mcb: fix error handling in mcballocbus()

There are two bugs: 1) If idasimpleget() fails then this code calls putdevice(carrier) but we haven't yet called getdevice(carrier) and probably that leads to a use after free. 2) After deviceinitialize() then we need to use putdevice() to release the bus. This will free the internal resources tied to the device and call mcbfreebus() which will free the rest.(CVE-2021-47361)

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

drm/amd/pm: Update intermediate power state for SI

Update the current state as boot state during dpm initialization. During the subsequent initialization, setpowerstate gets called to transition to the final power state. setpowerstate refers to values from the current state and without current state populated, it could result in NULL pointer dereference.

For ex: on platforms where PCI speed change is supported through ACPI ATCS method, the link speed of current state needs to be queried before deciding on changing to final power state's link speed. The logic to query ATCS-support was broken on certain platforms. The issue became visible when broken ATCS-support logic got fixed with commit f9b7f3703ff9 ("drm/amdgpu/acpi: make ATPX/ATCS structures global (v2)").

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1698(CVE-2021-47362)

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

mac80211: fix use-after-free in CCMP/GCMP RX

When PN checking is done in mac80211, for fragmentation we need to copy the PN to the RX struct so we can later use it to do a comparison, since commit bf30ca922a0c ("mac80211: check defrag PN against current frame").

Unfortunately, in that commit I used the 'hdr' variable without it being necessarily valid, so use-after-free could occur if it was necessary to reallocate (parts of) the frame.

Fix this by reloading the variable after the code that results in the reallocations, if any.

This fixes https://bugzilla.kernel.org/show_bug.cgi?id=214401.(CVE-2021-47388)

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

mac80211: limit injected vht mcs/nss in ieee80211parsetx_radiotap

Limit max values for vht mcs and nss in ieee80211parsetx_radiotap routine in order to fix the following warning reported by syzbot:

WARNING: CPU: 0 PID: 10717 at include/net/mac80211.h:989 ieee80211ratesetvht include/net/mac80211.h:989 [inline] WARNING: CPU: 0 PID: 10717 at include/net/mac80211.h:989 ieee80211parsetxradiotap+0x101e/0x12d0 net/mac80211/tx.c:2244 Modules linked in: CPU: 0 PID: 10717 Comm: syz-executor.5 Not tainted 5.14.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:ieee80211ratesetvht include/net/mac80211.h:989 [inline] RIP: 0010:ieee80211parsetxradiotap+0x101e/0x12d0 net/mac80211/tx.c:2244 RSP: 0018:ffffc9000186f3e8 EFLAGS: 00010216 RAX: 0000000000000618 RBX: ffff88804ef76500 RCX: ffffc900143a5000 RDX: 0000000000040000 RSI: ffffffff888f478e RDI: 0000000000000003 RBP: 00000000ffffffff R08: 0000000000000000 R09: 0000000000000100 R10: ffffffff888f46f9 R11: 0000000000000000 R12: 00000000fffffff8 R13: ffff88804ef7653c R14: 0000000000000001 R15: 0000000000000004 FS: 00007fbf5718f700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2de23000 CR3: 000000006a671000 CR4: 00000000001506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600 Call Trace: ieee80211monitorselectqueue+0xa6/0x250 net/mac80211/iface.c:740 netdevcorepicktx+0x169/0x2e0 net/core/dev.c:4089 devqueuexmit+0x6f9/0x3710 net/core/dev.c:4165 _bpftxskb net/core/filter.c:2114 [inline] _bpfredirectnomac net/core/filter.c:2139 [inline] _bpfredirect+0x5ba/0xd20 net/core/filter.c:2162 _bpfcloneredirect net/core/filter.c:2429 [inline] bpfcloneredirect+0x2ae/0x420 net/core/filter.c:2401 bpfprogeeb6f53a69e5c6a2+0x59/0x234 bpfdispatchernopfunc include/linux/bpf.h:717 [inline] _bpfprogrun include/linux/filter.h:624 [inline] bpfprogrun include/linux/filter.h:631 [inline] bpftestrun+0x381/0xa30 net/bpf/testrun.c:119 bpfprogtestrunskb+0xb84/0x1ee0 net/bpf/testrun.c:663 bpfprogtestrun kernel/bpf/syscall.c:3307 [inline] _sysbpf+0x2137/0x5df0 kernel/bpf/syscall.c:4605 _dosysbpf kernel/bpf/syscall.c:4691 [inline] _sesysbpf kernel/bpf/syscall.c:4689 [inline] _x64sysbpf+0x75/0xb0 kernel/bpf/syscall.c:4689 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x35/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x44/0xae RIP: 0033:0x4665f9(CVE-2021-47395)

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

sctp: break out if skbheaderpointer returns NULL in sctprcvootb

We should always check if skbheaderpointer's return is NULL before using it, otherwise it may cause null-ptr-deref, as syzbot reported:

KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:sctprcvootb net/sctp/input.c:705 [inline] RIP: 0010:sctprcv+0x1d84/0x3220 net/sctp/input.c:196 Call Trace: <IRQ> sctp6rcv+0x38/0x60 net/sctp/ipv6.c:1109 ip6protocoldeliverrcu+0x2e9/0x1ca0 net/ipv6/ip6input.c:422 ip6inputfinish+0x62/0x170 net/ipv6/ip6input.c:463 NFHOOK include/linux/netfilter.h:307 [inline] NFHOOK include/linux/netfilter.h:301 [inline] ip6input+0x9c/0xd0 net/ipv6/ip6input.c:472 dstinput include/net/dst.h:460 [inline] ip6rcvfinish net/ipv6/ip6input.c:76 [inline] NFHOOK include/linux/netfilter.h:307 [inline] NFHOOK include/linux/netfilter.h:301 [inline] ipv6rcv+0x28c/0x3c0 net/ipv6/ip6_input.c:297(CVE-2021-47397)

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

ipack: ipoctal: fix stack information leak

The tty driver name is used also after registering the driver and must specifically not be allocated on the stack to avoid leaking information to user space (or triggering an oops).

Drivers should not try to encode topology information in the tty device name but this one snuck in through staging without anyone noticing and another driver has since copied this malpractice.

Fixing the ABI is a separate issue, but this at least plugs the security hole.(CVE-2021-47401)

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

HID: betop: fix slab-out-of-bounds Write in betop_probe

Syzbot reported slab-out-of-bounds Write bug in hid-betopff driver. The problem is the driver assumes the device must have an input report but some malicious devices violate this assumption.

So this patch checks hid_device's input is non empty before it's been used.(CVE-2021-47404)

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

HID: usbhid: free rawreport buffers in usbhidstop

Free the unsent raw_report buffers when the device is removed.

Fixes a memory leak reported by syzbot at: https://syzkaller.appspot.com/bug?id=7b4fa7cb1a7c2d3342a2a8a6c53371c8c418ab47(CVE-2021-47405)

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

netfilter: conntrack: serialize hash resizes and cleanups

Syzbot was able to trigger the following warning [1]

No repro found by syzbot yet but I was able to trigger similar issue by having 2 scripts running in parallel, changing conntrack hash sizes, and:

for j in seq 1 1000 ; do unshare -n /bin/true >/dev/null ; done

It would take more than 5 minutes for net_namespace structures to be cleaned up.

This is because nfctiterate_cleanup() has to restart everytime a resize happened.

By adding a mutex, we can serialize hash resizes and cleanups and also make getnextcorpse() faster by skipping over empty buckets.

Even without resizes in the picture, this patch considerably speeds up network namespace dismantles.

[1] INFO: task syz-executor.0:8312 can't die for more than 144 seconds. task:syz-executor.0 state:R running task stack:25672 pid: 8312 ppid: 6573 flags:0x00004006 Call Trace: contextswitch kernel/sched/core.c:4955 [inline] _schedule+0x940/0x26f0 kernel/sched/core.c:6236 preemptschedulecommon+0x45/0xc0 kernel/sched/core.c:6408 preemptschedulethunk+0x16/0x18 arch/x86/entry/thunk64.S:35 _localbhenableip+0x109/0x120 kernel/softirq.c:390 localbhenable include/linux/bottomhalf.h:32 [inline] getnextcorpse net/netfilter/nfconntrackcore.c:2252 [inline] nfctiteratecleanup+0x15a/0x450 net/netfilter/nfconntrackcore.c:2275 nfconntrackcleanupnetlist+0x14c/0x4f0 net/netfilter/nfconntrackcore.c:2469 opsexitlist+0x10d/0x160 net/core/netnamespace.c:171 setupnet+0x639/0xa30 net/core/netnamespace.c:349 copynetns+0x319/0x760 net/core/netnamespace.c:470 createnewnamespaces+0x3f6/0xb20 kernel/nsproxy.c:110 unsharensproxynamespaces+0xc1/0x1f0 kernel/nsproxy.c:226 ksysunshare+0x445/0x920 kernel/fork.c:3128 _dosysunshare kernel/fork.c:3202 [inline] _sesysunshare kernel/fork.c:3200 [inline] _x64sysunshare+0x2d/0x40 kernel/fork.c:3200 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x35/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x44/0xae RIP: 0033:0x7f63da68e739 RSP: 002b:00007f63d7c05188 EFLAGS: 00000246 ORIGRAX: 0000000000000110 RAX: ffffffffffffffda RBX: 00007f63da792f80 RCX: 00007f63da68e739 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000040000000 RBP: 00007f63da6e8cc4 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f63da792f80 R13: 00007fff50b75d3f R14: 00007f63d7c05300 R15: 0000000000022000

Showing all locks held in the system: 1 lock held by khungtaskd/27: #0: ffffffff8b980020 (rcureadlock){....}-{1:2}, at: debugshowalllocks+0x53/0x260 kernel/locking/lockdep.c:6446 2 locks held by kworker/u4:2/153: #0: ffff888010c69138 ((wqcompletion)eventsunbound){+.+.}-{0:0}, at: archatomic64set arch/x86/include/asm/atomic6464.h:34 [inline] #0: ffff888010c69138 ((wqcompletion)eventsunbound){+.+.}-{0:0}, at: archatomiclongset include/linux/atomic/atomic-long.h:41 [inline] #0: ffff888010c69138 ((wqcompletion)eventsunbound){+.+.}-{0:0}, at: atomiclongset include/linux/atomic/atomic-instrumented.h:1198 [inline] #0: ffff888010c69138 ((wqcompletion)eventsunbound){+.+.}-{0:0}, at: setworkdata kernel/workqueue.c:634 [inline] #0: ffff888010c69138 ((wqcompletion)eventsunbound){+.+.}-{0:0}, at: setworkpoolandclearpending kernel/workqueue.c:661 [inline] #0: ffff888010c69138 ((wqcompletion)eventsunbound){+.+.}-{0:0}, at: processonework+0x896/0x1690 kernel/workqueue.c:2268 #1: ffffc9000140fdb0 ((kfencetimer).work){+.+.}-{0:0}, at: processonework+0x8ca/0x1690 kernel/workqueue.c:2272 1 lock held by systemd-udevd/2970: 1 lock held by in:imklog/6258: #0: ffff88807f970ff0 (&f->fposlock){+.+.}-{3:3}, at: _fdget_pos+0xe9/0x100 fs/file.c:990 3 locks held by kworker/1:6/8158: 1 lock held by syz-executor.0/8312: 2 locks held by kworker/u4:13/9320: 1 lock held by ---truncated---(CVE-2021-47408)

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

drm/nouveau/debugfs: fix file release memory leak

When using singleopen() for opening, singlerelease() should be called, otherwise the 'op' allocated in single_open() will be leaked.(CVE-2021-47423)

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

scsi: iscsi: Fix iscsi_task use after free

Commit d39df158518c ("scsi: iscsi: Have abort handler get ref to conn") added iscsigetconn()/iscsiputconn() calls during abort handling but then also changed the handling of the case where we detect an already completed task where we now end up doing a goto to the common put/cleanup code. This results in a iscsitask use after free, because the common cleanup code will do a put on the iscsitask.

This reverts the goto and moves the iscsigetconn() to after we've checked if the iscsi_task is valid.(CVE-2021-47427)

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

net/mlx5e: Fix memory leak in mlx5coredestroy_cq() error path

Prior to this patch in case mlx5coredestroy_cq() failed it returns without completing all destroy operations and that leads to memory leak. Instead, complete the destroy flow before return error.

Also move mlx5debugcqremove() to the beginning of mlx5coredestroycq() to be symmetrical with mlx5corecreate_cq().

kmemleak complains on:

unreferenced object 0xc000000038625100 (size 64): comm "ethtool", pid 28301, jiffies 4298062946 (age 785.380s) hex dump (first 32 bytes): 60 01 48 94 00 00 00 c0 b8 05 34 c3 00 00 00 c0 `.H.......4..... 02 00 00 00 00 00 00 00 00 db 7d c1 00 00 00 c0 ..........}..... backtrace: [<000000009e8643cb>] addrestree+0xd0/0x270 [mlx5core] [<00000000e7cb8e6c>] mlx5debugcqadd+0x5c/0xc0 [mlx5core] [<000000002a12918f>] mlx5corecreatecq+0x1d0/0x2d0 [mlx5core] [<00000000cef0a696>] mlx5ecreatecq+0x210/0x3f0 [mlx5core] [<000000009c642c26>] mlx5eopencq+0xb4/0x130 [mlx5core] [<0000000058dfa578>] mlx5eptpopen+0x7f4/0xe10 [mlx5core] [<0000000081839561>] mlx5eopenchannels+0x9cc/0x13e0 [mlx5core] [<0000000009cf05d4>] mlx5eswitchprivchannels+0xa4/0x230 [mlx5core] [<0000000042bbedd8>] mlx5esafeswitchparams+0x14c/0x300 [mlx5core] [<0000000004bc9db8>] setpflagtxportts+0x9c/0x160 [mlx5core] [<00000000a0553443>] mlx5esetprivflags+0xd0/0x1b0 [mlx5core] [<00000000a8f3d84b>] ethnlsetprivflags+0x234/0x2d0 [<00000000fd27f27c>] genlfamilyrcvmsgdoit+0x108/0x1d0 [<00000000f495e2bb>] genlfamilyrcvmsg+0xe4/0x1f0 [<00000000646c5c2c>] genlrcvmsg+0x78/0x120 [<00000000d53e384e>] netlinkrcv_skb+0x74/0x1a0(CVE-2021-47438)

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

NFC: digital: fix possible memory leak in digitalinsendsddreq()

'skb' is allocated in digitalinsendsddreq(), but not free when digitalinsendcmd() failed, which will cause memory leak. Fix it by freeing 'skb' if digitalinsendcmd() return failed.(CVE-2021-47442)

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

NFC: digital: fix possible memory leak in digitaltglisten_mdaa()

'params' is allocated in digitaltglistenmdaa(), but not free when digitalsendcmd() failed, which will cause memory leak. Fix it by freeing 'params' if digitalsend_cmd() return failed.(CVE-2021-47443)

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

drm/msm: Fix null pointer dereference on pointer edp

The initialization of pointer dev dereferences pointer edp before edp is null checked, so there is a potential null pointer deference issue. Fix this by only dereferencing edp after edp has been null checked.

Addresses-Coverity: ("Dereference before null check")(CVE-2021-47445)

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

ocfs2: mount fails with buffer overflow in strlen

Starting with kernel 5.11 built with CONFIGFORTIFYSOURCE mouting an ocfs2 filesystem with either o2cb or pcmk cluster stack fails with the trace below. Problem seems to be that strings for cluster stack and cluster name are not guaranteed to be null terminated in the disk representation, while strlcpy assumes that the source string is always null terminated. This causes a read outside of the source string triggering the buffer overflow detection.

detected buffer overflow in strlen ------------[ cut here ]------------ kernel BUG at lib/string.c:1149! invalid opcode: 0000 [#1] SMP PTI CPU: 1 PID: 910 Comm: mount.ocfs2 Not tainted 5.14.0-1-amd64 #1 Debian 5.14.6-2 RIP: 0010:fortifypanic+0xf/0x11 ... Call Trace: ocfs2initializesuper.isra.0.cold+0xc/0x18 [ocfs2] ocfs2fillsuper+0x359/0x19b0 [ocfs2] mountbdev+0x185/0x1b0 legacygettree+0x27/0x40 vfsgettree+0x25/0xb0 pathmount+0x454/0xa20 _x64sysmount+0x103/0x140 dosyscall64+0x3b/0xc0 entrySYSCALL64afterhwframe+0x44/0xae(CVE-2021-47458)

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

can: j1939: j1939netdevstart(): fix UAF for rxkref of j1939priv

It will trigger UAF for rxkref of j1939priv as following.

    cpu0                                    cpu1

j1939skbind(socket0, ndev0, ...) j1939netdevstart j1939skbind(socket1, ndev0, ...) j1939netdevstart j1939privset j1939privgetbyndevlocked j1939jskadd ..... j1939netdevstop krefputlock(&priv->rxkref, ...) krefget(&priv->rxkref, ...) REFCOUNT_WARN("addition on 0;...")

==================================================== refcountt: addition on 0; use-after-free. WARNING: CPU: 1 PID: 20874 at lib/refcount.c:25 refcountwarnsaturate+0x169/0x1e0 RIP: 0010:refcountwarnsaturate+0x169/0x1e0 Call Trace: j1939netdevstart+0x68b/0x920 j1939skbind+0x426/0xeb0 ? securitysocket_bind+0x83/0xb0

The rxkref's krefget() and krefput() should use j1939netdev_lock to protect.(CVE-2021-47459)

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

comedi: vmk80xx: fix transfer-buffer overflows

The driver uses endpoint-sized USB transfer buffers but up until recently had no sanity checks on the sizes.

Commit e1f13c879a7c ("staging: comedi: check validity of wMaxPacketSize of usb endpoints found") inadvertently fixed NULL-pointer dereferences when accessing the transfer buffers in case a malicious device has a zero wMaxPacketSize.

Make sure to allocate buffers large enough to handle also the other accesses that are done without a size check (e.g. byte 18 in vmk80xxcntinsnread() for the VMK8061MODEL) to avoid writing beyond the buffers, for example, when doing descriptor fuzzing.

The original driver was for a low-speed device with 8-byte buffers. Support was later added for a device that uses bulk transfers and is presumably a full-speed device with a maximum 64-byte wMaxPacketSize.(CVE-2021-47475)

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

comedi: dt9812: fix DMA buffers on stack

USB transfer buffers are typically mapped for DMA and must not be allocated on the stack or transfers will fail.

Allocate proper transfer buffers in the various command helpers and return an error on short transfers instead of acting on random stack data.

Note that this also fixes a stack info leak on systems where DMA is not used as 32 bytes are always sent to the device regardless of how short the command is.(CVE-2021-47477)

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

usbnet: sanity check for maxpacket

maxpacket of 0 makes no sense and oopses as we need to divide by it. Give up.

V2: fixed typo in log and stylistic issues(CVE-2021-47495)

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

perf hist: Fix memory leak of a perfhppfmt

perfhppcolumnunregister() removes an entry from a list but doesn't free the memory causing a memory leak spotted by leak sanitizer.

Add the free while at the same time reducing the scope of the function to static.(CVE-2021-47545)

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

ethernet: hisilicon: hns: hnsdsafmisc: fix a possible array overflow in hnsdsafgesrstby_port()

The if statement: if (port >= DSAFGENUM) return;

limits the value of port less than DSAFGENUM (i.e., 8). However, if the value of port is 6 or 7, an array overflow could occur: portrstoff = dsafdev->maccb[port]->portrstoff;

because the length of dsafdev->maccb is DSAFMAXPORT_NUM (i.e., 6).

To fix this possible array overflow, we first check port and if it is greater than or equal to DSAFMAXPORT_NUM, the function returns.(CVE-2021-47548)

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

satafsl: fix UAF in satafslportstop when rmmod sata_fsl

When the rmmod sata_fsl.ko command is executed in the PPC64 GNU/Linux, a bug is reported: ================================================================== BUG: Unable to handle kernel data access on read at 0x80000800805b502c Oops: Kernel access of bad area, sig: 11 [#1] NIP [c0000000000388a4] .ioread32+0x4/0x20 LR [80000000000c6034] .satafslportstop+0x44/0xe0 [satafsl] Call Trace: .freeirq+0x1c/0x4e0 (unreliable) .atahoststop+0x74/0xd0 [libata] .releasenodes+0x330/0x3f0 .devicereleasedriverinternal+0x178/0x2c0 .driverdetach+0x64/0xd0 .busremovedriver+0x70/0xf0 .driverunregister+0x38/0x80 .platformdriverunregister+0x14/0x30 .fslsatadriverexit+0x18/0xa20 [satafsl] .sesysdeletemodule+0x1ec/0x2d0 .systemcallexception+0xfc/0x1f0 systemcallcommon+0xf8/0x200 ==================================================================

The triggering of the BUG is shown in the following stack:

driverdetach devicereleasedriverinternal _devicereleasedriver drv->remove(dev) --> platformdrvremove/platformremove drv->remove(dev) --> satafslremove iounmap(hostpriv->hcrbase); <---- unmap kfree(hostpriv); <---- free devresreleaseall releasenodes dr->node.release(dev, dr->data) --> atahoststop ap->ops->portstop(ap) --> satafslportstop ioread32(hcrbase + HCONTROL) <---- UAF host->ops->hoststop(host)

The iounmap(hostpriv->hcrbase) and kfree(hostpriv) functions should not be executed in drv->remove. These functions should be executed in hoststop after portstop. Therefore, we move these functions to the new function satafslhoststop and bind the new function to host_stop.(CVE-2021-47549)

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

net/smc: Fix NULL pointer dereferencing in smcvlanby_tcpsk()

Coverity reports a possible NULL dereferencing problem:

in smcvlanbytcpsk(): 6. returnednull: netdevlowergetnext returns NULL (checked 29 out of 30 times). 7. varassigned: Assigning: ndev = NULL return value from netdevlowergetnext. 1623 ndev = (struct netdevice *)netdevlowergetnext(ndev, &lower); CID 1468509 (#1 of 1): Dereference null return value (NULLRETURNS) 8. dereference: Dereferencing a pointer that might be NULL ndev when calling isvlandev. 1624 if (isvlandev(ndev)) {

Remove the manual implementation and use netdevwalkalllowerdev() to iterate over the lower devices. While on it remove an obsolete function parameter comment.(CVE-2021-47559)

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

pinctrl: single: fix potential NULL dereference

Added checking of pointer "function" in pcssetmux(). pinmuxgenericget_function() can return NULL and the pointer "function" was dereferenced without checking against NULL.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2022-48708)

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

crypto: s390/aes - Fix buffer overread in CTR mode

When processing the last block, the s390 ctr code will always read a whole block, even if there isn't a whole block of data left. Fix this by using the actual length left and copy it into a buffer first for processing.(CVE-2023-52669)

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

ACPI: video: check for error while searching for backlight device parent

If acpigetparent() called in acpivideodevregisterbacklight() fails, for example, because acpiutacquiremutex() fails inside acpigetparent), this can lead to incorrect (uninitialized) acpiparent handle being passed to acpigetpci_dev() for detecting the parent pci device.

Check acpigetparent() result and set parent device only in case of success.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-52693)

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

sysv: don't call sbbread() with pointerslock held

syzbot is reporting sleep in atomic context in SysV filesystem [1], for sbbread() is called with rwspinlock held.

A "writelock(&pointerslock) => readlock(&pointerslock) deadlock" bug and a "sbbread() with writelock(&pointers_lock)" bug were introduced by "Replace BKL for chain locking with sysvfs-private rwlock" in Linux 2.5.12.

Then, "[PATCH] err1-40: sysvfs locking fix" in Linux 2.6.8 fixed the former bug by moving pointerslock lock to the callers, but instead introduced a "sbbread() with readlock(&pointerslock)" bug (which made this problem easier to hit).

Al Viro suggested that why not to do like getbranch()/getblock()/ findshared() in Minix filesystem does. And doing like that is almost a revert of "[PATCH] err1-40: sysvfs locking fix" except that getbranch() from with findshared() is called without writelock(&pointers_lock).(CVE-2023-52699)

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

net/usb: kalmia: Don't pass actlen in usbbulk_msg error path

syzbot reported that actlen in kalmiasendinitpacket() is uninitialized when passing it to the first usbbulkmsg error path. Jiri Pirko noted that it's pointless to pass it in the error path, and that the value that would be printed in the second error path would be the value of actlen from the first call to usbbulk_msg.[1]

With this in mind, let's just not pass actlen to the usbbulk_msg error paths.

1: https://lore.kernel.org/lkml/Y9pY61y1nwTuzMOa@nanopsycho/(CVE-2023-52703)

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

arm64: Restrict CPUBIGENDIAN to GNU as or LLVM IAS 15.x or newer

Prior to LLVM 15.0.0, LLVM's integrated assembler would incorrectly byte-swap NOP when compiling for big-endian, and the resulting series of bytes happened to match the encoding of FNMADD S21, S30, S0, S0.

This went unnoticed until commit:

34f66c4c4d5518c1 ("arm64: Use a positive cpucap for FP/SIMD")

Prior to that commit, the kernel would always enable the use of FPSIMD early in boot when _cpusetup() initialized CPACR_EL1, and so usage of FNMADD within the kernel was not detected, but could result in the corruption of user or kernel FPSIMD state.

After that commit, the instructions happen to trap during boot prior to FPSIMD being detected and enabled, e.g.

| Unhandled 64-bit el1h sync exception on CPU0, ESR 0x000000001fe00000 -- ASIMD | CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1 | Hardware name: linux,dummy-virt (DT) | pstate: 400000c9 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : _pistrcmp+0x1c/0x150 | lr : populateproperties+0xe4/0x254 | sp : ffffd014173d3ad0 | x29: ffffd014173d3af0 x28: fffffbfffddffcb8 x27: 0000000000000000 | x26: 0000000000000058 x25: fffffbfffddfe054 x24: 0000000000000008 | x23: fffffbfffddfe000 x22: fffffbfffddfe000 x21: fffffbfffddfe044 | x20: ffffd014173d3b70 x19: 0000000000000001 x18: 0000000000000005 | x17: 0000000000000010 x16: 0000000000000000 x15: 00000000413e7000 | x14: 0000000000000000 x13: 0000000000001bcc x12: 0000000000000000 | x11: 00000000d00dfeed x10: ffffd414193f2cd0 x9 : 0000000000000000 | x8 : 0101010101010101 x7 : ffffffffffffffc0 x6 : 0000000000000000 | x5 : 0000000000000000 x4 : 0101010101010101 x3 : 000000000000002a | x2 : 0000000000000001 x1 : ffffd014171f2988 x0 : fffffbfffddffcb8 | Kernel panic - not syncing: Unhandled exception | CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1 | Hardware name: linux,dummy-virt (DT) | Call trace: | dumpbacktrace+0xec/0x108 | showstack+0x18/0x2c | dumpstacklvl+0x50/0x68 | dumpstack+0x18/0x24 | panic+0x13c/0x340 | el1t64irqhandler+0x0/0x1c | el1abort+0x0/0x5c | el1h64sync+0x64/0x68 | _pistrcmp+0x1c/0x150 | unflattendtnodes+0x1e8/0x2d8 | _unflattendevicetree+0x5c/0x15c | unflattendevicetree+0x38/0x50 | setuparch+0x164/0x1e0 | startkernel+0x64/0x38c | _primary_switched+0xbc/0xc4

Restrict CONFIGCPUBIG_ENDIAN to a known good assembler, which is either GNU as or LLVM's IAS 15.0.0 and newer, which contains the linked commit.(CVE-2023-52750)

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

smb: client: fix use-after-free bug in cifsdebugdataprocshow()

Skip SMB sessions that are being teared down (e.g. @ses->sesstatus == SESEXITING) in cifsdebugdataprocshow() to avoid use-after-free in @ses.

This fixes the following GPF when reading from /proc/fs/cifs/DebugData while mounting and umounting

[ 816.251274] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6d81: 0000 [#1] PREEMPT SMP NOPTI ... [ 816.260138] Call Trace: [ 816.260329] <TASK> [ 816.260499] ? dieaddr+0x36/0x90 [ 816.260762] ? excgeneralprotection+0x1b3/0x410 [ 816.261126] ? asmexcgeneralprotection+0x26/0x30 [ 816.261502] ? cifsdebugtcon+0xbd/0x240 [cifs] [ 816.261878] ? cifsdebugtcon+0xab/0x240 [cifs] [ 816.262249] cifsdebugdataprocshow+0x516/0xdb0 [cifs] [ 816.262689] ? seqreaditer+0x379/0x470 [ 816.262995] seqreaditer+0x118/0x470 [ 816.263291] procregreaditer+0x53/0x90 [ 816.263596] ? srsoaliasreturnthunk+0x5/0x7f [ 816.263945] vfsread+0x201/0x350 [ 816.264211] ksysread+0x75/0x100 [ 816.264472] dosyscall64+0x3f/0x90 [ 816.264750] entrySYSCALL64afterhwframe+0x6e/0xd8 [ 816.265135] RIP: 0033:0x7fd5e669d381(CVE-2023-52752)

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

gfs2: ignore negated quota changes

When lots of quota changes are made, there may be cases in which an inode's quota information is increased and then decreased, such as when blocks are added to a file, then deleted from it. If the timing is right, function doqc can add pending quota changes to a transaction, then later, another call to doqc can negate those changes, resulting in a net gain of 0. The quotachange information is recorded in the qc buffer (and qd element of the inode as well). The buffer is added to the transaction by the first call to doqc, but a subsequent call changes the value from non-zero back to zero. At that point it's too late to remove the buffer_head from the transaction. Later, when the quota sync code is called, the zero-change qd element is discovered and flagged as an assert warning. If the fs is mounted with errors=panic, the kernel will panic.

This is usually seen when files are truncated and the quota changes are negated by punchhole/truncate which uses gfs2quotahold and gfs2quotaunhold rather than block allocations that use gfs2quotalock and gfs2quota_unlock which automatically do quota sync.

This patch solves the problem by adding a check to qdchecksync such that net-zero quota changes already added to the transaction are no longer deemed necessary to be synced, and skipped.

In this case references are taken for the qd and the slot from do_qc so those need to be put. The normal sequence of events for a normal non-zero quota change is as follows:

gfs2quotachange doqc qdhold slot_hold

Later, when the changes are to be synced:

gfs2quotasync qdfish qdchecksync gets qd ref via lockrefgetnotdead dosync doqc(QCSYNC) qdput lockrefputorlock qdunlock qdput lockrefputorlock

In the net-zero change case, we add a check to qdchecksync so it puts the qd and slot references acquired in gfs2quotachange and skip the unneeded sync.(CVE-2023-52759)

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

tty: vcc: Add check for kstrdup() in vcc_probe()

Add check for the return value of kstrdup() and return the error, if it fails in order to avoid NULL pointer dereference.(CVE-2023-52789)

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

ipvlan: add ipvlanroutev6_outbound() helper

Inspired by syzbot reports using a stack of multiple ipvlan devices.

Reduce stack size needed in ipvlanprocessv6outbound() by moving the flowi6 struct used for the route lookup in an non inlined helper. ipvlanroutev6outbound() needs 120 bytes on the stack, immediately reclaimed.

Also make sure ipvlanprocessv4_outbound() is not inlined.

We might also have to lower MAXNESTDEV, because only syzbot uses setups with more than four stacked devices.

BUG: TASK stack guard page was hit at ffffc9000e803ff8 (stack is ffffc9000e804000..ffffc9000e808000) stack guard page: 0000 [#1] SMP KASAN CPU: 0 PID: 13442 Comm: syz-executor.4 Not tainted 6.1.52-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023 RIP: 0010:kasancheckrange+0x4/0x2a0 mm/kasan/generic.c:188 Code: 48 01 c6 48 89 c7 e8 db 4e c1 03 31 c0 5d c3 cc 0f 0b eb 02 0f 0b b8 ea ff ff ff 5d c3 cc 00 00 cc cc 00 00 cc cc 55 48 89 e5 <41> 57 41 56 41 55 41 54 53 b0 01 48 85 f6 0f 84 a4 01 00 00 48 89 RSP: 0018:ffffc9000e804000 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817e5bf2 RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff887c6568 RBP: ffffc9000e804000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff92001d0080c R13: dffffc0000000000 R14: ffffffff87e6b100 R15: 0000000000000000 FS: 00007fd0c55826c0(0000) GS:ffff8881f6800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc9000e803ff8 CR3: 0000000170ef7000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <#DF> </#DF> <TASK> [<ffffffff81f281d1>] _kasancheckread+0x11/0x20 mm/kasan/shadow.c:31 [<ffffffff817e5bf2>] instrumentatomicread include/linux/instrumented.h:72 [inline] [<ffffffff817e5bf2>] _testbit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] [<ffffffff817e5bf2>] cpumasktestcpu include/linux/cpumask.h:506 [inline] [<ffffffff817e5bf2>] cpuonline include/linux/cpumask.h:1092 [inline] [<ffffffff817e5bf2>] tracelockacquire include/trace/events/lock.h:24 [inline] [<ffffffff817e5bf2>] lockacquire+0xe2/0x590 kernel/locking/lockdep.c:5632 [<ffffffff8563221e>] rculockacquire+0x2e/0x40 include/linux/rcupdate.h:306 [<ffffffff8561464d>] rcureadlock include/linux/rcupdate.h:747 [inline] [<ffffffff8561464d>] ip6polroute+0x15d/0x1440 net/ipv6/route.c:2221 [<ffffffff85618120>] ip6polrouteoutput+0x50/0x80 net/ipv6/route.c:2606 [<ffffffff856f65b5>] pollookupfunc include/net/ip6fib.h:584 [inline] [<ffffffff856f65b5>] fib6rulelookup+0x265/0x620 net/ipv6/fib6rules.c:116 [<ffffffff85618009>] ip6routeoutputflagsnoref+0x2d9/0x3a0 net/ipv6/route.c:2638 [<ffffffff8561821a>] ip6routeoutputflags+0xca/0x340 net/ipv6/route.c:2651 [<ffffffff838bd5a3>] ip6routeoutput include/net/ip6route.h:100 [inline] [<ffffffff838bd5a3>] ipvlanprocessv6outbound drivers/net/ipvlan/ipvlancore.c:473 [inline] [<ffffffff838bd5a3>] ipvlanprocessoutbound drivers/net/ipvlan/ipvlancore.c:529 [inline] [<ffffffff838bd5a3>] ipvlanxmitmodel3 drivers/net/ipvlan/ipvlancore.c:602 [inline] [<ffffffff838bd5a3>] ipvlanqueuexmit+0xc33/0x1be0 drivers/net/ipvlan/ipvlancore.c:677 [<ffffffff838c2909>] ipvlanstartxmit+0x49/0x100 drivers/net/ipvlan/ipvlanmain.c:229 [<ffffffff84d03900>] netdevstartxmit include/linux/netdevice.h:4966 [inline] [<ffffffff84d03900>] xmitone net/core/dev.c:3644 [inline] [<ffffffff84d03900>] devhardstartxmit+0x320/0x980 net/core/dev.c:3660 [<ffffffff84d080e2>] _devqueuexmit+0x16b2/0x3370 net/core/dev.c:4324 [<ffffffff855ce4cd>] devqueuexmit include/linux/netdevice.h:3067 [inline] [<ffffffff855ce4cd>] neighhh_output include/net/neighbour.h:529 [inline] [<f ---truncated---(CVE-2023-52796)

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

jfs: fix array-index-out-of-bounds in dbFindLeaf

Currently while searching for dmtreet for sufficient free blocks there is an array out of bounds while getting element in tp->dmstree. To add the required check for out of bound we first need to determine the type of dmtree. Thus added an extra parameter to dbFindLeaf so that the type of tree can be determined and the required check can be applied.(CVE-2023-52799)

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

iio: adc: stm32-adc: harden against NULL pointer deref in stm32adcprobe()

ofmatchdevice() may fail and returns a NULL pointer.

In practice there is no known reasonable way to trigger this, but in case one is added in future, harden the code by adding the check(CVE-2023-52802)

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

fs/jfs: Add validity check for dbmaxag and dbagpref

Both dbmaxag and dbagpref are used as the index of the dbagfree array, but there is currently no validity check for dbmaxag and db_agpref, which can lead to errors.

The following is related bug reported by Syzbot:

UBSAN: array-index-out-of-bounds in fs/jfs/jfsdmap.c:639:20 index 7936 is out of range for type 'atomict[128]'

Add checking that the values of dbmaxag and dbagpref are valid indexes for the db_agfree array.(CVE-2023-52804)

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

jfs: fix array-index-out-of-bounds in diAlloc

Currently there is not check against the agno of the iag while allocating new inodes to avoid fragmentation problem. Added the check which is required.(CVE-2023-52805)

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

scsi: libfc: Fix potential NULL pointer dereference in fclportptp_setup()

fclportptpsetup() did not check the return value of fcrportcreate() which can return NULL and would cause a NULL pointer dereference. Address this issue by checking return value of fcrportcreate() and log error message on fcrport_create() failed.(CVE-2023-52809)

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

drm/amd: Fix UBSAN array-index-out-of-bounds for Polaris and Tonga

For pptable structs that use flexible array sizes, use flexible arrays.(CVE-2023-52819)

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

cpu/hotplug: Don't offline the last non-isolated CPU

If a system has isolated CPUs via the "isolcpus=" command line parameter, then an attempt to offline the last housekeeping CPU will result in a WARNON() when rebuilding the scheduler domains and a subsequent panic due to and unhandled empty CPU mas in partitionscheddomainslocked().

cpusethotplugworkfn() rebuildscheddomainslocked() ndoms = generatescheddomains(&doms, &attr); cpumaskand(doms[0], topcpuset.effectivecpus, housekeepingcpumask(HKFLAG_DOMAIN));

Thus results in an empty CPU mask which triggers the warning and then the subsequent crash:

WARNING: CPU: 4 PID: 80 at kernel/sched/topology.c:2366 buildscheddomains+0x120c/0x1408 Call trace: buildscheddomains+0x120c/0x1408 partitionscheddomainslocked+0x234/0x880 rebuildscheddomainslocked+0x37c/0x798 rebuildscheddomains+0x30/0x58 cpusethotplugworkfn+0x2a8/0x930

Unable to handle kernel paging request at virtual address fffe80027ab37080 partitionscheddomainslocked+0x318/0x880 rebuildscheddomainslocked+0x37c/0x798

Aside of the resulting crash, it does not make any sense to offline the last last housekeeping CPU.

Prevent this by masking out the non-housekeeping CPUs when selecting a target CPU for initiating the CPU unplug operation via the work queue.(CVE-2023-52831)

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

wifi: mac80211: don't return unset power in ieee80211gettx_power()

We can get a UBSAN warning if ieee80211gettxpower() returns the INTMIN value mac80211 internally uses for "unset power level".

UBSAN: signed-integer-overflow in net/wireless/nl80211.c:3816:5 -2147483648 * 100 cannot be represented in type 'int' CPU: 0 PID: 20433 Comm: insmod Tainted: G WC OE Call Trace: dumpstack+0x74/0x92 ubsanepilogue+0x9/0x50 handleoverflow+0x8d/0xd0 _ubsanhandlemuloverflow+0xe/0x10 nl80211sendiface+0x688/0x6b0 [cfg80211] [...] cfg80211registerwdev+0x78/0xb0 [cfg80211] cfg80211netdevnotifiercall+0x200/0x620 [cfg80211] [...] ieee80211ifadd+0x60e/0x8f0 [mac80211] ieee80211registerhw+0xda5/0x1170 [mac80211]

In this case, simply return an error instead, to indicate that no data is available.(CVE-2023-52832)

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

tipc: Change nlapolicy for bearer-related names to NLANUL_STRING

syzbot reported the following uninit-value access issue [1]:

===================================================== BUG: KMSAN: uninit-value in strlen lib/string.c:418 [inline] BUG: KMSAN: uninit-value in strstr+0xb8/0x2f0 lib/string.c:756 strlen lib/string.c:418 [inline] strstr+0xb8/0x2f0 lib/string.c:756 tipcnlnoderesetlinkstats+0x3ea/0xb50 net/tipc/node.c:2595 genlfamilyrcvmsgdoit net/netlink/genetlink.c:971 [inline] genlfamilyrcvmsg net/netlink/genetlink.c:1051 [inline] genlrcvmsg+0x11ec/0x1290 net/netlink/genetlink.c:1066 netlinkrcvskb+0x371/0x650 net/netlink/afnetlink.c:2545 genlrcv+0x40/0x60 net/netlink/genetlink.c:1075 netlinkunicastkernel net/netlink/afnetlink.c:1342 [inline] netlinkunicast+0xf47/0x1250 net/netlink/afnetlink.c:1368 netlinksendmsg+0x1238/0x13d0 net/netlink/afnetlink.c:1910 socksendmsgnosec net/socket.c:730 [inline] socksendmsg net/socket.c:753 [inline] _syssendmsg+0x9c2/0xd60 net/socket.c:2541 syssendmsg+0x28d/0x3c0 net/socket.c:2595 _syssendmsg net/socket.c:2624 [inline] _dosyssendmsg net/socket.c:2633 [inline] _sesyssendmsg net/socket.c:2631 [inline] _x64syssendmsg+0x307/0x490 net/socket.c:2631 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x41/0xc0 arch/x86/entry/common.c:80 entrySYSCALL64after_hwframe+0x63/0xcd

Uninit was created at: slabpostallochook+0x12f/0xb70 mm/slab.h:767 slaballocnode mm/slub.c:3478 [inline] kmemcacheallocnode+0x577/0xa80 mm/slub.c:3523 kmallocreserve+0x13d/0x4a0 net/core/skbuff.c:559 allocskb+0x318/0x740 net/core/skbuff.c:650 allocskb include/linux/skbuff.h:1286 [inline] netlinkalloclargeskb net/netlink/afnetlink.c:1214 [inline] netlinksendmsg+0xb34/0x13d0 net/netlink/afnetlink.c:1885 socksendmsgnosec net/socket.c:730 [inline] socksendmsg net/socket.c:753 [inline] syssendmsg+0x9c2/0xd60 net/socket.c:2541 _syssendmsg+0x28d/0x3c0 net/socket.c:2595 _syssendmsg net/socket.c:2624 [inline] _dosyssendmsg net/socket.c:2633 [inline] _sesyssendmsg net/socket.c:2631 [inline] _x64syssendmsg+0x307/0x490 net/socket.c:2631 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x41/0xc0 arch/x86/entry/common.c:80 entrySYSCALL64after_hwframe+0x63/0xcd

TIPC bearer-related names including link names must be null-terminated strings. If a link name which is not null-terminated is passed through netlink, strstr() and similar functions can cause buffer overrun. This causes the above issue.

This patch changes the nlapolicy for bearer-related names from NLASTRING to NLANULSTRING. This resolves the issue by ensuring that only null-terminated strings are accepted as bearer-related names.

syzbot reported similar uninit-value issue related to bearer names [2]. The root cause of this issue is that a non-null-terminated bearer name was passed. This patch also resolved this issue.(CVE-2023-52845)

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

can: dev: canputechoskb(): don't crash kernel if canpriv::echo_skb is accessed out of bounds

If the "struct canpriv::echooskb" is accessed out of bounds, this would cause a kernel crash. Instead, issue a meaningful warning message and return with an error.(CVE-2023-52878)

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

USB: core: Fix deadlock in usbdeauthorizeinterface()

Among the attribute file callback routines in drivers/usb/core/sysfs.c, the interfaceauthorizedstore() function is the only one which acquires a device lock on an ancestor device: It calls usbdeauthorizeinterface(), which locks the interface's parent USB device.

The will lead to deadlock if another process already owns that lock and tries to remove the interface, whether through a configuration change or because the device has been disconnected. As part of the removal procedure, devicedel() waits for all ongoing sysfs attribute callbacks to complete. But usbdeauthorize_interface() can't complete until the device lock has been released, and the lock won't be released until the removal has finished.

The mechanism provided by sysfs to prevent this kind of deadlock is to use the sysfsbreakactive_protection() function, which tells sysfs not to wait for the attribute callback.

Reported-and-tested by: Yue Sun <samsun1006219@gmail.com> Reported by: xingwei lee <xrivendell7@gmail.com>(CVE-2024-26934)

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

netfilter: nftables: Fix potential data-race in _nftexprtype_get()

nftunregisterexpr() can concurrent with _nftexprtypeget(), and there is not any protection when iterate over nftablesexpressions list in _nftexprtypeget(). Therefore, there is potential data-race of nftablesexpressions list entry.

Use listforeachentryrcu() to iterate over nftablesexpressions list in _nftexprtypeget(), and use rcureadlock() in the caller nftexprtype_get() to protect the entire type query process.(CVE-2024-27020)

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

Bluetooth: l2cap: fix null-ptr-deref in l2capchantimeout

There is a race condition between l2capchantimeout() and l2capchandel(). When we use l2capchandel() to delete the channel, the chan->conn will be set to null. But the conn could be dereferenced again in the mutexlock() of l2capchan_timeout(). As a result the null pointer dereference bug will happen. The KASAN report triggered by POC is shown below:

[ 472.074580] ================================================================== [ 472.075284] BUG: KASAN: null-ptr-deref in mutexlock+0x68/0xc0 [ 472.075308] Write of size 8 at addr 0000000000000158 by task kworker/0:0/7 [ 472.075308] [ 472.075308] CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.9.0-rc5-00356-g78c0094a146b #36 [ 472.075308] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4 [ 472.075308] Workqueue: events l2capchantimeout [ 472.075308] Call Trace: [ 472.075308] <TASK> [ 472.075308] dumpstacklvl+0x137/0x1a0 [ 472.075308] printreport+0x101/0x250 [ 472.075308] ? _virtaddrvalid+0x77/0x160 [ 472.075308] ? mutexlock+0x68/0xc0 [ 472.075308] kasanreport+0x139/0x170 [ 472.075308] ? mutexlock+0x68/0xc0 [ 472.075308] kasancheckrange+0x2c3/0x2e0 [ 472.075308] mutexlock+0x68/0xc0 [ 472.075308] l2capchantimeout+0x181/0x300 [ 472.075308] processonework+0x5d2/0xe00 [ 472.075308] workerthread+0xe1d/0x1660 [ 472.075308] ? prcontwork+0x5e0/0x5e0 [ 472.075308] kthread+0x2b7/0x350 [ 472.075308] ? prcontwork+0x5e0/0x5e0 [ 472.075308] ? kthreadblkcg+0xd0/0xd0 [ 472.075308] retfromfork+0x4d/0x80 [ 472.075308] ? kthreadblkcg+0xd0/0xd0 [ 472.075308] retfromforkasm+0x11/0x20 [ 472.075308] </TASK> [ 472.075308] ================================================================== [ 472.094860] Disabling lock debugging due to kernel taint [ 472.096136] BUG: kernel NULL pointer dereference, address: 0000000000000158 [ 472.096136] #PF: supervisor write access in kernel mode [ 472.096136] #PF: errorcode(0x0002) - not-present page [ 472.096136] PGD 0 P4D 0 [ 472.096136] Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI [ 472.096136] CPU: 0 PID: 7 Comm: kworker/0:0 Tainted: G B 6.9.0-rc5-00356-g78c0094a146b #36 [ 472.096136] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4 [ 472.096136] Workqueue: events l2capchantimeout [ 472.096136] RIP: 0010:mutexlock+0x88/0xc0 [ 472.096136] Code: be 08 00 00 00 e8 f8 23 1f fd 4c 89 f7 be 08 00 00 00 e8 eb 23 1f fd 42 80 3c 23 00 74 08 48 88 [ 472.096136] RSP: 0018:ffff88800744fc78 EFLAGS: 00000246 [ 472.096136] RAX: 0000000000000000 RBX: 1ffff11000e89f8f RCX: ffffffff8457c865 [ 472.096136] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff88800744fc78 [ 472.096136] RBP: 0000000000000158 R08: ffff88800744fc7f R09: 1ffff11000e89f8f [ 472.096136] R10: dffffc0000000000 R11: ffffed1000e89f90 R12: dffffc0000000000 [ 472.096136] R13: 0000000000000158 R14: ffff88800744fc78 R15: ffff888007405a00 [ 472.096136] FS: 0000000000000000(0000) GS:ffff88806d200000(0000) knlGS:0000000000000000 [ 472.096136] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 472.096136] CR2: 0000000000000158 CR3: 000000000da32000 CR4: 00000000000006f0 [ 472.096136] Call Trace: [ 472.096136] <TASK> [ 472.096136] ? _diebody+0x8d/0xe0 [ 472.096136] ? pagefaultoops+0x6b8/0x9a0 [ 472.096136] ? kernelmodefixuporoops+0x20c/0x2a0 [ 472.096136] ? douseraddrfault+0x1027/0x1340 [ 472.096136] ? _printk+0x7a/0xa0 [ 472.096136] ? mutexlock+0x68/0xc0 [ 472.096136] ? addtaint+0x42/0xd0 [ 472.096136] ? excpagefault+0x6a/0x1b0 [ 472.096136] ? asmexcpagefault+0x26/0x30 [ 472.096136] ? mutexlock+0x75/0xc0 [ 472.096136] ? mutexlock+0x88/0xc0 [ 472.096136] ? mutexlock+0x75/0xc0 [ 472.096136] l2capchan_timeo ---truncated---(CVE-2024-27399)

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

firewire: nosy: ensure user_length is taken into account when fetching packet contents

Ensure that packetbufferget respects the userlength provided. If the length of the head packet exceeds the userlength, packetbufferget will now return 0 to signify to the user that no data were read and a larger buffer size is required. Helps prevent user space overflows.(CVE-2024-27401)

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

wifi: mac80211: check/clear fast rx for non-4addr sta VLAN changes

When moving a station out of a VLAN and deleting the VLAN afterwards, the fastrx entry still holds a pointer to the VLAN's netdev, which can cause use-after-free bugs. Fix this by immediately calling ieee80211checkfastrx after the VLAN change.(CVE-2024-35789)

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

md/dm-raid: don't call mdreapsync_thread() directly

Currently mdreapsyncthread() is called from raidmessage() directly without holding 'reconfigmutex', this is definitely unsafe because mdreapsyncthread() can change many fields that is protected by 'reconfig_mutex'.

However, hold 'reconfigmutex' here is still problematic because this will cause deadlock, for example, commit 130443d60b1b ("md: refactor idle/frozensync_thread() to fix deadlock").

Fix this problem by using stopsyncthread() to unregister sync_thread, like md/raid did.(CVE-2024-35808)

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

usb: udc: remove warning when queue disabled ep

It is possible trigger below warning message from mass storage function,

WARNING: CPU: 6 PID: 3839 at drivers/usb/gadget/udc/core.c:294 usbepqueue+0x7c/0x104 pc : usbepqueue+0x7c/0x104 lr : fsgmainthread+0x494/0x1b3c

Root cause is mass storage function try to queue request from main thread, but other thread may already disable ep when function disable.

As there is no function failure in the driver, in order to avoid effort to fix warning, change WARNONONCE() in usbepqueue() to pr_debug().(CVE-2024-35822)

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

vt: fix unicode buffer corruption when deleting characters

This is the same issue that was fixed for the VGA text buffer in commit 39cdb68c64d8 ("vt: fix memory overlapping when deleting chars in the buffer"). The cure is also the same i.e. replace memcpy() with memmove() due to the overlaping buffers.(CVE-2024-35823)

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

x86/mm/pat: fix VM_PAT handling in COW mappings

PAT handling won't do the right thing in COW mappings: the first PTE (or, in fact, all PTEs) can be replaced during write faults to point at anon folios. Reliably recovering the correct PFN and cachemode using follow_phys() from PTEs will not work in COW mappings.

Using followphys(), we might just get the address+protection of the anon folio (which is very wrong), or fail on swap/nonswap entries, failing followphys() and triggering a WARNONONCE() in untrackpfn() and trackpfncopy(), not properly calling freepfn_range().

In freepfnrange(), we either wouldn't call memtype_free() or would call it with the wrong range, possibly leaking memory.

To fix that, let's update followphys() to refuse returning anon folios, and fallback to using the stored PFN inside vma->vmpgoff for COW mappings if we run into that.

We will now properly handle untrackpfn() with COW mappings, where we don't need the cachemode. We'll have to fail fork()->trackpfn_copy() if the first page was replaced by an anon folio, though: we'd have to store the cachemode in the VMA to make this work, likely growing the VMA size.

For now, lets keep it simple and let trackpfncopy() just fail in that case: it would have failed in the past with swap/nonswap entries already, and it would have done the wrong thing with anon folios.

Simple reproducer to trigger the WARNONONCE() in untrack_pfn():

<--- C reproducer ---> #include <stdio.h> #include <sys/mman.h> #include <unistd.h> #include <liburing.h>

int main(void) { struct iouringparams p = {}; int ringfd; sizet size; char *map;

     ring_fd = io_uring_setup(1, &p);
     if (ring_fd < 0) {
             perror("io_uring_setup");
             return 1;
     }
     size = p.sq_off.array + p.sq_entries * sizeof(unsigned);

     /* Map the submission queue ring MAP_PRIVATE */
     map = mmap(0, size, PROT_READ | PROT_WRITE, MAP_PRIVATE,
                ring_fd, IORING_OFF_SQ_RING);
     if (map == MAP_FAILED) {
             perror("mmap");
             return 1;
     }

     /* We have at least one page. Let's COW it. */
     *map = 0;
     pause();
     return 0;

} <--- C reproducer --->

On a system with 16 GiB RAM and swap configured: # ./iouring & # memhog 16G # killall iouring [ 301.552930] ------------[ cut here ]------------ [ 301.553285] WARNING: CPU: 7 PID: 1402 at arch/x86/mm/pat/memtype.c:1060 untrackpfn+0xf4/0x100 [ 301.553989] Modules linked in: binfmtmisc nftfibinet nftfibipv4 nftfibipv6 nftfib nftrejectg [ 301.558232] CPU: 7 PID: 1402 Comm: iouring Not tainted 6.7.5-100.fc38.x8664 #1 [ 301.558772] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebu4 [ 301.559569] RIP: 0010:untrackpfn+0xf4/0x100 [ 301.559893] Code: 75 c4 eb cf 48 8b 43 10 8b a8 e8 00 00 00 3b 6b 28 74 b8 48 8b 7b 30 e8 ea 1a f7 000 [ 301.561189] RSP: 0018:ffffba2c0377fab8 EFLAGS: 00010282 [ 301.561590] RAX: 00000000ffffffea RBX: ffff9208c8ce9cc0 RCX: 000000010455e047 [ 301.562105] RDX: 07fffffff0eb1e0a RSI: 0000000000000000 RDI: ffff9208c391d200 [ 301.562628] RBP: 0000000000000000 R08: ffffba2c0377fab8 R09: 0000000000000000 [ 301.563145] R10: ffff9208d2292d50 R11: 0000000000000002 R12: 00007fea890e0000 [ 301.563669] R13: 0000000000000000 R14: ffffba2c0377fc08 R15: 0000000000000000 [ 301.564186] FS: 0000000000000000(0000) GS:ffff920c2fbc0000(0000) knlGS:0000000000000000 [ 301.564773] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 301.565197] CR2: 00007fea88ee8a20 CR3: 00000001033a8000 CR4: 0000000000750ef0 [ 301.565725] PKRU: 55555554 [ 301.565944] Call Trace: [ 301.566148] <TASK> [ 301.566325] ? untrackpfn+0xf4/0x100 [ 301.566618] ? _warn+0x81/0x130 [ 301.566876] ? untrackpfn+0xf4/0x100 [ 3 ---truncated---(CVE-2024-35877)

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

selinux: avoid dereference of garbage after mount failure

In case kern_mount() fails and returns an error pointer return in the error branch instead of continuing and dereferencing the error pointer.

While on it drop the never read static variable selinuxfs_mount.(CVE-2024-35904)

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

block: prevent division by zero in blkrqstat_sum()

The expression dst->nrsamples + src->nrsamples may have zero value on overflow. It is necessary to add a check to avoid division by zero.

Found by Linux Verification Center (linuxtesting.org) with Svace.(CVE-2024-35925)

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

net/mlx5: Properly link new fs rules into the tree

Previously, addrulefg would only add newly created rules from the handle into the tree when they had a refcount of 1. On the other hand, createflowhandle tries hard to find and reference already existing identical rules instead of creating new ones.

These two behaviors can result in a situation where createflowhandle 1) creates a new rule and references it, then 2) in a subsequent step during the same handle creation references it again, resulting in a rule with a refcount of 2 that is not linked into the tree, will have a NULL parent and root and will result in a crash when the flow group is deleted because delswhw_rule, invoked on rule deletion, assumes node->parent is != NULL.

This happened in the wild, due to another bug related to incorrect handling of duplicate pktreformat ids, which lead to the code in createflow_handle incorrectly referencing a just-added rule in the same flow handle, resulting in the problem described above. Full details are at [1].

This patch changes addrulefg to add new rules without parents into the tree, properly initializing them and avoiding the crash. This makes it more consistent with how rules are added to an FTE in createflowhandle.(CVE-2024-35960)

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

Bluetooth: Fix memory leak in hcireqsync_complete()

In 'hcireqsync_complete()', always free the previous sync request state before assigning reference to a new one.(CVE-2024-35978)

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

ACPI: CPPC: Use accesswidth over bitwidth for system memory accesses

To align with ACPI 6.3+, since bit_width can be any 8-bit value, it cannot be depended on to be always on a clean 8b boundary. This was uncovered on the Cobalt 100 platform.

SError Interrupt on CPU26, code 0xbe000011 -- SError CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1 Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION pstate: 62400009 (nZCv daif +PAN -UAO +TCO -DIT -SSBS BTYPE=--) pc : cppcgetperfcaps+0xec/0x410 lr : cppcgetperfcaps+0xe8/0x410 sp : ffff8000155ab730 x29: ffff8000155ab730 x28: ffff0080139d0038 x27: ffff0080139d0078 x26: 0000000000000000 x25: ffff0080139d0058 x24: 00000000ffffffff x23: ffff0080139d0298 x22: ffff0080139d0278 x21: 0000000000000000 x20: ffff00802b251910 x19: ffff0080139d0000 x18: ffffffffffffffff x17: 0000000000000000 x16: ffffdc7e111bad04 x15: ffff00802b251008 x14: ffffffffffffffff x13: ffff013f1fd63300 x12: 0000000000000006 x11: ffffdc7e128f4420 x10: 0000000000000000 x9 : ffffdc7e111badec x8 : ffff00802b251980 x7 : 0000000000000000 x6 : ffff0080139d0028 x5 : 0000000000000000 x4 : ffff0080139d0018 x3 : 00000000ffffffff x2 : 0000000000000008 x1 : ffff8000155ab7a0 x0 : 0000000000000000 Kernel panic - not syncing: Asynchronous SError Interrupt CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1 Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION Call trace: dumpbacktrace+0x0/0x1e0 showstack+0x24/0x30 dumpstacklvl+0x8c/0xb8 dumpstack+0x18/0x34 panic+0x16c/0x384 addtaint+0x0/0xc0 arm64serrorpanic+0x7c/0x90 arm64isfatalrasserror+0x34/0xa4 doserror+0x50/0x6c el1h64errorhandler+0x40/0x74 el1h64error+0x7c/0x80 cppcgetperfcaps+0xec/0x410 cppccpufreqcpuinit+0x74/0x400 [cppccpufreq] cpufreqonline+0x2dc/0xa30 cpufreqadddev+0xc0/0xd4 subsysinterfaceregister+0x134/0x14c cpufreqregisterdriver+0x1b0/0x354 cppccpufreqinit+0x1a8/0x1000 [cppccpufreq] dooneinitcall+0x50/0x250 doinitmodule+0x60/0x27c loadmodule+0x2300/0x2570 _dosysfinitmodule+0xa8/0x114 _arm64sysfinitmodule+0x2c/0x3c invokesyscall+0x78/0x100 el0svccommon.constprop.0+0x180/0x1a0 doel0svc+0x84/0xa0 el0svc+0x2c/0xc0 el0t64synchandler+0xa4/0x12c el0t64_sync+0x1a4/0x1a8

Instead, use accesswidth to determine the size and use the offset and width to shift and mask the bits to read/write out. Make sure to add a check for system memory since pcc redefines the accesswidth to subspace id.

If accesswidth is not set, then fall back to using bitwidth.

rjw: Subject and changelog edits, comment adjustments

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

i40e: Do not use WQMEMRECLAIM flag for workqueue

Issue reported by customer during SRIOV testing, call trace: When both i40e and the i40iw driver are loaded, a warning in checkflushdependency is being triggered. This seems to be because of the i40e driver workqueue is allocated with the WQMEMRECLAIM flag, and the i40iw one is not.

Similar error was encountered on ice too and it was fixed by removing the flag. Do the same for i40e too.

[Feb 9 09:08] ------------[ cut here ]------------ [ +0.000004] workqueue: WQMEMRECLAIM i40e:i40eservicetask [i40e] is flushing !WQMEMRECLAIM infiniband:0x0 [ +0.000060] WARNING: CPU: 0 PID: 937 at kernel/workqueue.c:2966 checkflushdependency+0x10b/0x120 [ +0.000007] Modules linked in: sndseqdummy sndhrtimer sndseq sndtimer sndseqdevice snd soundcore nlsutf8 cifs cifsarc4 nlsucs2utils rdmacm iwcm ibcm cifsmd4 dnsresolver netfs qrtr rfkill sunrpc vfat fat intelraplmsr intelraplcommon irdma inteluncorefrequency inteluncorefrequencycommon ice ipmissif isstifcommon skxedac nfit libnvdimm x86pkgtempthermal intelpowerclamp gnss coretemp ibuverbs rapl intelcstate ibcore iTCOwdt iTCOvendorsupport acpiipmi meime ipmisi inteluncore ioatdma i2ci801 joydev pcspkr mei ipmidevintf lpcich intelpchthermal i2csmbus ipmimsghandler acpipowermeter acpipad xfs libcrc32c ast sdmod drmshmemhelper t10pi drmkmshelper sg ixgbe drm i40e ahci crct10difpclmul libahci crc32pclmul igb crc32cintel libata ghashclmulniintel i2calgobit mdio dca wmi dmmirror dmregionhash dmlog dmmod fuse [ +0.000050] CPU: 0 PID: 937 Comm: kworker/0:3 Kdump: loaded Not tainted 6.8.0-rc2-Feb-netdev-Qiueue-00279-gbd43c5687e05 #1 [ +0.000003] Hardware name: Intel Corporation S2600BPB/S2600BPB, BIOS SE5C620.86B.02.01.0013.121520200651 12/15/2020 [ +0.000001] Workqueue: i40e i40eservicetask [i40e] [ +0.000024] RIP: 0010:checkflushdependency+0x10b/0x120 [ +0.000003] Code: ff 49 8b 54 24 18 48 8d 8b b0 00 00 00 49 89 e8 48 81 c6 b0 00 00 00 48 c7 c7 b0 97 fa 9f c6 05 8a cc 1f 02 01 e8 35 b3 fd ff <0f> 0b e9 10 ff ff ff 80 3d 78 cc 1f 02 00 75 94 e9 46 ff ff ff 90 [ +0.000002] RSP: 0018:ffffbd294976bcf8 EFLAGS: 00010282 [ +0.000002] RAX: 0000000000000000 RBX: ffff94d4c483c000 RCX: 0000000000000027 [ +0.000001] RDX: ffff94d47f620bc8 RSI: 0000000000000001 RDI: ffff94d47f620bc0 [ +0.000001] RBP: 0000000000000000 R08: 0000000000000000 R09: 00000000ffff7fff [ +0.000001] R10: ffffbd294976bb98 R11: ffffffffa0be65e8 R12: ffff94c5451ea180 [ +0.000001] R13: ffff94c5ab5e8000 R14: ffff94c5c20b6e05 R15: ffff94c5f1330ab0 [ +0.000001] FS: 0000000000000000(0000) GS:ffff94d47f600000(0000) knlGS:0000000000000000 [ +0.000002] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0.000001] CR2: 00007f9e6f1fca70 CR3: 0000000038e20004 CR4: 00000000007706f0 [ +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ +0.000001] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ +0.000001] PKRU: 55555554 [ +0.000001] Call Trace: [ +0.000001] <TASK> [ +0.000002] ? _warn+0x80/0x130 [ +0.000003] ? checkflushdependency+0x10b/0x120 [ +0.000002] ? reportbug+0x195/0x1a0 [ +0.000005] ? handlebug+0x3c/0x70 [ +0.000003] ? excinvalidop+0x14/0x70 [ +0.000002] ? asmexcinvalidop+0x16/0x20 [ +0.000006] ? checkflushdependency+0x10b/0x120 [ +0.000002] ? checkflushdependency+0x10b/0x120 [ +0.000002] _flushworkqueue+0x126/0x3f0 [ +0.000015] ibcachecleanupone+0x1c/0xe0 [ibcore] [ +0.000056] _ibunregisterdevice+0x6a/0xb0 [ibcore] [ +0.000023] ibunregisterdeviceandput+0x34/0x50 [ibcore] [ +0.000020] i40iwclose+0x4b/0x90 [irdma] [ +0.000022] i40enotifyclientofnetdevclose+0x54/0xc0 [i40e] [ +0.000035] i40eservicetask+0x126/0x190 [i40e] [ +0.000024] processonework+0x174/0x340 [ +0.000003] workerth ---truncated---(CVE-2024-36004)

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

ppdev: Add an error check in register_device

In registerdevice, the return value of idasimpleget is unchecked, in witch idasimple_get will use an invalid index value.

To address this issue, index should be checked after idasimpleget. When the index value is abnormal, a warning message should be printed, the port should be dropped, and the value should be recorded.(CVE-2024-36015)

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

pinctrl: core: delete incorrect free in pinctrl_enable()

The "pctldev" struct is allocated in devmpinctrlregisterandinit(). It's a devm_ managed pointer that is freed by devmpinctrldevrelease(), so freeing it in pinctrlenable() will lead to a double free.

The devmpinctrldev_release() function frees the pindescs and destroys the mutex as well.(CVE-2024-36940)