Network-reachable, unauthenticated deserialization flaws in Apache Kafka’s clients library and Kafka Streams can force multi-gigabyte allocations and crash the consuming application or Streams thread with an OutOfMemoryError; the broker and other cluster components are unaffected. Versions 0.10.0.0 through 4.1.2, 4.2.0 through 4.2.1, and 4.3.0 through 4.3.1 are affected across the Kafka Streams paths (ProcessorRecordContext, ChangedDeserializer, CombinedKeySchema, ProcessorMetadata, AssignmentInfo) and the clients ListDeserializer used by ListSerde. Exploitation requires the ability to place crafted data on the relevant deserialization path-writing to internal changelog or repartition topics, committing offset metadata, supplying crafted group-assignment data as Streams group leader, or producing to a topic consumed with ListSerde; Kafka ACLs block many of these paths when authorization is enabled, no CISA KEV entry is reported in the supplied data, no EPSS score is available, and no public exploit identified at time of analysis.
Kafka Streams can be stalled indefinitely by a single record whose timestamp is at or near Long.MAX_VALUE, causing an integer overflow that moves the next stream-time punctuation to a negative time and makes PunctuationQueue re-queue it in a lock-holding loop until the StreamThread stops. EUVD lists Apache Kafka 1.1.0 through 4.1.2, 4.2.0 through 4.2.1, and 4.3.0 through 4.3.1 as affected; only the Streams application is impacted, not the brokers or cluster, and the hang returns on restart while the record stays in the topic. Exploitation requires producer write access to a source topic feeding a stream-time-punctuation topology and a broker that stores the extreme timestamp-brokers from 4.0.0 reject timestamps more than one hour in the future by default-so reachability is limited to older brokers or relaxed bounds; the assessed vector is CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H, no EPSS score is present, no KEV entry is listed, and no public exploit identified at time of analysis, with priority monitor.
Unauthenticated remote attackers can exhaust broker heap and trigger process-wide GC stalls on Apache Kafka by declaring an enormous tagged-field count in the flexible request header, which generated readers accept without checking it against the remaining buffer. The affected lines are 2.4.0 through 4.1.2, 4.2.0 through 4.2.1, and 4.3.0 through 4.3.1; because each declared field costs one RawTaggedField allocation and can be encoded in as little as two bytes, a request of a few tens of megabytes can force roughly 20 million allocations, and this happens on the network thread before authentication, request dispatch and request-time quota accounting, so APIs such as ApiVersions v3 are reachable pre-authentication. The outcome is availability-only denial of service; no public exploit identified at time of analysis, and vendor fixes are available in 4.2.2, 4.3.2 and 4.4.0, making this a this-week priority rather than an emergency.
Jenkins 2.587 and earlier, and LTS 2.580.1 and earlier, expose an HTTP endpoint that loads agents by name without validating the name; an authenticated user with Overall/Read permission can thereby load any config.xml on the controller as an agent configuration. This can replace an existing agent or define a new one, and because the name declared in that file controls where the configuration is written, saving the agent overwrites that config.xml and can potentially lead to arbitrary code execution. The vendor fixed this in Jenkins 2.588 and LTS 2.580.2; no public exploit was identified at time of analysis.
Jenkins core 2.587 and earlier and Jenkins LTS 2.580.1 and earlier are covered by the vendor's 2026-10-28 security advisory, which bundles fixes for several distinct flaws into Jenkins 2.588 and LTS 2.580.2; the identifier CVE-2026-117624 does not appear anywhere in the supplied advisory text, so its specific defect, prerequisites and severity could not be verified from the available sources. The sibling issues that are described are not anonymously reachable - they require an authenticated account plus a Jenkins permission such as Overall/Read, Item/Configure, View/Configure, Agent/Configure or Item/Create - and several of them can end in code execution in the controller JVM or in cross-site scripting. No public exploit code and no CISA KEV entry were identified for this identifier, no EPSS score was supplied, and the priority label is awaiting_data; the vendor advisory at https://www.jenkins.io/security/advisory/2026-10-28/ is the authoritative reference.
Stored cross-site scripting in Jenkins core 2.587 and earlier and LTS 2.580.1 and earlier allows an attacker who already holds Item/Configure permission (or an equivalent */Configure permission such as View/Configure or Agent/Configure) to submit a crafted job config.xml through the POST config.xml API, where XStream deserialization of collection elements with unchecked types leads to script injection that executes in the browser of another user who later views the affected page. The actor cannot be anonymous and must be authorized to configure items, and exploitation requires victim interaction, so the practical impact is scoped to cross-site scripting rather than direct server compromise; Jenkins rates the issue qualitatively as High while publishing no CVSS base vector. No public exploit code has been identified at time of analysis and the CVE is not in CISA KEV. Enforcing Content Security Policy, available on Jenkins 2.539/LTS 2.541.1 and newer, mitigates the known impact, and the flaw is fixed in Jenkins 2.588 and LTS 2.580.2.
Jenkins core 2.587 and earlier, plus LTS 2.580.1 and earlier, are the affected versions for the security batch fixed in Jenkins 2.588 and LTS 2.580.2, but the individual defect tracked as CVE-2026-117626 is not described in any of the source material available here - the supplied oss-security post and the linked Jenkins advisory 2026-10-28 both cut off at CVE-2026-117622 (SECURITY-4249). Exploitation status, CVSS, CWE and impact for this specific ID are therefore unverified: no CISA KEV entry, no confirmed working public exploit code, and no EPSS score were provided, so it should be treated as an unresolved mapping gap within an actively maintained advisory rather than as a characterized vulnerability. Analysts should read the full advisory page directly before assigning severity or exposure for this CVE. As a family characteristic of the same advisory, the sibling issues require an authenticated Jenkins account holding permissions such as Overall/Read, Item/Configure, View/Configure or Agent/Configure, and are explicitly noted as not exploitable anonymously.
Arbitrary file write on the Jenkins controller is possible in Jenkins 2.587 and earlier and LTS 2.580.1 and earlier when an authenticated user with Item/Configure permission archives artifacts concurrently, such as from parallel Pipeline branches. The extraction code checks for symbolic links only before creating parent directories and permits symlinks in artifacts to replace existing files or empty directories, leaving a race before the final write; successful exploitation can overwrite files outside the intended directory and lead to remote code execution. No public exploit was identified at time of analysis, and the vendor fixed the issue in Jenkins 2.588 and LTS 2.580.2.
CVE-2026-117623 is one of several vulnerabilities fixed in the Jenkins 2026-10-28 security advisory, remediated only by upgrading Jenkins core to 2.588 or LTS 2.580.2. Its specific description is not present in the available sources: the advisory text enumerates CVE-2026-117612 through CVE-2026-117622 and truncates mid-sentence at SECURITY-4249 / CVE-2026-117622, so no CVSS score, CVSS vector, CWE, or trigger mechanism for CVE-2026-117623 is confirmed from the supplied data. No public exploit code is identified at time of analysis, the CVE is not noted as confirmed actively exploited (CISA KEV), and EPSS is not available; the root cause class and whether the same authenticated, permission-gated prerequisites that apply to its sibling issues apply here remain unverified.
Cross-site scripting in the Jenkins workspace browser lets an attacker who controls a build agent have script execute in the browser of a Jenkins user who opens the workspace listing for that agent. Only jobs whose workspace resides on an agent are affected, specifically Jenkins 2.587 and earlier and Jenkins LTS 2.580.1 and earlier, and the attacker must already control the agent process while a victim must actually view the workspace browser (assessed CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:L/A:N). The Jenkins advisory publishes no CVSS score or CWE for this item, there is no CISA KEV listing, no public exploit identified at time of analysis, and no EPSS data in the supplied sources.
CVE-2026-117622 (Jenkins SECURITY-4249) cannot be fully assessed from the supplied data because the oss-security description is truncated at 'To protect against deserialization vulnerabilities, Jenkins restricts th…'; the exact defect, trigger, required permissions, and impact are not stated. Jenkins core is the affected product, and the 2026-10-28 Jenkins advisory lists Jenkins 2.588 and Jenkins LTS 2.580.2 as releases containing fixes. No CVSS vector, CWE, EPSS, KEV status, or confirmed public exploit information is provided; the priority decision is awaiting_data and no public exploit is identified at time of analysis.
CVE-2026-117618 is one identifier in the Jenkins Security Advisory 2026-10-28 bundle, which fixes multiple Jenkins core vulnerabilities affecting Jenkins 2.587 and earlier and LTS 2.580.1 and earlier; the vendor-released patch is Jenkins 2.588 and LTS 2.580.2. The advisory excerpt available for this analysis enumerates SECURITY-4125/CVE-2026-117612 through SECURITY-4249/CVE-2026-117622 but does not include a description mapping SECURITY-4125 through SECURITY-4249 to the -117618 identifier, so the specific vulnerable component, attack vector, and required permissions for this CVE are unverified and must be read from the advisory page. No CISA KEV listing, no EPSS score, and no public exploit code were present in the supplied data, so exploitation status is no public exploit identified at time of analysis, and the vuln.today decision label remains awaiting_data. For the sibling issues in the same advisory, exploitation requires an authenticated foothold with configuration privileges (Overall/Read plus a non-anonymous account, Item/Configure, Agent/Configure, or Item/Create depending on the issue), and several of those siblings can lead to remote code execution on the controller.
Arbitrary code execution in the Jenkins controller JVM is possible for users holding Agent/Configure permission on Jenkins 2.587 and earlier and LTS 2.580.1 and earlier, because legacy agent launch commands carried over from Jenkins core are converted into Command Agent Launcher Plugin launchers without verifying that an administrator approved the command. The issue affects builds from Jenkins 2.86 / LTS 2.89.1 onward, where that launch functionality moved into the plugin, and is resolved only by upgrading to Jenkins 2.588 or LTS 2.580.2; no separate configuration workaround is documented for this specific issue. Exploitation requires an authenticated account with the elevated Agent/Configure permission, so the practical blast radius depends on how broadly that permission is delegated in a given installation; no public exploit code, EPSS score, or CISA KEV entry was identified at time of analysis, and the vulnerability remains at an 'awaiting data' prioritization state.
CVE-2026-117620 is one of the vulnerabilities covered by the Jenkins security advisory of 2026-10-28, fixed in Jenkins 2.588 and Jenkins LTS 2.580.2, but the supplied advisory text and oss-security post do not include a standalone description for this specific identifier. By contrast, the sibling CVEs detailed in the same bundle are permission-gated issues (XStream deserialization RCE under SECURITY-4125, stored XSS via crafted job config.xml under SECURITY-4225, command agent launcher RCE, symlink-based file read/write flaws, and an unvalidated agent-loading endpoint) and are not reported as actively exploited. The exact mechanism, impact, and required permissions for CVE-2026-117620 remain unconfirmed from the available sources; no public exploit code is identified for it and the decision label is awaiting_data.
Arbitrary file read on the Jenkins controller affects Jenkins 2.587 and earlier and Jenkins LTS 2.580.1 and earlier when an authenticated user with both Item/Create and Item/Configure renames an item whose directory contains a symbolic link, causing the copy fallback to follow the link and disclose file contents. The direct impact is confidentiality loss (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N); disclosed secrets can enable a contingent escalation to remote code execution. No public exploit identified at time of analysis, and the supplied data contains no EPSS score or CISA KEV entry.
Jenkins core 2.587 and earlier, along with LTS 2.580.1 and earlier, are affected by CVE-2026-117619, one of eight security issues addressed in the Jenkins advisory dated 2026-10-28 and fixed in Jenkins 2.588 and LTS 2.580.2. The per-CVE description for this specific identifier is not present in the supplied advisory excerpt, so neither the vulnerability class nor the precise attacker impact can be stated from the available data - only the affected scope and the fixed versions are confirmed. Every other entry in the same advisory requires an authenticated user holding specific Jenkins permissions (Overall/Read, Item/Configure, View/Configure, Agent/Configure, Item/Create) rather than anonymous access, which suggests a similar privilege prerequisite is likely here, but that remains unverified. No public exploit code and no CISA KEV entry are associated with this identifier in the supplied intelligence, and the priority decision is awaiting_data.
Deserialization of attacker-controlled XML in Jenkins 2.587 and earlier and LTS 2.580.1 and earlier can instantiate arbitrary types because the custom XStream converter does not apply the JEP-200 deserialization filter to classes referenced by the `resolves-to` attribute, potentially leading to remote code execution in the Jenkins controller JVM. Exploitation requires Overall/Read permission plus either a non-anonymous user account or a permission set that permits POSTing config.xml (Item/Configure, View/Configure, or Agent/Configure), so anonymous or account-less read access is insufficient. The issue is assessed as CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H; no CISA KEV entry, EPSS score, or public exploit reference was provided in the available intelligence, so no public exploit is identified at time of analysis.
Jenkins core 2.587 and earlier, along with LTS 2.580.1 and earlier, are covered by the 2026-10-28 Jenkins security advisory, and the EUVD record for this CVE points to advisory section SECURITY-4206; that section's text is not included in the material supplied here, so the specific defect, its trigger, and its exact permission prerequisites for CVE-2026-117625 cannot be confirmed from available data. What is confirmed for the advisory as a whole is that every listed issue requires an authenticated, non-anonymous Jenkins user holding a permission such as Overall/Read, Item/Configure, View/Configure, or Agent/Configure, and that several of the batch lead to remote code execution or stored cross-site scripting on the controller. No public exploit code or confirmed active exploitation is identified in the supplied sources, and the priority decision remains awaiting data, so treatment should be driven by the confirmed availability of the 2.588 / LTS 2.580.2 fix rather than by an exploitation signal.
Heap exhaustion in Apache Kafka allows remote attackers to crash brokers by sending requests that declare an array element count far exceeding the actual buffer contents, causing generated protocol readers to pre-allocate an ImplicitLinkedHashCollection with capacity 2*count+1 before reading any elements. Because parsing happens before authorization, listeners without authentication such as PLAINTEXT are exposed to unauthenticated attackers, while authenticated listeners require valid credentials but no specific ACL; the reporter demonstrated three concurrent ~90 MB ProduceRequest v3 connections exhausting a 1 GB heap (~8x amplification). Affected releases are prior to 4.2.2, 4.3.2, and 4.4.0, and no public exploit code has been identified at time of analysis.
Apache Kafka brokers can be driven into heap exhaustion by any authenticated client because the PushTelemetry (KIP-714) path limits the compressed request size but not the decompressed output. A tiny, highly compressible payload can expand to hundreds of megabytes, and repeated or concurrent requests can trigger OutOfMemoryError, degrade brokers, and affect cluster availability; PushTelemetry is not ACL-gated. No public exploit was identified at time of analysis, and vendor fixes are available in Apache Kafka 4.2.2, 4.3.1, and 4.4.0.
Apache Kafka brokers that run SASL/OAUTHBEARER with the default DefaultJwtValidator and leave sasl.oauthbearer.jwks.endpoint.url unset silently fall back to a validator that performs no JWT signature, algorithm, or issuer checks, allowing unauthenticated remote attackers with listener reachability to forge tokens for arbitrary principals, including configured superusers, and gain full cluster access. The flaw is a residual of CVE-2026-33557 and only affects brokers in this specific OAUTHBEARER-without-JWKS-URL configuration with no custom verification key resolver; brokers that set the JWKS URL verify signatures and are not affected. No CISA KEV listing or public exploit code is identified in the available data, no public exploit identified at time of analysis, and no EPSS score is provided.
Apache Kafka brokers that authenticate clients via SASL/OAUTHBEARER using the bundled JWKS-backed validator can accept a validly-signed JWT that was minted by a different issuer, or that omits the aud claim, because the issuer check only runs when sasl.oauthbearer.expected.issuer is set and an audience claim is only required when sasl.oauthbearer.expected.audience is set - both default to unset. The practical exposure is concentrated in deployments whose JWKS endpoint publishes signing keys for more than one issuer (multi-tenant IdP, aggregated/shared JWKS, shared signing keys), where such a token may authenticate a client, potentially as a higher-privileged principal; single-issuer deployments that control the iss claim and issue audience-scoped tokens are far less exposed. The JWT signature trust anchor is still enforced in every case, no public exploit code has been identified at time of analysis, and the flaw is not listed in CISA KEV; an analyst-derived CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N places severity at the high end while acknowledging the configuration and token-availability preconditions.
Denial of service in Apache Kafka's KRaft controller affects releases 2.8.0 through 4.2.1 and 4.3.0 through 4.3.1, where a remote authenticated principal holding CLUSTER_ACTION authorization can terminate the controller process by sending a crafted FetchSnapshotRequest whose topics array is empty or whose single topic carries no partitions. The impact is availability-only: the controller dies, taking cluster metadata management down with it, but no data is exposed or altered (assessed CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). CLUSTER_ACTION is a cluster-level permission normally held by broker/controller identities rather than ordinary producers or consumers, so the realistic attacker is a compromised or malicious broker or a holder of inter-broker credentials. No public exploit has been identified at time of analysis, no CISA KEV entry exists, and the vuln.today decision label is 'monitor'.
In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: Don't reset VMBus connection state on error/exit paths In two places, current code forces vmbus_connection.conn_state to DISCONNECTED prior to calling vmbus_disconnect(). But vmbus_disconnect() calls vmbus_initiate_unload(), which unloads the VMBus connection only if the conn_state is CONNECTED. Consequently, the connection remains and the Hyper-V host might continue to send messages or post VMBus interrupts. The problem was introduced in commit 74347a99e73ae ("x86/Hyper-V: Unload vmbus channel in hv panic callback"), in that vmbus_initiate_unload() started checking the current connection state before doing the unload. This commit removed some occurrences where conn_state was forced to DISCONNECTED, but these two remained, apparently due to an oversight at the time. Fix this by not forcing conn_state to DISCONNECTED during VMBus exit, or if a failure occurs when establishing the connection in the first place. Whatever value conn_state has at the time is then read by vmbus_initiate_unload() to determine if there is a connection to be unloaded.
In the Linux kernel, the following vulnerability has been resolved: power: supply: core: prevent unregistering a power supply while a callback runs Once a power supply is registered, its callbacks can immediately start firing from other contexts, such as external_power_changed() triggered by the TCPM stack. If a power supply is unregistered while the callback is still running, the driver data can already be freed when the callback tries to access it, leading to a use-after-free. This happens e.g. when the hardware bus carrying the power supply device malfunctions (e.g. I2C is hogged down by another malfunctioning device) immediately after the power supply is registered, and thus the core is still processing the callbacks which were queued up when the driver starts the removal, leading in some cases to a kernel crash, e.g.: [ 11.645942] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000005 [ 11.646751] Mem abort info: [ 11.647006] ESR = 0x0000000096000004 [ 11.647338] EC = 0x25: DABT (current EL), IL = 32 bits [ 11.647806] SET = 0, FnV = 0 [ 11.648077] EA = 0, S1PTW = 0 [ 11.648356] FSC = 0x04: level 0 translation fault [ 11.648785] Data abort info: [ 11.649041] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 11.649524] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 11.649981] GCS = 0, Overlay = 0, DirtyBit = 0 [ 11.650390] [0000000000000005] user address but active_mm is swapper [ 11.650955] Internal error: Oops: 0000000096000004 [#1] SMP [ 11.651460] Modules linked in: [ 11.651742] CPU: 1 UID: 0 PID: 144 Comm: kworker/1:2 Not tainted 7.2.0-rc6-g62a9297af2cd #1 PREEMPT [ 11.652553] Hardware name: Flipper One rev. F0B1C2 (DT) [ 11.653024] Workqueue: events power_supply_changed_work [ 11.653511] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 11.654135] pc : __power_supply_is_supplied_by+0x18/0x100 [ 11.654624] lr : __power_supply_am_i_supplied+0x40/0xb8 [ 11.655098] sp : ffff80008192bb30 [ 11.655399] x29: ffff80008192bb30 x28: 0000000000000000 x27: 0000000000000000 [ 11.656049] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 [ 11.656695] x23: ffff0000c19f4200 x22: ffffdb2232ba4ea8 x21: ffff80008192bc28 [ 11.657344] x20: ffff0000c1eef000 x19: ffff80008192bc18 x18: 00000000a0886e62 [ 11.657991] x17: 000000040044ffff x16: 04500072b5503510 x15: 0000000000000000 [ 11.658639] x14: 0000000000000000 x13: 0000000000000220 x12: 0000000000000000 [ 11.659286] x11: 0000000000000000 x10: ffff0000c1fdb2b0 x9 : ffffdb2232ba5590 [ 11.659934] x8 : 00000000e5b906e6 x7 : ffff0000c2502778 x6 : ffffdb22339793d0 [ 11.660581] x5 : ffff80008192bc18 x4 : ffff0000c19cbca0 x3 : 0000000000000000 [ 11.661228] x2 : ffff0000c1fdaf40 x1 : ffffffffffffffed x0 : ffff0000c1eef000 [ 11.661878] Call trace: [ 11.662103] __power_supply_is_supplied_by+0x18/0x100 (P) [ 11.662596] __power_supply_am_i_supplied+0x40/0xb8 [ 11.663040] psy_for_each_psy_cb+0x20/0x40 [ 11.663416] class_for_each_device+0x110/0x150 [ 11.663825] power_supply_am_i_supplied+0x68/0x100 [ 11.664262] bq257xx_external_power_changed+0x58/0x140 [ 11.664733] __power_supply_changed_work+0x60/0x80 [ 11.665170] psy_for_each_psy_cb+0x20/0x40 [ 11.665545] class_for_each_device+0x110/0x150 [ 11.665953] power_supply_changed_work+0x98/0x1b8 [ 11.666382] process_one_work+0x164/0x4c0 [ 11.666758] worker_thread+0x19c/0x320 [ 11.667104] kthread+0x138/0x150 [ 11.667408] ret_from_fork+0x10/0x20 [ 11.667744] Code: d503233f a9bd7bfd 910003fd a90153f3 (f9400c34) [ 11.668294] ---[ end trace 0000000000000000 ]--- Add a read-write semaphore between external_power_changed() and power_supply_unregister() to prevent the latter from returning (and thus the driver from freeing its data) while the callback is still running.
In the Linux kernel, the following vulnerability has been resolved: drm/vc4: hdmi: Move packet RAM enable to PM runtime Audio can be triggered by the HPD handler and start up before video has been restored, calling vc4_hdmi_write_infoframe() for the audio infoframe. vc4_hdmi_write_infoframe() needs Packet RAM to be on to store the infoframe, however, if the video hasn't been enabled, vc4_hdmi_encoder_post_crtc_enable() hasn't been called and therefore, the Packet RAM can be disabled by the time vc4_hdmi_write_infoframe() executes, causing the following splat: [ 201.570266] ------------[ cut here ]------------ [ 201.570293] Packet RAM has to be on to store the packet. [ 201.570367] WARNING: drivers/gpu/drm/vc4/vc4_hdmi.c:683 at vc4_hdmi_write_infoframe+0x404/0x494 [vc4], CPU#0: wireplumber/1606 [...] [ 201.658650] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [...] [ 201.758499] Call trace: [ 201.760967] vc4_hdmi_write_infoframe+0x404/0x494 [vc4] (P) [ 201.766607] vc4_hdmi_write_audio_infoframe+0x1c/0x28 [vc4] [ 201.772247] write_infoframe+0xbc/0x140 [drm_display_helper] [ 201.777975] drm_atomic_helper_connector_hdmi_update_audio_infoframe+0x80/0xdc [drm_display_helper] [ 201.787140] vc4_hdmi_audio_prepare+0x4ac/0x570 [vc4] [ 201.792252] drm_connector_hdmi_audio_prepare+0x24/0x30 [drm_display_helper] [ 201.799390] hdmi_codec_prepare+0x100/0x160 [snd_soc_hdmi_codec] [ 201.805471] snd_soc_pcm_dai_prepare+0xd4/0x100 [snd_soc_core] [ 201.811375] __soc_pcm_prepare+0x60/0x12c [snd_soc_core] [ 201.816752] soc_pcm_prepare+0x34/0x58 [snd_soc_core] [ 201.821863] snd_pcm_do_prepare+0x70/0x8c [snd_pcm] [ 201.826798] snd_pcm_action_nonatomic+0xe4/0x174 [snd_pcm] [ 201.832350] snd_pcm_prepare+0xc8/0xd8 [snd_pcm] [ 201.837021] snd_pcm_common_ioctl+0x458/0x614 [snd_pcm] [ 201.842308] snd_pcm_ioctl+0x30/0x48 [snd_pcm] [ 201.846802] __arm64_sys_ioctl+0x88/0xd8 [ 201.850769] invoke_syscall+0x48/0xf4 [ 201.854470] el0_svc_common+0x80/0xd8 [ 201.858171] do_el0_svc+0x1c/0x28 [ 201.861520] el0_svc+0x3c/0xb0 [ 201.864605] el0t_64_sync_handler+0x68/0xdc [ 201.868834] el0t_64_sync+0x198/0x19c [ 201.872536] ---[ end trace 0000000000000000 ]--- Considering that Packet RAM enable is essentially a power management configuration, move its enabling/disabling to the Runtime PM hooks. Note that post_crtc_disable() still stops all infoframes, but keeps Packet RAM enabled, leaving it to be disabled by runtime suspend.
In the Linux kernel, the following vulnerability has been resolved: vsock: treat TCP_CLOSING as once-established Handle the TCP_ESTABLISHED -> TCP_CLOSING transition on OP_RST, which can race with the connect loop. Immediately break and return 0 on ESTABLISHED/CLOSING. The return value of connect() should reflect what happened up to the point the connection was established or failed. Events that occur afterwards must not affect it. E.g. even if OP_RW has already set sk_err, connect() should still return 0, not ENOBUFS because of it. Adapt the inaccurate comment above signal_pending(). Resetting a socket that is still present in connected_table can lead to memory corruption. The reporter noted lost transports for in-flight skbs, and I have reproduced crashes caused by re-insertion into connected_table. list_add double add: new=, prev=, next=. kernel BUG at lib/list_debug.c:35! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI Workqueue: vsock-loopback vsock_loopback_work RIP: 0010:__list_add_valid_or_report+0x11f/0x130 Call Trace: vsock_insert_connected.cold+0xe/0x13 virtio_transport_recv_pkt+0x10e9/0x1460 vsock_loopback_work+0x305/0x480 process_one_work+0xe4c/0x1560 worker_thread+0x4f1/0xd60 kthread+0x36e/0x470 ret_from_fork+0x47b/0x6b0 ret_from_fork_asm+0x1a/0x30 This fix is supplementary to commit 002541ef650b ("vsock: Ignore signal/timeout on connect() if already established"). Details under Link.
In the Linux kernel, the following vulnerability has been resolved: net/rds: don't let the rdma_cm destroy an id RDS still owns on route failure rds_rdma_cm_event_handler_cmn() hands the return value of rdma_resolve_route() straight back to the rdma_cm on RDMA_CM_EVENT_ADDR_RESOLVED. A synchronous failure there - -ENOMEM from the route work allocation, an SA query that cannot be set up, a RoCE route with no usable device - makes addr_handler() destroy the id the event was delivered on. That id is ic->i_cm_id, and nothing clears the pointer: the connection sits in RDS_CONN_CONNECTING with a freed id until its shutdown calls rdma_disconnect() and rdma_destroy_id() on it. The ROUTE_RESOLVED case already avoids this: rds_ib_cm_initiate_connect() forces a zero return while ic->i_cm_id == cm_id, as the comment there explains. Do the same here - drop the connection and return 0 - so the id stays RDS's to destroy from the shutdown, and the reconnect gets a fresh one.
In the Linux kernel, the following vulnerability has been resolved: netlink: reset skb headers before unicast and multicast filtering Socket filters can use SKF_NET_OFF and SKF_LL_OFF to read relative to an skb's network and MAC headers. Netlink producers may reserve headroom without resetting those headers, allowing a receiving socket's filter to read data before the initialized message. For example, IWPM HELLO replies are allocated with dev_alloc_skb(), which reserves NET_SKB_PAD bytes. An unprivileged NETLINK_RDMA user can attach a classic socket filter and disclose this headroom through the length of the delivered reply. The resets in netlink_dump() do not help because IWPM sends a separately allocated skb through netlink_unicast(). Reset both headers before running the receiver's filter in unicast and broadcast delivery, as is already done for dump skbs. This also covers other netlink producers that reserve headroom without changing their allocation or message-building code.
In the Linux kernel, the following vulnerability has been resolved: accel/rocket: clear rdev on device init failure rocket_probe() stores the return value from rocket_device_init() in the file-scoped rdev pointer before checking whether it is an error pointer. If rocket_device_init() fails, rdev is left as an ERR_PTR. The rdev pointer is also used as the marker for whether the shared rocket device has already been initialized. A later core probe can therefore see a non-NULL rdev, skip rocket_device_init(), and dereference the error pointer when reading rdev->num_cores. Save the error code and clear rdev before returning from the rocket_device_init() failure path.
In the Linux kernel, the following vulnerability has been resolved: drm/xe: skip eviction of a BO with no resource xe_evict_flags() switches on tbo->resource->mem_type to choose an eviction placement. An xe BO can reach eviction with no ttm.resource, e.g. an imported dma-buf BO whose resource was freed during teardown while its attachment is still live: the exporter then invalidates it via xe_dma_buf_move_notify() -> xe_bo_evict(), and the switch dereferences a NULL resource and faults. A BO with no resource has nothing placed or mapped, so there is nothing to evict. Return an empty placement (num_placement = 0), mirroring the handling already used for non-xe scatter-gather BOs just above; ttm_bo_validate() then takes the pipeline-gutting path and returns 0. Without the fix the xe_dma_buf@xe_test_dmabuf_move_notify_no_resource dynamic live selftest will fail with below stack. BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: 0010:xe_evict_flags+0xf4/0x140 [xe] Call Trace: <TASK> xe_bo_evict+0x40/0xa0 [xe] ? ttm_bo_pipeline_gutting+0x71/0x180 [ttm] xe_test_dmabuf_move_notify_no_resource+0x182/0x440 [xe] xe_dma_buf_kunit+0x387/0x580 [xe] v2: Add Fixes tag and failure info in commit text (Matt Brost) (cherry picked from commit dbcfaac6331f1fcb0c2fe3ad3e9adb1e5d43ec0c)
In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Zero OA buffer at allocation ttm_bo_type_kernel BOs are not guaranteed to be zeroed on allocation and may contain data from previously freed pages. Since the OA buffer is mmap'able by userspace, this can expose stale kernel memory contents. Streams opened with DRM_XE_OA_PROPERTY_OA_DISABLED allocate the OA buffer without calling xe_oa_init_oa_buffer(). Zero the buffer at allocation to prevent information disclosure through mmap. The existing zeroing in xe_oa_init_oa_buffer() remains necessary for zero report-id/timestamp detection on enable/re-enable. (cherry picked from commit 126c4c5388f9311a390b9b254a835b0cf0f55331)
In the Linux kernel, the following vulnerability has been resolved: scsi: target: Disable interrupts while holding delayed_cmd_lock target_do_delayed_work() takes dev->delayed_cmd_lock with a plain spin_lock(). It runs from system_percpu_wq, so interrupts stay enabled while the lock is held. Every other acquisition of that lock uses spin_lock_irqsave(): target_handle_task_attr() and transport_complete_ordered_sync() in target_core_transport.c, and target_non_ordered_release() in target_core_device.c. That was safe while every caller of transport_complete_task_attr() ran in process context: target_complete_ok_work() from target_completion_wq, transport_complete_qf() from dev->qf_work_queue, and transport_generic_request_failure() from the submit and execute paths. Since commit 06933066d88a ("scsi: target: Add support for completing commands from backend context") that is no longer true. With complete_type=1 on a fabric that sets direct_compl_supp, target_complete() runs target_complete_ok_work() inline in the backend's completion context, which target_complete_cmd_with_sense() documents as "May be called from interrupt context". For iblock that is the bio end_io. target_complete_ok_work() starts with transport_complete_task_attr(), which takes delayed_cmd_lock in two ways: - Every ORDERED command is put on dev->delayed_cmd_list by target_handle_task_attr() and dispatched from there by target_do_delayed_work(), which marks it SCF_TASK_ORDERED_SYNC. Its completion therefore goes through transport_complete_ordered_sync(). - A SIMPLE command that completes while an ORDERED command is pending drops the last reference to the killed dev->non_ordered, and percpu_ref_put() then runs target_non_ordered_release() in the completing context. Both take the lock and, if commands are waiting, call schedule_work(&dev->delayed_cmd_work), which queues on system_percpu_wq, i.e. on the CPU that took the completion. Further completions for the same queue are typically delivered there too, so one arriving while the work holds the lock spins on it forever. Reaching this needs complete_type=1, which is not the default (vhost-scsi, the only fabric with direct_compl_supp, defaults to TARGET_QUEUE_COMPL), a backend whose I/O completes from interrupt context, and ORDERED commands from the initiator. Linux virtio_scsi guests send only VIRTIO_SCSI_S_SIMPLE and never take the ordered path; any guest that uses the ORDERED task attribute, which vhost-scsi accepts, does. target_do_delayed_work() is a work item and always runs in process context, so spin_lock_irq() is sufficient. Found by inspection; no runtime report. A single ORDERED command goes through both acquisitions, so with CONFIG_PROVE_LOCKING the first one completed through direct completion should produce an inconsistent lock state report on delayed_cmd_lock (hardirq or softirq, depending on where the backend completes).
In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix race in discovery auth updates Separate configfs opens can concurrently update the discovery AuthMethod parameter. Both callers may free the same value in iscsi_update_param_value(), causing a double-free. Protect the lookup and replacement with the discovery TPG access lock, as used by the other TPG configfs parameter updates.
In the Linux kernel, the following vulnerability has been resolved: sched/core: Call wakeup_preempt() for queued tasks during class change Paul reported recent RCU changes exposed a lost resched where CPU idles with a rcutorture thread waiting while being completely runnable. Dumping the rq state at the time of idling with runnable tasks showed the following: rq->next_class = &fair_sched_class rq->nr_running = 1 rq->cfs.h_nr_queued = 0 rq->rt.rt_nr_running = 1 Although the waiting task was an RT task, "rq->next_class" did not point to rt_sched_class and was stuck at the lower priority fair_sched_class. Inspecting sched_change_end() revealed the following race with __sched_setscheduler() for queued, but non-running tasks: CPU0 CPU1 ==== ==== __schedule() /* * rq->donor is a fair task that blocks. * rq->next_class = &fair_sched_class */ rq_lock(rq0) pick_next_task() /* nr_running = 0 */ pick_task_fair() sched_balance_newidle() raw_spin_rq_unlock(rq0) rq_lock(rq0) activate_task(rq0, p) /* p is a fair task */ rq0->nr_running++; rq0->cfs.h_nr_queued++; wakeup_preempt(rq, p) rq->next_class = &fair_sched_class resched_curr() rq_unlock(rq0) __sched_setscheduler(p) /* p is moved to SCHED_RR */ task_rq_lock(p) sched_change_begin() rq0->cfs.h_nr_queued--; rq0->rt.rt_nr_running++; sched_change_end() /* * p->on_rq = 1 (ctx->queued) * but p is not rq->donor * (!ctx->running) hence * resched_curr() is and * rq->next_class upgrade is * skipped. */ task_rq_unlock() raw_spin_rq_lock(rq0) /* * rq->nr_running = 1 * rq->cfs.h_nr_queued = 0 * rq->rt.rt_nr_running = 1 * rq->next_class = &fair_sched_class */ if (rq->cfs.h_nr_queued && ...) /* Above is false */ if (rq_modified_above(this_rq, &fair_sched_class)) /* Also false since rq->next_class is still fair */ /* * sched_balance_newidle() is considered to * have failed to pull any fair tasks and no * other wakeups were detected. */ return NULL; /* pick_task_fair() */ pick_task_idle() return rq->idle; next = rq->idle; /* Preemption indicators are lost */ clear_tsk_need_resched(prev); clear_preempt_need_resched(); rq->curr = rq->idle; !!! rq->idle switches in with rq->running == 1 but !need_resched() !!! In simple words, enqueue, followed by a class change of the newly queued task goes unnoticed in rq->next_class indicator and sched_balance_newidle() sees no fair task, nor any higher priority task enqueued. The above sequence will lead to CPU idling with a runnable task on the CPU. Call wakeup_preempt() for ctx->queued cases in sched_change_end() to re-evaluate rq->next_class after class change (ENQUEUE_CLASS) and set the NEED_RESCHED indicator accordingly. Newidle balance will correctly see an enqueue of a higher priority t ---truncated---
In the Linux kernel, the following vulnerability has been resolved: ocfs2/dlm: Protect the recovery list during debugfs reads Recovery participant records must remain alive while debug_state_print() walks reco.node_data and formats their fields. The formatter holds dlm->spinlock, but the recovery participant list is protected by dlm_reco_state_lock. In particular, dlm_destroy_recovery_area() detaches the list under dlm_reco_state_lock and frees the detached records after releasing it. A concurrent debugfs open can therefore read freed memory. Protect the participant traversal and field reads in debug_state_print() with dlm_reco_state_lock, matching the existing list writers. This also serializes the traversal against list_add_tail() during recovery-area initialization. Make the existing lock available to the debug code through dlmcommon.h; the lock remains internal to the OCFS2 DLM module. Release dlm->spinlock after formatting the other domain state and before acquiring dlm_reco_state_lock, so the debug reader does not nest the two locks. Leave recovery list insertion, detachment and freeing unchanged. KASAN report as below: BUG: KASAN: slab-use-after-free in debug_state_open+0x1169/0x12d0 Read of size 4 at addr ffff88810662ef80 by task dlm-state-stres/896 CPU: 1 UID: 0 PID: 896 Comm: dlm-state-stres Not tainted 7.3.0-rc4-next-20260921-pmb-ocfs2-functional-v1+ #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x93/0xd0 print_report+0xce/0x630 ? debug_state_open+0x1169/0x12d0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x20e/0x420 ? debug_state_open+0x1169/0x12d0 kasan_report+0xe0/0x110 ? debug_state_open+0x1169/0x12d0 debug_state_open+0x1169/0x12d0 ? __pfx_debug_state_open+0x10/0x10 full_proxy_open_regular+0x193/0x310 do_dentry_open+0x595/0x12d0 ? __pfx_full_proxy_open_regular+0x10/0x10 vfs_open_consume+0xd1/0x400 ? srso_alias_return_thunk+0x5/0xfbef5 path_openat+0x18d0/0x2020 ? __pfx_path_openat+0x10/0x10 do_file_open+0x21e/0x470 ? __pfx_do_file_open+0x10/0x10 ? _raw_spin_unlock+0x23/0x40 ? srso_alias_return_thunk+0x5/0xfbef5 ? alloc_fd+0x3a6/0x6b0 do_sys_openat2+0xf4/0x1b0 ? __pfx_do_sys_openat2+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __fput+0x5b5/0xa60 __x64_sys_openat+0x136/0x1e0 ? __pfx___x64_sys_openat+0x10/0x10 do_syscall_64+0x114/0x620 entry_SYSCALL_64_after_hwframe+0x77/0x7f [Register dump omitted.] </TASK> Allocated by task 880: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kmalloc_cache_noprof+0x28d/0x610 dlm_remaster_locks+0x147/0x1d90 dlm_do_recovery+0xde1/0x1580 dlm_recovery_thread+0x109/0x300 kthread+0x351/0x460 ret_from_fork+0x659/0x940 ret_from_fork_asm+0x1a/0x30 Freed by task 880: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x308/0x580 dlm_destroy_recovery_area+0x285/0x460 dlm_remaster_locks+0x17c4/0x1d90 dlm_do_recovery+0xde1/0x1580 dlm_recovery_thread+0x109/0x300 kthread+0x351/0x460 ret_from_fork+0x659/0x940 ret_from_fork_asm+0x1a/0x30 The buggy address belongs to the object at ffff88810662ef80 which belongs to the cache kmalloc-32 of size 32 The buggy address is located 0 bytes inside of freed 32-byte region [ffff88810662ef80, ffff88810662efa0) [Page and memory-state dumps omitted.]
In the Linux kernel, the following vulnerability has been resolved: pipe: preserve existing fasync readers on writer setup failure F_SETFL and FIOASYNC decide whether to invoke ->fasync() before pipe_fasync() takes pipe->mutex. Two enables of one O_RDWR FIFO can therefore both enter the callback. fasync_helper() allocates before checking for an existing entry. If the first enable installs both entries, a second enable can update the reader entry and then fail the allocation for the writer entry. The error path removes the pre-existing reader entry, clearing FASYNC while the writer entry remains registered. __fput() then skips ->fasync(), so a later pipe notification can dereference the freed file or its f_owner. An unprivileged memory-pressure reproducer triggers a KASAN slab-use-after-free in send_sigio() through this path. Keep the reader helper's result and undo the registration only if this call added it. The pipe mutex serializes changes to both lists, so a failed new registration still removes its reader, while a failed duplicate preserves the existing registrations and FASYNC. Successful duplicate enables continue to update fa_fd as before.
In the Linux kernel, the following vulnerability has been resolved: scsi: libsas: Fix SMP IO deadlock during HA resume smp_execute_task_sg() calls pm_runtime_get_sync() on the host before issuing an SMP command. When that command is itself issued from the HA resume path, the get_sync() deadlocks: it waits for the ongoing resume (the device is RPM_RESUMING), while the resume is blocked in sas_drain_work() waiting for that same SMP IO to complete. The deadlock needs an expander-attached SATA disk. During sas_resume_ha() -> sas_drain_work(), DISCE_RESUME -> sas_resume_sata() -> ata_sas_port_resume() requests ATA_EH_RESET, and the hard reset for such a disk is done via SMP PHY CONTROL (sas_ata_hard_reset() -> sas_phy_reset() -> sas_smp_phy_control() -> smp_execute_task_sg()). Direct-attached SATA resets through lldd_control_phy() and SSP devices use TMFs, so neither hits this. Replace the get_sync()/put_sync() pair with pm_runtime_get_noresume()/pm_runtime_put(). smp_execute_task_sg() only needs to hold off autosuspend while the SMP is in flight, and it must not try to resume the host: a sync resume issued from the HA resume path itself is what deadlocks, and by the time sas_resume_ha() runs, hw_init has already reinitialized the hardware, so the device is accessible without one. The usage reference is still required. Discovery work normally runs inside an event worker's PM reference, taken at sas_notify_port_event() notify time and held until the handler has flushed the disco queue. sas_rediscover_ex_phy() however requeues DISCE_REVALIDATE_DOMAIN from within the revalidation worker itself, and flush_workqueue() does not wait for work items queued during execution, so that chained revalidation runs with no outer PM reference - without the get_noresume(), its SMP could race autosuspend. For the BSG path, sas_smp_handler() is the only caller which may find the host autosuspended: expander SMP requests do not go through any SCSI device request queue, so nothing else in that path holds the host awake. Resume it there with pm_runtime_resume_and_get() and check the result.
In the Linux kernel, the following vulnerability has been resolved: netlink: avoid hashing the network namespace pointer The netlink rhashtable key includes a raw struct net pointer and a user-controlled port ID. Both /proc/net/netlink and socket diagnostics expose the table's bucket order. By binding and rebinding chosen NETLINK_USERSOCK port IDs, an unprivileged reader can distinguish equal buckets and recover the low bits of the Jenkins hash. Its 32-bit seed and the limited set of kernel-image slides can then be searched offline to recover the address of init_net. Use the namespace's unique, non-address net_cookie in the comparison key instead. It is assigned before the per-net initializers run and remains unchanged for the namespace's lifetime. The lookup key and object hash are still built by netlink_compare_arg_init(), keeping lookup, insertion, removal and rehashing consistent while preserving namespace separation. Neither public table walker needs to change. Reading the socket's namespace cookie in netlink_compare() is safe under RCU, including during namespace teardown. netlink_release() removes the socket from the hash table and defers its final put with call_rcu(). cleanup_net() runs the per-net exit methods and waits for outstanding RCU callbacks with rcu_barrier() before freeing namespace storage. Unlike ns.ns_id, net_cookie is also available and initialized during setup_net() in older stable kernels, making the change straightforward to backport to v5.15 and later.
In the Linux kernel, the following vulnerability has been resolved: net: hisilicon: hisi_femac: Move setting of netops to fix crash hisi_femac_drv_probe() connects the PHY before dev->netdev_ops is assigned. phy_attach_direct() -> phy_link_topo_add_phy() reads dev->netdev_ops through netdev_need_ops_lock() since the commit in question, so probing crashes with a NULL pointer dereference when CONFIG_NET_SHAPER is enabled. phy_link_topo_add_phy from phy_attach_direct+0xec/0x37c of_phy_get_and_connect from hisi_femac_drv_probe+0x1f4/0x558 Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b Assign netdev_ops before the PHY attach, as was done for emac in commit 7c9f391ec89c ("net: emac: move setting of netops to fix crash").
In the Linux kernel, the following vulnerability has been resolved: net: hisilicon: hip04_eth: Move setting of netops to fix crash hip04_mac_probe() calls of_phy_connect() before ndev->netdev_ops is assigned. phy_attach_direct() -> phy_link_topo_add_phy() reads dev->netdev_ops through netdev_need_ops_lock() since the commit in question, so probing crashes with a NULL pointer dereference when CONFIG_NET_SHAPER is enabled. Assign netdev_ops before the PHY attach, as was done for emac in commit 7c9f391ec89c ("net: emac: move setting of netops to fix crash").
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: actions: Move setting of netops to fix crash owl_emac_probe() calls owl_emac_phy_init(), which connects the PHY, before netdev->netdev_ops is assigned. phy_attach_direct() -> phy_link_topo_add_phy() reads dev->netdev_ops through netdev_need_ops_lock() since the commit in question, so probing crashes with a NULL pointer dereference when CONFIG_NET_SHAPER is enabled. Assign netdev_ops before the PHY attach, as was done for emac in commit 7c9f391ec89c ("net: emac: move setting of netops to fix crash").
In the Linux kernel, the following vulnerability has been resolved: net: mv643xx: move setting of netops to fix crash mv643xx_eth_probe() connects the PHY before dev->netdev_ops is assigned. phy_attach_direct() -> phy_link_topo_add_phy() reads dev->netdev_ops through netdev_need_ops_lock() since the commit in question, so probing crashes with a NULL pointer dereference when CONFIG_NET_SHAPER is enabled. Assign netdev_ops before the PHY attach, as was done for emac in commit 7c9f391ec89c ("net: emac: move setting of netops to fix crash").
In the Linux kernel, the following vulnerability has been resolved: net: au1000: move setting of netops to fix crash au1000_probe() calls au1000_mii_probe(), which connects the PHY, before dev->netdev_ops is assigned. phy_attach_direct() -> phy_link_topo_add_phy() reads dev->netdev_ops through netdev_need_ops_lock() since the commit in question, so probing crashes with a NULL pointer dereference when CONFIG_NET_SHAPER is enabled. Assign netdev_ops before the PHY attach, as was done for emac in commit 7c9f391ec89c ("net: emac: move setting of netops to fix crash").
In the Linux kernel, the following vulnerability has been resolved: net: ethoc: move setting of netops to fix crash ethoc_probe() calls ethoc_mdio_probe(), which connects the PHY, before netdev->netdev_ops is assigned. phy_attach_direct() -> phy_link_topo_add_phy() reads dev->netdev_ops through netdev_need_ops_lock() since the commit in question, so probing crashes with a NULL pointer dereference when CONFIG_NET_SHAPER is enabled. Assign netdev_ops before the PHY attach, as was done for emac in commit 7c9f391ec89c ("net: emac: move setting of netops to fix crash").
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: aeroflex: move setting of netops to fix crash greth_of_probe() calls greth_mdio_init(), which connects the PHY, before dev->netdev_ops is assigned. phy_attach_direct() -> phy_link_topo_add_phy() reads dev->netdev_ops through netdev_need_ops_lock() since the commit in question, so probing crashes with a NULL pointer dereference when CONFIG_NET_SHAPER is enabled. Assign netdev_ops before the PHY attach, as was done for emac in commit 7c9f391ec89c ("net: emac: move setting of netops to fix crash").
In the Linux kernel, the following vulnerability has been resolved: net: ti: icssm-prueth: Move setting of netops to fix crash icssm_prueth_netdev_init() calls of_phy_get_and_connect() before ndev->netdev_ops is assigned. phy_attach_direct() -> phy_link_topo_add_phy() reads dev->netdev_ops through netdev_need_ops_lock() since the commit in question, so probing crashes with a NULL pointer dereference when CONFIG_NET_SHAPER is enabled. Assign netdev_ops before the PHY attach, as was done for emac in commit 7c9f391ec89c ("net: emac: move setting of netops to fix crash").
In the Linux kernel, the following vulnerability has been resolved: net: bcmgenet: unshare the skb before writing the control block bcmgenet stores first_cb, last_cb and bytes_sent in the skb control block and reads them back on completion to free the skb and credit BQL. ether_setup() leaves IFF_TX_SKB_SHARING set, so the stack can resubmit a shared skb that is still in the ring. The next transmit overwrites last_cb, so the earlier slots complete without crediting their bytes and BQL stalls the queue until the watchdog resets it. Unshare the skb before writing the control block. Reproduce with pktgen in clone_skb mode, which hands the driver the same skb while earlier copies are still in the ring: modprobe pktgen pg=/proc/net/pktgen echo "add_device eth0" > $pg/kpktgend_0 echo "dst_mac AA:BB:CC:DD:EE:FF" > $pg/eth0 echo "dst 192.0.2.1" > $pg/eth0 echo "clone_skb 8" > $pg/eth0 echo "count 0" > $pg/eth0 echo start > $pg/pgctrl & sleep 5 echo stop > $pg/pgctrl wait cat /sys/class/net/eth0/queues/tx-0/byte_queue_limits/inflight inflight stays nonzero on the now idle queue. clone_skb 0 leaves it at zero.
In the Linux kernel, the following vulnerability has been resolved: calipso: keep BIG TCP payload_len in calipso_skbuff_setattr() calipso_skbuff_setattr() adjusts payload_len by the length of the option it inserts or resizes: payload = ntohs(ip6_hdr->payload_len); ip6_hdr->payload_len = htons(payload + len_delta); GRO can build BIG TCP packets larger than IPV6_MAXPLEN, and stores payload_len == 0 for them; ipv6_payload_len() then falls back to skb->len. For such a packet forwarded to a destination mapped to CALIPSO, the code above writes len_delta (or 65536 + len_delta when shrinking) into payload_len, and ipv6_payload_len() no longer falls back to skb->len. nf_tables, conntrack and sch_cake rely on it. The same arithmetic also wraps when a packet grows past IPV6_MAXPLEN, and a BIG TCP packet that shrinks below IPV6_MAXPLEN should get its real length back. Set payload_len from the skb length with ipv6_set_payload_len(), which stores 0 above IPV6_MAXPLEN and the real length otherwise, as ipv6_gro_complete() does. The network header was just reset to skb->data, so skb->len - sizeof(*ip6_hdr) is the payload length. Tested on one kernel (arm64, QEMU) with SELinux permissive, a minimal mdp-generated policy (network_peer_controls=1), "netlabelctl calipso add pass doi:16" and a NetLabel mapping of fd00:2::/64 to CALIPSO DOI 16. calipso_skbuff_setattr() was called through netlbl_skbuff_setattr() from a test-only debugfs hook (not part of this patch) adding a level-only label; payload_len after the call: case before fix after fix real length 1000, unlabeled 1016 1016 1016 70000 GSO, payload_len 0 16 0 70016 65530 GSO, grows past MAXPLEN 10 0 65546 65540 GSO with a 24 byte hop header, shrinks below MAXPLEN 65528 65532 65532 1000 with a 24 byte hop header 992 992 992 (0 means ipv6_payload_len() returns the real length.) On the forward path, with a client injecting unlabeled UDP through a router to a server, the router adds the CALIPSO option and the server delivers all datagrams (Udp6InDatagrams 5, Ip6InTruncatedPkts 0) with this patch.
In the Linux kernel, the following vulnerability has been resolved: gpiolib: fix memory leak in gpiod_set_array_value_complex() on error paths A drive-by review by Sashiko reports that, after a failed call to gpiochip_set_multiple(), gpiod_set_array_value() returns abruptly, bypassing the freeing of possibly alloced bitmaps, potentially leaking memory. It is an unlikely error path, but is possible. Defer the return code check until after the bitmap_free() block.