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 perform unauthorized actions due to argument injection.
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 attacker with administrative privileges and access to the local management interface to execute arbitrary code due to an unbounded write to a fixed-size stack buffer.
IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 is vulnerable to an information disclosure attack.
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 security restrictions due to improper authentication.
IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 may not enforce authorization correctly for some web servers.
IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 is vulnerable to cross-site scripting. This vulnerability allows an unauthenticated 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 attacker to perform an arbitrary file write due to path traversal.
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 execute arbitrary commands due to improper neutralization of command arguments.
IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 is vulnerable to cross-site request forgery which could allow an attacker to execute malicious and unauthorized actions transmitted from a user that the website trusts.
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 attacker to cause a denial of service due to uncontrolled recursion.
IBM Verify Identity Access could allow an administrator to execute additional commands they are not entitled to due to improper validation of user supplied requests.
IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 and IBM Verify Identity Access Container 11.0 through 11.0.3 Reverse Proxy in certain configurations may provide weaker than expected cryptographic validation of user supplied data.
IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 and IBM Verify Identity Access Container 11.0 through 11.0.3 could allow a remote attacker to access sensitive information due to an inconsistent interpretation of an HTTP request by a reverse proxy.
IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 and IBM Verify Identity Access Container 11.0 through 11.0.3 could allow an administrator to execute additional commands they are not entitled to due to improper validation of user supplied input.
IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 and IBM Verify Identity Access Container 11.0 through 11.0.3 is vulnerable to a denial of service attack.
IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 and IBM Verify Identity Access Container 11.0 through 11.0.3 contains a input validation vulnerability in the management interface that allows already privileged attackers to execute additional operations by crafting a malicious HTTP request.
IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 and IBM Verify Identity Access Container 11.0 through 11.0.3 contains a format string injection vulnerability in the management interface that allows attackers to cause denial of service and information disclosure by crafting a malicious HTTP request.
IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 and IBM Verify Identity Access Container 11.0 through 11.0.3 could allow an authenticated user to gain privileges of another user via a specially crafted request.
In Eclipse Parsson published Maven Central artifacts before version 1.1.8, the JSON parser did not enforce a default maximum on the number of characters consumed while parsing a single JSON document. Applications that parse attacker- controlled JSON can be forced to consume excessive CPU and memory by processing very large documents, including large arrays, objects, strings, numbers, whitespace, or nested structures, resulting in a denial of service. Eclipse Parsson 1.1.8 introduces a configurable maximum parsing limit with a default limit of 15 million parser-consumed characters.
crypto: algifaead - Revert to operating out-of-place
IBM Security Verify Access Container could allow an unauthenticated user to execute arbitrary commands as lower user privileges on the system due to improper validation of user supplied input.
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 locally authenticated user to execute malicious scripts from outside of its control sphere.
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 allows an attacker to contact internal authentication endpoints which are protected by the Reverse Proxy.
In the Linux kernel, the following vulnerability has been resolved:
net/sched: Only allow actct to bind to clsact/ingress qdiscs and shared blocks
As Paolo said earlier [1]:
"Since the blamed commit below, classify can return TCACTCONSUMED while the current skb being held by the defragmentation engine. As reported by GangMin Kim, if such packet is that may cause a UaF when the defrag engine later on tries to tuch again such packet."
actct was never meant to be used in the egress path, however some users are attaching it to egress today [2]. Attempting to reach a middle ground, we noticed that, while most qdiscs are not handling TCACTCONSUMED, clsact/ingress qdiscs are. With that in mind, we address the issue by only allowing actct to bind to clsact/ingress qdiscs and shared blocks. That way it's still possible to attach actct to egress (albeit only with clsact).
[1]
In the Linux kernel, the following vulnerability has been resolved:
macvlan: fix error recovery in macvlancommonnewlink()
valis provided a nice repro to crash the kernel:
ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2
ip link add mv0 link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20
ping -c1 -I p1 1.2.3.4
He also gave a very detailed analysis:
<quote valis>
The issue is triggered when a new macvlan link is created with MACVLANMODESOURCE mode and MACVLANMACADDRADD (or MACVLANMACADDRSET) parameter, lower device already has a macvlan port and registernetdevice() called from macvlancommonnewlink() fails (e.g. because of the invalid link name).
In this case macvlanhashaddsource is called from macvlanchangesources() / macvlancommonnewlink():
This adds a reference to vlan to the port's vlansourcehash using macvlansourceentry.
vlan is a pointer to the priv data of the link that is being created.
When registernetdevice() fails, the error is returned from macvlannewlink() to rtnlnewlinkcreate():
if (ops->newlink) err = ops->newlink(dev, ¶ms, extack); else err = registernetdevice(dev); if (err < 0) { freenetdev(dev); goto out; }
and freenetdev() is called, causing a kvfree() on the struct netdevice that is still referenced in the source entry attached to the lower device's macvlan port.
Now all packets sent on the macvlan port with a matching source mac address will trigger a use-after-free in macvlanforwardsource().
</quote valis>
With all that, my fix is to make sure we call macvlanflushsources() regardless of @create value whenever "goto destroymacvlanport;" path is taken.
Many thanks to valis for following up on this issue.
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
In the Linux kernel, the following vulnerability has been resolved:
scsi: target: iscsi: Fix use-after-free in iscsitdecsessionusagecount()
In iscsitdecsessionusagecount(), the function calls complete() while holding the sess->sessionusagelock. Similar to the connection usage count logic, the waiter signaled by complete() (e.g., in the session release path) may wake up and free the iscsitsession structure immediately.
This creates a race condition where the current thread may attempt to execute spinunlockbh() on a session structure that has already been deallocated, resulting in a KASAN slab-use-after-free.
To resolve this, release the sessionusagelock before calling complete() to ensure all dereferences of the sess pointer are finished before the waiter is allowed to proceed with deallocation.
ALSA: aloop: Fix racy access at PCM trigger
bonding: fix use-after-free due to enslave fail after slave array update
In the Linux kernel, the following vulnerability has been resolved:
libceph: reset sparse-read state in osdfault()
When a fault occurs, the connection is abandoned, reestablished, and any pending operations are retried. The OSD client tracks the progress of a sparse-read reply using a separate state machine, largely independent of the messenger's state.
If a connection is lost mid-payload or the sparse-read state machine returns an error, the sparse-read state is not reset. The OSD client will then interpret the beginning of a new reply as the continuation of the old one. If this makes the sparse-read machinery enter a failure state, it may never recover, producing loops like:
libceph: [0] got 0 extents libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on read libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on read
Therefore, reset the sparse-read state in osdfault(), ensuring retries start from a clean state.