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

ASoC: amd: acp-mach-common: Add missing error check for clock acquisition

The acpcardrt5682init() and acpcardrt5682sinit() functions did not check the return values of clkget(). This could lead to a kernel crash when the invalid pointers are later dereferenced by clock core functions.

Fix this by: 1. Changing clkget() to the device-managed devmclkget(). 2. Adding ISERR() checks immediately after each clock acquisition.

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

x86/vmscape: Add conditional IBPB mitigation

VMSCAPE is a vulnerability that exploits insufficient branch predictor isolation between a guest and a userspace hypervisor (like QEMU). Existing mitigations already protect kernel/KVM from a malicious guest. Userspace can additionally be protected by flushing the branch predictors after a VMexit.

Since it is the userspace that consumes the poisoned branch predictors, conditionally issue an IBPB after a VMexit and before returning to userspace. Workloads that frequently switch between hypervisor and userspace will incur the most overhead from the new IBPB.

This new IBPB is not integrated with the existing IBPB sites. For instance, a task can use the existing speculation control prctl() to get an IBPB at context switch time. With this implementation, the IBPB is doubled up: one at context switch and another before running userspace.

The intent is to integrate and optimize these cases post-embargo.

[ dhansen: elaborate on suboptimal IBPB solution ]

cgroup: split cgroupdestroywq into 3 workqueues

block: avoid possible overflow for chunksectors check in blkstacklimits()

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

x86/mm/64: define ARCHPAGETABLESYNCMASK and archsynckernelmappings()

Define ARCHPAGETABLESYNCMASK and archsynckernelmappings() to ensure page tables are properly synchronized when calling pdpopulatekernel().

For 5-level paging, synchronization is performed via pgdpopulatekernel(). In 4-level paging, pgdpopulate() is a no-op, so synchronization is instead performed at the P4D level via p4dpopulatekernel().

This fixes intermittent boot failures on systems using 4-level paging and a large amount of persistent memory:

BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:initsinglepage+0x9/0x6d Call Trace: <TASK> initzonedevicepage+0x17/0x5d memmapinitzonedevice+0x154/0x1bb pagemaprange+0x2e0/0x40f memremappages+0x10b/0x2f0 devmmemremappages+0x1e/0x60 devdaxprobe+0xce/0x2ec [devicedax] daxbusprobe+0x6d/0xc9 [... snip ...] </TASK>

It also fixes a crash in vmemmapsetpmd() caused by accessing vmemmap before syncglobalpgds() [1]:

