IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 may be vulnerable to audit log forgery.

IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 are vulnerable to cross-site scripting. This vulnerability allows an authenticated user to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session.

IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 could allow an authenticated user to cause a denial of service using a specially crafted HTTP query due to improper allocation of system resources

IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 local management interface in certain configurations is vulnerable to cross-site scripting. This vulnerability allows an authenticated user to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session.

IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 could allow a remote authenticated attacker to modify data and cause a denial of service due to an SQL injection vulnerability.

IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 could allow a remote authenticated attacker to bypass additional authentication workflow steps.

IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 could allow a denial of service due to a heap-based out-of-bounds read. A remote attacker could send a specially crafted request that causes a limited out‑of‑bounds memory read.

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()

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 ...

IBM Security Verify Access Appliance and Docker 10.0 through 10.0.8 could allow a remote attacker to enumerate usernames due to an observable response discrepancy of disabled accounts.

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.