| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix memory access flags in helper prototypes
After commit 37cce22dbd51 ("bpf: verifier: Refactor helper access type tracking"),
the verifier started relying on the access type flags in helper
function prototypes to perform memory access optimizations.
Currently, several helper functions utilizing ARG_PTR_TO_MEM lack the
corresponding MEM_RDONLY or MEM_WRITE flags. This omission causes the
verifier to incorrectly assume that the buffer contents are unchanged
across the helper call. Consequently, the verifier may optimize away
subsequent reads based on this wrong assumption, leading to correctness
issues.
For bpf_get_stack_proto_raw_tp, the original MEM_RDONLY was incorrect
since the helper writes to the buffer. Change it to ARG_PTR_TO_UNINIT_MEM
which correctly indicates write access to potentially uninitialized memory.
Similar issues were recently addressed for specific helpers in commit
ac44dcc788b9 ("bpf: Fix verifier assumptions of bpf_d_path's output buffer")
and commit 2eb7648558a7 ("bpf: Specify access type of bpf_sysctl_get_name args").
Fix these prototypes by adding the correct memory access flags. |
| free5GC is an open-source implementation of the 5G core network. Prior to 4.2.2, free5GC's PCF POST /npcf-smpolicycontrol/v1/sm-policies handler (HandleCreateSmPolicyRequest) panics with a nil-pointer dereference when a downstream OpenAPI consumer call (UDR lookup) returns 404 Not Found and the consumer wrapper returns err != nil together with a nil response struct. The handler logs the OpenAPI error and continues executing instead of returning, then dereferences the nil response struct on a subsequent line and panics. Gin recovery converts the panic into HTTP 500, so a single attacker-shaped POST returns 500 instead of a clean 4xx whenever the downstream lookup fails. The PCF process keeps running. The trigger is a single POST containing input that causes the downstream UDR lookup to fail (e.g. an unknown DNN). In 4.2.1 this endpoint is also reachable WITHOUT an Authorization header because the PCF Npcf_SMPolicyControl route group is mounted without inbound auth middleware. This vulnerability is fixed in 4.2.2. |
| WeGIA is a web manager for charitable institutions. In versions prior to 3.7.3, when a user logs in, html/login.php hashes the submitted password using PHP's hash() function with the SHA-256 algorithm and no salt before comparing it to the stored value. The password change flow in controle/FuncionarioControle.php follows the same pattern. SHA-256 is a general-purpose cryptographic hash built for speed, not password storage. Without a salt, identical passwords produce identical digests, making the entire hash database vulnerable to a single precomputed rainbow table lookup. This vulnerability is fixed in 3.7.3. |
| free5GC is an open-source implementation of the 5G core network. Prior to 4.2.2, free5GC's NRF root SBI endpoint POST /oauth2/token contains a parser-level type-confusion bug family. The handler in NFs/nrf/internal/sbi/api_accesstoken.go reflects over models.NrfAccessTokenAccessTokenReq, special-cases only plain string and NrfNfManagementNfType fields, and treats every other field as if it were a single models.PlmnId. The parsed *models.PlmnId is then assigned with reflect.Value.Set() to whichever field name the attacker put in the form body, which panics whenever the destination field's real type is incompatible (slice, different struct, primitive). Gin recovery converts each panic into HTTP 500, but the endpoint remains remotely panicable from a single unauthenticated form-encoded request and is repeatedly triggerable. This vulnerability is fixed in 4.2.2. |
| In the Linux kernel, the following vulnerability has been resolved:
mtd: parsers: Fix memory leak in mtd_parser_tplink_safeloader_parse()
The function mtd_parser_tplink_safeloader_parse() allocates buf via
mtd_parser_tplink_safeloader_read_table(). If the allocation for
parts[idx].name fails inside the loop, the code jumps to the err_free
label without freeing buf, leading to a memory leak.
Fix this by freeing the temporary buffer buf in the err_free label.
Compile tested only. Issue found using a prototype static analysis tool
and code review. |
| In the Linux kernel, the following vulnerability has been resolved:
quota: fix livelock between quotactl and freeze_super
When a filesystem is frozen, quotactl_block() enters a retry loop
waiting for the filesystem to thaw. It acquires s_umount, checks the
freeze state, drops s_umount and uses sb_start_write() - sb_end_write()
pair to wait for the unfreeze.
However, this retry loop can trigger a livelock issue, specifically on
kernels with preemption disabled.
The mechanism is as follows:
1. freeze_super() sets SB_FREEZE_WRITE and calls sb_wait_write().
2. sb_wait_write() calls percpu_down_write(), which initiates
synchronize_rcu().
3. Simultaneously, quotactl_block() spins in its retry loop, immediately
executing the sb_start_write() - sb_end_write() pair.
4. Because the kernel is non-preemptible and the loop contains no
scheduling points, quotactl_block() never yields the CPU. This
prevents that CPU from reaching an RCU quiescent state.
5. synchronize_rcu() in the freezer thread waits indefinitely for the
quotactl_block() CPU to report a quiescent state.
6. quotactl_block() spins indefinitely waiting for the freezer to
advance, which it cannot do as it is blocked on the RCU sync.
This results in a hang of the freezer process and 100% CPU usage by the
quota process.
While this can occur intermittently on multi-core systems, it is
reliably reproducing on a node with the following script, running both
the freezer and the quota toggle on the same CPU:
# mkfs.ext4 -O quota /dev/sda 2g && mkdir a_mount
# mount /dev/sda -o quota,usrquota,grpquota a_mount
# taskset -c 3 bash -c "while true; do xfs_freeze -f a_mount; \
xfs_freeze -u a_mount; done" &
# taskset -c 3 bash -c "while true; do quotaon a_mount; \
quotaoff a_mount; done" &
Adding cond_resched() to the retry loop fixes the issue. It acts as an
RCU quiescent state, allowing synchronize_rcu() in percpu_down_write()
to complete. |
| free5GC is an open-source implementation of the 5G core network. Prior to 4.2.2, free5GC's PCF POST /npcf-policyauthorization/v1/app-sessions handler panics on a single authenticated request whose ascReqData.suppFeat == "1" (enabling traffic-routing feature negotiation) and whose medComponents entries supply an afAppId but NO AfRoutReq. The create path then calls provisioningOfTrafficRoutingInfo(smPolicy, appID, routeReq, ...) with routeReq == nil and dereferences routeReq.RouteToLocs (and other fields) without a nil check, causing runtime error: invalid memory address or nil pointer dereference. Gin recovery converts the panic into HTTP 500. This vulnerability is fixed in 4.2.2. |
| free5GC is an open-source implementation of the 5G core network. Prior to 4.2.2, free5GC's NEF terminates the entire process when a stored PFD-subscription notifyUri cannot be reached. In PfdChangeNotifier.FlushNotifications(), the notifier calls NnefPFDmanagementNotify(...) and on any delivery error invokes logger.PFDManageLog.Fatal(err), which is os.Exit(1)-equivalent in Go. An attacker who can create a PFD subscription with an attacker-chosen notifyUri and then trigger a PFD change can deterministically kill NEF on the asynchronous delivery attempt -- the process exits with status 1, dropping NEF's entire SBI surface until restart. This vulnerability is fixed in 4.2.2. |
| free5GC is an open-source implementation of the 5G core network. Prior to 4.2.2, free5GC's NEF PATCH /3gpp-pfd-management/v1/{afId}/transactions/{transId}/applications/{appId} handler panics with a nil-pointer dereference when the upstream UDR call fails AND the consumer wrapper returns err != nil together with a nil *ProblemDetails. The handler's errPfdData != nil branch builds its own problemDetailsErr correctly, but immediately after it reads problemDetails.Cause (the OTHER value, which is nil in this branch) and panics. Gin recovery converts the panic into HTTP 500, so a single PATCH against this endpoint returns 500 instead of the intended controlled error response whenever UDR access is failing. This vulnerability is fixed in 4.2.2. |
| free5GC is an open-source implementation of the 5G core network. Prior to 4.2.2, free5GC's UDR nudr-dr DELETE /subscription-data/{ueId}/{servingPlmnId}/ee-subscriptions/{subsId}/amf-subscriptions handler panics on a single authenticated request against a fresh UDR instance when the supplied ueId does not exist in UESubsCollection. The processor checks value, ok := udrSelf.UESubsCollection.Load(ueId) and sets a 404 USER_NOT_FOUND problem-details on the miss path, but execution continues and immediately runs value.(*udr_context.UESubsData) -- a Go type assertion on a nil interface, which panics with interface conversion: interface {} is nil, not *context.UESubsData. Gin recovery converts the panic into HTTP 500, but the endpoint remains repeatedly panicable. This vulnerability is fixed in 4.2.2. |
| Improper Check for Unusual or Exceptional Conditions vulnerability in Drupal Node View Permissions allows Forceful Browsing.
This issue affects Node View Permissions: from 0.0.0 before 1.7.0, from 2.0.0 before 2.0.1. |
| opentelemetry-js is the OpenTelemetry JavaScript Client. Prior to 0.217.0, a single malformed HTTP request crashes any Node.js process running the OpenTelemetry JS Prometheus exporter. The metrics endpoint (default 0.0.0.0:9464) has no error handling around URL parsing, so a request with an invalid URI causes an uncaught TypeError that terminates the process. This vulnerability is fixed in 0.217.0. |
| Improper check for unusual or exceptional conditions vulnerability in SSO in Synology DiskStation Manager (DSM) before 7.2.2-72806-5 and 7.3.1-86003-1 (7.2.1-69057 is not affected) allows remote attackers to bypass authentication with prior knowledge of the distinguished name (DN). |
| IO::Compress versions from 2.207 before 2.220 for Perl ship a zipdetails CLI tool that crashes with undefined subroutine on Info-ZIP Unix Extra Field with 8-byte UID or GID.
When decode_ux() in bin/zipdetails handles an Info-ZIP Unix Extra Field (tag 0x7875) with UID Size or GID Size set to 8, causing zipdetails to decode an 8-byte UID or GID value, it dispatches through decodeLitteEndian(), which calls a misnamed helper unpackValueQ. The actual function defined in the same file is unpackValue_Q (with underscore); the call raises 'Undefined subroutine &main::unpackValueQ' and the script exits with status 255.
Library callers of IO::Compress and IO::Uncompress are not affected; the defect is in the bundled CLI tool. |
| Mattermost versions 11.6.x <= 11.6.0, 11.5.x <= 11.5.3, 11.4.x <= 11.4.4, 10.11.x <= 10.11.14 fail to filter nil elements from outgoing webhook attachment payloads before processing, which allows an authenticated user to cause a denial of service (server process termination) via a crafted webhook callback response containing a null attachment entry.. Mattermost Advisory ID: MMSA-2026-00641 |
| A weakness has been identified in ulisesbocchio jasypt-spring-boot up to 3.0.5/4.0.4. Affected by this vulnerability is the function getSecretKeySaltGenerator of the file jasypt-spring-boot/src/main/java/com/ulisesbocchio/jasyptspringboot/encryptor/SimpleGCMConfig.java of the component Password Hash Handler. Executing a manipulation can lead to use of a one-way hash with a predictable salt. The attack can be launched remotely. The attack requires a high level of complexity. The exploitation appears to be difficult. The exploit has been made available to the public and could be used for attacks. The project was informed of the problem early through an issue report but has not responded yet. |
| Multiple flaws have been identified in `named` related to the handling of DNS messages whose CLASS is not Internet (`IN`) — for example, `CHAOS` or `HESIOD`, or DNS messages that specify meta-classes (`ANY` or `NONE`) in the question section. Specially crafted requests reaching the affected code paths — recursion, dynamic updates (`UPDATE`), zone change notifications (`NOTIFY`), or processing of `IN`-specific record types in non-`IN` data — can cause assertion failures in `named`.
This issue affects BIND 9 versions 9.11.0 through 9.16.50, 9.18.0 through 9.18.48, 9.20.0 through 9.20.22, 9.21.0 through 9.21.21, 9.11.3-S1 through 9.16.50-S1, 9.18.11-S1 through 9.18.48-S1, and 9.20.9-S1 through 9.20.22-S1. |
| nimiq-blockchain provides persistent block storage for Nimiq's Rust implementation. In versions 1.3.0 and prior, network-libp2p discovery accepts signed PeerContact updates from untrusted peers and stores them in a peer contact book, eventually leading to address book crash. A PeerContact can legally contain an empty addresses list (no intrinsic validation enforces non-empty). Later, PeerContactBook::known_peers builds an address book by taking addresses.first().expect("every peer should have at least one address"). If the attacker has inserted a signed peer contact with addresses=[], any call to get_address_book (RPC/web client) can panic and crash the node/RPC task depending on panic settings. This issue has been fixed in version 1.4.0. |
| Improper Check for Unusual or Exceptional Conditions vulnerability in Samsung Open Source Escargot allows Input Data Manipulation.
This issue affects Escargot: 590345cc6258317c5da850d846ce6baaf2afc2d3. |
| Issue summary: An OpenSSL TLS 1.3 server may fail to negotiate the expected
preferred key exchange group when its key exchange group configuration includes
the default by using the 'DEFAULT' keyword.
Impact summary: A less preferred key exchange may be used even when a more
preferred group is supported by both client and server, if the group
was not included among the client's initial predicated keyshares.
This will sometimes be the case with the new hybrid post-quantum groups,
if the client chooses to defer their use until specifically requested by
the server.
If an OpenSSL TLS 1.3 server's configuration uses the 'DEFAULT' keyword to
interpolate the built-in default group list into its own configuration, perhaps
adding or removing specific elements, then an implementation defect causes the
'DEFAULT' list to lose its 'tuple' structure, and all server-supported groups
were treated as a single sufficiently secure 'tuple', with the server not
sending a Hello Retry Request (HRR) even when a group in a more preferred tuple
was mutually supported.
As a result, the client and server might fail to negotiate a mutually supported
post-quantum key agreement group, such as 'X25519MLKEM768', if the client's
configuration results in only 'classical' groups (such as 'X25519' being the
only ones in the client's initial keyshare prediction).
OpenSSL 3.5 and later support a new syntax for selecting the most preferred TLS
1.3 key agreement group on TLS servers. The old syntax had a single 'flat'
list of groups, and treated all the supported groups as sufficiently secure.
If any of the keyshares predicted by the client were supported by the server
the most preferred among these was selected, even if other groups supported by
the client, but not included in the list of predicted keyshares would have been
more preferred, if included.
The new syntax partitions the groups into distinct 'tuples' of roughly
equivalent security. Within each tuple the most preferred group included among
the client's predicted keyshares is chosen, but if the client supports a group
from a more preferred tuple, but did not predict any corresponding keyshares,
the server will ask the client to retry the ClientHello (by issuing a Hello
Retry Request or HRR) with the most preferred mutually supported group.
The above works as expected when the server's configuration uses the built-in
default group list, or explicitly defines its own list by directly defining the
various desired groups and group 'tuples'.
No OpenSSL FIPS modules are affected by this issue, the code in question lies
outside the FIPS boundary.
OpenSSL 3.6 and 3.5 are vulnerable to this issue.
OpenSSL 3.6 users should upgrade to OpenSSL 3.6.2 once it is released.
OpenSSL 3.5 users should upgrade to OpenSSL 3.5.6 once it is released.
OpenSSL 3.4, 3.3, 3.0, 1.0.2 and 1.1.1 are not affected by this issue. |