BUG: unable to handle page fault for address: ffffeb3ff1200000 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 0 P4D 0 Oops: Oops: 0002 [#1] PREEMPT SMP NOPTI Tainted: [W]=WARN RIP: 0010:vmemmapsetpmd+0xff/0x230 <TASK> vmemmappopulatehugepages+0x176/0x180 vmemmappopulate+0x34/0x80 populatesectionmemmap+0x41/0x90 sparseaddsection+0x121/0x3e0 addpages+0xba/0x150 addpages+0x1d/0x70 memremappages+0x3dc/0x810 devmmemremappages+0x1c/0x60 xedevmadd+0x8b/0x100 [xe] xetileinitnoalloc+0x6a/0x70 [xe] xedeviceprobe+0x48c/0x740 [xe] [... snip ...]

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

net: bridge: fix soft lockup in brmulticastqueryexpired()

When set multicastqueryinterval to a large value, the local variable 'time' in brmulticastsendquery() may overflow. If the time is smaller than jiffies, the timer will expire immediately, and then call modtimer() again, which creates a loop and may trigger the following soft lockup issue.

watchdog: BUG: soft lockup - CPU#1 stuck for 221s! [rbconsumer:66] CPU: 1 UID: 0 PID: 66 Comm: rbconsumer Not tainted 6.16.0+ #259 PREEMPT(none) Call Trace: <IRQ> netdevallocskb+0x2e/0x3a0 brip6multicastallocquery+0x212/0x1b70 brmulticastsendquery+0x376/0xac0 brmulticastsendquery+0x299/0x510 brmulticastqueryexpired.constprop.0+0x16d/0x1b0 calltimerfn+0x3b/0x2a0 runtimers+0x619/0x950 runtimersoftirq+0x11c/0x220 handlesoftirqs+0x18e/0x560 irqexitrcu+0x158/0x1a0 sysvecapictimerinterrupt+0x76/0x90 </IRQ>

This issue can be reproduced with: ip link add br0 type bridge echo 1 > /sys/class/net/br0/bridge/multicastquerier echo 0xffffffffffffffff > /sys/class/net/br0/bridge/multicastqueryinterval ip link set dev br0 up

The multicaststartupqueryinterval can also cause this issue. Similar to the commit 99b40610956a ("net: bridge: mcast: add and enforce query interval minimum"), add check for the query interval maximum to fix this issue.

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

jbd2: prevent softlockup in jbd2logdocheckpoint()

Both jbd2logdocheckpoint() and jbd2journalshrinkcheckpointlist() periodically release jlistlock after processing a batch of buffers to avoid long hold times on the jlistlock. However, since both functions contend for jlistlock, the combined time spent waiting and processing can be significant.

jbd2journalshrinkcheckpointlist() explicitly calls condresched() when needresched() is true to avoid softlockups during prolonged operations. But jbd2logdocheckpoint() only exits its loop when needresched() is true, relying on potentially sleeping functions like flushbatch() or waitonbuffer() to trigger rescheduling. If those functions do not sleep, the kernel may hit a softlockup.

watchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373] CPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10 Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017 Workqueue: writeback wbworkfn (flush-7:2) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : nativequeuedspinlockslowpath+0x358/0x418 lr : jbd2logdocheckpoint+0x31c/0x438 [jbd2] Call trace: nativequeuedspinlockslowpath+0x358/0x418 jbd2logdocheckpoint+0x31c/0x438 [jbd2] jbd2logwaitforspace+0xfc/0x2f8 [jbd2] addtransactioncredits+0x3bc/0x418 [jbd2] startthishandle+0xf8/0x560 [jbd2] jbd2journalstart+0x118/0x228 [jbd2] ext4journalstartsb+0x110/0x188 [ext4] ext4dowritepages+0x3dc/0x740 [ext4] ext4writepages+0xa4/0x190 [ext4] dowritepages+0x94/0x228 writebacksingleinode+0x48/0x318 writebacksbinodes+0x204/0x590 writebackinodeswb+0x54/0xf8 wbwriteback+0x2cc/0x3d8 wbdowriteback+0x2e0/0x2f8 wbworkfn+0x80/0x2a8 processonework+0x178/0x3e8 workerthread+0x234/0x3b8 kthread+0xf0/0x108 retfromfork+0x10/0x20

So explicitly call condresched() in jbd2logdocheckpoint() to avoid softlockup.

fs: Prevent file descriptor table allocations exceeding INTMAX

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

x86/cpu/hygon: Add missing resctrlcpudetect() in bspinit helper

Since

923f3a2b48bd ("x86/resctrl: Query LLC monitoring properties once during boot")

resctrlcpudetect() has been moved from common CPU initialization code to the vendor-specific BSP init helper, while Hygon didn't put that call in their code.

This triggers a division by zero fault during early booting stage on our machines with X86FEATURECQM supported, where getrdtmonresources() tries to calculate monl3config with uninitialized bootcpudata.x86cacheoccscale.

Add the missing resctrlcpudetect() in the Hygon BSP init helper.

[ bp: Massage commit message. ]

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

net: usb: asixdevices: add phymask for ax88772 mdio bus

Without setting phymask for ax88772 mdio bus, current driver may create at most 32 mdio phy devices with phy address range from 0x00 ~ 0x1f. DLink DUB-E100 H/W Ver B1 is such a device. However, only one main phy device will bind to net phy driver. This is creating issue during system suspend/resume since phypollingmode() in phystatemachine() will directly deference member of phydev->drv for non-main phy devices. Then NULL pointer dereference issue will occur. Due to only external phy or internal phy is necessary, add phymask for ax88772 mdio bus to workarnoud the issue.

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

