In the Linux kernel, the following vulnerability has been resolved:
platform/x86/amd/pmc: Only disable IRQ1 wakeup where i8042 actually enabled it
Wakeup for IRQ1 should be disabled only in cases where i8042 had actually enabled it, otherwise "wakedepth" for this IRQ will try to drop below zero and there will be an unpleasant WARN() logged:
kernel: atkbd serio0: Disabling IRQ1 wakeup source to avoid platform firmware bug kernel: ------------[ cut here ]------------ kernel: Unbalanced IRQ 1 wake disable kernel: WARNING: CPU: 10 PID: 6431 at kernel/irq/manage.c:920 irqsetirqwake+0x147/0x1a0
The PMC driver uses DEFINESIMPLEDEVPMOPS() to define its devpmops which sets amdpmcsuspendhandler() to the .suspend, .freeze, and .poweroff handlers. i8042pmsuspend(), however, is only set as the .suspend handler.
Fix the issue by call PMC suspend handler only from the same set of devpmops handlers as i8042pmsuspend(), which currently means just the .suspend handler.
To reproduce this issue try hibernating (S4) the machine after a fresh boot without putting it into s2idle first.
[ij: edited the commit message.]
In the Linux kernel, the following vulnerability has been resolved:
scsi: sg: Fix slab-use-after-free read in sgrelease()
Fix a use-after-free bug in sgrelease(), detected by syzbot with KASAN:
BUG: KASAN: slab-use-after-free in lockrelease+0x151/0xa30 kernel/locking/lockdep.c:5838 mutexunlockslowpath+0xe2/0x750 kernel/locking/mutex.c:912 sgrelease+0x1f4/0x2e0 drivers/scsi/sg.c:407
In sgrelease(), the function krefput(&sfp->fref, sgremovesfp) is called before releasing the openrellock mutex. The krefput() call may decrement the reference count of sfp to zero, triggering its cleanup through sgremovesfp(). This cleanup includes scheduling deferred work via sgremovesfpusercontext(), which ultimately frees sfp.
After krefput(), sgrelease() continues to unlock openrellock and may reference sfp or sdp. If sfp has already been freed, this results in a slab-use-after-free error.
Move the krefput(&sfp->fref, sgremovesfp) call after unlocking the openrellock mutex. This ensures:
- No references to sfp or sdp occur after the reference count is decremented.
- Cleanup functions such as sgremovesfp() and sgremovesfpusercontext() can safely execute without impacting the mutex handling in sgrelease().
The fix has been tested and validated by syzbot. This patch closes the bug reported at the following syzkaller link and ensures proper sequencing of resource cleanup and mutex operations, eliminating the risk of use-after-free errors in sgrelease().
fs: relax assertions on failure to encode file handles
In the Linux kernel, the following vulnerability has been resolved:
net: fec: handle pagepooldevallocpages error
The fecenetupdatecbd function calls pagepooldevallocpages but did not handle the case when it returned NULL. There was a WARNON(!newpage) but it would still proceed to use the NULL pointer and then crash.
This case does seem somewhat rare but when the system is under memory pressure it can happen. One case where I can duplicate this with some frequency is when writing over a smbd share to a SATA HDD attached to an imx6q.
Setting /proc/sys/vm/minfreekbytes to higher values also seems to solve the problem for my test case. But it still seems wrong that the fec driver ignores the memory allocation error and can crash.
This commit handles the allocation error by dropping the current packet.
eth: bnxt: always recalculate features after XDP clearing, fix null-deref
In the Linux kernel, the following vulnerability has been resolved:
iouring/eventfd: ensure ioeventfdsignal() defers another RCU period
ioeventfddosignal() is invoked from an RCU callback, but when dropping the reference to the ioevfd, it calls ioeventfdfree() directly if the refcount drops to zero. This isn't correct, as any potential freeing of the ioevfd should be deferred another RCU grace period.
Just call ioeventfdput() rather than open-code the dec-and-test and free, which will correctly defer it another RCU grace period.
In the Linux kernel, the following vulnerability has been resolved:
net: stmmac: fix TSO DMA API usage causing oops
Commit 66600fac7a98 ("net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data") moved the assignment of txskbuffdma[]'s members to be later in stmmactsoxmit().
The buf (dma cookie) and len stored in this structure are passed to dmaunmapsingle() by stmmactxclean(). The DMA API requires that the dma cookie passed to dmaunmapsingle() is the same as the value returned from dmamapsingle(). However, by moving the assignment later, this is not the case when priv->dmacap.addr64 > 32 as "des" is offset by protohdrlen.
This causes problems such as:
dwc-eth-dwmac 2490000.ethernet eth0: Tx DMA map failed
and with DMAAPIDEBUG enabled:
DMA-API: dwc-eth-dwmac 2490000.ethernet: device driver tries to +free DMA memory it has not allocated [device address=0x000000ffffcf65c0] [size=66 bytes]
Fix this by maintaining "des" as the original DMA cookie, and use tsodes to pass the offset DMA cookie to stmmactsoallocator().
Full details of the crashes can be found at: https://lore.kernel.org/all/d8112193-0386-4e14-b516-37c2d838171a@nvidia.com/ https://lore.kernel.org/all/klkzp5yn5kq5efgtrow6wbvnc46bcqfxs65nz3qy77ujr5turc@bwwhelz2l4dw/
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:
topology: Keep the cpumask unchanged when printing cpumap
During fuzz testing, the following warning was discovered:
different return values (15 and 11) from vsnprintf("%pbl ", ...)
test:keyward is WARNING in kvasprintf WARNING: CPU: 55 PID: 1168477 at lib/kasprintf.c:30 kvasprintf+0x121/0x130 Call Trace: kvasprintf+0x121/0x130 kasprintf+0xa6/0xe0 bitmapprinttobuf+0x89/0x100 coresiblingslistread+0x7e/0xb0 kernfsfilereaditer+0x15b/0x270 newsyncread+0x153/0x260 vfsread+0x215/0x290 ksysread+0xb9/0x160 dosyscall64+0x56/0x100 entrySYSCALL64afterhwframe+0x78/0xe2
The call trace shows that kvasprintf() reported this warning during the printing of coresiblingslist. kvasprintf() has several steps:
(1) First, calculate the length of the resulting formatted string.
(2) Allocate a buffer based on the returned length.
(3) Then, perform the actual string formatting.
(4) Check whether the lengths of the formatted strings returned in steps (1) and (2) are consistent.
If the corecpumask is modified between steps (1) and (3), the lengths obtained in these two steps may not match. Indeed our test includes cpu hotplugging, which should modify corecpumask while printing.
To fix this issue, cache the cpumask into a temporary variable before calling cpumapprint{list, cpumask}tobuf(), to keep it unchanged during the printing process.
In the Linux kernel, the following vulnerability has been resolved:
bpf: fix OOB devmap writes when deleting elements
Jordy reported issue against XSKMAP which also applies to DEVMAP - the index used for accessing map entry, due to being a signed integer, causes the OOB writes. Fix is simple as changing the type from int to u32, however, when compared to XSKMAP case, one more thing needs to be addressed.
When map is released from system via devmapfree(), we iterate through all of the entries and an iterator variable is also an int, which implies OOB accesses. Again, change it to be u32.
Example splat below:
[ 160.724676] BUG: unable to handle page fault for address: ffffc8fc2c001000 [ 160.731662] #PF: supervisor read access in kernel mode [ 160.736876] #PF: errorcode(0x0000) - not-present page [ 160.742095] PGD 0 P4D 0 [ 160.744678] Oops: Oops: 0000 [#1] PREEMPT SMP [ 160.749106] CPU: 1 UID: 0 PID: 520 Comm: kworker/u145:12 Not tainted 6.12.0-rc1+ #487 [ 160.757050] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019 [ 160.767642] Workqueue: eventsunbound bpfmapfreedeferred [ 160.773308] RIP: 0010:devmapfree+0x77/0x170 [ 160.777735] Code: 00 e8 fd 91 ed ff e8 b8 73 ed ff 41 83 7d 18 19 74 6e 41 8b 45 24 49 8b bd f8 00 00 00 31 db 85 c0 74 48 48 63 c3 48 8d 04 c7 <48> 8b 28 48 85 ed 74 30 48 8b 7d 18 48 85 ff 74 05 e8 b3 52 fa ff [ 160.796777] RSP: 0018:ffffc9000ee1fe38 EFLAGS: 00010202 [ 160.802086] RAX: ffffc8fc2c001000 RBX: 0000000080000000 RCX: 0000000000000024 [ 160.809331] RDX: 0000000000000000 RSI: 0000000000000024 RDI: ffffc9002c001000 [ 160.816576] RBP: 0000000000000000 R08: 0000000000000023 R09: 0000000000000001 [ 160.823823] R10: 0000000000000001 R11: 00000000000ee6b2 R12: dead000000000122 [ 160.831066] R13: ffff88810c928e00 R14: ffff8881002df405 R15: 0000000000000000 [ 160.838310] FS: 0000000000000000(0000) GS:ffff8897e0c40000(0000) knlGS:0000000000000000 [ 160.846528] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 160.852357] CR2: ffffc8fc2c001000 CR3: 0000000005c32006 CR4: 00000000007726f0 [ 160.859604] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 160.866847] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 160.874092] PKRU: 55555554 [ 160.876847] Call Trace: [ 160.879338] <TASK> [ 160.881477] ? die+0x20/0x60 [ 160.884586] ? pagefaultoops+0x15a/0x450 [ 160.888746] ? searchextable+0x22/0x30 [ 160.892647] ? searchbpfextables+0x5f/0x80 [ 160.896988] ? excpagefault+0xa9/0x140 [ 160.900973] ? asmexcpagefault+0x22/0x30 [ 160.905232] ? devmapfree+0x77/0x170 [ 160.909043] ? devmapfree+0x58/0x170 [ 160.912857] bpfmapfreedeferred+0x51/0x90 [ 160.917196] processonework+0x142/0x370 [ 160.921272] workerthread+0x29e/0x3b0 [ 160.925082] ? rescuerthread+0x4b0/0x4b0 [ 160.929157] kthread+0xd4/0x110 [ 160.932355] ? kthreadpark+0x80/0x80 [ 160.936079] retfromfork+0x2d/0x50 [ 160.943396] ? kthreadpark+0x80/0x80 [ 160.950803] retfromforkasm+0x11/0x20 [ 160.958482] </TASK>
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftsocket: remove WARNONONCE on maximum cgroup level
cgroup maximum depth is INTMAX by default, there is a cgroup toggle to restrict this maximum depth to a more reasonable value not to harm performance. Remove unnecessary WARNONONCE which is reachable from userspace.
In the Linux kernel, the following vulnerability has been resolved:
xsk: fix OOB map writes when deleting elements
Jordy says:
" In the xskmapdeleteelem function an unsigned integer (map->maxentries) is compared with a user-controlled signed integer (k). Due to implicit type conversion, a large unsigned value for map->maxentries can bypass the intended bounds check:
if (k >= map->maxentries) return -EINVAL;
This allows k to hold a negative value (between -2147483648 and -2), which is then used as an array index in m->xskmap[k], which results in an out-of-bounds access.
spinlockbh(&m->lock); mapentry = &m->xskmap[k]; // Out-of-bounds mapentry oldxs = unrcupointer(xchg(mapentry, NULL)); // Oob write if (oldxs) xskmapsockdelete(oldxs, mapentry); spinunlockbh(&m->lock);
The xchg operation can then be used to cause an out-of-bounds write. Moreover, the invalid mapentry passed to xskmapsockdelete can lead to further memory corruption. "
It indeed results in following splat:
[76612.897343] BUG: unable to handle page fault for address: ffffc8fc2e461108 [76612.904330] #PF: supervisor write access in kernel mode [76612.909639] #PF: errorcode(0x0002) - not-present page [76612.914855] PGD 0 P4D 0 [76612.917431] Oops: Oops: 0002 [#1] PREEMPT SMP [76612.921859] CPU: 11 UID: 0 PID: 10318 Comm: a.out Not tainted 6.12.0-rc1+ #470 [76612.929189] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019 [76612.939781] RIP: 0010:xskmapdeleteelem+0x2d/0x60 [76612.944738] Code: 00 00 41 54 55 53 48 63 2e 3b 6f 24 73 38 4c 8d a7 f8 00 00 00 48 89 fb 4c 89 e7 e8 2d bf 05 00 48 8d b4 eb 00 01 00 00 31 ff <48> 87 3e 48 85 ff 74 05 e8 16 ff ff ff 4c 89 e7 e8 3e bc 05 00 31 [76612.963774] RSP: 0018:ffffc9002e407df8 EFLAGS: 00010246 [76612.969079] RAX: 0000000000000000 RBX: ffffc9002e461000 RCX: 0000000000000000 [76612.976323] RDX: 0000000000000001 RSI: ffffc8fc2e461108 RDI: 0000000000000000 [76612.983569] RBP: ffffffff80000001 R08: 0000000000000000 R09: 0000000000000007 [76612.990812] R10: ffffc9002e407e18 R11: ffff888108a38858 R12: ffffc9002e4610f8 [76612.998060] R13: ffff888108a38858 R14: 00007ffd1ae0ac78 R15: ffffc9002e4610c0 [76613.005303] FS: 00007f80b6f59740(0000) GS:ffff8897e0ec0000(0000) knlGS:0000000000000000 [76613.013517] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [76613.019349] CR2: ffffc8fc2e461108 CR3: 000000011e3ef001 CR4: 00000000007726f0 [76613.026595] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [76613.033841] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [76613.041086] PKRU: 55555554 [76613.043842] Call Trace: [76613.046331] <TASK> [76613.048468] ? die+0x20/0x60 [76613.051581] ? pagefaultoops+0x15a/0x450 [76613.055747] ? searchextable+0x22/0x30 [76613.059649] ? searchbpfextables+0x5f/0x80 [76613.063988] ? excpagefault+0xa9/0x140 [76613.067975] ? asmexcpagefault+0x22/0x30 [76613.072229] ? xskmapdeleteelem+0x2d/0x60 [76613.076573] ? xskmapdeleteelem+0x23/0x60 [76613.080914] sysbpf+0x19b7/0x23c0 [76613.084555] x64sysbpf+0x1a/0x20 [76613.088194] dosyscall64+0x37/0xb0 [76613.091832] entrySYSCALL64afterhwframe+0x4b/0x53 [76613.096962] RIP: 0033:0x7f80b6d1e88d [76613.100592] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 b5 0f 00 f7 d8 64 89 01 48 [76613.119631] RSP: 002b:00007ffd1ae0ac68 EFLAGS: 00000206 ORIGRAX: 0000000000000141 [76613.131330] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f80b6d1e88d [76613.142632] RDX: 0000000000000098 RSI: 00007ffd1ae0ad20 RDI: 0000000000000003 [76613.153967] RBP: 00007ffd1ae0adc0 R08: 0000000000000000 R09: 0000000000000000 [76613.166030] R10: 00007f80b6f77040 R11: 0000000000000206 R12: 00007ffd1ae0aed8 [76613.177130] R13: 000055ddf42ce1e9 R14: 000055ddf42d0d98 R15: 00 ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
virt: tdx-guest: Just leak decrypted memory on unrecoverable errors
In CoCo VMs it is possible for the untrusted host to cause setmemorydecrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues.
Leak the decrypted memory when setmemorydecrypted() fails, and don't need to print an error since setmemorydecrypted() will call WARNONCE().
In the Linux kernel, the following vulnerability has been resolved:
vfio/platform: check the bounds of read/write syscalls
count and offset are passed from user space and not checked, only offset is capped to 40 bits, which can be used to read/write out of bounds of the device.
In the Linux kernel, the following vulnerability has been resolved:
tracing: Prevent bad count for tracingcpumaskwrite
If a large count is provided, it will trigger a warning in bitmapparseuser. Also check zero for it.
In the Linux kernel, the following vulnerability has been resolved:
net/smc: check v2extoffset/eidcnt/ismgidcnt when receiving proposal msg
When receiving proposal msg in server, the fields v2extoffset/ eidcnt/ismgidcnt in proposal msg are from the remote client and can not be fully trusted. Especially the field v2extoffset, once exceed the max value, there has the chance to access wrong address, and crash may happen.
This patch checks the fields v2extoffset/eidcnt/ismgidcnt before using them.
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: don't auto enable misc vector
Currently, there is a time window between misc irq enabled and service task inited. If an interrupte is reported at this time, it will cause warning like below:
[ 16.324639] Call trace: [ 16.324641] queuedelayedwork+0xb8/0xe0 [ 16.324643] moddelayedworkon+0x78/0xd0 [ 16.324655] hclgeerrhandtaskschedule+0x58/0x90 [hclge] [ 16.324662] hclgemiscirqhandle+0x168/0x240 [hclge] [ 16.324666] handleirqeventpercpu+0x64/0x1e0 [ 16.324667] handleirqevent+0x80/0x170 [ 16.324670] handlefasteoiedgeirq+0x110/0x2bc [ 16.324671] handledomainirq+0x84/0xfc [ 16.324673] gichandleirq+0x88/0x2c0 [ 16.324674] el1irq+0xb8/0x140 [ 16.324677] archcpuidle+0x18/0x40 [ 16.324679] defaultidlecall+0x5c/0x1bc [ 16.324682] cpuidleidlecall+0x18c/0x1c4 [ 16.324684] doidle+0x174/0x17c [ 16.324685] cpustartupentry+0x30/0x6c [ 16.324687] secondarystartkernel+0x1a4/0x280 [ 16.324688] ---[ end trace 6aa0bff672a964aa ]---
So don't auto enable misc vector when request irq..
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (drivetemp) Fix driver producing garbage data when SCSI errors occur
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: fix kernel crash when 1588 is sent on HIP08 devices
Currently, HIP08 devices does not register the ptp devices, so the hdev->ptp is NULL. But the tx process would still try to set hardware time stamp info with SKBTXHWTSTAMP flag and cause a kernel crash.
[ 128.087798] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 ... [ 128.280251] pc : hclgeptpsettxinfo+0x2c/0x140 [hclge] [ 128.286600] lr : hclgeptpsettxinfo+0x20/0x140 [hclge] [ 128.292938] sp : ffff800059b93140 [ 128.297200] x29: ffff800059b93140 x28: 0000000000003280 [ 128.303455] x27: ffff800020d48280 x26: ffff0cb9dc814080 [ 128.309715] x25: ffff0cb9cde93fa0 x24: 0000000000000001 [ 128.315969] x23: 0000000000000000 x22: 0000000000000194 [ 128.322219] x21: ffff0cd94f986000 x20: 0000000000000000 [ 128.328462] x19: ffff0cb9d2a166c0 x18: 0000000000000000 [ 128.334698] x17: 0000000000000000 x16: ffffcf1fc523ed24 [ 128.340934] x15: 0000ffffd530a518 x14: 0000000000000000 [ 128.347162] x13: ffff0cd6bdb31310 x12: 0000000000000368 [ 128.353388] x11: ffff0cb9cfbc7070 x10: ffff2cf55dd11e02 [ 128.359606] x9 : ffffcf1f85a212b4 x8 : ffff0cd7cf27dab0 [ 128.365831] x7 : 0000000000000a20 x6 : ffff0cd7cf27d000 [ 128.372040] x5 : 0000000000000000 x4 : 000000000000ffff [ 128.378243] x3 : 0000000000000400 x2 : ffffcf1f85a21294 [ 128.384437] x1 : ffff0cb9db520080 x0 : ffff0cb9db500080 [ 128.390626] Call trace: [ 128.393964] hclgeptpsettxinfo+0x2c/0x140 [hclge] [ 128.399893] hns3nicnetxmit+0x39c/0x4c4 [hns3] [ 128.405468] xmitone.constprop.0+0xc4/0x200 [ 128.410600] devhardstartxmit+0x54/0xf0 [ 128.415556] schdirectxmit+0xe8/0x634 [ 128.420246] devqueuexmit+0x224/0xc70 [ 128.425101] devqueuexmit+0x1c/0x40 [ 128.429608] ovsvportsend+0xac/0x1a0 [openvswitch] [ 128.435409] dooutput+0x60/0x17c [openvswitch] [ 128.440770] doexecuteactions+0x898/0x8c4 [openvswitch] [ 128.446993] ovsexecuteactions+0x64/0xf0 [openvswitch] [ 128.453129] ovsdpprocesspacket+0xa0/0x224 [openvswitch] [ 128.459530] ovsvportreceive+0x7c/0xfc [openvswitch] [ 128.465497] internaldevxmit+0x34/0xb0 [openvswitch] [ 128.471460] xmitone.constprop.0+0xc4/0x200 [ 128.476561] devhardstartxmit+0x54/0xf0 [ 128.481489] devqueuexmit+0x968/0xc70 [ 128.486330] devqueuexmit+0x1c/0x40 [ 128.490856] ipfinishoutput2+0x250/0x570 [ 128.495810] ipfinishoutput+0x170/0x1e0 [ 128.500832] ipfinishoutput+0x3c/0xf0 [ 128.505504] ipoutput+0xbc/0x160 [ 128.509654] ipsendskb+0x58/0xd4 [ 128.513892] udpsendskb+0x12c/0x354 [ 128.518387] udpsendmsg+0x7a8/0x9c0 [ 128.522793] inetsendmsg+0x4c/0x8c [ 128.527116] socksendmsg+0x48/0x80 [ 128.531609] syssendto+0x124/0x164 [ 128.536099] arm64syssendto+0x30/0x5c [ 128.540935] invokesyscall+0x50/0x130 [ 128.545508] el0svccommon.constprop.0+0x10c/0x124 [ 128.551205] doel0svc+0x34/0xdc [ 128.555347] el0svc+0x20/0x30 [ 128.559227] el0synchandler+0xb8/0xc0 [ 128.563883] el0sync+0x160/0x180
In the Linux kernel, the following vulnerability has been resolved:
drm/dpmst: Fix MST sideband message body length check
Fix the MST sideband message body length check, which must be at least 1 byte accounting for the message body CRC (aka message data CRC) at the end of the message.
This fixes a case where an MST branch device returns a header with a correct header CRC (indicating a correctly received body length), with the body length being incorrectly set to 0. This will later lead to a memory corruption in drmdpsidebandappendpayload() and the following errors in dmesg:
UBSAN: array-index-out-of-bounds in drivers/gpu/drm/display/drmdpmsttopology.c:786:25 index -1 is out of range for type 'u8 [48]' Call Trace: drmdpsidebandappendpayload+0x33d/0x350 [drmdisplayhelper] drmdpgetonesbmsg+0x3ce/0x5f0 [drmdisplayhelper] drmdpmsthpdirqhandleevent+0xc8/0x1580 [drmdisplayhelper]
memcpy: detected field-spanning write (size 18446744073709551615) of single field "&msg->msg[msg->curlen]" at drivers/gpu/drm/display/drmdpmsttopology.c:791 (size 256) Call Trace: drmdpsidebandappendpayload+0x324/0x350 [drmdisplayhelper] drmdpgetonesbmsg+0x3ce/0x5f0 [drmdisplayhelper] drmdpmsthpdirqhandleevent+0xc8/0x1580 [drmdisplayhelper]
In the Linux kernel, the following vulnerability has been resolved:
riscv: mm: Fix the out of bound issue of vmemmap address
In sparse vmemmap model, the virtual address of vmemmap is calculated as: ((struct page )VMEMMAPSTART - (physrambase >> PAGESHIFT)). And the struct page's va can be calculated with an offset: (vmemmap + (pfn)).
However, when initializing struct pages, kernel actually starts from the first page from the same section that physrambase belongs to. If the first page's physical address is not (physrambase >> PAGESHIFT), then we get an va below VMEMMAPSTART when calculating va for it's struct page.
For example, if physrambase starts from 0x82000000 with pfn 0x82000, the first page in the same section is actually pfn 0x80000. During initunavailablerange(), we will initialize struct page for pfn 0x80000 with virtual address ((struct page )VMEMMAPSTART - 0x2000), which is below VMEMMAPSTART as well as PCIIOEND.
This commit fixes this bug by introducing a new variable 'vmemmapstartpfn' which is aligned with memory section size and using it to calculate vmemmap address instead of physrambase.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: IDLETIMER: Fix for possible ABBA deadlock
Deletion of the last rule referencing a given idletimer may happen at the same time as a read of its file in sysfs:
| ====================================================== | WARNING: possible circular locking dependency detected | 6.12.0-rc7-01692-g5e9a28f41134-dirty #594 Not tainted | ------------------------------------------------------ | iptables/3303 is trying to acquire lock: | ffff8881057e04b8 (kn->active#48){++++}-{0:0}, at: kernfsremove+0x20 | | but task is already holding lock: | ffffffffa0249068 (listmutex){+.+.}-{3:3}, at: idletimertgdestroyv] | | which lock already depends on the new lock.
A simple reproducer is:
| #!/bin/bash | | while true; do | iptables -A INPUT -i foo -j IDLETIMER --timeout 10 --label "testme" | iptables -D INPUT -i foo -j IDLETIMER --timeout 10 --label "testme" | done & | while true; do | cat /sys/class/xtidletimer/timers/testme >/dev/null | done
Avoid this by freeing listmutex right after deleting the element from the list, then continuing with the teardown.
In the Linux kernel, the following vulnerability has been resolved:
In the Linux kernel, the following vulnerability has been resolved:
sctp: sysctl: rtomin/max: avoid using current->nsproxy
As mentioned in a previous commit of this series, using the 'net' structure via 'current' is not recommended for different reasons:
- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.
- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).
The 'net' structure can be obtained from the table->data using containerof().
Note that table->data could also be used directly, as this is the only member needed from the 'net' structure, but that would increase the size of this fix, to use 'data' everywhere 'net->sctp.rtomin/max' is used.
In the Linux kernel, the following vulnerability has been resolved:
cgroup/cpuset: remove kernfs active break
A warning was found:
WARNING: CPU: 10 PID: 3486953 at fs/kernfs/file.c:828 CPU: 10 PID: 3486953 Comm: rmdir Kdump: loaded Tainted: G RIP: 0010:kernfsshoulddrainopenfiles+0x1a1/0x1b0 RSP: 0018:ffff8881107ef9e0 EFLAGS: 00010202 RAX: 0000000080000002 RBX: ffff888154738c00 RCX: dffffc0000000000 RDX: 0000000000000007 RSI: 0000000000000004 RDI: ffff888154738c04 RBP: ffff888154738c04 R08: ffffffffaf27fa15 R09: ffffed102a8e7180 R10: ffff888154738c07 R11: 0000000000000000 R12: ffff888154738c08 R13: ffff888750f8c000 R14: ffff888750f8c0e8 R15: ffff888154738ca0 FS: 00007f84cd0be740(0000) GS:ffff8887ddc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555f9fbe00c8 CR3: 0000000153eec001 CR4: 0000000000370ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: kernfsdrain+0x15e/0x2f0 kernfsremove+0x165/0x300 kernfsremovebynamens+0x7b/0xc0 cgrouprmfile+0x154/0x1c0 cgroupaddrmfiles+0x1c2/0x1f0 csscleardir+0x77/0x110 killcss+0x4c/0x1b0 cgroupdestroylocked+0x194/0x380 cgrouprmdir+0x2a/0x140
It can be explained by: rmdir echo 1 > cpuset.cpus kernfsfopwriteiter // active=0 cgrouprmfile kernfsremovebynamens kernfsgetactive // active=1 kernfsremove // active=0x80000002 kernfsdrain cpusetwriteresmask waitevent //waiting (active == 0x80000001) kernfsbreakactiveprotection // active = 0x80000001 // continue kernfsunbreakactiveprotection // active = 0x80000002 ... kernfsshoulddrainopenfiles // warning occurs kernfsputactive
This warning is caused by 'kernfsbreakactiveprotection' when it is writing to cpuset.cpus, and the cgroup is removed concurrently.
The commit 3a5a6d0c2b03 ("cpuset: don't nest cgroupmutex inside getonlinecpus()") made cpusethotplugworkfn asynchronous, This change involves calling flushwork(), which can create a multiple processes circular locking dependency that involve cgroupmutex, potentially leading to a deadlock. To avoid deadlock. the commit 76bb5ab8f6e3 ("cpuset: break kernfs active protection in cpusetwriteresmask()") added 'kernfsbreakactiveprotection' in the cpusetwriteresmask. This could lead to this warning.
After the commit 2125c0034c5d ("cgroup/cpuset: Make cpuset hotplug processing synchronous"), the cpusetwriteresmask no longer needs to wait the hotplug to finish, which means that concurrent hotplug and cpuset operations are no longer possible. Therefore, the deadlock doesn't exist anymore and it does not have to 'break active protection' now. To fix this warning, just remove kernfsbreakactiveprotection operation in the 'cpusetwriteresmask'.
In the Linux kernel, the following vulnerability has been resolved:
USB: serial: quatech2: fix null-ptr-deref in qt2processreadurb()
This patch addresses a null-ptr-deref in qt2processreadurb() due to an incorrect bounds check in the following:
if (newport > serial->numports) { deverr(&port->dev, "%s - port change to invalid port: %i\n", func, newport); break; }
The condition doesn't account for the valid range of the serial->port buffer, which is from 0 to serial->numports - 1. When newport is equal to serial->numports, the assignment of "port" in the following code is out-of-bounds and NULL:
serialpriv->currentport = newport; port = serial->port[serialpriv->currentport];
The fix checks if newport is greater than or equal to serial->numports indicating it is out-of-bounds.
In the Linux kernel, the following vulnerability has been resolved:
net: reenable NETIFFIPV6CSUM offload for BIG TCP packets
The blamed commit disabled hardware offoad of IPv6 packets with extension headers on devices that advertise NETIFFIPV6CSUM, based on the definition of that feature in skbuff.h:
- %NETIFFIPV6CSUM - Driver (device) is only able to checksum plain TCP or UDP packets over IPv6. These are specifically unencapsulated packets of the form IPv6|TCP or IPv6|UDP where the Next Header field in the IPv6 header is either TCP or UDP. IPv6 extension headers are not supported with this feature. This feature cannot be set in features for a device with NETIFFHWCSUM also set. This feature is being DEPRECATED (see below).
The change causes skbwarnbadoffload to fire for BIG TCP packets.
[ 496.310233] WARNING: CPU: 13 PID: 23472 at net/core/dev.c:3129 skbwarnbadoffload+0xc4/0xe0
[ 496.310297] ? skbwarnbadoffload+0xc4/0xe0 [ 496.310300] skbchecksumhelp+0x129/0x1f0 [ 496.310303] skbcsumhwoffloadhelp+0x150/0x1b0 [ 496.310306] validatexmitskb+0x159/0x270 [ 496.310309] validatexmitskblist+0x41/0x70 [ 496.310312] schdirectxmit+0x5c/0x250 [ 496.310317] qdiscrun+0x388/0x620
BIG TCP introduced an IPV6TLVJUMBO IPv6 extension header to communicate packet length, as this is an IPv6 jumbogram. But, the feature is only enabled on devices that support BIG TCP TSO. The header is only present for PFPACKET taps like tcpdump, and not transmitted by physical devices.
For this specific case of extension headers that are not transmitted, return to the situation before the blamed commit and support hardware offload.
ipv6hashopoptjumbo() tests not only whether this header is present, but also that it is the only extension header before a terminal (L4) header.
In the Linux kernel, the following vulnerability has been resolved:
sctp: sysctl: cookiehmacalg: avoid using current->nsproxy
As mentioned in a previous commit of this series, using the 'net' structure via 'current' is not recommended for different reasons:
- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.
- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).
The 'net' structure can be obtained from the table->data using containerof().
Note that table->data could also be used directly, as this is the only member needed from the 'net' structure, but that would increase the size of this fix, to use 'data' everywhere 'net->sctp.sctphmacalg' is used.
In the Linux kernel, the following vulnerability has been resolved:
sched: schcake: add bounds checks to host bulk flow fairness counts
Even though we fixed a logic error in the commit cited below, syzbot still managed to trigger an underflow of the per-host bulk flow counters, leading to an out of bounds memory access.
To avoid any such logic errors causing out of bounds memory accesses, this commit factors out all accesses to the per-host bulk flow counters to a series of helpers that perform bounds-checking before any increments and decrements. This also has the benefit of improving readability by moving the conditional checks for the flow mode into these helpers, instead of having them spread out throughout the code (which was the cause of the original logic error).
As part of this change, the flow quantum calculation is consolidated into a helper function, which means that the dithering applied to the ost load scaling is now applied both in the DRR rotation and when a sparse flow's quantum is first initiated. The only user-visible effect of this is that the maximum packet size that can be sent while a flow stays sparse will now vary with +/- one byte in some cases. This should not make a noticeable difference in practice, and thus it's not worth complicating the code to preserve the old behaviour.