In the Linux kernel, the following vulnerability has been resolved:
libceph: replace BUGON with bounds check for map->maxosd
OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->maxosd.
[ idryomov: drop BUGON in cephgetprimaryaffinity(), minor cosmetic edits ]
In the Linux kernel, the following vulnerability has been resolved:
libceph: prevent potential out-of-bounds writes in handleauthsessionkey()
The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets.
[ idryomov: changelog ]
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential UAF in smb2closecachedfid()
findorcreatecacheddir() could grab a new reference after krefput() had seen the refcount drop to zero but before cfidlistlock is acquired in smb2closecachedfid(), leading to use-after-free.
Switch to krefputlock() so cfidrelease() is called with cfidlistlock held, closing that gap.
In the Linux kernel, the following vulnerability has been resolved:
nvmet-fc: avoid scheduling association deletion twice
When forcefully shutting down a port via the configfs interface, nvmetportsubsysdroplink() first calls nvmetportdelctrls() and then nvmetdisableport(). Both functions will eventually schedule all remaining associations for deletion.
The current implementation checks whether an association is about to be removed, but only after the work item has already been scheduled. As a result, it is possible for the first scheduled work item to free all resources, and then for the same work item to be scheduled again for deletion.
Because the association list is an RCU list, it is not possible to take a lock and remove the list entry directly, so it cannot be looked up again. Instead, a flag (terminating) must be used to determine whether the association is already in the process of being deleted.
In the Linux kernel, the following vulnerability has been resolved:
drm/gpusvm: fix hmmpfntomaporder() usage
Handle the case where the hmm range partially covers a huge page (like 2M), otherwise we can potentially end up doing something nasty like mapping memory which is outside the range, and maybe not even mapped by the mm. Fix is based on the xe userptr code, which in a future patch will directly use gpusvm, so needs alignment here.
v2: - Add kernel-doc (Matt B) - s/fls/ilog2/ (Thomas)
Bluetooth: MGMT: cancel mesh send timer when hdev removed
Bluetooth: btusb: reorder cleanup in btusbdisconnect to avoid UAF
In the Linux kernel, the following vulnerability has been resolved:
net: tls: avoid hanging tasks on the txlock
syzbot sent a hung task report and Eric explains that adversarial receiver may keep RWIN at 0 for a long time, so we are not guaranteed to make forward progress. Thread which took txlock and went to sleep may not release txlock for hours. Use interruptible sleep where possible and reschedule the work if it can't take the lock.
Testing: existing selftest passes
In the Linux kernel, the following vulnerability has been resolved:
net/smc: use smclgrlist.lock to protect smclgrlist.list iterate in smcrportadd
While doing smcrportadd, there maybe linkgroup add into or delete from smclgrlist.list at the same time, which may result kernel crash. So, use smclgrlist.lock to protect smclgrlist.list iterate in smcrportadd.
The crash calltrace show below: BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 0 PID: 559726 Comm: kworker/0:92 Kdump: loaded Tainted: G Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 449e491 04/01/2014 Workqueue: events smcibporteventwork [smc] RIP: 0010:smcrportadd+0xa6/0xf0 [smc] RSP: 0000:ffffa5a2c8f67de0 EFLAGS: 00010297 RAX: 0000000000000001 RBX: ffff9935e0650000 RCX: 0000000000000000 RDX: 0000000000000010 RSI: ffff9935e0654290 RDI: ffff9935c8560000 RBP: 0000000000000000 R08: 0000000000000000 R09: ffff9934c0401918 R10: 0000000000000000 R11: ffffffffb4a5c278 R12: ffff99364029aae4 R13: ffff99364029aa00 R14: 00000000ffffffed R15: ffff99364029ab08 FS: 0000000000000000(0000) GS:ffff994380600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000f06a10003 CR4: 0000000002770ef0 PKRU: 55555554 Call Trace: smcibporteventwork+0x18f/0x380 [smc] processonework+0x19b/0x340 workerthread+0x30/0x370 ? processonework+0x340/0x340 kthread+0x114/0x130 ? kthreadcancelwork+0x50/0x50 retfromfork+0x1f/0x30
In the Linux kernel, the following vulnerability has been resolved:
mlx5: fix skb leak while fifo resync and push
During ptp resync operation SKBs were poped from the fifo but were never freed neither by napiconsume nor by devkfreeskbany. Add call to napiconsumeskb to properly free SKBs.
Another leak was happening because mlx5eskbfifohasroom() had an error in the check. Comparing free running counters works well unless C promotes the types to something wider than the counter. In this case counters are u16 but the result of the substraction is promouted to int and it causes wrong result (negative value) of the check when producer have already overlapped but consumer haven't yet. Explicit cast to u16 fixes the issue.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftables: always release netdev hooks from notifier
This reverts "netfilter: nftables: skip netdev events generated on netns removal".
The problem is that when a veth device is released, the veth release callback will also queue the peer netns device for removal.
Its possible that the peer netns is also slated for removal. In this case, the device memory is already released before the preexit hook of the peer netns runs:
BUG: KASAN: slab-use-after-free in nfhookentryhead+0x1b8/0x1d0 Read of size 8 at addr ffff88812c0124f0 by task kworker/u8:1/45 Workqueue: netns cleanupnet Call Trace: nfhookentryhead+0x1b8/0x1d0 nfunregisternethook+0x76/0x510 nftnetdevunregisterhooks+0xa0/0x220 nftreleasehook+0x184/0x490 nftablespreexitnet+0x12f/0x1b0 ..
Order is: 1. First netns is released, vethdellink() queues peer netns device for removal 2. peer netns is queued for removal 3. peer netns device is released, unreg event is triggered 4. unreg event is ignored because netns is going down 5. preexit hook calls nftnetdevunregisterhooks but device memory might be free'd already.
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix potential user-after-free
This fixes all instances of which requires to allocate a buffer calling allocskb which may release the chan lock and reacquire later which makes it possible that the chan is disconnected in the meantime.
In the Linux kernel, the following vulnerability has been resolved:
net/sched: flower: fix filter idr initialization
The cited commit moved idr initialization too early in flchange() which allows concurrent users to access the filter that is still being initialized and is in inconsistent state, which, in turn, can cause NULL pointer dereference [0]. Since there is no obvious way to fix the ordering without reverting the whole cited commit, alternative approach taken to first insert NULL pointer into idr in order to allocate the handle but still cause flget() to return NULL and prevent concurrent users from seeing the filter while providing miss-to-action infrastructure with valid handle id early in flchange().
[ 152.434728] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN [ 152.436163] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] [ 152.437269] CPU: 4 PID: 3877 Comm: tc Not tainted 6.3.0-rc4+ #5 [ 152.438110] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 152.439644] RIP: 0010:fldumpkey+0x8b/0x1d10 [clsflower] [ 152.440461] Code: 01 f2 02 f2 c7 40 08 04 f2 04 f2 c7 40 0c 04 f3 f3 f3 65 48 8b 04 25 28 00 00 00 48 89 84 24 00 01 00 00 48 89 c8 48 c1 e8 03 <0f> b6 04 10 84 c0 74 08 3c 03 0f 8e 98 19 00 00 8b 13 85 d2 74 57 [ 152.442885] RSP: 0018:ffff88817a28f158 EFLAGS: 00010246 [ 152.443851] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 152.444826] RDX: dffffc0000000000 RSI: ffffffff8500ae80 RDI: ffff88810a987900 [ 152.445791] RBP: ffff888179d88240 R08: ffff888179d8845c R09: ffff888179d88240 [ 152.446780] R10: ffffed102f451e48 R11: 00000000fffffff2 R12: ffff88810a987900 [ 152.447741] R13: ffffffff8500ae80 R14: ffff88810a987900 R15: ffff888149b3c738 [ 152.448756] FS: 00007f5eb2a34800(0000) GS:ffff88881ec00000(0000) knlGS:0000000000000000 [ 152.449888] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 152.450685] CR2: 000000000046ad19 CR3: 000000010b0bd006 CR4: 0000000000370ea0 [ 152.451641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 152.452628] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 152.453588] Call Trace: [ 152.454032] <TASK> [ 152.454447] ? netlinksendmsg+0x7a1/0xcb0 [ 152.455109] ? socksendmsg+0xc5/0x190 [ 152.455689] ? syssendmsg+0x535/0x6b0 [ 152.456320] ? syssendmsg+0xeb/0x170 [ 152.456916] ? dosyscall64+0x3d/0x90 [ 152.457529] ? entrySYSCALL64afterhwframe+0x46/0xb0 [ 152.458321] ? syssendmsg+0xeb/0x170 [ 152.458958] ? syssendmsg+0xb5/0x140 [ 152.459564] ? dosyscall64+0x3d/0x90 [ 152.460122] ? entrySYSCALL64afterhwframe+0x46/0xb0 [ 152.460852] ? fldumpkeyoptions.part.0+0xea0/0xea0 [clsflower] [ 152.461710] ? rawspinlock+0x7a/0xd0 [ 152.462299] ? rawreadlockirq+0x30/0x30 [ 152.462924] ? nlaput+0x15e/0x1c0 [ 152.463480] fldump+0x228/0x650 [clsflower] [ 152.464112] ? fltmpltdump+0x210/0x210 [clsflower] [ 152.464854] ? kmemcacheallocnode+0x1a7/0x330 [ 152.465592] ? nlaput+0x15e/0x1c0 [ 152.466160] tcffillnode+0x515/0x9a0 [ 152.466766] ? tcsetupoffloadaction+0xf0/0xf0 [ 152.467463] ? allocskb+0x13c/0x2a0 [ 152.468067] ? buildskbaround+0x330/0x330 [ 152.468814] ? flget+0x107/0x1a0 [clsflower] [ 152.469503] tcdeltfilter+0x718/0x1330 [ 152.470115] ? isbpftextaddress+0xa/0x20 [ 152.470765] ? tcctlchain+0xee0/0xee0 [ 152.471335] ? kerneltextaddress+0xe/0x30 [ 152.471948] ? unwindgetreturnaddress+0x56/0xa0 [ 152.472639] ? thawtask+0x150/0x150 [ 152.473218] ? archstackwalk+0x98/0xf0 [ 152.473839] ? stackdepotsave+0x35/0x4c0 [ 152.474501] ? stacktracesave+0x91/0xc0 [ 152.475119] ? securitycapable+0x51/0x90 [ 152.475741] rtnetlinkrcvmsg+0x2c1/0x9d0 [ 152.476387] ? rtnlcalcit.isra.0+0x2b0/0x2b0 [ 152.477042] ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
fs: drop peer group ids under namespace lock
When cleaning up peer group ids in the failure path we need to make sure to hold on to the namespace lock. Otherwise another thread might just turn the mount from a shared into a non-shared mount concurrently.
In the Linux kernel, the following vulnerability has been resolved:
drm/fbdev-generic: prohibit potential out-of-bounds access
The fbdev test of IGT may write after EOF, which lead to out-of-bound access for drm drivers with fbdev-generic. For example, run fbdev test on a x86+ast2400 platform, with 1680x1050 resolution, will cause the linux kernel hang with the following call trace:
Oops: 0000 [#1] PREEMPT SMP PTI [IGT] fbdev: starting subtest eof Workqueue: events drmfbhelperdamagework [drmkmshelper] [IGT] fbdev: starting subtest nullptr
RIP: 0010:memcpyerms+0xa/0x20 RSP: 0018:ffffa17d40167d98 EFLAGS: 00010246 RAX: ffffa17d4eb7fa80 RBX: ffffa17d40e0aa80 RCX: 00000000000014c0 RDX: 0000000000001a40 RSI: ffffa17d40e0b000 RDI: ffffa17d4eb80000 RBP: ffffa17d40167e20 R08: 0000000000000000 R09: ffff89522ecff8c0 R10: ffffa17d4e4c5000 R11: 0000000000000000 R12: ffffa17d4eb7fa80 R13: 0000000000001a40 R14: 000000000000041a R15: ffffa17d40167e30 FS: 0000000000000000(0000) GS:ffff895257380000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffa17d40e0b000 CR3: 00000001eaeca006 CR4: 00000000001706e0 Call Trace: <TASK> ? drmfbdevgenerichelperfbdirty+0x207/0x330 [drmkmshelper] drmfbhelperdamagework+0x8f/0x170 [drmkmshelper] processonework+0x21f/0x430 workerthread+0x4e/0x3c0 ? pfxworkerthread+0x10/0x10 kthread+0xf4/0x120 ? pfxkthread+0x10/0x10 retfromfork+0x2c/0x50 </TASK> CR2: ffffa17d40e0b000 ---[ end trace 0000000000000000 ]---
The is because damage rectangles computed by drmfbhelpermemoryrangetoclip() function is not guaranteed to be bound in the screen's active display area. Possible reasons are:
1) Buffers are allocated in the granularity of page size, for mmap system call support. The shadow screen buffer consumed by fbdev emulation may also choosed be page size aligned.
2) The DIVROUNDUP() used in drmfbhelpermemoryrangetoclip() will introduce off-by-one error.
For example, on a 16KB page size system, in order to store a 1920x1080 XRGB framebuffer, we need allocate 507 pages. Unfortunately, the size 192010804 can not be divided exactly by 16KB.
1920 1080 4 = 8294400 bytes 506 16 1024 = 8290304 bytes 507 16 1024 = 8306688 bytes
linelength = 19204 = 7680 bytes
507 16 1024 / 7680 = 1081.6
off / linelength = 507 16 1024 / 7680 = 1081 DIVROUNDUP(507 16 1024, 7680) will yeild 1082
memcpytoio() typically issue the copy line by line, when copy the last line, out-of-bound access will be happen. Because:
1082 linelength = 1082 7680 = 8309760, and 8309760 > 8306688
Note that userspace may still write to the invisiable area if a larger buffer than width x stride is exposed. But it is not a big issue as long as there still have memory resolve the access if not drafting so far.
- Also limit the y1 (Daniel) - keep fix patch it to minimal (Daniel) - screensize is page size aligned because of it need mmap (Thomas) - Adding fixes tag (Thomas)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix race condition in hidpsessionthread
There is a potential race condition in hidpsessionthread that may lead to use-after-free. For instance, the timer is active while hidpdeltimer is called in hidpsessionthread(). After hidpsessionput, then 'session' will be freed, causing kernel panic when hidpidletimeout is running.
The solution is to use deltimersync instead of deltimer.
Here is the call trace:
? hidpsessionprobe+0x780/0x780 calltimerfn+0x2d/0x1e0 runtimers.part.0+0x569/0x940 hidpsessionprobe+0x780/0x780 calltimerfn+0x1e0/0x1e0 ktimeget+0x5c/0xf0 lapicnextdeadline+0x2c/0x40 clockeventsprogramevent+0x205/0x320 runtimersoftirq+0xa9/0x1b0 dosoftirq+0x1b9/0x641 irqexitrcu+0xdc/0x190 irqexitrcu+0xe/0x20 sysvecapictimerinterrupt+0xa1/0xc0
In the Linux kernel, the following vulnerability has been resolved:
bpf: Disable preemption in bpfeventoutput
We received report [1] of kernel crash, which is caused by using nesting protection without disabled preemption.
The bpfeventoutput can be called by programs executed by bpfprogrunarraycg function that disabled migration but keeps preemption enabled.
This can cause task to be preempted by another one inside the nesting protection and lead eventually to two tasks using same perfsampledata buffer and cause crashes like:
BUG: kernel NULL pointer dereference, address: 0000000000000001 #PF: supervisor instruction fetch in kernel mode #PF: errorcode(0x0010) - not-present page ... ? perfoutputsample+0x12a/0x9a0 ? finishtaskswitch.isra.0+0x81/0x280 ? perfeventoutput+0x66/0xa0 ? bpfeventoutput+0x13a/0x190 ? bpfeventoutputdata+0x22/0x40 ? bpfprogdfc84bbde731b257cilsock4connect+0x40a/0xacb ? xaload+0x87/0xe0 ? cgroupbpfrunfiltersockaddr+0xc1/0x1a0 ? releasesock+0x3e/0x90 ? sksetsockopt+0x1a1/0x12f0 ? udppreconnect+0x36/0x50 ? inetdgramconnect+0x93/0xa0 ? sysconnect+0xb4/0xe0 ? udpsetsockopt+0x27/0x40 ? pfxudppushpendingframes+0x10/0x10 ? syssetsockopt+0xdf/0x1a0 ? x64sysconnect+0xf/0x20 ? dosyscall64+0x3a/0x90 ? entrySYSCALL64afterhwframe+0x72/0xdc
Fixing this by disabling preemption in bpfeventoutput.
[1] https://github.com/cilium/cilium/issues/26756
In the Linux kernel, the following vulnerability has been resolved:
powerpc/iommu: Fix notifiers being shared by PCI and VIO buses
failiommusetup() registers the failiommubusnotifier struct to both PCI and VIO buses. struct notifierblock is a linked list node, so this causes any notifiers later registered to either bus type to also be registered to the other since they share the same node.
This causes issues in (at least) the vgaarb code, which registers a notifier for PCI buses. pcinotify() ends up being called on a vio device, converted with topcidev() even though it's not a PCI device, and finally makes a bad access in vgaarbiteraddpcidevice() as discovered with KASAN:
BUG: KASAN: slab-out-of-bounds in vgaarbiteraddpcidevice+0x60/0xe00 Read of size 4 at addr c000000264c26fdc by task swapper/0/1
Call Trace: dumpstacklvl+0x1bc/0x2b8 (unreliable) printreport+0x3f4/0xc60 kasanreport+0x244/0x698 asanload4+0xe8/0x250 vgaarbiteraddpcidevice+0x60/0xe00 pcinotify+0x88/0x444 notifiercallchain+0x104/0x320 blockingnotifiercallchain+0xa0/0x140 deviceadd+0xac8/0x1d30 deviceregister+0x58/0x80 vioregisterdevicenode+0x9ac/0xce0 viobusscanregisterdevices+0xc4/0x13c machineinitcallpseriesviodeviceinit+0x94/0xf0 dooneinitcall+0x12c/0xaa8 kernelinitfreeable+0xa48/0xba8 kernelinit+0x64/0x400 retfromkernelthread+0x5c/0x64
Fix this by creating separate notifierblock structs for each bus type.
[mpe: Add #ifdef to fix CONFIGIBMVIO=n build]
In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: pv: fix index value of replaced ASCE
The index field of the struct page corresponding to a guest ASCE should be 0. When replacing the ASCE in s390replaceasce(), the index of the new ASCE should also be set to 0.
Having the wrong index might lead to the wrong addresses being passed around when notifying pte invalidations, and eventually to validity intercepts (VM crash) if the prefix gets unmapped and the notifier gets called with the wrong address.
In the Linux kernel, the following vulnerability has been resolved:
ASoC: soc-compress: Reposition and add pcmmutex
If paniconwarn is set and compress stream(DPCM) is started, then kernel panic occurred because card->pcmmutex isn't held appropriately. In the following functions, warning were issued at this line "sndsocdpcmmutexassertheld".
static int dpcmbeconnect(struct sndsocpcmruntime fe, struct sndsocpcmruntime be, int stream) { ... sndsocdpcmmutexassertheld(fe); ... }
void dpcmbedisconnect(struct sndsocpcmruntime fe, int stream) { ... sndsocdpcmmutexassertheld(fe); ... }
void sndsocruntimeaction(struct sndsocpcmruntime rtd, int stream, int action) { ... sndsocdpcmmutexassertheld(rtd); ... }
int dpcmdapmstreamevent(struct sndsocpcmruntime fe, int dir, int event) { ... sndsocdpcmmutexassertheld(fe); ... }
These functions are called by soccomprsetparamsfe, soccompropenfe and soccomprfreefe without pcmmutex locking. And this is call stack.
[ 414.527841][ T2179] pc : dpcmprocesspaths+0x5a4/0x750 [ 414.527848][ T2179] lr : dpcmprocesspaths+0x37c/0x750 [ 414.527945][ T2179] Call trace: [ 414.527949][ T2179] dpcmprocesspaths+0x5a4/0x750 [ 414.527955][ T2179] soccompropenfe+0xb0/0x2cc [ 414.527972][ T2179] sndcompropen+0x180/0x248 [ 414.527981][ T2179] sndopen+0x15c/0x194 [ 414.528003][ T2179] chrdevopen+0x1b0/0x220 [ 414.528023][ T2179] dodentryopen+0x30c/0x594 [ 414.528045][ T2179] vfsopen+0x34/0x44 [ 414.528053][ T2179] pathopenat+0x914/0xb08 [ 414.528062][ T2179] dofilpopen+0xc0/0x170 [ 414.528068][ T2179] dosysopenat2+0x94/0x18c [ 414.528076][ T2179] arm64sysopenat+0x78/0xa4 [ 414.528084][ T2179] invokesyscall+0x48/0x10c [ 414.528094][ T2179] el0svccommon+0xbc/0x104 [ 414.528099][ T2179] doel0svc+0x34/0xd8 [ 414.528103][ T2179] el0svc+0x34/0xc4 [ 414.528125][ T2179] el0t64synchandler+0x8c/0xfc [ 414.528133][ T2179] el0t64sync+0x1a0/0x1a4 [ 414.528142][ T2179] Kernel panic - not syncing: paniconwarn set ...
So, I reposition and add pcmmutex to resolve lockdep error.
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: fix mapping to non-allocated address
[Why] There is an issue mapping non-allocated location of memory. It would allocate gpio registers from an array out of bounds.
[How] Patch correct numbers of bounds for using.
In the Linux kernel, the following vulnerability has been resolved:
nfsd: clean up potential nfsdfile refcount leaks in COPY codepath
There are two different flavors of the nfsd4copy struct. One is embedded in the compound and is used directly in synchronous copies. The other is dynamically allocated, refcounted and tracked in the client struture. For the embedded one, the cleanup just involves releasing any nfsdfiles held on its behalf. For the async one, the cleanup is a bit more involved, and we need to dequeue it from lists, unhash it, etc.
There is at least one potential refcount leak in this code now. If the kthreadcreate call fails, then both the src and dst nfsdfiles in the original nfsd4copy object are leaked.
The cleanup in this codepath is also sort of weird. In the async copy case, we'll have up to four nfsdfile references (src and dst for both flavors of copy structure). They are both put at the end of nfsd4doasynccopy, even though the ones held on behalf of the embedded one outlive that structure.
Change it so that we always clean up the nfsdfile refs held by the embedded copy structure before nfsd4copy returns. Rework cleanupasynccopy to handle both inter and intra copies. Eliminate nfsd4cleanupintrassc since it now becomes a no-op.
In the Linux kernel, the following vulnerability has been resolved:
nvme-pci: fix mempool alloc size
Convert the max size to bytes to match the units of the divisor that calculates the worst-case number of PRP entries.
The result is used to determine how many PRP Lists are required. The code was previously rounding this to 1 list, but we can require 2 in the worst case. In that scenario, the driver would corrupt memory beyond the size provided by the mempool.
While unlikely to occur (you'd need a 4MB in exactly 127 phys segments on a queue that doesn't support SGLs), this memory corruption has been observed by kfence.
In the Linux kernel, the following vulnerability has been resolved:
erofs: validate the extent length for uncompressed pclusters
syzkaller reported a KASAN use-after-free: https://syzkaller.appspot.com/bug?extid=2ae90e873e97f1faf6f2
The referenced fuzzed image actually has two issues: - mpa == 0 as a non-inlined pcluster; - The logical length is longer than its physical length.
The first issue has already been addressed. This patch addresses the second issue by checking the extent length validity.
In the Linux kernel, the following vulnerability has been resolved:
net: add proper RCU protection to /proc/net/ptype
Yin Fengwei reported an RCU stall in ptypeseqshow() and provided a patch.
Real issue is that ptypeseqnext() and ptypeseqshow() violate RCU rules.
ptypeseqshow() runs under rcureadlock(), and reads pt->dev to get device name without any barrier.
At the same time, concurrent writers can remove a packettype structure (which is correctly freed after an RCU grace period) and clear pt->dev without an RCU grace period.
Define ptypeiterstate to carry a dev pointer along seqnetprivate:
struct ptypeiterstate { struct seqnetprivate p; struct netdevice dev; // added in this patch };
We need to record the device pointer in ptypegetidx() and ptypeseqnext() so that ptypeseqshow() is safe against concurrent pt->dev changes.
We also need to add full RCU protection in ptypeseqnext(). (Missing READONCE() when reading list.next values)
Many thanks to Dong Chenchen for providing a repro.
In the Linux kernel, the following vulnerability has been resolved:
RDMA/umad: Reject negative datalen in ibumadwrite
ibumadwrite computes datalen from user-controlled count and the MAD header sizes. With a mismatched user MAD header size and RMPP header length, datalen can become negative and reach ibcreatesendmad(). This can make the padding calculation exceed the segment size and trigger an out-of-bounds memset in allocsendrmpplist().
Add an explicit check to reject negative datalen before creating the send buffer.
KASAN splat: [ 211.363464] BUG: KASAN: slab-out-of-bounds in ibcreatesendmad+0xa01/0x11b0 [ 211.364077] Write of size 220 at addr ffff88800c3fa1f8 by task spraythread/102 [ 211.365867] ibcreatesendmad+0xa01/0x11b0 [ 211.365887] ibumadwrite+0x853/0x1c80
In the Linux kernel, the following vulnerability has been resolved:
RDMA/siw: Fix potential NULL pointer dereference in header processing
If siwgethdr() returns -EINVAL before setrxfpducontext(), qp->rxfpdu can be NULL. The error path in siwtcprxdata() dereferences qp->rxfpdu->moreddpsegs without checking, which may lead to a NULL pointer deref. Only check moreddpsegs when rxfpdu is present.
KASAN splat: [ 101.384271] KASAN: null-ptr-deref in range [0x00000000000000c0-0x00000000000000c7] [ 101.385869] RIP: 0010:siwtcprxdata+0x13ad/0x1e50
In the Linux kernel, the following vulnerability has been resolved:
net/sched: clsu32: use skbheaderpointercareful()
skbheaderpointer() does not fully validate negative @offset values.
Use skbheaderpointercareful() instead.
GangMin Kim provided a report and a repro fooling u32classify():
BUG: KASAN: slab-out-of-bounds in u32classify+0x1180/0x11b0 net/sched/clsu32.c:221
btrfs: send: check for inline extents in rangeisholeinparent()
In the Linux kernel, the following vulnerability has been resolved:
scsi: core: Wake up the error handler when final completions race against each other
The fragile ordering between marking commands completed or failed so that the error handler only wakes when the last running command completes or times out has race conditions. These race conditions can cause the SCSI layer to fail to wake the error handler, leaving I/O through the SCSI host stuck as the error state cannot advance.
First, there is an memory ordering issue within scsidechostbusy(). The write which clears SCMDSTATEINFLIGHT may be reordered with reads counting in scsihostbusy(). While the local CPU will see its own write, reordering can allow other CPUs in scsidechostbusy() or scsiehinchostfailed() to see a raised busy count, causing no CPU to see a host busy equal to the hostfailed count.
This race condition can be prevented with a memory barrier on the error path to force the write to be visible before counting host busy commands.
Second, there is a general ordering issue with scsiehinchostfailed(). By counting busy commands before incrementing hostfailed, it can race with a final command in scsidechostbusy(), such that scsidechostbusy() does not see hostfailed incremented but scsiehinchostfailed() counts busy commands before SCMDSTATEINFLIGHT is cleared by scsidechostbusy(), resulting in neither waking the error handler task.
This needs the call to scsihostbusy() to be moved after hostfailed is incremented to close the race condition.