netfilter: ctnetlink: fix refcount leak on table dump

There is a reference count leak in ctnetlinkdumptable(): if (res < 0) { nfconntrackget(&ct->ctgeneral); // HERE cb->args[1] = (unsigned long)ct; ...

While its very unlikely, its possible that ct == last. If this happens, then the refcount of ct was already incremented. This 2nd increment is never undone.

This prevents the conntrack object from being released, which in turn keeps prevents cnet->count from dropping back to 0.

This will then block the netns dismantle (or conntrack rmmod) as nfconntrackcleanupnetlist() will wait forever.

This can be reproduced by running conntrackresize.sh selftest in a loop. It takes ~20 minutes for me on a preemptible kernel on average before I see a runaway kworker spinning in nfconntrackcleanupnetlist.

One fix would to change this to: if (res < 0) { if (ct != last) nfconntrackget(&ct->ctgeneral);

But this reference counting isn't needed in the first place. We can just store a cookie value instead.

A followup patch will do the same for ctnetlinkexpdumptable, it looks to me as if this has the same problem and like ctnetlinkdumptable, we only need a 'skip hint', not the actual object so we can apply the same cookie strategy there as well.

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

mm/ptdump: take the memory hotplug lock inside ptdumpwalkpgd()

Memory hot remove unmaps and tears down various kernel page table regions as required. The ptdump code can race with concurrent modifications of the kernel page tables. When leaf entries are modified concurrently, the dump code may log stale or inconsistent information for a VA range, but this is otherwise not harmful.

But when intermediate levels of kernel page table are freed, the dump code will continue to use memory that has been freed and potentially reallocated for another purpose. In such cases, the ptdump code may dereference bogus addresses, leading to a number of potential problems.

To avoid the above mentioned race condition, platforms such as arm64, riscv and s390 take memory hotplug lock, while dumping kernel page table via the sysfs interface /sys/kernel/debug/kernelpagetables.

Similar race condition exists while checking for pages that might have been marked W+X via /sys/kernel/debug/kernelpagetables/checkwxpages which in turn calls ptdumpcheckwx(). Instead of solving this race condition again, let's just move the memory hotplug lock inside generic ptdumpcheckwx() which will benefit both the scenarios.

Drop getonlinemems() and putonlinemems() combination from all existing platform ptdump code paths.

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

net: lan743x: Fix memleak issue when GSO enabled

Always map the skb to the LS descriptor. Previously skb was mapped to EXT descriptor when the number of fragments is zero with GSO enabled. Mapping the skb to EXT descriptor prevents it from being freed, leading to a memory leak

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

thermal: int340x: Add NULL check for adev

Not all devices have an ACPI companion fwnode, so adev might be NULL. This is similar to the commit cd2fd6eab480 ("platform/x86: int3472: Check for adev == NULL").

Add a check for adev not being set and return -ENODEV in that case to avoid a possible NULL pointer deref in int3402thermalprobe().

Note, under the same directory, int3400thermalprobe() has such a check.

[ rjw: Subject edit, added Fixes: ]

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

net: Fix null-ptr-deref by socklockinitclassandname() and rmmod.

When I ran the repro [0] and waited a few seconds, I observed two LOCKDEP splats: a warning immediately followed by a null-ptr-deref. [1]

Reproduction Steps:

1) Mount CIFS 2) Add an iptables rule to drop incoming FIN packets for CIFS 3) Unmount CIFS 4) Unload the CIFS module 5) Remove the iptables rule

At step 3), the CIFS module calls sockrelease() for the underlying TCP socket, and it returns quickly. However, the socket remains in FINWAIT1 because incoming FIN packets are dropped.

At this point, the module's refcnt is 0 while the socket is still alive, so the following rmmod command succeeds.

