IBM Security Verify could allow a remote attacker to obtain sensitive information when a detailed technical error message is returned in the browser.  This information could be used in further attacks against the system.

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 obtain sensitive information when a detailed technical error message is returned in the browser. This information could be used in further attacks against the system.

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.

IBM Security Verify Access could allow an attacker with read-only privileges to make unauthorized modifications and deployments outside of their assigned permissions.

IBM Security Verify Access uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information.

IBM Security Verify Access allows certificate listings retrieved via a browser session to return a JSON payload while incorrectly specifying the response Content-Type as text/html. Because the content is delivered with an HTML MIME type, browsers may interpret the JSON data as executable script under certain conditions. This creates an opportunity for JavaScript injection, potentially leading to cross-site scripting (XSS).

IBM Verify Identity Access Container 11.0 through 11.0.2 and IBM Security Verify Access Container 10.0 through 10.0.9.1 and IBM Verify Identity Access 11.0 through 11.0.2 and IBM Security Verify Access 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.

IBM Verify Identity Access Container 11.0 through 11.0.2 and IBM Security Verify Access Container 10.0 through 10.0.9.1 and IBM Verify Identity Access 11.0 through 11.0.2 and IBM Security Verify Access 10.0 through 10.0.9.1 IBM Security Verify could allow a remote attacker to access sensitive information due to an inconsistent interpretation of an HTTP request by a reverse proxy.

IBM Verify Identity Access Container 11.0 through 11.0.2 and IBM Security Verify Access Container 10.0 through 10.0.9.1 and IBM Verify Identity Access 11.0 through 11.0.2 and IBM Security Verify Access 10.0 through 10.0.9.1 IBM Security Verify could allow a remote attacker to access sensitive information due to an inconsistent interpretation of an HTTP request by a reverse proxy.

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

mm/damon/sysfs: cleanup attrs subdirs on context dir setup failure

When a context DAMON sysfs directory setup is failed after setup of attrs/ directory, subdirectories of attrs/ directory are not cleaned up. As a result, DAMON sysfs interface is nearly broken until the system reboots, and the memory for the unremoved directory is leaked.

Cleanup the directories under such failures.

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

Bluetooth: hcisock: Prevent race in socket write iter and sock bind

There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmtpending before write iter sends the cmd, just as syzbot reported in UAF[1].

Here we use hcidevlock to synchronize the two, thereby avoiding the UAF mentioned in [1].

