IBM Security Verify Access uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information.
IBM Security Verify Access could allow an attacker with read-only privileges to make unauthorized modifications and deployments outside of their assigned permissions.
Quadratic complexity in node ID cache clearing
IBM Verify Identity Access 11.0 through 11.0.2 and IBM Security Verify Access 10.0 through 10.0.9.1 and IBM Verify Identity Access Container 11.0 through 11.0.2 and IBM Security Verify Access Container 10.0 through 10.0.9.1 could allow a remote attacker to conduct phishing attacks, caused by an open redirect vulnerability. An attacker could exploit this vulnerability using a specially crafted request to redirect a victim to arbitrary Web sites.
A transient execution vulnerability in some AMD processors may allow an attacker to infer data from previous stores, potentially resulting in the leakage of privileged information.
A transient execution vulnerability in some AMD processors may allow an attacker to infer data in the L1D cache, potentially resulting in the leakage of sensitive information across privileged boundaries.
In the Linux kernel, the following vulnerability has been resolved:
soc: qcom: cmd-db: Map shared memory as WC, not WB
Linux does not write into cmd-db region. This region of memory is write protected by XPU. XPU may sometime falsely detect clean cache eviction as "write" into the write protected region leading to secure interrupt which causes an endless loop somewhere in Trust Zone.
The only reason it is working right now is because Qualcomm Hypervisor maps the same region as Non-Cacheable memory in Stage 2 translation tables. The issue manifests if we want to use another hypervisor (like Xen or KVM), which does not know anything about those specific mappings.
Changing the mapping of cmd-db memory from MEMREMAPWB to MEMREMAPWT/WC removes dependency on correct mappings in Stage 2 tables. This patch fixes the issue by updating the mapping to MEMREMAPWC.
I tested this on SA8155P with Xen.
In the Linux kernel, the following vulnerability has been resolved:
iouring: check if we need to reschedule during overflow flush
In terms of normal application usage, this list will always be empty. And if an application does overflow a bit, it'll have a few entries. However, nothing obviously prevents syzbot from running a test case that generates a ton of overflow entries, and then flushing them can take quite a while.
Check for needing to reschedule while flushing, and drop our locks and do so if necessary. There's no state to maintain here as overflows always prune from head-of-list, hence it's fine to drop and reacquire the locks at the end of the loop.
In the Linux kernel, the following vulnerability has been resolved:
can: mcan: pci: add missing mcanclassfreedev() in probe/remove methods
In mcanpciremove() and error handling path of mcanpciprobe(), mcanclassfreedev() should be called to free resource allocated by mcanclassallocatedev(), otherwise there will be memleak.
In the Linux kernel, the following vulnerability has been resolved:
virtio/vsock: Fix acceptqueue memory leak
As the final stages of socket destruction may be delayed, it is possible that virtiotransportrecvlisten() will be called after the acceptqueue has been flushed, but before the SOCKDONE flag has been set. As a result, sockets enqueued after the flush would remain unremoved, leading to a memory leak.
vsockrelease vsockrelease lock virtiotransportrelease virtiotransportclose scheduledelayedwork(closework) skshutdown = SHUTDOWNMASK (!) flush acceptqueue release virtiotransportrecvpkt vsockfindboundsocket lock if flag(SOCKDONE) return virtiotransportrecvlisten child = vsockcreateconnected (!) vsockenqueueaccept(child) release closework lock virtiotransportdoclose setflag(SOCKDONE) virtiotransportremovesock vsockremovesock vsockremovebound release
Introduce a skshutdown check to disallow vsockenqueueaccept() during socket destruction.
unreferenced object 0xffff888109e3f800 (size 2040): comm "kworker/5:2", pid 371, jiffies 4294940105 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace (crc 9e5f4e84): [<ffffffff81418ff1>] kmemcacheallocnoprof+0x2c1/0x360 [<ffffffff81d27aa0>] skprotalloc+0x30/0x120 [<ffffffff81d2b54c>] skalloc+0x2c/0x4b0 [<ffffffff81fe049a>] vsockcreate.constprop.0+0x2a/0x310 [<ffffffff81fe6d6c>] virtiotransportrecvpkt+0x4dc/0x9a0 [<ffffffff81fe745d>] vsockloopbackwork+0xfd/0x140 [<ffffffff810fc6ac>] processonework+0x20c/0x570 [<ffffffff810fce3f>] workerthread+0x1bf/0x3a0 [<ffffffff811070dd>] kthread+0xdd/0x110 [<ffffffff81044fdd>] retfromfork+0x2d/0x50 [<ffffffff8100785a>] retfromforkasm+0x1a/0x30
In the Linux kernel, the following vulnerability has been resolved:
x86/xen: don't do PV iret hypercall through hypercall page
Instead of jumping to the Xen hypercall page for doing the iret hypercall, directly code the required sequence in xen-asm.S.
This is done in preparation of no longer using hypercall page at all, as it has shown to cause problems with speculation mitigations.
This is part of XSA-466 / CVE-2024-53241.
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix the qp flush warnings in req
When the qp is in error state, the status of WQEs in the queue should be set to error. Or else the following will appear.
[ 920.617269] WARNING: CPU: 1 PID: 21 at drivers/infiniband/sw/rxe/rxecomp.c:756 rxecompleter+0x989/0xcc0 [rdmarxe] [ 920.617744] Modules linked in: rnbdclient(O) rtrsclient(O) rtrscore(O) rdmaucm rdmacm iwcm ibcm crc32generic rdmarxe ip6udptunnel udptunnel ibuverbs ibcore loop brd nullblk ipv6 [ 920.618516] CPU: 1 PID: 21 Comm: ksoftirqd/1 Tainted: G O 6.1.113-storage+ #65 [ 920.618986] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [ 920.619396] RIP: 0010:rxecompleter+0x989/0xcc0 [rdmarxe] [ 920.619658] Code: 0f b6 84 24 3a 02 00 00 41 89 84 24 44 04 00 00 e9 2a f7 ff ff 39 ca bb 03 00 00 00 b8 0e 00 00 00 48 0f 45 d8 e9 15 f7 ff ff <0f> 0b e9 cb f8 ff ff 41 bf f5 ff ff ff e9 08 f8 ff ff 49 8d bc 24 [ 920.620482] RSP: 0018:ffff97b7c00bbc38 EFLAGS: 00010246 [ 920.620817] RAX: 0000000000000000 RBX: 000000000000000c RCX: 0000000000000008 [ 920.621183] RDX: ffff960dc396ebc0 RSI: 0000000000005400 RDI: ffff960dc4e2fbac [ 920.621548] RBP: 0000000000000000 R08: 0000000000000001 R09: ffffffffac406450 [ 920.621884] R10: ffffffffac4060c0 R11: 0000000000000001 R12: ffff960dc4e2f800 [ 920.622254] R13: ffff960dc4e2f928 R14: ffff97b7c029c580 R15: 0000000000000000 [ 920.622609] FS: 0000000000000000(0000) GS:ffff960ef7d00000(0000) knlGS:0000000000000000 [ 920.622979] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 920.623245] CR2: 00007fa056965e90 CR3: 00000001107f1000 CR4: 00000000000006e0 [ 920.623680] Call Trace: [ 920.623815] <TASK> [ 920.623933] ? warn+0x79/0xc0 [ 920.624116] ? rxecompleter+0x989/0xcc0 [rdmarxe] [ 920.624356] ? reportbug+0xfb/0x150 [ 920.624594] ? handlebug+0x3c/0x60 [ 920.624796] ? excinvalidop+0x14/0x70 [ 920.624976] ? asmexcinvalidop+0x16/0x20 [ 920.625203] ? rxecompleter+0x989/0xcc0 [rdmarxe] [ 920.625474] ? rxecompleter+0x329/0xcc0 [rdmarxe] [ 920.625749] rxedotask+0x80/0x110 [rdmarxe] [ 920.626037] rxerequester+0x625/0xde0 [rdmarxe] [ 920.626310] ? rxecqpost+0xe2/0x180 [rdmarxe] [ 920.626583] ? docomplete+0x18d/0x220 [rdmarxe] [ 920.626812] ? rxecompleter+0x1a3/0xcc0 [rdmarxe] [ 920.627050] rxedotask+0x80/0x110 [rdmarxe] [ 920.627285] taskletactioncommon.constprop.0+0xa4/0x120 [ 920.627522] handlesoftirqs+0xc2/0x250 [ 920.627728] ? sortrange+0x20/0x20 [ 920.627942] runksoftirqd+0x1f/0x30 [ 920.628158] smpbootthreadfn+0xc7/0x1b0 [ 920.628334] kthread+0xd6/0x100 [ 920.628504] ? kthreadcompleteandexit+0x20/0x20 [ 920.628709] retfromfork+0x1f/0x30 [ 920.628892] </TASK>
In the Linux kernel, the following vulnerability has been resolved:
crypto: pcrypt - Call crypto layer directly when padatadoparallel() return -EBUSY
Since commit 8f4f68e788c3 ("crypto: pcrypt - Fix hungtask for PADATARESET"), the pcrypt encryption and decryption operations return -EAGAIN when the CPU goes online or offline. In algtest(), a WARN is generated when pcryptaeaddecrypt() or pcryptaeadencrypt() returns -EAGAIN, the unnecessary panic will occur when paniconwarn set 1. Fix this issue by calling crypto layer directly without parallelization in that case.
In the Linux kernel, the following vulnerability has been resolved:
rtc: check if rtcreadtime was successful in rtctimerdowork()
If the rtcreadtime call fails,, the struct rtctime tm; may contain uninitialized data, or an illegal date/time read from the RTC hardware.
When calling rtctmtoktime later, the result may be a very large value (possibly KTIMEMAX). If there are periodic timers in rtc->timerqueue, they will continually expire, may causing kernel softlockup.
In the Linux kernel, the following vulnerability has been resolved:
ipvs: fix UB due to uninitialized stack access in ipvsprotocolinit()
Under certain kernel configurations when building with Clang/LLVM, the compiler does not generate a return or jump as the terminator instruction for ipvsprotocolinit(), triggering the following objtool warning during build time:
vmlinux.o: warning: objtool: ipvsprotocolinit() falls through to next function initstubkmodipvsrr935123ipvsrrinit6()
At runtime, this either causes an oops when trying to load the ipvs module or a boot-time panic if ipvs is built-in. This same issue has been reported by the Intel kernel test robot previously.
Digging deeper into both LLVM and the kernel code reveals this to be a undefined behavior problem. ipvsprotocolinit() uses a on-stack buffer of 64 chars to store the registered protocol names and leaves it uninitialized after definition. The function calls strnlen() when concatenating protocol names into the buffer. With CONFIGFORTIFYSOURCE strnlen() performs an extra step to check whether the last byte of the input char buffer is a null character (commit 3009f891bb9f ("fortify: Allow strlen() and strnlen() to pass compile-time known lengths")). This, together with possibly other configurations, cause the following IR to be generated:
define hidden i32 @ipvsprotocolinit() localunnamedaddr #5 section ".init.text" align 16 !kcfitype !29 { %1 = alloca [64 x i8], align 16 ...
14: ; preds = %11 %15 = getelementptr inbounds i8, ptr %1, i64 63 %16 = load i8, ptr %15, align 1 %17 = tail call i1 @llvm.is.constant.i8(i8 %16) %18 = icmp eq i8 %16, 0 %19 = select i1 %17, i1 %18, i1 false br i1 %19, label %20, label %23
20: ; preds = %14 %21 = call i64 @strlen(ptr noundef nonnull dereferenceable(1) %1) #23 ...
23: ; preds = %14, %11, %20 %24 = call i64 @strnlen(ptr noundef nonnull dereferenceable(1) %1, i64 noundef 64) #24 ... }
The above code calculates the address of the last char in the buffer (value %15) and then loads from it (value %16). Because the buffer is never initialized, the LLVM GVN pass marks value %16 as undefined:
%13 = getelementptr inbounds i8, ptr %1, i64 63 br i1 undef, label %14, label %17
This gives later passes (SCCP, in particular) more DCE opportunities by propagating the undef value further, and eventually removes everything after the load on the uninitialized stack location:
define hidden i32 @ipvsprotocolinit() localunnamedaddr #0 section ".init.text" align 16 !kcfitype !11 { %1 = alloca [64 x i8], align 16 ...
12: ; preds = %11 %13 = getelementptr inbounds i8, ptr %1, i64 63 unreachable }
In this way, the generated native code will just fall through to the next function, as LLVM does not generate any code for the unreachable IR instruction and leaves the function without a terminator.
Zero the on-stack buffer to avoid this possible UB.
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:
afs: Fix merge preference rule failure condition
syzbot reported a lock held when returning to userspace[1]. This is because if argc is less than 0 and the function returns directly, the held inode lock is not released.
Fix this by store the error in ret and jump to done to clean up instead of returning directly.
[dh: Modified Lizhi Xu's original patch to make it honour the error code from afssplitstring()]
[1] WARNING: lock held when returning to user space! 6.13.0-rc3-syzkaller-00209-g499551201b5f #0 Not tainted ------------------------------------------------ syz-executor133/5823 is leaving the kernel with locks still held! 1 lock held by syz-executor133/5823: #0: ffff888071cffc00 (&sb->stype->imutexkey#9){++++}-{4:4}, at: inodelock include/linux/fs.h:818 [inline] #0: ffff888071cffc00 (&sb->stype->imutexkey#9){++++}-{4:4}, at: afsprocaddrprefswrite+0x2bb/0x14e0 fs/afs/addrprefs.c:388
In the Linux kernel, the following vulnerability has been resolved:
cachestat: fix page cache statistics permission checking
When the 'cachestat()' system call was added in commit cf264e1329fb ("cachestat: implement cachestat syscall"), it was meant to be a much more convenient (and performant) version of mincore() that didn't need mapping things into the user virtual address space in order to work.
But it ended up missing the "check for writability or ownership" fix for mincore(), done in commit 134fca9063ad ("mm/mincore.c: make mincore() more conservative").
This just adds equivalent logic to 'cachestat()', modified for the file context (rather than vma).
In the Linux kernel, the following vulnerability has been resolved:
mm: clear uffd-wp PTE/PMD state on mremap()
When mremap()ing a memory region previously registered with userfaultfd as write-protected but without UFFDFEATUREEVENTREMAP, an inconsistency in flag clearing leads to a mismatch between the vma flags (which have uffd-wp cleared) and the pte/pmd flags (which do not have uffd-wp cleared). This mismatch causes a subsequent mprotect(PROTWRITE) to trigger a warning in pagetablecheckpteflags() due to setting the pte to writable while uffd-wp is still set.
Fix this by always explicitly clearing the uffd-wp pte/pmd flags on any such mremap() so that the values are consistent with the existing clearing of VMUFFDWP. Be careful to clear the logical flag regardless of its physical form; a PTE bit, a swap PTE bit, or a PTE marker. Cover PTE, huge PMD and hugetlb paths.
In the Linux kernel, the following vulnerability has been resolved:
can: isotp: sanitize CAN ID checks in isotpbind()
Syzbot created an environment that lead to a state machine status that can not be reached with a compliant CAN ID address configuration. The provided address information consisted of CAN ID 0x6000001 and 0xC28001 which both boil down to 11 bit CAN IDs 0x001 in sending and receiving.
Sanitize the SFF/EFF CAN ID values before performing the address checks.
In the Linux kernel, the following vulnerability has been resolved:
efi: Do not import certificates from UEFI Secure Boot for T2 Macs
On Apple T2 Macs, when Linux attempts to read the db and dbx efi variables at early boot to load UEFI Secure Boot certificates, a page fault occurs in Apple firmware code and EFI runtime services are disabled with the following logs:
[Firmware Bug]: Page fault caused by firmware at PA: 0xffffb1edc0068000 WARNING: CPU: 3 PID: 104 at arch/x86/platform/efi/quirks.c:735 eficrashgracefullyonpagefault+0x50/0xf0 (Removed some logs from here) Call Trace: <TASK> pagefaultoops+0x4f/0x2c0 ? searchbpfextables+0x6b/0x80 ? searchmoduleextables+0x50/0x80 ? searchexceptiontables+0x5b/0x60 kernelmodefixuporoops+0x9e/0x110 badareanosemaphore+0x155/0x190 badareanosemaphore+0x16/0x20 dokernaddrfault+0x8c/0xa0 excpagefault+0xd8/0x180 asmexcpagefault+0x1e/0x30 (Removed some logs from here) ? eficall+0x28/0x30 ? switchmm+0x20/0x30 ? eficallrts+0x19a/0x8e0 ? processonework+0x222/0x3f0 ? workerthread+0x4a/0x3d0 ? kthread+0x17a/0x1a0 ? processonework+0x3f0/0x3f0 ? setkthreadstruct+0x40/0x40 ? retfromfork+0x22/0x30 </TASK> ---[ end trace 1f82023595a5927f ]--- efi: Froze efirtswq and disabled EFI Runtime Services integrity: Couldn't get size: 0x8000000000000015 integrity: MODSIGN: Couldn't get UEFI db list efi: EFI Runtime Services are disabled! integrity: Couldn't get size: 0x8000000000000015 integrity: Couldn't get UEFI dbx list integrity: Couldn't get size: 0x8000000000000015 integrity: Couldn't get mokx list integrity: Couldn't get size: 0x80000000
So we avoid reading these UEFI variables and thus prevent the crash.
In the Linux kernel, the following vulnerability has been resolved:
powerpc/paprscm: don't requests stats with '0' sized stats buffer
Sachin reported [1] that on a POWER-10 lpar he is seeing a kernel panic being reported with vPMEM when paprscm probe is being called. The panic is of the form below and is observed only with following option disabled(profile) for the said LPAR 'Enable Performance Information Collection' in the HMC:
Kernel attempted to write user page (1c) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on write at 0x0000001c Faulting instruction address: 0xc008000001b90844 Oops: Kernel access of bad area, sig: 11 [#1] <snip> NIP [c008000001b90844] drcpmemquerystats+0x5c/0x270 [paprscm] LR [c008000001b92794] paprscmprobe+0x2ac/0x6ec [paprscm] Call Trace: 0xc00000000941bca0 (unreliable) paprscmprobe+0x2ac/0x6ec [paprscm] platformprobe+0x98/0x150 reallyprobe+0xfc/0x510 driverprobedevice+0x17c/0x230 <snip> ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception
On investigation looks like this panic was caused due to a 'statbuffer' of size==0 being provided to drcpmemquerystats() to fetch all performance stats-ids of an NVDIMM. However drcpmemquerystats() shouldn't have been called since the vPMEM NVDIMM doesn't support and performance stat-id's. This was caused due to missing check for 'p->statbufferlen' at the beginning of paprscmpmucheckevents() which indicates that the NVDIMM doesn't support performance-stats.
Fix this by introducing the check for 'p->statbufferlen' at the beginning of paprscmpmucheckevents().
[1] https://lore.kernel.org/all/6B3A522A-6A5F-4CC9-B268-0C63AA6E07D3@linux.ibm.com
In the Linux kernel, the following vulnerability has been resolved:
powerpc/xics: fix refcount leak in icpopalinit()
The offindcompatiblenode() function returns a node pointer with refcount incremented, use ofnodeput() on it when done.
In the Linux kernel, the following vulnerability has been resolved:
powerpc/xive: Fix refcount leak in xivespaprinit
offindcompatiblenode() returns a node pointer with refcount incremented, we should use ofnodeput() on it when done. Add missing ofnodeput() to avoid refcount leak.
In the Linux kernel, the following vulnerability has been resolved:
tracing/histograms: Fix memory leak problem
This reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac.
As commit 46bbe5c671e0 ("tracing: fix double free") said, the "double free" problem reported by clang static analyzer is: In parsevardefs() if there is a problem allocating vardefs.expr, the earlier vardefs.name is freed. This free is duplicated by freevardefs() which frees the rest of the list.
However, if there is a problem allocating N-th vardefs.expr: + in parsevardefs(), the freed 'earlier vardefs.name' is actually the N-th vardefs.name; + then in freevardefs(), the names from 0th to (N-1)-th are freed;
IF ALLOCATING PROBLEM HAPPENED HERE!!! -+ \ | 0th 1th (N-1)-th N-th V +-------------+-------------+-----+-------------+----------- vardefs: | name | expr | name | expr | ... | name | expr | name | /// +-------------+-------------+-----+-------------+-----------
These two frees don't act on same name, so there was no "double free" problem before. Conversely, after that commit, we get a "memory leak" problem because the above "N-th vardefs.name" is not freed.
If enable CONFIGDEBUGKMEMLEAK and inject a fault at where the N-th vardefs.expr allocated, then execute on shell like: $ echo 'hist:key=callsite:val=$v1,$v2:v1=bytesreq,v2=bytesalloc' \ /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger
Then kmemleak reports: unreferenced object 0xffff8fb100ef3518 (size 8): comm "bash", pid 196, jiffies 4295681690 (age 28.538s) hex dump (first 8 bytes): 76 31 00 00 b1 8f ff ff v1...... backtrace: [0000000038fe4895] kstrdup+0x2d/0x60 [00000000c99c049a] eventhisttriggerparse+0x206f/0x20e0 [00000000ae70d2cc] triggerprocessregex+0xc0/0x110 [0000000066737a4c] eventtriggerwrite+0x75/0xd0 [000000007341e40c] vfswrite+0xbb/0x2a0 [0000000087fde4c2] ksyswrite+0x59/0xd0 [00000000581e9cdf] dosyscall64+0x3a/0x80 [00000000cf3b065c] entrySYSCALL64afterhwframe+0x46/0xb0
In the Linux kernel, the following vulnerability has been resolved:
ima: Fix potential memory leak in imainitcrypto()
On failure to allocate the SHA1 tfm, IMA fails to initialize and exits without freeing the imaalgoarray. Add the missing kfree() for imaalgoarray to avoid the potential memory leak.
In the Linux kernel, the following vulnerability has been resolved:
usbnet: fix memory leak in error case
usbnetwritecmdasync() mixed up which buffers need to be freed in which error case.
v2: add Fixes tag v3: fix uninitialized buf pointer
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btbcm: Fix NULL deref in btbcmgetboardname()
devmkstrdup() can return a NULL pointer on failure,but this returned value in btbcmgetboardname() is not checked. Add NULL check in btbcmgetboardname(), to handle kernel NULL pointer dereference error.
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btrtl: check for NULL in btrtlsetuprealtek()
If insert an USB dongle which chip is not maintained in icidtable, it will hit the NULL point accessed. Add a null point check to avoid the Kernel Oops.
In the Linux kernel, the following vulnerability has been resolved:
usb: xhci: Fix NULL pointer dereference on certain command aborts
If a command is queued to the final usable TRB of a ring segment, the enqueue pointer is advanced to the subsequent link TRB and no further. If the command is later aborted, when the abort completion is handled the dequeue pointer is advanced to the first TRB of the next segment.
If no further commands are queued, xhcihandlestoppedcmdring() sees the ring pointers unequal and assumes that there is a pending command, so it calls xhcimodcmdtimer() which crashes if curcmd was NULL.
Don't attempt timer setup if curcmd is NULL. The subsequent doorbell ring likely is unnecessary too, but it's harmless. Leave it alone.
This is probably Bug 219532, but no confirmation has been received.
The issue has been independently reproduced and confirmed fixed using a USB MCU programmed to NAK the Status stage of SETADDRESS forever. Everything continued working normally after several prevented crashes.