# ss -tan State Recv-Q Send-Q Local Address:Port Peer Address:Port FIN-WAIT-1 0 477 10.0.2.15:51062 10.0.0.137:445

# lsmod | grep cifs cifs 1159168 0

This highlights a discrepancy between the lifetime of the CIFS module and the underlying TCP socket. Even after CIFS calls sockrelease() and it returns, the TCP socket does not die immediately in order to close the connection gracefully.

While this is generally fine, it causes an issue with LOCKDEP because CIFS assigns a different lock class to the TCP socket's sk->sklock using socklockinitclassandname().

Once an incoming packet is processed for the socket or a timer fires, sk->sklock is acquired.

Then, LOCKDEP checks the lock context in checkwaitcontext(), where hlockclass() is called to retrieve the lock class. However, since the module has already been unloaded, hlockclass() logs a warning and returns NULL, triggering the null-ptr-deref.

If LOCKDEP is enabled, we must ensure that a module calling socklockinitclassandname() (CIFS, NFS, etc) cannot be unloaded while such a socket is still alive to prevent this issue.

Let's hold the module reference in socklockinitclassandname() and release it when the socket is freed in skprotfree().

Note that socklockinit() clears sk->skowner for svccreatesocket() that calls socklockinitclassandname() for a listening socket, which clones a socket by skclonelock() without GFPZERO.

[0]: CIFSSERVER="10.0.0.137" CIFSPATH="//${CIFSSERVER}/Users/Administrator/Desktop/CIFSTEST" DEV="enp0s3" CRED="/root/WindowsCredential.txt"

MNT=$(mktemp -d /tmp/XXXXXX) mount -t cifs ${CIFSPATH} ${MNT} -o vers=3.0,credentials=${CRED},cache=none,echointerval=1

iptables -A INPUT -s ${CIFSSERVER} -j DROP

for i in $(seq 10); do umount ${MNT} rmmod cifs sleep 1 done

rm -r ${MNT}

iptables -D INPUT -s ${CIFSSERVER} -j DROP

[1]: DEBUGLOCKSWARNON(1) WARNING: CPU: 10 PID: 0 at kernel/locking/lockdep.c:234 hlockclass (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223) Modules linked in: cifsarc4 nlsucs2utils cifsmd4 [last unloaded: cifs] CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Not tainted 6.14.0 #36 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:hlockclass (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223) ... Call Trace: <IRQ> lockacquire (kernel/locking/lockdep.c:4853 kernel/locking/lockdep.c:5178) lockacquire (kernel/locking/lockdep.c:469 kernel/locking/lockdep.c:5853 kernel/locking/lockdep.c:5816) rawspinlocknested (kernel/locking/spinlock.c:379) tcpv4rcv (./include/linux/skbuff.h:1678 ./include/net/tcp.h:2547 net/ipv4/tcpipv4.c:2350) ...

BUG: kernel NULL pointer dereference, address: 00000000000000c4 PF: supervisor read access in kernel mode PF: errorcode(0x0000) - not-present page PGD 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Tainted: G W 6.14.0 #36 Tainted: [W]=WARN Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:lockacquire (kernel/ ---truncated---

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

net: mvpp2: Prevent parser TCAM memory corruption

Protect the parser TCAM/SRAM memory, and the cached (shadow) SRAM information, from concurrent modifications.

Both the TCAM and SRAM tables are indirectly accessed by configuring an index register that selects the row to read or write to. This means that operations must be atomic in order to, e.g., avoid spreading writes across multiple rows. Since the shadow SRAM array is used to find free rows in the hardware table, it must also be protected in order to avoid TOCTOU errors where multiple cores allocate the same row.

This issue was detected in a situation where mvpp2setrxmode() ran concurrently on two CPUs. In this particular case the MVPP2PEMACUCPROMISCUOUS entry was corrupted, causing the classifier unit to drop all incoming unicast - indicated by the rxclassifierdrops counter.

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

ipv6: Fix memleak of nhcpcpurthoutput in fibchecknhv6gw().