[1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmtpendingremove+0x3b/0x210 net/bluetooth/mgmtutil.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmtpendingremove+0x3b/0x210 net/bluetooth/mgmtutil.c:316 setlinksecurity+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hcimgmtcmd+0x9c9/0xef0 net/bluetooth/hcisock.c:1719 hcisocksendmsg+0x6ca/0xef0 net/bluetooth/hcisock.c:1839 socksendmsgnosec net/socket.c:727 [inline] socksendmsg+0x21c/0x270 net/socket.c:742 sockwriteiter+0x279/0x360 net/socket.c:1195

Allocated by task 5989: mgmtpendingadd+0x35/0x140 net/bluetooth/mgmtutil.c:296 setlinksecurity+0x557/0x710 net/bluetooth/mgmt.c:1910 hcimgmtcmd+0x9c9/0xef0 net/bluetooth/hcisock.c:1719 hcisocksendmsg+0x6ca/0xef0 net/bluetooth/hcisock.c:1839 socksendmsgnosec net/socket.c:727 [inline] socksendmsg+0x21c/0x270 net/socket.c:742 sockwriteiter+0x279/0x360 net/socket.c:1195

Freed by task 5991: mgmtpendingfree net/bluetooth/mgmtutil.c:311 [inline] mgmtpendingforeach+0x30d/0x380 net/bluetooth/mgmtutil.c:257 mgmtindexremoved+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hcisockbind+0xbe9/0x1000 net/bluetooth/hcisock.c:1314

Bluetooth: MGMT: Fix OOB access in parseadvmonitorpattern()

Quadratic complexity in node ID cache clearing

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

mm: slub: avoid wake up kswapd in settrackprepare

settrackprepare() can incur lock recursion. The issue is that it is called from hrtimerstartrangens holding the percpu(hrtimerbases)[n].lock, but when enabled CONFIGDEBUGOBJECTSTIMERS, may wake up kswapd in settrackprepare, and try to hold the percpu(hrtimerbases)[n].lock.

Avoid deadlock caused by implicitly waking up kswapd by passing in allocation flags, which do not contain GFPKSWAPDRECLAIM in the debugobjectsfillpool() case. Inside stack depot they are processed by gfpnestedmask(). Since slaballoc() has preemption disabled, we mask out GFPDIRECTRECLAIM from the flags there.

The oops looks something like:

BUG: spinlock recursion on CPU#3, swapper/3/0 lock: 0xffffff8a4bf29c80, .magic: dead4ead, .owner: swapper/3/0, .ownercpu: 3 Hardware name: Qualcomm Technologies, Inc. Popsicle based on SM8850 (DT) Call trace: spinbug+0x0 rawspinlockirqsave+0x80 hrtimertrytocancel+0x94 taskcontending+0x10c enqueuedlentity+0x2a4 dlserverstart+0x74 enqueuetaskfair+0x568 enqueuetask+0xac doactivatetask+0x14c ttwudoactivate+0xcc trytowakeup+0x6c8 defaultwakefunction+0x20 autoremovewakefunction+0x1c wakeup+0xac wakeupkswapd+0x19c wakeallkswapds+0x78 allocpagesslowpath+0x1ac allocpagesnoprof+0x298 stackdepotsaveflags+0x6b0 stackdepotsave+0x14 settrackprepare+0x5c slaballoc+0xccc kmalloccachenoprof+0x470 setpageowner+0x2bc postallochook[jt]+0x1b8 prepnewpage+0x28 getpagefromfreelist+0x1edc allocpagesnoprof+0x13c allocslabpage+0x244 allocateslab+0x7c slaballoc+0x8e8 kmemcacheallocnoprof+0x450 debugobjectsfillpool+0x22c debugobjectactivate+0x40 enqueuehrtimer[jt]+0xdc hrtimerstartrangens+0x5f8 ...

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

usb: typec: ucsi: displayport: Fix NULL pointer access

This patch ensures that the UCSI driver waits for all pending tasks in the ucsidisplayportwork workqueue to finish executing before proceeding with the partner removal.

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

can: j1939: j1939sendone(): fix missing CAN header initialization

The read access to struct canxlframe::len inside of a j1939 created skbuff revealed a missing initialization of reserved and later filled elements in struct canframe.

This patch initializes the 8 byte CAN header with zero.

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

mm/migratedevice: don't add folio to be freed to LRU in migratedevicefinalize()

If migration succeeded, we called foliomigrateflags()->memcgroupmigrate() to migrate the memcg from the old to the new folio. This will set memcgdata of the old folio to 0.

Similarly, if migration failed, memcgdata of the dst folio is left unset.

If we call folioputbacklru() on such folios (memcgdata == 0), we will add the folio to be freed to the LRU, making memcg code unhappy. Running the hmm selftests:

# ./hmm-tests ... # RUN hmm.hmmdeviceprivate.migrate ... [ 102.078007][T14893] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7ff27d200 pfn:0x13cc00 [ 102.079974][T14893] anon flags: 0x17ff00000020018(uptodate|dirty|swapbacked|node=0|zone=2|lastcpupid=0x7ff) [ 102.082037][T14893] raw: 017ff00000020018 dead000000000100 dead000000000122 ffff8881353896c9 [ 102.083687][T14893] raw: 00000007ff27d200 0000000000000000 00000001ffffffff 0000000000000000 [ 102.085331][T14893] page dumped because: VMWARNONONCEFOLIO(!memcg && !memcgroupdisabled()) [ 102.087230][T14893] ------------[ cut here ]------------ [ 102.088279][T14893] WARNING: CPU: 0 PID: 14893 at ./include/linux/memcontrol.h:726 foliolruveclockirqsave+0x10e/0x170 [ 102.090478][T14893] Modules linked in: [ 102.091244][T14893] CPU: 0 UID: 0 PID: 14893 Comm: hmm-tests Not tainted 6.13.0-09623-g6c216bc522fd #151 [ 102.093089][T14893] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 [ 102.094848][T14893] RIP: 0010:foliolruveclockirqsave+0x10e/0x170 [ 102.096104][T14893] Code: ... [ 102.099908][T14893] RSP: 0018:ffffc900236c37b0 EFLAGS: 00010293 [ 102.101152][T14893] RAX: 0000000000000000 RBX: ffffea0004f30000 RCX: ffffffff8183f426 [ 102.102684][T14893] RDX: ffff8881063cb880 RSI: ffffffff81b8117f RDI: ffff8881063cb880 [ 102.104227][T14893] RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000 [ 102.105757][T14893] R10: 0000000000000001 R11: 0000000000000002 R12: ffffc900236c37d8 [ 102.107296][T14893] R13: ffff888277a2bcb0 R14: 000000000000001f R15: 0000000000000000 [ 102.108830][T14893] FS: 00007ff27dbdd740(0000) GS:ffff888277a00000(0000) knlGS:0000000000000000 [ 102.110643][T14893] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 102.111924][T14893] CR2: 00007ff27d400000 CR3: 000000010866e000 CR4: 0000000000750ef0 [ 102.113478][T14893] PKRU: 55555554 [ 102.114172][T14893] Call Trace: [ 102.114805][T14893] <TASK> [ 102.115397][T14893] ? foliolruveclockirqsave+0x10e/0x170 [ 102.116547][T14893] ? warn.cold+0x110/0x210 [ 102.117461][T14893] ? foliolruveclockirqsave+0x10e/0x170 [ 102.118667][T14893] ? reportbug+0x1b9/0x320 [ 102.119571][T14893] ? handlebug+0x54/0x90 [ 102.120494][T14893] ? excinvalidop+0x17/0x50 [ 102.121433][T14893] ? asmexcinvalidop+0x1a/0x20 [ 102.122435][T14893] ? wakeupklogd.part.0+0x76/0xd0 [ 102.123506][T14893] ? dumppage+0x4f/0x60 [ 102.124352][T14893] ? foliolruveclockirqsave+0x10e/0x170 [ 102.125500][T14893] foliobatchmovelru+0xd4/0x200 [ 102.126577][T14893] ? pfxlruadd+0x10/0x10 [ 102.127505][T14893] foliobatchaddandmove+0x391/0x720 [ 102.128633][T14893] ? pfxlruadd+0x10/0x10 [ 102.129550][T14893] folioputbacklru+0x16/0x80 [ 102.130564][T14893] migratedevicefinalize+0x9b/0x530 [ 102.131640][T14893] dmirrormigratetodevice.constprop.0+0x7c5/0xad0 [ 102.133047][T14893] dmirrorfopsunlockedioctl+0x89b/0xc80

Likely, nothing else goes wrong: putting the last folio reference will remove the folio from the LRU again. So besides memcg complaining, adding the folio to be freed to the LRU is just an unnecessary step.

The new flow resembles what we have in migratefoliomove(): add the dst to the lru, rem ---truncated---

bpf: avoid holding freezemutex during mmap operation

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

nfp: bpf: Add check for nfpappctrlmsgalloc()

Add check for the return value of nfpappctrlmsgalloc() in nfpbpfcmsgalloc() to prevent null pointer dereference.

ASoC: SOF: stream-ipc: Check for cstream nullity in sofipcmsgdata()

acct: perform last write from workqueue

bpf: Fix deadlock when freeing cgroup storage

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.

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.

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

ASoC: soc-pcm: don't use socpcmret() on .prepare callback

commit 1f5664351410 ("ASoC: lower "no backend DAIs enabled for ... Port" log severity") ignores -EINVAL error message on common socpcmret(). It is used from many functions, ignoring -EINVAL is over-kill.

The reason why -EINVAL was ignored was it really should only be used upon invalid parameters coming from userspace and in that case we don't want to log an error since we do not want to give userspace a way to do a denial-of-service attack on the syslog / diskspace.

So don't use socpcmret() on .prepare callback is better idea.

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

OPP: fix devpmoppfindbw() when bandwidth table not initialized

If a driver calls devpmoppfindbwceil/floor() the retrieve bandwidth from the OPP table but the bandwidth table was not created because the interconnect properties were missing in the OPP consumer node, the kernel will crash with:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 ... pc : readbw+0x8/0x10 lr : opptablefindkey+0x9c/0x174 ... Call trace: readbw+0x8/0x10 (P) opptablefindkey+0x9c/0x174 (L) findkey+0x98/0x168 devpmoppfindbwceil+0x50/0x88 ...

In order to fix the crash, create an assert function to check if the bandwidth table was created before trying to get a bandwidth with readbw().

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

wifi: iwlwifi: mvm: avoid NULL pointer dereference

When iterating over the links of a vif, we need to make sure that the pointer is valid (in other words - that the link exists) before dereferncing it. Use foreachvifactivelink that also does the check.

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

idpf: convert workqueues to unbound

When a workqueue is created with WQUNBOUND, its work items are served by special worker-pools, whose host workers are not bound to any specific CPU. In the default configuration (i.e. when queuedelayedwork and friends do not specify which CPU to run the work item on), WQUNBOUND allows the work item to be executed on any CPU in the same node of the CPU it was enqueued on. While this solution potentially sacrifices locality, it avoids contention with other processes that might dominate the CPU time of the processor the work item was scheduled on.

This is not just a theoretical problem: in a particular scenario misconfigured process was hogging most of the time from CPU0, leaving less than 0.5% of its CPU time to the kworker. The IDPF workqueues that were using the kworker on CPU0 suffered large completion delays as a result, causing performance degradation, timeouts and eventual system crash.

I have also run a manual test to gauge the performance improvement. The test consists of an antagonist process (./stress --cpu 2) consuming as much of CPU 0 as possible. This process is run under taskset 01 to bind it to CPU0, and its priority is changed with chrt -pQ 9900 10000 ${pid} and renice -n -20 ${pid} after start.

Then, the IDPF driver is forced to prefer CPU0 by editing all calls to queuedelayedwork, moddelayedwork, etc... to use CPU 0.

Finally, ktraces for the workqueue events are collected.

Without the current patch, the antagonist process can force arbitrary delays between workqueuequeuework and workqueueexecutestart, that in my tests were as high as 30ms. With the current patch applied, the workqueue can be migrated to another unloaded CPU in the same node, and, keeping everything else equal, the maximum delay I could see was 6us.

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:

vxlan: check vxlanvnigroupinit() return value

vxlaninit() must check vxlanvnigroupinit() success otherwise a crash happens later, spotted by syzbot.

Oops: general protection fault, probably for non-canonical address 0xdffffc000000002c: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000160-0x0000000000000167] CPU: 0 UID: 0 PID: 7313 Comm: syz-executor147 Not tainted 6.14.0-rc1-syzkaller-00276-g69b54314c975 #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:vxlanvnigroupuninit+0x89/0x500 drivers/net/vxlan/vxlanvnifilter.c:912 Code: 00 48 8b 44 24 08 4c 8b b0 98 41 00 00 49 8d 86 60 01 00 00 48 89 c2 48 89 44 24 10 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4d 04 00 00 49 8b 86 60 01 00 00 48 ba 00 00 00 RSP: 0018:ffffc9000cc1eea8 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000001 RCX: ffffffff8672effb RDX: 000000000000002c RSI: ffffffff8672ecb9 RDI: ffff8880461b4f18 RBP: ffff8880461b4ef4 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000020000 R13: ffff8880461b0d80 R14: 0000000000000000 R15: dffffc0000000000 FS: 00007fecfa95d6c0(0000) GS:ffff88806a600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fecfa95cfb8 CR3: 000000004472c000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> vxlanuninit+0x1ab/0x200 drivers/net/vxlan/vxlancore.c:2942 unregisternetdevicemanynotify+0x12d6/0x1f30 net/core/dev.c:11824 unregisternetdevicemany net/core/dev.c:11866 [inline] unregisternetdevicequeue+0x307/0x3f0 net/core/dev.c:11736 registernetdevice+0x1829/0x1eb0 net/core/dev.c:10901 vxlandevcreate+0x7c6/0xa30 drivers/net/vxlan/vxlancore.c:3981 vxlannewlink+0xd1/0x130 drivers/net/vxlan/vxlancore.c:4407 rtnlnewlinkcreate net/core/rtnetlink.c:3795 [inline] rtnlnewlink net/core/rtnetlink.c:3906 [inline]