fibchecknhv6gw() expects that fib6nhinit() cleans up everything when it fails.

Commit 7dd73168e273 ("ipv6: Always allocate pcpu memory in a fib6nh") moved fibnhcommoninit() before allocpercpugfp() within fib6nhinit() but forgot to add cleanup for fib6nh->nhcommon.nhcpcpurthoutput in case it fails to allocate fib6nh->rt6ipcpu, resulting in memleak.

Let's call fibnhcommonrelease() and clear nhcpcpurthoutput in the error path.

Note that we can remove the fib6nhrelease() call in nhcreateipv6() later in net-next.git.

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

llc: do not use skbget() before devqueuexmit()

syzbot is able to crash hosts [1], using llc and devices not supporting IFFTXSKBSHARING.

In this case, e1000 driver calls ethskbpad(), while the skb is shared.

Simply replace skbget() by skbclone() in net/llc/llcsac.c

Note that e1000 driver might have an issue with pktgen, because it does not clear IFFTXSKBSHARING, this is an orthogonal change.

We need to audit other skbget() uses in net/llc.

[1]

kernel BUG at net/core/skbuff.c:2178 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 UID: 0 PID: 16371 Comm: syz.2.2764 Not tainted 6.14.0-rc4-syzkaller-00052-gac9c34d1e45a #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:pskbexpandhead+0x6ce/0x1240 net/core/skbuff.c:2178 Call Trace: <TASK> skbpad+0x18a/0x610 net/core/skbuff.c:2466 skbputpadto include/linux/skbuff.h:3843 [inline] skbputpadto include/linux/skbuff.h:3862 [inline] ethskbpad include/linux/etherdevice.h:656 [inline] e1000xmitframe+0x2d99/0x5800 drivers/net/ethernet/intel/e1000/e1000main.c:3128 netdevstartxmit include/linux/netdevice.h:5151 [inline] netdevstartxmit include/linux/netdevice.h:5160 [inline] xmitone net/core/dev.c:3806 [inline] devhardstartxmit+0x9a/0x7b0 net/core/dev.c:3822 schdirectxmit+0x1ae/0xc30 net/sched/schgeneric.c:343 devxmitskb net/core/dev.c:4045 [inline] devqueuexmit+0x13d4/0x43e0 net/core/dev.c:4621 devqueuexmit include/linux/netdevice.h:3313 [inline] llcsapactionsendtestc+0x268/0x320 net/llc/llcsac.c:144 llcexecsaptransactions net/llc/llcsap.c:153 [inline] llcsapnextstate net/llc/llcsap.c:182 [inline] llcsapstateprocess+0x239/0x510 net/llc/llcsap.c:209 llcuisendmsg+0xd0d/0x14e0 net/llc/afllc.c:993 socksendmsgnosec net/socket.c:718 [inline]

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

usb: gadget: fmidi: fix MIDI Streaming descriptor lengths

While the MIDI jacks are configured correctly, and the MIDIStreaming endpoint descriptors are filled with the correct information, bNumEmbMIDIJack and bLength are set incorrectly in these descriptors.

This does not matter when the numbers of in and out ports are equal, but when they differ the host will receive broken descriptors with uninitialized stack memory leaking into the descriptor for whichever value is smaller.

The precise meaning of "in" and "out" in the port counts is not clearly defined and can be confusing. But elsewhere the driver consistently uses this to match the USB meaning of IN and OUT viewed from the host, so that "in" ports send data to the host and "out" ports receive data from it.

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

net: hns3: fix oops when unload drivers paralleling

When unload hclge driver, it tries to disable sriov first for each aedev node from hnae3aedevlist. If user unloads hns3 driver at the time, because it removes all the aedev nodes, and it may cause oops.

But we can't simply use hnae3commonlock for this. Because in the process flow of pcidisablesriov(), it will trigger the remove flow of VF, which will also take hnae3commonlock.

To fixes it, introduce a new mutex to protect the unload process.

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

net: let net.core.devweight always be non-zero

The following problem was encountered during stability test:

(NULL netdevice): NAPI poll function processbacklog+0x0/0x530 \ returned 1, exceeding its budget of 0. ------------[ cut here ]------------ listadd double add: new=ffff88905f746f48, prev=ffff88905f746f48, \ next=ffff88905f746e40. WARNING: CPU: 18 PID: 5462 at lib/listdebug.c:35 \ listaddvalidorreport+0xf3/0x130 CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+ RIP: 0010:listaddvalidorreport+0xf3/0x130 Call Trace: ? warn+0xcd/0x250 ? listaddvalidorreport+0xf3/0x130 enqueuetobacklog+0x923/0x1070 netifrxinternal+0x92/0x2b0 netifrx+0x15/0x170 loopbackxmit+0x2ef/0x450 devhardstartxmit+0x103/0x490 devqueuexmit+0xeac/0x1950 ipfinishoutput2+0x6cc/0x1620 ipoutput+0x161/0x270 ippushpendingframes+0x155/0x1a0 rawsendmsg+0xe13/0x1550 syssendto+0x3bf/0x4e0 x64syssendto+0xdc/0x1b0 dosyscall64+0x5b/0x170 entrySYSCALL64afterhwframe+0x76/0x7e

The reproduction command is as follows: sysctl -w net.core.devweight=0 ping 127.0.0.1

This is because when the napi's weight is set to 0, processbacklog() may return 0 and clear the NAPISTATESCHED bit of napi->state, causing this napi to be re-polled in netrxaction() until dosoftirq() times out. Since the NAPISTATESCHED bit has been cleared, napischedulerps() can be retriggered in enqueuetobacklog(), causing this issue.

Making the napi's weight always non-zero solves this problem.

Triggering this issue requires system-wide admin (setting is not namespaced).

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

clocksource: Use migratedisable() to avoid calling getrandomu32() in atomic context

The following bug report happened with a PREEMPTRT kernel:

BUG: sleeping function called from invalid context at kernel/locking/spinlockrt.c:48 inatomic(): 1, irqsdisabled(): 0, nonblock: 0, pid: 2012, name: kwatchdog preemptcount: 1, expected: 0 RCU nest depth: 0, expected: 0 getrandomu32+0x4f/0x110 clocksourceverifychoosecpus+0xab/0x1a0 clocksourceverifypercpu.part.0+0x6b/0x330 clocksourcewatchdogkthread+0x193/0x1a0

It is due to the fact that clocksourceverifychoosecpus() is invoked with preemption disabled. This function invokes getrandomu32() to obtain random numbers for choosing CPUs. The batchedentropy32 local lock and/or the basecrng.lock spinlock in driver/char/random.c will be acquired during the call. In PREEMPTRT kernel, they are both sleeping locks and so cannot be acquired in atomic context.

Fix this problem by using migratedisable() to allow smpprocessorid() to be reliably used without introducing atomic context. preemptdisable() is then called after clocksourceverifychoosecpus() but before the clocksource measurement is being run to avoid introducing unexpected latency.

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

bpf: Send signals asynchronously if !preemptible

BPF programs can execute in all kinds of contexts and when a program running in a non-preemptible context uses the bpfsendsignal() kfunc, it will cause issues because this kfunc can sleep. Change irqsdisabled() to !preemptible().

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

net: usb: rtl8150: enable basic endpoint checking

Syzkaller reports [1] encountering a common issue of utilizing a wrong usb endpoint type during URB submitting stage. This, in turn, triggers a warning shown below.

For now, enable simple endpoint checking (specifically, bulk and interrupt eps, testing control one is not essential) to mitigate the issue with a view to do other related cosmetic changes later, if they are necessary.

[1] Syzkaller report: usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 1 PID: 2586 at drivers/usb/core/urb.c:503 usbsubmiturb+0xe4b/0x1730 driv> Modules linked in: CPU: 1 UID: 0 PID: 2586 Comm: dhcpcd Not tainted 6.11.0-rc4-syzkaller-00069-gfc88bb11617> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:usbsubmiturb+0xe4b/0x1730 drivers/usb/core/urb.c:503 Code: 84 3c 02 00 00 e8 05 e4 fc fc 4c 89 ef e8 fd 25 d7 fe 45 89 e0 89 e9 4c 89 f2 48 8> RSP: 0018:ffffc9000441f740 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff888112487a00 RCX: ffffffff811a99a9 RDX: ffff88810df6ba80 RSI: ffffffff811a99b6 RDI: 0000000000000001 RBP: 0000000000000003 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001 R13: ffff8881023bf0a8 R14: ffff888112452a20 R15: ffff888112487a7c FS: 00007fc04eea5740(0000) GS:ffff8881f6300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f0a1de9f870 CR3: 000000010dbd0000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> rtl8150open+0x300/0xe30 drivers/net/usb/rtl8150.c:733 devopen+0x2d4/0x4e0 net/core/dev.c:1474 devchangeflags+0x561/0x720 net/core/dev.c:8838 devchangeflags+0x8f/0x160 net/core/dev.c:8910 devinetioctl+0x127a/0x1f10 net/ipv4/devinet.c:1177 inetioctl+0x3aa/0x3f0 net/ipv4/afinet.c:1003 sockdoioctl+0x116/0x280 net/socket.c:1222 sockioctl+0x22e/0x6c0 net/socket.c:1341 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:907 [inline] sesysioctl fs/ioctl.c:893 [inline] x64sysioctl+0x193/0x220 fs/ioctl.c:893 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x250 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7fc04ef73d49 ...

This change has not been tested on real hardware.

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

netfilter: conntrack: clamp maximum hashtable size to INTMAX

Use INTMAX as maximum size for the conntrack hashtable. Otherwise, it is possible to hit WARNONONCE in kvmallocnodenoprof() when resizing hashtable because GFPNOWARN is unset. See:

0708a0afe291 ("mm: Consider GFPNOWARN flag for oversized kvmalloc() calls")

Note: hashtable resize is only possible from initnetns.

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

tomoyo: don't emit warning in tomoyowritecontrol()

syzbot is reporting too large allocation warning at tomoyowritecontrol(), for one can write a very very long line without new line character. To fix this warning, I use GFPNOWARN rather than checking for KMALLOCMAXSIZE, for practically a valid line should be always shorter than 32KB where the "too small to fail" memory-allocation rule applies.

One might try to write a valid line that is longer than 32KB, but such request will likely fail with -ENOMEM. Therefore, I feel that separately returning -EINVAL when a line is longer than KMALLOCMAXSIZE is redundant. There is no need to distinguish over-32KB and over-KMALLOCMAXSIZE.

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

team: prevent adding a device which is already a team device lower

Prevent adding a device which is already a team device lower, e.g. adding veth0 if vlan1 was already added and veth0 is a lower of vlan1.

This is not useful in practice and can lead to recursive locking:

$ ip link add veth0 type veth peer name veth1 $ ip link set veth0 up $ ip link set veth1 up $ ip link add link veth0 name veth0.1 type vlan protocol 802.1Q id 1 $ ip link add team0 type team $ ip link set veth0.1 down $ ip link set veth0.1 master team0 team0: Port device veth0.1 added $ ip link set veth0 down $ ip link set veth0 master team0

============================================ WARNING: possible recursive locking detected 6.13.0-rc2-virtme-00441-ga14a429069bb #46 Not tainted -------------------------------------------- ip/7684 is trying to acquire lock: ffff888016848e00 (team->teamlockkey){+.+.}-{4:4}, at: teamdeviceevent (drivers/net/team/teamcore.c:2928 drivers/net/team/teamcore.c:2951 drivers/net/team/teamcore.c:2973)

but task is already holding lock: ffff888016848e00 (team->teamlockkey){+.+.}-{4:4}, at: teamaddslave (drivers/net/team/teamcore.c:1147 drivers/net/team/teamcore.c:1977)

other info that might help us debug this: Possible unsafe locking scenario:

CPU0 ---- lock(team->teamlockkey); lock(team->teamlockkey);

DEADLOCK

May be due to missing lock nesting notation

2 locks held by ip/7684:

stack backtrace: CPU: 3 UID: 0 PID: 7684 Comm: ip Not tainted 6.13.0-rc2-virtme-00441-ga14a429069bb #46 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dumpstacklvl (lib/dumpstack.c:122) printdeadlockbug.cold (kernel/locking/lockdep.c:3040) lockacquire (kernel/locking/lockdep.c:3893 kernel/locking/lockdep.c:5226) ? netlinkbroadcastfiltered (net/netlink/afnetlink.c:1548) lockacquire.part.0 (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851) ? teamdeviceevent (drivers/net/team/teamcore.c:2928 drivers/net/team/teamcore.c:2951 drivers/net/team/teamcore.c:2973) ? tracelockacquire (./include/trace/events/lock.h:24 (discriminator 2)) ? teamdeviceevent (drivers/net/team/teamcore.c:2928 drivers/net/team/teamcore.c:2951 drivers/net/team/teamcore.c:2973) ? lockacquire (kernel/locking/lockdep.c:5822) ? teamdeviceevent (drivers/net/team/teamcore.c:2928 drivers/net/team/teamcore.c:2951 drivers/net/team/teamcore.c:2973) mutexlock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:735) ? teamdeviceevent (drivers/net/team/teamcore.c:2928 drivers/net/team/teamcore.c:2951 drivers/net/team/teamcore.c:2973) ? teamdeviceevent (drivers/net/team/teamcore.c:2928 drivers/net/team/teamcore.c:2951 drivers/net/team/teamcore.c:2973) ? fibsyncup (net/ipv4/fibsemantics.c:2167) ? teamdeviceevent (drivers/net/team/teamcore.c:2928 drivers/net/team/teamcore.c:2951 drivers/net/team/teamcore.c:2973) teamdeviceevent (drivers/net/team/teamcore.c:2928 drivers/net/team/teamcore.c:2951 drivers/net/team/teamcore.c:2973) notifiercallchain (kernel/notifier.c:85) callnetdevicenotifiersinfo (net/core/dev.c:1996) devnotifyflags (net/core/dev.c:8993) ? devchangeflags (net/core/dev.c:8975) devchangeflags (net/core/dev.c:9027) vlandeviceevent (net/8021q/vlan.c:85 net/8021q/vlan.c:470) ? brdeviceevent (net/bridge/br.c:143) notifiercallchain (kernel/notifier.c:85) callnetdevicenotifiersinfo (net/core/dev.c:1996) devopen (net/core/dev.c:1519 net/core/dev.c:1505) teamaddslave (drivers/net/team/teamcore.c:1219 drivers/net/team/teamcore.c:1977) ? pfxteamaddslave (drivers/net/team/teamcore.c:1972) dosetmaster (net/core/rtnetlink.c:2917) dosetlink.isra.0 (net/core/rtnetlink.c:3117)

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

ipmi: ipmb: Add check devmkasprintf() returned value

devmkasprintf() can return a NULL pointer on failure but this returned value is not checked.

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

wifi: rtlwifi: fix memory leaks and invalid access at probe error path

Deinitialize at reverse order when probe fails.

When initswvars fails, rtldeinitcore should not be called, specially now that it destroys the rtlwq workqueue.

And call rtlpcideinit and deinitswvars, otherwise, memory will be leaked.

Remove pcisetdrvdata call as it will already be cleaned up by the core driver code and could lead to memory leaks too. cf. commit 8d450935ae7f ("wireless: rtlwifi: remove unnecessary pcisetdrvdata()") and commit 3d86b93064c7 ("rtlwifi: Fix PCI probe error path orphaned memory").

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

ubifs: skip dumping tnc tree when zroot is null

Clearing slab cache will free all znode in memory and make c->zroot.znode = NULL, then dumping tnc tree will access c->zroot.znode which cause null pointer dereference.