<?xml version="1.0" encoding="UTF-8"?>
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1" xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.1">
  <DocumentTitle xml:lang="en">SUSE-IU-2025:2550-1</DocumentTitle>
  <DocumentType>SUSE Image</DocumentType>
  <DocumentPublisher Type="Vendor">
    <ContactDetails>security@suse.de</ContactDetails>
    <IssuingAuthority>SUSE Security Team</IssuingAuthority>
  </DocumentPublisher>
  <DocumentTracking>
    <Identification>
      <ID>SUSE Image SUSE-IU-2025:2550-1</ID>
    </Identification>
    <Status>Interim</Status>
    <Version>1</Version>
    <RevisionHistory>
      <Revision>
        <Number>1</Number>
        <Date>2026-03-19T08:57:22Z</Date>
        <Description>current</Description>
      </Revision>
    </RevisionHistory>
    <InitialReleaseDate>2025-09-20T01:00:00Z</InitialReleaseDate>
    <CurrentReleaseDate>2025-09-20T01:00:00Z</CurrentReleaseDate>
    <Generator>
      <Engine>cve-database/bin/generate-cvrf-publiccloud.pl</Engine>
      <Date>2021-02-18T01:00:00Z</Date>
    </Generator>
  </DocumentTracking>
  <DocumentNotes>
    <Note Title="Topic" Type="Summary" Ordinal="1" xml:lang="en">Image update for SUSE-IU-2025:2550-1 / google/sle-hpc-15-sp7-byos-v20250920-x86-64</Note>
    <Note Title="Details" Type="General" Ordinal="2" xml:lang="en">This image update for google/sle-hpc-15-sp7-byos-v20250920-x86-64 contains the following changes:
Package bind was updated:

- Upgrade to release 9.20.11  Security Fixes:
  * Fix a possible assertion failure when
    stale-answer-client-timeout is set to 0. In specific
    circumstances the named resolver process could exit with an
    assertion failure when stale answers were enabled and the
    stale-answer-client-timeout configuration option was set to 0.
    (CVE-2025-40777)
    [bsc#1246548]
  New Features:
  * Add support for the CO flag to dig.
  * Implement a new notify-defer configuration option. This new
    option sets a delay (in seconds) to wait before sending a set
    of NOTIFY messages for a zone. Whenever a NOTIFY message is
    ready to be sent, sending is deferred for this duration. This
    option should not be confused with the notify-delay option. The
    default is 0 seconds.
  Removed Features:
  * Implement the systemd notification protocol manually to remove
    dependency on libsystemd.
  Bug Fixes:
  * Correct the default interface-interval from 60s to 60m.
  * Fix a purge-keys bug when using multiple views of a zone.
  * Use IPv6 queries in delv +ns.
  * A secondary zone could initiate a new zone transfer from the
    primary server after it had been already deleted from the
    secondary server, and before the internal garbage collection
    was activated to clean it up completely. This has been fixed.
  * A secondary zone could fail to further refresh with new
    versions of the zone from a primary server if named was
    reconfigured during the SOA request step of an ongoing zone
    transfer. This has been fixed.
- Clean up systemd BuildRequires

Package boost was updated:

- CVE-2016-9840: fixed out-of-bounds pointer arithmetic in zlib in beast  (bsc#1245936)
  - adds patch boost-zlib.patch

Package cifs-utils was updated:

- Add patches:  * 0001-cifs.upcall-correctly-treat-UPTARGET_UNSPECIFIED-as-.patch
  (bsc#1243488)
  * 0001-mount.cifs-retry-mount-on-EINPROGRESS.patch

Package cloud-regionsrv-client was updated:

- Update version to 10.5.2 (bsc#1247539)  + When an instance fails verification server side the default credentials
    were left behind requireing manual intervantion prior to the next
    registration attempt.
  + Fix issue triggered when using instance-billing-flavor-check due to
    IP address handling as object rather than string introduced 10.5.0

- Update version to 10.5.1
  + Fix issue with picking up configured server names from the
    regionsrv config file. Previously only IP addresses were collected
  + Update scriptlet for package uninstall to avoid issues in the
    build service

- Update version to 10.5.0
  + Use region server IP addresses to determine Internet access rather
    than a generic address. Region server IP addresses may not be blocked
    in the network construct. (bsc#1245305)

Package coreutils was updated:

- coreutils-9.7-sort-CVE-2025-5278.patch: Add upstream patch:  sort with key character offsets of SIZE_MAX, could induce
  a read of 1 byte before an allocated heap buffer.
  (CVE-2025-5278, bsc#1243767)

Package crypto-policies was updated:

- Update the BSI policy [jsc#PED-12880]  * BSI: switch to 3072 minimum RSA key size [322f0ba4]
  * BSI: Update BSI policy for new 2024 minimum [64b9dddd]
  * Add patches:
  - crypto-policies-BSI-Update-BSI-policy-for-new-2024-minimum-recommend.patch
  - crypto-policies-BSI-switch-to-3072-minimum-RSA-key-size.patch

Package curl was updated:

- tool_operate: fix return code when --retry is used but not  triggered [bsc#1249367]
  * Add curl-tool_operate-fix-return-code-when-retry-is-used.patch

- Security fixes:
  * [bsc#1249191, CVE-2025-9086] Out of bounds read for cookie path
  * [bsc#1249348, CVE-2025-10148] Predictable WebSocket mask
  * Add patches:
  - curl-CVE-2025-9086.patch
  - curl-CVE-2025-10148.patch

- Fix the --ftp-pasv option in curl v8.14.1 [bsc#1246197]
  * tool_getparam: fix --ftp-pasv [5f805ee]
  * Add curl-fix--ftp-pasv.patch

- Update to 8.14.1: [jsc#PED-13055, jsc#PED-13056]
  * Add _multibuild
  * Remove patches fixed in the update:
  - curl-CVE-2024-11053.patch
  - curl-CVE-2024-2004.patch
  - curl-CVE-2024-2379.patch
  - curl-CVE-2024-2398.patch
  - curl-CVE-2024-2466.patch
  - curl-CVE-2024-6197.patch
  - curl-CVE-2024-7264.patch
  - curl-CVE-2024-8096.patch
  - curl-CVE-2024-9681.patch
  - curl-CVE-2025-0167.patch
  - curl-CVE-2025-0725.patch
  - curl-aws_sigv4-url-encode-the-canonical-path.patch
  - curl-mstp-starttls.patch

- Sync spec file with SLE codestreams: [jsc#PED-13055, jsc#PED-13056]
  * Add curl-mini.rpmlintrc to avoid rpmlint shlib-policy-name-error
    when building the curl-mini package in SLE.
  * Add libssh minimum version requirements.
  * Use ldconfig_scriptlets when available.
  * Remove unused option --disable-ntlm-wb.

- Update to 8.14.1:
  * Security fixes:
  - [bsc#1243933, CVE-2025-5399] libcurl can possibly get
    trapped in an endless busy-loop when processing specially
    crafted packets [d1145df2]
  * Bugfixes:
  - asyn-thrdd: fix cleanup when RR fails due to OOM
  - ftp: fix teardown of DATA connection in done
  - http: fail early when rewind of input failed when following redirects
  - multi: fix add_handle resizing
  - tls BIOs: handle BIO_CTRL_EOF correctly
  - tool_getparam: make --no-anyauth not be accepted
  - wolfssl: fix sending of early data
  - ws: handle blocked sends better
  - ws: tests and fixes

- Update to 8.14.0:
  * Security fixes:
  - [CVE-2025-4947, bsc#1243397] QUIC certificate check skip with wolfSSL
  - [CVE-2025-5025, bsc#1243706] No QUIC certificate pinning with wolfSSL
  * Changes:
  - mqtt: send ping at upkeep interval
  - schannel: handle pkcs12 client certificates containing CA certificates
  - TLS: add CURLOPT_SSL_SIGNATURE_ALGORITHMS and --sigalgs
  - vquic: ngtcp2 + openssl support
  - wcurl: import v2025.04.20 script + docs
  - websocket: add option to disable auto-pong reply
  * Bugfixes:
  - asny-thrdd: fix detach from running thread
  - async-threaded resolver: use ref counter
  - async: DoH improvements
  - build: enable gcc-12/13+, clang-10+ picky warnings
  - build: enable gcc-15 picky warnings
  - certs: drop unused `default_bits` from `.prm` files
  - cf-https-connect: use the passed in dns struct pointer
  - cf-socket: fix FTP accept connect
  - cfilters: remove assert
  - cmake: fix nghttp3 static linking with `USE_OPENSSL_QUIC=ON`
  - cmake: prefer `COMPILE_OPTIONS` over `CMAKE_C_FLAGS` for custom C options
  - cmake: revert `CURL_LTO` behavior for multi-config generators
  - configure: fix --disable-rt
  - CONTRIBUTE: add project guidelines for AI use
  - cpool/cshutdown: force close connections under pressure
  - curl: fix memory leak when -h is used in config file
  - curl_get_line: handle lines ending on the buffer boundary
  - headers: enforce a max number of response header to accept
  - http: fix HTTP/2 handling of TE request header using &amp;quot;trailers&amp;quot;
  - lib: include files using known path
  - lib: unify conversions to/from hex
  - libssh: add NULL check for Curl_meta_get()
  - libssh: fix memory leak
  - mqtt: use conn/easy meta hash
  - multi: do transfer book keeping using mid
  - multi: init_do(): check result
  - netrc: avoid NULL deref on weird input
  - netrc: avoid strdup NULL
  - netrc: deal with null token better
  - openssl-quic: avoid potential `-Wnull-dereference`, add assert
  - openssl-quic: fix shutdown when stream not open
  - openssl: enable builds for *both* engines and providers
  - openssl: set the cipher string before doing private cert
  - progress: avoid integer overflow when gathering total transfer size
  - rand: update comment on Curl_rand_bytes weak random
  - rustls: make max size of cert and key reasonable
  - smb: avoid integer overflow on weird input date
  - urlapi: redirecting to &amp;quot;&amp;quot; is considered fine
  * Remove curl-8.13.0-CloseSocket.patch upstream
  * Rebase libcurl-ocloexec.patch

- fix Leap build add curl-8.13.0-CloseSocket.patch

- Update to 8.13.0:
  * Changes:
  - curl: add write-out variable 'tls_earlydata'
  - curl: make --url support a file with URLs
  - gnutls: set priority via --ciphers
  - IMAP: add CURLOPT_UPLOAD_FLAGS and --upload-flags
  - lib: add CURLFOLLOW_OBEYCODE and CURLFOLLOW_FIRSTONLY
  - OpenSSL/quictls: add support for TLSv1.3 early data
  - rustls: add support for CERTINFO
  - rustls: add support for SSLKEYLOGFILE
  - rustls: support ECH w/ DoH lookup for config
  - rustls: support native platform verifier
  - var: add a '64dec' function that can base64 decode a string
  * Bugfixes:
  - conn: fix connection reuse when SSL is optional
  - hash: use single linked list for entries
  - http2: detect session being closed on ingress handling
  - http2: reset stream on response header error
  - http: remove a HTTP method size restriction
  - http: version negotiation
  - httpsrr: fix port detection
  - libssh: fix freeing of resources in disconnect
  - libssh: fix scp large file upload for 32-bit size_t systems
  - openssl-quic: do not iterate over multi handles
  - openssl: check return value of X509_get0_pubkey
  - openssl: drop support for old OpenSSL/LibreSSL versions
  - openssl: fix crash on missing cert password
  - openssl: fix pkcs11 URI checking for key files.
  - openssl: remove bad `goto`s into other scope
  - setopt: illegal CURLOPT_SOCKS5_AUTH should return error
  - setopt: setting PROXYUSERPWD after PROXYUSERNAME/PASSWORD is fine
  - sshserver.pl: adjust `AuthorizedKeysFile2` cutoff version
  - sshserver: fix excluding obsolete client config lines
  - SSLCERTS: list support for SSL_CERT_FILE and SSL_CERT_DIR
  - tftpd: prefix TFTP protocol error `E*` constants with `TFTP_`
  - tool_operate: fail SSH transfers without server auth
  - url: call protocol handler's disconnect in Curl_conn_free
  - urlapi: remove percent encoded dot sequences from the URL path
  - urldata: remove 'hostname' from struct Curl_async
  * Rebase patches:
  - libcurl-ocloexec.patch
  - curl-secure-getenv.patch

- Update to 8.12.1:
  * Bugfixes:
  - asyn-thread: fix build with 'CURL_DISABLE_SOCKETPAIR'
  - asyn-thread: fix HTTPS RR crash
  - asyn-thread: fix the returned bitmask from Curl_resolver_getsock
  - asyn-thread: survive a c-ares channel set to NULL
  - cmake: always reference OpenSSL and ZLIB via imported targets
  - cmake: respect 'GNUTLS_CFLAGS' when detected via 'pkg-config'
  - cmake: respect 'GNUTLS_LIBRARY_DIRS' in 'libcurl.pc' and 'curl-config'
  - content_encoding: #error on too old zlib
  - imap: TLS upgrade fix
  - ldap: drop support for legacy Novell LDAP SDK
  - libssh2: comparison is always true because rc &amp;lt;= -1
  - libssh2: raise lowest supported version to 1.2.8
  - libssh: drop support for libssh older than 0.9.0
  - openssl-quic: ignore ciphers for h3
  - pop3: TLS upgrade fix
  - runtests: fix the disabling of the memory tracking
  - runtests: quote commands to support paths with spaces
  - scache: add magic checks
  - smb: silence '-Warray-bounds' with gcc 13+
  - smtp: TLS upgrade fix
  - tool_cfgable: sort struct fields by size, use bitfields for booleans
  - tool_getparam: add &amp;quot;TLS required&amp;quot; flag for each such option
  - vtls: fix multissl-init
  - wakeup_write: make sure the eventfd write sends eight bytes

- Update to 8.12.0:
  * Security fixes:
  - [bsc#1234068, CVE-2024-11053] curl could leak the password used
    for the first host to the followed-to host under certain circumstances.
  - [bsc#1232528, CVE-2024-9681] HSTS subdomain overwrites parent cache entry
  - [bsc#1236589, CVE-2025-0665] eventfd double close
  * Changes:
  - curl: add byte range support to --variable reading from file
  - curl: make --etag-save acknowledge --create-dirs
  - getinfo: fix CURLINFO_QUEUE_TIME_T and add 'time_queue' var
  - getinfo: provide info which auth was used for HTTP and proxy
  - hyper: drop support
  - openssl: add support to use keys and certificates from PKCS#11 provider
  - QUIC: 0RTT for gnutls via CURLSSLOPT_EARLYDATA
  - vtls: feature ssls-export for SSL session im-/export
  * Bugfixes:
  - altsvc: avoid integer overflow in expire calculation
  - asyn-ares: acknowledge CURLOPT_DNS_SERVERS set to NULL
  - asyn-ares: fix memory leak
  - asyn-ares: initial HTTPS resolve support
  - asyn-thread: use c-ares to resolve HTTPS RR
  - async-thread: avoid closing eventfd twice
  - cd2nroff: do not insist on quoted &amp;lt;&amp;gt; within backticks
  - cd2nroff: support &amp;quot;none&amp;quot; as a TLS backend
  - conncache: count shutdowns against host and max limits
  - content_encoding: drop support for zlib before 1.2.0.4
  - content_encoding: namespace GZIP flag constants
  - content_encoding: put the decomp buffers into the writer structs
  - content_encoding: support use of custom libzstd memory functions
  - cookie: cap expire times to 400 days
  - cookie: parse only the exact expire date
  - curl: return error if etag options are used with multiple URLs
  - curl_multi_fdset: include the shutdown connections in the set
  - curl_sha512_256: rename symbols to the curl namespace
  - curl_url_set.md: adjust the added-in to 7.62.0
  - doh: send HTTPS RR requests for all HTTP(S) transfers
  - easy: allow connect-only handle reuse with easy_perform
  - easy: make curl_easy_perform() return error if connection still there
  - easy_lock: use Sleep(1) for thread yield on old Windows
  - ECH: update APIs to those agreed with OpenSSL maintainers
  - GnuTLS: fix 'time_appconnect' for early data
  - HTTP/2: strip TE request header
  - http2: fix data_pending check
  - http2: fix value stored to 'result' is never read
  - http: ignore invalid Retry-After times
  - http_aws_sigv4: Fix invalid compare function handling zero-length pairs
  - https-connect: start next immediately on failure
  - lib: redirect handling by protocol handler
  - multi: fix curl_multi_waitfds reporting of fd_count
  - netrc: 'default' with no credentials is not a match
  - netrc: fix password-only entries
  - netrc: restore _netrc fallback logic
  - ngtcp2: fix memory leak on connect failure
  - openssl: define `HAVE_KEYLOG_CALLBACK` before use
  - openssl: fix ECH logic
  - osslq: use SSL_poll to determine writeability of QUIC streams
  - sectransp: free certificate on error
  - select: avoid a NULL deref in cwfds_add_sock
  - src: omit hugehelp and ca-embed from libcurltool
  - ssl session cache: change cache dimensions
  - system.h: add 64-bit curl_off_t definitions for NonStop
  - telnet: handle single-byte input option
  - TLS: check connection for SSL use, not handler
  - tool_formparse.c: make curlx_uztoso a static in here
  - tool_formparse: accept digits in --form type= strings
  - tool_getparam: ECH param parsing refix
  - tool_getparam: fail --hostpubsha256 if libssh2 is not used
  - tool_getparam: fix &amp;quot;Ignored Return Value&amp;quot;
  - tool_getparam: fix memory leak on error in parse_ech
  - tool_getparam: fix the ECH parser
  - tool_operate: make --etag-compare always accept a non-existing file
  - transfer: fix CURLOPT_CURLU override logic
  - urlapi: fix redirect to a new fragment or query (only)
  - vquic: make vquic_send_packets not return without setting psent
  - vtls: fix default SSL backend as a fallback
  - vtls: only remember the expiry timestamp in session cache
  - websocket: fix message send corruption
  - x509asn1: add parse recursion limit
  * Rebase pathes:
  - libcurl-ocloexec.patch
  - dont-mess-with-rpmoptflags.patch

Package cyrus-sasl was updated:

- Add Channel Binding support for GSSAPI/GSS-SPNEGO; (bsc#1229655);  (jsc#PED-12097); Add patch
  0009-Add-Channel-Binding-support-for-GSSAPI-GSS-SPNEGO.patch
- Add support for setting max ssf 0 to GSS-SPNEGO; (bsc#1229655);
  (jsc#PED-12097); Add patch
  0010-Add-support-for-setting-max-ssf-0-to-GSS-SPNEGO.patch

Package docker was updated:

- Update to Docker 28.3.3-ce. See upstream changelog online at  &amp;lt;https://docs.docker.com/engine/release-notes/28/#2833&amp;gt;
  CVE-2025-54388 bsc#1247367

- Update to docker-buildx v0.26.1. Upstream changelog:
  &amp;lt;https://github.com/docker/buildx/releases/tag/v0.26.1&amp;gt;

- Update to docker-buildx v0.26.0. Upstream changelog:
  &amp;lt;https://github.com/docker/buildx/releases/tag/v0.26.0&amp;gt;

- Update to Go 1.24 for builds, to match upstream.

- Update to Docker 28.3.2-ce. See upstream changelog online at
  &amp;lt;https://docs.docker.com/engine/release-notes/28/#2832&amp;gt;

- Update to Docker 28.3.1-ce. See upstream changelog online at
  &amp;lt;https://docs.docker.com/engine/release-notes/28/#2831&amp;gt;

- Update to Docker 28.3.0-ce. See upstream changelog online at
  &amp;lt;https://docs.docker.com/engine/release-notes/28/#2830&amp;gt;
  bsc#1246556
- Rebase patches:
  * 0001-SECRETS-SUSE-always-clear-our-internal-secrets.patch
  * 0002-SECRETS-daemon-allow-directory-creation-in-run-secre.patch
  * 0003-SECRETS-SUSE-implement-SUSE-container-secrets.patch
  * 0004-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch
  * 0005-bsc1073877-apparmor-clobber-docker-default-profile-o.patch
  * 0006-SLE12-revert-apparmor-remove-version-conditionals-fr.patch

[ This update is a no-op, only needed to work around unfortunate automated
  packaging script behaviour on SLES. ]
- The following patches were removed in openSUSE in the Docker 28.1.1-ce
  update, but the patch names were later renamed in a SLES-only update before
  Docker 28.1.1-ce was submitted to SLES.
  This causes the SLES build scripts to refuse the update because the patches
  are not referenced in the changelog. There is no obvious place to put the
  patch removals (the 28.1.1-ce update removing the patches chronologically
  predates their renaming in SLES), so they are included here a dummy changelog
  entry to work around the issue.
  - 0007-CVE-2025-22868-vendor-jws-split-token-into-fixed-num.patch
  - 0008-CVE-2025-22869-vendor-ssh-limit-the-size-of-the-inte.patch

- Update to docker-buildx v0.25.0. Upstream changelog:
  &amp;lt;https://github.com/docker/buildx/releases/tag/v0.25.0&amp;gt;

- Do not try to inject SUSEConnect secrets when in Rootless Docker mode, as
  Docker does not have permission to access the host zypper credentials in this
  mode (and unprivileged users cannot disable the feature using
  /etc/docker/suse-secrets-enable.) bsc#1240150
  * 0003-SECRETS-SUSE-implement-SUSE-container-secrets.patch
- Rebase patches:
  * 0001-SECRETS-SUSE-always-clear-our-internal-secrets.patch
  * 0002-SECRETS-daemon-allow-directory-creation-in-run-secre.patch
  * 0004-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch
  * 0005-bsc1073877-apparmor-clobber-docker-default-profile-o.patch
  * 0006-SLE12-revert-apparmor-remove-version-conditionals-fr.patch

- Always clear SUSEConnect suse_* secrets when starting containers regardless
  of whether the daemon was built with SUSEConnect support. Not doing this
  causes containers from SUSEConnect-enabled daemons to fail to start when
  running with SUSEConnect-disabled (i.e. upstream) daemons.
  This was a long-standing issue with our secrets support but until recently
  this would've required migrating from SLE packages to openSUSE packages
  (which wasn't supported). However, as SLE Micro 6.x and SLES 16 will move
  away from in-built SUSEConnect support, this is now a practical issue users
  will run into. bsc#1244035
  + 0001-SECRETS-SUSE-always-clear-our-internal-secrets.patch
- Rearrange patches:
  - 0001-SECRETS-daemon-allow-directory-creation-in-run-secre.patch
  + 0002-SECRETS-daemon-allow-directory-creation-in-run-secre.patch
  - 0002-SECRETS-SUSE-implement-SUSE-container-secrets.patch
  + 0003-SECRETS-SUSE-implement-SUSE-container-secrets.patch
  - 0003-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch
  + 0004-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch
  - 0004-bsc1073877-apparmor-clobber-docker-default-profile-o.patch
  + 0005-bsc1073877-apparmor-clobber-docker-default-profile-o.patch
  - 0005-SLE12-revert-apparmor-remove-version-conditionals-fr.patch
  + 0006-SLE12-revert-apparmor-remove-version-conditionals-fr.patch

[NOTE: This update was only ever released in SLES and Leap.]
- Always clear SUSEConnect suse_* secrets when starting containers regardless
  of whether the daemon was built with SUSEConnect support. Not doing this
  causes containers from SUSEConnect-enabled daemons to fail to start when
  running with SUSEConnect-disabled (i.e. upstream) daemons.
  This was a long-standing issue with our secrets support but until recently
  this would've required migrating from SLE packages to openSUSE packages
  (which wasn't supported). However, as SLE Micro 6.x and SLES 16 will move
  away from in-built SUSEConnect support, this is now a practical issue users
  will run into. bsc#1244035
  + 0001-SECRETS-SUSE-always-clear-our-internal-secrets.patch
- Rearrange patches:
  - 0001-SECRETS-daemon-allow-directory-creation-in-run-secre.patch
  + 0002-SECRETS-daemon-allow-directory-creation-in-run-secre.patch
  - 0002-SECRETS-SUSE-implement-SUSE-container-secrets.patch
  + 0003-SECRETS-SUSE-implement-SUSE-container-secrets.patch
  - 0003-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch
  + 0004-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch
  - 0004-bsc1073877-apparmor-clobber-docker-default-profile-o.patch
  + 0005-bsc1073877-apparmor-clobber-docker-default-profile-o.patch
  - 0005-SLE12-revert-apparmor-remove-version-conditionals-fr.patch
  + 0006-SLE12-revert-apparmor-remove-version-conditionals-fr.patch
  - 0006-CVE-2025-22868-vendor-jws-split-token-into-fixed-num.patch
  + 0007-CVE-2025-22868-vendor-jws-split-token-into-fixed-num.patch
  - 0007-CVE-2025-22869-vendor-ssh-limit-the-size-of-the-inte.patch
  + 0008-CVE-2025-22869-vendor-ssh-limit-the-size-of-the-inte.patch

- Update to Docker 28.2.2-ce. See upstream changelog online at
  &amp;lt;https://docs.docker.com/engine/release-notes/28/#2822&amp;gt;
- Rebase patches:
  * 0001-SECRETS-daemon-allow-directory-creation-in-run-secre.patch
  * 0002-SECRETS-SUSE-implement-SUSE-container-secrets.patch
  * 0003-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch
  * 0004-bsc1073877-apparmor-clobber-docker-default-profile-o.patch
  * 0005-SLE12-revert-apparmor-remove-version-conditionals-fr.patch

- Update to Docker 28.2.1-ce. See upstream changelog online at
  &amp;lt;https://docs.docker.com/engine/release-notes/28/#2820&amp;gt; bsc#1243833
  &amp;lt;https://github.com/moby/moby/releases/tag/v28.2.1&amp;gt;
- Rebase patches:
  * 0001-SECRETS-daemon-allow-directory-creation-in-run-secre.patch
  * 0002-SECRETS-SUSE-implement-SUSE-container-secrets.patch
  * 0003-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch
  * 0004-bsc1073877-apparmor-clobber-docker-default-profile-o.patch
  * 0005-SLE12-revert-apparmor-remove-version-conditionals-fr.patch

- Update to docker-buildx v0.24.0. Upstream changelog:
  &amp;lt;https://github.com/docker/buildx/releases/tag/v0.24.0&amp;gt;

- Update to Docker 28.1.1-ce. See upstream changelog online at
  &amp;lt;https://docs.docker.com/engine/release-notes/28/#2811&amp;gt; bsc#1242114
  Includes upstream fixes:
  - CVE-2025-22872 bsc#1241830
- Remove long-outdated build handling for deprecated and unsupported
  devicemapper and AUFS storage drivers. AUFS was removed in v24, and
  devicemapper was removed in v25.
  &amp;lt;https://docs.docker.com/engine/deprecated/#aufs-storage-driver&amp;gt;
- Rebase patches:
  * 0001-SECRETS-daemon-allow-directory-creation-in-run-secre.patch
  * 0002-SECRETS-SUSE-implement-SUSE-container-secrets.patch
  * 0003-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch
  * 0004-bsc1073877-apparmor-clobber-docker-default-profile-o.patch
  * 0005-SLE12-revert-apparmor-remove-version-conditionals-fr.patch
- Remove upstreamed patches:
  - 0006-CVE-2025-22868-vendor-jws-split-token-into-fixed-num.patch
  - 0007-CVE-2025-22869-vendor-ssh-limit-the-size-of-the-inte.patch
  - cli-0001-docs-include-required-tools-in-source-tree.patch

- Update to docker-buildx v0.23.0. Upstream changelog:
  &amp;lt;https://github.com/docker/buildx/releases/tag/v0.23.0&amp;gt;

- Update to docker-buildx v0.22.0. Upstream changelog:
  &amp;lt;https://github.com/docker/buildx/releases/tag/v0.22.0&amp;gt;
  * Includes fixes for CVE-2025-0495. bsc#1239765

- Disable transparent SUSEConnect support for SLE-16. PED-12534
  When this patchset was first added in 2013 (and rewritten over the years),
  there was no upstream way to easily provide SLE customers with a way to build
  container images based on SLE using the host subscription. However, with
  docker-buildx you can now define secrets for builds (this is not entirely
  transparent, but we can easily document this new requirement for SLE-16).
  Users should use
    RUN --mount=type=secret,id=SCCcredentials zypper -n ...
  in their Dockerfiles, and
    docker buildx build --secret id=SCCcredentials,src=/etc/zypp/credentials.d/SCCcredentials,type=file .
  when doing their builds.
- Now that the only blocker for docker-buildx support was removed for SLE-16,
  enable docker-buildx for SLE-16 as well. PED-8905

Package dracut was updated:

- Update to version 059+suse.564.g984c275a:  * fix(rngd): adjust license to match the license of the whole project
  * fix(dracut): kernel module name normalization in drivers lists (bsc#1241680)

Package glib2 was updated:

- Add glib2-CVE-2025-6052.patch: fix overflow check when expanding  a GString (bsc#1244596 CVE-2025-6052).

- Add glib2-CVE-2025-4373.patch: carefully handle gssize parameters
  (bsc#1242844 CVE-2025-4373 glgo#GNOME/glib#3677).

Package glibc was updated:

- regcomp-double-free.patch: posix: Fix double-free after allocation  failure in regcomp (CVE-2025-8058, bsc#1246965, BZ #33185)

- nscd-gethst-race.patch: Reduce chance of crash when using nscd GETFDHST
  (bsc#1240058)

Package google-dracut-config was updated:

Package google-guest-configs was updated:

- Check that %{_sysconfdir}/sysconfig/network/ifcfg-eth0 actually  exists before making any modifications to it (bsc#1241112)

Package google-guest-oslogin was updated:

- Cherry-pick dont-retry-bad-requests.patch to stop retrying bad  requests causing timeouts during container startup (bsc#1243992)

- Override upstream version to address upgrade problems (bsc#1243997)

Package google-osconfig-agent was updated:

- Update to version 20250416.02 (bsc#1244304, bsc#1244503)  * defaultSleeper: tolerate 10% difference to reduce test flakiness (#810)
  * Add output of some packagemanagers to the testdata (#808)
- from version 20250416.01
  * Refactor OS Info package (#809)
- from version 20250416.00
  * Report RPM inventory as YUM instead of empty SoftwarePackage
    when neither Zypper nor YUM are installed. (#805)
- from version 20250414.00
  * Update hash computation algorithm (#799)

- Update to version 20250320.00
  * Bump github.com/envoyproxy/protoc-gen-validate from 1.1.0 to 1.2.1 (#797)
- from version 20250318.00
  * Bump go.opentelemetry.io/otel/sdk/metric from 1.32.0 to 1.35.0 (#793)
- from version 20250317.02
  * Bump cel.dev/expr from 0.18.0 to 0.22.0 (#792)
  * Bump github.com/golang/glog from 1.2.3 to 1.2.4 in the go_modules group (#785)
- from version 20250317.01
  * Bump cloud.google.com/go/logging from 1.12.0 to 1.13.0 (#774)
- from version 20250317.00
  * Add tests for retryutil package. (#795)
- from version 20250306.00
  * Update OWNERS (#794)
- from version 20250206.01
  * Use separate counters for pre- and post-patch reboots. (#788)
- from version 20250206.00
  * Update owners (#789)
- from version 20250203.00
  * Fix the vet errors for contants in logging (#786)
- from version 20250122.00
  * change available package check (#783)
- from version 20250121.00
  * Fix Inventory reporting e2e tests. (#782)
- from version 20250120.00
  * fix e2e tests (#781)
- Add -buildmode=pie to go build command line (bsc#1239948)
- Drop CVE-2024-45339.patch, merged upstream
- Renumber patches

Package gpg2 was updated:

- Security fix: [bsc#1236931, bsc#1239119, CVE-2025-30258]  * gpg: Fix regression for the recent malicious subkey DoS fix.
  * gpg: Fix another regression due to the T7547 fix.
  * gpg: Allow the use of an ADSK subkey as ADSK subkey.
  * Add patches:
  - gnupg-gpg-Fix-regression-for-the-recent-malicious-subkey-D.patch
  - gnupg-gpg-Fix-another-regression-due-to-the-T7547-fix.patch
  - gnupg-gpg-Allow-the-use-of-an-ADSK-subkey-as-ADSK-subkey.patch

- Don't install expired sks certificate [bsc#1243069]
  * Add patch gnupg-dirmngr-Don-t-install-expired-sks-certificate.patch

- Fix a verification DoS due to a malicious subkey in the keyring: [bsc#1239119]
  * Add patch gnupg-gpg-Fix-a-verification-DoS-due-to-a-malicious-subkey-in-the-keyring.patch

Package grub2 was updated:

- Skip mount point in grub_find_device function (bsc#1246231)  * 0001-getroot-Skip-mount-points-in-grub_find_device.patch

- Fix CVE-2024-56738: side-channel attack due to not constant-time
  algorithm in grub_crypto_memcmp (bsc#1234959)
  * grub2-constant-time-grub_crypto_memcmp.patch

- Fix test -f and -s do not work properly over the network files served via
  tftp and http (bsc#1246157) (bsc#1246237)
  * 0001-test-Fix-f-test-on-files-over-network.patch
  * 0002-http-Return-HTTP-status-code-in-http_establish.patch
  * 0003-docs-Clarify-test-for-files-on-TFTP-and-HTTP.patch
  * 0004-tftp-Fix-hang-when-file-is-a-directory.patch

Package hwinfo was updated:

- merge gh#openSUSE/hwinfo#168- fix usb network card detection (bsc#1245950)
- 21.89

Package iputils was updated:

- Security fix [bsc#1243772, CVE-2025-48964]  * Fix  integer overflow in ping statistics via zero timestamp
  * Add iputils-CVE-2025-48964_01.patch
  * Add iputils-CVE-2025-48964_02.patch
  * Add iputils-CVE-2025-48964_03.patch
  * Add iputils-CVE-2025-48964_04.patch
  * Add iputils-CVE-2025-48964_regression.patch

Package jq was updated:

- Add patches CVE-2025-48060-1.patch and CVE-2025-48060-2.patch  (CVE-2025-48060, bsc#1244116)

- Add patch CVE-2024-23337.patch (CVE-2024-23337, bsc#1243450)

Package kbd was updated:

- dummy update to trigger rebuild after having updated  console-setup (bsc#1246522); so this needs to be checked in and
  build after checking in console-setup !!!
- kbd-better-error-message-on-unsupported-unicode-value.patch
  * has been extremely useful for debugging that issue

Package kdump was updated:

- upgrade to version 2.0.18+git2.g881ca8c  * kdumptool calibrate: add per-cpu userspace requirements

- upgrade to version 2.0.18+git1.ga389ce7
  * set KDUMP_CPUs to 1 on XEN (bsc#1244289)

Package kernel-default was updated:

- ice, irdma: fix an off by one in error handling code  (bsc#1247712).
- irdma: free iwdev-&amp;gt;rf after removing MSI-X (bsc#1247712).
- ice: Fix signedness bug in ice_init_interrupt_scheme()
  (bsc#1247712).
- commit eba4226

- ice: init flow director before RDMA (bsc#1247712).
- ice: simplify VF MSI-X managing (bsc#1247712).
- ice: enable_rdma devlink param (bsc#1247712).
- ice: treat dyn_allowed only as suggestion (bsc#1247712).
- ice, irdma: move interrupts code to irdma (bsc#1247712).
- ice: get rid of num_lan_msix field (bsc#1247712).
- ice: remove splitting MSI-X between features (bsc#1247712).
- ice: devlink PF MSI-X max and min parameter (bsc#1247712).
- ice: count combined queues using Rx/Tx count (bsc#1247712).
- commit 0afdc75

- smb3: move server check earlier when setting channel sequence
  number (git-fixes).
- commit df2adca

- ring-buffer: Do not allow events in NMI with generic atomic64
  cmpxchg() (git-fixes).
- commit 890fc59

- module: Restore the moduleparam prefix length check (git-fixes).
- commit ad2fc48

- module: Remove unnecessary +1 from last_unloaded_module::name
  size (git-fixes).
- commit 3efc8ab

- audit,module: restore audit logging in load failure case
  (git-fixes).
- kABI: Fix the module::name type in audit_context (git-fixes).
- commit 7e23359

- module: Fix memory deallocation on error path in move_module()
  (git-fixes).
- commit bb37d39

- SMB3: rename macro CIFS_SERVER_IS_CHAN to avoid confusion
  (git-fixes).
- Refresh
  patches.suse/smb-client-fix-use-after-free-of-signing-key.patch.
- commit ee8ada8

- smb: client: fix potential deadlock when reconnecting channels
  (bsc#1246183, CVE-2025-38244).
- commit fcf601a

- cifs: reconnect helper should set reconnect for the right
  channel (git-fixes).
- commit ae3173e

- [SMB3] send channel sequence number in SMB3 requests after
  reconnects (git-fixes).
- commit baa81e9

- net: mana: Add debug logs in MANA network driver (bsc#1246212).
- Refresh
  patches.suse/msft-hv-3280-net-mana-Add-support-for-Multi-Vports-on-Bare-metal.patch.
- commit 1b4ad82

- netlink: avoid infinite retry looping in netlink_unicast()
  (CVE-2025-38465 bsc#1247118).
- net: mana: Set tx_packets to post gso processing packet count
  (bsc#1245731).
- net: mana: Allocate MSI-X vectors dynamically (bsc#1245457).
- net: mana: Allow irq_setup() to skip cpus for affinity
  (bsc#1245457).
- net: mana: explain irq_setup() algorithm (bsc#1245457).
- PCI: hv: Allow dynamic MSI-X vector allocation (bsc#1245457).
- PCI/MSI: Export pci_msix_prepare_desc() for dynamic MSI-X
  allocations (bsc#1245457).
- net: mana: Add handler for hardware servicing events
  (bsc#1245730).
- net: mana: Expose additional hardware counters for drop and
  TC via ethtool (bsc#1245729).
- hv_netvsc: Use VF's tso_max_size value when data path is VF
  (bsc#1246203).
- net: mana: Allow tso_max_size to go up-to GSO_MAX_SIZE
  (bsc#1246203).
- commit bdd7f41

- NFS: Fix wakeup of __nfs_lookup_revalidate() in
  unblock_revalidate() (git-fixes).
- commit 80e576f

- sched: Add test_and_clear_wake_up_bit() and
  atomic_dec_and_wake_up() (git-fixes).
- commit 3754627

- drm/amdgpu: Add basic validation for RAS header (bsc#1247252 CVE-2025-38426)
- commit 5d23e74

- NFS: Fix the setting of capabilities when automounting a new
  filesystem (git-fixes).
- commit fabe208

- sunrpc: fix client side handling of tls alerts (git-fixes).
- commit 4c093f3

- NFS: Fixup allocation flags for nfsiod's __GFP_NORETRY
  (git-fixes).
- commit fd58755

- NFSv4.2: another fix for listxattr (git-fixes).
- commit 5a2e576

- NFS: Fix filehandle bounds checking in nfs_fh_to_dentry()
  (git-fixes).
- commit 094541e

- pNFS/flexfiles: don't attempt pnfs on fatal DS errors
  (git-fixes).
- commit ec1d884

- gpio: mlxbf2: use platform_get_irq_optional() (git-fixes).
- ALSA: hda/ca0132: Fix missing error handling in
  ca0132_alt_select_out() (git-fixes).
- ALSA: intel_hdmi: Fix off-by-one error in
  __hdmi_lpe_audio_probe() (git-fixes).
- commit 1750f05

- kABI: io_uring: msg_ring ensure io_kiocb freeing is deferred
  (CVE-2025-38453 bsc#1247234).
- commit 0f853c5

- posix-cpu-timers: fix race between handle_posix_cpu_timers()
  and posix_cpu_timer_del() (bsc#1246911 CVE-2025-38352).
- commit ab7e2c1

- io_uring/msg_ring: ensure io_kiocb freeing is deferred for RCU
  (CVE-2025-38453 bsc#1247234).
- commit d411ddb

- tls: always refresh the queue when reading sock (CVE-2025-38471
  bsc#1247450).
- ext4: only dirty folios when data journaling regular files
  (CVE-2025-38220 bsc#1245966).
- commit 4468ab0

- virtio-pci: Check if is_avq is NULL (bsc#1247831 bsc#1228664
  CVE-2024-42134).
- commit fd0b149

- net/sched: mqprio: fix stack out-of-bounds write in tc entry
  parsing (git-fixes).
- commit 87e34c3

- net/packet: fix a race in packet_set_ring() and
  packet_notifier() (git-fixes).
- commit caa5d02

- net/sched: taprio: enforce minimum value for picos_per_byte
  (git-fixes).
- commit d33d37f

- ipv6: reject malicious packets in ipv6_gso_segment()
  (git-fixes).
- commit e120573

- netpoll: prevent hanging NAPI when netcons gets enabled
  (git-fixes).
- commit d8e3fe4

- tracing/kprobes: Fix to free objects when failed to copy a
  symbol (git-fixes).
- commit a2d3373

- tracing/kprobe: Make trace_kprobe's module callback called
  after jump_label update (git-fixes).
- commit 34ee7ea

- kABI fix for net: vlan: fix VLAN 0 refcount imbalance of
  toggling (CVE-2025-38470 bsc#1247288).
- commit 00f8e79

- net: vlan: fix VLAN 0 refcount imbalance of toggling filtering
  during runtime (CVE-2025-38470 bsc#1247288).
- net/sched: Abort __tc_modify_qdisc if parent class does not
  exist (CVE-2025-38457 bsc#1247098).
- atm: clip: Fix potential null-ptr-deref in to_atmarpd()
  (CVE-2025-38460 bsc#1247143).
- idpf: convert control queue mutex to a spinlock (CVE-2025-38392
  bsc#1247169).
- commit 4f53008

- drm/amd/display: Don't overwrite dce60_clk_mgr (git-fixes).
- Revert &amp;quot;vgacon: Add check for vc_origin address range in
  vgacon_scroll()&amp;quot; (stable-fixes).
- commit 6cc69eb

- exfat: fdatasync flag should be same like generic_write_sync()
  (git-fixes).
- commit ec3f01f

- do_change_type(): refuse to operate on unmounted/not ours mounts (CVE-2025-38498 bsc#1247374)
- commit 545afad

- vfio/mlx5: Fix an unwind issue in mlx5vf_add_migration_pages() (CVE-2024-56742 bsc#1235613)
- commit ff30550

- scsi: target: Fix NULL pointer dereference in
  core_scsi3_decode_spec_i_port() (CVE-2025-38399 bsc#1247097).
- commit e689eaa

- smc: Fix various oops due to inet_sock type confusion
  (CVE-2025-38475 bsc#1247308).
- commit a8e35aa

- RDMA/siw: Fix the sendmsg byte count in siw_tcp_sendpages (git-fixes)
- commit 39fb4df

- drm/v3d: Disable interrupts before resetting the GPU
  (CVE-2025-38371 bsc#1247178).
- commit 4160ac6

- io_uring/rsrc: fix folio unpinning (bsc#1246188 CVE-2025-38256).
- mm: release number of pages of a folio (CVE-2025-38256
  bsc#1246188).
- commit 3b7e190

- io_uring: fix potential page leak in io_sqe_buffer_register()
  (git-fixes).
- commit a038a0d

- btrfs: fix log tree replay failure due to file with 0 links
  and extents (git-fixes).
- commit fd0c9dd

- netlink: make sure we allow at least one dump skb
  (CVE-2025-38465 bsc#1247118).
- netlink: Fix rmem check in netlink_broadcast_deliver()
  (CVE-2025-38465 bsc#1247118).
- netlink: Fix wraparounds of sk-&amp;gt;sk_rmem_alloc (CVE-2025-38465
  bsc#1247118).
- commit b3ac9f0

- Enable SMC_LO (a.k.a SMC-D) (jsc#PED-13248).
- commit e35260b

- Refresh
  patches.kabi/xsk-Fix-race-condition-in-AF_XDP-generic-RX-path.patch.
  Drop the static_assert() kABI checks temporarily until we have a proper
  solution to signal kABI verification.
- commit d4817c8

- af_unix: Add a prompt to CONFIG_AF_UNIX_OOB (bsc#1246093).
- commit 9dcc611

- net: usbnet: Fix the wrong netif_carrier_on() call (git-fixes).
- commit 3ed80f8

- io_uring/timeout: fix multishot updates (bsc#1247021).
- commit 3631cdf

- kABI: restore layout of struct msi_desc (CVE-2025-38062
  bsc#1245216).
- genirq/msi: Store the IOMMU IOVA directly in msi_desc instead
  of iommu_cookie (CVE-2025-38062 bsc#1245216).
- commit 19502f4

- Delete
  patches.suse/af_unix-Disable-MSG_OOB-for-unprivileged-users.patch.
- commit e99b1bb

- Update config files. (CVE-2025-38236 bsc#1246093)
  Disable CONFIG_AF_UNIX_OOB as the implementation is ridden with security
  bugs whose fixes would be hard to backport and the feature has no known
  users.
- commit f8cd607

- Refresh patches.suse/x86-its-Enumerate-Indirect-Target-Selection-ITS-bug.patch.
- Refresh
  patches.suse/x86-its-Add-vmexit-option-to-skip-mitigation-on-some-CPUs.patch.
  Fix affected model steppings.
- commit 115d04b

- KVM: x86: Reset IRTE to host control if *new* route isn't
  postable (bsc#1242960 CVE-2025-37885).
- commit b463fcd

- enabled CONFIG_X86_INTEL_TSX_MODE_AUTO
  This is a response to bsc#1246695. As result of TAA vulnerability
  (CVE-2019-11135) we have aimed to follow the upstream default for TSX
  but due to a mistake we have ended up using CONFIG_X86_INTEL_TSX_MODE_ON
  rather than CONFIG_X86_INTEL_TSX_MODE_OFF. This has been noticed later
  on and fixed to align with upstream. Which has made some users unhappy
  because they have lost a default TSX functionality even on HW that is
  not susceptible to CVE-2019-11135.
  We have discussed different ways to deal with that but the likely most
  straightforward turned out to be to go with CONFIG_X86_INTEL_TSX_MODE_AUTO
  which disables TSX only on CVE-2019-11135 affected HW. We are still
  diverging from the upstream here but there are some positive indications
  that no new TSX based side channels have been discovered since.
- commit 395c9dd

- kABI fix after KVM: SVM: Fix SNP AP destroy race with VMRUN
  (git-fixes).
- commit 8a8d140

- KVM: SVM: Fix SNP AP destroy race with VMRUN (git-fixes).
- commit a050518

- tcp: call tcp_measure_rcv_mss() for ooo packets (git-fixes).
- commit 54261d2

- net/sched: sch_qfq: Avoid triggering might_sleep in atomic
  context in qfq_delete_class (git-fixes).
- commit cdfb027

- Refresh
  patches.suse/af_unix-Disable-MSG_OOB-for-unprivileged-users.patch.
  Print message upon disabled use.
- commit 31d5690

- Refresh
  patches.suse/virtio-blk-scsi-use-block-layer-helpers-to-calculate.patch.
- commit 773f5a0

- Rename to
  patches.suse/scsi-use-block-layer-helpers-to-calculate-num-of-que.patch.
- commit dd839b8

- Refresh
  patches.suse/nvme-pci-use-block-layer-helpers-to-calculate-num-of.patch.
- commit e114e47

- Refresh
  patches.suse/blk-mq-add-number-of-queue-calc-helper.patch.
- commit db4fa45

- Rename to
  patches.suse/lib-group_cpus-Let-group_cpu_evenly-return-the-numbe.patch.
  Refresh:
  - patches.kabi/kabi-fix-group-cpus-evenly.patch
  - patches.suse/lib-group_cpus-honor-housekeeping-config-when-grouping.patch
- commit ca07a82

- btrfs: tests: fix chunk map leak after failure to add it to
  the tree (git-fixes).
- commit 4c3fd9d

- lib/group_cpus: fix NULL pointer dereference from
  group_cpus_evenly() (bsc#1236897).
- lib/group_cpus.c: avoid acquiring cpu hotplug lock in
  group_cpus_evenly (bsc#1236897).
- commit 749ceff

- btrfs: fix ssd_spread overallocation (git-fixes).
- commit 760f402

- btrfs: use btrfs_record_snapshot_destroy() during rmdir
  (git-fixes).
- commit 05219d1

- btrfs: propagate last_unlink_trans earlier when doing a rmdir
  (git-fixes).
- btrfs: rename err to ret in btrfs_rmdir() (git-fixes).
- commit 6fea6c3

- btrfs: don't skip remaining extrefs if dir not found during
  log replay (git-fixes).
- commit ae66e11

- btrfs: don't ignore inode missing when replaying log tree
  (git-fixes).
- commit 87671c8

- btrfs: fix inode lookup error handling during log replay
  (git-fixes).
- commit a89d2a6

- nvmet-tcp: fix callback lock for TLS handshake (git-fixes).
- nvme: fix misaccounting of nvme-mpath inflight I/O (git-fixes).
- nvme: fix endianness of command word prints in
  nvme_log_err_passthru() (git-fixes).
- nvme: fix inconsistent RCU list manipulation in
  nvme_ns_add_to_ctrl_list() (git-fixes).
- commit bbf2481

- RDMA/core: Rate limit GID cache warning messages (git-fixes)
- commit fd0e41a

- kernel-syms.spec: Drop old rpm release number hack (bsc#1247172).
- commit b4fa2d1

- rtc: rv3028: fix incorrect maximum clock rate handling
  (git-fixes).
- rtc: pcf8563: fix incorrect maximum clock rate handling
  (git-fixes).
- rtc: pcf85063: fix incorrect maximum clock rate handling
  (git-fixes).
- rtc: nct3018y: fix incorrect maximum clock rate handling
  (git-fixes).
- rtc: hym8563: fix incorrect maximum clock rate handling
  (git-fixes).
- rtc: ds1307: fix incorrect maximum clock rate handling
  (git-fixes).
- ucount: fix atomic_long_inc_below() argument type (git-fixes).
- i3c: fix module_i3c_i2c_driver() with I3C=n (git-fixes).
- commit e466472

- pinmux: fix race causing mux_owner NULL with active mux_usecount
  (git-fixes).
- pinctrl: sunxi: Fix memory leak on krealloc failure (git-fixes).
- fbdev: imxfb: Check fb_add_videomode to prevent null-ptr-deref
  (git-fixes).
- firewire: ohci: correct code comments about bus_reset tasklet
  (git-fixes).
- commit fd1a6ae

- drm/amd/display: fix initial backlight brightness calculation
  (git-fixes).
- commit 9a59f80

- ALSA: scarlett2: Add retry on -EPROTO from scarlett2_usb_tx()
  (git-fixes).
- drm/xe/vf: Disable CSC support on VF (git-fixes).
- drm/amdgpu: Initialize data to NULL in
  imu_v12_0_program_rlc_ram() (git-fixes).
- staging: vchiq_arm: Make vchiq_shutdown never fail (git-fixes).
- regulator: core: fix NULL dereference on unbind due to stale
  coupling data (stable-fixes).
- commit 9ec53f4

- PCI: rockchip-host: Fix &amp;quot;Unexpected Completion&amp;quot; log message
  (git-fixes).
- PCI: endpoint: pci-epf-vntb: Fix the incorrect usage of __iomem
  attribute (git-fixes).
- PCI: endpoint: pci-epf-vntb: Return -ENOENT if
  pci_epc_get_next_free_bar() fails (git-fixes).
- PCI: endpoint: Fix configfs group removal on driver teardown
  (git-fixes).
- PCI: endpoint: Fix configfs group list head handling
  (git-fixes).
- watchdog: ziirave_wdt: check record length in
  ziirave_firm_verify() (git-fixes).
- dmaengine: nbpfaxi: Add missing check after DMA map (git-fixes).
- dmaengine: mv_xor: Fix missing check after DMA map and missing
  unmap (git-fixes).
- dmaengine: qcom: gpi: Drop unused gpi_write_reg_field()
  (git-fixes).
- dmaengine: dw-edma: Drop unused dchan2dev() and chan2dev()
  (git-fixes).
- ASoC: fsl_xcvr: get channel status data when PHY is not exists
  (git-fixes).
- soundwire: stream: restore params when prepare ports fail
  (git-fixes).
- power: supply: max14577: Handle NULL pdata when CONFIG_OF is
  not set (git-fixes).
- power: supply: cpcap-charger: Fix null check for
  power_supply_get_by_name (git-fixes).
- ALSA: hda/realtek - Add mute LED support for HP Pavilion
  15-eg0xxx (stable-fixes).
- can: netlink: can_changelink(): fix NULL pointer deref of
  struct can_priv::do_set_mode (git-fixes).
- ALSA: hda: Add missing NVIDIA HDA codec IDs (stable-fixes).
- usb: typec: tcpm: apply vbus before data bringup in
  tcpm_src_attach (git-fixes).
- usb: typec: tcpm: allow switching to mode accessory to mux
  properly (stable-fixes).
- usb: typec: tcpm: allow to use sink in accessory mode
  (stable-fixes).
- ALSA: hda/tegra: Add Tegra264 support (stable-fixes).
- can: dev: can_restart(): move debug message and stats after
  successful restart (stable-fixes).
- can: dev: can_restart(): reverse logic to remove need for goto
  (stable-fixes).
- commit 0f0c0d9

- btrfs: don't silently ignore unexpected extent type when
  replaying log (git-fixes).
- commit e423498

- btrfs: fix invalid inode pointer dereferences during log replay
  (git-fixes).
- commit 78cbba9

- btrfs: return a btrfs_inode from read_one_inode() (git-fixes).
- commit b3a9472

- iommu/arm-smmu-qcom: Add SM6115 MDSS compatible (git-fixes).
- iommu/amd: Fix geometry.aperture_end for V2 tables (git-fixes).
- commit f8c05a9

- btrfs: return a btrfs_inode from btrfs_iget_logging()
  (git-fixes).
- commit 88ed97b

- btrfs: use NOFS context when getting inodes during logging
  and log replay (git-fixes).
- commit 88eb1d5

- virtio-net: ensure the received length does not exceed allocated
  size (CVE-2025-38375 bsc#1247177).
- commit 2adf745

- btrfs: update superblock's device bytes_used when dropping chunk
  (git-fixes).
- commit e33076b

- Update
  patches.suse/0001-mm-hugetlb-fix-huge_pmd_unshare-vs-GUP-fast-race.patch
  (bsc#1245431 CVE-2025-38085 bsc#1245499).
- Update
  patches.suse/0001-mm-hugetlb-unshare-page-tables-during-VMA-split-not-.patch
  (bsc#1245431 CVE-2025-38084 bsc#1245498).
- Update
  patches.suse/ACPI-CPPC-Fix-NULL-pointer-dereference-when-nosmp-is.patch
  (git-fixes CVE-2025-38113 bsc#1245683).
- Update
  patches.suse/ACPICA-Refuse-to-evaluate-a-method-if-arguments-are-.patch
  (stable-fixes CVE-2025-38386 bsc#1247138).
- Update
  patches.suse/ACPICA-fix-acpi-operand-cache-leak-in-dswstate.c.patch
  (stable-fixes CVE-2025-38345 bsc#1246337).
- Update
  patches.suse/ACPICA-fix-acpi-parse-and-parseext-cache-leaks.patch
  (stable-fixes CVE-2025-38344 bsc#1246334).
- Update
  patches.suse/ALSA-usb-audio-Fix-out-of-bounds-read-in-snd_usb_get.patch
  (git-fixes CVE-2025-38249 bsc#1246171).
- Update
  patches.suse/ASoC-Intel-avs-Verify-content-returned-by-parse_int_.patch
  (git-fixes CVE-2025-38307 bsc#1246364).
- Update
  patches.suse/ASoC-codecs-wcd9335-Fix-missing-free-of-regulator-su.patch
  (git-fixes CVE-2025-38259 bsc#1246220).
- Update
  patches.suse/Bluetooth-Fix-NULL-pointer-deference-on-eir_get_serv.patch
  (git-fixes CVE-2025-38304 bsc#1246240).
- Update
  patches.suse/Bluetooth-Fix-null-ptr-deref-in-l2cap_sock_resume_cb.patch
  (git-fixes CVE-2025-38473 bsc#1247289).
- Update
  patches.suse/Bluetooth-MGMT-Fix-UAF-on-mgmt_remove_adv_monitor_co.patch
  (git-fixes CVE-2025-38118 bsc#1245670).
- Update
  patches.suse/HID-core-do-not-bypass-hid_hw_raw_request.patch
  (stable-fixes CVE-2025-38494 bsc#1247349).
- Update
  patches.suse/HID-core-ensure-the-allocated-report-buffer-can-cont.patch
  (stable-fixes CVE-2025-38495 bsc#1247348).
- Update
  patches.suse/IB-mlx5-Fix-potential-deadlock-in-MR-deregistration.patch
  (git-fixes CVE-2025-38373 bsc#1247033).
- Update
  patches.suse/Input-ims-pcu-check-record-size-in-ims_pcu_flash_fir.patch
  (git-fixes CVE-2025-38428 bsc#1247150).
- Update
  patches.suse/NFC-nci-uart-Set-tty-disc_data-only-in-success-path.patch
  (git-fixes CVE-2025-38416 bsc#1247151).
- Update
  patches.suse/NFSv4-pNFS-Fix-a-race-to-wake-on-NFS_LAYOUT_DRAIN.patch
  (git-fixes CVE-2025-38393 bsc#1247170).
- Update
  patches.suse/RDMA-cma-Fix-hang-when-cma_netevent_callback-fails-t.patch
  (git-fixes CVE-2025-38151 bsc#1245745).
- Update
  patches.suse/RDMA-iwcm-Fix-use-after-free-of-work-objects-after-c.patch
  (git-fixes CVE-2025-38211 bsc#1246008).
- Update
  patches.suse/RDMA-mlx5-Fix-error-flow-upon-firmware-failure-for-R.patch
  (git-fixes CVE-2025-38161 bsc#1245777).
- Update
  patches.suse/RDMA-mlx5-Initialize-obj_event-obj_sub_list-before-x.patch
  (git-fixes CVE-2025-38387 bsc#1247154).
- Update
  patches.suse/Squashfs-check-return-result-of-sb_min_blocksize.patch
  (git-fixes CVE-2025-38415 bsc#1247147).
- Update
  patches.suse/VMCI-fix-race-between-vmci_host_setup_notify-and-vmc.patch
  (git-fixes CVE-2025-38102 bsc#1245669).
- Update
  patches.suse/aoe-clean-device-rq_list-in-aoedev_downdev.patch
  (git-fixes CVE-2025-38326 bsc#1246490).
- Update
  patches.suse/ata-pata_via-Force-PIO-for-ATAPI-devices-on-VT6415-V.patch
  (stable-fixes CVE-2025-38336 bsc#1246370).
- Update
  patches.suse/backlight-pm8941-Add-NULL-check-in-wled_configure.patch
  (git-fixes CVE-2025-38143 bsc#1245714).
- Update patches.suse/bnxt-properly-flush-XDP-redirect-lists.patch
  (git-fixes CVE-2025-38246 bsc#1246195).
- Update
  patches.suse/bpf-sockmap-Fix-panic-when-calling-skb_linearize.patch
  (bsc#1245749 CVE-2025-38154 CVE-2025-38165 bsc#1245757).
- Update patches.suse/bus-fsl-mc-fix-double-free-on-mc_dev.patch
  (git-fixes CVE-2025-38313 bsc#1246342).
- Update
  patches.suse/calipso-Fix-null-ptr-deref-in-calipso_req_-set-del-a.patch
  (git-fixes CVE-2025-38181 bsc#1246000).
- Update
  patches.suse/comedi-Fail-COMEDI_INSNLIST-ioctl-if-n_insns-is-too-.patch
  (git-fixes CVE-2025-38481 bsc#1247276).
- Update
  patches.suse/comedi-Fix-initialization-of-data-for-instructions-t.patch
  (git-fixes CVE-2025-38478 bsc#1247273).
- Update
  patches.suse/comedi-Fix-use-of-uninitialized-data-in-insn_rw_emul.patch
  (git-fixes CVE-2025-38480 bsc#1247274).
- Update
  patches.suse/comedi-das16m1-Fix-bit-shift-out-of-bounds.patch
  (git-fixes CVE-2025-38483 bsc#1247278).
- Update
  patches.suse/comedi-das6402-Fix-bit-shift-out-of-bounds.patch
  (git-fixes CVE-2025-38482 bsc#1247277).
- Update
  patches.suse/crypto-marvell-cesa-Handle-zero-length-skcipher-requ.patch
  (git-fixes CVE-2025-38173 bsc#1245769).
- Update
  patches.suse/crypto-sun8i-ce-cipher-fix-error-handling-in-sun8i_c.patch
  (git-fixes CVE-2025-38300 bsc#1246349).
- Update patches.suse/dm-bufio-fix-sched-in-atomic-context.patch
  (git-fixes CVE-2025-38496 bsc#1247284).
- Update
  patches.suse/dma-buf-insert-memory-barrier-before-updating-num_fe.patch
  (git-fixes CVE-2025-38095 bsc#1245658).
- Update
  patches.suse/dmaengine-idxd-Check-availability-of-workqueue-alloc.patch
  (stable-fixes CVE-2025-38369 bsc#1247209).
- Update
  patches.suse/dmaengine-ti-Add-NULL-check-in-udma_probe.patch
  (git-fixes CVE-2025-38138 bsc#1245719).
- Update
  patches.suse/drivers-rapidio-rio_cm.c-prevent-possible-heap-overw.patch
  (stable-fixes CVE-2025-38090 bsc#1245510).
- Update
  patches.suse/drm-amd-display-Add-null-pointer-check-for-get_first.patch
  (git-fixes CVE-2025-38362 bsc#1247089).
- Update
  patches.suse/drm-amd-pp-Fix-potential-NULL-pointer-dereference-in.patch
  (git-fixes CVE-2025-38319 bsc#1246243).
- Update
  patches.suse/drm-exynos-exynos7_drm_decon-add-vblank-check-in-IRQ.patch
  (git-fixes CVE-2025-38467 bsc#1247146).
- Update
  patches.suse/drm-gem-Acquire-references-on-GEM-handles-for-frameb.patch
  (stable-fixes CVE-2025-38449 bsc#1247255).
- Update
  patches.suse/drm-i915-gt-Fix-timeline-left-held-on-VMA-alloc-erro.patch
  (git-fixes CVE-2025-38389 bsc#1247153).
- Update
  patches.suse/drm-msm-Fix-a-fence-leak-in-submit-error-path.patch
  (stable-fixes CVE-2025-38410 bsc#1247128).
- Update
  patches.suse/drm-msm-Fix-another-leak-in-the-submit-error-path.patch
  (stable-fixes CVE-2025-38409 bsc#1247285).
- Update
  patches.suse/drm-msm-gpu-Fix-crash-when-throttling-GPU-immediatel.patch
  (git-fixes CVE-2025-38354 bsc#1247061).
- Update
  patches.suse/drm-scheduler-signal-scheduled-fence-when-kill-job.patch
  (stable-fixes CVE-2025-38436 bsc#1247227).
- Update
  patches.suse/drm-tegra-Fix-a-possible-null-pointer-dereference.patch
  (git-fixes CVE-2025-38363 bsc#1247018).
- Update
  patches.suse/fbcon-Make-sure-modelist-not-set-on-unregistered-con.patch
  (stable-fixes CVE-2025-38198 bsc#1245952).
- Update
  patches.suse/fbdev-Fix-do_register_framebuffer-to-prevent-null-pt.patch
  (git-fixes CVE-2025-38215 bsc#1246109).
- Update
  patches.suse/fbdev-Fix-fb_set_var-to-prevent-null-ptr-deref-in-fb.patch
  (git-fixes CVE-2025-38214 bsc#1246042).
- Update
  patches.suse/fbdev-core-fbcvt-avoid-division-by-0-in-fb_cvt_hperi.patch
  (git-fixes CVE-2025-38312 bsc#1246386).
- Update
  patches.suse/fs-nfs-read-fix-double-unlock-bug-in-nfs_return_empty_folio.patch
  (git-fixes CVE-2025-38338 bsc#1246258).
- Update
  patches.suse/gve-add-missing-NULL-check-for-gve_alloc_pending_pac.patch
  (git-fixes CVE-2025-38122 bsc#1245746).
- Update
  patches.suse/hwmon-asus-ec-sensors-check-sensor-index-in-read_str.patch
  (git-fixes CVE-2025-38142 bsc#1245713).
- Update
  patches.suse/hwmon-ftsteutates-Fix-TOCTOU-race-in-fts_read.patch
  (git-fixes CVE-2025-38217 bsc#1246002).
- Update
  patches.suse/i2c-designware-Fix-an-initialization-issue.patch
  (git-fixes CVE-2025-38380 bsc#1247028).
- Update
  patches.suse/i2c-tegra-check-msg-length-in-SMBUS-block-read.patch
  (bsc#1242086 CVE-2025-38425 bsc#1247251).
- Update
  patches.suse/ice-fix-Tx-scheduler-error-handling-in-XDP-callback.patch
  (git-fixes CVE-2025-38127 bsc#1245705).
- Update
  patches.suse/iio-accel-fxls8962af-Fix-use-after-free-in-fxls8962a.patch
  (git-fixes CVE-2025-38485 bsc#1247236).
- Update
  patches.suse/jffs2-check-jffs2_prealloc_raw_node_refs-result-in-few-other-places.patch
  (git-fixes CVE-2025-38328 bsc#1246249).
- Update
  patches.suse/jffs2-check-that-raw-node-were-preallocated-before-writing-summary.patch
  (git-fixes CVE-2025-38194 bsc#1245957).
- Update
  patches.suse/media-cxusb-no-longer-judge-rbuf-when-the-write-fail.patch
  (git-fixes CVE-2025-38229 bsc#1246049).
- Update
  patches.suse/media-imx-jpeg-Cleanup-after-an-allocation-error.patch
  (git-fixes CVE-2025-38225 bsc#1246041).
- Update
  patches.suse/media-vidtv-Terminating-the-subsequent-process-of-in.patch
  (git-fixes CVE-2025-38227 bsc#1246031).
- Update
  patches.suse/media-vivid-Change-the-siize-of-the-composing.patch
  (git-fixes CVE-2025-38226 bsc#1246050).
- Update
  patches.suse/mtd-nand-ecc-mxic-Fix-use-of-uninitialized-variable-.patch
  (git-fixes CVE-2025-38277 bsc#1246246).
- Update
  patches.suse/mtd-spinand-fix-memory-leak-of-ECC-engine-conf.patch
  (stable-fixes CVE-2025-38384 bsc#1247035).
- Update
  patches.suse/mtk-sd-Prevent-memory-corruption-from-DMA-map-failur.patch
  (git-fixes CVE-2025-38401 bsc#1247125).
- Update
  patches.suse/nbd-fix-uaf-in-nbd_genl_connect-error-path.patch
  (git-fixes CVE-2025-38443 bsc#1247164).
- Update patches.suse/net-Fix-TOCTOU-issue-in-sk_is_readable.patch
  (git-fixes CVE-2025-38112 bsc#1245668).
- Update
  patches.suse/net-fix-udp-gso-skb_segment-after-pull-from-frag_lis.patch
  (git-fixes CVE-2025-38124 bsc#1245690).
- Update
  patches.suse/net-mdiobus-Fix-potential-out-of-bounds-clause-45-re.patch
  (git-fixes CVE-2025-38110 bsc#1245665).
- Update
  patches.suse/net-mdiobus-Fix-potential-out-of-bounds-read-write-a.patch
  (git-fixes CVE-2025-38111 bsc#1245666).
- Update
  patches.suse/net-mlx5-Fix-ECVF-vports-unload-on-shutdown-flow.patch
  (git-fixes CVE-2025-38109 bsc#1245684).
- Update
  patches.suse/net-phy-clear-phydev-devlink-when-the-link-is-delete.patch
  (git-fixes CVE-2025-38149 bsc#1245737).
- Update
  patches.suse/net-phy-mscc-Fix-memory-leak-when-using-one-step-tim.patch
  (git-fixes CVE-2025-38148 bsc#1245735).
- Update
  patches.suse/net-sched-Return-NULL-when-htb_lookup_leaf-encounter.patch
  (git-fixes CVE-2025-38468 bsc#1247437).
- Update
  patches.suse/net-sched-fix-use-after-free-in-taprio_dev_notifier.patch
  (git-fixes CVE-2025-38087 bsc#1245504).
- Update
  patches.suse/net-sched-sch_qfq-Fix-race-condition-on-qfq_aggregat.patch
  (git-fixes CVE-2025-38477 bsc#1247314).
- Update
  patches.suse/net-tipc-fix-refcount-warning-in-tipc_aead_encrypt.patch
  (CVE-2025-38052 bsc#1244749 CVE-2025-38273 bsc#1246266).
- Update
  patches.suse/net-usb-aqc111-fix-error-handling-of-usbnet-read-cal.patch
  (git-fixes CVE-2025-38153 bsc#1245744).
- Update
  patches.suse/net-usb-lan78xx-fix-WARN-in-__netif_napi_del_locked-.patch
  (git-fixes CVE-2025-38385 bsc#1247149).
- Update patches.suse/net-wwan-t7xx-Fix-napi-rx-poll-issue.patch
  (git-fixes CVE-2025-38123 bsc#1245688).
- Update
  patches.suse/net_sched-ets-fix-a-race-in-ets_qdisc_change.patch
  (git-fixes CVE-2025-38107 bsc#1245676).
- Update
  patches.suse/net_sched-red-fix-a-race-in-__red_change.patch
  (git-fixes CVE-2025-38108 bsc#1245675).
- Update
  patches.suse/net_sched-sch_sfq-reject-invalid-perturb-period.patch
  (git-fixes CVE-2025-38193 bsc#1245945).
- Update
  patches.suse/netfilter-nf_set_pipapo_avx2-fix-initial-map-fill.patch
  (git-fixes CVE-2024-57947 bsc#1236333 CVE-2025-38120
  bsc#1245711).
- Update
  patches.suse/nfs-Clean-up-proc-net-rpc-nfs-when-nfs_fs_proc_net_init-fails.patch
  (git-fixes CVE-2025-38400 bsc#1247123).
- Update
  patches.suse/nfsd-Initialize-ssc-before-laundromat_work-to-prevent-NULL-dereference.patch
  (git-fixes CVE-2025-38231 bsc#1246055).
- Update
  patches.suse/nfsd-nfsd4_spo_must_allow-must-check-this-is-a-v4-compound-request.patch
  (git-fixes CVE-2025-38430 bsc#1247160).
- Update
  patches.suse/page_pool-Fix-use-after-free-in-page_pool_recycle_in.patch
  (git-fixes CVE-2025-38129 bsc#1245723).
- Update patches.suse/perf-Fix-sample-vs-do_exit.patch
  (bsc#1246547 CVE-2025-38424 bsc#1247293).
- Update
  patches.suse/phy-qcom-qmp-usb-Fix-an-NULL-vs-IS_ERR-bug.patch
  (git-fixes CVE-2025-38275 bsc#1246236).
- Update
  patches.suse/pinctrl-at91-Fix-possible-out-of-boundary-access.patch
  (git-fixes CVE-2025-38286 bsc#1246283).
- Update
  patches.suse/platform-x86-dell-wmi-sysman-Fix-WMI-data-block-retr.patch
  (git-fixes CVE-2025-38412 bsc#1247132).
- Update patches.suse/platform-x86-dell_rbu-Fix-list-usage.patch
  (git-fixes CVE-2025-38197 bsc#1246047).
- Update
  patches.suse/powerpc-powernv-memtrace-Fix-out-of-bounds-issue-in-.patch
  (bsc#1244309 ltc#213790 CVE-2025-38088 bsc#1245506).
- Update
  patches.suse/ptp-remove-ptp-n_vclocks-check-logic-in-ptp_vclock_i.patch
  (git-fixes CVE-2025-38305 bsc#1246358).
- Update
  patches.suse/regulator-gpio-Fix-the-out-of-bounds-access-to-drvda.patch
  (git-fixes CVE-2025-38395 bsc#1247171).
- Update
  patches.suse/rose-fix-dangling-neighbour-pointers-in-rose_rt_devi.patch
  (git-fixes CVE-2025-38377 bsc#1247174).
- Update
  patches.suse/rpl-Fix-use-after-free-in-rpl_do_srh_inline.patch
  (git-fixes CVE-2025-38476 bsc#1247317).
- Update
  patches.suse/s390-bpf-Fix-bpf_arch_text_poke-with-new_addr-NULL-again.patch
  (git-fixes bsc#1246870 CVE-2025-38489 bsc#1247241).
- Update
  patches.suse/s390-pkey-Prevent-overflow-in-size-calculation-for-memdup_.patch
  (git-fixes bsc#1245598 CVE-2025-38257 bsc#1246186).
- Update
  patches.suse/sch_hfsc-make-hfsc_qlen_notify-idempotent.patch
  (CVE-2025-37798 bsc#1242414 CVE-2025-38177 bsc#1245986).
- Update
  patches.suse/scsi-lpfc-Avoid-potential-ndlp-use-after-free-in-dev.patch
  (bsc#1242993 CVE-2025-38289 bsc#1246287).
- Update patches.suse/scsi-lpfc-Use-memcpy-for-BIOS-version.patch
  (bsc#1240966 CVE-2025-38332 bsc#1246375).
- Update
  patches.suse/serial-Fix-potential-null-ptr-deref-in-mlb_usio_prob.patch
  (git-fixes CVE-2025-38135 bsc#1246023).
- Update
  patches.suse/soc-aspeed-Add-NULL-check-in-aspeed_lpc_enable_snoop.patch
  (git-fixes CVE-2025-38145 bsc#1245765).
- Update
  patches.suse/soc-aspeed-lpc-snoop-Don-t-disable-channels-that-are.patch
  (git-fixes CVE-2025-38487 bsc#1247238).
- Update
  patches.suse/software-node-Correct-a-OOB-check-in-software_node_g.patch
  (stable-fixes CVE-2025-38342 bsc#1246453).
- Update
  patches.suse/sunrpc-handle-SVC_GARBAGE-during-svc-auth-processing-as-auth-error.patch
  (git-fixes CVE-2025-38089 bsc#1245508).
- Update
  patches.suse/thunderbolt-Do-not-double-dequeue-a-configuration-re.patch
  (stable-fixes CVE-2025-38174 bsc#1245781).
- Update
  patches.suse/usb-chipidea-udc-disconnect-reconnect-from-host-when.patch
  (git-fixes CVE-2025-38376 bsc#1247176).
- Update
  patches.suse/usb-gadget-u_serial-Fix-race-condition-in-TTY-wakeup.patch
  (git-fixes CVE-2025-38448 bsc#1247233).
- Update
  patches.suse/usb-net-sierra-check-for-no-status-endpoint.patch
  (git-fixes CVE-2025-38474 bsc#1247311).
- Update
  patches.suse/usb-renesas_usbhs-Reorder-clock-handling-and-power-m.patch
  (git-fixes CVE-2025-38136 bsc#1245691).
- Update
  patches.suse/usb-typec-altmodes-displayport-do-not-index-invalid-.patch
  (git-fixes CVE-2025-38391 bsc#1247181).
- Update
  patches.suse/usb-typec-displayport-Fix-potential-deadlock.patch
  (git-fixes CVE-2025-38404 bsc#1247271).
- Update
  patches.suse/vgacon-Add-check-for-vc_origin-address-range-in-vgac.patch
  (git-fixes CVE-2025-38213 bsc#1246037).
- Update
  patches.suse/wifi-ath11k-fix-node-corruption-in-ar-arvifs-list.patch
  (git-fixes CVE-2025-38293 bsc#1246292).
- Update
  patches.suse/wifi-ath12k-fix-invalid-access-to-memory.patch
  (git-fixes CVE-2025-38292 bsc#1246295).
- Update
  patches.suse/wifi-ath12k-fix-node-corruption-in-ar-arvifs-list.patch
  (git-fixes CVE-2025-38290 bsc#1246293).
- Update
  patches.suse/wifi-ath6kl-remove-WARN-on-bad-firmware-input.patch
  (stable-fixes CVE-2025-38406 bsc#1247210).
- Update
  patches.suse/wifi-ath9k_htc-Abort-software-beacon-handling-if-dis.patch
  (git-fixes CVE-2025-38157 bsc#1245747).
- Update
  patches.suse/wifi-carl9170-do-not-ping-device-which-has-failed-to.patch
  (git-fixes CVE-2025-38420 bsc#1247279).
- Update
  patches.suse/wifi-mt76-mt7915-Fix-null-ptr-deref-in-mt7915_mmio_w.patch
  (git-fixes CVE-2025-38155 bsc#1245748).
- Update
  patches.suse/wifi-mt76-mt7996-drop-fragments-with-multicast-or-br.patch
  (stable-fixes CVE-2025-38343 bsc#1246438).
- Update
  patches.suse/wifi-p54-prevent-buffer-overflow-in-p54_rx_eeprom_re.patch
  (git-fixes CVE-2025-38348 bsc#1246262).
- Update
  patches.suse/wifi-rtw88-fix-the-para-buffer-size-to-avoid-reading.patch
  (git-fixes CVE-2025-38159 bsc#1245751).
- commit de345c9

- Revert &amp;quot;cgroup_freezer: cgroup_freezing: Check if not frozen&amp;quot;
  (bsc#1219338).
- sched,freezer: Remove unnecessary warning in __thaw_task
  (bsc#1219338).
- commit 108588a

- Update
  patches.suse/ASoC-mediatek-mt8195-Set-ETDM1-2-IN-OUT-to-COMP_DUMM.patch
  (git-fixes CVE-2025-38299 bsc#1246290).
- Update
  patches.suse/Bluetooth-btintel-Check-dsbr-size-from-EFI-variable.patch
  (git-fixes CVE-2025-38315 bsc#1246333).
- Update
  patches.suse/IB-cm-Drop-lockdep-assert-and-WARN-when-freeing-old-.patch
  (git-fixes CVE-2025-38287 bsc#1246285).
- Update
  patches.suse/bnxt_en-Fix-double-invocation-of-bnxt_ulp_stop-bnxt_.patch
  (git-fixes CVE-2025-38186 bsc#1245955).
- Update
  patches.suse/drm-amd-display-Check-dce_hwseq-before-dereferencing.patch
  (stable-fixes CVE-2025-38361 bsc#1247079).
- Update
  patches.suse/drm-amd-display-check-stream-id-dml21-wrapper-to-get.patch
  (stable-fixes CVE-2025-38091 bsc#1245621).
- Update
  patches.suse/drm-v3d-Avoid-NULL-pointer-dereference-in-v3d_job_up.patch
  (stable-fixes CVE-2025-38189 bsc#1245812).
- Update
  patches.suse/drm-v3d-Disable-interrupts-before-resetting-the-GPU.patch
  (git-fixes CVE-2025-38371 bsc#1247178).
- Update
  patches.suse/drm-xe-Fix-taking-invalid-lock-on-wedge.patch
  (stable-fixes CVE-2025-38353 bsc#1247265).
- Update
  patches.suse/drm-xe-Process-deferred-GGTT-node-removals-on-device.patch
  (git-fixes CVE-2025-38355 bsc#1247062).
- Update
  patches.suse/drm-xe-guc-Explicitly-exit-CT-safe-mode-on-unwind.patch
  (git-fixes CVE-2025-38356 bsc#1247064).
- Update
  patches.suse/e1000-Move-cancel_work_sync-to-avoid-deadlock.patch
  (git-fixes CVE-2025-38114 bsc#1245686).
- Update
  patches.suse/ice-fix-eswitch-code-memory-leak-in-reset-scenario.patch
  (git-fixes CVE-2025-38417 bsc#1247282).
- Update
  patches.suse/scsi-fnic-Fix-crash-in-fnic_wq_cmpl_handler-when-FDMI-time.patch
  (git-fixes CVE-2025-38238 bsc#1246179).
- Update
  patches.suse/scsi-smartpqi-Fix-smp_processor_id-call-trace-for-preempti.patch
  (git-fixes CVE-2025-38288 bsc#1246286).
- Update
  patches.suse/serial-jsm-fix-NPE-during-jsm_uart_port_init.patch
  (git-fixes CVE-2025-38265 bsc#1246244).
- Update
  patches.suse/usb-typec-tcpm-move-tcpm_queue_vdm_unlocked-to-async.patch
  (git-fixes CVE-2025-38268 bsc#1246385).
- Update
  patches.suse/video-screen_info-Update-framebuffers-behind-PCI-bri.patch
  (bsc#1240696 CVE-2025-38427 bsc#1247152).
- Update
  patches.suse/wifi-ath12k-Fix-buffer-overflow-in-debugfs.patch
  (bsc#1240998 CVE-2025-38317 bsc#1246443).
- Update
  patches.suse/wifi-ath12k-Prevent-sending-WMI-commands-to-firmware.patch
  (bsc#1240998 CVE-2025-38291 bsc#1246297).
- commit 7a0cbb6

- ipv6: fix possible infinite loop in fib6_info_uses_dev()
  (git-fixes).
- commit 16f1f6e

- ipv6: prevent infinite loop in rt6_nlmsg_size() (git-fixes).
- commit cb535e8

- net/sched: Restrict conditions for adding duplicating netems
  to qdisc tree (git-fixes).
- commit 6fae648

- Refresh
  patches.suse/af_unix-Disable-MSG_OOB-for-unprivileged-users.patch.
  Add cmdline override.
- commit 4b6e594

- af_unix: Disable MSG_OOB for unprivileged users (CVE-2025-38236
  bsc#1246093).
- commit 6110a63

- fs/orangefs: Allow 2 more characters in do_c_string()
  (git-fixes).
- commit 642fa26

- media: ipu6: isys: Use correct pads for xlate_streams()
  (git-fixes).
- media: ivsc: Fix crash at shutdown due to missing
  mei_cldev_disable() calls (git-fixes).
- media: verisilicon: Fix AV1 decoder clock frequency (git-fixes).
- commit ce0d383

- jfs: fix metapage reference count leak in dbAllocCtl
  (git-fixes).
- commit 58c926b

- x86/mce/amd: Fix threshold limit reset (git-fixes).
- commit 468e2ae

- bus: mhi: ep: Update read pointer only after buffer is written
  (CVE-2025-38429 bsc#1247253).
- commit 3341565

- x86/mce: Don't remove sysfs if thresholding sysfs init fails (git-fixes).
- commit 3d8385a

- x86/mce: Make sure CMCI banks are cleared during shutdown on Intel (git-fixes).
- commit fe9eb0f

- x86/mce/amd: Add default names for MCA banks and blocks (git-fixes).
- commit 27f7700

- x86/traps: Initialize DR6 by writing its architectural reset value (git-fixes).
- commit 80ddfd8

- media: venus: vdec: Clamp param smaller than 1fps and bigger
  than 240 (git-fixes).
- commit 1212a93

- x86/cpu/amd: Fix workaround for erratum 1054 (git-fixes).
- commit 2d80ddf

- mtd: rawnand: atmel: set pmecc data setup time (git-fixes).
- mtd: spinand: propagate spinand_wait() errors from
  spinand_write_page() (git-fixes).
- mtd: rawnand: fsmc: Add missing check after DMA map (git-fixes).
- mtd: rawnand: rockchip: Add missing check after DMA map
  (git-fixes).
- mtd: rawnand: atmel: Fix dma_mapping_error() address
  (git-fixes).
- mtd: rawnand: renesas: Add missing check after DMA map
  (git-fixes).
- mtd: spi-nor: Fix spi_nor_try_unlock_all() (git-fixes).
- mtd: fix possible integer overflow in erase_xfer() (git-fixes).
- clk: sunxi-ng: v3s: Fix de clock definition (git-fixes).
- clk: clk-axi-clkgen: fix fpfd_max frequency for zynq
  (git-fixes).
- clk: xilinx: vcu: unregister pll_post only if registered
  correctly (git-fixes).
- clk: davinci: Add NULL check in davinci_lpsc_clk_register()
  (git-fixes).
- hwmon: (gsc-hwmon) fix fan pwm setpoint show functions
  (git-fixes).
- pwm: imx-tpm: Reset counter if CMOD is 0 (git-fixes).
- media: uvcvideo: Do not mark valid metadata as invalid
  (git-fixes).
- media: ov2659: Fix memory leaks in ov2659_probe() (git-fixes).
- media: hi556: correct the test pattern configuration
  (git-fixes).
- media: vivid: fix wrong pixel_array control size (git-fixes).
- media: venus: hfi: explicitly release IRQ during teardown
  (git-fixes).
- media: venus: Add a check for packet size after reading from
  shared memory (git-fixes).
- media: venus: protect against spurious interrupts during probe
  (git-fixes).
- media: venus: venc: Clamp param smaller than 1fps and bigger
  than 240 (git-fixes).
- media: v4l2-ctrls: Don't reset handler's error in
  v4l2_ctrl_handler_free() (git-fixes).
- media: v4l2-ctrls: Fix H264 SEPARATE_COLOUR_PLANE check
  (git-fixes).
- media: imx: fix a potential memory leak in
  imx_media_csc_scaler_device_init() (git-fixes).
- media: rainshadow-cec: fix TOCTOU race condition in
  rain_interrupt() (git-fixes).
- media: gspca: Add bounds checking to firmware parser
  (git-fixes).
- media: usbtv: Lock resolution while streaming (git-fixes).
- media: uvcvideo: Fix 1-byte out-of-bounds read in
  uvc_parse_format() (git-fixes).
- crypto: qat - fix seq_file position update in adf_ring_next()
  (git-fixes).
- crypto: qat - fix DMA direction for compression on GEN2 devices
  (git-fixes).
- crypto: qat - flush misc workqueue during device shutdown
  (git-fixes).
- crypto: qat - disable ZUC-256 capability for QAT GEN5
  (git-fixes).
- crypto: img-hash - Fix dma_unmap_sg() nents value (git-fixes).
- crypto: keembay - Fix dma_unmap_sg() nents value (git-fixes).
- hwrng: mtk - handle devm_pm_runtime_enable errors (git-fixes).
- crypto: ccp - Fix crash when rebind ccp device for ccp.ko
  (git-fixes).
- crypto: inside-secure - Fix `dma_unmap_sg()` nents value
  (git-fixes).
- crypto: ccp - Fix locking on alloc failure handling (git-fixes).
- crypto: arm/aes-neonbs - work around gcc-15 warning (git-fixes).
- crypto: qat - fix state restore for banks with exceptions
  (git-fixes).
- crypto: qat - allow enabling VFs in the absence of IOMMU
  (git-fixes).
- crypto: marvell/cesa - Fix engine load inaccuracy (git-fixes).
- crypto: qat - use unmanaged allocation for dc_data (git-fixes).
- crypto: sun8i-ce - fix nents passed to dma_unmap_sg()
  (git-fixes).
- commit 8f3fb2a

- Move upstreamed SCSI and ACPI patches into sorted section
- commit 09d9d7c

- RDMA/uverbs: Add empty rdma_uattrs_has_raw_cap() declaration (git-fixes)
- commit ced3c6d

- Update config files.
  run_oldconfig, no functional change.
- commit 0b6044b

- RDMA/mlx5: Fix compilation warning when USER_ACCESS isn't set (git-fixes)
- commit dce79bd

- RDMA/hns: Fix -Wframe-larger-than issue (git-fixes)
- commit 90a067b

- RDMA/hns: Drop GFP_NOWARN (git-fixes)
- commit 927f6d6

- RDMA/hns: Fix accessing uninitialized resources (git-fixes)
- commit c1be2f8

- RDMA/hns: Get message length of ack_req from FW (git-fixes)
- commit 2e9a431

- RDMA/hns: Fix HW configurations not cleared in error flow (git-fixes)
- commit ba6e757

- RDMA/hns: Fix double destruction of rsv_qp (git-fixes)
- commit 0d7fee3

- Fix dma_unmap_sg() nents value (git-fixes)
- commit 89d1cb0

- RDMA/counter: Check CAP_NET_RAW check in user namespace for RDMA counters (git-fixes)
- commit c5238e7

- RDMA/nldev: Check CAP_NET_RAW in user namespace for QP modify (git-fixes)
- commit 0d7ab5b

- RDMA/mlx5: Check CAP_NET_RAW in user namespace for devx create (git-fixes)
- commit c162c8c

- RDMA/uverbs: Check CAP_NET_RAW in user namespace for RAW QP create (git-fixes)
- commit 3292115

- RDMA/uverbs: Check CAP_NET_RAW in user namespace for QP create (git-fixes)
- commit 90f88d3

- RDMA/mlx5: Check CAP_NET_RAW in user namespace for anchor create (git-fixes)
- commit a812e80

- RDMA/mlx5: Check CAP_NET_RAW in user namespace for flow create (git-fixes)
- commit 9dcd5e1

- RDMA/uverbs: Check CAP_NET_RAW in user namespace for flow create (git-fixes)
- commit eaff4b0

- vsock: Fix transport_{g2h,h2g} TOCTOU (CVE-2025-38462
  bsc#1247104).
- commit f5da768

- tcp: Correct signedness in skb remaining space calculation
  (CVE-2025-38463 bsc#1247113).
- net/sched: Always pass notifications when child class becomes
  empty (CVE-2025-38350 bsc#1246781).
- maple_tree: fix MA_STATE_PREALLOC flag in mas_preallocate()
  (CVE-2025-38364 bsc#1247091).
- commit 7390872

- x86: UV RTC: Add parameter to disable RTC clocksource
  (bsc#1241345).
- commit 79ccdce

- clocksource: Set cs_watchdog_read() checks based on
  .uncertainty_margin (bsc#1241345 bsc#1244457).
- commit 09911af

- clocksource: Scale the watchdog read retries automatically
  (bsc#1241345 bsc#1244457).
- Refresh
  patches.suse/clocksource-Fix-brown-bag-boolean-thinko-in-cs_watch.patch.
- Refresh
  patches.suse/clocksource-Make-watchdog-and-suspend-timing-multipl.patch.
- commit fdf040b

- drm/amdgpu/gfx10: fix kiq locking in KCQ reset (git-fixes).
- drm/amdgpu/gfx9.4.3: fix kiq locking in KCQ reset (git-fixes).
- drm/amdgpu/gfx9: fix kiq locking in KCQ reset (git-fixes).
- drm/xe/uapi: Correct sync type definition in comments
  (git-fixes).
- drm/amdgpu: Remove nbiov7.9 replay count reporting (git-fixes).
- drm/panthor: Add missing explicit padding in
  drm_panthor_gpu_info (git-fixes).
- drm/connector: hdmi: Evaluate limited range after computing
  format (git-fixes).
- wifi: nl80211: Set num_sub_specs before looping through
  sub_specs (git-fixes).
- wifi: mac80211: Write cnt before copying in
  ieee80211_copy_rnr_beacon() (git-fixes).
- wifi: ath12k: Pass ab pointer directly to
  ath12k_dp_tx_get_encap_type() (git-fixes).
- commit 52bb8aa

- wifi: iwlwifi: Fix error code in iwl_op_mode_dvm_start()
  (git-fixes).
- wifi: iwlwifi: return ERR_PTR from opmode start()
  (stable-fixes).
- commit bb4c593

- drm/amd/pm/powerplay/hwmgr/smu_helper: fix order of mask and
  value (git-fixes).
- fbcon: Fix outdated registered_fb reference in comment
  (git-fixes).
- drm/msm/dpu: Fill in min_prefill_lines for SC8180X (git-fixes).
- drm/vmwgfx: Fix Host-Backed userspace on Guest-Backed kernel
  (git-fixes).
- drm/panfrost: Fix panfrost device variable name in devfreq
  (git-fixes).
- drm/rockchip: cleanup fb when drm_gem_fb_afbc_init failed
  (git-fixes).
- can: peak_usb: fix USB FD devices potential malfunction
  (git-fixes).
- net: phy: micrel: fix KSZ8081/KSZ8091 cable test (git-fixes).
- net: usbnet: Avoid potential RCU stall on LINK_CHANGE event
  (git-fixes).
- can: kvaser_usb: Assign netdev.dev_port based on device channel
  index (git-fixes).
- can: kvaser_pciefd: Store device channel index (git-fixes).
- Bluetooth: hci_event: Mask data status from LE ext adv reports
  (git-fixes).
- wifi: ath12k: fix endianness handling while accessing wmi
  service bit (git-fixes).
- wifi: ath11k: fix sleeping-in-atomic in
  ath11k_mac_op_set_bitrate_mask() (git-fixes).
- wifi: ath12k: fix dest ring-buffer corruption when ring is full
  (git-fixes).
- wifi: ath12k: fix source ring-buffer corruption (git-fixes).
- wifi: ath12k: fix dest ring-buffer corruption (git-fixes).
- wifi: ath11k: fix dest ring-buffer corruption when ring is full
  (git-fixes).
- wifi: ath11k: fix source ring-buffer corruption (git-fixes).
- wifi: ath11k: fix dest ring-buffer corruption (git-fixes).
- wifi: ath11k: fix suspend use-after-free after probe failure
  (git-fixes).
- wifi: ath11k: clear initialized flag for deinit-ed srng lists
  (git-fixes).
- wifi: brcmfmac: fix P2P discovery failure in P2P peer due to
  missing P2P IE (git-fixes).
- Reapply &amp;quot;wifi: mac80211: Update skb's control block key in
  ieee80211_tx_dequeue()&amp;quot; (git-fixes).
- wifi: mac80211: Check 802.11 encaps offloading in
  ieee80211_tx_h_select_key() (git-fixes).
- wifi: mac80211: Don't call fq_flow_idx() for management frames
  (git-fixes).
- wifi: mac80211: Do not schedule stopped TXQs (git-fixes).
- wifi: plfxlc: Fix error handling in usb driver probe
  (git-fixes).
- wifi: mac80211: reject TDLS operations when station is not
  associated (git-fixes).
- wifi: brcmsmac: Remove const from tbl_ptr parameter in
  wlc_lcnphy_common_read_table() (git-fixes).
- mwl8k: Add missing check after DMA map (git-fixes).
- iwlwifi: Add missing check for alloc_ordered_workqueue
  (git-fixes).
- wifi: iwlwifi: Fix memory leak in iwl_mvm_init() (git-fixes).
- wifi: rtl818x: Kill URBs before clearing tx status queue
  (git-fixes).
- wifi: rtw89: avoid NULL dereference when RX problematic packet
  on unsupported 6 GHz band (git-fixes).
- commit 338f129

- RDMA/mlx5: Fix UMR modifying of mkey page size (git-fixes)
- commit d8f496b

- io_uring/sqpoll: don't put task_struct on tctx setup failure
  (bsc#1245664 CVE-2025-38106).
- commit 99ec003

- io_uring: consistently use rcu semantics with sqpoll thread
  (bsc#1245664 CVE-2025-38106).
- commit 528e7aa

- usb: gadget: configfs: Fix OOB read on empty string write
  (CVE-2025-38497 bsc#1247347).
- commit 96c22e3

- fs: export anon_inode_make_secure_inode() and fix secretmem
  LSM bypass (CVE-2025-38396 bsc#1247156).
- commit 281f5f1

- kabi/severities: ignore two unused/dropped symbols from MEI
- commit 7263fd9

- mei: vsc: Fix &amp;quot;BUG: Invalid wait context&amp;quot; lockdep error
  (git-fixes).
- mei: vsc: Run event callback from a workqueue (git-fixes).
- mei: vsc: Unset the event callback on remove and probe errors
  (git-fixes).
- mei: vsc: Event notifier fixes (git-fixes).
- mei: vsc: Destroy mutex after freeing the IRQ (git-fixes).
- mei: vsc: Don't re-init VSC from mei_vsc_hw_reset() on stop
  (git-fixes).
- mei: vsc: Drop unused vsc_tp_request_irq() and vsc_tp_free_irq()
  (stable-fixes).
- pwm: rockchip: Round period/duty down on apply, up on get
  (git-fixes).
- ASoC: mediatek: use reserved memory or enable buffer
  pre-allocation (git-fixes).
- commit 88c8c1c

- wifi: ath12k: fix GCC_GCC_PCIE_HOT_RST definition for WCN7850
  (CVE-2025-38414 bsc#1247145).
- commit be37365

- Docs/ABI: Fix sysfs-kernel-address_bits path (git-fixes).
- soc: qcom: pmic_glink: fix OF node leak (git-fixes).
- soc: qcom: fix endianness for QMI header (git-fixes).
- soc: qcom: QMI encoding/decoding for big endian (git-fixes).
- soc/tegra: cbb: Clear ERR_FORCE register with ERR_STATUS
  (git-fixes).
- usb: musb: omap2430: fix device leak at unbind (git-fixes).
- usb: gadget: udc: renesas_usb3: fix device leak at unbind
  (git-fixes).
- usb: dwc3: meson-g12a: fix device leaks at unbind (git-fixes).
- usb: atm: cxacru: Merge cxacru_upload_firmware() into
  cxacru_heavy_init() (git-fixes).
- thunderbolt: Fix copy+paste error in match_service_id()
  (git-fixes).
- usb: typec: ucsi: Update power_supply on power role change
  (git-fixes).
- usb: gadget : fix use-after-free in composite_dev_cleanup()
  (git-fixes).
- cdc-acm: fix race between initial clearing halt and open
  (git-fixes).
- usb: early: xhci-dbc: Fix early_ioremap leak (git-fixes).
- usb: misc: apple-mfi-fastcharge: Make power supply names unique
  (git-fixes).
- Documentation: usb: gadget: Wrap remaining usage snippets in
  literal code block (git-fixes).
- usb: host: xhci-plat: fix incorrect type for of_match variable
  in xhci_plat_probe() (git-fixes).
- vt: defkeymap: Map keycodes above 127 to K_HOLE (git-fixes).
- vt: keyboard: Don't process Unicode characters in K_OFF mode
  (git-fixes).
- staging: axis-fifo: remove sysfs interface (git-fixes).
- staging: nvec: Fix incorrect null termination of battery
  manufacturer (git-fixes).
- staging: fbtft: fix potential memory leak in
  fbtft_framebuffer_alloc() (git-fixes).
- iio: adc: ad_sigma_delta: change to buffer predisable
  (git-fixes).
- iio: imu: bno055: fix OOB access of hw_xlate array (git-fixes).
- bus: mhi: host: Detect events pointing to unexpected TREs
  (git-fixes).
- misc: rtsx: usb: Ensure mmc child device is active when card
  is present (git-fixes).
- vmci: Prevent the dispatching of uninitialized payloads
  (git-fixes).
- samples: mei: Fix building on musl libc (git-fixes).
- platform/chrome: cros_ec: Unregister notifier in
  cros_ec_unregister() (git-fixes).
- gpio: virtio: Fix config space reading (git-fixes).
- ASoC: ops: dynamically allocate struct snd_ctl_elem_value
  (git-fixes).
- ASoC: soc-dai: tidyup return value of
  snd_soc_xlate_tdm_slot_mask() (git-fixes).
- Documentation: ACPI: Fix parent device references (git-fixes).
- ACPI: LPSS: Remove AudioDSP related ID (git-fixes).
- ACPI: processor: perflib: Fix initial _PPC limit application
  (git-fixes).
- powercap: dtpm_cpu: Fix NULL pointer dereference in
  get_pd_power_uw() (git-fixes).
- PM / devfreq: Check governor before using governor-&amp;gt;name
  (git-fixes).
- commit fbd21ae

- apple-mfi-fastcharge: protect first device name (git-fixes).
- commit 903dc58

- vsock/vmci: Clear the vmci transport packet properly when
  initializing it (CVE-2025-38403 bsc#1247141).
- commit 6379963

- KVM: SVM: Reject SEV{-ES} intra host migration if vCPU creation
  is in-flight (CVE-2025-38455 bsc#1247101).
- commit ca76701

- vsock: Fix transport_* TOCTOU (CVE-2025-38461 bsc#1247103).
- commit 916fdd6

- iommu/tegra241-cmdqv: Read SMMU IDR1.CMDQS instead of
  hardcoding (git-fixes).
- commit 8985193

- eventpoll: don't decrement ep refcount while still holding
  the ep mutex (bsc#1246777 CVE-2025-38349).
- commit 6c5e857

- jbd2: fix data-race and null-ptr-deref in
  jbd2_journal_dirty_metadata() (bsc#1246253 CVE-2025-38337).
- commit 4cfb834

- ext4: inline: fix len overflow in ext4_prepare_inline_data
  (bsc#1245976 CVE-2025-38222).
- commit bdddb2f

- ublk: santizize the arguments from userspace when adding a
  device (bsc#1245937 CVE-2025-38182).
- commit c70260e

- __legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under
  mount_lock (bsc#1245151 CVE-2025-38058).
- commit 5d79b46

- xfs: remove unused trace event xfs_reflink_cow_enospc
  (git-fixes).
- commit 43f2e3c

- xfs: only create event xfs_file_compat_ioctl when CONFIG_COMPAT
  is configure (git-fixes).
- commit 90cf0ff

- xfs: remove usused xfs_end_io_direct events (git-fixes).
- commit 973d0e0

- xfs: remove unused event xfs_pagecache_inval (git-fixes).
- commit 92f5436

- xfs: remove unused event xfs_alloc_near_nominleft (git-fixes).
- commit cce777b

- xfs: remove unused event xfs_alloc_near_error (git-fixes).
- commit 5b572bf

- xfs: remove unused event xfs_attr_node_removename (git-fixes).
- commit 4753b23

- xfs: remove unused xfs_attr events (git-fixes).
- commit 1b0cc0c

- xfs: remove unused trace event xfs_attr_rmtval_set (git-fixes).
- commit d855e56

- xfs: remove unused xfs_reflink_compare_extents events
  (git-fixes).
- commit a7afc4b

- xfs: remove unused event xfs_ioctl_clone (git-fixes).
- commit b5dfc1b

- xfs: remove unused event xlog_iclog_want_sync (git-fixes).
- commit 217c9f9

- xfs: remove unused trace event xfs_attr_remove_iter_return
  (git-fixes).
- commit 70b1bc5

- NFSD: detect mismatch of file handle and delegation stateid
  in OPEN op (git-fixes).
- commit 00b51c6

- nfsd: handle get_client_locked() failure in
  nfsd4_setclientid_confirm() (git-fixes).
- commit b0cf612

- hfsplus: remove mutex_lock check in hfsplus_free_extents
  (git-fixes).
- commit e14f374

- s390/entry: Fix last breaking event handling in case of stack
  corruption (git-fixes bsc#1243806).
- commit d31e65a

- hfs: make splice write available again (git-fixes).
- commit 96498bf

- hfsplus: make splice write available again (git-fixes).
- commit 5121068

- Refresh
  patches.suse/btrfs-always-fallback-to-buffered-write-if-the-inode.patch.
  To remove an incorrectly generated file which is not utilized at all.
- commit 8e57a15

- io_uring: fix use-after-free of sq-&amp;gt;thread in
  __io_uring_show_fdinfo() (bsc#1245664 CVE-2025-38106).
- io_uring/sqpoll: fix sqpoll error handling races (bsc#1245664
  CVE-2025-38106).
- commit d9c3e11

- sprintf.h: mask additional include (git-fixes).
- sprintf.h requires stdarg.h (git-fixes).
- commit 3d7f6c0

- btrfs: fix non-empty delayed iputs list on unmount due to
  async workers (git-fixes).
- commit 285c1f5

- btrfs: fix assertion when building free space tree (git-fixes).
- commit a3fd65f

- btrfs: fix iteration of extrefs during log replay (bsc#1247031
  CVE-2025-38382).
- commit 5e64fe6

- btrfs: fix missing error handling when searching for inode
  refs during log replay (git-fixes).
- commit a8205e6

- kabi: Hide adding of u64 to devlink_param_type (jsc#PED-12745).
- commit aad1545

- i2c: qup: jump out of the loop in case of timeout (git-fixes).
- i2c: virtio: Avoid hang by using interruptible completion wait
  (git-fixes).
- i2c: tegra: Fix reset error handling with ACPI (git-fixes).
- commit 5a2e6c7

- drm/xe: Fix build without debugfs (git-fixes).
- drm/i915/display: Fix dma_fence_wait_timeout() return value
  handling (git-fixes).
- commit c72dd8f

- btrfs: fix a race between renames and directory logging
  (bsc#1247023 CVE-2025-38365).
- commit 322c28e

- netlink: specs: devlink: replace underscores with dashes in
  names (jsc#PED-12745).
- netlink: fix policy dump for int with validation callback
  (jsc#PED-12745).
- commit 379185c

- dpll: Add basic Microchip ZL3073x support (jsc#PED-12745).
- Update config files.
- supported.conf: Mark ZL3073X modules supported
- commit d22a1c3

- supported.conf: move nvme-apple to optional again
- commit a3e3a0c

- dpll: zl3073x: Add support to get/set frequency on pins
  (jsc#PED-12745).
- dpll: zl3073x: Implement input pin state setting in automatic
  mode (jsc#PED-12745).
- dpll: zl3073x: Add support to get/set priority on input pins
  (jsc#PED-12745).
- dpll: zl3073x: Implement input pin selection in manual mode
  (jsc#PED-12745).
- dpll: zl3073x: Register DPLL devices and pins (jsc#PED-12745).
- dpll: zl3073x: Read DPLL types and pin properties from system
  firmware (jsc#PED-12745).
- dpll: zl3073x: Fetch invariants during probe (jsc#PED-12745).
- devlink: Add support for u64 parameters (jsc#PED-12745).
- dt-bindings: dpll: Add support for Microchip Azurite chip family
  (jsc#PED-12745).
- dt-bindings: dpll: Add DPLL device and pin (jsc#PED-12745).
- devlink: avoid param type value translations (jsc#PED-12745).
- devlink: define enum for attr types of dynamic attributes
  (jsc#PED-12745).
- devlink: introduce devlink_nl_put_u64() (jsc#PED-12745).
- commit d75c228

- llist: add interface to check if a node is on a list
  (CVE-2025-38264 bsc#1246387).
- commit f06e99c

- nvme-tcp: sanitize request list handling (CVE-2025-38264
  bsc#1246387).
- commit 33933f9

- supported.conf: sort entries again
- commit c720956

- supported.conf: sort entries again
- commit 2db834f

- supported.conf: add missing entries for armv7hl
- commit 3fcf489

- ALSA: hda/realtek: Fix mute LED mask on HP OMEN 16 laptop
  (git-fixes).
- drm/xe/pf: Prepare to stop SR-IOV support prior GT reset
  (git-fixes).
- drm/xe/mocs: Initialize MOCS index early (stable-fixes).
- drm/amdgpu: Increase reset counter only on success
  (stable-fixes).
- drm/amd/display: Disable CRTC degamma LUT for DCN401
  (stable-fixes).
- drm/amd/display: Free memory allocation (stable-fixes).
- drm/xe/pf: Move VFs reprovisioning to worker (stable-fixes).
- drm/xe/pf: Sanitize VF scratch registers on FLR (stable-fixes).
- commit 13260a4

- nilfs2: reject invalid file types when reading inodes
  (git-fixes).
- commit b094111

- resource: fix false warning in __request_region() (git-fixes).
- bus: fsl-mc: Fix potential double device reference in
  fsl_mc_get_endpoint() (git-fixes).
- USB: serial: option: add Telit Cinterion FE910C04 (ECM)
  composition (stable-fixes).
- USB: serial: ftdi_sio: add support for NDI EMGUIDE GEMINI
  (stable-fixes).
- USB: serial: option: add Foxconn T99W640 (stable-fixes).
- iio: adc: max1363: Reorder mode_list[] entries (stable-fixes).
- iio: adc: max1363: Fix MAX1363_4X_CHANS/MAX1363_8X_CHANS[]
  (stable-fixes).
- ALSA: hda/realtek: Add quirk for ASUS ROG Strix G712LWS
  (stable-fixes).
- HID: core: do not bypass hid_hw_raw_request (stable-fixes).
- HID: core: ensure the allocated report buffer can contain the
  reserved report ID (stable-fixes).
- regulator: pwm-regulator: Calculate the output voltage for
  disabled PWMs (stable-fixes).
- commit 829a426

- rpm/kernel-subpackage-spec: Skip brp-strip-debug to avoid file truncation (bsc#1246879)
  Put the same workaround to avoid file truncation of vmlinux and co in
  kernel-default-base package, too.
- commit 2329734

- iommu/vt-d: Fix possible circular locking dependency
  (git-fixes).
- commit 0774c7d

- Revert &amp;quot;drm/nouveau: check ioctl command codes better&amp;quot;
  (git-fixes).
- drm/amdgpu: Reset the clear flag in buddy during resume
  (git-fixes).
- platform/x86: Fix initialization order for
  firmware_attributes_class (git-fixes).
- commit 46d2d36

- drm/bridge: ti-sn65dsi86: Remove extra semicolon in
  ti_sn_bridge_probe() (git-fixes).
- drm/sched: Remove optimization that causes hang when killing
  dependent jobs (git-fixes).
- platform/x86: ideapad-laptop: Fix kbd backlight not remembered
  among boots (git-fixes).
- commit 0083a37

- iommu/vt-d: Fix system hang on reboot -f (git-fixes).
- commit 034e69f

- rpm/kernel-binary.spec.in: Ignore return code from ksymtypes compare
  When using suse-kabi-tools, the RPM build invokes 'ksymvers compare' to
  compare the resulting symbol CRCs with the reference data. If the values
  differ, it then invokes 'ksymtypes compare' to provide a detailed report
  explaining why the symbols differ. The build expects the latter
  'ksymtypes compare' command to always return zero, even if the two
  compared kABI corpuses are different.
  This is currently the case for 'ksymtypes compare'. However, I plan to
  update the command to return a non-zero code when the comparison detects
  any differences. This should ensure consistent behavior with 'ksymvers
  compare'.
  Since the build uses 'ksymtypes compare' only for more detailed
  diagnostics, ignore its return code.
- commit 5ac1381

- net: atm: fix /proc/net/atm/lec handling (CVE-2025-38180
  bsc#1245970).
- net: atm: add lec_mutex (CVE-2025-38323 bsc#1246473).
- commit 1698a7c

- KVM: x86: Load DR6 with guest value only before entering .vcpu_run() loop (bsc#1239061 CVE-2025-21839).
- commit fe1f630

- net: dsa: b53: do not enable EEE on bcm63xx (CVE-2025-38272
  bsc#1246268).
- commit ee16b59

- Refresh
  patches.suse/selftests-bpf-Clean-up-open-coded-gettid-syscall-inv.patch.
  Fix following BPF selftests compilation error due to missing dependency.
  /home/runner/work/libbpf/libbpf/.kernel/tools/testing/selftests/bpf/prog_tests/ns_current_pid_tgid.c: In function âtest_current_pid_tgidâ:
  /home/runner/work/libbpf/libbpf/.kernel/tools/testing/selftests/bpf/prog_tests/ns_current_pid_tgid.c:31:9: error: invalid type argument of unary â*â (have âpid_tâ {aka âintâ})
    31 |         *pid = sys_gettid();
    |         ^~~~
- commit d85d5ff

- Delete
  patches.suse/selftests-bpf-Add-tests-for-sdiv-smod-overflow-cases.patch.
  The __arch_x86_64 macro is not yet supported in BPF selftests (depends
  on c64d2f72bf2e &amp;quot;selftests/bpf: *_arch** macro to limit test cases to
  specific archs&amp;quot;), so drop tests that uses it.
- commit 55e800e

- scsi: fnic: Set appropriate logging level for log message
  (bsc#1246644).
- scsi: fnic: Add and improve logs in FDMI and FDMI ABTS paths
  (bsc#1246644).
- commit b87ecf0

- Bluetooth: hci_sync: Fix UAF on create_le_conn_complete
  (git-fixes).
- commit 7a089da

- hci_dev centralize extra lock (CVE-2025-38117 bsc#1245695).
- commit 892de21

- Bluetooth: MGMT: Protect mgmt_pending list with its own lock
  (CVE-2025-38117 bsc#1245695).
- commit e0d8b29

- Bluetooth: hci_sync: Introduce
  hci_cmd_sync_run/hci_cmd_sync_run_once (CVE-2025-38117
  bsc#1245695).
- commit c86dd9a

- Bluetooth: hci_core: Make hci_is_le_conn_scanning public
  (CVE-2025-38117 bsc#1245695).
- Refresh
  patches.suse/Bluetooth-hci_sync-Use-QoS-to-determine-which-PHY-to.patch.
- commit 566b348

- Bluetooth: hci_sync: Fix handling of HCI_OP_CREATE_CONN_CANCEL
  (git-fixes).
- commit 79fc3de

- gpiolib: of: Add polarity quirk for s5m8767 (stable-fixes).
- gpio: vf610: add locking to gpio direction functions
  (git-fixes).
- gpio: pca953x: log an error when failing to get the reset GPIO
  (git-fixes).
- gpiolib: cdev: Ignore reconfiguration without direction
  (git-fixes).
- gpiolib: acpi: Fix failed in acpi_gpiochip_find() by adding
  parent node match (bsc#1233300).
- gpiolib: Fix debug messaging in gpiod_find_and_request()
  (git-fixes).
- gpiolib: Handle no pin_ranges in gpiochip_generic_config()
  (git-fixes).
- gpio: sim: include a missing header (git-fixes).
- gpiolib: acpi: Don't use GPIO chip fwnode in
  acpi_gpiochip_find() (bsc#1233300).
- commit 75afc01

- Bluetooth: MGMT: convert timeouts to secs_to_jiffies()
  (CVE-2025-38117 bsc#1245695).
- commit 3e2758a

- bluetooth: mgmt: convert timeouts to secs_to_jiffies()
  (CVE-2025-38117 bsc#1245695).
- commit b8976eb

- s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL again
  (git-fixes bsc#1246870).
- commit 8e4fb25

- Fix build warning
  Refresh
  patches.suse/mm-hugetlb-fix-DEBUG_LOCKS_WARN_ON-1-when-dissolve_f.patch.
- commit ccb6e90

- Bluetooth: MGMT: Fix not generating command complete for
  MGMT_OP_DISCONNECT (git-fixes).
- Refresh
  patches.suse/Bluetooth-hci_event-Fix-not-using-key-encryption-siz.patch.
- commit 6f743e7

- Bluetooth: hci_sync: Attempt to dequeue connection attempt
  (git-fixes).
- Refresh
  patches.suse/Bluetooth-L2CAP-Fix-slab-use-after-free-Read-in-l2ca.patch.
- Refresh
  patches.suse/Bluetooth-hci_event-Fix-not-using-key-encryption-siz.patch.
- Refresh
  patches.suse/Bluetooth-hci_sync-Fix-UAF-in-hci_acl_create_conn_sy.patch.
- commit 22a7d25

- Bluetooth: hci_conn: Fix sending
  BT_HCI_CMD_LE_CREATE_CONN_CANCEL (git-fixes).
- commit defb49e

- Bluetooth: mgmt: remove NULL check in
  add_ext_adv_params_complete() (CVE-2025-38117 bsc#1245695).
- Bluetooth: mgmt: remove NULL check in
  mgmt_set_connectable_complete() (CVE-2025-38117 bsc#1245695).
- commit 3217653

- bluetooth: restore le_scan_restart in struct hci_dev
  (CVE-2025-38117 bsc#1245695).
- commit 7e7eb69

- Bluetooth: hci_core: Remove le_restart_scan work (CVE-2025-38117
  bsc#1245695).
- commit 9530108

- Input: gpio-keys - fix a sleep while atomic with PREEMPT_RT
  (CVE-2025-38335 bsc#1246250).
- commit 4b421f0

- Correctly put RDMA kabi patch into patches.kabi instead of patches.suse
- commit 0433d1f

- kABI workaround for bluetooth hci_dev changes (CVE-2025-38250
  bsc#1246182).
- commit 2bfeee5

- Bluetooth: hci_core: Fix use-after-free in vhci_flush()
  (CVE-2025-38250 bsc#1246182).
- commit 45dea35

- selftests/bpf: Support more socket types in create_pair()
  (bsc#1239470 CVE-2025-21854).
- selftests/bpf: Refactor out helper functions for a few tests
  (bsc#1239470 CVE-2025-21854).
- commit 21d7fea

- mm/hugetlb: fix DEBUG_LOCKS_WARN_ON(1) when
  dissolve_free_hugetlb_folio() (bsc#1225707 CVE-2024-36028).
- commit ce47e5b

- Delete
  patches.suse/selftest-bpf-Add-test-for-af_vsock-poll.patch.
  It requires the &amp;quot;bpf_program__attach_sockmap&amp;quot; API in libbpf, which isn't
  backported.
- Refresh patches.suse/selftest-bpf-Add-vsock-test-for-sockmap-rejecting-un.patch
- commit a7dddad

- i2c: stm32: fix the device used for the DMA map (git-fixes).
- usb: hub: Don't try to recover devices lost during warm reset
  (git-fixes).
- usb: musb: fix gadget state on disconnect (git-fixes).
- thunderbolt: Fix bit masking in tb_dp_port_set_hops()
  (git-fixes).
- thunderbolt: Fix wake on connect at runtime (git-fixes).
- pch_uart: Fix dma_sync_sg_for_device() nents value (git-fixes).
- comedi: Fix initialization of data for instructions that write
  to subdevice (git-fixes).
- comedi: Fix use of uninitialized data in insn_rw_emulate_bits()
  (git-fixes).
- comedi: das6402: Fix bit shift out of bounds (git-fixes).
- comedi: aio_iiro_16: Fix bit shift out of bounds (git-fixes).
- comedi: pcl812: Fix bit shift out of bounds (git-fixes).
- comedi: das16m1: Fix bit shift out of bounds (git-fixes).
- comedi: Fix some signed shift left operations (git-fixes).
- comedi: Fail COMEDI_INSNLIST ioctl if n_insns is too large
  (git-fixes).
- iio: adc: ad7949: use spi_is_bpw_supported() (git-fixes).
- iio: accel: fxls8962af: Fix use after free in
  fxls8962af_fifo_flush (git-fixes).
- iio: adc: stm32-adc: Fix race in installing chained IRQ handler
  (git-fixes).
- regmap: fix potential memory leak of regmap_bus (git-fixes).
- Input: xpad - set correct controller type for Acer NGR200
  (git-fixes).
- commit 08dfa63

- jfs: Fix null-ptr-deref in jfs_ioc_trim (bsc#1246044
  CVE-2025-38203).
- commit e88ea13

- drm/mediatek: only announce AFBC if really supported
  (git-fixes).
- drm/mediatek: Add wait_event_timeout when disabling plane
  (git-fixes).
- drm/nouveau: check ioctl command codes better (git-fixes).
- commit 8f80850

- hwmon: (corsair-cpro) Validate the size of the received input
  buffer (git-fixes).
- drm/amdgpu/gfx8: reset compute ring wptr on the GPU on resume
  (git-fixes).
- soundwire: amd: fix for clearing command status register
  (git-fixes).
- dmaengine: nbpfaxi: Fix memory corruption in probe()
  (git-fixes).
- phy: tegra: xusb: Fix unbalanced regulator disable in UTMI
  PHY mode (git-fixes).
- memstick: core: Zero initialize id_reg in
  h_memstick_read_dev_id() (git-fixes).
- mmc: bcm2835: Fix dma_unmap_sg() nents value (git-fixes).
- mmc: sdhci_am654: Workaround for Errata i2312 (git-fixes).
- mmc: sdhci-pci: Quirk for broken command queuing on Intel
  GLK-based Positivo models (git-fixes).
- commit 0d9aae2

- net/sched: Return NULL when htb_lookup_leaf encounters an
  empty rbtree (git-fixes).
- commit fb42307

- ipv6: mcast: Delay put pmc-&amp;gt;idev in mld_del_delrec()
  (git-fixes).
- commit 505c14c

- rpl: Fix use-after-free in rpl_do_srh_inline() (git-fixes).
- commit 3342938

- af_packet: fix the SO_SNDTIMEO constraint not effective on
  tpacked_snd() (git-fixes).
- commit 877c186

- net/sched: sch_qfq: Fix race condition on qfq_aggregate
  (git-fixes).
- commit 2e8a829

- Delete
  patches.kabi/struct-ucsi_operations-use-padding-for-new-operation.patch.
- Delete
  patches.kabi/ucsi_operations-add-stubs-for-all-operations.patch.
- Delete
  patches.kabi/ucsi_ops-adapt-update_connector-to-kABI-consistency.patch.
- commit 0ef32b8

- wifi: cfg80211: remove scan request n_channels counted_by
  (git-fixes).
- Refresh patches.suse/wireless-suse-kabi-padding.patch.
- commit b29e6bc

- Bluetooth: hci_core: add missing braces when using macro
  parameters (git-fixes).
- Bluetooth: btintel: Check if controller is ISO capable on
  btintel_classify_pkt_type (git-fixes).
- wifi: rt2x00: fix remove callback type mismatch (git-fixes).
- wifi: cfg80211: fix S1G beacon head validation in nl80211
  (git-fixes).
- wifi: cfg80211/mac80211: correctly parse S1G beacon optional
  elements (git-fixes).
- drm/amdgpu/ip_discovery: add missing ip_discovery fw
  (stable-fixes).
- drm/amdgpu/discovery: use specific ip_discovery.bin for legacy
  asics (stable-fixes).
- commit 201bdcf

- kABI workaround for struct drm_framebuffer changes (git-fixes).
- commit 7b3cefa

- drm/framebuffer: Acquire internal references on GEM handles
  (git-fixes).
- commit 736ff8d

- Bluetooth: L2CAP: Fix attempting to adjust outgoing MTU
  (git-fixes).
- Bluetooth: btusb: QCA: Fix downloading wrong NVM for WCN6855
  GF variant without board ID (git-fixes).
- Bluetooth: SMP: Fix using HCI_ERROR_REMOTE_USER_TERM on timeout
  (git-fixes).
- Bluetooth: SMP: If an unallowed command is received consider
  it a failure (git-fixes).
- Bluetooth: hci_sync: fix connectable extended advertising when
  using static random address (git-fixes).
- Bluetooth: Fix null-ptr-deref in l2cap_sock_resume_cb()
  (git-fixes).
- usb: net: sierra: check for no status endpoint (git-fixes).
- net: phy: Don't register LEDs for genphy (git-fixes).
- drm/gem: Fix race in drm_gem_handle_create_tail()
  (stable-fixes).
- wifi: prevent A-MSDU attacks in mesh networks (stable-fixes).
- Revert &amp;quot;ACPI: battery: negate current when discharging&amp;quot;
  (stable-fixes).
- usb: cdnsp: Fix issue with CV Bad Descriptor test (git-fixes).
- drm/gem: Acquire references on GEM handles for framebuffers
  (stable-fixes).
- vt: add missing notification when switching back to text mode
  (stable-fixes).
- ASoC: amd: yc: add quirk for Acer Nitro ANV15-41 internal mic
  (stable-fixes).
- ALSA: hda/realtek - Enable mute LED on HP Pavilion Laptop
  15-eg100 (stable-fixes).
- HID: lenovo: Add support for ThinkPad X1 Tablet Thin Keyboard
  Gen2 (stable-fixes).
- HID: Add IGNORE quirk for SMARTLINKTECHNOLOGY (stable-fixes).
- HID: quirks: Add quirk for 2 Chicony Electronics HP 5MP Cameras
  (stable-fixes).
- net: usb: qmi_wwan: add SIMCom 8230C composition (stable-fixes).
- usb: cdnsp: Replace snprintf() with the safer scnprintf()
  variant (stable-fixes).
- usb:cdnsp: remove TRB_FLUSH_ENDPOINT command (stable-fixes).
- commit b8ce602

- Refresh
  patches.suse/selftests-bpf-Add-tests-for-iter-next-method-returni.patch.
  Fix BPF selftests build failure in progs/iters_testmod.c due to missing
  definition of 'struct bpf_iter_task_vma' and 'bpf_iter_task_vma()'.
- commit ca03a47

- selftests/bpf: Add ASSERT_OK_FD macro (bsc#1239470
  CVE-2025-21854).
- commit 746f5fc

- ptp: fix breakage after ptp_vclock_in_use() rework
  (bsc#1246506).
- commit bbe324a

- x86/virt/tdx: Avoid indirect calls to TDX assembly functions (git-fixes).
- commit 9c296c1

- soc: aspeed: lpc-snoop: Don't disable channels that aren't
  enabled (git-fixes).
- soc: aspeed: lpc-snoop: Cleanup resources in stack-order
  (git-fixes).
- HID: core: ensure __hid_request reserves the report ID as the
  first byte (git-fixes).
- commit 5cd5cd3

- drm/msm/a7xx: Call CP_RESET_CONTEXT_STATE (CVE-2025-38188
  bsc#1246098).
- drm/msm/a6xx+: Insert a fence wait before SMMU table update
  (CVE-2025-38188 bsc#1246098).
- commit e22ddaf

- x86/iopl: Cure TIF_IO_BITMAP inconsistencies (CVE-2025-38100
  bsc#1245650).
- commit 143bbc6

- Bluetooth: eir: Fix possible crashes on eir_create_adv_data
  (CVE-2025-38303 bsc#1246354).
- commit 89447f6

- kABI workaround for bpf: Do not include stack ptr register in
  precision backtracking bookkeeping (bsc#1246264 CVE-2025-38279).
- commit 8287c19

- btrfs: explicitly ref count block_group on new_bgs list (bsc#1243068)
- commit 8647d2c

- btrfs: make btrfs_discard_workfn() block_group ref explicit (bsc#1243068)
- commit 32e19f5

- btrfs: harden block_group::bg_list against list_del() races (CVE-2025-37856 bsc#1243068)
- commit 3333359

- btrfs: correct the order of prelim_ref arguments in btrfs__prelim_ref (CVE-2025-38034 bsc#1244792)
- commit 55c0ec4

- btrfs: do not BUG_ON() when freeing tree block after error (CVE-2024-44963 1230216)
- commit d292416

- scsi: megaraid_sas: Fix invalid node index (CVE-2025-38239
  bsc#1246178).
- seg6: Fix validation of nexthop addresses (CVE-2025-38310
  bsc#1246361).
- x86/sgx: Prevent attempts to reclaim poisoned pages
  (CVE-2025-38334 bsc#1246384).
- commit 740f6c2

- selftests/bpf: Add tests with stack ptr register in conditional
  jmp (bsc#1246264 CVE-2025-38279).
- bpf: Do not include stack ptr register in precision backtracking
  bookkeeping (bsc#1246264 CVE-2025-38279).
- Refresh patches.kabi/bpf-verifier-kABI-workarounds.patch
- commit ccc2c5b

- bridge: mcast: Fix use-after-free during router port
  configuration (CVE-2025-38248 bsc#1246173).
- net: stmmac: make sure that ptp_rate is not 0 before configuring
  timestamping (CVE-2025-38126 bsc#1245708).
- bpf: fix ktls panic with sockmap (CVE-2025-38166 bsc#1245758).
- commit 01133bb

- iommu/amd: Set the pgsize_bitmap correctly (git-fixes).
- commit 8746ec5

- scsi: core: Enforce unlimited max_segment_size when
  virt_boundary_mask is set (git-fixes).
- scsi: qla4xxx: Fix missing DMA mapping error in
  qla4xxx_alloc_pdu() (git-fixes).
- scsi: qla2xxx: Fix DMA mapping test in
  qla24xx_get_port_database() (git-fixes).
- scsi: megaraid_sas: Fix invalid node index (git-fixes).
- aoe: clean device rq_list in aoedev_downdev() (git-fixes).
- md/md-bitmap: fix dm-raid max_write_behind setting (git-fixes).
- commit 2e07501

- dm-bufio: fix sched in atomic context (git-fixes).
- commit c664ddf

- Update
  patches.suse/nvme-pci-fix-queue-unquiesce-check-on-slot_reset.patch
  (git-fixes bsc#1240885).
- commit 08c0025

- scsi: fnic: Fix missing DMA mapping error in fnic_send_frame()
  (git-fixes).
- scsi: fnic: Turn off FDMI ACTIVE flags on link down (git-fixes).
- scsi: fnic: Fix crash in fnic_wq_cmpl_handler when FDMI times
  out (git-fixes).
- commit 60bac5b

- perf: Fix sample vs do_exit() (bsc#1246547).
- commit 5327721

- thermal: trip: Use READ_ONCE() for lockless access to trip
  properties (git-fixes).
- commit bd7ba80

- thermal: trip: Use common set of trip type names (git-fixes).
- commit a92e9b8

- x86/CPU/AMD: Add more models to X86_FEATURE_ZEN5 (bsc#1246449).
- Refresh
  patches.suse/x86-CPU-AMD-Add-models-0x10-0x1f-to-the-Zen5-range.patch.
- commit b606b50

- nvme-pci: refresh visible attrs after being checked (git-fixes).
- nvme: Fix incorrect cdw15 value in passthru error logging
  (git-fixes).
- commit c5d3460

- scsi: lpfc: Copyright updates for 14.4.0.10 patches (bsc#1245260
  bsc#1243100 bsc#1246125).
- commit 58f7c6e

- scsi: lpfc: Update lpfc version to 14.4.0.10 (bsc#1245260
  bsc#1243100 bsc#1246125).
- scsi: lpfc: Modify end-of-life adapters' model descriptions
  (bsc#1245260 bsc#1243100 bsc#1246125 bsc#1204142).
- scsi: lpfc: Revise CQ_CREATE_SET mailbox bitfield definitions
  (bsc#1245260 bsc#1243100 bsc#1246125).
- scsi: lpfc: Move clearing of HBA_SETUP flag to before
  lpfc_sli4_queue_unset (bsc#1245260 bsc#1243100 bsc#1246125).
- scsi: lpfc: Ensure HBA_SETUP flag is used only for SLI4 in
  dev_loss_tmo_callbk (bsc#1245260 bsc#1243100 bsc#1246125).
- scsi: lpfc: Relocate clearing initial phba flags from link up
  to link down hdlr (bsc#1245260 bsc#1243100 bsc#1246125).
- scsi: lpfc: Simplify error handling for failed
  lpfc_get_sli4_parameters cmd (bsc#1245260 bsc#1243100
  bsc#1246125).
- scsi: lpfc: Early return out of FDMI cmpl for locally rejected
  statuses (bsc#1245260 bsc#1243100 bsc#1246125).
- scsi: lpfc: Skip RSCN processing when FC_UNLOADING flag is set
  (bsc#1245260 bsc#1243100 bsc#1246125).
- scsi: lpfc: Check for hdwq null ptr when cleaning up lpfc_vport
  structure (bsc#1245260 bsc#1243100 bsc#1246125).
- scsi: lpfc: Update debugfs trace ring initialization messages
  (bsc#1245260 bsc#1243100 bsc#1246125).
- scsi: lpfc: Revise logging format for failed CT MIB requests
  (bsc#1245260 bsc#1243100 bsc#1246125).
- commit 14dcfed

- crypto: hkdf - skip TVs with unapproved salt lengths in FIPS
  mode (bsc#1241200 bsc#1246134).
- commit 1b17c76

- Update
  patches.suse/net-clear-the-dst-when-changing-skb-protocol.patch
  (bsc#1245954 CVE-2025-38192).
  Fix incorrect CVE reference.
- commit 288e8f6

- drm/nouveau: fix a use-after-free in r535_gsp_rpc_push() (bsc#1245951 CVE-2025-38187)
- commit 62c6956

- bpf: Check rcu_read_lock_trace_held() in
  bpf_map_lookup_percpu_elem() (bsc#1245980 CVE-2025-38202).
- commit 630834e

- selftest/bpf/benchs: Add benchmark for sockmap usage
  (bsc#1245749 CVE-2025-38154).
- commit ac96089

- bpf, sockmap: Avoid using sk_socket after free when sending
  (bsc#1245749 CVE-2025-38154).
- bpf, sockmap: Fix panic when calling skb_linearize (bsc#1245749
  CVE-2025-38154).
- bpf, sockmap: fix duplicated data transmission (bsc#1245749
  CVE-2025-38154).
- bpf, sockmap: Fix data lost during EAGAIN retries (bsc#1245749
  CVE-2025-38154).
- commit bc1361f

- bpf: Fix memory leak in bpf_core_apply (git-fixes).
- commit 44b4ba3

- bpf/selftests: Check errno when percpu map value size exceeds
  (git-fixes).
- bpf: Check percpu map value size first (git-fixes).
- commit 81feacb

- bpftool: Fix undefined behavior caused by shifting into the
  sign bit (git-fixes).
- commit 9363920

- ipc: fix to protect IPCS lookups using RCU (CVE-2025-38212
  bsc#1246029).
- commit 9ff5b2e

- calipso: unlock rcu before returning -EAFNOSUPPORT
  (CVE-2025-38147 bsc#1245768).
- calipso: Don't call calipso functions for AF_INET sk
  (CVE-2025-38147 bsc#1245768).
- commit 74ee184

- ucsi_operations: add stubs for all operations (git-fixes).
- commit 1e9baf6

- drm/amd/display: Don't treat wb connector as physical in (bsc#1245654 CVE-2025-38098)
- commit 277f764

- x86/fred: Fix system hang during S4 resume with FRED enabled (bsc#1245084 CVE-2025-38047).
- commit 77102ae

- net/smc: Fix lookup of netdev by using ib_device_get_netdev()
  (git-fixes bsc#1246217).
- commit a5383eb

- selftests/bpf: Add tests for iter next method returning valid
  pointer (git-fixes).
- bpf: Make the pointer returned by iter next method valid
  (git-fixes).
- commit fcdc4ee

- hisi_acc_vfio_pci: bugfix live migration function without VF
  device driver (CVE-2025-38283 bsc#1246273).
- configfs-tsm-report: Fix NULL dereference of tsm_ops
  (CVE-2025-38210 bsc#1246020).
- commit eef28a4

- kasan: remove kasan_find_vm_area() to prevent possible deadlock
  (git-fixes).
- maple_tree: fix mt_destroy_walk() on root leaf node (git-fixes).
- commit aaacc92

- drm/imagination: Fix kernel crash when hard resetting the GPU
  (git-fixes).
- drm/xe/pm: Correct comment of xe_pm_set_vram_threshold()
  (git-fixes).
- drm/xe/bmg: fix compressed VRAM handling (git-fixes).
- Revert &amp;quot;drm/xe/xe2: Enable Indirect Ring State support for Xe2&amp;quot;
  (git-fixes).
- drm/xe: Allocate PF queue size on pow2 boundary (git-fixes).
- drm/xe/pf: Clear all LMTT pages on alloc (git-fixes).
- wifi: mac80211: fix non-transmitted BSSID profile search
  (git-fixes).
- commit ec1cfba

- drm/tegra: nvdec: Fix dma_alloc_coherent error check
  (git-fixes).
- nbd: fix uaf in nbd_genl_connect() error path (git-fixes).
- can: m_can: m_can_handle_lost_msg(): downgrade msg lost in rx
  message to debug level (git-fixes).
- net: phy: microchip: limit 100M workaround to link-down events
  on LAN88xx (git-fixes).
- wifi: mt76: mt7925: Fix null-ptr-deref in mt7925_thermal_init()
  (git-fixes).
- wifi: mt76: mt7925: fix invalid array index in ssid assignment
  during hw scan (git-fixes).
- wifi: mt76: mt7925: fix the wrong config for tx interrupt
  (git-fixes).
- wifi: zd1211rw: Fix potential NULL pointer dereference in
  zd_mac_tx_to_dev() (git-fixes).
- commit 067b949

- xfs: fix off-by-one error in fsmap's end_daddr usage
  (bsc#1235837).
- commit 919d943

- hisi_acc_vfio_pci: fix XQE dma address error (CVE-2025-38158
  bsc#1245750).
- commit 373ef61

- i40e: fix MMIO write access to an invalid page in i40e_clear_hw
  (CVE-2025-38200 bsc#1246045).
- net: cadence: macb: Fix a possible deadlock in macb_halt_tx
  (CVE-2025-38094 bsc#1245649).
- commit 45301b8

- kABI workaround for fw_attributes_class_get() (stable-fixes).
- commit 8322949

- drm/xe/guc: Dead CT helper (stable-fixes).
- Refresh
  patches.suse/drm-xe-Fix-early-wedge-on-GuC-load-failure.patch.
- commit 169fbda

- platform/x86: dell-wmi-sysman: Fix class device unregistration
  (git-fixes).
- platform/x86: think-lmi: Fix class device unregistration
  (git-fixes).
- platform/x86: hp-bioscfg: Fix class device unregistration
  (git-fixes).
- usb: dwc3: Abort suspend on soft disconnect failure (git-fixes).
- drm/xe/guc: Explicitly exit CT safe mode on unwind (git-fixes).
- drm/xe: move DPT l2 flush to a more sensible place (git-fixes).
- drm/xe: Move DSB l2 flush to a more sensible place (git-fixes).
- platform/x86: dell-sysman: Directly use
  firmware_attributes_class (stable-fixes).
- platform/x86: hp-bioscfg: Directly use firmware_attributes_class
  (stable-fixes).
- platform/x86: think-lmi: Directly use firmware_attributes_class
  (stable-fixes).
- platform/x86: firmware_attributes_class: Simplify API
  (stable-fixes).
- platform/x86: firmware_attributes_class: Move include
  linux/device/class.h (stable-fixes).
- drm/xe: Allow bo mapping on multiple ggtts (stable-fixes).
- drm/xe: add interface to request physical alignment for buffer
  objects (stable-fixes).
- drm/xe: Fix DSB buffer coherency (stable-fixes).
- drm/xe: Replace double space with single space after comma
  (stable-fixes).
- platform/x86: make fw_attr_class constant (stable-fixes).
- commit 5fd840c

- x86/CPU/AMD: Terminate the erratum_1386_microcode array (git-fixes).
- Refresh
  patches.suse/x86-cpu-Move-AMD-erratum-1386-table-over-to-x86_cpu_id.patch.
- commit 1e0fa3d

- x86/cpu: Avoid running off the end of an AMD erratum table (git-fixes).
- commit 9861130

- platform/x86: think-lmi: Create ksets consecutively
  (stable-fixes).
- Refresh
  patches.suse/platform-x86-think-lmi-Fix-kobject-cleanup.patch.
- commit 5072bed

- net: phy: smsc: Fix link failure in forced mode with Auto-MDIX
  (git-fixes).
- net: phy: smsc: Fix Auto-MDIX configuration when disabled by
  strap (git-fixes).
- Bluetooth: hci_event: Fix not marking Broadcast Sink BIS as
  connected (git-fixes).
- Bluetooth: hci_sync: Fix not disabling advertising instance
  (git-fixes).
- usb: xhci: quirk for data loss in ISOC transfers (stable-fixes).
- Logitech C-270 even more broken (stable-fixes).
- Input: xpad - support Acer NGR 200 Controller (stable-fixes).
- dma-buf: fix timeout handling in dma_resv_wait_timeout v2
  (stable-fixes).
- mmc: sdhci: Add a helper function for dump register in dynamic
  debug mode (stable-fixes).
- ACPICA: Refuse to evaluate a method if arguments are missing
  (stable-fixes).
- mtd: spinand: fix memory leak of ECC engine conf (stable-fixes).
- ASoC: amd: yc: update quirk data for HP Victus (stable-fixes).
- ASoC: amd: yc: Add quirk for MSI Bravo 17 D7VF internal mic
  (stable-fixes).
- ALSA: sb: Force to disable DMAs once when DMA mode is changed
  (stable-fixes).
- ALSA: sb: Don't allow changing the DMA mode during operations
  (stable-fixes).
- drm/msm: Fix another leak in the submit error path
  (stable-fixes).
- drm/msm: Fix a fence leak in submit error path (stable-fixes).
- regulator: fan53555: add enable_time support and soft-start
  times (stable-fixes).
- wifi: ath6kl: remove WARN on bad firmware input (stable-fixes).
- wifi: mac80211: drop invalid source address OCB frames
  (stable-fixes).
- ata: pata_cs5536: fix build on 32-bit UML (stable-fixes).
- platform/x86/amd/pmc: Add PCSpecialist Lafite Pro V 14M to
  8042 quirks list (stable-fixes).
- Revert &amp;quot;drm/i915/gem: Allow EXEC_CAPTURE on recoverable contexts
  on DG1&amp;quot; (stable-fixes).
- wifi: mac80211: Add link iteration macro for link data
  (stable-fixes).
- wifi: mac80211: chan: chandef is non-NULL for reserved
  (stable-fixes).
- commit 66a4a55

- net: clear the dst when changing skb protocol (bsc#1245954
  CVE-2024-49861).
- commit eed1284

- usb: typec: ucsi: Set orientation as none when connector is
  unplugged (git-fixes).
- commit 9b64a84

- usb: typec: ucsi: glink: fix off-by-one in connector_status
  (git-fixes).
- commit 63d64a6

- coresight: prevent deactivate active config while enabling
  the config (CVE-2025-38131 bsc#1245677).
- coresight: holding cscfg_csdev_lock while removing cscfg from
  csdev (CVE-2025-38132 bsc#1245679).
- commit f8db328

- x86/process: Move the buffer clearing before MONITOR (bsc#1238896 CVE-2024-36350 CVE-2024-36357 CVE-2024-36348 CVE-2024-36349).
- commit 4a10507

- KVM: SVM: Advertise TSA CPUID bits to guests (bsc#1238896 CVE-2024-36350 CVE-2024-36357 CVE-2024-36348 CVE-2024-36349).
- Refresh
  patches.suse/x86-bugs-Add-a-Transient-Scheduler-Attacks-mitigation.patch.
- commit 09387da

- x86/cpu: Move AMD erratum 1386 table over to 'x86_cpu_id' (git-fixes).
- commit ba3af9a

- x86/CPU/AMD: Improve the erratum 1386 workaround (git-fixes).
- commit 4c8067b

- x86/cpu: Replace PEBS use of 'x86_cpu_desc' use with 'x86_cpu_id' (git-fixes).
- commit 32b283a

- x86/cpu: Expose only stepping min/max interface (git-fixes).
- Refresh
  patches.suse/x86-its-Add-vmexit-option-to-skip-mitigation-on-some-CPUs.patch.
- Refresh
  patches.suse/x86-its-Enumerate-Indirect-Target-Selection-ITS-bug.patch.
- commit 4c83b07

- x86/cpu: Introduce new microcode matching helper (git-fixes).
- commit e25965b

- x86/bugs: Add a Transient Scheduler Attacks mitigation (bsc#1238896 CVE-2024-36350 CVE-2024-36357 CVE-2024-36348 CVE-2024-36349).
- Update config files.
- commit ed9e719

- ACPI: PRM: Reduce unnecessary printing to avoid user confusion
  (bsc#1246122).
- commit f060328

- usb: typec: ucsi: Fix busy loop on ASUS VivoBooks (git-fixes).
- usb: typec: ucsi: Fix the partner PD revision (git-fixes).
- commit cb5cfe6

- restore UCSI_CONNECTOR_RESET_HARD definition (git-fixes).
- commit 3a50af7

- series.txt: Sort cBPF security patches
- commit adce8c6

- usb: typec: ucsi: Add DATA_RESET option of Connector Reset
  command (git-fixes).
- commit ebc917a

- pinctrl: amd: Clear GPIO debounce for suspend (git-fixes).
- pinctrl: qcom: msm: mark certain pins as invalid for interrupts
  (git-fixes).
- commit 7a0a421

- Re-enable qmi_wwan for arm64 (bsc#1246113)
- commit d07961b

- efi/mokvar-table: Avoid repeated map/unmap of the same page
  (bsc#1240323 CVE-2025-21872).
- commit a16e799

- usb: typec: ucsi: move ucsi_acknowledge() from ucsi_read_error()
  (git-fixes).
- commit 9793505

- kabi: restore encap_sk in struct xfrm_state (CVE-2025-38097
  bsc#1245660).
- espintcp: remove encap socket caching to avoid reference leak
  (CVE-2025-38097 bsc#1245660).
- commit 94f2735

- net: lan743x: fix potential out-of-bounds write in
  lan743x_ptp_io_event_clock_get() (CVE-2025-38183 bsc#1246006).
- commit 0eb12cd

- net_sched: sch_sfq: fix a potential crash on gso_skb handling
  (CVE-2025-38115 bsc#1245689).
- commit 6a4ffd3

- usb: typec: ucsi_acpi: Add LG Gram quirk (git-fixes).
- commit da7fb49

- usb: typec: ucsi: don't retrieve PDOs if not supported
  (git-fixes).
- commit d303a5e

- usb: typec: ucsi: Delay alternate mode discovery (git-fixes).
- commit b7ba22d

- usb: typec: Update sysfs when setting ops (git-fixes).
- commit b336d78

- usb: typec: ucsi: glink: increase max ports for x1e80100
  (git-fixes).
- commit 31de9c9

- ucsi_ops: adapt update_connector to kABI consistency
  (git-fixes).
- usb: typec: ucsi: add update_connector callback (git-fixes).
- blacklist.conf: needed for infrastructure. kABI fix added
- Refresh
  patches.kabi/struct-ucsi_operations-use-padding-for-new-operation.patch.
- Refresh patches.suse/paddings-add-paddings-to-TypeC-stuff.patch.
- commit a70b9ee

- ALSA: usb-audio: Kill timer properly at removal (CVE-2025-38105
  bsc#1245682).
- commit 2bf6099

- x86/process: Move the buffer clearing before MONITOR (bsc#1238896 CVE-2024-36350 CVE-2024-36357 CVE-2024-36348 CVE-2024-36349).
- commit 9303368

- usb: typec: ucsi: glink: use typec_set_orientation (git-fixes).
- Refresh
  patches.suse/soc-qcom-pmic_glink-Fix-race-during-initialization.patch.
- Refresh
  patches.suse/usb-typec-ucsi-glink-fix-child-node-release-in-probe.patch.
- commit b105e3e

- KVM: SVM: Advertise TSA CPUID bits to guests (bsc#1238896 CVE-2024-36350 CVE-2024-36357 CVE-2024-36348 CVE-2024-36349).
- commit 67b316f

- Bluetooth: btusb: Fix regression in the initialization of fake
  Bluetooth controllers (CVE-2025-38099 bsc#1245671).
- Bluetooth: Disable SCO support if READ_VOICE_SETTING is
  unsupported/broken (CVE-2025-38099 bsc#1245671).
- Bluetooth: Add quirk for broken READ_PAGE_SCAN_TYPE
  (CVE-2025-38099 bsc#1245671).
- Bluetooth: Add quirk for broken READ_VOICE_SETTING
  (CVE-2025-38099 bsc#1245671).
- commit 254e65a

- jfs: fix array-index-out-of-bounds read in add_missing_indices
  (bsc#1245983 CVE-2025-38204).
- commit 65d9d7f

- usb: typec: ucsi_glink: drop NO_PARTNER_PDOS quirk for sm8550 /
  sm8650 (git-fixes).
- commit 380eca4

- usb: typec: ucsi_glink: enable the UCSI_DELAY_DEVICE_PDOS
  quirk on qcm6490 (git-fixes).
- commit 3de42d7

- usb: typec: ucsi_glink: enable the UCSI_DELAY_DEVICE_PDOS quirk
  (git-fixes).
- commit 2a3ce34

- usb: typec: ucsi_glink: rework quirks implementation
  (git-fixes).
- commit b78f907

- usb: typec: ucsi: support delaying GET_PDOS for device
  (git-fixes).
- Refresh patches.kabi/struct-usci-hide-additional-member.patch.
- commit 95f3b03

- rpm/mkspec: Fix missing kernel-syms-rt creation (bsc#1244337)
- commit 630f139

- usb: typec: ucsi: extract code to read PD caps (git-fixes).
- commit ebc6c46

- usb: typec: ucsi: properly register partner's PD device
  (git-fixes).
- commit 7b95fc1

- usb: typec: ucsi: fix UCSI on SM8550 &amp;amp; SM8650 Qualcomm devices
  (git-fixes).
- commit c40444f

- usb: typec: ucsi: Add qcm6490-pmic-glink as needing PDOS quirk
  (git-fixes).
- commit 46f5c2a

- ucsi_ccg: Refine the UCSI Interrupt handling (git-fixes).
- commit e97f436

- exfat: fix double free in delayed_free (bsc#1246073
  CVE-2025-38206).
- commit 38c1950

- usb: typec: ucsi: Get PD revision for partner (git-fixes).
- commit a80ec70

- x86/bugs: Add a Transient Scheduler Attacks mitigation (bsc#1238896 CVE-2024-36350 CVE-2024-36357 CVE-2024-36348 CVE-2024-36349).
- Update config files.
- commit 45d6a14

- ASoC: fsl_sai: Force a software reset when starting in consumer
  mode (git-fixes).
- commit d1c8181

- pwm: mediatek: Ensure to disable clocks in error path
  (git-fixes).
- ASoC: cs35l56: probe() should fail if the device ID is not
  recognized (git-fixes).
- ASoC: fsl_asrc: use internal measured ratio for non-ideal
  ratio mode (git-fixes).
- commit 5b2c070

- dm-raid: fix variable in journal device check (git-fixes).
- commit 7e51a3f

- dm-verity: fix a memory leak if some arguments are specified
  multiple times (git-fixes).
- commit 18c3347

- dm-mirror: fix a tiny race condition (git-fixes).
- commit 6d6aef6

- dm-flakey: make corrupting read bios work (git-fixes).
- commit bbf383a

- dm-flakey: error all IOs when num_features is absent
  (git-fixes).
- commit d4d758e

- dm: free table mempools if not used in __bind (git-fixes).
- commit 6abd700

- dm: don't change md if dm_table_set_restrictions() fails
  (git-fixes).
- commit 0d534aa

- dm: restrict dm device size to 2^63-512 bytes (git-fixes).
- commit 240dadc

- virtgpu: don't reset on shutdown (git-fixes).
- commit 82f42df

- kernel/fork: only call untrack_pfn_clear() on VMAs duplicated
  for fork() (git-fix for CVE-2025-22090 bsc#1241537).
- commit 852f7f4

- netfilter: nft_set_pipapo: prevent overflow in lookup table
  allocation (CVE-2025-38162 bsc#1245752).
- commit c7520cc

- efi: Don't map the entire mokvar table to determine its size
  (bsc#1240323 CVE-2025-21872).
- commit aefffb0

- ucsi-glink: adapt to kABI consistency (git-fixes).
- usb: typec: ucsi: glink: move GPIO reading into connector_status
  callback (git-fixes).
- Refresh
  patches.suse/usb-typec-ucsi-Move-unregister-out-of-atomic-section.patch.
- commit 8ae6c79

- vhost-scsi: protect vq-&amp;gt;log_used with vq-&amp;gt;mutex (CVE-2025-38074
  bsc#1244735).
- commit 29ecfb7

- struct ucsi_operations: use padding for new operation
  (git-fixes).
- commit 5fe6bda

- crypto: ecdsa - Harden against integer overflows in
  DIV_ROUND_UP() (CVE-2025-37984 bsc#1243669).
- commit 4115893

- virtio: break and reset virtio devices on device_shutdown()
  (CVE-2025-38064 bsc#1245201).
- commit 1ef712f

- usb: typec: ucsi: add callback for connector status updates
  (git-fixes).
- blacklist.conf: needed as infrastructure. kABI workaround following
- Refresh patches.suse/paddings-add-paddings-to-TypeC-stuff.patch.
- Refresh
  patches.suse/usb-typec-ucsi-displayport-Fix-deadlock.patch.
- commit de5a5b0

- x86/mtrr: Rename mtrr_overwrite_state() to guest_force_mtrr_state() (git-fixes).
- commit 676e3b6

- struct cdns: move new member to the end (git-fixes).
- commit 4384b08

- usb: cdnsp: Fix issue with resuming from L1 (git-fixes).
- commit c8b7c96

- net: dsa: clean up FDB, MDB, VLAN entries on unbind
  (CVE-2025-37864 bsc#1242965).
- commit d1f463e

- NFSv4: Always set NLINK even if the server doesn't support it
  (git-fixes).
- commit 84005c5

- NFSv4.2: fix listxattr to return selinux security label
  (git-fixes).
- commit 0319baa

- NFSv4: xattr handlers should check for absent nfs filehandles
  (git-fixes).
- commit 80ac5a3

- sunrpc: don't immediately retransmit on seqno miss (git-fixes).
- commit ceebf6f

- fs/jfs: consolidate sanity checking in dbMount (git-fixes).
- commit 5c4bc1b

- objtool: Ignore end-of-section jumps for KCOV/GCOV (git-fixes).
- commit e383ffb

- objtool: Silence more KCOV warnings, part 2 (git-fixes).
- commit ddae9d6

- netfilter: nf_set_pipapo_avx2: fix initial map fill (git-fixes
  CVE-2024-57947 bsc#1236333).
- commit cedcb24

- drm/amdgpu: Add kicker device detection (stable-fixes).
- commit d4202db

- drm/amdkfd: Fix instruction hazard in gfx12 trap handler
  (stable-fixes).
- commit bcd44b6

- wifi: mac80211: finish link init before RCU publish (git-fixes).
- drm/xe: Fix early wedge on GuC load failure (git-fixes).
- drm/amdgpu: Fix SDMA UTC_L1 handling during start/stop sequences
  (stable-fixes).
- drm/amd/display: Check dce_hwseq before dereferencing it
  (stable-fixes).
- drm/amd/display: Fix RMCM programming seq errors (stable-fixes).
- drm/amd/display: Fix mpv playback corruption on weston
  (stable-fixes).
- drm/i915/dsi: Fix off by one in BXT_MIPI_TRANS_VTOTAL
  (stable-fixes).
- drm/amd/display: Correct non-OLED pre_T11_delay (stable-fixes).
- drm/xe/guc_submit: add back fix (git-fixes).
- drm/amdgpu: seq64 memory unmap uses uninterruptible lock
  (stable-fixes).
- Revert &amp;quot;drm/i915/gem: Allow EXEC_CAPTURE on recoverable contexts
  on DG1&amp;quot; (stable-fixes).
- wifi: mac80211: Create separate links for VLAN interfaces
  (stable-fixes).
- wifi: mac80211: Add link iteration macro for link data
  (stable-fixes).
- drm/xe: Fix taking invalid lock on wedge (stable-fixes).
- drm/amdkfd: remove gfx 12 trap handler page size cap
  (stable-fixes).
- accel/ivpu: Remove copy engine support (stable-fixes).
- commit 934978c

- usb: typec: displayport: Fix potential deadlock (git-fixes).
- commit a45e2f9

- drm/bridge: ti-sn65dsi86: Add HPD for DisplayPort connector type
  (git-fixes).
- ASoC: amd: yc: Add DMI quirk for Lenovo IdeaPad Slim 5 15
  (stable-fixes).
- Bluetooth: L2CAP: Fix L2CAP MTU negotiation (stable-fixes).
- drm/amdkfd: Fix race in GWS queue scheduling (stable-fixes).
- ASoC: codecs: wcd9335: Fix missing free of regulator supplies
  (git-fixes).
- ALSA: hda: Ignore unsol events for cards being shut down
  (stable-fixes).
- ALSA: hda: Add new pci id for AMD GPU display HD audio
  controller (stable-fixes).
- usb: dwc2: also exit clock_gating when stopping udc while
  suspended (stable-fixes).
- usb: potential integer overflow in usbg_make_tpg()
  (stable-fixes).
- usb: common: usb-conn-gpio: use a unique name for usb connector
  device (stable-fixes).
- usb: Add checks for snprintf() calls in usb_alloc_dev()
  (stable-fixes).
- usb: cdc-wdm: avoid setting WDM_READ for ZLP-s (stable-fixes).
- usb: typec: displayport: Receive DP Status Update NAK request
  exit dp altmode (stable-fixes).
- usb: typec: mux: do not return on EOPNOTSUPP in {mux,
  switch}_set (stable-fixes).
- iio: pressure: zpa2326: Use aligned_s64 for the timestamp
  (stable-fixes).
- iio: adc: ad_sigma_delta: Fix use of uninitialized status_pos
  (stable-fixes).
- drm/scheduler: signal scheduled fence when kill job
  (stable-fixes).
- amd/amdkfd: fix a kfd_process ref leak (stable-fixes).
- drm/amdgpu: amdgpu_vram_mgr_new(): Clamp lpfn to total vram
  (stable-fixes).
- dmaengine: idxd: Check availability of workqueue allocated by
  idxd wq driver before using (stable-fixes).
- dmaengine: xilinx_dma: Set dma_device directions (stable-fixes).
- PCI: dwc: Make link training more robust by setting
  PORT_LOGIC_LINK_WIDTH to one lane (stable-fixes).
- leds: multicolor: Fix intensity setting while SW blinking
  (stable-fixes).
- mfd: max14577: Fix wakeup source leaks on device unbind
  (stable-fixes).
- hwmon: (pmbus/max34440) Fix support for max34451 (stable-fixes).
- drm/bridge: ti-sn65dsi86: make use of debugfs_init callback
  (stable-fixes).
- ASoC: codec: wcd9335: Convert to GPIO descriptors
  (stable-fixes).
- types: Complement the aligned types with signed 64-bit one
  (stable-fixes).
- ASoC: codecs: wcd9335: Handle nicer probe deferral and simplify
  with dev_err_probe() (stable-fixes).
- commit 9aa1e05

- i2c/designware: Fix an initialization issue (git-fixes).
- commit d80f186

- drm/v3d: Disable interrupts before resetting the GPU
  (git-fixes).
- drm/bridge: aux-hpd-bridge: fix assignment of the of_node
  (git-fixes).
- drm/amdkfd: Don't call mmput from MMU notifier callback
  (git-fixes).
- commit 8444f01

- powercap: intel_rapl: Do not change CLAMPING bit if ENABLE
  bit cannot be changed (git-fixes).
- regulator: gpio: Fix the out-of-bounds access to drvdata::gpiods
  (git-fixes).
- spi: spi-fsl-dspi: Clear completion counter before initiating
  transfer (git-fixes).
- platform/x86: think-lmi: Fix sysfs group cleanup (git-fixes).
- platform/x86: think-lmi: Fix kobject cleanup (git-fixes).
- platform/mellanox: mlxreg-lc: Fix logic error in power state
  check (git-fixes).
- platform/x86: dell-wmi-sysman: Fix WMI data block retrieval
  in sysfs callbacks (git-fixes).
- platform/mellanox: nvsw-sn2201: Fix bus number in adapter
  error message (git-fixes).
- platform/mellanox: mlxbf-pmc: Fix duplicate event ID for
  CACHE_DATA1 (git-fixes).
- platform/mellanox: mlxbf-tmfifo: fix vring_desc.len assignment
  (git-fixes).
- xhci: dbc: Flush queued requests before stopping dbc
  (git-fixes).
- xhci: dbctty: disable ECHO flag by default (git-fixes).
- xhci: Disable stream for xHC controller with XHCI_BROKEN_STREAMS
  (git-fixes).
- usb: typec: altmodes/displayport: do not index invalid
  pin_assignments (git-fixes).
- Revert &amp;quot;usb: xhci: Implement xhci_handshake_check_state()
  helper&amp;quot; (git-fixes).
- usb: xhci: Skip xhci_reset in xhci_resume if xhci is being
  removed (git-fixes).
- usb: gadget: u_serial: Fix race condition in TTY wakeup
  (git-fixes).
- usb: chipidea: udc: disconnect/reconnect from host when do
  suspend/resume (git-fixes).
- usb: cdnsp: do not disable slot for disabled slot (git-fixes).
- Input: iqs7222 - explicitly define number of external channels
  (git-fixes).
- Input: xpad - adjust error handling for disconnect (git-fixes).
- drm/exynos: fimd: Guard display clock control with runtime PM
  calls (git-fixes).
- drm/exynos: exynos7_drm_decon: add vblank check in IRQ handling
  (git-fixes).
- drm/i915/gsc: mei interrupt top half should be in irq disabled
  context (git-fixes).
- drm/i915/gt: Fix timeline left held on VMA alloc error
  (git-fixes).
- drm/i915/selftests: Change mock_request() to return error
  pointers (git-fixes).
- drm/sched: Increment job count before swapping tail spsc queue
  (git-fixes).
- drm/bridge: panel: move prepare_prev_first handling to
  drm_panel_bridge_add_typed (git-fixes).
- drm/ttm: fix error handling in ttm_buffer_object_transfer
  (git-fixes).
- powercap: call put_device() on an error path in
  powercap_register_control_type() (stable-fixes).
- commit d0cb71b

- dm: fix unconditional IO throttle caused by REQ_PREFLUSH
  (CVE-2025-38063 bsc#1245202).
- commit 65fa7b7

- smb: client: Fix use-after-free in cifs_fill_dirent
  (CVE-2025-38051 bsc#1244750).
- commit 0f203bf

- cgroup,freezer: fix incomplete freezing when attaching tasks
  (bsc#1245789).
- commit 1970df7

- cgroup/cpuset: Extend kthread_is_per_cpu() check to all
  PF_NO_SETAFFINITY tasks (bsc#1241166).
- commit 86012b8

- objtool: Stop UNRET validation on UD2 (git-fixes).
- commit 0be0bc6

- objtool: Fix INSN_CONTEXT_SWITCH handling in validate_unret()
  (git-fixes).
- commit f1073e2

- objtool: Properly disable uaccess validation (git-fixes).
- commit b170301

- mm/memory-failure: fix handling of dissolved but not taken
  off from buddy pages (CVE-2024-39298 bsc#1227082).
  Refreshed:
  blacklist.conf: De-blacklist 8cf360b9d6a840700e06864236a01a883b34bbad
- commit 1d1f80f

- Bluetooth: HCI: Set extended advertising data synchronously
  (git-fixes).
- commit 70fcbcd

- rose: fix dangling neighbour pointers in rose_rt_device_down()
  (git-fixes).
- Bluetooth: MGMT: mesh_send: check instances prior disabling
  advertising (git-fixes).
- Bluetooth: MGMT: set_mesh: update LE scan interval and window
  (git-fixes).
- Bluetooth: hci_sync: revert some mesh modifications (git-fixes).
- Bluetooth: Prevent unintended pause by checking if advertising
  is active (git-fixes).
- net: usb: lan78xx: fix WARN in __netif_napi_del_locked on
  disconnect (git-fixes).
- commit 9d01c7e

- objtool: Silence more KCOV warnings (git-fixes).
- commit 246e013

- objtool: Fix error handling inconsistencies in check()
  (git-fixes).
- commit 2b123dd

- objtool: Ignore dangling jump table entries (git-fixes).
- commit 694bcb3

- objtool: Fix UNWIND_HINT_{SAVE,RESTORE} across basic blocks
  (git-fixes).
- commit 24df4fe

- x86/tdx: Fix __noreturn build warning around
  __tdx_hypercall_failed() (git-fixes).
- Refresh
  patches.suse/x86-virt-tdx-Define-TDX-supported-page-sizes-as-macros.patch.
- commit 741a25e

- objtool: Fix _THIS_IP_ detection for cold functions (git-fixes).
- commit b2539b9

- nvmet-tcp: don't restore null sk_state_change (bsc#1244801
  CVE-2025-38035).
- commit a1cc55e

- s390/pci: Fix stale function handles in error handling
  (git-fixes bsc#1245647).
- commit 1f0ecfd

- s390/pci: Do not try re-enabling load/store if device is
  disabled (git-fixes bsc#1245646).
- commit a7a5884

- NFSv4/pNFS: Fix a race to wake on NFS_LAYOUT_DRAIN (git-fixes).
- commit cbe692c

- nfs: Clean up /proc/net/rpc/nfs when nfs_fs_proc_net_init()
  fails (git-fixes).
- commit 29c2a95

- IB/mlx5: Fix potential deadlock in MR deregistration (git-fixes)
- commit a31c762

- RDMA/mlx5: Fix vport loopback for MPV device (git-fixes)
- commit 50aa3ad

- RDMA/mlx5: Fix CC counters query for MPV (git-fixes)
- commit 6fac6aa

- RDMA/mlx5: Fix HW counters query for non-representor devices (git-fixes)
- commit f645a5e

- RDMA/mlx5: reduce stack usage in mlx5_ib_ufile_hw_cleanup (git-fixes)
- commit 1e8906b

- RDMA/mlx5: Initialize obj_event-&amp;gt;obj_sub_list before xa_insert (git-fixes)
- commit 9bf32eb

- mtk-sd: reset host-&amp;gt;mrq on prepare_data() error (git-fixes).
- commit 85b8654

- Revert &amp;quot;mmc: sdhci: Disable SD card clock before changing
  parameters&amp;quot; (git-fixes).
- mtk-sd: Prevent memory corruption from DMA map failure
  (git-fixes).
- mtk-sd: Fix a pagefault in dma_unmap_sg() for not prepared data
  (git-fixes).
- mmc: core: sd: Apply BROKEN_SD_DISCARD quirk earlier
  (git-fixes).
- commit 4977a9e

- kABI workaround for xsk: Fix race condition in AF_XDP generic
  RX path (CVE-2025-37920 bsc#1243479).
- commit 2cbaa5f

- xsk: Fix race condition in AF_XDP generic RX path
  (CVE-2025-37920 bsc#1243479).
- commit b0fed9b

- bpf, sockmap: Fix sk_msg_reset_curr (git-fixes).
- commit 3936762

- scsi: s390: zfcp: Ensure synchronous unit_add (git-fixes
  bsc#1245599).
- commit 4cb28a8

- s390/pkey: Prevent overflow in size calculation for
  memdup_user() (git-fixes bsc#1245598).
- commit 458c9d8

- s390: Add z17 elf platform (LTC#214086 bsc#1245540).
- commit a338278

- netlink: specs: tc: replace underscores with dashes in names
  (git-fixes).
- netlink: specs: nfsd: replace underscores with dashes in names
  (git-fixes).
- ice: fix eswitch code memory leak in reset scenario (git-fixes).
- bnxt_en: Fix double invocation of
  bnxt_ulp_stop()/bnxt_ulp_start() (git-fixes).
- net/mlx5: HWS, fix missing ip_version handling in definer
  (git-fixes).
- e1000: Move cancel_work_sync to avoid deadlock (git-fixes).
- bonding: Correctly support GSO ESP offload (git-fixes).
- commit fca0d66

- net: pktgen: fix access outside of user given buffer in
  pktgen_thread_write() (CVE-2025-38061 bsc#1245440).
- commit 386f111

- net: tipc: fix refcount warning in tipc_aead_encrypt
  (CVE-2025-38052 bsc#1244749).
- net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done
  (CVE-2025-38052 bsc#1244749).
- commit 39309cf

- r8152: add vendor/device ID pair for Dell Alienware AW1022z
  (git-fixes).
- commit 9bd4e20

- perf/x86/intel: Fix segfault with PEBS-via-PT with sample_freq
  (CVE-2025-38055 bsc#1244747).
- commit 144da01

- net: vlan: don't propagate flags on open (CVE-2025-23163
  bsc#1242837).
- commit a49d71b

- rtc: cmos: use spin_lock_irqsave in cmos_interrupt (git-fixes).
- commit d8e756f

- add bug reference to existing hv_storvsc change (bsc#1245455).
- net: mana: Record doorbell physical address in PF mode (bsc#1244229).
- commit 1c553b0

- kernel-obs-qa: Do not depend on srchash when qemu emulation is used
  In this case the dependency is never fulfilled
  Fixes: 485ae1da2b88 (&amp;quot;kernel-obs-qa: Use srchash for dependency as well&amp;quot;)
- commit a840f87

- nfsd: nfsd4_spo_must_allow() must check this is a v4 compound
  request (git-fixes).
- commit 784f61d

- mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race
  (bsc#1245431).
- commit dd145d5

- netlink: specs: dpll: replace underscores with dashes in names
  (git-fixes).
- bnxt: properly flush XDP redirect lists (git-fixes).
- e1000e: set fixed clock frequency indication for Nahum 11 and
  Nahum 13 (git-fixes).
- net: ice: Perform accurate aRFS flow match (git-fixes).
- net/mlx5e: Fix leak of Geneve TLV option object (git-fixes).
- net/mlx5: Fix return value when searching for existing flow
  group (git-fixes).
- net/mlx5: Fix ECVF vports unload on shutdown flow (git-fixes).
- net/mlx5: Ensure fw pages are always allocated on same NUMA
  (git-fixes).
- i40e: retry VFLR handling if there is ongoing VF reset
  (git-fixes).
- i40e: return false from i40e_reset_vf if reset is in progress
  (git-fixes).
- gve: add missing NULL check for gve_alloc_pending_packet()
  in TX DQO (git-fixes).
- ice: fix rebuilding the Tx scheduler tree for large queue counts
  (git-fixes).
- ice: create new Tx scheduler nodes for new queues only
  (git-fixes).
- ice: fix Tx scheduler error handling in XDP callback
  (git-fixes).
- net/mlx4_en: Prevent potential integer overflow calculating Hz
  (git-fixes).
- gve: Fix RX_BUFFERS_POSTED stat to report per-queue fill_cnt
  (git-fixes).
- net/mlx5: Add error handling in mlx5_query_nic_vport_node_guid()
  (git-fixes).
- net/mlx5_core: Add error handling
  inmlx5_query_nic_vport_qkey_viol_cntr() (git-fixes).
- idpf: fix null-ptr-deref in idpf_features_check (CVE-2025-38053
  bsc#1244746).
- ice: Fix LACP bonds without SRIOV environment (git-fixes).
- ice: fix vf-&amp;gt;num_mac count with port representors (git-fixes).
- devlink: fix port dump cmd type (git-fixes).
- devlink: Fix referring to hw_addr attribute during state
  validation (git-fixes).
- netlink: fix potential sleeping issue in mqueue_flush_file
  (git-fixes).
- commit 6dccf5f

- mm/hugetlb: unshare page tables during VMA split, not before
  (bsc#1245431).
- commit bf8eb79

- mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race
  (bsc#1245431).
- commit 0b96583

- mm/hugetlb: unshare page tables during VMA split, not before
  (bsc#1245431).
- commit cdfa193

- serial: core: restore of_node information in sysfs (git-fixes).
- commit 6ac0cc6

- bpf: Add a possibly-zero-sized read test (git-fixes).
- bpf: Simplify checking size of helper accesses (git-fixes).
- commit 04f6dc5

- staging: rtl8723bs: Avoid memset() in aes_cipher() and
  aes_decipher() (git-fixes).
- serial: imx: Restore original RXTL for console to fix data loss
  (git-fixes).
- commit 652de47

- drm/amdgpu: csa unmap use uninterruptible lock (CVE-2025-38011
  bsc#1244729).
- commit d370e7c

- selftests/bpf: Fix prog numbers in test_sockmap (git-fixes).
- bpftool: Un-const bpf_func_info to fix it for llvm 17 and newer
  (git-fixes).
- commit fadce21

- bpf: fix order of args in call to bpf_map_kvcalloc (git-fixes).
- bpf: Harden __bpf_kfunc tag against linker kfunc removal
  (git-fixes).
- compiler_types.h: Define __retain for
  __attribute__((__retain__)) (git-fixes).
- powerpc/bpf: enforce full ordering for ATOMIC operations with
  BPF_FETCH (git-fixes).
- commit e32b4e5

- bpf: Fix potential integer overflow in resolve_btfids
  (git-fixes).
- commit 7ce99c9

- selftests/bpf: Fix a few tests for GCC related warnings
  (git-fixes).
- selftests/bpf: Change functions definitions to support GCC
  (git-fixes).
- selftests/bpf: Add CFLAGS per source file and runner
  (git-fixes).
- bpf: Disable some `attribute ignored' warnings in GCC
  (git-fixes).
- bpf: Avoid __hidden__ attribute in static object (git-fixes).
- selftests/bpf: Fix pointer arithmetic in test_xdp_do_redirect
  (git-fixes).
- commit 71918be

- bpftool: Mount bpffs on provided dir instead of parent dir
  (git-fixes).
- commit 1bba21b

- bpftool: Remove unnecessary source files from bootstrap version
  (git-fixes).
- bpf/lpm_trie: Inline longest_prefix_match for fastpath
  (git-fixes).
- commit 99d4fb6

- bpftool: Fix missing pids during link show (git-fixes).
- bpf: sockmap, updating the sg structure should also update curr
  (git-fixes).
- commit 2322e0e

- drm/xe/gt: Update handling of xe_force_wake_get return
  (stable-fixes).
- Refresh
  patches.suse/drm-xe-Fix-GT-for-each-engine-workarounds.patch.
- commit 2738ff8

- drm/xe: Process deferred GGTT node removals on device unwind
  (git-fixes).
- drm/xe/display: Add check for alloc_ordered_workqueue()
  (git-fixes).
- drm/amd: Adjust output for discovery error handling (git-fixes).
- drm/xe/bmg: Update Wa_16023588340 (git-fixes).
- drm/v3d: Avoid NULL pointer dereference in
  `v3d_job_update_stats()` (stable-fixes).
- PCI: Add ACS quirk for Loongson PCIe (stable-fixes).
- wifi: mt76: mt7925: introduce thermal protection (stable-fixes).
- wifi: mac80211: validate SCAN_FLAG_AP in scan request during
  MLO (stable-fixes).
- wifi: rtw89: 8922a: fix TX fail with wrong VCO setting
  (stable-fixes).
- wifi: iwlwifi: mvm: fix beacon CCK flag (stable-fixes).
- wireless: purelifi: plfxlc: fix memory leak in
  plfxlc_usb_wreq_asyn() (stable-fixes).
- wifi: ath12k: using msdu end descriptor to check for rx
  multicast packets (stable-fixes).
- ACPI: Add missing prototype for non CONFIG_SUSPEND/CONFIG_X86
  case (stable-fixes).
- drm/amdgpu: read back register after written for VCN v4.0.5
  (stable-fixes).
- wifi: rtw89: phy: add dummy C2H event handler for report of
  TAS power (stable-fixes).
- drm/xe: Wire up device shutdown handler (stable-fixes).
- commit 59cc8a5

- i2c: tiny-usb: disable zero-length read messages (git-fixes).
- i2c: robotfuzz-osif: disable zero-length read messages
  (git-fixes).
- drm/i915: fix build error some more (git-fixes).
- ALSA: hda/realtek: Fix built-in mic on ASUS VivoBook X507UAR
  (git-fixes).
- ALSA: usb-audio: Fix out-of-bounds read in
  snd_usb_get_audioformat_uac3() (git-fixes).
- ALSA: hda/realtek: enable headset mic on Latitude 5420 Rugged
  (stable-fixes).
- ALSA: usb-audio: Rename ALSA kcontrol PCM and PCM1 for the
  KTMicro sound card (stable-fixes).
- ALSA: hda/intel: Add Thinkpad E15 to PM deny list
  (stable-fixes).
- ata: pata_via: Force PIO for ATAPI devices on VT6415/VT6330
  (stable-fixes).
- drivers/rapidio/rio_cm.c: prevent possible heap overwrite
  (stable-fixes).
- watchdog: da9052_wdt: respect TWDMIN (stable-fixes).
- watchdog: fix watchdog may detect false positive of softlockup
  (stable-fixes).
- fbcon: Make sure modelist not set on unregistered console
  (stable-fixes).
- bus: fsl-mc: increase MC_CMD_COMPLETION_TIMEOUT_MS value
  (stable-fixes).
- i2c: designware: Invoke runtime suspend on quick slave
  re-registration (stable-fixes).
- i2c: npcm: Add clock toggle recovery (stable-fixes).
- pinctrl: armada-37xx: propagate error from
  armada_37xx_pmx_set_by_name() (stable-fixes).
- pinctrl: armada-37xx: propagate error from
  armada_37xx_gpio_get_direction() (stable-fixes).
- pinctrl: armada-37xx: propagate error from
  armada_37xx_pmx_gpio_set_direction() (stable-fixes).
- pinctrl: armada-37xx: propagate error from
  armada_37xx_gpio_get() (stable-fixes).
- pinctrl: mcp23s08: Reset all pins to input at probe
  (stable-fixes).
- software node: Correct a OOB check in
  software_node_get_reference_args() (stable-fixes).
- wifi: mt76: mt7996: drop fragments with multicast or broadcast
  RA (stable-fixes).
- wifi: mt76: mt7921: add 160 MHz AP for mt7922 device
  (stable-fixes).
- wifi: mt76: mt76x2: Add support for LiteOn WN4516R,WN4519R
  (stable-fixes).
- wifi: ath12k: fix macro definition HAL_RX_MSDU_PKT_LENGTH_GET
  (stable-fixes).
- wifi: ath12k: fix a possible dead lock caused by ab-&amp;gt;base_lock
  (stable-fixes).
- wifi: ath11k: Fix QMI memory reuse logic (stable-fixes).
- wifi: rtw89: leave idle mode when setting WEP encryption for
  AP mode (stable-fixes).
- wifi: mac80211: do not offer a mesh path if forwarding is
  disabled (stable-fixes).
- wifi: iwlwifi: pcie: make sure to lock rxq-&amp;gt;read (stable-fixes).
- wifi: mac80211_hwsim: Prevent tsf from setting if beacon is
  disabled (stable-fixes).
- wifi: ath12k: fix failed to set mhi state error during reboot
  with hardware grouping (stable-fixes).
- wifi: ath12k: fix link valid field initialization in the
  monitor Rx (stable-fixes).
- wifi: ath12k: fix incorrect CE addresses (stable-fixes).
- wifi: ath12k: Pass correct values of center freq1 and center
  freq2 for 160 MHz (stable-fixes).
- wifi: mac80211: VLAN traffic in multicast path (stable-fixes).
- wifi: iwlwifi: Add missing MODULE_FIRMWARE for Qu-c0-jf-b0
  (stable-fixes).
- usbnet: asix AX88772: leave the carrier control to phylink
  (stable-fixes).
- PM: runtime: fix denying of auto suspend in
  pm_suspend_timer_fn() (stable-fixes).
- ACPI: battery: negate current when discharging (stable-fixes).
- ACPICA: Avoid sequence overread in call to strncmp()
  (stable-fixes).
- ACPICA: utilities: Fix overflow check in vsnprintf()
  (stable-fixes).
- ACPICA: fix acpi parse and parseext cache leaks (stable-fixes).
- ACPICA: fix acpi operand cache leak in dswstate.c
  (stable-fixes).
- ACPI: bus: Bail out if acpi_kobj registration fails
  (stable-fixes).
- mmc: Add quirk to disable DDR50 tuning (stable-fixes).
- power: supply: bq27xxx: Retrieve again when busy (stable-fixes).
- power: supply: collie: Fix wakeup source leaks on device unbind
  (stable-fixes).
- ASoC: amd: yc: Add quirk for Lenovo Yoga Pro 7 14ASP9
  (stable-fixes).
- ASoC: tegra210_ahub: Add check to of_device_get_match_data()
  (stable-fixes).
- ASoC: tas2770: Power cycle amp on ISENSE/VSENSE change
  (stable-fixes).
- Input: sparcspkr - avoid unannotated fall-through
  (stable-fixes).
- commit 0dc7dde

- Update
  patches.suse/HID-uclogic-Add-NULL-check-in-uclogic_input_configur.patch
  (git-fixes CVE-2025-38007 bsc#1244938).
- Update
  patches.suse/RDMA-core-Fix-KASAN-slab-use-after-free-Read-in-ib_r.patch
  (git-fixes CVE-2025-38022 bsc#1245003).
- Update
  patches.suse/RDMA-rxe-Fix-slab-use-after-free-Read-in-rxe_queue_c.patch
  (git-fixes CVE-2025-38024 bsc#1245025).
- Update
  patches.suse/btrfs-avoid-NULL-pointer-dereference-if-no-valid-csu.patch
  (bsc#1243342 CVE-2025-38059 bsc#1244759).
- Update
  patches.suse/btrfs-avoid-NULL-pointer-dereference-if-no-valid-ext.patch
  (bsc#1236208 CVE-2025-21658).
- Update
  patches.suse/can-bcm-add-locking-for-bcm_op-runtime-updates.patch
  (git-fixes CVE-2025-38004 bsc#1244274).
- Update
  patches.suse/can-bcm-add-missing-rcu-read-protection-for-procfs-c.patch
  (git-fixes CVE-2025-38003 bsc#1244275).
- Update
  patches.suse/crypto-algif_hash-fix-double-free-in-hash_accept.patch
  (git-fixes CVE-2025-38079 bsc#1245217).
- Update
  patches.suse/crypto-lzo-Fix-compression-buffer-overrun.patch
  (stable-fixes CVE-2025-38068 bsc#1245210).
- Update
  patches.suse/dmaengine-idxd-Refactor-remove-call-with-idxd_cleanu.patch
  (git-fixes CVE-2025-38014 bsc#1244732).
- Update
  patches.suse/dmaengine-idxd-fix-memory-leak-in-error-handling-pat-46a5cca.patch
  (git-fixes CVE-2025-38015 bsc#1244789).
- Update
  patches.suse/dmaengine-ti-k3-udma-Add-missing-locking.patch
  (git-fixes CVE-2025-38005 bsc#1244727).
- Update
  patches.suse/drm-amd-display-Increase-block_sequence-array-size.patch
  (stable-fixes CVE-2025-38080 bsc#1244738).
- Update
  patches.suse/ext4-goto-right-label-out_mmap_sem-in-ext4_setattr.patch
  (bsc#1242556 CVE-2025-22120 bsc#1241592).
- Update
  patches.suse/firmware-arm_ffa-Set-dma_mask-for-ffa-devices.patch
  (stable-fixes CVE-2025-38043 bsc#1245081).
- Update patches.suse/media-cx231xx-set-device_caps-for-417.patch
  (stable-fixes CVE-2025-38044 bsc#1245082).
- Update
  patches.suse/net-handshake-Fix-handshake_req_destroy_test1.patch
  (git-fixes CVE-2024-26831 bsc#1223008).
- Update
  patches.suse/net-mlx5e-Disable-MACsec-offload-for-uplink-represen.patch
  (git-fixes CVE-2025-38020 bsc#1245001).
- Update patches.suse/net_sched-prio-fix-a-race-in-prio_tune.patch
  (git-fixes CVE-2025-38083 bsc#1245183).
- Update
  patches.suse/nfs-handle-failure-of-nfs_get_lock_context-in-unlock-path.patch
  (git-fixes CVE-2025-38023 bsc#1245004).
- Update patches.suse/orangefs-Do-not-truncate-file-size.patch
  (git-fixes CVE-2025-38065 bsc#1244906).
- Update
  patches.suse/padata-do-not-leak-refcount-in-reorder_work.patch
  (git-fixes CVE-2025-38031 bsc#1245046).
- Update
  patches.suse/phy-tegra-xusb-Use-a-bitmask-for-UTMI-pad-power-stat.patch
  (git-fixes CVE-2025-38010 bsc#1244996).
- Update
  patches.suse/platform-x86-dell-wmi-sysman-Avoid-buffer-overflow-i.patch
  (git-fixes CVE-2025-38077 bsc#1244736).
- Update
  patches.suse/regulator-max20086-fix-invalid-memory-access.patch
  (git-fixes CVE-2025-38027 bsc#1245042).
- Update
  patches.suse/s390-pci-Fix-duplicate-pci_dev_put-in-disable_slot-w.patch
  (git-fixes bsc#1244145 CVE-2025-37946 bsc#1243506).
- Update
  patches.suse/s390-pci-fix-potential-double-remove-of-hotplug-slot.patch
  (bsc#1244145 CVE-2024-56699 bsc#1235490).
- Update
  patches.suse/sched-numa-fix-memory-leak-due-to-the-overwritten-vma-numab_state.patch
  (git fixes (sched/numa) CVE-2024-56613 bsc#1244176).
- Update
  patches.suse/serial-mctrl_gpio-split-disable_ms-into-sync-and-no_.patch
  (git-fixes CVE-2025-38040 bsc#1245078).
- Update
  patches.suse/spi-rockchip-Fix-register-out-of-bounds-access.patch
  (stable-fixes CVE-2025-38081 bsc#1244739).
- Update
  patches.suse/usb-typec-ucsi-displayport-Fix-NULL-pointer-access.patch
  (git-fixes CVE-2025-37994 bsc#1243823).
- Update
  patches.suse/vhost-scsi-Fix-handling-of-multiple-calls-to-vhost_s.patch
  (git-fixes CVE-2025-22083 bsc#1241414).
- Update
  patches.suse/wifi-cfg80211-fix-out-of-bounds-access-during-multi-.patch
  (git-fixes CVE-2025-37973 bsc#1244172).
- Update patches.suse/wifi-iwlwifi-fix-debug-actions-order.patch
  (stable-fixes CVE-2025-38045 bsc#1245083).
- Update
  patches.suse/wifi-mac80211-Set-n_channels-after-allocating-struct.patch
  (git-fixes CVE-2025-38013 bsc#1244731).
- Update
  patches.suse/wifi-mt76-disable-napi-on-driver-removal.patch
  (git-fixes CVE-2025-38009 bsc#1244995).
- commit fee1c31

- Update
  patches.suse/ASoC-soc-pcm-don-t-use-soc_pcm_ret-on-.prepare-callb.patch
  (stable-fixes CVE-2024-58077 bsc#1239090).
- Update
  patches.suse/Bluetooth-btbcm-Fix-NULL-deref-in-btbcm_get_board_na.patch
  (git-fixes CVE-2024-57988 bsc#1237910).
- Update
  patches.suse/Bluetooth-btrtl-check-for-NULL-in-btrtl_setup_realte.patch
  (git-fixes CVE-2024-57987 bsc#1237905).
- Update
  patches.suse/RDMA-bnxt_re-Add-sanity-checks-on-rdev-validity.patch
  (bsc#1237200 CVE-2025-21901 bsc#1240579).
- Update patches.suse/RDMA-rtrs-Add-missing-deinit-call.patch
  (git-fixes CVE-2025-21805 bsc#1238741).
- Update
  patches.suse/amdkfd-properly-free-gang_ctx_bo-when-failed-to-init.patch
  (git-fixes CVE-2025-21842 bsc#1239063).
- Update
  patches.suse/cxl-mem-Fix-no-cxl_nvd-during-pmem-region-auto-assem.patch
  (jsc#PED-10836 CVE-2024-41085 bsc#1228478).
- Update
  patches.suse/cxl-pci-Skip-to-handle-RAS-errors-if-CXL.mem-device-.patch
  (jsc#PED-10836 CVE-2024-26762 bsc#1230337).
- Update
  patches.suse/drm-amd-display-Fix-invalid-context-error-in-dml-hel.patch
  (git-fixes CVE-2025-37965 bsc#1244174).
- Update
  patches.suse/drm-amdgpu-init-return-value-in-amdgpu_ttm_clear_buf.patch
  (git-fixes CVE-2025-21987 bsc#1240798).
- Update
  patches.suse/drm-amdkfd-Fix-NULL-Pointer-Dereference-in-KFD-queue.patch
  (git-fixes CVE-2025-21940 bsc#1240702).
- Update
  patches.suse/drm-i915-gt-Use-spin_lock_irqsave-in-interruptible-c.patch
  (git-fixes CVE-2025-21849 bsc#1239485).
- Update
  patches.suse/drm-imagination-avoid-deadlock-on-fence-release.patch
  (git-fixes CVE-2025-21911 bsc#1240589).
- Update
  patches.suse/drm-xe-hmm-Don-t-dereference-struct-page-pointers-wi.patch
  (git-fixes CVE-2025-21939 bsc#1240710).
- Update patches.suse/drm-xe-userptr-fix-EFAULT-handling.patch
  (git-fixes CVE-2025-21880 bsc#1240170).
- Update
  patches.suse/gpu-host1x-Fix-a-use-of-uninitialized-mutex.patch
  (git-fixes CVE-2025-21824 bsc#1238478).
- Update
  patches.suse/iommu-Fix-potential-memory-leak-in-iopf_queue_remove.patch
  (git-fixes CVE-2025-21770 bsc#1238495).
- Update
  patches.suse/media-intel-ipu6-remove-cpu-latency-qos-request-on-e.patch
  (git-fixes CVE-2024-58004 bsc#1238508).
- Update
  patches.suse/net-smc-do-not-leave-a-dangling-sk-pointer-in-__smc_create.patch
  (jsc#PED-10299 bsc#1241689 CVE-2024-50293 bsc#1233482).
- Update
  patches.suse/net-smc-fix-lacks-of-icsk_syn_mss-with-IPPROTO_SMC.patch
  (jsc#PED-10299 bsc#1241689 CVE-2024-50034 bsc#1231913).
- Update
  patches.suse/powerpc-pseries-iommu-Don-t-unset-window-if-it-was-n.patch
  (jsc#PED-10539 git-fixes CVE-2025-21713 bsc#1237887).
- Update
  patches.suse/wifi-ath12k-Fix-for-out-of-bound-access-error.patch
  (bsc#1240998 CVE-2024-58015 bsc#1238995).
- Update
  patches.suse/wifi-ath12k-fix-use-after-free-in-ath12k_dp_cc_clean.patch
  (bsc#1240998 CVE-2024-56541 bsc#1235064).
- Update
  patches.suse/wifi-iwlwifi-mvm-avoid-NULL-pointer-dereference-cf704a7.patch
  (git-fixes CVE-2024-58062 bsc#1238965).
- commit 0597d89

- HID: lenovo: Restrict F7/9/11 mode to compact keyboards only
  (git-fixes).
- HID: wacom: fix kobject reference count leak (git-fixes).
- HID: wacom: fix memory leak on sysfs attribute creation failure
  (git-fixes).
- HID: wacom: fix memory leak on kobject creation failure
  (git-fixes).
- wifi: mac80211: fix beacon interval calculation overflow
  (git-fixes).
- commit 8d2d6ad

- scsi: storvsc: Increase the timeouts to storvsc_timeout (git-fixes).
- net: mana: Add support for Multi Vports on Bare metal (bsc#1244229).
- scsi: storvsc: Don't report the host packet status as the hv status (git-fixes).
- commit cde971c

- btrfs: fix fsync of files with no hard links not persisting
  deletion (git-fixes).
- btrfs: remove end_no_trans label from btrfs_log_inode_parent()
  (git-fixes).
- btrfs: simplify condition for logging new dentries at
  btrfs_log_inode_parent() (git-fixes).
- commit 9370aa3

- btrfs: fix wrong start offset for delalloc space release during
  mmap write (git-fixes).
- commit 59b0f84

- btrfs: fix invalid data space release when truncating block
  in NOCOW mode (git-fixes).
- commit b11e8b5

- btrfs: fix qgroup reservation leak on failure to allocate
  ordered extent (git-fixes).
- commit e13d6e0

- ntp: Remove invalid cast in time offset math (git-fixes)
- commit 92649f3

- timekeeping: Fix bogus clock_was_set() invocation in (git-fixes)
- commit 17fecee

- ntp: Safeguard against time_constant overflow (git-fixes)
- commit fb90573

- ntp: Clamp maxerror and esterror to operating range (git-fixes)
- commit 947fc29

- clocksource: Fix brown-bag boolean thinko in (git-fixes)
- commit f65bb99

- clocksource: Make watchdog and suspend-timing multiplication (git-fixes)
- commit a87f573

- timekeeping: Fix cross-timestamp interpolation for non-x86 (git-fixes)
- commit 1a57489

- timekeeping: Fix cross-timestamp interpolation corner case (git-fixes)
- commit dc250ae

- timekeeping: Fix cross-timestamp interpolation on counter (git-fixes)
- commit 4e863aa

- Refresh
  patches.kabi/kabi-restore-layout-of-struct-mem_control.patch.
- commit 5049495

- kabi: restore layout of struct cgroup_subsys (bsc#1241166).
- commit 2014732

- cgroup/cpuset: Fix race between newly created partition and
  dying one (bsc#1241166).
- cgroup/cpuset: Don't allow creation of local partition over
  a remote one (bsc#1241166).
- commit 36dffbc

- fgraph: Still initialize idle shadow stacks when starting
  (git-fixes).
- commit 1697414

- tracing/eprobe: Fix to release eprobe when failed to add
  dyn_event (git-fixes).
- commit a8fd69f

- tracing: Fix cmp_entries_dup() to respect sort() comparison
  rules (git-fixes).
- commit f73056c

- tracing: Use atomic64_inc_return() in trace_clock_counter()
  (git-fixes).
- commit 23262fc

- trace/trace_event_perf: remove duplicate samples on the first
  tracepoint event (git-fixes).
- commit b4e63e6

- bpf: Force uprobe bpf program to always return 0 (git-fixes).
- commit 90effed

- uprobes: Use kzalloc to allocate xol area (git-fixes).
- Refresh
  patches.suse/uprobes-introduce-the-global-struct-vm_special_mapping-xol_mapping.patch.
- commit 30d8536

- bpf: abort verification if env-&amp;gt;cur_state-&amp;gt;loop_entry != NULL
  (CVE-2025-38060 bsc#1245155).
- Refresh patches.kabi/bpf-verifier-kABI-workarounds.patch.
- commit c80eca0

- selftests/bpf: check states pruning for deeply nested iterator
  (CVE-2025-38060 bsc#1245155).
- bpf: don't do clean_live_states when state-&amp;gt;loop_entry-&amp;gt;branches
  &amp;gt; 0 (CVE-2025-38060 bsc#1245155).
- commit f0d9333

- supported.conf: support firmware_attributes_class
  We added support for hp_bioscfg in commit 23a469a682d6 and the build now
  fails:
  The following unsupported modules are used by supported modules:
  firmware_attributes_class needed by hp_bioscfg
  So support firmware_attributes_class too.
- commit 939c58c

- vmxnet3: support higher link speeds from vmxnet3 v9
  (bsc#1244626).
- commit 0aa445e

- vmxnet3: correctly report gso type for UDP tunnels
  (bsc#1244626).
- commit 44584be

- vmxnet3: update MTU after device quiesce (bsc#1244626).
- commit 14400a7

- scsi: elx: efct: Fix memory leak in efct_hw_parse_filter()
  (git-fixes).
- commit 11611ac

- mm/memory_hotplug: fix memmap_on_memory sysfs value retrieval
  (git-fixes).
- commit e4e3ed3

- tracing: Fix compilation warning on arm32 (bsc#1243551).
- commit bc2f48d

- kABI fixes for struct memory_block changes
  (bsc#1235515,jsc#PED-12731).
- commit c5d4cff

- tracing: Fix oob write in trace_seq_to_buffer() (CVE-2025-37923
  bsc#1243551).
- commit ff6a777

- ata: libata-eh: Do not use ATAPI DMA for a device limited to
  PIO mode (stable-fixes).
- commit 07065f3

- bpf: copy_verifier_state() should copy 'loop_entry' field
  (CVE-2025-38060 bsc#1245155).
- Refresh patches.kabi/bpf-verifier-kABI-workarounds.patch.
- commit 815fadf

- selftests/bpf: test correct loop_entry update in
  copy_verifier_state (CVE-2025-38060 bsc#1245155).
- commit b2e3449

- tracing: Fix use-after-free in print_graph_function_flags
  during tracer switching (CVE-2025-22035 bsc#1241544).
- commit b6d43f4

- bpf: Fix deadlock between rcu_tasks_trace and event_mutex
  (CVE-2025-37884 bsc#1243060).
- commit 7f690ab

- truct dwc3 hide new member wakeup_pending_funcs (git-fixes).
- commit 84579a6

- kabi: restore layout of struct page_counter (jsc#PED-12551).
- commit ef34a22

- usb: dwc3: gadget: Make gadget_wakeup asynchronous (git-fixes).
- commit 39cb14b

- ucsi_debugfs_entry: hide signedness change (git-fixes).
- commit 154816e

- usb: typec: ucsi: fix Clang -Wsign-conversion warning
  (git-fixes).
- Refresh patches.suse/paddings-add-paddings-to-TypeC-stuff.patch.
- commit 40f2bc3

- dax: add a sysfs knob to control memmap_on_memory behavior (bsc#1235515,jsc#PED-12731).
- mm/memory_hotplug: export mhp_supports_memmap_on_memory() (bsc#1235515,jsc#PED-12731).
- commit 09f84d7

- Documentatiion/ABI: add ABI documentation for sys-bus-dax (bsc#1235515,jsc#PED-12731).
- commit 8ee67a8

- mm/memory_hotplug: split memmap_on_memory requests across memblocks (bsc#1235515,jsc#PED-12731).
- commit 08c671b

- mm/memory_hotplug: replace an open-coded kmemdup() in (bsc#1235515,jsc#PED-12731).
- commit d8a9dae

- mm/memory_hotplug: embed vmem_altmap details in memory block
  (bsc#1235515,jsc#PED-12731).
- Refresh
  patches.suse/mm-memory_hotplug-add-missing-mem_hotplug_lock.patch.
- Refresh
  patches.suse/mm-memory_hotplug-fix-error-handling-in-add_memory_r.patch.
- commit b3d81f3

- mm/memory_hotplug: support memmap_on_memory when memmap is
  not aligned to pageblocks (bsc#1235515,jsc#PED-12731).
- Refresh
  patches.suse/mm-memory_hotplug-fix-error-handling-in-add_memory_r.patch.
- commit e3abf57

- mm/memory_hotplug: allow architecture to override memmap on
  memory support check (bsc#1235515,jsc#PED-12731).
- commit b1ed4e9

- mm/memory_hotplug: allow memmap on memory hotplug request to
  fallback (bsc#1235515,jsc#PED-12731).
- mm/memory_hotplug: simplify ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE
  kconfig (bsc#1235515,jsc#PED-12731).
- commit e613057

- hwmon: corsair-psu: add USB id of HX1200i Series 2023 psu
  (git-fixes).
- commit b5678d7

- net: phy: move phy_link_change() prior to mdio_bus_phy_may_suspend() (bsc#1243538)
- commit 416e192

- hwmon: (peci/dimmtemp) Do not provide fake thresholds data
  (git-fixes).
- hwmon: (nct6775): Actually make use of the HWMON_NCT6775 symbol
  namespace (git-fixes).
- commit 53b0cf2

- Update reference for patches.suse/net_sched-sch_sfq-use-a-temporary-work-area-for-vali.patch (bsc#1242504)
- commit 8730da1

- s390/tty: Fix a potential memory leak bug (git-fixes
  bsc#1245228).
- commit e4f3ff4

- s390/pci: Fix __pcilg_mio_inuser() inline assembly (git-fixes
  bsc#1245226).
- commit 7cf700b

- ceph: fix memory leaks in __ceph_sync_read() (git-fixes).
- Refresh
  patches.suse/ceph-improve-error-handling-and-short-overflow-read-.patch.
- commit 04880f5

- ceph: allocate sparse_ext map only for sparse reads (git-fixes).
- commit e7c7fa7

- ceph: Fix incorrect flush end position calculation (git-fixes).
- commit 626f897

- KVM: s390: rename PROT_NONE to PROT_TYPE_DUMMY (git-fixes
  bsc#1245225).
- commit 7cc3455

- iommu/amd: Fix potential buffer overflow in  parse_ivrs_acpihid
  (CVE-2025-37927 bsc#1243620).
- commit 4916f47

- nvme-fc: do not reference lsrsp after failure (bsc#1245193).
- nvmet-fcloop: don't wait for lport cleanup (bsc#1245193).
- nvmet-fcloop: add missing fcloop_callback_host_done
  (bsc#1245193).
- nvmet-fc: take tgtport refs for portentry (bsc#1245193).
- nvmet-fc: free pending reqs on tgtport unregister (bsc#1245193).
- nvmet-fcloop: drop response if targetport is gone (bsc#1245193).
- nvmet-fcloop: allocate/free fcloop_lsreq directly (bsc#1245193).
- nvmet-fcloop: prevent double port deletion (bsc#1245193).
- nvmet-fcloop: access fcpreq only when holding reqlock
  (bsc#1245193).
- nvmet-fcloop: update refs on tfcp_req (bsc#1245193).
- nvmet-fcloop: refactor fcloop_delete_local_port (bsc#1245193).
- nvmet-fcloop: refactor fcloop_nport_alloc and track lport
  (bsc#1245193).
- nvmet-fcloop: remove nport from list on last user (bsc#1245193).
- nvmet-fcloop: track ref counts for nports (bsc#1245193).
- commit 20104c4

- Remove host-memcpy-hack.h
  This might have been usefult at some point but we have more things that
  depend on specific library versions today.
- commit 0396c23

- Remove compress-vmlinux.sh
  /usr/lib/rpm/brp-suse.d/brp-99-compress-vmlinux was added in
  pesign-obs-integration during SLE12 RC. This workaround can be removed.
- commit 19caac0

- Remove try-disable-staging-driver
  The config for linux-next is autogenerated from master config, and
  defaults filled for missing options. This is unlikely to enable any
  staging driver in the first place.
- commit a6f21ed

- nvme: always punt polled uring_cmd end_io work to task_work
  (git-fixes).
- nvme: fix implicit bool to flags conversion (git-fixes).
- commit 36de06b

- platform/x86: hp-bioscfg: Removed needless asm-generic
  (jsc#PED-13019).
- platform/x86: hp-bioscfg: Remove unused obj in
  hp_add_other_attributes() (jsc#PED-13019).
- platform/x86: hp-bioscfg: Fix error handling in
  hp_add_other_attributes() (jsc#PED-13019).
- platform/x86: hp-bioscfg: move mutex_lock() down in
  hp_add_other_attributes() (jsc#PED-13019).
- platform/x86: hp-bioscfg: Simplify return check in
  hp_add_other_attributes() (jsc#PED-13019).
- platform/x86: hp-bioscfg: Annotate struct bios_args with
  __counted_by (jsc#PED-13019).
- platform/x86: hp-bioscfg: Fix reference leak (jsc#PED-13019).
- platform/x86: hp-bioscfg: Update steps order list elements
  are evaluated (jsc#PED-13019).
- platform/x86: hp-bioscfg: Use kmemdup() to replace kmalloc +
  memcpy (jsc#PED-13019).
- platform/x86: hp-bioscfg: Remove duplicate use of variable in
  inner loop (jsc#PED-13019).
- platform/x86: hp-bioscfg: Change how password encoding size
  is evaluated (jsc#PED-13019).
- platform/x86: hp-bioscfg: Change how enum possible values size
  is evaluated (jsc#PED-13019).
- platform/x86: hp-bioscfg: Change how order list size is
  evaluated (jsc#PED-13019).
- platform/x86: hp-bioscfg: Change how prerequisites size is
  evaluated (jsc#PED-13019).
- platform/x86: hp-bioscfg: Replace the word HACK from source code
  (jsc#PED-13019).
- platform/x86: hp-bioscfg: Fix uninitialized variable errors
  (jsc#PED-13019).
- platform/x86: hp-bioscfg: Fix memory leaks in attribute packages
  (jsc#PED-13019).
- platform/x86: hp-bioscfg: fix error reporting in
  hp_add_other_attributes() (jsc#PED-13019).
- platform/x86: hp-bioscfg: prevent a small buffer overflow
  (jsc#PED-13019).
- platform/x86: hp-bioscfg: fix a signedness bug in
  hp_wmi_perform_query() (jsc#PED-13019).
- platform/x86: hp-bioscfg: Makefile (jsc#PED-13019).
- Update config files. (HP_BIOSCFG=m)
- supported.conf: add it
- platform/x86: hp-bioscfg: surestart-attributes (jsc#PED-13019).
- platform/x86: hp-bioscfg: string-attributes (jsc#PED-13019).
- platform/x86: hp-bioscfg: spmobj-attributes (jsc#PED-13019).
- platform/x86: hp-bioscfg: passwdobj-attributes (jsc#PED-13019).
- platform/x86: hp-bioscfg: order-list-attributes (jsc#PED-13019).
- platform/x86: hp-bioscfg: int-attributes (jsc#PED-13019).
- platform/x86: hp-bioscfg: enum-attributes (jsc#PED-13019).
- platform/x86: hp-bioscfg: biosattr-interface (jsc#PED-13019).
- platform/x86: hp-bioscfg: bioscfg (jsc#PED-13019).
- platform/x86: hp-bioscfg: bioscfg-h (jsc#PED-13019).
- commit 9e16bbb

- net/tls: fix kernel panic when alloc_page failed (CVE-2025-38018
  bsc#1244999).
- commit 1124110

- espintcp: fix skb leaks (CVE-2025-38057 bsc#1244862).
- commit dffbfd5

- nvme: fix command limits status code (git-fixes).
- nvme-pci: add NVME_QUIRK_NO_DEEPEST_PS quirk for SOLIDIGM P44
  Pro (git-fixes).
- nvme-pci: add quirks for WDC Blue SN550 15b7:5009 (git-fixes).
- nvme-pci: add quirks for device 126f:1001 (git-fixes).
- commit 990928c

- sunrpc: handle SVC_GARBAGE during svc auth processing as auth
  error (git-fixes).
- commit afe6d07

- x86/fred/signal: Prevent immediate repeat of single step trap on return from SIGTRAP handler (git-fixes).
- commit 2684d30

- x86/acpi: Fix LAPIC/x2APIC parsing order (git-fixes).
- commit ecc04e3

- x86/microcode/AMD: Add get_patch_level() (git-fixes).
- commit 73bb23d

- x86/microcode/AMD: Get rid of the _load_microcode_amd() forward  declaration (git-fixes).
- commit c818693

- x86/microcode/AMD: Merge early_apply_microcode() into its single  callsite (git-fixes).
- commit 761df14

- x86/microcode/AMD: Remove ugly linebreak in __verify_patch_section()  signature (git-fixes).
- commit d6c2d35

- x86/microcode: Consolidate the loader enablement checking (git-fixes).
- commit d0fff01

- scsi: iscsi: Fix incorrect error path labels for flashnode
  operations (git-fixes).
- md/raid1,raid10: don't handle IO error for REQ_RAHEAD and
  REQ_NOWAIT (git-fixes).
- commit cbd3a76

- PCI/PM: Set up runtime PM even for devices without PCI PM
  (git-fixes).
- commit 871b129

- drm/xe: Fix memset on iomem (git-fixes).
- drm/msm/a7xx: Call CP_RESET_CONTEXT_STATE (git-fixes).
- drm/msm: Fix CP_RESET_CONTEXT_STATE bitfield names (git-fixes).
- commit 68c42f4

- gpio: mlxbf3: only get IRQ for device instance 0 (git-fixes).
- ALSA: hda/realtek: Fix built-in mic on ASUS VivoBook X513EA
  (git-fixes).
- drm/etnaviv: Protect the scheduler's pending list with its lock
  (git-fixes).
- drm/nouveau/bl: increase buffer size to avoid truncate warning
  (git-fixes).
- drm/ssd130x: fix ssd132x_clear_screen() columns (git-fixes).
- drm/amdgpu: switch job hw_fence to amdgpu_fence (git-fixes).
- drm/i915/pmu: Fix build error with GCOV and AutoFDO enabled
  (git-fixes).
- drm/msm/dsi/dsi_phy_10nm: Fix missing initial VCO rate
  (git-fixes).
- drm/msm/disp: Correct porch timing for SDM845 (git-fixes).
- commit 3df7edd

- libnvdimm/labels: Fix divide error in nd_label_data_init()
  (bsc#1244743, CVE-2025-38072).
- commit 42a394c

- kabi: restore layout of struct mem_control (jsc#PED-12551).
- commit e948e2e

- mm, memcg: cg2 memory{.swap,}.peak write handlers
  (jsc#PED-12551).
- mm/memcontrol: export memcg.swap watermark via sysfs for v2
  memcg (jsc#PED-12551).
- commit 97c4d37

- wifi: ath12k: fix GCC_GCC_PCIE_HOT_RST definition for WCN7850
  (git-fixes).
- wifi: ath12k: refactor ath12k_hw_regs structure (stable-fixes).
- commit 0aa272e

- can: tcan4x5x: fix power regulator retrieval during probe
  (git-fixes).
- commit 5798451

- wifi: carl9170: do not ping device which has failed to load
  firmware (git-fixes).
- NFC: nci: uart: Set tty-&amp;gt;disc_data only in success path
  (git-fixes).
- hwmon: (occ) fix unaligned accesses (git-fixes).
- hwmon: (occ) Rework attribute registration for stack usage
  (git-fixes).
- hwmon: (ftsteutates) Fix TOCTOU race in fts_read() (git-fixes).
- wifi: ath11k: move some firmware stats related functions
  outside of debugfs (git-fixes).
- wifi: ath11k: don't wait when there is no vdev started
  (git-fixes).
- wifi: ath11k: don't use static variables in
  ath11k_debugfs_fw_stats_process() (git-fixes).
- wifi: ath11k: avoid burning CPU in
  ath11k_debugfs_fw_stats_request() (git-fixes).
- USB: serial: pl2303: add new chip PL2303GC-Q20 and PL2303GT-2AB
  (stable-fixes).
- usb: storage: Ignore UAS driver for SanDisk 3.2 Gen2 storage
  device (stable-fixes).
- usb: quirks: Add NO_LPM quirk for SanDisk Extreme 55AE
  (stable-fixes).
- thunderbolt: Do not double dequeue a configuration request
  (stable-fixes).
- rtc: Make rtc_time64_to_tm() support dates before 1970
  (stable-fixes).
- firmware: SDEI: Allow sdei initialization without ACPI_APEI_GHES
  (git-fixes).
- Bluetooth: MGMT: Remove unused mgmt_pending_find_data
  (stable-fixes).
- serial: sh-sci: Move runtime PM enable to sci_probe_single()
  (stable-fixes).
- wifi: ath11k: convert timeouts to secs_to_jiffies()
  (stable-fixes).
- wifi: ath11k: fix soc_dp_stats debugfs file permission
  (stable-fixes).
- commit d77b71f

- Update patches.suse/ALSA-pcm-Fix-race-of-buffer-access-at-PCM-OSS-layer.patch
  (CVE-2025-38078 bsc#1244737).
- commit 9ad878b

- workqueue: Initialize wq_isolated_cpumask in
  workqueue_init_early() (bsc#1245101 jsc#PED-11934).
- commit cf8ea05

- calipso: Fix null-ptr-deref in calipso_req_{set,del}attr()
  (git-fixes).
- commit 1a53756

- net/sched: fix use-after-free in taprio_dev_notifier
  (git-fixes).
- commit bd7e23e

- net_sched: ets: fix a race in ets_qdisc_change() (git-fixes).
- commit c8863c2

- net_sched: tbf: fix a race in tbf_change() (git-fixes).
- commit 8dd49d3

- net_sched: red: fix a race in __red_change() (git-fixes).
- commit eb63704

- net_sched: prio: fix a race in prio_tune() (git-fixes).
- commit 2898595

- net_sched: sch_sfq: reject invalid perturb period (git-fixes).
- commit 11af7b7

- net: Fix TOCTOU issue in sk_is_readable() (git-fixes).
- commit 9bf44e9

- Update patches.suse/dlm-mask-sk_shutdown-value.patch
  (bsc#1241278).
- Update patches.suse/dlm-use-SHUT_RDWR-for-SCTP-shutdown.patch
  (bsc#1241278).
  Original bsc number was wrong. Fix it.
- commit 37c9443

- net_sched: hfsc: Address reentrant enqueue adding class to
  eltree twice (CVE-2025-38001 bsc#1244234).
- commit 6a31481

- packaging: Add support for suse-kabi-tools
  The current workflow to check kABI stability during the RPM build of SUSE
  kernels consists of the following steps:
  * The downstream script rpm/modversions unpacks the consolidated kABI
  symtypes reference data from kabi/&amp;lt;arch&amp;gt;/symtypes-&amp;lt;flavor&amp;gt; and creates
  individual symref files.
  * The build performs a regular kernel make. During this operation, genksyms
  is invoked for each source file. The tool determines type signatures of
  all exports within the file, reports any differences compared to the
  associated symref reference, calculates symbol CRCs from the signatures
  and writes new type data into a symtypes file.
  * The script rpm/modversions is invoked again, this time it packs all new
  symtypes files to a consolidated kABI file.
  * The downstream script rpm/kabi.pl checks symbol CRCs in the new build and
  compares them to a reference from kabi/&amp;lt;arch&amp;gt;/symvers-&amp;lt;flavor&amp;gt;, taking
  kabi/severities into account.
  suse-kabi-tools is a new set of tools to improve the kABI checking process.
  The suite includes two tools, ksymtypes and ksymvers, which replace the
  existing scripts rpm/modversions and rpm/kabi.pl, as well as the comparison
  functionality previously provided by genksyms. The tools have their own
  source repository and package.
  The tools provide faster operation and more detailed, unified output. In
  addition, they allow the use of the new upstream tool gendwarfksyms, which
  lacks any built-in comparison functionality.
  The updated workflow is as follows:
  * The build performs a regular kernel make. During this operation, genksyms
  (gendwarfksyms) is invoked as usual, determinining signatures and CRCs of
  all exports and writing the type data to symtypes files. However,
  genksyms no longer performs any comparison.
  * 'ksymtypes consolidate' packs all new symtypes files to a consolidated
  kABI file.
  * 'ksymvers compare' checks symbol CRCs in the new build and compares them
  to a reference from kabi/&amp;lt;arch&amp;gt;/symvers-&amp;lt;flavor&amp;gt;, taking kabi/severities
  into account. The tool writes its result in a human-readable form on
  standard output and also writes a list of all changed exports (not
  ignored by kabi/severities) to the changed-exports file.
  * 'ksymtypes compare' takes the changed-exports file, the consolidated kABI
  symtypes reference data from kabi/&amp;lt;arch&amp;gt;/symtypes-&amp;lt;flavor&amp;gt; and the new
  consolidated data. Based on this data, it produces a detailed report
  explaining why the symbols changed.
  The patch enables the use of suse-kabi-tools via rpm/config.sh, providing
  explicit control to each branch. To enable the support, set
  USE_SUSE_KABI_TOOLS=Yes in the config file.
- commit a2c6f89

- rpm/kernel-source.changes.old: Drop bogus bugzilla reference (bsc#1244725)
- commit 5432961

- platform/x86/amd/hsmp: mark hsmp_msg_desc_table as maybe_unused (git-fixes).
- commit eaf3f3e

- platform/x86: ideapad-laptop: use usleep_range() for EC polling
  (git-fixes).
- commit 1373cac

- platform/x86: dell_rbu: Stop overwriting data buffer
  (git-fixes).
- platform/x86: dell_rbu: Fix list usage (git-fixes).
- platform/x86/amd: pmc: Clear metrics table at start of cycle
  (git-fixes).
- platform/x86/intel-uncore-freq: Fail module load when plat_info
  is NULL (git-fixes).
- commit 4eb007c

- platform/x86/amd/hsmp: fix building with CONFIG_HWMON=m (jsc#PED-13094).
- commit 7e90eae

- platform/x86/amd/hsmp: acpi: Add sysfs files to display HSMP telemetry (jsc#PED-13094).
- commit c34bfd9

- Bluetooth: hci_sync: Fix UAF in hci_acl_create_conn_sync
  (git-fixes).
- Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync (git-fixes).
- Bluetooth: hci_conn: Fix UAF Write in
  __hci_acl_create_connection_sync (git-fixes).
- commit cc24dff

- Bluetooth: hci_event: Fix not using key encryption size when
  its known (git-fixes).
- Bluetooth: Remove pending ACL connection attempts
  (stable-fixes).
- Bluetooth: hci_conn: Only do ACL connections sequentially
  (stable-fixes).
- commit 45b89a8

- platform/x86/amd/hsmp: Report power via hwmon sensor (jsc#PED-13094).
- commit 3fa9047

- platform/x86/amd/hsmp: Use a single DRIVER_VERSION for all hsmp  modules (jsc#PED-13094).
- commit b70cb9c

- platform/x86/amd/hsmp: Make amd_hsmp and hsmp_acpi as mutually exclusive drivers (jsc#PED-13094).
- Refresh
  patches.suse/x86-platform-amd-Move-the-asm-amd_hsmp.h-header-to-asm-amd.patch.
- commit e869dba

- x86/platform/amd: Move the &amp;lt;asm/amd_hsmp.h&amp;gt; header to &amp;lt;asm/amd/hsmp.h&amp;gt; (jsc#PED-13094).
- commit b780fd8

- x86/amd_node: Use defines for SMN register offsets (jsc#PED-13094).
- commit bea8590

- kernel-source: Remove log.sh from sources
- commit 96bd779

- powerpc/eeh: Fix missing PE bridge reconfiguration during VFIO
  EEH recovery (bsc#1215199).
- commit 8ae69e3

- platform/x86/amd/hsmp: Make hsmp_pdev static instead of global (jsc#PED-13094).
- commit 379d9d8

- platform/x86/amd/hsmp: Use dev_groups in the driver structure (jsc#PED-13094).
- commit 66e3f77

- platform/x86/amd/hsmp: Use name space while exporting module symbols (jsc#PED-13094).
- commit 2dee567

- platform/x86/amd/hsmp: Create separate ACPI, plat and common drivers (jsc#PED-13094).
- Update config files.
- Refresh
  patches.suse/platform-x86-amd-amd_3d_vcache-Add-AMD-3D-V-Cache-optimize.patch.
- commit ffd3128

- platform/x86/amd/hsmp: Change generic plat_dev name to hsmp_pdev (jsc#PED-13094).
- commit 915a3f7

- platform/x86/amd/hsmp: Move ACPI code to acpi.c (jsc#PED-13094).
- commit 783665d

- platform/x86/amd/hsmp: Move platform device specific code to plat.c (jsc#PED-13094).
- commit 05a6a05

- platform/x86/amd/hsmp: Move structure and macros to header file (jsc#PED-13094).
- commit bfb5c2a

- platform/x86/amd/hsmp: Convert amd_hsmp_rdwr() to a function pointer (jsc#PED-13094).
- commit 9f08011

- platform/x86/amd/hsmp: Create wrapper function init_acpi() (jsc#PED-13094).
- commit b6c3243

- platform/x86/amd/hsmp: Create hsmp/ directory (jsc#PED-13094).
- Refresh
  patches.suse/platform-x86-amd-amd_3d_vcache-Add-AMD-3D-V-Cache-optimize.patch.
- commit 9dae3f7

- x86/amd_node: Add support for debugfs access to SMN registers (jsc#PED-13094).
- commit a3ccd34

- x86/amd_node: Add SMN offsets to exclusive region access (jsc#PED-13094).
- commit d16a516

- ima: Suspend PCR extends and log appends when rebooting
  (bsc#1210025 ltc#196650).
- commit 25c308f

- wifi: ath12k: Prevent sending WMI commands to firmware during
  firmware crash (bsc#1240998).
- wifi: ath12k: Resolve multicast packet drop by populating
  key_cipher in ath12k_install_key() (bsc#1240998).
- commit eceaca4

- x86/amd_node: Remove dependency on AMD_NB (jsc#PED-13094).
- commit c48ff26

- x86/amd_node: Update __amd_smn_rw() error paths (jsc#PED-13094).
- commit fe719a3

- x86/amd_nb: Move SMN access code to a new amd_node driver (jsc#PED-13094).
- commit 72c9a97

- x86/amd_nb, hwmon: (k10temp): Simplify amd_pci_dev_to_node_id() (jsc#PED-13094).
- commit 66ca957

- x86/amd_nb: Simplify root device search (jsc#PED-13094).
- commit ec70dba

- x86/amd_nb: Simplify function 4 search (jsc#PED-13094).
- commit 60f7dbe

- x86: Start moving AMD node functionality out of AMD_NB (jsc#PED-13094).
- commit 03a65bb

- x86/amd_nb: Clean up early_is_amd_nb() (jsc#PED-13094).
- commit 300fc20

- x86/amd_nb: Restrict init function to AMD-based systems (jsc#PED-13094).
- commit 00ad037

- x86/mce/amd: Remove shared threshold bank plumbing (jsc#PED-13094).
- commit daa6443

- platform/x86: amd: Use *-y instead of *-objs in Makefiles (jsc#PED-13094).
- commit 0e11b2e

- platform/x86/amd/hsmp: Add support for HSMP protocol version 7 messages (jsc#PED-13094).
- commit ea1af9f

- platform/x86/amd/hsmp: Change the error type (jsc#PED-13094).
- commit a7ed99b

- platform/x86/amd/hsmp: Add new error code and error logs (jsc#PED-13094).
- commit 5e1eefb

- ACPI: CPPC: Fix NULL pointer dereference when nosmp is used
  (git-fixes).
- regulator: max20086: Fix refcount leak in
  max20086_parse_regulators_dt() (git-fixes).
- commit 5b8c5a3

- scsi: dc395x: Remove leftover if statement in reselect()
  (git-fixes).
- commit c259874

- loop: add file_start_write() and file_end_write() (git-fixes).
- scsi: dc395x: Remove DEBUG conditional compilation (git-fixes).
- scsi: hisi_sas: Call I_T_nexus after soft reset for SATA disk
  (git-fixes).
- scsi: qedf: Use designated initializer for struct
  qed_fcoe_cb_ops (git-fixes).
- scsi: sd_zbc: block: Respect bio vector limits for REPORT
  ZONES buffer (git-fixes).
- scsi: mpi3mr: Add level check to control event logging
  (git-fixes).
- scsi: st: Tighten the page format heuristics with MODE SELECT
  (git-fixes).
- scsi: st: ERASE does not change tape location (git-fixes).
- scsi: mpt3sas: Send a diag reset if target reset fails
  (git-fixes).
- scsi: st: Restore some drive settings after reset (git-fixes).
- commit 6dba36f

- scsi: mpt3sas: Fix _ctl_get_mpt_mctp_passthru_adapter() to
  return IOC pointer (git-fixes).
- scsi: smartpqi: Fix smp_processor_id() call trace for
  preemptible kernels (git-fixes).
- commit 26561f1

- x86/mm/init: Handle the special case of device private
  pages in add_pages(), to not increase max_pfn and trigger
  dma_addressing_limited() bounce buffers (git-fixes).
- commit d67c7bf

- PCI/MSI: Size device MSI domain with the maximum number of
  vectors (git-fixes).
- PCI: dw-rockchip: Remove PCIE_L0S_ENTRY check from
  rockchip_pcie_link_up() (git-fixes).
- PCI: apple: Set only available ports up (git-fixes).
- PCI: dwc: ep: Correct PBA offset in .set_msix() callback
  (git-fixes).
- PCI: endpoint: Retain fixed-size BAR size as well as aligned
  size (git-fixes).
- kABI: PCI: endpoint: Retain fixed-size BAR size as well as
  aligned size (git-fixes).
- PCI/DPC: Log Error Source ID only when valid (git-fixes).
- serial: mctrl_gpio: split disable_ms into sync and no_sync APIs
  (git-fixes).
- kABI: serial: mctrl_gpio: split disable_ms into sync and
  no_sync APIs (git-fixes).
- x86/kaslr: Reduce KASLR entropy on most x86 systems (git-fixes).
- PCI/DPC: Use defines with DPC reason fields (git-fixes).
- commit 67e24e5

- Revert &amp;quot;wifi: mwifiex: Fix HT40 bandwidth issue.&amp;quot; (git-fixes).
- Bluetooth: eir: Fix possible crashes on eir_create_adv_data
  (git-fixes).
- Bluetooth: btintel_pcie: Reduce driver buffer posting to
  prevent race condition (git-fixes).
- Bluetooth: btintel_pcie: Increase the tx and rx descriptor count
  (git-fixes).
- Bluetooth: btintel_pcie: Fix driver not posting maximum rx
  buffers (git-fixes).
- ptp: ocp: fix start time alignment in ptp_ocp_signal_set
  (git-fixes).
- ptp: ocp: reject unsupported periodic output flags (git-fixes).
- commit 7815601

- Bluetooth: MGMT: Fix sparse errors (git-fixes).
- commit bcd5c33

- wifi: ath11k: validate ath11k_crypto_mode on top of
  ath11k_core_qmi_firmware_ready (git-fixes).
- ath10k: snoc: fix unbalanced IRQ enable in crash recovery
  (git-fixes).
- Bluetooth: hci_sync: Fix broadcast/PA when using an existing
  instance (git-fixes).
- Bluetooth: Fix NULL pointer deference on eir_get_service_data
  (git-fixes).
- net/mdiobus: Fix potential out-of-bounds clause 45 read/write
  access (git-fixes).
- net/mdiobus: Fix potential out-of-bounds read/write access
  (git-fixes).
- Bluetooth: MGMT: Fix UAF on mgmt_remove_adv_monitor_complete
  (git-fixes).
- Bluetooth: hci_core: fix list_for_each_entry_rcu usage
  (git-fixes).
- ptp: remove ptp-&amp;gt;n_vclocks check logic in ptp_vclock_in_use()
  (git-fixes).
- pinctrl: st: Drop unused st_gpio_bank() function (git-fixes).
- pinctrl: qcom: pinctrl-qcm2290: Add missing pins (git-fixes).
- commit d9ecc09

- wifi: ath12k: fix key cache handling (bsc#1240998).
- wifi: ath12k: ath12k_mac_op_set_key(): fix uninitialized symbol
  'ret' (bsc#1240998).
- wifi: ath12k: Fix for out-of bound access error (bsc#1240998).
- commit 8ff94a8

- wifi: ath12k: fix A-MSDU indication in monitor mode
  (bsc#1240998).
- wifi: ath12k: use tail MSDU to get MSDU information
  (bsc#1240998).
- commit e2172a0

- wifi: ath12k: modify link arvif creation and removal for MLO
  (bsc#1240998).
- Refresh
  patches.suse/wifi-ath12k-fix-read-pointer-after-free-in-ath12k_ma.patch.
- commit 923a9a5

- wifi: ath12k: delete NSS and TX power setting for monitor vdev
  (bsc#1240998).
- wifi: ath12k: fix struct hal_rx_mpdu_start (bsc#1240998).
- wifi: ath12k: fix struct hal_rx_phyrx_rssi_legacy_info
  (bsc#1240998).
- wifi: ath12k: fix struct hal_rx_ppdu_start (bsc#1240998).
- wifi: ath12k: fix struct hal_rx_ppdu_end_user_stats
  (bsc#1240998).
- wifi: ath12k: remove unused variable monitor_present
  (bsc#1240998).
- wifi: ath12k: update ath12k_mac_op_update_vif_offload() for MLO
  (bsc#1240998).
- wifi: ath12k: update ath12k_mac_op_conf_tx() for MLO
  (bsc#1240998).
- wifi: ath12k: modify ath12k_mac_op_set_key() for MLO
  (bsc#1240998).
- commit 875025b

- wifi: ath12k: prepare vif data structure for MLO handling
  (bsc#1240998).
- Refresh
  patches.suse/wifi-ath12k-Handle-error-cases-during-extended-skb-a.patch.
- Refresh
  patches.suse/wifi-ath12k-fix-tx-power-max-reg-power-update-to-fir.patch.
- commit d3bc90b

- wifi: ath12k: modify ath12k_mac_op_bss_info_changed() for MLO
  (bsc#1240998).
- wifi: ath12k: modify ath12k_get_arvif_iter() for MLO
  (bsc#1240998).
- wifi: ath12k: modify ath12k_mac_vif_chan() for MLO
  (bsc#1240998).
- wifi: ath12k: prepare vif config caching for MLO (bsc#1240998).
- wifi: ath12k: prepare sta data structure for MLO handling
  (bsc#1240998).
- wifi: ath12k: pass ath12k_link_vif instead of vif/ahvif
  (bsc#1240998).
- wifi: ath12k: Support BE OFDMA Pdev Rate Stats (bsc#1240998).
- wifi: ath12k: Support Pdev Scheduled Algorithm Stats
  (bsc#1240998).
- wifi: ath12k: Support DMAC Reset Stats (bsc#1240998).
- commit 45b89e0

- Update config files: set CONFIG_ATH12K_COREDUMP=n
- commit 6743252

- wifi: ath12k: switch to using wiphy_lock() and remove
  ar-&amp;gt;conf_mutex (bsc#1240998).
- Refresh
  patches.suse/wifi-ath12k-fix-node-corruption-in-ar-arvifs-list.patch.
- Refresh
  patches.suse/wifi-ath12k-fix-read-pointer-after-free-in-ath12k_ma.patch.
- commit e4becf9

- wifi: ath12k: Add firmware coredump collection support
  (bsc#1240998).
- wifi: ath12k: add missing lockdep_assert_wiphy() for
  ath12k_mac_op_ functions (bsc#1240998).
- wifi: ath12k: ath12k_mac_op_sta_state(): clean up update_wk
  cancellation (bsc#1240998).
- wifi: ath12k: ath12k_mac_set_key(): remove exit label
  (bsc#1240998).
- wifi: ath12k: cleanup unneeded labels (bsc#1240998).
- wifi: ath12k: convert struct ath12k_sta::update_wk to use
  struct wiphy_work (bsc#1240998).
- wifi: ath12k: Support Pdev OBSS Stats (bsc#1240998).
- wifi: ath12k: Support pdev CCA Stats (bsc#1240998).
- wifi: ath12k: Support pdev Transmit Multi-user stats
  (bsc#1240998).
- wifi: ath12k: Support Ring and SFM stats (bsc#1240998).
- wifi: ath12k: Support Self-Generated Transmit stats
  (bsc#1240998).
- wifi: ath12k: Modify print_array_to_buf() to support arrays
  with 1-based semantics (bsc#1240998).
- wifi: ath12k: move txbaddr/rxbaddr into struct ath12k_dp
  (bsc#1240998).
- wifi: ath12k: make read-only array svc_id static const
  (bsc#1240998).
- commit 52faf57

- sch_hfsc: Fix qlen accounting bug when using peek in
  hfsc_enqueue() (CVE-2025-38000 bsc#1244277).
- commit ffb9ab4

- thunderbolt: Improve redrive mode handling (git-fixes).
- commit 9923d39

- net_sched: sch_fifo: implement lockless __fifo_dump() (bsc#1237312)
- commit 8196566

- wifi: ath12k: Handle error cases during extended skb allocation
  (git-fixes).
- wifi: ath12k: fix read pointer after free in
  ath12k_mac_assign_vif_to_vdev() (git-fixes CVE-2024-57995
  bsc#1237895).
- commit f9ec810

- wifi: ath12k: Fix buffer overflow in debugfs (bsc#1240998).
- wifi: ath12k: Add missing htt_metadata flag in ath12k_dp_tx()
  (bsc#1240998).
- wifi: ath12k: fix skb_ext_desc leak in ath12k_dp_tx() error path
  (bsc#1240998).
- wifi: ath12k: fix one more memcpy size error (bsc#1240998).
- wifi: ath12k: fix use-after-free in ath12k_dp_cc_cleanup()
  (bsc#1240998).
- commit 911b319

- wifi: ath12k: Avoid -Wflex-array-member-not-at-end warnings
  (bsc#1240998).
- wifi: ath12k: fix the stack frame size warning in
  ath12k_mac_op_hw_scan (bsc#1240998).
- commit 00bca74

- wifi: ath12k: restore ASPM for supported hardwares only
  (bsc#1240998).
- commit 32459d7

- wifi: ath12k: Support Transmit DE stats (bsc#1240998).
- wifi: ath12k: use 128 bytes aligned iova in transmit path for
  WCN7850 (bsc#1240998).
- wifi: ath12k: fix reusing outside iterator in
  ath12k_wow_vif_set_wakeups() (bsc#1240998).
- wifi: ath12k: fix build vs old compiler (bsc#1240998).
- wifi: ath12k: Support TQM stats (bsc#1240998).
- wifi: ath12k: Support pdev error stats (bsc#1240998).
- wifi: ath12k: Support Transmit Scheduler stats (bsc#1240998).
- wifi: ath12k: Dump additional Tx PDEV HTT stats (bsc#1240998).
- commit 55670c2

- Revert &amp;quot;ipv6: save dontfrag in cork (git-fixes).&amp;quot;
  This reverts commit d3fe600164867bd0529ed1049fbd53ca9fce2eaf.
  See https://lore.kernel.org/all/aElivdUXqd1OqgMY@karahi.gladserv.com/
  and https://bugzilla.suse.com/show_bug.cgi?id=1244313.
- commit b9e7a4e

- wifi: ath12k: Add support to parse requested stats_type
  (bsc#1240998).
- wifi: ath12k: Add htt_stats_dump file ops support (bsc#1240998).
- wifi: ath12k: Add support to enable debugfs_htt_stats
  (bsc#1240998).
- wifi: ath12k: fix driver initialization for WoW unsupported
  devices (bsc#1240998).
- wifi: ath12k: Fix pdev id sent to firmware for single phy
  devices (bsc#1240998).
- wifi: ath12k: handle keepalive during WoWLAN suspend and resume
  (bsc#1240998).
- wifi: ath12k: support GTK rekey offload (bsc#1240998).
- wifi: ath12k: support ARP and NS offload (bsc#1240998).
- wifi: ath12k: implement hardware data filter (bsc#1240998).
- wifi: ath12k: add WoW net-detect functionality (bsc#1240998).
- wifi: ath12k: add basic WoW functionalities (bsc#1240998).
- wifi: ath12k: implement WoW enable and wakeup commands
  (bsc#1240998).
- wifi: ath12k: add ATH12K_DBG_WOW log level (bsc#1240998).
- wifi: ath12k: fix mbssid max interface advertisement
  (bsc#1240998).
- wifi: ath12k: fix legacy peer association due to missing HT
  or 6 GHz capabilities (bsc#1240998).
- wifi: ath12k: fix NULL pointer access in
  ath12k_mac_op_get_survey() (bsc#1240998).
- wifi: ath12k: Remove unused ath12k_base from ath12k_hw
  (bsc#1240998).
- wifi: ath12k: Fix WARN_ON during firmware crash in split-phy
  (bsc#1240998).
- wifi: ath12k: handle symlink cleanup for per pdev debugfs dentry
  (bsc#1240998).
- wifi: ath12k: unregister per pdev debugfs (bsc#1240998).
- commit 0bd0160

- Revert &amp;quot;kABI: ipv6: save dontfrag in cork (git-fixes).&amp;quot;
  This reverts commit cbc81e238815721048ac709726467c90981753c9.
  See https://lore.kernel.org/all/aElivdUXqd1OqgMY@karahi.gladserv.com/
  and https://bugzilla.suse.com/show_bug.cgi?id=1244313.
- commit 38d0091

- wifi: ath12k: fix per pdev debugfs registration (bsc#1240998).
- wifi: ath12k: avoid unnecessary MSDU drop in the Rx error
  process (bsc#1240998).
- wifi: ath12k: fix ACPI warning when resume (bsc#1240998).
- wifi: ath12k: modify remain on channel for single wiphy
  (bsc#1240998).
- wifi: ath12k: add hw_link_id in ath12k_pdev (bsc#1240998).
- wifi: ath12k: add panic handler (bsc#1240998).
- wifi: ath12k: do not process consecutive RDDM event
  (bsc#1240998).
- wifi: ath12k: Fix devmem address prefix when logging
  (bsc#1240998).
- wifi: ath12k: improve the rx descriptor error information
  (bsc#1240998).
- wifi: ath12k: refactor rx descriptor CMEM configuration
  (bsc#1240998).
- wifi: ath12k: fix Smatch warnings on ath12k_core_suspend()
  (bsc#1240998).
- wifi: ath12k: dynamic VLAN support (bsc#1240998).
- wifi: ath12k: fix ack signal strength calculation (bsc#1240998).
- wifi: ath12k: use correct MAX_RADIOS (bsc#1240998).
- wifi: ath12k: remove duplicate definition of MAX_RADIOS
  (bsc#1240998).
- wifi: ath12k: remove redundant peer delete for WCN7850
  (bsc#1240998).
- wifi: ath12k: skip sending vdev down for channel switch
  (bsc#1240998).
- wifi: ath12k: add EMA beacon support (bsc#1240998).
- wifi: ath12k: add MBSSID beacon support (bsc#1240998).
- wifi: ath12k: refactor arvif security parameter configuration
  (bsc#1240998).
- commit 187e02f

- wifi: ath12k: advertise driver capabilities for MBSSID and EMA
  (bsc#1240998).
- Refresh
  patches.suse/wifi-ath12k-fix-peer-metadata-parsing.patch.
- commit 9bb543e

- wifi: ath12k: allocate dummy net_device dynamically
  (bsc#1240998).
- Refresh
  patches.suse/wifi-ath12k-Avoid-napi_sync-before-napi_enable.patch.
- commit 6102136

- wifi: ath12k: configure MBSSID parameters in AP mode
  (bsc#1240998).
- wifi: ath12k: create a structure for WMI vdev up parameters
  (bsc#1240998).
- wifi: ath12k: rename MBSSID fields in wmi_vdev_up_cmd
  (bsc#1240998).
- wifi: ath12k: configure MBSSID params in vdev create/start
  (bsc#1240998).
- wifi: ath12k: support SMPS configuration for 6 GHz
  (bsc#1240998).
- wifi: ath12k: refactor SMPS configuration (bsc#1240998).
- wifi: ath12k: add 6 GHz params in peer assoc command
  (bsc#1240998).
- wifi: ath12k: fix survey dump collection in 6 GHz (bsc#1240998).
- wifi: ath12k: add channel 2 into 6 GHz channel list
  (bsc#1240998).
- wifi: ath12k: fix misspelling of &amp;quot;dma&amp;quot; in num_rxmda_per_pdev
  (bsc#1240998).
- wifi: ath12k: avoid double SW2HW_MACID conversion (bsc#1240998).
- wifi: ath12k: remove invalid peer create logic (bsc#1240998).
- wifi: ath12k: avoid duplicated vdev down (bsc#1240998).
- wifi: ath12k: remove unused variable monitor_flags
  (bsc#1240998).
- wifi: ath12k: Remove unused tcl_*_ring configuration
  (bsc#1240998).
- wifi: ath12k: Remove unsupported tx monitor handling
  (bsc#1240998).
- wifi: ath12k: fix calling correct function for rx monitor mode
  (bsc#1240998).
- wifi: ath12k: add multi device support for WBM idle ring buffer
  setup (bsc#1240998).
- commit ea4159d

- wifi: ath12k: Refactor idle ring descriptor setup (bsc#1240998).
- Refresh
  patches.suse/wifi-ath12k-fix-firmware-crash-during-reo-reinject.patch.
- commit 3c261ef

- wifi: ath12k: Introduce device index (bsc#1240998).
- wifi: ath12k: Replace &amp;quot;chip&amp;quot; with &amp;quot;device&amp;quot; in hal Rx return
  buffer manager (bsc#1240998).
- wifi: ath12k: Add lock to protect the hardware state
  (bsc#1240998).
- wifi: ath12k: Refactor the hardware state (bsc#1240998).
- wifi: ath12k: Refactor the hardware recovery procedure
  (bsc#1240998).
- wifi: ath12k: fix flush failure in recovery scenarios
  (bsc#1240998).
- wifi: ath12k: set mlo_capable_flags based on QMI PHY capability
  (bsc#1240998).
- wifi: ath12k: read single_chip_mlo_support parameter from QMI
  PHY capability (bsc#1240998).
- wifi: ath12k: add support to handle beacon miss for WCN7850
  (bsc#1240998).
- wifi: ath12k: ACPI band edge channel power support
  (bsc#1240998).
- wifi: ath12k: ACPI CCA threshold support (bsc#1240998).
- wifi: ath12k: ACPI SAR support (bsc#1240998).
- wifi: ath12k: ACPI TAS support (bsc#1240998).
- wifi: ath12k: change supports_suspend to true for WCN7850
  (bsc#1240998).
- wifi: ath12k: support suspend/resume (bsc#1240998).
- wifi: ath12k: avoid stopping mac80211 queues in
  ath12k_core_restart() (bsc#1240998).
- wifi: ath12k: no need to handle pktlog during suspend/resume
  (bsc#1240998).
- wifi: ath12k: flush all packets before suspend (bsc#1240998).
- commit 9a64ae8

- wifi: ath12k: decrease MHI channel buffer length to 8KB
  (bsc#1240998).
- wifi: ath12k: fix warning on DMA ring capabilities event
  (bsc#1240998).
- wifi: ath12k: do not dump SRNG statistics during resume
  (bsc#1240998).
- wifi: ath12k: remove MHI LOOPBACK channels (bsc#1240998).
- wifi: ath12k: rearrange IRQ enable/disable in reset path
  (bsc#1240998).
- wifi: ath12k: Refactor data path cmem init (bsc#1240998).
- wifi: ath12k: displace the Tx and Rx descriptor in cookie
  conversion table (bsc#1240998).
- wifi: ath12k: Refactor the hardware cookie conversion init
  (bsc#1240998).
- wifi: ath12k: avoid redundant code in Rx cookie conversion init
  (bsc#1240998).
- wifi: ath12k: don't use %pK in dmesg format strings
  (bsc#1240998).
- wifi: ath12k: enable service flag for survey dump stats
  (bsc#1240998).
- wifi: ath12k: enable WIPHY_FLAG_DISABLE_WEXT (bsc#1240998).
- wifi: ath12k: dynamically update peer puncturing bitmap for STA
  (bsc#1240998).
- wifi: ath12k: fix mac id extraction when MSDU spillover in rx
  error path (bsc#1240998).
- wifi: ath12k: support get_survey mac op for single wiphy
  (bsc#1240998).
- wifi: ath12k: Modify rts threshold mac op for single wiphy
  (bsc#1240998).
- wifi: ath12k: Modify set and get antenna mac ops for single
  wiphy (bsc#1240998).
- wifi: ath12k: modify regulatory support for single wiphy
  architecture (bsc#1240998).
- wifi: ath12k: Add additional checks for vif and sta iterators
  (bsc#1240998).
- wifi: ath12k: Cache vdev configs before vdev create
  (bsc#1240998).
- commit ea1744e

- wifi: ath12k: vdev statemachine changes for single wiphy
  (bsc#1240998).
- Refresh
  patches.suse/wifi-ath12k-fix-peer-metadata-parsing.patch.
- commit ab212a6

- wifi: ath12k: modify ath12k mac start/stop ops for single wiphy
  (bsc#1240998).
- Refresh
  patches.suse/wifi-mac80211-inform-the-low-level-if-drv_stop-is-a-.patch.
- commit 0a8727c

- wifi: ath12k: add multiple radio support in a single MAC HW
  un/register (bsc#1240998).
- Refresh
  patches.suse/wifi-mac80211-inform-the-low-level-if-drv_stop-is-a-.patch.
- commit 5897b5c

- wifi: ath12k: fetch correct radio based on vdev status
  (bsc#1240998).
- wifi: ath12k: scan statemachine changes for single wiphy
  (bsc#1240998).
- wifi: ath12k: Modify add and remove chanctx ops for single
  wiphy support (bsc#1240998).
- wifi: ath12k: correct the capital word typo (bsc#1240998).
- wifi: ath12k: fix link capable flags (bsc#1240998).
- wifi: ath12k: extend the link capable flag (bsc#1240998).
- wifi: ath12k: fix hal_rx_buf_return_buf_manager documentation
  (bsc#1240998).
- wifi: ath12k: fix missing endianness conversion in
  wmi_vdev_create_cmd() (bsc#1240998).
- wifi: ath12k: debugfs: radar simulation support (bsc#1240998).
- wifi: ath12k: initial debugfs support (bsc#1240998).
- wifi: ath12k: Refactor error handler of Rxdma replenish
  (bsc#1240998).
- wifi: ath12k: Optimize the lock contention of used list in Rx
  data path (bsc#1240998).
- wifi: ath12k: Refactor Rxdma buffer replinish argument
  (bsc#1240998).
- wifi: ath12k: remove duplicate definitions in wmi.h
  (bsc#1240998).
- wifi: ath12k: fix desc address calculation in wbm tx completion
  (bsc#1240998).
- wifi: ath12k: remove obsolete struct wmi_start_scan_arg
  (bsc#1240998).
- commit 56d49fd

- kABI fix for net: Remove RTNL dance for SIOCBRADDIF and
  SIOCBRDELIF (CVE-2025-22111 bsc#1241572).
- commit edfd43c

- page_pool: avoid infinite loop to schedule delayed worker
  (CVE-2025-37859 bsc#1243051).
- commit b8f1dfd

- tipc: fix memory leak in tipc_link_xmit (CVE-2025-37757 bsc#1242521)
- commit 48e0415

- struct usci: hide additional member (git-fixes).
- commit 1b8456a

- net_sched: Flush gso_skb list too during -&amp;gt;change()
  (CVE-2025-37992 bsc#1243698).
- netfilter: ipset: fix region locking in hash types
  (CVE-2025-37997 bsc#1243832).
- ipvs: fix uninit-value for saddr in do_output_route4
  (CVE-2025-37961 bsc#1243523).
- net: dsa: free routing table on probe failure (CVE-2025-37786
  bsc#1242725).
- net: tls: explicitly disallow disconnect (CVE-2025-37756
  bsc#1242515).
- net: Remove RTNL dance for SIOCBRADDIF and SIOCBRDELIF
  (CVE-2025-22111 bsc#1241572).
- vlan: enforce underlying device type (CVE-2025-21920
  bsc#1240686).
- xfrm: delete intermediate secpath entry in packet offload mode
  (CVE-2025-21720 bsc#1238859).
- xfrm: state: fix out-of-bounds read during lookup
  (CVE-2024-57982 bsc#1237913).
- rxrpc: Fix handling of received connection abort (CVE-2024-58053
  bsc#1238982).
- commit d3e755f

- isolcpus: fix bug in returning number of allocated cpumask (bsc#1243774).
  Return the correct upper limit of the allocated cpumask.
  modified:
  - patches.suse/lib-group_cpus-honor-housekeeping-config-when-grouping.patch
  - patches.suse/lib-group_cpus-let-group_cpu_evenly-return-number.patch
- commit 092bf4a

- xen/arm: call uaccess_ttbr0_enable for dm_op hypercall (git-fixes)
- commit 24d5250

- arm64: dts: marvell: uDPU: define pinctrl state for alarm LEDs (git-fixes)
- commit 28d162e

- Revert &amp;quot;arm64: dts: allwinner: h6: Use RSB for AXP805 PMIC (git-fixes)
- commit 9dd3301

- xen/x86: fix initial memory balloon target (git-fixes).
- commit 7e938b1

- ALSA: usb-audio: Add a quirk for Lenovo Thinkpad Thunderbolt
  3 dock (stable-fixes).
- ALSA: usb-audio: Fix NULL pointer deref in
  snd_usb_power_domain_set() (git-fixes).
- commit 9d209cd

- ALSA: usb-audio: Rename Pioneer mixer channel controls
  (git-fixes).
- ALSA: usb-audio: Add Pioneer DJ DJM-V10 support (stable-fixes).
- ALSA: usb-audio: Fix duplicated name in MIDI substream names
  (stable-fixes).
- ALSA: usb-audio: mixer: Remove temporary string use in
  parse_clock_source_unit (stable-fixes).
- commit e8737ac

- ALSA: usb-audio: Set MIDI1 flag appropriately for GTB MIDI
  1.0 entry (stable-fixes).
- ALSA: usb-audio: Accept multiple protocols in GTBs
  (stable-fixes).
- ALSA: usb-audio: Add name for HP Engage Go dock (stable-fixes).
- commit 498a796

- Revert &amp;quot;ALSA: usb-audio: Skip setting clock selector for single
  connections&amp;quot; (stable-fixes).
- Refresh
  patches.suse/ALSA-usb-audio-Ignore-clock-selector-errors-for-sing.patch.
- Refresh
  patches.suse/ALSA-usb-audio-Support-multiple-control-interfaces.patch.
- commit d0138e9

- ALSA: usb-audio: Support read-only clock selector control
  (stable-fixes).
- Refresh
  patches.suse/ALSA-usb-audio-Ignore-clock-selector-errors-for-sing.patch.
- Refresh
  patches.suse/ALSA-usb-audio-Support-multiple-control-interfaces.patch.
- commit ee97bec

- ALSA: usb-audio: Skip setting clock selector for single
  connections (stable-fixes).
- Refresh
  patches.suse/ALSA-usb-audio-Ignore-clock-selector-errors-for-sing.patch.
- Refresh
  patches.suse/ALSA-usb-audio-Support-multiple-control-interfaces.patch.
- commit 7326e0b

- ALSA: usb-audio: Add implicit feedback quirk for RODE AI-1
  (stable-fixes).
- ALSA: usb-audio: enable support for Presonus Studio 1824c
  within 1810c file (stable-fixes).
- ALSA: usb-audio: Support multiple control interfaces
  (stable-fixes).
- ALSA: usb-audio: Check shutdown at endpoint_set_interface()
  (stable-fixes).
- commit d4a0ce3

- wifi: ath11k: update channel list in worker when wait flag is
  set (bsc#1243847).
- commit 4cfebaa

- net: lan743x: Fix memleak issue when GSO enabled (CVE-2025-37909
  bsc#1243467).
- vxlan: vnifilter: Fix unlocked deletion of default FDB entry
  (CVE-2025-37921 bsc#1243480).
- commit 788c92a

- watchdog: mediatek: Add support for MT6735 TOPRGU/WDT
  (git-fixes).
- commit 4df631e

- watchdog: it87_wdt: add PWRGD enable quirk for Qotom QCML04
  (git-fixes).
- commit ba2db88

- module: ensure that kobject_put() is safe for module type kobjects (CVE-2025-37995 bsc#1243827)
- commit 6979c9a

- mkspec: Exclude rt flavor from kernel-syms dependencies (bsc#1244337).
- commit 7c95ae0

- x86/xen: fix balloon target initialization for PVH dom0
  (git-fixes).
- commit ad18aba

- powerpc/vas: Return -EINVAL if the offset is non-zero in mmap()
  (bsc#1244309 ltc#213790).
- powerpc/powernv/memtrace: Fix out of bounds issue in memtrace
  mmap (bsc#1244309 ltc#213790).
- commit 2d4ad48

- tracing: Verify event formats that have &amp;quot;%*p..&amp;quot; (CVE-2025-37938
  bsc#1243544).
- tracing: Add __print_dynamic_array() helper (bsc#1243544).
- tracing: Add __string_len() example (bsc#1243544).
- commit c705d1d

- fbdev/efifb: Remove PM for parent device (bsc#1244261).
- Refresh
  patches.suse/fbdev-efifb-Register-sysfs-groups-through-driver-cor.patch.
- commit 0c56458

- RDMA/uverbs: Propagate errors from rdma_lookup_get_uobject() (git-fixes)
- commit 7d2ce51

- RDMA/core: Fix best page size finding when it can cross SG entries (git-fixes)
- commit bfdc372

- Update config files.
  config/x86_64/default
  config/arm64/default
  CONFIG_INTEGRITY_MACHINE_KEYRING=y
  +CONFIG_INTEGRITY_CA_MACHINE_KEYRING=y
  +CONFIG_INTEGRITY_CA_MACHINE_KEYRING_MAX=y
  +CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY=y
  (bsc#1243678)
- commit a35da96

- MyBS: Do not build kernel-obs-qa with limit_packages
  Fixes: 58e3f8c34b2b (&amp;quot;bs-upload-kernel: Pass limit_packages also on multibuild&amp;quot;)
- commit f4c6047

- MyBS: Simplify qa_expr generation
  Start with a 0 which makes the expression valid even if there are no QA
  repositories (currently does not happen). Then separator is always
  needed.
- commit e4c2851

- MyBS: Correctly generate build flags for non-multibuild package limit
  (bsc# 1244241)
  Fixes: 0999112774fc (&amp;quot;MyBS: Use buildflags to set which package to build&amp;quot;)
- commit 27588c9

- bs-upload-kernel: Pass limit_packages also on multibuild
  Fixes: 0999112774fc (&amp;quot;MyBS: Use buildflags to set which package to build&amp;quot;)
  Fixes: 747f601d4156 (&amp;quot;bs-upload-kernel, MyBS, Buildresults: Support multibuild (JSC-SLE#5501, boo#1211226, bsc#1218184)&amp;quot;)
- commit 8ef486c

- ftrace: Avoid potential division by zero in function_stat_show()
  (CVE-2025-21898 bsc#1240610).
- commit d476f96

- tracing: Fix bad hist from corrupting named_triggers list
  (CVE-2025-21899 bsc#1240577).
- commit 60219e4

- iommu: Skip PASID validation for devices without PASID capability (bsc#1244100)
- commit 647b2f4

- iommu: Validate the PASID in iommu_attach_device_pasid() (bsc#1244100)
- commit ca42766

- nfsd: Initialize ssc before laundromat_work to prevent NULL
  dereference (git-fixes).
- commit 153c2a2

- nfsd: validate the nfsd_serv pointer before calling svc_wake_up
  (git-fixes).
- commit af8b93e

- NFSD: Insulate nfsd4_encode_read_plus() from page boundaries
  in the encode buffer (git-fixes).
- commit 91b6192

- jffs2: check jffs2_prealloc_raw_node_refs() result in few
  other places (git-fixes).
- commit 254a145

- jffs2: check that raw node were preallocated before writing
  summary (git-fixes).
- commit 4a6701a

- x86/microcode/AMD: Have __apply_microcode_amd() return bool (git-fixes).
- commit ae818bc

- x86/microcode/AMD: Make __verify_patch_size() return bool (git-fixes).
- commit dcdd8b6

- x86/microcode/AMD: Return bool from find_blobs_in_containers() (git-fixes).
- commit 65dff7c

- x86/microcode/AMD: Do not return error when microcode update is not necessary (git-fixes).
- commit 662ffcd

- x86/idle: Remove MFENCEs for X86_BUG_CLFLUSH_MONITOR in mwait_idle_with_hints() and prefer_mwait_c1_over_halt() (git-fixes).
- commit 15bb5b3

- blacklist.conf: Disable fineibt part of ITS mitigation
- Refresh
  patches.suse/x86-its-Enumerate-Indirect-Target-Selection-ITS-bug.patch.
- commit cedb857

- xsk: fix an integer overflow in xp_create_and_assign_umem()
  (bsc#1240823 CVE-2025-21997).
- commit 931fc27

- dlm: use SHUT_RDWR for SCTP shutdown (bsc#1228854).
- dlm: mask sk_shutdown value (bsc#1228854).
- commit 730d8cf

- drm/xe: Rework eviction rejection of bound external bos
  (git-fixes).
- commit 939c62a

- ASoC: ti: omap-hdmi: Re-add dai_link-&amp;gt;platform to fix card init
  (git-fixes).
- commit e678093

- ASoC: Intel: avs: Verify content returned by parse_int_array()
  (git-fixes).
- ASoC: Intel: avs: Fix deadlock when the failing IPC is SET_D0IX
  (git-fixes).
- ASoC: codecs: hda: Fix RPM usage count underflow (git-fixes).
- commit 7d227ae

- Move upstreamed iommu patch into sorted section
- commit f4c105a

- Move upstreamed crypto patches into sorted section
- commit 9df372d

- drm/xe: remove unmatched xe_vm_unlock() from
  __xe_exec_queue_init() (git-fixes).
- commit 5e0c63a

- usb: typec: tcpm: move tcpm_queue_vdm_unlocked to asynchronous
  work (git-fixes).
- tty: serial: 8250_omap: fix TX with DMA for am33xx (git-fixes).
- serial: jsm: fix NPE during jsm_uart_port_init (git-fixes).
- sysfb: Fix screen_info type check for VGA (git-fixes).
- accel/ivpu: Use dma_resv_lock() instead of a custom mutex
  (git-fixes).
- drm/panel-simple: fix the warnings for the Evervision VGG644804
  (git-fixes).
- accel/ivpu: Improve buffer object logging (git-fixes).
- dummycon: Trigger redraw when switching consoles with deferred
  takeover (git-fixes).
- drm/xe: Create LRC BO without VM (git-fixes).
- drm/xe/sched: stop re-submitting signalled jobs (git-fixes).
- drm/xe/vm: move rebind_work init earlier (git-fixes).
- drm/i915/guc: Handle race condition where wakeref count drops
  below 0 (git-fixes).
- drm/i915/psr: Fix using wrong mask in REG_FIELD_PREP
  (git-fixes).
- drm/i915/guc: Check if expecting reply before decrementing
  outstanding_submission_g2h (git-fixes).
- drm/xe: Make xe_gt_freq part of the Documentation (git-fixes).
- commit 5cf14c5

- Update video patch to the upstream version (bsc#1240696).
- commit 8af5790

- Move upstreamed patches into sorted section
- commit 022730e

- spi: bcm63xx-hsspi: fix shared reset (git-fixes).
- spi: bcm63xx-spi: fix shared reset (git-fixes).
- regulator: max14577: Add error check for max14577_read_reg()
  (git-fixes).
- usb: usbtmc: Fix timeout value in get_stb (git-fixes).
- usb: usbtmc: Fix read_stb function and get_stb ioctl
  (git-fixes).
- usb: cdnsp: Fix issue with detecting command completion event
  (git-fixes).
- usb: cdnsp: Fix issue with detecting USB 3.2 speed (git-fixes).
- usb: Flush altsetting 0 endpoints before reinitializating them
  after reset (git-fixes).
- usb: typec: tcpm/tcpci_maxim: Fix bounds check in process_rx()
  (git-fixes).
- thunderbolt: Fix a logic error in wake on connect (git-fixes).
- usb: renesas_usbhs: Reorder clock handling and power management
  in probe (git-fixes).
- vt: remove VT_RESIZE and VT_RESIZEX from vt_compat_ioctl()
  (git-fixes).
- serial: Fix potential null-ptr-deref in mlb_usio_probe()
  (git-fixes).
- staging: iio: ad5933: Correct settling cycles encoding per
  datasheet (git-fixes).
- iio: adc: ad7124: Fix 3dB filter frequency reading (git-fixes).
- iio: filter: admv8818: Support frequencies &amp;gt;= 2^32 (git-fixes).
- iio: filter: admv8818: fix range calculation (git-fixes).
- iio: filter: admv8818: fix integer overflow (git-fixes).
- iio: filter: admv8818: fix band 4, state 15 (git-fixes).
- VMCI: fix race between vmci_host_setup_notify and
  vmci_ctx_unset_notify (git-fixes).
- iio: accel: fxls8962af: Fix temperature scan element sign
  (git-fixes).
- iio: imu: inv_icm42600: Fix temperature calculation (git-fixes).
- iio: adc: ad7606_spi: fix reg write value mask (git-fixes).
- bus: mhi: host: Fix conflict between power_up and SYSERR
  (git-fixes).
- drm/amd/display: Add null pointer check for
  get_first_active_display() (git-fixes).
- drm/i915/gem: Allow EXEC_CAPTURE on recoverable contexts on DG1
  (git-fixes).
- commit def2214

- s390/pci: Serialize device addition and removal (bsc#1244145).
- commit f1ae730

- s390/pci: Allow re-add of a reserved but not yet removed device
  (bsc#1244145).
- commit a73fcdb

- s390/pci: Prevent self deletion in disable_slot() (bsc#1244145).
- commit 136fe4f

- s390/pci: Remove redundant bus removal and disable from
  zpci_release_device() (bsc#1244145).
- commit 9bbc219

- s390/pci: Fix potential double remove of hotplug slot
  (bsc#1244145).
- commit 9714d95

- s390/pci: remove hotplug slot when releasing the device
  (bsc#1244145).
- commit 1415bb1

- s390/pci: Fix duplicate pci_dev_put() in disable_slot() when
  PF has child VFs (git-fixes bsc#1244145).
- commit 3430d11

- s390/pci: introduce lock to synchronize state of zpci_dev's
  (jsc#PED-10253 bsc#1244145).
- Refresh
  patches.suse/s390-pci-Fix-leak-of-struct-zpci_dev-when-zpci_add_device-fails.patch.
- Refresh
  patches.suse/s390-pci-Sort-PCI-functions-prior-to-creating-virtual-busses.patch.
- commit 2644b79

- s390/pci: rename lock member in struct zpci_dev (jsc#PED-10253
  bsc#1244145).
- Refresh
  patches.suse/s390-pci-Fix-leak-of-struct-zpci_dev-when-zpci_add_device-fails.patch.
- Refresh
  patches.suse/s390-pci-Sort-PCI-functions-prior-to-creating-virtual-busses.patch.
- Refresh
  patches.suse/s390-pci-Use-topology-ID-for-multi-function-devices.patch.
- commit 9223df0

- media: mediatek: vcodec: Only free buffer VA that is not NULL
  (CVE-2023-52888 bsc#1228557).
- commit 0299171

- drm/amd/display: Fix default DC and AC levels (bsc#1240650).
- drm/amd/display: Add debugging message for brightness caps
  (bsc#1240650).
- commit 5941cb0

- net: fix udp gso skb_segment after pull from frag_list
  (git-fixes).
- commit 8353437

- page_pool: Fix use-after-free in page_pool_recycle_in_ring
  (git-fixes).
- commit 69ccdcd

- net: Implement missing getsockopt(SO_TIMESTAMPING_NEW)
  (git-fixes).
- commit d107edf

- net: sched: em_text: fix possible memory leak in
  em_text_destroy() (git-fixes).
- commit 71395f7

- neighbour: Don't let neigh_forced_gc() disable preemption for
  long (git-fixes).
- commit fea49bb

- net: sched: cls_u32: Fix allocation size in u32_init()
  (git-fixes).
- commit eea3eab

- Move upstreamed patches into sorted section
- commit c9465fb

- kernel-source: Do not use multiple -r in sed parameters
  This usage is enabled in commit b18d64d
  (sed: allow multiple (non-conflicting) -E/-r parameters, 2016-07-31)
  only available since sed 4.3
  Fixes: dc2037cd8f94 (&amp;quot;kernel-source: Also replace bin/env&amp;quot;
- commit 91ad98e

- efi/libstub: Describe missing 'out' parameter in efi_load_initrd
  (git-fixes).
- drm/msm/dpu: Clear CTL_FETCH_PIPE_ACTIVE before blend setup
  (git-fixes).
- drm/msm/dpu: Clear CTL_FETCH_PIPE_ACTIVE on ctl_path reset
  (git-fixes).
- drm/msm/a6xx: Disable rgb565_predicator on Adreno 7c3
  (git-fixes).
- drm/msm/dpu: enable SmartDMA on SC8180X (git-fixes).
- drm/msm/dpu: enable SmartDMA on SM8150 (git-fixes).
- drm/panthor: Update panthor_mmu::irq::mask when needed
  (git-fixes).
- drm/panthor: Fix GPU_COHERENCY_ACE[_LITE] definitions
  (git-fixes).
- drm/panic: add missing space (git-fixes).
- drm/vmwgfx: Fix dumb buffer leak (git-fixes).
- drm/vmwgfx: Add error path for xa_store in
  vmw_bo_add_detached_resource (git-fixes).
- drm/xe/d3cold: Set power state to D3Cold during s2idle/s3
  (git-fixes).
- media: verisilicon: Free post processor buffers on error
  (git-fixes).
- media: platform: mtk-mdp3: Remove unused mdp_get_plat_device
  (git-fixes).
- media: intel/ipu6: Fix dma mask for non-secure mode (git-fixes).
- media: ov2740: Move pm-runtime cleanup on probe-errors to
  proper place (git-fixes).
- media: ipu6: Remove workaround for Meteor Lake ES2 (git-fixes).
- thermal/drivers/mediatek/lvts: Fix debugfs unregister on failure
  (git-fixes).
- drm/xe: Save the gt pointer in lrc and drop the tile
  (stable-fixes).
- wifi: mt76: mt7925: load the appropriate CLC data based on
  hardware type (stable-fixes).
- wifi: mt76: mt7925: fix fails to enter low power mode in
  suspend state (stable-fixes).
- wifi: rtw89: fw: get sb_sel_ver via get_unaligned_le32()
  (stable-fixes).
- wifi: rtw89: 8922a: fix incorrect STA-ID in EHT MU PPDU
  (stable-fixes).
- wifi: mwifiex: Fix HT40 bandwidth issue (stable-fixes).
- wifi: iwlwifi: mvm: fix setting the TK when associated
  (stable-fixes).
- wifi: iwlwifi: don't warn when if there is a FW error
  (stable-fixes).
- wifi: iwlwifi: w/a FW SMPS mode selection (stable-fixes).
- wifi: iwlwifi: mark Br device not integrated (stable-fixes).
- wifi: iwlwifi: fix the ECKV UEFI variable name (stable-fixes).
- wifi: mac80211: fix warning on disconnect during failed ML
  reconf (stable-fixes).
- wifi: mac80211_hwsim: Fix MLD address translation
  (stable-fixes).
- wifi: cfg80211: allow IR in 20 MHz configurations
  (stable-fixes).
- wifi: ath12k: fix the ampdu id fetch in the HAL_RX_MPDU_START
  TLV (stable-fixes).
- wifi: ath12k: Fetch regdb.bin file from board-2.bin
  (stable-fixes).
- wifi: rtw89: call power_on ahead before selecting firmware
  (stable-fixes).
- wifi: iwlwifi: use correct IMR dump variable (stable-fixes).
- wifi: iwlwifi: don't warn during reprobe (stable-fixes).
- wifi: mac80211: set ieee80211_prep_tx_info::link_id upon Auth Rx
  (stable-fixes).
- commit 33f1dc1

- drm/amd/display: Configure DTBCLK_P with OPTC only for dcn401
  (stable-fixes).
- Refresh
  patches.suse/drm-amd-display-prevent-hang-on-link-training-fail.patch.
- commit 063600f

- Bluetooth: btintel: Check dsbr size from EFI variable
  (git-fixes).
- Documentation: ACPI: Use all-string data node references
  (git-fixes).
- ASoC: mediatek: mt8195: Set ETDM1/2 IN/OUT to COMP_DUMMY()
  (git-fixes).
- ASoC: SOF: Intel: hda-bus: Use PIO mode on ACE2+ platforms
  (git-fixes).
- drm/xe/xe2hpg: Add Wa_22021007897 (stable-fixes).
- drm/amd/display: check stream id dml21 wrapper to get plane_id
  (stable-fixes).
- drm/amd/display: Defer BW-optimization-blocked DRR adjustments
  (git-fixes).
- drm/amd/display: Call FP Protect Before Mode Programming/Mode
  Support (stable-fixes).
- ASoC: cs42l43: Disable headphone clamps during type detection
  (stable-fixes).
- drm/amdgpu: Allow P2P access through XGMI (stable-fixes).
- drm/amdgpu/discovery: check ip_discovery fw file available
  (stable-fixes).
- drm/amdkfd: set precise mem ops caps to disabled for gfx 11
  and 12 (stable-fixes).
- drm/amdgpu: Skip pcie_replay_count sysfs creation for VF
  (stable-fixes).
- drm/amdgpu: release xcp_mgr on exit (stable-fixes).
- drm/amdgpu: adjust drm_firmware_drivers_only() handling
  (stable-fixes).
- drm/amdkfd: Correct F8_MODE for gfx950 (git-fixes).
- drm/amdgpu/gfx12: don't read registers in mqd init
  (stable-fixes).
- drm/amdgpu/gfx11: don't read registers in mqd init
  (stable-fixes).
- drm/amdgpu: Fix the race condition for draining retry fault
  (stable-fixes).
- drm/amd/display: Correct timing_adjust_pending flag setting
  (stable-fixes).
- drm/amd/display: calculate the remain segments for all pipes
  (stable-fixes).
- drm/amd/display: not abort link train when bw is low
  (stable-fixes).
- drm/amd/display: Do not enable replay when vtotal update is
  pending (stable-fixes).
- drm/xe: Nuke VM's mapping upon close (stable-fixes).
- drm/xe: Retry BO allocation (stable-fixes).
- drm/xe/vf: Retry sending MMIO request to GUC on timeout error
  (stable-fixes).
- drm/xe/pf: Create a link between PF and VF devices
  (stable-fixes).
- drm/xe: xe_gen_wa_oob: replace program_invocation_short_name
  (stable-fixes).
- drm/amdkfd: Set per-process flags only once for gfx9/10/11/12
  (stable-fixes).
- drm/amdgpu: Fix missing drain retry fault the last entry
  (stable-fixes).
- drm/amd/display: Ensure DMCUB idle before reset on DCN31/DCN35
  (stable-fixes).
- drm/amd/display: Fix DMUB reset sequence for DCN401
  (stable-fixes).
- drm/amd/display: Fix p-state type when p-state is unsupported
  (stable-fixes).
- drm/amd/display: Request HW cursor on DCN3.2 with SubVP
  (stable-fixes).
- drm/amd/display: handle max_downscale_src_width fail check
  (stable-fixes).
- drm/amd/display: fix dcn4x init failed (stable-fixes).
- drm/amdgpu: remove all KFD fences from the BO on release
  (stable-fixes).
- drm/xe/oa: Ensure that polled read returns latest data
  (stable-fixes).
- drm/xe: Stop ignoring errors from xe_ttm_stolen_mgr_init()
  (stable-fixes).
- drm/xe: Fix xe_tile_init_noalloc() error propagation
  (stable-fixes).
- drm/xe/debugfs: fixed the return value of wedged_mode_set
  (stable-fixes).
- drm/xe/debugfs: Add missing xe_pm_runtime_put in wedge_mode_set
  (stable-fixes).
- drm/xe/relay: Don't use GFP_KERNEL for new transactions
  (stable-fixes).
- drm/xe/pf: Reset GuC VF config when unprovisioning critical
  resource (stable-fixes).
- drm/xe: Move suballocator init to after display init
  (stable-fixes).
- drm/xe: Do not attempt to bootstrap VF in execlists mode
  (stable-fixes).
- drm/xe/sa: Always call drm_suballoc_manager_fini()
  (stable-fixes).
- drm/xe: Reject BO eviction if BO is bound to current VM
  (stable-fixes).
- drm/amd/pm: Fetch current power limit from PMFW (stable-fixes).
- drm/amd/display: Add support for disconnected eDP streams
  (stable-fixes).
- drm/amd/display: Guard against setting dispclk low when active
  (stable-fixes).
- drm/amd/display: Fix BT2020 YCbCr limited/full range input
  (stable-fixes).
- drm/amd/display: Read LTTPR ALPM caps during link cap retrieval
  (stable-fixes).
- drm/amd/display: Don't treat wb connector as physical in
  create_validate_stream_for_sink (stable-fixes).
- drm/amdgpu/mes11: fix set_hw_resources_1 calculation
  (stable-fixes).
- drm/amdkfd: fix missing L2 cache info in topology
  (stable-fixes).
- drm/amd/display: pass calculated dram_speed_mts to dml2
  (stable-fixes).
- drm/amd/pm: Skip P2S load for SMU v13.0.12 (stable-fixes).
- drm/amd/display: Support multiple options during psr entry
  (stable-fixes).
- drm/amd/display: Use Nominal vBlank If Provided Instead Of
  Capping It (stable-fixes).
- drm/amd/display: Populate register address for dentist for
  dcn401 (stable-fixes).
- drm/amdgpu: Use active umc info from discovery (stable-fixes).
- drm/rockchip: vop2: Improve display modes handling on RK3588
  HDMI0 (stable-fixes).
- drm/nouveau: fix the broken marco GSP_MSG_MAX_SIZE
  (stable-fixes).
- drm/buddy: fix issue that force_merge cannot free all roots
  (stable-fixes).
- commit c1bcb86

- Drop AMDGPU patch that may cause regressions (bsc#1243782)
  Deleted:
  patches.suse/drm-amd-display-more-liberal-vmin-vmax-update-for-fr.patch
- commit c23b99f

- wifi: ath12k: Avoid memory leak while enabling statistics
  (CVE-2025-37743 bsc#1242163).
- commit f493528

- PM: sleep: Fix power.is_suspended cleanup for direct-complete
  devices (git-fixes).
- net: wwan: t7xx: Fix napi rx poll issue (git-fixes).
- Bluetooth: L2CAP: Fix not responding with L2CAP_CR_LE_ENCRYPTION
  (git-fixes).
- Bluetooth: hci_qca: move the SoC type check to the right place
  (git-fixes).
- rtc: Fix offset calculation for .start_secs &amp;lt; 0 (git-fixes).
- rtc: stm32: drop unused module alias (git-fixes).
- rtc: s3c: drop unused module alias (git-fixes).
- rtc: pm8xxx: drop unused module alias (git-fixes).
- rtc: jz4740: drop unused module alias (git-fixes).
- rtc: da9063: drop unused module alias (git-fixes).
- rtc: cpcap: drop unused module alias (git-fixes).
- rtc: at91rm9200: drop unused module alias (git-fixes).
- rtc: sh: assign correct interrupts with DT (git-fixes).
- dmaengine: ti: Add NULL check in udma_probe() (git-fixes).
- phy: qcom-qmp-usb: Fix an NULL vs IS_ERR() bug (git-fixes).
- commit ec23ee6

- net: usb: aqc111: debug info before sanitation (git-fixes).
- commit fc18979

- openvswitch: Fix unsafe attribute parsing in output_userspace() (CVE-2025-37998 bsc#1243836)
- commit 51afd13

- octeon_ep: Fix host hang issue during device reboot (CVE-2025-37933 bsc#1243628)
- commit 44230dd

- kABI: ipv6: save dontfrag in cork (git-fixes).
  Patch-up the kABI change with an #ifdef __GENKSYMS__. This change is
  safe (as detailed in the patch commit message) due to the struct
  having a 6-byte hole at the end we can use.
- commit cbc81e2

- ipv6: save dontfrag in cork (git-fixes).
- commit d3fe600

- tcp: bring back NUMA dispersion in inet_ehash_locks_alloc()
  (git-fixes).
- commit 756fa72

- netpoll: hold rcu read lock in __netpoll_send_skb() (git-fixes).
- commit e02eac4

- ipvs: Always clear ipvs_property flag in skb_scrub_packet()
  (git-fixes).
- commit d943643

- tcp/dccp: allow a connection when sk_max_ack_backlog is zero
  (git-fixes).
- commit 09561a1

- xsk: always clear DMA mapping information when unmapping the
  pool (git-fixes).
- commit 9908bc6

- net: sched: fix erspan_opt settings in cls_flower (git-fixes).
- commit fc52734

- spi: spi-imx: Add check for spi_imx_setupxfer() (CVE-2025-37801 bsc#1242850)
- commit f3955e7

- ipmr: fix tables suspicious RCU usage (git-fixes).
- commit d029f0f

- ip6mr: fix tables suspicious RCU usage (git-fixes).
- commit 79bb134

- netpoll: Use rcu_access_pointer() in __netpoll_setup
  (git-fixes).
- commit f180c62

- netdev-genl: Hold rcu_read_lock in napi_get (git-fixes).
- commit 895e121

- net/neighbor: clear error in case strict check is not set
  (git-fixes).
- commit 9eb711a

- ipv4: Convert ip_route_input() to dscp_t (git-fixes).
- commit 401defe

- net: sched: consistently use rcu_replace_pointer() in
  taprio_change() (git-fixes).
- commit a6910eb

- udp: fix receiving fraglist GSO packets (git-fixes).
- commit 5b87500

- net: linkwatch: use system_unbound_wq (git-fixes).
- commit 34d590e

- net: page_pool: fix warning code (git-fixes).
- commit 0d77245

- net: give more chances to rcu in netdev_wait_allrefs_any()
  (git-fixes).
- commit a1b1859

- tcp/dccp: complete lockless accesses to sk-&amp;gt;sk_max_ack_backlog
  (git-fixes).
- commit b96b4a8

- tcp/dccp: bypass empty buckets in inet_twsk_purge() (git-fixes).
- commit afdb9bb

- udp: preserve the connected status if only UDP cmsg (git-fixes).
- commit 8714e3a

- udp: fix incorrect parameter validation in the
  udp_lib_getsockopt() function (git-fixes).
- commit 34a2994

- ipmr: fix incorrect parameter validation in the
  ip_mroute_getsockopt() function (git-fixes).
- commit f23f4c9

- ip_tunnel: annotate data-races around t-&amp;gt;parms.link (git-fixes).
- commit 765e083

- net: add rcu safety to rtnl_prop_list_size() (git-fixes).
- commit 1e0fceb

- net: ipv4: fix a memleak in ip_setup_cork (git-fixes).
- commit 935ac41

- udp: annotate data-races around up-&amp;gt;pending (git-fixes).
- commit 72fda93

- ipv4: Correct/silence an endian warning in __ip_do_redirect
  (git-fixes).
- commit 011b9c9

- driver core: fix potential NULL pointer dereference in
  dev_uevent() (CVE-2025-37800 bsc#1242849).
- driver core: introduce device_set_driver() helper
  (CVE-2025-37800 bsc#1242849).
- commit 3aecdc2

- soc: qcom: smp2p: Fix fallback to qcom,ipc parse (git-fixes).
- commit a145886

- wifi: mt76: mt7996: fix RX buffer size of MCU event (git-fixes).
- wifi: mt76: mt7996: set EHT max ampdu length capability
  (git-fixes).
- wifi: mt76: mt7925: ensure all MCU commands wait for response
  (git-fixes).
- wifi: mt76: mt7925: refine the sniffer commnad (git-fixes).
- wifi: mt76: mt7925: prevent multiple scan commands (git-fixes).
- wifi: mt76: mt7915: Fix null-ptr-deref in mt7915_mmio_wed_init()
  (git-fixes).
- wifi: mt76: mt7925: fix host interrupt register initialization
  (git-fixes).
- Revert &amp;quot;wifi: mt76: mt7996: fill txd by host driver&amp;quot;
  (stable-fixes).
- wifi: ath9k_htc: Abort software beacon handling if disabled
  (git-fixes).
- wifi: ath12k: fix ring-buffer corruption (git-fixes).
- wifi: ath11k: fix rx completion meta data corruption
  (git-fixes).
- wifi: ath11k: fix ring-buffer corruption (git-fixes).
- wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()
  (git-fixes).
- wifi: rtw88: fix the 'para' buffer size to avoid reading out
  of bounds (git-fixes).
- wifi: rtw88: usb: Reduce control message timeout to 500 ms
  (git-fixes).
- wifi: rtw89: pci: enlarge retry times of RX tag to 1000
  (git-fixes).
- wifi: rtlwifi: disable ASPM for RTL8723BE with subsystem ID
  11ad:1723 (git-fixes).
- wifi: rtw88: do not ignore hardware read error during DPK
  (git-fixes).
- wifi: rtw88: sdio: call rtw_sdio_indicate_tx_status
  unconditionally (git-fixes).
- wifi: rtw88: sdio: map mgmt frames to queue TX_DESC_QSEL_MGMT
  (git-fixes).
- wifi: iwlfiwi: mvm: Fix the rate reporting (git-fixes).
- wifi: ath12k: fix node corruption in ar-&amp;gt;arvifs list
  (git-fixes).
- wifi: ath12k: Fix the QoS control field offset to build QoS
  header (git-fixes).
- commit 3f5d0e4

- wifi: mt76: only mark tx-status-failed frames as ACKed on
  mt76x0/2 (stable-fixes).
- commit 0de0b80

- wifi: ath12k: Add MSDU length validation for TKIP MIC error
  (git-fixes).
- wifi: ath12k: fix invalid access to memory (git-fixes).
- wifi: ath12k: Fix WMI tag for EHT rate in peer assoc
  (git-fixes).
- wifi: ath12k: fix cleanup path after mhi init (git-fixes).
- wifi: ath12k: Fix invalid memory access while forming 802.11
  header (git-fixes).
- wifi: ath12k: Fix memory leak during vdev_id mismatch
  (git-fixes).
- wifi: ath11k: fix node corruption in ar-&amp;gt;arvifs list
  (git-fixes).
- watchdog: exar: Shorten identity name to fit correctly
  (git-fixes).
- wifi: iwlwifi: add support for Killer on MTL (stable-fixes).
- wifi: mt76: mt7996: revise TXS size (stable-fixes).
- wifi: rtw88: Fix rtw_init_vht_cap() for RTL8814AU
  (stable-fixes).
- wifi: rtw88: Fix rtw_init_ht_cap() for RTL8814AU (stable-fixes).
- wifi: rtw88: Fix rtw_desc_to_mcsrate() to handle MCS16-31
  (stable-fixes).
- wifi: rtw89: fw: propagate error code from rtw89_h2c_tx()
  (stable-fixes).
- wifi: iwlwifi: fix debug actions order (stable-fixes).
- wifi: ath12k: Report proper tx completion status to mac80211
  (stable-fixes).
- wifi: ath12k: Improve BSS discovery with hidden SSID in 6 GHz
  band (stable-fixes).
- wifi: ath12k: Avoid napi_sync() before napi_enable()
  (stable-fixes).
- wifi: ath12k: fix ath12k_hal_tx_cmd_ext_desc_setup() info1
  override (stable-fixes).
- wifi: ath9k: return by of_get_mac_address (stable-fixes).
- wifi: ath12k: Fix end offset bit definition in monitor ring
  descriptor (stable-fixes).
- wifi: rtw88: Fix download_firmware_validate() for RTL8814AU
  (stable-fixes).
- wifi: rtw88: Fix __rtw_download_firmware() for RTL8814AU
  (stable-fixes).
- wifi: rtw88: Don't use static local variable in
  rtw8822b_set_tx_power_index_by_rate (stable-fixes).
- wifi: rtw89: add wiphy_lock() to work that isn't held
  wiphy_lock() yet (stable-fixes).
- wifi: mac80211: don't unconditionally call drv_mgd_complete_tx()
  (stable-fixes).
- wifi: mac80211: remove misplaced drv_mgd_complete_tx() call
  (stable-fixes).
- commit 9963350

- vgacon: Add check for vc_origin address range in vgacon_scroll()
  (git-fixes).
- soc: aspeed: Add NULL check in aspeed_lpc_enable_snoop()
  (git-fixes).
- soc: aspeed: lpc: Fix impossible judgment condition (git-fixes).
- spi: sh-msiof: Fix maximum DMA transfer size (git-fixes).
- spi: tegra210-quad: modify chip select (CS) deactivation
  (git-fixes).
- spi: tegra210-quad: remove redundant error handling code
  (git-fixes).
- spi: tegra210-quad: Fix X1_X2_X4 encoding and support x4
  transfers (git-fixes).
- spi: spi-sun4i: fix early activation (stable-fixes).
- spi-rockchip: Fix register out of bounds access (stable-fixes).
- thunderbolt: Do not add non-active NVM if NVM upgrade is
  disabled for retimer (stable-fixes).
- usb: xhci: Don't change the status of stalled TDs on failed
  Stop EP (stable-fixes).
- serial: sh-sci: Save and restore more registers (git-fixes).
- serial: sh-sci: Update the suspend/resume support
  (stable-fixes).
- thermal/drivers/qoriq: Power down TMU on system suspend
  (stable-fixes).
- soundwire: amd: change the soundwire wake enable/disable
  sequence (stable-fixes).
- soc: ti: k3-socinfo: Do not use syscon helper to build regmap
  (stable-fixes).
- spi: zynqmp-gqspi: Always acknowledge interrupts (stable-fixes).
- commit 38d0a8f

- PM: sleep: Print PM debug messages during hibernation
  (git-fixes).
- commit 96179c7

- PCI: dw-rockchip: Fix PHY function call sequence in
  rockchip_pcie_phy_deinit() (git-fixes).
- PCI: cadence: Fix runtime atomic count underflow (git-fixes).
- PCI: apple: Use gpiod_set_value_cansleep in probe flow
  (git-fixes).
- PCI: cadence-ep: Correct PBA offset in .set_msix() callback
  (git-fixes).
- PCI: Fix lock symmetry in pci_slot_unlock() (git-fixes).
- PCI: Explicitly put devices into D0 when initializing
  (git-fixes).
- PCI/DPC: Initialize aer_err_info before using it (git-fixes).
- selftests/mm: restore default nr_hugepages value during cleanup
  in hugetlb_reparenting_test.sh (git-fixes).
- pinctrl: armada-37xx: set GPIO output value before setting
  direction (git-fixes).
- pinctrl: armada-37xx: use correct OUTPUT_VAL register for
  GPIOs &amp;gt; 31 (git-fixes).
- pinctrl: at91: Fix possible out-of-boundary access (git-fixes).
- selftests/bpf: Fix bpf_nf selftest failure (git-fixes).
- selftests/seccomp: fix syscall_restart test for arm compat
  (git-fixes).
- PM: wakeup: Delete space in the end of string shown by
  pm_show_wakelocks() (git-fixes).
- power: reset: at91-reset: Optimize at91_reset() (git-fixes).
- regulator: max20086: Change enable gpio to optional (git-fixes).
- regulator: max20086: Fix MAX200086 chip id (git-fixes).
- platform/x86: thinkpad_acpi: Ignore battery threshold change
  event notification (stable-fixes).
- platform/x86: fujitsu-laptop: Support Lifebook S2110 hotkeys
  (stable-fixes).
- phy: renesas: rcar-gen3-usb2: Assert PLL reset on PHY power off
  (git-fixes).
- phy: renesas: rcar-gen3-usb2: Lock around hardware registers
  and driver data (git-fixes).
- phy: renesas: rcar-gen3-usb2: Move IRQ request in probe
  (stable-fixes).
- platform/x86: thinkpad_acpi: Support also NEC Lavie X1475JAS
  (stable-fixes).
- pinctrl: meson: define the pull up/down resistor value as 60
  kOhm (stable-fixes).
- rtc: rv3032: fix EERD location (stable-fixes).
- rtc: ds1307: stop disabling alarms on probe (stable-fixes).
- phy: core: don't require set_mode() callback for phy_get_mode()
  to work (stable-fixes).
- pinctrl: tegra: Fix off by one in tegra_pinctrl_get_group()
  (git-fixes).
- pinctrl-tegra: Restore SFSEL bit when freeing pins
  (stable-fixes).
- pinctrl: bcm281xx: Use &amp;quot;unsigned int&amp;quot; instead of bare &amp;quot;unsigned&amp;quot;
  (stable-fixes).
- pinctrl: devicetree: do not goto err when probing hogs in
  pinctrl_dt_to_map (stable-fixes).
- PCI: dwc: ep: Ensure proper iteration over outbound map windows
  (stable-fixes).
- PCI: brcmstb: Expand inbound window size up to 64GB
  (stable-fixes).
- PCI: brcmstb: Add a softdep to MIP MSI-X driver (stable-fixes).
- PCI: Fix old_size lower bound in calculate_iosize() too
  (stable-fixes).
- selftests/net: have `gro.sh -t` return a correct exit code
  (stable-fixes).
- regulator: ad5398: Add device tree support (stable-fixes).
- PCI: vmd: Disable MSI remapping bypass under Xen (stable-fixes).
- phy: renesas: rcar-gen3-usb2: Add support to initialize the bus
  (stable-fixes).
- commit 32a9142

- tcp_metrics: optimize tcp_metrics_flush_all() (git-fixes).
- commit 2a9c7bb

- mtd: rawnand: sunxi: Add randomizer configuration in
  sunxi_nfc_hw_ecc_write_chunk (git-fixes).
- mtd: nand: sunxi: Add randomizer configuration before randomizer
  enable (git-fixes).
- mtd: nand: ecc-mxic: Fix use of uninitialized variable ret
  (git-fixes).
- net: phy: mscc: Stop clearing the the UDPv4 checksum for L2
  frames (git-fixes).
- net: phy: mscc: Fix memory leak when using one step timestamping
  (git-fixes).
- net: phy: clear phydev-&amp;gt;devlink when the link is deleted
  (git-fixes).
- net: phy: fix up const issues in to_mdio_device() and
  to_phy_device() (git-fixes).
- net: usb: aqc111: fix error handling of usbnet read calls
  (git-fixes).
- mmc: host: Wait for Vdd to settle on card power off
  (stable-fixes).
- mmc: dw_mmc: add exynos7870 DW MMC support (stable-fixes).
- commit eedda90

- mfd: stmpe-spi: Correct the name used in MODULE_DEVICE_TABLE
  (git-fixes).
- mfd: exynos-lpass: Avoid calling exynos_lpass_disable() twice
  in exynos_lpass_remove() (git-fixes).
- media: uvcvideo: Fix deferred probing error (git-fixes).
- media: uvcvideo: Return the number of processed controls
  (git-fixes).
- media: omap3isp: use sgtable-based scatterlist wrappers
  (git-fixes).
- media: videobuf2: use sgtable-based scatterlist wrappers
  (git-fixes).
- media: v4l2-dev: fix error handling in __video_register_device()
  (git-fixes).
- media: ov8856: suppress probe deferral errors (git-fixes).
- media: ov5675: suppress probe deferral errors (git-fixes).
- media: nxp: imx8-isi: better handle the m2m usage_count
  (git-fixes).
- media: gspca: Add error handling for stv06xx_read_sensor()
  (git-fixes).
- media: davinci: vpif: Fix memory leak in probe error path
  (git-fixes).
- media: vivid: Change the siize of the composing (git-fixes).
- media: cxusb: no longer judge rbuf when the write fails
  (git-fixes).
- media: vidtv: Terminating the subsequent process of
  initialization failure (git-fixes).
- media: ccs-pll: Correct the upper limit of maximum
  op_pre_pll_clk_div (git-fixes).
- media: ccs-pll: Check for too high VT PLL multiplier in dual
  PLL case (git-fixes).
- media: ccs-pll: Start VT pre-PLL multiplier search from correct
  value (git-fixes).
- media: ccs-pll: Start OP pre-PLL multiplier search from correct
  value (git-fixes).
- media: imx-jpeg: Cleanup after an allocation error (git-fixes).
- media: imx-jpeg: Reset slot data pointers when freed
  (git-fixes).
- media: imx-jpeg: Move mxc_jpeg_free_slot_data() ahead
  (git-fixes).
- media: imx-jpeg: Drop the first error frames (git-fixes).
- media: venus: Fix probe error handling (git-fixes).
- media: rkvdec: Fix frame size enumeration (git-fixes).
- mfd: tps65219: Remove TPS65219_REG_TI_DEV_ID check
  (stable-fixes).
- media: c8sectpfe: Call of_node_put(i2c_bus) only once in
  c8sectpfe_probe() (stable-fixes).
- media: cx231xx: set device_caps for 417 (stable-fixes).
- media: uvcvideo: Add sanity check to uvc_ioctl_xu_ctrl_map
  (stable-fixes).
- media: uvcvideo: Handle uvc menu translation inside
  uvc_get_le_value (stable-fixes).
- media: adv7180: Disable test-pattern control on adv7180
  (stable-fixes).
- media: tc358746: improve calculation of the D-PHY timing
  registers (stable-fixes).
- media: test-drivers: vivid: don't call schedule in loop
  (stable-fixes).
- media: i2c: imx219: Correct the minimum vblanking value
  (stable-fixes).
- media: v4l: Memset argument to 0 before calling get_mbus_config
  pad op (stable-fixes).
- media: qcom: camss: csid: Only add TPG v4l2 ctrl if TPG hardware
  is available (stable-fixes).
- mmc: sdhci: Disable SD card clock before changing parameters
  (stable-fixes).
- commit de6c9a2

- Input: gpio-keys - fix possible concurrent access in
  gpio_keys_irq_timer() (git-fixes).
- commit e29f865

- hwmon: (asus-ec-sensors) check sensor index in read_string()
  (git-fixes).
- Input: ims-pcu - check record size in ims_pcu_flash_firmware()
  (git-fixes).
- firmware: psci: Fix refcount leak in psci_dt_init (git-fixes).
- gpiolib: Revert &amp;quot;Don't WARN on gpiod_put() for optional GPIO&amp;quot;
  (stable-fixes).
- Input: xpad - add more controllers (stable-fixes).
- gpio: pca953x: fix IRQ storm on system wake up (git-fixes).
- HID: quirks: Add ADATA XPG alpha wireless mouse support
  (stable-fixes).
- intel_th: avoid using deprecated page-&amp;gt;mapping, index fields
  (stable-fixes).
- ima: process_measurement() needlessly takes inode_lock()
  on MAY_READ (stable-fixes).
- i3c: master: svc: Fix implicit fallthrough in
  svc_i3c_master_ibi_work() (git-fixes).
- i3c: master: svc: Fix missing STOP for master request
  (stable-fixes).
- i3c: master: svc: Flush FIFO before sending Dynamic Address
  Assignment(DAA) (stable-fixes).
- i2c: qup: Vote for interconnect bandwidth to DRAM
  (stable-fixes).
- i2c: pxa: fix call balance of i2c-&amp;gt;clk handling routines
  (stable-fixes).
- fpga: altera-cvp: Increase credit timeout (stable-fixes).
- mailbox: use error ret code of of_parse_phandle_with_args()
  (stable-fixes).
- leds: pwm-multicolor: Add check for fwnode_property_read_u32
  (stable-fixes).
- firmware: arm_ffa: Set dma_mask for ffa devices (stable-fixes).
- firmware: arm_ffa: Reject higher major version as incompatible
  (stable-fixes).
- ieee802154: ca8210: Use proper setters and getters for bitwise
  types (stable-fixes).
- HID: usbkbd: Fix the bit shift number for LED_KANA
  (stable-fixes).
- hwmon: (dell-smm) Increment the number of fans (stable-fixes).
- hwmon: (gpio-fan) Add missing mutex locks (stable-fixes).
- hwmon: (xgene-hwmon) use appropriate type for the latency value
  (stable-fixes).
- gpio: pca953x: Simplify code with cleanup helpers
  (stable-fixes).
- gpio: pca953x: Split pca953x_restore_context() and
  pca953x_save_context() (stable-fixes).
- commit 50f84af

- fbdev: Fix fb_set_var to prevent null-ptr-deref in
  fb_videomode_to_var (git-fixes).
- fbdev: Fix do_register_framebuffer to prevent null-ptr-deref
  in fb_videomode_to_var (git-fixes).
- fbdev: core: fbcvt: avoid division by 0 in fb_cvt_hperiod()
  (git-fixes).
- drm/msm/gpu: Fix crash when throttling GPU immediately during
  boot (git-fixes).
- drm/mediatek: mtk_drm_drv: Unbind secondary mmsys components
  on err (git-fixes).
- drm/mediatek: Fix kobject put for component sub-drivers
  (git-fixes).
- drm/mediatek: mtk_drm_drv: Fix kobject put for mtk_mutex device
  ptr (git-fixes).
- Revert &amp;quot;drm/amdgpu: don't allow userspace to create a doorbell
  BO&amp;quot; (stable-fixes).
- drm/amd/pp: Fix potential NULL pointer dereference in
  atomctrl_initialize_mc_reg_table (git-fixes).
- drm/tegra: Fix a possible null pointer dereference (git-fixes).
- drm/tegra: rgb: Fix the unbound reference count (git-fixes).
- drm/tegra: Assign plane type before registration (git-fixes).
- drm/vkms: Adjust vkms_state-&amp;gt;active_planes allocation type
  (git-fixes).
- drm: rcar-du: Fix memory leak in rcar_du_vsps_init()
  (git-fixes).
- drm/bridge: lt9611uxc: Fix an error handling path in
  lt9611uxc_probe() (git-fixes).
- drm/panel: samsung-sofef00: Drop s6e3fc2x01 support (git-fixes).
- drm/ast: Fix comment on modeset lock (git-fixes).
- drm/vc4: tests: Use return instead of assert (git-fixes).
- drm/bridge: cdns-dsi: Wait for Clk and Data Lanes to be ready
  (git-fixes).
- drm/bridge: cdns-dsi: Check return value when getting default
  PHY config (git-fixes).
- drm/bridge: cdns-dsi: Fix the clock variable for mode_valid()
  (git-fixes).
- drm/bridge: cdns-dsi: Fix phy de-init and flag it so
  (git-fixes).
- drm/bridge: cdns-dsi: Fix connecting to next bridge (git-fixes).
- drm/udl: Unregister device before cleaning up on disconnect
  (git-fixes).
- drm/vmwgfx: Add seqno waiter for sync_files (git-fixes).
- Documentation/rtla: Fix typo in common_timerlat_description.rst
  (git-fixes).
- Documentation/rtla: Fix typo in rtla-timerlat.rst (git-fixes).
- drm/amd/display: fix link_set_dpms_off multi-display MST corner
  case (stable-fixes).
- drm/amd/display: Guard against setting dispclk low for dcn31x
  (stable-fixes).
- drm/amdgpu: Update SRIOV video codec caps (stable-fixes).
- drm/amd/display: remove minimum Dispclk and apply oem panel
  timing (stable-fixes).
- drm/amd/display: Fix incorrect DPCD configs while Replay/PSR
  switch (stable-fixes).
- drm/mediatek: mtk_dpi: Add checks for reg_h_fre_con existence
  (stable-fixes).
- drm/amdkfd: Set per-process flags only once cik/vi
  (stable-fixes).
- drm/amdgpu: Do not program AGP BAR regs under SRIOV in
  gfxhub_v1_0.c (stable-fixes).
- drm/amd/display: Skip checking FRL_MODE bit for PCON BW
  determination (stable-fixes).
- drm/amdkfd: KFD release_work possible circular locking
  (stable-fixes).
- drm/rockchip: vop2: Add uv swap for cluster window
  (stable-fixes).
- drm/amdgpu: Set snoop bit for SDMA for MI series (stable-fixes).
- drm/amd/display: Don't try AUX transactions on disconnected link
  (stable-fixes).
- drm/amdgpu: reset psp-&amp;gt;cmd to NULL after releasing the buffer
  (stable-fixes).
- drm/amd/display: Update CR AUX RD interval interpretation
  (stable-fixes).
- drm/amd/display: Initial psr_version with correct setting
  (stable-fixes).
- drm/amd/display: Increase block_sequence array size
  (stable-fixes).
- drm/amdgpu: enlarge the VBIOS binary size limit (stable-fixes).
- drm/amd/display/dm: drop hw_support check in
  amdgpu_dm_i2c_xfer() (stable-fixes).
- drm/v3d: Add clock handling (stable-fixes).
- drm/ast: Find VBIOS mode from regular display size
  (stable-fixes).
- drm: bridge: adv7511: fill stream capabilities (stable-fixes).
- drm/atomic: clarify the rules around
  drm_atomic_state-&amp;gt;allow_modeset (stable-fixes).
- drm/panel-edp: Add Starry 116KHD024006 (stable-fixes).
- drm: Add valid clones check (stable-fixes).
- fbdev: fsl-diu-fb: add missing device_remove_file()
  (stable-fixes).
- fbcon: Use correct erase colour for clearing in fbcon
  (stable-fixes).
- fbdev: core: tileblit: Implement missing margin clearing for
  tileblit (stable-fixes).
- firmware: arm_scmi: Relax duplicate name constraint across
  protocol ids (stable-fixes).
- commit 0574d41

- Documentation/rtla: Fix duplicate text about timerlat tracer
  (git-fixes).
- crypto: marvell/cesa - Do not chain submitted requests
  (git-fixes).
- crypto: sun8i-ce - move fallback ahash_request to the end of
  the struct (git-fixes).
- crypto: xts - Only add ecb if it is not already there
  (git-fixes).
- crypto: lrw - Only add ecb if it is not already there
  (git-fixes).
- crypto: marvell/cesa - Avoid empty transfer descriptor
  (git-fixes).
- crypto: marvell/cesa - Handle zero-length skcipher requests
  (git-fixes).
- crypto: sun8i-ss - do not use sg_dma_len before calling DMA
  functions (git-fixes).
- Documentation: fix typo in root= kernel parameter description
  (git-fixes).
- dmaengine: idxd: cdev: Fix uninitialized use of sva in
  idxd_cdev_open (stable-fixes).
- commit 8e41cce

- backlight: pm8941: Add NULL check in wled_configure()
  (git-fixes).
- bus: fsl-mc: fix GET/SET_TAILDROP command ids (git-fixes).
- bus: fsl-mc: do not add a device-link for the UAPI used DPMCP
  device (git-fixes).
- bus: fsl-mc: fix double-free on mc_dev (git-fixes).
- Revert &amp;quot;bus: ti-sysc: Probe for l4_wkup and l4_cfg interconnect
  devices first&amp;quot; (stable-fixes).
- Bluetooth: MGMT: iterate over mesh commands in
  mgmt_mesh_foreach() (git-fixes).
- ASoC: qcom: sdm845: Add error handling in
  sdm845_slim_snd_hw_params() (git-fixes).
- ASoC: apple: mca: Constrain channels according to TDM mask
  (git-fixes).
- ASoC: SOF: ipc4-pcm: Adjust pipeline_list-&amp;gt;pipelines allocation
  type (git-fixes).
- crypto: sun8i-ce-cipher - fix error handling in
  sun8i_ce_cipher_prepare() (git-fixes).
- crypto: qat - add shutdown handler to qat_420xx (git-fixes).
- crypto: qat - add shutdown handler to qat_4xxx (git-fixes).
- crypto: octeontx2 - suppress auth failure screaming due to
  negative tests (stable-fixes).
- crypto: lzo - Fix compression buffer overrun (stable-fixes).
- crypto: skcipher - Zap type in crypto_alloc_sync_skcipher
  (stable-fixes).
- can: c_can: Use of_property_present() to test existence of DT
  property (stable-fixes).
- commit 595e083

- ASoC: meson: meson-card-utils: use of_property_present()
  for DT parsing (git-fixes).
- ASoC: tas2764: Enable main IRQs (git-fixes).
- ASoC: tas2764: Reinit cache on part reset (git-fixes).
- ASoC: Intel: bytcr_rt5640: Add DMI quirk for Acer Aspire SW3-013
  (stable-fixes).
- ASoC: imx-card: Adjust over allocation of memory in
  imx_card_parse_of() (stable-fixes).
- ASoC: mediatek: mt6359: Add stub for
  mt6359_accdet_enable_jack_detect (stable-fixes).
- ASoC: sun4i-codec: support hp-det-gpios property (stable-fixes).
- ASoC: qcom: sm8250: explicitly set format in
  sm8250_be_hw_params_fixup() (stable-fixes).
- ASoC: mediatek: mt8188: Treat DMIC_GAINx_CUR as non-volatile
  (stable-fixes).
- ASoC: mediatek: mt8188: Add reference for dmic clocks
  (stable-fixes).
- commit 255f2cb

- ALSA: hda/realtek: Add quirk for Lenovo Yoga Pro 7 14ASP10
  (stable-fixes).
- ALSA: pcm: Fix race of buffer access at PCM OSS layer
  (stable-fixes).
- ALSA: hda/realtek: Add quirk for HP Spectre x360 15-df1xxx
  (stable-fixes).
- ASoC: soc-dai: check return value at snd_soc_dai_set_tdm_slot()
  (stable-fixes).
- ASoC: tas2764: Add reg defaults for TAS2764_INT_CLK_CFG
  (stable-fixes).
- ASoC: tas2764: Mark SW_RESET as volatile (stable-fixes).
- ASoC: tas2764: Power up/down amp on mute ops (stable-fixes).
- ASoC: ops: Enforce platform maximum on initial value
  (stable-fixes).
- ASoC: codecs: pcm3168a: Allow for 24-bit in provider mode
  (stable-fixes).
- ASoC: rt722-sdca: Add some missing readable registers
  (stable-fixes).
- commit ab5fcf6

- kABI workaround for hda_codec.beep_just_power_on flag
  (git-fixes).
- commit 11aaa35

- acpi-cpufreq: Fix nominal_freq units to KHz in
  get_max_boost_ratio() (git-fixes).
- ACPICA: Utilities: Fix spelling mistake &amp;quot;Incremement&amp;quot; -&amp;gt;
  &amp;quot;Increment&amp;quot; (git-fixes).
- ACPICA: exserial: don't forget to handle FFixedHW opregions
  for reading (git-fixes).
- ACPI: OSI: Stop advertising support for &amp;quot;3.0 _SCP Extensions&amp;quot;
  (git-fixes).
- ACPI: PNP: Add Intel OC Watchdog IDs to non-PNP device list
  (stable-fixes).
- accel/qaic: Mask out SR-IOV PCI resources (stable-fixes).
- ALSA: seq: Improve data consistency at polling (stable-fixes).
- ALSA: hda/realtek: Enable PC beep passthrough for HP EliteBook
  855 G7 (stable-fixes).
- ACPI: HED: Always initialize before evged (stable-fixes).
- commit 6ebe577

- net: ethernet: mtk-star-emac: fix spinlock recursion issues
  on rx/tx poll (CVE-2025-37917 bsc#1243475).
- commit 0f659f2

- usb: typec: ucsi: limit the UCSI_NO_PARTNER_PDOS even further
  (git-fixes).
- commit bae0091

- usb: typec: ucsi: allow non-partner GET_PDOS for Qualcomm
  devices (git-fixes).
- commit a0506dd

- usb: typec: ucsi: Only enable supported notifications
  (git-fixes).
- commit 3a52706

- usb: typec: ucsi: fix UCSI on buggy Qualcomm devices
  (git-fixes).
- commit 5ca6578

- platform/x86: fujitsu-laptop: Support Lifebook S2110 hotkeys
  (git-fixes).
- commit 1564858

- platform/x86: thinkpad_acpi: Support also NEC Lavie X1475JAS
  (git-fixes).
- commit 2bfd2a7

- pstore: Change kmsg_bytes storage size to u32 (git-fixes).
- commit c964f36

- orangefs: Do not truncate file size (git-fixes).
- commit 9fbe3ae

- NFSv4: Check for delegation validity in
  nfs_start_delegation_return_locked() (git-fixes).
- commit a689f10

- NFS: Don't allow waiting for exiting tasks (git-fixes).
- Refresh
  patches.suse/nfs-add-missing-selections-of-CONFIG_CRC32.patch.
- commit 899f47c

- SUNRPC: Don't allow waiting for exiting tasks (git-fixes).
- commit 8b942ca

- NFSv4: Treat ENETUNREACH errors as fatal for state recovery
  (git-fixes).
- commit 9139fd5

- SUNRPC: rpc_clnt_set_transport() must not change the autobind
  setting (git-fixes).
- commit e2112a4

- SUNRPC: rpcbind should never reset the port to the value '0'
  (git-fixes).
- commit f49c9db

- pNFS/flexfiles: Report ENETDOWN as a connection error
  (git-fixes).
- commit 39e7a29

- iommu: Protect against overflow in iommu_pgsize() (git-fixes).
- commit 6adbec5

- ext4: define ext4_journal_destroy wrapper (CVE-2025-22113
  bsc#1241617).
- commit 8dddf47

- ext4: ignore xattrs past end (bsc#1242846 CVE-2025-37738).
- commit 2a74454

- ext4: avoid journaling sb update on error if journal is
  destroying (bsc#1241617 CVE-2025-22113).
- commit 0445179

- xhci: dbc: Avoid event polling busyloop if pending rx transfers
  are inactive (git-fixes).
- commit 7bb46ec

- usb: misc: onboard_usb_dev: fix support for Cypress HX3 hubs
  (git-fixes).
- commit b84bbc1

- net/smc: check v2_ext_offset/eid_cnt/ism_gid_cnt when receiving
  proposal msg (CVE-2024-49568 bsc#1235728).
- commit a7c2f15

- i2c: tegra: check msg length in SMBUS block read (bsc#1242086)
- commit 625407a

- iio: light: opt3001: fix deadlock due to concurrent flag access (CVE-2025-37968 bsc#1243571)
- commit 0e5e655

- perf/x86/intel: KVM: Mask PEBS_ENABLE loaded for guest with vCPU's value (CVE-2025-37936 bsc#1243537)
- commit 2e13950

- net: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHY (CVE-2025-37945 bsc#1243538)
- commit efc17f3

- pds_core: Prevent possible adminq overflow/stuck condition (CVE-2025-37987 bsc#1243542)
- commit ba1ea39

- SUNRPC: Prevent hang on NFS mount with xprtsec=[m]tls
  (git-fixes).
- commit dc6e86f

- Refresh
  patches.suse/nfs-ignore-SB_RDONLY-when-remounting-nfs.patch.
- commit 359f356

- Refresh
  patches.suse/nfs-clear-SB_RDONLY-before-getting-superblock.patch.
- commit 2697e51

- fs/nfs/read: fix double-unlock bug in nfs_return_empty_folio()
  (git-fixes).
- commit fcf1703

- powerpc/pseries/msi: Avoid reading PCI device registers in
  reduced power states (bsc#1215199).
- KVM: powerpc: Enable commented out BUILD_BUG_ON() assertion
  (bsc#1215199).
- commit 2d2709b

- IB/cm: Drop lockdep assert and WARN when freeing old msg (git-fixes)
- commit 80fb173

- Update patches.suse/nfsd-Fix-race-to-FREE_STATEID-and-cl_revoked.patch
  (bsc#1012628 CVE-2024-50106 bsc#1232882).
- commit a87a308

- iommu/tegra241-cmdqv: Fix warnings due to  dmam_free_coherent()
  (CVE-2025-37837 bsc#1242952).
- commit 0f31b68

- net: ngbe: fix memory leak in ngbe_probe() error path (CVE-2025-37874 bsc#1242940)
- commit bc2e64d

- smb: client: fix hang in wait_for_response() for negproto
  (bsc#1242709).
- commit 709cb2e

- net: dsa: mv88e6xxx: fix -ENOENT when deleting VLANs and MST is unsupported (CVE-2025-37865 bsc#1242954)
- commit 885d04c

- HID: pidff: Fix null pointer dereference in pidff_find_fields (CVE-2025-37862 bsc#1242982)
- commit f9d615e

- usb: chipidea: ci_hdrc_imx: fix usbmisc handling (CVE-2025-37811 bsc#1242907)
- commit 1f2ed79

- mptcp: fix 'scheduling while atomic' in
  mptcp_pm_nl_append_new_local_addr (git-fixes CVE-2025-21938
  bsc#1240723).
- commit 02ff1ac

- usb: typec: ucsi: displayport: Fix deadlock (bsc#1243572
  CVE-2025-37967).
- commit 59ea04d

- kABI workaround for adding an header (CVE-2025-21868
  bsc#1240180).
- commit 8687a45

- powerpc/pseries/dlpar: Search DRC index from ibm,drc-indexes
  for IO add (bsc#1243042 ltc#212167).
- commit a5aefbc

- cifs: avoid NULL pointer dereference in dbg call (CVE-2025-37844 bsc#1242946)
- commit 031bdce

- Update
  patches.suse/ASoC-simple-card-utils-Fix-pointer-check-in-graph_ut.patch
  (git-fixes CVE-2025-37934 bsc#1243548).
- Update
  patches.suse/accel-ivpu-Fix-PM-related-deadlocks-in-MS-IOCTLs.patch
  (git-fixes CVE-2025-37848 bsc#1242943).
- Update
  patches.suse/accel-ivpu-Fix-deadlock-in-ivpu_ms_cleanup.patch
  (git-fixes CVE-2025-37847 bsc#1242947).
- Update
  patches.suse/arm64-bpf-Add-BHB-mitigation-to-the-epilogue-for-cBP.patch
  (bsc#1242778 CVE-2025-37948 bsc#1243649).
- Update
  patches.suse/arm64-bpf-Only-mitigate-cBPF-programs-loaded-by-unpr.patch
  (bsc#1242778 CVE-2025-37963 bsc#1243660).
- Update
  patches.suse/drm-imagination-fix-firmware-memory-leaks.patch
  (git-fixes CVE-2025-37764 bsc#1242577).
- Update
  patches.suse/drm-imagination-take-paired-job-reference.patch
  (git-fixes CVE-2025-37763 bsc#1242508).
- Update
  patches.suse/drm-xe-Fix-an-out-of-bounds-shift-when-invalidating-.patch
  (git-fixes CVE-2025-37761 bsc#1242724).
- Update
  patches.suse/drm-xe-Use-local-fence-in-error-path-of-xe_migrate_c.patch
  (git-fixes CVE-2025-37869 bsc#1242967).
- Update
  patches.suse/drm-xe-userptr-fix-notifier-vs-folio-deadlock.patch
  (git-fixes CVE-2025-37868 bsc#1242966).
- Update
  patches.suse/drm-xe-vf-Don-t-try-to-trigger-a-full-GT-reset-if-VF.patch
  (stable-fixes CVE-2025-23162 bsc#1242834).
- Update
  patches.suse/ethtool-cmis_cdb-use-correct-rpl-size-in-ethtool_cmi.patch
  (git-fixes CVE-2025-37791 bsc#1242729).
- Update
  patches.suse/mei-vsc-Fix-fortify-panic-caused-by-invalid-counted_.patch
  (git-fixes CVE-2025-37816 bsc#1242863).
- Update
  patches.suse/net-mlx5-Fix-null-ptr-deref-in-mlx5_create_-inner_-t.patch
  (git-fixes CVE-2025-37888 bsc#1242964).
- Update
  patches.suse/s390-pci-Fix-duplicate-pci_dev_put-in-disable_slot-w.patch
  (git-fixes CVE-2025-37946 bsc#1243506).
- Update
  patches.suse/scsi-mpi3mr-Synchronous-access-b-w-reset-and-tm-thre.patch
  (bsc#1241388 CVE-2025-37861 bsc#1243055).
- Update
  patches.suse/scsi-smartpqi-Use-is_kdump_kernel-to-check-for-kdump.patch
  (git-fixes CVE-2025-37981 bsc#1243514).
- Update
  patches.suse/tty-Require-CAP_SYS_ADMIN-for-all-usages-of-TIOCL_SE.patch
  (git-fixes CVE-2025-37814 bsc#1242865).
- Update
  patches.suse/usb-xhci-Don-t-skip-on-Stopped-Length-Invalid.patch
  (git-fixes CVE-2025-22023 bsc#1241298).
- Update
  patches.suse/usb-xhci-Fix-invalid-pointer-dereference-in-Etron-wo.patch
  (git-fixes CVE-2025-37813 bsc#1242909).
- commit ba2a725

- Update
  patches.suse/ALSA-ump-Fix-buffer-overflow-at-UMP-SysEx-message-co.patch
  (bsc#1242044 CVE-2025-37891 bsc#1243589).
- Update
  patches.suse/ASoC-Intel-avs-Fix-null-ptr-deref-in-avs_component_p.patch
  (git-fixes CVE-2025-37793 bsc#1242584).
- Update
  patches.suse/ASoC-imx-card-Add-NULL-check-in-imx_card_probe.patch
  (git-fixes CVE-2025-22066 bsc#1241340).
- Update
  patches.suse/ASoC-ops-Consistently-treat-platform_max-as-control-.patch
  (git-fixes CVE-2025-37889 bsc#1242945).
- Update
  patches.suse/ASoC-qcom-Fix-sc7280-lpass-potential-buffer-overflow.patch
  (git-fixes CVE-2025-37979 bsc#1243545).
- Update
  patches.suse/Bluetooth-btrtl-Prevent-potential-NULL-dereference.patch
  (git-fixes CVE-2025-37792 bsc#1242591).
- Update
  patches.suse/Bluetooth-btusb-avoid-NULL-pointer-dereference-in-sk.patch
  (git-fixes CVE-2025-37918 bsc#1243476).
- Update
  patches.suse/Input-mtk-pmic-keys-fix-possible-null-pointer-derefe.patch
  (git-fixes CVE-2025-37972 bsc#1243573).
- Update
  patches.suse/KVM-arm64-Tear-down-vGIC-on-failed-vCPU-creation.patch
  (git-fixes CVE-2025-37849 bsc#1243000).
- Update
  patches.suse/KVM-x86-Acquire-SRCU-in-KVM_GET_MP_STATE-to-protect-.patch
  (git-fixes CVE-2025-23141 bsc#1242782).
- Update
  patches.suse/PCI-Fix-reference-leak-in-pci_register_host_bridge.patch
  (git-fixes CVE-2025-37836 bsc#1242957).
- Update
  patches.suse/PCI-brcmstb-Fix-error-path-after-a-call-to-regulator.patch
  (git-fixes CVE-2025-22095 bsc#1241519).
- Update
  patches.suse/PCI-vmd-Make-vmd_dev-cfg_lock-a-raw_spinlock_t-type.patch
  (stable-fixes CVE-2025-23161 bsc#1242792).
- Update
  patches.suse/RDMA-cma-Fix-workqueue-crash-in-cma_netevent_work_ha.patch
  (git-fixes CVE-2025-37772 bsc#1242563).
- Update
  patches.suse/RDMA-core-Don-t-expose-hw_counters-outside-of-init-n.patch
  (git-fixes bsc#1239925 CVE-2025-22089 bsc#1241538).
- Update
  patches.suse/RDMA-core-Silence-oversized-kvmalloc-warning.patch
  (git-fixes CVE-2025-37867 bsc#1242948).
- Update
  patches.suse/USB-wdm-close-race-between-wdm_open-and-wdm_wwan_por.patch
  (git-fixes CVE-2025-37985 bsc#1243529).
- Update
  patches.suse/arm64-bpf-Add-BHB-mitigation-to-the-epilogue-for-cBPF-prog.patch
  (git-fixes CVE-2025-37948 bsc#1243649).
- Update
  patches.suse/arm64-bpf-Only-mitigate-cBPF-programs-loaded-by-unprivileg.patch
  (git-fixes CVE-2025-37963 bsc#1243660).
- Update
  patches.suse/arm64-errata-Add-missing-sentinels-to-Spectre-BHB-MIDR-arr.patch
  (git-fixes CVE-2025-37929 bsc#1243624).
- Update
  patches.suse/ata-pata_pxa-Fix-potential-NULL-pointer-dereference-.patch
  (git-fixes CVE-2025-37758 bsc#1242514).
- Update
  patches.suse/backlight-led_bl-Hold-led_access-lock-when-calling-l.patch
  (git-fixes CVE-2025-23144 bsc#1242568).
- Update
  patches.suse/block-fix-resource-leak-in-blk_register_queue-error-path.patch
  (git-fixes CVE-2025-37980 bsc#1243522).
- Update
  patches.suse/block-integrity-Do-not-call-set_page_dirty_lock.patch
  (git-fixes CVE-2025-37978 bsc#1243516).
- Update
  patches.suse/bnxt_en-Fix-out-of-bound-memcpy-during-ethtool-w.patch
  (git-fixes CVE-2025-37911 bsc#1243469).
- Update patches.suse/bpf-Scrub-packet-on-bpf_redirect_peer.patch
  (git-fixes CVE-2025-37959 bsc#1243517).
- Update
  patches.suse/bpf-check-changes_pkt_data-property-for-extension-pr.patch
  (bsc#1241590 CVE-2024-58100 bsc#1242564).
- Update
  patches.suse/bpf-consider-that-tail-calls-invalidate-packet-point.patch
  (bsc#1241590 CVE-2024-58237 bsc#1242574).
- Update
  patches.suse/bpf-track-changes_pkt_data-property-for-global-funct.patch
  (bsc#1241590 CVE-2024-58098 bsc#1242565).
- Update
  patches.suse/btrfs-adjust-subpage-bit-start-based-on-sectorsize.patch
  (bsc#1241492 CVE-2025-37931 bsc#1243626).
- Update
  patches.suse/bus-mhi-host-Fix-race-between-unprepare-and-queue_bu.patch
  (git-fixes CVE-2025-23151 bsc#1242512).
- Update
  patches.suse/cxgb4-fix-memory-leak-in-cxgb4_init_ethtool_filters-.patch
  (git-fixes CVE-2025-37788 bsc#1242766).
- Update
  patches.suse/dm-bufio-don-t-schedule-in-atomic-context.patch
  (git-fixes CVE-2025-37928 bsc#1243621).
- Update
  patches.suse/drm-amd-display-Fix-slab-use-after-free-in-hdcp.patch
  (git-fixes CVE-2025-37903 bsc#1243562).
- Update
  patches.suse/drm-amd-pm-Prevent-division-by-zero-4b8c3c0.patch
  (git-fixes CVE-2025-37770 bsc#1242764).
- Update
  patches.suse/drm-amd-pm-Prevent-division-by-zero-4e3d950.patch
  (git-fixes CVE-2025-37766 bsc#1242785).
- Update
  patches.suse/drm-amd-pm-Prevent-division-by-zero-7c246a0.patch
  (git-fixes CVE-2025-37768 bsc#1242567).
- Update
  patches.suse/drm-amd-pm-Prevent-division-by-zero-7d641c2.patch
  (git-fixes CVE-2025-37771 bsc#1242781).
- Update patches.suse/drm-amd-pm-Prevent-division-by-zero.patch
  (git-fixes CVE-2025-37767 bsc#1242501).
- Update
  patches.suse/drm-amd-pm-smu11-Prevent-division-by-zero.patch
  (git-fixes CVE-2025-37769 bsc#1242587).
- Update
  patches.suse/drm-amdgpu-Replace-Mutex-with-Spinlock-for-RLCG-regi.patch
  (git-fixes CVE-2025-38104 bsc#1241635).
- Update
  patches.suse/drm-amdgpu-handle-amdgpu_cgs_create_device-errors-in.patch
  (stable-fixes CVE-2025-37852 bsc#1243074).
- Update patches.suse/drm-amdkfd-Fix-mode1-reset-crash-issue.patch
  (stable-fixes CVE-2025-37854 bsc#1243082).
- Update
  patches.suse/drm-amdkfd-debugfs-hang_hws-skip-GPU-with-MES.patch
  (stable-fixes CVE-2025-37853 bsc#1243076).
- Update
  patches.suse/drm-i915-huc-Fix-fence-not-released-on-early-probe-e.patch
  (git-fixes CVE-2025-37754 bsc#1242524).
- Update
  patches.suse/drm-mediatek-dp-drm_err-dev_err-in-HPD-path-to-avoid.patch
  (git-fixes CVE-2025-38240 bsc#1241457).
- Update
  patches.suse/drm-nouveau-Fix-WARN_ON-in-nouveau_fence_context_kil.patch
  (git-fixes CVE-2025-37930 bsc#1243625).
- Update
  patches.suse/drm-nouveau-prime-fix-ttm_bo_delayed_delete-oops.patch
  (git-fixes CVE-2025-37765 bsc#1242761).
- Update
  patches.suse/drm-v3d-Add-job-to-pending-list-if-the-reset-was-ski.patch
  (stable-fixes CVE-2025-37951 bsc#1243659).
- Update
  patches.suse/eth-bnxt-fix-missing-ring-index-trim-on-error-path.patch
  (git-fixes CVE-2025-37873 bsc#1242961).
- Update patches.suse/fbdev-omapfb-Add-plane-value-check.patch
  (stable-fixes CVE-2025-37851 bsc#1242977).
- Update
  patches.suse/firmware-arm_scmi-Balance-device-refcount-when-destr.patch
  (git-fixes CVE-2025-37905 bsc#1243456).
- Update
  patches.suse/fs-jfs-Prevent-integer-overflow-in-AG-size-calculation.patch
  (git-fixes CVE-2025-37858 bsc#1243049).
- Update
  patches.suse/hfs-hfsplus-fix-slab-out-of-bounds-in-hfs_bnode_read_key.patch
  (git-fixes CVE-2025-37782 bsc#1242770).
- Update
  patches.suse/i2c-cros-ec-tunnel-defer-probe-if-parent-EC-is-not-p.patch
  (git-fixes CVE-2025-37781 bsc#1242575).
- Update
  patches.suse/i3c-Add-NULL-pointer-check-in-i3c_master_queue_ibi.patch
  (git-fixes CVE-2025-23147 bsc#1242530).
- Update
  patches.suse/ice-Check-VF-VSI-Pointer-Value-in-ice_vc_add_fdir_fl.patch
  (git-fixes CVE-2025-37912 bsc#1243470).
- Update patches.suse/igc-fix-PTM-cycle-trigger-logic.patch
  (git-fixes CVE-2025-37875 bsc#1242959).
- Update
  patches.suse/iio-imu-st_lsm6dsx-fix-possible-lockup-in-st_lsm6dsx-8114ef8.patch
  (git-fixes CVE-2025-37969 bsc#1243574).
- Update
  patches.suse/iio-imu-st_lsm6dsx-fix-possible-lockup-in-st_lsm6dsx.patch
  (git-fixes CVE-2025-37970 bsc#1243575).
- Update
  patches.suse/iommu-Fix-two-issues-in-iommu_copy_struct_from_user.patch
  (git-fixes CVE-2025-37900 bsc#1243560).
- Update
  patches.suse/ipv6-Fix-memleak-of-nhc_pcpu_rth_output-in-fib_check_nh_v6_gw.patch
  (git-fixes CVE-2025-22005 bsc#1240866).
- Update
  patches.suse/irqchip-gic-v2m-Prevent-use-after-free-of-gicv2m_get.patch
  (git-fixes CVE-2025-37819 bsc#1242873).
- Update
  patches.suse/irqchip-qcom-mpm-Prevent-crash-when-trying-to-handle.patch
  (git-fixes CVE-2025-37901 bsc#1243559).
- Update patches.suse/jbd2-remove-wrong-sb-s_sequence-check.patch
  (bsc#1242343 CVE-2025-37839 bsc#1242990).
- Update
  patches.suse/jfs-Fix-uninit-value-access-of-imap-allocated-in-the-diMount-function.patch
  (git-fixes CVE-2025-37742 bsc#1243011).
- Update
  patches.suse/jfs-Prevent-copying-of-nlink-with-value-0-from-disk-inode.patch
  (git-fixes CVE-2025-37741 bsc#1243015).
- Update
  patches.suse/jfs-add-sanity-check-for-agwidth-in-dbMount.patch
  (git-fixes CVE-2025-37740 bsc#1243006).
- Update
  patches.suse/jfs-fix-slab-out-of-bounds-read-in-ea_get.patch
  (git-fixes CVE-2025-39735 bsc#1241625).
- Update
  patches.suse/jfs-reject-on-disk-inodes-of-an-unsupported-type.patch
  (git-fixes CVE-2025-37925 bsc#1241654).
- Update
  patches.suse/md-md-bitmap-fix-wrong-bitmap_limit-for-clustermd-wh.patch
  (bsc#1238212 CVE-2025-22124 bsc#1241595).
- Update
  patches.suse/media-dw2102-Fix-null-ptr-deref-in-dw2102_i2c_transf.patch
  (git-fixes CVE-2023-53146 bsc#1220112).
- Update
  patches.suse/media-venus-hfi-add-a-check-to-handle-OOB-in-sfr-reg.patch
  (git-fixes CVE-2025-23159 bsc#1242529).
- Update
  patches.suse/media-venus-hfi-add-check-to-handle-incorrect-queue-.patch
  (git-fixes CVE-2025-23158 bsc#1242531).
- Update
  patches.suse/media-venus-hfi_parser-add-check-to-avoid-out-of-bou.patch
  (git-fixes CVE-2025-23157 bsc#1242532).
- Update
  patches.suse/media-venus-hfi_parser-refactor-hfi-packet-parsing-l.patch
  (git-fixes CVE-2025-23156 bsc#1242569).
- Update
  patches.suse/mfd-ene-kb3930-Fix-a-potential-NULL-pointer-derefere.patch
  (git-fixes CVE-2025-23146 bsc#1242559).
- Update
  patches.suse/misc-microchip-pci1xxxx-Fix-Kernel-panic-during-IRQ-.patch
  (git-fixes CVE-2025-37815 bsc#1242871).
- Update
  patches.suse/mtd-inftlcore-Add-error-check-for-inftl_read_oob.patch
  (git-fixes CVE-2025-37892 bsc#1243536).
- Update
  patches.suse/mtd-rawnand-brcmnand-fix-PM-resume-warning.patch
  (git-fixes CVE-2025-37840 bsc#1242953).
- Update patches.suse/net-phy-leds-fix-memory-leak.patch
  (git-fixes CVE-2025-37989 bsc#1243511).
- Update
  patches.suse/net-reenable-NETIF_F_IPV6_CSUM-offload-for-BIG-TCP-p.patch
  (git-fixes CVE-2025-21629 bsc#1235968).
- Update
  patches.suse/net_sched-drr-Fix-double-list-add-in-class-with-nete.patch
  (git-fixes CVE-2025-37915 bsc#1243473).
- Update
  patches.suse/net_sched-ets-Fix-double-list-add-in-class-with-nete.patch
  (git-fixes CVE-2025-37914 bsc#1243472).
- Update
  patches.suse/net_sched-hfsc-Fix-a-UAF-vulnerability-in-class-with.patch
  (git-fixes CVE-2025-37890 bsc#1243330).
- Update
  patches.suse/net_sched-qfq-Fix-double-list-add-in-class-with-nete.patch
  (git-fixes CVE-2025-37913 bsc#1243471).
- Update
  patches.suse/nfsd-decrease-sc_count-directly-if-fail-to-queue-dl_recall.patch
  (git-fixes CVE-2025-37871 bsc#1242949).
- Update
  patches.suse/objtool-media-dib8000-Prevent-divide-by-zero-in-dib8.patch
  (git-fixes CVE-2025-37937 bsc#1243540).
- Update
  patches.suse/objtool-spi-amd-Fix-out-of-bounds-stack-access-in-am.patch
  (git-fixes CVE-2025-40014 bsc#1241644).
- Update
  patches.suse/perf-Fix-hang-while-freeing-sigtrap-event.patch
  (bsc#1229491 CVE-2024-43869 CVE-2025-37747 bsc#1242520).
- Update
  patches.suse/pm-cpupower-bench-Prevent-NULL-dereference-on-malloc.patch
  (stable-fixes CVE-2025-37841 bsc#1242974).
- Update
  patches.suse/pwm-mediatek-Prevent-divide-by-zero-in-pwm_mediatek_.patch
  (git-fixes CVE-2025-37850 bsc#1242955).
- Update patches.suse/qibfs-fix-_another_-leak.patch (git-fixes
  CVE-2025-37983 bsc#1243567).
- Update patches.suse/sch_htb-make-htb_deactivate-idempotent.patch
  (CVE-2025-37798 bsc#1242414 CVE-2025-37953 bsc#1243543).
- Update
  patches.suse/sch_htb-make-htb_qlen_notify-idempotent.patch
  (CVE-2025-37798 bsc#1242414 CVE-2025-37932 bsc#1243627).
- Update
  patches.suse/sctp-detect-and-prevent-references-to-a-freed-transp.patch
  (git-fixes CVE-2025-23142 bsc#1242760).
- Update
  patches.suse/soc-samsung-exynos-chipid-Add-NULL-pointer-check-in-.patch
  (git-fixes CVE-2025-23148 bsc#1242578).
- Update
  patches.suse/sound-virtio-Fix-cancel_sync-warnings-on-uninitializ.patch
  (stable-fixes CVE-2025-37805 bsc#1242930).
- Update patches.suse/tpm-do-not-start-chip-while-suspended.patch
  (git-fixes CVE-2025-23149 bsc#1242758).
- Update
  patches.suse/usb-cdns3-Fix-deadlock-when-using-NCM-gadget.patch
  (git-fixes CVE-2025-37812 bsc#1242908).
- Update
  patches.suse/usb-dwc3-gadget-check-that-event-count-does-not-exce.patch
  (git-fixes CVE-2025-37810 bsc#1242906).
- Update
  patches.suse/usb-gadget-aspeed-Add-NULL-pointer-check-in-ast_vhub.patch
  (stable-fixes CVE-2025-37881 bsc#1242973).
- Update
  patches.suse/usb-typec-class-Invalidate-USB-device-pointers-on-pa.patch
  (git-fixes CVE-2025-37986 bsc#1243515).
- Update
  patches.suse/vmxnet3-Fix-packet-corruption-in-vmxnet3_xdp_xmit_fr.patch
  (bsc#1226498 CVE-2024-58099 bsc#1242035).
- Update
  patches.suse/wifi-at76c50x-fix-use-after-free-access-in-at76_disc.patch
  (git-fixes CVE-2025-37796 bsc#1242727).
- Update
  patches.suse/wifi-ath12k-Fix-invalid-data-access-in-ath12k_dp_rx_.patch
  (stable-fixes CVE-2025-37943 bsc#1243509).
- Update
  patches.suse/wifi-ath12k-Fix-invalid-entry-fetch-in-ath12k_dp_mon.patch
  (stable-fixes CVE-2025-37944 bsc#1243530).
- Update
  patches.suse/wifi-brcm80211-fmac-Add-error-handling-for-brcmf_usb.patch
  (git-fixes CVE-2025-37990 bsc#1243528).
- Update
  patches.suse/wifi-cfg80211-init-wiphy_work-before-allocating-rfki.patch
  (git-fixes CVE-2025-22119 bsc#1241576).
- Update
  patches.suse/wifi-mac80211-Purge-vif-txq-in-ieee80211_do_stop.patch
  (git-fixes CVE-2025-37794 bsc#1242566).
- Update
  patches.suse/wifi-plfxlc-Remove-erroneous-assert-in-plfxlc_mac_re.patch
  (git-fixes CVE-2025-37897 bsc#1243534).
- Update
  patches.suse/wifi-wl1251-fix-memory-leak-in-wl1251_tx_work.patch
  (git-fixes CVE-2025-37982 bsc#1243524).
- commit 4bd69e5

Package gcc14 was updated:

- Exclude shared objects present for link editing in the GCC specific  subdirectory from provides processing via __provides_exclude_from.
  [bsc#1244050][bsc#1243991]

- Make cross-*-gcc14-bootstrap package conflict with the non-bootstrap
  variant conflict with the unversioned cross-*-gcc package.

- Disable build of glibc cross to loongarch64 and hppa in SLFO
  and SLE15.

- Update to GCC 14.3 release, bb24b4c804f3d95b0ba95b7496, git11799
- Remove gcc14-pr120061.patch which is now included upstream.

- Add gcc14-pr120061.patch to fix the PR108900 fix instead of
  reverting it.
- Remove gcc14-pr108900.patch

- Add gcc14-pr108900.patch to revert it, fixing libqt6webengine build.

- Update to gcc-14 branch head, 3418d740b344e0ba38022f3be, git11702
  * Remove gcc14-pr118780.patch now on the upstream branch
- Fix build on s390x [bsc#1241549]

- Make sure link editing is done against our own shared library
  copy rather than the installed system runtime.  [bsc#1240788]
- Add gcc14-pr119680.patch to fix cross-compiler builds with
  - -enable-host-pie.

Package libevent was updated:

- Disable the select backend, this can be easily done by lying  to configure. This is done due to:
  * using fd number &amp;gt; 1024 on an fd_set results in a runtime
    fortify source assertion, preventing further doom.
  * select will not be changed to handle fd &amp;gt; 1024.
  * this limit is unreasonable low for this century.

- Drop insserv_prereq and fillup_prereq macros: there are no
  pre-scripts that would justify these dependencies.

- Update to 2.1.12 stable
  * buffer: do not pass NULL to memcpy() from evbuffer_pullup()
  * http: fix undefined-shift in EVUTIL_IS*_ helpers
  * Check error code of evhttp_add_header_internal() in
    evhttp_parse_query_impl()
  * http: fix EVHTTP_CON_AUTOFREE in case of timeout
  * evdns: Add additional validation for values of dns options
  * Fix memory corruption in EV_CLOSURE_EVENT_FINALIZE with debug enabled
  * increase segment refcnt only if evbuffer_add_file_segment() succeeds
  * evdns: fix a crash when evdns_base with waiting requests is freed
  * event_base_once: fix potential null pointer threat
  * http: do not assume body for CONNECT
  * evbuffer_add_file: fix freeing of segment in the error path
  * Fix checking return value of the evdns_base_resolv_conf_parse()
  * Support EV_CLOSED on linux for poll(2)
  * Parse IPv6 scope IDs.
  * evutil_time: detect and use _gmtime64_s()/_gmtime64()
  * bufferevent: allow setting priority on socket and openssl type
  * Fix EV_CLOSED detection/reporting
  * Revert &amp;quot;Warn if forked from the event loop during event_reinit()&amp;quot;

- Add upstream patches with the feature of &amp;quot;prepare&amp;quot; and &amp;quot;check&amp;quot;
  watchers. That feature is needed by envoy-proxy:
  * 0001-evwatch-Add-prepare-and-check-watchers.patch
  * 0002-evwatch-fix-race-condition.patch

- Update to 2.1.11 stable
  * Fix ABI breakage that had been introduced in 2.1.10. Strictly speaking
    this release breaks ABI again to make it compatible with &amp;lt;= 2.1.9.
    + See git commit 18104973 for more details
  * evdns: add new options -- so-rcvbuf/so-sndbuf
  * various autotools and cmake build changes
  * buffer: fix possible NULL dereference in evbuffer_setcb() on ENOMEM
  * Warn if forked from the event loop during event_reinit()
  * evutil: set the have_checked_interfaces in evutil_check_interfaces()
  * https-client: correction error checking

- Use FAT LTO objects in order to provide proper static library.

- Fix name of library package (bsc#1138369)

- Update to 2.1.10 stable
  * evdns: add DNS_OPTION_NAMESERVERS_NO_DEFAULT /
    EVDNS_BASE_NAMESERVERS_NO_DEFAULT
  * Add support for EV_TIMEOUT to event_base_active_by_fd
  * kqueue: Avoid undefined behaviour.
  * Prevent integer overflow in kq_build_changes_list.
  * evdns: fix lock/unlock mismatch in evdns_close_server_port()
  * Protect min_heap_push_ against integer overflow.
  * le-proxy: initiate use of the Winsock DLL
  * Fix leaks in error path of the bufferevent_init_common_()
  * buffer: make evbuffer_prepend() of zero-length array no-op
  * Don't loose top error in SSL
  * Remove needless check for arc4_seeded_ok
  * Cleanup __func__ detection
  * Add convenience macros for user-triggered events
  * Notify event base if there are no more events, so it can exit without
    delay
  * Fix base unlocking in event_del() if event_base_set() runned in another
    thread
  * If precise_time is false, we should not set EVENT_BASE_FLAG_PRECISE_TIMER
  * Fix race in access to ev_res from event loop with event_active()
  * Return from event_del() after the last event callback termination
  * Preserve socket error from listen across closesocket cleanup
  * fix connection retries when there more then one request for connection
  * improve error path for bufferevent_{setfd,enable,disable}()
  * Fix conceivable UAF of the bufferevent in evhttp_connection_free()
  * Fix evhttp_connection_get_addr() fox incomming http connections
  * fix leaks in evhttp_uriencode()
  * CONNECT method only takes an authority
  * Allow bodies for GET/DELETE/OPTIONS/CONNECT
  * Do not crash when evhttp_send_reply_start() is called after a timeout.
  * Fix crashing http server when callback do not reply in place
  * fix handling of close_notify (ssl) in http with openssl bufferevents
  * use *_new_with_arg() to match function prototype
  * avoid NULL dereference on request is not EVHTTP_REQ_POST
  * bufferevent_socket_connect{,_hostname}() missing event callback and use
    ret code
  * don't fail be_null_filter if bytes are copied
  * Call underlying bev ctrl GET_FD on filtered bufferevents
  * be_openssl: avoid leaking of SSL structure
  * Add missing includes into openssl-compat.h
  * Explicitly call SSL_clear when reseting the fd.
  * sample/https-client: use host SSL certificate store by default
  * ipv6only socket bind support
  * evdns: handle NULL filename explicitly
  * Fix assert() condition in evbuffer_drain() for IOCP
  * fix incorrect unlock of the buffer mutex (for deferred callbacks)
  * Fix wrong assert in evbuffer_drain()
  * Port `event_rpcgen.py` and `test/check-dumpevents.py` to Python 3.
- rename python2-shebang.patch -&amp;gt; python3-shebang.patch following port

- Make use of %license macro

- Add devel-static package, which is needed for building Envoy
  (https://www.envoyproxy.io/) and Cilium with Envoy integration
- Fix an error about /usr/bin/env shebang in event_rpcgen.py
  * python2-shebang.patch

Package expat was updated:

- version update to 2.7.1    Bug fixes:
    [#980] #989  Restore event pointer behavior from Expat 2.6.4
    (that the fix to CVE-2024-8176 changed in 2.7.0);
    affected API functions are:
  - XML_GetCurrentByteCount
  - XML_GetCurrentByteIndex
  - XML_GetCurrentColumnNumber
  - XML_GetCurrentLineNumber
  - XML_GetInputContext
    Other changes:
    [#976] #977  Autotools: Integrate files &amp;quot;fuzz/xml_lpm_fuzzer.{cpp,proto}&amp;quot;
    with Automake that were missing from 2.7.0 release tarballs
    [#983] #984  Fix printf format specifiers for 32bit Emscripten
    [#992]  docs: Promote OpenSSF Best Practices self-certification
    [#978]  tests/benchmark: Resolve mistaken double close
    [#986]  Address compiler warnings
    [#990] #993  Version info bumped from 11:1:10 (libexpat*.so.1.10.1)
    to 11:2:10 (libexpat*.so.1.10.2); see https://verbump.de/
    for what these numbers do
    Infrastructure:
    [#982]  CI: Start running Perl XML::Parser integration tests
    [#987]  CI: Enforce Clang Static Analyzer clean code
    [#991]  CI: Re-enable warning clang-analyzer-valist.Uninitialized
    for clang-tidy
    [#981]  CI: Cover compilation with musl
    [#983] #984  CI: Cover compilation with 32bit Emscripten
    [#976] #977  CI: Protect against fuzzer files missing from future
    release archives

- version update to 2.7.0 for SLE-15-SP7 (jsc#PED-12507)

- version update to 2.7.0 (CVE-2024-8176 [bsc#1239618])
  * Security fixes:
    [#893] #973  CVE-2024-8176 -- Fix crash from chaining a large number
    of entities caused by stack overflow by resolving use of
    recursion, for all three uses of entities:
  - general entities in character data (&amp;quot;&amp;lt;e&amp;gt;&amp;amp;g1;&amp;lt;/e&amp;gt;&amp;quot;)
  - general entities in attribute values (&amp;quot;&amp;lt;e k1='&amp;amp;g1;'/&amp;gt;&amp;quot;)
  - parameter entities (&amp;quot;%p1;&amp;quot;)
    Known impact is (reliable and easy) denial of service:
    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H/E:H/RL:O/RC:C
    (Base Score: 7.5, Temporal Score: 7.2)
    Please note that a layer of compression around XML can
    significantly reduce the minimum attack payload size.
  * Other changes:
    [#935] #937  Autotools: Make generated CMake files look for
    libexpat.@SO_MAJOR@.dylib on macOS
    [#925]  Autotools: Sync CMake templates with CMake 3.29
  [#945] #962 #966  CMake: Drop support for CMake &amp;lt;3.13
    [#942]  CMake: Small fuzzing related improvements
    [#921]  docs: Add missing documentation of error code
    XML_ERROR_NOT_STARTED that was introduced with 2.6.4
    [#941]  docs: Document need for C++11 compiler for use from C++
    [#959]  tests/benchmark: Fix a (harmless) TOCTTOU
    [#944]  Windows: Fix installer target location of file xmlwf.xml
    for CMake
    [#953]  Windows: Address warning -Wunknown-warning-option
    about -Wno-pedantic-ms-format from LLVM MinGW
    [#971]  Address Cppcheck warnings
    [#969] #970  Mass-migrate links from http:// to https://
    [#947] #958 ..
    [#974] #975  Document changes since the previous release
    [#974] #975  Version info bumped from 11:0:10 (libexpat*.so.1.10.0)
    to 11:1:10 (libexpat*.so.1.10.1); see https://verbump.de/
    for what these numbers do

Package libgcrypt was updated:

- Security fix [bsc#1221107, CVE-2024-2236]  * Add --enable-marvin-workaround to spec to enable workaround
  * Fix  timing based side-channel in RSA implementation ( Marvin attack )
  * Add libgcrypt-CVE-2024-2236.patch
- Fix kdf test and fail accordingly if tests fail under FIPS mode [bsc#1246934]
  * Rebased patches: libgcrypt-FIPS-SLI-kdf-leylength.patch

Package gnutls was updated:

- Fix heap buffer overread when handling the CT SCT extension during X.509  certificate parsing [bsc#1246233, CVE-2025-32989]
  * Add patch gnutls-CVE-2025-32989.patch
- Fix double-free due to incorrect ownership handling in the export logic of
  SAN entries containing an otherName [bsc#1246232, CVE-2025-32988]
  * Add patch gnutls-CVE-2025-32988.patch
- Fix 1-byte heap buffer overflow when parsing templates with certtool
  [bsc#1246267, CVE-2025-32990]
  * Add patch gnutls-CVE-2025-32990.patch
- Fix NULL pointer dereference when 2nd Client Hello omits PSK
  [bsc#1246299, CVE-2025-6395]
  * Add patch gnutls-CVE-2025-6395.patch

Package icu was updated:

- Add icu-CVE-2025-5222.patch:  Backport 2c667e3 from upstream, ICU-22973 Fix buffer overflow by
  using CharString.
  (CVE-2025-5222, bsc#1243721)

Package samba was updated:

- Update to 4.21.7  * Windows security hardening locks out schannel'ed netlogon dc
    calls like netr_DsRGetDCName; (bsc#1246431); (bso#15876);
  * Trust domains are not created; (bso#15680);
  * Startup messages of rpc deamons fills /var/log/messages;
    (bso#15869);

- Update to 4.21.6
  * Running &amp;quot;gpo manage motd set&amp;quot; twice fails with backtrace;
    (bso#15774).
  * samba-tool gpo backup creates entity backups it can't read;
    (bso#15829).
  * gp_cert_auto_enroll_ext.py has problem unpacking GUIDs with
    prepended 0's; (bso#15839).
  * CVE-2025-0620 [SECURITY] smbd doesn't pick up group
    membership changes when re-authenticating an expired SMB
    session; (bso#15707), (bsc#1244136).
  * Deadlock between two smbd processes; (bso#15767).
  * net ad join fails with &amp;quot;Failed to join domain: failed to
    create kerberos keytab&amp;quot;; (bso#15727).
  * Wide link issue in samba 4.22; (bso#15841).
  * dcerpcd not able to bind to listening port; (bso#15851).
  * vfs_ceph_snapshots fails to list snapshots for entries at any
    level beyond share root; (bso#15819).
  * CTDB does not put nodes running NFS into grace on graceful
    shutdown; (bso#15858).

- Update to 4.21.5
  * ldb index cache is too small on known large transactions
    (schemaupgrade, provision); (bso#15795).
  * Enable support for cephfs case insensitive behavior;
    (bso#15822).
  * Subnet based interfaces definition not listening on all
    covered IP addresses; (bso#15823).
  * net ad join fails with &amp;quot;Failed to join domain: failed to
    create kerberos keytab&amp;quot;; (bso#15727); (bsc#1238063).
  * Remove of file or directory not possible with vfs_acl_tdb;
    (bso#15791).
  * Unable to connect to CephFS subvolume shares with
    vfs_shadow_copy2; (bso#15797).
  * Add async io API from libcephfs to ceph_new VFS module;
    (bso#15810).
  * vfs_ceph_new module does not work with other modules for
    snapshot management; (bso#15818).
  * vfs_ceph_new: Add path based fallback for SMB_VFS_FCHOWN,
    SMB_VFS_FCHMOD and SMB_VFS_FNTIMES; (bso#15834).
  * Incorrect FSF address in ctdb pcp scripts; (bso#15820).
  * &amp;quot;samba-tool domain backup offline&amp;quot; hangs; (bso#15804).

- Update to 4.21.4
  * Increasing slowness of sharesec performance with high number
    of registry shares; (bso#15780).
  * winbindd shows memleak in kerberos_decode_pac; (bso#15782).
  * Creation of GPOs applicable to more than one group is
    impossible with Samba 4.20.0 and later; (bso#15738).
  * Replace `crypt` module in
    python/samba/netcmd/user/readpasswords/common.py;
    (bso#15756).
  * vfs_gpfs silently garbles timestamps &amp;gt; year 2106;
    (bso#15151).
  * Spotlight search results don't show file size and creation
    date; (bso#15796).
  * General improvements for vfs_ceph_new module; (bso#15703).
  * net offlinejoin not working correctly; (bso#15777).
  * net ads create/join/winbind producing unix dysfunctional
    keytabs; (bso#15759).
  * Windows Explorer crashes on S-1-22-* Unix-SIDs when accessing
    security tab; (bso#14213).
  * The values from hresult_errstr_const and hresult_errstr are
    reversed in 4.20 and 4.21; (bso#15769).
  * Kerberos referral tickets are generated for principals in our
    domain if we have a trust to a top level domain; (bso#15778).
  * NETLOGON_NTLMV2_ENABLED is missing in the SamLogon*
    user_flags field; (bso#15783).
  * Regression: stack-use-after-return in crypt_as_best_we_can();
    (bso#15784).
  * libreplace:readline: gcc 15 complains about incompatible
    pointer types; (bso#15788).

- Update to 4.21.3
  * More possible replication loops against Azure AD;
    (bso#15701).
  * Compound rename from Mac clients can fail with
    NT_STATUS_INTERNAL_ERROR if the file has a lease;
    (bso#15697).
  * vfs crossrename seems not work correctly; (bso#15724).
  * After 'machine password timeout' /etc/krb5.keytab is not
    updated; (bso#6750).
  * Memory leak wbcCtxLookupSid; (bso#15771).
  * Fix heap-user-after-free with association groups;
    (bso#15765).
  * Segfault in vfs_btrfs; (bso#15758).
  * Avoid event failure race when disabling an event script;
    (bso#15755).

Package nfs-utils was updated:

- gssd: add support for an &amp;quot;allowed-enctypes&amp;quot; option in nfs.conf  (bsc#1240899)
  - add 0008-gssd-add-support-for-an-allowed-enctypes-option-in-n.patch

Package libnvme was updated:

- Update to version 1.11+8.gfb9b581c:  * tree: do not try to strdup NULL pointer (bsc#1247225)
  * tree: always set the host key (bsc#1246560)

- Update to version 1.11+6.g0d17be77:
  * tree: free ctrl attributes when (re)configure ctrl (bsc#1243716)
  * tree: filter tree after scan has completed (bsc#1243716)

Package openssl-1_1 was updated:

- FIPS: Use the NID_X9_62_prime256v1 curve in ECDSA KAT test  instead of NID_secp256k1. [bsc#1246697]
  * Add openssl-fips-ECDSA-KAT.patch

Package openssl-3 was updated:

- Increase limit for CRL download [bsc#1247148, bsc#1247144]  * Add openssl-3-large-CRLs.patch

- FIPS: Fix EMS in crypto-policies FIPS:NO-ENFORCE-EMS
  * [bsc#1230959, bsc#1232326, bsc#1231748, bsc#1246428]
  * Add patch openssl-FIPS-fix-EMS-support.patch

- Backport mdless cms signing support [jsc#PED-12895]
  * Add openssl-3-support-mdless-cms.patch

- Security fix: [bsc#1240366, CVE-2025-27587]
  * Minerva side channel vulnerability in P-384 on PPC arch
  * Add openssl-3-p384-minerva-ppc.patch
  * Add openssl-3-p384-minerva-ppc-p9.patch

- Security fix: [bsc#1236599, CVE-2024-12797]
  * RFC7250 handshakes with unauthenticated servers don't abort as
    expected.
  * Add openssl-CVE-2024-12797.patch

- Security fix: [bsc#1236136, CVE-2024-13176]
  * Fix timing side-channel in ECDSA signature computation
  * Add openssl-CVE-2024-13176.patch

Package polkit was updated:

- CVE-2025-7519: Fixed that a XML policy file with a large number of  nested elements may lead to out-of-bounds write (bsc#1246472)
  added 0001-Nested-.policy-files-cause-xml-parsing-overflow-lead.patch

Package libpsm2 was updated:

- Add libpsm2-disable-AVX.patch to completely disable AVX support  and use only up to SSE4.2. (bsc#1245739)

- Use %autosetup macro. Allows to eliminate the usage of deprecated
  %patchN

Package python311 was updated:

- Add CVE-2025-8194-tarfile-no-neg-offsets.patch which now  validates archives to ensure member offsets are non-negative
  (gh#python/cpython#130577, CVE-2025-8194, bsc#1247249).

- Add CVE-2025-6069-quad-complex-HTMLParser.patch to avoid worst
  case quadratic complexity when processing certain crafted
  malformed inputs with HTMLParser (CVE-2025-6069, bsc#1244705).

- Use one core to build doc. This will make sphinx doc build
  reproducible.
  bsc#1243155

- Update to 3.11.13:
  - Security
  - gh-135034: Fixes multiple issues that allowed tarfile
    extraction filters (filter=&amp;quot;data&amp;quot; and filter=&amp;quot;tar&amp;quot;)
    to be bypassed using crafted symlinks and hard links.
    Addresses CVE-2024-12718 (bsc#1244056), CVE-2025-4138
    (bsc#1244059), CVE-2025-4330 (bsc#1244060), and
    CVE-2025-4517 (bsc#1244032). Also addresses CVE-2025-4435
    (gh#135034, bsc#1244061).
  - gh-133767: Fix use-after-free in the âunicode-escapeâ
    decoder with a non-âstrictâ error handler (CVE-2025-4516,
    bsc#1243273).
  - gh-128840: Short-circuit the processing of long IPv6
    addresses early in ipaddress to prevent excessive memory
    consumption and a minor denial-of-service.
  - Library
  - gh-128840: Fix parsing long IPv6 addresses with embedded
    IPv4 address.
  - gh-134062: ipaddress: fix collisions in __hash__() for
    IPv4Network and IPv6Network objects.
  - gh-123409: Fix ipaddress.IPv6Address.reverse_pointer output
    according to RFC 3596, Â§2.5. Patch by BÃ©nÃ©dikt Tran.
  - bpo-43633: Improve the textual representation of
    IPv4-mapped IPv6 addresses (RFC 4291 Sections 2.2, 2.5.5.2)
    in ipaddress. Patch by Oleksandr Pavliuk.
- Remove upstreamed patches:
  - gh-126572-test_ssl-no-stop-ThreadedEchoServer-OSError.patch
  - CVE-2025-4516-DecodeError-handler.patch

- Add CVE-2025-4516-DecodeError-handler.patch fixing
  CVE-2025-4516 (bsc#1243273) blocking DecodeError handling
  vulnerability, which could lead to DoS.

- Use extended %autopatch.

- Remove python-3.3.0b1-test-posix_fadvise.patch (not needed
  since kernel 3.6-rc1)

- Update to 3.11.12:
  - gh-131809: Update bundled libexpat to 2.7.1
  - gh-131261: Upgrade to libexpat 2.7.0
  - gh-105704: When using urllib.parse.urlsplit() and
    urllib.parse.urlparse() host parsing would not reject domain
    names containing square brackets ([ and ]). Square brackets
    are only valid for IPv6 and IPvFuture hosts according to RFC
    3986 Section 3.2.2 (bsc#1236705, CVE-2025-0938,
    gh#python/cpython#105704).
  - gh-121284: Fix bug in the folding of rfc2047 encoded-words
    when flattening an email message using a modern email
    policy. Previously when an encoded-word was too long for
    a line, it would be decoded, split across lines, and
    re-encoded. But commas and other special characters in the
    original text could be left unencoded and unquoted. This
    could theoretically be used to spoof header lines using a
    carefully constructed encoded-word if the resulting rendered
    email was transmitted or re-parsed.
  - gh-80222: Fix bug in the folding of quoted strings
    when flattening an email message using a modern email
    policy. Previously when a quoted string was folded so that
    it spanned more than one line, the surrounding quotes and
    internal escapes would be omitted. This could theoretically
    be used to spoof header lines using a carefully constructed
    quoted string if the resulting rendered email was transmitted
    or re-parsed.
  - gh-119511: Fix a potential denial of service in the imaplib
    module. When connecting to a malicious server, it could
    cause an arbitrary amount of memory to be allocated. On many
    systems this is harmless as unused virtual memory is only
    a mapping, but if this hit a virtual address size limit
    it could lead to a MemoryError or other process crash. On
    unusual systems or builds where all allocated memory is
    touched and backed by actual ram or storage it couldâve
    consumed resources doing so until similarly crashing.
  - gh-127257: In ssl, system call failures that OpenSSL reports
    using ERR_LIB_SYS are now raised as OSError.
  - gh-121277: Writers of CPythonâs documentation can now use
    next as the version for the versionchanged, versionadded,
    deprecated directives.
  - gh-106883: Disable GC during the _PyThread_CurrentFrames()
    and _PyThread_CurrentExceptions() calls to avoid the
    interpreter to deadlock.
- Remove upstreamed patch:
  - CVE-2025-0938-sq-brackets-domain-names.patch
- Add gh-126572-test_ssl-no-stop-ThreadedEchoServer-OSError.patch
  which makes test_ssl not to stop ThreadedEchoServer on OSError,
  which makes test_ssl pass with OpenSSL 3.5 (bsc#1241067,
  gh#python/cpython!126572)

Package python3 was updated:

- Add CVE-2025-8194-tarfile-no-neg-offsets.patch which now  validates archives to ensure member offsets are non-negative
  (gh#python/cpython#130577, CVE-2025-8194, bsc#1247249).

- Add CVE-2025-4435-normalize-lnk-trgts-tarfile.patch
  Security fixes for CVE-2025-4517, CVE-2025-4330, CVE-2025-4138,
  CVE-2024-12718, CVE-2025-4435 on tarfile (bsc#1244032,
  bsc#1244061, bsc#1244059, bsc#1244060, bsc#1244056).
  The backported fixes do not contain changes for ntpath.py and
  related tests, because the support for symlinks and junctions
  were added later in Python 3.9, and it does not make sense to
  backport them to 3.6 here.
  The patch is contains the following changes:
  - python@42deeab fixes symlink handling for tarfile.data_filter
  - python@9d2c2a8 fixes handling of existing files/symlinks in tarfile
  - python@00af979 adds a new &amp;quot;strict&amp;quot; argument to realpath()
  - python@dd8f187 fixes mulriple CVE fixes in the tarfile module
  - downstream only fixes that makes the changes work and
    compatible with Python 3.6
- Add CVE-2025-6069-quad-complex-HTMLParser.patch to avoid worst
  case quadratic complexity when processing certain crafted
  malformed inputs with HTMLParser (CVE-2025-6069, bsc#1244705).

- Add python36-* provides/obsoletes to enable SLE-12 -&amp;gt; SLE-15
  migration, bsc#1233012

- Add ipaddress-update-pr60.patch from gh#phihag/ipaddress!60 to
  update vendored ipaddress module to 3.8 equivalent
- Add gh-128840_parse-IPv6-with-emb-IPv4.patch to limit buffer
  size for IPv6 address parsing (gh#python/cpython#128840,
  bsc#1244401).
- Update CVE-2025-4516-DecodeError-handler.patch not to break
  _PyBytes_DecodeEscape signature.

- Add CVE-2025-4516-DecodeError-handler.patch fixing
  CVE-2025-4516 (bsc#1243273) blocking DecodeError handling
  vulnerability, which could lead to DoS.

Package libsolv was updated:

- add support for product-obsoletes() provides in the product  autopackage generation code
- bump version to 0.7.34

- improve transaction ordering by allowing more uninst-&amp;gt;uninst
  edges [bsc#1243457]
- implement color filtering when adding update targets
- support orderwithrequires dependencies in susedata.xml
- bump version to 0.7.33

Package sqlite3 was updated:

- Backpatch the URLs in sqlite3.n from https to http to avoid a  file conflict with the tcl package on SLE-15-GA up to SP2. In
  SP3 and onwards the Tcl package does not contain the sqlite
  extension anymore.

- Sync version 3.50.2 from Factory:
  * CVE-2025-6965, bsc#1246597:
    Raise an error early if the number of aggregate terms in a
    query exceeds the maximum number of columns, to avoid
    downstream assertion faults.
  * Add subpackage for the lemon parser generator.
    + sqlite-3.49.0-fix-lemon-missing-cflags.patch
    + sqlite-3.6.23-lemon-system-template.patch

Package libssh was updated:

- Fix CVE-2025-5318: Likely read beyond bounds in sftp server handle management (bsc#1245311)  * Add patch libssh-CVE-2025-5318.patch
- Fix CVE-2025-4877: Write beyond bounds in binary to base64 conversion functions (bsc#1245309)
  * Add patch libssh-CVE-2025-4877.patch
- Fix CVE-2025-4878: Use of uninitialized variable in privatekey_from_file() (bsc#1245310)
  * Add patches:
  - libssh-CVE-2025-4878-1.patch
  - libssh-CVE-2025-4878-2.patch
- Fix CVE-2025-5372: ssh_kdf() returns a success code on certain failures (bsc#1245314)
  * Add patch libssh-CVE-2025-5372.patch

Package systemd was updated:

- triggers.systemd: skip update of hwdb, journal-catalog if executed during  an offline update.

- systemd-repart is no more considered as experimental (jsc#PED-13213)

- Import commit 130293e510ceb4d121d11823e6ebd4b1e8332ea0 (merge of v254.27)
  For a complete list of changes, visit:
  https://github.com/openSUSE/systemd/compare/278fb676146e35a7b4057f52f34a7bbaf1b82369...130293e510ceb4d121d11823e6ebd4b1e8332ea0

- Import commit 278fb676146e35a7b4057f52f34a7bbaf1b82369
  aa12f501ae logs-show: get timestamp and boot ID only when necessary (bsc#1242827)
  e8b17d11bc sd-journal: drop to use Hashmap to manage journal files per boot ID
  ea80273738 tree-wide: set SD_JOURNAL_ASSUME_IMMUTABLE where appropriate
  a5b3b5344f sd-journal: introduce SD_JOURNAL_ASSUME_IMMUTABLE flag
  5fa0600b34 sd-journal: make journal_file_read_tail_timestamp() notify to the caller that some new journal entries added
  737e8193e7 sd-journal: cache last entry offset and journal file state
  057dca426f sd-journal: fix typo in function name

- Start the systemd-coredump.socket unit on systemd-coredump package
  installation.
- Restore the kernel default values of the coredump sysctl settings on
  systemd-coredump package removal.

- Import commit e08f49f2432509787abfb7f3fc0b2f2c459def04 (merge of v254.25)
  This merge includes the following fix:
    7fc7aa5a4d coredump: use %d in kernel core pattern (bsc#1243935 CVE-2025-4598)
  For a complete list of changes, visit:
  https://github.com/openSUSE/systemd/compare/b0ae3b6e85b6a4030cf2adb88519a6ca0ffc1343...e08f49f2432509787abfb7f3fc0b2f2c459def04
- Drop 1021-Revert-macro-terminate-the-temporary-VA_ARGS_FOREACH.patch
  The SUSE specific patch has been integrated into the SUSE/v254 git
  branch. Some of the imported commits from the stable tree rely on the macro
  now.

- Import commit b0ae3b6e85b6a4030cf2adb88519a6ca0ffc1343
  41d2be2fb5 Revert &amp;quot;macro: terminate the temporary VA_ARGS_FOREACH() array with a sentinel&amp;quot; (SUSE specific)

Package libxml2 was updated:

- security update- added patches
  CVE-2025-7425 [bsc#1246296], Heap Use-After-Free in libxslt caused by atype corruption in xmlAttrPtr
  + libxml2-CVE-2025-7425.patch

- security update
- added patches
  CVE-2025-49794 [bsc#1244554], heap use after free (UAF) can lead to Denial of service (DoS)
  CVE-2025-49796 [bsc#1244557], type confusion may lead to Denial of service (DoS)
  + libxml2-CVE-2025-49794,49796.patch
  CVE-2025-49795 [bsc#1244555], null pointer dereference may lead to Denial of service (DoS)
  + libxml2-CVE-2025-49795.patch

- security update
- added patches
  CVE-2025-6170 [bsc#1244700], stack buffer overflow may lead to a crash
  CVE-2025-6021 [bsc#1244580], Integer Overflow in xmlBuildQName() Leads to Stack Buffer Overflow in libxml2
  + libxml2-CVE-2025-6170,6021.patch

Package libzypp was updated:

- Fix evaluation of libproxy results (bsc#1247690)- Replace URL variables inside mirrorlist/metalink files
  (fixes #667)
- version 17.37.16 (35)

- Append RepoInfo::path() to the mirror URLs in Preloader
  (bsc#1247054)
- version 17.37.15 (35)

- During installation indicate the backend being used (bsc#1246038)
  If some package actually needs to know, it should test for
  ZYPP_CLASSIC_RPMTRANS being set in the environment.
  Otherwise the transaction is driven by librpm.
- version 17.37.14 (35)

- Workaround 'rpm -vv' leaving scriptlets /var/tmp (bsc#1218459)
- Verbose log libproxy results if PX_DEBUG=1 is set.
- BuildRequires:  cmake &amp;gt;= 3.17.
- version 17.37.13 (35)

- Allow explicit request to probe an added repo's URL
  (bsc#1246466)
- Fix tests with -DISABLE_MEDIABACKEND_TESTS=1 (fixes #661)
- version 17.37.12 (35)

- Add runtime check for a broken rpm-4.18.0 --runpostrans
  (bsc#1246149)
- Add regression test for bsc#1245220 and some other filesize
  related tests.
- version 17.37.11 (35)

- BuildRequires: %{libsolv_devel_package} &amp;gt;= 0.7.34 (bsc#1243486)
  Newer rpm versions no longer allow a ':' in rpm package names or
  obsoletes. So injecting an
    Obsoletes: product:oldproductname &amp;lt; oldproductversion
  into the -release package to indicate a product rename is no longer
  possible.
  Since libsolv-0.7.34 you can and should use:
    Provides: product-obsoletes(oldproductname) &amp;lt; oldproductversion
  in the -release package. libsolv will then inject the appropriate
  Obsoletes into the Product.
- version 17.37.10 (35)

- Ignore DeltaRpm download errors (bsc#1245672)
  DeltaRpms are in fact optional resources. In case of a failure
  the full rpm is downloaded.
- Improve fix for incorrect filesize handling (bsc#1245220)
- version 17.37.9 (35)

- Do not trigger download data exceeded errors on HTTP non data
  responses (bsc#1245220)
  In some cases a HTTP 401 or 407 did trigger a &amp;quot;filesize exceeded&amp;quot;
  error, because the response payload size was compared against the
  expected filesize. This patch adds some checks if the response
  code is in the success range and only then takes expected
  filesize into account. Otherwise the response content-length is
  used or a fallback of 2Mb if no content-length is known.
- version 17.37.8 (35)

- Fix SEGV in MediaDISK handler (bsc#1245452)
- Explicitly selecting DownloadAsNeeded also selects the
  classic_rpmtrans backend.
  DownloadAsNeeded can not be combined with the rpm singletrans
  installer backend because a rpm transaction requires all package
  headers to be available the the beginning of the transaction. So
  explicitly selecting this mode also turns on the classic_rpmtrans
  backend.
- Fix evaluation of libproxy results (bsc#1244710)
- version 17.37.7 (35)

- Enhancements regarding mirror handling during repo refresh.
  Added  means to disable the use of mirrors when downloading
  security relevant files. Requires updaing zypper to 1.14.91.
- Fix autotestcase writer if ZYPP_FULLLOG=1 (bsc#1244042)
  If ZYPP_FULLLOG=1 a solver testcase to
  &amp;quot;/var/log/YaST2/autoTestcase&amp;quot; should be written for each solver
  run. There was no testcase written for the very first solver run.
  This is now fixed.
- Pass $1==2 to %posttrans script if it's an update (bsc#1243279)
- version 17.37.6 (35)

Package mdadm was updated:

- monitor: Add MAILFROM address to email envelope to avoid smtp auth  errors (bsc#1241474)
  * add 1008-mdmonitor-use-MAILFROM-to-set-sendmail-envelope-send.patch

- Allow any valid minor name in md device name (bsc#1240789)
  * add 1007-mdadm-allow-any-valid-minor-number-in-md-device-name.patch

- Add dependency on suse-module-tools for SLE15 (bsc#1242696)

Package mozilla-nspr was updated:

- update to version 4.36  * remove support for OS/2
  * remove support for Unixware, Bsdi, old AIX, old HPUX9 &amp;amp; scoos
  * remove support for Windows 16 bit
  * renamed the prwin16.h header to prwin.h
  * configure was updated from 2.69 to 2.71
  * various build, test and automation script fixes
  * major parts of the source code were reformatted

Package mozilla-nss was updated:

- update to NSS 3.112  * bmo#1963792 - Fix alias for mac workers on try
  * bmo#1966786 - ensure all options can be configured with SSL_OptionSet and SSL_OptionSetDefault
  * bmo#1931930 - ABI/API break in ssl certificate processing
  * bmo#1955971 - remove unnecessary assertion in sec_asn1d_init_state_based_on_template
  * bmo#1965754 - update taskgraph to v14.2.1
  * bmo#1964358 - Workflow for automation of the release on GitHub when pushing a tag
  * bmo#1952860 - fix faulty assertions in SEC_ASN1DecoderUpdate
  * bmo#1934877 - Renegotiations should use a fresh ECH GREASE buffer
  * bmo#1951396 - update taskgraph to v14.1.1
  * bmo#1962503 - Partial fix for ACVP build CI job
  * bmo#1961827 - Initialize find in sftk_searchDatabase
  * bmo#1963121 - Add clang-18 to extra builds
  * bmo#1963044 - Fault tolerant git fetch for fuzzing
  * bmo#1962556 - Tolerate intermittent failures in ssl_policy_pkix_ocsp
  * bmo#1962770 - fix compiler warnings when DEBUG_ASN1D_STATES or CMSDEBUG are set
  * bmo#1961835 - fix content type tag check in NSS_CMSMessage_ContainsCertsOrCrls
  * bmo#1963102 - Remove Cryptofuzz CI version check

- update to NSS 3.111
  * bmo#1930806 - FIPS changes need to be upstreamed: force ems policy
  * bmo#1957685 - Turn off Websites Trust Bit from CAs
  * bmo#1937338 - Update nssckbi version following April 2025 Batch of Changes
  * bmo#1943135 - Disable SMIME âtrust bitâ for GoDaddy CAs
  * bmo#1874383 - Replaced deprecated sprintf function with snprintf in dbtool.c
  * bmo#1954612 - Need up update NSS for PKCS 3.1
  * bmo#1773374 - avoid leaking localCert if it is already set in ssl3_FillInCachedSID
  * bmo#1953097 - Decrease ASAN quarantine size for Cryptofuzz in CI
  * bmo#1943962 - selfserv: Add support for zlib certificate compression

- update to NSS 3.110
  * bmo#1930806 - FIPS changes need to be upstreamed: force ems policy
  * bmo#1954724 - Prevent excess allocations in sslBuffer_Grow
  * bmo#1953429 - Remove Crl templates from ASN1 fuzz target
  * bmo#1953429 - Remove CERT_CrlTemplate from ASN1 fuzz target
  * bmo#1952855 - Fix memory leak in NSS_CMSMessage_IsSigned
  * bmo#1930807 - NSS policy updates
  * bmo#1951161 - Improve locking in nssPKIObject_GetInstances
  * bmo#1951394 - Fix race in sdb_GetMetaData
  * bmo#1951800 - Fix member access within null pointer
  * bmo#1950077 - Increase smime fuzzer memory limit
  * bmo#1949677 - Enable resumption when using custom extensions
  * bmo#1952568 - change CN of server12 test certificate
  * bmo#1949118 - Part 2: Add missing check in
    NSS_CMSDigestContext_FinishSingle
  * bmo#1949118 - Part 1: Fix smime UBSan errors
  * bmo#1930806 - FIPS changes need to be upstreamed: updated key checks
  * bmo#1951491 - Don't build libpkix in static builds
  * bmo#1951395 - handle `-p all` in try syntax
  * bmo#1951346 - fix opt-make builds to actually be opt
  * bmo#1951346 - fix opt-static builds to actually be opt
  * bmo#1916439 - Remove extraneous assert
- Removed upstreamed nss-fips-stricter-dh.patch
- Added bmo1962556.patch to fix test failures
- Rebased nss-fips-approved-crypto-non-ec.patch nss-fips-combined-hash-sign-dsa-ecdsa.patch
- update to NSS 3.109
  * bmo#1939512 - Call BL_Init before RNG_RNGInit() so that special
    SHA instructions can be used if available
  * bmo#1930807 - NSS policy updates - fix inaccurate key policy issues
  * bmo#1945883 - SMIME fuzz target
  * bmo#1914256 - ASN1 decoder fuzz target
  * bmo#1936001 - Part 2: Revert âExtract testcases from ssl gtests
    for fuzzingâ
  * bmo#1915155 - Add fuzz/README.md
  * bmo#1936001 - Part 4: Fix tstclnt arguments script
  * bmo#1944545 - Extend pkcs7 fuzz target
  * bmo#1912320 - Extend certDN fuzz target
  * bmo#1944300 - revert changes to HACL* files from bug 1866841
  * bmo#1936001 - Part 3: Package frida corpus script
- update to NSS 3.108
  * bmo#1923285 - libclang-16 -&amp;gt; libclang-19
  * bmo#1939086 - Turn off Secure Email Trust Bit for Security
    Communication ECC RootCA1
  * bmo#1937332 - Turn off Secure Email Trust Bit for BJCA Global Root
    CA1 and BJCA Global Root CA2
  * bmo#1915902 - Remove SwissSign Silver CA â G2
  * bmo#1938245 - Add D-Trust 2023 TLS Roots to NSS
  * bmo#1942301 - fix fips test failure on windows
  * bmo#1935925 - change default sensitivity of KEM keys
  * bmo#1936001 - Part 1: Introduce frida hooks and script
  * bmo#1942350 - add missing arm_neon.h include to gcm.c
  * bmo#1831552 - ci: update windows workers to win2022
  * bmo#1831552 - strip trailing carriage returns in tools tests
  * bmo#1880256 - work around unix/windows path translation issues
    in cert test script
  * bmo#1831552 - ci: let the windows setup script work without $m
  * bmo#1880255 - detect msys
  * bmo#1936680 - add a specialized CTR_Update variant for AES-GCM
  * bmo#1930807 - NSS policy updates
  * bmo#1930806 - FIPS changes need to be upstreamed: FIPS 140-3 RNG
  * bmo#1930806 - FIPS changes need to be upstreamed: Add SafeZero
  * bmo#1930806 - FIPS changes need to be upstreamed - updated POST
  * bmo#1933031 - Segmentation fault in SECITEM_Hash during pkcs12 processing
  * bmo#1929922 - Extending NSS with LoadModuleFromFunction functionality
  * bmo#1935984 - Ensure zero-initialization of collectArgs.cert
  * bmo#1934526 - pkcs7 fuzz target use CERT_DestroyCertificate
  * bmo#1915898 - Fix actual underlying ODR violations issue
  * bmo#1184059 - mozilla::pkix: allow reference ID labels to begin
    and/or end with hyphens
  * bmo#1927953 - don't look for secmod.db in nssutil_ReadSecmodDB if
    NSS_DISABLE_DBM is set
  * bmo#1934526 - Fix memory leak in pkcs7 fuzz target
  * bmo#1934529 - Set -O2 for ASan builds in CI
  * bmo#1934543 - Change branch of tlsfuzzer dependency
  * bmo#1915898 - Run tests in CI for ASan builds with detect_odr_violation=1
  * bmo#1934241 - Fix coverage failure in CI
  * bmo#1934213 - Add fuzzing for delegated credentials, DTLS short
    header and Tls13BackendEch
  * bmo#1927142 - Add fuzzing for SSL_EnableTls13GreaseEch and
    SSL_SetDtls13VersionWorkaround
  * bmo#1913677 - Part 3: Restructure fuzz/
  * bmo#1931925 - Extract testcases from ssl gtests for fuzzing
  * bmo#1923037 - Force Cryptofuzz to use NSS in CI
  * bmo#1923037 - Fix Cryptofuzz on 32 bit in CI
  * bmo#1933154 - Update Cryptofuzz repository link
  * bmo#1926256 - fix build error from 9505f79d
  * bmo#1926256 - simplify error handling in get_token_objects_for_cache
  * bmo#1931973 - nss doc: fix a warning
  * bmo#1930797 - pkcs12 fixes from RHEL need to be picked up
- remove obsolete patches
  * nss-fips-safe-memset.patch
  * nss-bmo1930797.patch
- update to NSS 3.107
  * bmo#1923038 - Remove MPI fuzz targets.
  * bmo#1925512 - Remove globals `lockStatus` and `locksEverDisabled`.
  * bmo#1919015 - Enable PKCS8 fuzz target.
  * bmo#1923037 - Integrate Cryptofuzz in CI.
  * bmo#1913677 - Part 2: Set tls server target socket options in config class
  * bmo#1913677 - Part 1: Set tls client target socket options in config class
  * bmo#1913680 - Support building with thread sanitizer.
  * bmo#1922392 - set nssckbi version number to 2.72.
  * bmo#1919913 - remove Websites Trust Bit from Entrust Root
    Certification Authority - G4.
  * bmo#1920641 - remove Security Communication RootCA3 root cert.
  * bmo#1918559 - remove SecureSign RootCA11 root cert.
  * bmo#1922387 - Add distrust-after for TLS to Entrust Roots.
  * bmo#1927096 - update expected error code in pk12util pbmac1 tests.
  * bmo#1929041 - Use random tstclnt args with handshake collection script
  * bmo#1920466 - Remove extraneous assert in ssl3gthr.c.
  * bmo#1928402 - Adding missing release notes for NSS_3_105.
  * bmo#1874451 - Enable the disabled mlkem tests for dtls.
  * bmo#1874451 - NSS gtests filter cleans up the constucted buffer
    before the use.
  * bmo#1925505 - Make ssl_SetDefaultsFromEnvironment thread-safe.
  * bmo#1925503 - Remove short circuit test from ssl_Init.
- fix build on loongarch64 (setting it as 64bit arch)
- Remove upstreamed bmo-1400603.patch
- Added nss-bmo1930797.patch to fix failing tests in testsuite
- update to NSS 3.106
  * bmo#1925975 - NSS 3.106 should be distributed with NSPR 4.36.
  * bmo#1923767 - pk12util: improve error handling in p12U_ReadPKCS12File.
  * bmo#1899402 - Correctly destroy bulkkey in error scenario.
  * bmo#1919997 - PKCS7 fuzz target, r=djackson,nss-reviewers.
  * bmo#1923002 - Extract certificates with handshake collection script.
  * bmo#1923006 - Specify len_control for fuzz targets.
  * bmo#1923280 - Fix memory leak in dumpCertificatePEM.
  * bmo#1102981 - Fix UBSan errors for SECU_PrintCertificate and
    SECU_PrintCertificateBasicInfo.
  * bmo#1921528 - add new error codes to mozilla::pkix for Firefox to use.
  * bmo#1921768 - allow null phKey in NSC_DeriveKey.
  * bmo#1921801 - Only create seed corpus zip from existing corpus.
  * bmo#1826035 - Use explicit allowlist for for KDF PRFS.
  * bmo#1920138 - Increase optimization level for fuzz builds.
  * bmo#1920470 - Remove incorrect assert.
  * bmo#1914870 - Use libFuzzer options from fuzz/options/\*.options in CI.
  * bmo#1920945 - Polish corpus collection for automation.
  * bmo#1917572 - Detect new and unfuzzed SSL options.
  * bmo#1804646 - PKCS12 fuzzing target.
- requires NSPR 4.36
- update to NSS 3.105
  * bmo#1915792 - Allow importing PKCS#8 private EC keys missing public key
  * bmo#1909768 - UBSAN fix: applying zero offset to null pointer in sslsnce.c
  * bmo#1919577 - set KRML_MUSTINLINE=inline in makefile builds
  * bmo#1918965 - Don't set CKA_SIGN for CKK_EC_MONTGOMERY private keys
  * bmo#1918767 - override default definition of KRML_MUSTINLINE
  * bmo#1916525 - libssl support for mlkem768x25519
  * bmo#1916524 - support for ML-KEM-768 in softoken and pk11wrap
  * bmo#1866841 - Add Libcrux implementation of ML-KEM 768 to FreeBL
  * bmo#1911912 - Avoid misuse of ctype(3) functions
  * bmo#1917311 - part 2: run clang-format
  * bmo#1917311 - part 1: upgrade to clang-format 13
  * bmo#1916953 - clang-format fuzz
  * bmo#1910370 - DTLS client message buffer may not empty be on retransmit
  * bmo#1916413 - Optionally print config for TLS client and server
    fuzz target
  * bmo#1916059 - Fix some simple documentation issues in NSS.
  * bmo#1915439 - improve performance of NSC_FindObjectsInit when
    template has CKA_TOKEN attr
  * bmo#1912828 - define CKM_NSS_ECDHE_NO_PAIRWISE_CHECK_KEY_PAIR_GEN
- Fix build error under Leap by rebasing nss-fips-safe-memset.patch.
- update to NSS 3.104
  * bmo#1910071 - Copy original corpus to heap-allocated buffer
  * bmo#1910079 - Fix min ssl version for DTLS client fuzzer
  * bmo#1908990 - Remove OS2 support just like we did on NSPR
  * bmo#1910605 - clang-format NSS improvements
  * bmo#1902078 - Adding basicutil.h to use HexString2SECItem function
  * bmo#1908990 - removing dirent.c from build
  * bmo#1902078 - Allow handing in keymaterial to shlibsign to make
    the output reproducible
  * bmo#1908990 - remove nec4.3, sunos4, riscos and SNI references
  * bmo#1908990 - remove other old OS (BSDI, old HP UX, NCR,
    openunix, sco, unixware or reliantUnix
  * bmo#1908990 - remove mentions of WIN95
  * bmo#1908990 - remove mentions of WIN16
  * bmo#1913750 - More explicit directory naming
  * bmo#1913755 - Add more options to TLS server fuzz target
  * bmo#1913675 - Add more options to TLS client fuzz target
  * bmo#1835240 - Use OSS-Fuzz corpus in NSS CI
  * bmo#1908012 - set nssckbi version number to 2.70.
  * bmo#1914499 - Remove Email Trust bit from ACCVRAIZ1 root cert.
  * bmo#1908009 - Remove Email Trust bit from certSIGN ROOT CA.
  * bmo#1908006 - Add Cybertrust Japan Roots to NSS.
  * bmo#1908004 - Add Taiwan CA Roots to NSS.
  * bmo#1911354 - remove search by decoded serial in
    nssToken_FindCertificateByIssuerAndSerialNumber
  * bmo#1913132 - Fix tstclnt CI build failure
  * bmo#1913047 - vfyserv: ensure peer cert chain is in db for
    CERT_VerifyCertificateNow
  * bmo#1912427 - Enable all supported protocol versions for UDP
  * bmo#1910361 - Actually use random PSK hash type
  * bmo#1911576 - Initialize NSS DB once
  * bmo#1910361 - Additional ECH cipher suites and PSK hash types
  * bmo#1903604 - Automate corpus file generation for TLS client Fuzzer
  * bmo#1910364 - Fix crash with UNSAFE_FUZZER_MODE
  * bmo#1910605 - clang-format shlibsign.c
- remove obsolete nss-reproducible-builds.patch
- update to NSS 3.103
  * bmo#1908623 - move list size check after lock acquisition in sftk_PutObjectToList.
  * bmo#1899542 - Add fuzzing support for SSL_ENABLE_POST_HANDSHAKE_AUTH,
  * bmo#1909638 - Follow-up to fix test for presence of file nspr.patch.
  * bmo#1903783 - Adjust libFuzzer size limits
  * bmo#1899542 - Add fuzzing support for SSL_SetCertificateCompressionAlgorithm,
    SSL_SetClientEchConfigs, SSL_VersionRangeSet and SSL_AddExternalPsk
  * bmo#1899542 - Add fuzzing support for SSL_ENABLE_GREASE and
    SSL_ENABLE_CH_EXTENSION_PERMUTATION
- Add nss-reproducible-builds.patch to make the rpms reproducible,
  by using a hardcoded, static key to generate the checksums (*.chk-files)
- Updated nss-fips-approved-crypto-non-ec.patch to enforce
  approved curves with the CKK_EC_MONTGOMERY key type (bsc#1224113).
- update to NSS 3.102.1
  * bmo#1905691 - ChaChaXor to return after the function
- update to NSS 3.102
  * bmo#1880351 - Add Valgrind annotations to freebl Chacha20-Poly1305.
  * bmo#1901932 - missing sqlite header.
  * bmo#1901080 - GLOBALTRUST 2020: Set Distrust After for TLS and S/MIME.
  * bmo#1615298 - improve certutil keyUsage, extKeyUsage, and nsCertType keyword handling.
  * bmo#1660676 - correct length of raw SPKI data before printing in pp utility.

- Add nss-reproducible-chksums.patch to make NSS-build reproducible
  Use key from openssl (bsc#1081723)

- Updated nss-fips-approved-crypto-non-ec.patch to exclude the
  SHA-1 hash from SLI approval.

Package nvme-cli was updated:

- Update to version 2.11+28.g2fc67685:  * netapp-ontapdev: update invalid device handling (bsc#1247017)
  * netapp-smdev: update invalid device handling (bsc#1247017)

- Update to version 2.11+26.gfbd2b4f4:
  * nvme: fix mem leak in nvme copy (bsc#1243716)
  * nvme-print: suppress output when no ctrl is present for list-subsys (bsc#1243716)
  * nvme: extend filter to match device name (bsc#1243716)
  * udev-rules-ontap: switch to queue-depth iopolicy (bsc#1246599)

Package openssh was updated:

Package pam-config was updated:

- Stop adding pam_env in AUTH stack, and be sure to put this module at the  really end of the SESSION stack.
  [bsc#1243226, CVE-2025-6018, remove-pam_env-from-auth-stack.patch]

Package pam was updated:

- Make sure that the buffer containing encrypted passwords get's erased  bedore free.
- Replace to previous CVE fix which led to CPU performance issues.
  [bsc#1246221, CVE-2024-10041,
  + libpam-introduce-secure-memory-erasure-helpers.patch
  + pam_modutil_get-overwrite-password-at-free.patch
  - passverify-always-run-the-helper-to-obtain-shadow_pwd.patch]

Package perl-Bootloader was updated:

- merge gh#openSUSE/perl-bootloader#191- avoid spurious warning messages when parsing /etc/default/grub
  (bsc#1246373, bsc#1245323)
- 1.25

Package perl was updated:

- do not change the current directory when cloning an open  directory handle [bnc#1244079] [CVE-2025-40909]
  new patch: perl-dirdup.diff

Package python-instance-billing-flavor-check was updated:

- Update to version 1.0.1  + Fix infinite loop (bsc#1242064)
  + Fix bug in update infrastructure request (bsc#1242064)

Package python-appdirs was updated:

- Add python36-appdirs provides/obsoletes to enable SLE-12 -&amp;gt;  SLE-15 migration, bsc#1233012

Package python-asn1crypto was updated:

- Add python36-asn1crypto provides/obsoletes to enable SLE-12 -&amp;gt;  SLE-15 migration, bsc#1233012

Package python-certifi was updated:

- Add python36-certifi provides/obsoletes to enable SLE-12 -&amp;gt;  SLE-15 migration, bsc#1233012

Package python-chardet was updated:

- Add python36-chardet provides/obsoletes to enable SLE-12 -&amp;gt;  SLE-15 migration, bsc#1233012

Package python3-cryptography was updated:

- Add python36-cryptography provides/obsoletes to enable SLE-12 -&amp;gt;  SLE-15 migration, bsc#1233012
- Skipping failing test

Package python-decorator was updated:

- Add python36-decorator provides/obsoletes to enable SLE-12 -&amp;gt;  SLE-15 migration, bsc#1233012

Package python-idna was updated:

- Add python36-idna provides/obsoletes to enable SLE-12 -&amp;gt;  SLE-15 migration, bsc#1233012

Package python-packaging was updated:

- Add python36-packaging provides/obsoletes to enable SLE-12 -&amp;gt;  SLE-15 migration, bsc#1233012

Package python3-pyOpenSSL was updated:

- Add python36-pyOpenSSL provides/obsoletes to enable SLE-12 -&amp;gt;  SLE-15 migration, bsc#1233012

Package python-pyasn1 was updated:

- Add python36-pyasn1 provides/obsoletes to enable SLE-12 -&amp;gt;  SLE-15 migration, bsc#1233012

Package python-pycparser was updated:

- Add python36-pycparser provides/obsoletes to enable SLE-12 -&amp;gt;  SLE-15 migration, bsc#1233012

Package python-pyparsing was updated:

- Add python36-pyparsing provides/obsoletes to enable SLE-12 -&amp;gt;  SLE-15 migration, bsc#1233012

Package python-py was updated:

- Add python36-py provides/obsoletes to enable SLE-12 -&amp;gt;  SLE-15 migration, bsc#1233012

Package python-requests was updated:

- Add python36- provides/obsoletes to enable SLE-12 -&amp;gt;  SLE-15 migration, bsc#1233012

- Add CVE-2024-47081.patch upstream patch, fixes netrc credential leak
  (gh#psf/requests#6965, CVE-2024-47081, bsc#1244039)

Package python3-setuptools was updated:

- Add python36-setuptools provides/obsoletes to enable SLE-12 -&amp;gt;  SLE-15 migration, bsc#1233012

Package python-six was updated:

- Add python36-six provides/obsoletes to enable SLE-12 -&amp;gt;  SLE-15 migration, bsc#1233012

Package python-urllib3 was updated:

- Add patch CVE-2025-50181-poolmanager-redirects.patch:  * Pool managers now properly control redirects when retries is passed
    (CVE-2025-50181, GHSA-pq67-6m6q-mj2v, bsc#1244925)

- Add python36-urllib3 provides/obsoletes to enable SLE-12 -&amp;gt;
  SLE-15 migration, bsc#1233012

Package salt was updated:

- Add `minion_legacy_req_warnings` option to avoid noisy warnings- Require M2Crypto &amp;gt;= 0.44.0 for SUSE Family distros
- Added:
  * add-minion_legacy_req_warnings-option-to-avoid-noisy.patch

- Prevent tests failures when pygit2 is not present
- Several fixes for security issues
  (bsc#1244561, CVE-2024-38822)
  (bsc#1244564, CVE-2024-38823)
  (bsc#1244565, CVE-2024-38824)
  (bsc#1244566, CVE-2024-38825)
  (bsc#1244567, CVE-2025-22240)
  (bsc#1244568, CVE-2025-22236)
  (bsc#1244570, CVE-2025-22241)
  (bsc#1244571, CVE-2025-22237)
  (bsc#1244572, CVE-2025-22238)
  (bsc#1244574, CVE-2025-22239)
  (bsc#1244575, CVE-2025-22242)
  * Request server hardening
  * Prevent traversal in local_cache::save_minions
  * Add test and fix for file_recv cve
  * Fix traversal in gitfs find_file
  * Fix traversal in salt.utils.virt
  * Fix traversal in pub_ret
  * Reasonable failures when pillars timeout
  * Make send_req_async wait longer
  * Remove token to prevent decoding errors
  * Fix checking of non-url style git remotes
  * Allow subdirs in GitFS find_file check
- Add subsystem filter to udev.exportdb (bsc#1236621)
- tornado.httputil: raise errors instead of logging in
  multipart/form-data parsing (CVE-2025-47287, bsc#1243268)
- Fix Ubuntu 24.04 edge-case test failures
- Fix broken tests for Ubuntu 24.04
- Fix refresh of osrelease and related grains on Python 3.10+
- Make &amp;quot;salt&amp;quot; package to obsolete &amp;quot;python3-salt&amp;quot; package on SLE15SP7+
- Fix issue requiring proper Python flavor for dependencies and recommended package
- Added:
  * fix-tests-issues-in-salt-shaker-environments-721.patch
  * several-fixes-for-security-issues.patch
  * add-subsystem-filter-to-udev.exportdb-bsc-1236621-71.patch
  * fix-of-cve-2025-47287-bsc-1243268-718.patch
  * fix-ubuntu-24.04-specific-failures-716.patch
  * fix-debian-tests-715.patch
  * fix-refresh-of-osrelease-and-related-grains-on-pytho.patch

Package regionServiceClientConfigGCE was updated:

- Update to version 5.0.0 (bsc#1246995)  + SLE 16 python-requests requiers SSL v3 certificates. Update 2
    region server certs to support SLE 16 when it gets released.

- Update conditional to handle name change of metadata package
  in SLE 16 (bsc#1242063)

Package rubygem-gem2rpm was updated:

- update suse.patch  - use opensuse template on sles as well

- update suse.patch
  - on newer rubies Kernel.open is no longer working with URIs.
    use URI.open()
  - also treat contributing as documentation.

- instead of using %{ruby} for the buildrequires, lets expand it
  in the spec file so we do not have to use
  rb_build_ruby_abis/rb_build_version

Package runc was updated:

- Update to runc v1.2.6. Upstream changelog is available from  &amp;lt;https://github.com/opencontainers/runc/releases/tag/v1.2.6&amp;gt;.

- Update to runc v1.2.5. Upstream changelog is available from
  &amp;lt;https://github.com/opencontainers/runc/releases/tag/v1.2.5&amp;gt;.

- Update to runc v1.2.4. Upstream changelog is available from
  &amp;lt;https://github.com/opencontainers/runc/releases/tag/v1.2.4&amp;gt;.
- Update runc.keyring to match upstream.

- Update to runc v1.2.3. Upstream changelog is available from
  &amp;lt;https://github.com/opencontainers/runc/releases/tag/v1.2.3&amp;gt;.

- Update to runc v1.2.2. Upstream changelog is available from
  &amp;lt;https://github.com/opencontainers/runc/releases/tag/v1.2.2&amp;gt;.

- Update to runc v1.2.1. Upstream changelog is available from
  &amp;lt;https://github.com/opencontainers/runc/releases/tag/v1.2.1&amp;gt;.

- Update to runc v1.2.0. Upstream changelog is available from
  &amp;lt;https://github.com/opencontainers/runc/releases/tag/v1.2.0&amp;gt;.
- Remove upstreamed patches.
  - 0001-bsc1221050-libct-seccomp-patchbpf-rm-duplicated-code.patch
  - 0002-bsc1221050-seccomp-patchbpf-rename-nativeArch-linuxA.patch
  - 0003-bsc1221050-seccomp-patchbpf-always-include-native-ar.patch
  - 0004-bsc1214960-nsenter-cloned_binary-remove-bindfd-logic.patch

- Update to runc v1.2.0~rc3. Upstream changelog is available from
  &amp;lt;https://github.com/opencontainers/runc/releases/tag/v1.2.0-rc.3&amp;gt;.
  Includes the patch for CVE-2024-45310. bsc#1230092

Package sudo was updated:

- Fix a possible local privilege escalation via the --host option  [bsc#1245274, CVE-2025-32462]
- Fix a possible local privilege Escalation via chroot option
  [bsc#1245275, CVE-2025-32463]

Package suse-build-key was updated:

- adjust UID (name + email) of SLES16 signing key with official  names. (bsc#1245223)

Package suse-module-tools was updated:

- Update to version 15.7.6:  * spec file: add missing util-linux requirement (bsc#1241038)

Package systemd-presets-branding-SLE was updated:

- enable sysstat_collect.timer and sysstat_summary.timer [bsc#1244553]  and [bsc#1246835]
- modified sources
  % default-SLE.preset

Package systemd-rpm-macros was updated:

- Bump version to 16
- Introduce %udev_trigger_with_reload() for packages that need to trigger events
  in theirs scriplets. The new macro automatically triggers a reload of the udev
  rule files as this step is often overlooked by packages (bsc#1237143).

Package vim was updated:

- Fix bsc#1228776 / CVE-2024-41965.- Fix bsc#1239602 / CVE-2025-29768.
- Refresh patch:
  vim-7.3-sh_is_bash.patch
- Update to 9.1.1406:
  9.1.1406: crash when importing invalid tuple
  9.1.1405: tests: no test for mapping with special keys in session file
  9.1.1404: wrong link to Chapter 2 in new-tutor
  9.1.1403: expansion of 'tabpanelopt' value adds wrong values
  9.1.1402: multi-byte mappings not properly stored in session file
  9.1.1401: list not materialized in prop_list()
  9.1.1400: [security]: use-after-free when evaluating tuple fails
  9.1.1399: tests: test_codestyle fails for auto-generated files
  9.1.1398: completion: trunc does not follow Pmenu highlighting attributes
  9.1.1397: tabpanel not correctly updated on :tabonly
  9.1.1396: 'errorformat' is a global option
  9.1.1395: search_stat not reset when pattern differs in case
  9.1.1394: tabpanel not correctly redrawn on tabonly
  9.1.1393: missing test for switching buffers and reusing curbuf
  9.1.1392: missing patch number
  9.1.1391: Vim does not have a vertical tabpanel
  9.1.1390: style: more wrong indentation
  9.1.1389: completion: still some issue when 'isexpand' contains a space
  9.1.1388: Scrolling one line too far with 'nosmoothscroll' page scrolling
  9.1.1387: memory leak when buflist_new() fails to reuse curbuf
  9.1.1386: MS-Windows: some minor problems building on AARCH64
  9.1.1385: inefficient loop for 'nosmoothscroll' scrolling
  9.1.1384: still some problem with the new tutors filetype plugin
  9.1.1383: completion: 'isexpand' option does not handle space char correct
  9.1.1382: if_ruby: unused compiler warnings from ruby internals
  9.1.1381: completion: cannot return to original text
  9.1.1380: 'eventignorewin' only checked for current buffer
  9.1.1379: MS-Windows: error when running evim when space in path
  9.1.1378: sign without text overwrites number option
  9.1.1377: patch v9.1.1370 causes some GTK warning messages
  9.1.1376: quickfix dummy buffer may remain as dummy buffer
  9.1.1375: [security]: possible heap UAF with quickfix dummy buffer
  9.1.1374: completion: 'smartcase' not respected when filtering matches
  9.1.1373: 'completeopt' checking logic can be simplified
  9.1.1372: style: braces issues in various files
  9.1.1371: style: indentation and brace issues in insexpand.c
  9.1.1370: CI Tests favor GTK2 over GTK3
  9.1.1369: configure still using autoconf 2.71
  9.1.1368: GTK3 and GTK4 will drop numeric cursor support.
  9.1.1367: too many strlen() calls in gui.c
  9.1.1366: v9.1.1364 unintentionally changed sign.c and sound.c
  9.1.1365: MS-Windows: compile warnings and too many strlen() calls
  9.1.1364: style: more indentation issues
  9.1.1363: style: inconsistent indentation in various files
  9.1.1362: Vim9: type ignored when adding tuple to instance list var
  9.1.1361: [security]: possible use-after-free when closing a buffer
  9.1.1360: filetype: GNU Radio companion files are not recognized
  9.1.1359: filetype: GNU Radio config files are not recognized
  9.1.1358: if_lua: compile warnings with gcc15
  9.1.1357: Vim incorrectly escapes tags with &amp;quot;[&amp;quot; in a help buffer
  9.1.1356: Vim9: crash when unletting variable
  9.1.1355: The pum_redraw() function is too complex
  9.1.1354: tests: Test_terminalwinscroll_topline() fails on Windows
  9.1.1353: missing change from v9.1.1350
  9.1.1352: style: inconsistent indent in insexpand.c
  9.1.1351: Return value of getcmdline() inconsistent in CmdlineLeavePre
  9.1.1350: tests: typo in Test_CmdlineLeavePre_cabbr()
  9.1.1349: CmdlineLeavePre may trigger twice
  9.1.1348: still E315 with the terminal feature
  9.1.1347: small problems with gui_w32.c
  9.1.1346: missing out-of-memory check in textformat.c
  9.1.1345: tests: Test_xxd_color2() test failure dump diff is misleading
  9.1.1344: double free in f_complete_match() (after v9.1.1341)
  9.1.1343: filetype: IPython files are not recognized
  9.1.1342: Shebang filetype detection can be improved
  9.1.1341: cannot define completion triggers
  9.1.1340: cannot complete :filetype arguments
  9.1.1339: missing out-of-memory checks for enc_to_utf16()/utf16_to_enc()
  9.1.1338: Calling expand() interferes with cmdcomplete_info()
  9.1.1337: Undo corrupted with 'completeopt' &amp;quot;preinsert&amp;quot; when switching buffer
  9.1.1336: comment plugin does not support case-insensitive 'commentstring'
  9.1.1335: Coverity complains about Null pointer dereferences
  9.1.1334: Coverity complains about unchecked return value
  9.1.1333: Coverity: complains about unutilized variable
  9.1.1332: Vim9: segfault when using super within a lambda
  9.1.1331: Leaking memory with cmdcomplete()
  9.1.1330: may receive E315 in terminal
  9.1.1329: cannot get information about command line completion
  9.1.1328: too many strlen() calls in indent.c
  9.1.1327: filetype: nroff detection can be improved
  9.1.1326: invalid cursor position after 'tagfunc'
  9.1.1325: tests: not checking error numbers properly
  9.1.1324: undefined behaviour if X11 connection dies
  9.1.1323: b:undo_ftplugin not executed when re-using buffer
  9.1.1322: small delete register cannot paste multi-line correctly
  9.1.1321: filetype: MS ixx and mpp files are not recognized
  9.1.1320: filetype: alsoft config files are not recognized
  9.1.1319: Various typos in the code, issue with test_inst_complete.vim
  9.1.1318: tests: test_format fails
  9.1.1317: noisy error when restoring folds from session fails
  9.1.1316: missing memory allocation failure in os_mswin.c
  9.1.1315: completion: issue with fuzzy completion and 'completefuzzycollect'
  9.1.1314: max allowed string width too small
  9.1.1313: compile warning about uninitialized value
  9.1.1312: tests: Test_backupskip() fails when HOME is defined
  9.1.1311: completion: not possible to limit number of matches
  9.1.1310: completion: redundant check for preinsert effect
  9.1.1309: tests: no test for 'pummaxwidth' with non-truncated &amp;quot;kind&amp;quot;
  9.1.1308: completion: cannot order matches by distance to cursor
  9.1.1307: make syntax does not reliably detect different flavors
  9.1.1306: completion menu rendering can be improved
  9.1.1305: completion menu active after switching windows/tabs
  9.1.1304: filetype: some man files are not recognized
  9.1.1303: missing out-of-memory check in linematch.c
  9.1.1302: Coverity warns about using uninitialized value
  9.1.1301: completion: cannot configure completion functions with 'complete'
  9.1.1300: wrong detection of -inf
  9.1.1299: filetype: mbsyncrc files are not recognized
  9.1.1298: define_function() is too long
  9.1.1297: Ctrl-D scrolling can get stuck
  9.1.1296: completion: incorrect truncation logic
  9.1.1295: clientserver: does not handle :stopinsert correctly
  9.1.1294: gui tabline menu does not use confirm when closing tabs
  9.1.1293: comment plugin does not handle 'exclusive' selection for comment object
  9.1.1292: statusline not correctly evaluated
  9.1.1291: too many strlen() calls in buffer.c
  9.1.1290: tests: missing cleanup in test_filetype.vim
  9.1.1289: tests: no test for matchparen plugin with WinScrolled event
  9.1.1288: Using wrong window in ll_resize_stack()
  9.1.1287: quickfix code can be further improved
  9.1.1286: filetype: help files not detected when 'iskeyword' includes &amp;quot;:&amp;quot;
  9.1.1285: Vim9: no error message for missing method after &amp;quot;super.&amp;quot;
  9.1.1284: not possible to configure pum truncation char
  9.1.1283: quickfix stack is limited to 10 items
  9.1.1282: Build and test failure without job feature
  9.1.1281: extra newline output when editing stdin
  9.1.1280: trailing additional semicolon in get_matches_in_str()
  9.1.1279: Vim9: null_object and null_class are no reserved names
  9.1.1278: Vim9: too long functions in vim9type.c
  9.1.1277: tests: trailing comment char in test_popupwin
  9.1.1276: inline word diff treats multibyte chars as word char
  9.1.1275: MS-Windows: Not possible to pass additional flags to Make_mvc
  9.1.1274: Vim9: no support for object&amp;lt;type&amp;gt; as variable type
  9.1.1273: Coverity warns about using uninitialized value
  9.1.1272: completion: in keyword completion Ctrl_P cannot go back after Ctrl_N
  9.1.1271: filetype: Power Query files are not recognized
  9.1.1270: missing out-of-memory checks in buffer.c
  9.1.1269: completion: compl_shown_match is updated when starting keyword completion
  9.1.1268: filetype: dax files are not recognized
  9.1.1267: Vim9: no support for type list/dict&amp;lt;object&amp;lt;any&amp;gt;&amp;gt;
  9.1.1266: MS-Windows: type conversion warnings
  9.1.1265: tests: no tests for typing normal char during completion
  9.1.1264: Vim9: error when comparing objects
  9.1.1263: string length wrong in get_last_inserted_save()
  9.1.1262: heap-buffer-overflow with narrow 'pummaxwidth' value
  9.1.1261: No test for 'pummaxwidth' non-truncated items
  9.1.1260: Hang when filtering buffer with NUL bytes
  9.1.1259: some issues with comment package and tailing spaces
  9.1.1258: regexp: max \U and \%U value is limited by INT_MAX
  9.1.1257: Mixing vim_strsize() with mb_ptr2cells() in pum_redraw()
  9.1.1256: if_python: duplicate tuple data entries
  9.1.1255: missing test condition for 'pummaxwidth' setting
  9.1.1254: need more tests for the comment plugin
  9.1.1253: abort when closing window with attached quickfix data
  9.1.1252: typos in code and docs related to 'diffopt' &amp;quot;inline:&amp;quot;
  9.1.1251: if_python: build error with tuples and dynamic python
  9.1.1250: cannot set the maximum popup menu width
  9.1.1249: tests: no test that 'listchars' &amp;quot;eol&amp;quot; doesn't affect &amp;quot;gM&amp;quot;
  9.1.1248: compile error when building without FEAT_QUICKFIX
  9.1.1247: fragile setup to get (preferred) keys from key_name_entry
  9.1.1246: coverity complains about some changes in v9.1.1243
  9.1.1245: need some more tests for curly braces evaluation
  9.1.1244: part of patch v9.1.1242 was wrong
  9.1.1243: diff mode is lacking for changes within lines
  9.1.1242: Crash when evaluating variable name
  9.1.1241: wrong preprocessort indentation in term.c
  9.1.1240: Regression with ic/ac text objects and comment plugin
  9.1.1239: if_python: no tuple data type support
  9.1.1238: wrong cursor column with 'set splitkeep=screen'
  9.1.1237: Compile error with C89 compiler in term.c
  9.1.1236: tests: test_comments leaves swapfiles around
  9.1.1235: cproto files are outdated
  9.1.1234: Compile error when SIZE_MAX is not defined
  9.1.1233: Coverity warns about NULL pointer when triggering WinResized
  9.1.1232: Vim script is missing the tuple data type
  9.1.1231: filetype: SPA JSON files are not recognized
  9.1.1230: inconsistent CTRL-C behaviour for popup windows
  9.1.1229: the comment plugin can be improved
  9.1.1228: completion: current position column wrong after got a match
  9.1.1227: no tests for the comment package
  9.1.1226: &amp;quot;shellcmdline&amp;quot; completion doesn't work with input()
  9.1.1225: extra NULL check in VIM_CLEAR()
  9.1.1224: cannot :put while keeping indent
  9.1.1223: wrong translation used for encoding failures
  9.1.1222: using wrong length for last inserted string
  9.1.1221: Wrong cursor pos when leaving Insert mode just after 'autoindent'
  9.1.1220: filetype: uv.lock file not recognized
  9.1.1219: Strange error with wrong type for matchfuzzy() &amp;quot;camelcase&amp;quot;
  9.1.1218: missing out-of-memory check in filepath.c
  9.1.1217: tests: typos in test_matchfuzzy.vim
  9.1.1216: Pasting the '.' register multiple times may not work
  9.1.1215: Patch 9.1.1213 has some issues
  9.1.1214: matchfuzzy() can be improved for camel case matches
  9.1.1213: cannot :put while keeping indent
  9.1.1212: too many strlen() calls in edit.c
  9.1.1212: filetype: logrotate'd pacmanlogs are not recognized
  9.1.1211: TabClosedPre is triggered just before the tab is being freed
  9.1.1210: translation(ru): missing Russian translation for the new tutor
  9.1.1209: colorcolumn not drawn after virtual text lines
  9.1.1208: MS-Windows: not correctly restoring alternate screen on Win 10
  9.1.1207: MS-Windows: build warning in filepath.c
  9.1.1206: tests: test_filetype fails when a file is a directory
  9.1.1205: completion: preinserted text not removed when closing pum
  9.1.1204: MS-Windows: crash when passing long string to expand()
  9.1.1203: matchparen keeps cursor on case label in sh filetype
  9.1.1202: Missing TabClosedPre autocommand
  9.1.1201: 'completefuzzycollect' does not handle dictionary correctly
  9.1.1200: cmdline pum not cleared for input() completion
  9.1.1199: gvim uses hardcoded xpm icon file
  9.1.1198: [security]: potential data loss with zip.vim
  9.1.1197: process_next_cpt_value() uses wrong condition
  9.1.1196: filetype: config files for container tools are not recognized
  9.1.1195: inside try-block: fn body executed with default arg undefined
  9.1.1194: filetype: false positive help filetype detection
  9.1.1193: Unnecessary use of STRCAT() in au_event_disable()
  9.1.1192: Vim crashes with term response debug logging enabled
  9.1.1191: tests: test for patch 9.1.1186 doesn't fail without the patch
  9.1.1190: C indentation does not detect multibyte labels
  9.1.1189: if_python: build error due to incompatible pointer types
  9.1.1188: runtime(tera): tera support can be improved
  9.1.1187: matchparen plugin wrong highlights shell case statement
  9.1.1186: filetype: help files in git repos are not detected
  9.1.1185: endless loop with completefuzzycollect and no match found
  9.1.1184: Unnecessary use of vim_tolower() in vim_strnicmp_asc()
  9.1.1083: &amp;quot;above&amp;quot; virtual text breaks cursorlineopt=number
  9.1.1182: No cmdline completion for 'completefuzzycollect'
  9.1.1181: Unnecessary STRLEN() calls in insexpand.c
  9.1.1180: short-description
  9.1.1179: too many strlen() calls in misc2.c
  9.1.1178: not possible to generate completion candidates using fuzzy matching
  9.1.1177: filetype: tera files not detected

Package xen was updated:

- Upstream bug fixes (bsc#1027519)  687a40ac-x86-C6-eoi_errata-include-NEHALEM_EX.patch
  68931694-x86-HPET-defer-LAPIC-EOI.patch
  689b0c0c-EFI-cond-FreePages.patch
  68a2e770-x86-mkelf32-pad-segment-to-2Mb.patch
  68a2e7c8-x86-HVM-ioreq-inverted-condition.patch
  68a6ed85-x86-setup-MMCFG-ahead-of-IOMMU.patch
  68ac5f69-x86-adjustments-to-intel_init_ppin.patch

- bsc#1248807 - VUL-0: CVE-2025-27466, CVE-2025-58142,
  CVE-2025-58143: xen: Mutiple vulnerabilities in the Viridian
  interface (XSA-472)
  xsa472-1.patch
  xsa472-2.patch
  xsa472-3.patch

- Update to Xen 4.20.1 bug fix release (jsc#PED-8907)
  * No upstream changelog found in sources or webpage
- bsc#1246112, bsc#1238896 - VUL-0: xen: More AMD transient
  execution attack (CVE-2024-36350, CVE-2024-36357, XSA-471)
  Patches contained in new tarball for 4.20.1
- Drop patches contained in new tarball
  67c818d4-x86-log-unhandled-mem-accesses-for-PVH-dom0.patch
  67c818d5-x86-fixup-p2m-page-faults-for-PVH-dom0.patch
  67c818d6-x86-PVH-dom0-correct-iomem_caps-bound.patch
  67c818d7-x86-IOMMU-account-for-IOMEM-caps-when-populating.patch
  67c818d8-x86-Dom0-relax-Interrupt-Address-Range.patch
  67c86fc1-xl-fix-channel-configuration-setting.patch
  67cb03e0-x86-vlapic-ESR-write-handling.patch
  67d17edd-x86-expose-MSR_FAM10H_MMIO_CONF_BASE-on-AMD.patch
  67d17ede-VT-x-PI-usage-of-msi_desc-msg-field.patch
  67d2a3fe-libxl-avoid-infinite-loop-in-libxl__remove_directory.patch
  67dada68-x86-mm-IS_ALIGNED-in-IS_LnE_ALIGNED.patch
  67ea4268-x86-P2M-sync-fast-slow-p2m_get_page_from_gfn.patch
  67ea428e-percpu-dont-init-on-resume.patch
  67f8ecda-rangeset-incorrect-subtraction.patch
  6800b54f-x86-HVM-update-repeat-count-upon.patch
  68076044-x86emul-clip-rep-count-for-STOS.patch
  6808f549-x86-Intel-work-around-MONITOR-MWAIT-errata.patch
  68221f20-x86-alternative-when-feature-not-present.patch
  68221f21-x86-guest-remove-Xen-hypercall_page.patch
  68221f22-x86-misalign-__x86_indirect_thunk.patch
  68221f23-x86-misalign-RETs-in-clear_bhb_loops.patch
  68221f24-x86-stubs-introduce-place_ret.patch
  68221f25-x86-build-with-Return-Thunks.patch
  68221f26-x86-spec-ctrl-synthesise-ITS_NO.patch
  682dff83-x86-vPCI-BAR-overlaps-with-non-holes.patch
  6835a042-VMX-VMEntry-failure-on-ADL-SPR-with-shadow.patch
  6835a043-x86-PV-breakpoint-reporting.patch
  xsa470.patch

- bsc#1244644 - VUL-0: CVE-2025-27465: xen: x86: Incorrect stubs
  exception handling for flags recovery (XSA-470)
  xsa470.patch
- Upstream bug fixes (bsc#1027519)
  682dff83-x86-vPCI-BAR-overlaps-with-non-holes.patch
  6835a042-VMX-VMEntry-failure-on-ADL-SPR-with-shadow.patch
  6835a043-x86-PV-breakpoint-reporting.patch

- bsc#1243117 - VUL-0: CVE-2024-28956: xen: Intel CPU: Indirect
  Target Selection (ITS) (XSA-469)
  68221f20-x86-alternative-when-feature-not-present.patch
  68221f21-x86-guest-remove-Xen-hypercall_page.patch
  68221f22-x86-misalign-__x86_indirect_thunk.patch
  68221f23-x86-misalign-RETs-in-clear_bhb_loops.patch
  68221f24-x86-stubs-introduce-place_ret.patch
  68221f25-x86-build-with-Return-Thunks.patch
  68221f26-x86-spec-ctrl-synthesise-ITS_NO.patch

- Upstream bug fixes (bsc#1027519)
  67dada68-x86-mm-IS_ALIGNED-in-IS_LnE_ALIGNED.patch
  67ea4268-x86-P2M-sync-fast-slow-p2m_get_page_from_gfn.patch
  67ea428e-percpu-dont-init-on-resume.patch
  67f8ecda-rangeset-incorrect-subtraction.patch
  6800b54f-x86-HVM-update-repeat-count-upon.patch
  68076044-x86emul-clip-rep-count-for-STOS.patch
  6808f549-x86-Intel-work-around-MONITOR-MWAIT-errata.patch

Package yast2-iscsi-client was updated:

- Fix the initialization of the valid iscsi offload cards not  bringing up the network cards with an empty iface name
  (bsc#1246210).

- Ensure to hide passwords (bsc#1246833)
- 4.7.6

Package yast2 was updated:

- Do not try installing packages into the inst-sys during  installation (bsc#1240867)
- 4.7.1

Package yast2-packager was updated:

- Fix Internal Error: Encoding::CompatibilityError when  adding SLE-HA as add-on product (bsc#1245555)
- 4.7.1

Package yast2-users was updated:

Package zsh was updated:

- Update to version 5.8.1  * Dropped patches, which are included upstream now:
  - CVE-2019-20044.patch
  - CVE-2021-45444.patch
  * See included NEWS file for complete changes
  * Implements ECO PED-12771

Package zypper was updated:

- Fix addrepo to handle explicit --check and --no-check requests  (bsc#1246466)
- Accept &amp;quot;show&amp;quot; as alias for &amp;quot;info&amp;quot; (bsc#1245985)
- version 1.14.93

- sh: Reset solver options after command (bsc#1245496)
- Explicitly selecting DownloadAsNeeded also selects the
  classic_rpmtrans backend.
- version 1.14.92

- BuildRequires:  libzypp-devel &amp;gt;= 17.37.6.
  Enhancements regarding mirror handling during repo refresh. Adapt
  to libzypp API changes. (bsc#1230267)
- version 1.14.91

</Note>
    <Note Title="Terms of Use" Type="Legal Disclaimer" Ordinal="3" xml:lang="en">The CVRF data is provided by SUSE under the Creative Commons License 4.0 with Attribution (CC-BY-4.0).</Note>
  </DocumentNotes>
  <DocumentReferences>
    <Reference Type="Self">
      <URL>https://publiccloudimagechangeinfo.suse.com/google/sle-hpc-15-sp7-byos-v20250920-x86-64/</URL>
      <Description>Public Cloud Image Info</Description>
    </Reference>
    <Reference Type="Self">
      <URL>https://www.suse.com/support/security/rating/</URL>
      <Description>SUSE Security Ratings</Description>
    </Reference>
  </DocumentReferences>
  <ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
    <Branch Type="Product Family" Name="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <Branch Type="Product Name" Name="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
        <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
      </Branch>
    </Branch>
    <Branch Type="Product Version" Name="bind-utils-9.20.11-150700.3.6.1">
      <FullProductName ProductID="bind-utils-9.20.11-150700.3.6.1">bind-utils-9.20.11-150700.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="boost-license1_66_0-1.66.0-150200.12.7.1">
      <FullProductName ProductID="boost-license1_66_0-1.66.0-150200.12.7.1">boost-license1_66_0-1.66.0-150200.12.7.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cifs-utils-6.15-150400.3.15.1">
      <FullProductName ProductID="cifs-utils-6.15-150400.3.15.1">cifs-utils-6.15-150400.3.15.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cloud-regionsrv-client-10.5.2-150300.13.29.1">
      <FullProductName ProductID="cloud-regionsrv-client-10.5.2-150300.13.29.1">cloud-regionsrv-client-10.5.2-150300.13.29.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cloud-regionsrv-client-license-watcher-1.0.0-150300.13.29.1">
      <FullProductName ProductID="cloud-regionsrv-client-license-watcher-1.0.0-150300.13.29.1">cloud-regionsrv-client-license-watcher-1.0.0-150300.13.29.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cloud-regionsrv-client-plugin-gce-1.0.0-150300.13.29.1">
      <FullProductName ProductID="cloud-regionsrv-client-plugin-gce-1.0.0-150300.13.29.1">cloud-regionsrv-client-plugin-gce-1.0.0-150300.13.29.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="coreutils-8.32-150400.9.9.1">
      <FullProductName ProductID="coreutils-8.32-150400.9.9.1">coreutils-8.32-150400.9.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="crypto-policies-20230920.570ea89-150600.3.12.1">
      <FullProductName ProductID="crypto-policies-20230920.570ea89-150600.3.12.1">crypto-policies-20230920.570ea89-150600.3.12.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="curl-8.14.1-150600.4.28.1">
      <FullProductName ProductID="curl-8.14.1-150600.4.28.1">curl-8.14.1-150600.4.28.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cyrus-sasl-2.1.28-150600.7.6.2">
      <FullProductName ProductID="cyrus-sasl-2.1.28-150600.7.6.2">cyrus-sasl-2.1.28-150600.7.6.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cyrus-sasl-digestmd5-2.1.28-150600.7.6.2">
      <FullProductName ProductID="cyrus-sasl-digestmd5-2.1.28-150600.7.6.2">cyrus-sasl-digestmd5-2.1.28-150600.7.6.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cyrus-sasl-gssapi-2.1.28-150600.7.6.2">
      <FullProductName ProductID="cyrus-sasl-gssapi-2.1.28-150600.7.6.2">cyrus-sasl-gssapi-2.1.28-150600.7.6.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cyrus-sasl-plain-2.1.28-150600.7.6.2">
      <FullProductName ProductID="cyrus-sasl-plain-2.1.28-150600.7.6.2">cyrus-sasl-plain-2.1.28-150600.7.6.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cyrus-sasl-saslauthd-2.1.28-150600.7.6.2">
      <FullProductName ProductID="cyrus-sasl-saslauthd-2.1.28-150600.7.6.2">cyrus-sasl-saslauthd-2.1.28-150600.7.6.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="docker-28.3.3_ce-150000.230.1">
      <FullProductName ProductID="docker-28.3.3_ce-150000.230.1">docker-28.3.3_ce-150000.230.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="dracut-059+suse.564.g984c275a-150700.3.3.1">
      <FullProductName ProductID="dracut-059+suse.564.g984c275a-150700.3.3.1">dracut-059+suse.564.g984c275a-150700.3.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glib2-tools-2.78.6-150600.4.16.1">
      <FullProductName ProductID="glib2-tools-2.78.6-150600.4.16.1">glib2-tools-2.78.6-150600.4.16.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-2.38-150600.14.37.1">
      <FullProductName ProductID="glibc-2.38-150600.14.37.1">glibc-2.38-150600.14.37.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-32bit-2.38-150600.14.37.1">
      <FullProductName ProductID="glibc-32bit-2.38-150600.14.37.1">glibc-32bit-2.38-150600.14.37.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-devel-2.38-150600.14.37.1">
      <FullProductName ProductID="glibc-devel-2.38-150600.14.37.1">glibc-devel-2.38-150600.14.37.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-i18ndata-2.38-150600.14.37.1">
      <FullProductName ProductID="glibc-i18ndata-2.38-150600.14.37.1">glibc-i18ndata-2.38-150600.14.37.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-locale-2.38-150600.14.37.1">
      <FullProductName ProductID="glibc-locale-2.38-150600.14.37.1">glibc-locale-2.38-150600.14.37.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-locale-base-2.38-150600.14.37.1">
      <FullProductName ProductID="glibc-locale-base-2.38-150600.14.37.1">glibc-locale-base-2.38-150600.14.37.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="google-dracut-config-0.0.4-150300.7.12.1">
      <FullProductName ProductID="google-dracut-config-0.0.4-150300.7.12.1">google-dracut-config-0.0.4-150300.7.12.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="google-guest-configs-20241205.00-150400.13.22.1">
      <FullProductName ProductID="google-guest-configs-20241205.00-150400.13.22.1">google-guest-configs-20241205.00-150400.13.22.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="google-guest-oslogin-20240311.01-150000.1.56.1">
      <FullProductName ProductID="google-guest-oslogin-20240311.01-150000.1.56.1">google-guest-oslogin-20240311.01-150000.1.56.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="google-osconfig-agent-20250416.02-150000.1.50.1">
      <FullProductName ProductID="google-osconfig-agent-20250416.02-150000.1.50.1">google-osconfig-agent-20250416.02-150000.1.50.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="gpg2-2.4.4-150600.3.9.1">
      <FullProductName ProductID="gpg2-2.4.4-150600.3.9.1">gpg2-2.4.4-150600.3.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="grub2-2.12-150700.19.13.2">
      <FullProductName ProductID="grub2-2.12-150700.19.13.2">grub2-2.12-150700.19.13.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="grub2-i386-pc-2.12-150700.19.13.2">
      <FullProductName ProductID="grub2-i386-pc-2.12-150700.19.13.2">grub2-i386-pc-2.12-150700.19.13.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="grub2-x86_64-efi-2.12-150700.19.13.2">
      <FullProductName ProductID="grub2-x86_64-efi-2.12-150700.19.13.2">grub2-x86_64-efi-2.12-150700.19.13.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="hwinfo-21.89-150500.3.12.1">
      <FullProductName ProductID="hwinfo-21.89-150500.3.12.1">hwinfo-21.89-150500.3.12.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="iputils-20221126-150500.3.14.1">
      <FullProductName ProductID="iputils-20221126-150500.3.14.1">iputils-20221126-150500.3.14.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="jq-1.6-150000.3.9.1">
      <FullProductName ProductID="jq-1.6-150000.3.9.1">jq-1.6-150000.3.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="kbd-2.4.0-150700.15.6.1">
      <FullProductName ProductID="kbd-2.4.0-150700.15.6.1">kbd-2.4.0-150700.15.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="kdump-2.0.18+git2.g881ca8c-150700.3.3.2">
      <FullProductName ProductID="kdump-2.0.18+git2.g881ca8c-150700.3.3.2">kdump-2.0.18+git2.g881ca8c-150700.3.3.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="kernel-default-6.4.0-150700.53.11.1">
      <FullProductName ProductID="kernel-default-6.4.0-150700.53.11.1">kernel-default-6.4.0-150700.53.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libatomic1-14.3.0+git11799-150000.1.11.1">
      <FullProductName ProductID="libatomic1-14.3.0+git11799-150000.1.11.1">libatomic1-14.3.0+git11799-150000.1.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libboost_regex1_66_0-1.66.0-150200.12.7.1">
      <FullProductName ProductID="libboost_regex1_66_0-1.66.0-150200.12.7.1">libboost_regex1_66_0-1.66.0-150200.12.7.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libboost_system1_66_0-1.66.0-150200.12.7.1">
      <FullProductName ProductID="libboost_system1_66_0-1.66.0-150200.12.7.1">libboost_system1_66_0-1.66.0-150200.12.7.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libboost_thread1_66_0-1.66.0-150200.12.7.1">
      <FullProductName ProductID="libboost_thread1_66_0-1.66.0-150200.12.7.1">libboost_thread1_66_0-1.66.0-150200.12.7.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libbrotlicommon1-1.0.7-150200.3.5.1">
      <FullProductName ProductID="libbrotlicommon1-1.0.7-150200.3.5.1">libbrotlicommon1-1.0.7-150200.3.5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libbrotlidec1-1.0.7-150200.3.5.1">
      <FullProductName ProductID="libbrotlidec1-1.0.7-150200.3.5.1">libbrotlidec1-1.0.7-150200.3.5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libcurl4-8.14.1-150600.4.28.1">
      <FullProductName ProductID="libcurl4-8.14.1-150600.4.28.1">libcurl4-8.14.1-150600.4.28.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libexpat1-2.7.1-150700.3.3.1">
      <FullProductName ProductID="libexpat1-2.7.1-150700.3.3.1">libexpat1-2.7.1-150700.3.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgcc_s1-14.3.0+git11799-150000.1.11.1">
      <FullProductName ProductID="libgcc_s1-14.3.0+git11799-150000.1.11.1">libgcc_s1-14.3.0+git11799-150000.1.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgcrypt20-1.11.0-150700.5.7.1">
      <FullProductName ProductID="libgcrypt20-1.11.0-150700.5.7.1">libgcrypt20-1.11.0-150700.5.7.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgfortran5-14.3.0+git11799-150000.1.11.1">
      <FullProductName ProductID="libgfortran5-14.3.0+git11799-150000.1.11.1">libgfortran5-14.3.0+git11799-150000.1.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgio-2_0-0-2.78.6-150600.4.16.1">
      <FullProductName ProductID="libgio-2_0-0-2.78.6-150600.4.16.1">libgio-2_0-0-2.78.6-150600.4.16.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libglib-2_0-0-2.78.6-150600.4.16.1">
      <FullProductName ProductID="libglib-2_0-0-2.78.6-150600.4.16.1">libglib-2_0-0-2.78.6-150600.4.16.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgmodule-2_0-0-2.78.6-150600.4.16.1">
      <FullProductName ProductID="libgmodule-2_0-0-2.78.6-150600.4.16.1">libgmodule-2_0-0-2.78.6-150600.4.16.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgnutls30-3.8.3-150600.4.9.1">
      <FullProductName ProductID="libgnutls30-3.8.3-150600.4.9.1">libgnutls30-3.8.3-150600.4.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgobject-2_0-0-2.78.6-150600.4.16.1">
      <FullProductName ProductID="libgobject-2_0-0-2.78.6-150600.4.16.1">libgobject-2_0-0-2.78.6-150600.4.16.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgomp1-14.3.0+git11799-150000.1.11.1">
      <FullProductName ProductID="libgomp1-14.3.0+git11799-150000.1.11.1">libgomp1-14.3.0+git11799-150000.1.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libicu-suse65_1-65.1-150200.4.15.1">
      <FullProductName ProductID="libicu-suse65_1-65.1-150200.4.15.1">libicu-suse65_1-65.1-150200.4.15.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libicu65_1-ledata-65.1-150200.4.15.1">
      <FullProductName ProductID="libicu65_1-ledata-65.1-150200.4.15.1">libicu65_1-ledata-65.1-150200.4.15.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libitm1-14.3.0+git11799-150000.1.11.1">
      <FullProductName ProductID="libitm1-14.3.0+git11799-150000.1.11.1">libitm1-14.3.0+git11799-150000.1.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libjq1-1.6-150000.3.9.1">
      <FullProductName ProductID="libjq1-1.6-150000.3.9.1">libjq1-1.6-150000.3.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libldb2-4.21.6+git.493.f39e13aba14-150700.3.6.1">
      <FullProductName ProductID="libldb2-4.21.6+git.493.f39e13aba14-150700.3.6.1">libldb2-4.21.6+git.493.f39e13aba14-150700.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="liblsan0-14.3.0+git11799-150000.1.11.1">
      <FullProductName ProductID="liblsan0-14.3.0+git11799-150000.1.11.1">liblsan0-14.3.0+git11799-150000.1.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libnfsidmap1-1.0-150600.28.12.1">
      <FullProductName ProductID="libnfsidmap1-1.0-150600.28.12.1">libnfsidmap1-1.0-150600.28.12.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libnvme-mi1-1.11+8.gfb9b581c-150700.4.9.1">
      <FullProductName ProductID="libnvme-mi1-1.11+8.gfb9b581c-150700.4.9.1">libnvme-mi1-1.11+8.gfb9b581c-150700.4.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libnvme1-1.11+8.gfb9b581c-150700.4.9.1">
      <FullProductName ProductID="libnvme1-1.11+8.gfb9b581c-150700.4.9.1">libnvme1-1.11+8.gfb9b581c-150700.4.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libopenssl1_1-1.1.1w-150700.11.3.1">
      <FullProductName ProductID="libopenssl1_1-1.1.1w-150700.11.3.1">libopenssl1_1-1.1.1w-150700.11.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libopenssl3-3.2.3-150700.5.18.1">
      <FullProductName ProductID="libopenssl3-3.2.3-150700.5.18.1">libopenssl3-3.2.3-150700.5.18.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libpolkit-agent-1-0-121-150500.3.6.1">
      <FullProductName ProductID="libpolkit-agent-1-0-121-150500.3.6.1">libpolkit-agent-1-0-121-150500.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libpolkit-gobject-1-0-121-150500.3.6.1">
      <FullProductName ProductID="libpolkit-gobject-1-0-121-150500.3.6.1">libpolkit-gobject-1-0-121-150500.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libpsm2-2-12.0.1-150600.3.5.1">
      <FullProductName ProductID="libpsm2-2-12.0.1-150600.3.5.1">libpsm2-2-12.0.1-150600.3.5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libpsm2-devel-12.0.1-150600.3.5.1">
      <FullProductName ProductID="libpsm2-devel-12.0.1-150600.3.5.1">libpsm2-devel-12.0.1-150600.3.5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libpython3_11-1_0-3.11.13-150600.3.35.1">
      <FullProductName ProductID="libpython3_11-1_0-3.11.13-150600.3.35.1">libpython3_11-1_0-3.11.13-150600.3.35.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libpython3_6m1_0-3.6.15-150300.10.97.1">
      <FullProductName ProductID="libpython3_6m1_0-3.6.15-150300.10.97.1">libpython3_6m1_0-3.6.15-150300.10.97.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libquadmath0-14.3.0+git11799-150000.1.11.1">
      <FullProductName ProductID="libquadmath0-14.3.0+git11799-150000.1.11.1">libquadmath0-14.3.0+git11799-150000.1.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsasl2-3-2.1.28-150600.7.6.2">
      <FullProductName ProductID="libsasl2-3-2.1.28-150600.7.6.2">libsasl2-3-2.1.28-150600.7.6.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsolv-tools-base-0.7.34-150600.8.17.2">
      <FullProductName ProductID="libsolv-tools-base-0.7.34-150600.8.17.2">libsolv-tools-base-0.7.34-150600.8.17.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsqlite3-0-3.50.2-150000.3.33.1">
      <FullProductName ProductID="libsqlite3-0-3.50.2-150000.3.33.1">libsqlite3-0-3.50.2-150000.3.33.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libssh-config-0.9.8-150600.11.3.1">
      <FullProductName ProductID="libssh-config-0.9.8-150600.11.3.1">libssh-config-0.9.8-150600.11.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libssh4-0.9.8-150600.11.3.1">
      <FullProductName ProductID="libssh4-0.9.8-150600.11.3.1">libssh4-0.9.8-150600.11.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libstdc++6-14.3.0+git11799-150000.1.11.1">
      <FullProductName ProductID="libstdc++6-14.3.0+git11799-150000.1.11.1">libstdc++6-14.3.0+git11799-150000.1.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsystemd0-254.27-150600.4.43.3">
      <FullProductName ProductID="libsystemd0-254.27-150600.4.43.3">libsystemd0-254.27-150600.4.43.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libubsan1-14.3.0+git11799-150000.1.11.1">
      <FullProductName ProductID="libubsan1-14.3.0+git11799-150000.1.11.1">libubsan1-14.3.0+git11799-150000.1.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libudev1-254.27-150600.4.43.3">
      <FullProductName ProductID="libudev1-254.27-150600.4.43.3">libudev1-254.27-150600.4.43.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libxml2-2-2.12.10-150700.4.6.1">
      <FullProductName ProductID="libxml2-2-2.12.10-150700.4.6.1">libxml2-2-2.12.10-150700.4.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libyaml-0-2-0.1.7-150000.3.4.1">
      <FullProductName ProductID="libyaml-0-2-0.1.7-150000.3.4.1">libyaml-0-2-0.1.7-150000.3.4.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libzypp-17.37.16-150600.3.79.1">
      <FullProductName ProductID="libzypp-17.37.16-150600.3.79.1">libzypp-17.37.16-150600.3.79.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="mdadm-4.4-150700.4.5.3">
      <FullProductName ProductID="mdadm-4.4-150700.4.5.3">mdadm-4.4-150700.4.5.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="mozilla-nspr-4.36-150000.3.32.1">
      <FullProductName ProductID="mozilla-nspr-4.36-150000.3.32.1">mozilla-nspr-4.36-150000.3.32.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="mozilla-nss-certs-3.112-150400.3.57.1">
      <FullProductName ProductID="mozilla-nss-certs-3.112-150400.3.57.1">mozilla-nss-certs-3.112-150400.3.57.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="nfs-client-2.6.4-150600.28.12.1">
      <FullProductName ProductID="nfs-client-2.6.4-150600.28.12.1">nfs-client-2.6.4-150600.28.12.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="nfs-kernel-server-2.6.4-150600.28.12.1">
      <FullProductName ProductID="nfs-kernel-server-2.6.4-150600.28.12.1">nfs-kernel-server-2.6.4-150600.28.12.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="nscd-2.38-150600.14.37.1">
      <FullProductName ProductID="nscd-2.38-150600.14.37.1">nscd-2.38-150600.14.37.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="nvme-cli-2.11+28.g2fc67685-150700.3.9.1">
      <FullProductName ProductID="nvme-cli-2.11+28.g2fc67685-150700.3.9.1">nvme-cli-2.11+28.g2fc67685-150700.3.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssh-9.6p1-150600.6.29.2">
      <FullProductName ProductID="openssh-9.6p1-150600.6.29.2">openssh-9.6p1-150600.6.29.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssh-clients-9.6p1-150600.6.29.2">
      <FullProductName ProductID="openssh-clients-9.6p1-150600.6.29.2">openssh-clients-9.6p1-150600.6.29.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssh-common-9.6p1-150600.6.29.2">
      <FullProductName ProductID="openssh-common-9.6p1-150600.6.29.2">openssh-common-9.6p1-150600.6.29.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssh-server-9.6p1-150600.6.29.2">
      <FullProductName ProductID="openssh-server-9.6p1-150600.6.29.2">openssh-server-9.6p1-150600.6.29.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssh-server-config-disallow-rootlogin-9.6p1-150600.6.29.2">
      <FullProductName ProductID="openssh-server-config-disallow-rootlogin-9.6p1-150600.6.29.2">openssh-server-config-disallow-rootlogin-9.6p1-150600.6.29.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssl-3-3.2.3-150700.5.18.1">
      <FullProductName ProductID="openssl-3-3.2.3-150700.5.18.1">openssl-3-3.2.3-150700.5.18.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="pam-1.3.0-150000.6.86.1">
      <FullProductName ProductID="pam-1.3.0-150000.6.86.1">pam-1.3.0-150000.6.86.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="pam-config-1.1-150600.16.8.1">
      <FullProductName ProductID="pam-config-1.1-150600.16.8.1">pam-config-1.1-150600.16.8.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="perl-5.26.1-150300.17.20.1">
      <FullProductName ProductID="perl-5.26.1-150300.17.20.1">perl-5.26.1-150300.17.20.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="perl-Bootloader-1.25-150700.3.3.1">
      <FullProductName ProductID="perl-Bootloader-1.25-150700.3.3.1">perl-Bootloader-1.25-150700.3.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="perl-base-5.26.1-150300.17.20.1">
      <FullProductName ProductID="perl-base-5.26.1-150300.17.20.1">perl-base-5.26.1-150300.17.20.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="polkit-121-150500.3.6.1">
      <FullProductName ProductID="polkit-121-150500.3.6.1">polkit-121-150500.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python-instance-billing-flavor-check-1.0.1-150000.1.23.1">
      <FullProductName ProductID="python-instance-billing-flavor-check-1.0.1-150000.1.23.1">python-instance-billing-flavor-check-1.0.1-150000.1.23.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-3.6.15-150300.10.97.2">
      <FullProductName ProductID="python3-3.6.15-150300.10.97.2">python3-3.6.15-150300.10.97.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-PyYAML-5.4.1-150300.3.6.1">
      <FullProductName ProductID="python3-PyYAML-5.4.1-150300.3.6.1">python3-PyYAML-5.4.1-150300.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-appdirs-1.4.3-150000.3.3.1">
      <FullProductName ProductID="python3-appdirs-1.4.3-150000.3.3.1">python3-appdirs-1.4.3-150000.3.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-asn1crypto-0.24.0-150000.3.5.1">
      <FullProductName ProductID="python3-asn1crypto-0.24.0-150000.3.5.1">python3-asn1crypto-0.24.0-150000.3.5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-base-3.6.15-150300.10.97.1">
      <FullProductName ProductID="python3-base-3.6.15-150300.10.97.1">python3-base-3.6.15-150300.10.97.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-certifi-2018.1.18-150000.3.6.1">
      <FullProductName ProductID="python3-certifi-2018.1.18-150000.3.6.1">python3-certifi-2018.1.18-150000.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-cffi-1.13.2-150200.3.5.1">
      <FullProductName ProductID="python3-cffi-1.13.2-150200.3.5.1">python3-cffi-1.13.2-150200.3.5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-chardet-3.0.4-150000.5.6.1">
      <FullProductName ProductID="python3-chardet-3.0.4-150000.5.6.1">python3-chardet-3.0.4-150000.5.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-cryptography-3.3.2-150400.26.1">
      <FullProductName ProductID="python3-cryptography-3.3.2-150400.26.1">python3-cryptography-3.3.2-150400.26.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-curses-3.6.15-150300.10.97.2">
      <FullProductName ProductID="python3-curses-3.6.15-150300.10.97.2">python3-curses-3.6.15-150300.10.97.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-decorator-4.4.2-150200.7.6.1">
      <FullProductName ProductID="python3-decorator-4.4.2-150200.7.6.1">python3-decorator-4.4.2-150200.7.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-idna-2.6-150000.3.6.1">
      <FullProductName ProductID="python3-idna-2.6-150000.3.6.1">python3-idna-2.6-150000.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-iniconfig-1.1.1-150000.1.13.1">
      <FullProductName ProductID="python3-iniconfig-1.1.1-150000.1.13.1">python3-iniconfig-1.1.1-150000.1.13.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-packaging-21.3-150200.3.6.1">
      <FullProductName ProductID="python3-packaging-21.3-150200.3.6.1">python3-packaging-21.3-150200.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-py-1.10.0-150100.5.15.1">
      <FullProductName ProductID="python3-py-1.10.0-150100.5.15.1">python3-py-1.10.0-150100.5.15.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-pyOpenSSL-21.0.0-150400.10.1">
      <FullProductName ProductID="python3-pyOpenSSL-21.0.0-150400.10.1">python3-pyOpenSSL-21.0.0-150400.10.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-pyasn1-0.4.2-150000.3.8.1">
      <FullProductName ProductID="python3-pyasn1-0.4.2-150000.3.8.1">python3-pyasn1-0.4.2-150000.3.8.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-pycparser-2.17-150000.3.5.1">
      <FullProductName ProductID="python3-pycparser-2.17-150000.3.5.1">python3-pycparser-2.17-150000.3.5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-pyparsing-2.4.7-150300.3.3.1">
      <FullProductName ProductID="python3-pyparsing-2.4.7-150300.3.3.1">python3-pyparsing-2.4.7-150300.3.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-requests-2.25.1-150300.3.18.1">
      <FullProductName ProductID="python3-requests-2.25.1-150300.3.18.1">python3-requests-2.25.1-150300.3.18.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-setuptools-44.1.1-150400.9.15.1">
      <FullProductName ProductID="python3-setuptools-44.1.1-150400.9.15.1">python3-setuptools-44.1.1-150400.9.15.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-six-1.14.0-150200.15.1">
      <FullProductName ProductID="python3-six-1.14.0-150200.15.1">python3-six-1.14.0-150200.15.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-solv-0.7.34-150600.8.17.2">
      <FullProductName ProductID="python3-solv-0.7.34-150600.8.17.2">python3-solv-0.7.34-150600.8.17.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-urllib3-1.25.10-150300.4.18.1">
      <FullProductName ProductID="python3-urllib3-1.25.10-150300.4.18.1">python3-urllib3-1.25.10-150300.4.18.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-zypp-plugin-0.6.5-150600.18.8.1">
      <FullProductName ProductID="python3-zypp-plugin-0.6.5-150600.18.8.1">python3-zypp-plugin-0.6.5-150600.18.8.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python311-3.11.13-150600.3.35.2">
      <FullProductName ProductID="python311-3.11.13-150600.3.35.2">python311-3.11.13-150600.3.35.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python311-PyYAML-6.0.2-150600.10.3.1">
      <FullProductName ProductID="python311-PyYAML-6.0.2-150600.10.3.1">python311-PyYAML-6.0.2-150600.10.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python311-base-3.11.13-150600.3.35.1">
      <FullProductName ProductID="python311-base-3.11.13-150600.3.35.1">python311-base-3.11.13-150600.3.35.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python311-contextvars-2.4-150400.10.5.1">
      <FullProductName ProductID="python311-contextvars-2.4-150400.10.5.1">python311-contextvars-2.4-150400.10.5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python311-immutables-0.19-150400.10.5.1">
      <FullProductName ProductID="python311-immutables-0.19-150400.10.5.1">python311-immutables-0.19-150400.10.5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python311-looseversion-1.3.0-150400.10.6.1">
      <FullProductName ProductID="python311-looseversion-1.3.0-150400.10.6.1">python311-looseversion-1.3.0-150400.10.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python311-psutil-5.9.5-150400.6.11.1">
      <FullProductName ProductID="python311-psutil-5.9.5-150400.6.11.1">python311-psutil-5.9.5-150400.6.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python311-pyzmq-25.1.2-150400.12.6.1">
      <FullProductName ProductID="python311-pyzmq-25.1.2-150400.12.6.1">python311-pyzmq-25.1.2-150400.12.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python311-requests-2.31.0-150400.6.18.1">
      <FullProductName ProductID="python311-requests-2.31.0-150400.6.18.1">python311-requests-2.31.0-150400.6.18.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python311-salt-3006.0-150700.14.5.2">
      <FullProductName ProductID="python311-salt-3006.0-150700.14.5.2">python311-salt-3006.0-150700.14.5.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python311-urllib3-2.0.7-150400.7.21.1">
      <FullProductName ProductID="python311-urllib3-2.0.7-150400.7.21.1">python311-urllib3-2.0.7-150400.7.21.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python311-zypp-plugin-0.6.5-150600.18.8.1">
      <FullProductName ProductID="python311-zypp-plugin-0.6.5-150600.18.8.1">python311-zypp-plugin-0.6.5-150600.18.8.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="regionServiceClientConfigGCE-5.0.0-150000.4.18.1">
      <FullProductName ProductID="regionServiceClientConfigGCE-5.0.0-150000.4.18.1">regionServiceClientConfigGCE-5.0.0-150000.4.18.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ruby-solv-0.7.34-150600.8.17.2">
      <FullProductName ProductID="ruby-solv-0.7.34-150600.8.17.2">ruby-solv-0.7.34-150600.8.17.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ruby2.5-rubygem-gem2rpm-0.10.1-150700.22.7.1">
      <FullProductName ProductID="ruby2.5-rubygem-gem2rpm-0.10.1-150700.22.7.1">ruby2.5-rubygem-gem2rpm-0.10.1-150700.22.7.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="runc-1.2.6-150000.73.2">
      <FullProductName ProductID="runc-1.2.6-150000.73.2">runc-1.2.6-150000.73.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="salt-3006.0-150700.14.5.2">
      <FullProductName ProductID="salt-3006.0-150700.14.5.2">salt-3006.0-150700.14.5.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="salt-minion-3006.0-150700.14.5.2">
      <FullProductName ProductID="salt-minion-3006.0-150700.14.5.2">salt-minion-3006.0-150700.14.5.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="samba-client-libs-4.21.6+git.493.f39e13aba14-150700.3.6.1">
      <FullProductName ProductID="samba-client-libs-4.21.6+git.493.f39e13aba14-150700.3.6.1">samba-client-libs-4.21.6+git.493.f39e13aba14-150700.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="sqlite3-tcl-3.50.2-150000.3.33.1">
      <FullProductName ProductID="sqlite3-tcl-3.50.2-150000.3.33.1">sqlite3-tcl-3.50.2-150000.3.33.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="sudo-1.9.15p5-150600.3.9.1">
      <FullProductName ProductID="sudo-1.9.15p5-150600.3.9.1">sudo-1.9.15p5-150600.3.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="suse-build-key-12.0-150000.8.61.2">
      <FullProductName ProductID="suse-build-key-12.0-150000.8.61.2">suse-build-key-12.0-150000.8.61.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="suse-module-tools-15.7.6-150700.3.3.3">
      <FullProductName ProductID="suse-module-tools-15.7.6-150700.3.3.3">suse-module-tools-15.7.6-150700.3.3.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="systemd-254.27-150600.4.43.3">
      <FullProductName ProductID="systemd-254.27-150600.4.43.3">systemd-254.27-150600.4.43.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="systemd-presets-branding-SLE-15.1-150600.35.3.1">
      <FullProductName ProductID="systemd-presets-branding-SLE-15.1-150600.35.3.1">systemd-presets-branding-SLE-15.1-150600.35.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="systemd-rpm-macros-16-150000.7.42.1">
      <FullProductName ProductID="systemd-rpm-macros-16-150000.7.42.1">systemd-rpm-macros-16-150000.7.42.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="systemd-sysvcompat-254.27-150600.4.43.3">
      <FullProductName ProductID="systemd-sysvcompat-254.27-150600.4.43.3">systemd-sysvcompat-254.27-150600.4.43.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="udev-254.27-150600.4.43.3">
      <FullProductName ProductID="udev-254.27-150600.4.43.3">udev-254.27-150600.4.43.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="update-alternatives-1.19.0.4-150000.4.7.1">
      <FullProductName ProductID="update-alternatives-1.19.0.4-150000.4.7.1">update-alternatives-1.19.0.4-150000.4.7.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="vim-9.1.1406-150500.20.27.1">
      <FullProductName ProductID="vim-9.1.1406-150500.20.27.1">vim-9.1.1406-150500.20.27.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="vim-data-common-9.1.1406-150500.20.27.1">
      <FullProductName ProductID="vim-data-common-9.1.1406-150500.20.27.1">vim-data-common-9.1.1406-150500.20.27.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="xen-libs-4.20.1_04-150700.3.11.1">
      <FullProductName ProductID="xen-libs-4.20.1_04-150700.3.11.1">xen-libs-4.20.1_04-150700.3.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="yast2-4.7.1-150700.3.3.1">
      <FullProductName ProductID="yast2-4.7.1-150700.3.3.1">yast2-4.7.1-150700.3.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="yast2-iscsi-client-4.7.7-150700.3.8.1">
      <FullProductName ProductID="yast2-iscsi-client-4.7.7-150700.3.8.1">yast2-iscsi-client-4.7.7-150700.3.8.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="yast2-logs-4.7.1-150700.3.3.1">
      <FullProductName ProductID="yast2-logs-4.7.1-150700.3.3.1">yast2-logs-4.7.1-150700.3.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="yast2-packager-4.7.1-150700.3.5.1">
      <FullProductName ProductID="yast2-packager-4.7.1-150700.3.5.1">yast2-packager-4.7.1-150700.3.5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="yast2-users-4.7.1-150700.3.5.1">
      <FullProductName ProductID="yast2-users-4.7.1-150700.3.5.1">yast2-users-4.7.1-150700.3.5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="zsh-5.8.1-150600.18.3.2">
      <FullProductName ProductID="zsh-5.8.1-150600.18.3.2">zsh-5.8.1-150600.18.3.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="zypper-1.14.93-150600.10.49.2">
      <FullProductName ProductID="zypper-1.14.93-150600.10.49.2">zypper-1.14.93-150600.10.49.2</FullProductName>
    </Branch>
    <Relationship ProductReference="bind-utils-9.20.11-150700.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:bind-utils-9.20.11-150700.3.6.1">bind-utils-9.20.11-150700.3.6.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="boost-license1_66_0-1.66.0-150200.12.7.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:boost-license1_66_0-1.66.0-150200.12.7.1">boost-license1_66_0-1.66.0-150200.12.7.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cifs-utils-6.15-150400.3.15.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:cifs-utils-6.15-150400.3.15.1">cifs-utils-6.15-150400.3.15.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cloud-regionsrv-client-10.5.2-150300.13.29.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:cloud-regionsrv-client-10.5.2-150300.13.29.1">cloud-regionsrv-client-10.5.2-150300.13.29.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cloud-regionsrv-client-license-watcher-1.0.0-150300.13.29.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:cloud-regionsrv-client-license-watcher-1.0.0-150300.13.29.1">cloud-regionsrv-client-license-watcher-1.0.0-150300.13.29.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cloud-regionsrv-client-plugin-gce-1.0.0-150300.13.29.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:cloud-regionsrv-client-plugin-gce-1.0.0-150300.13.29.1">cloud-regionsrv-client-plugin-gce-1.0.0-150300.13.29.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="coreutils-8.32-150400.9.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:coreutils-8.32-150400.9.9.1">coreutils-8.32-150400.9.9.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="crypto-policies-20230920.570ea89-150600.3.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:crypto-policies-20230920.570ea89-150600.3.12.1">crypto-policies-20230920.570ea89-150600.3.12.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="curl-8.14.1-150600.4.28.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:curl-8.14.1-150600.4.28.1">curl-8.14.1-150600.4.28.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cyrus-sasl-2.1.28-150600.7.6.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:cyrus-sasl-2.1.28-150600.7.6.2">cyrus-sasl-2.1.28-150600.7.6.2 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cyrus-sasl-digestmd5-2.1.28-150600.7.6.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:cyrus-sasl-digestmd5-2.1.28-150600.7.6.2">cyrus-sasl-digestmd5-2.1.28-150600.7.6.2 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cyrus-sasl-gssapi-2.1.28-150600.7.6.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:cyrus-sasl-gssapi-2.1.28-150600.7.6.2">cyrus-sasl-gssapi-2.1.28-150600.7.6.2 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cyrus-sasl-plain-2.1.28-150600.7.6.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:cyrus-sasl-plain-2.1.28-150600.7.6.2">cyrus-sasl-plain-2.1.28-150600.7.6.2 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cyrus-sasl-saslauthd-2.1.28-150600.7.6.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:cyrus-sasl-saslauthd-2.1.28-150600.7.6.2">cyrus-sasl-saslauthd-2.1.28-150600.7.6.2 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="docker-28.3.3_ce-150000.230.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:docker-28.3.3_ce-150000.230.1">docker-28.3.3_ce-150000.230.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="dracut-059+suse.564.g984c275a-150700.3.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:dracut-059+suse.564.g984c275a-150700.3.3.1">dracut-059+suse.564.g984c275a-150700.3.3.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glib2-tools-2.78.6-150600.4.16.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:glib2-tools-2.78.6-150600.4.16.1">glib2-tools-2.78.6-150600.4.16.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-2.38-150600.14.37.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:glibc-2.38-150600.14.37.1">glibc-2.38-150600.14.37.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-32bit-2.38-150600.14.37.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:glibc-32bit-2.38-150600.14.37.1">glibc-32bit-2.38-150600.14.37.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-devel-2.38-150600.14.37.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:glibc-devel-2.38-150600.14.37.1">glibc-devel-2.38-150600.14.37.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-i18ndata-2.38-150600.14.37.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:glibc-i18ndata-2.38-150600.14.37.1">glibc-i18ndata-2.38-150600.14.37.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-locale-2.38-150600.14.37.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:glibc-locale-2.38-150600.14.37.1">glibc-locale-2.38-150600.14.37.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-locale-base-2.38-150600.14.37.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:glibc-locale-base-2.38-150600.14.37.1">glibc-locale-base-2.38-150600.14.37.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="google-dracut-config-0.0.4-150300.7.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:google-dracut-config-0.0.4-150300.7.12.1">google-dracut-config-0.0.4-150300.7.12.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="google-guest-configs-20241205.00-150400.13.22.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:google-guest-configs-20241205.00-150400.13.22.1">google-guest-configs-20241205.00-150400.13.22.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="google-guest-oslogin-20240311.01-150000.1.56.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:google-guest-oslogin-20240311.01-150000.1.56.1">google-guest-oslogin-20240311.01-150000.1.56.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="google-osconfig-agent-20250416.02-150000.1.50.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:google-osconfig-agent-20250416.02-150000.1.50.1">google-osconfig-agent-20250416.02-150000.1.50.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="gpg2-2.4.4-150600.3.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:gpg2-2.4.4-150600.3.9.1">gpg2-2.4.4-150600.3.9.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="grub2-2.12-150700.19.13.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:grub2-2.12-150700.19.13.2">grub2-2.12-150700.19.13.2 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="grub2-i386-pc-2.12-150700.19.13.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:grub2-i386-pc-2.12-150700.19.13.2">grub2-i386-pc-2.12-150700.19.13.2 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="grub2-x86_64-efi-2.12-150700.19.13.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:grub2-x86_64-efi-2.12-150700.19.13.2">grub2-x86_64-efi-2.12-150700.19.13.2 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="hwinfo-21.89-150500.3.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:hwinfo-21.89-150500.3.12.1">hwinfo-21.89-150500.3.12.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="iputils-20221126-150500.3.14.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:iputils-20221126-150500.3.14.1">iputils-20221126-150500.3.14.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="jq-1.6-150000.3.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:jq-1.6-150000.3.9.1">jq-1.6-150000.3.9.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="kbd-2.4.0-150700.15.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:kbd-2.4.0-150700.15.6.1">kbd-2.4.0-150700.15.6.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="kdump-2.0.18+git2.g881ca8c-150700.3.3.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:kdump-2.0.18+git2.g881ca8c-150700.3.3.2">kdump-2.0.18+git2.g881ca8c-150700.3.3.2 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="kernel-default-6.4.0-150700.53.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:kernel-default-6.4.0-150700.53.11.1">kernel-default-6.4.0-150700.53.11.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libatomic1-14.3.0+git11799-150000.1.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libatomic1-14.3.0+git11799-150000.1.11.1">libatomic1-14.3.0+git11799-150000.1.11.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libboost_regex1_66_0-1.66.0-150200.12.7.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libboost_regex1_66_0-1.66.0-150200.12.7.1">libboost_regex1_66_0-1.66.0-150200.12.7.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libboost_system1_66_0-1.66.0-150200.12.7.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libboost_system1_66_0-1.66.0-150200.12.7.1">libboost_system1_66_0-1.66.0-150200.12.7.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libboost_thread1_66_0-1.66.0-150200.12.7.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libboost_thread1_66_0-1.66.0-150200.12.7.1">libboost_thread1_66_0-1.66.0-150200.12.7.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libbrotlicommon1-1.0.7-150200.3.5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libbrotlicommon1-1.0.7-150200.3.5.1">libbrotlicommon1-1.0.7-150200.3.5.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libbrotlidec1-1.0.7-150200.3.5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libbrotlidec1-1.0.7-150200.3.5.1">libbrotlidec1-1.0.7-150200.3.5.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libcurl4-8.14.1-150600.4.28.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libcurl4-8.14.1-150600.4.28.1">libcurl4-8.14.1-150600.4.28.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libexpat1-2.7.1-150700.3.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libexpat1-2.7.1-150700.3.3.1">libexpat1-2.7.1-150700.3.3.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgcc_s1-14.3.0+git11799-150000.1.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libgcc_s1-14.3.0+git11799-150000.1.11.1">libgcc_s1-14.3.0+git11799-150000.1.11.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgcrypt20-1.11.0-150700.5.7.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libgcrypt20-1.11.0-150700.5.7.1">libgcrypt20-1.11.0-150700.5.7.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgfortran5-14.3.0+git11799-150000.1.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libgfortran5-14.3.0+git11799-150000.1.11.1">libgfortran5-14.3.0+git11799-150000.1.11.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgio-2_0-0-2.78.6-150600.4.16.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libgio-2_0-0-2.78.6-150600.4.16.1">libgio-2_0-0-2.78.6-150600.4.16.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libglib-2_0-0-2.78.6-150600.4.16.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libglib-2_0-0-2.78.6-150600.4.16.1">libglib-2_0-0-2.78.6-150600.4.16.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgmodule-2_0-0-2.78.6-150600.4.16.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libgmodule-2_0-0-2.78.6-150600.4.16.1">libgmodule-2_0-0-2.78.6-150600.4.16.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgnutls30-3.8.3-150600.4.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libgnutls30-3.8.3-150600.4.9.1">libgnutls30-3.8.3-150600.4.9.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgobject-2_0-0-2.78.6-150600.4.16.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libgobject-2_0-0-2.78.6-150600.4.16.1">libgobject-2_0-0-2.78.6-150600.4.16.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgomp1-14.3.0+git11799-150000.1.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libgomp1-14.3.0+git11799-150000.1.11.1">libgomp1-14.3.0+git11799-150000.1.11.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libicu-suse65_1-65.1-150200.4.15.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libicu-suse65_1-65.1-150200.4.15.1">libicu-suse65_1-65.1-150200.4.15.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libicu65_1-ledata-65.1-150200.4.15.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libicu65_1-ledata-65.1-150200.4.15.1">libicu65_1-ledata-65.1-150200.4.15.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libitm1-14.3.0+git11799-150000.1.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libitm1-14.3.0+git11799-150000.1.11.1">libitm1-14.3.0+git11799-150000.1.11.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libjq1-1.6-150000.3.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libjq1-1.6-150000.3.9.1">libjq1-1.6-150000.3.9.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libldb2-4.21.6+git.493.f39e13aba14-150700.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libldb2-4.21.6+git.493.f39e13aba14-150700.3.6.1">libldb2-4.21.6+git.493.f39e13aba14-150700.3.6.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="liblsan0-14.3.0+git11799-150000.1.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:liblsan0-14.3.0+git11799-150000.1.11.1">liblsan0-14.3.0+git11799-150000.1.11.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libnfsidmap1-1.0-150600.28.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libnfsidmap1-1.0-150600.28.12.1">libnfsidmap1-1.0-150600.28.12.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libnvme-mi1-1.11+8.gfb9b581c-150700.4.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libnvme-mi1-1.11+8.gfb9b581c-150700.4.9.1">libnvme-mi1-1.11+8.gfb9b581c-150700.4.9.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libnvme1-1.11+8.gfb9b581c-150700.4.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libnvme1-1.11+8.gfb9b581c-150700.4.9.1">libnvme1-1.11+8.gfb9b581c-150700.4.9.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libopenssl1_1-1.1.1w-150700.11.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libopenssl1_1-1.1.1w-150700.11.3.1">libopenssl1_1-1.1.1w-150700.11.3.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libopenssl3-3.2.3-150700.5.18.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libopenssl3-3.2.3-150700.5.18.1">libopenssl3-3.2.3-150700.5.18.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libpolkit-agent-1-0-121-150500.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libpolkit-agent-1-0-121-150500.3.6.1">libpolkit-agent-1-0-121-150500.3.6.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libpolkit-gobject-1-0-121-150500.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libpolkit-gobject-1-0-121-150500.3.6.1">libpolkit-gobject-1-0-121-150500.3.6.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libpsm2-2-12.0.1-150600.3.5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libpsm2-2-12.0.1-150600.3.5.1">libpsm2-2-12.0.1-150600.3.5.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libpsm2-devel-12.0.1-150600.3.5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libpsm2-devel-12.0.1-150600.3.5.1">libpsm2-devel-12.0.1-150600.3.5.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libpython3_11-1_0-3.11.13-150600.3.35.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libpython3_11-1_0-3.11.13-150600.3.35.1">libpython3_11-1_0-3.11.13-150600.3.35.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libpython3_6m1_0-3.6.15-150300.10.97.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libpython3_6m1_0-3.6.15-150300.10.97.1">libpython3_6m1_0-3.6.15-150300.10.97.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libquadmath0-14.3.0+git11799-150000.1.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libquadmath0-14.3.0+git11799-150000.1.11.1">libquadmath0-14.3.0+git11799-150000.1.11.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsasl2-3-2.1.28-150600.7.6.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libsasl2-3-2.1.28-150600.7.6.2">libsasl2-3-2.1.28-150600.7.6.2 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsolv-tools-base-0.7.34-150600.8.17.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libsolv-tools-base-0.7.34-150600.8.17.2">libsolv-tools-base-0.7.34-150600.8.17.2 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsqlite3-0-3.50.2-150000.3.33.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libsqlite3-0-3.50.2-150000.3.33.1">libsqlite3-0-3.50.2-150000.3.33.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libssh-config-0.9.8-150600.11.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libssh-config-0.9.8-150600.11.3.1">libssh-config-0.9.8-150600.11.3.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libssh4-0.9.8-150600.11.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libssh4-0.9.8-150600.11.3.1">libssh4-0.9.8-150600.11.3.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libstdc++6-14.3.0+git11799-150000.1.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libstdc++6-14.3.0+git11799-150000.1.11.1">libstdc++6-14.3.0+git11799-150000.1.11.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsystemd0-254.27-150600.4.43.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libsystemd0-254.27-150600.4.43.3">libsystemd0-254.27-150600.4.43.3 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libubsan1-14.3.0+git11799-150000.1.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libubsan1-14.3.0+git11799-150000.1.11.1">libubsan1-14.3.0+git11799-150000.1.11.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libudev1-254.27-150600.4.43.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libudev1-254.27-150600.4.43.3">libudev1-254.27-150600.4.43.3 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libxml2-2-2.12.10-150700.4.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libxml2-2-2.12.10-150700.4.6.1">libxml2-2-2.12.10-150700.4.6.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libyaml-0-2-0.1.7-150000.3.4.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libyaml-0-2-0.1.7-150000.3.4.1">libyaml-0-2-0.1.7-150000.3.4.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libzypp-17.37.16-150600.3.79.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:libzypp-17.37.16-150600.3.79.1">libzypp-17.37.16-150600.3.79.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="mdadm-4.4-150700.4.5.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:mdadm-4.4-150700.4.5.3">mdadm-4.4-150700.4.5.3 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="mozilla-nspr-4.36-150000.3.32.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:mozilla-nspr-4.36-150000.3.32.1">mozilla-nspr-4.36-150000.3.32.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="mozilla-nss-certs-3.112-150400.3.57.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:mozilla-nss-certs-3.112-150400.3.57.1">mozilla-nss-certs-3.112-150400.3.57.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="nfs-client-2.6.4-150600.28.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:nfs-client-2.6.4-150600.28.12.1">nfs-client-2.6.4-150600.28.12.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="nfs-kernel-server-2.6.4-150600.28.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:nfs-kernel-server-2.6.4-150600.28.12.1">nfs-kernel-server-2.6.4-150600.28.12.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="nscd-2.38-150600.14.37.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:nscd-2.38-150600.14.37.1">nscd-2.38-150600.14.37.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="nvme-cli-2.11+28.g2fc67685-150700.3.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:nvme-cli-2.11+28.g2fc67685-150700.3.9.1">nvme-cli-2.11+28.g2fc67685-150700.3.9.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-9.6p1-150600.6.29.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:openssh-9.6p1-150600.6.29.2">openssh-9.6p1-150600.6.29.2 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-clients-9.6p1-150600.6.29.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:openssh-clients-9.6p1-150600.6.29.2">openssh-clients-9.6p1-150600.6.29.2 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-common-9.6p1-150600.6.29.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:openssh-common-9.6p1-150600.6.29.2">openssh-common-9.6p1-150600.6.29.2 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-server-9.6p1-150600.6.29.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:openssh-server-9.6p1-150600.6.29.2">openssh-server-9.6p1-150600.6.29.2 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-server-config-disallow-rootlogin-9.6p1-150600.6.29.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:openssh-server-config-disallow-rootlogin-9.6p1-150600.6.29.2">openssh-server-config-disallow-rootlogin-9.6p1-150600.6.29.2 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssl-3-3.2.3-150700.5.18.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:openssl-3-3.2.3-150700.5.18.1">openssl-3-3.2.3-150700.5.18.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="pam-1.3.0-150000.6.86.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:pam-1.3.0-150000.6.86.1">pam-1.3.0-150000.6.86.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="pam-config-1.1-150600.16.8.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:pam-config-1.1-150600.16.8.1">pam-config-1.1-150600.16.8.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="perl-5.26.1-150300.17.20.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:perl-5.26.1-150300.17.20.1">perl-5.26.1-150300.17.20.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="perl-Bootloader-1.25-150700.3.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:perl-Bootloader-1.25-150700.3.3.1">perl-Bootloader-1.25-150700.3.3.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="perl-base-5.26.1-150300.17.20.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:perl-base-5.26.1-150300.17.20.1">perl-base-5.26.1-150300.17.20.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="polkit-121-150500.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:polkit-121-150500.3.6.1">polkit-121-150500.3.6.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python-instance-billing-flavor-check-1.0.1-150000.1.23.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python-instance-billing-flavor-check-1.0.1-150000.1.23.1">python-instance-billing-flavor-check-1.0.1-150000.1.23.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-3.6.15-150300.10.97.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python3-3.6.15-150300.10.97.2">python3-3.6.15-150300.10.97.2 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-PyYAML-5.4.1-150300.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python3-PyYAML-5.4.1-150300.3.6.1">python3-PyYAML-5.4.1-150300.3.6.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-appdirs-1.4.3-150000.3.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python3-appdirs-1.4.3-150000.3.3.1">python3-appdirs-1.4.3-150000.3.3.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-asn1crypto-0.24.0-150000.3.5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python3-asn1crypto-0.24.0-150000.3.5.1">python3-asn1crypto-0.24.0-150000.3.5.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-base-3.6.15-150300.10.97.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python3-base-3.6.15-150300.10.97.1">python3-base-3.6.15-150300.10.97.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-certifi-2018.1.18-150000.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python3-certifi-2018.1.18-150000.3.6.1">python3-certifi-2018.1.18-150000.3.6.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-cffi-1.13.2-150200.3.5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python3-cffi-1.13.2-150200.3.5.1">python3-cffi-1.13.2-150200.3.5.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-chardet-3.0.4-150000.5.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python3-chardet-3.0.4-150000.5.6.1">python3-chardet-3.0.4-150000.5.6.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-cryptography-3.3.2-150400.26.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python3-cryptography-3.3.2-150400.26.1">python3-cryptography-3.3.2-150400.26.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-curses-3.6.15-150300.10.97.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python3-curses-3.6.15-150300.10.97.2">python3-curses-3.6.15-150300.10.97.2 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-decorator-4.4.2-150200.7.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python3-decorator-4.4.2-150200.7.6.1">python3-decorator-4.4.2-150200.7.6.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-idna-2.6-150000.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python3-idna-2.6-150000.3.6.1">python3-idna-2.6-150000.3.6.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-iniconfig-1.1.1-150000.1.13.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python3-iniconfig-1.1.1-150000.1.13.1">python3-iniconfig-1.1.1-150000.1.13.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-packaging-21.3-150200.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python3-packaging-21.3-150200.3.6.1">python3-packaging-21.3-150200.3.6.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-py-1.10.0-150100.5.15.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python3-py-1.10.0-150100.5.15.1">python3-py-1.10.0-150100.5.15.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-pyOpenSSL-21.0.0-150400.10.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python3-pyOpenSSL-21.0.0-150400.10.1">python3-pyOpenSSL-21.0.0-150400.10.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-pyasn1-0.4.2-150000.3.8.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python3-pyasn1-0.4.2-150000.3.8.1">python3-pyasn1-0.4.2-150000.3.8.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-pycparser-2.17-150000.3.5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python3-pycparser-2.17-150000.3.5.1">python3-pycparser-2.17-150000.3.5.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-pyparsing-2.4.7-150300.3.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python3-pyparsing-2.4.7-150300.3.3.1">python3-pyparsing-2.4.7-150300.3.3.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-requests-2.25.1-150300.3.18.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python3-requests-2.25.1-150300.3.18.1">python3-requests-2.25.1-150300.3.18.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-setuptools-44.1.1-150400.9.15.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python3-setuptools-44.1.1-150400.9.15.1">python3-setuptools-44.1.1-150400.9.15.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-six-1.14.0-150200.15.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python3-six-1.14.0-150200.15.1">python3-six-1.14.0-150200.15.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-solv-0.7.34-150600.8.17.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python3-solv-0.7.34-150600.8.17.2">python3-solv-0.7.34-150600.8.17.2 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-urllib3-1.25.10-150300.4.18.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python3-urllib3-1.25.10-150300.4.18.1">python3-urllib3-1.25.10-150300.4.18.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-zypp-plugin-0.6.5-150600.18.8.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python3-zypp-plugin-0.6.5-150600.18.8.1">python3-zypp-plugin-0.6.5-150600.18.8.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python311-3.11.13-150600.3.35.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python311-3.11.13-150600.3.35.2">python311-3.11.13-150600.3.35.2 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python311-PyYAML-6.0.2-150600.10.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python311-PyYAML-6.0.2-150600.10.3.1">python311-PyYAML-6.0.2-150600.10.3.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python311-base-3.11.13-150600.3.35.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python311-base-3.11.13-150600.3.35.1">python311-base-3.11.13-150600.3.35.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python311-contextvars-2.4-150400.10.5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python311-contextvars-2.4-150400.10.5.1">python311-contextvars-2.4-150400.10.5.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python311-immutables-0.19-150400.10.5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python311-immutables-0.19-150400.10.5.1">python311-immutables-0.19-150400.10.5.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python311-looseversion-1.3.0-150400.10.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python311-looseversion-1.3.0-150400.10.6.1">python311-looseversion-1.3.0-150400.10.6.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python311-psutil-5.9.5-150400.6.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python311-psutil-5.9.5-150400.6.11.1">python311-psutil-5.9.5-150400.6.11.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python311-pyzmq-25.1.2-150400.12.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python311-pyzmq-25.1.2-150400.12.6.1">python311-pyzmq-25.1.2-150400.12.6.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python311-requests-2.31.0-150400.6.18.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python311-requests-2.31.0-150400.6.18.1">python311-requests-2.31.0-150400.6.18.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python311-salt-3006.0-150700.14.5.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python311-salt-3006.0-150700.14.5.2">python311-salt-3006.0-150700.14.5.2 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python311-urllib3-2.0.7-150400.7.21.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python311-urllib3-2.0.7-150400.7.21.1">python311-urllib3-2.0.7-150400.7.21.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python311-zypp-plugin-0.6.5-150600.18.8.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:python311-zypp-plugin-0.6.5-150600.18.8.1">python311-zypp-plugin-0.6.5-150600.18.8.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="regionServiceClientConfigGCE-5.0.0-150000.4.18.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:regionServiceClientConfigGCE-5.0.0-150000.4.18.1">regionServiceClientConfigGCE-5.0.0-150000.4.18.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ruby-solv-0.7.34-150600.8.17.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:ruby-solv-0.7.34-150600.8.17.2">ruby-solv-0.7.34-150600.8.17.2 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ruby2.5-rubygem-gem2rpm-0.10.1-150700.22.7.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:ruby2.5-rubygem-gem2rpm-0.10.1-150700.22.7.1">ruby2.5-rubygem-gem2rpm-0.10.1-150700.22.7.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="runc-1.2.6-150000.73.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:runc-1.2.6-150000.73.2">runc-1.2.6-150000.73.2 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="salt-3006.0-150700.14.5.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:salt-3006.0-150700.14.5.2">salt-3006.0-150700.14.5.2 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="salt-minion-3006.0-150700.14.5.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:salt-minion-3006.0-150700.14.5.2">salt-minion-3006.0-150700.14.5.2 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="samba-client-libs-4.21.6+git.493.f39e13aba14-150700.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:samba-client-libs-4.21.6+git.493.f39e13aba14-150700.3.6.1">samba-client-libs-4.21.6+git.493.f39e13aba14-150700.3.6.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="sqlite3-tcl-3.50.2-150000.3.33.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:sqlite3-tcl-3.50.2-150000.3.33.1">sqlite3-tcl-3.50.2-150000.3.33.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="sudo-1.9.15p5-150600.3.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:sudo-1.9.15p5-150600.3.9.1">sudo-1.9.15p5-150600.3.9.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="suse-build-key-12.0-150000.8.61.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:suse-build-key-12.0-150000.8.61.2">suse-build-key-12.0-150000.8.61.2 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="suse-module-tools-15.7.6-150700.3.3.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:suse-module-tools-15.7.6-150700.3.3.3">suse-module-tools-15.7.6-150700.3.3.3 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="systemd-254.27-150600.4.43.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:systemd-254.27-150600.4.43.3">systemd-254.27-150600.4.43.3 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="systemd-presets-branding-SLE-15.1-150600.35.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:systemd-presets-branding-SLE-15.1-150600.35.3.1">systemd-presets-branding-SLE-15.1-150600.35.3.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="systemd-rpm-macros-16-150000.7.42.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:systemd-rpm-macros-16-150000.7.42.1">systemd-rpm-macros-16-150000.7.42.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="systemd-sysvcompat-254.27-150600.4.43.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:systemd-sysvcompat-254.27-150600.4.43.3">systemd-sysvcompat-254.27-150600.4.43.3 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="udev-254.27-150600.4.43.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:udev-254.27-150600.4.43.3">udev-254.27-150600.4.43.3 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="update-alternatives-1.19.0.4-150000.4.7.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:update-alternatives-1.19.0.4-150000.4.7.1">update-alternatives-1.19.0.4-150000.4.7.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="vim-9.1.1406-150500.20.27.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:vim-9.1.1406-150500.20.27.1">vim-9.1.1406-150500.20.27.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="vim-data-common-9.1.1406-150500.20.27.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:vim-data-common-9.1.1406-150500.20.27.1">vim-data-common-9.1.1406-150500.20.27.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="xen-libs-4.20.1_04-150700.3.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:xen-libs-4.20.1_04-150700.3.11.1">xen-libs-4.20.1_04-150700.3.11.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="yast2-4.7.1-150700.3.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:yast2-4.7.1-150700.3.3.1">yast2-4.7.1-150700.3.3.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="yast2-iscsi-client-4.7.7-150700.3.8.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:yast2-iscsi-client-4.7.7-150700.3.8.1">yast2-iscsi-client-4.7.7-150700.3.8.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="yast2-logs-4.7.1-150700.3.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:yast2-logs-4.7.1-150700.3.3.1">yast2-logs-4.7.1-150700.3.3.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="yast2-packager-4.7.1-150700.3.5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:yast2-packager-4.7.1-150700.3.5.1">yast2-packager-4.7.1-150700.3.5.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="yast2-users-4.7.1-150700.3.5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:yast2-users-4.7.1-150700.3.5.1">yast2-users-4.7.1-150700.3.5.1 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="zsh-5.8.1-150600.18.3.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:zsh-5.8.1-150600.18.3.2">zsh-5.8.1-150600.18.3.2 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="zypper-1.14.93-150600.10.49.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64:zypper-1.14.93-150600.10.49.2">zypper-1.14.93-150600.10.49.2 as a component of Public Cloud Image google/sle-hpc-15-sp7-byos-v20250920-x86-64</FullProductName>
    </Relationship>
  </ProductTree>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">inftrees.c in zlib 1.2.8 might allow context-dependent attackers to have unspecified impact by leveraging improper pointer arithmetic.</Note>
    </Notes>
    <CVE>CVE-2016-9840</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>critical</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>6.8</BaseScore>
        <Vector>AV:N/AC:M/Au:N/C:P/I:P/A:P</Vector>
      </ScoreSet>
    </CVSSScoreSets>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">TSX Asynchronous Abort condition on some CPUs utilizing speculative execution may allow an authenticated user to potentially enable information disclosure via a side channel with local access.</Note>
    </Notes>
    <CVE>CVE-2019-11135</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>2.1</BaseScore>
        <Vector>AV:L/AC:L/Au:N/C:P/I:N/A:N</Vector>
      </ScoreSet>
    </CVSSScoreSets>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In Zsh before 5.8, attackers able to execute commands can regain privileges dropped by the --no-PRIVILEGED option. Zsh fails to overwrite the saved uid, so the original privileges can be restored by executing MODULE_PATH=/dir/with/module zmodload with a module that calls setuid().</Note>
    </Notes>
    <CVE>CVE-2019-20044</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>7.2</BaseScore>
        <Vector>AV:L/AC:L/Au:N/C:C/I:C/A:C</Vector>
      </ScoreSet>
    </CVSSScoreSets>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In zsh before 5.8.1, an attacker can achieve code execution if they control a command output inside the prompt, as demonstrated by a %F argument. This occurs because of recursive PROMPT_SUBST expansion.</Note>
    </Notes>
    <CVE>CVE-2021-45444</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>5.1</BaseScore>
        <Vector>AV:N/AC:H/Au:N/C:P/I:P/A:P</Vector>
      </ScoreSet>
    </CVSSScoreSets>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: mediatek: vcodec: Only free buffer VA that is not NULL

In the MediaTek vcodec driver, while mtk_vcodec_mem_free() is mostly
called only when the buffer to free exists, there are some instances
that didn't do the check and triggered warnings in practice.

We believe those checks were forgotten unintentionally. Add the checks
back to fix the warnings.</Note>
    </Notes>
    <CVE>CVE-2023-52888</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: dw2102: Fix null-ptr-deref in dw2102_i2c_transfer()

In dw2102_i2c_transfer, msg is controlled by user. When msg[i].buf
is null and msg[i].len is zero, former checks on msg[i].buf would be
passed. Malicious data finally reach dw2102_i2c_transfer. If accessing
msg[i].buf[0] without sanity check, null ptr deref would happen.
We add check on msg[i].len to prevent crash.

Similar commit:
commit 950e252cb469
("[media] dw2102: limit messages to buffer size")</Note>
    </Notes>
    <CVE>CVE-2023-53146</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability was found in PAM. The secret information is stored in memory, where the attacker can trigger the victim program to execute by sending characters to its standard input (stdin). As this occurs, the attacker can train the branch predictor to execute an ROP chain speculatively. This flaw could result in leaked passwords, such as those found in /etc/shadow while performing authentications.</Note>
    </Notes>
    <CVE>CVE-2024-10041</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">When asked to both use a `.netrc` file for credentials and to follow HTTP
redirects, curl could leak the password used for the first host to the
followed-to host under certain circumstances.

This flaw only manifests itself if the netrc file has an entry that matches
the redirect target hostname but the entry either omits just the password or
omits both login and password.</Note>
    </Notes>
    <CVE>CVE-2024-11053</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Allows modifying some file metadata (e.g. last modified) with filter="data"  or file permissions (chmod) with filter="tar"  of files outside the extraction directory.
You are affected by this vulnerability if using the tarfile  module to extract untrusted tar archives using TarFile.extractall()  or TarFile.extract()  using the filter=  parameter with a value of "data"  or "tar". See the tarfile  extraction filters documentation https://docs.python.org/3/library/tarfile.html#tarfile-extraction-filter   for more information. Only Python versions 3.12 or later are affected by these vulnerabilities, earlier versions don't include the extraction filter feature.

Note that for Python 3.14 or later the default value of filter=  changed from "no filtering" to `"data", so if you are relying on this new default behavior then your usage is also affected.

Note that none of these vulnerabilities significantly affect the installation of source distributions which are tar archives as source distributions already allow arbitrary code execution during the build process. However when evaluating source distributions it's important to avoid installing source distributions with suspicious links.</Note>
    </Notes>
    <CVE>CVE-2024-12718</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Issue summary: Clients using RFC7250 Raw Public Keys (RPKs) to authenticate a
server may fail to notice that the server was not authenticated, because
handshakes don't abort as expected when the SSL_VERIFY_PEER verification mode
is set.

Impact summary: TLS and DTLS connections using raw public keys may be
vulnerable to man-in-middle attacks when server authentication failure is not
detected by clients.

RPKs are disabled by default in both TLS clients and TLS servers.  The issue
only arises when TLS clients explicitly enable RPK use by the server, and the
server, likewise, enables sending of an RPK instead of an X.509 certificate
chain.  The affected clients are those that then rely on the handshake to
fail when the server's RPK fails to match one of the expected public keys,
by setting the verification mode to SSL_VERIFY_PEER.

Clients that enable server-side raw public keys can still find out that raw
public key verification failed by calling SSL_get_verify_result(), and those
that do, and take appropriate action, are not affected.  This issue was
introduced in the initial implementation of RPK support in OpenSSL 3.2.

The FIPS modules in 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.</Note>
    </Notes>
    <CVE>CVE-2024-12797</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Issue summary: A timing side-channel which could potentially allow recovering
the private key exists in the ECDSA signature computation.

Impact summary: A timing side-channel in ECDSA signature computations
could allow recovering the private key by an attacker. However, measuring
the timing would require either local access to the signing application or
a very fast network connection with low latency.

There is a timing signal of around 300 nanoseconds when the top word of
the inverted ECDSA nonce value is zero. This can happen with significant
probability only for some of the supported elliptic curves. In particular
the NIST P-521 curve is affected. To be able to measure this leak, the attacker
process must either be located in the same physical computer or must
have a very fast network connection with low latency. For that reason
the severity of this vulnerability is Low.

The FIPS modules in 3.4, 3.3, 3.2, 3.1 and 3.0 are affected by this issue.</Note>
    </Notes>
    <CVE>CVE-2024-13176</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">When a protocol selection parameter option disables all protocols without adding any then the default set of protocols would remain in the allowed set due to an error in the logic for removing protocols. The below command would perform a request to curl.se with a plaintext protocol which has been explicitly disabled.      curl --proto -all,-http http://curl.se  The flaw is only present if the set of selected protocols disables the entire set of available protocols, in itself a command with no practical use and therefore unlikely to be encountered in real situations. The curl security team has thus assessed this to be low severity bug.</Note>
    </Notes>
    <CVE>CVE-2024-2004</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A timing-based side-channel flaw was found in libgcrypt's RSA implementation. This issue may allow a remote attacker to initiate a Bleichenbacher-style attack, which can lead to the decryption of RSA ciphertexts.</Note>
    </Notes>
    <CVE>CVE-2024-2236</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">jq is a command-line JSON processor. In versions up to and including 1.7.1, an integer overflow arises when assigning value using an index of 2147483647, the signed integer limit. This causes a denial of service. Commit de21386681c0df0104a99d9d09db23a9b2a78b1e contains a patch for the issue.</Note>
    </Notes>
    <CVE>CVE-2024-23337</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">libcurl skips the certificate verification for a QUIC connection under certain conditions, when built to use wolfSSL. If told to use an unknown/bad cipher or curve, the error path accidentally skips the verification and returns OK, thus ignoring any certificate problems.</Note>
    </Notes>
    <CVE>CVE-2024-2379</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">When an application tells libcurl it wants to allow HTTP/2 server push, and the amount of received headers for the push surpasses the maximum allowed limit (1000), libcurl aborts the server push. When aborting, libcurl inadvertently does not free all the previously allocated headers and instead leaks the memory.  Further, this error condition fails silently and is therefore not easily detected by an application.</Note>
    </Notes>
    <CVE>CVE-2024-2398</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">libcurl did not check the server certificate of TLS connections done to a host specified as an IP address, when built to use mbedTLS.  libcurl would wrongly avoid using the set hostname function when the specified hostname was given as an IP address, therefore completely skipping the certificate check. This affects all uses of TLS protocols (HTTPS, FTPS, IMAPS, POPS3, SMTPS, etc).</Note>
    </Notes>
    <CVE>CVE-2024-2466</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

cxl/pci: Skip to handle RAS errors if CXL.mem device is detached

The PCI AER model is an awkward fit for CXL error handling. While the
expectation is that a PCI device can escalate to link reset to recover
from an AER event, the same reset on CXL amounts to a surprise memory
hotplug of massive amounts of memory.

At present, the CXL error handler attempts some optimistic error
handling to unbind the device from the cxl_mem driver after reaping some
RAS register values. This results in a "hopeful" attempt to unplug the
memory, but there is no guarantee that will succeed.

A subsequent AER notification after the memdev unbind event can no
longer assume the registers are mapped. Check for memdev bind before
reaping status register values to avoid crashes of the form:

 BUG: unable to handle page fault for address: ffa00000195e9100
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 [...]
 RIP: 0010:__cxl_handle_ras+0x30/0x110 [cxl_core]
 [...]
 Call Trace:
  &lt;TASK&gt;
  ? __die+0x24/0x70
  ? page_fault_oops+0x82/0x160
  ? kernelmode_fixup_or_oops+0x84/0x110
  ? exc_page_fault+0x113/0x170
  ? asm_exc_page_fault+0x26/0x30
  ? __pfx_dpc_reset_link+0x10/0x10
  ? __cxl_handle_ras+0x30/0x110 [cxl_core]
  ? find_cxl_port+0x59/0x80 [cxl_core]
  cxl_handle_rp_ras+0xbc/0xd0 [cxl_core]
  cxl_error_detected+0x6c/0xf0 [cxl_core]
  report_error_detected+0xc7/0x1c0
  pci_walk_bus+0x73/0x90
  pcie_do_recovery+0x23f/0x330

Longer term, the unbind and PCI_ERS_RESULT_DISCONNECT behavior might
need to be replaced with a new PCI_ERS_RESULT_PANIC.</Note>
    </Notes>
    <CVE>CVE-2024-26762</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/handshake: Fix handshake_req_destroy_test1

Recently, handshake_req_destroy_test1 started failing:

Expected handshake_req_destroy_test == req, but
    handshake_req_destroy_test == 0000000000000000
    req == 0000000060f99b40
not ok 11 req_destroy works

This is because "sock_release(sock)" was replaced with "fput(filp)"
to address a memory leak. Note that sock_release() is synchronous
but fput() usually delays the final close and clean-up.

The delay is not consequential in the other cases that were changed
but handshake_req_destroy_test1 is testing that handshake_req_cancel()
followed by closing the file actually does call the -&gt;hp_destroy
method. Thus the PTR_EQ test at the end has to be sure that the
final close is complete before it checks the pointer.

We cannot use a completion here because if -&gt;hp_destroy is never
called (ie, there is an API bug) then the test will hang.

Reported by: Guenter Roeck &lt;linux@roeck-us.net&gt;</Note>
    </Notes>
    <CVE>CVE-2024-26831</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution for some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.</Note>
    </Notes>
    <CVE>CVE-2024-28956</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mm/hugetlb: fix DEBUG_LOCKS_WARN_ON(1) when dissolve_free_hugetlb_folio()

When I did memory failure tests recently, below warning occurs:

DEBUG_LOCKS_WARN_ON(1)
WARNING: CPU: 8 PID: 1011 at kernel/locking/lockdep.c:232 __lock_acquire+0xccb/0x1ca0
Modules linked in: mce_inject hwpoison_inject
CPU: 8 PID: 1011 Comm: bash Kdump: loaded Not tainted 6.9.0-rc3-next-20240410-00012-gdb69f219f4be #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
RIP: 0010:__lock_acquire+0xccb/0x1ca0
RSP: 0018:ffffa7a1c7fe3bd0 EFLAGS: 00000082
RAX: 0000000000000000 RBX: eb851eb853975fcf RCX: ffffa1ce5fc1c9c8
RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffffa1ce5fc1c9c0
RBP: ffffa1c6865d3280 R08: ffffffffb0f570a8 R09: 0000000000009ffb
R10: 0000000000000286 R11: ffffffffb0f2ad50 R12: ffffa1c6865d3d10
R13: ffffa1c6865d3c70 R14: 0000000000000000 R15: 0000000000000004
FS:  00007ff9f32aa740(0000) GS:ffffa1ce5fc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ff9f3134ba0 CR3: 00000008484e4000 CR4: 00000000000006f0
Call Trace:
 &lt;TASK&gt;
 lock_acquire+0xbe/0x2d0
 _raw_spin_lock_irqsave+0x3a/0x60
 hugepage_subpool_put_pages.part.0+0xe/0xc0
 free_huge_folio+0x253/0x3f0
 dissolve_free_huge_page+0x147/0x210
 __page_handle_poison+0x9/0x70
 memory_failure+0x4e6/0x8c0
 hard_offline_page_store+0x55/0xa0
 kernfs_fop_write_iter+0x12c/0x1d0
 vfs_write+0x380/0x540
 ksys_write+0x64/0xe0
 do_syscall_64+0xbc/0x1d0
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7ff9f3114887
RSP: 002b:00007ffecbacb458 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007ff9f3114887
RDX: 000000000000000c RSI: 0000564494164e10 RDI: 0000000000000001
RBP: 0000564494164e10 R08: 00007ff9f31d1460 R09: 000000007fffffff
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c
R13: 00007ff9f321b780 R14: 00007ff9f3217600 R15: 00007ff9f3216a00
 &lt;/TASK&gt;
Kernel panic - not syncing: kernel: panic_on_warn set ...
CPU: 8 PID: 1011 Comm: bash Kdump: loaded Not tainted 6.9.0-rc3-next-20240410-00012-gdb69f219f4be #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
Call Trace:
 &lt;TASK&gt;
 panic+0x326/0x350
 check_panic_on_warn+0x4f/0x50
 __warn+0x98/0x190
 report_bug+0x18e/0x1a0
 handle_bug+0x3d/0x70
 exc_invalid_op+0x18/0x70
 asm_exc_invalid_op+0x1a/0x20
RIP: 0010:__lock_acquire+0xccb/0x1ca0
RSP: 0018:ffffa7a1c7fe3bd0 EFLAGS: 00000082
RAX: 0000000000000000 RBX: eb851eb853975fcf RCX: ffffa1ce5fc1c9c8
RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffffa1ce5fc1c9c0
RBP: ffffa1c6865d3280 R08: ffffffffb0f570a8 R09: 0000000000009ffb
R10: 0000000000000286 R11: ffffffffb0f2ad50 R12: ffffa1c6865d3d10
R13: ffffa1c6865d3c70 R14: 0000000000000000 R15: 0000000000000004
 lock_acquire+0xbe/0x2d0
 _raw_spin_lock_irqsave+0x3a/0x60
 hugepage_subpool_put_pages.part.0+0xe/0xc0
 free_huge_folio+0x253/0x3f0
 dissolve_free_huge_page+0x147/0x210
 __page_handle_poison+0x9/0x70
 memory_failure+0x4e6/0x8c0
 hard_offline_page_store+0x55/0xa0
 kernfs_fop_write_iter+0x12c/0x1d0
 vfs_write+0x380/0x540
 ksys_write+0x64/0xe0
 do_syscall_64+0xbc/0x1d0
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7ff9f3114887
RSP: 002b:00007ffecbacb458 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007ff9f3114887
RDX: 000000000000000c RSI: 0000564494164e10 RDI: 0000000000000001
RBP: 0000564494164e10 R08: 00007ff9f31d1460 R09: 000000007fffffff
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c
R13: 00007ff9f321b780 R14: 00007ff9f3217600 R15: 00007ff9f3216a00
 &lt;/TASK&gt;

After git bisecting and digging into the code, I believe the root cause is
that _deferred_list field of folio is unioned with _hugetlb_subpool field.
In __update_and_free_hugetlb_folio(), folio-&gt;_deferred_
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-36028</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A transient execution vulnerability in some AMD processors may allow an attacker to infer data from previous stores, potentially resulting in the leakage of privileged information.</Note>
    </Notes>
    <CVE>CVE-2024-36350</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Multiple methods in the salt master skip minion token validation. Therefore a misbehaving minion can impersonate another minion.</Note>
    </Notes>
    <CVE>CVE-2024-38822</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Salt's request server is vulnerable to replay attacks when not using a TLS encrypted transport.</Note>
    </Notes>
    <CVE>CVE-2024-38823</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Directory traversal vulnerability in recv_file method allows arbitrary files to be written to the master cache directory.</Note>
    </Notes>
    <CVE>CVE-2024-38824</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>critical</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">The salt.auth.pki module does not properly authenticate callers. The "password" field contains a public certificate which is validated against a CA certificate by the module. This is not pki authentication, as the caller does not need access to the corresponding private key for the authentication attempt to be accepted.</Note>
    </Notes>
    <CVE>CVE-2024-38825</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mm/memory-failure: fix handling of dissolved but not taken off from buddy pages

When I did memory failure tests recently, below panic occurs:

page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x8cee00
flags: 0x6fffe0000000000(node=1|zone=2|lastcpupid=0x7fff)
raw: 06fffe0000000000 dead000000000100 dead000000000122 0000000000000000
raw: 0000000000000000 0000000000000009 00000000ffffffff 0000000000000000
page dumped because: VM_BUG_ON_PAGE(!PageBuddy(page))
------------[ cut here ]------------
kernel BUG at include/linux/page-flags.h:1009!
invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
RIP: 0010:__del_page_from_free_list+0x151/0x180
RSP: 0018:ffffa49c90437998 EFLAGS: 00000046
RAX: 0000000000000035 RBX: 0000000000000009 RCX: ffff8dd8dfd1c9c8
RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff8dd8dfd1c9c0
RBP: ffffd901233b8000 R08: ffffffffab5511f8 R09: 0000000000008c69
R10: 0000000000003c15 R11: ffffffffab5511f8 R12: ffff8dd8fffc0c80
R13: 0000000000000001 R14: ffff8dd8fffc0c80 R15: 0000000000000009
FS:  00007ff916304740(0000) GS:ffff8dd8dfd00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055eae50124c8 CR3: 00000008479e0000 CR4: 00000000000006f0
Call Trace:
 &lt;TASK&gt;
 __rmqueue_pcplist+0x23b/0x520
 get_page_from_freelist+0x26b/0xe40
 __alloc_pages_noprof+0x113/0x1120
 __folio_alloc_noprof+0x11/0xb0
 alloc_buddy_hugetlb_folio.isra.0+0x5a/0x130
 __alloc_fresh_hugetlb_folio+0xe7/0x140
 alloc_pool_huge_folio+0x68/0x100
 set_max_huge_pages+0x13d/0x340
 hugetlb_sysctl_handler_common+0xe8/0x110
 proc_sys_call_handler+0x194/0x280
 vfs_write+0x387/0x550
 ksys_write+0x64/0xe0
 do_syscall_64+0xc2/0x1d0
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7ff916114887
RSP: 002b:00007ffec8a2fd78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 000055eae500e350 RCX: 00007ff916114887
RDX: 0000000000000004 RSI: 000055eae500e390 RDI: 0000000000000003
RBP: 000055eae50104c0 R08: 0000000000000000 R09: 000055eae50104c0
R10: 0000000000000077 R11: 0000000000000246 R12: 0000000000000004
R13: 0000000000000004 R14: 00007ff916216b80 R15: 00007ff916216a00
 &lt;/TASK&gt;
Modules linked in: mce_inject hwpoison_inject
---[ end trace 0000000000000000 ]---

And before the panic, there had an warning about bad page state:

BUG: Bad page state in process page-types  pfn:8cee00
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x8cee00
flags: 0x6fffe0000000000(node=1|zone=2|lastcpupid=0x7fff)
page_type: 0xffffff7f(buddy)
raw: 06fffe0000000000 ffffd901241c0008 ffffd901240f8008 0000000000000000
raw: 0000000000000000 0000000000000009 00000000ffffff7f 0000000000000000
page dumped because: nonzero mapcount
Modules linked in: mce_inject hwpoison_inject
CPU: 8 PID: 154211 Comm: page-types Not tainted 6.9.0-rc4-00499-g5544ec3178e2-dirty #22
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x83/0xa0
 bad_page+0x63/0xf0
 free_unref_page+0x36e/0x5c0
 unpoison_memory+0x50b/0x630
 simple_attr_write_xsigned.constprop.0.isra.0+0xb3/0x110
 debugfs_attr_write+0x42/0x60
 full_proxy_write+0x5b/0x80
 vfs_write+0xcd/0x550
 ksys_write+0x64/0xe0
 do_syscall_64+0xc2/0x1d0
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f189a514887
RSP: 002b:00007ffdcd899718 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f189a514887
RDX: 0000000000000009 RSI: 00007ffdcd899730 RDI: 0000000000000003
RBP: 00007ffdcd8997a0 R08: 0000000000000000 R09: 00007ffdcd8994b2
R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffdcda199a8
R13: 0000000000404af1 R14: 000000000040ad78 R15: 00007f189a7a5040
 &lt;/TASK&gt;

The root cause should be the below race:

 memory_failure
  try_memory_failure_hugetlb
   me_huge_page
    __page_handle_poison
     dissolve_free_hugetlb_folio
     drain_all_pages -- Buddy page can be isolated e.g. for compaction.
     take_page_off_buddy -- Failed as page is not in the 
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-39298</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

cxl/mem: Fix no cxl_nvd during pmem region auto-assembling

When CXL subsystem is auto-assembling a pmem region during cxl
endpoint port probing, always hit below calltrace.

 BUG: kernel NULL pointer dereference, address: 0000000000000078
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 RIP: 0010:cxl_pmem_region_probe+0x22e/0x360 [cxl_pmem]
 Call Trace:
  &lt;TASK&gt;
  ? __die+0x24/0x70
  ? page_fault_oops+0x82/0x160
  ? do_user_addr_fault+0x65/0x6b0
  ? exc_page_fault+0x7d/0x170
  ? asm_exc_page_fault+0x26/0x30
  ? cxl_pmem_region_probe+0x22e/0x360 [cxl_pmem]
  ? cxl_pmem_region_probe+0x1ac/0x360 [cxl_pmem]
  cxl_bus_probe+0x1b/0x60 [cxl_core]
  really_probe+0x173/0x410
  ? __pfx___device_attach_driver+0x10/0x10
  __driver_probe_device+0x80/0x170
  driver_probe_device+0x1e/0x90
  __device_attach_driver+0x90/0x120
  bus_for_each_drv+0x84/0xe0
  __device_attach+0xbc/0x1f0
  bus_probe_device+0x90/0xa0
  device_add+0x51c/0x710
  devm_cxl_add_pmem_region+0x1b5/0x380 [cxl_core]
  cxl_bus_probe+0x1b/0x60 [cxl_core]

The cxl_nvd of the memdev needs to be available during the pmem region
probe. Currently the cxl_nvd is registered after the endpoint port probe.
The endpoint probe, in the case of autoassembly of regions, can cause a
pmem region probe requiring the not yet available cxl_nvd. Adjust the
sequence so this dependency is met.

This requires adding a port parameter to cxl_find_nvdimm_bridge() that
can be used to query the ancestor root port. The endpoint port is not
yet available, but will share a common ancestor with its parent, so
start the query from there instead.</Note>
    </Notes>
    <CVE>CVE-2024-41085</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Vim is an open source command line text editor. double-free in dialog_changed() in Vim &lt; v9.1.0648. When abandoning a buffer, Vim may ask the user what to do with the modified buffer. If the user wants the changed buffer to be saved, Vim may create a new Untitled file, if the buffer did not have a name yet. However, when setting the buffer name to Unnamed, Vim will falsely free a pointer twice, leading to a double-free and possibly later to a heap-use-after-free, which can lead to a crash. The issue has been fixed as of Vim patch v9.1.0648.</Note>
    </Notes>
    <CVE>CVE-2024-41965</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

virtio-pci: Check if is_avq is NULL

[bug]
In the virtio_pci_common.c function vp_del_vqs, vp_dev-&gt;is_avq is involved
to determine whether it is admin virtqueue, but this function vp_dev-&gt;is_avq
 may be empty. For installations, virtio_pci_legacy does not assign a value
 to vp_dev-&gt;is_avq.

[fix]
Check whether it is vp_dev-&gt;is_avq before use.

[test]
Test with virsh Attach device
Before this patch, the following command would crash the guest system

After applying the patch, everything seems to be working fine.</Note>
    </Notes>
    <CVE>CVE-2024-42134</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

perf: Fix event leak upon exec and file release

The perf pending task work is never waited upon the matching event
release. In the case of a child event, released via free_event()
directly, this can potentially result in a leaked event, such as in the
following scenario that doesn't even require a weak IRQ work
implementation to trigger:

schedule()
   prepare_task_switch()
=======&gt; &lt;NMI&gt;
      perf_event_overflow()
         event-&gt;pending_sigtrap = ...
         irq_work_queue(&amp;event-&gt;pending_irq)
&lt;======= &lt;/NMI&gt;
      perf_event_task_sched_out()
          event_sched_out()
              event-&gt;pending_sigtrap = 0;
              atomic_long_inc_not_zero(&amp;event-&gt;refcount)
              task_work_add(&amp;event-&gt;pending_task)
   finish_lock_switch()
=======&gt; &lt;IRQ&gt;
   perf_pending_irq()
      //do nothing, rely on pending task work
&lt;======= &lt;/IRQ&gt;

begin_new_exec()
   perf_event_exit_task()
      perf_event_exit_event()
         // If is child event
         free_event()
            WARN(atomic_long_cmpxchg(&amp;event-&gt;refcount, 1, 0) != 1)
            // event is leaked

Similar scenarios can also happen with perf_event_remove_on_exec() or
simply against concurrent perf_event_release().

Fix this with synchonizing against the possibly remaining pending task
work while freeing the event, just like is done with remaining pending
IRQ work. This means that the pending task callback neither need nor
should hold a reference to the event, preventing it from ever beeing
freed.</Note>
    </Notes>
    <CVE>CVE-2024-43869</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

btrfs: do not BUG_ON() when freeing tree block after error

When freeing a tree block, at btrfs_free_tree_block(), if we fail to
create a delayed reference we don't deal with the error and just do a
BUG_ON(). The error most likely to happen is -ENOMEM, and we have a
comment mentioning that only -ENOMEM can happen, but that is not true,
because in case qgroups are enabled any error returned from
btrfs_qgroup_trace_extent_post() (can be -EUCLEAN or anything returned
from btrfs_search_slot() for example) can be propagated back to
btrfs_free_tree_block().

So stop doing a BUG_ON() and return the error to the callers and make
them abort the transaction to prevent leaking space. Syzbot was
triggering this, likely due to memory allocation failure injection.</Note>
    </Notes>
    <CVE>CVE-2024-44963</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">runc is a CLI tool for spawning and running containers according to the OCI specification. runc 1.1.13 and earlier, as well as 1.2.0-rc2 and earlier, can be tricked into creating empty files or directories in arbitrary locations in the host filesystem by sharing a volume between two containers and exploiting a race with `os.MkdirAll`. While this could be used to create empty files, existing files would not be truncated. An attacker must have the ability to start containers using some kind of custom volume configuration. Containers using user namespaces are still affected, but the scope of places an attacker can create inodes can be significantly reduced. Sufficiently strict LSM policies (SELinux/Apparmor) can also in principle block this attack -- we suspect the industry standard SELinux policy may restrict this attack's scope but the exact scope of protection hasn't been analysed. This is exploitable using runc directly as well as through Docker and Kubernetes. The issue is fixed in runc v1.1.14 and v1.2.0-rc3.

Some workarounds are available. Using user namespaces restricts this attack fairly significantly such that the attacker can only create inodes in directories that the remapped root user/group has write access to. Unless the root user is remapped to an actual
user on the host (such as with rootless containers that don't use `/etc/sub[ug]id`), this in practice means that an attacker would only be able to create inodes in world-writable directories. A strict enough SELinux or AppArmor policy could in principle also restrict the scope if a specific label is applied to the runc runtime, though neither the extent to which the standard existing policies block this attack nor what exact policies are needed to sufficiently restrict this attack have been thoroughly tested.</Note>
    </Notes>
    <CVE>CVE-2024-45310</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">When logs are written to a widely-writable directory (the default), an unprivileged attacker may predict a privileged process's log file path and pre-create a symbolic link to a sensitive file in its place. When that privileged process runs, it will follow the planted symlink and overwrite that sensitive file. To fix that, glog now causes the program to exit (with status code 2) when it finds that the configured log file already exists.</Note>
    </Notes>
    <CVE>CVE-2024-45339</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Requests is a HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session.</Note>
    </Notes>
    <CVE>CVE-2024-47081</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/smc: check v2_ext_offset/eid_cnt/ism_gid_cnt when receiving proposal msg

When receiving proposal msg in server, the fields v2_ext_offset/
eid_cnt/ism_gid_cnt in proposal msg are from the remote client
and can not be fully trusted. Especially the field v2_ext_offset,
once exceed the max value, there has the chance to access wrong
address, and crash may happen.

This patch checks the fields v2_ext_offset/eid_cnt/ism_gid_cnt
before using them.</Note>
    </Notes>
    <CVE>CVE-2024-49568</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix helper writes to read-only maps

Lonial found an issue that despite user- and BPF-side frozen BPF map
(like in case of .rodata), it was still possible to write into it from
a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT}
as arguments.

In check_func_arg() when the argument is as mentioned, the meta-&gt;raw_mode
is never set. Later, check_helper_mem_access(), under the case of
PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the
subsequent call to check_map_access_type() and given the BPF map is
read-only it succeeds.

The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT
when results are written into them as opposed to read out of them. The
latter indicates that it's okay to pass a pointer to uninitialized memory
as the memory is written to anyway.

However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM
just with additional alignment requirement. So it is better to just get
rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the
fixed size memory types. For this, add MEM_ALIGNED to additionally ensure
alignment given these helpers write directly into the args via *&lt;ptr&gt; = val.
The .arg*_size has been initialized reflecting the actual sizeof(*&lt;ptr&gt;).

MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated
argument types, since in !MEM_FIXED_SIZE cases the verifier does not know
the buffer size a priori and therefore cannot blindly write *&lt;ptr&gt; = val.</Note>
    </Notes>
    <CVE>CVE-2024-49861</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/smc: fix lacks of icsk_syn_mss with IPPROTO_SMC

Eric report a panic on IPPROTO_SMC, and give the facts
that when INET_PROTOSW_ICSK was set, icsk-&gt;icsk_sync_mss must be set too.

Bug: Unable to handle kernel NULL pointer dereference at virtual address
0000000000000000
Mem abort info:
ESR = 0x0000000086000005
EC = 0x21: IABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x05: level 1 translation fault
user pgtable: 4k pages, 48-bit VAs, pgdp=00000001195d1000
[0000000000000000] pgd=0800000109c46003, p4d=0800000109c46003,
pud=0000000000000000
Internal error: Oops: 0000000086000005 [#1] PREEMPT SMP
Modules linked in:
CPU: 1 UID: 0 PID: 8037 Comm: syz.3.265 Not tainted
6.11.0-rc7-syzkaller-g5f5673607153 #0
Hardware name: Google Google Compute Engine/Google Compute Engine,
BIOS Google 08/06/2024
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : 0x0
lr : cipso_v4_sock_setattr+0x2a8/0x3c0 net/ipv4/cipso_ipv4.c:1910
sp : ffff80009b887a90
x29: ffff80009b887aa0 x28: ffff80008db94050 x27: 0000000000000000
x26: 1fffe0001aa6f5b3 x25: dfff800000000000 x24: ffff0000db75da00
x23: 0000000000000000 x22: ffff0000d8b78518 x21: 0000000000000000
x20: ffff0000d537ad80 x19: ffff0000d8b78000 x18: 1fffe000366d79ee
x17: ffff8000800614a8 x16: ffff800080569b84 x15: 0000000000000001
x14: 000000008b336894 x13: 00000000cd96feaa x12: 0000000000000003
x11: 0000000000040000 x10: 00000000000020a3 x9 : 1fffe0001b16f0f1
x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f
x5 : 0000000000000040 x4 : 0000000000000001 x3 : 0000000000000000
x2 : 0000000000000002 x1 : 0000000000000000 x0 : ffff0000d8b78000
Call trace:
0x0
netlbl_sock_setattr+0x2e4/0x338 net/netlabel/netlabel_kapi.c:1000
smack_netlbl_add+0xa4/0x154 security/smack/smack_lsm.c:2593
smack_socket_post_create+0xa8/0x14c security/smack/smack_lsm.c:2973
security_socket_post_create+0x94/0xd4 security/security.c:4425
__sock_create+0x4c8/0x884 net/socket.c:1587
sock_create net/socket.c:1622 [inline]
__sys_socket_create net/socket.c:1659 [inline]
__sys_socket+0x134/0x340 net/socket.c:1706
__do_sys_socket net/socket.c:1720 [inline]
__se_sys_socket net/socket.c:1718 [inline]
__arm64_sys_socket+0x7c/0x94 net/socket.c:1718
__invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49
el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132
do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151
el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:712
el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730
el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598
Code: ???????? ???????? ???????? ???????? (????????)
---[ end trace 0000000000000000 ]---

This patch add a toy implementation that performs a simple return to
prevent such panic. This is because MSS can be set in sock_create_kern
or smc_setsockopt, similar to how it's done in AF_SMC. However, for
AF_SMC, there is currently no way to synchronize MSS within
__sys_connect_file. This toy implementation lays the groundwork for us
to support such feature for IPPROTO_SMC in the future.</Note>
    </Notes>
    <CVE>CVE-2024-50034</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nfsd: fix race between laundromat and free_stateid

There is a race between laundromat handling of revoked delegations
and a client sending free_stateid operation. Laundromat thread
finds that delegation has expired and needs to be revoked so it
marks the delegation stid revoked and it puts it on a reaper list
but then it unlock the state lock and the actual delegation revocation
happens without the lock. Once the stid is marked revoked a racing
free_stateid processing thread does the following (1) it calls
list_del_init() which removes it from the reaper list and (2) frees
the delegation stid structure. The laundromat thread ends up not
calling the revoke_delegation() function for this particular delegation
but that means it will no release the lock lease that exists on
the file.

Now, a new open for this file comes in and ends up finding that
lease list isn't empty and calls nfsd_breaker_owns_lease() which ends
up trying to derefence a freed delegation stateid. Leading to the
followint use-after-free KASAN warning:

kernel: ==================================================================
kernel: BUG: KASAN: slab-use-after-free in nfsd_breaker_owns_lease+0x140/0x160 [nfsd]
kernel: Read of size 8 at addr ffff0000e73cd0c8 by task nfsd/6205
kernel:
kernel: CPU: 2 UID: 0 PID: 6205 Comm: nfsd Kdump: loaded Not tainted 6.11.0-rc7+ #9
kernel: Hardware name: Apple Inc. Apple Virtualization Generic Platform, BIOS 2069.0.0.0.0 08/03/2024
kernel: Call trace:
kernel: dump_backtrace+0x98/0x120
kernel: show_stack+0x1c/0x30
kernel: dump_stack_lvl+0x80/0xe8
kernel: print_address_description.constprop.0+0x84/0x390
kernel: print_report+0xa4/0x268
kernel: kasan_report+0xb4/0xf8
kernel: __asan_report_load8_noabort+0x1c/0x28
kernel: nfsd_breaker_owns_lease+0x140/0x160 [nfsd]
kernel: nfsd_file_do_acquire+0xb3c/0x11d0 [nfsd]
kernel: nfsd_file_acquire_opened+0x84/0x110 [nfsd]
kernel: nfs4_get_vfs_file+0x634/0x958 [nfsd]
kernel: nfsd4_process_open2+0xa40/0x1a40 [nfsd]
kernel: nfsd4_open+0xa08/0xe80 [nfsd]
kernel: nfsd4_proc_compound+0xb8c/0x2130 [nfsd]
kernel: nfsd_dispatch+0x22c/0x718 [nfsd]
kernel: svc_process_common+0x8e8/0x1960 [sunrpc]
kernel: svc_process+0x3d4/0x7e0 [sunrpc]
kernel: svc_handle_xprt+0x828/0xe10 [sunrpc]
kernel: svc_recv+0x2cc/0x6a8 [sunrpc]
kernel: nfsd+0x270/0x400 [nfsd]
kernel: kthread+0x288/0x310
kernel: ret_from_fork+0x10/0x20

This patch proposes a fixed that's based on adding 2 new additional
stid's sc_status values that help coordinate between the laundromat
and other operations (nfsd4_free_stateid() and nfsd4_delegreturn()).

First to make sure, that once the stid is marked revoked, it is not
removed by the nfsd4_free_stateid(), the laundromat take a reference
on the stateid. Then, coordinating whether the stid has been put
on the cl_revoked list or we are processing FREE_STATEID and need to
make sure to remove it from the list, each check that state and act
accordingly. If laundromat has added to the cl_revoke list before
the arrival of FREE_STATEID, then nfsd4_free_stateid() knows to remove
it from the list. If nfsd4_free_stateid() finds that operations arrived
before laundromat has placed it on cl_revoke list, it marks the state
freed and then laundromat will no longer add it to the list.

Also, for nfsd4_delegreturn() when looking for the specified stid,
we need to access stid that are marked removed or freeable, it means
the laundromat has started processing it but hasn't finished and this
delegreturn needs to return nfserr_deleg_revoked and not
nfserr_bad_stateid. The latter will not trigger a FREE_STATEID and the
lack of it will leave this stid on the cl_revoked list indefinitely.</Note>
    </Notes>
    <CVE>CVE-2024-50106</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/smc: do not leave a dangling sk pointer in __smc_create()

Thanks to commit 4bbd360a5084 ("socket: Print pf-&gt;create() when
it does not clear sock-&gt;sk on failure."), syzbot found an issue with AF_SMC:

smc_create must clear sock-&gt;sk on failure, family: 43, type: 1, protocol: 0
 WARNING: CPU: 0 PID: 5827 at net/socket.c:1565 __sock_create+0x96f/0xa30 net/socket.c:1563
Modules linked in:
CPU: 0 UID: 0 PID: 5827 Comm: syz-executor259 Not tainted 6.12.0-rc6-next-20241106-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
 RIP: 0010:__sock_create+0x96f/0xa30 net/socket.c:1563
Code: 03 00 74 08 4c 89 e7 e8 4f 3b 85 f8 49 8b 34 24 48 c7 c7 40 89 0c 8d 8b 54 24 04 8b 4c 24 0c 44 8b 44 24 08 e8 32 78 db f7 90 &lt;0f&gt; 0b 90 90 e9 d3 fd ff ff 89 e9 80 e1 07 fe c1 38 c1 0f 8c ee f7
RSP: 0018:ffffc90003e4fda0 EFLAGS: 00010246
RAX: 099c6f938c7f4700 RBX: 1ffffffff1a595fd RCX: ffff888034823c00
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 00000000ffffffe9 R08: ffffffff81567052 R09: 1ffff920007c9f50
R10: dffffc0000000000 R11: fffff520007c9f51 R12: ffffffff8d2cafe8
R13: 1ffffffff1a595fe R14: ffffffff9a789c40 R15: ffff8880764298c0
FS:  000055557b518380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fa62ff43225 CR3: 0000000031628000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
  sock_create net/socket.c:1616 [inline]
  __sys_socket_create net/socket.c:1653 [inline]
  __sys_socket+0x150/0x3c0 net/socket.c:1700
  __do_sys_socket net/socket.c:1714 [inline]
  __se_sys_socket net/socket.c:1712 [inline]

For reference, see commit 2d859aff775d ("Merge branch
'do-not-leave-dangling-sk-pointers-in-pf-create-functions'")</Note>
    </Notes>
    <CVE>CVE-2024-50293</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: fix use-after-free in ath12k_dp_cc_cleanup()

During ath12k module removal, in ath12k_core_deinit(),
ath12k_mac_destroy() un-registers ah-&gt;hw from mac80211 and frees
the ah-&gt;hw as well as all the ar's in it. After this
ath12k_core_soc_destroy()-&gt; ath12k_dp_free()-&gt; ath12k_dp_cc_cleanup()
tries to access one of the freed ar's from pending skb.

This is because during mac destroy, driver failed to flush few
data packets, which were accessed later in ath12k_dp_cc_cleanup()
and freed, but using ar from the packet led to this use-after-free.

BUG: KASAN: use-after-free in ath12k_dp_cc_cleanup.part.0+0x5e2/0xd40 [ath12k]
Write of size 4 at addr ffff888150bd3514 by task modprobe/8926
CPU: 0 UID: 0 PID: 8926 Comm: modprobe Not tainted
6.11.0-rc2-wt-ath+ #1746
Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS
HNKBLi70.86A.0067.2021.0528.1339 05/28/2021

Call Trace:
  &lt;TASK&gt;
  dump_stack_lvl+0x7d/0xe0
  print_address_description.constprop.0+0x33/0x3a0
  print_report+0xb5/0x260
  ? kasan_addr_to_slab+0x24/0x80
  kasan_report+0xd8/0x110
  ? ath12k_dp_cc_cleanup.part.0+0x5e2/0xd40 [ath12k]
  ? ath12k_dp_cc_cleanup.part.0+0x5e2/0xd40 [ath12k]
  kasan_check_range+0xf3/0x1a0
  __kasan_check_write+0x14/0x20
  ath12k_dp_cc_cleanup.part.0+0x5e2/0xd40 [ath12k]
  ath12k_dp_free+0x178/0x420 [ath12k]
  ath12k_core_stop+0x176/0x200 [ath12k]
  ath12k_core_deinit+0x13f/0x210 [ath12k]
  ath12k_pci_remove+0xad/0x1c0 [ath12k]
  pci_device_remove+0x9b/0x1b0
  device_remove+0xbf/0x150
  device_release_driver_internal+0x3c3/0x580
  ? __kasan_check_read+0x11/0x20
  driver_detach+0xc4/0x190
  bus_remove_driver+0x130/0x2a0
  driver_unregister+0x68/0x90
  pci_unregister_driver+0x24/0x240
  ? find_module_all+0x13e/0x1e0
  ath12k_pci_exit+0x10/0x20 [ath12k]
  __do_sys_delete_module+0x32c/0x580
  ? module_flags+0x2f0/0x2f0
  ? kmem_cache_free+0xf0/0x410
  ? __fput+0x56f/0xab0
  ? __fput+0x56f/0xab0
  ? debug_smp_processor_id+0x17/0x20
  __x64_sys_delete_module+0x4f/0x70
  x64_sys_call+0x522/0x9f0
  do_syscall_64+0x64/0x130
  entry_SYSCALL_64_after_hwframe+0x4b/0x53
RIP: 0033:0x7f8182c6ac8b

Commit 24de1b7b231c ("wifi: ath12k: fix flush failure in recovery
scenarios") added the change to decrement the pending packets count
in case of recovery which make sense as ah-&gt;hw as well all
ar's in it are intact during recovery, but during core deinit there
is no use in decrementing packets count or waking up the empty waitq
as the module is going to be removed also ar's from pending skb's
can't be used and the packets should just be released back.

To fix this, avoid accessing ar from skb-&gt;cb when driver is being
unregistered.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00214-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3</Note>
    </Notes>
    <CVE>CVE-2024-56541</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sched/numa: fix memory leak due to the overwritten vma-&gt;numab_state

[Problem Description]
When running the hackbench program of LTP, the following memory leak is
reported by kmemleak.

  # /opt/ltp/testcases/bin/hackbench 20 thread 1000
  Running with 20*40 (== 800) tasks.

  # dmesg | grep kmemleak
  ...
  kmemleak: 480 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
  kmemleak: 665 new suspected memory leaks (see /sys/kernel/debug/kmemleak)

  # cat /sys/kernel/debug/kmemleak
  unreferenced object 0xffff888cd8ca2c40 (size 64):
    comm "hackbench", pid 17142, jiffies 4299780315
    hex dump (first 32 bytes):
      ac 74 49 00 01 00 00 00 4c 84 49 00 01 00 00 00  .tI.....L.I.....
      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    backtrace (crc bff18fd4):
      [&lt;ffffffff81419a89&gt;] __kmalloc_cache_noprof+0x2f9/0x3f0
      [&lt;ffffffff8113f715&gt;] task_numa_work+0x725/0xa00
      [&lt;ffffffff8110f878&gt;] task_work_run+0x58/0x90
      [&lt;ffffffff81ddd9f8&gt;] syscall_exit_to_user_mode+0x1c8/0x1e0
      [&lt;ffffffff81dd78d5&gt;] do_syscall_64+0x85/0x150
      [&lt;ffffffff81e0012b&gt;] entry_SYSCALL_64_after_hwframe+0x76/0x7e
  ...

This issue can be consistently reproduced on three different servers:
  * a 448-core server
  * a 256-core server
  * a 192-core server

[Root Cause]
Since multiple threads are created by the hackbench program (along with
the command argument 'thread'), a shared vma might be accessed by two or
more cores simultaneously. When two or more cores observe that
vma-&gt;numab_state is NULL at the same time, vma-&gt;numab_state will be
overwritten.

Although current code ensures that only one thread scans the VMAs in a
single 'numa_scan_period', there might be a chance for another thread
to enter in the next 'numa_scan_period' while we have not gotten till
numab_state allocation [1].

Note that the command `/opt/ltp/testcases/bin/hackbench 50 process 1000`
cannot the reproduce the issue. It is verified with 200+ test runs.

[Solution]
Use the cmpxchg atomic operation to ensure that only one thread executes
the vma-&gt;numab_state assignment.

[1] https://lore.kernel.org/lkml/1794be3c-358c-4cdc-a43d-a1f841d91ef7@amd.com/</Note>
    </Notes>
    <CVE>CVE-2024-56613</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

s390/pci: Fix potential double remove of hotplug slot

In commit 6ee600bfbe0f ("s390/pci: remove hotplug slot when releasing the
device") the zpci_exit_slot() was moved from zpci_device_reserved() to
zpci_release_device() with the intention of keeping the hotplug slot
around until the device is actually removed.

Now zpci_release_device() is only called once all references are
dropped. Since the zPCI subsystem only drops its reference once the
device is in the reserved state it follows that zpci_release_device()
must only deal with devices in the reserved state. Despite that it
contains code to tear down from both configured and standby state. For
the standby case this already includes the removal of the hotplug slot
so would cause a double removal if a device was ever removed in
either configured or standby state.

Instead of causing a potential double removal in a case that should
never happen explicitly WARN_ON() if a device in non-reserved state is
released and get rid of the dead code cases.</Note>
    </Notes>
    <CVE>CVE-2024-56699</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">GNU GRUB (aka GRUB2) through 2.12 does not use a constant-time algorithm for grub_crypto_memcmp and thus allows side-channel attacks.</Note>
    </Notes>
    <CVE>CVE-2024-56738</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vfio/mlx5: Fix an unwind issue in mlx5vf_add_migration_pages()

Fix an unwind issue in mlx5vf_add_migration_pages().

If a set of pages is allocated but fails to be added to the SG table,
they need to be freed to prevent a memory leak.

Any pages successfully added to the SG table will be freed as part of
mlx5vf_free_data_buffer().</Note>
    </Notes>
    <CVE>CVE-2024-56742</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_set_pipapo: fix initial map fill

The initial buffer has to be inited to all-ones, but it must restrict
it to the size of the first field, not the total field size.

After each round in the map search step, the result and the fill map
are swapped, so if we have a set where f-&gt;bsize of the first element
is smaller than m-&gt;bsize_max, those one-bits are leaked into future
rounds result map.

This makes pipapo find an incorrect matching results for sets where
first field size is not the largest.

Followup patch adds a test case to nft_concat_range.sh selftest script.

Thanks to Stefano Brivio for pointing out that we need to zero out
the remainder explicitly, only correcting memset() argument isn't enough.</Note>
    </Notes>
    <CVE>CVE-2024-57947</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

xfrm: state: fix out-of-bounds read during lookup

lookup and resize can run in parallel.

The xfrm_state_hash_generation seqlock ensures a retry, but the hash
functions can observe a hmask value that is too large for the new hlist
array.

rehash does:
  rcu_assign_pointer(net-&gt;xfrm.state_bydst, ndst) [..]
  net-&gt;xfrm.state_hmask = nhashmask;

While state lookup does:
  h = xfrm_dst_hash(net, daddr, saddr, tmpl-&gt;reqid, encap_family);
  hlist_for_each_entry_rcu(x, net-&gt;xfrm.state_bydst + h, bydst) {

This is only safe in case the update to state_bydst is larger than
net-&gt;xfrm.xfrm_state_hmask (or if the lookup function gets
serialized via state spinlock again).

Fix this by prefetching state_hmask and the associated pointers.
The xfrm_state_hash_generation seqlock retry will ensure that the pointer
and the hmask will be consistent.

The existing helpers, like xfrm_dst_hash(), are now unsafe for RCU side,
add lockdep assertions to document that they are only safe for insert
side.

xfrm_state_lookup_byaddr() uses the spinlock rather than RCU.
AFAICS this is an oversight from back when state lookup was converted to
RCU, this lock should be replaced with RCU in a future patch.</Note>
    </Notes>
    <CVE>CVE-2024-57982</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: btrtl: check for NULL in btrtl_setup_realtek()

If insert an USB dongle which chip is not maintained in ic_id_table, it
will hit the NULL point accessed. Add a null point check to avoid the
Kernel Oops.</Note>
    </Notes>
    <CVE>CVE-2024-57987</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: btbcm: Fix NULL deref in btbcm_get_board_name()

devm_kstrdup() can return a NULL pointer on failure,but this
returned value in btbcm_get_board_name() is not checked.
Add NULL check in btbcm_get_board_name(), to handle kernel NULL
pointer dereference error.</Note>
    </Notes>
    <CVE>CVE-2024-57988</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: fix read pointer after free in ath12k_mac_assign_vif_to_vdev()

In ath12k_mac_assign_vif_to_vdev(), if arvif is created on a different
radio, it gets deleted from that radio through a call to
ath12k_mac_unassign_link_vif(). This action frees the arvif pointer.
Subsequently, there is a check involving arvif, which will result in a
read-after-free scenario.

Fix this by moving this check after arvif is again assigned via call to
ath12k_mac_assign_link_vif().

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1</Note>
    </Notes>
    <CVE>CVE-2024-57995</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: intel/ipu6: remove cpu latency qos request on error

Fix cpu latency qos list corruption like below. It happens when
we do not remove cpu latency request on error path and free
corresponding memory.

[   30.634378] l7 kernel: list_add corruption. prev-&gt;next should be next (ffffffff9645e960), but was 0000000100100001. (prev=ffff8e9e877e20a8).
[   30.634388] l7 kernel: WARNING: CPU: 2 PID: 2008 at lib/list_debug.c:32 __list_add_valid_or_report+0x83/0xa0
&lt;snip&gt;
[   30.634640] l7 kernel: Call Trace:
[   30.634650] l7 kernel:  &lt;TASK&gt;
[   30.634659] l7 kernel:  ? __list_add_valid_or_report+0x83/0xa0
[   30.634669] l7 kernel:  ? __warn.cold+0x93/0xf6
[   30.634678] l7 kernel:  ? __list_add_valid_or_report+0x83/0xa0
[   30.634690] l7 kernel:  ? report_bug+0xff/0x140
[   30.634702] l7 kernel:  ? handle_bug+0x58/0x90
[   30.634712] l7 kernel:  ? exc_invalid_op+0x17/0x70
[   30.634723] l7 kernel:  ? asm_exc_invalid_op+0x1a/0x20
[   30.634733] l7 kernel:  ? __list_add_valid_or_report+0x83/0xa0
[   30.634742] l7 kernel:  plist_add+0xdd/0x140
[   30.634754] l7 kernel:  pm_qos_update_target+0xa0/0x1f0
[   30.634764] l7 kernel:  cpu_latency_qos_update_request+0x61/0xc0
[   30.634773] l7 kernel:  intel_dp_aux_xfer+0x4c7/0x6e0 [i915 1f824655ed04687c2b0d23dbce759fa785f6d033]</Note>
    </Notes>
    <CVE>CVE-2024-58004</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: Fix for out-of bound access error

Selfgen stats are placed in a buffer using print_array_to_buf_index() function.
Array length parameter passed to the function is too big, resulting in possible
out-of bound memory error.
Decreasing buffer size by one fixes faulty upper bound of passed array.

Discovered in coverity scan, CID 1600742 and CID 1600758</Note>
    </Notes>
    <CVE>CVE-2024-58015</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

rxrpc: Fix handling of received connection abort

Fix the handling of a connection abort that we've received.  Though the
abort is at the connection level, it needs propagating to the calls on that
connection.  Whilst the propagation bit is performed, the calls aren't then
woken up to go and process their termination, and as no further input is
forthcoming, they just hang.

Also add some tracing for the logging of connection aborts.</Note>
    </Notes>
    <CVE>CVE-2024-58053</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: avoid NULL pointer dereference

When iterating over the links of a vif, we need to make sure that the
pointer is valid (in other words - that the link exists) before
dereferncing it.
Use for_each_vif_active_link that also does the check.</Note>
    </Notes>
    <CVE>CVE-2024-58062</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

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

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

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

So don't use soc_pcm_ret() on .prepare callback is better idea.</Note>
    </Notes>
    <CVE>CVE-2024-58077</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: track changes_pkt_data property for global functions

When processing calls to certain helpers, verifier invalidates all
packet pointers in a current state. For example, consider the
following program:

    __attribute__((__noinline__))
    long skb_pull_data(struct __sk_buff *sk, __u32 len)
    {
        return bpf_skb_pull_data(sk, len);
    }

    SEC("tc")
    int test_invalidate_checks(struct __sk_buff *sk)
    {
        int *p = (void *)(long)sk-&gt;data;
        if ((void *)(p + 1) &gt; (void *)(long)sk-&gt;data_end) return TCX_DROP;
        skb_pull_data(sk, 0);
        *p = 42;
        return TCX_PASS;
    }

After a call to bpf_skb_pull_data() the pointer 'p' can't be used
safely. See function filter.c:bpf_helper_changes_pkt_data() for a list
of such helpers.

At the moment verifier invalidates packet pointers when processing
helper function calls, and does not traverse global sub-programs when
processing calls to global sub-programs. This means that calls to
helpers done from global sub-programs do not invalidate pointers in
the caller state. E.g. the program above is unsafe, but is not
rejected by verifier.

This commit fixes the omission by computing field
bpf_subprog_info-&gt;changes_pkt_data for each sub-program before main
verification pass.
changes_pkt_data should be set if:
- subprogram calls helper for which bpf_helper_changes_pkt_data
  returns true;
- subprogram calls a global function,
  for which bpf_subprog_info-&gt;changes_pkt_data should be set.

The verifier.c:check_cfg() pass is modified to compute this
information. The commit relies on depth first instruction traversal
done by check_cfg() and absence of recursive function calls:
- check_cfg() would eventually visit every call to subprogram S in a
  state when S is fully explored;
- when S is fully explored:
  - every direct helper call within S is explored
    (and thus changes_pkt_data is set if needed);
  - every call to subprogram S1 called by S was visited with S1 fully
    explored (and thus S inherits changes_pkt_data from S1).

The downside of such approach is that dead code elimination is not
taken into account: if a helper call inside global function is dead
because of current configuration, verifier would conservatively assume
that the call occurs for the purpose of the changes_pkt_data
computation.</Note>
    </Notes>
    <CVE>CVE-2024-58098</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vmxnet3: Fix packet corruption in vmxnet3_xdp_xmit_frame

Andrew and Nikolay reported connectivity issues with Cilium's service
load-balancing in case of vmxnet3.

If a BPF program for native XDP adds an encapsulation header such as
IPIP and transmits the packet out the same interface, then in case
of vmxnet3 a corrupted packet is being sent and subsequently dropped
on the path.

vmxnet3_xdp_xmit_frame() which is called e.g. via vmxnet3_run_xdp()
through vmxnet3_xdp_xmit_back() calculates an incorrect DMA address:

  page = virt_to_page(xdpf-&gt;data);
  tbi-&gt;dma_addr = page_pool_get_dma_addr(page) +
                  VMXNET3_XDP_HEADROOM;
  dma_sync_single_for_device(&amp;adapter-&gt;pdev-&gt;dev,
                             tbi-&gt;dma_addr, buf_size,
                             DMA_TO_DEVICE);

The above assumes a fixed offset (VMXNET3_XDP_HEADROOM), but the XDP
BPF program could have moved xdp-&gt;data. While the passed buf_size is
correct (xdpf-&gt;len), the dma_addr needs to have a dynamic offset which
can be calculated as xdpf-&gt;data - (void *)xdpf, that is, xdp-&gt;data -
xdp-&gt;data_hard_start.</Note>
    </Notes>
    <CVE>CVE-2024-58099</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: check changes_pkt_data property for extension programs

When processing calls to global sub-programs, verifier decides whether
to invalidate all packet pointers in current state depending on the
changes_pkt_data property of the global sub-program.

Because of this, an extension program replacing a global sub-program
must be compatible with changes_pkt_data property of the sub-program
being replaced.

This commit:
- adds changes_pkt_data flag to struct bpf_prog_aux:
  - this flag is set in check_cfg() for main sub-program;
  - in jit_subprogs() for other sub-programs;
- modifies bpf_check_attach_btf_id() to check changes_pkt_data flag;
- moves call to check_attach_btf_id() after the call to check_cfg(),
  because it needs changes_pkt_data flag to be set:

    bpf_check:
      ...                             ...
    - check_attach_btf_id             resolve_pseudo_ldimm64
      resolve_pseudo_ldimm64   --&gt;    bpf_prog_is_offloaded
      bpf_prog_is_offloaded           check_cfg
      check_cfg                     + check_attach_btf_id
      ...                             ...

The following fields are set by check_attach_btf_id():
- env-&gt;ops
- prog-&gt;aux-&gt;attach_btf_trace
- prog-&gt;aux-&gt;attach_func_name
- prog-&gt;aux-&gt;attach_func_proto
- prog-&gt;aux-&gt;dst_trampoline
- prog-&gt;aux-&gt;mod
- prog-&gt;aux-&gt;saved_dst_attach_type
- prog-&gt;aux-&gt;saved_dst_prog_type
- prog-&gt;expected_attach_type

Neither of these fields are used by resolve_pseudo_ldimm64() or
bpf_prog_offload_verifier_prep() (for netronome and netdevsim
drivers), so the reordering is safe.</Note>
    </Notes>
    <CVE>CVE-2024-58100</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: consider that tail calls invalidate packet pointers

Tail-called programs could execute any of the helpers that invalidate
packet pointers. Hence, conservatively assume that each tail call
invalidates packet pointers.

Making the change in bpf_helper_changes_pkt_data() automatically makes
use of check_cfg() logic that computes 'changes_pkt_data' effect for
global sub-programs, such that the following program could be
rejected:

    int tail_call(struct __sk_buff *sk)
    {
    	bpf_tail_call_static(sk, &amp;jmp_table, 0);
    	return 0;
    }

    SEC("tc")
    int not_safe(struct __sk_buff *sk)
    {
    	int *p = (void *)(long)sk-&gt;data;
    	... make p valid ...
    	tail_call(sk);
    	*p = 42; /* this is unsafe */
    	...
    }

The tc_bpf2bpf.c:subprog_tc() needs change: mark it as a function that
can invalidate packet pointers. Otherwise, it can't be freplaced with
tailcall_freplace.c:entry_freplace() that does a tail call.</Note>
    </Notes>
    <CVE>CVE-2024-58237</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">libcurl's ASN1 parser has this utf8asn1str() function used for parsing an ASN.1 UTF-8 string. Itcan detect an invalid field and return error. Unfortunately, when doing so it also invokes `free()` on a 4 byte localstack buffer.  Most modern malloc implementations detect this error and immediately abort. Some however accept the input pointer and add that memory to its list of available chunks. This leads to the overwriting of nearby stack memory. The content of the overwrite is decided by the `free()` implementation; likely to be memory pointers and a set of flags.  The most likely outcome of exploting this flaw is a crash, although it cannot be ruled out that more serious results can be had in special circumstances.</Note>
    </Notes>
    <CVE>CVE-2024-6197</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">libcurl's ASN1 parser code has the `GTime2str()` function, used for parsing an
ASN.1 Generalized Time field. If given an syntactically incorrect field, the
parser might end up using -1 for the length of the *time fraction*, leading to
a `strlen()` getting performed on a pointer to a heap buffer area that is not
(purposely) null terminated.

This flaw most likely leads to a crash, but can also lead to heap contents
getting returned to the application when
[CURLINFO_CERTINFO](https://curl.se/libcurl/c/CURLINFO_CERTINFO.html) is used.</Note>
    </Notes>
    <CVE>CVE-2024-7264</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">When curl is told to use the Certificate Status Request TLS extension, often referred to as OCSP stapling, to verify that the server certificate is valid, it might fail to detect some OCSP problems and instead wrongly consider the response as fine.  If the returned status reports another error than 'revoked' (like for example 'unauthorized') it is not treated as a bad certficate.</Note>
    </Notes>
    <CVE>CVE-2024-8096</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A stack overflow vulnerability exists in the libexpat library due to the way it handles recursive entity expansion in XML documents. When parsing an XML document with deeply nested entity references, libexpat can be forced to recurse indefinitely, exhausting the stack space and causing a crash. This issue could lead to denial of service (DoS) or, in some cases, exploitable memory corruption, depending on the environment and library usage.</Note>
    </Notes>
    <CVE>CVE-2024-8176</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">When curl is asked to use HSTS, the expiry time for a subdomain might
overwrite a parent domain's cache entry, making it end sooner or later than
otherwise intended.

This affects curl using applications that enable HSTS and use URLs with the
insecure `HTTP://` scheme and perform transfers with hosts like
`x.example.com` as well as `example.com` where the first host is a subdomain
of the second host.

(The HSTS cache either needs to have been populated manually or there needs to
have been previous HTTPS accesses done as the cache needs to have entries for
the domains involved to trigger this problem.)

When `x.example.com` responds with `Strict-Transport-Security:` headers, this
bug can make the subdomain's expiry timeout *bleed over* and get set for the
parent domain `example.com` in curl's HSTS cache.

The result of a triggered bug is that HTTP accesses to `example.com` get
converted to HTTPS for a different period of time than what was asked for by
the origin server. If `example.com` for example stops supporting HTTPS at its
expiry time, curl might then fail to access `http://example.com` until the
(wrongly set) timeout expires. This bug can also expire the parent's entry
*earlier*, thus making curl inadvertently switch back to insecure HTTP earlier
than otherwise intended.</Note>
    </Notes>
    <CVE>CVE-2024-9681</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">When asked to use a `.netrc` file for credentials **and** to follow HTTP
redirects, curl could leak the password used for the first host to the
followed-to host under certain circumstances.

This flaw only manifests itself if the netrc file has a `default` entry that
omits both login and password. A rare circumstance.</Note>
    </Notes>
    <CVE>CVE-2025-0167</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Buildx is a Docker CLI plugin that extends build capabilities using BuildKit.

Cache backends support credentials by setting secrets directly as attribute values in cache-to/cache-from  configuration. When supplied as user input, these secure values may be inadvertently captured in OpenTelemetry traces as part of the arguments and flags for the traced CLI command.  OpenTelemetry traces are also saved in BuildKit daemon's history records.


This vulnerability does not impact secrets passed to the Github cache backend  via environment variables or registry authentication.</Note>
    </Notes>
    <CVE>CVE-2025-0495</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in Samba. The smbd service daemon does not pick up group membership changes when re-authenticating an expired SMB session. This issue can expose file shares until clients disconnect and then connect again.</Note>
    </Notes>
    <CVE>CVE-2025-0620</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">libcurl would wrongly close the same eventfd file descriptor twice when taking
down a connection channel after having completed a threaded name resolve.</Note>
    </Notes>
    <CVE>CVE-2025-0665</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">When libcurl is asked to perform automatic gzip decompression of
content-encoded HTTP responses with the `CURLOPT_ACCEPT_ENCODING` option,
**using zlib 1.2.0.3 or older**, an attacker-controlled integer overflow would
make libcurl perform a buffer overflow.</Note>
    </Notes>
    <CVE>CVE-2025-0725</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">The Python standard library functions `urllib.parse.urlsplit` and `urlparse` accepted domain names that included square brackets which isn't valid according to RFC 3986. Square brackets are only meant to be used as delimiters for specifying IPv6 and IPvFuture hosts in URLs. This could result in differential parsing across the Python URL parser and other specification-compliant URL parsers.</Note>
    </Notes>
    <CVE>CVE-2025-0938</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">curl's websocket code did not update the 32 bit mask pattern for each new
 outgoing frame as the specification says. Instead it used a fixed mask that
persisted and was used throughout the entire connection.

A predictable mask pattern allows for a malicious server to induce traffic
between the two communicating parties that could be interpreted by an involved
proxy (configured or transparent) as genuine, real, HTTP traffic with content
and thereby poison its cache. That cached poisoned content could then be
served to all users of that proxy.</Note>
    </Notes>
    <CVE>CVE-2025-10148</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: reenable NETIF_F_IPV6_CSUM offload for BIG TCP packets

The blamed commit disabled hardware offoad of IPv6 packets with
extension headers on devices that advertise NETIF_F_IPV6_CSUM,
based on the definition of that feature in skbuff.h:

 *   * - %NETIF_F_IPV6_CSUM
 *     - Driver (device) is only able to checksum plain
 *       TCP or UDP packets over IPv6. These are specifically
 *       unencapsulated packets of the form IPv6|TCP or
 *       IPv6|UDP where the Next Header field in the IPv6
 *       header is either TCP or UDP. IPv6 extension headers
 *       are not supported with this feature. This feature
 *       cannot be set in features for a device with
 *       NETIF_F_HW_CSUM also set. This feature is being
 *       DEPRECATED (see below).

The change causes skb_warn_bad_offload to fire for BIG TCP
packets.

[  496.310233] WARNING: CPU: 13 PID: 23472 at net/core/dev.c:3129 skb_warn_bad_offload+0xc4/0xe0

[  496.310297]  ? skb_warn_bad_offload+0xc4/0xe0
[  496.310300]  skb_checksum_help+0x129/0x1f0
[  496.310303]  skb_csum_hwoffload_help+0x150/0x1b0
[  496.310306]  validate_xmit_skb+0x159/0x270
[  496.310309]  validate_xmit_skb_list+0x41/0x70
[  496.310312]  sch_direct_xmit+0x5c/0x250
[  496.310317]  __qdisc_run+0x388/0x620

BIG TCP introduced an IPV6_TLV_JUMBO IPv6 extension header to
communicate packet length, as this is an IPv6 jumbogram. But, the
feature is only enabled on devices that support BIG TCP TSO. The
header is only present for PF_PACKET taps like tcpdump, and not
transmitted by physical devices.

For this specific case of extension headers that are not
transmitted, return to the situation before the blamed commit
and support hardware offload.

ipv6_has_hopopt_jumbo() tests not only whether this header is present,
but also that it is the only extension header before a terminal (L4)
header.</Note>
    </Notes>
    <CVE>CVE-2025-21629</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

btrfs: avoid NULL pointer dereference if no valid extent tree

[BUG]
Syzbot reported a crash with the following call trace:

  BTRFS info (device loop0): scrub: started on devid 1
  BUG: kernel NULL pointer dereference, address: 0000000000000208
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 106e70067 P4D 106e70067 PUD 107143067 PMD 0
  Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI
  CPU: 1 UID: 0 PID: 689 Comm: repro Kdump: loaded Tainted: G           O       6.13.0-rc4-custom+ #206
  Tainted: [O]=OOT_MODULE
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022
  RIP: 0010:find_first_extent_item+0x26/0x1f0 [btrfs]
  Call Trace:
   &lt;TASK&gt;
   scrub_find_fill_first_stripe+0x13d/0x3b0 [btrfs]
   scrub_simple_mirror+0x175/0x260 [btrfs]
   scrub_stripe+0x5d4/0x6c0 [btrfs]
   scrub_chunk+0xbb/0x170 [btrfs]
   scrub_enumerate_chunks+0x2f4/0x5f0 [btrfs]
   btrfs_scrub_dev+0x240/0x600 [btrfs]
   btrfs_ioctl+0x1dc8/0x2fa0 [btrfs]
   ? do_sys_openat2+0xa5/0xf0
   __x64_sys_ioctl+0x97/0xc0
   do_syscall_64+0x4f/0x120
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
   &lt;/TASK&gt;

[CAUSE]
The reproducer is using a corrupted image where extent tree root is
corrupted, thus forcing to use "rescue=all,ro" mount option to mount the
image.

Then it triggered a scrub, but since scrub relies on extent tree to find
where the data/metadata extents are, scrub_find_fill_first_stripe()
relies on an non-empty extent root.

But unfortunately scrub_find_fill_first_stripe() doesn't really expect
an NULL pointer for extent root, it use extent_root to grab fs_info and
triggered a NULL pointer dereference.

[FIX]
Add an extra check for a valid extent root at the beginning of
scrub_find_fill_first_stripe().

The new error path is introduced by 42437a6386ff ("btrfs: introduce
mount option rescue=ignorebadroots"), but that's pretty old, and later
commit b979547513ff ("btrfs: scrub: introduce helper to find and fill
sector info for a scrub_stripe") changed how we do scrub.

So for kernels older than 6.6, the fix will need manual backport.</Note>
    </Notes>
    <CVE>CVE-2025-21658</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

powerpc/pseries/iommu: Don't unset window if it was never set

On pSeries, when user attempts to use the same vfio container used by
different iommu group, the spapr_tce_set_window() returns -EPERM
and the subsequent cleanup leads to the below crash.

   Kernel attempted to read user page (308) - exploit attempt?
   BUG: Kernel NULL pointer dereference on read at 0x00000308
   Faulting instruction address: 0xc0000000001ce358
   Oops: Kernel access of bad area, sig: 11 [#1]
   NIP:  c0000000001ce358 LR: c0000000001ce05c CTR: c00000000005add0
   &lt;snip&gt;
   NIP [c0000000001ce358] spapr_tce_unset_window+0x3b8/0x510
   LR [c0000000001ce05c] spapr_tce_unset_window+0xbc/0x510
   Call Trace:
     spapr_tce_unset_window+0xbc/0x510 (unreliable)
     tce_iommu_attach_group+0x24c/0x340 [vfio_iommu_spapr_tce]
     vfio_container_attach_group+0xec/0x240 [vfio]
     vfio_group_fops_unl_ioctl+0x548/0xb00 [vfio]
     sys_ioctl+0x754/0x1580
     system_call_exception+0x13c/0x330
     system_call_vectored_common+0x15c/0x2ec
   &lt;snip&gt;
   --- interrupt: 3000

Fix this by having null check for the tbl passed to the
spapr_tce_unset_window().</Note>
    </Notes>
    <CVE>CVE-2025-21713</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

xfrm: delete intermediate secpath entry in packet offload mode

Packets handled by hardware have added secpath as a way to inform XFRM
core code that this path was already handled. That secpath is not needed
at all after policy is checked and it is removed later in the stack.

However, in the case of IP forwarding is enabled (/proc/sys/net/ipv4/ip_forward),
that secpath is not removed and packets which already were handled are reentered
to the driver TX path with xfrm_offload set.

The following kernel panic is observed in mlx5 in such case:

 mlx5_core 0000:04:00.0 enp4s0f0np0: Link up
 mlx5_core 0000:04:00.1 enp4s0f1np1: Link up
 Initializing XFRM netlink socket
 IPsec XFRM device driver
 BUG: kernel NULL pointer dereference, address: 0000000000000000
 #PF: supervisor instruction fetch in kernel mode
 #PF: error_code(0x0010) - not-present page
 PGD 0 P4D 0
 Oops: Oops: 0010 [#1] PREEMPT SMP
 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc1-alex #3
 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014
 RIP: 0010:0x0
 Code: Unable to access opcode bytes at 0xffffffffffffffd6.
 RSP: 0018:ffffb87380003800 EFLAGS: 00010206
 RAX: ffff8df004e02600 RBX: ffffb873800038d8 RCX: 00000000ffff98cf
 RDX: ffff8df00733e108 RSI: ffff8df00521fb80 RDI: ffff8df001661f00
 RBP: ffffb87380003850 R08: ffff8df013980000 R09: 0000000000000010
 R10: 0000000000000002 R11: 0000000000000002 R12: ffff8df001661f00
 R13: ffff8df00521fb80 R14: ffff8df00733e108 R15: ffff8df011faf04e
 FS:  0000000000000000(0000) GS:ffff8df46b800000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: ffffffffffffffd6 CR3: 0000000106384000 CR4: 0000000000350ef0
 Call Trace:
  &lt;IRQ&gt;
  ? show_regs+0x63/0x70
  ? __die_body+0x20/0x60
  ? __die+0x2b/0x40
  ? page_fault_oops+0x15c/0x550
  ? do_user_addr_fault+0x3ed/0x870
  ? exc_page_fault+0x7f/0x190
  ? asm_exc_page_fault+0x27/0x30
  mlx5e_ipsec_handle_tx_skb+0xe7/0x2f0 [mlx5_core]
  mlx5e_xmit+0x58e/0x1980 [mlx5_core]
  ? __fib_lookup+0x6a/0xb0
  dev_hard_start_xmit+0x82/0x1d0
  sch_direct_xmit+0xfe/0x390
  __dev_queue_xmit+0x6d8/0xee0
  ? __fib_lookup+0x6a/0xb0
  ? internal_add_timer+0x48/0x70
  ? mod_timer+0xe2/0x2b0
  neigh_resolve_output+0x115/0x1b0
  __neigh_update+0x26a/0xc50
  neigh_update+0x14/0x20
  arp_process+0x2cb/0x8e0
  ? __napi_build_skb+0x5e/0x70
  arp_rcv+0x11e/0x1c0
  ? dev_gro_receive+0x574/0x820
  __netif_receive_skb_list_core+0x1cf/0x1f0
  netif_receive_skb_list_internal+0x183/0x2a0
  napi_complete_done+0x76/0x1c0
  mlx5e_napi_poll+0x234/0x7a0 [mlx5_core]
  __napi_poll+0x2d/0x1f0
  net_rx_action+0x1a6/0x370
  ? atomic_notifier_call_chain+0x3b/0x50
  ? irq_int_handler+0x15/0x20 [mlx5_core]
  handle_softirqs+0xb9/0x2f0
  ? handle_irq_event+0x44/0x60
  irq_exit_rcu+0xdb/0x100
  common_interrupt+0x98/0xc0
  &lt;/IRQ&gt;
  &lt;TASK&gt;
  asm_common_interrupt+0x27/0x40
 RIP: 0010:pv_native_safe_halt+0xb/0x10
 Code: 09 c3 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 0f 22
 0f 1f 84 00 00 00 00 00 90 eb 07 0f 00 2d 7f e9 36 00 fb
40 00 83 ff 07 77 21 89 ff ff 24 fd 88 3d a1 bd 0f 21 f8
 RSP: 0018:ffffffffbe603de8 EFLAGS: 00000202
 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000f92f46680
 RDX: 0000000000000037 RSI: 00000000ffffffff RDI: 00000000000518d4
 RBP: ffffffffbe603df0 R08: 000000cd42e4dffb R09: ffffffffbe603d70
 R10: 0000004d80d62680 R11: 0000000000000001 R12: ffffffffbe60bf40
 R13: 0000000000000000 R14: 0000000000000000 R15: ffffffffbe60aff8
  ? default_idle+0x9/0x20
  arch_cpu_idle+0x9/0x10
  default_idle_call+0x29/0xf0
  do_idle+0x1f2/0x240
  cpu_startup_entry+0x2c/0x30
  rest_init+0xe7/0x100
  start_kernel+0x76b/0xb90
  x86_64_start_reservations+0x18/0x30
  x86_64_start_kernel+0xc0/0x110
  ? setup_ghcb+0xe/0x130
  common_startup_64+0x13e/0x141
  &lt;/TASK&gt;
 Modules linked in: esp4_offload esp4 xfrm_interface
xfrm6_tunnel tunnel4 tunnel6 xfrm_user xfrm_algo binf
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-21720</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iommu: Fix potential memory leak in iopf_queue_remove_device()

The iopf_queue_remove_device() helper removes a device from the per-iommu
iopf queue when PRI is disabled on the device. It responds to all
outstanding iopf's with an IOMMU_PAGE_RESP_INVALID code and detaches the
device from the queue.

However, it fails to release the group structure that represents a group
of iopf's awaiting for a response after responding to the hardware. This
can cause a memory leak if iopf_queue_remove_device() is called with
pending iopf's.

Fix it by calling iopf_free_group() after the iopf group is responded.</Note>
    </Notes>
    <CVE>CVE-2025-21770</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/rtrs: Add missing deinit() call

A warning is triggered when repeatedly connecting and disconnecting the
rnbd:
 list_add corruption. prev-&gt;next should be next (ffff88800b13e480), but was ffff88801ecd1338. (prev=ffff88801ecd1340).
 WARNING: CPU: 1 PID: 36562 at lib/list_debug.c:32 __list_add_valid_or_report+0x7f/0xa0
 Workqueue: ib_cm cm_work_handler [ib_cm]
 RIP: 0010:__list_add_valid_or_report+0x7f/0xa0
  ? __list_add_valid_or_report+0x7f/0xa0
  ib_register_event_handler+0x65/0x93 [ib_core]
  rtrs_srv_ib_dev_init+0x29/0x30 [rtrs_server]
  rtrs_ib_dev_find_or_add+0x124/0x1d0 [rtrs_core]
  __alloc_path+0x46c/0x680 [rtrs_server]
  ? rtrs_rdma_connect+0xa6/0x2d0 [rtrs_server]
  ? rcu_is_watching+0xd/0x40
  ? __mutex_lock+0x312/0xcf0
  ? get_or_create_srv+0xad/0x310 [rtrs_server]
  ? rtrs_rdma_connect+0xa6/0x2d0 [rtrs_server]
  rtrs_rdma_connect+0x23c/0x2d0 [rtrs_server]
  ? __lock_release+0x1b1/0x2d0
  cma_cm_event_handler+0x4a/0x1a0 [rdma_cm]
  cma_ib_req_handler+0x3a0/0x7e0 [rdma_cm]
  cm_process_work+0x28/0x1a0 [ib_cm]
  ? _raw_spin_unlock_irq+0x2f/0x50
  cm_req_handler+0x618/0xa60 [ib_cm]
  cm_work_handler+0x71/0x520 [ib_cm]

Commit 667db86bcbe8 ("RDMA/rtrs: Register ib event handler") introduced a
new element .deinit but never used it at all. Fix it by invoking the
`deinit()` to appropriately unregister the IB event handler.</Note>
    </Notes>
    <CVE>CVE-2025-21805</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

gpu: host1x: Fix a use of uninitialized mutex

commit c8347f915e67 ("gpu: host1x: Fix boot regression for Tegra")
caused a use of uninitialized mutex leading to below warning when
CONFIG_DEBUG_MUTEXES and CONFIG_DEBUG_LOCK_ALLOC are enabled.

[   41.662843] ------------[ cut here ]------------
[   41.663012] DEBUG_LOCKS_WARN_ON(lock-&gt;magic != lock)
[   41.663035] WARNING: CPU: 4 PID: 794 at kernel/locking/mutex.c:587 __mutex_lock+0x670/0x878
[   41.663458] Modules linked in: rtw88_8822c(+) bluetooth(+) rtw88_pci rtw88_core mac80211 aquantia libarc4 crc_itu_t cfg80211 tegra194_cpufreq dwmac_tegra(+) arm_dsu_pmu stmmac_platform stmmac pcs_xpcs rfkill at24 host1x(+) tegra_bpmp_thermal ramoops reed_solomon fuse loop nfnetlink xfs mmc_block rpmb_core ucsi_ccg ina3221 crct10dif_ce xhci_tegra ghash_ce lm90 sha2_ce sha256_arm64 sha1_ce sdhci_tegra pwm_fan sdhci_pltfm sdhci gpio_keys rtc_tegra cqhci mmc_core phy_tegra_xusb i2c_tegra tegra186_gpc_dma i2c_tegra_bpmp spi_tegra114 dm_mirror dm_region_hash dm_log dm_mod
[   41.665078] CPU: 4 UID: 0 PID: 794 Comm: (udev-worker) Not tainted 6.11.0-29.31_1538613708.el10.aarch64+debug #1
[   41.665838] Hardware name: NVIDIA NVIDIA Jetson AGX Orin Developer Kit/Jetson, BIOS 36.3.0-gcid-35594366 02/26/2024
[   41.672555] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[   41.679636] pc : __mutex_lock+0x670/0x878
[   41.683834] lr : __mutex_lock+0x670/0x878
[   41.688035] sp : ffff800084b77090
[   41.691446] x29: ffff800084b77160 x28: ffffdd4bebf7b000 x27: ffffdd4be96b1000
[   41.698799] x26: 1fffe0002308361c x25: 1ffff0001096ee18 x24: 0000000000000000
[   41.706149] x23: 0000000000000000 x22: 0000000000000002 x21: ffffdd4be6e3c7a0
[   41.713500] x20: ffff800084b770f0 x19: ffff00011841b1e8 x18: 0000000000000000
[   41.720675] x17: 0000000000000000 x16: 0000000000000000 x15: 0720072007200720
[   41.728023] x14: 0000000000000000 x13: 0000000000000001 x12: ffff6001a96eaab3
[   41.735375] x11: 1fffe001a96eaab2 x10: ffff6001a96eaab2 x9 : ffffdd4be4838bbc
[   41.742723] x8 : 00009ffe5691554e x7 : ffff000d4b755593 x6 : 0000000000000001
[   41.749985] x5 : ffff000d4b755590 x4 : 1fffe0001d88f001 x3 : dfff800000000000
[   41.756988] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000ec478000
[   41.764251] Call trace:
[   41.766695]  __mutex_lock+0x670/0x878
[   41.770373]  mutex_lock_nested+0x2c/0x40
[   41.774134]  host1x_intr_start+0x54/0xf8 [host1x]
[   41.778863]  host1x_runtime_resume+0x150/0x228 [host1x]
[   41.783935]  pm_generic_runtime_resume+0x84/0xc8
[   41.788485]  __rpm_callback+0xa0/0x478
[   41.792422]  rpm_callback+0x15c/0x1a8
[   41.795922]  rpm_resume+0x698/0xc08
[   41.799597]  __pm_runtime_resume+0xa8/0x140
[   41.803621]  host1x_probe+0x810/0xbc0 [host1x]
[   41.807909]  platform_probe+0xcc/0x1a8
[   41.811845]  really_probe+0x188/0x800
[   41.815347]  __driver_probe_device+0x164/0x360
[   41.819810]  driver_probe_device+0x64/0x1a8
[   41.823834]  __driver_attach+0x180/0x490
[   41.827773]  bus_for_each_dev+0x104/0x1a0
[   41.831797]  driver_attach+0x44/0x68
[   41.835296]  bus_add_driver+0x23c/0x4e8
[   41.839235]  driver_register+0x15c/0x3a8
[   41.843170]  __platform_register_drivers+0xa4/0x208
[   41.848159]  tegra_host1x_init+0x4c/0xff8 [host1x]
[   41.853147]  do_one_initcall+0xd4/0x380
[   41.856997]  do_init_module+0x1dc/0x698
[   41.860758]  load_module+0xc70/0x1300
[   41.864435]  __do_sys_init_module+0x1a8/0x1d0
[   41.868721]  __arm64_sys_init_module+0x74/0xb0
[   41.873183]  invoke_syscall.constprop.0+0xdc/0x1e8
[   41.877997]  do_el0_svc+0x154/0x1d0
[   41.881671]  el0_svc+0x54/0x140
[   41.884820]  el0t_64_sync_handler+0x120/0x130
[   41.889285]  el0t_64_sync+0x1a4/0x1a8
[   41.892960] irq event stamp: 69737
[   41.896370] hardirqs last  enabled at (69737): [&lt;ffffdd4be6d7768c&gt;] _raw_spin_unlock_irqrestore+0x44/0xe8
[   41.905739] hardirqs last disabled at (69736):
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-21824</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

KVM: x86: Load DR6 with guest value only before entering .vcpu_run() loop

Move the conditional loading of hardware DR6 with the guest's DR6 value
out of the core .vcpu_run() loop to fix a bug where KVM can load hardware
with a stale vcpu-&gt;arch.dr6.

When the guest accesses a DR and host userspace isn't debugging the guest,
KVM disables DR interception and loads the guest's values into hardware on
VM-Enter and saves them on VM-Exit.  This allows the guest to access DRs
at will, e.g. so that a sequence of DR accesses to configure a breakpoint
only generates one VM-Exit.

For DR0-DR3, the logic/behavior is identical between VMX and SVM, and also
identical between KVM_DEBUGREG_BP_ENABLED (userspace debugging the guest)
and KVM_DEBUGREG_WONT_EXIT (guest using DRs), and so KVM handles loading
DR0-DR3 in common code, _outside_ of the core kvm_x86_ops.vcpu_run() loop.

But for DR6, the guest's value doesn't need to be loaded into hardware for
KVM_DEBUGREG_BP_ENABLED, and SVM provides a dedicated VMCB field whereas
VMX requires software to manually load the guest value, and so loading the
guest's value into DR6 is handled by {svm,vmx}_vcpu_run(), i.e. is done
_inside_ the core run loop.

Unfortunately, saving the guest values on VM-Exit is initiated by common
x86, again outside of the core run loop.  If the guest modifies DR6 (in
hardware, when DR interception is disabled), and then the next VM-Exit is
a fastpath VM-Exit, KVM will reload hardware DR6 with vcpu-&gt;arch.dr6 and
clobber the guest's actual value.

The bug shows up primarily with nested VMX because KVM handles the VMX
preemption timer in the fastpath, and the window between hardware DR6
being modified (in guest context) and DR6 being read by guest software is
orders of magnitude larger in a nested setup.  E.g. in non-nested, the
VMX preemption timer would need to fire precisely between #DB injection
and the #DB handler's read of DR6, whereas with a KVM-on-KVM setup, the
window where hardware DR6 is "dirty" extends all the way from L1 writing
DR6 to VMRESUME (in L1).

    L1's view:
    ==========
    &lt;L1 disables DR interception&gt;
           CPU 0/KVM-7289    [023] d....  2925.640961: kvm_entry: vcpu 0
 A:  L1 Writes DR6
           CPU 0/KVM-7289    [023] d....  2925.640963: &lt;hack&gt;: Set DRs, DR6 = 0xffff0ff1

 B:        CPU 0/KVM-7289    [023] d....  2925.640967: kvm_exit: vcpu 0 reason EXTERNAL_INTERRUPT intr_info 0x800000ec

 D: L1 reads DR6, arch.dr6 = 0
           CPU 0/KVM-7289    [023] d....  2925.640969: &lt;hack&gt;: Sync DRs, DR6 = 0xffff0ff0

           CPU 0/KVM-7289    [023] d....  2925.640976: kvm_entry: vcpu 0
    L2 reads DR6, L1 disables DR interception
           CPU 0/KVM-7289    [023] d....  2925.640980: kvm_exit: vcpu 0 reason DR_ACCESS info1 0x0000000000000216
           CPU 0/KVM-7289    [023] d....  2925.640983: kvm_entry: vcpu 0

           CPU 0/KVM-7289    [023] d....  2925.640983: &lt;hack&gt;: Set DRs, DR6 = 0xffff0ff0

    L2 detects failure
           CPU 0/KVM-7289    [023] d....  2925.640987: kvm_exit: vcpu 0 reason HLT
    L1 reads DR6 (confirms failure)
           CPU 0/KVM-7289    [023] d....  2925.640990: &lt;hack&gt;: Sync DRs, DR6 = 0xffff0ff0

    L0's view:
    ==========
    L2 reads DR6, arch.dr6 = 0
          CPU 23/KVM-5046    [001] d....  3410.005610: kvm_exit: vcpu 23 reason DR_ACCESS info1 0x0000000000000216
          CPU 23/KVM-5046    [001] .....  3410.005610: kvm_nested_vmexit: vcpu 23 reason DR_ACCESS info1 0x0000000000000216

    L2 =&gt; L1 nested VM-Exit
          CPU 23/KVM-5046    [001] .....  3410.005610: kvm_nested_vmexit_inject: reason: DR_ACCESS ext_inf1: 0x0000000000000216

          CPU 23/KVM-5046    [001] d....  3410.005610: kvm_entry: vcpu 23
          CPU 23/KVM-5046    [001] d....  3410.005611: kvm_exit: vcpu 23 reason VMREAD
          CPU 23/KVM-5046    [001] d....  3410.005611: kvm_entry: vcpu 23
          CPU 23/KVM-5046    [001] d....  3410.
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-21839</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

amdkfd: properly free gang_ctx_bo when failed to init user queue

The destructor of a gtt bo is declared as
void amdgpu_amdkfd_free_gtt_mem(struct amdgpu_device *adev, void **mem_obj);
Which takes void** as the second parameter.

GCC allows passing void* to the function because void* can be implicitly
casted to any other types, so it can pass compiling.

However, passing this void* parameter into the function's
execution process(which expects void** and dereferencing void**)
will result in errors.</Note>
    </Notes>
    <CVE>CVE-2025-21842</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/i915/gt: Use spin_lock_irqsave() in interruptible context

spin_lock/unlock() functions used in interrupt contexts could
result in a deadlock, as seen in GitLab issue #13399,
which occurs when interrupt comes in while holding a lock.

Try to remedy the problem by saving irq state before spin lock
acquisition.

v2: add irqs' state save/restore calls to all locks/unlocks in
 signal_irq_work() execution (Maciej)

v3: use with spin_lock_irqsave() in guc_lrc_desc_unpin() instead
 of other lock/unlock calls and add Fixes and Cc tags (Tvrtko);
 change title and commit message

(cherry picked from commit c088387ddd6482b40f21ccf23db1125e8fa4af7e)</Note>
    </Notes>
    <CVE>CVE-2025-21849</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sockmap, vsock: For connectible sockets allow only connected

sockmap expects all vsocks to have a transport assigned, which is expressed
in vsock_proto::psock_update_sk_prot(). However, there is an edge case
where an unconnected (connectible) socket may lose its previously assigned
transport. This is handled with a NULL check in the vsock/BPF recv path.

Another design detail is that listening vsocks are not supposed to have any
transport assigned at all. Which implies they are not supported by the
sockmap. But this is complicated by the fact that a socket, before
switching to TCP_LISTEN, may have had some transport assigned during a
failed connect() attempt. Hence, we may end up with a listening vsock in a
sockmap, which blows up quickly:

KASAN: null-ptr-deref in range [0x0000000000000120-0x0000000000000127]
CPU: 7 UID: 0 PID: 56 Comm: kworker/7:0 Not tainted 6.14.0-rc1+
Workqueue: vsock-loopback vsock_loopback_work
RIP: 0010:vsock_read_skb+0x4b/0x90
Call Trace:
 sk_psock_verdict_data_ready+0xa4/0x2e0
 virtio_transport_recv_pkt+0x1ca8/0x2acc
 vsock_loopback_work+0x27d/0x3f0
 process_one_work+0x846/0x1420
 worker_thread+0x5b3/0xf80
 kthread+0x35a/0x700
 ret_from_fork+0x2d/0x70
 ret_from_fork_asm+0x1a/0x30

For connectible sockets, instead of relying solely on the state of
vsk-&gt;transport, tell sockmap to only allow those representing established
connections. This aligns with the behaviour for AF_INET and AF_UNIX.</Note>
    </Notes>
    <CVE>CVE-2025-21854</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: allow small head cache usage with large MAX_SKB_FRAGS values

Sabrina reported the following splat:

    WARNING: CPU: 0 PID: 1 at net/core/dev.c:6935 netif_napi_add_weight_locked+0x8f2/0xba0
    Modules linked in:
    CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.14.0-rc1-net-00092-g011b03359038 #996
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014
    RIP: 0010:netif_napi_add_weight_locked+0x8f2/0xba0
    Code: e8 c3 e6 6a fe 48 83 c4 28 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc c7 44 24 10 ff ff ff ff e9 8f fb ff ff e8 9e e6 6a fe &lt;0f&gt; 0b e9 d3 fe ff ff e8 92 e6 6a fe 48 8b 04 24 be ff ff ff ff 48
    RSP: 0000:ffffc9000001fc60 EFLAGS: 00010293
    RAX: 0000000000000000 RBX: ffff88806ce48128 RCX: 1ffff11001664b9e
    RDX: ffff888008f00040 RSI: ffffffff8317ca42 RDI: ffff88800b325cb6
    RBP: ffff88800b325c40 R08: 0000000000000001 R09: ffffed100167502c
    R10: ffff88800b3a8163 R11: 0000000000000000 R12: ffff88800ac1c168
    R13: ffff88800ac1c168 R14: ffff88800ac1c168 R15: 0000000000000007
    FS:  0000000000000000(0000) GS:ffff88806ce00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: ffff888008201000 CR3: 0000000004c94001 CR4: 0000000000370ef0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
    &lt;TASK&gt;
    gro_cells_init+0x1ba/0x270
    xfrm_input_init+0x4b/0x2a0
    xfrm_init+0x38/0x50
    ip_rt_init+0x2d7/0x350
    ip_init+0xf/0x20
    inet_init+0x406/0x590
    do_one_initcall+0x9d/0x2e0
    do_initcalls+0x23b/0x280
    kernel_init_freeable+0x445/0x490
    kernel_init+0x20/0x1d0
    ret_from_fork+0x46/0x80
    ret_from_fork_asm+0x1a/0x30
    &lt;/TASK&gt;
    irq event stamp: 584330
    hardirqs last  enabled at (584338): [&lt;ffffffff8168bf87&gt;] __up_console_sem+0x77/0xb0
    hardirqs last disabled at (584345): [&lt;ffffffff8168bf6c&gt;] __up_console_sem+0x5c/0xb0
    softirqs last  enabled at (583242): [&lt;ffffffff833ee96d&gt;] netlink_insert+0x14d/0x470
    softirqs last disabled at (583754): [&lt;ffffffff8317c8cd&gt;] netif_napi_add_weight_locked+0x77d/0xba0

on kernel built with MAX_SKB_FRAGS=45, where SKB_WITH_OVERHEAD(1024)
is smaller than GRO_MAX_HEAD.

Such built additionally contains the revert of the single page frag cache
so that napi_get_frags() ends up using the page frag allocator, triggering
the splat.

Note that the underlying issue is independent from the mentioned
revert; address it ensuring that the small head cache will fit either TCP
and GRO allocation and updating napi_alloc_skb() and __netdev_alloc_skb()
to select kmalloc() usage for any allocation fitting such cache.</Note>
    </Notes>
    <CVE>CVE-2025-21868</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

efi: Don't map the entire mokvar table to determine its size

Currently, when validating the mokvar table, we (re)map the entire table
on each iteration of the loop, adding space as we discover new entries.
If the table grows over a certain size, this fails due to limitations of
early_memmap(), and we get a failure and traceback:

  ------------[ cut here ]------------
  WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:139 __early_ioremap+0xef/0x220
  ...
  Call Trace:
   &lt;TASK&gt;
   ? __early_ioremap+0xef/0x220
   ? __warn.cold+0x93/0xfa
   ? __early_ioremap+0xef/0x220
   ? report_bug+0xff/0x140
   ? early_fixup_exception+0x5d/0xb0
   ? early_idt_handler_common+0x2f/0x3a
   ? __early_ioremap+0xef/0x220
   ? efi_mokvar_table_init+0xce/0x1d0
   ? setup_arch+0x864/0xc10
   ? start_kernel+0x6b/0xa10
   ? x86_64_start_reservations+0x24/0x30
   ? x86_64_start_kernel+0xed/0xf0
   ? common_startup_64+0x13e/0x141
   &lt;/TASK&gt;
  ---[ end trace 0000000000000000 ]---
  mokvar: Failed to map EFI MOKvar config table pa=0x7c4c3000, size=265187.

Mapping the entire structure isn't actually necessary, as we don't ever
need more than one entry header mapped at once.

Changes efi_mokvar_table_init() to only map each entry header, not the
entire table, when determining the table size.  Since we're not mapping
any data past the variable name, it also changes the code to enforce
that each variable name is NUL terminated, rather than attempting to
verify it in place.</Note>
    </Notes>
    <CVE>CVE-2025-21872</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/xe/userptr: fix EFAULT handling

Currently we treat EFAULT from hmm_range_fault() as a non-fatal error
when called from xe_vm_userptr_pin() with the idea that we want to avoid
killing the entire vm and chucking an error, under the assumption that
the user just did an unmap or something, and has no intention of
actually touching that memory from the GPU.  At this point we have
already zapped the PTEs so any access should generate a page fault, and
if the pin fails there also it will then become fatal.

However it looks like it's possible for the userptr vma to still be on
the rebind list in preempt_rebind_work_func(), if we had to retry the
pin again due to something happening in the caller before we did the
rebind step, but in the meantime needing to re-validate the userptr and
this time hitting the EFAULT.

This explains an internal user report of hitting:

[  191.738349] WARNING: CPU: 1 PID: 157 at drivers/gpu/drm/xe/xe_res_cursor.h:158 xe_pt_stage_bind.constprop.0+0x60a/0x6b0 [xe]
[  191.738551] Workqueue: xe-ordered-wq preempt_rebind_work_func [xe]
[  191.738616] RIP: 0010:xe_pt_stage_bind.constprop.0+0x60a/0x6b0 [xe]
[  191.738690] Call Trace:
[  191.738692]  &lt;TASK&gt;
[  191.738694]  ? show_regs+0x69/0x80
[  191.738698]  ? __warn+0x93/0x1a0
[  191.738703]  ? xe_pt_stage_bind.constprop.0+0x60a/0x6b0 [xe]
[  191.738759]  ? report_bug+0x18f/0x1a0
[  191.738764]  ? handle_bug+0x63/0xa0
[  191.738767]  ? exc_invalid_op+0x19/0x70
[  191.738770]  ? asm_exc_invalid_op+0x1b/0x20
[  191.738777]  ? xe_pt_stage_bind.constprop.0+0x60a/0x6b0 [xe]
[  191.738834]  ? ret_from_fork_asm+0x1a/0x30
[  191.738849]  bind_op_prepare+0x105/0x7b0 [xe]
[  191.738906]  ? dma_resv_reserve_fences+0x301/0x380
[  191.738912]  xe_pt_update_ops_prepare+0x28c/0x4b0 [xe]
[  191.738966]  ? kmemleak_alloc+0x4b/0x80
[  191.738973]  ops_execute+0x188/0x9d0 [xe]
[  191.739036]  xe_vm_rebind+0x4ce/0x5a0 [xe]
[  191.739098]  ? trace_hardirqs_on+0x4d/0x60
[  191.739112]  preempt_rebind_work_func+0x76f/0xd00 [xe]

Followed by NPD, when running some workload, since the sg was never
actually populated but the vma is still marked for rebind when it should
be skipped for this special EFAULT case. This is confirmed to fix the
user report.

v2 (MattB):
 - Move earlier.
v3 (MattB):
 - Update the commit message to make it clear that this indeed fixes the
   issue.

(cherry picked from commit 6b93cb98910c826c2e2004942f8b060311e43618)</Note>
    </Notes>
    <CVE>CVE-2025-21880</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ftrace: Avoid potential division by zero in function_stat_show()

Check whether denominator expression x * (x - 1) * 1000 mod {2^32, 2^64}
produce zero and skip stddev computation in that case.

For now don't care about rec-&gt;counter * rec-&gt;counter overflow because
rec-&gt;time * rec-&gt;time overflow will likely happen earlier.</Note>
    </Notes>
    <CVE>CVE-2025-21898</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tracing: Fix bad hist from corrupting named_triggers list

The following commands causes a crash:

 ~# cd /sys/kernel/tracing/events/rcu/rcu_callback
 ~# echo 'hist:name=bad:keys=common_pid:onmax(bogus).save(common_pid)' &gt; trigger
 bash: echo: write error: Invalid argument
 ~# echo 'hist:name=bad:keys=common_pid' &gt; trigger

Because the following occurs:

event_trigger_write() {
  trigger_process_regex() {
    event_hist_trigger_parse() {

      data = event_trigger_alloc(..);

      event_trigger_register(.., data) {
        cmd_ops-&gt;reg(.., data, ..) [hist_register_trigger()] {
          data-&gt;ops-&gt;init() [event_hist_trigger_init()] {
            save_named_trigger(name, data) {
              list_add(&amp;data-&gt;named_list, &amp;named_triggers);
            }
          }
        }
      }

      ret = create_actions(); (return -EINVAL)
      if (ret)
        goto out_unreg;
[..]
      ret = hist_trigger_enable(data, ...) {
        list_add_tail_rcu(&amp;data-&gt;list, &amp;file-&gt;triggers); &lt;&lt;&lt;---- SKIPPED!!! (this is important!)
[..]
 out_unreg:
      event_hist_unregister(.., data) {
        cmd_ops-&gt;unreg(.., data, ..) [hist_unregister_trigger()] {
          list_for_each_entry(iter, &amp;file-&gt;triggers, list) {
            if (!hist_trigger_match(data, iter, named_data, false))   &lt;- never matches
                continue;
            [..]
            test = iter;
          }
          if (test &amp;&amp; test-&gt;ops-&gt;free) &lt;&lt;&lt;-- test is NULL

            test-&gt;ops-&gt;free(test) [event_hist_trigger_free()] {
              [..]
              if (data-&gt;name)
                del_named_trigger(data) {
                  list_del(&amp;data-&gt;named_list);  &lt;&lt;&lt;&lt;-- NEVER gets removed!
                }
              }
           }
         }

         [..]
         kfree(data); &lt;&lt;&lt;-- frees item but it is still on list

The next time a hist with name is registered, it causes an u-a-f bug and
the kernel can crash.

Move the code around such that if event_trigger_register() succeeds, the
next thing called is hist_trigger_enable() which adds it to the list.

A bunch of actions is called if get_named_trigger_data() returns false.
But that doesn't need to be called after event_trigger_register(), so it
can be moved up, allowing event_trigger_register() to be called just
before hist_trigger_enable() keeping them together and allowing the
file-&gt;triggers to be properly populated.</Note>
    </Notes>
    <CVE>CVE-2025-21899</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/bnxt_re: Add sanity checks on rdev validity

There is a possibility that ulp_irq_stop and ulp_irq_start
callbacks will be called when the device is in detached state.
This can cause a crash due to NULL pointer dereference as
the rdev is already freed.</Note>
    </Notes>
    <CVE>CVE-2025-21901</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/imagination: avoid deadlock on fence release

Do scheduler queue fence release processing on a workqueue, rather
than in the release function itself.

Fixes deadlock issues such as the following:

[  607.400437] ============================================
[  607.405755] WARNING: possible recursive locking detected
[  607.415500] --------------------------------------------
[  607.420817] weston:zfq0/24149 is trying to acquire lock:
[  607.426131] ffff000017d041a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: pvr_gem_object_vunmap+0x40/0xc0 [powervr]
[  607.436728]
               but task is already holding lock:
[  607.442554] ffff000017d105a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: dma_buf_ioctl+0x250/0x554
[  607.451727]
               other info that might help us debug this:
[  607.458245]  Possible unsafe locking scenario:

[  607.464155]        CPU0
[  607.466601]        ----
[  607.469044]   lock(reservation_ww_class_mutex);
[  607.473584]   lock(reservation_ww_class_mutex);
[  607.478114]
                *** DEADLOCK ***</Note>
    </Notes>
    <CVE>CVE-2025-21911</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vlan: enforce underlying device type

Currently, VLAN devices can be created on top of non-ethernet devices.

Besides the fact that it doesn't make much sense, this also causes a
bug which leaks the address of a kernel function to usermode.

When creating a VLAN device, we initialize GARP (garp_init_applicant)
and MRP (mrp_init_applicant) for the underlying device.

As part of the initialization process, we add the multicast address of
each applicant to the underlying device, by calling dev_mc_add.

__dev_mc_add uses dev-&gt;addr_len to determine the length of the new
multicast address.

This causes an out-of-bounds read if dev-&gt;addr_len is greater than 6,
since the multicast addresses provided by GARP and MRP are only 6
bytes long.

This behaviour can be reproduced using the following commands:

ip tunnel add gretest mode ip6gre local ::1 remote ::2 dev lo
ip l set up dev gretest
ip link add link gretest name vlantest type vlan id 100

Then, the following command will display the address of garp_pdu_rcv:

ip maddr show | grep 01:80:c2:00:00:21

Fix the bug by enforcing the type of the underlying device during VLAN
device initialization.</Note>
    </Notes>
    <CVE>CVE-2025-21920</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mptcp: fix 'scheduling while atomic' in mptcp_pm_nl_append_new_local_addr

If multiple connection requests attempt to create an implicit mptcp
endpoint in parallel, more than one caller may end up in
mptcp_pm_nl_append_new_local_addr because none found the address in
local_addr_list during their call to mptcp_pm_nl_get_local_id.  In this
case, the concurrent new_local_addr calls may delete the address entry
created by the previous caller.  These deletes use synchronize_rcu, but
this is not permitted in some of the contexts where this function may be
called.  During packet recv, the caller may be in a rcu read critical
section and have preemption disabled.

An example stack:

   BUG: scheduling while atomic: swapper/2/0/0x00000302

   Call Trace:
   &lt;IRQ&gt;
   dump_stack_lvl (lib/dump_stack.c:117 (discriminator 1))
   dump_stack (lib/dump_stack.c:124)
   __schedule_bug (kernel/sched/core.c:5943)
   schedule_debug.constprop.0 (arch/x86/include/asm/preempt.h:33 kernel/sched/core.c:5970)
   __schedule (arch/x86/include/asm/jump_label.h:27 include/linux/jump_label.h:207 kernel/sched/features.h:29 kernel/sched/core.c:6621)
   schedule (arch/x86/include/asm/preempt.h:84 kernel/sched/core.c:6804 kernel/sched/core.c:6818)
   schedule_timeout (kernel/time/timer.c:2160)
   wait_for_completion (kernel/sched/completion.c:96 kernel/sched/completion.c:116 kernel/sched/completion.c:127 kernel/sched/completion.c:148)
   __wait_rcu_gp (include/linux/rcupdate.h:311 kernel/rcu/update.c:444)
   synchronize_rcu (kernel/rcu/tree.c:3609)
   mptcp_pm_nl_append_new_local_addr (net/mptcp/pm_netlink.c:966 net/mptcp/pm_netlink.c:1061)
   mptcp_pm_nl_get_local_id (net/mptcp/pm_netlink.c:1164)
   mptcp_pm_get_local_id (net/mptcp/pm.c:420)
   subflow_check_req (net/mptcp/subflow.c:98 net/mptcp/subflow.c:213)
   subflow_v4_route_req (net/mptcp/subflow.c:305)
   tcp_conn_request (net/ipv4/tcp_input.c:7216)
   subflow_v4_conn_request (net/mptcp/subflow.c:651)
   tcp_rcv_state_process (net/ipv4/tcp_input.c:6709)
   tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1934)
   tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2334)
   ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205 (discriminator 1))
   ip_local_deliver_finish (include/linux/rcupdate.h:813 net/ipv4/ip_input.c:234)
   ip_local_deliver (include/linux/netfilter.h:314 include/linux/netfilter.h:308 net/ipv4/ip_input.c:254)
   ip_sublist_rcv_finish (include/net/dst.h:461 net/ipv4/ip_input.c:580)
   ip_sublist_rcv (net/ipv4/ip_input.c:640)
   ip_list_rcv (net/ipv4/ip_input.c:675)
   __netif_receive_skb_list_core (net/core/dev.c:5583 net/core/dev.c:5631)
   netif_receive_skb_list_internal (net/core/dev.c:5685 net/core/dev.c:5774)
   napi_complete_done (include/linux/list.h:37 include/net/gro.h:449 include/net/gro.h:444 net/core/dev.c:6114)
   igb_poll (drivers/net/ethernet/intel/igb/igb_main.c:8244) igb
   __napi_poll (net/core/dev.c:6582)
   net_rx_action (net/core/dev.c:6653 net/core/dev.c:6787)
   handle_softirqs (kernel/softirq.c:553)
   __irq_exit_rcu (kernel/softirq.c:588 kernel/softirq.c:427 kernel/softirq.c:636)
   irq_exit_rcu (kernel/softirq.c:651)
   common_interrupt (arch/x86/kernel/irq.c:247 (discriminator 14))
   &lt;/IRQ&gt;

This problem seems particularly prevalent if the user advertises an
endpoint that has a different external vs internal address.  In the case
where the external address is advertised and multiple connections
already exist, multiple subflow SYNs arrive in parallel which tends to
trigger the race during creation of the first local_addr_list entries
which have the internal address instead.

Fix by skipping the replacement of an existing implicit local address if
called via mptcp_pm_nl_get_local_id.</Note>
    </Notes>
    <CVE>CVE-2025-21938</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/xe/hmm: Don't dereference struct page pointers without notifier lock

The pnfs that we obtain from hmm_range_fault() point to pages that
we don't have a reference on, and the guarantee that they are still
in the cpu page-tables is that the notifier lock must be held and the
notifier seqno is still valid.

So while building the sg table and marking the pages accesses / dirty
we need to hold this lock with a validated seqno.

However, the lock is reclaim tainted which makes
sg_alloc_table_from_pages_segment() unusable, since it internally
allocates memory.

Instead build the sg-table manually. For the non-iommu case
this might lead to fewer coalesces, but if that's a problem it can
be fixed up later in the resource cursor code. For the iommu case,
the whole sg-table may still be coalesced to a single contigous
device va region.

This avoids marking pages that we don't own dirty and accessed, and
it also avoid dereferencing struct pages that we don't own.

v2:
- Use assert to check whether hmm pfns are valid (Matthew Auld)
- Take into account that large pages may cross range boundaries
  (Matthew Auld)

v3:
- Don't unnecessarily check for a non-freed sg-table. (Matthew Auld)
- Add a missing up_read() in an error path. (Matthew Auld)

(cherry picked from commit ea3e66d280ce2576664a862693d1da8fd324c317)</Note>
    </Notes>
    <CVE>CVE-2025-21939</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amdkfd: Fix NULL Pointer Dereference in KFD queue

Through KFD IOCTL Fuzzing we encountered a NULL pointer derefrence
when calling kfd_queue_acquire_buffers.

(cherry picked from commit 049e5bf3c8406f87c3d8e1958e0a16804fa1d530)</Note>
    </Notes>
    <CVE>CVE-2025-21940</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: init return value in amdgpu_ttm_clear_buffer

Otherwise an uninitialized value can be returned if
amdgpu_res_cleared returns true for all regions.

Possibly closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3812

(cherry picked from commit 7c62aacc3b452f73a1284198c81551035fac6d71)</Note>
    </Notes>
    <CVE>CVE-2025-21987</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

xsk: fix an integer overflow in xp_create_and_assign_umem()

Since the i and pool-&gt;chunk_size variables are of type 'u32',
their product can wrap around and then be cast to 'u64'.
This can lead to two different XDP buffers pointing to the same
memory area.

Found by InfoTeCS on behalf of Linux Verification Center
(linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2025-21997</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ipv6: Fix memleak of nhc_pcpu_rth_output in fib_check_nh_v6_gw().

fib_check_nh_v6_gw() expects that fib6_nh_init() cleans up everything
when it fails.

Commit 7dd73168e273 ("ipv6: Always allocate pcpu memory in a fib6_nh")
moved fib_nh_common_init() before alloc_percpu_gfp() within fib6_nh_init()
but forgot to add cleanup for fib6_nh-&gt;nh_common.nhc_pcpu_rth_output in
case it fails to allocate fib6_nh-&gt;rt6i_pcpu, resulting in memleak.

Let's call fib_nh_common_release() and clear nhc_pcpu_rth_output in the
error path.

Note that we can remove the fib6_nh_release() call in nh_create_ipv6()
later in net-next.git.</Note>
    </Notes>
    <CVE>CVE-2025-22005</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: xhci: Don't skip on Stopped - Length Invalid

Up until commit d56b0b2ab142 ("usb: xhci: ensure skipped isoc TDs are
returned when isoc ring is stopped") in v6.11, the driver didn't skip
missed isochronous TDs when handling Stoppend and Stopped - Length
Invalid events. Instead, it erroneously cleared the skip flag, which
would cause the ring to get stuck, as future events won't match the
missed TD which is never removed from the queue until it's cancelled.

This buggy logic seems to have been in place substantially unchanged
since the 3.x series over 10 years ago, which probably speaks first
and foremost about relative rarity of this case in normal usage, but
by the spec I see no reason why it shouldn't be possible.

After d56b0b2ab142, TDs are immediately skipped when handling those
Stopped events. This poses a potential problem in case of Stopped -
Length Invalid, which occurs either on completed TDs (likely already
given back) or Link and No-Op TRBs. Such event won't be recognized
as matching any TD (unless it's the rare Link TRB inside a TD) and
will result in skipping all pending TDs, giving them back possibly
before they are done, risking isoc data loss and maybe UAF by HW.

As a compromise, don't skip and don't clear the skip flag on this
kind of event. Then the next event will skip missed TDs. A downside
of not handling Stopped - Length Invalid on a Link inside a TD is
that if the TD is cancelled, its actual length will not be updated
to account for TRBs (silently) completed before the TD was stopped.

I had no luck producing this sequence of completion events so there
is no compelling demonstration of any resulting disaster. It may be
a very rare, obscure condition. The sole motivation for this patch
is that if such unlikely event does occur, I'd rather risk reporting
a cancelled partially done isoc frame as empty than gamble with UAF.

This will be fixed more properly by looking at Stopped event's TRB
pointer when making skipping decisions, but such rework is unlikely
to be backported to v6.12, which will stay around for a few years.</Note>
    </Notes>
    <CVE>CVE-2025-22023</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tracing: Fix use-after-free in print_graph_function_flags during tracer switching

Kairui reported a UAF issue in print_graph_function_flags() during
ftrace stress testing [1]. This issue can be reproduced if puting a
'mdelay(10)' after 'mutex_unlock(&amp;trace_types_lock)' in s_start(),
and executing the following script:

  $ echo function_graph &gt; current_tracer
  $ cat trace &gt; /dev/null &amp;
  $ sleep 5  # Ensure the 'cat' reaches the 'mdelay(10)' point
  $ echo timerlat &gt; current_tracer

The root cause lies in the two calls to print_graph_function_flags
within print_trace_line during each s_show():

  * One through 'iter-&gt;trace-&gt;print_line()';
  * Another through 'event-&gt;funcs-&gt;trace()', which is hidden in
    print_trace_fmt() before print_trace_line returns.

Tracer switching only updates the former, while the latter continues
to use the print_line function of the old tracer, which in the script
above is print_graph_function_flags.

Moreover, when switching from the 'function_graph' tracer to the
'timerlat' tracer, s_start only calls graph_trace_close of the
'function_graph' tracer to free 'iter-&gt;private', but does not set
it to NULL. This provides an opportunity for 'event-&gt;funcs-&gt;trace()'
to use an invalid 'iter-&gt;private'.

To fix this issue, set 'iter-&gt;private' to NULL immediately after
freeing it in graph_trace_close(), ensuring that an invalid pointer
is not passed to other tracers. Additionally, clean up the unnecessary
'iter-&gt;private = NULL' during each 'cat trace' when using wakeup and
irqsoff tracers.

 [1] https://lore.kernel.org/all/20231112150030.84609-1-ryncsn@gmail.com/</Note>
    </Notes>
    <CVE>CVE-2025-22035</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ASoC: imx-card: Add NULL check in imx_card_probe()

devm_kasprintf() returns NULL when memory allocation fails. Currently,
imx_card_probe() does not check for this case, which results in a NULL
pointer dereference.

Add NULL check after devm_kasprintf() to prevent this issue.</Note>
    </Notes>
    <CVE>CVE-2025-22066</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint

If vhost_scsi_set_endpoint is called multiple times without a
vhost_scsi_clear_endpoint between them, we can hit multiple bugs
found by Haoran Zhang:

1. Use-after-free when no tpgs are found:

This fixes a use after free that occurs when vhost_scsi_set_endpoint is
called more than once and calls after the first call do not find any
tpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first finds
tpgs to add to the vs_tpg array match=true, so we will do:

vhost_vq_set_backend(vq, vs_tpg);
...

kfree(vs-&gt;vs_tpg);
vs-&gt;vs_tpg = vs_tpg;

If vhost_scsi_set_endpoint is called again and no tpgs are found
match=false so we skip the vhost_vq_set_backend call leaving the
pointer to the vs_tpg we then free via:

kfree(vs-&gt;vs_tpg);
vs-&gt;vs_tpg = vs_tpg;

If a scsi request is then sent we do:

vhost_scsi_handle_vq -&gt; vhost_scsi_get_req -&gt; vhost_vq_get_backend

which sees the vs_tpg we just did a kfree on.

2. Tpg dir removal hang:

This patch fixes an issue where we cannot remove a LIO/target layer
tpg (and structs above it like the target) dir due to the refcount
dropping to -1.

The problem is that if vhost_scsi_set_endpoint detects a tpg is already
in the vs-&gt;vs_tpg array or if the tpg has been removed so
target_depend_item fails, the undepend goto handler will do
target_undepend_item on all tpgs in the vs_tpg array dropping their
refcount to 0. At this time vs_tpg contains both the tpgs we have added
in the current vhost_scsi_set_endpoint call as well as tpgs we added in
previous calls which are also in vs-&gt;vs_tpg.

Later, when vhost_scsi_clear_endpoint runs it will do
target_undepend_item on all the tpgs in the vs-&gt;vs_tpg which will drop
their refcount to -1. Userspace will then not be able to remove the tpg
and will hang when it tries to do rmdir on the tpg dir.

3. Tpg leak:

This fixes a bug where we can leak tpgs and cause them to be
un-removable because the target name is overwritten when
vhost_scsi_set_endpoint is called multiple times but with different
target names.

The bug occurs if a user has called VHOST_SCSI_SET_ENDPOINT and setup
a vhost-scsi device to target/tpg mapping, then calls
VHOST_SCSI_SET_ENDPOINT again with a new target name that has tpgs we
haven't seen before (target1 has tpg1 but target2 has tpg2). When this
happens we don't teardown the old target tpg mapping and just overwrite
the target name and the vs-&gt;vs_tpg array. Later when we do
vhost_scsi_clear_endpoint, we are passed in either target1 or target2's
name and we will only match that target's tpgs when we loop over the
vs-&gt;vs_tpg. We will then return from the function without doing
target_undepend_item on the tpgs.

Because of all these bugs, it looks like being able to call
vhost_scsi_set_endpoint multiple times was never supported. The major
user, QEMU, already has checks to prevent this use case. So to fix the
issues, this patch prevents vhost_scsi_set_endpoint from being called
if it's already successfully added tpgs. To add, remove or change the
tpg config or target name, you must do a vhost_scsi_clear_endpoint
first.</Note>
    </Notes>
    <CVE>CVE-2025-22083</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/core: Don't expose hw_counters outside of init net namespace

Commit 467f432a521a ("RDMA/core: Split port and device counter sysfs
attributes") accidentally almost exposed hw counters to non-init net
namespaces. It didn't expose them fully, as an attempt to read any of
those counters leads to a crash like this one:

[42021.807566] BUG: kernel NULL pointer dereference, address: 0000000000000028
[42021.814463] #PF: supervisor read access in kernel mode
[42021.819549] #PF: error_code(0x0000) - not-present page
[42021.824636] PGD 0 P4D 0
[42021.827145] Oops: 0000 [#1] SMP PTI
[42021.830598] CPU: 82 PID: 2843922 Comm: switchto-defaul Kdump: loaded Tainted: G S      W I        XXX
[42021.841697] Hardware name: XXX
[42021.849619] RIP: 0010:hw_stat_device_show+0x1e/0x40 [ib_core]
[42021.855362] Code: 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 49 89 d0 4c 8b 5e 20 48 8b 8f b8 04 00 00 48 81 c7 f0 fa ff ff &lt;48&gt; 8b 41 28 48 29 ce 48 83 c6 d0 48 c1 ee 04 69 d6 ab aa aa aa 48
[42021.873931] RSP: 0018:ffff97fe90f03da0 EFLAGS: 00010287
[42021.879108] RAX: ffff9406988a8c60 RBX: ffff940e1072d438 RCX: 0000000000000000
[42021.886169] RDX: ffff94085f1aa000 RSI: ffff93c6cbbdbcb0 RDI: ffff940c7517aef0
[42021.893230] RBP: ffff97fe90f03e70 R08: ffff94085f1aa000 R09: 0000000000000000
[42021.900294] R10: ffff94085f1aa000 R11: ffffffffc0775680 R12: ffffffff87ca2530
[42021.907355] R13: ffff940651602840 R14: ffff93c6cbbdbcb0 R15: ffff94085f1aa000
[42021.914418] FS:  00007fda1a3b9700(0000) GS:ffff94453fb80000(0000) knlGS:0000000000000000
[42021.922423] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[42021.928130] CR2: 0000000000000028 CR3: 00000042dcfb8003 CR4: 00000000003726f0
[42021.935194] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[42021.942257] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[42021.949324] Call Trace:
[42021.951756]  &lt;TASK&gt;
[42021.953842]  [&lt;ffffffff86c58674&gt;] ? show_regs+0x64/0x70
[42021.959030]  [&lt;ffffffff86c58468&gt;] ? __die+0x78/0xc0
[42021.963874]  [&lt;ffffffff86c9ef75&gt;] ? page_fault_oops+0x2b5/0x3b0
[42021.969749]  [&lt;ffffffff87674b92&gt;] ? exc_page_fault+0x1a2/0x3c0
[42021.975549]  [&lt;ffffffff87801326&gt;] ? asm_exc_page_fault+0x26/0x30
[42021.981517]  [&lt;ffffffffc0775680&gt;] ? __pfx_show_hw_stats+0x10/0x10 [ib_core]
[42021.988482]  [&lt;ffffffffc077564e&gt;] ? hw_stat_device_show+0x1e/0x40 [ib_core]
[42021.995438]  [&lt;ffffffff86ac7f8e&gt;] dev_attr_show+0x1e/0x50
[42022.000803]  [&lt;ffffffff86a3eeb1&gt;] sysfs_kf_seq_show+0x81/0xe0
[42022.006508]  [&lt;ffffffff86a11134&gt;] seq_read_iter+0xf4/0x410
[42022.011954]  [&lt;ffffffff869f4b2e&gt;] vfs_read+0x16e/0x2f0
[42022.017058]  [&lt;ffffffff869f50ee&gt;] ksys_read+0x6e/0xe0
[42022.022073]  [&lt;ffffffff8766f1ca&gt;] do_syscall_64+0x6a/0xa0
[42022.027441]  [&lt;ffffffff8780013b&gt;] entry_SYSCALL_64_after_hwframe+0x78/0xe2

The problem can be reproduced using the following steps:
  ip netns add foo
  ip netns exec foo bash
  cat /sys/class/infiniband/mlx4_0/hw_counters/*

The panic occurs because of casting the device pointer into an
ib_device pointer using container_of() in hw_stat_device_show() is
wrong and leads to a memory corruption.

However the real problem is that hw counters should never been exposed
outside of the non-init net namespace.

Fix this by saving the index of the corresponding attribute group
(it might be 1 or 2 depending on the presence of driver-specific
attributes) and zeroing the pointer to hw_counters group for compat
devices during the initialization.

With this fix applied hw_counters are not available in a non-init
net namespace:
  find /sys/class/infiniband/mlx4_0/ -name hw_counters
    /sys/class/infiniband/mlx4_0/ports/1/hw_counters
    /sys/class/infiniband/mlx4_0/ports/2/hw_counters
    /sys/class/infiniband/mlx4_0/hw_counters

  ip netns add foo
  ip netns exec foo bash
  find /sys/class/infiniband/mlx4_0/ -name hw_counters</Note>
    </Notes>
    <CVE>CVE-2025-22089</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

x86/mm/pat: Fix VM_PAT handling when fork() fails in copy_page_range()

If track_pfn_copy() fails, we already added the dst VMA to the maple
tree. As fork() fails, we'll cleanup the maple tree, and stumble over
the dst VMA for which we neither performed any reservation nor copied
any page tables.

Consequently untrack_pfn() will see VM_PAT and try obtaining the
PAT information from the page table -- which fails because the page
table was not copied.

The easiest fix would be to simply clear the VM_PAT flag of the dst VMA
if track_pfn_copy() fails. However, the whole thing is about "simply"
clearing the VM_PAT flag is shaky as well: if we passed track_pfn_copy()
and performed a reservation, but copying the page tables fails, we'll
simply clear the VM_PAT flag, not properly undoing the reservation ...
which is also wrong.

So let's fix it properly: set the VM_PAT flag only if the reservation
succeeded (leaving it clear initially), and undo the reservation if
anything goes wrong while copying the page tables: clearing the VM_PAT
flag after undoing the reservation.

Note that any copied page table entries will get zapped when the VMA will
get removed later, after copy_page_range() succeeded; as VM_PAT is not set
then, we won't try cleaning VM_PAT up once more and untrack_pfn() will be
happy. Note that leaving these page tables in place without a reservation
is not a problem, as we are aborting fork(); this process will never run.

A reproducer can trigger this usually at the first try:

  https://gitlab.com/davidhildenbrand/scratchspace/-/raw/main/reproducers/pat_fork.c

  WARNING: CPU: 26 PID: 11650 at arch/x86/mm/pat/memtype.c:983 get_pat_info+0xf6/0x110
  Modules linked in: ...
  CPU: 26 UID: 0 PID: 11650 Comm: repro3 Not tainted 6.12.0-rc5+ #92
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014
  RIP: 0010:get_pat_info+0xf6/0x110
  ...
  Call Trace:
   &lt;TASK&gt;
   ...
   untrack_pfn+0x52/0x110
   unmap_single_vma+0xa6/0xe0
   unmap_vmas+0x105/0x1f0
   exit_mmap+0xf6/0x460
   __mmput+0x4b/0x120
   copy_process+0x1bf6/0x2aa0
   kernel_clone+0xab/0x440
   __do_sys_clone+0x66/0x90
   do_syscall_64+0x95/0x180

Likely this case was missed in:

  d155df53f310 ("x86/mm/pat: clear VM_PAT if copy_p4d_range failed")

... and instead of undoing the reservation we simply cleared the VM_PAT flag.

Keep the documentation of these functions in include/linux/pgtable.h,
one place is more than sufficient -- we should clean that up for the other
functions like track_pfn_remap/untrack_pfn separately.</Note>
    </Notes>
    <CVE>CVE-2025-22090</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

PCI: brcmstb: Fix error path after a call to regulator_bulk_get()

If the regulator_bulk_get() returns an error and no regulators
are created, we need to set their number to zero.

If we don't do this and the PCIe link up fails, a call to the
regulator_bulk_free() will result in a kernel panic.

While at it, print the error value, as we cannot return an error
upwards as the kernel will WARN() on an error from add_bus().

[kwilczynski: commit log, use comma in the message to match style with
other similar messages]</Note>
    </Notes>
    <CVE>CVE-2025-22095</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: Remove RTNL dance for SIOCBRADDIF and SIOCBRDELIF.

SIOCBRDELIF is passed to dev_ioctl() first and later forwarded to
br_ioctl_call(), which causes unnecessary RTNL dance and the splat
below [0] under RTNL pressure.

Let's say Thread A is trying to detach a device from a bridge and
Thread B is trying to remove the bridge.

In dev_ioctl(), Thread A bumps the bridge device's refcnt by
netdev_hold() and releases RTNL because the following br_ioctl_call()
also re-acquires RTNL.

In the race window, Thread B could acquire RTNL and try to remove
the bridge device.  Then, rtnl_unlock() by Thread B will release RTNL
and wait for netdev_put() by Thread A.

Thread A, however, must hold RTNL after the unlock in dev_ifsioc(),
which may take long under RTNL pressure, resulting in the splat by
Thread B.

  Thread A (SIOCBRDELIF)           Thread B (SIOCBRDELBR)
  ----------------------           ----------------------
  sock_ioctl                       sock_ioctl
  `- sock_do_ioctl                 `- br_ioctl_call
     `- dev_ioctl                     `- br_ioctl_stub
        |- rtnl_lock                     |
        |- dev_ifsioc                    '
        '  |- dev = __dev_get_by_name(...)
           |- netdev_hold(dev, ...)      .
       /   |- rtnl_unlock  ------.       |
       |   |- br_ioctl_call       `---&gt;  |- rtnl_lock
  Race |   |  `- br_ioctl_stub           |- br_del_bridge
  Window   |     |                       |  |- dev = __dev_get_by_name(...)
       |   |     |  May take long        |  `- br_dev_delete(dev, ...)
       |   |     |  under RTNL pressure  |     `- unregister_netdevice_queue(dev, ...)
       |   |     |               |       `- rtnl_unlock
       \   |     |- rtnl_lock  &lt;-'          `- netdev_run_todo
           |     |- ...                        `- netdev_run_todo
           |     `- rtnl_unlock                   |- __rtnl_unlock
           |                                      |- netdev_wait_allrefs_any
           |- netdev_put(dev, ...)  &lt;----------------'
                                                Wait refcnt decrement
                                                and log splat below

To avoid blocking SIOCBRDELBR unnecessarily, let's not call
dev_ioctl() for SIOCBRADDIF and SIOCBRDELIF.

In the dev_ioctl() path, we do the following:

  1. Copy struct ifreq by get_user_ifreq in sock_do_ioctl()
  2. Check CAP_NET_ADMIN in dev_ioctl()
  3. Call dev_load() in dev_ioctl()
  4. Fetch the master dev from ifr.ifr_name in dev_ifsioc()

3. can be done by request_module() in br_ioctl_call(), so we move
1., 2., and 4. to br_ioctl_stub().

Note that 2. is also checked later in add_del_if(), but it's better
performed before RTNL.

SIOCBRADDIF and SIOCBRDELIF have been processed in dev_ioctl() since
the pre-git era, and there seems to be no specific reason to process
them there.

[0]:
unregister_netdevice: waiting for wpan3 to become free. Usage count = 2
ref_tracker: wpan3@ffff8880662d8608 has 1/1 users at
     __netdev_tracker_alloc include/linux/netdevice.h:4282 [inline]
     netdev_hold include/linux/netdevice.h:4311 [inline]
     dev_ifsioc+0xc6a/0x1160 net/core/dev_ioctl.c:624
     dev_ioctl+0x255/0x10c0 net/core/dev_ioctl.c:826
     sock_do_ioctl+0x1ca/0x260 net/socket.c:1213
     sock_ioctl+0x23a/0x6c0 net/socket.c:1318
     vfs_ioctl fs/ioctl.c:51 [inline]
     __do_sys_ioctl fs/ioctl.c:906 [inline]
     __se_sys_ioctl fs/ioctl.c:892 [inline]
     __x64_sys_ioctl+0x1a4/0x210 fs/ioctl.c:892
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0xcb/0x250 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f</Note>
    </Notes>
    <CVE>CVE-2025-22111</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ext4: avoid journaling sb update on error if journal is destroying

Presently we always BUG_ON if trying to start a transaction on a journal marked
with JBD2_UNMOUNT, since this should never happen. However, while ltp running
stress tests, it was observed that in case of some error handling paths, it is
possible for update_super_work to start a transaction after the journal is
destroyed eg:

(umount)
ext4_kill_sb
  kill_block_super
    generic_shutdown_super
      sync_filesystem /* commits all txns */
      evict_inodes
        /* might start a new txn */
      ext4_put_super
	flush_work(&amp;sbi-&gt;s_sb_upd_work) /* flush the workqueue */
        jbd2_journal_destroy
          journal_kill_thread
            journal-&gt;j_flags |= JBD2_UNMOUNT;
          jbd2_journal_commit_transaction
            jbd2_journal_get_descriptor_buffer
              jbd2_journal_bmap
                ext4_journal_bmap
                  ext4_map_blocks
                    ...
                    ext4_inode_error
                      ext4_handle_error
                        schedule_work(&amp;sbi-&gt;s_sb_upd_work)

                                               /* work queue kicks in */
                                               update_super_work
                                                 jbd2_journal_start
                                                   start_this_handle
                                                     BUG_ON(journal-&gt;j_flags &amp;
                                                            JBD2_UNMOUNT)

Hence, introduce a new mount flag to indicate journal is destroying and only do
a journaled (and deferred) update of sb if this flag is not set. Otherwise, just
fallback to an un-journaled commit.

Further, in the journal destroy path, we have the following sequence:

  1. Set mount flag indicating journal is destroying
  2. force a commit and wait for it
  3. flush pending sb updates

This sequence is important as it ensures that, after this point, there is no sb
update that might be journaled so it is safe to update the sb outside the
journal. (To avoid race discussed in 2d01ddc86606)

Also, we don't need a similar check in ext4_grp_locked_error since it is only
called from mballoc and AFAICT it would be always valid to schedule work here.</Note>
    </Notes>
    <CVE>CVE-2025-22113</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: cfg80211: init wiphy_work before allocating rfkill fails

syzbort reported a uninitialize wiphy_work_lock in cfg80211_dev_free. [1]

After rfkill allocation fails, the wiphy release process will be performed,
which will cause cfg80211_dev_free to access the uninitialized wiphy_work
related data.

Move the initialization of wiphy_work to before rfkill initialization to
avoid this issue.

[1]
INFO: trying to register non-static key.
The code is fine but needs lockdep annotation, or maybe
you didn't initialize this object before use?
turning off the locking correctness validator.
CPU: 0 UID: 0 PID: 5935 Comm: syz-executor550 Not tainted 6.14.0-rc6-syzkaller-00103-g4003c9e78778 #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
 assign_lock_key kernel/locking/lockdep.c:983 [inline]
 register_lock_class+0xc39/0x1240 kernel/locking/lockdep.c:1297
 __lock_acquire+0x135/0x3c40 kernel/locking/lockdep.c:5103
 lock_acquire.part.0+0x11b/0x380 kernel/locking/lockdep.c:5851
 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
 _raw_spin_lock_irqsave+0x3a/0x60 kernel/locking/spinlock.c:162
 cfg80211_dev_free+0x30/0x3d0 net/wireless/core.c:1196
 device_release+0xa1/0x240 drivers/base/core.c:2568
 kobject_cleanup lib/kobject.c:689 [inline]
 kobject_release lib/kobject.c:720 [inline]
 kref_put include/linux/kref.h:65 [inline]
 kobject_put+0x1e4/0x5a0 lib/kobject.c:737
 put_device+0x1f/0x30 drivers/base/core.c:3774
 wiphy_free net/wireless/core.c:1224 [inline]
 wiphy_new_nm+0x1c1f/0x2160 net/wireless/core.c:562
 ieee80211_alloc_hw_nm+0x1b7a/0x2260 net/mac80211/main.c:835
 mac80211_hwsim_new_radio+0x1d6/0x54e0 drivers/net/wireless/virtual/mac80211_hwsim.c:5185
 hwsim_new_radio_nl+0xb42/0x12b0 drivers/net/wireless/virtual/mac80211_hwsim.c:6242
 genl_family_rcv_msg_doit+0x202/0x2f0 net/netlink/genetlink.c:1115
 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]
 genl_rcv_msg+0x565/0x800 net/netlink/genetlink.c:1210
 netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2533
 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219
 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline]
 netlink_unicast+0x53c/0x7f0 net/netlink/af_netlink.c:1338
 netlink_sendmsg+0x8b8/0xd70 net/netlink/af_netlink.c:1882
 sock_sendmsg_nosec net/socket.c:718 [inline]
 __sock_sendmsg net/socket.c:733 [inline]
 ____sys_sendmsg+0xaaf/0xc90 net/socket.c:2573
 ___sys_sendmsg+0x135/0x1e0 net/socket.c:2627
 __sys_sendmsg+0x16e/0x220 net/socket.c:2659
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83

Close: https://syzkaller.appspot.com/bug?extid=aaf0488c83d1d5f4f029</Note>
    </Notes>
    <CVE>CVE-2025-22119</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ext4: goto right label 'out_mmap_sem' in ext4_setattr()

Otherwise, if ext4_inode_attach_jinode() fails, a hung task will
happen because filemap_invalidate_unlock() isn't called to unlock
mapping-&gt;invalidate_lock. Like this:

EXT4-fs error (device sda) in ext4_setattr:5557: Out of memory
INFO: task fsstress:374 blocked for more than 122 seconds.
      Not tainted 6.14.0-rc1-next-20250206-xfstests-dirty #726
"echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:fsstress state:D stack:0     pid:374   tgid:374   ppid:373
                                  task_flags:0x440140 flags:0x00000000
Call Trace:
 &lt;TASK&gt;
 __schedule+0x2c9/0x7f0
 schedule+0x27/0xa0
 schedule_preempt_disabled+0x15/0x30
 rwsem_down_read_slowpath+0x278/0x4c0
 down_read+0x59/0xb0
 page_cache_ra_unbounded+0x65/0x1b0
 filemap_get_pages+0x124/0x3e0
 filemap_read+0x114/0x3d0
 vfs_read+0x297/0x360
 ksys_read+0x6c/0xe0
 do_syscall_64+0x4b/0x110
 entry_SYSCALL_64_after_hwframe+0x76/0x7e</Note>
    </Notes>
    <CVE>CVE-2025-22120</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

md/md-bitmap: fix wrong bitmap_limit for clustermd when write sb

In clustermd, separate write-intent-bitmaps are used for each cluster
node:

0                    4k                     8k                    12k
-------------------------------------------------------------------
| idle                | md super            | bm super [0] + bits |
| bm bits[0, contd]   | bm super[1] + bits  | bm bits[1, contd]   |
| bm super[2] + bits  | bm bits [2, contd]  | bm super[3] + bits  |
| bm bits [3, contd]  |                     |                     |

So in node 1, pg_index in __write_sb_page() could equal to
bitmap-&gt;storage.file_pages. Then bitmap_limit will be calculated to
0. md_super_write() will be called with 0 size.
That means the first 4k sb area of node 1 will never be updated
through filemap_write_page().
This bug causes hang of mdadm/clustermd_tests/01r1_Grow_resize.

Here use (pg_index % bitmap-&gt;storage.file_pages) to make calculation
of bitmap_limit correct.</Note>
    </Notes>
    <CVE>CVE-2025-22124</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Minion event bus authorization bypass. An attacker with access to a minion key can craft a message which may be able to execute a job on other minions (&gt;= 3007.0).</Note>
    </Notes>
    <CVE>CVE-2025-22236</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">An attacker with access to a minion key can exploit the 'on demand' pillar functionality with a specially crafted git url which could cause and arbitrary command to be run on the master with the same privileges as the master process.</Note>
    </Notes>
    <CVE>CVE-2025-22237</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Directory traversal attack in minion file cache creation. The master's default cache is vulnerable to a directory traversal attack. Which could be leveraged to write or overwrite 'cache' files outside of the cache directory.</Note>
    </Notes>
    <CVE>CVE-2025-22238</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Arbitrary event injection on Salt Master. The master's "_minion_event" method can be used by and authorized minion to send arbitrary events onto the master's event bus.</Note>
    </Notes>
    <CVE>CVE-2025-22239</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Arbitrary directory creation or file deletion. In the find_file method of the GitFS class, a path is created using os.path.join using unvalidated input from the “tgt_env” variable. This can be exploited by an attacker to delete any file on the Master's process has permissions to.</Note>
    </Notes>
    <CVE>CVE-2025-22240</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">File contents overwrite the VirtKey class is called when “on-demand pillar” data is requested and uses un-validated input to create paths to the “pki directory”. The functionality is used to auto-accept Minion authentication keys based on a pre-placed “authorization file” at a specific location and is present in the default configuration.</Note>
    </Notes>
    <CVE>CVE-2025-22241</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Worker process denial of service through file read operation. .A vulnerability exists in the Master's “pub_ret” method which is exposed to all minions. The un-sanitized input value “jid” is used to construct a path which is then opened for reading. An attacker could exploit this vulnerabilities by attempting to read from a filename that will not return any data, e.g. by targeting a pipe node on the proc file system.</Note>
    </Notes>
    <CVE>CVE-2025-22242</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">An attacker can pass a malicious malformed token which causes unexpected memory to be consumed during parsing.</Note>
    </Notes>
    <CVE>CVE-2025-22868</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">SSH servers which implement file transfer protocols are vulnerable to a denial of service attack from clients which complete the key exchange slowly, or not at all, causing pending content to be read into memory, but never transmitted.</Note>
    </Notes>
    <CVE>CVE-2025-22869</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">The tokenizer incorrectly interprets tags with unquoted attribute values that end with a solidus character (/) as self-closing. When directly using Tokenizer, this can result in such tags incorrectly being marked as self-closing, and when using the Parse functions, this can result in content following such tags as being placed in the wrong scope during DOM construction, but only when tags are in foreign content (e.g. &lt;math&gt;, &lt;svg&gt;, etc contexts).</Note>
    </Notes>
    <CVE>CVE-2025-22872</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

KVM: x86: Acquire SRCU in KVM_GET_MP_STATE to protect guest memory accesses

Acquire a lock on kvm-&gt;srcu when userspace is getting MP state to handle a
rather extreme edge case where "accepting" APIC events, i.e. processing
pending INIT or SIPI, can trigger accesses to guest memory.  If the vCPU
is in L2 with INIT *and* a TRIPLE_FAULT request pending, then getting MP
state will trigger a nested VM-Exit by way of -&gt;check_nested_events(), and
emuating the nested VM-Exit can access guest memory.

The splat was originally hit by syzkaller on a Google-internal kernel, and
reproduced on an upstream kernel by hacking the triple_fault_event_test
selftest to stuff a pending INIT, store an MSR on VM-Exit (to generate a
memory access on VMX), and do vcpu_mp_state_get() to trigger the scenario.

  =============================
  WARNING: suspicious RCU usage
  6.14.0-rc3-b112d356288b-vmx/pi_lockdep_false_pos-lock #3 Not tainted
  -----------------------------
  include/linux/kvm_host.h:1058 suspicious rcu_dereference_check() usage!

  other info that might help us debug this:

  rcu_scheduler_active = 2, debug_locks = 1
  1 lock held by triple_fault_ev/1256:
   #0: ffff88810df5a330 (&amp;vcpu-&gt;mutex){+.+.}-{4:4}, at: kvm_vcpu_ioctl+0x8b/0x9a0 [kvm]

  stack backtrace:
  CPU: 11 UID: 1000 PID: 1256 Comm: triple_fault_ev Not tainted 6.14.0-rc3-b112d356288b-vmx #3
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
  Call Trace:
   &lt;TASK&gt;
   dump_stack_lvl+0x7f/0x90
   lockdep_rcu_suspicious+0x144/0x190
   kvm_vcpu_gfn_to_memslot+0x156/0x180 [kvm]
   kvm_vcpu_read_guest+0x3e/0x90 [kvm]
   read_and_check_msr_entry+0x2e/0x180 [kvm_intel]
   __nested_vmx_vmexit+0x550/0xde0 [kvm_intel]
   kvm_check_nested_events+0x1b/0x30 [kvm]
   kvm_apic_accept_events+0x33/0x100 [kvm]
   kvm_arch_vcpu_ioctl_get_mpstate+0x30/0x1d0 [kvm]
   kvm_vcpu_ioctl+0x33e/0x9a0 [kvm]
   __x64_sys_ioctl+0x8b/0xb0
   do_syscall_64+0x6c/0x170
   entry_SYSCALL_64_after_hwframe+0x4b/0x53
   &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2025-23141</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sctp: detect and prevent references to a freed transport in sendmsg

sctp_sendmsg() re-uses associations and transports when possible by
doing a lookup based on the socket endpoint and the message destination
address, and then sctp_sendmsg_to_asoc() sets the selected transport in
all the message chunks to be sent.

There's a possible race condition if another thread triggers the removal
of that selected transport, for instance, by explicitly unbinding an
address with setsockopt(SCTP_SOCKOPT_BINDX_REM), after the chunks have
been set up and before the message is sent. This can happen if the send
buffer is full, during the period when the sender thread temporarily
releases the socket lock in sctp_wait_for_sndbuf().

This causes the access to the transport data in
sctp_outq_select_transport(), when the association outqueue is flushed,
to result in a use-after-free read.

This change avoids this scenario by having sctp_transport_free() signal
the freeing of the transport, tagging it as "dead". In order to do this,
the patch restores the "dead" bit in struct sctp_transport, which was
removed in
commit 47faa1e4c50e ("sctp: remove the dead field of sctp_transport").

Then, in the scenario where the sender thread has released the socket
lock in sctp_wait_for_sndbuf(), the bit is checked again after
re-acquiring the socket lock to detect the deletion. This is done while
holding a reference to the transport to prevent it from being freed in
the process.

If the transport was deleted while the socket lock was relinquished,
sctp_sendmsg_to_asoc() will return -EAGAIN to let userspace retry the
send.

The bug was found by a private syzbot instance (see the error report [1]
and the C reproducer that triggers it [2]).</Note>
    </Notes>
    <CVE>CVE-2025-23142</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

backlight: led_bl: Hold led_access lock when calling led_sysfs_disable()

Lockdep detects the following issue on led-backlight removal:
  [  142.315935] ------------[ cut here ]------------
  [  142.315954] WARNING: CPU: 2 PID: 292 at drivers/leds/led-core.c:455 led_sysfs_enable+0x54/0x80
  ...
  [  142.500725] Call trace:
  [  142.503176]  led_sysfs_enable+0x54/0x80 (P)
  [  142.507370]  led_bl_remove+0x80/0xa8 [led_bl]
  [  142.511742]  platform_remove+0x30/0x58
  [  142.515501]  device_remove+0x54/0x90
  ...

Indeed, led_sysfs_enable() has to be called with the led_access
lock held.

Hold the lock when calling led_sysfs_disable().</Note>
    </Notes>
    <CVE>CVE-2025-23144</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mfd: ene-kb3930: Fix a potential NULL pointer dereference

The off_gpios could be NULL. Add missing check in the kb3930_probe().
This is similar to the issue fixed in commit b1ba8bcb2d1f
("backlight: hx8357: Fix potential NULL pointer dereference").

This was detected by our static analysis tool.</Note>
    </Notes>
    <CVE>CVE-2025-23146</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

i3c: Add NULL pointer check in i3c_master_queue_ibi()

The I3C master driver may receive an IBI from a target device that has not
been probed yet. In such cases, the master calls `i3c_master_queue_ibi()`
to queue an IBI work task, leading to "Unable to handle kernel read from
unreadable memory" and resulting in a kernel panic.

Typical IBI handling flow:
1. The I3C master scans target devices and probes their respective drivers.
2. The target device driver calls `i3c_device_request_ibi()` to enable IBI
   and assigns `dev-&gt;ibi = ibi`.
3. The I3C master receives an IBI from the target device and calls
   `i3c_master_queue_ibi()` to queue the target device driver's IBI
   handler task.

However, since target device events are asynchronous to the I3C probe
sequence, step 3 may occur before step 2, causing `dev-&gt;ibi` to be `NULL`,
leading to a kernel panic.

Add a NULL pointer check in `i3c_master_queue_ibi()` to prevent accessing
an uninitialized `dev-&gt;ibi`, ensuring stability.</Note>
    </Notes>
    <CVE>CVE-2025-23147</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

soc: samsung: exynos-chipid: Add NULL pointer check in exynos_chipid_probe()

soc_dev_attr-&gt;revision could be NULL, thus,
a pointer check is added to prevent potential NULL pointer dereference.
This is similar to the fix in commit 3027e7b15b02
("ice: Fix some null pointer dereference issues in ice_ptp.c").

This issue is found by our static analysis tool.</Note>
    </Notes>
    <CVE>CVE-2025-23148</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tpm: do not start chip while suspended

Checking TPM_CHIP_FLAG_SUSPENDED after the call to tpm_find_get_ops() can
lead to a spurious tpm_chip_start() call:

[35985.503771] i2c i2c-1: Transfer while suspended
[35985.503796] WARNING: CPU: 0 PID: 74 at drivers/i2c/i2c-core.h:56 __i2c_transfer+0xbe/0x810
[35985.503802] Modules linked in:
[35985.503808] CPU: 0 UID: 0 PID: 74 Comm: hwrng Tainted: G        W          6.13.0-next-20250203-00005-gfa0cb5642941 #19 9c3d7f78192f2d38e32010ac9c90fdc71109ef6f
[35985.503814] Tainted: [W]=WARN
[35985.503817] Hardware name: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 10/26/2023
[35985.503819] RIP: 0010:__i2c_transfer+0xbe/0x810
[35985.503825] Code: 30 01 00 00 4c 89 f7 e8 40 fe d8 ff 48 8b 93 80 01 00 00 48 85 d2 75 03 49 8b 16 48 c7 c7 0a fb 7c a7 48 89 c6 e8 32 ad b0 fe &lt;0f&gt; 0b b8 94 ff ff ff e9 33 04 00 00 be 02 00 00 00 83 fd 02 0f 5
[35985.503828] RSP: 0018:ffffa106c0333d30 EFLAGS: 00010246
[35985.503833] RAX: 074ba64aa20f7000 RBX: ffff8aa4c1167120 RCX: 0000000000000000
[35985.503836] RDX: 0000000000000000 RSI: ffffffffa77ab0e4 RDI: 0000000000000001
[35985.503838] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000
[35985.503841] R10: 0000000000000004 R11: 00000001000313d5 R12: ffff8aa4c10f1820
[35985.503843] R13: ffff8aa4c0e243c0 R14: ffff8aa4c1167250 R15: ffff8aa4c1167120
[35985.503846] FS:  0000000000000000(0000) GS:ffff8aa4eae00000(0000) knlGS:0000000000000000
[35985.503849] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[35985.503852] CR2: 00007fab0aaf1000 CR3: 0000000105328000 CR4: 00000000003506f0
[35985.503855] Call Trace:
[35985.503859]  &lt;TASK&gt;
[35985.503863]  ? __warn+0xd4/0x260
[35985.503868]  ? __i2c_transfer+0xbe/0x810
[35985.503874]  ? report_bug+0xf3/0x210
[35985.503882]  ? handle_bug+0x63/0xb0
[35985.503887]  ? exc_invalid_op+0x16/0x50
[35985.503892]  ? asm_exc_invalid_op+0x16/0x20
[35985.503904]  ? __i2c_transfer+0xbe/0x810
[35985.503913]  tpm_cr50_i2c_transfer_message+0x24/0xf0
[35985.503920]  tpm_cr50_i2c_read+0x8e/0x120
[35985.503928]  tpm_cr50_request_locality+0x75/0x170
[35985.503935]  tpm_chip_start+0x116/0x160
[35985.503942]  tpm_try_get_ops+0x57/0x90
[35985.503948]  tpm_find_get_ops+0x26/0xd0
[35985.503955]  tpm_get_random+0x2d/0x80

Don't move forward with tpm_chip_start() inside tpm_try_get_ops(), unless
TPM_CHIP_FLAG_SUSPENDED is not set. tpm_find_get_ops() will return NULL in
such a failure case.</Note>
    </Notes>
    <CVE>CVE-2025-23149</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bus: mhi: host: Fix race between unprepare and queue_buf

A client driver may use mhi_unprepare_from_transfer() to quiesce
incoming data during the client driver's tear down. The client driver
might also be processing data at the same time, resulting in a call to
mhi_queue_buf() which will invoke mhi_gen_tre(). If mhi_gen_tre() runs
after mhi_unprepare_from_transfer() has torn down the channel, a panic
will occur due to an invalid dereference leading to a page fault.

This occurs because mhi_gen_tre() does not verify the channel state
after locking it. Fix this by having mhi_gen_tre() confirm the channel
state is valid, or return error to avoid accessing deinitialized data.

[mani: added stable tag]</Note>
    </Notes>
    <CVE>CVE-2025-23151</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: venus: hfi_parser: refactor hfi packet parsing logic

words_count denotes the number of words in total payload, while data
points to payload of various property within it. When words_count
reaches last word, data can access memory beyond the total payload. This
can lead to OOB access. With this patch, the utility api for handling
individual properties now returns the size of data consumed. Accordingly
remaining bytes are calculated before parsing the payload, thereby
eliminates the OOB access possibilities.</Note>
    </Notes>
    <CVE>CVE-2025-23156</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: venus: hfi_parser: add check to avoid out of bound access

There is a possibility that init_codecs is invoked multiple times during
manipulated payload from video firmware. In such case, if codecs_count
can get incremented to value more than MAX_CODEC_NUM, there can be OOB
access. Reset the count so that it always starts from beginning.</Note>
    </Notes>
    <CVE>CVE-2025-23157</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: venus: hfi: add check to handle incorrect queue size

qsize represents size of shared queued between driver and video
firmware. Firmware can modify this value to an invalid large value. In
such situation, empty_space will be bigger than the space actually
available. Since new_wr_idx is not checked, so the following code will
result in an OOB write.
...
qsize = qhdr-&gt;q_size

if (wr_idx &gt;= rd_idx)
 empty_space = qsize - (wr_idx - rd_idx)
....
if (new_wr_idx &lt; qsize) {
 memcpy(wr_ptr, packet, dwords &lt;&lt; 2) --&gt; OOB write

Add check to ensure qsize is within the allocated size while
reading and writing packets into the queue.</Note>
    </Notes>
    <CVE>CVE-2025-23158</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: venus: hfi: add a check to handle OOB in sfr region

sfr-&gt;buf_size is in shared memory and can be modified by malicious user.
OOB write is possible when the size is made higher than actual sfr data
buffer. Cap the size to allocated size for such cases.</Note>
    </Notes>
    <CVE>CVE-2025-23159</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

PCI: vmd: Make vmd_dev::cfg_lock a raw_spinlock_t type

The access to the PCI config space via pci_ops::read and pci_ops::write is
a low-level hardware access. The functions can be accessed with disabled
interrupts even on PREEMPT_RT. The pci_lock is a raw_spinlock_t for this
purpose.

A spinlock_t becomes a sleeping lock on PREEMPT_RT, so it cannot be
acquired with disabled interrupts. The vmd_dev::cfg_lock is accessed in
the same context as the pci_lock.

Make vmd_dev::cfg_lock a raw_spinlock_t type so it can be used with
interrupts disabled.

This was reported as:

  BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
  Call Trace:
   rt_spin_lock+0x4e/0x130
   vmd_pci_read+0x8d/0x100 [vmd]
   pci_user_read_config_byte+0x6f/0xe0
   pci_read_config+0xfe/0x290
   sysfs_kf_bin_read+0x68/0x90

[bigeasy: reword commit message]
Tested-off-by: Luis Claudio R. Goncalves &lt;lgoncalv@redhat.com&gt;
[kwilczynski: commit log]
[bhelgaas: add back report info from
https://lore.kernel.org/lkml/20241218115951.83062-1-ryotkkr98@gmail.com/]</Note>
    </Notes>
    <CVE>CVE-2025-23161</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/xe/vf: Don't try to trigger a full GT reset if VF

VFs don't have access to the GDRST(0x941c) register that driver
uses to reset a GT. Attempt to trigger a reset using debugfs:

 $ cat /sys/kernel/debug/dri/0000:00:02.1/gt0/force_reset

or due to a hang condition detected by the driver leads to:

 [ ] xe 0000:00:02.1: [drm] GT0: trying reset from force_reset [xe]
 [ ] xe 0000:00:02.1: [drm] GT0: reset queued
 [ ] xe 0000:00:02.1: [drm] GT0: reset started
 [ ] ------------[ cut here ]------------
 [ ] xe 0000:00:02.1: [drm] GT0: VF is trying to write 0x1 to an inaccessible register 0x941c+0x0
 [ ] WARNING: CPU: 3 PID: 3069 at drivers/gpu/drm/xe/xe_gt_sriov_vf.c:996 xe_gt_sriov_vf_write32+0xc6/0x580 [xe]
 [ ] RIP: 0010:xe_gt_sriov_vf_write32+0xc6/0x580 [xe]
 [ ] Call Trace:
 [ ]  &lt;TASK&gt;
 [ ]  ? show_regs+0x6c/0x80
 [ ]  ? __warn+0x93/0x1c0
 [ ]  ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe]
 [ ]  ? report_bug+0x182/0x1b0
 [ ]  ? handle_bug+0x6e/0xb0
 [ ]  ? exc_invalid_op+0x18/0x80
 [ ]  ? asm_exc_invalid_op+0x1b/0x20
 [ ]  ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe]
 [ ]  ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe]
 [ ]  ? xe_gt_tlb_invalidation_reset+0xef/0x110 [xe]
 [ ]  ? __mutex_unlock_slowpath+0x41/0x2e0
 [ ]  xe_mmio_write32+0x64/0x150 [xe]
 [ ]  do_gt_reset+0x2f/0xa0 [xe]
 [ ]  gt_reset_worker+0x14e/0x1e0 [xe]
 [ ]  process_one_work+0x21c/0x740
 [ ]  worker_thread+0x1db/0x3c0

Fix that by sending H2G VF_RESET(0x5507) action instead.</Note>
    </Notes>
    <CVE>CVE-2025-23162</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: vlan: don't propagate flags on open

With the device instance lock, there is now a possibility of a deadlock:

[    1.211455] ============================================
[    1.211571] WARNING: possible recursive locking detected
[    1.211687] 6.14.0-rc5-01215-g032756b4ca7a-dirty #5 Not tainted
[    1.211823] --------------------------------------------
[    1.211936] ip/184 is trying to acquire lock:
[    1.212032] ffff8881024a4c30 (&amp;dev-&gt;lock){+.+.}-{4:4}, at: dev_set_allmulti+0x4e/0xb0
[    1.212207]
[    1.212207] but task is already holding lock:
[    1.212332] ffff8881024a4c30 (&amp;dev-&gt;lock){+.+.}-{4:4}, at: dev_open+0x50/0xb0
[    1.212487]
[    1.212487] other info that might help us debug this:
[    1.212626]  Possible unsafe locking scenario:
[    1.212626]
[    1.212751]        CPU0
[    1.212815]        ----
[    1.212871]   lock(&amp;dev-&gt;lock);
[    1.212944]   lock(&amp;dev-&gt;lock);
[    1.213016]
[    1.213016]  *** DEADLOCK ***
[    1.213016]
[    1.213143]  May be due to missing lock nesting notation
[    1.213143]
[    1.213294] 3 locks held by ip/184:
[    1.213371]  #0: ffffffff838b53e0 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x1b/0xa0
[    1.213543]  #1: ffffffff84e5fc70 (&amp;net-&gt;rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x37/0xa0
[    1.213727]  #2: ffff8881024a4c30 (&amp;dev-&gt;lock){+.+.}-{4:4}, at: dev_open+0x50/0xb0
[    1.213895]
[    1.213895] stack backtrace:
[    1.213991] CPU: 0 UID: 0 PID: 184 Comm: ip Not tainted 6.14.0-rc5-01215-g032756b4ca7a-dirty #5
[    1.213993] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014
[    1.213994] Call Trace:
[    1.213995]  &lt;TASK&gt;
[    1.213996]  dump_stack_lvl+0x8e/0xd0
[    1.214000]  print_deadlock_bug+0x28b/0x2a0
[    1.214020]  lock_acquire+0xea/0x2a0
[    1.214027]  __mutex_lock+0xbf/0xd40
[    1.214038]  dev_set_allmulti+0x4e/0xb0 # real_dev-&gt;flags &amp; IFF_ALLMULTI
[    1.214040]  vlan_dev_open+0xa5/0x170 # ndo_open on vlandev
[    1.214042]  __dev_open+0x145/0x270
[    1.214046]  __dev_change_flags+0xb0/0x1e0
[    1.214051]  netif_change_flags+0x22/0x60 # IFF_UP vlandev
[    1.214053]  dev_change_flags+0x61/0xb0 # for each device in group from dev-&gt;vlan_info
[    1.214055]  vlan_device_event+0x766/0x7c0 # on netdevsim0
[    1.214058]  notifier_call_chain+0x78/0x120
[    1.214062]  netif_open+0x6d/0x90
[    1.214064]  dev_open+0x5b/0xb0 # locks netdevsim0
[    1.214066]  bond_enslave+0x64c/0x1230
[    1.214075]  do_set_master+0x175/0x1e0 # on netdevsim0
[    1.214077]  do_setlink+0x516/0x13b0
[    1.214094]  rtnl_newlink+0xaba/0xb80
[    1.214132]  rtnetlink_rcv_msg+0x440/0x490
[    1.214144]  netlink_rcv_skb+0xeb/0x120
[    1.214150]  netlink_unicast+0x1f9/0x320
[    1.214153]  netlink_sendmsg+0x346/0x3f0
[    1.214157]  __sock_sendmsg+0x86/0xb0
[    1.214160]  ____sys_sendmsg+0x1c8/0x220
[    1.214164]  ___sys_sendmsg+0x28f/0x2d0
[    1.214179]  __x64_sys_sendmsg+0xef/0x140
[    1.214184]  do_syscall_64+0xec/0x1d0
[    1.214190]  entry_SYSCALL_64_after_hwframe+0x77/0x7f
[    1.214191] RIP: 0033:0x7f2d1b4a7e56

Device setup:

     netdevsim0 (down)
     ^        ^
  bond        netdevsim1.100@netdevsim1 allmulticast=on (down)

When we enslave the lower device (netdevsim0) which has a vlan, we
propagate vlan's allmuti/promisc flags during ndo_open. This causes
(re)locking on of the real_dev.

Propagate allmulti/promisc on flags change, not on the open. There
is a slight semantics change that vlans that are down now propagate
the flags, but this seems unlikely to result in the real issues.

Reproducer:

  echo 0 1 &gt; /sys/bus/netdevsim/new_device

  dev_path=$(ls -d /sys/bus/netdevsim/devices/netdevsim0/net/*)
  dev=$(echo $dev_path | rev | cut -d/ -f1 | rev)

  ip link set dev $dev name netdevsim0
  ip link set dev netdevsim0 up

  ip link add link netdevsim0 name netdevsim0.100 type vlan id 100
  ip link set dev netdevsim0.100 allm
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-23163</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Certain instructions need intercepting and emulating by Xen.  In some
cases Xen emulates the instruction by replaying it, using an executable
stub.  Some instructions may raise an exception, which is supposed to be
handled gracefully.  Certain replayed instructions have additional logic
to set up and recover the changes to the arithmetic flags.

For replayed instructions where the flags recovery logic is used, the
metadata for exception handling was incorrect, preventing Xen from
handling the the exception gracefully, treating it as fatal instead.</Note>
    </Notes>
    <CVE>CVE-2025-27465</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">[This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]

There are multiple issues related to the handling and accessing of guest
memory pages in the viridian code:

 1. A NULL pointer dereference in the updating of the reference TSC area.
    This is CVE-2025-27466.

 2. A NULL pointer dereference by assuming the SIM page is mapped when
    a synthetic timer message has to be delivered.  This is
    CVE-2025-58142.

 3. A race in the mapping of the reference TSC page, where a guest can
    get Xen to free a page while still present in the guest physical to
    machine (p2m) page tables.  This is CVE-2025-58143.</Note>
    </Notes>
    <CVE>CVE-2025-27466</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">OpenSSL 3.0.0 through 3.3.2 on the PowerPC architecture is vulnerable to a Minerva attack, exploitable by measuring the time of signing of random messages using the EVP_DigestSign API, and then using the private key to extract the K value (nonce) from the signatures. Next, based on the bit size of the extracted nonce, one can compare the signing time of full-sized nonces to signatures that used smaller nonces, via statistical tests. There is a side-channel in the P-364 curve that allows private key extraction (also, there is a dependency between the bit size of K and the size of the side channel). NOTE: This CVE is disputed because the OpenSSL security policy explicitly notes that any side channels which require same physical system to be detected are outside of the threat model for the software. The timing signal is so small that it is infeasible to be detected without having the attacking process running on the same physical system.</Note>
    </Notes>
    <CVE>CVE-2025-27587</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Vim, a text editor, is vulnerable to potential data loss with zip.vim and special crafted zip files in versions prior to 9.1.1198. The impact is medium because a user must be made to view such an archive with Vim and then press 'x' on such a strange filename. The issue has been fixed as of Vim patch v9.1.1198.</Note>
    </Notes>
    <CVE>CVE-2025-29768</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In GnuPG before 2.5.5, if a user chooses to import a certificate with certain crafted subkey data that lacks a valid backsig or that has incorrect usage flags, the user loses the ability to verify signatures made from certain other signing keys, aka a "verification DoS."</Note>
    </Notes>
    <CVE>CVE-2025-30258</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Sudo before 1.9.17p1, when used with a sudoers file that specifies a host that is neither the current host nor ALL, allows listed users to execute commands on unintended machines.</Note>
    </Notes>
    <CVE>CVE-2025-32462</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Sudo before 1.9.17p1 allows local users to obtain root access because /etc/nsswitch.conf from a user-controlled directory is used with the --chroot option.</Note>
    </Notes>
    <CVE>CVE-2025-32463</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in GnuTLS. A double-free vulnerability exists in GnuTLS due to incorrect ownership handling in the export logic of Subject Alternative Name (SAN) entries containing an otherName. If the type-id OID is invalid or malformed, GnuTLS will call asn1_delete_structure() on an ASN.1 node it does not own, leading to a double-free condition when the parent function or caller later attempts to free the same structure.

This vulnerability can be triggered using only public GnuTLS APIs and may result in denial of service or memory corruption, depending on allocator behavior.</Note>
    </Notes>
    <CVE>CVE-2025-32988</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A heap-buffer-overread vulnerability was found in GnuTLS in how it handles the Certificate Transparency (CT) Signed Certificate Timestamp (SCT) extension during X.509 certificate parsing. This flaw allows a malicious user to create a certificate containing a malformed SCT extension (OID 1.3.6.1.4.1.11129.2.4.2) that contains sensitive data. This issue leads to the exposure of confidential information when GnuTLS verifies certificates from certain websites when the certificate (SCT) is not checked correctly.</Note>
    </Notes>
    <CVE>CVE-2025-32989</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A heap-buffer-overflow (off-by-one) flaw was found in the GnuTLS software in the template parsing logic within the certtool utility. When it reads certain settings from a template file, it allows an attacker to cause an out-of-bounds (OOB) NULL pointer write, resulting in memory corruption and a denial-of-service (DoS) that could potentially crash the system.</Note>
    </Notes>
    <CVE>CVE-2025-32990</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ext4: ignore xattrs past end

Once inside 'ext4_xattr_inode_dec_ref_all' we should
ignore xattrs entries past the 'end' entry.

This fixes the following KASAN reported issue:

==================================================================
BUG: KASAN: slab-use-after-free in ext4_xattr_inode_dec_ref_all+0xb8c/0xe90
Read of size 4 at addr ffff888012c120c4 by task repro/2065

CPU: 1 UID: 0 PID: 2065 Comm: repro Not tainted 6.13.0-rc2+ #11
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x1fd/0x300
 ? tcp_gro_dev_warn+0x260/0x260
 ? _printk+0xc0/0x100
 ? read_lock_is_recursive+0x10/0x10
 ? irq_work_queue+0x72/0xf0
 ? __virt_addr_valid+0x17b/0x4b0
 print_address_description+0x78/0x390
 print_report+0x107/0x1f0
 ? __virt_addr_valid+0x17b/0x4b0
 ? __virt_addr_valid+0x3ff/0x4b0
 ? __phys_addr+0xb5/0x160
 ? ext4_xattr_inode_dec_ref_all+0xb8c/0xe90
 kasan_report+0xcc/0x100
 ? ext4_xattr_inode_dec_ref_all+0xb8c/0xe90
 ext4_xattr_inode_dec_ref_all+0xb8c/0xe90
 ? ext4_xattr_delete_inode+0xd30/0xd30
 ? __ext4_journal_ensure_credits+0x5f0/0x5f0
 ? __ext4_journal_ensure_credits+0x2b/0x5f0
 ? inode_update_timestamps+0x410/0x410
 ext4_xattr_delete_inode+0xb64/0xd30
 ? ext4_truncate+0xb70/0xdc0
 ? ext4_expand_extra_isize_ea+0x1d20/0x1d20
 ? __ext4_mark_inode_dirty+0x670/0x670
 ? ext4_journal_check_start+0x16f/0x240
 ? ext4_inode_is_fast_symlink+0x2f2/0x3a0
 ext4_evict_inode+0xc8c/0xff0
 ? ext4_inode_is_fast_symlink+0x3a0/0x3a0
 ? do_raw_spin_unlock+0x53/0x8a0
 ? ext4_inode_is_fast_symlink+0x3a0/0x3a0
 evict+0x4ac/0x950
 ? proc_nr_inodes+0x310/0x310
 ? trace_ext4_drop_inode+0xa2/0x220
 ? _raw_spin_unlock+0x1a/0x30
 ? iput+0x4cb/0x7e0
 do_unlinkat+0x495/0x7c0
 ? try_break_deleg+0x120/0x120
 ? 0xffffffff81000000
 ? __check_object_size+0x15a/0x210
 ? strncpy_from_user+0x13e/0x250
 ? getname_flags+0x1dc/0x530
 __x64_sys_unlinkat+0xc8/0xf0
 do_syscall_64+0x65/0x110
 entry_SYSCALL_64_after_hwframe+0x67/0x6f
RIP: 0033:0x434ffd
Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 8
RSP: 002b:00007ffc50fa7b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000107
RAX: ffffffffffffffda RBX: 00007ffc50fa7e18 RCX: 0000000000434ffd
RDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000005
RBP: 00007ffc50fa7be0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
R13: 00007ffc50fa7e08 R14: 00000000004bbf30 R15: 0000000000000001
 &lt;/TASK&gt;

The buggy address belongs to the object at ffff888012c12000
 which belongs to the cache filp of size 360
The buggy address is located 196 bytes inside of
 freed 360-byte region [ffff888012c12000, ffff888012c12168)

The buggy address belongs to the physical page:
page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x12c12
head: order:1 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
flags: 0x40(head|node=0|zone=0)
page_type: f5(slab)
raw: 0000000000000040 ffff888000ad7640 ffffea0000497a00 dead000000000004
raw: 0000000000000000 0000000000100010 00000001f5000000 0000000000000000
head: 0000000000000040 ffff888000ad7640 ffffea0000497a00 dead000000000004
head: 0000000000000000 0000000000100010 00000001f5000000 0000000000000000
head: 0000000000000001 ffffea00004b0481 ffffffffffffffff 0000000000000000
head: 0000000000000002 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff888012c11f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff888012c12000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
&gt; ffff888012c12080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                           ^
 ffff888012c12100: fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc
 ffff888012c12180: fc fc fc fc fc fc fc fc fc
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-37738</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

jfs: add sanity check for agwidth in dbMount

The width in dmapctl of the AG is zero, it trigger a divide error when
calculating the control page level in dbAllocAG.

To avoid this issue, add a check for agwidth in dbAllocAG.</Note>
    </Notes>
    <CVE>CVE-2025-37740</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

jfs: Prevent copying of nlink with value 0 from disk inode

syzbot report a deadlock in diFree. [1]

When calling "ioctl$LOOP_SET_STATUS64", the offset value passed in is 4,
which does not match the mounted loop device, causing the mapping of the
mounted loop device to be invalidated.

When creating the directory and creating the inode of iag in diReadSpecial(),
read the page of fixed disk inode (AIT) in raw mode in read_metapage(), the
metapage data it returns is corrupted, which causes the nlink value of 0 to be
assigned to the iag inode when executing copy_from_dinode(), which ultimately
causes a deadlock when entering diFree().

To avoid this, first check the nlink value of dinode before setting iag inode.

[1]
WARNING: possible recursive locking detected
6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Not tainted
--------------------------------------------
syz-executor301/5309 is trying to acquire lock:
ffff888044548920 (&amp;(imap-&gt;im_aglock[index])){+.+.}-{3:3}, at: diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889

but task is already holding lock:
ffff888044548920 (&amp;(imap-&gt;im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&amp;(imap-&gt;im_aglock[index]));
  lock(&amp;(imap-&gt;im_aglock[index]));

 *** DEADLOCK ***

 May be due to missing lock nesting notation

5 locks held by syz-executor301/5309:
 #0: ffff8880422a4420 (sb_writers#9){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:515
 #1: ffff88804755b390 (&amp;type-&gt;i_mutex_dir_key#6/1){+.+.}-{3:3}, at: inode_lock_nested include/linux/fs.h:850 [inline]
 #1: ffff88804755b390 (&amp;type-&gt;i_mutex_dir_key#6/1){+.+.}-{3:3}, at: filename_create+0x260/0x540 fs/namei.c:4026
 #2: ffff888044548920 (&amp;(imap-&gt;im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630
 #3: ffff888044548890 (&amp;imap-&gt;im_freelock){+.+.}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2460 [inline]
 #3: ffff888044548890 (&amp;imap-&gt;im_freelock){+.+.}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline]
 #3: ffff888044548890 (&amp;imap-&gt;im_freelock){+.+.}-{3:3}, at: diAllocAG+0x4b7/0x1e50 fs/jfs/jfs_imap.c:1669
 #4: ffff88804755a618 (&amp;jfs_ip-&gt;rdwrlock/1){++++}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2477 [inline]
 #4: ffff88804755a618 (&amp;jfs_ip-&gt;rdwrlock/1){++++}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline]
 #4: ffff88804755a618 (&amp;jfs_ip-&gt;rdwrlock/1){++++}-{3:3}, at: diAllocAG+0x869/0x1e50 fs/jfs/jfs_imap.c:1669

stack backtrace:
CPU: 0 UID: 0 PID: 5309 Comm: syz-executor301 Not tainted 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
 print_deadlock_bug+0x483/0x620 kernel/locking/lockdep.c:3037
 check_deadlock kernel/locking/lockdep.c:3089 [inline]
 validate_chain+0x15e2/0x5920 kernel/locking/lockdep.c:3891
 __lock_acquire+0x1384/0x2050 kernel/locking/lockdep.c:5202
 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825
 __mutex_lock_common kernel/locking/mutex.c:608 [inline]
 __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752
 diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889
 jfs_evict_inode+0x32d/0x440 fs/jfs/inode.c:156
 evict+0x4e8/0x9b0 fs/inode.c:725
 diFreeSpecial fs/jfs/jfs_imap.c:552 [inline]
 duplicateIXtree+0x3c6/0x550 fs/jfs/jfs_imap.c:3022
 diNewIAG fs/jfs/jfs_imap.c:2597 [inline]
 diAllocExt fs/jfs/jfs_imap.c:1905 [inline]
 diAllocAG+0x17dc/0x1e50 fs/jfs/jfs_imap.c:1669
 diAlloc+0x1d2/0x1630 fs/jfs/jfs_imap.c:1590
 ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56
 jfs_mkdir+0x1c5/0xba0 fs/jfs/namei.c:225
 vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257
 do_mkdirat+0x264/0x3a0 fs/namei.c:4280
 __do_sys_mkdirat fs/namei.c:4295 [inline]
 __se_sys_mkdirat fs/namei.c:4293 [inline]
 __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293
 do_syscall_x64 arch/x86/en
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-37741</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

jfs: Fix uninit-value access of imap allocated in the diMount() function

syzbot reports that hex_dump_to_buffer is using uninit-value:

=====================================================
BUG: KMSAN: uninit-value in hex_dump_to_buffer+0x888/0x1100 lib/hexdump.c:171
hex_dump_to_buffer+0x888/0x1100 lib/hexdump.c:171
print_hex_dump+0x13d/0x3e0 lib/hexdump.c:276
diFree+0x5ba/0x4350 fs/jfs/jfs_imap.c:876
jfs_evict_inode+0x510/0x550 fs/jfs/inode.c:156
evict+0x723/0xd10 fs/inode.c:796
iput_final fs/inode.c:1946 [inline]
iput+0x97b/0xdb0 fs/inode.c:1972
txUpdateMap+0xf3e/0x1150 fs/jfs/jfs_txnmgr.c:2367
txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline]
jfs_lazycommit+0x627/0x11d0 fs/jfs/jfs_txnmgr.c:2733
kthread+0x6b9/0xef0 kernel/kthread.c:464
ret_from_fork+0x6d/0x90 arch/x86/kernel/process.c:148
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

Uninit was created at:
slab_post_alloc_hook mm/slub.c:4121 [inline]
slab_alloc_node mm/slub.c:4164 [inline]
__kmalloc_cache_noprof+0x8e3/0xdf0 mm/slub.c:4320
kmalloc_noprof include/linux/slab.h:901 [inline]
diMount+0x61/0x7f0 fs/jfs/jfs_imap.c:105
jfs_mount+0xa8e/0x11d0 fs/jfs/jfs_mount.c:176
jfs_fill_super+0xa47/0x17c0 fs/jfs/super.c:523
get_tree_bdev_flags+0x6ec/0x910 fs/super.c:1636
get_tree_bdev+0x37/0x50 fs/super.c:1659
jfs_get_tree+0x34/0x40 fs/jfs/super.c:635
vfs_get_tree+0xb1/0x5a0 fs/super.c:1814
do_new_mount+0x71f/0x15e0 fs/namespace.c:3560
path_mount+0x742/0x1f10 fs/namespace.c:3887
do_mount fs/namespace.c:3900 [inline]
__do_sys_mount fs/namespace.c:4111 [inline]
__se_sys_mount+0x71f/0x800 fs/namespace.c:4088
__x64_sys_mount+0xe4/0x150 fs/namespace.c:4088
x64_sys_call+0x39bf/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:166
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
=====================================================

The reason is that imap is not properly initialized after memory
allocation. It will cause the snprintf() function to write uninitialized
data into linebuf within hex_dump_to_buffer().

Fix this by using kzalloc instead of kmalloc to clear its content at the
beginning in diMount().</Note>
    </Notes>
    <CVE>CVE-2025-37742</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: Avoid memory leak while enabling statistics

Driver uses monitor destination rings for extended statistics mode and
standalone monitor mode. In extended statistics mode, TLVs are parsed from
the buffer received from the monitor destination ring and assigned to the
ppdu_info structure to update per-packet statistics. In standalone monitor
mode, along with per-packet statistics, the packet data (payload) is
captured, and the driver updates per MSDU to mac80211.

When the AP interface is enabled, only extended statistics mode is
activated. As part of enabling monitor rings for collecting statistics,
the driver subscribes to HAL_RX_MPDU_START TLV in the filter
configuration. This TLV is received from the monitor destination ring, and
kzalloc for the mon_mpdu object occurs, which is not freed, leading to a
memory leak. The kzalloc for the mon_mpdu object is only required while
enabling the standalone monitor interface. This causes a memory leak while
enabling extended statistics mode in the driver.

Fix this memory leak by removing the kzalloc for the mon_mpdu object in
the HAL_RX_MPDU_START TLV handling. Additionally, remove the standalone
monitor mode handlings in the HAL_MON_BUF_ADDR and HAL_RX_MSDU_END TLVs.
These TLV tags will be handled properly when enabling standalone monitor
mode in the future.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3</Note>
    </Notes>
    <CVE>CVE-2025-37743</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/i915/huc: Fix fence not released on early probe errors

HuC delayed loading fence, introduced with commit 27536e03271da
("drm/i915/huc: track delayed HuC load with a fence"), is registered with
object tracker early on driver probe but unregistered only from driver
remove, which is not called on early probe errors.  Since its memory is
allocated under devres, then released anyway, it may happen to be
allocated again to the fence and reused on future driver probes, resulting
in kernel warnings that taint the kernel:

&lt;4&gt; [309.731371] ------------[ cut here ]------------
&lt;3&gt; [309.731373] ODEBUG: init destroyed (active state 0) object: ffff88813d7dd2e0 object type: i915_sw_fence hint: sw_fence_dummy_notify+0x0/0x20 [i915]
&lt;4&gt; [309.731575] WARNING: CPU: 2 PID: 3161 at lib/debugobjects.c:612 debug_print_object+0x93/0xf0
...
&lt;4&gt; [309.731693] CPU: 2 UID: 0 PID: 3161 Comm: i915_module_loa Tainted: G     U             6.14.0-CI_DRM_16362-gf0fd77956987+ #1
...
&lt;4&gt; [309.731700] RIP: 0010:debug_print_object+0x93/0xf0
...
&lt;4&gt; [309.731728] Call Trace:
&lt;4&gt; [309.731730]  &lt;TASK&gt;
...
&lt;4&gt; [309.731949]  __debug_object_init+0x17b/0x1c0
&lt;4&gt; [309.731957]  debug_object_init+0x34/0x50
&lt;4&gt; [309.732126]  __i915_sw_fence_init+0x34/0x60 [i915]
&lt;4&gt; [309.732256]  intel_huc_init_early+0x4b/0x1d0 [i915]
&lt;4&gt; [309.732468]  intel_uc_init_early+0x61/0x680 [i915]
&lt;4&gt; [309.732667]  intel_gt_common_init_early+0x105/0x130 [i915]
&lt;4&gt; [309.732804]  intel_root_gt_init_early+0x63/0x80 [i915]
&lt;4&gt; [309.732938]  i915_driver_probe+0x1fa/0xeb0 [i915]
&lt;4&gt; [309.733075]  i915_pci_probe+0xe6/0x220 [i915]
&lt;4&gt; [309.733198]  local_pci_probe+0x44/0xb0
&lt;4&gt; [309.733203]  pci_device_probe+0xf4/0x270
&lt;4&gt; [309.733209]  really_probe+0xee/0x3c0
&lt;4&gt; [309.733215]  __driver_probe_device+0x8c/0x180
&lt;4&gt; [309.733219]  driver_probe_device+0x24/0xd0
&lt;4&gt; [309.733223]  __driver_attach+0x10f/0x220
&lt;4&gt; [309.733230]  bus_for_each_dev+0x7d/0xe0
&lt;4&gt; [309.733236]  driver_attach+0x1e/0x30
&lt;4&gt; [309.733239]  bus_add_driver+0x151/0x290
&lt;4&gt; [309.733244]  driver_register+0x5e/0x130
&lt;4&gt; [309.733247]  __pci_register_driver+0x7d/0x90
&lt;4&gt; [309.733251]  i915_pci_register_driver+0x23/0x30 [i915]
&lt;4&gt; [309.733413]  i915_init+0x34/0x120 [i915]
&lt;4&gt; [309.733655]  do_one_initcall+0x62/0x3f0
&lt;4&gt; [309.733667]  do_init_module+0x97/0x2a0
&lt;4&gt; [309.733671]  load_module+0x25ff/0x2890
&lt;4&gt; [309.733688]  init_module_from_file+0x97/0xe0
&lt;4&gt; [309.733701]  idempotent_init_module+0x118/0x330
&lt;4&gt; [309.733711]  __x64_sys_finit_module+0x77/0x100
&lt;4&gt; [309.733715]  x64_sys_call+0x1f37/0x2650
&lt;4&gt; [309.733719]  do_syscall_64+0x91/0x180
&lt;4&gt; [309.733763]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
&lt;4&gt; [309.733792]  &lt;/TASK&gt;
...
&lt;4&gt; [309.733806] ---[ end trace 0000000000000000 ]---

That scenario is most easily reproducible with
igt@i915_module_load@reload-with-fault-injection.

Fix the issue by moving the cleanup step to driver release path.

(cherry picked from commit 795dbde92fe5c6996a02a5b579481de73035e7bf)</Note>
    </Notes>
    <CVE>CVE-2025-37754</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: tls: explicitly disallow disconnect

syzbot discovered that it can disconnect a TLS socket and then
run into all sort of unexpected corner cases. I have a vague
recollection of Eric pointing this out to us a long time ago.
Supporting disconnect is really hard, for one thing if offload
is enabled we'd need to wait for all packets to be _acked_.
Disconnect is not commonly used, disallow it.

The immediate problem syzbot run into is the warning in the strp,
but that's just the easiest bug to trigger:

  WARNING: CPU: 0 PID: 5834 at net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486
  RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486
  Call Trace:
   &lt;TASK&gt;
   tls_rx_rec_wait+0x280/0xa60 net/tls/tls_sw.c:1363
   tls_sw_recvmsg+0x85c/0x1c30 net/tls/tls_sw.c:2043
   inet6_recvmsg+0x2c9/0x730 net/ipv6/af_inet6.c:678
   sock_recvmsg_nosec net/socket.c:1023 [inline]
   sock_recvmsg+0x109/0x280 net/socket.c:1045
   __sys_recvfrom+0x202/0x380 net/socket.c:2237</Note>
    </Notes>
    <CVE>CVE-2025-37756</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tipc: fix memory leak in tipc_link_xmit

In case the backlog transmit queue for system-importance messages is overloaded,
tipc_link_xmit() returns -ENOBUFS but the skb list is not purged. This leads to
memory leak and failure when a skb is allocated.

This commit fixes this issue by purging the skb list before tipc_link_xmit()
returns.</Note>
    </Notes>
    <CVE>CVE-2025-37757</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ata: pata_pxa: Fix potential NULL pointer dereference in pxa_ata_probe()

devm_ioremap() returns NULL on error. Currently, pxa_ata_probe() does
not check for this case, which can result in a NULL pointer dereference.

Add NULL check after devm_ioremap() to prevent this issue.</Note>
    </Notes>
    <CVE>CVE-2025-37758</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/xe: Fix an out-of-bounds shift when invalidating TLB

When the size of the range invalidated is larger than
rounddown_pow_of_two(ULONG_MAX),
The function macro roundup_pow_of_two(length) will hit an out-of-bounds
shift [1].

Use a full TLB invalidation for such cases.
v2:
- Use a define for the range size limit over which we use a full
  TLB invalidation. (Lucas)
- Use a better calculation of the limit.

[1]:
[   39.202421] ------------[ cut here ]------------
[   39.202657] UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13
[   39.202673] shift exponent 64 is too large for 64-bit type 'long unsigned int'
[   39.202688] CPU: 8 UID: 0 PID: 3129 Comm: xe_exec_system_ Tainted: G     U             6.14.0+ #10
[   39.202690] Tainted: [U]=USER
[   39.202690] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS 2001 02/01/2023
[   39.202691] Call Trace:
[   39.202692]  &lt;TASK&gt;
[   39.202695]  dump_stack_lvl+0x6e/0xa0
[   39.202699]  ubsan_epilogue+0x5/0x30
[   39.202701]  __ubsan_handle_shift_out_of_bounds.cold+0x61/0xe6
[   39.202705]  xe_gt_tlb_invalidation_range.cold+0x1d/0x3a [xe]
[   39.202800]  ? find_held_lock+0x2b/0x80
[   39.202803]  ? mark_held_locks+0x40/0x70
[   39.202806]  xe_svm_invalidate+0x459/0x700 [xe]
[   39.202897]  drm_gpusvm_notifier_invalidate+0x4d/0x70 [drm_gpusvm]
[   39.202900]  __mmu_notifier_release+0x1f5/0x270
[   39.202905]  exit_mmap+0x40e/0x450
[   39.202912]  __mmput+0x45/0x110
[   39.202914]  exit_mm+0xc5/0x130
[   39.202916]  do_exit+0x21c/0x500
[   39.202918]  ? lockdep_hardirqs_on_prepare+0xdb/0x190
[   39.202920]  do_group_exit+0x36/0xa0
[   39.202922]  get_signal+0x8f8/0x900
[   39.202926]  arch_do_signal_or_restart+0x35/0x100
[   39.202930]  syscall_exit_to_user_mode+0x1fc/0x290
[   39.202932]  do_syscall_64+0xa1/0x180
[   39.202934]  ? do_user_addr_fault+0x59f/0x8a0
[   39.202937]  ? lock_release+0xd2/0x2a0
[   39.202939]  ? do_user_addr_fault+0x5a9/0x8a0
[   39.202942]  ? trace_hardirqs_off+0x4b/0xc0
[   39.202944]  ? clear_bhb_loop+0x25/0x80
[   39.202946]  ? clear_bhb_loop+0x25/0x80
[   39.202947]  ? clear_bhb_loop+0x25/0x80
[   39.202950]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[   39.202952] RIP: 0033:0x7fa945e543e1
[   39.202961] Code: Unable to access opcode bytes at 0x7fa945e543b7.
[   39.202962] RSP: 002b:00007ffca8fb4170 EFLAGS: 00000293
[   39.202963] RAX: 000000000000003d RBX: 0000000000000000 RCX: 00007fa945e543e3
[   39.202964] RDX: 0000000000000000 RSI: 00007ffca8fb41ac RDI: 00000000ffffffff
[   39.202964] RBP: 00007ffca8fb4190 R08: 0000000000000000 R09: 00007fa945f600a0
[   39.202965] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000
[   39.202966] R13: 00007fa9460dd310 R14: 00007ffca8fb41ac R15: 0000000000000000
[   39.202970]  &lt;/TASK&gt;
[   39.202970] ---[ end trace ]---

(cherry picked from commit b88f48f86500bc0b44b4f73ac66d500a40d320ad)</Note>
    </Notes>
    <CVE>CVE-2025-37761</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/imagination: take paired job reference

For paired jobs, have the fragment job take a reference on the
geometry job, so that the geometry job cannot be freed until
the fragment job has finished with it.

The geometry job structure is accessed when the fragment job is being
prepared by the GPU scheduler. Taking the reference prevents the
geometry job being freed until the fragment job no longer requires it.

Fixes a use after free bug detected by KASAN:

[  124.256386] BUG: KASAN: slab-use-after-free in pvr_queue_prepare_job+0x108/0x868 [powervr]
[  124.264893] Read of size 1 at addr ffff0000084cb960 by task kworker/u16:4/63</Note>
    </Notes>
    <CVE>CVE-2025-37763</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/imagination: fix firmware memory leaks

Free the memory used to hold the results of firmware image processing
when the module is unloaded.

Fix the related issue of the same memory being leaked if processing
of the firmware image fails during module load.

Ensure all firmware GEM objects are destroyed if firmware image
processing fails.

Fixes memory leaks on powervr module unload detected by Kmemleak:

unreferenced object 0xffff000042e20000 (size 94208):
  comm "modprobe", pid 470, jiffies 4295277154
  hex dump (first 32 bytes):
    02 ae 7f ed bf 45 84 00 3c 5b 1f ed 9f 45 45 05  .....E..&lt;[...EE.
    d5 4f 5d 14 6c 00 3d 23 30 d0 3a 4a 66 0e 48 c8  .O].l.=#0.:Jf.H.
  backtrace (crc dd329dec):
    kmemleak_alloc+0x30/0x40
    ___kmalloc_large_node+0x140/0x188
    __kmalloc_large_node_noprof+0x2c/0x13c
    __kmalloc_noprof+0x48/0x4c0
    pvr_fw_init+0xaa4/0x1f50 [powervr]

unreferenced object 0xffff000042d20000 (size 20480):
  comm "modprobe", pid 470, jiffies 4295277154
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 09 00 00 00 0b 00 00 00  ................
    00 00 00 00 00 00 00 00 07 00 00 00 08 00 00 00  ................
  backtrace (crc 395b02e3):
    kmemleak_alloc+0x30/0x40
    ___kmalloc_large_node+0x140/0x188
    __kmalloc_large_node_noprof+0x2c/0x13c
    __kmalloc_noprof+0x48/0x4c0
    pvr_fw_init+0xb0c/0x1f50 [powervr]</Note>
    </Notes>
    <CVE>CVE-2025-37764</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/nouveau: prime: fix ttm_bo_delayed_delete oops

Fix an oops in ttm_bo_delayed_delete which results from dererencing a
dangling pointer:

Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b7b: 0000 [#1] PREEMPT SMP
CPU: 4 UID: 0 PID: 1082 Comm: kworker/u65:2 Not tainted 6.14.0-rc4-00267-g505460b44513-dirty #216
Hardware name: LENOVO 82N6/LNVNB161216, BIOS GKCN65WW 01/16/2024
Workqueue: ttm ttm_bo_delayed_delete [ttm]
RIP: 0010:dma_resv_iter_first_unlocked+0x55/0x290
Code: 31 f6 48 c7 c7 00 2b fa aa e8 97 bd 52 ff e8 a2 c1 53 00 5a 85 c0 74 48 e9 88 01 00 00 4c 89 63 20 4d 85 e4 0f 84 30 01 00 00 &lt;41&gt; 8b 44 24 10 c6 43 2c 01 48 89 df 89 43 28 e8 97 fd ff ff 4c 8b
RSP: 0018:ffffbf9383473d60 EFLAGS: 00010202
RAX: 0000000000000001 RBX: ffffbf9383473d88 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffbf9383473d78 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 6b6b6b6b6b6b6b6b
R13: ffffa003bbf78580 R14: ffffa003a6728040 R15: 00000000000383cc
FS:  0000000000000000(0000) GS:ffffa00991c00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000758348024dd0 CR3: 000000012c259000 CR4: 0000000000f50ef0
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 ? __die_body.cold+0x19/0x26
 ? die_addr+0x3d/0x70
 ? exc_general_protection+0x159/0x460
 ? asm_exc_general_protection+0x27/0x30
 ? dma_resv_iter_first_unlocked+0x55/0x290
 dma_resv_wait_timeout+0x56/0x100
 ttm_bo_delayed_delete+0x69/0xb0 [ttm]
 process_one_work+0x217/0x5c0
 worker_thread+0x1c8/0x3d0
 ? apply_wqattrs_cleanup.part.0+0xc0/0xc0
 kthread+0x10b/0x240
 ? kthreads_online_cpu+0x140/0x140
 ret_from_fork+0x40/0x70
 ? kthreads_online_cpu+0x140/0x140
 ret_from_fork_asm+0x11/0x20
 &lt;/TASK&gt;

The cause of this is:

- drm_prime_gem_destroy calls dma_buf_put(dma_buf) which releases the
  reference to the shared dma_buf. The reference count is 0, so the
  dma_buf is destroyed, which in turn decrements the corresponding
  amdgpu_bo reference count to 0, and the amdgpu_bo is destroyed -
  calling drm_gem_object_release then dma_resv_fini (which destroys the
  reservation object), then finally freeing the amdgpu_bo.

- nouveau_bo obj-&gt;bo.base.resv is now a dangling pointer to the memory
  formerly allocated to the amdgpu_bo.

- nouveau_gem_object_del calls ttm_bo_put(&amp;nvbo-&gt;bo) which calls
  ttm_bo_release, which schedules ttm_bo_delayed_delete.

- ttm_bo_delayed_delete runs and dereferences the dangling resv pointer,
  resulting in a general protection fault.

Fix this by moving the drm_prime_gem_destroy call from
nouveau_gem_object_del to nouveau_bo_del_ttm. This ensures that it will
be run after ttm_bo_delayed_delete.</Note>
    </Notes>
    <CVE>CVE-2025-37765</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/pm: Prevent division by zero

The user can set any speed value.
If speed is greater than UINT_MAX/8, division by zero is possible.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2025-37766</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/pm: Prevent division by zero

The user can set any speed value.
If speed is greater than UINT_MAX/8, division by zero is possible.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2025-37767</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/pm: Prevent division by zero

The user can set any speed value.
If speed is greater than UINT_MAX/8, division by zero is possible.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2025-37768</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/pm/smu11: Prevent division by zero

The user can set any speed value.
If speed is greater than UINT_MAX/8, division by zero is possible.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

(cherry picked from commit da7dc714a8f8e1c9fc33c57cd63583779a3bef71)</Note>
    </Notes>
    <CVE>CVE-2025-37769</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/pm: Prevent division by zero

The user can set any speed value.
If speed is greater than UINT_MAX/8, division by zero is possible.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2025-37770</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/pm: Prevent division by zero

The user can set any speed value.
If speed is greater than UINT_MAX/8, division by zero is possible.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2025-37771</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/cma: Fix workqueue crash in cma_netevent_work_handler

struct rdma_cm_id has member "struct work_struct net_work"
that is reused for enqueuing cma_netevent_work_handler()s
onto cma_wq.

Below crash[1] can occur if more than one call to
cma_netevent_callback() occurs in quick succession,
which further enqueues cma_netevent_work_handler()s for the
same rdma_cm_id, overwriting any previously queued work-item(s)
that was just scheduled to run i.e. there is no guarantee
the queued work item may run between two successive calls
to cma_netevent_callback() and the 2nd INIT_WORK would overwrite
the 1st work item (for the same rdma_cm_id), despite grabbing
id_table_lock during enqueue.

Also drgn analysis [2] indicates the work item was likely overwritten.

Fix this by moving the INIT_WORK() to __rdma_create_id(),
so that it doesn't race with any existing queue_work() or
its worker thread.

[1] Trimmed crash stack:
=============================================
BUG: kernel NULL pointer dereference, address: 0000000000000008
kworker/u256:6 ... 6.12.0-0...
Workqueue:  cma_netevent_work_handler [rdma_cm] (rdma_cm)
RIP: 0010:process_one_work+0xba/0x31a
Call Trace:
 worker_thread+0x266/0x3a0
 kthread+0xcf/0x100
 ret_from_fork+0x31/0x50
 ret_from_fork_asm+0x1a/0x30
=============================================

[2] drgn crash analysis:

&gt;&gt;&gt; trace = prog.crashed_thread().stack_trace()
&gt;&gt;&gt; trace
(0)  crash_setup_regs (./arch/x86/include/asm/kexec.h:111:15)
(1)  __crash_kexec (kernel/crash_core.c:122:4)
(2)  panic (kernel/panic.c:399:3)
(3)  oops_end (arch/x86/kernel/dumpstack.c:382:3)
...
(8)  process_one_work (kernel/workqueue.c:3168:2)
(9)  process_scheduled_works (kernel/workqueue.c:3310:3)
(10) worker_thread (kernel/workqueue.c:3391:4)
(11) kthread (kernel/kthread.c:389:9)

Line workqueue.c:3168 for this kernel version is in process_one_work():
3168	strscpy(worker-&gt;desc, pwq-&gt;wq-&gt;name, WORKER_DESC_LEN);

&gt;&gt;&gt; trace[8]["work"]
*(struct work_struct *)0xffff92577d0a21d8 = {
	.data = (atomic_long_t){
		.counter = (s64)536870912,    &lt;=== Note
	},
	.entry = (struct list_head){
		.next = (struct list_head *)0xffff924d075924c0,
		.prev = (struct list_head *)0xffff924d075924c0,
	},
	.func = (work_func_t)cma_netevent_work_handler+0x0 = 0xffffffffc2cec280,
}

Suspicion is that pwq is NULL:
&gt;&gt;&gt; trace[8]["pwq"]
(struct pool_workqueue *)&lt;absent&gt;

In process_one_work(), pwq is assigned from:
struct pool_workqueue *pwq = get_work_pwq(work);

and get_work_pwq() is:
static struct pool_workqueue *get_work_pwq(struct work_struct *work)
{
 	unsigned long data = atomic_long_read(&amp;work-&gt;data);

 	if (data &amp; WORK_STRUCT_PWQ)
 		return work_struct_pwq(data);
 	else
 		return NULL;
}

WORK_STRUCT_PWQ is 0x4:
&gt;&gt;&gt; print(repr(prog['WORK_STRUCT_PWQ']))
Object(prog, 'enum work_flags', value=4)

But work-&gt;data is 536870912 which is 0x20000000.
So, get_work_pwq() returns NULL and we crash in process_one_work():
3168	strscpy(worker-&gt;desc, pwq-&gt;wq-&gt;name, WORKER_DESC_LEN);
=============================================</Note>
    </Notes>
    <CVE>CVE-2025-37772</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

i2c: cros-ec-tunnel: defer probe if parent EC is not present

When i2c-cros-ec-tunnel and the EC driver are built-in, the EC parent
device will not be found, leading to NULL pointer dereference.

That can also be reproduced by unbinding the controller driver and then
loading i2c-cros-ec-tunnel module (or binding the device).

[  271.991245] BUG: kernel NULL pointer dereference, address: 0000000000000058
[  271.998215] #PF: supervisor read access in kernel mode
[  272.003351] #PF: error_code(0x0000) - not-present page
[  272.008485] PGD 0 P4D 0
[  272.011022] Oops: Oops: 0000 [#1] SMP NOPTI
[  272.015207] CPU: 0 UID: 0 PID: 3859 Comm: insmod Tainted: G S                  6.15.0-rc1-00004-g44722359ed83 #30 PREEMPT(full)  3c7fb39a552e7d949de2ad921a7d6588d3a4fdc5
[  272.030312] Tainted: [S]=CPU_OUT_OF_SPEC
[  272.034233] Hardware name: HP Berknip/Berknip, BIOS Google_Berknip.13434.356.0 05/17/2021
[  272.042400] RIP: 0010:ec_i2c_probe+0x2b/0x1c0 [i2c_cros_ec_tunnel]
[  272.048577] Code: 1f 44 00 00 41 57 41 56 41 55 41 54 53 48 83 ec 10 65 48 8b 05 06 a0 6c e7 48 89 44 24 08 4c 8d 7f 10 48 8b 47 50 4c 8b 60 78 &lt;49&gt; 83 7c 24 58 00 0f 84 2f 01 00 00 48 89 fb be 30 06 00 00 4c 9
[  272.067317] RSP: 0018:ffffa32082a03940 EFLAGS: 00010282
[  272.072541] RAX: ffff969580b6a810 RBX: ffff969580b68c10 RCX: 0000000000000000
[  272.079672] RDX: 0000000000000000 RSI: 0000000000000282 RDI: ffff969580b68c00
[  272.086804] RBP: 00000000fffffdfb R08: 0000000000000000 R09: 0000000000000000
[  272.093936] R10: 0000000000000000 R11: ffffffffc0600000 R12: 0000000000000000
[  272.101067] R13: ffffffffa666fbb8 R14: ffffffffc05b5528 R15: ffff969580b68c10
[  272.108198] FS:  00007b930906fc40(0000) GS:ffff969603149000(0000) knlGS:0000000000000000
[  272.116282] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  272.122024] CR2: 0000000000000058 CR3: 000000012631c000 CR4: 00000000003506f0
[  272.129155] Call Trace:
[  272.131606]  &lt;TASK&gt;
[  272.133709]  ? acpi_dev_pm_attach+0xdd/0x110
[  272.137985]  platform_probe+0x69/0xa0
[  272.141652]  really_probe+0x152/0x310
[  272.145318]  __driver_probe_device+0x77/0x110
[  272.149678]  driver_probe_device+0x1e/0x190
[  272.153864]  __driver_attach+0x10b/0x1e0
[  272.157790]  ? driver_attach+0x20/0x20
[  272.161542]  bus_for_each_dev+0x107/0x150
[  272.165553]  bus_add_driver+0x15d/0x270
[  272.169392]  driver_register+0x65/0x110
[  272.173232]  ? cleanup_module+0xa80/0xa80 [i2c_cros_ec_tunnel 3a00532f3f4af4a9eade753f86b0f8dd4e4e5698]
[  272.182617]  do_one_initcall+0x110/0x350
[  272.186543]  ? security_kernfs_init_security+0x49/0xd0
[  272.191682]  ? __kernfs_new_node+0x1b9/0x240
[  272.195954]  ? security_kernfs_init_security+0x49/0xd0
[  272.201093]  ? __kernfs_new_node+0x1b9/0x240
[  272.205365]  ? kernfs_link_sibling+0x105/0x130
[  272.209810]  ? kernfs_next_descendant_post+0x1c/0xa0
[  272.214773]  ? kernfs_activate+0x57/0x70
[  272.218699]  ? kernfs_add_one+0x118/0x160
[  272.222710]  ? __kernfs_create_file+0x71/0xa0
[  272.227069]  ? sysfs_add_bin_file_mode_ns+0xd6/0x110
[  272.232033]  ? internal_create_group+0x453/0x4a0
[  272.236651]  ? __vunmap_range_noflush+0x214/0x2d0
[  272.241355]  ? __free_frozen_pages+0x1dc/0x420
[  272.245799]  ? free_vmap_area_noflush+0x10a/0x1c0
[  272.250505]  ? load_module+0x1509/0x16f0
[  272.254431]  do_init_module+0x60/0x230
[  272.258181]  __se_sys_finit_module+0x27a/0x370
[  272.262627]  do_syscall_64+0x6a/0xf0
[  272.266206]  ? do_syscall_64+0x76/0xf0
[  272.269956]  ? irqentry_exit_to_user_mode+0x79/0x90
[  272.274836]  entry_SYSCALL_64_after_hwframe+0x55/0x5d
[  272.279887] RIP: 0033:0x7b9309168d39
[  272.283466] Code: 5b 41 5c 5d c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d af 40 0c 00 f7 d8 64 89 01 8
[  272.302210] RSP: 002b:00007fff50f1a288 EFLAGS: 00000246 ORIG_RAX: 000
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-37781</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
    </Notes>
    <CVE>CVE-2025-37782</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: dsa: free routing table on probe failure

If complete = true in dsa_tree_setup(), it means that we are the last
switch of the tree which is successfully probing, and we should be
setting up all switches from our probe path.

After "complete" becomes true, dsa_tree_setup_cpu_ports() or any
subsequent function may fail. If that happens, the entire tree setup is
in limbo: the first N-1 switches have successfully finished probing
(doing nothing but having allocated persistent memory in the tree's
dst-&gt;ports, and maybe dst-&gt;rtable), and switch N failed to probe, ending
the tree setup process before anything is tangible from the user's PoV.

If switch N fails to probe, its memory (ports) will be freed and removed
from dst-&gt;ports. However, the dst-&gt;rtable elements pointing to its ports,
as created by dsa_link_touch(), will remain there, and will lead to
use-after-free if dereferenced.

If dsa_tree_setup_switches() returns -EPROBE_DEFER, which is entirely
possible because that is where ds-&gt;ops-&gt;setup() is, we get a kasan
report like this:

==================================================================
BUG: KASAN: slab-use-after-free in mv88e6xxx_setup_upstream_port+0x240/0x568
Read of size 8 at addr ffff000004f56020 by task kworker/u8:3/42

Call trace:
 __asan_report_load8_noabort+0x20/0x30
 mv88e6xxx_setup_upstream_port+0x240/0x568
 mv88e6xxx_setup+0xebc/0x1eb0
 dsa_register_switch+0x1af4/0x2ae0
 mv88e6xxx_register_switch+0x1b8/0x2a8
 mv88e6xxx_probe+0xc4c/0xf60
 mdio_probe+0x78/0xb8
 really_probe+0x2b8/0x5a8
 __driver_probe_device+0x164/0x298
 driver_probe_device+0x78/0x258
 __device_attach_driver+0x274/0x350

Allocated by task 42:
 __kasan_kmalloc+0x84/0xa0
 __kmalloc_cache_noprof+0x298/0x490
 dsa_switch_touch_ports+0x174/0x3d8
 dsa_register_switch+0x800/0x2ae0
 mv88e6xxx_register_switch+0x1b8/0x2a8
 mv88e6xxx_probe+0xc4c/0xf60
 mdio_probe+0x78/0xb8
 really_probe+0x2b8/0x5a8
 __driver_probe_device+0x164/0x298
 driver_probe_device+0x78/0x258
 __device_attach_driver+0x274/0x350

Freed by task 42:
 __kasan_slab_free+0x48/0x68
 kfree+0x138/0x418
 dsa_register_switch+0x2694/0x2ae0
 mv88e6xxx_register_switch+0x1b8/0x2a8
 mv88e6xxx_probe+0xc4c/0xf60
 mdio_probe+0x78/0xb8
 really_probe+0x2b8/0x5a8
 __driver_probe_device+0x164/0x298
 driver_probe_device+0x78/0x258
 __device_attach_driver+0x274/0x350

The simplest way to fix the bug is to delete the routing table in its
entirety. dsa_tree_setup_routing_table() has no problem in regenerating
it even if we deleted links between ports other than those of switch N,
because dsa_link_touch() first checks whether the port pair already
exists in dst-&gt;rtable, allocating if not.

The deletion of the routing table in its entirety already exists in
dsa_tree_teardown(), so refactor that into a function that can also be
called from the tree setup error path.

In my analysis of the commit to blame, it is the one which added
dsa_link elements to dst-&gt;rtable. Prior to that, each switch had its own
ds-&gt;rtable which is freed when the switch fails to probe. But the tree
is potentially persistent memory.</Note>
    </Notes>
    <CVE>CVE-2025-37786</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

cxgb4: fix memory leak in cxgb4_init_ethtool_filters() error path

In the for loop used to allocate the loc_array and bmap for each port, a
memory leak is possible when the allocation for loc_array succeeds,
but the allocation for bmap fails. This is because when the control flow
goes to the label free_eth_finfo, only the allocations starting from
(i-1)th iteration are freed.

Fix that by freeing the loc_array in the bmap allocation error path.</Note>
    </Notes>
    <CVE>CVE-2025-37788</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ethtool: cmis_cdb: use correct rpl size in ethtool_cmis_module_poll()

rpl is passed as a pointer to ethtool_cmis_module_poll(), so the correct
size of rpl is sizeof(*rpl) which should be just 1 byte.  Using the
pointer size instead can cause stack corruption:

Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ethtool_cmis_wait_for_cond+0xf4/0x100
CPU: 72 UID: 0 PID: 4440 Comm: kworker/72:2 Kdump: loaded Tainted: G           OE      6.11.0 #24
Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
Hardware name: Dell Inc. PowerEdge R760/04GWWM, BIOS 1.6.6 09/20/2023
Workqueue: events module_flash_fw_work
Call Trace:
 &lt;TASK&gt;
 panic+0x339/0x360
 ? ethtool_cmis_wait_for_cond+0xf4/0x100
 ? __pfx_status_success+0x10/0x10
 ? __pfx_status_fail+0x10/0x10
 __stack_chk_fail+0x10/0x10
 ethtool_cmis_wait_for_cond+0xf4/0x100
 ethtool_cmis_cdb_execute_cmd+0x1fc/0x330
 ? __pfx_status_fail+0x10/0x10
 cmis_cdb_module_features_get+0x6d/0xd0
 ethtool_cmis_cdb_init+0x8a/0xd0
 ethtool_cmis_fw_update+0x46/0x1d0
 module_flash_fw_work+0x17/0xa0
 process_one_work+0x179/0x390
 worker_thread+0x239/0x340
 ? __pfx_worker_thread+0x10/0x10
 kthread+0xcc/0x100
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x2d/0x50
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1a/0x30
 &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2025-37791</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: btrtl: Prevent potential NULL dereference

The btrtl_initialize() function checks that rtl_load_file() either
had an error or it loaded a zero length file.  However, if it loaded
a zero length file then the error code is not set correctly.  It
results in an error pointer vs NULL bug, followed by a NULL pointer
dereference.  This was detected by Smatch:

drivers/bluetooth/btrtl.c:592 btrtl_initialize() warn: passing zero to 'ERR_PTR'</Note>
    </Notes>
    <CVE>CVE-2025-37792</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ASoC: Intel: avs: Fix null-ptr-deref in avs_component_probe()

devm_kasprintf() returns NULL when memory allocation fails. Currently,
avs_component_probe() does not check for this case, which results in a
NULL pointer dereference.</Note>
    </Notes>
    <CVE>CVE-2025-37793</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: Purge vif txq in ieee80211_do_stop()

After ieee80211_do_stop() SKB from vif's txq could still be processed.
Indeed another concurrent vif schedule_and_wake_txq call could cause
those packets to be dequeued (see ieee80211_handle_wake_tx_queue())
without checking the sdata current state.

Because vif.drv_priv is now cleared in this function, this could lead to
driver crash.

For example in ath12k, ahvif is store in vif.drv_priv. Thus if
ath12k_mac_op_tx() is called after ieee80211_do_stop(), ahvif-&gt;ah can be
NULL, leading the ath12k_warn(ahvif-&gt;ah,...) call in this function to
trigger the NULL deref below.

  Unable to handle kernel paging request at virtual address dfffffc000000001
  KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
  batman_adv: bat0: Interface deactivated: brbh1337
  Mem abort info:
    ESR = 0x0000000096000004
    EC = 0x25: DABT (current EL), IL = 32 bits
    SET = 0, FnV = 0
    EA = 0, S1PTW = 0
    FSC = 0x04: level 0 translation fault
  Data abort info:
    ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
    CM = 0, WnR = 0, TnD = 0, TagAccess = 0
    GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
  [dfffffc000000001] address between user and kernel address ranges
  Internal error: Oops: 0000000096000004 [#1] SMP
  CPU: 1 UID: 0 PID: 978 Comm: lbd Not tainted 6.13.0-g633f875b8f1e #114
  Hardware name: HW (DT)
  pstate: 10000005 (nzcV daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
  pc : ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k]
  lr : ath12k_mac_op_tx+0x174/0x29b8 [ath12k]
  sp : ffffffc086ace450
  x29: ffffffc086ace450 x28: 0000000000000000 x27: 1ffffff810d59ca4
  x26: ffffff801d05f7c0 x25: 0000000000000000 x24: 000000004000001e
  x23: ffffff8009ce4926 x22: ffffff801f9c0800 x21: ffffff801d05f7f0
  x20: ffffff8034a19f40 x19: 0000000000000000 x18: ffffff801f9c0958
  x17: ffffff800bc0a504 x16: dfffffc000000000 x15: ffffffc086ace4f8
  x14: ffffff801d05f83c x13: 0000000000000000 x12: ffffffb003a0bf03
  x11: 0000000000000000 x10: ffffffb003a0bf02 x9 : ffffff8034a19f40
  x8 : ffffff801d05f818 x7 : 1ffffff0069433dc x6 : ffffff8034a19ee0
  x5 : ffffff801d05f7f0 x4 : 0000000000000000 x3 : 0000000000000001
  x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000008
  Call trace:
   ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] (P)
   ieee80211_handle_wake_tx_queue+0x16c/0x260
   ieee80211_queue_skb+0xeec/0x1d20
   ieee80211_tx+0x200/0x2c8
   ieee80211_xmit+0x22c/0x338
   __ieee80211_subif_start_xmit+0x7e8/0xc60
   ieee80211_subif_start_xmit+0xc4/0xee0
   __ieee80211_subif_start_xmit_8023.isra.0+0x854/0x17a0
   ieee80211_subif_start_xmit_8023+0x124/0x488
   dev_hard_start_xmit+0x160/0x5a8
   __dev_queue_xmit+0x6f8/0x3120
   br_dev_queue_push_xmit+0x120/0x4a8
   __br_forward+0xe4/0x2b0
   deliver_clone+0x5c/0xd0
   br_flood+0x398/0x580
   br_dev_xmit+0x454/0x9f8
   dev_hard_start_xmit+0x160/0x5a8
   __dev_queue_xmit+0x6f8/0x3120
   ip6_finish_output2+0xc28/0x1b60
   __ip6_finish_output+0x38c/0x638
   ip6_output+0x1b4/0x338
   ip6_local_out+0x7c/0xa8
   ip6_send_skb+0x7c/0x1b0
   ip6_push_pending_frames+0x94/0xd0
   rawv6_sendmsg+0x1a98/0x2898
   inet_sendmsg+0x94/0xe0
   __sys_sendto+0x1e4/0x308
   __arm64_sys_sendto+0xc4/0x140
   do_el0_svc+0x110/0x280
   el0_svc+0x20/0x60
   el0t_64_sync_handler+0x104/0x138
   el0t_64_sync+0x154/0x158

To avoid that, empty vif's txq at ieee80211_do_stop() so no packet could
be dequeued after ieee80211_do_stop() (new packets cannot be queued
because SDATA_STATE_RUNNING is cleared at this point).</Note>
    </Notes>
    <CVE>CVE-2025-37794</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: at76c50x: fix use after free access in at76_disconnect

The memory pointed to by priv is freed at the end of at76_delete_device
function (using ieee80211_free_hw). But the code then accesses the udev
field of the freed object to put the USB device. This may also lead to a
memory leak of the usb device. Fix this by using udev from interface.</Note>
    </Notes>
    <CVE>CVE-2025-37796</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

codel: remove sch-&gt;q.qlen check before qdisc_tree_reduce_backlog()

After making all -&gt;qlen_notify() callbacks idempotent, now it is safe to
remove the check of qlen!=0 from both fq_codel_dequeue() and
codel_qdisc_dequeue().</Note>
    </Notes>
    <CVE>CVE-2025-37798</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

driver core: fix potential NULL pointer dereference in dev_uevent()

If userspace reads "uevent" device attribute at the same time as another
threads unbinds the device from its driver, change to dev-&gt;driver from a
valid pointer to NULL may result in crash. Fix this by using READ_ONCE()
when fetching the pointer, and take bus' drivers klist lock to make sure
driver instance will not disappear while we access it.

Use WRITE_ONCE() when setting the driver pointer to ensure there is no
tearing.</Note>
    </Notes>
    <CVE>CVE-2025-37800</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

spi: spi-imx: Add check for spi_imx_setupxfer()

Add check for the return value of spi_imx_setupxfer().
spi_imx-&gt;rx and spi_imx-&gt;tx function pointer can be NULL when
spi_imx_setupxfer() return error, and make NULL pointer dereference.

 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
 Call trace:
  0x0
  spi_imx_pio_transfer+0x50/0xd8
  spi_imx_transfer_one+0x18c/0x858
  spi_transfer_one_message+0x43c/0x790
  __spi_pump_transfer_message+0x238/0x5d4
  __spi_sync+0x2b0/0x454
  spi_write_then_read+0x11c/0x200</Note>
    </Notes>
    <CVE>CVE-2025-37801</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sound/virtio: Fix cancel_sync warnings on uninitialized work_structs

Betty reported hitting the following warning:

[    8.709131][  T221] WARNING: CPU: 2 PID: 221 at kernel/workqueue.c:4182
...
[    8.713282][  T221] Call trace:
[    8.713365][  T221]  __flush_work+0x8d0/0x914
[    8.713468][  T221]  __cancel_work_sync+0xac/0xfc
[    8.713570][  T221]  cancel_work_sync+0x24/0x34
[    8.713667][  T221]  virtsnd_remove+0xa8/0xf8 [virtio_snd ab15f34d0dd772f6d11327e08a81d46dc9c36276]
[    8.713868][  T221]  virtsnd_probe+0x48c/0x664 [virtio_snd ab15f34d0dd772f6d11327e08a81d46dc9c36276]
[    8.714035][  T221]  virtio_dev_probe+0x28c/0x390
[    8.714139][  T221]  really_probe+0x1bc/0x4c8
...

It seems we're hitting the error path in virtsnd_probe(), which
triggers a virtsnd_remove() which iterates over the substreams
calling cancel_work_sync() on the elapsed_period work_struct.

Looking at the code, from earlier in:
virtsnd_probe()-&gt;virtsnd_build_devs()-&gt;virtsnd_pcm_parse_cfg()

We set snd-&gt;nsubstreams, allocate the snd-&gt;substreams, and if
we then hit an error on the info allocation or something in
virtsnd_ctl_query_info() fails, we will exit without having
initialized the elapsed_period work_struct.

When that error path unwinds we then call virtsnd_remove()
which as long as the substreams array is allocated, will iterate
through calling cancel_work_sync() on the uninitialized work
struct hitting this warning.

Takashi Iwai suggested this fix, which initializes the substreams
structure right after allocation, so that if we hit the error
paths we avoid trying to cleanup uninitialized data.

Note: I have not yet managed to reproduce the issue myself, so
this patch has had limited testing.

Feedback or thoughts would be appreciated!</Note>
    </Notes>
    <CVE>CVE-2025-37805</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: dwc3: gadget: check that event count does not exceed event buffer length

The event count is read from register DWC3_GEVNTCOUNT.
There is a check for the count being zero, but not for exceeding the
event buffer length.
Check that event count does not exceed event buffer length,
avoiding an out-of-bounds access when memcpy'ing the event.
Crash log:
Unable to handle kernel paging request at virtual address ffffffc0129be000
pc : __memcpy+0x114/0x180
lr : dwc3_check_event_buf+0xec/0x348
x3 : 0000000000000030 x2 : 000000000000dfc4
x1 : ffffffc0129be000 x0 : ffffff87aad60080
Call trace:
__memcpy+0x114/0x180
dwc3_interrupt+0x24/0x34</Note>
    </Notes>
    <CVE>CVE-2025-37810</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: chipidea: ci_hdrc_imx: fix usbmisc handling

usbmisc is an optional device property so it is totally valid for the
corresponding data-&gt;usbmisc_data to have a NULL value.

Check that before dereferencing the pointer.

Found by Linux Verification Center (linuxtesting.org) with Svace static
analysis tool.</Note>
    </Notes>
    <CVE>CVE-2025-37811</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: cdns3: Fix deadlock when using NCM gadget

The cdns3 driver has the same NCM deadlock as fixed in cdnsp by commit
58f2fcb3a845 ("usb: cdnsp: Fix deadlock issue during using NCM gadget").

Under PREEMPT_RT the deadlock can be readily triggered by heavy network
traffic, for example using "iperf --bidir" over NCM ethernet link.

The deadlock occurs because the threaded interrupt handler gets
preempted by a softirq, but both are protected by the same spinlock.
Prevent deadlock by disabling softirq during threaded irq handler.</Note>
    </Notes>
    <CVE>CVE-2025-37812</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: xhci: Fix invalid pointer dereference in Etron workaround

This check is performed before prepare_transfer() and prepare_ring(), so
enqueue can already point at the final link TRB of a segment. And indeed
it will, some 0.4% of times this code is called.

Then enqueue + 1 is an invalid pointer. It will crash the kernel right
away or load some junk which may look like a link TRB and cause the real
link TRB to be replaced with a NOOP. This wouldn't end well.

Use a functionally equivalent test which doesn't dereference the pointer
and always gives correct result.

Something has crashed my machine twice in recent days while playing with
an Etron HC, and a control transfer stress test ran for confirmation has
just crashed it again. The same test passes with this patch applied.</Note>
    </Notes>
    <CVE>CVE-2025-37813</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tty: Require CAP_SYS_ADMIN for all usages of TIOCL_SELMOUSEREPORT

This requirement was overeagerly loosened in commit 2f83e38a095f
("tty: Permit some TIOCL_SETSEL modes without CAP_SYS_ADMIN"), but as
it turns out,

  (1) the logic I implemented there was inconsistent (apologies!),

  (2) TIOCL_SELMOUSEREPORT might actually be a small security risk
      after all, and

  (3) TIOCL_SELMOUSEREPORT is only meant to be used by the mouse
      daemon (GPM or Consolation), which runs as CAP_SYS_ADMIN
      already.

In more detail:

1. The previous patch has inconsistent logic:

   In commit 2f83e38a095f ("tty: Permit some TIOCL_SETSEL modes
   without CAP_SYS_ADMIN"), we checked for sel_mode ==
   TIOCL_SELMOUSEREPORT, but overlooked that the lower four bits of
   this "mode" parameter were actually used as an additional way to
   pass an argument.  So the patch did actually still require
   CAP_SYS_ADMIN, if any of the mouse button bits are set, but did not
   require it if none of the mouse buttons bits are set.

   This logic is inconsistent and was not intentional.  We should have
   the same policies for using TIOCL_SELMOUSEREPORT independent of the
   value of the "hidden" mouse button argument.

   I sent a separate documentation patch to the man page list with
   more details on TIOCL_SELMOUSEREPORT:
   https://lore.kernel.org/all/20250223091342.35523-2-gnoack3000@gmail.com/

2. TIOCL_SELMOUSEREPORT is indeed a potential security risk which can
   let an attacker simulate "keyboard" input to command line
   applications on the same terminal, like TIOCSTI and some other
   TIOCLINUX "selection mode" IOCTLs.

   By enabling mouse reporting on a terminal and then injecting mouse
   reports through TIOCL_SELMOUSEREPORT, an attacker can simulate
   mouse movements on the same terminal, similar to the TIOCSTI
   keystroke injection attacks that were previously possible with
   TIOCSTI and other TIOCL_SETSEL selection modes.

   Many programs (including libreadline/bash) are then prone to
   misinterpret these mouse reports as normal keyboard input because
   they do not expect input in the X11 mouse protocol form.  The
   attacker does not have complete control over the escape sequence,
   but they can at least control the values of two consecutive bytes
   in the binary mouse reporting escape sequence.

   I went into more detail on that in the discussion at
   https://lore.kernel.org/all/20250221.0a947528d8f3@gnoack.org/

   It is not equally trivial to simulate arbitrary keystrokes as it
   was with TIOCSTI (commit 83efeeeb3d04 ("tty: Allow TIOCSTI to be
   disabled")), but the general mechanism is there, and together with
   the small number of existing legit use cases (see below), it would
   be better to revert back to requiring CAP_SYS_ADMIN for
   TIOCL_SELMOUSEREPORT, as it was already the case before
   commit 2f83e38a095f ("tty: Permit some TIOCL_SETSEL modes without
   CAP_SYS_ADMIN").

3. TIOCL_SELMOUSEREPORT is only used by the mouse daemons (GPM or
   Consolation), and they are the only legit use case:

   To quote console_codes(4):

     The mouse tracking facility is intended to return
     xterm(1)-compatible mouse status reports.  Because the console
     driver has no way to know the device or type of the mouse, these
     reports are returned in the console input stream only when the
     virtual terminal driver receives a mouse update ioctl.  These
     ioctls must be generated by a mouse-aware user-mode application
     such as the gpm(8) daemon.

   Jared Finder has also confirmed in
   https://lore.kernel.org/all/491f3df9de6593df8e70dbe77614b026@finder.org/
   that Emacs does not call TIOCL_SELMOUSEREPORT directly, and it
   would be difficult to find good reasons for doing that, given that
   it would interfere with the reports that GPM is sending.

   More information on the interaction between GPM, terminals and th
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-37814</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

misc: microchip: pci1xxxx: Fix Kernel panic during IRQ handler registration

Resolve kernel panic while accessing IRQ handler associated with the
generated IRQ. This is done by acquiring the spinlock and storing the
current interrupt state before handling the interrupt request using
generic_handle_irq.

A previous fix patch was submitted where 'generic_handle_irq' was
replaced with 'handle_nested_irq'. However, this change also causes
the kernel panic where after determining which GPIO triggered the
interrupt and attempting to call handle_nested_irq with the mapped
IRQ number, leads to a failure in locating the registered handler.</Note>
    </Notes>
    <CVE>CVE-2025-37815</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mei: vsc: Fix fortify-panic caused by invalid counted_by() use

gcc 15 honors the __counted_by(len) attribute on vsc_tp_packet.buf[]
and the vsc-tp.c code is using this in a wrong way. len does not contain
the available size in the buffer, it contains the actual packet length
*without* the crc. So as soon as vsc_tp_xfer() tries to add the crc to
buf[] the fortify-panic handler gets triggered:

[   80.842193] memcpy: detected buffer overflow: 4 byte write of buffer size 0
[   80.842243] WARNING: CPU: 4 PID: 272 at lib/string_helpers.c:1032 __fortify_report+0x45/0x50
...
[   80.843175]  __fortify_panic+0x9/0xb
[   80.843186]  vsc_tp_xfer.cold+0x67/0x67 [mei_vsc_hw]
[   80.843210]  ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90
[   80.843229]  ? lockdep_hardirqs_on+0x7c/0x110
[   80.843250]  mei_vsc_hw_start+0x98/0x120 [mei_vsc]
[   80.843270]  mei_reset+0x11d/0x420 [mei]

The easiest fix would be to just drop the counted-by but with the exception
of the ack buffer in vsc_tp_xfer_helper() which only contains enough room
for the packet-header, all other uses of vsc_tp_packet always use a buffer
of VSC_TP_MAX_XFER_SIZE bytes for the packet.

Instead of just dropping the counted-by, split the vsc_tp_packet struct
definition into a header and a full-packet definition and use a fixed
size buf[] in the packet definition, this way fortify-source buffer
overrun checking still works when enabled.</Note>
    </Notes>
    <CVE>CVE-2025-37816</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

irqchip/gic-v2m: Prevent use after free of gicv2m_get_fwnode()

With ACPI in place, gicv2m_get_fwnode() is registered with the pci
subsystem as pci_msi_get_fwnode_cb(), which may get invoked at runtime
during a PCI host bridge probe. But, the call back is wrongly marked as
__init, causing it to be freed, while being registered with the PCI
subsystem and could trigger:

 Unable to handle kernel paging request at virtual address ffff8000816c0400
  gicv2m_get_fwnode+0x0/0x58 (P)
  pci_set_bus_msi_domain+0x74/0x88
  pci_register_host_bridge+0x194/0x548

This is easily reproducible on a Juno board with ACPI boot.

Retain the function for later use.</Note>
    </Notes>
    <CVE>CVE-2025-37819</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

PCI: Fix reference leak in pci_register_host_bridge()

If device_register() fails, call put_device() to give up the reference to
avoid a memory leak, per the comment at device_register().

Found by code review.

[bhelgaas: squash Dan Carpenter's double free fix from
https://lore.kernel.org/r/db806a6c-a91b-4e5a-a84b-6b7e01bdac85@stanley.mountain]</Note>
    </Notes>
    <CVE>CVE-2025-37836</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iommu/tegra241-cmdqv: Fix warnings due to dmam_free_coherent()

Two WARNINGs are observed when SMMU driver rolls back upon failure:
 arm-smmu-v3.9.auto: Failed to register iommu
 arm-smmu-v3.9.auto: probe with driver arm-smmu-v3 failed with error -22
 ------------[ cut here ]------------
 WARNING: CPU: 5 PID: 1 at kernel/dma/mapping.c:74 dmam_free_coherent+0xc0/0xd8
 Call trace:
  dmam_free_coherent+0xc0/0xd8 (P)
  tegra241_vintf_free_lvcmdq+0x74/0x188
  tegra241_cmdqv_remove_vintf+0x60/0x148
  tegra241_cmdqv_remove+0x48/0xc8
  arm_smmu_impl_remove+0x28/0x60
  devm_action_release+0x1c/0x40
 ------------[ cut here ]------------
 128 pages are still in use!
 WARNING: CPU: 16 PID: 1 at mm/page_alloc.c:6902 free_contig_range+0x18c/0x1c8
 Call trace:
  free_contig_range+0x18c/0x1c8 (P)
  cma_release+0x154/0x2f0
  dma_free_contiguous+0x38/0xa0
  dma_direct_free+0x10c/0x248
  dma_free_attrs+0x100/0x290
  dmam_free_coherent+0x78/0xd8
  tegra241_vintf_free_lvcmdq+0x74/0x160
  tegra241_cmdqv_remove+0x98/0x198
  arm_smmu_impl_remove+0x28/0x60
  devm_action_release+0x1c/0x40

This is because the LVCMDQ queue memory are managed by devres, while that
dmam_free_coherent() is called in the context of devm_action_release().

Jason pointed out that "arm_smmu_impl_probe() has mis-ordered the devres
callbacks if ops-&gt;device_remove() is going to be manually freeing things
that probe allocated":
https://lore.kernel.org/linux-iommu/20250407174408.GB1722458@nvidia.com/

In fact, tegra241_cmdqv_init_structures() only allocates memory resources
which means any failure that it generates would be similar to -ENOMEM, so
there is no point in having that "falling back to standard SMMU" routine,
as the standard SMMU would likely fail to allocate memory too.

Remove the unwind part in tegra241_cmdqv_init_structures(), and return a
proper error code to ask SMMU driver to call tegra241_cmdqv_remove() via
impl_ops-&gt;device_remove(). Then, drop tegra241_vintf_free_lvcmdq() since
devres will take care of that.</Note>
    </Notes>
    <CVE>CVE-2025-37837</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

jbd2: remove wrong sb-&gt;s_sequence check

Journal emptiness is not determined by sb-&gt;s_sequence == 0 but rather by
sb-&gt;s_start == 0 (which is set a few lines above). Furthermore 0 is a
valid transaction ID so the check can spuriously trigger. Remove the
invalid WARN_ON.</Note>
    </Notes>
    <CVE>CVE-2025-37839</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mtd: rawnand: brcmnand: fix PM resume warning

Fixed warning on PM resume as shown below caused due to uninitialized
struct nand_operation that checks chip select field :
WARN_ON(op-&gt;cs &gt;= nanddev_ntargets(&amp;chip-&gt;base)

[   14.588522] ------------[ cut here ]------------
[   14.588529] WARNING: CPU: 0 PID: 1392 at drivers/mtd/nand/raw/internals.h:139 nand_reset_op+0x1e0/0x1f8
[   14.588553] Modules linked in: bdc udc_core
[   14.588579] CPU: 0 UID: 0 PID: 1392 Comm: rtcwake Tainted: G        W          6.14.0-rc4-g5394eea10651 #16
[   14.588590] Tainted: [W]=WARN
[   14.588593] Hardware name: Broadcom STB (Flattened Device Tree)
[   14.588598] Call trace:
[   14.588604]  dump_backtrace from show_stack+0x18/0x1c
[   14.588622]  r7:00000009 r6:0000008b r5:60000153 r4:c0fa558c
[   14.588625]  show_stack from dump_stack_lvl+0x70/0x7c
[   14.588639]  dump_stack_lvl from dump_stack+0x18/0x1c
[   14.588653]  r5:c08d40b0 r4:c1003cb0
[   14.588656]  dump_stack from __warn+0x84/0xe4
[   14.588668]  __warn from warn_slowpath_fmt+0x18c/0x194
[   14.588678]  r7:c08d40b0 r6:c1003cb0 r5:00000000 r4:00000000
[   14.588681]  warn_slowpath_fmt from nand_reset_op+0x1e0/0x1f8
[   14.588695]  r8:70c40dff r7:89705f41 r6:36b4a597 r5:c26c9444 r4:c26b0048
[   14.588697]  nand_reset_op from brcmnand_resume+0x13c/0x150
[   14.588714]  r9:00000000 r8:00000000 r7:c24f8010 r6:c228a3f8 r5:c26c94bc r4:c26b0040
[   14.588717]  brcmnand_resume from platform_pm_resume+0x34/0x54
[   14.588735]  r5:00000010 r4:c0840a50
[   14.588738]  platform_pm_resume from dpm_run_callback+0x5c/0x14c
[   14.588757]  dpm_run_callback from device_resume+0xc0/0x324
[   14.588776]  r9:c24f8054 r8:c24f80a0 r7:00000000 r6:00000000 r5:00000010 r4:c24f8010
[   14.588779]  device_resume from dpm_resume+0x130/0x160
[   14.588799]  r9:c22539e4 r8:00000010 r7:c22bebb0 r6:c24f8010 r5:c22539dc r4:c22539b0
[   14.588802]  dpm_resume from dpm_resume_end+0x14/0x20
[   14.588822]  r10:c2204e40 r9:00000000 r8:c228a3fc r7:00000000 r6:00000003 r5:c228a414
[   14.588826]  r4:00000010
[   14.588828]  dpm_resume_end from suspend_devices_and_enter+0x274/0x6f8
[   14.588848]  r5:c228a414 r4:00000000
[   14.588851]  suspend_devices_and_enter from pm_suspend+0x228/0x2bc
[   14.588868]  r10:c3502910 r9:c3501f40 r8:00000004 r7:c228a438 r6:c0f95e18 r5:00000000
[   14.588871]  r4:00000003
[   14.588874]  pm_suspend from state_store+0x74/0xd0
[   14.588889]  r7:c228a438 r6:c0f934c8 r5:00000003 r4:00000003
[   14.588892]  state_store from kobj_attr_store+0x1c/0x28
[   14.588913]  r9:00000000 r8:00000000 r7:f09f9f08 r6:00000004 r5:c3502900 r4:c0283250
[   14.588916]  kobj_attr_store from sysfs_kf_write+0x40/0x4c
[   14.588936]  r5:c3502900 r4:c0d92a48
[   14.588939]  sysfs_kf_write from kernfs_fop_write_iter+0x104/0x1f0
[   14.588956]  r5:c3502900 r4:c3501f40
[   14.588960]  kernfs_fop_write_iter from vfs_write+0x250/0x420
[   14.588980]  r10:c0e14b48 r9:00000000 r8:c25f5780 r7:00443398 r6:f09f9f68 r5:c34f7f00
[   14.588983]  r4:c042a88c
[   14.588987]  vfs_write from ksys_write+0x74/0xe4
[   14.589005]  r10:00000004 r9:c25f5780 r8:c02002fA0 r7:00000000 r6:00000000 r5:c34f7f00
[   14.589008]  r4:c34f7f00
[   14.589011]  ksys_write from sys_write+0x10/0x14
[   14.589029]  r7:00000004 r6:004421c0 r5:00443398 r4:00000004
[   14.589032]  sys_write from ret_fast_syscall+0x0/0x5c
[   14.589044] Exception stack(0xf09f9fa8 to 0xf09f9ff0)
[   14.589050] 9fa0:                   00000004 00443398 00000004 00443398 00000004 00000001
[   14.589056] 9fc0: 00000004 00443398 004421c0 00000004 b6ecbd58 00000008 bebfbc38 0043eb78
[   14.589062] 9fe0: 00440eb0 bebfbaf8 b6de18a0 b6e579e8
[   14.589065] ---[ end trace 0000000000000000 ]---

The fix uses the higher level nand_reset(chip, chipnr); where chipnr = 0, when
doing PM resume operation in compliance with the controller support for single
die nand chip. Switching from nand_reset_op() to nan
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-37840</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

pm: cpupower: bench: Prevent NULL dereference on malloc failure

If malloc returns NULL due to low memory, 'config' pointer can be NULL.
Add a check to prevent NULL dereference.</Note>
    </Notes>
    <CVE>CVE-2025-37841</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

cifs: avoid NULL pointer dereference in dbg call

cifs_server_dbg() implies server to be non-NULL so
move call under condition to avoid NULL pointer dereference.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2025-37844</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

accel/ivpu: Fix deadlock in ivpu_ms_cleanup()

Fix deadlock in ivpu_ms_cleanup() by preventing runtime resume after
file_priv-&gt;ms_lock is acquired.

During a failure in runtime resume, a cold boot is executed, which
calls ivpu_ms_cleanup_all(). This function calls ivpu_ms_cleanup()
that acquires file_priv-&gt;ms_lock and causes the deadlock.</Note>
    </Notes>
    <CVE>CVE-2025-37847</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

accel/ivpu: Fix PM related deadlocks in MS IOCTLs

Prevent runtime resume/suspend while MS IOCTLs are in progress.
Failed suspend will call ivpu_ms_cleanup() that would try to acquire
file_priv-&gt;ms_lock, which is already held by the IOCTLs.</Note>
    </Notes>
    <CVE>CVE-2025-37848</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

KVM: arm64: Tear down vGIC on failed vCPU creation

If kvm_arch_vcpu_create() fails to share the vCPU page with the
hypervisor, we propagate the error back to the ioctl but leave the
vGIC vCPU data initialised. Note only does this leak the corresponding
memory when the vCPU is destroyed but it can also lead to use-after-free
if the redistributor device handling tries to walk into the vCPU.

Add the missing cleanup to kvm_arch_vcpu_create(), ensuring that the
vGIC vCPU structures are destroyed on error.</Note>
    </Notes>
    <CVE>CVE-2025-37849</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

pwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config()

With CONFIG_COMPILE_TEST &amp;&amp; !CONFIG_HAVE_CLK, pwm_mediatek_config() has a
divide-by-zero in the following line:

	do_div(resolution, clk_get_rate(pc-&gt;clk_pwms[pwm-&gt;hwpwm]));

due to the fact that the !CONFIG_HAVE_CLK version of clk_get_rate()
returns zero.

This is presumably just a theoretical problem: COMPILE_TEST overrides
the dependency on RALINK which would select COMMON_CLK.  Regardless it's
a good idea to check for the error explicitly to avoid divide-by-zero.

Fixes the following warning:

  drivers/pwm/pwm-mediatek.o: warning: objtool: .text: unexpected end of section

[ukleinek: s/CONFIG_CLK/CONFIG_HAVE_CLK/]</Note>
    </Notes>
    <CVE>CVE-2025-37850</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

fbdev: omapfb: Add 'plane' value check

Function dispc_ovl_setup is not intended to work with the value OMAP_DSS_WB
of the enum parameter plane.

The value of this parameter is initialized in dss_init_overlays and in the
current state of the code it cannot take this value so it's not a real
problem.

For the purposes of defensive coding it wouldn't be superfluous to check
the parameter value, because some functions down the call stack process
this value correctly and some not.

For example, in dispc_ovl_setup_global_alpha it may lead to buffer
overflow.

Add check for this value.

Found by Linux Verification Center (linuxtesting.org) with SVACE static
analysis tool.</Note>
    </Notes>
    <CVE>CVE-2025-37851</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: handle amdgpu_cgs_create_device() errors in amd_powerplay_create()

Add error handling to propagate amdgpu_cgs_create_device() failures
to the caller. When amdgpu_cgs_create_device() fails, release hwmgr
and return -ENOMEM to prevent null pointer dereference.

[v1]-&gt;[v2]: Change error code from -EINVAL to -ENOMEM. Free hwmgr.</Note>
    </Notes>
    <CVE>CVE-2025-37852</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amdkfd: debugfs hang_hws skip GPU with MES

debugfs hang_hws is used by GPU reset test with HWS, for MES this crash
the kernel with NULL pointer access because dqm-&gt;packet_mgr is not setup
for MES path.

Skip GPU with MES for now, MES hang_hws debugfs interface will be
supported later.</Note>
    </Notes>
    <CVE>CVE-2025-37853</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amdkfd: Fix mode1 reset crash issue

If HW scheduler hangs and mode1 reset is used to recover GPU, KFD signal
user space to abort the processes. After process abort exit, user queues
still use the GPU to access system memory before h/w is reset while KFD
cleanup worker free system memory and free VRAM.

There is use-after-free race bug that KFD allocate and reuse the freed
system memory, and user queue write to the same system memory to corrupt
the data structure and cause driver crash.

To fix this race, KFD cleanup worker terminate user queues, then flush
reset_domain wq to wait for any GPU ongoing reset complete, and then
free outstanding BOs.</Note>
    </Notes>
    <CVE>CVE-2025-37854</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

btrfs: harden block_group::bg_list against list_del() races

As far as I can tell, these calls of list_del_init() on bg_list cannot
run concurrently with btrfs_mark_bg_unused() or btrfs_mark_bg_to_reclaim(),
as they are in transaction error paths and situations where the block
group is readonly.

However, if there is any chance at all of racing with mark_bg_unused(),
or a different future user of bg_list, better to be safe than sorry.

Otherwise we risk the following interleaving (bg_list refcount in parens)

T1 (some random op)                       T2 (btrfs_mark_bg_unused)
                                        !list_empty(&amp;bg-&gt;bg_list); (1)
list_del_init(&amp;bg-&gt;bg_list); (1)
                                        list_move_tail (1)
btrfs_put_block_group (0)
                                        btrfs_delete_unused_bgs
                                             bg = list_first_entry
                                             list_del_init(&amp;bg-&gt;bg_list);
                                             btrfs_put_block_group(bg); (-1)

Ultimately, this results in a broken ref count that hits zero one deref
early and the real final deref underflows the refcount, resulting in a WARNING.</Note>
    </Notes>
    <CVE>CVE-2025-37856</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

fs/jfs: Prevent integer overflow in AG size calculation

The JFS filesystem calculates allocation group (AG) size using 1 &lt;&lt;
l2agsize in dbExtendFS(). When l2agsize exceeds 31 (possible with &gt;2TB
aggregates on 32-bit systems), this 32-bit shift operation causes undefined
behavior and improper AG sizing.

On 32-bit architectures:
- Left-shifting 1 by 32+ bits results in 0 due to integer overflow
- This creates invalid AG sizes (0 or garbage values) in
sbi-&gt;bmap-&gt;db_agsize
- Subsequent block allocations would reference invalid AG structures
- Could lead to:
  - Filesystem corruption during extend operations
  - Kernel crashes due to invalid memory accesses
  - Security vulnerabilities via malformed on-disk structures

Fix by casting to s64 before shifting:
bmp-&gt;db_agsize = (s64)1 &lt;&lt; l2agsize;

This ensures 64-bit arithmetic even on 32-bit architectures. The cast
matches the data type of db_agsize (s64) and follows similar patterns in
JFS block calculation code.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2025-37858</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

page_pool: avoid infinite loop to schedule delayed worker

We noticed the kworker in page_pool_release_retry() was waken
up repeatedly and infinitely in production because of the
buggy driver causing the inflight less than 0 and warning
us in page_pool_inflight()[1].

Since the inflight value goes negative, it means we should
not expect the whole page_pool to get back to work normally.

This patch mitigates the adverse effect by not rescheduling
the kworker when detecting the inflight negative in
page_pool_release_retry().

[1]
[Mon Feb 10 20:36:11 2025] ------------[ cut here ]------------
[Mon Feb 10 20:36:11 2025] Negative(-51446) inflight packet-pages
...
[Mon Feb 10 20:36:11 2025] Call Trace:
[Mon Feb 10 20:36:11 2025]  page_pool_release_retry+0x23/0x70
[Mon Feb 10 20:36:11 2025]  process_one_work+0x1b1/0x370
[Mon Feb 10 20:36:11 2025]  worker_thread+0x37/0x3a0
[Mon Feb 10 20:36:11 2025]  kthread+0x11a/0x140
[Mon Feb 10 20:36:11 2025]  ? process_one_work+0x370/0x370
[Mon Feb 10 20:36:11 2025]  ? __kthread_cancel_work+0x40/0x40
[Mon Feb 10 20:36:11 2025]  ret_from_fork+0x35/0x40
[Mon Feb 10 20:36:11 2025] ---[ end trace ebffe800f33e7e34 ]---
Note: before this patch, the above calltrace would flood the
dmesg due to repeated reschedule of release_dw kworker.</Note>
    </Notes>
    <CVE>CVE-2025-37859</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queue

When the task management thread processes reply queues while the reset
thread resets them, the task management thread accesses an invalid queue ID
(0xFFFF), set by the reset thread, which points to unallocated memory,
causing a crash.

Add flag 'io_admin_reset_sync' to synchronize access between the reset,
I/O, and admin threads. Before a reset, the reset handler sets this flag to
block I/O and admin processing threads. If any thread bypasses the initial
check, the reset thread waits up to 10 seconds for processing to finish. If
the wait exceeds 10 seconds, the controller is marked as unrecoverable.</Note>
    </Notes>
    <CVE>CVE-2025-37861</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

HID: pidff: Fix null pointer dereference in pidff_find_fields

This function triggered a null pointer dereference if used to search for
a report that isn't implemented on the device. This happened both for
optional and required reports alike.

The same logic was applied to pidff_find_special_field and although
pidff_init_fields should return an error earlier if one of the required
reports is missing, future modifications could change this logic and
resurface this possible null pointer dereference again.

LKML bug report:
https://lore.kernel.org/all/CAL-gK7f5=R0nrrQdPtaZZr1fd-cdAMbDMuZ_NLA8vM0SX+nGSw@mail.gmail.com</Note>
    </Notes>
    <CVE>CVE-2025-37862</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: dsa: clean up FDB, MDB, VLAN entries on unbind

As explained in many places such as commit b117e1e8a86d ("net: dsa:
delete dsa_legacy_fdb_add and dsa_legacy_fdb_del"), DSA is written given
the assumption that higher layers have balanced additions/deletions.
As such, it only makes sense to be extremely vocal when those
assumptions are violated and the driver unbinds with entries still
present.

But Ido Schimmel points out a very simple situation where that is wrong:
https://lore.kernel.org/netdev/ZDazSM5UsPPjQuKr@shredder/
(also briefly discussed by me in the aforementioned commit).

Basically, while the bridge bypass operations are not something that DSA
explicitly documents, and for the majority of DSA drivers this API
simply causes them to go to promiscuous mode, that isn't the case for
all drivers. Some have the necessary requirements for bridge bypass
operations to do something useful - see dsa_switch_supports_uc_filtering().

Although in tools/testing/selftests/net/forwarding/local_termination.sh,
we made an effort to popularize better mechanisms to manage address
filters on DSA interfaces from user space - namely macvlan for unicast,
and setsockopt(IP_ADD_MEMBERSHIP) - through mtools - for multicast, the
fact is that 'bridge fdb add ... self static local' also exists as
kernel UAPI, and might be useful to someone, even if only for a quick
hack.

It seems counter-productive to block that path by implementing shim
.ndo_fdb_add and .ndo_fdb_del operations which just return -EOPNOTSUPP
in order to prevent the ndo_dflt_fdb_add() and ndo_dflt_fdb_del() from
running, although we could do that.

Accepting that cleanup is necessary seems to be the only option.
Especially since we appear to be coming back at this from a different
angle as well. Russell King is noticing that the WARN_ON() triggers even
for VLANs:
https://lore.kernel.org/netdev/Z_li8Bj8bD4-BYKQ@shell.armlinux.org.uk/

What happens in the bug report above is that dsa_port_do_vlan_del() fails,
then the VLAN entry lingers on, and then we warn on unbind and leak it.

This is not a straight revert of the blamed commit, but we now add an
informational print to the kernel log (to still have a way to see
that bugs exist), and some extra comments gathered from past years'
experience, to justify the logic.</Note>
    </Notes>
    <CVE>CVE-2025-37864</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: dsa: mv88e6xxx: fix -ENOENT when deleting VLANs and MST is unsupported

Russell King reports that on the ZII dev rev B, deleting a bridge VLAN
from a user port fails with -ENOENT:
https://lore.kernel.org/netdev/Z_lQXNP0s5-IiJzd@shell.armlinux.org.uk/

This comes from mv88e6xxx_port_vlan_leave() -&gt; mv88e6xxx_mst_put(),
which tries to find an MST entry in &amp;chip-&gt;msts associated with the SID,
but fails and returns -ENOENT as such.

But we know that this chip does not support MST at all, so that is not
surprising. The question is why does the guard in mv88e6xxx_mst_put()
not exit early:

	if (!sid)
		return 0;

And the answer seems to be simple: the sid comes from vlan.sid which
supposedly was previously populated by mv88e6xxx_vtu_get().
But some chip-&gt;info-&gt;ops-&gt;vtu_getnext() implementations do not populate
vlan.sid, for example see mv88e6185_g1_vtu_getnext(). In that case,
later in mv88e6xxx_port_vlan_leave() we are using a garbage sid which is
just residual stack memory.

Testing for sid == 0 covers all cases of a non-bridge VLAN or a bridge
VLAN mapped to the default MSTI. For some chips, SID 0 is valid and
installed by mv88e6xxx_stu_setup(). A chip which does not support the
STU would implicitly only support mapping all VLANs to the default MSTI,
so although SID 0 is not valid, it would be sufficient, if we were to
zero-initialize the vlan structure, to fix the bug, due to the
coincidence that a test for vlan.sid == 0 already exists and leads to
the same (correct) behavior.

Another option which would be sufficient would be to add a test for
mv88e6xxx_has_stu() inside mv88e6xxx_mst_put(), symmetric to the one
which already exists in mv88e6xxx_mst_get(). But that placement means
the caller will have to dereference vlan.sid, which means it will access
uninitialized memory, which is not nice even if it ignores it later.

So we end up making both modifications, in order to not rely just on the
sid == 0 coincidence, but also to avoid having uninitialized structure
fields which might get temporarily accessed.</Note>
    </Notes>
    <CVE>CVE-2025-37865</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/core: Silence oversized kvmalloc() warning

syzkaller triggered an oversized kvmalloc() warning.
Silence it by adding __GFP_NOWARN.

syzkaller log:
 WARNING: CPU: 7 PID: 518 at mm/util.c:665 __kvmalloc_node_noprof+0x175/0x180
 CPU: 7 UID: 0 PID: 518 Comm: c_repro Not tainted 6.11.0-rc6+ #6
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
 RIP: 0010:__kvmalloc_node_noprof+0x175/0x180
 RSP: 0018:ffffc90001e67c10 EFLAGS: 00010246
 RAX: 0000000000000100 RBX: 0000000000000400 RCX: ffffffff8149d46b
 RDX: 0000000000000000 RSI: ffff8881030fae80 RDI: 0000000000000002
 RBP: 000000712c800000 R08: 0000000000000100 R09: 0000000000000000
 R10: ffffc90001e67c10 R11: 0030ae0601000000 R12: 0000000000000000
 R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000000
 FS:  00007fde79159740(0000) GS:ffff88813bdc0000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000020000180 CR3: 0000000105eb4005 CR4: 00000000003706b0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
 Call Trace:
  &lt;TASK&gt;
  ib_umem_odp_get+0x1f6/0x390
  mlx5_ib_reg_user_mr+0x1e8/0x450
  ib_uverbs_reg_mr+0x28b/0x440
  ib_uverbs_write+0x7d3/0xa30
  vfs_write+0x1ac/0x6c0
  ksys_write+0x134/0x170
  ? __sanitizer_cov_trace_pc+0x1c/0x50
  do_syscall_64+0x50/0x110
  entry_SYSCALL_64_after_hwframe+0x76/0x7e</Note>
    </Notes>
    <CVE>CVE-2025-37867</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/xe/userptr: fix notifier vs folio deadlock

User is reporting what smells like notifier vs folio deadlock, where
migrate_pages_batch() on core kernel side is holding folio lock(s) and
then interacting with the mappings of it, however those mappings are
tied to some userptr, which means calling into the notifier callback and
grabbing the notifier lock. With perfect timing it looks possible that
the pages we pulled from the hmm fault can get sniped by
migrate_pages_batch() at the same time that we are holding the notifier
lock to mark the pages as accessed/dirty, but at this point we also want
to grab the folio locks(s) to mark them as dirty, but if they are
contended from notifier/migrate_pages_batch side then we deadlock since
folio lock won't be dropped until we drop the notifier lock.

Fortunately the mark_page_accessed/dirty is not really needed in the
first place it seems and should have already been done by hmm fault, so
just remove it.

(cherry picked from commit bd7c0cb695e87c0e43247be8196b4919edbe0e85)</Note>
    </Notes>
    <CVE>CVE-2025-37868</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/xe: Use local fence in error path of xe_migrate_clear

The intent of the error path in xe_migrate_clear is to wait on locally
generated fence and then return. The code is waiting on m-&gt;fence which
could be the local fence but this is only stable under the job mutex
leading to a possible UAF. Fix code to wait on local fence.

(cherry picked from commit 762b7e95362170b3e13a8704f38d5e47eca4ba74)</Note>
    </Notes>
    <CVE>CVE-2025-37869</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nfsd: decrease sc_count directly if fail to queue dl_recall

A deadlock warning occurred when invoking nfs4_put_stid following a failed
dl_recall queue operation:
            T1                            T2
                                nfs4_laundromat
                                 nfs4_get_client_reaplist
                                  nfs4_anylock_blockers
__break_lease
 spin_lock // ctx-&gt;flc_lock
                                   spin_lock // clp-&gt;cl_lock
                                   nfs4_lockowner_has_blockers
                                    locks_owner_has_blockers
                                     spin_lock // flctx-&gt;flc_lock
 nfsd_break_deleg_cb
  nfsd_break_one_deleg
   nfs4_put_stid
    refcount_dec_and_lock
     spin_lock // clp-&gt;cl_lock

When a file is opened, an nfs4_delegation is allocated with sc_count
initialized to 1, and the file_lease holds a reference to the delegation.
The file_lease is then associated with the file through kernel_setlease.

The disassociation is performed in nfsd4_delegreturn via the following
call chain:
nfsd4_delegreturn --&gt; destroy_delegation --&gt; destroy_unhashed_deleg --&gt;
nfs4_unlock_deleg_lease --&gt; kernel_setlease --&gt; generic_delete_lease
The corresponding sc_count reference will be released after this
disassociation.

Since nfsd_break_one_deleg executes while holding the flc_lock, the
disassociation process becomes blocked when attempting to acquire flc_lock
in generic_delete_lease. This means:
1) sc_count in nfsd_break_one_deleg will not be decremented to 0;
2) The nfs4_put_stid called by nfsd_break_one_deleg will not attempt to
acquire cl_lock;
3) Consequently, no deadlock condition is created.

Given that sc_count in nfsd_break_one_deleg remains non-zero, we can
safely perform refcount_dec on sc_count directly. This approach
effectively avoids triggering deadlock warnings.</Note>
    </Notes>
    <CVE>CVE-2025-37871</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

eth: bnxt: fix missing ring index trim on error path

Commit under Fixes converted tx_prod to be free running but missed
masking it on the Tx error path. This crashes on error conditions,
for example when DMA mapping fails.</Note>
    </Notes>
    <CVE>CVE-2025-37873</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: ngbe: fix memory leak in ngbe_probe() error path

When ngbe_sw_init() is called, memory is allocated for wx-&gt;rss_key
in wx_init_rss_key(). However, in ngbe_probe() function, the subsequent
error paths after ngbe_sw_init() don't free the rss_key. Fix that by
freeing it in error path along with wx-&gt;mac_table.

Also change the label to which execution jumps when ngbe_sw_init()
fails, because otherwise, it could lead to a double free for rss_key,
when the mac_table allocation fails in wx_sw_init().</Note>
    </Notes>
    <CVE>CVE-2025-37874</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

igc: fix PTM cycle trigger logic

Writing to clear the PTM status 'valid' bit while the PTM cycle is
triggered results in unreliable PTM operation. To fix this, clear the
PTM 'trigger' and status after each PTM transaction.

The issue can be reproduced with the following:

$ sudo phc2sys -R 1000 -O 0 -i tsn0 -m

Note: 1000 Hz (-R 1000) is unrealistically large, but provides a way to
quickly reproduce the issue.

PHC2SYS exits with:

"ioctl PTP_OFFSET_PRECISE: Connection timed out" when the PTM transaction
  fails

This patch also fixes a hang in igc_probe() when loading the igc
driver in the kdump kernel on systems supporting PTM.

The igc driver running in the base kernel enables PTM trigger in
igc_probe().  Therefore the driver is always in PTM trigger mode,
except in brief periods when manually triggering a PTM cycle.

When a crash occurs, the NIC is reset while PTM trigger is enabled.
Due to a hardware problem, the NIC is subsequently in a bad busmaster
state and doesn't handle register reads/writes.  When running
igc_probe() in the kdump kernel, the first register access to a NIC
register hangs driver probing and ultimately breaks kdump.

With this patch, igc has PTM trigger disabled most of the time,
and the trigger is only enabled for very brief (10 - 100 us) periods
when manually triggering a PTM cycle.  Chances that a crash occurs
during a PTM trigger are not 0, but extremely reduced.</Note>
    </Notes>
    <CVE>CVE-2025-37875</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: aspeed: Add NULL pointer check in ast_vhub_init_dev()

The variable d-&gt;name, returned by devm_kasprintf(), could be NULL.
A pointer check is added to prevent potential NULL pointer dereference.
This is similar to the fix in commit 3027e7b15b02
("ice: Fix some null pointer dereference issues in ice_ptp.c").

This issue is found by our static analysis tool</Note>
    </Notes>
    <CVE>CVE-2025-37881</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix deadlock between rcu_tasks_trace and event_mutex.

Fix the following deadlock:
CPU A
_free_event()
  perf_kprobe_destroy()
    mutex_lock(&amp;event_mutex)
      perf_trace_event_unreg()
        synchronize_rcu_tasks_trace()

There are several paths where _free_event() grabs event_mutex
and calls sync_rcu_tasks_trace. Above is one such case.

CPU B
bpf_prog_test_run_syscall()
  rcu_read_lock_trace()
    bpf_prog_run_pin_on_cpu()
      bpf_prog_load()
        bpf_tracing_func_proto()
          trace_set_clr_event()
            mutex_lock(&amp;event_mutex)

Delegate trace_set_clr_event() to workqueue to avoid
such lock dependency.</Note>
    </Notes>
    <CVE>CVE-2025-37884</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

KVM: x86: Reset IRTE to host control if *new* route isn't postable

Restore an IRTE back to host control (remapped or posted MSI mode) if the
*new* GSI route prevents posting the IRQ directly to a vCPU, regardless of
the GSI routing type.  Updating the IRTE if and only if the new GSI is an
MSI results in KVM leaving an IRTE posting to a vCPU.

The dangling IRTE can result in interrupts being incorrectly delivered to
the guest, and in the worst case scenario can result in use-after-free,
e.g. if the VM is torn down, but the underlying host IRQ isn't freed.</Note>
    </Notes>
    <CVE>CVE-2025-37885</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/mlx5: Fix null-ptr-deref in mlx5_create_{inner_,}ttc_table()

Add NULL check for mlx5_get_flow_namespace() returns in
mlx5_create_inner_ttc_table() and mlx5_create_ttc_table() to prevent
NULL pointer dereference.</Note>
    </Notes>
    <CVE>CVE-2025-37888</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ASoC: ops: Consistently treat platform_max as control value

This reverts commit 9bdd10d57a88 ("ASoC: ops: Shift tested values in
snd_soc_put_volsw() by +min"), and makes some additional related
updates.

There are two ways the platform_max could be interpreted; the maximum
register value, or the maximum value the control can be set to. The
patch moved from treating the value as a control value to a register
one. When the patch was applied it was technically correct as
snd_soc_limit_volume() also used the register interpretation. However,
even then most of the other usages treated platform_max as a
control value, and snd_soc_limit_volume() has since been updated to
also do so in commit fb9ad24485087 ("ASoC: ops: add correct range
check for limiting volume"). That patch however, missed updating
snd_soc_put_volsw() back to the control interpretation, and fixing
snd_soc_info_volsw_range(). The control interpretation makes more
sense as limiting is typically done from the machine driver, so it is
appropriate to use the customer facing representation rather than the
internal codec representation. Update all the code to consistently use
this interpretation of platform_max.

Finally, also add some comments to the soc_mixer_control struct to
hopefully avoid further patches switching between the two approaches.</Note>
    </Notes>
    <CVE>CVE-2025-37889</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net_sched: hfsc: Fix a UAF vulnerability in class with netem as child qdisc

As described in Gerrard's report [1], we have a UAF case when an hfsc class
has a netem child qdisc. The crux of the issue is that hfsc is assuming
that checking for cl-&gt;qdisc-&gt;q.qlen == 0 guarantees that it hasn't inserted
the class in the vttree or eltree (which is not true for the netem
duplicate case).

This patch checks the n_active class variable to make sure that the code
won't insert the class in the vttree or eltree twice, catering for the
reentrant case.

[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/</Note>
    </Notes>
    <CVE>CVE-2025-37890</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ALSA: ump: Fix buffer overflow at UMP SysEx message conversion

The conversion function from MIDI 1.0 to UMP packet contains an
internal buffer to keep the incoming MIDI bytes, and its size is 4, as
it was supposed to be the max size for a MIDI1 UMP packet data.
However, the implementation overlooked that SysEx is handled in a
different format, and it can be up to 6 bytes, as found in
do_convert_to_ump().  It leads eventually to a buffer overflow, and
may corrupt the memory when a longer SysEx message is received.

The fix is simply to extend the buffer size to 6 to fit with the SysEx
UMP message.</Note>
    </Notes>
    <CVE>CVE-2025-37891</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mtd: inftlcore: Add error check for inftl_read_oob()

In INFTL_findwriteunit(), the return value of inftl_read_oob()
need to be checked. A proper implementation can be
found in INFTL_deleteblock(). The status will be set as
SECTOR_IGNORE to break from the while-loop correctly
if the inftl_read_oob() fails.</Note>
    </Notes>
    <CVE>CVE-2025-37892</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: plfxlc: Remove erroneous assert in plfxlc_mac_release

plfxlc_mac_release() asserts that mac-&gt;lock is held. This assertion is
incorrect, because even if it was possible, it would not be the valid
behaviour. The function is used when probe fails or after the device is
disconnected. In both cases mac-&gt;lock can not be held as the driver is
not working with the device at the moment. All functions that use mac-&gt;lock
unlock it just after it was held. There is also no need to hold mac-&gt;lock
for plfxlc_mac_release() itself, as mac data is not affected, except for
mac-&gt;flags, which is modified atomically.

This bug leads to the following warning:
================================================================
WARNING: CPU: 0 PID: 127 at drivers/net/wireless/purelifi/plfxlc/mac.c:106 plfxlc_mac_release+0x7d/0xa0
Modules linked in:
CPU: 0 PID: 127 Comm: kworker/0:2 Not tainted 6.1.124-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Workqueue: usb_hub_wq hub_event
RIP: 0010:plfxlc_mac_release+0x7d/0xa0 drivers/net/wireless/purelifi/plfxlc/mac.c:106
Call Trace:
 &lt;TASK&gt;
 probe+0x941/0xbd0 drivers/net/wireless/purelifi/plfxlc/usb.c:694
 usb_probe_interface+0x5c0/0xaf0 drivers/usb/core/driver.c:396
 really_probe+0x2ab/0xcb0 drivers/base/dd.c:639
 __driver_probe_device+0x1a2/0x3d0 drivers/base/dd.c:785
 driver_probe_device+0x50/0x420 drivers/base/dd.c:815
 __device_attach_driver+0x2cf/0x510 drivers/base/dd.c:943
 bus_for_each_drv+0x183/0x200 drivers/base/bus.c:429
 __device_attach+0x359/0x570 drivers/base/dd.c:1015
 bus_probe_device+0xba/0x1e0 drivers/base/bus.c:489
 device_add+0xb48/0xfd0 drivers/base/core.c:3696
 usb_set_configuration+0x19dd/0x2020 drivers/usb/core/message.c:2165
 usb_generic_driver_probe+0x84/0x140 drivers/usb/core/generic.c:238
 usb_probe_device+0x130/0x260 drivers/usb/core/driver.c:293
 really_probe+0x2ab/0xcb0 drivers/base/dd.c:639
 __driver_probe_device+0x1a2/0x3d0 drivers/base/dd.c:785
 driver_probe_device+0x50/0x420 drivers/base/dd.c:815
 __device_attach_driver+0x2cf/0x510 drivers/base/dd.c:943
 bus_for_each_drv+0x183/0x200 drivers/base/bus.c:429
 __device_attach+0x359/0x570 drivers/base/dd.c:1015
 bus_probe_device+0xba/0x1e0 drivers/base/bus.c:489
 device_add+0xb48/0xfd0 drivers/base/core.c:3696
 usb_new_device+0xbdd/0x18f0 drivers/usb/core/hub.c:2620
 hub_port_connect drivers/usb/core/hub.c:5477 [inline]
 hub_port_connect_change drivers/usb/core/hub.c:5617 [inline]
 port_event drivers/usb/core/hub.c:5773 [inline]
 hub_event+0x2efe/0x5730 drivers/usb/core/hub.c:5855
 process_one_work+0x8a9/0x11d0 kernel/workqueue.c:2292
 worker_thread+0xa47/0x1200 kernel/workqueue.c:2439
 kthread+0x28d/0x320 kernel/kthread.c:376
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295
 &lt;/TASK&gt;
================================================================

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.</Note>
    </Notes>
    <CVE>CVE-2025-37897</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iommu: Fix two issues in iommu_copy_struct_from_user()

In the review for iommu_copy_struct_to_user() helper, Matt pointed out that
a NULL pointer should be rejected prior to dereferencing it:
https://lore.kernel.org/all/86881827-8E2D-461C-BDA3-FA8FD14C343C@nvidia.com

And Alok pointed out a typo at the same time:
https://lore.kernel.org/all/480536af-6830-43ce-a327-adbd13dc3f1d@oracle.com

Since both issues were copied from iommu_copy_struct_from_user(), fix them
first in the current header.</Note>
    </Notes>
    <CVE>CVE-2025-37900</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

irqchip/qcom-mpm: Prevent crash when trying to handle non-wake GPIOs

On Qualcomm chipsets not all GPIOs are wakeup capable. Those GPIOs do not
have a corresponding MPM pin and should not be handled inside the MPM
driver. The IRQ domain hierarchy is always applied, so it's required to
explicitly disconnect the hierarchy for those. The pinctrl-msm driver marks
these with GPIO_NO_WAKE_IRQ. qcom-pdc has a check for this, but
irq-qcom-mpm is currently missing the check. This is causing crashes when
setting up interrupts for non-wake GPIOs:

 root@rb1:~# gpiomon -c gpiochip1 10
   irq: IRQ159: trimming hierarchy from :soc@0:interrupt-controller@f200000-1
   Unable to handle kernel paging request at virtual address ffff8000a1dc3820
   Hardware name: Qualcomm Technologies, Inc. Robotics RB1 (DT)
   pc : mpm_set_type+0x80/0xcc
   lr : mpm_set_type+0x5c/0xcc
   Call trace:
    mpm_set_type+0x80/0xcc (P)
    qcom_mpm_set_type+0x64/0x158
    irq_chip_set_type_parent+0x20/0x38
    msm_gpio_irq_set_type+0x50/0x530
    __irq_set_trigger+0x60/0x184
    __setup_irq+0x304/0x6bc
    request_threaded_irq+0xc8/0x19c
    edge_detector_setup+0x260/0x364
    linereq_create+0x420/0x5a8
    gpio_ioctl+0x2d4/0x6c0

Fix this by copying the check for GPIO_NO_WAKE_IRQ from qcom-pdc.c, so that
MPM is removed entirely from the hierarchy for non-wake GPIOs.</Note>
    </Notes>
    <CVE>CVE-2025-37901</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix slab-use-after-free in hdcp

The HDCP code in amdgpu_dm_hdcp.c copies pointers to amdgpu_dm_connector
objects without incrementing the kref reference counts. When using a
USB-C dock, and the dock is unplugged, the corresponding
amdgpu_dm_connector objects are freed, creating dangling pointers in the
HDCP code. When the dock is plugged back, the dangling pointers are
dereferenced, resulting in a slab-use-after-free:

[   66.775837] BUG: KASAN: slab-use-after-free in event_property_validate+0x42f/0x6c0 [amdgpu]
[   66.776171] Read of size 4 at addr ffff888127804120 by task kworker/0:1/10

[   66.776179] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.14.0-rc7-00180-g54505f727a38-dirty #233
[   66.776183] Hardware name: HP HP Pavilion Aero Laptop 13-be0xxx/8916, BIOS F.17 12/18/2024
[   66.776186] Workqueue: events event_property_validate [amdgpu]
[   66.776494] Call Trace:
[   66.776496]  &lt;TASK&gt;
[   66.776497]  dump_stack_lvl+0x70/0xa0
[   66.776504]  print_report+0x175/0x555
[   66.776507]  ? __virt_addr_valid+0x243/0x450
[   66.776510]  ? kasan_complete_mode_report_info+0x66/0x1c0
[   66.776515]  kasan_report+0xeb/0x1c0
[   66.776518]  ? event_property_validate+0x42f/0x6c0 [amdgpu]
[   66.776819]  ? event_property_validate+0x42f/0x6c0 [amdgpu]
[   66.777121]  __asan_report_load4_noabort+0x14/0x20
[   66.777124]  event_property_validate+0x42f/0x6c0 [amdgpu]
[   66.777342]  ? __lock_acquire+0x6b40/0x6b40
[   66.777347]  ? enable_assr+0x250/0x250 [amdgpu]
[   66.777571]  process_one_work+0x86b/0x1510
[   66.777575]  ? pwq_dec_nr_in_flight+0xcf0/0xcf0
[   66.777578]  ? assign_work+0x16b/0x280
[   66.777580]  ? lock_is_held_type+0xa3/0x130
[   66.777583]  worker_thread+0x5c0/0xfa0
[   66.777587]  ? process_one_work+0x1510/0x1510
[   66.777588]  kthread+0x3a2/0x840
[   66.777591]  ? kthread_is_per_cpu+0xd0/0xd0
[   66.777594]  ? trace_hardirqs_on+0x4f/0x60
[   66.777597]  ? _raw_spin_unlock_irq+0x27/0x60
[   66.777599]  ? calculate_sigpending+0x77/0xa0
[   66.777602]  ? kthread_is_per_cpu+0xd0/0xd0
[   66.777605]  ret_from_fork+0x40/0x90
[   66.777607]  ? kthread_is_per_cpu+0xd0/0xd0
[   66.777609]  ret_from_fork_asm+0x11/0x20
[   66.777614]  &lt;/TASK&gt;

[   66.777643] Allocated by task 10:
[   66.777646]  kasan_save_stack+0x39/0x60
[   66.777649]  kasan_save_track+0x14/0x40
[   66.777652]  kasan_save_alloc_info+0x37/0x50
[   66.777655]  __kasan_kmalloc+0xbb/0xc0
[   66.777658]  __kmalloc_cache_noprof+0x1c8/0x4b0
[   66.777661]  dm_dp_add_mst_connector+0xdd/0x5c0 [amdgpu]
[   66.777880]  drm_dp_mst_port_add_connector+0x47e/0x770 [drm_display_helper]
[   66.777892]  drm_dp_send_link_address+0x1554/0x2bf0 [drm_display_helper]
[   66.777901]  drm_dp_check_and_send_link_address+0x187/0x1f0 [drm_display_helper]
[   66.777909]  drm_dp_mst_link_probe_work+0x2b8/0x410 [drm_display_helper]
[   66.777917]  process_one_work+0x86b/0x1510
[   66.777919]  worker_thread+0x5c0/0xfa0
[   66.777922]  kthread+0x3a2/0x840
[   66.777925]  ret_from_fork+0x40/0x90
[   66.777927]  ret_from_fork_asm+0x11/0x20

[   66.777932] Freed by task 1713:
[   66.777935]  kasan_save_stack+0x39/0x60
[   66.777938]  kasan_save_track+0x14/0x40
[   66.777940]  kasan_save_free_info+0x3b/0x60
[   66.777944]  __kasan_slab_free+0x52/0x70
[   66.777946]  kfree+0x13f/0x4b0
[   66.777949]  dm_dp_mst_connector_destroy+0xfa/0x150 [amdgpu]
[   66.778179]  drm_connector_free+0x7d/0xb0
[   66.778184]  drm_mode_object_put.part.0+0xee/0x160
[   66.778188]  drm_mode_object_put+0x37/0x50
[   66.778191]  drm_atomic_state_default_clear+0x220/0xd60
[   66.778194]  __drm_atomic_state_free+0x16e/0x2a0
[   66.778197]  drm_mode_atomic_ioctl+0x15ed/0x2ba0
[   66.778200]  drm_ioctl_kernel+0x17a/0x310
[   66.778203]  drm_ioctl+0x584/0xd10
[   66.778206]  amdgpu_drm_ioctl+0xd2/0x1c0 [amdgpu]
[   66.778375]  __x64_sys_ioctl+0x139/0x1a0
[   66.778378]  x64_sys_call+0xee7/0xfb0
[   66.778381] 
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-37903</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

firmware: arm_scmi: Balance device refcount when destroying devices

Using device_find_child() to lookup the proper SCMI device to destroy
causes an unbalance in device refcount, since device_find_child() calls an
implicit get_device(): this, in turns, inhibits the call of the provided
release methods upon devices destruction.

As a consequence, one of the structures that is not freed properly upon
destruction is the internal struct device_private dev-&gt;p populated by the
drivers subsystem core.

KMemleak detects this situation since loading/unloding some SCMI driver
causes related devices to be created/destroyed without calling any
device_release method.

unreferenced object 0xffff00000f583800 (size 512):
  comm "insmod", pid 227, jiffies 4294912190
  hex dump (first 32 bytes):
    00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00  .....N..........
    ff ff ff ff ff ff ff ff 60 36 1d 8a 00 80 ff ff  ........`6......
  backtrace (crc 114e2eed):
    kmemleak_alloc+0xbc/0xd8
    __kmalloc_cache_noprof+0x2dc/0x398
    device_add+0x954/0x12d0
    device_register+0x28/0x40
    __scmi_device_create.part.0+0x1bc/0x380
    scmi_device_create+0x2d0/0x390
    scmi_create_protocol_devices+0x74/0xf8
    scmi_device_request_notifier+0x1f8/0x2a8
    notifier_call_chain+0x110/0x3b0
    blocking_notifier_call_chain+0x70/0xb0
    scmi_driver_register+0x350/0x7f0
    0xffff80000a3b3038
    do_one_initcall+0x12c/0x730
    do_init_module+0x1dc/0x640
    load_module+0x4b20/0x5b70
    init_module_from_file+0xec/0x158

$ ./scripts/faddr2line ./vmlinux device_add+0x954/0x12d0
device_add+0x954/0x12d0:
kmalloc_noprof at include/linux/slab.h:901
(inlined by) kzalloc_noprof at include/linux/slab.h:1037
(inlined by) device_private_init at drivers/base/core.c:3510
(inlined by) device_add at drivers/base/core.c:3561

Balance device refcount by issuing a put_device() on devices found via
device_find_child().</Note>
    </Notes>
    <CVE>CVE-2025-37905</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: lan743x: Fix memleak issue when GSO enabled

Always map the `skb` to the LS descriptor. Previously skb was
mapped to EXT descriptor when the number of fragments is zero with
GSO enabled. Mapping the skb to EXT descriptor prevents it from
being freed, leading to a memory leak</Note>
    </Notes>
    <CVE>CVE-2025-37909</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bnxt_en: Fix out-of-bound memcpy() during ethtool -w

When retrieving the FW coredump using ethtool, it can sometimes cause
memory corruption:

BUG: KFENCE: memory corruption in __bnxt_get_coredump+0x3ef/0x670 [bnxt_en]
Corrupted memory at 0x000000008f0f30e8 [ ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ] (in kfence-#45):
__bnxt_get_coredump+0x3ef/0x670 [bnxt_en]
ethtool_get_dump_data+0xdc/0x1a0
__dev_ethtool+0xa1e/0x1af0
dev_ethtool+0xa8/0x170
dev_ioctl+0x1b5/0x580
sock_do_ioctl+0xab/0xf0
sock_ioctl+0x1ce/0x2e0
__x64_sys_ioctl+0x87/0xc0
do_syscall_64+0x5c/0xf0
entry_SYSCALL_64_after_hwframe+0x78/0x80

...

This happens when copying the coredump segment list in
bnxt_hwrm_dbg_dma_data() with the HWRM_DBG_COREDUMP_LIST FW command.
The info-&gt;dest_buf buffer is allocated based on the number of coredump
segments returned by the FW.  The segment list is then DMA'ed by
the FW and the length of the DMA is returned by FW.  The driver then
copies this DMA'ed segment list to info-&gt;dest_buf.

In some cases, this DMA length may exceed the info-&gt;dest_buf length
and cause the above BUG condition.  Fix it by capping the copy
length to not exceed the length of info-&gt;dest_buf.  The extra
DMA data contains no useful information.

This code path is shared for the HWRM_DBG_COREDUMP_LIST and the
HWRM_DBG_COREDUMP_RETRIEVE FW commands.  The buffering is different
for these 2 FW commands.  To simplify the logic, we need to move
the line to adjust the buffer length for HWRM_DBG_COREDUMP_RETRIEVE
up, so that the new check to cap the copy length will work for both
commands.</Note>
    </Notes>
    <CVE>CVE-2025-37911</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ice: Check VF VSI Pointer Value in ice_vc_add_fdir_fltr()

As mentioned in the commit baeb705fd6a7 ("ice: always check VF VSI
pointer values"), we need to perform a null pointer check on the return
value of ice_get_vf_vsi() before using it.</Note>
    </Notes>
    <CVE>CVE-2025-37912</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net_sched: qfq: Fix double list add in class with netem as child qdisc

As described in Gerrard's report [1], there are use cases where a netem
child qdisc will make the parent qdisc's enqueue callback reentrant.
In the case of qfq, there won't be a UAF, but the code will add the same
classifier to the list twice, which will cause memory corruption.

This patch checks whether the class was already added to the agg-&gt;active
list (cl_is_active) before doing the addition to cater for the reentrant
case.

[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/</Note>
    </Notes>
    <CVE>CVE-2025-37913</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net_sched: ets: Fix double list add in class with netem as child qdisc

As described in Gerrard's report [1], there are use cases where a netem
child qdisc will make the parent qdisc's enqueue callback reentrant.
In the case of ets, there won't be a UAF, but the code will add the same
classifier to the list twice, which will cause memory corruption.

In addition to checking for qlen being zero, this patch checks whether
the class was already added to the active_list (cl_is_active) before
doing the addition to cater for the reentrant case.

[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/</Note>
    </Notes>
    <CVE>CVE-2025-37914</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net_sched: drr: Fix double list add in class with netem as child qdisc

As described in Gerrard's report [1], there are use cases where a netem
child qdisc will make the parent qdisc's enqueue callback reentrant.
In the case of drr, there won't be a UAF, but the code will add the same
classifier to the list twice, which will cause memory corruption.

In addition to checking for qlen being zero, this patch checks whether the
class was already added to the active_list (cl_is_active) before adding
to the list to cover for the reentrant case.

[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/</Note>
    </Notes>
    <CVE>CVE-2025-37915</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: ethernet: mtk-star-emac: fix spinlock recursion issues on rx/tx poll

Use spin_lock_irqsave and spin_unlock_irqrestore instead of spin_lock
and spin_unlock in mtk_star_emac driver to avoid spinlock recursion
occurrence that can happen when enabling the DMA interrupts again in
rx/tx poll.

```
BUG: spinlock recursion on CPU#0, swapper/0/0
 lock: 0xffff00000db9cf20, .magic: dead4ead, .owner: swapper/0/0,
    .owner_cpu: 0
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted
    6.15.0-rc2-next-20250417-00001-gf6a27738686c-dirty #28 PREEMPT
Hardware name: MediaTek MT8365 Open Platform EVK (DT)
Call trace:
 show_stack+0x18/0x24 (C)
 dump_stack_lvl+0x60/0x80
 dump_stack+0x18/0x24
 spin_dump+0x78/0x88
 do_raw_spin_lock+0x11c/0x120
 _raw_spin_lock+0x20/0x2c
 mtk_star_handle_irq+0xc0/0x22c [mtk_star_emac]
 __handle_irq_event_percpu+0x48/0x140
 handle_irq_event+0x4c/0xb0
 handle_fasteoi_irq+0xa0/0x1bc
 handle_irq_desc+0x34/0x58
 generic_handle_domain_irq+0x1c/0x28
 gic_handle_irq+0x4c/0x120
 do_interrupt_handler+0x50/0x84
 el1_interrupt+0x34/0x68
 el1h_64_irq_handler+0x18/0x24
 el1h_64_irq+0x6c/0x70
 regmap_mmio_read32le+0xc/0x20 (P)
 _regmap_bus_reg_read+0x6c/0xac
 _regmap_read+0x60/0xdc
 regmap_read+0x4c/0x80
 mtk_star_rx_poll+0x2f4/0x39c [mtk_star_emac]
 __napi_poll+0x38/0x188
 net_rx_action+0x164/0x2c0
 handle_softirqs+0x100/0x244
 __do_softirq+0x14/0x20
 ____do_softirq+0x10/0x20
 call_on_irq_stack+0x24/0x64
 do_softirq_own_stack+0x1c/0x40
 __irq_exit_rcu+0xd4/0x10c
 irq_exit_rcu+0x10/0x1c
 el1_interrupt+0x38/0x68
 el1h_64_irq_handler+0x18/0x24
 el1h_64_irq+0x6c/0x70
 cpuidle_enter_state+0xac/0x320 (P)
 cpuidle_enter+0x38/0x50
 do_idle+0x1e4/0x260
 cpu_startup_entry+0x34/0x3c
 rest_init+0xdc/0xe0
 console_on_rootfs+0x0/0x6c
 __primary_switched+0x88/0x90
```</Note>
    </Notes>
    <CVE>CVE-2025-37917</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: btusb: avoid NULL pointer dereference in skb_dequeue()

A NULL pointer dereference can occur in skb_dequeue() when processing a
QCA firmware crash dump on WCN7851 (0489:e0f3).

[ 93.672166] Bluetooth: hci0: ACL memdump size(589824)

[ 93.672475] BUG: kernel NULL pointer dereference, address: 0000000000000008
[ 93.672517] Workqueue: hci0 hci_devcd_rx [bluetooth]
[ 93.672598] RIP: 0010:skb_dequeue+0x50/0x80

The issue stems from handle_dump_pkt_qca() returning 0 even when a dump
packet is successfully processed. This is because it incorrectly
forwards the return value of hci_devcd_init() (which returns 0 on
success). As a result, the caller (btusb_recv_acl_qca() or
btusb_recv_evt_qca()) assumes the packet was not handled and passes it
to hci_recv_frame(), leading to premature kfree() of the skb.

Later, hci_devcd_rx() attempts to dequeue the same skb from the dump
queue, resulting in a NULL pointer dereference.

Fix this by:
1. Making handle_dump_pkt_qca() return 0 on success and negative errno
   on failure, consistent with kernel conventions.
2. Splitting dump packet detection into separate functions for ACL
   and event packets for better structure and readability.

This ensures dump packets are properly identified and consumed, avoiding
double handling and preventing NULL pointer access.</Note>
    </Notes>
    <CVE>CVE-2025-37918</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

xsk: Fix race condition in AF_XDP generic RX path

Move rx_lock from xsk_socket to xsk_buff_pool.
Fix synchronization for shared umem mode in
generic RX path where multiple sockets share
single xsk_buff_pool.

RX queue is exclusive to xsk_socket, while FILL
queue can be shared between multiple sockets.
This could result in race condition where two
CPU cores access RX path of two different sockets
sharing the same umem.

Protect both queues by acquiring spinlock in shared
xsk_buff_pool.

Lock contention may be minimized in the future by some
per-thread FQ buffering.

It's safe and necessary to move spin_lock_bh(rx_lock)
after xsk_rcv_check():
* xs-&gt;pool and spinlock_init is synchronized by
  xsk_bind() -&gt; xsk_is_bound() memory barriers.
* xsk_rcv_check() may return true at the moment
  of xsk_release() or xsk_unbind_dev(),
  however this will not cause any data races or
  race conditions. xsk_unbind_dev() removes xdp
  socket from all maps and waits for completion
  of all outstanding rx operations. Packets in
  RX path will either complete safely or drop.</Note>
    </Notes>
    <CVE>CVE-2025-37920</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vxlan: vnifilter: Fix unlocked deletion of default FDB entry

When a VNI is deleted from a VXLAN device in 'vnifilter' mode, the FDB
entry associated with the default remote (assuming one was configured)
is deleted without holding the hash lock. This is wrong and will result
in a warning [1] being generated by the lockdep annotation that was
added by commit ebe642067455 ("vxlan: Create wrappers for FDB lookup").

Reproducer:

 # ip link add vx0 up type vxlan dstport 4789 external vnifilter local 192.0.2.1
 # bridge vni add vni 10010 remote 198.51.100.1 dev vx0
 # bridge vni del vni 10010 dev vx0

Fix by acquiring the hash lock before the deletion and releasing it
afterwards. Blame the original commit that introduced the issue rather
than the one that exposed it.

[1]
WARNING: CPU: 3 PID: 392 at drivers/net/vxlan/vxlan_core.c:417 vxlan_find_mac+0x17f/0x1a0
[...]
RIP: 0010:vxlan_find_mac+0x17f/0x1a0
[...]
Call Trace:
 &lt;TASK&gt;
 __vxlan_fdb_delete+0xbe/0x560
 vxlan_vni_delete_group+0x2ba/0x940
 vxlan_vni_del.isra.0+0x15f/0x580
 vxlan_process_vni_filter+0x38b/0x7b0
 vxlan_vnifilter_process+0x3bb/0x510
 rtnetlink_rcv_msg+0x2f7/0xb70
 netlink_rcv_skb+0x131/0x360
 netlink_unicast+0x426/0x710
 netlink_sendmsg+0x75a/0xc20
 __sock_sendmsg+0xc1/0x150
 ____sys_sendmsg+0x5aa/0x7b0
 ___sys_sendmsg+0xfc/0x180
 __sys_sendmsg+0x121/0x1b0
 do_syscall_64+0xbb/0x1d0
 entry_SYSCALL_64_after_hwframe+0x4b/0x53</Note>
    </Notes>
    <CVE>CVE-2025-37921</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tracing: Fix oob write in trace_seq_to_buffer()

syzbot reported this bug:
==================================================================
BUG: KASAN: slab-out-of-bounds in trace_seq_to_buffer kernel/trace/trace.c:1830 [inline]
BUG: KASAN: slab-out-of-bounds in tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822
Write of size 4507 at addr ffff888032b6b000 by task syz.2.320/7260

CPU: 1 UID: 0 PID: 7260 Comm: syz.2.320 Not tainted 6.15.0-rc1-syzkaller-00301-g3bde70a2c827 #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:408 [inline]
 print_report+0xc3/0x670 mm/kasan/report.c:521
 kasan_report+0xe0/0x110 mm/kasan/report.c:634
 check_region_inline mm/kasan/generic.c:183 [inline]
 kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189
 __asan_memcpy+0x3c/0x60 mm/kasan/shadow.c:106
 trace_seq_to_buffer kernel/trace/trace.c:1830 [inline]
 tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822
 ....
==================================================================

It has been reported that trace_seq_to_buffer() tries to copy more data
than PAGE_SIZE to buf. Therefore, to prevent this, we should use the
smaller of trace_seq_used(&amp;iter-&gt;seq) and PAGE_SIZE as an argument.</Note>
    </Notes>
    <CVE>CVE-2025-37923</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

jfs: reject on-disk inodes of an unsupported type

Syzbot has reported the following BUG:

kernel BUG at fs/inode.c:668!
Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 3 UID: 0 PID: 139 Comm: jfsCommit Not tainted 6.12.0-rc4-syzkaller-00085-g4e46774408d9 #0
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014
RIP: 0010:clear_inode+0x168/0x190
Code: 4c 89 f7 e8 ba fe e5 ff e9 61 ff ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 7c c1 4c 89 f7 e8 90 ff e5 ff eb b7
 0b e8 01 5d 7f ff 90 0f 0b e8 f9 5c 7f ff 90 0f 0b e8 f1 5c 7f
RSP: 0018:ffffc900027dfae8 EFLAGS: 00010093
RAX: ffffffff82157a87 RBX: 0000000000000001 RCX: ffff888104d4b980
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
RBP: ffffc900027dfc90 R08: ffffffff82157977 R09: fffff520004fbf38
R10: dffffc0000000000 R11: fffff520004fbf38 R12: dffffc0000000000
R13: ffff88811315bc00 R14: ffff88811315bda8 R15: ffff88811315bb80
FS:  0000000000000000(0000) GS:ffff888135f00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005565222e0578 CR3: 0000000026ef0000 CR4: 00000000000006f0
Call Trace:
 &lt;TASK&gt;
 ? __die_body+0x5f/0xb0
 ? die+0x9e/0xc0
 ? do_trap+0x15a/0x3a0
 ? clear_inode+0x168/0x190
 ? do_error_trap+0x1dc/0x2c0
 ? clear_inode+0x168/0x190
 ? __pfx_do_error_trap+0x10/0x10
 ? report_bug+0x3cd/0x500
 ? handle_invalid_op+0x34/0x40
 ? clear_inode+0x168/0x190
 ? exc_invalid_op+0x38/0x50
 ? asm_exc_invalid_op+0x1a/0x20
 ? clear_inode+0x57/0x190
 ? clear_inode+0x167/0x190
 ? clear_inode+0x168/0x190
 ? clear_inode+0x167/0x190
 jfs_evict_inode+0xb5/0x440
 ? __pfx_jfs_evict_inode+0x10/0x10
 evict+0x4ea/0x9b0
 ? __pfx_evict+0x10/0x10
 ? iput+0x713/0xa50
 txUpdateMap+0x931/0xb10
 ? __pfx_txUpdateMap+0x10/0x10
 jfs_lazycommit+0x49a/0xb80
 ? _raw_spin_unlock_irqrestore+0x8f/0x140
 ? lockdep_hardirqs_on+0x99/0x150
 ? __pfx_jfs_lazycommit+0x10/0x10
 ? __pfx_default_wake_function+0x10/0x10
 ? __kthread_parkme+0x169/0x1d0
 ? __pfx_jfs_lazycommit+0x10/0x10
 kthread+0x2f2/0x390
 ? __pfx_jfs_lazycommit+0x10/0x10
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x4d/0x80
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1a/0x30
 &lt;/TASK&gt;

This happens when 'clear_inode()' makes an attempt to finalize an underlying
JFS inode of unknown type. According to JFS layout description from
https://jfs.sourceforge.net/project/pub/jfslayout.pdf, inode types from 5 to
15 are reserved for future extensions and should not be encountered on a valid
filesystem. So add an extra check for valid inode type in 'copy_from_dinode()'.</Note>
    </Notes>
    <CVE>CVE-2025-37925</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid

There is a string parsing logic error which can lead to an overflow of hid
or uid buffers. Comparing ACPIID_LEN against a total string length doesn't
take into account the lengths of individual hid and uid buffers so the
check is insufficient in some cases. For example if the length of hid
string is 4 and the length of the uid string is 260, the length of str
will be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer
which size is 256.

The same applies to the hid string with length 13 and uid string with
length 250.

Check the length of hid and uid strings separately to prevent
buffer overflow.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2025-37927</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

dm-bufio: don't schedule in atomic context

A BUG was reported as below when CONFIG_DEBUG_ATOMIC_SLEEP and
try_verify_in_tasklet are enabled.
[  129.444685][  T934] BUG: sleeping function called from invalid context at drivers/md/dm-bufio.c:2421
[  129.444723][  T934] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 934, name: kworker/1:4
[  129.444740][  T934] preempt_count: 201, expected: 0
[  129.444756][  T934] RCU nest depth: 0, expected: 0
[  129.444781][  T934] Preemption disabled at:
[  129.444789][  T934] [&lt;ffffffd816231900&gt;] shrink_work+0x21c/0x248
[  129.445167][  T934] kernel BUG at kernel/sched/walt/walt_debug.c:16!
[  129.445183][  T934] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
[  129.445204][  T934] Skip md ftrace buffer dump for: 0x1609e0
[  129.447348][  T934] CPU: 1 PID: 934 Comm: kworker/1:4 Tainted: G        W  OE      6.6.56-android15-8-o-g6f82312b30b9-debug #1 1400000003000000474e5500b3187743670464e8
[  129.447362][  T934] Hardware name: Qualcomm Technologies, Inc. Parrot QRD, Alpha-M (DT)
[  129.447373][  T934] Workqueue: dm_bufio_cache shrink_work
[  129.447394][  T934] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  129.447406][  T934] pc : android_rvh_schedule_bug+0x0/0x8 [sched_walt_debug]
[  129.447435][  T934] lr : __traceiter_android_rvh_schedule_bug+0x44/0x6c
[  129.447451][  T934] sp : ffffffc0843dbc90
[  129.447459][  T934] x29: ffffffc0843dbc90 x28: ffffffffffffffff x27: 0000000000000c8b
[  129.447479][  T934] x26: 0000000000000040 x25: ffffff804b3d6260 x24: ffffffd816232b68
[  129.447497][  T934] x23: ffffff805171c5b4 x22: 0000000000000000 x21: ffffffd816231900
[  129.447517][  T934] x20: ffffff80306ba898 x19: 0000000000000000 x18: ffffffc084159030
[  129.447535][  T934] x17: 00000000d2b5dd1f x16: 00000000d2b5dd1f x15: ffffffd816720358
[  129.447554][  T934] x14: 0000000000000004 x13: ffffff89ef978000 x12: 0000000000000003
[  129.447572][  T934] x11: ffffffd817a823c4 x10: 0000000000000202 x9 : 7e779c5735de9400
[  129.447591][  T934] x8 : ffffffd81560d004 x7 : 205b5d3938373434 x6 : ffffffd8167397c8
[  129.447610][  T934] x5 : 0000000000000000 x4 : 0000000000000001 x3 : ffffffc0843db9e0
[  129.447629][  T934] x2 : 0000000000002f15 x1 : 0000000000000000 x0 : 0000000000000000
[  129.447647][  T934] Call trace:
[  129.447655][  T934]  android_rvh_schedule_bug+0x0/0x8 [sched_walt_debug 1400000003000000474e550080cce8a8a78606b6]
[  129.447681][  T934]  __might_resched+0x190/0x1a8
[  129.447694][  T934]  shrink_work+0x180/0x248
[  129.447706][  T934]  process_one_work+0x260/0x624
[  129.447718][  T934]  worker_thread+0x28c/0x454
[  129.447729][  T934]  kthread+0x118/0x158
[  129.447742][  T934]  ret_from_fork+0x10/0x20
[  129.447761][  T934] Code: ???????? ???????? ???????? d2b5dd1f (d4210000)
[  129.447772][  T934] ---[ end trace 0000000000000000 ]---

dm_bufio_lock will call spin_lock_bh when try_verify_in_tasklet
is enabled, and __scan will be called in atomic context.</Note>
    </Notes>
    <CVE>CVE-2025-37928</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

arm64: errata: Add missing sentinels to Spectre-BHB MIDR arrays

Commit a5951389e58d ("arm64: errata: Add newer ARM cores to the
spectre_bhb_loop_affected() lists") added some additional CPUs to the
Spectre-BHB workaround, including some new arrays for designs that
require new 'k' values for the workaround to be effective.

Unfortunately, the new arrays omitted the sentinel entry and so
is_midr_in_range_list() will walk off the end when it doesn't find a
match. With UBSAN enabled, this leads to a crash during boot when
is_midr_in_range_list() is inlined (which was more common prior to
c8c2647e69be ("arm64: Make   _midr_in_range_list() an exported
function")):

 |  Internal error: aarch64 BRK: 00000000f2000001 [#1] PREEMPT SMP
 |  pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 |  pc : spectre_bhb_loop_affected+0x28/0x30
 |  lr : is_spectre_bhb_affected+0x170/0x190
 | [...]
 |  Call trace:
 |   spectre_bhb_loop_affected+0x28/0x30
 |   update_cpu_capabilities+0xc0/0x184
 |   init_cpu_features+0x188/0x1a4
 |   cpuinfo_store_boot_cpu+0x4c/0x60
 |   smp_prepare_boot_cpu+0x38/0x54
 |   start_kernel+0x8c/0x478
 |   __primary_switched+0xc8/0xd4
 |  Code: 6b09011f 54000061 52801080 d65f03c0 (d4200020)
 |  ---[ end trace 0000000000000000 ]---
 |  Kernel panic - not syncing: aarch64 BRK: Fatal exception

Add the missing sentinel entries.</Note>
    </Notes>
    <CVE>CVE-2025-37929</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/nouveau: Fix WARN_ON in nouveau_fence_context_kill()

Nouveau is mostly designed in a way that it's expected that fences only
ever get signaled through nouveau_fence_signal(). However, in at least
one other place, nouveau_fence_done(), can signal fences, too. If that
happens (race) a signaled fence remains in the pending list for a while,
until it gets removed by nouveau_fence_update().

Should nouveau_fence_context_kill() run in the meantime, this would be
a bug because the function would attempt to set an error code on an
already signaled fence.

Have nouveau_fence_context_kill() check for a fence being signaled.</Note>
    </Notes>
    <CVE>CVE-2025-37930</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

btrfs: adjust subpage bit start based on sectorsize

When running machines with 64k page size and a 16k nodesize we started
seeing tree log corruption in production.  This turned out to be because
we were not writing out dirty blocks sometimes, so this in fact affects
all metadata writes.

When writing out a subpage EB we scan the subpage bitmap for a dirty
range.  If the range isn't dirty we do

	bit_start++;

to move onto the next bit.  The problem is the bitmap is based on the
number of sectors that an EB has.  So in this case, we have a 64k
pagesize, 16k nodesize, but a 4k sectorsize.  This means our bitmap is 4
bits for every node.  With a 64k page size we end up with 4 nodes per
page.

To make this easier this is how everything looks

[0         16k       32k       48k     ] logical address
[0         4         8         12      ] radix tree offset
[               64k page               ] folio
[ 16k eb ][ 16k eb ][ 16k eb ][ 16k eb ] extent buffers
[ | | | |  | | | |   | | | |   | | | | ] bitmap

Now we use all of our addressing based on fs_info-&gt;sectorsize_bits, so
as you can see the above our 16k eb-&gt;start turns into radix entry 4.

When we find a dirty range for our eb, we correctly do bit_start +=
sectors_per_node, because if we start at bit 0, the next bit for the
next eb is 4, to correspond to eb-&gt;start 16k.

However if our range is clean, we will do bit_start++, which will now
put us offset from our radix tree entries.

In our case, assume that the first time we check the bitmap the block is
not dirty, we increment bit_start so now it == 1, and then we loop
around and check again.  This time it is dirty, and we go to find that
start using the following equation

	start = folio_start + bit_start * fs_info-&gt;sectorsize;

so in the case above, eb-&gt;start 0 is now dirty, and we calculate start
as

	0 + 1 * fs_info-&gt;sectorsize = 4096
	4096 &gt;&gt; 12 = 1

Now we're looking up the radix tree for 1, and we won't find an eb.
What's worse is now we're using bit_start == 1, so we do bit_start +=
sectors_per_node, which is now 5.  If that eb is dirty we will run into
the same thing, we will look at an offset that is not populated in the
radix tree, and now we're skipping the writeout of dirty extent buffers.

The best fix for this is to not use sectorsize_bits to address nodes,
but that's a larger change.  Since this is a fs corruption problem fix
it simply by always using sectors_per_node to increment the start bit.</Note>
    </Notes>
    <CVE>CVE-2025-37931</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

octeon_ep: Fix host hang issue during device reboot

When the host loses heartbeat messages from the device,
the driver calls the device-specific ndo_stop function,
which frees the resources. If the driver is unloaded in
this scenario, it calls ndo_stop again, attempting to free
resources that have already been freed, leading to a host
hang issue. To resolve this, dev_close should be called
instead of the device-specific stop function.dev_close
internally calls ndo_stop to stop the network interface
and performs additional cleanup tasks. During the driver
unload process, if the device is already down, ndo_stop
is not called.</Note>
    </Notes>
    <CVE>CVE-2025-37933</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ASoC: simple-card-utils: Fix pointer check in graph_util_parse_link_direction

Actually check if the passed pointers are valid, before writing to them.
This also fixes a USBAN warning:
UBSAN: invalid-load in ../sound/soc/fsl/imx-card.c:687:25
load of value 255 is not a valid value for type '_Bool'

This is because playback_only is uninitialized and is not written to, as
the playback-only property is absent.</Note>
    </Notes>
    <CVE>CVE-2025-37934</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

perf/x86/intel: KVM: Mask PEBS_ENABLE loaded for guest with vCPU's value.

When generating the MSR_IA32_PEBS_ENABLE value that will be loaded on
VM-Entry to a KVM guest, mask the value with the vCPU's desired PEBS_ENABLE
value.  Consulting only the host kernel's host vs. guest masks results in
running the guest with PEBS enabled even when the guest doesn't want to use
PEBS.  Because KVM uses perf events to proxy the guest virtual PMU, simply
looking at exclude_host can't differentiate between events created by host
userspace, and events created by KVM on behalf of the guest.

Running the guest with PEBS unexpectedly enabled typically manifests as
crashes due to a near-infinite stream of #PFs.  E.g. if the guest hasn't
written MSR_IA32_DS_AREA, the CPU will hit page faults on address '0' when
trying to record PEBS events.

The issue is most easily reproduced by running `perf kvm top` from before
commit 7b100989b4f6 ("perf evlist: Remove __evlist__add_default") (after
which, `perf kvm top` effectively stopped using PEBS).	The userspace side
of perf creates a guest-only PEBS event, which intel_guest_get_msrs()
misconstrues a guest-*owned* PEBS event.

Arguably, this is a userspace bug, as enabling PEBS on guest-only events
simply cannot work, and userspace can kill VMs in many other ways (there
is no danger to the host).  However, even if this is considered to be bad
userspace behavior, there's zero downside to perf/KVM restricting PEBS to
guest-owned events.

Note, commit 854250329c02 ("KVM: x86/pmu: Disable guest PEBS temporarily
in two rare situations") fixed the case where host userspace is profiling
KVM *and* userspace, but missed the case where userspace is profiling only
KVM.</Note>
    </Notes>
    <CVE>CVE-2025-37936</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

objtool, media: dib8000: Prevent divide-by-zero in dib8000_set_dds()

If dib8000_set_dds()'s call to dib8000_read32() returns zero, the result
is a divide-by-zero.  Prevent that from happening.

Fixes the following warning with an UBSAN kernel:

  drivers/media/dvb-frontends/dib8000.o: warning: objtool: dib8000_tune() falls through to next function dib8096p_cfg_DibRx()</Note>
    </Notes>
    <CVE>CVE-2025-37937</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tracing: Verify event formats that have "%*p.."

The trace event verifier checks the formats of trace events to make sure
that they do not point at memory that is not in the trace event itself or
in data that will never be freed. If an event references data that was
allocated when the event triggered and that same data is freed before the
event is read, then the kernel can crash by reading freed memory.

The verifier runs at boot up (or module load) and scans the print formats
of the events and checks their arguments to make sure that dereferenced
pointers are safe. If the format uses "%*p.." the verifier will ignore it,
and that could be dangerous. Cover this case as well.

Also add to the sample code a use case of "%*pbl".</Note>
    </Notes>
    <CVE>CVE-2025-37938</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: Fix invalid data access in ath12k_dp_rx_h_undecap_nwifi

In certain cases, hardware might provide packets with a
length greater than the maximum native Wi-Fi header length.
This can lead to accessing and modifying fields in the header
within the ath12k_dp_rx_h_undecap_nwifi function for
DP_RX_DECAP_TYPE_NATIVE_WIFI decap type and
potentially resulting in invalid data access and memory corruption.

Add a sanity check before processing the SKB to prevent invalid
data access in the undecap native Wi-Fi function for the
DP_RX_DECAP_TYPE_NATIVE_WIFI decap type.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1</Note>
    </Notes>
    <CVE>CVE-2025-37943</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: Fix invalid entry fetch in ath12k_dp_mon_srng_process

Currently, ath12k_dp_mon_srng_process uses ath12k_hal_srng_src_get_next_entry
to fetch the next entry from the destination ring. This is incorrect because
ath12k_hal_srng_src_get_next_entry is intended for source rings, not destination
rings. This leads to invalid entry fetches, causing potential data corruption or
crashes due to accessing incorrect memory locations. This happens because the
source ring and destination ring have different handling mechanisms and using
the wrong function results in incorrect pointer arithmetic and ring management.

To fix this issue, replace the call to ath12k_hal_srng_src_get_next_entry with
ath12k_hal_srng_dst_get_next_entry in ath12k_dp_mon_srng_process. This ensures
that the correct function is used for fetching entries from the destination
ring, preventing invalid memory accesses.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3</Note>
    </Notes>
    <CVE>CVE-2025-37944</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHY

DSA has 2 kinds of drivers:

1. Those who call dsa_switch_suspend() and dsa_switch_resume() from
   their device PM ops: qca8k-8xxx, bcm_sf2, microchip ksz
2. Those who don't: all others. The above methods should be optional.

For type 1, dsa_switch_suspend() calls dsa_user_suspend() -&gt; phylink_stop(),
and dsa_switch_resume() calls dsa_user_resume() -&gt; phylink_start().
These seem good candidates for setting mac_managed_pm = true because
that is essentially its definition [1], but that does not seem to be the
biggest problem for now, and is not what this change focuses on.

Talking strictly about the 2nd category of DSA drivers here (which
do not have MAC managed PM, meaning that for their attached PHYs,
mdio_bus_phy_suspend() and mdio_bus_phy_resume() should run in full),
I have noticed that the following warning from mdio_bus_phy_resume() is
triggered:

	WARN_ON(phydev-&gt;state != PHY_HALTED &amp;&amp; phydev-&gt;state != PHY_READY &amp;&amp;
		phydev-&gt;state != PHY_UP);

because the PHY state machine is running.

It's running as a result of a previous dsa_user_open() -&gt; ... -&gt;
phylink_start() -&gt; phy_start() having been initiated by the user.

The previous mdio_bus_phy_suspend() was supposed to have called
phy_stop_machine(), but it didn't. So this is why the PHY is in state
PHY_NOLINK by the time mdio_bus_phy_resume() runs.

mdio_bus_phy_suspend() did not call phy_stop_machine() because for
phylink, the phydev-&gt;adjust_link function pointer is NULL. This seems a
technicality introduced by commit fddd91016d16 ("phylib: fix PAL state
machine restart on resume"). That commit was written before phylink
existed, and was intended to avoid crashing with consumer drivers which
don't use the PHY state machine - phylink always does, when using a PHY.
But phylink itself has historically not been developed with
suspend/resume in mind, and apparently not tested too much in that
scenario, allowing this bug to exist unnoticed for so long. Plus, prior
to the WARN_ON(), it would have likely been invisible.

This issue is not in fact restricted to type 2 DSA drivers (according to
the above ad-hoc classification), but can be extrapolated to any MAC
driver with phylink and MDIO-bus-managed PHY PM ops. DSA is just where
the issue was reported. Assuming mac_managed_pm is set correctly, a
quick search indicates the following other drivers might be affected:

$ grep -Zlr PHYLINK_NETDEV drivers/ | xargs -0 grep -L mac_managed_pm
drivers/net/ethernet/atheros/ag71xx.c
drivers/net/ethernet/microchip/sparx5/sparx5_main.c
drivers/net/ethernet/microchip/lan966x/lan966x_main.c
drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c
drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
drivers/net/ethernet/freescale/ucc_geth.c
drivers/net/ethernet/freescale/enetc/enetc_pf_common.c
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
drivers/net/ethernet/marvell/mvneta.c
drivers/net/ethernet/marvell/prestera/prestera_main.c
drivers/net/ethernet/mediatek/mtk_eth_soc.c
drivers/net/ethernet/altera/altera_tse_main.c
drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c
drivers/net/ethernet/meta/fbnic/fbnic_phylink.c
drivers/net/ethernet/tehuti/tn40_phy.c
drivers/net/ethernet/mscc/ocelot_net.c

Make the existing conditions dependent on the PHY device having a
phydev-&gt;phy_link_change() implementation equal to the default
phy_link_change() provided by phylib. Otherwise, we implicitly know that
the phydev has the phylink-provided phylink_phy_change() callback, and
when phylink is used, the PHY state machine always needs to be stopped/
started on the suspend/resume path. The code is structured as such that
if phydev-&gt;phy_link_change() is absent, it is a matter of time until the
kernel will crash - no need to further complicate the test.

Thus, for the situation where the PM is not managed b
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-37945</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

s390/pci: Fix duplicate pci_dev_put() in disable_slot() when PF has child VFs

With commit bcb5d6c76903 ("s390/pci: introduce lock to synchronize state
of zpci_dev's") the code to ignore power off of a PF that has child VFs
was changed from a direct return to a goto to the unlock and
pci_dev_put() section. The change however left the existing pci_dev_put()
untouched resulting in a doubple put. This can subsequently cause a use
after free if the struct pci_dev is released in an unexpected state.
Fix this by removing the extra pci_dev_put().</Note>
    </Notes>
    <CVE>CVE-2025-37946</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

arm64: bpf: Add BHB mitigation to the epilogue for cBPF programs

A malicious BPF program may manipulate the branch history to influence
what the hardware speculates will happen next.

On exit from a BPF program, emit the BHB mititgation sequence.

This is only applied for 'classic' cBPF programs that are loaded by
seccomp.</Note>
    </Notes>
    <CVE>CVE-2025-37948</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/v3d: Add job to pending list if the reset was skipped

When a CL/CSD job times out, we check if the GPU has made any progress
since the last timeout. If so, instead of resetting the hardware, we skip
the reset and let the timer get rearmed. This gives long-running jobs a
chance to complete.

However, when `timedout_job()` is called, the job in question is removed
from the pending list, which means it won't be automatically freed through
`free_job()`. Consequently, when we skip the reset and keep the job
running, the job won't be freed when it finally completes.

This situation leads to a memory leak, as exposed in [1] and [2].

Similarly to commit 704d3d60fec4 ("drm/etnaviv: don't block scheduler when
GPU is still active"), this patch ensures the job is put back on the
pending list when extending the timeout.</Note>
    </Notes>
    <CVE>CVE-2025-37951</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: Scrub packet on bpf_redirect_peer

When bpf_redirect_peer is used to redirect packets to a device in
another network namespace, the skb isn't scrubbed. That can lead skb
information from one namespace to be "misused" in another namespace.

As one example, this is causing Cilium to drop traffic when using
bpf_redirect_peer to redirect packets that just went through IPsec
decryption to a container namespace. The following pwru trace shows (1)
the packet path from the host's XFRM layer to the container's XFRM
layer where it's dropped and (2) the number of active skb extensions at
each function.

    NETNS       MARK  IFACE  TUPLE                                FUNC
    4026533547  d00   eth0   10.244.3.124:35473-&gt;10.244.2.158:53  xfrm_rcv_cb
                             .active_extensions = (__u8)2,
    4026533547  d00   eth0   10.244.3.124:35473-&gt;10.244.2.158:53  xfrm4_rcv_cb
                             .active_extensions = (__u8)2,
    4026533547  d00   eth0   10.244.3.124:35473-&gt;10.244.2.158:53  gro_cells_receive
                             .active_extensions = (__u8)2,
    [...]
    4026533547  0     eth0   10.244.3.124:35473-&gt;10.244.2.158:53  skb_do_redirect
                             .active_extensions = (__u8)2,
    4026534999  0     eth0   10.244.3.124:35473-&gt;10.244.2.158:53  ip_rcv
                             .active_extensions = (__u8)2,
    4026534999  0     eth0   10.244.3.124:35473-&gt;10.244.2.158:53  ip_rcv_core
                             .active_extensions = (__u8)2,
    [...]
    4026534999  0     eth0   10.244.3.124:35473-&gt;10.244.2.158:53  udp_queue_rcv_one_skb
                             .active_extensions = (__u8)2,
    4026534999  0     eth0   10.244.3.124:35473-&gt;10.244.2.158:53  __xfrm_policy_check
                             .active_extensions = (__u8)2,
    4026534999  0     eth0   10.244.3.124:35473-&gt;10.244.2.158:53  __xfrm_decode_session
                             .active_extensions = (__u8)2,
    4026534999  0     eth0   10.244.3.124:35473-&gt;10.244.2.158:53  security_xfrm_decode_session
                             .active_extensions = (__u8)2,
    4026534999  0     eth0   10.244.3.124:35473-&gt;10.244.2.158:53  kfree_skb_reason(SKB_DROP_REASON_XFRM_POLICY)
                             .active_extensions = (__u8)2,

In this case, there are no XFRM policies in the container's network
namespace so the drop is unexpected. When we decrypt the IPsec packet,
the XFRM state used for decryption is set in the skb extensions. This
information is preserved across the netns switch. When we reach the
XFRM policy check in the container's netns, __xfrm_policy_check drops
the packet with LINUX_MIB_XFRMINNOPOLS because a (container-side) XFRM
policy can't be found that matches the (host-side) XFRM state used for
decryption.

This patch fixes this by scrubbing the packet when using
bpf_redirect_peer, as is done on typical netns switches via veth
devices except skb-&gt;mark and skb-&gt;tstamp are not zeroed.</Note>
    </Notes>
    <CVE>CVE-2025-37959</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ipvs: fix uninit-value for saddr in do_output_route4

syzbot reports for uninit-value for the saddr argument [1].
commit 4754957f04f5 ("ipvs: do not use random local source address for
tunnels") already implies that the input value of saddr
should be ignored but the code is still reading it which can prevent
to connect the route. Fix it by changing the argument to ret_saddr.

[1]
BUG: KMSAN: uninit-value in do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147
 do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147
 __ip_vs_get_out_rt+0x403/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:330
 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136
 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063
 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
 nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626
 nf_hook include/linux/netfilter.h:269 [inline]
 __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118
 ip_local_out net/ipv4/ip_output.c:127 [inline]
 ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501
 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195
 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483
 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851
 sock_sendmsg_nosec net/socket.c:712 [inline]
 __sock_sendmsg+0x267/0x380 net/socket.c:727
 ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566
 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620
 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702
 __compat_sys_sendmmsg net/compat.c:360 [inline]
 __do_compat_sys_sendmmsg net/compat.c:367 [inline]
 __se_compat_sys_sendmmsg net/compat.c:364 [inline]
 __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364
 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346
 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]
 __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306
 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331
 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369
 entry_SYSENTER_compat_after_hwframe+0x84/0x8e

Uninit was created at:
 slab_post_alloc_hook mm/slub.c:4167 [inline]
 slab_alloc_node mm/slub.c:4210 [inline]
 __kmalloc_cache_noprof+0x8fa/0xe00 mm/slub.c:4367
 kmalloc_noprof include/linux/slab.h:905 [inline]
 ip_vs_dest_dst_alloc net/netfilter/ipvs/ip_vs_xmit.c:61 [inline]
 __ip_vs_get_out_rt+0x35d/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:323
 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136
 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063
 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
 nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626
 nf_hook include/linux/netfilter.h:269 [inline]
 __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118
 ip_local_out net/ipv4/ip_output.c:127 [inline]
 ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501
 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195
 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483
 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851
 sock_sendmsg_nosec net/socket.c:712 [inline]
 __sock_sendmsg+0x267/0x380 net/socket.c:727
 ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566
 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620
 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702
 __compat_sys_sendmmsg net/compat.c:360 [inline]
 __do_compat_sys_sendmmsg net/compat.c:367 [inline]
 __se_compat_sys_sendmmsg net/compat.c:364 [inline]
 __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364
 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346
 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]
 __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306
 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331
 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369
 entry_SYSENTER_compat_after_hwframe+0x84/0x8e

CPU: 0 UID: 0 PID: 22408 Comm: syz.4.5165 Not tainted 6.15.0-rc3-syzkaller-00019-gbc3372351d0c #0 PREEMPT(undef)
Hardware name: Google Google Compute Engi
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-37961</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

arm64: bpf: Only mitigate cBPF programs loaded by unprivileged users

Support for eBPF programs loaded by unprivileged users is typically
disabled. This means only cBPF programs need to be mitigated for BHB.

In addition, only mitigate cBPF programs that were loaded by an
unprivileged user. Privileged users can also load the same program
via eBPF, making the mitigation pointless.</Note>
    </Notes>
    <CVE>CVE-2025-37963</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix invalid context error in dml helper

[Why]
"BUG: sleeping function called from invalid context" error.
after:
"drm/amd/display: Protect FPU in dml2_validate()/dml21_validate()"

The populate_dml_plane_cfg_from_plane_state() uses the GFP_KERNEL flag
for memory allocation, which shouldn't be used in atomic contexts.

The allocation is needed only for using another helper function
get_scaler_data_for_plane().

[How]
Modify helpers to pass a pointer to scaler_data within existing context,
eliminating the need for dynamic memory allocation/deallocation
and copying.

(cherry picked from commit bd3e84bc98f81b44f2c43936bdadc3241d654259)</Note>
    </Notes>
    <CVE>CVE-2025-37965</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: typec: ucsi: displayport: Fix deadlock

This patch introduces the ucsi_con_mutex_lock / ucsi_con_mutex_unlock
functions to the UCSI driver. ucsi_con_mutex_lock ensures the connector
mutex is only locked if a connection is established and the partner pointer
is valid. This resolves a deadlock scenario where
ucsi_displayport_remove_partner holds con-&gt;mutex waiting for
dp_altmode_work to complete while dp_altmode_work attempts to acquire it.</Note>
    </Notes>
    <CVE>CVE-2025-37967</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iio: light: opt3001: fix deadlock due to concurrent flag access

The threaded IRQ function in this driver is reading the flag twice: once to
lock a mutex and once to unlock it. Even though the code setting the flag
is designed to prevent it, there are subtle cases where the flag could be
true at the mutex_lock stage and false at the mutex_unlock stage. This
results in the mutex not being unlocked, resulting in a deadlock.

Fix it by making the opt3001_irq() code generally more robust, reading the
flag into a variable and using the variable value at both stages.</Note>
    </Notes>
    <CVE>CVE-2025-37968</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_tagged_fifo

Prevent st_lsm6dsx_read_tagged_fifo from falling in an infinite loop in
case pattern_len is equal to zero and the device FIFO is not empty.</Note>
    </Notes>
    <CVE>CVE-2025-37969</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_fifo

Prevent st_lsm6dsx_read_fifo from falling in an infinite loop in case
pattern_len is equal to zero and the device FIFO is not empty.</Note>
    </Notes>
    <CVE>CVE-2025-37970</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Input: mtk-pmic-keys - fix possible null pointer dereference

In mtk_pmic_keys_probe, the regs parameter is only set if the button is
parsed in the device tree. However, on hardware where the button is left
floating, that node will most likely be removed not to enable that
input. In that case the code will try to dereference a null pointer.

Let's use the regs struct instead as it is defined for all supported
platforms. Note that it is ok setting the key reg even if that latter is
disabled as the interrupt won't be enabled anyway.</Note>
    </Notes>
    <CVE>CVE-2025-37972</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: cfg80211: fix out-of-bounds access during multi-link element defragmentation

Currently during the multi-link element defragmentation process, the
multi-link element length added to the total IEs length when calculating
the length of remaining IEs after the multi-link element in
cfg80211_defrag_mle(). This could lead to out-of-bounds access if the
multi-link element or its corresponding fragment elements are the last
elements in the IEs buffer.

To address this issue, correctly calculate the remaining IEs length by
deducting the multi-link element end offset from total IEs end offset.</Note>
    </Notes>
    <CVE>CVE-2025-37973</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

block: integrity: Do not call set_page_dirty_lock()

Placing multiple protection information buffers inside the same page
can lead to oopses because set_page_dirty_lock() can't be called from
interrupt context.

Since a protection information buffer is not backed by a file there is
no point in setting its page dirty, there is nothing to synchronize.
Drop the call to set_page_dirty_lock() and remove the last argument to
bio_integrity_unpin_bvec().</Note>
    </Notes>
    <CVE>CVE-2025-37978</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ASoC: qcom: Fix sc7280 lpass potential buffer overflow

Case values introduced in commit
5f78e1fb7a3e ("ASoC: qcom: Add driver support for audioreach solution")
cause out of bounds access in arrays of sc7280 driver data (e.g. in case
of RX_CODEC_DMA_RX_0 in sc7280_snd_hw_params()).

Redefine LPASS_MAX_PORTS to consider the maximum possible port id for
q6dsp as sc7280 driver utilizes some of those values.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2025-37979</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

block: fix resource leak in blk_register_queue() error path

When registering a queue fails after blk_mq_sysfs_register() is
successful but the function later encounters an error, we need
to clean up the blk_mq_sysfs resources.

Add the missing blk_mq_sysfs_unregister() call in the error path
to properly clean up these resources and prevent a memory leak.</Note>
    </Notes>
    <CVE>CVE-2025-37980</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: smartpqi: Use is_kdump_kernel() to check for kdump

The smartpqi driver checks the reset_devices variable to determine
whether special adjustments need to be made for kdump. This has the
effect that after a regular kexec reboot, some driver parameters such as
max_transfer_size are much lower than usual. More importantly, kexec
reboot tests have revealed memory corruption caused by the driver log
being written to system memory after a kexec.

Fix this by testing is_kdump_kernel() rather than reset_devices where
appropriate.</Note>
    </Notes>
    <CVE>CVE-2025-37981</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: wl1251: fix memory leak in wl1251_tx_work

The skb dequeued from tx_queue is lost when wl1251_ps_elp_wakeup fails
with a -ETIMEDOUT error. Fix that by queueing the skb back to tx_queue.</Note>
    </Notes>
    <CVE>CVE-2025-37982</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

qibfs: fix _another_ leak

failure to allocate inode =&gt; leaked dentry...

this one had been there since the initial merge; to be fair,
if we are that far OOM, the odds of failing at that particular
allocation are low...</Note>
    </Notes>
    <CVE>CVE-2025-37983</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

crypto: ecdsa - Harden against integer overflows in DIV_ROUND_UP()

Herbert notes that DIV_ROUND_UP() may overflow unnecessarily if an ecdsa
implementation's -&gt;key_size() callback returns an unusually large value.
Herbert instead suggests (for a division by 8):

  X / 8 + !!(X &amp; 7)

Based on this formula, introduce a generic DIV_ROUND_UP_POW2() macro and
use it in lieu of DIV_ROUND_UP() for -&gt;key_size() return values.

Additionally, use the macro in ecc_digits_from_bytes(), whose "nbytes"
parameter is a -&gt;key_size() return value in some instances, or a
user-specified ASN.1 length in the case of ecdsa_get_signature_rs().</Note>
    </Notes>
    <CVE>CVE-2025-37984</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

USB: wdm: close race between wdm_open and wdm_wwan_port_stop

Clearing WDM_WWAN_IN_USE must be the last action or
we can open a chardev whose URBs are still poisoned</Note>
    </Notes>
    <CVE>CVE-2025-37985</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: typec: class: Invalidate USB device pointers on partner unregistration

To avoid using invalid USB device pointers after a Type-C partner
disconnects, this patch clears the pointers upon partner unregistration.
This ensures a clean state for future connections.</Note>
    </Notes>
    <CVE>CVE-2025-37986</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

pds_core: Prevent possible adminq overflow/stuck condition

The pds_core's adminq is protected by the adminq_lock, which prevents
more than 1 command to be posted onto it at any one time. This makes it
so the client drivers cannot simultaneously post adminq commands.
However, the completions happen in a different context, which means
multiple adminq commands can be posted sequentially and all waiting
on completion.

On the FW side, the backing adminq request queue is only 16 entries
long and the retry mechanism and/or overflow/stuck prevention is
lacking. This can cause the adminq to get stuck, so commands are no
longer processed and completions are no longer sent by the FW.

As an initial fix, prevent more than 16 outstanding adminq commands so
there's no way to cause the adminq from getting stuck. This works
because the backing adminq request queue will never have more than 16
pending adminq commands, so it will never overflow. This is done by
reducing the adminq depth to 16.</Note>
    </Notes>
    <CVE>CVE-2025-37987</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: phy: leds: fix memory leak

A network restart test on a router led to an out-of-memory condition,
which was traced to a memory leak in the PHY LED trigger code.

The root cause is misuse of the devm API. The registration function
(phy_led_triggers_register) is called from phy_attach_direct, not
phy_probe, and the unregister function (phy_led_triggers_unregister)
is called from phy_detach, not phy_remove. This means the register and
unregister functions can be called multiple times for the same PHY
device, but devm-allocated memory is not freed until the driver is
unbound.

This also prevents kmemleak from detecting the leak, as the devm API
internally stores the allocated pointer.

Fix this by replacing devm_kzalloc/devm_kcalloc with standard
kzalloc/kcalloc, and add the corresponding kfree calls in the unregister
path.</Note>
    </Notes>
    <CVE>CVE-2025-37989</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: brcm80211: fmac: Add error handling for brcmf_usb_dl_writeimage()

The function brcmf_usb_dl_writeimage() calls the function
brcmf_usb_dl_cmd() but dose not check its return value. The
'state.state' and the 'state.bytes' are uninitialized if the
function brcmf_usb_dl_cmd() fails. It is dangerous to use
uninitialized variables in the conditions.

Add error handling for brcmf_usb_dl_cmd() to jump to error
handling path if the brcmf_usb_dl_cmd() fails and the
'state.state' and the 'state.bytes' are uninitialized.

Improve the error message to report more detailed error
information.</Note>
    </Notes>
    <CVE>CVE-2025-37990</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net_sched: Flush gso_skb list too during -&gt;change()

Previously, when reducing a qdisc's limit via the -&gt;change() operation, only
the main skb queue was trimmed, potentially leaving packets in the gso_skb
list. This could result in NULL pointer dereference when we only check
sch-&gt;limit against sch-&gt;q.qlen.

This patch introduces a new helper, qdisc_dequeue_internal(), which ensures
both the gso_skb list and the main queue are properly flushed when trimming
excess packets. All relevant qdiscs (codel, fq, fq_codel, fq_pie, hhf, pie)
are updated to use this helper in their -&gt;change() routines.</Note>
    </Notes>
    <CVE>CVE-2025-37992</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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
ucsi_displayport_work workqueue to finish executing before proceeding with
the partner removal.</Note>
    </Notes>
    <CVE>CVE-2025-37994</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

module: ensure that kobject_put() is safe for module type kobjects

In 'lookup_or_create_module_kobject()', an internal kobject is created
using 'module_ktype'. So call to 'kobject_put()' on error handling
path causes an attempt to use an uninitialized completion pointer in
'module_kobject_release()'. In this scenario, we just want to release
kobject without an extra synchronization required for a regular module
unloading process, so adding an extra check whether 'complete()' is
actually required makes 'kobject_put()' safe.</Note>
    </Notes>
    <CVE>CVE-2025-37995</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfilter: ipset: fix region locking in hash types

Region locking introduced in v5.6-rc4 contained three macros to handle
the region locks: ahash_bucket_start(), ahash_bucket_end() which gave
back the start and end hash bucket values belonging to a given region
lock and ahash_region() which should give back the region lock belonging
to a given hash bucket. The latter was incorrect which can lead to a
race condition between the garbage collector and adding new elements
when a hash type of set is defined with timeouts.</Note>
    </Notes>
    <CVE>CVE-2025-37997</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

openvswitch: Fix unsafe attribute parsing in output_userspace()

This patch replaces the manual Netlink attribute iteration in
output_userspace() with nla_for_each_nested(), which ensures that only
well-formed attributes are processed.</Note>
    </Notes>
    <CVE>CVE-2025-37998</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sch_hfsc: Fix qlen accounting bug when using peek in hfsc_enqueue()

When enqueuing the first packet to an HFSC class, hfsc_enqueue() calls the
child qdisc's peek() operation before incrementing sch-&gt;q.qlen and
sch-&gt;qstats.backlog. If the child qdisc uses qdisc_peek_dequeued(), this may
trigger an immediate dequeue and potential packet drop. In such cases,
qdisc_tree_reduce_backlog() is called, but the HFSC qdisc's qlen and backlog
have not yet been updated, leading to inconsistent queue accounting. This
can leave an empty HFSC class in the active list, causing further
consequences like use-after-free.

This patch fixes the bug by moving the increment of sch-&gt;q.qlen and
sch-&gt;qstats.backlog before the call to the child qdisc's peek() operation.
This ensures that queue length and backlog are always accurate when packet
drops or dequeues are triggered during the peek.</Note>
    </Notes>
    <CVE>CVE-2025-38000</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net_sched: hfsc: Address reentrant enqueue adding class to eltree twice

Savino says:
    "We are writing to report that this recent patch
    (141d34391abbb315d68556b7c67ad97885407547) [1]
    can be bypassed, and a UAF can still occur when HFSC is utilized with
    NETEM.

    The patch only checks the cl-&gt;cl_nactive field to determine whether
    it is the first insertion or not [2], but this field is only
    incremented by init_vf [3].

    By using HFSC_RSC (which uses init_ed) [4], it is possible to bypass the
    check and insert the class twice in the eltree.
    Under normal conditions, this would lead to an infinite loop in
    hfsc_dequeue for the reasons we already explained in this report [5].

    However, if TBF is added as root qdisc and it is configured with a
    very low rate,
    it can be utilized to prevent packets from being dequeued.
    This behavior can be exploited to perform subsequent insertions in the
    HFSC eltree and cause a UAF."

To fix both the UAF and the infinite loop, with netem as an hfsc child,
check explicitly in hfsc_enqueue whether the class is already in the eltree
whenever the HFSC_RSC flag is set.

[1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=141d34391abbb315d68556b7c67ad97885407547
[2] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1572
[3] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L677
[4] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1574
[5] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/T/#u</Note>
    </Notes>
    <CVE>CVE-2025-38001</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

can: bcm: add missing rcu read protection for procfs content

When the procfs content is generated for a bcm_op which is in the process
to be removed the procfs output might show unreliable data (UAF).

As the removal of bcm_op's is already implemented with rcu handling this
patch adds the missing rcu_read_lock() and makes sure the list entries
are properly removed under rcu protection.</Note>
    </Notes>
    <CVE>CVE-2025-38003</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

can: bcm: add locking for bcm_op runtime updates

The CAN broadcast manager (CAN BCM) can send a sequence of CAN frames via
hrtimer. The content and also the length of the sequence can be changed
resp reduced at runtime where the 'currframe' counter is then set to zero.

Although this appeared to be a safe operation the updates of 'currframe'
can be triggered from user space and hrtimer context in bcm_can_tx().
Anderson Nascimento created a proof of concept that triggered a KASAN
slab-out-of-bounds read access which can be prevented with a spin_lock_bh.

At the rework of bcm_can_tx() the 'count' variable has been moved into
the protected section as this variable can be modified from both contexts
too.</Note>
    </Notes>
    <CVE>CVE-2025-38004</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

dmaengine: ti: k3-udma: Add missing locking

Recent kernels complain about a missing lock in k3-udma.c when the lock
validator is enabled:

[    4.128073] WARNING: CPU: 0 PID: 746 at drivers/dma/ti/../virt-dma.h:169 udma_start.isra.0+0x34/0x238
[    4.137352] CPU: 0 UID: 0 PID: 746 Comm: kworker/0:3 Not tainted 6.12.9-arm64 #28
[    4.144867] Hardware name: pp-v12 (DT)
[    4.148648] Workqueue: events udma_check_tx_completion
[    4.153841] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    4.160834] pc : udma_start.isra.0+0x34/0x238
[    4.165227] lr : udma_start.isra.0+0x30/0x238
[    4.169618] sp : ffffffc083cabcf0
[    4.172963] x29: ffffffc083cabcf0 x28: 0000000000000000 x27: ffffff800001b005
[    4.180167] x26: ffffffc0812f0000 x25: 0000000000000000 x24: 0000000000000000
[    4.187370] x23: 0000000000000001 x22: 00000000e21eabe9 x21: ffffff8000fa0670
[    4.194571] x20: ffffff8001b6bf00 x19: ffffff8000fa0430 x18: ffffffc083b95030
[    4.201773] x17: 0000000000000000 x16: 00000000f0000000 x15: 0000000000000048
[    4.208976] x14: 0000000000000048 x13: 0000000000000000 x12: 0000000000000001
[    4.216179] x11: ffffffc08151a240 x10: 0000000000003ea1 x9 : ffffffc08046ab68
[    4.223381] x8 : ffffffc083cabac0 x7 : ffffffc081df3718 x6 : 0000000000029fc8
[    4.230583] x5 : ffffffc0817ee6d8 x4 : 0000000000000bc0 x3 : 0000000000000000
[    4.237784] x2 : 0000000000000000 x1 : 00000000001fffff x0 : 0000000000000000
[    4.244986] Call trace:
[    4.247463]  udma_start.isra.0+0x34/0x238
[    4.251509]  udma_check_tx_completion+0xd0/0xdc
[    4.256076]  process_one_work+0x244/0x3fc
[    4.260129]  process_scheduled_works+0x6c/0x74
[    4.264610]  worker_thread+0x150/0x1dc
[    4.268398]  kthread+0xd8/0xe8
[    4.271492]  ret_from_fork+0x10/0x20
[    4.275107] irq event stamp: 220
[    4.278363] hardirqs last  enabled at (219): [&lt;ffffffc080a27c7c&gt;] _raw_spin_unlock_irq+0x38/0x50
[    4.287183] hardirqs last disabled at (220): [&lt;ffffffc080a1c154&gt;] el1_dbg+0x24/0x50
[    4.294879] softirqs last  enabled at (182): [&lt;ffffffc080037e68&gt;] handle_softirqs+0x1c0/0x3cc
[    4.303437] softirqs last disabled at (177): [&lt;ffffffc080010170&gt;] __do_softirq+0x1c/0x28
[    4.311559] ---[ end trace 0000000000000000 ]---

This commit adds the missing locking.</Note>
    </Notes>
    <CVE>CVE-2025-38005</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

HID: uclogic: Add NULL check in uclogic_input_configured()

devm_kasprintf() returns NULL when memory allocation fails. Currently,
uclogic_input_configured() does not check for this case, which results
in a NULL pointer dereference.

Add NULL check after devm_kasprintf() to prevent this issue.</Note>
    </Notes>
    <CVE>CVE-2025-38007</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: disable napi on driver removal

A warning on driver removal started occurring after commit 9dd05df8403b
("net: warn if NAPI instance wasn't shut down"). Disable tx napi before
deleting it in mt76_dma_cleanup().

 WARNING: CPU: 4 PID: 18828 at net/core/dev.c:7288 __netif_napi_del_locked+0xf0/0x100
 CPU: 4 UID: 0 PID: 18828 Comm: modprobe Not tainted 6.15.0-rc4 #4 PREEMPT(lazy)
 Hardware name: ASUS System Product Name/PRIME X670E-PRO WIFI, BIOS 3035 09/05/2024
 RIP: 0010:__netif_napi_del_locked+0xf0/0x100
 Call Trace:
 &lt;TASK&gt;
 mt76_dma_cleanup+0x54/0x2f0 [mt76]
 mt7921_pci_remove+0xd5/0x190 [mt7921e]
 pci_device_remove+0x47/0xc0
 device_release_driver_internal+0x19e/0x200
 driver_detach+0x48/0x90
 bus_remove_driver+0x6d/0xf0
 pci_unregister_driver+0x2e/0xb0
 __do_sys_delete_module.isra.0+0x197/0x2e0
 do_syscall_64+0x7b/0x160
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Tested with mt7921e but the same pattern can be actually applied to other
mt76 drivers calling mt76_dma_cleanup() during removal. Tx napi is enabled
in their *_dma_init() functions and only toggled off and on again inside
their suspend/resume/reset paths. So it should be okay to disable tx
napi in such a generic way.

Found by Linux Verification Center (linuxtesting.org).</Note>
    </Notes>
    <CVE>CVE-2025-38009</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

phy: tegra: xusb: Use a bitmask for UTMI pad power state tracking

The current implementation uses bias_pad_enable as a reference count to
manage the shared bias pad for all UTMI PHYs. However, during system
suspension with connected USB devices, multiple power-down requests for
the UTMI pad result in a mismatch in the reference count, which in turn
produces warnings such as:

[  237.762967] WARNING: CPU: 10 PID: 1618 at tegra186_utmi_pad_power_down+0x160/0x170
[  237.763103] Call trace:
[  237.763104]  tegra186_utmi_pad_power_down+0x160/0x170
[  237.763107]  tegra186_utmi_phy_power_off+0x10/0x30
[  237.763110]  phy_power_off+0x48/0x100
[  237.763113]  tegra_xusb_enter_elpg+0x204/0x500
[  237.763119]  tegra_xusb_suspend+0x48/0x140
[  237.763122]  platform_pm_suspend+0x2c/0xb0
[  237.763125]  dpm_run_callback.isra.0+0x20/0xa0
[  237.763127]  __device_suspend+0x118/0x330
[  237.763129]  dpm_suspend+0x10c/0x1f0
[  237.763130]  dpm_suspend_start+0x88/0xb0
[  237.763132]  suspend_devices_and_enter+0x120/0x500
[  237.763135]  pm_suspend+0x1ec/0x270

The root cause was traced back to the dynamic power-down changes
introduced in commit a30951d31b25 ("xhci: tegra: USB2 pad power controls"),
where the UTMI pad was being powered down without verifying its current
state. This unbalanced behavior led to discrepancies in the reference
count.

To rectify this issue, this patch replaces the single reference counter
with a bitmask, renamed to utmi_pad_enabled. Each bit in the mask
corresponds to one of the four USB2 PHYs, allowing us to track each pad's
enablement status individually.

With this change:
  - The bias pad is powered on only when the mask is clear.
  - Each UTMI pad is powered on or down based on its corresponding bit
    in the mask, preventing redundant operations.
  - The overall power state of the shared bias pad is maintained
    correctly during suspend/resume cycles.

The mutex used to prevent race conditions during UTMI pad enable/disable
operations has been moved from the tegra186_utmi_bias_pad_power_on/off
functions to the parent functions tegra186_utmi_pad_power_on/down. This
change ensures that there are no race conditions when updating the bitmask.</Note>
    </Notes>
    <CVE>CVE-2025-38010</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: csa unmap use uninterruptible lock

After process exit to unmap csa and free GPU vm, if signal is accepted
and then waiting to take vm lock is interrupted and return, it causes
memory leaking and below warning backtrace.

Change to use uninterruptible wait lock fix the issue.

WARNING: CPU: 69 PID: 167800 at amd/amdgpu/amdgpu_kms.c:1525
 amdgpu_driver_postclose_kms+0x294/0x2a0 [amdgpu]
 Call Trace:
  &lt;TASK&gt;
  drm_file_free.part.0+0x1da/0x230 [drm]
  drm_close_helper.isra.0+0x65/0x70 [drm]
  drm_release+0x6a/0x120 [drm]
  amdgpu_drm_release+0x51/0x60 [amdgpu]
  __fput+0x9f/0x280
  ____fput+0xe/0x20
  task_work_run+0x67/0xa0
  do_exit+0x217/0x3c0
  do_group_exit+0x3b/0xb0
  get_signal+0x14a/0x8d0
  arch_do_signal_or_restart+0xde/0x100
  exit_to_user_mode_loop+0xc1/0x1a0
  exit_to_user_mode_prepare+0xf4/0x100
  syscall_exit_to_user_mode+0x17/0x40
  do_syscall_64+0x69/0xc0

(cherry picked from commit 7dbbfb3c171a6f63b01165958629c9c26abf38ab)</Note>
    </Notes>
    <CVE>CVE-2025-38011</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: Set n_channels after allocating struct cfg80211_scan_request

Make sure that n_channels is set after allocating the
struct cfg80211_registered_device::int_scan_req member. Seen with
syzkaller:

UBSAN: array-index-out-of-bounds in net/mac80211/scan.c:1208:5
index 0 is out of range for type 'struct ieee80211_channel *[] __counted_by(n_channels)' (aka 'struct ieee80211_channel *[]')

This was missed in the initial conversions because I failed to locate
the allocation likely due to the "sizeof(void *)" not matching the
"channels" array type.</Note>
    </Notes>
    <CVE>CVE-2025-38013</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

dmaengine: idxd: Refactor remove call with idxd_cleanup() helper

The idxd_cleanup() helper cleans up perfmon, interrupts, internals and
so on. Refactor remove call with the idxd_cleanup() helper to avoid code
duplication. Note, this also fixes the missing put_device() for idxd
groups, enginces and wqs.</Note>
    </Notes>
    <CVE>CVE-2025-38014</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

dmaengine: idxd: fix memory leak in error handling path of idxd_alloc

Memory allocated for idxd is not freed if an error occurs during
idxd_alloc(). To fix it, free the allocated memory in the reverse order
of allocation before exiting the function in case of an error.</Note>
    </Notes>
    <CVE>CVE-2025-38015</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/tls: fix kernel panic when alloc_page failed

We cannot set frag_list to NULL pointer when alloc_page failed.
It will be used in tls_strp_check_queue_ok when the next time
tls_strp_read_sock is called.

This is because we don't reset full_len in tls_strp_flush_anchor_copy()
so the recv path will try to continue handling the partial record
on the next call but we dettached the rcvq from the frag list.
Alternative fix would be to reset full_len.

Unable to handle kernel NULL pointer dereference
at virtual address 0000000000000028
 Call trace:
 tls_strp_check_rcv+0x128/0x27c
 tls_strp_data_ready+0x34/0x44
 tls_data_ready+0x3c/0x1f0
 tcp_data_ready+0x9c/0xe4
 tcp_data_queue+0xf6c/0x12d0
 tcp_rcv_established+0x52c/0x798</Note>
    </Notes>
    <CVE>CVE-2025-38018</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: Disable MACsec offload for uplink representor profile

MACsec offload is not supported in switchdev mode for uplink
representors. When switching to the uplink representor profile, the
MACsec offload feature must be cleared from the netdevice's features.

If left enabled, attempts to add offloads result in a null pointer
dereference, as the uplink representor does not support MACsec offload
even though the feature bit remains set.

Clear NETIF_F_HW_MACSEC in mlx5e_fix_uplink_rep_features().

Kernel log:

Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f]
CPU: 29 UID: 0 PID: 4714 Comm: ip Not tainted 6.14.0-rc4_for_upstream_debug_2025_03_02_17_35 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
RIP: 0010:__mutex_lock+0x128/0x1dd0
Code: d0 7c 08 84 d2 0f 85 ad 15 00 00 8b 35 91 5c fe 03 85 f6 75 29 49 8d 7e 60 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 &lt;80&gt; 3c 02 00 0f 85 a6 15 00 00 4d 3b 76 60 0f 85 fd 0b 00 00 65 ff
RSP: 0018:ffff888147a4f160 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000001
RDX: 000000000000000f RSI: 0000000000000000 RDI: 0000000000000078
RBP: ffff888147a4f2e0 R08: ffffffffa05d2c19 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
R13: dffffc0000000000 R14: 0000000000000018 R15: ffff888152de0000
FS:  00007f855e27d800(0000) GS:ffff88881ee80000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000004e5768 CR3: 000000013ae7c005 CR4: 0000000000372eb0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
 ? die_addr+0x3d/0xa0
 ? exc_general_protection+0x144/0x220
 ? asm_exc_general_protection+0x22/0x30
 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core]
 ? __mutex_lock+0x128/0x1dd0
 ? lockdep_set_lock_cmp_fn+0x190/0x190
 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core]
 ? mutex_lock_io_nested+0x1ae0/0x1ae0
 ? lock_acquire+0x1c2/0x530
 ? macsec_upd_offload+0x145/0x380
 ? lockdep_hardirqs_on_prepare+0x400/0x400
 ? kasan_save_stack+0x30/0x40
 ? kasan_save_stack+0x20/0x40
 ? kasan_save_track+0x10/0x30
 ? __kasan_kmalloc+0x77/0x90
 ? __kmalloc_noprof+0x249/0x6b0
 ? genl_family_rcv_msg_attrs_parse.constprop.0+0xb5/0x240
 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core]
 mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core]
 ? mlx5e_macsec_add_rxsa+0x11a0/0x11a0 [mlx5_core]
 macsec_update_offload+0x26c/0x820
 ? macsec_set_mac_address+0x4b0/0x4b0
 ? lockdep_hardirqs_on_prepare+0x284/0x400
 ? _raw_spin_unlock_irqrestore+0x47/0x50
 macsec_upd_offload+0x2c8/0x380
 ? macsec_update_offload+0x820/0x820
 ? __nla_parse+0x22/0x30
 ? genl_family_rcv_msg_attrs_parse.constprop.0+0x15e/0x240
 genl_family_rcv_msg_doit+0x1cc/0x2a0
 ? genl_family_rcv_msg_attrs_parse.constprop.0+0x240/0x240
 ? cap_capable+0xd4/0x330
 genl_rcv_msg+0x3ea/0x670
 ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0
 ? lockdep_set_lock_cmp_fn+0x190/0x190
 ? macsec_update_offload+0x820/0x820
 netlink_rcv_skb+0x12b/0x390
 ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0
 ? netlink_ack+0xd80/0xd80
 ? rwsem_down_read_slowpath+0xf90/0xf90
 ? netlink_deliver_tap+0xcd/0xac0
 ? netlink_deliver_tap+0x155/0xac0
 ? _copy_from_iter+0x1bb/0x12c0
 genl_rcv+0x24/0x40
 netlink_unicast+0x440/0x700
 ? netlink_attachskb+0x760/0x760
 ? lock_acquire+0x1c2/0x530
 ? __might_fault+0xbb/0x170
 netlink_sendmsg+0x749/0xc10
 ? netlink_unicast+0x700/0x700
 ? __might_fault+0xbb/0x170
 ? netlink_unicast+0x700/0x700
 __sock_sendmsg+0xc5/0x190
 ____sys_sendmsg+0x53f/0x760
 ? import_iovec+0x7/0x10
 ? kernel_sendmsg+0x30/0x30
 ? __copy_msghdr+0x3c0/0x3c0
 ? filter_irq_stacks+0x90/0x90
 ? stack_depot_save_flags+0x28/0xa30
 ___sys_sen
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-38020</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/core: Fix "KASAN: slab-use-after-free Read in ib_register_device" problem

Call Trace:

 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:408 [inline]
 print_report+0xc3/0x670 mm/kasan/report.c:521
 kasan_report+0xe0/0x110 mm/kasan/report.c:634
 strlen+0x93/0xa0 lib/string.c:420
 __fortify_strlen include/linux/fortify-string.h:268 [inline]
 get_kobj_path_length lib/kobject.c:118 [inline]
 kobject_get_path+0x3f/0x2a0 lib/kobject.c:158
 kobject_uevent_env+0x289/0x1870 lib/kobject_uevent.c:545
 ib_register_device drivers/infiniband/core/device.c:1472 [inline]
 ib_register_device+0x8cf/0xe00 drivers/infiniband/core/device.c:1393
 rxe_register_device+0x275/0x320 drivers/infiniband/sw/rxe/rxe_verbs.c:1552
 rxe_net_add+0x8e/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:550
 rxe_newlink+0x70/0x190 drivers/infiniband/sw/rxe/rxe.c:225
 nldev_newlink+0x3a3/0x680 drivers/infiniband/core/nldev.c:1796
 rdma_nl_rcv_msg+0x387/0x6e0 drivers/infiniband/core/netlink.c:195
 rdma_nl_rcv_skb.constprop.0.isra.0+0x2e5/0x450
 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]
 netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339
 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883
 sock_sendmsg_nosec net/socket.c:712 [inline]
 __sock_sendmsg net/socket.c:727 [inline]
 ____sys_sendmsg+0xa95/0xc70 net/socket.c:2566
 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620
 __sys_sendmsg+0x16d/0x220 net/socket.c:2652
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

This problem is similar to the problem that the
commit 1d6a9e7449e2 ("RDMA/core: Fix use-after-free when rename device name")
fixes.

The root cause is: the function ib_device_rename() renames the name with
lock. But in the function kobject_uevent(), this name is accessed without
lock protection at the same time.

The solution is to add the lock protection when this name is accessed in
the function kobject_uevent().</Note>
    </Notes>
    <CVE>CVE-2025-38022</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nfs: handle failure of nfs_get_lock_context in unlock path

When memory is insufficient, the allocation of nfs_lock_context in
nfs_get_lock_context() fails and returns -ENOMEM. If we mistakenly treat
an nfs4_unlockdata structure (whose l_ctx member has been set to -ENOMEM)
as valid and proceed to execute rpc_run_task(), this will trigger a NULL
pointer dereference in nfs4_locku_prepare. For example:

BUG: kernel NULL pointer dereference, address: 000000000000000c
PGD 0 P4D 0
Oops: Oops: 0000 [#1] SMP PTI
CPU: 15 UID: 0 PID: 12 Comm: kworker/u64:0 Not tainted 6.15.0-rc2-dirty #60
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40
Workqueue: rpciod rpc_async_schedule
RIP: 0010:nfs4_locku_prepare+0x35/0xc2
Code: 89 f2 48 89 fd 48 c7 c7 68 69 ef b5 53 48 8b 8e 90 00 00 00 48 89 f3
RSP: 0018:ffffbbafc006bdb8 EFLAGS: 00010246
RAX: 000000000000004b RBX: ffff9b964fc1fa00 RCX: 0000000000000000
RDX: 0000000000000000 RSI: fffffffffffffff4 RDI: ffff9ba53fddbf40
RBP: ffff9ba539934000 R08: 0000000000000000 R09: ffffbbafc006bc38
R10: ffffffffb6b689c8 R11: 0000000000000003 R12: ffff9ba539934030
R13: 0000000000000001 R14: 0000000004248060 R15: ffffffffb56d1c30
FS: 0000000000000000(0000) GS:ffff9ba5881f0000(0000) knlGS:00000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000000000c CR3: 000000093f244000 CR4: 00000000000006f0
Call Trace:
 &lt;TASK&gt;
 __rpc_execute+0xbc/0x480
 rpc_async_schedule+0x2f/0x40
 process_one_work+0x232/0x5d0
 worker_thread+0x1da/0x3d0
 ? __pfx_worker_thread+0x10/0x10
 kthread+0x10d/0x240
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x34/0x50
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1a/0x30
 &lt;/TASK&gt;
Modules linked in:
CR2: 000000000000000c
---[ end trace 0000000000000000 ]---

Free the allocated nfs4_unlockdata when nfs_get_lock_context() fails and
return NULL to terminate subsequent rpc_run_task, preventing NULL pointer
dereference.</Note>
    </Notes>
    <CVE>CVE-2025-38023</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bug

Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x7d/0xa0 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:378 [inline]
 print_report+0xcf/0x610 mm/kasan/report.c:489
 kasan_report+0xb5/0xe0 mm/kasan/report.c:602
 rxe_queue_cleanup+0xd0/0xe0 drivers/infiniband/sw/rxe/rxe_queue.c:195
 rxe_cq_cleanup+0x3f/0x50 drivers/infiniband/sw/rxe/rxe_cq.c:132
 __rxe_cleanup+0x168/0x300 drivers/infiniband/sw/rxe/rxe_pool.c:232
 rxe_create_cq+0x22e/0x3a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1109
 create_cq+0x658/0xb90 drivers/infiniband/core/uverbs_cmd.c:1052
 ib_uverbs_create_cq+0xc7/0x120 drivers/infiniband/core/uverbs_cmd.c:1095
 ib_uverbs_write+0x969/0xc90 drivers/infiniband/core/uverbs_main.c:679
 vfs_write fs/read_write.c:677 [inline]
 vfs_write+0x26a/0xcc0 fs/read_write.c:659
 ksys_write+0x1b8/0x200 fs/read_write.c:731
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the function rxe_create_cq, when rxe_cq_from_init fails, the function
rxe_cleanup will be called to handle the allocated resources. In fact,
some memory resources have already been freed in the function
rxe_cq_from_init. Thus, this problem will occur.

The solution is to let rxe_cleanup do all the work.</Note>
    </Notes>
    <CVE>CVE-2025-38024</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

regulator: max20086: fix invalid memory access

max20086_parse_regulators_dt() calls of_regulator_match() using an
array of struct of_regulator_match allocated on the stack for the
matches argument.

of_regulator_match() calls devm_of_regulator_put_matches(), which calls
devres_alloc() to allocate a struct devm_of_regulator_matches which will
be de-allocated using devm_of_regulator_put_matches().

struct devm_of_regulator_matches is populated with the stack allocated
matches array.

If the device fails to probe, devm_of_regulator_put_matches() will be
called and will try to call of_node_put() on that stack pointer,
generating the following dmesg entries:

max20086 6-0028: Failed to read DEVICE_ID reg: -121
kobject: '\xc0$\xa5\x03' (000000002cebcb7a): is not initialized, yet
kobject_put() is being called.

Followed by a stack trace matching the call flow described above.

Switch to allocating the matches array using devm_kcalloc() to
avoid accessing the stack pointer long after it's out of scope.

This also has the advantage of allowing multiple max20086 to probe
without overriding the data stored inside the global of_regulator_match.</Note>
    </Notes>
    <CVE>CVE-2025-38027</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

padata: do not leak refcount in reorder_work

A recent patch that addressed a UAF introduced a reference count leak:
the parallel_data refcount is incremented unconditionally, regardless
of the return value of queue_work(). If the work item is already queued,
the incremented refcount is never decremented.

Fix this by checking the return value of queue_work() and decrementing
the refcount when necessary.

Resolves:

Unreferenced object 0xffff9d9f421e3d80 (size 192):
  comm "cryptomgr_probe", pid 157, jiffies 4294694003
  hex dump (first 32 bytes):
    80 8b cf 41 9f 9d ff ff b8 97 e0 89 ff ff ff ff  ...A............
    d0 97 e0 89 ff ff ff ff 19 00 00 00 1f 88 23 00  ..............#.
  backtrace (crc 838fb36):
    __kmalloc_cache_noprof+0x284/0x320
    padata_alloc_pd+0x20/0x1e0
    padata_alloc_shell+0x3b/0xa0
    0xffffffffc040a54d
    cryptomgr_probe+0x43/0xc0
    kthread+0xf6/0x1f0
    ret_from_fork+0x2f/0x50
    ret_from_fork_asm+0x1a/0x30</Note>
    </Notes>
    <CVE>CVE-2025-38031</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

btrfs: correct the order of prelim_ref arguments in btrfs__prelim_ref

btrfs_prelim_ref() calls the old and new reference variables in the
incorrect order. This causes a NULL pointer dereference because oldref
is passed as NULL to trace_btrfs_prelim_ref_insert().

Note, trace_btrfs_prelim_ref_insert() is being called with newref as
oldref (and oldref as NULL) on purpose in order to print out
the values of newref.

To reproduce:
echo 1 &gt; /sys/kernel/debug/tracing/events/btrfs/btrfs_prelim_ref_insert/enable

Perform some writeback operations.

Backtrace:
BUG: kernel NULL pointer dereference, address: 0000000000000018
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 115949067 P4D 115949067 PUD 11594a067 PMD 0
 Oops: Oops: 0000 [#1] SMP NOPTI
 CPU: 1 UID: 0 PID: 1188 Comm: fsstress Not tainted 6.15.0-rc2-tester+ #47 PREEMPT(voluntary)  7ca2cef72d5e9c600f0c7718adb6462de8149622
 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014
 RIP: 0010:trace_event_raw_event_btrfs__prelim_ref+0x72/0x130
 Code: e8 43 81 9f ff 48 85 c0 74 78 4d 85 e4 0f 84 8f 00 00 00 49 8b 94 24 c0 06 00 00 48 8b 0a 48 89 48 08 48 8b 52 08 48 89 50 10 &lt;49&gt; 8b 55 18 48 89 50 18 49 8b 55 20 48 89 50 20 41 0f b6 55 28 88
 RSP: 0018:ffffce44820077a0 EFLAGS: 00010286
 RAX: ffff8c6b403f9014 RBX: ffff8c6b55825730 RCX: 304994edf9cf506b
 RDX: d8b11eb7f0fdb699 RSI: ffff8c6b403f9010 RDI: ffff8c6b403f9010
 RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000010
 R10: 00000000ffffffff R11: 0000000000000000 R12: ffff8c6b4e8fb000
 R13: 0000000000000000 R14: ffffce44820077a8 R15: ffff8c6b4abd1540
 FS:  00007f4dc6813740(0000) GS:ffff8c6c1d378000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000018 CR3: 000000010eb42000 CR4: 0000000000750ef0
 PKRU: 55555554
 Call Trace:
  &lt;TASK&gt;
  prelim_ref_insert+0x1c1/0x270
  find_parent_nodes+0x12a6/0x1ee0
  ? __entry_text_end+0x101f06/0x101f09
  ? srso_alias_return_thunk+0x5/0xfbef5
  ? srso_alias_return_thunk+0x5/0xfbef5
  ? srso_alias_return_thunk+0x5/0xfbef5
  ? srso_alias_return_thunk+0x5/0xfbef5
  btrfs_is_data_extent_shared+0x167/0x640
  ? fiemap_process_hole+0xd0/0x2c0
  extent_fiemap+0xa5c/0xbc0
  ? __entry_text_end+0x101f05/0x101f09
  btrfs_fiemap+0x7e/0xd0
  do_vfs_ioctl+0x425/0x9d0
  __x64_sys_ioctl+0x75/0xc0</Note>
    </Notes>
    <CVE>CVE-2025-38034</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nvmet-tcp: don't restore null sk_state_change

queue-&gt;state_change is set as part of nvmet_tcp_set_queue_sock(), but if
the TCP connection isn't established when nvmet_tcp_set_queue_sock() is
called then queue-&gt;state_change isn't set and sock-&gt;sk-&gt;sk_state_change
isn't replaced.

As such we don't need to restore sock-&gt;sk-&gt;sk_state_change if
queue-&gt;state_change is NULL.

This avoids NULL pointer dereferences such as this:

[  286.462026][    C0] BUG: kernel NULL pointer dereference, address: 0000000000000000
[  286.462814][    C0] #PF: supervisor instruction fetch in kernel mode
[  286.463796][    C0] #PF: error_code(0x0010) - not-present page
[  286.464392][    C0] PGD 8000000140620067 P4D 8000000140620067 PUD 114201067 PMD 0
[  286.465086][    C0] Oops: Oops: 0010 [#1] SMP KASAN PTI
[  286.465559][    C0] CPU: 0 UID: 0 PID: 1628 Comm: nvme Not tainted 6.15.0-rc2+ #11 PREEMPT(voluntary)
[  286.466393][    C0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014
[  286.467147][    C0] RIP: 0010:0x0
[  286.467420][    C0] Code: Unable to access opcode bytes at 0xffffffffffffffd6.
[  286.467977][    C0] RSP: 0018:ffff8883ae008580 EFLAGS: 00010246
[  286.468425][    C0] RAX: 0000000000000000 RBX: ffff88813fd34100 RCX: ffffffffa386cc43
[  286.469019][    C0] RDX: 1ffff11027fa68b6 RSI: 0000000000000008 RDI: ffff88813fd34100
[  286.469545][    C0] RBP: ffff88813fd34160 R08: 0000000000000000 R09: ffffed1027fa682c
[  286.470072][    C0] R10: ffff88813fd34167 R11: 0000000000000000 R12: ffff88813fd344c3
[  286.470585][    C0] R13: ffff88813fd34112 R14: ffff88813fd34aec R15: ffff888132cdd268
[  286.471070][    C0] FS:  00007fe3c04c7d80(0000) GS:ffff88840743f000(0000) knlGS:0000000000000000
[  286.471644][    C0] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  286.472543][    C0] CR2: ffffffffffffffd6 CR3: 000000012daca000 CR4: 00000000000006f0
[  286.473500][    C0] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  286.474467][    C0] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400
[  286.475453][    C0] Call Trace:
[  286.476102][    C0]  &lt;IRQ&gt;
[  286.476719][    C0]  tcp_fin+0x2bb/0x440
[  286.477429][    C0]  tcp_data_queue+0x190f/0x4e60
[  286.478174][    C0]  ? __build_skb_around+0x234/0x330
[  286.478940][    C0]  ? rcu_is_watching+0x11/0xb0
[  286.479659][    C0]  ? __pfx_tcp_data_queue+0x10/0x10
[  286.480431][    C0]  ? tcp_try_undo_loss+0x640/0x6c0
[  286.481196][    C0]  ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90
[  286.482046][    C0]  ? kvm_clock_get_cycles+0x14/0x30
[  286.482769][    C0]  ? ktime_get+0x66/0x150
[  286.483433][    C0]  ? rcu_is_watching+0x11/0xb0
[  286.484146][    C0]  tcp_rcv_established+0x6e4/0x2050
[  286.484857][    C0]  ? rcu_is_watching+0x11/0xb0
[  286.485523][    C0]  ? ipv4_dst_check+0x160/0x2b0
[  286.486203][    C0]  ? __pfx_tcp_rcv_established+0x10/0x10
[  286.486917][    C0]  ? lock_release+0x217/0x2c0
[  286.487595][    C0]  tcp_v4_do_rcv+0x4d6/0x9b0
[  286.488279][    C0]  tcp_v4_rcv+0x2af8/0x3e30
[  286.488904][    C0]  ? raw_local_deliver+0x51b/0xad0
[  286.489551][    C0]  ? rcu_is_watching+0x11/0xb0
[  286.490198][    C0]  ? __pfx_tcp_v4_rcv+0x10/0x10
[  286.490813][    C0]  ? __pfx_raw_local_deliver+0x10/0x10
[  286.491487][    C0]  ? __pfx_nf_confirm+0x10/0x10 [nf_conntrack]
[  286.492275][    C0]  ? rcu_is_watching+0x11/0xb0
[  286.492900][    C0]  ip_protocol_deliver_rcu+0x8f/0x370
[  286.493579][    C0]  ip_local_deliver_finish+0x297/0x420
[  286.494268][    C0]  ip_local_deliver+0x168/0x430
[  286.494867][    C0]  ? __pfx_ip_local_deliver+0x10/0x10
[  286.495498][    C0]  ? __pfx_ip_local_deliver_finish+0x10/0x10
[  286.496204][    C0]  ? ip_rcv_finish_core+0x19a/0x1f20
[  286.496806][    C0]  ? lock_release+0x217/0x2c0
[  286.497414][    C0]  ip_rcv+0x455/0x6e0
[  286.497945][    C0]  ? __pfx_ip_rcv+0x10/0x10
[ 
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-38035</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

serial: mctrl_gpio: split disable_ms into sync and no_sync APIs

The following splat has been observed on a SAMA5D27 platform using
atmel_serial:

BUG: sleeping function called from invalid context at kernel/irq/manage.c:738
in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 27, name: kworker/u5:0
preempt_count: 1, expected: 0
INFO: lockdep is turned off.
irq event stamp: 0
hardirqs last  enabled at (0): [&lt;00000000&gt;] 0x0
hardirqs last disabled at (0): [&lt;c01588f0&gt;] copy_process+0x1c4c/0x7bec
softirqs last  enabled at (0): [&lt;c0158944&gt;] copy_process+0x1ca0/0x7bec
softirqs last disabled at (0): [&lt;00000000&gt;] 0x0
CPU: 0 UID: 0 PID: 27 Comm: kworker/u5:0 Not tainted 6.13.0-rc7+ #74
Hardware name: Atmel SAMA5
Workqueue: hci0 hci_power_on [bluetooth]
Call trace:
  unwind_backtrace from show_stack+0x18/0x1c
  show_stack from dump_stack_lvl+0x44/0x70
  dump_stack_lvl from __might_resched+0x38c/0x598
  __might_resched from disable_irq+0x1c/0x48
  disable_irq from mctrl_gpio_disable_ms+0x74/0xc0
  mctrl_gpio_disable_ms from atmel_disable_ms.part.0+0x80/0x1f4
  atmel_disable_ms.part.0 from atmel_set_termios+0x764/0x11e8
  atmel_set_termios from uart_change_line_settings+0x15c/0x994
  uart_change_line_settings from uart_set_termios+0x2b0/0x668
  uart_set_termios from tty_set_termios+0x600/0x8ec
  tty_set_termios from ttyport_set_flow_control+0x188/0x1e0
  ttyport_set_flow_control from wilc_setup+0xd0/0x524 [hci_wilc]
  wilc_setup [hci_wilc] from hci_dev_open_sync+0x330/0x203c [bluetooth]
  hci_dev_open_sync [bluetooth] from hci_dev_do_open+0x40/0xb0 [bluetooth]
  hci_dev_do_open [bluetooth] from hci_power_on+0x12c/0x664 [bluetooth]
  hci_power_on [bluetooth] from process_one_work+0x998/0x1a38
  process_one_work from worker_thread+0x6e0/0xfb4
  worker_thread from kthread+0x3d4/0x484
  kthread from ret_from_fork+0x14/0x28

This warning is emitted when trying to toggle, at the highest level,
some flow control (with serdev_device_set_flow_control) in a device
driver. At the lowest level, the atmel_serial driver is using
serial_mctrl_gpio lib to enable/disable the corresponding IRQs
accordingly.  The warning emitted by CONFIG_DEBUG_ATOMIC_SLEEP is due to
disable_irq (called in mctrl_gpio_disable_ms) being possibly called in
some atomic context (some tty drivers perform modem lines configuration
in regions protected by port lock).

Split mctrl_gpio_disable_ms into two differents APIs, a non-blocking one
and a blocking one. Replace mctrl_gpio_disable_ms calls with the
relevant version depending on whether the call is protected by some port
lock.</Note>
    </Notes>
    <CVE>CVE-2025-38040</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

firmware: arm_ffa: Set dma_mask for ffa devices

Set dma_mask for FFA devices, otherwise DMA allocation using the device pointer
lead to following warning:

WARNING: CPU: 1 PID: 1 at kernel/dma/mapping.c:597 dma_alloc_attrs+0xe0/0x124</Note>
    </Notes>
    <CVE>CVE-2025-38043</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: cx231xx: set device_caps for 417

The video_device for the MPEG encoder did not set device_caps.

Add this, otherwise the video device can't be registered (you get a
WARN_ON instead).

Not seen before since currently 417 support is disabled, but I found
this while experimenting with it.</Note>
    </Notes>
    <CVE>CVE-2025-38044</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: fix debug actions order

The order of actions taken for debug was implemented incorrectly.
Now we implemented the dump split and do the FW reset only in the
middle of the dump (rather than the FW killing itself on error.)
As a result, some of the actions taken when applying the config
will now crash the device, so we need to fix the order.</Note>
    </Notes>
    <CVE>CVE-2025-38045</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

x86/fred: Fix system hang during S4 resume with FRED enabled

Upon a wakeup from S4, the restore kernel starts and initializes the
FRED MSRs as needed from its perspective.  It then loads a hibernation
image, including the image kernel, and attempts to load image pages
directly into their original page frames used before hibernation unless
those frames are currently in use.  Once all pages are moved to their
original locations, it jumps to a "trampoline" page in the image kernel.

At this point, the image kernel takes control, but the FRED MSRs still
contain values set by the restore kernel, which may differ from those
set by the image kernel before hibernation.  Therefore, the image kernel
must ensure the FRED MSRs have the same values as before hibernation.
Since these values depend only on the location of the kernel text and
data, they can be recomputed from scratch.</Note>
    </Notes>
    <CVE>CVE-2025-38047</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

smb: client: Fix use-after-free in cifs_fill_dirent

There is a race condition in the readdir concurrency process, which may
access the rsp buffer after it has been released, triggering the
following KASAN warning.

 ==================================================================
 BUG: KASAN: slab-use-after-free in cifs_fill_dirent+0xb03/0xb60 [cifs]
 Read of size 4 at addr ffff8880099b819c by task a.out/342975

 CPU: 2 UID: 0 PID: 342975 Comm: a.out Not tainted 6.15.0-rc6+ #240 PREEMPT(full)
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014
 Call Trace:
  &lt;TASK&gt;
  dump_stack_lvl+0x53/0x70
  print_report+0xce/0x640
  kasan_report+0xb8/0xf0
  cifs_fill_dirent+0xb03/0xb60 [cifs]
  cifs_readdir+0x12cb/0x3190 [cifs]
  iterate_dir+0x1a1/0x520
  __x64_sys_getdents+0x134/0x220
  do_syscall_64+0x4b/0x110
  entry_SYSCALL_64_after_hwframe+0x76/0x7e
 RIP: 0033:0x7f996f64b9f9
 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89
 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01
 f0 ff ff  0d f7 c3 0c 00 f7 d8 64 89 8
 RSP: 002b:00007f996f53de78 EFLAGS: 00000207 ORIG_RAX: 000000000000004e
 RAX: ffffffffffffffda RBX: 00007f996f53ecdc RCX: 00007f996f64b9f9
 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003
 RBP: 00007f996f53dea0 R08: 0000000000000000 R09: 0000000000000000
 R10: 0000000000000000 R11: 0000000000000207 R12: ffffffffffffff88
 R13: 0000000000000000 R14: 00007ffc8cd9a500 R15: 00007f996f51e000
  &lt;/TASK&gt;

 Allocated by task 408:
  kasan_save_stack+0x20/0x40
  kasan_save_track+0x14/0x30
  __kasan_slab_alloc+0x6e/0x70
  kmem_cache_alloc_noprof+0x117/0x3d0
  mempool_alloc_noprof+0xf2/0x2c0
  cifs_buf_get+0x36/0x80 [cifs]
  allocate_buffers+0x1d2/0x330 [cifs]
  cifs_demultiplex_thread+0x22b/0x2690 [cifs]
  kthread+0x394/0x720
  ret_from_fork+0x34/0x70
  ret_from_fork_asm+0x1a/0x30

 Freed by task 342979:
  kasan_save_stack+0x20/0x40
  kasan_save_track+0x14/0x30
  kasan_save_free_info+0x3b/0x60
  __kasan_slab_free+0x37/0x50
  kmem_cache_free+0x2b8/0x500
  cifs_buf_release+0x3c/0x70 [cifs]
  cifs_readdir+0x1c97/0x3190 [cifs]
  iterate_dir+0x1a1/0x520
  __x64_sys_getdents64+0x134/0x220
  do_syscall_64+0x4b/0x110
  entry_SYSCALL_64_after_hwframe+0x76/0x7e

 The buggy address belongs to the object at ffff8880099b8000
  which belongs to the cache cifs_request of size 16588
 The buggy address is located 412 bytes inside of
  freed 16588-byte region [ffff8880099b8000, ffff8880099bc0cc)

 The buggy address belongs to the physical page:
 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x99b8
 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
 anon flags: 0x80000000000040(head|node=0|zone=1)
 page_type: f5(slab)
 raw: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001
 raw: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000
 head: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001
 head: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000
 head: 0080000000000003 ffffea0000266e01 00000000ffffffff 00000000ffffffff
 head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008
 page dumped because: kasan: bad access detected

 Memory state around the buggy address:
  ffff8880099b8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
  ffff8880099b8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 &gt;ffff8880099b8180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                             ^
  ffff8880099b8200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
  ffff8880099b8280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ==================================================================

POC is available in the link [1].

The problem triggering process is as follows:

Process 1                       Process 2
-----------------------------------
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-38051</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done

Syzbot reported a slab-use-after-free with the following call trace:

  ==================================================================
  BUG: KASAN: slab-use-after-free in tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840
  Read of size 8 at addr ffff88807a733000 by task kworker/1:0/25

  Call Trace:
   kasan_report+0xd9/0x110 mm/kasan/report.c:601
   tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840
   crypto_request_complete include/crypto/algapi.h:266
   aead_request_complete include/crypto/internal/aead.h:85
   cryptd_aead_crypt+0x3b8/0x750 crypto/cryptd.c:772
   crypto_request_complete include/crypto/algapi.h:266
   cryptd_queue_worker+0x131/0x200 crypto/cryptd.c:181
   process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231

  Allocated by task 8355:
   kzalloc_noprof include/linux/slab.h:778
   tipc_crypto_start+0xcc/0x9e0 net/tipc/crypto.c:1466
   tipc_init_net+0x2dd/0x430 net/tipc/core.c:72
   ops_init+0xb9/0x650 net/core/net_namespace.c:139
   setup_net+0x435/0xb40 net/core/net_namespace.c:343
   copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508
   create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110
   unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:228
   ksys_unshare+0x419/0x970 kernel/fork.c:3323
   __do_sys_unshare kernel/fork.c:3394

  Freed by task 63:
   kfree+0x12a/0x3b0 mm/slub.c:4557
   tipc_crypto_stop+0x23c/0x500 net/tipc/crypto.c:1539
   tipc_exit_net+0x8c/0x110 net/tipc/core.c:119
   ops_exit_list+0xb0/0x180 net/core/net_namespace.c:173
   cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640
   process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231

After freed the tipc_crypto tx by delete namespace, tipc_aead_encrypt_done
may still visit it in cryptd_queue_worker workqueue.

I reproduce this issue by:
  ip netns add ns1
  ip link add veth1 type veth peer name veth2
  ip link set veth1 netns ns1
  ip netns exec ns1 tipc bearer enable media eth dev veth1
  ip netns exec ns1 tipc node set key this_is_a_master_key master
  ip netns exec ns1 tipc bearer disable media eth dev veth1
  ip netns del ns1

The key of reproduction is that, simd_aead_encrypt is interrupted, leading
to crypto_simd_usable() return false. Thus, the cryptd_queue_worker is
triggered, and the tipc_crypto tx will be visited.

  tipc_disc_timeout
    tipc_bearer_xmit_skb
      tipc_crypto_xmit
        tipc_aead_encrypt
          crypto_aead_encrypt
            // encrypt()
            simd_aead_encrypt
              // crypto_simd_usable() is false
              child = &amp;ctx-&gt;cryptd_tfm-&gt;base;

  simd_aead_encrypt
    crypto_aead_encrypt
      // encrypt()
      cryptd_aead_encrypt_enqueue
        cryptd_aead_enqueue
          cryptd_enqueue_request
            // trigger cryptd_queue_worker
            queue_work_on(smp_processor_id(), cryptd_wq, &amp;cpu_queue-&gt;work)

Fix this by holding net reference count before encrypt.</Note>
    </Notes>
    <CVE>CVE-2025-38052</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

idpf: fix null-ptr-deref in idpf_features_check

idpf_features_check is used to validate the TX packet. skb header
length is compared with the hardware supported value received from
the device control plane. The value is stored in the adapter structure
and to access it, vport pointer is used. During reset all the vports
are released and the vport pointer that the netdev private structure
points to is NULL.

To avoid null-ptr-deref, store the max header length value in netdev
private structure. This also helps to cache the value and avoid
accessing adapter pointer in hot path.

BUG: kernel NULL pointer dereference, address: 0000000000000068
...
RIP: 0010:idpf_features_check+0x6d/0xe0 [idpf]
Call Trace:
 &lt;TASK&gt;
 ? __die+0x23/0x70
 ? page_fault_oops+0x154/0x520
 ? exc_page_fault+0x76/0x190
 ? asm_exc_page_fault+0x26/0x30
 ? idpf_features_check+0x6d/0xe0 [idpf]
 netif_skb_features+0x88/0x310
 validate_xmit_skb+0x2a/0x2b0
 validate_xmit_skb_list+0x4c/0x70
 sch_direct_xmit+0x19d/0x3a0
 __dev_queue_xmit+0xb74/0xe70
 ...</Note>
    </Notes>
    <CVE>CVE-2025-38053</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

perf/x86/intel: Fix segfault with PEBS-via-PT with sample_freq

Currently, using PEBS-via-PT with a sample frequency instead of a sample
period, causes a segfault.  For example:

    BUG: kernel NULL pointer dereference, address: 0000000000000195
    &lt;NMI&gt;
    ? __die_body.cold+0x19/0x27
    ? page_fault_oops+0xca/0x290
    ? exc_page_fault+0x7e/0x1b0
    ? asm_exc_page_fault+0x26/0x30
    ? intel_pmu_pebs_event_update_no_drain+0x40/0x60
    ? intel_pmu_pebs_event_update_no_drain+0x32/0x60
    intel_pmu_drain_pebs_icl+0x333/0x350
    handle_pmi_common+0x272/0x3c0
    intel_pmu_handle_irq+0x10a/0x2e0
    perf_event_nmi_handler+0x2a/0x50

That happens because intel_pmu_pebs_event_update_no_drain() assumes all the
pebs_enabled bits represent counter indexes, which is not always the case.
In this particular case, bits 60 and 61 are set for PEBS-via-PT purposes.

The behaviour of PEBS-via-PT with sample frequency is questionable because
although a PMI is generated (PEBS_PMI_AFTER_EACH_RECORD), the period is not
adjusted anyway.

Putting that aside, fix intel_pmu_pebs_event_update_no_drain() by passing
the mask of counter bits instead of 'size'.  Note, prior to the Fixes
commit, 'size' would be limited to the maximum counter index, so the issue
was not hit.</Note>
    </Notes>
    <CVE>CVE-2025-38055</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

espintcp: fix skb leaks

A few error paths are missing a kfree_skb.</Note>
    </Notes>
    <CVE>CVE-2025-38057</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

__legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock

... or we risk stealing final mntput from sync umount - raising mnt_count
after umount(2) has verified that victim is not busy, but before it
has set MNT_SYNC_UMOUNT; in that case __legitimize_mnt() doesn't see
that it's safe to quietly undo mnt_count increment and leaves dropping
the reference to caller, where it'll be a full-blown mntput().

Check under mount_lock is needed; leaving the current one done before
taking that makes no sense - it's nowhere near common enough to bother
with.</Note>
    </Notes>
    <CVE>CVE-2025-38058</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

btrfs: avoid NULL pointer dereference if no valid csum tree

[BUG]
When trying read-only scrub on a btrfs with rescue=idatacsums mount
option, it will crash with the following call trace:

  BUG: kernel NULL pointer dereference, address: 0000000000000208
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  CPU: 1 UID: 0 PID: 835 Comm: btrfs Tainted: G           O        6.15.0-rc3-custom+ #236 PREEMPT(full)
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022
  RIP: 0010:btrfs_lookup_csums_bitmap+0x49/0x480 [btrfs]
  Call Trace:
   &lt;TASK&gt;
   scrub_find_fill_first_stripe+0x35b/0x3d0 [btrfs]
   scrub_simple_mirror+0x175/0x290 [btrfs]
   scrub_stripe+0x5f7/0x6f0 [btrfs]
   scrub_chunk+0x9a/0x150 [btrfs]
   scrub_enumerate_chunks+0x333/0x660 [btrfs]
   btrfs_scrub_dev+0x23e/0x600 [btrfs]
   btrfs_ioctl+0x1dcf/0x2f80 [btrfs]
   __x64_sys_ioctl+0x97/0xc0
   do_syscall_64+0x4f/0x120
   entry_SYSCALL_64_after_hwframe+0x76/0x7e

[CAUSE]
Mount option "rescue=idatacsums" will completely skip loading the csum
tree, so that any data read will not find any data csum thus we will
ignore data checksum verification.

Normally call sites utilizing csum tree will check the fs state flag
NO_DATA_CSUMS bit, but unfortunately scrub does not check that bit at all.

This results in scrub to call btrfs_search_slot() on a NULL pointer
and triggered above crash.

[FIX]
Check both extent and csum tree root before doing any tree search.</Note>
    </Notes>
    <CVE>CVE-2025-38059</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: copy_verifier_state() should copy 'loop_entry' field

The bpf_verifier_state.loop_entry state should be copied by
copy_verifier_state(). Otherwise, .loop_entry values from unrelated
states would poison env-&gt;cur_state.

Additionally, env-&gt;stack should not contain any states with
.loop_entry != NULL. The states in env-&gt;stack are yet to be verified,
while .loop_entry is set for states that reached an equivalent state.
This means that env-&gt;cur_state-&gt;loop_entry should always be NULL after
pop_stack().

See the selftest in the next commit for an example of the program that
is not safe yet is accepted by verifier w/o this fix.

This change has some verification performance impact for selftests:

File                                Program                       Insns (A)  Insns (B)  Insns   (DIFF)  States (A)  States (B)  States (DIFF)
----------------------------------  ----------------------------  ---------  ---------  --------------  ----------  ----------  -------------
arena_htab.bpf.o                    arena_htab_llvm                     717        426  -291 (-40.59%)          57          37  -20 (-35.09%)
arena_htab_asm.bpf.o                arena_htab_asm                      597        445  -152 (-25.46%)          47          37  -10 (-21.28%)
arena_list.bpf.o                    arena_list_del                      309        279    -30 (-9.71%)          23          14   -9 (-39.13%)
iters.bpf.o                         iter_subprog_check_stacksafe        155        141    -14 (-9.03%)          15          14    -1 (-6.67%)
iters.bpf.o                         iter_subprog_iters                 1094       1003    -91 (-8.32%)          88          83    -5 (-5.68%)
iters.bpf.o                         loop_state_deps2                    479        725  +246 (+51.36%)          46          63  +17 (+36.96%)
kmem_cache_iter.bpf.o               open_coded_iter                      63         59     -4 (-6.35%)           7           6   -1 (-14.29%)
verifier_bits_iter.bpf.o            max_words                            92         84     -8 (-8.70%)           8           7   -1 (-12.50%)
verifier_iterating_callbacks.bpf.o  cond_break2                         113        107     -6 (-5.31%)          12          12    +0 (+0.00%)

And significant negative impact for sched_ext:

File               Program                 Insns (A)  Insns (B)  Insns         (DIFF)  States (A)  States (B)  States      (DIFF)
-----------------  ----------------------  ---------  ---------  --------------------  ----------  ----------  ------------------
bpf.bpf.o          lavd_init                    7039      14723      +7684 (+109.16%)         490        1139     +649 (+132.45%)
bpf.bpf.o          layered_dispatch            11485      10548         -937 (-8.16%)         848         762       -86 (-10.14%)
bpf.bpf.o          layered_dump                 7422    1000001  +992579 (+13373.47%)         681       31178  +30497 (+4478.27%)
bpf.bpf.o          layered_enqueue             16854      71127     +54273 (+322.02%)        1611        6450    +4839 (+300.37%)
bpf.bpf.o          p2dq_dispatch                 665        791        +126 (+18.95%)          68          78       +10 (+14.71%)
bpf.bpf.o          p2dq_init                    2343       2980        +637 (+27.19%)         201         237       +36 (+17.91%)
bpf.bpf.o          refresh_layer_cpumasks      16487     674760   +658273 (+3992.68%)        1770       65370  +63600 (+3593.22%)
bpf.bpf.o          rusty_select_cpu             1937      40872    +38935 (+2010.07%)         177        3210   +3033 (+1713.56%)
scx_central.bpf.o  central_dispatch              636       2687      +2051 (+322.48%)          63         227     +164 (+260.32%)
scx_nest.bpf.o     nest_init                     636        815        +179 (+28.14%)          60          73       +13 (+21.67%)
scx_qmap.bpf.o     qmap_dispatch      
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-38060</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: pktgen: fix access outside of user given buffer in pktgen_thread_write()

Honour the user given buffer size for the strn_len() calls (otherwise
strn_len() will access memory outside of the user given buffer).</Note>
    </Notes>
    <CVE>CVE-2025-38061</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

genirq/msi: Store the IOMMU IOVA directly in msi_desc instead of iommu_cookie

The IOMMU translation for MSI message addresses has been a 2-step process,
separated in time:

 1) iommu_dma_prepare_msi(): A cookie pointer containing the IOVA address
    is stored in the MSI descriptor when an MSI interrupt is allocated.

 2) iommu_dma_compose_msi_msg(): this cookie pointer is used to compute a
    translated message address.

This has an inherent lifetime problem for the pointer stored in the cookie
that must remain valid between the two steps. However, there is no locking
at the irq layer that helps protect the lifetime. Today, this works under
the assumption that the iommu domain is not changed while MSI interrupts
being programmed. This is true for normal DMA API users within the kernel,
as the iommu domain is attached before the driver is probed and cannot be
changed while a driver is attached.

Classic VFIO type1 also prevented changing the iommu domain while VFIO was
running as it does not support changing the "container" after starting up.

However, iommufd has improved this so that the iommu domain can be changed
during VFIO operation. This potentially allows userspace to directly race
VFIO_DEVICE_ATTACH_IOMMUFD_PT (which calls iommu_attach_group()) and
VFIO_DEVICE_SET_IRQS (which calls into iommu_dma_compose_msi_msg()).

This potentially causes both the cookie pointer and the unlocked call to
iommu_get_domain_for_dev() on the MSI translation path to become UAFs.

Fix the MSI cookie UAF by removing the cookie pointer. The translated IOVA
address is already known during iommu_dma_prepare_msi() and cannot change.
Thus, it can simply be stored as an integer in the MSI descriptor.

The other UAF related to iommu_get_domain_for_dev() will be addressed in
patch "iommu: Make iommu_dma_prepare_msi() into a generic operation" by
using the IOMMU group mutex.</Note>
    </Notes>
    <CVE>CVE-2025-38062</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

dm: fix unconditional IO throttle caused by REQ_PREFLUSH

When a bio with REQ_PREFLUSH is submitted to dm, __send_empty_flush()
generates a flush_bio with REQ_OP_WRITE | REQ_PREFLUSH | REQ_SYNC,
which causes the flush_bio to be throttled by wbt_wait().

An example from v5.4, similar problem also exists in upstream:

    crash&gt; bt 2091206
    PID: 2091206  TASK: ffff2050df92a300  CPU: 109  COMMAND: "kworker/u260:0"
     #0 [ffff800084a2f7f0] __switch_to at ffff80004008aeb8
     #1 [ffff800084a2f820] __schedule at ffff800040bfa0c4
     #2 [ffff800084a2f880] schedule at ffff800040bfa4b4
     #3 [ffff800084a2f8a0] io_schedule at ffff800040bfa9c4
     #4 [ffff800084a2f8c0] rq_qos_wait at ffff8000405925bc
     #5 [ffff800084a2f940] wbt_wait at ffff8000405bb3a0
     #6 [ffff800084a2f9a0] __rq_qos_throttle at ffff800040592254
     #7 [ffff800084a2f9c0] blk_mq_make_request at ffff80004057cf38
     #8 [ffff800084a2fa60] generic_make_request at ffff800040570138
     #9 [ffff800084a2fae0] submit_bio at ffff8000405703b4
    #10 [ffff800084a2fb50] xlog_write_iclog at ffff800001280834 [xfs]
    #11 [ffff800084a2fbb0] xlog_sync at ffff800001280c3c [xfs]
    #12 [ffff800084a2fbf0] xlog_state_release_iclog at ffff800001280df4 [xfs]
    #13 [ffff800084a2fc10] xlog_write at ffff80000128203c [xfs]
    #14 [ffff800084a2fcd0] xlog_cil_push at ffff8000012846dc [xfs]
    #15 [ffff800084a2fda0] xlog_cil_push_work at ffff800001284a2c [xfs]
    #16 [ffff800084a2fdb0] process_one_work at ffff800040111d08
    #17 [ffff800084a2fe00] worker_thread at ffff8000401121cc
    #18 [ffff800084a2fe70] kthread at ffff800040118de4

After commit 2def2845cc33 ("xfs: don't allow log IO to be throttled"),
the metadata submitted by xlog_write_iclog() should not be throttled.
But due to the existence of the dm layer, throttling flush_bio indirectly
causes the metadata bio to be throttled.

Fix this by conditionally adding REQ_IDLE to flush_bio.bi_opf, which makes
wbt_should_throttle() return false to avoid wbt_wait().</Note>
    </Notes>
    <CVE>CVE-2025-38063</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

virtio: break and reset virtio devices on device_shutdown()

Hongyu reported a hang on kexec in a VM. QEMU reported invalid memory
accesses during the hang.

	Invalid read at addr 0x102877002, size 2, region '(null)', reason: rejected
	Invalid write at addr 0x102877A44, size 2, region '(null)', reason: rejected
	...

It was traced down to virtio-console. Kexec works fine if virtio-console
is not in use.

The issue is that virtio-console continues to write to the MMIO even after
underlying virtio-pci device is reset.

Additionally, Eric noticed that IOMMUs are reset before devices, if
devices are not reset on shutdown they continue to poke at guest memory
and get errors from the IOMMU. Some devices get wedged then.

The problem can be solved by breaking all virtio devices on virtio
bus shutdown, then resetting them.</Note>
    </Notes>
    <CVE>CVE-2025-38064</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

orangefs: Do not truncate file size

'len' is used to store the result of i_size_read(), so making 'len'
a size_t results in truncation to 4GiB on 32-bit systems.</Note>
    </Notes>
    <CVE>CVE-2025-38065</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

crypto: lzo - Fix compression buffer overrun

Unlike the decompression code, the compression code in LZO never
checked for output overruns.  It instead assumes that the caller
always provides enough buffer space, disregarding the buffer length
provided by the caller.

Add a safe compression interface that checks for the end of buffer
before each write.  Use the safe interface in crypto/lzo.</Note>
    </Notes>
    <CVE>CVE-2025-38068</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

libnvdimm/labels: Fix divide error in nd_label_data_init()

If a faulty CXL memory device returns a broken zero LSA size in its
memory device information (Identify Memory Device (Opcode 4000h), CXL
spec. 3.1, 8.2.9.9.1.1), a divide error occurs in the libnvdimm
driver:

 Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI
 RIP: 0010:nd_label_data_init+0x10e/0x800 [libnvdimm]

Code and flow:

1) CXL Command 4000h returns LSA size = 0
2) config_size is assigned to zero LSA size (CXL pmem driver):

drivers/cxl/pmem.c:             .config_size = mds-&gt;lsa_size,

3) max_xfer is set to zero (nvdimm driver):

drivers/nvdimm/label.c: max_xfer = min_t(size_t, ndd-&gt;nsarea.max_xfer, config_size);

4) A subsequent DIV_ROUND_UP() causes a division by zero:

drivers/nvdimm/label.c: /* Make our initial read size a multiple of max_xfer size */
drivers/nvdimm/label.c: read_size = min(DIV_ROUND_UP(read_size, max_xfer) * max_xfer,
drivers/nvdimm/label.c-                 config_size);

Fix this by checking the config size parameter by extending an
existing check.</Note>
    </Notes>
    <CVE>CVE-2025-38072</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vhost-scsi: protect vq-&gt;log_used with vq-&gt;mutex

The vhost-scsi completion path may access vq-&gt;log_base when vq-&gt;log_used is
already set to false.

    vhost-thread                       QEMU-thread

vhost_scsi_complete_cmd_work()
-&gt; vhost_add_used()
   -&gt; vhost_add_used_n()
      if (unlikely(vq-&gt;log_used))
                                      QEMU disables vq-&gt;log_used
                                      via VHOST_SET_VRING_ADDR.
                                      mutex_lock(&amp;vq-&gt;mutex);
                                      vq-&gt;log_used = false now!
                                      mutex_unlock(&amp;vq-&gt;mutex);

				      QEMU gfree(vq-&gt;log_base)
        log_used()
        -&gt; log_write(vq-&gt;log_base)

Assuming the VMM is QEMU. The vq-&gt;log_base is from QEMU userpace and can be
reclaimed via gfree(). As a result, this causes invalid memory writes to
QEMU userspace.

The control queue path has the same issue.</Note>
    </Notes>
    <CVE>CVE-2025-38074</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

platform/x86: dell-wmi-sysman: Avoid buffer overflow in current_password_store()

If the 'buf' array received from the user contains an empty string, the
'length' variable will be zero. Accessing the 'buf' array element with
index 'length - 1' will result in a buffer overflow.

Add a check for an empty string.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2025-38077</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ALSA: pcm: Fix race of buffer access at PCM OSS layer

The PCM OSS layer tries to clear the buffer with the silence data at
initialization (or reconfiguration) of a stream with the explicit call
of snd_pcm_format_set_silence() with runtime-&gt;dma_area.  But this may
lead to a UAF because the accessed runtime-&gt;dma_area might be freed
concurrently, as it's performed outside the PCM ops.

For avoiding it, move the code into the PCM core and perform it inside
the buffer access lock, so that it won't be changed during the
operation.</Note>
    </Notes>
    <CVE>CVE-2025-38078</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

crypto: algif_hash - fix double free in hash_accept

If accept(2) is called on socket type algif_hash with
MSG_MORE flag set and crypto_ahash_import fails,
sk2 is freed. However, it is also freed in af_alg_release,
leading to slab-use-after-free error.</Note>
    </Notes>
    <CVE>CVE-2025-38079</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Increase block_sequence array size

[Why]
It's possible to generate more than 50 steps in hwss_build_fast_sequence,
for example with a 6-pipe asic where all pipes are in one MPC chain. This
overflows the block_sequence buffer and corrupts block_sequence_steps,
causing a crash.

[How]
Expand block_sequence to 100 items. A naive upper bound on the possible
number of steps for a 6-pipe asic, ignoring the potential for steps to be
mutually exclusive, is 91 with current code, therefore 100 is sufficient.</Note>
    </Notes>
    <CVE>CVE-2025-38080</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

spi-rockchip: Fix register out of bounds access

Do not write native chip select stuff for GPIO chip selects.
GPIOs can be numbered much higher than native CS.
Also, it makes no sense.</Note>
    </Notes>
    <CVE>CVE-2025-38081</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net_sched: prio: fix a race in prio_tune()

Gerrard Tai reported a race condition in PRIO, whenever SFQ perturb timer
fires at the wrong time.

The race is as follows:

CPU 0                                 CPU 1
[1]: lock root
[2]: qdisc_tree_flush_backlog()
[3]: unlock root
 |
 |                                    [5]: lock root
 |                                    [6]: rehash
 |                                    [7]: qdisc_tree_reduce_backlog()
 |
[4]: qdisc_put()

This can be abused to underflow a parent's qlen.

Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog()
should fix the race, because all packets will be purged from the qdisc
before releasing the lock.</Note>
    </Notes>
    <CVE>CVE-2025-38083</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mm/hugetlb: unshare page tables during VMA split, not before

Currently, __split_vma() triggers hugetlb page table unsharing through
vm_ops-&gt;may_split().  This happens before the VMA lock and rmap locks are
taken - which is too early, it allows racing VMA-locked page faults in our
process and racing rmap walks from other processes to cause page tables to
be shared again before we actually perform the split.

Fix it by explicitly calling into the hugetlb unshare logic from
__split_vma() in the same place where THP splitting also happens.  At that
point, both the VMA and the rmap(s) are write-locked.

An annoying detail is that we can now call into the helper
hugetlb_unshare_pmds() from two different locking contexts:

1. from hugetlb_split(), holding:
    - mmap lock (exclusively)
    - VMA lock
    - file rmap lock (exclusively)
2. hugetlb_unshare_all_pmds(), which I think is designed to be able to
   call us with only the mmap lock held (in shared mode), but currently
   only runs while holding mmap lock (exclusively) and VMA lock

Backporting note:
This commit fixes a racy protection that was introduced in commit
b30c14cd6102 ("hugetlb: unshare some PMDs when splitting VMAs"); that
commit claimed to fix an issue introduced in 5.13, but it should actually
also go all the way back.

[jannh@google.com: v2]</Note>
    </Notes>
    <CVE>CVE-2025-38084</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race

huge_pmd_unshare() drops a reference on a page table that may have
previously been shared across processes, potentially turning it into a
normal page table used in another process in which unrelated VMAs can
afterwards be installed.

If this happens in the middle of a concurrent gup_fast(), gup_fast() could
end up walking the page tables of another process.  While I don't see any
way in which that immediately leads to kernel memory corruption, it is
really weird and unexpected.

Fix it with an explicit broadcast IPI through tlb_remove_table_sync_one(),
just like we do in khugepaged when removing page tables for a THP
collapse.</Note>
    </Notes>
    <CVE>CVE-2025-38085</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/sched: fix use-after-free in taprio_dev_notifier

Since taprio's taprio_dev_notifier() isn't protected by an
RCU read-side critical section, a race with advance_sched()
can lead to a use-after-free.

Adding rcu_read_lock() inside taprio_dev_notifier() prevents this.</Note>
    </Notes>
    <CVE>CVE-2025-38087</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

powerpc/powernv/memtrace: Fix out of bounds issue in memtrace mmap

memtrace mmap issue has an out of bounds issue. This patch fixes the by
checking that the requested mapping region size should stay within the
allocated region size.</Note>
    </Notes>
    <CVE>CVE-2025-38088</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sunrpc: handle SVC_GARBAGE during svc auth processing as auth error

tianshuo han reported a remotely-triggerable crash if the client sends a
kernel RPC server a specially crafted packet. If decoding the RPC reply
fails in such a way that SVC_GARBAGE is returned without setting the
rq_accept_statp pointer, then that pointer can be dereferenced and a
value stored there.

If it's the first time the thread has processed an RPC, then that
pointer will be set to NULL and the kernel will crash. In other cases,
it could create a memory scribble.

The server sunrpc code treats a SVC_GARBAGE return from svc_authenticate
or pg_authenticate as if it should send a GARBAGE_ARGS reply. RFC 5531
says that if authentication fails that the RPC should be rejected
instead with a status of AUTH_ERR.

Handle a SVC_GARBAGE return as an AUTH_ERROR, with a reason of
AUTH_BADCRED instead of returning GARBAGE_ARGS in that case. This
sidesteps the whole problem of touching the rpc_accept_statp pointer in
this situation and avoids the crash.</Note>
    </Notes>
    <CVE>CVE-2025-38089</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drivers/rapidio/rio_cm.c: prevent possible heap overwrite

In

riocm_cdev_ioctl(RIO_CM_CHAN_SEND)
   -&gt; cm_chan_msg_send()
      -&gt; riocm_ch_send()

cm_chan_msg_send() checks that userspace didn't send too much data but
riocm_ch_send() failed to check that userspace sent sufficient data.  The
result is that riocm_ch_send() can write to fields in the rio_ch_chan_hdr
which were outside the bounds of the space which cm_chan_msg_send()
allocated.

Address this by teaching riocm_ch_send() to check that the entire
rio_ch_chan_hdr was copied in from userspace.</Note>
    </Notes>
    <CVE>CVE-2025-38090</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: check stream id dml21 wrapper to get plane_id

[Why &amp; How]
Fix a false positive warning which occurs due to lack of correct checks
when querying plane_id in DML21. This fixes the warning when performing a
mode1 reset (cat /sys/kernel/debug/dri/1/amdgpu_gpu_recover):

[   35.751250] WARNING: CPU: 11 PID: 326 at /tmp/amd.PHpyAl7v/amd/amdgpu/../display/dc/dml2/dml2_dc_resource_mgmt.c:91 dml2_map_dc_pipes+0x243d/0x3f40 [amdgpu]
[   35.751434] Modules linked in: amdgpu(OE) amddrm_ttm_helper(OE) amdttm(OE) amddrm_buddy(OE) amdxcp(OE) amddrm_exec(OE) amd_sched(OE) amdkcl(OE) drm_suballoc_helper drm_ttm_helper ttm drm_display_helper cec rc_core i2c_algo_bit rfcomm qrtr cmac algif_hash algif_skcipher af_alg bnep amd_atl intel_rapl_msr intel_rapl_common snd_hda_codec_hdmi snd_hda_intel edac_mce_amd snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec kvm_amd snd_hda_core snd_hwdep snd_pcm kvm snd_seq_midi snd_seq_midi_event snd_rawmidi crct10dif_pclmul polyval_clmulni polyval_generic btusb ghash_clmulni_intel sha256_ssse3 btrtl sha1_ssse3 snd_seq btintel aesni_intel btbcm btmtk snd_seq_device crypto_simd sunrpc cryptd bluetooth snd_timer ccp binfmt_misc rapl snd i2c_piix4 wmi_bmof gigabyte_wmi k10temp i2c_smbus soundcore gpio_amdpt mac_hid sch_fq_codel msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs ip_tables x_tables autofs4 hid_generic usbhid hid crc32_pclmul igc ahci xhci_pci libahci xhci_pci_renesas video wmi
[   35.751501] CPU: 11 UID: 0 PID: 326 Comm: kworker/u64:9 Tainted: G           OE      6.11.0-21-generic #21~24.04.1-Ubuntu
[   35.751504] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
[   35.751505] Hardware name: Gigabyte Technology Co., Ltd. X670E AORUS PRO X/X670E AORUS PRO X, BIOS F30 05/22/2024
[   35.751506] Workqueue: amdgpu-reset-dev amdgpu_debugfs_reset_work [amdgpu]
[   35.751638] RIP: 0010:dml2_map_dc_pipes+0x243d/0x3f40 [amdgpu]
[   35.751794] Code: 6d 0c 00 00 8b 84 24 88 00 00 00 41 3b 44 9c 20 0f 84 fc 07 00 00 48 83 c3 01 48 83 fb 06 75 b3 4c 8b 64 24 68 4c 8b 6c 24 40 &lt;0f&gt; 0b b8 06 00 00 00 49 8b 94 24 a0 49 00 00 89 c3 83 f8 07 0f 87
[   35.751796] RSP: 0018:ffffbfa3805d7680 EFLAGS: 00010246
[   35.751798] RAX: 0000000000010000 RBX: 0000000000000006 RCX: 0000000000000000
[   35.751799] RDX: 0000000000000000 RSI: 0000000000000005 RDI: 0000000000000000
[   35.751800] RBP: ffffbfa3805d78f0 R08: 0000000000000000 R09: 0000000000000000
[   35.751801] R10: 0000000000000000 R11: 0000000000000000 R12: ffffbfa383249000
[   35.751802] R13: ffffa0e68f280000 R14: ffffbfa383249658 R15: 0000000000000000
[   35.751803] FS:  0000000000000000(0000) GS:ffffa0edbe580000(0000) knlGS:0000000000000000
[   35.751804] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   35.751805] CR2: 00005d847ef96c58 CR3: 000000041de3e000 CR4: 0000000000f50ef0
[   35.751806] PKRU: 55555554
[   35.751807] Call Trace:
[   35.751810]  &lt;TASK&gt;
[   35.751816]  ? show_regs+0x6c/0x80
[   35.751820]  ? __warn+0x88/0x140
[   35.751822]  ? dml2_map_dc_pipes+0x243d/0x3f40 [amdgpu]
[   35.751964]  ? report_bug+0x182/0x1b0
[   35.751969]  ? handle_bug+0x6e/0xb0
[   35.751972]  ? exc_invalid_op+0x18/0x80
[   35.751974]  ? asm_exc_invalid_op+0x1b/0x20
[   35.751978]  ? dml2_map_dc_pipes+0x243d/0x3f40 [amdgpu]
[   35.752117]  ? math_pow+0x48/0xa0 [amdgpu]
[   35.752256]  ? srso_alias_return_thunk+0x5/0xfbef5
[   35.752260]  ? math_pow+0x48/0xa0 [amdgpu]
[   35.752400]  ? srso_alias_return_thunk+0x5/0xfbef5
[   35.752403]  ? math_pow+0x11/0xa0 [amdgpu]
[   35.752524]  ? srso_alias_return_thunk+0x5/0xfbef5
[   35.752526]  ? core_dcn4_mode_programming+0xe4d/0x20d0 [amdgpu]
[   35.752663]  ? srso_alias_return_thunk+0x5/0xfbef5
[   35.752669]  dml21_validate+0x3d4/0x980 [amdgpu]

(cherry picked from commit f8ad62c0a93e5dd94243e10f1b742232e4d6411e)</Note>
    </Notes>
    <CVE>CVE-2025-38091</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: cadence: macb: Fix a possible deadlock in macb_halt_tx.

There is a situation where after THALT is set high, TGO stays high as
well. Because jiffies are never updated, as we are in a context with
interrupts disabled, we never exit that loop and have a deadlock.

That deadlock was noticed on a sama5d4 device that stayed locked for days.

Use retries instead of jiffies so that the timeout really works and we do
not have a deadlock anymore.</Note>
    </Notes>
    <CVE>CVE-2025-38094</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

dma-buf: insert memory barrier before updating num_fences

smp_store_mb() inserts memory barrier after storing operation.
It is different with what the comment is originally aiming so Null
pointer dereference can be happened if memory update is reordered.</Note>
    </Notes>
    <CVE>CVE-2025-38095</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

espintcp: remove encap socket caching to avoid reference leak

The current scheme for caching the encap socket can lead to reference
leaks when we try to delete the netns.

The reference chain is: xfrm_state -&gt; enacp_sk -&gt; netns

Since the encap socket is a userspace socket, it holds a reference on
the netns. If we delete the espintcp state (through flush or
individual delete) before removing the netns, the reference on the
socket is dropped and the netns is correctly deleted. Otherwise, the
netns may not be reachable anymore (if all processes within the ns
have terminated), so we cannot delete the xfrm state to drop its
reference on the socket.

This patch results in a small (~2% in my tests) performance
regression.

A GC-type mechanism could be added for the socket cache, to clear
references if the state hasn't been used "recently", but it's a lot
more complex than just not caching the socket.</Note>
    </Notes>
    <CVE>CVE-2025-38097</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Don't treat wb connector as physical in create_validate_stream_for_sink

Don't try to operate on a drm_wb_connector as an amdgpu_dm_connector.
While dereferencing aconnector-&gt;base will "work" it's wrong and
might lead to unknown bad things. Just... don't.</Note>
    </Notes>
    <CVE>CVE-2025-38098</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: Disable SCO support if READ_VOICE_SETTING is unsupported/broken

A SCO connection without the proper voice_setting can cause
the controller to lock up.</Note>
    </Notes>
    <CVE>CVE-2025-38099</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

x86/iopl: Cure TIF_IO_BITMAP inconsistencies

io_bitmap_exit() is invoked from exit_thread() when a task exists or
when a fork fails. In the latter case the exit_thread() cleans up
resources which were allocated during fork().

io_bitmap_exit() invokes task_update_io_bitmap(), which in turn ends up
in tss_update_io_bitmap(). tss_update_io_bitmap() operates on the
current task. If current has TIF_IO_BITMAP set, but no bitmap installed,
tss_update_io_bitmap() crashes with a NULL pointer dereference.

There are two issues, which lead to that problem:

  1) io_bitmap_exit() should not invoke task_update_io_bitmap() when
     the task, which is cleaned up, is not the current task. That's a
     clear indicator for a cleanup after a failed fork().

  2) A task should not have TIF_IO_BITMAP set and neither a bitmap
     installed nor IOPL emulation level 3 activated.

     This happens when a kernel thread is created in the context of
     a user space thread, which has TIF_IO_BITMAP set as the thread
     flags are copied and the IO bitmap pointer is cleared.

     Other than in the failed fork() case this has no impact because
     kernel threads including IO workers never return to user space and
     therefore never invoke tss_update_io_bitmap().

Cure this by adding the missing cleanups and checks:

  1) Prevent io_bitmap_exit() to invoke task_update_io_bitmap() if
     the to be cleaned up task is not the current task.

  2) Clear TIF_IO_BITMAP in copy_thread() unconditionally. For user
     space forks it is set later, when the IO bitmap is inherited in
     io_bitmap_share().

For paranoia sake, add a warning into tss_update_io_bitmap() to catch
the case, when that code is invoked with inconsistent state.</Note>
    </Notes>
    <CVE>CVE-2025-38100</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

VMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify

During our test, it is found that a warning can be trigger in try_grab_folio
as follow:

  ------------[ cut here ]------------
  WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130
  Modules linked in:
  CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef)
  RIP: 0010:try_grab_folio+0x106/0x130
  Call Trace:
   &lt;TASK&gt;
   follow_huge_pmd+0x240/0x8e0
   follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0
   follow_pud_mask.constprop.0.isra.0+0x14a/0x170
   follow_page_mask+0x1c2/0x1f0
   __get_user_pages+0x176/0x950
   __gup_longterm_locked+0x15b/0x1060
   ? gup_fast+0x120/0x1f0
   gup_fast_fallback+0x17e/0x230
   get_user_pages_fast+0x5f/0x80
   vmci_host_unlocked_ioctl+0x21c/0xf80
  RIP: 0033:0x54d2cd
  ---[ end trace 0000000000000000 ]---

Digging into the source, context-&gt;notify_page may init by get_user_pages_fast
and can be seen in vmci_ctx_unset_notify which will try to put_page. However
get_user_pages_fast is not finished here and lead to following
try_grab_folio warning. The race condition is shown as follow:

cpu0			cpu1
vmci_host_do_set_notify
vmci_host_setup_notify
get_user_pages_fast(uva, 1, FOLL_WRITE, &amp;context-&gt;notify_page);
lockless_pages_from_mm
gup_pgd_range
gup_huge_pmd  // update &amp;context-&gt;notify_page
			vmci_host_do_set_notify
			vmci_ctx_unset_notify
			notify_page = context-&gt;notify_page;
			if (notify_page)
			put_page(notify_page);	// page is freed
__gup_longterm_locked
__get_user_pages
follow_trans_huge_pmd
try_grab_folio // warn here

To slove this, use local variable page to make notify_page can be seen
after finish get_user_pages_fast.</Note>
    </Notes>
    <CVE>CVE-2025-38102</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: Replace Mutex with Spinlock for RLCG register access to avoid Priority Inversion in SRIOV

RLCG Register Access is a way for virtual functions to safely access GPU
registers in a virtualized environment., including TLB flushes and
register reads. When multiple threads or VFs try to access the same
registers simultaneously, it can lead to race conditions. By using the
RLCG interface, the driver can serialize access to the registers. This
means that only one thread can access the registers at a time,
preventing conflicts and ensuring that operations are performed
correctly. Additionally, when a low-priority task holds a mutex that a
high-priority task needs, ie., If a thread holding a spinlock tries to
acquire a mutex, it can lead to priority inversion. register access in
amdgpu_virt_rlcg_reg_rw especially in a fast code path is critical.

The call stack shows that the function amdgpu_virt_rlcg_reg_rw is being
called, which attempts to acquire the mutex. This function is invoked
from amdgpu_sriov_wreg, which in turn is called from
gmc_v11_0_flush_gpu_tlb.

The [ BUG: Invalid wait context ] indicates that a thread is trying to
acquire a mutex while it is in a context that does not allow it to sleep
(like holding a spinlock).

Fixes the below:

[  253.013423] =============================
[  253.013434] [ BUG: Invalid wait context ]
[  253.013446] 6.12.0-amdstaging-drm-next-lol-050225 #14 Tainted: G     U     OE
[  253.013464] -----------------------------
[  253.013475] kworker/0:1/10 is trying to lock:
[  253.013487] ffff9f30542e3cf8 (&amp;adev-&gt;virt.rlcg_reg_lock){+.+.}-{3:3}, at: amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu]
[  253.013815] other info that might help us debug this:
[  253.013827] context-{4:4}
[  253.013835] 3 locks held by kworker/0:1/10:
[  253.013847]  #0: ffff9f3040050f58 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x3f5/0x680
[  253.013877]  #1: ffffb789c008be40 ((work_completion)(&amp;wfc.work)){+.+.}-{0:0}, at: process_one_work+0x1d6/0x680
[  253.013905]  #2: ffff9f3054281838 (&amp;adev-&gt;gmc.invalidate_lock){+.+.}-{2:2}, at: gmc_v11_0_flush_gpu_tlb+0x198/0x4f0 [amdgpu]
[  253.014154] stack backtrace:
[  253.014164] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Tainted: G     U     OE      6.12.0-amdstaging-drm-next-lol-050225 #14
[  253.014189] Tainted: [U]=USER, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
[  253.014203] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/18/2024
[  253.014224] Workqueue: events work_for_cpu_fn
[  253.014241] Call Trace:
[  253.014250]  &lt;TASK&gt;
[  253.014260]  dump_stack_lvl+0x9b/0xf0
[  253.014275]  dump_stack+0x10/0x20
[  253.014287]  __lock_acquire+0xa47/0x2810
[  253.014303]  ? srso_alias_return_thunk+0x5/0xfbef5
[  253.014321]  lock_acquire+0xd1/0x300
[  253.014333]  ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu]
[  253.014562]  ? __lock_acquire+0xa6b/0x2810
[  253.014578]  __mutex_lock+0x85/0xe20
[  253.014591]  ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu]
[  253.014782]  ? sched_clock_noinstr+0x9/0x10
[  253.014795]  ? srso_alias_return_thunk+0x5/0xfbef5
[  253.014808]  ? local_clock_noinstr+0xe/0xc0
[  253.014822]  ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu]
[  253.015012]  ? srso_alias_return_thunk+0x5/0xfbef5
[  253.015029]  mutex_lock_nested+0x1b/0x30
[  253.015044]  ? mutex_lock_nested+0x1b/0x30
[  253.015057]  amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu]
[  253.015249]  amdgpu_sriov_wreg+0xc5/0xd0 [amdgpu]
[  253.015435]  gmc_v11_0_flush_gpu_tlb+0x44b/0x4f0 [amdgpu]
[  253.015667]  gfx_v11_0_hw_init+0x499/0x29c0 [amdgpu]
[  253.015901]  ? __pfx_smu_v13_0_update_pcie_parameters+0x10/0x10 [amdgpu]
[  253.016159]  ? srso_alias_return_thunk+0x5/0xfbef5
[  253.016173]  ? smu_hw_init+0x18d/0x300 [amdgpu]
[  253.016403]  amdgpu_device_init+0x29ad/0x36a0 [amdgpu]
[  253.016614]  amdgpu_driver_load_kms+0x1a/0xc0 [amdgpu]
[  253.0170
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-38104</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ALSA: usb-audio: Kill timer properly at removal

The USB-audio MIDI code initializes the timer, but in a rare case, the
driver might be freed without the disconnect call.  This leaves the
timer in an active state while the assigned object is released via
snd_usbmidi_free(), which ends up with a kernel warning when the debug
configuration is enabled, as spotted by fuzzer.

For avoiding the problem, put timer_shutdown_sync() at
snd_usbmidi_free(), so that the timer can be killed properly.
While we're at it, replace the existing timer_delete_sync() at the
disconnect callback with timer_shutdown_sync(), too.</Note>
    </Notes>
    <CVE>CVE-2025-38105</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

io_uring: fix use-after-free of sq-&gt;thread in __io_uring_show_fdinfo()

syzbot reports:

BUG: KASAN: slab-use-after-free in getrusage+0x1109/0x1a60
Read of size 8 at addr ffff88810de2d2c8 by task a.out/304

CPU: 0 UID: 0 PID: 304 Comm: a.out Not tainted 6.16.0-rc1 #1 PREEMPT(voluntary)
Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x53/0x70
 print_report+0xd0/0x670
 ? __pfx__raw_spin_lock_irqsave+0x10/0x10
 ? getrusage+0x1109/0x1a60
 kasan_report+0xce/0x100
 ? getrusage+0x1109/0x1a60
 getrusage+0x1109/0x1a60
 ? __pfx_getrusage+0x10/0x10
 __io_uring_show_fdinfo+0x9fe/0x1790
 ? ksys_read+0xf7/0x1c0
 ? do_syscall_64+0xa4/0x260
 ? vsnprintf+0x591/0x1100
 ? __pfx___io_uring_show_fdinfo+0x10/0x10
 ? __pfx_vsnprintf+0x10/0x10
 ? mutex_trylock+0xcf/0x130
 ? __pfx_mutex_trylock+0x10/0x10
 ? __pfx_show_fd_locks+0x10/0x10
 ? io_uring_show_fdinfo+0x57/0x80
 io_uring_show_fdinfo+0x57/0x80
 seq_show+0x38c/0x690
 seq_read_iter+0x3f7/0x1180
 ? inode_set_ctime_current+0x160/0x4b0
 seq_read+0x271/0x3e0
 ? __pfx_seq_read+0x10/0x10
 ? __pfx__raw_spin_lock+0x10/0x10
 ? __mark_inode_dirty+0x402/0x810
 ? selinux_file_permission+0x368/0x500
 ? file_update_time+0x10f/0x160
 vfs_read+0x177/0xa40
 ? __pfx___handle_mm_fault+0x10/0x10
 ? __pfx_vfs_read+0x10/0x10
 ? mutex_lock+0x81/0xe0
 ? __pfx_mutex_lock+0x10/0x10
 ? fdget_pos+0x24d/0x4b0
 ksys_read+0xf7/0x1c0
 ? __pfx_ksys_read+0x10/0x10
 ? do_user_addr_fault+0x43b/0x9c0
 do_syscall_64+0xa4/0x260
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f0f74170fc9
Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 8
RSP: 002b:00007fffece049e8 EFLAGS: 00000206 ORIG_RAX: 0000000000000000
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0f74170fc9
RDX: 0000000000001000 RSI: 00007fffece049f0 RDI: 0000000000000004
RBP: 00007fffece05ad0 R08: 0000000000000000 R09: 00007fffece04d90
R10: 0000000000000000 R11: 0000000000000206 R12: 00005651720a1100
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
 &lt;/TASK&gt;

Allocated by task 298:
 kasan_save_stack+0x33/0x60
 kasan_save_track+0x14/0x30
 __kasan_slab_alloc+0x6e/0x70
 kmem_cache_alloc_node_noprof+0xe8/0x330
 copy_process+0x376/0x5e00
 create_io_thread+0xab/0xf0
 io_sq_offload_create+0x9ed/0xf20
 io_uring_setup+0x12b0/0x1cc0
 do_syscall_64+0xa4/0x260
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Freed by task 22:
 kasan_save_stack+0x33/0x60
 kasan_save_track+0x14/0x30
 kasan_save_free_info+0x3b/0x60
 __kasan_slab_free+0x37/0x50
 kmem_cache_free+0xc4/0x360
 rcu_core+0x5ff/0x19f0
 handle_softirqs+0x18c/0x530
 run_ksoftirqd+0x20/0x30
 smpboot_thread_fn+0x287/0x6c0
 kthread+0x30d/0x630
 ret_from_fork+0xef/0x1a0
 ret_from_fork_asm+0x1a/0x30

Last potentially related work creation:
 kasan_save_stack+0x33/0x60
 kasan_record_aux_stack+0x8c/0xa0
 __call_rcu_common.constprop.0+0x68/0x940
 __schedule+0xff2/0x2930
 __cond_resched+0x4c/0x80
 mutex_lock+0x5c/0xe0
 io_uring_del_tctx_node+0xe1/0x2b0
 io_uring_clean_tctx+0xb7/0x160
 io_uring_cancel_generic+0x34e/0x760
 do_exit+0x240/0x2350
 do_group_exit+0xab/0x220
 __x64_sys_exit_group+0x39/0x40
 x64_sys_call+0x1243/0x1840
 do_syscall_64+0xa4/0x260
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

The buggy address belongs to the object at ffff88810de2cb00
 which belongs to the cache task_struct of size 3712
The buggy address is located 1992 bytes inside of
 freed 3712-byte region [ffff88810de2cb00, ffff88810de2d980)

which is caused by the task_struct pointed to by sq-&gt;thread being
released while it is being used in the function
__io_uring_show_fdinfo(). Holding ctx-&gt;uring_lock does not prevent ehre
relase or exit of sq-&gt;thread.

Fix this by assigning and looking up -&gt;thread under RCU, and grabbing a
reference to the task_struct. This e
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-38106</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net_sched: ets: fix a race in ets_qdisc_change()

Gerrard Tai reported a race condition in ETS, whenever SFQ perturb timer
fires at the wrong time.

The race is as follows:

CPU 0                                 CPU 1
[1]: lock root
[2]: qdisc_tree_flush_backlog()
[3]: unlock root
 |
 |                                    [5]: lock root
 |                                    [6]: rehash
 |                                    [7]: qdisc_tree_reduce_backlog()
 |
[4]: qdisc_put()

This can be abused to underflow a parent's qlen.

Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog()
should fix the race, because all packets will be purged from the qdisc
before releasing the lock.</Note>
    </Notes>
    <CVE>CVE-2025-38107</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net_sched: red: fix a race in __red_change()

Gerrard Tai reported a race condition in RED, whenever SFQ perturb timer
fires at the wrong time.

The race is as follows:

CPU 0                                 CPU 1
[1]: lock root
[2]: qdisc_tree_flush_backlog()
[3]: unlock root
 |
 |                                    [5]: lock root
 |                                    [6]: rehash
 |                                    [7]: qdisc_tree_reduce_backlog()
 |
[4]: qdisc_put()

This can be abused to underflow a parent's qlen.

Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog()
should fix the race, because all packets will be purged from the qdisc
before releasing the lock.</Note>
    </Notes>
    <CVE>CVE-2025-38108</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/mlx5: Fix ECVF vports unload on shutdown flow

Fix shutdown flow UAF when a virtual function is created on the embedded
chip (ECVF) of a BlueField device. In such case the vport acl ingress
table is not properly destroyed.

ECVF functionality is independent of ecpf_vport_exists capability and
thus functions mlx5_eswitch_(enable|disable)_pf_vf_vports() should not
test it when enabling/disabling ECVF vports.

kernel log:
[] refcount_t: underflow; use-after-free.
[] WARNING: CPU: 3 PID: 1 at lib/refcount.c:28
   refcount_warn_saturate+0x124/0x220
----------------
[] Call trace:
[] refcount_warn_saturate+0x124/0x220
[] tree_put_node+0x164/0x1e0 [mlx5_core]
[] mlx5_destroy_flow_table+0x98/0x2c0 [mlx5_core]
[] esw_acl_ingress_table_destroy+0x28/0x40 [mlx5_core]
[] esw_acl_ingress_lgcy_cleanup+0x80/0xf4 [mlx5_core]
[] esw_legacy_vport_acl_cleanup+0x44/0x60 [mlx5_core]
[] esw_vport_cleanup+0x64/0x90 [mlx5_core]
[] mlx5_esw_vport_disable+0xc0/0x1d0 [mlx5_core]
[] mlx5_eswitch_unload_ec_vf_vports+0xcc/0x150 [mlx5_core]
[] mlx5_eswitch_disable_sriov+0x198/0x2a0 [mlx5_core]
[] mlx5_device_disable_sriov+0xb8/0x1e0 [mlx5_core]
[] mlx5_sriov_detach+0x40/0x50 [mlx5_core]
[] mlx5_unload+0x40/0xc4 [mlx5_core]
[] mlx5_unload_one_devl_locked+0x6c/0xe4 [mlx5_core]
[] mlx5_unload_one+0x3c/0x60 [mlx5_core]
[] shutdown+0x7c/0xa4 [mlx5_core]
[] pci_device_shutdown+0x3c/0xa0
[] device_shutdown+0x170/0x340
[] __do_sys_reboot+0x1f4/0x2a0
[] __arm64_sys_reboot+0x2c/0x40
[] invoke_syscall+0x78/0x100
[] el0_svc_common.constprop.0+0x54/0x184
[] do_el0_svc+0x30/0xac
[] el0_svc+0x48/0x160
[] el0t_64_sync_handler+0xa4/0x12c
[] el0t_64_sync+0x1a4/0x1a8
[] --[ end trace 9c4601d68c70030e ]---</Note>
    </Notes>
    <CVE>CVE-2025-38109</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/mdiobus: Fix potential out-of-bounds clause 45 read/write access

When using publicly available tools like 'mdio-tools' to read/write data
from/to network interface and its PHY via C45 (clause 45) mdiobus,
there is no verification of parameters passed to the ioctl and
it accepts any mdio address.
Currently there is support for 32 addresses in kernel via PHY_MAX_ADDR define,
but it is possible to pass higher value than that via ioctl.
While read/write operation should generally fail in this case,
mdiobus provides stats array, where wrong address may allow out-of-bounds
read/write.

Fix that by adding address verification before C45 read/write operation.
While this excludes this access from any statistics, it improves security of
read/write operation.</Note>
    </Notes>
    <CVE>CVE-2025-38110</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/mdiobus: Fix potential out-of-bounds read/write access

When using publicly available tools like 'mdio-tools' to read/write data
from/to network interface and its PHY via mdiobus, there is no verification of
parameters passed to the ioctl and it accepts any mdio address.
Currently there is support for 32 addresses in kernel via PHY_MAX_ADDR define,
but it is possible to pass higher value than that via ioctl.
While read/write operation should generally fail in this case,
mdiobus provides stats array, where wrong address may allow out-of-bounds
read/write.

Fix that by adding address verification before read/write operation.
While this excludes this access from any statistics, it improves security of
read/write operation.</Note>
    </Notes>
    <CVE>CVE-2025-38111</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: Fix TOCTOU issue in sk_is_readable()

sk-&gt;sk_prot-&gt;sock_is_readable is a valid function pointer when sk resides
in a sockmap. After the last sk_psock_put() (which usually happens when
socket is removed from sockmap), sk-&gt;sk_prot gets restored and
sk-&gt;sk_prot-&gt;sock_is_readable becomes NULL.

This makes sk_is_readable() racy, if the value of sk-&gt;sk_prot is reloaded
after the initial check. Which in turn may lead to a null pointer
dereference.

Ensure the function pointer does not turn NULL after the check.</Note>
    </Notes>
    <CVE>CVE-2025-38112</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ACPI: CPPC: Fix NULL pointer dereference when nosmp is used

With nosmp in cmdline, other CPUs are not brought up, leaving
their cpc_desc_ptr NULL. CPU0's iteration via for_each_possible_cpu()
dereferences these NULL pointers, causing panic.

Panic backtrace:

[    0.401123] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000b8
...
[    0.403255] [&lt;ffffffff809a5818&gt;] cppc_allow_fast_switch+0x6a/0xd4
...
Kernel panic - not syncing: Attempted to kill init!

[ rjw: New subject ]</Note>
    </Notes>
    <CVE>CVE-2025-38113</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

e1000: Move cancel_work_sync to avoid deadlock

Previously, e1000_down called cancel_work_sync for the e1000 reset task
(via e1000_down_and_stop), which takes RTNL.

As reported by users and syzbot, a deadlock is possible in the following
scenario:

CPU 0:
  - RTNL is held
  - e1000_close
  - e1000_down
  - cancel_work_sync (cancel / wait for e1000_reset_task())

CPU 1:
  - process_one_work
  - e1000_reset_task
  - take RTNL

To remedy this, avoid calling cancel_work_sync from e1000_down
(e1000_reset_task does nothing if the device is down anyway). Instead,
call cancel_work_sync for e1000_reset_task when the device is being
removed.</Note>
    </Notes>
    <CVE>CVE-2025-38114</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net_sched: sch_sfq: fix a potential crash on gso_skb handling

SFQ has an assumption of always being able to queue at least one packet.

However, after the blamed commit, sch-&gt;q.len can be inflated by packets
in sch-&gt;gso_skb, and an enqueue() on an empty SFQ qdisc can be followed
by an immediate drop.

Fix sfq_drop() to properly clear q-&gt;tail in this situation.


ip netns add lb
ip link add dev to-lb type veth peer name in-lb netns lb
ethtool -K to-lb tso off                 # force qdisc to requeue gso_skb
ip netns exec lb ethtool -K in-lb gro on # enable NAPI
ip link set dev to-lb up
ip -netns lb link set dev in-lb up
ip addr add dev to-lb 192.168.20.1/24
ip -netns lb addr add dev in-lb 192.168.20.2/24
tc qdisc replace dev to-lb root sfq limit 100

ip netns exec lb netserver

netperf -H 192.168.20.2 -l 100 &amp;
netperf -H 192.168.20.2 -l 100 &amp;
netperf -H 192.168.20.2 -l 100 &amp;
netperf -H 192.168.20.2 -l 100 &amp;</Note>
    </Notes>
    <CVE>CVE-2025-38115</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: MGMT: Protect mgmt_pending list with its own lock

This uses a mutex to protect from concurrent access of mgmt_pending
list which can cause crashes like:

==================================================================
BUG: KASAN: slab-use-after-free in hci_sock_get_channel+0x60/0x68 net/bluetooth/hci_sock.c:91
Read of size 2 at addr ffff0000c48885b2 by task syz.4.334/7318

CPU: 0 UID: 0 PID: 7318 Comm: syz.4.334 Not tainted 6.15.0-rc7-syzkaller-g187899f4124a #0 PREEMPT
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025
Call trace:
 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C)
 __dump_stack+0x30/0x40 lib/dump_stack.c:94
 dump_stack_lvl+0xd8/0x12c lib/dump_stack.c:120
 print_address_description+0xa8/0x254 mm/kasan/report.c:408
 print_report+0x68/0x84 mm/kasan/report.c:521
 kasan_report+0xb0/0x110 mm/kasan/report.c:634
 __asan_report_load2_noabort+0x20/0x2c mm/kasan/report_generic.c:379
 hci_sock_get_channel+0x60/0x68 net/bluetooth/hci_sock.c:91
 mgmt_pending_find+0x7c/0x140 net/bluetooth/mgmt_util.c:223
 pending_find net/bluetooth/mgmt.c:947 [inline]
 remove_adv_monitor+0x44/0x1a4 net/bluetooth/mgmt.c:5445
 hci_mgmt_cmd+0x780/0xc00 net/bluetooth/hci_sock.c:1712
 hci_sock_sendmsg+0x544/0xbb0 net/bluetooth/hci_sock.c:1832
 sock_sendmsg_nosec net/socket.c:712 [inline]
 __sock_sendmsg net/socket.c:727 [inline]
 sock_write_iter+0x25c/0x378 net/socket.c:1131
 new_sync_write fs/read_write.c:591 [inline]
 vfs_write+0x62c/0x97c fs/read_write.c:684
 ksys_write+0x120/0x210 fs/read_write.c:736
 __do_sys_write fs/read_write.c:747 [inline]
 __se_sys_write fs/read_write.c:744 [inline]
 __arm64_sys_write+0x7c/0x90 fs/read_write.c:744
 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
 invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49
 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132
 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151
 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767
 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786
 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600

Allocated by task 7037:
 kasan_save_stack mm/kasan/common.c:47 [inline]
 kasan_save_track+0x40/0x78 mm/kasan/common.c:68
 kasan_save_alloc_info+0x44/0x54 mm/kasan/generic.c:562
 poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
 __kasan_kmalloc+0x9c/0xb4 mm/kasan/common.c:394
 kasan_kmalloc include/linux/kasan.h:260 [inline]
 __do_kmalloc_node mm/slub.c:4327 [inline]
 __kmalloc_noprof+0x2fc/0x4c8 mm/slub.c:4339
 kmalloc_noprof include/linux/slab.h:909 [inline]
 sk_prot_alloc+0xc4/0x1f0 net/core/sock.c:2198
 sk_alloc+0x44/0x3ac net/core/sock.c:2254
 bt_sock_alloc+0x4c/0x300 net/bluetooth/af_bluetooth.c:148
 hci_sock_create+0xa8/0x194 net/bluetooth/hci_sock.c:2202
 bt_sock_create+0x14c/0x24c net/bluetooth/af_bluetooth.c:132
 __sock_create+0x43c/0x91c net/socket.c:1541
 sock_create net/socket.c:1599 [inline]
 __sys_socket_create net/socket.c:1636 [inline]
 __sys_socket+0xd4/0x1c0 net/socket.c:1683
 __do_sys_socket net/socket.c:1697 [inline]
 __se_sys_socket net/socket.c:1695 [inline]
 __arm64_sys_socket+0x7c/0x94 net/socket.c:1695
 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
 invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49
 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132
 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151
 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767
 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786
 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600

Freed by task 6607:
 kasan_save_stack mm/kasan/common.c:47 [inline]
 kasan_save_track+0x40/0x78 mm/kasan/common.c:68
 kasan_save_free_info+0x58/0x70 mm/kasan/generic.c:576
 poison_slab_object mm/kasan/common.c:247 [inline]
 __kasan_slab_free+0x68/0x88 mm/kasan/common.c:264
 kasan_slab_free include/linux/kasan.h:233 [inline
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-38117</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: MGMT: Fix UAF on mgmt_remove_adv_monitor_complete

This reworks MGMT_OP_REMOVE_ADV_MONITOR to not use mgmt_pending_add to
avoid crashes like bellow:

==================================================================
BUG: KASAN: slab-use-after-free in mgmt_remove_adv_monitor_complete+0xe5/0x540 net/bluetooth/mgmt.c:5406
Read of size 8 at addr ffff88801c53f318 by task kworker/u5:5/5341

CPU: 0 UID: 0 PID: 5341 Comm: kworker/u5:5 Not tainted 6.15.0-syzkaller-10402-g4cb6c8af8591 #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
Workqueue: hci0 hci_cmd_sync_work
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:408 [inline]
 print_report+0xd2/0x2b0 mm/kasan/report.c:521
 kasan_report+0x118/0x150 mm/kasan/report.c:634
 mgmt_remove_adv_monitor_complete+0xe5/0x540 net/bluetooth/mgmt.c:5406
 hci_cmd_sync_work+0x261/0x3a0 net/bluetooth/hci_sync.c:334
 process_one_work kernel/workqueue.c:3238 [inline]
 process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3321
 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402
 kthread+0x711/0x8a0 kernel/kthread.c:464
 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
 &lt;/TASK&gt;

Allocated by task 5987:
 kasan_save_stack mm/kasan/common.c:47 [inline]
 kasan_save_track+0x3e/0x80 mm/kasan/common.c:68
 poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
 __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394
 kasan_kmalloc include/linux/kasan.h:260 [inline]
 __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4358
 kmalloc_noprof include/linux/slab.h:905 [inline]
 kzalloc_noprof include/linux/slab.h:1039 [inline]
 mgmt_pending_new+0x65/0x240 net/bluetooth/mgmt_util.c:252
 mgmt_pending_add+0x34/0x120 net/bluetooth/mgmt_util.c:279
 remove_adv_monitor+0x103/0x1b0 net/bluetooth/mgmt.c:5454
 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719
 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839
 sock_sendmsg_nosec net/socket.c:712 [inline]
 __sock_sendmsg+0x219/0x270 net/socket.c:727
 sock_write_iter+0x258/0x330 net/socket.c:1131
 new_sync_write fs/read_write.c:593 [inline]
 vfs_write+0x548/0xa90 fs/read_write.c:686
 ksys_write+0x145/0x250 fs/read_write.c:738
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Freed by task 5989:
 kasan_save_stack mm/kasan/common.c:47 [inline]
 kasan_save_track+0x3e/0x80 mm/kasan/common.c:68
 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576
 poison_slab_object mm/kasan/common.c:247 [inline]
 __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264
 kasan_slab_free include/linux/kasan.h:233 [inline]
 slab_free_hook mm/slub.c:2380 [inline]
 slab_free mm/slub.c:4642 [inline]
 kfree+0x18e/0x440 mm/slub.c:4841
 mgmt_pending_foreach+0xc9/0x120 net/bluetooth/mgmt_util.c:242
 mgmt_index_removed+0x10d/0x2f0 net/bluetooth/mgmt.c:9366
 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314
 __sys_bind_socket net/socket.c:1810 [inline]
 __sys_bind+0x2c3/0x3e0 net/socket.c:1841
 __do_sys_bind net/socket.c:1846 [inline]
 __se_sys_bind net/socket.c:1844 [inline]
 __x64_sys_bind+0x7a/0x90 net/socket.c:1844
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f</Note>
    </Notes>
    <CVE>CVE-2025-38118</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

gve: add missing NULL check for gve_alloc_pending_packet() in TX DQO

gve_alloc_pending_packet() can return NULL, but gve_tx_add_skb_dqo()
did not check for this case before dereferencing the returned pointer.

Add a missing NULL check to prevent a potential NULL pointer
dereference when allocation fails.

This improves robustness in low-memory scenarios.</Note>
    </Notes>
    <CVE>CVE-2025-38122</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: wwan: t7xx: Fix napi rx poll issue

When driver handles the napi rx polling requests, the netdev might
have been released by the dellink logic triggered by the disconnect
operation on user plane. However, in the logic of processing skb in
polling, an invalid netdev is still being used, which causes a panic.

BUG: kernel NULL pointer dereference, address: 00000000000000f1
Oops: 0000 [#1] PREEMPT SMP NOPTI
RIP: 0010:dev_gro_receive+0x3a/0x620
[...]
Call Trace:
 &lt;IRQ&gt;
 ? __die_body+0x68/0xb0
 ? page_fault_oops+0x379/0x3e0
 ? exc_page_fault+0x4f/0xa0
 ? asm_exc_page_fault+0x22/0x30
 ? __pfx_t7xx_ccmni_recv_skb+0x10/0x10 [mtk_t7xx (HASH:1400 7)]
 ? dev_gro_receive+0x3a/0x620
 napi_gro_receive+0xad/0x170
 t7xx_ccmni_recv_skb+0x48/0x70 [mtk_t7xx (HASH:1400 7)]
 t7xx_dpmaif_napi_rx_poll+0x590/0x800 [mtk_t7xx (HASH:1400 7)]
 net_rx_action+0x103/0x470
 irq_exit_rcu+0x13a/0x310
 sysvec_apic_timer_interrupt+0x56/0x90
 &lt;/IRQ&gt;</Note>
    </Notes>
    <CVE>CVE-2025-38123</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: fix udp gso skb_segment after pull from frag_list

Commit a1e40ac5b5e9 ("net: gso: fix udp gso fraglist segmentation after
pull from frag_list") detected invalid geometry in frag_list skbs and
redirects them from skb_segment_list to more robust skb_segment. But some
packets with modified geometry can also hit bugs in that code. We don't
know how many such cases exist. Addressing each one by one also requires
touching the complex skb_segment code, which risks introducing bugs for
other types of skbs. Instead, linearize all these packets that fail the
basic invariants on gso fraglist skbs. That is more robust.

If only part of the fraglist payload is pulled into head_skb, it will
always cause exception when splitting skbs by skb_segment. For detailed
call stack information, see below.

Valid SKB_GSO_FRAGLIST skbs
- consist of two or more segments
- the head_skb holds the protocol headers plus first gso_size
- one or more frag_list skbs hold exactly one segment
- all but the last must be gso_size

Optional datapath hooks such as NAT and BPF (bpf_skb_pull_data) can
modify fraglist skbs, breaking these invariants.

In extreme cases they pull one part of data into skb linear. For UDP,
this  causes three payloads with lengths of (11,11,10) bytes were
pulled tail to become (12,10,10) bytes.

The skbs no longer meets the above SKB_GSO_FRAGLIST conditions because
payload was pulled into head_skb, it needs to be linearized before pass
to regular skb_segment.

    skb_segment+0xcd0/0xd14
    __udp_gso_segment+0x334/0x5f4
    udp4_ufo_fragment+0x118/0x15c
    inet_gso_segment+0x164/0x338
    skb_mac_gso_segment+0xc4/0x13c
    __skb_gso_segment+0xc4/0x124
    validate_xmit_skb+0x9c/0x2c0
    validate_xmit_skb_list+0x4c/0x80
    sch_direct_xmit+0x70/0x404
    __dev_queue_xmit+0x64c/0xe5c
    neigh_resolve_output+0x178/0x1c4
    ip_finish_output2+0x37c/0x47c
    __ip_finish_output+0x194/0x240
    ip_finish_output+0x20/0xf4
    ip_output+0x100/0x1a0
    NF_HOOK+0xc4/0x16c
    ip_forward+0x314/0x32c
    ip_rcv+0x90/0x118
    __netif_receive_skb+0x74/0x124
    process_backlog+0xe8/0x1a4
    __napi_poll+0x5c/0x1f8
    net_rx_action+0x154/0x314
    handle_softirqs+0x154/0x4b8

    [118.376811] [C201134] rxq0_pus: [name:bug&amp;]kernel BUG at net/core/skbuff.c:4278!
    [118.376829] [C201134] rxq0_pus: [name:traps&amp;]Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
    [118.470774] [C201134] rxq0_pus: [name:mrdump&amp;]Kernel Offset: 0x178cc00000 from 0xffffffc008000000
    [118.470810] [C201134] rxq0_pus: [name:mrdump&amp;]PHYS_OFFSET: 0x40000000
    [118.470827] [C201134] rxq0_pus: [name:mrdump&amp;]pstate: 60400005 (nZCv daif +PAN -UAO)
    [118.470848] [C201134] rxq0_pus: [name:mrdump&amp;]pc : [0xffffffd79598aefc] skb_segment+0xcd0/0xd14
    [118.470900] [C201134] rxq0_pus: [name:mrdump&amp;]lr : [0xffffffd79598a5e8] skb_segment+0x3bc/0xd14
    [118.470928] [C201134] rxq0_pus: [name:mrdump&amp;]sp : ffffffc008013770</Note>
    </Notes>
    <CVE>CVE-2025-38124</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: stmmac: make sure that ptp_rate is not 0 before configuring timestamping

The stmmac platform drivers that do not open-code the clk_ptp_rate value
after having retrieved the default one from the device-tree can end up
with 0 in clk_ptp_rate (as clk_get_rate can return 0). It will
eventually propagate up to PTP initialization when bringing up the
interface, leading to a divide by 0:

 Division by zero in kernel.
 CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.30-00001-g48313bd5768a #22
 Hardware name: STM32 (Device Tree Support)
 Call trace:
  unwind_backtrace from show_stack+0x18/0x1c
  show_stack from dump_stack_lvl+0x6c/0x8c
  dump_stack_lvl from Ldiv0_64+0x8/0x18
  Ldiv0_64 from stmmac_init_tstamp_counter+0x190/0x1a4
  stmmac_init_tstamp_counter from stmmac_hw_setup+0xc1c/0x111c
  stmmac_hw_setup from __stmmac_open+0x18c/0x434
  __stmmac_open from stmmac_open+0x3c/0xbc
  stmmac_open from __dev_open+0xf4/0x1ac
  __dev_open from __dev_change_flags+0x1cc/0x224
  __dev_change_flags from dev_change_flags+0x24/0x60
  dev_change_flags from ip_auto_config+0x2e8/0x11a0
  ip_auto_config from do_one_initcall+0x84/0x33c
  do_one_initcall from kernel_init_freeable+0x1b8/0x214
  kernel_init_freeable from kernel_init+0x24/0x140
  kernel_init from ret_from_fork+0x14/0x28
 Exception stack(0xe0815fb0 to 0xe0815ff8)

Prevent this division by 0 by adding an explicit check and error log
about the actual issue. While at it, remove the same check from
stmmac_ptp_register, which then becomes duplicate</Note>
    </Notes>
    <CVE>CVE-2025-38126</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ice: fix Tx scheduler error handling in XDP callback

When the XDP program is loaded, the XDP callback adds new Tx queues.
This means that the callback must update the Tx scheduler with the new
queue number. In the event of a Tx scheduler failure, the XDP callback
should also fail and roll back any changes previously made for XDP
preparation.

The previous implementation had a bug that not all changes made by the
XDP callback were rolled back. This caused the crash with the following
call trace:

[  +9.549584] ice 0000:ca:00.0: Failed VSI LAN queue config for XDP, error: -5
[  +0.382335] Oops: general protection fault, probably for non-canonical address 0x50a2250a90495525: 0000 [#1] SMP NOPTI
[  +0.010710] CPU: 103 UID: 0 PID: 0 Comm: swapper/103 Not tainted 6.14.0-net-next-mar-31+ #14 PREEMPT(voluntary)
[  +0.010175] Hardware name: Intel Corporation M50CYP2SBSTD/M50CYP2SBSTD, BIOS SE5C620.86B.01.01.0005.2202160810 02/16/2022
[  +0.010946] RIP: 0010:__ice_update_sample+0x39/0xe0 [ice]

[...]

[  +0.002715] Call Trace:
[  +0.002452]  &lt;IRQ&gt;
[  +0.002021]  ? __die_body.cold+0x19/0x29
[  +0.003922]  ? die_addr+0x3c/0x60
[  +0.003319]  ? exc_general_protection+0x17c/0x400
[  +0.004707]  ? asm_exc_general_protection+0x26/0x30
[  +0.004879]  ? __ice_update_sample+0x39/0xe0 [ice]
[  +0.004835]  ice_napi_poll+0x665/0x680 [ice]
[  +0.004320]  __napi_poll+0x28/0x190
[  +0.003500]  net_rx_action+0x198/0x360
[  +0.003752]  ? update_rq_clock+0x39/0x220
[  +0.004013]  handle_softirqs+0xf1/0x340
[  +0.003840]  ? sched_clock_cpu+0xf/0x1f0
[  +0.003925]  __irq_exit_rcu+0xc2/0xe0
[  +0.003665]  common_interrupt+0x85/0xa0
[  +0.003839]  &lt;/IRQ&gt;
[  +0.002098]  &lt;TASK&gt;
[  +0.002106]  asm_common_interrupt+0x26/0x40
[  +0.004184] RIP: 0010:cpuidle_enter_state+0xd3/0x690

Fix this by performing the missing unmapping of XDP queues from
q_vectors and setting the XDP rings pointer back to NULL after all those
queues are released.
Also, add an immediate exit from the XDP callback in case of ring
preparation failure.</Note>
    </Notes>
    <CVE>CVE-2025-38127</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

page_pool: Fix use-after-free in page_pool_recycle_in_ring

syzbot reported a uaf in page_pool_recycle_in_ring:

BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862
Read of size 8 at addr ffff8880286045a0 by task syz.0.284/6943

CPU: 0 UID: 0 PID: 6943 Comm: syz.0.284 Not tainted 6.13.0-rc3-syzkaller-gdfa94ce54f41 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:378 [inline]
 print_report+0x169/0x550 mm/kasan/report.c:489
 kasan_report+0x143/0x180 mm/kasan/report.c:602
 lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862
 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:165 [inline]
 _raw_spin_unlock_bh+0x1b/0x40 kernel/locking/spinlock.c:210
 spin_unlock_bh include/linux/spinlock.h:396 [inline]
 ptr_ring_produce_bh include/linux/ptr_ring.h:164 [inline]
 page_pool_recycle_in_ring net/core/page_pool.c:707 [inline]
 page_pool_put_unrefed_netmem+0x748/0xb00 net/core/page_pool.c:826
 page_pool_put_netmem include/net/page_pool/helpers.h:323 [inline]
 page_pool_put_full_netmem include/net/page_pool/helpers.h:353 [inline]
 napi_pp_put_page+0x149/0x2b0 net/core/skbuff.c:1036
 skb_pp_recycle net/core/skbuff.c:1047 [inline]
 skb_free_head net/core/skbuff.c:1094 [inline]
 skb_release_data+0x6c4/0x8a0 net/core/skbuff.c:1125
 skb_release_all net/core/skbuff.c:1190 [inline]
 __kfree_skb net/core/skbuff.c:1204 [inline]
 sk_skb_reason_drop+0x1c9/0x380 net/core/skbuff.c:1242
 kfree_skb_reason include/linux/skbuff.h:1263 [inline]
 __skb_queue_purge_reason include/linux/skbuff.h:3343 [inline]

root cause is:

page_pool_recycle_in_ring
  ptr_ring_produce
    spin_lock(&amp;r-&gt;producer_lock);
    WRITE_ONCE(r-&gt;queue[r-&gt;producer++], ptr)
      //recycle last page to pool
				page_pool_release
				  page_pool_scrub
				    page_pool_empty_ring
				      ptr_ring_consume
				      page_pool_return_page  //release all page
				  __page_pool_destroy
				     free_percpu(pool-&gt;recycle_stats);
				     free(pool) //free

     spin_unlock(&amp;r-&gt;producer_lock); //pool-&gt;ring uaf read
  recycle_stat_inc(pool, ring);

page_pool can be free while page pool recycle the last page in ring.
Add producer-lock barrier to page_pool_release to prevent the page
pool from being free before all pages have been recycled.

recycle_stat_inc() is empty when CONFIG_PAGE_POOL_STATS is not
enabled, which will trigger Wempty-body build warning. Add definition
for pool stat macro to fix warning.</Note>
    </Notes>
    <CVE>CVE-2025-38129</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

coresight: prevent deactivate active config while enabling the config

While enable active config via cscfg_csdev_enable_active_config(),
active config could be deactivated via configfs' sysfs interface.
This could make UAF issue in below scenario:

CPU0                                          CPU1
(sysfs enable)                                load module
                                              cscfg_load_config_sets()
                                              activate config. // sysfs
                                              (sys_active_cnt == 1)
...
cscfg_csdev_enable_active_config()
lock(csdev-&gt;cscfg_csdev_lock)
// here load config activate by CPU1
unlock(csdev-&gt;cscfg_csdev_lock)

                                              deactivate config // sysfs
                                              (sys_activec_cnt == 0)
                                              cscfg_unload_config_sets()
                                              unload module

// access to config_desc which freed
// while unloading module.
cscfg_csdev_enable_config

To address this, use cscfg_config_desc's active_cnt as a reference count
 which will be holded when
    - activate the config.
    - enable the activated config.
and put the module reference when config_active_cnt == 0.</Note>
    </Notes>
    <CVE>CVE-2025-38131</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

coresight: holding cscfg_csdev_lock while removing cscfg from csdev

There'll be possible race scenario for coresight config:

CPU0                                          CPU1
(perf enable)                                 load module
                                              cscfg_load_config_sets()
                                              activate config. // sysfs
                                              (sys_active_cnt == 1)
...
cscfg_csdev_enable_active_config()
  lock(csdev-&gt;cscfg_csdev_lock)
                                              deactivate config // sysfs
                                              (sys_activec_cnt == 0)
                                              cscfg_unload_config_sets()
  &lt;iterating config_csdev_list&gt;               cscfg_remove_owned_csdev_configs()
  // here load config activate by CPU1
  unlock(csdev-&gt;cscfg_csdev_lock)

iterating config_csdev_list could be raced with config_csdev_list's
entry delete.

To resolve this race , hold csdev-&gt;cscfg_csdev_lock() while
cscfg_remove_owned_csdev_configs()</Note>
    </Notes>
    <CVE>CVE-2025-38132</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

serial: Fix potential null-ptr-deref in mlb_usio_probe()

devm_ioremap() can return NULL on error. Currently, mlb_usio_probe()
does not check for this case, which could result in a NULL pointer
dereference.

Add NULL check after devm_ioremap() to prevent this issue.</Note>
    </Notes>
    <CVE>CVE-2025-38135</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: renesas_usbhs: Reorder clock handling and power management in probe

Reorder the initialization sequence in `usbhs_probe()` to enable runtime
PM before accessing registers, preventing potential crashes due to
uninitialized clocks.

Currently, in the probe path, registers are accessed before enabling the
clocks, leading to a synchronous external abort on the RZ/V2H SoC.
The problematic call flow is as follows:

    usbhs_probe()
        usbhs_sys_clock_ctrl()
            usbhs_bset()
                usbhs_write()
                    iowrite16()  &lt;-- Register access before enabling clocks

Since `iowrite16()` is performed without ensuring the required clocks are
enabled, this can lead to access errors. To fix this, enable PM runtime
early in the probe function and ensure clocks are acquired before register
access, preventing crashes like the following on RZ/V2H:

[13.272640] Internal error: synchronous external abort: 0000000096000010 [#1] PREEMPT SMP
[13.280814] Modules linked in: cec renesas_usbhs(+) drm_kms_helper fuse drm backlight ipv6
[13.289088] CPU: 1 UID: 0 PID: 195 Comm: (udev-worker) Not tainted 6.14.0-rc7+ #98
[13.296640] Hardware name: Renesas RZ/V2H EVK Board based on r9a09g057h44 (DT)
[13.303834] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[13.310770] pc : usbhs_bset+0x14/0x4c [renesas_usbhs]
[13.315831] lr : usbhs_probe+0x2e4/0x5ac [renesas_usbhs]
[13.321138] sp : ffff8000827e3850
[13.324438] x29: ffff8000827e3860 x28: 0000000000000000 x27: ffff8000827e3ca0
[13.331554] x26: ffff8000827e3ba0 x25: ffff800081729668 x24: 0000000000000025
[13.338670] x23: ffff0000c0f08000 x22: 0000000000000000 x21: ffff0000c0f08010
[13.345783] x20: 0000000000000000 x19: ffff0000c3b52080 x18: 00000000ffffffff
[13.352895] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000827e36ce
[13.360009] x14: 00000000000003d7 x13: 00000000000003d7 x12: 0000000000000000
[13.367122] x11: 0000000000000000 x10: 0000000000000aa0 x9 : ffff8000827e3750
[13.374235] x8 : ffff0000c1850b00 x7 : 0000000003826060 x6 : 000000000000001c
[13.381347] x5 : 000000030d5fcc00 x4 : ffff8000825c0000 x3 : 0000000000000000
[13.388459] x2 : 0000000000000400 x1 : 0000000000000000 x0 : ffff0000c3b52080
[13.395574] Call trace:
[13.398013]  usbhs_bset+0x14/0x4c [renesas_usbhs] (P)
[13.403076]  platform_probe+0x68/0xdc
[13.406738]  really_probe+0xbc/0x2c0
[13.410306]  __driver_probe_device+0x78/0x120
[13.414653]  driver_probe_device+0x3c/0x154
[13.418825]  __driver_attach+0x90/0x1a0
[13.422647]  bus_for_each_dev+0x7c/0xe0
[13.426470]  driver_attach+0x24/0x30
[13.430032]  bus_add_driver+0xe4/0x208
[13.433766]  driver_register+0x68/0x130
[13.437587]  __platform_driver_register+0x24/0x30
[13.442273]  renesas_usbhs_driver_init+0x20/0x1000 [renesas_usbhs]
[13.448450]  do_one_initcall+0x60/0x1d4
[13.452276]  do_init_module+0x54/0x1f8
[13.456014]  load_module+0x1754/0x1c98
[13.459750]  init_module_from_file+0x88/0xcc
[13.464004]  __arm64_sys_finit_module+0x1c4/0x328
[13.468689]  invoke_syscall+0x48/0x104
[13.472426]  el0_svc_common.constprop.0+0xc0/0xe0
[13.477113]  do_el0_svc+0x1c/0x28
[13.480415]  el0_svc+0x30/0xcc
[13.483460]  el0t_64_sync_handler+0x10c/0x138
[13.487800]  el0t_64_sync+0x198/0x19c
[13.491453] Code: 2a0103e1 12003c42 12003c63 8b010084 (79400084)
[13.497522] ---[ end trace 0000000000000000 ]---</Note>
    </Notes>
    <CVE>CVE-2025-38136</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

dmaengine: ti: Add NULL check in udma_probe()

devm_kasprintf() returns NULL when memory allocation fails. Currently,
udma_probe() does not check for this case, which results in a NULL
pointer dereference.

Add NULL check after devm_kasprintf() to prevent this issue.</Note>
    </Notes>
    <CVE>CVE-2025-38138</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hwmon: (asus-ec-sensors) check sensor index in read_string()

Prevent a potential invalid memory access when the requested sensor
is not found.

find_ec_sensor_index() may return a negative value (e.g. -ENOENT),
but its result was used without checking, which could lead to
undefined behavior when passed to get_sensor_info().

Add a proper check to return -EINVAL if sensor_index is negative.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

[groeck: Return error code returned from find_ec_sensor_index]</Note>
    </Notes>
    <CVE>CVE-2025-38142</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

backlight: pm8941: Add NULL check in wled_configure()

devm_kasprintf() returns NULL when memory allocation fails. Currently,
wled_configure() does not check for this case, which results in a NULL
pointer dereference.

Add NULL check after devm_kasprintf() to prevent this issue.</Note>
    </Notes>
    <CVE>CVE-2025-38143</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

soc: aspeed: Add NULL check in aspeed_lpc_enable_snoop()

devm_kasprintf() returns NULL when memory allocation fails. Currently,
aspeed_lpc_enable_snoop() does not check for this case, which results in a
NULL pointer dereference.

Add NULL check after devm_kasprintf() to prevent this issue.

[arj: Fix Fixes: tag to use subject from 3772e5da4454]</Note>
    </Notes>
    <CVE>CVE-2025-38145</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

calipso: Don't call calipso functions for AF_INET sk.

syzkaller reported a null-ptr-deref in txopt_get(). [0]

The offset 0x70 was of struct ipv6_txoptions in struct ipv6_pinfo,
so struct ipv6_pinfo was NULL there.

However, this never happens for IPv6 sockets as inet_sk(sk)-&gt;pinet6
is always set in inet6_create(), meaning the socket was not IPv6 one.

The root cause is missing validation in netlbl_conn_setattr().

netlbl_conn_setattr() switches branches based on struct
sockaddr.sa_family, which is passed from userspace.  However,
netlbl_conn_setattr() does not check if the address family matches
the socket.

The syzkaller must have called connect() for an IPv6 address on
an IPv4 socket.

We have a proper validation in tcp_v[46]_connect(), but
security_socket_connect() is called in the earlier stage.

Let's copy the validation to netlbl_conn_setattr().

[0]:
Oops: general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]
CPU: 2 UID: 0 PID: 12928 Comm: syz.9.1677 Not tainted 6.12.0 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
RIP: 0010:txopt_get include/net/ipv6.h:390 [inline]
RIP: 0010:
Code: 02 00 00 49 8b ac 24 f8 02 00 00 e8 84 69 2a fd e8 ff 00 16 fd 48 8d 7d 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 &lt;80&gt; 3c 02 00 0f 85 53 02 00 00 48 8b 6d 70 48 85 ed 0f 84 ab 01 00
RSP: 0018:ffff88811b8afc48 EFLAGS: 00010212
RAX: dffffc0000000000 RBX: 1ffff11023715f8a RCX: ffffffff841ab00c
RDX: 000000000000000e RSI: ffffc90007d9e000 RDI: 0000000000000070
RBP: 0000000000000000 R08: ffffed1023715f9d R09: ffffed1023715f9e
R10: ffffed1023715f9d R11: 0000000000000003 R12: ffff888123075f00
R13: ffff88810245bd80 R14: ffff888113646780 R15: ffff888100578a80
FS:  00007f9019bd7640(0000) GS:ffff8882d2d00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f901b927bac CR3: 0000000104788003 CR4: 0000000000770ef0
PKRU: 80000000
Call Trace:
 &lt;TASK&gt;
 calipso_sock_setattr+0x56/0x80 net/netlabel/netlabel_calipso.c:557
 netlbl_conn_setattr+0x10c/0x280 net/netlabel/netlabel_kapi.c:1177
 selinux_netlbl_socket_connect_helper+0xd3/0x1b0 security/selinux/netlabel.c:569
 selinux_netlbl_socket_connect_locked security/selinux/netlabel.c:597 [inline]
 selinux_netlbl_socket_connect+0xb6/0x100 security/selinux/netlabel.c:615
 selinux_socket_connect+0x5f/0x80 security/selinux/hooks.c:4931
 security_socket_connect+0x50/0xa0 security/security.c:4598
 __sys_connect_file+0xa4/0x190 net/socket.c:2067
 __sys_connect+0x12c/0x170 net/socket.c:2088
 __do_sys_connect net/socket.c:2098 [inline]
 __se_sys_connect net/socket.c:2095 [inline]
 __x64_sys_connect+0x73/0xb0 net/socket.c:2095
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f901b61a12d
Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f9019bd6fa8 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
RAX: ffffffffffffffda RBX: 00007f901b925fa0 RCX: 00007f901b61a12d
RDX: 000000000000001c RSI: 0000200000000140 RDI: 0000000000000003
RBP: 00007f901b701505 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 00007f901b5b62a0 R15: 00007f9019bb7000
 &lt;/TASK&gt;
Modules linked in:</Note>
    </Notes>
    <CVE>CVE-2025-38147</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: phy: mscc: Fix memory leak when using one step timestamping

Fix memory leak when running one-step timestamping. When running
one-step sync timestamping, the HW is configured to insert the TX time
into the frame, so there is no reason to keep the skb anymore. As in
this case the HW will never generate an interrupt to say that the frame
was timestamped, then the frame will never released.
Fix this by freeing the frame in case of one-step timestamping.</Note>
    </Notes>
    <CVE>CVE-2025-38148</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: phy: clear phydev-&gt;devlink when the link is deleted

There is a potential crash issue when disabling and re-enabling the
network port. When disabling the network port, phy_detach() calls
device_link_del() to remove the device link, but it does not clear
phydev-&gt;devlink, so phydev-&gt;devlink is not a NULL pointer. Then the
network port is re-enabled, but if phy_attach_direct() fails before
calling device_link_add(), the code jumps to the "error" label and
calls phy_detach(). Since phydev-&gt;devlink retains the old value from
the previous attach/detach cycle, device_link_del() uses the old value,
which accesses a NULL pointer and causes a crash. The simplified crash
log is as follows.

[   24.702421] Call trace:
[   24.704856]  device_link_put_kref+0x20/0x120
[   24.709124]  device_link_del+0x30/0x48
[   24.712864]  phy_detach+0x24/0x168
[   24.716261]  phy_attach_direct+0x168/0x3a4
[   24.720352]  phylink_fwnode_phy_connect+0xc8/0x14c
[   24.725140]  phylink_of_phy_connect+0x1c/0x34

Therefore, phydev-&gt;devlink needs to be cleared when the device link is
deleted.</Note>
    </Notes>
    <CVE>CVE-2025-38149</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/cma: Fix hang when cma_netevent_callback fails to queue_work

The cited commit fixed a crash when cma_netevent_callback was called for
a cma_id while work on that id from a previous call had not yet started.
The work item was re-initialized in the second call, which corrupted the
work item currently in the work queue.

However, it left a problem when queue_work fails (because the item is
still pending in the work queue from a previous call). In this case,
cma_id_put (which is called in the work handler) is therefore not
called. This results in a userspace process hang (zombie process).

Fix this by calling cma_id_put() if queue_work fails.</Note>
    </Notes>
    <CVE>CVE-2025-38151</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: usb: aqc111: fix error handling of usbnet read calls

Syzkaller, courtesy of syzbot, identified an error (see report [1]) in
aqc111 driver, caused by incomplete sanitation of usb read calls'
results. This problem is quite similar to the one fixed in commit
920a9fa27e78 ("net: asix: add proper error handling of usb read errors").

For instance, usbnet_read_cmd() may read fewer than 'size' bytes,
even if the caller expected the full amount, and aqc111_read_cmd()
will not check its result properly. As [1] shows, this may lead
to MAC address in aqc111_bind() being only partly initialized,
triggering KMSAN warnings.

Fix the issue by verifying that the number of bytes read is
as expected and not less.

[1] Partial syzbot report:
BUG: KMSAN: uninit-value in is_valid_ether_addr include/linux/etherdevice.h:208 [inline]
BUG: KMSAN: uninit-value in usbnet_probe+0x2e57/0x4390 drivers/net/usb/usbnet.c:1830
 is_valid_ether_addr include/linux/etherdevice.h:208 [inline]
 usbnet_probe+0x2e57/0x4390 drivers/net/usb/usbnet.c:1830
 usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396
 call_driver_probe drivers/base/dd.c:-1 [inline]
 really_probe+0x4d1/0xd90 drivers/base/dd.c:658
 __driver_probe_device+0x268/0x380 drivers/base/dd.c:800
...

Uninit was stored to memory at:
 dev_addr_mod+0xb0/0x550 net/core/dev_addr_lists.c:582
 __dev_addr_set include/linux/netdevice.h:4874 [inline]
 eth_hw_addr_set include/linux/etherdevice.h:325 [inline]
 aqc111_bind+0x35f/0x1150 drivers/net/usb/aqc111.c:717
 usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772
 usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396
...

Uninit was stored to memory at:
 ether_addr_copy include/linux/etherdevice.h:305 [inline]
 aqc111_read_perm_mac drivers/net/usb/aqc111.c:663 [inline]
 aqc111_bind+0x794/0x1150 drivers/net/usb/aqc111.c:713
 usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772
 usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396
 call_driver_probe drivers/base/dd.c:-1 [inline]
...

Local variable buf.i created at:
 aqc111_read_perm_mac drivers/net/usb/aqc111.c:656 [inline]
 aqc111_bind+0x221/0x1150 drivers/net/usb/aqc111.c:713
 usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772</Note>
    </Notes>
    <CVE>CVE-2025-38153</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf, sockmap: Avoid using sk_socket after free when sending

The sk-&gt;sk_socket is not locked or referenced in backlog thread, and
during the call to skb_send_sock(), there is a race condition with
the release of sk_socket. All types of sockets(tcp/udp/unix/vsock)
will be affected.

Race conditions:
'''
CPU0                               CPU1

backlog::skb_send_sock
  sendmsg_unlocked
    sock_sendmsg
      sock_sendmsg_nosec
                                   close(fd):
                                     ...
                                     ops-&gt;release() -&gt; sock_map_close()
                                     sk_socket-&gt;ops = NULL
                                     free(socket)
      sock-&gt;ops-&gt;sendmsg
            ^
            panic here
'''

The ref of psock become 0 after sock_map_close() executed.
'''
void sock_map_close()
{
    ...
    if (likely(psock)) {
    ...
    // !! here we remove psock and the ref of psock become 0
    sock_map_remove_links(sk, psock)
    psock = sk_psock_get(sk);
    if (unlikely(!psock))
        goto no_psock; &lt;=== Control jumps here via goto
        ...
        cancel_delayed_work_sync(&amp;psock-&gt;work); &lt;=== not executed
        sk_psock_put(sk, psock);
        ...
}
'''

Based on the fact that we already wait for the workqueue to finish in
sock_map_close() if psock is held, we simply increase the psock
reference count to avoid race conditions.

With this patch, if the backlog thread is running, sock_map_close() will
wait for the backlog thread to complete and cancel all pending work.

If no backlog running, any pending work that hasn't started by then will
fail when invoked by sk_psock_get(), as the psock reference count have
been zeroed, and sk_psock_drop() will cancel all jobs via
cancel_delayed_work_sync().

In summary, we require synchronization to coordinate the backlog thread
and close() thread.

The panic I catched:
'''
Workqueue: events sk_psock_backlog
RIP: 0010:sock_sendmsg+0x21d/0x440
RAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001
...
Call Trace:
 &lt;TASK&gt;
 ? die_addr+0x40/0xa0
 ? exc_general_protection+0x14c/0x230
 ? asm_exc_general_protection+0x26/0x30
 ? sock_sendmsg+0x21d/0x440
 ? sock_sendmsg+0x3e0/0x440
 ? __pfx_sock_sendmsg+0x10/0x10
 __skb_send_sock+0x543/0xb70
 sk_psock_backlog+0x247/0xb80
...
'''</Note>
    </Notes>
    <CVE>CVE-2025-38154</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: mt7915: Fix null-ptr-deref in mt7915_mmio_wed_init()

devm_ioremap() returns NULL on error. Currently, mt7915_mmio_wed_init()
does not check for this case, which results in a NULL pointer
dereference.

Prevent null pointer dereference in mt7915_mmio_wed_init().</Note>
    </Notes>
    <CVE>CVE-2025-38155</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: ath9k_htc: Abort software beacon handling if disabled

A malicious USB device can send a WMI_SWBA_EVENTID event from an
ath9k_htc-managed device before beaconing has been enabled. This causes
a device-by-zero error in the driver, leading to either a crash or an
out of bounds read.

Prevent this by aborting the handling in ath9k_htc_swba() if beacons are
not enabled.</Note>
    </Notes>
    <CVE>CVE-2025-38157</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hisi_acc_vfio_pci: fix XQE dma address error

The dma addresses of EQE and AEQE are wrong after migration and
results in guest kernel-mode encryption services  failure.
Comparing the definition of hardware registers, we found that
there was an error when the data read from the register was
combined into an address. Therefore, the address combination
sequence needs to be corrected.

Even after fixing the above problem, we still have an issue
where the Guest from an old kernel can get migrated to
new kernel and may result in wrong data.

In order to ensure that the address is correct after migration,
if an old magic number is detected, the dma address needs to be
updated.</Note>
    </Notes>
    <CVE>CVE-2025-38158</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: rtw88: fix the 'para' buffer size to avoid reading out of bounds

Set the size to 6 instead of 2, since 'para' array is passed to
'rtw_fw_bt_wifi_control(rtwdev, para[0], &amp;para[1])', which reads
5 bytes:

void rtw_fw_bt_wifi_control(struct rtw_dev *rtwdev, u8 op_code, u8 *data)
{
    ...
    SET_BT_WIFI_CONTROL_DATA1(h2c_pkt, *data);
    SET_BT_WIFI_CONTROL_DATA2(h2c_pkt, *(data + 1));
    ...
    SET_BT_WIFI_CONTROL_DATA5(h2c_pkt, *(data + 4));

Detected using the static analysis tool - Svace.</Note>
    </Notes>
    <CVE>CVE-2025-38159</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/mlx5: Fix error flow upon firmware failure for RQ destruction

Upon RQ destruction if the firmware command fails which is the
last resource to be destroyed some SW resources were already cleaned
regardless of the failure.

Now properly rollback the object to its original state upon such failure.

In order to avoid a use-after free in case someone tries to destroy the
object again, which results in the following kernel trace:
refcount_t: underflow; use-after-free.
WARNING: CPU: 0 PID: 37589 at lib/refcount.c:28 refcount_warn_saturate+0xf4/0x148
Modules linked in: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) rfkill mlx5_core(OE) mlxdevm(OE) ib_uverbs(OE) ib_core(OE) psample mlxfw(OE) mlx_compat(OE) macsec tls pci_hyperv_intf sunrpc vfat fat virtio_net net_failover failover fuse loop nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce virtio_console virtio_gpu virtio_blk virtio_dma_buf virtio_mmio dm_mirror dm_region_hash dm_log dm_mod xpmem(OE)
CPU: 0 UID: 0 PID: 37589 Comm: python3 Kdump: loaded Tainted: G           OE     -------  ---  6.12.0-54.el10.aarch64 #1
Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : refcount_warn_saturate+0xf4/0x148
lr : refcount_warn_saturate+0xf4/0x148
sp : ffff80008b81b7e0
x29: ffff80008b81b7e0 x28: ffff000133d51600 x27: 0000000000000001
x26: 0000000000000000 x25: 00000000ffffffea x24: ffff00010ae80f00
x23: ffff00010ae80f80 x22: ffff0000c66e5d08 x21: 0000000000000000
x20: ffff0000c66e0000 x19: ffff00010ae80340 x18: 0000000000000006
x17: 0000000000000000 x16: 0000000000000020 x15: ffff80008b81b37f
x14: 0000000000000000 x13: 2e656572662d7265 x12: ffff80008283ef78
x11: ffff80008257efd0 x10: ffff80008283efd0 x9 : ffff80008021ed90
x8 : 0000000000000001 x7 : 00000000000bffe8 x6 : c0000000ffff7fff
x5 : ffff0001fb8e3408 x4 : 0000000000000000 x3 : ffff800179993000
x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000133d51600
Call trace:
 refcount_warn_saturate+0xf4/0x148
 mlx5_core_put_rsc+0x88/0xa0 [mlx5_ib]
 mlx5_core_destroy_rq_tracked+0x64/0x98 [mlx5_ib]
 mlx5_ib_destroy_wq+0x34/0x80 [mlx5_ib]
 ib_destroy_wq_user+0x30/0xc0 [ib_core]
 uverbs_free_wq+0x28/0x58 [ib_uverbs]
 destroy_hw_idr_uobject+0x34/0x78 [ib_uverbs]
 uverbs_destroy_uobject+0x48/0x240 [ib_uverbs]
 __uverbs_cleanup_ufile+0xd4/0x1a8 [ib_uverbs]
 uverbs_destroy_ufile_hw+0x48/0x120 [ib_uverbs]
 ib_uverbs_close+0x2c/0x100 [ib_uverbs]
 __fput+0xd8/0x2f0
 __fput_sync+0x50/0x70
 __arm64_sys_close+0x40/0x90
 invoke_syscall.constprop.0+0x74/0xd0
 do_el0_svc+0x48/0xe8
 el0_svc+0x44/0x1d0
 el0t_64_sync_handler+0x120/0x130
 el0t_64_sync+0x1a4/0x1a8</Note>
    </Notes>
    <CVE>CVE-2025-38161</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfilter: nft_set_pipapo: prevent overflow in lookup table allocation

When calculating the lookup table size, ensure the following
multiplication does not overflow:

- desc-&gt;field_len[] maximum value is U8_MAX multiplied by
  NFT_PIPAPO_GROUPS_PER_BYTE(f) that can be 2, worst case.
- NFT_PIPAPO_BUCKETS(f-&gt;bb) is 2^8, worst case.
- sizeof(unsigned long), from sizeof(*f-&gt;lt), lt in
  struct nft_pipapo_field.

Then, use check_mul_overflow() to multiply by bucket size and then use
check_add_overflow() to the alignment for avx2 (if needed). Finally, add
lt_size_check_overflow() helper and use it to consolidate this.

While at it, replace leftover allocation using the GFP_KERNEL to
GFP_KERNEL_ACCOUNT for consistency, in pipapo_resize().</Note>
    </Notes>
    <CVE>CVE-2025-38162</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: fix ktls panic with sockmap

[ 2172.936997] ------------[ cut here ]------------
[ 2172.936999] kernel BUG at lib/iov_iter.c:629!
......
[ 2172.944996] PKRU: 55555554
[ 2172.945155] Call Trace:
[ 2172.945299]  &lt;TASK&gt;
[ 2172.945428]  ? die+0x36/0x90
[ 2172.945601]  ? do_trap+0xdd/0x100
[ 2172.945795]  ? iov_iter_revert+0x178/0x180
[ 2172.946031]  ? iov_iter_revert+0x178/0x180
[ 2172.946267]  ? do_error_trap+0x7d/0x110
[ 2172.946499]  ? iov_iter_revert+0x178/0x180
[ 2172.946736]  ? exc_invalid_op+0x50/0x70
[ 2172.946961]  ? iov_iter_revert+0x178/0x180
[ 2172.947197]  ? asm_exc_invalid_op+0x1a/0x20
[ 2172.947446]  ? iov_iter_revert+0x178/0x180
[ 2172.947683]  ? iov_iter_revert+0x5c/0x180
[ 2172.947913]  tls_sw_sendmsg_locked.isra.0+0x794/0x840
[ 2172.948206]  tls_sw_sendmsg+0x52/0x80
[ 2172.948420]  ? inet_sendmsg+0x1f/0x70
[ 2172.948634]  __sys_sendto+0x1cd/0x200
[ 2172.948848]  ? find_held_lock+0x2b/0x80
[ 2172.949072]  ? syscall_trace_enter+0x140/0x270
[ 2172.949330]  ? __lock_release.isra.0+0x5e/0x170
[ 2172.949595]  ? find_held_lock+0x2b/0x80
[ 2172.949817]  ? syscall_trace_enter+0x140/0x270
[ 2172.950211]  ? lockdep_hardirqs_on_prepare+0xda/0x190
[ 2172.950632]  ? ktime_get_coarse_real_ts64+0xc2/0xd0
[ 2172.951036]  __x64_sys_sendto+0x24/0x30
[ 2172.951382]  do_syscall_64+0x90/0x170
......

After calling bpf_exec_tx_verdict(), the size of msg_pl-&gt;sg may increase,
e.g., when the BPF program executes bpf_msg_push_data().

If the BPF program sets cork_bytes and sg.size is smaller than cork_bytes,
it will return -ENOSPC and attempt to roll back to the non-zero copy
logic. However, during rollback, msg-&gt;msg_iter is reset, but since
msg_pl-&gt;sg.size has been increased, subsequent executions will exceed the
actual size of msg_iter.
'''
iov_iter_revert(&amp;msg-&gt;msg_iter, msg_pl-&gt;sg.size - orig_size);
'''

The changes in this commit are based on the following considerations:

1. When cork_bytes is set, rolling back to non-zero copy logic is
pointless and can directly go to zero-copy logic.

2. We can not calculate the correct number of bytes to revert msg_iter.

Assume the original data is "abcdefgh" (8 bytes), and after 3 pushes
by the BPF program, it becomes 11-byte data: "abc?de?fgh?".
Then, we set cork_bytes to 6, which means the first 6 bytes have been
processed, and the remaining 5 bytes "?fgh?" will be cached until the
length meets the cork_bytes requirement.

However, some data in "?fgh?" is not within 'sg-&gt;msg_iter'
(but in msg_pl instead), especially the data "?" we pushed.

So it doesn't seem as simple as just reverting through an offset of
msg_iter.

3. For non-TLS sockets in tcp_bpf_sendmsg, when a "cork" situation occurs,
the user-space send() doesn't return an error, and the returned length is
the same as the input length parameter, even if some data is cached.

Additionally, I saw that the current non-zero-copy logic for handling
corking is written as:
'''
line 1177
else if (ret != -EAGAIN) {
	if (ret == -ENOSPC)
		ret = 0;
	goto send_end;
'''

So it's ok to just return 'copied' without error when a "cork" situation
occurs.</Note>
    </Notes>
    <CVE>CVE-2025-38166</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

crypto: marvell/cesa - Handle zero-length skcipher requests

Do not access random memory for zero-length skcipher requests.
Just return 0.</Note>
    </Notes>
    <CVE>CVE-2025-38173</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

thunderbolt: Do not double dequeue a configuration request

Some of our devices crash in tb_cfg_request_dequeue():

 general protection fault, probably for non-canonical address 0xdead000000000122

 CPU: 6 PID: 91007 Comm: kworker/6:2 Tainted: G U W 6.6.65
 RIP: 0010:tb_cfg_request_dequeue+0x2d/0xa0
 Call Trace:
 &lt;TASK&gt;
 ? tb_cfg_request_dequeue+0x2d/0xa0
 tb_cfg_request_work+0x33/0x80
 worker_thread+0x386/0x8f0
 kthread+0xed/0x110
 ret_from_fork+0x38/0x50
 ret_from_fork_asm+0x1b/0x30

The circumstances are unclear, however, the theory is that
tb_cfg_request_work() can be scheduled twice for a request:
first time via frame.callback from ring_work() and second
time from tb_cfg_request().  Both times kworkers will execute
tb_cfg_request_dequeue(), which results in double list_del()
from the ctl-&gt;request_queue (the list poison deference hints
at it: 0xdead000000000122).

Do not dequeue requests that don't have TB_CFG_REQUEST_ACTIVE
bit set.</Note>
    </Notes>
    <CVE>CVE-2025-38174</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: atm: fix /proc/net/atm/lec handling

/proc/net/atm/lec must ensure safety against dev_lec[] changes.

It appears it had dev_put() calls without prior dev_hold(),
leading to imbalance and UAF.</Note>
    </Notes>
    <CVE>CVE-2025-38180</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

calipso: Fix null-ptr-deref in calipso_req_{set,del}attr().

syzkaller reported a null-ptr-deref in sock_omalloc() while allocating
a CALIPSO option.  [0]

The NULL is of struct sock, which was fetched by sk_to_full_sk() in
calipso_req_setattr().

Since commit a1a5344ddbe8 ("tcp: avoid two atomic ops for syncookies"),
reqsk-&gt;rsk_listener could be NULL when SYN Cookie is returned to its
client, as hinted by the leading SYN Cookie log.

Here are 3 options to fix the bug:

  1) Return 0 in calipso_req_setattr()
  2) Return an error in calipso_req_setattr()
  3) Alaways set rsk_listener

1) is no go as it bypasses LSM, but 2) effectively disables SYN Cookie
for CALIPSO.  3) is also no go as there have been many efforts to reduce
atomic ops and make TCP robust against DDoS.  See also commit 3b24d854cb35
("tcp/dccp: do not touch listener sk_refcnt under synflood").

As of the blamed commit, SYN Cookie already did not need refcounting,
and no one has stumbled on the bug for 9 years, so no CALIPSO user will
care about SYN Cookie.

Let's return an error in calipso_req_setattr() and calipso_req_delattr()
in the SYN Cookie case.

This can be reproduced by [1] on Fedora and now connect() of nc times out.

[0]:
TCP: request_sock_TCPv6: Possible SYN flooding on port [::]:20002. Sending cookies.
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
CPU: 3 UID: 0 PID: 12262 Comm: syz.1.2611 Not tainted 6.14.0 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
RIP: 0010:read_pnet include/net/net_namespace.h:406 [inline]
RIP: 0010:sock_net include/net/sock.h:655 [inline]
RIP: 0010:sock_kmalloc+0x35/0x170 net/core/sock.c:2806
Code: 89 d5 41 54 55 89 f5 53 48 89 fb e8 25 e3 c6 fd e8 f0 91 e3 00 48 8d 7b 30 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 &lt;80&gt; 3c 02 00 0f 85 26 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b
RSP: 0018:ffff88811af89038 EFLAGS: 00010216
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffff888105266400
RDX: 0000000000000006 RSI: ffff88800c890000 RDI: 0000000000000030
RBP: 0000000000000050 R08: 0000000000000000 R09: ffff88810526640e
R10: ffffed1020a4cc81 R11: ffff88810526640f R12: 0000000000000000
R13: 0000000000000820 R14: ffff888105266400 R15: 0000000000000050
FS:  00007f0653a07640(0000) GS:ffff88811af80000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f863ba096f4 CR3: 00000000163c0005 CR4: 0000000000770ef0
PKRU: 80000000
Call Trace:
 &lt;IRQ&gt;
 ipv6_renew_options+0x279/0x950 net/ipv6/exthdrs.c:1288
 calipso_req_setattr+0x181/0x340 net/ipv6/calipso.c:1204
 calipso_req_setattr+0x56/0x80 net/netlabel/netlabel_calipso.c:597
 netlbl_req_setattr+0x18a/0x440 net/netlabel/netlabel_kapi.c:1249
 selinux_netlbl_inet_conn_request+0x1fb/0x320 security/selinux/netlabel.c:342
 selinux_inet_conn_request+0x1eb/0x2c0 security/selinux/hooks.c:5551
 security_inet_conn_request+0x50/0xa0 security/security.c:4945
 tcp_v6_route_req+0x22c/0x550 net/ipv6/tcp_ipv6.c:825
 tcp_conn_request+0xec8/0x2b70 net/ipv4/tcp_input.c:7275
 tcp_v6_conn_request+0x1e3/0x440 net/ipv6/tcp_ipv6.c:1328
 tcp_rcv_state_process+0xafa/0x52b0 net/ipv4/tcp_input.c:6781
 tcp_v6_do_rcv+0x8a6/0x1a40 net/ipv6/tcp_ipv6.c:1667
 tcp_v6_rcv+0x505e/0x5b50 net/ipv6/tcp_ipv6.c:1904
 ip6_protocol_deliver_rcu+0x17c/0x1da0 net/ipv6/ip6_input.c:436
 ip6_input_finish+0x103/0x180 net/ipv6/ip6_input.c:480
 NF_HOOK include/linux/netfilter.h:314 [inline]
 NF_HOOK include/linux/netfilter.h:308 [inline]
 ip6_input+0x13c/0x6b0 net/ipv6/ip6_input.c:491
 dst_input include/net/dst.h:469 [inline]
 ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline]
 ip6_rcv_finish+0xb6/0x490 net/ipv6/ip6_input.c:69
 NF_HOOK include/linux/netfilter.h:314 [inline]
 NF_HOOK include/linux/netf
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-38181</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ublk: santizize the arguments from userspace when adding a device

Sanity check the values for queue depth and number of queues
we get from userspace when adding a device.</Note>
    </Notes>
    <CVE>CVE-2025-38182</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: lan743x: fix potential out-of-bounds write in lan743x_ptp_io_event_clock_get()

Before calling lan743x_ptp_io_event_clock_get(), the 'channel' value
is checked against the maximum value of PCI11X1X_PTP_IO_MAX_CHANNELS(8).
This seems correct and aligns with the PTP interrupt status register
(PTP_INT_STS) specifications.

However, lan743x_ptp_io_event_clock_get() writes to ptp-&gt;extts[] with
only LAN743X_PTP_N_EXTTS(4) elements, using channel as an index:

    lan743x_ptp_io_event_clock_get(..., u8 channel,...)
    {
        ...
        /* Update Local timestamp */
        extts = &amp;ptp-&gt;extts[channel];
        extts-&gt;ts.tv_sec = sec;
        ...
    }

To avoid an out-of-bounds write and utilize all the supported GPIO
inputs, set LAN743X_PTP_N_EXTTS to 8.

Detected using the static analysis tool - Svace.</Note>
    </Notes>
    <CVE>CVE-2025-38183</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bnxt_en: Fix double invocation of bnxt_ulp_stop()/bnxt_ulp_start()

Before the commit under the Fixes tag below, bnxt_ulp_stop() and
bnxt_ulp_start() were always invoked in pairs.  After that commit,
the new bnxt_ulp_restart() can be invoked after bnxt_ulp_stop()
has been called.  This may result in the RoCE driver's aux driver
.suspend() method being invoked twice.  The 2nd bnxt_re_suspend()
call will crash when it dereferences a NULL pointer:

(NULL ib_device): Handle device suspend call
BUG: kernel NULL pointer dereference, address: 0000000000000b78
PGD 0 P4D 0
Oops: Oops: 0000 [#1] SMP PTI
CPU: 20 UID: 0 PID: 181 Comm: kworker/u96:5 Tainted: G S                  6.15.0-rc1 #4 PREEMPT(voluntary)
Tainted: [S]=CPU_OUT_OF_SPEC
Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01/17/2017
Workqueue: bnxt_pf_wq bnxt_sp_task [bnxt_en]
RIP: 0010:bnxt_re_suspend+0x45/0x1f0 [bnxt_re]
Code: 8b 05 a7 3c 5b f5 48 89 44 24 18 31 c0 49 8b 5c 24 08 4d 8b 2c 24 e8 ea 06 0a f4 48 c7 c6 04 60 52 c0 48 89 df e8 1b ce f9 ff &lt;48&gt; 8b 83 78 0b 00 00 48 8b 80 38 03 00 00 a8 40 0f 85 b5 00 00 00
RSP: 0018:ffffa2e84084fd88 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000001
RDX: 0000000000000000 RSI: ffffffffb4b6b934 RDI: 00000000ffffffff
RBP: ffffa1760954c9c0 R08: 0000000000000000 R09: c0000000ffffdfff
R10: 0000000000000001 R11: ffffa2e84084fb50 R12: ffffa176031ef070
R13: ffffa17609775000 R14: ffffa17603adc180 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffffa17daa397000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000b78 CR3: 00000004aaa30003 CR4: 00000000003706f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
&lt;TASK&gt;
bnxt_ulp_stop+0x69/0x90 [bnxt_en]
bnxt_sp_task+0x678/0x920 [bnxt_en]
? __schedule+0x514/0xf50
process_scheduled_works+0x9d/0x400
worker_thread+0x11c/0x260
? __pfx_worker_thread+0x10/0x10
kthread+0xfe/0x1e0
? __pfx_kthread+0x10/0x10
ret_from_fork+0x2b/0x40
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30

Check the BNXT_EN_FLAG_ULP_STOPPED flag and do not proceed if the flag
is already set.  This will preserve the original symmetrical
bnxt_ulp_stop() and bnxt_ulp_start().

Also, inside bnxt_ulp_start(), clear the BNXT_EN_FLAG_ULP_STOPPED
flag after taking the mutex to avoid any race condition.  And for
symmetry, only proceed in bnxt_ulp_start() if the
BNXT_EN_FLAG_ULP_STOPPED is set.</Note>
    </Notes>
    <CVE>CVE-2025-38186</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/nouveau: fix a use-after-free in r535_gsp_rpc_push()

The RPC container is released after being passed to r535_gsp_rpc_send().

When sending the initial fragment of a large RPC and passing the
caller's RPC container, the container will be freed prematurely. Subsequent
attempts to send remaining fragments will therefore result in a
use-after-free.

Allocate a temporary RPC container for holding the initial fragment of a
large RPC when sending. Free the caller's container when all fragments
are successfully sent.

[ Rebase onto Blackwell changes. - Danilo ]</Note>
    </Notes>
    <CVE>CVE-2025-38187</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/msm/a7xx: Call CP_RESET_CONTEXT_STATE

Calling this packet is necessary when we switch contexts because there
are various pieces of state used by userspace to synchronize between BR
and BV that are persistent across submits and we need to make sure that
they are in a "safe" state when switching contexts. Otherwise a
userspace submission in one context could cause another context to
function incorrectly and hang, effectively a denial of service (although
without leaking data). This was missed during initial a7xx bringup.

Patchwork: https://patchwork.freedesktop.org/patch/654924/</Note>
    </Notes>
    <CVE>CVE-2025-38188</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/v3d: Avoid NULL pointer dereference in `v3d_job_update_stats()`

The following kernel Oops was recently reported by Mesa CI:

[  800.139824] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000588
[  800.148619] Mem abort info:
[  800.151402]   ESR = 0x0000000096000005
[  800.155141]   EC = 0x25: DABT (current EL), IL = 32 bits
[  800.160444]   SET = 0, FnV = 0
[  800.163488]   EA = 0, S1PTW = 0
[  800.166619]   FSC = 0x05: level 1 translation fault
[  800.171487] Data abort info:
[  800.174357]   ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
[  800.179832]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[  800.184873]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[  800.190176] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001014c2000
[  800.196607] [0000000000000588] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000
[  800.205305] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP
[  800.211564] Modules linked in: vc4 snd_soc_hdmi_codec drm_display_helper v3d cec gpu_sched drm_dma_helper drm_shmem_helper drm_kms_helper drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm i2c_brcmstb snd_timer snd backlight
[  800.234448] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.25+rpt-rpi-v8 #1  Debian 1:6.12.25-1+rpt1
[  800.244182] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT)
[  800.250005] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  800.256959] pc : v3d_job_update_stats+0x60/0x130 [v3d]
[  800.262112] lr : v3d_job_update_stats+0x48/0x130 [v3d]
[  800.267251] sp : ffffffc080003e60
[  800.270555] x29: ffffffc080003e60 x28: ffffffd842784980 x27: 0224012000000000
[  800.277687] x26: ffffffd84277f630 x25: ffffff81012fd800 x24: 0000000000000020
[  800.284818] x23: ffffff8040238b08 x22: 0000000000000570 x21: 0000000000000158
[  800.291948] x20: 0000000000000000 x19: ffffff8040238000 x18: 0000000000000000
[  800.299078] x17: ffffffa8c1bd2000 x16: ffffffc080000000 x15: 0000000000000000
[  800.306208] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
[  800.313338] x11: 0000000000000040 x10: 0000000000001a40 x9 : ffffffd83b39757c
[  800.320468] x8 : ffffffd842786420 x7 : 7fffffffffffffff x6 : 0000000000ef32b0
[  800.327598] x5 : 00ffffffffffffff x4 : 0000000000000015 x3 : ffffffd842784980
[  800.334728] x2 : 0000000000000004 x1 : 0000000000010002 x0 : 000000ba4c0ca382
[  800.341859] Call trace:
[  800.344294]  v3d_job_update_stats+0x60/0x130 [v3d]
[  800.349086]  v3d_irq+0x124/0x2e0 [v3d]
[  800.352835]  __handle_irq_event_percpu+0x58/0x218
[  800.357539]  handle_irq_event+0x54/0xb8
[  800.361369]  handle_fasteoi_irq+0xac/0x240
[  800.365458]  handle_irq_desc+0x48/0x68
[  800.369200]  generic_handle_domain_irq+0x24/0x38
[  800.373810]  gic_handle_irq+0x48/0xd8
[  800.377464]  call_on_irq_stack+0x24/0x58
[  800.381379]  do_interrupt_handler+0x88/0x98
[  800.385554]  el1_interrupt+0x34/0x68
[  800.389123]  el1h_64_irq_handler+0x18/0x28
[  800.393211]  el1h_64_irq+0x64/0x68
[  800.396603]  default_idle_call+0x3c/0x168
[  800.400606]  do_idle+0x1fc/0x230
[  800.403827]  cpu_startup_entry+0x40/0x50
[  800.407742]  rest_init+0xe4/0xf0
[  800.410962]  start_kernel+0x5e8/0x790
[  800.414616]  __primary_switched+0x80/0x90
[  800.418622] Code: 8b170277 8b160296 11000421 b9000861 (b9401ac1)
[  800.424707] ---[ end trace 0000000000000000 ]---
[  800.457313] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---

This issue happens when the file descriptor is closed before the jobs
submitted by it are completed. When the job completes, we update the
global GPU stats and the per-fd GPU stats, which are exposed through
fdinfo. If the file descriptor was closed, then the struct `v3d_file_priv`
and its stats were already freed and we can't update the per-fd stats.

Therefore, if the file descriptor was already closed, don't u
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-38189</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: clear the dst when changing skb protocol

A not-so-careful NAT46 BPF program can crash the kernel
if it indiscriminately flips ingress packets from v4 to v6:

  BUG: kernel NULL pointer dereference, address: 0000000000000000
    ip6_rcv_core (net/ipv6/ip6_input.c:190:20)
    ipv6_rcv (net/ipv6/ip6_input.c:306:8)
    process_backlog (net/core/dev.c:6186:4)
    napi_poll (net/core/dev.c:6906:9)
    net_rx_action (net/core/dev.c:7028:13)
    do_softirq (kernel/softirq.c:462:3)
    netif_rx (net/core/dev.c:5326:3)
    dev_loopback_xmit (net/core/dev.c:4015:2)
    ip_mc_finish_output (net/ipv4/ip_output.c:363:8)
    NF_HOOK (./include/linux/netfilter.h:314:9)
    ip_mc_output (net/ipv4/ip_output.c:400:5)
    dst_output (./include/net/dst.h:459:9)
    ip_local_out (net/ipv4/ip_output.c:130:9)
    ip_send_skb (net/ipv4/ip_output.c:1496:8)
    udp_send_skb (net/ipv4/udp.c:1040:8)
    udp_sendmsg (net/ipv4/udp.c:1328:10)

The output interface has a 4-&gt;6 program attached at ingress.
We try to loop the multicast skb back to the sending socket.
Ingress BPF runs as part of netif_rx(), pushes a valid v6 hdr
and changes skb-&gt;protocol to v6. We enter ip6_rcv_core which
tries to use skb_dst(). But the dst is still an IPv4 one left
after IPv4 mcast output.

Clear the dst in all BPF helpers which change the protocol.
Try to preserve metadata dsts, those may carry non-routing
metadata.</Note>
    </Notes>
    <CVE>CVE-2025-38192</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net_sched: sch_sfq: reject invalid perturb period

Gerrard Tai reported that SFQ perturb_period has no range check yet,
and this can be used to trigger a race condition fixed in a separate patch.

We want to make sure ctl-&gt;perturb_period * HZ will not overflow
and is positive.


tc qd add dev lo root sfq perturb -10   # negative value : error
Error: sch_sfq: invalid perturb period.

tc qd add dev lo root sfq perturb 1000000000 # too big : error
Error: sch_sfq: invalid perturb period.

tc qd add dev lo root sfq perturb 2000000 # acceptable value
tc -s -d qd sh dev lo
qdisc sfq 8005: root refcnt 2 limit 127p quantum 64Kb depth 127 flows 128 divisor 1024 perturb 2000000sec
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0</Note>
    </Notes>
    <CVE>CVE-2025-38193</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

jffs2: check that raw node were preallocated before writing summary

Syzkaller detected a kernel bug in jffs2_link_node_ref, caused by fault
injection in jffs2_prealloc_raw_node_refs. jffs2_sum_write_sumnode doesn't
check return value of jffs2_prealloc_raw_node_refs and simply lets any
error propagate into jffs2_sum_write_data, which eventually calls
jffs2_link_node_ref in order to link the summary to an expectedly allocated
node.

kernel BUG at fs/jffs2/nodelist.c:592!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI
CPU: 1 PID: 31277 Comm: syz-executor.7 Not tainted 6.1.128-syzkaller-00139-ge10f83ca10a1 #0
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
RIP: 0010:jffs2_link_node_ref+0x570/0x690 fs/jffs2/nodelist.c:592
Call Trace:
 &lt;TASK&gt;
 jffs2_sum_write_data fs/jffs2/summary.c:841 [inline]
 jffs2_sum_write_sumnode+0xd1a/0x1da0 fs/jffs2/summary.c:874
 jffs2_do_reserve_space+0xa18/0xd60 fs/jffs2/nodemgmt.c:388
 jffs2_reserve_space+0x55f/0xaa0 fs/jffs2/nodemgmt.c:197
 jffs2_write_inode_range+0x246/0xb50 fs/jffs2/write.c:362
 jffs2_write_end+0x726/0x15d0 fs/jffs2/file.c:301
 generic_perform_write+0x314/0x5d0 mm/filemap.c:3856
 __generic_file_write_iter+0x2ae/0x4d0 mm/filemap.c:3973
 generic_file_write_iter+0xe3/0x350 mm/filemap.c:4005
 call_write_iter include/linux/fs.h:2265 [inline]
 do_iter_readv_writev+0x20f/0x3c0 fs/read_write.c:735
 do_iter_write+0x186/0x710 fs/read_write.c:861
 vfs_iter_write+0x70/0xa0 fs/read_write.c:902
 iter_file_splice_write+0x73b/0xc90 fs/splice.c:685
 do_splice_from fs/splice.c:763 [inline]
 direct_splice_actor+0x10c/0x170 fs/splice.c:950
 splice_direct_to_actor+0x337/0xa10 fs/splice.c:896
 do_splice_direct+0x1a9/0x280 fs/splice.c:1002
 do_sendfile+0xb13/0x12c0 fs/read_write.c:1255
 __do_sys_sendfile64 fs/read_write.c:1323 [inline]
 __se_sys_sendfile64 fs/read_write.c:1309 [inline]
 __x64_sys_sendfile64+0x1cf/0x210 fs/read_write.c:1309
 do_syscall_x64 arch/x86/entry/common.c:51 [inline]
 do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81
 entry_SYSCALL_64_after_hwframe+0x6e/0xd8

Fix this issue by checking return value of jffs2_prealloc_raw_node_refs
before calling jffs2_sum_write_data.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.</Note>
    </Notes>
    <CVE>CVE-2025-38194</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

platform/x86: dell_rbu: Fix list usage

Pass the correct list head to list_for_each_entry*() when looping through
the packet list.

Without this patch, reading the packet data via sysfs will show the data
incorrectly (because it starts at the wrong packet), and clearing the
packet list will result in a NULL pointer dereference.</Note>
    </Notes>
    <CVE>CVE-2025-38197</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

fbcon: Make sure modelist not set on unregistered console

It looks like attempting to write to the "store_modes" sysfs node will
run afoul of unregistered consoles:

UBSAN: array-index-out-of-bounds in drivers/video/fbdev/core/fbcon.c:122:28
index -1 is out of range for type 'fb_info *[32]'
...
 fbcon_info_from_console+0x192/0x1a0 drivers/video/fbdev/core/fbcon.c:122
 fbcon_new_modelist+0xbf/0x2d0 drivers/video/fbdev/core/fbcon.c:3048
 fb_new_modelist+0x328/0x440 drivers/video/fbdev/core/fbmem.c:673
 store_modes+0x1c9/0x3e0 drivers/video/fbdev/core/fbsysfs.c:113
 dev_attr_store+0x55/0x80 drivers/base/core.c:2439

static struct fb_info *fbcon_registered_fb[FB_MAX];
...
static signed char con2fb_map[MAX_NR_CONSOLES];
...
static struct fb_info *fbcon_info_from_console(int console)
...
        return fbcon_registered_fb[con2fb_map[console]];

If con2fb_map contains a -1 things go wrong here. Instead, return NULL,
as callers of fbcon_info_from_console() are trying to compare against
existing "info" pointers, so error handling should kick in correctly.</Note>
    </Notes>
    <CVE>CVE-2025-38198</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

i40e: fix MMIO write access to an invalid page in i40e_clear_hw

When the device sends a specific input, an integer underflow can occur, leading
to MMIO write access to an invalid page.

Prevent the integer underflow by changing the type of related variables.</Note>
    </Notes>
    <CVE>CVE-2025-38200</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: Check rcu_read_lock_trace_held() in bpf_map_lookup_percpu_elem()

bpf_map_lookup_percpu_elem() helper is also available for sleepable bpf
program. When BPF JIT is disabled or under 32-bit host,
bpf_map_lookup_percpu_elem() will not be inlined. Using it in a
sleepable bpf program will trigger the warning in
bpf_map_lookup_percpu_elem(), because the bpf program only holds
rcu_read_lock_trace lock. Therefore, add the missed check.</Note>
    </Notes>
    <CVE>CVE-2025-38202</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

jfs: Fix null-ptr-deref in jfs_ioc_trim

[ Syzkaller Report ]

Oops: general protection fault, probably for non-canonical address
0xdffffc0000000087: 0000 [#1
KASAN: null-ptr-deref in range [0x0000000000000438-0x000000000000043f]
CPU: 2 UID: 0 PID: 10614 Comm: syz-executor.0 Not tainted
6.13.0-rc6-gfbfd64d25c7a-dirty #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Sched_ext: serialise (enabled+all), task: runnable_at=-30ms
RIP: 0010:jfs_ioc_trim+0x34b/0x8f0
Code: e7 e8 59 a4 87 fe 4d 8b 24 24 4d 8d bc 24 38 04 00 00 48 8d 93
90 82 fe ff 4c 89 ff 31 f6
RSP: 0018:ffffc900055f7cd0 EFLAGS: 00010206
RAX: 0000000000000087 RBX: 00005866a9e67ff8 RCX: 000000000000000a
RDX: 0000000000000001 RSI: 0000000000000004 RDI: 0000000000000001
RBP: dffffc0000000000 R08: ffff88807c180003 R09: 1ffff1100f830000
R10: dffffc0000000000 R11: ffffed100f830001 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000438
FS:  00007fe520225640(0000) GS:ffff8880b7e80000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005593c91b2c88 CR3: 000000014927c000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
&lt;TASK&gt;
? __die_body+0x61/0xb0
? die_addr+0xb1/0xe0
? exc_general_protection+0x333/0x510
? asm_exc_general_protection+0x26/0x30
? jfs_ioc_trim+0x34b/0x8f0
jfs_ioctl+0x3c8/0x4f0
? __pfx_jfs_ioctl+0x10/0x10
? __pfx_jfs_ioctl+0x10/0x10
__se_sys_ioctl+0x269/0x350
? __pfx___se_sys_ioctl+0x10/0x10
? do_syscall_64+0xfb/0x210
do_syscall_64+0xee/0x210
? syscall_exit_to_user_mode+0x1e0/0x330
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fe51f4903ad
Code: c3 e8 a7 2b 00 00 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 89 f8 48
89 f7 48 89 d6 48 89 ca 4d
RSP: 002b:00007fe5202250c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007fe51f5cbf80 RCX: 00007fe51f4903ad
RDX: 0000000020000680 RSI: 00000000c0185879 RDI: 0000000000000005
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe520225640
R13: 000000000000000e R14: 00007fe51f44fca0 R15: 00007fe52021d000
&lt;/TASK&gt;
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:jfs_ioc_trim+0x34b/0x8f0
Code: e7 e8 59 a4 87 fe 4d 8b 24 24 4d 8d bc 24 38 04 00 00 48 8d 93
90 82 fe ff 4c 89 ff 31 f6
RSP: 0018:ffffc900055f7cd0 EFLAGS: 00010206
RAX: 0000000000000087 RBX: 00005866a9e67ff8 RCX: 000000000000000a
RDX: 0000000000000001 RSI: 0000000000000004 RDI: 0000000000000001
RBP: dffffc0000000000 R08: ffff88807c180003 R09: 1ffff1100f830000
R10: dffffc0000000000 R11: ffffed100f830001 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000438
FS:  00007fe520225640(0000) GS:ffff8880b7e80000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005593c91b2c88 CR3: 000000014927c000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Kernel panic - not syncing: Fatal exception

[ Analysis ]

We believe that we have found a concurrency bug in the `fs/jfs` module
that results in a null pointer dereference. There is a closely related
issue which has been fixed:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d6c1b3599b2feb5c7291f5ac3a36e5fa7cedb234

... but, unfortunately, the accepted patch appears to still be
susceptible to a null pointer dereference under some interleavings.

To trigger the bug, we think that `JFS_SBI(ipbmap-&gt;i_sb)-&gt;bmap` is set
to NULL in `dbFreeBits` and then dereferenced in `jfs_ioc_trim`. This
bug manifests quite rarely under normal circumstances, but is
triggereable from a syz-program.</Note>
    </Notes>
    <CVE>CVE-2025-38203</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

jfs: fix array-index-out-of-bounds read in add_missing_indices

stbl is s8 but it must contain offsets into slot which can go from 0 to
127.

Added a bound check for that error and return -EIO if the check fails.
Also make jfs_readdir return with error if add_missing_indices returns
with an error.</Note>
    </Notes>
    <CVE>CVE-2025-38204</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

exfat: fix double free in delayed_free

The double free could happen in the following path.

exfat_create_upcase_table()
        exfat_create_upcase_table() : return error
        exfat_free_upcase_table() : free -&gt;vol_utbl
        exfat_load_default_upcase_table : return error
     exfat_kill_sb()
           delayed_free()
                  exfat_free_upcase_table() &lt;--------- double free
This patch set -&gt;vol_util as NULL after freeing it.</Note>
    </Notes>
    <CVE>CVE-2025-38206</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

configfs-tsm-report: Fix NULL dereference of tsm_ops

Unlike sysfs, the lifetime of configfs objects is controlled by
userspace. There is no mechanism for the kernel to find and delete all
created config-items. Instead, the configfs-tsm-report mechanism has an
expectation that tsm_unregister() can happen at any time and cause
established config-item access to start failing.

That expectation is not fully satisfied. While tsm_report_read(),
tsm_report_{is,is_bin}_visible(), and tsm_report_make_item() safely fail
if tsm_ops have been unregistered, tsm_report_privlevel_store()
tsm_report_provider_show() fail to check for ops registration. Add the
missing checks for tsm_ops having been removed.

Now, in supporting the ability for tsm_unregister() to always succeed,
it leaves the problem of what to do with lingering config-items. The
expectation is that the admin that arranges for the -&gt;remove() (unbind)
of the ${tsm_arch}-guest driver is also responsible for deletion of all
open config-items. Until that deletion happens, -&gt;probe() (reload /
bind) of the ${tsm_arch}-guest driver fails.

This allows for emergency shutdown / revocation of attestation
interfaces, and requires coordinated restart.</Note>
    </Notes>
    <CVE>CVE-2025-38210</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/iwcm: Fix use-after-free of work objects after cm_id destruction

The commit 59c68ac31e15 ("iw_cm: free cm_id resources on the last
deref") simplified cm_id resource management by freeing cm_id once all
references to the cm_id were removed. The references are removed either
upon completion of iw_cm event handlers or when the application destroys
the cm_id. This commit introduced the use-after-free condition where
cm_id_private object could still be in use by event handler works during
the destruction of cm_id. The commit aee2424246f9 ("RDMA/iwcm: Fix a
use-after-free related to destroying CM IDs") addressed this use-after-
free by flushing all pending works at the cm_id destruction.

However, still another use-after-free possibility remained. It happens
with the work objects allocated for each cm_id_priv within
alloc_work_entries() during cm_id creation, and subsequently freed in
dealloc_work_entries() once all references to the cm_id are removed.
If the cm_id's last reference is decremented in the event handler work,
the work object for the work itself gets removed, and causes the use-
after-free BUG below:

  BUG: KASAN: slab-use-after-free in __pwq_activate_work+0x1ff/0x250
  Read of size 8 at addr ffff88811f9cf800 by task kworker/u16:1/147091

  CPU: 2 UID: 0 PID: 147091 Comm: kworker/u16:1 Not tainted 6.15.0-rc2+ #27 PREEMPT(voluntary)
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014
  Workqueue:  0x0 (iw_cm_wq)
  Call Trace:
   &lt;TASK&gt;
   dump_stack_lvl+0x6a/0x90
   print_report+0x174/0x554
   ? __virt_addr_valid+0x208/0x430
   ? __pwq_activate_work+0x1ff/0x250
   kasan_report+0xae/0x170
   ? __pwq_activate_work+0x1ff/0x250
   __pwq_activate_work+0x1ff/0x250
   pwq_dec_nr_in_flight+0x8c5/0xfb0
   process_one_work+0xc11/0x1460
   ? __pfx_process_one_work+0x10/0x10
   ? assign_work+0x16c/0x240
   worker_thread+0x5ef/0xfd0
   ? __pfx_worker_thread+0x10/0x10
   kthread+0x3b0/0x770
   ? __pfx_kthread+0x10/0x10
   ? rcu_is_watching+0x11/0xb0
   ? _raw_spin_unlock_irq+0x24/0x50
   ? rcu_is_watching+0x11/0xb0
   ? __pfx_kthread+0x10/0x10
   ret_from_fork+0x30/0x70
   ? __pfx_kthread+0x10/0x10
   ret_from_fork_asm+0x1a/0x30
   &lt;/TASK&gt;

  Allocated by task 147416:
   kasan_save_stack+0x2c/0x50
   kasan_save_track+0x10/0x30
   __kasan_kmalloc+0xa6/0xb0
   alloc_work_entries+0xa9/0x260 [iw_cm]
   iw_cm_connect+0x23/0x4a0 [iw_cm]
   rdma_connect_locked+0xbfd/0x1920 [rdma_cm]
   nvme_rdma_cm_handler+0x8e5/0x1b60 [nvme_rdma]
   cma_cm_event_handler+0xae/0x320 [rdma_cm]
   cma_work_handler+0x106/0x1b0 [rdma_cm]
   process_one_work+0x84f/0x1460
   worker_thread+0x5ef/0xfd0
   kthread+0x3b0/0x770
   ret_from_fork+0x30/0x70
   ret_from_fork_asm+0x1a/0x30

  Freed by task 147091:
   kasan_save_stack+0x2c/0x50
   kasan_save_track+0x10/0x30
   kasan_save_free_info+0x37/0x60
   __kasan_slab_free+0x4b/0x70
   kfree+0x13a/0x4b0
   dealloc_work_entries+0x125/0x1f0 [iw_cm]
   iwcm_deref_id+0x6f/0xa0 [iw_cm]
   cm_work_handler+0x136/0x1ba0 [iw_cm]
   process_one_work+0x84f/0x1460
   worker_thread+0x5ef/0xfd0
   kthread+0x3b0/0x770
   ret_from_fork+0x30/0x70
   ret_from_fork_asm+0x1a/0x30

  Last potentially related work creation:
   kasan_save_stack+0x2c/0x50
   kasan_record_aux_stack+0xa3/0xb0
   __queue_work+0x2ff/0x1390
   queue_work_on+0x67/0xc0
   cm_event_handler+0x46a/0x820 [iw_cm]
   siw_cm_upcall+0x330/0x650 [siw]
   siw_cm_work_handler+0x6b9/0x2b20 [siw]
   process_one_work+0x84f/0x1460
   worker_thread+0x5ef/0xfd0
   kthread+0x3b0/0x770
   ret_from_fork+0x30/0x70
   ret_from_fork_asm+0x1a/0x30

This BUG is reproducible by repeating the blktests test case nvme/061
for the rdma transport and the siw driver.

To avoid the use-after-free of cm_id_private work objects, ensure that
the last reference to the cm_id is decremented not in the event handler
works, but in the cm_id destruction context. For that purpose, mo
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-38211</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ipc: fix to protect IPCS lookups using RCU

syzbot reported that it discovered a use-after-free vulnerability, [0]

[0]: https://lore.kernel.org/all/67af13f8.050a0220.21dd3.0038.GAE@google.com/

idr_for_each() is protected by rwsem, but this is not enough.  If it is
not protected by RCU read-critical region, when idr_for_each() calls
radix_tree_node_free() through call_rcu() to free the radix_tree_node
structure, the node will be freed immediately, and when reading the next
node in radix_tree_for_each_slot(), the already freed memory may be read.

Therefore, we need to add code to make sure that idr_for_each() is
protected within the RCU read-critical region when we call it in
shm_destroy_orphaned().</Note>
    </Notes>
    <CVE>CVE-2025-38212</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
    </Notes>
    <CVE>CVE-2025-38213</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

fbdev: Fix fb_set_var to prevent null-ptr-deref in fb_videomode_to_var

If fb_add_videomode() in fb_set_var() fails to allocate memory for
fb_videomode, later it may lead to a null-ptr dereference in
fb_videomode_to_var(), as the fb_info is registered while not having the
mode in modelist that is expected to be there, i.e. the one that is
described in fb_info-&gt;var.

================================================================
general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901
Call Trace:
 display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929
 fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071
 resize_screen drivers/tty/vt/vt.c:1176 [inline]
 vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263
 fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720
 fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776
 do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128
 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203
 vfs_ioctl fs/ioctl.c:48 [inline]
 __do_sys_ioctl fs/ioctl.c:753 [inline]
 __se_sys_ioctl fs/ioctl.c:739 [inline]
 __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739
 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x67/0xd1
================================================================

The reason is that fb_info-&gt;var is being modified in fb_set_var(), and
then fb_videomode_to_var() is called. If it fails to add the mode to
fb_info-&gt;modelist, fb_set_var() returns error, but does not restore the
old value of fb_info-&gt;var. Restore fb_info-&gt;var on failure the same way
it is done earlier in the function.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.</Note>
    </Notes>
    <CVE>CVE-2025-38214</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

fbdev: Fix do_register_framebuffer to prevent null-ptr-deref in fb_videomode_to_var

If fb_add_videomode() in do_register_framebuffer() fails to allocate
memory for fb_videomode, it will later lead to a null-ptr dereference in
fb_videomode_to_var(), as the fb_info is registered while not having the
mode in modelist that is expected to be there, i.e. the one that is
described in fb_info-&gt;var.

================================================================
general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901
Call Trace:
 display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929
 fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071
 resize_screen drivers/tty/vt/vt.c:1176 [inline]
 vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263
 fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720
 fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776
 do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128
 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203
 vfs_ioctl fs/ioctl.c:48 [inline]
 __do_sys_ioctl fs/ioctl.c:753 [inline]
 __se_sys_ioctl fs/ioctl.c:739 [inline]
 __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739
 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x67/0xd1
================================================================

Even though fbcon_init() checks beforehand if fb_match_mode() in
var_to_display() fails, it can not prevent the panic because fbcon_init()
does not return error code. Considering this and the comment in the code
about fb_match_mode() returning NULL - "This should not happen" - it is
better to prevent registering the fb_info if its mode was not set
successfully. Also move fb_add_videomode() closer to the beginning of
do_register_framebuffer() to avoid having to do the cleanup on fail.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.</Note>
    </Notes>
    <CVE>CVE-2025-38215</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hwmon: (ftsteutates) Fix TOCTOU race in fts_read()

In the fts_read() function, when handling hwmon_pwm_auto_channels_temp,
the code accesses the shared variable data-&gt;fan_source[channel] twice
without holding any locks. It is first checked against
FTS_FAN_SOURCE_INVALID, and if the check passes, it is read again
when used as an argument to the BIT() macro.

This creates a Time-of-Check to Time-of-Use (TOCTOU) race condition.
Another thread executing fts_update_device() can modify the value of
data-&gt;fan_source[channel] between the check and its use. If the value
is changed to FTS_FAN_SOURCE_INVALID (0xff) during this window, the
BIT() macro will be called with a large shift value (BIT(255)).
A bit shift by a value greater than or equal to the type width is
undefined behavior and can lead to a crash or incorrect values being
returned to userspace.

Fix this by reading data-&gt;fan_source[channel] into a local variable
once, eliminating the race condition. Additionally, add a bounds check
to ensure the value is less than BITS_PER_LONG before passing it to
the BIT() macro, making the code more robust against undefined behavior.

This possible bug was found by an experimental static analysis tool
developed by our team.</Note>
    </Notes>
    <CVE>CVE-2025-38217</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ext4: only dirty folios when data journaling regular files

fstest generic/388 occasionally reproduces a crash that looks as
follows:

BUG: kernel NULL pointer dereference, address: 0000000000000000
...
Call Trace:
 &lt;TASK&gt;
 ext4_block_zero_page_range+0x30c/0x380 [ext4]
 ext4_truncate+0x436/0x440 [ext4]
 ext4_process_orphan+0x5d/0x110 [ext4]
 ext4_orphan_cleanup+0x124/0x4f0 [ext4]
 ext4_fill_super+0x262d/0x3110 [ext4]
 get_tree_bdev_flags+0x132/0x1d0
 vfs_get_tree+0x26/0xd0
 vfs_cmd_create+0x59/0xe0
 __do_sys_fsconfig+0x4ed/0x6b0
 do_syscall_64+0x82/0x170
 ...

This occurs when processing a symlink inode from the orphan list. The
partial block zeroing code in the truncate path calls
ext4_dirty_journalled_data() -&gt; folio_mark_dirty(). The latter calls
mapping-&gt;a_ops-&gt;dirty_folio(), but symlink inodes are not assigned an
a_ops vector in ext4, hence the crash.

To avoid this problem, update the ext4_dirty_journalled_data() helper to
only mark the folio dirty on regular files (for which a_ops is
assigned). This also matches the journaling logic in the ext4_symlink()
creation path, where ext4_handle_dirty_metadata() is called directly.</Note>
    </Notes>
    <CVE>CVE-2025-38220</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ext4: inline: fix len overflow in ext4_prepare_inline_data

When running the following code on an ext4 filesystem with inline_data
feature enabled, it will lead to the bug below.

        fd = open("file1", O_RDWR | O_CREAT | O_TRUNC, 0666);
        ftruncate(fd, 30);
        pwrite(fd, "a", 1, (1UL &lt;&lt; 40) + 5UL);

That happens because write_begin will succeed as when
ext4_generic_write_inline_data calls ext4_prepare_inline_data, pos + len
will be truncated, leading to ext4_prepare_inline_data parameter to be 6
instead of 0x10000000006.

Then, later when write_end is called, we hit:

        BUG_ON(pos + len &gt; EXT4_I(inode)-&gt;i_inline_size);

at ext4_write_inline_data.

Fix it by using a loff_t type for the len parameter in
ext4_prepare_inline_data instead of an unsigned int.

[   44.545164] ------------[ cut here ]------------
[   44.545530] kernel BUG at fs/ext4/inline.c:240!
[   44.545834] Oops: invalid opcode: 0000 [#1] SMP NOPTI
[   44.546172] CPU: 3 UID: 0 PID: 343 Comm: test Not tainted 6.15.0-rc2-00003-g9080916f4863 #45 PREEMPT(full)  112853fcebfdb93254270a7959841d2c6aa2c8bb
[   44.546523] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[   44.546523] RIP: 0010:ext4_write_inline_data+0xfe/0x100
[   44.546523] Code: 3c 0e 48 83 c7 48 48 89 de 5b 41 5c 41 5d 41 5e 41 5f 5d e9 e4 fa 43 01 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc 0f 0b &lt;0f&gt; 0b 0f 1f 44 00 00 55 41 57 41 56 41 55 41 54 53 48 83 ec 20 49
[   44.546523] RSP: 0018:ffffb342008b79a8 EFLAGS: 00010216
[   44.546523] RAX: 0000000000000001 RBX: ffff9329c579c000 RCX: 0000010000000006
[   44.546523] RDX: 000000000000003c RSI: ffffb342008b79f0 RDI: ffff9329c158e738
[   44.546523] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000
[   44.546523] R10: 00007ffffffff000 R11: ffffffff9bd0d910 R12: 0000006210000000
[   44.546523] R13: fffffc7e4015e700 R14: 0000010000000005 R15: ffff9329c158e738
[   44.546523] FS:  00007f4299934740(0000) GS:ffff932a60179000(0000) knlGS:0000000000000000
[   44.546523] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   44.546523] CR2: 00007f4299a1ec90 CR3: 0000000002886002 CR4: 0000000000770eb0
[   44.546523] PKRU: 55555554
[   44.546523] Call Trace:
[   44.546523]  &lt;TASK&gt;
[   44.546523]  ext4_write_inline_data_end+0x126/0x2d0
[   44.546523]  generic_perform_write+0x17e/0x270
[   44.546523]  ext4_buffered_write_iter+0xc8/0x170
[   44.546523]  vfs_write+0x2be/0x3e0
[   44.546523]  __x64_sys_pwrite64+0x6d/0xc0
[   44.546523]  do_syscall_64+0x6a/0xf0
[   44.546523]  ? __wake_up+0x89/0xb0
[   44.546523]  ? xas_find+0x72/0x1c0
[   44.546523]  ? next_uptodate_folio+0x317/0x330
[   44.546523]  ? set_pte_range+0x1a6/0x270
[   44.546523]  ? filemap_map_pages+0x6ee/0x840
[   44.546523]  ? ext4_setattr+0x2fa/0x750
[   44.546523]  ? do_pte_missing+0x128/0xf70
[   44.546523]  ? security_inode_post_setattr+0x3e/0xd0
[   44.546523]  ? ___pte_offset_map+0x19/0x100
[   44.546523]  ? handle_mm_fault+0x721/0xa10
[   44.546523]  ? do_user_addr_fault+0x197/0x730
[   44.546523]  ? do_syscall_64+0x76/0xf0
[   44.546523]  ? arch_exit_to_user_mode_prepare+0x1e/0x60
[   44.546523]  ? irqentry_exit_to_user_mode+0x79/0x90
[   44.546523]  entry_SYSCALL_64_after_hwframe+0x55/0x5d
[   44.546523] RIP: 0033:0x7f42999c6687
[   44.546523] Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 &lt;5b&gt; c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff
[   44.546523] RSP: 002b:00007ffeae4a7930 EFLAGS: 00000202 ORIG_RAX: 0000000000000012
[   44.546523] RAX: ffffffffffffffda RBX: 00007f4299934740 RCX: 00007f42999c6687
[   44.546523] RDX: 0000000000000001 RSI: 000055ea6149200f RDI: 0000000000000003
[   44.546523] RBP: 00007ffeae4a79a0 R08: 0000000000000000 R09: 0000000000000000
[   44.546523] R10: 0000010000000005 R11: 0000000000000202 R12: 0000
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-38222</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: imx-jpeg: Cleanup after an allocation error

When allocation failures are not cleaned up by the driver, further
allocation errors will be false-positives, which will cause buffers to
remain uninitialized and cause NULL pointer dereferences.
Ensure proper cleanup of failed allocations to prevent these issues.</Note>
    </Notes>
    <CVE>CVE-2025-38225</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: vivid: Change the siize of the composing

syzkaller found a bug:

BUG: KASAN: vmalloc-out-of-bounds in tpg_fill_plane_pattern drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2608 [inline]
BUG: KASAN: vmalloc-out-of-bounds in tpg_fill_plane_buffer+0x1a9c/0x5af0 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2705
Write of size 1440 at addr ffffc9000d0ffda0 by task vivid-000-vid-c/5304

CPU: 0 UID: 0 PID: 5304 Comm: vivid-000-vid-c Not tainted 6.14.0-rc2-syzkaller-00039-g09fbf3d50205 #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014

Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:378 [inline]
 print_report+0x169/0x550 mm/kasan/report.c:489
 kasan_report+0x143/0x180 mm/kasan/report.c:602
 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189
 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106
 tpg_fill_plane_pattern drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2608 [inline]
 tpg_fill_plane_buffer+0x1a9c/0x5af0 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2705
 vivid_fillbuff drivers/media/test-drivers/vivid/vivid-kthread-cap.c:470 [inline]
 vivid_thread_vid_cap_tick+0xf8e/0x60d0 drivers/media/test-drivers/vivid/vivid-kthread-cap.c:629
 vivid_thread_vid_cap+0x8aa/0xf30 drivers/media/test-drivers/vivid/vivid-kthread-cap.c:767
 kthread+0x7a9/0x920 kernel/kthread.c:464
 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:148
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
 &lt;/TASK&gt;

The composition size cannot be larger than the size of fmt_cap_rect.
So execute v4l2_rect_map_inside() even if has_compose_cap == 0.</Note>
    </Notes>
    <CVE>CVE-2025-38226</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: vidtv: Terminating the subsequent process of initialization failure

syzbot reported a slab-use-after-free Read in vidtv_mux_init. [1]

After PSI initialization fails, the si member is accessed again, resulting
in this uaf.

After si initialization fails, the subsequent process needs to be exited.

[1]
BUG: KASAN: slab-use-after-free in vidtv_mux_pid_ctx_init drivers/media/test-drivers/vidtv/vidtv_mux.c:78 [inline]
BUG: KASAN: slab-use-after-free in vidtv_mux_init+0xac2/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:524
Read of size 8 at addr ffff88802fa42acc by task syz.2.37/6059

CPU: 0 UID: 0 PID: 6059 Comm: syz.2.37 Not tainted 6.14.0-rc5-syzkaller #0
Hardware name: Google Compute Engine, BIOS Google 02/12/2025
Call Trace:
&lt;TASK&gt;
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:408 [inline]
print_report+0xc3/0x670 mm/kasan/report.c:521
kasan_report+0xd9/0x110 mm/kasan/report.c:634
vidtv_mux_pid_ctx_init drivers/media/test-drivers/vidtv/vidtv_mux.c:78
vidtv_mux_init+0xac2/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:524
vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194
vidtv_start_feed drivers/media/test-drivers/vidtv/vidtv_bridge.c:239
dmx_section_feed_start_filtering drivers/media/dvb-core/dvb_demux.c:973
dvb_dmxdev_feed_start drivers/media/dvb-core/dmxdev.c:508 [inline]
dvb_dmxdev_feed_restart.isra.0 drivers/media/dvb-core/dmxdev.c:537
dvb_dmxdev_filter_stop+0x2b4/0x3a0 drivers/media/dvb-core/dmxdev.c:564
dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline]
dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246
__fput+0x3ff/0xb70 fs/file_table.c:464
task_work_run+0x14e/0x250 kernel/task_work.c:227
exit_task_work include/linux/task_work.h:40 [inline]
do_exit+0xad8/0x2d70 kernel/exit.c:938
do_group_exit+0xd3/0x2a0 kernel/exit.c:1087
__do_sys_exit_group kernel/exit.c:1098 [inline]
__se_sys_exit_group kernel/exit.c:1096 [inline]
__x64_sys_exit_group+0x3e/0x50 kernel/exit.c:1096
x64_sys_call+0x151f/0x1720 arch/x86/include/generated/asm/syscalls_64.h:232
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f871d58d169
Code: Unable to access opcode bytes at 0x7f871d58d13f.
RSP: 002b:00007fff4b19a788 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f871d58d169
RDX: 0000000000000064 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 00007fff4b19a7ec R08: 0000000b4b19a87f R09: 00000000000927c0
R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000003
R13: 00000000000927c0 R14: 000000000001d553 R15: 00007fff4b19a840
 &lt;/TASK&gt;

Allocated by task 6059:
 kasan_save_stack+0x33/0x60 mm/kasan/common.c:47
 kasan_save_track+0x14/0x30 mm/kasan/common.c:68
 poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
 __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394
 kmalloc_noprof include/linux/slab.h:901 [inline]
 kzalloc_noprof include/linux/slab.h:1037 [inline]
 vidtv_psi_pat_table_init drivers/media/test-drivers/vidtv/vidtv_psi.c:970
 vidtv_channel_si_init drivers/media/test-drivers/vidtv/vidtv_channel.c:423
 vidtv_mux_init drivers/media/test-drivers/vidtv/vidtv_mux.c:519
 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194
 vidtv_start_feed drivers/media/test-drivers/vidtv/vidtv_bridge.c:239
 dmx_section_feed_start_filtering drivers/media/dvb-core/dvb_demux.c:973
 dvb_dmxdev_feed_start drivers/media/dvb-core/dmxdev.c:508 [inline]
 dvb_dmxdev_feed_restart.isra.0 drivers/media/dvb-core/dmxdev.c:537
 dvb_dmxdev_filter_stop+0x2b4/0x3a0 drivers/media/dvb-core/dmxdev.c:564
 dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline]
 dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246
 __fput+0x3ff/0xb70 fs/file_tabl
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-38227</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: cxusb: no longer judge rbuf when the write fails

syzbot reported a uninit-value in cxusb_i2c_xfer. [1]

Only when the write operation of usb_bulk_msg() in dvb_usb_generic_rw()
succeeds and rlen is greater than 0, the read operation of usb_bulk_msg()
will be executed to read rlen bytes of data from the dvb device into the
rbuf.

In this case, although rlen is 1, the write operation failed which resulted
in the dvb read operation not being executed, and ultimately variable i was
not initialized.

[1]
BUG: KMSAN: uninit-value in cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline]
BUG: KMSAN: uninit-value in cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196
 cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline]
 cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196
 __i2c_transfer+0xe25/0x3150 drivers/i2c/i2c-core-base.c:-1
 i2c_transfer+0x317/0x4a0 drivers/i2c/i2c-core-base.c:2315
 i2c_transfer_buffer_flags+0x125/0x1e0 drivers/i2c/i2c-core-base.c:2343
 i2c_master_send include/linux/i2c.h:109 [inline]
 i2cdev_write+0x210/0x280 drivers/i2c/i2c-dev.c:183
 do_loop_readv_writev fs/read_write.c:848 [inline]
 vfs_writev+0x963/0x14e0 fs/read_write.c:1057
 do_writev+0x247/0x5c0 fs/read_write.c:1101
 __do_sys_writev fs/read_write.c:1169 [inline]
 __se_sys_writev fs/read_write.c:1166 [inline]
 __x64_sys_writev+0x98/0xe0 fs/read_write.c:1166
 x64_sys_call+0x2229/0x3c80 arch/x86/include/generated/asm/syscalls_64.h:21
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xcd/0x1e0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f</Note>
    </Notes>
    <CVE>CVE-2025-38229</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nfsd: Initialize ssc before laundromat_work to prevent NULL dereference

In nfs4_state_start_net(), laundromat_work may access nfsd_ssc through
nfs4_laundromat -&gt; nfsd4_ssc_expire_umount. If nfsd_ssc isn't initialized,
this can cause NULL pointer dereference.

Normally the delayed start of laundromat_work allows sufficient time for
nfsd_ssc initialization to complete. However, when the kernel waits too
long for userspace responses (e.g. in nfs4_state_start_net -&gt;
nfsd4_end_grace -&gt; nfsd4_record_grace_done -&gt; nfsd4_cld_grace_done -&gt;
cld_pipe_upcall -&gt; __cld_pipe_upcall -&gt; wait_for_completion path), the
delayed work may start before nfsd_ssc initialization finishes.

Fix this by moving nfsd_ssc initialization before starting laundromat_work.</Note>
    </Notes>
    <CVE>CVE-2025-38231</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

af_unix: Don't leave consecutive consumed OOB skbs.

Jann Horn reported a use-after-free in unix_stream_read_generic().

The following sequences reproduce the issue:

  $ python3
  from socket import *
  s1, s2 = socketpair(AF_UNIX, SOCK_STREAM)
  s1.send(b'x', MSG_OOB)
  s2.recv(1, MSG_OOB)     # leave a consumed OOB skb
  s1.send(b'y', MSG_OOB)
  s2.recv(1, MSG_OOB)     # leave a consumed OOB skb
  s1.send(b'z', MSG_OOB)
  s2.recv(1)              # recv 'z' illegally
  s2.recv(1, MSG_OOB)     # access 'z' skb (use-after-free)

Even though a user reads OOB data, the skb holding the data stays on
the recv queue to mark the OOB boundary and break the next recv().

After the last send() in the scenario above, the sk2's recv queue has
2 leading consumed OOB skbs and 1 real OOB skb.

Then, the following happens during the next recv() without MSG_OOB

  1. unix_stream_read_generic() peeks the first consumed OOB skb
  2. manage_oob() returns the next consumed OOB skb
  3. unix_stream_read_generic() fetches the next not-yet-consumed OOB skb
  4. unix_stream_read_generic() reads and frees the OOB skb

, and the last recv(MSG_OOB) triggers KASAN splat.

The 3. above occurs because of the SO_PEEK_OFF code, which does not
expect unix_skb_len(skb) to be 0, but this is true for such consumed
OOB skbs.

  while (skip &gt;= unix_skb_len(skb)) {
    skip -= unix_skb_len(skb);
    skb = skb_peek_next(skb, &amp;sk-&gt;sk_receive_queue);
    ...
  }

In addition to this use-after-free, there is another issue that
ioctl(SIOCATMARK) does not function properly with consecutive consumed
OOB skbs.

So, nothing good comes out of such a situation.

Instead of complicating manage_oob(), ioctl() handling, and the next
ECONNRESET fix by introducing a loop for consecutive consumed OOB skbs,
let's not leave such consecutive OOB unnecessarily.

Now, while receiving an OOB skb in unix_stream_recv_urg(), if its
previous skb is a consumed OOB skb, it is freed.

[0]:
BUG: KASAN: slab-use-after-free in unix_stream_read_actor (net/unix/af_unix.c:3027)
Read of size 4 at addr ffff888106ef2904 by task python3/315

CPU: 2 UID: 0 PID: 315 Comm: python3 Not tainted 6.16.0-rc1-00407-gec315832f6f9 #8 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.fc42 04/01/2014
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl (lib/dump_stack.c:122)
 print_report (mm/kasan/report.c:409 mm/kasan/report.c:521)
 kasan_report (mm/kasan/report.c:636)
 unix_stream_read_actor (net/unix/af_unix.c:3027)
 unix_stream_read_generic (net/unix/af_unix.c:2708 net/unix/af_unix.c:2847)
 unix_stream_recvmsg (net/unix/af_unix.c:3048)
 sock_recvmsg (net/socket.c:1063 (discriminator 20) net/socket.c:1085 (discriminator 20))
 __sys_recvfrom (net/socket.c:2278)
 __x64_sys_recvfrom (net/socket.c:2291 (discriminator 1) net/socket.c:2287 (discriminator 1) net/socket.c:2287 (discriminator 1))
 do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))
 entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
RIP: 0033:0x7f8911fcea06
Code: 5d e8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 75 19 83 e2 39 83 fa 08 75 11 e8 26 ff ff ff 66 0f 1f 44 00 00 48 8b 45 10 0f 05 &lt;48&gt; 8b 5d f8 c9 c3 0f 1f 40 00 f3 0f 1e fa 55 48 89 e5 48 83 ec 08
RSP: 002b:00007fffdb0dccb0 EFLAGS: 00000202 ORIG_RAX: 000000000000002d
RAX: ffffffffffffffda RBX: 00007fffdb0dcdc8 RCX: 00007f8911fcea06
RDX: 0000000000000001 RSI: 00007f8911a5e060 RDI: 0000000000000006
RBP: 00007fffdb0dccd0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000202 R12: 00007f89119a7d20
R13: ffffffffc4653600 R14: 0000000000000000 R15: 0000000000000000
 &lt;/TASK&gt;

Allocated by task 315:
 kasan_save_stack (mm/kasan/common.c:48)
 kasan_save_track (mm/kasan/common.c:60 (discriminator 1) mm/kasan/common.c:69 (discriminator 1))
 __kasan_slab_alloc (mm/kasan/common.c:348)
 kmem_cache_alloc_
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-38236</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: fnic: Fix crash in fnic_wq_cmpl_handler when FDMI times out

When both the RHBA and RPA FDMI requests time out, fnic reuses a frame to
send ABTS for each of them. On send completion, this causes an attempt to
free the same frame twice that leads to a crash.

Fix crash by allocating separate frames for RHBA and RPA, and modify ABTS
logic accordingly.

Tested by checking MDS for FDMI information.

Tested by using instrumented driver to:

 - Drop PLOGI response
 - Drop RHBA response
 - Drop RPA response
 - Drop RHBA and RPA response
 - Drop PLOGI response + ABTS response
 - Drop RHBA response + ABTS response
 - Drop RPA response + ABTS response
 - Drop RHBA and RPA response + ABTS response for both of them</Note>
    </Notes>
    <CVE>CVE-2025-38238</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: megaraid_sas: Fix invalid node index

On a system with DRAM interleave enabled, out-of-bound access is
detected:

megaraid_sas 0000:3f:00.0: requested/available msix 128/128 poll_queue 0
------------[ cut here ]------------
UBSAN: array-index-out-of-bounds in ./arch/x86/include/asm/topology.h:72:28
index -1 is out of range for type 'cpumask *[1024]'
dump_stack_lvl+0x5d/0x80
ubsan_epilogue+0x5/0x2b
__ubsan_handle_out_of_bounds.cold+0x46/0x4b
megasas_alloc_irq_vectors+0x149/0x190 [megaraid_sas]
megasas_probe_one.cold+0xa4d/0x189c [megaraid_sas]
local_pci_probe+0x42/0x90
pci_device_probe+0xdc/0x290
really_probe+0xdb/0x340
__driver_probe_device+0x78/0x110
driver_probe_device+0x1f/0xa0
__driver_attach+0xba/0x1c0
bus_for_each_dev+0x8b/0xe0
bus_add_driver+0x142/0x220
driver_register+0x72/0xd0
megasas_init+0xdf/0xff0 [megaraid_sas]
do_one_initcall+0x57/0x310
do_init_module+0x90/0x250
init_module_from_file+0x85/0xc0
idempotent_init_module+0x114/0x310
__x64_sys_finit_module+0x65/0xc0
do_syscall_64+0x82/0x170
entry_SYSCALL_64_after_hwframe+0x76/0x7e

Fix it accordingly.</Note>
    </Notes>
    <CVE>CVE-2025-38239</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/mediatek: dp: drm_err =&gt; dev_err in HPD path to avoid NULL ptr

The function mtk_dp_wait_hpd_asserted() may be called before the
`mtk_dp-&gt;drm_dev` pointer is assigned in mtk_dp_bridge_attach().
Specifically it can be called via this callpath:
 - mtk_edp_wait_hpd_asserted
 - [panel probe]
 - dp_aux_ep_probe

Using "drm" level prints anywhere in this callpath causes a NULL
pointer dereference. Change the error message directly in
mtk_dp_wait_hpd_asserted() to dev_err() to avoid this. Also change the
error messages in mtk_dp_parse_capabilities(), which is called by
mtk_dp_wait_hpd_asserted().

While touching these prints, also add the error code to them to make
future debugging easier.</Note>
    </Notes>
    <CVE>CVE-2025-38240</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

smb: client: fix potential deadlock when reconnecting channels

Fix cifs_signal_cifsd_for_reconnect() to take the correct lock order
and prevent the following deadlock from happening

======================================================
WARNING: possible circular locking dependency detected
6.16.0-rc3-build2+ #1301 Tainted: G S      W
------------------------------------------------------
cifsd/6055 is trying to acquire lock:
ffff88810ad56038 (&amp;tcp_ses-&gt;srv_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x134/0x200

but task is already holding lock:
ffff888119c64330 (&amp;ret_buf-&gt;chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-&gt; #2 (&amp;ret_buf-&gt;chan_lock){+.+.}-{3:3}:
       validate_chain+0x1cf/0x270
       __lock_acquire+0x60e/0x780
       lock_acquire.part.0+0xb4/0x1f0
       _raw_spin_lock+0x2f/0x40
       cifs_setup_session+0x81/0x4b0
       cifs_get_smb_ses+0x771/0x900
       cifs_mount_get_session+0x7e/0x170
       cifs_mount+0x92/0x2d0
       cifs_smb3_do_mount+0x161/0x460
       smb3_get_tree+0x55/0x90
       vfs_get_tree+0x46/0x180
       do_new_mount+0x1b0/0x2e0
       path_mount+0x6ee/0x740
       do_mount+0x98/0xe0
       __do_sys_mount+0x148/0x180
       do_syscall_64+0xa4/0x260
       entry_SYSCALL_64_after_hwframe+0x76/0x7e

-&gt; #1 (&amp;ret_buf-&gt;ses_lock){+.+.}-{3:3}:
       validate_chain+0x1cf/0x270
       __lock_acquire+0x60e/0x780
       lock_acquire.part.0+0xb4/0x1f0
       _raw_spin_lock+0x2f/0x40
       cifs_match_super+0x101/0x320
       sget+0xab/0x270
       cifs_smb3_do_mount+0x1e0/0x460
       smb3_get_tree+0x55/0x90
       vfs_get_tree+0x46/0x180
       do_new_mount+0x1b0/0x2e0
       path_mount+0x6ee/0x740
       do_mount+0x98/0xe0
       __do_sys_mount+0x148/0x180
       do_syscall_64+0xa4/0x260
       entry_SYSCALL_64_after_hwframe+0x76/0x7e

-&gt; #0 (&amp;tcp_ses-&gt;srv_lock){+.+.}-{3:3}:
       check_noncircular+0x95/0xc0
       check_prev_add+0x115/0x2f0
       validate_chain+0x1cf/0x270
       __lock_acquire+0x60e/0x780
       lock_acquire.part.0+0xb4/0x1f0
       _raw_spin_lock+0x2f/0x40
       cifs_signal_cifsd_for_reconnect+0x134/0x200
       __cifs_reconnect+0x8f/0x500
       cifs_handle_standard+0x112/0x280
       cifs_demultiplex_thread+0x64d/0xbc0
       kthread+0x2f7/0x310
       ret_from_fork+0x2a/0x230
       ret_from_fork_asm+0x1a/0x30

other info that might help us debug this:

Chain exists of:
  &amp;tcp_ses-&gt;srv_lock --&gt; &amp;ret_buf-&gt;ses_lock --&gt; &amp;ret_buf-&gt;chan_lock

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&amp;ret_buf-&gt;chan_lock);
                               lock(&amp;ret_buf-&gt;ses_lock);
                               lock(&amp;ret_buf-&gt;chan_lock);
  lock(&amp;tcp_ses-&gt;srv_lock);

 *** DEADLOCK ***

3 locks held by cifsd/6055:
 #0: ffffffff857de398 (&amp;cifs_tcp_ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x7b/0x200
 #1: ffff888119c64060 (&amp;ret_buf-&gt;ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x9c/0x200
 #2: ffff888119c64330 (&amp;ret_buf-&gt;chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200</Note>
    </Notes>
    <CVE>CVE-2025-38244</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bnxt: properly flush XDP redirect lists

We encountered following crash when testing a XDP_REDIRECT feature
in production:

[56251.579676] list_add corruption. next-&gt;prev should be prev (ffff93120dd40f30), but was ffffb301ef3a6740. (next=ffff93120dd
40f30).
[56251.601413] ------------[ cut here ]------------
[56251.611357] kernel BUG at lib/list_debug.c:29!
[56251.621082] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
[56251.632073] CPU: 111 UID: 0 PID: 0 Comm: swapper/111 Kdump: loaded Tainted: P           O       6.12.33-cloudflare-2025.6.
3 #1
[56251.653155] Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE
[56251.663877] Hardware name: MiTAC GC68B-B8032-G11P6-GPU/S8032GM-HE-CFR, BIOS V7.020.B10-sig 01/22/2025
[56251.682626] RIP: 0010:__list_add_valid_or_report+0x4b/0xa0
[56251.693203] Code: 0e 48 c7 c7 68 e7 d9 97 e8 42 16 fe ff 0f 0b 48 8b 52 08 48 39 c2 74 14 48 89 f1 48 c7 c7 90 e7 d9 97 48
 89 c6 e8 25 16 fe ff &lt;0f&gt; 0b 4c 8b 02 49 39 f0 74 14 48 89 d1 48 c7 c7 e8 e7 d9 97 4c 89
[56251.725811] RSP: 0018:ffff93120dd40b80 EFLAGS: 00010246
[56251.736094] RAX: 0000000000000075 RBX: ffffb301e6bba9d8 RCX: 0000000000000000
[56251.748260] RDX: 0000000000000000 RSI: ffff9149afda0b80 RDI: ffff9149afda0b80
[56251.760349] RBP: ffff9131e49c8000 R08: 0000000000000000 R09: ffff93120dd40a18
[56251.772382] R10: ffff9159cf2ce1a8 R11: 0000000000000003 R12: ffff911a80850000
[56251.784364] R13: ffff93120fbc7000 R14: 0000000000000010 R15: ffff9139e7510e40
[56251.796278] FS:  0000000000000000(0000) GS:ffff9149afd80000(0000) knlGS:0000000000000000
[56251.809133] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[56251.819561] CR2: 00007f5e85e6f300 CR3: 00000038b85e2006 CR4: 0000000000770ef0
[56251.831365] PKRU: 55555554
[56251.838653] Call Trace:
[56251.845560]  &lt;IRQ&gt;
[56251.851943]  cpu_map_enqueue.cold+0x5/0xa
[56251.860243]  xdp_do_redirect+0x2d9/0x480
[56251.868388]  bnxt_rx_xdp+0x1d8/0x4c0 [bnxt_en]
[56251.877028]  bnxt_rx_pkt+0x5f7/0x19b0 [bnxt_en]
[56251.885665]  ? cpu_max_write+0x1e/0x100
[56251.893510]  ? srso_alias_return_thunk+0x5/0xfbef5
[56251.902276]  __bnxt_poll_work+0x190/0x340 [bnxt_en]
[56251.911058]  bnxt_poll+0xab/0x1b0 [bnxt_en]
[56251.919041]  ? srso_alias_return_thunk+0x5/0xfbef5
[56251.927568]  ? srso_alias_return_thunk+0x5/0xfbef5
[56251.935958]  ? srso_alias_return_thunk+0x5/0xfbef5
[56251.944250]  __napi_poll+0x2b/0x160
[56251.951155]  bpf_trampoline_6442548651+0x79/0x123
[56251.959262]  __napi_poll+0x5/0x160
[56251.966037]  net_rx_action+0x3d2/0x880
[56251.973133]  ? srso_alias_return_thunk+0x5/0xfbef5
[56251.981265]  ? srso_alias_return_thunk+0x5/0xfbef5
[56251.989262]  ? __hrtimer_run_queues+0x162/0x2a0
[56251.996967]  ? srso_alias_return_thunk+0x5/0xfbef5
[56252.004875]  ? srso_alias_return_thunk+0x5/0xfbef5
[56252.012673]  ? bnxt_msix+0x62/0x70 [bnxt_en]
[56252.019903]  handle_softirqs+0xcf/0x270
[56252.026650]  irq_exit_rcu+0x67/0x90
[56252.032933]  common_interrupt+0x85/0xa0
[56252.039498]  &lt;/IRQ&gt;
[56252.044246]  &lt;TASK&gt;
[56252.048935]  asm_common_interrupt+0x26/0x40
[56252.055727] RIP: 0010:cpuidle_enter_state+0xb8/0x420
[56252.063305] Code: dc 01 00 00 e8 f9 79 3b ff e8 64 f7 ff ff 49 89 c5 0f 1f 44 00 00 31 ff e8 a5 32 3a ff 45 84 ff 0f 85 ae
 01 00 00 fb 45 85 f6 &lt;0f&gt; 88 88 01 00 00 48 8b 04 24 49 63 ce 4c 89 ea 48 6b f1 68 48 29
[56252.088911] RSP: 0018:ffff93120c97fe98 EFLAGS: 00000202
[56252.096912] RAX: ffff9149afd80000 RBX: ffff9141d3a72800 RCX: 0000000000000000
[56252.106844] RDX: 00003329176c6b98 RSI: ffffffe36db3fdc7 RDI: 0000000000000000
[56252.116733] RBP: 0000000000000002 R08: 0000000000000002 R09: 000000000000004e
[56252.126652] R10: ffff9149afdb30c4 R11: 071c71c71c71c71c R12: ffffffff985ff860
[56252.136637] R13: 00003329176c6b98 R14: 0000000000000002 R15: 0000000000000000
[56252.146667]  ? cpuidle_enter_state+0xab/0x420
[56252.153909]  cpuidle_enter+0x2d/0x40
[56252.160360]  do_idle+0x176/0x1c0
[56252.166456
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-38246</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bridge: mcast: Fix use-after-free during router port configuration

The bridge maintains a global list of ports behind which a multicast
router resides. The list is consulted during forwarding to ensure
multicast packets are forwarded to these ports even if the ports are not
member in the matching MDB entry.

When per-VLAN multicast snooping is enabled, the per-port multicast
context is disabled on each port and the port is removed from the global
router port list:

 # ip link add name br1 up type bridge vlan_filtering 1 mcast_snooping 1
 # ip link add name dummy1 up master br1 type dummy
 # ip link set dev dummy1 type bridge_slave mcast_router 2
 $ bridge -d mdb show | grep router
 router ports on br1: dummy1
 # ip link set dev br1 type bridge mcast_vlan_snooping 1
 $ bridge -d mdb show | grep router

However, the port can be re-added to the global list even when per-VLAN
multicast snooping is enabled:

 # ip link set dev dummy1 type bridge_slave mcast_router 0
 # ip link set dev dummy1 type bridge_slave mcast_router 2
 $ bridge -d mdb show | grep router
 router ports on br1: dummy1

Since commit 4b30ae9adb04 ("net: bridge: mcast: re-implement
br_multicast_{enable, disable}_port functions"), when per-VLAN multicast
snooping is enabled, multicast disablement on a port will disable the
per-{port, VLAN} multicast contexts and not the per-port one. As a
result, a port will remain in the global router port list even after it
is deleted. This will lead to a use-after-free [1] when the list is
traversed (when adding a new port to the list, for example):

 # ip link del dev dummy1
 # ip link add name dummy2 up master br1 type dummy
 # ip link set dev dummy2 type bridge_slave mcast_router 2

Similarly, stale entries can also be found in the per-VLAN router port
list. When per-VLAN multicast snooping is disabled, the per-{port, VLAN}
contexts are disabled on each port and the port is removed from the
per-VLAN router port list:

 # ip link add name br1 up type bridge vlan_filtering 1 mcast_snooping 1 mcast_vlan_snooping 1
 # ip link add name dummy1 up master br1 type dummy
 # bridge vlan add vid 2 dev dummy1
 # bridge vlan global set vid 2 dev br1 mcast_snooping 1
 # bridge vlan set vid 2 dev dummy1 mcast_router 2
 $ bridge vlan global show dev br1 vid 2 | grep router
       router ports: dummy1
 # ip link set dev br1 type bridge mcast_vlan_snooping 0
 $ bridge vlan global show dev br1 vid 2 | grep router

However, the port can be re-added to the per-VLAN list even when
per-VLAN multicast snooping is disabled:

 # bridge vlan set vid 2 dev dummy1 mcast_router 0
 # bridge vlan set vid 2 dev dummy1 mcast_router 2
 $ bridge vlan global show dev br1 vid 2 | grep router
       router ports: dummy1

When the VLAN is deleted from the port, the per-{port, VLAN} multicast
context will not be disabled since multicast snooping is not enabled
on the VLAN. As a result, the port will remain in the per-VLAN router
port list even after it is no longer member in the VLAN. This will lead
to a use-after-free [2] when the list is traversed (when adding a new
port to the list, for example):

 # ip link add name dummy2 up master br1 type dummy
 # bridge vlan add vid 2 dev dummy2
 # bridge vlan del vid 2 dev dummy1
 # bridge vlan set vid 2 dev dummy2 mcast_router 2

Fix these issues by removing the port from the relevant (global or
per-VLAN) router port list in br_multicast_port_ctx_deinit(). The
function is invoked during port deletion with the per-port multicast
context and during VLAN deletion with the per-{port, VLAN} multicast
context.

Note that deleting the multicast router timer is not enough as it only
takes care of the temporary multicast router states (1 or 3) and not the
permanent one (2).

[1]
BUG: KASAN: slab-out-of-bounds in br_multicast_add_router.part.0+0x3f1/0x560
Write of size 8 at addr ffff888004a67328 by task ip/384
[...]
Call Trace:
 &lt;TASK&gt;
 dump_stack
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-38248</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ALSA: usb-audio: Fix out-of-bounds read in snd_usb_get_audioformat_uac3()

In snd_usb_get_audioformat_uac3(), the length value returned from
snd_usb_ctl_msg() is used directly for memory allocation without
validation. This length is controlled by the USB device.

The allocated buffer is cast to a uac3_cluster_header_descriptor
and its fields are accessed without verifying that the buffer
is large enough. If the device returns a smaller than expected
length, this leads to an out-of-bounds read.

Add a length check to ensure the buffer is large enough for
uac3_cluster_header_descriptor.</Note>
    </Notes>
    <CVE>CVE-2025-38249</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_core: Fix use-after-free in vhci_flush()

syzbot reported use-after-free in vhci_flush() without repro. [0]

From the splat, a thread close()d a vhci file descriptor while
its device was being used by iotcl() on another thread.

Once the last fd refcnt is released, vhci_release() calls
hci_unregister_dev(), hci_free_dev(), and kfree() for struct
vhci_data, which is set to hci_dev-&gt;dev-&gt;driver_data.

The problem is that there is no synchronisation after unlinking
hdev from hci_dev_list in hci_unregister_dev().  There might be
another thread still accessing the hdev which was fetched before
the unlink operation.

We can use SRCU for such synchronisation.

Let's run hci_dev_reset() under SRCU and wait for its completion
in hci_unregister_dev().

Another option would be to restore hci_dev-&gt;destruct(), which was
removed in commit 587ae086f6e4 ("Bluetooth: Remove unused
hci-destruct cb").  However, this would not be a good solution, as
we should not run hci_unregister_dev() while there are in-flight
ioctl() requests, which could lead to another data-race KCSAN splat.

Note that other drivers seem to have the same problem, for exmaple,
virtbt_remove().

[0]:
BUG: KASAN: slab-use-after-free in skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline]
BUG: KASAN: slab-use-after-free in skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937
Read of size 8 at addr ffff88807cb8d858 by task syz.1.219/6718

CPU: 1 UID: 0 PID: 6718 Comm: syz.1.219 Not tainted 6.16.0-rc1-syzkaller-00196-g08207f42d3ff #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:408 [inline]
 print_report+0xd2/0x2b0 mm/kasan/report.c:521
 kasan_report+0x118/0x150 mm/kasan/report.c:634
 skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline]
 skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937
 skb_queue_purge include/linux/skbuff.h:3368 [inline]
 vhci_flush+0x44/0x50 drivers/bluetooth/hci_vhci.c:69
 hci_dev_do_reset net/bluetooth/hci_core.c:552 [inline]
 hci_dev_reset+0x420/0x5c0 net/bluetooth/hci_core.c:592
 sock_do_ioctl+0xd9/0x300 net/socket.c:1190
 sock_ioctl+0x576/0x790 net/socket.c:1311
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:907 [inline]
 __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fcf5b98e929
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fcf5c7b9038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007fcf5bbb6160 RCX: 00007fcf5b98e929
RDX: 0000000000000000 RSI: 00000000400448cb RDI: 0000000000000009
RBP: 00007fcf5ba10b39 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 00007fcf5bbb6160 R15: 00007ffd6353d528
 &lt;/TASK&gt;

Allocated by task 6535:
 kasan_save_stack mm/kasan/common.c:47 [inline]
 kasan_save_track+0x3e/0x80 mm/kasan/common.c:68
 poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
 __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394
 kasan_kmalloc include/linux/kasan.h:260 [inline]
 __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359
 kmalloc_noprof include/linux/slab.h:905 [inline]
 kzalloc_noprof include/linux/slab.h:1039 [inline]
 vhci_open+0x57/0x360 drivers/bluetooth/hci_vhci.c:635
 misc_open+0x2bc/0x330 drivers/char/misc.c:161
 chrdev_open+0x4c9/0x5e0 fs/char_dev.c:414
 do_dentry_open+0xdf0/0x1970 fs/open.c:964
 vfs_open+0x3b/0x340 fs/open.c:1094
 do_open fs/namei.c:3887 [inline]
 path_openat+0x2ee5/0x3830 fs/name
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-38250</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

io_uring/rsrc: fix folio unpinning

syzbot complains about an unmapping failure:

[  108.070381][   T14] kernel BUG at mm/gup.c:71!
[  108.070502][   T14] Internal error: Oops - BUG: 00000000f2000800 [#1]  SMP
[  108.123672][   T14] Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20250221-8.fc42 02/21/2025
[  108.127458][   T14] Workqueue: iou_exit io_ring_exit_work
[  108.174205][   T14] Call trace:
[  108.175649][   T14]  sanity_check_pinned_pages+0x7cc/0x7d0 (P)
[  108.178138][   T14]  unpin_user_page+0x80/0x10c
[  108.180189][   T14]  io_release_ubuf+0x84/0xf8
[  108.182196][   T14]  io_free_rsrc_node+0x250/0x57c
[  108.184345][   T14]  io_rsrc_data_free+0x148/0x298
[  108.186493][   T14]  io_sqe_buffers_unregister+0x84/0xa0
[  108.188991][   T14]  io_ring_ctx_free+0x48/0x480
[  108.191057][   T14]  io_ring_exit_work+0x764/0x7d8
[  108.193207][   T14]  process_one_work+0x7e8/0x155c
[  108.195431][   T14]  worker_thread+0x958/0xed8
[  108.197561][   T14]  kthread+0x5fc/0x75c
[  108.199362][   T14]  ret_from_fork+0x10/0x20

We can pin a tail page of a folio, but then io_uring will try to unpin
the head page of the folio. While it should be fine in terms of keeping
the page actually alive, mm folks say it's wrong and triggers a debug
warning. Use unpin_user_folio() instead of unpin_user_page*.

[axboe: adapt to current tree, massage commit message]</Note>
    </Notes>
    <CVE>CVE-2025-38256</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

s390/pkey: Prevent overflow in size calculation for memdup_user()

Number of apqn target list entries contained in 'nr_apqns' variable is
determined by userspace via an ioctl call so the result of the product in
calculation of size passed to memdup_user() may overflow.

In this case the actual size of the allocated area and the value
describing it won't be in sync leading to various types of unpredictable
behaviour later.

Use a proper memdup_array_user() helper which returns an error if an
overflow is detected. Note that it is different from when nr_apqns is
initially zero - that case is considered valid and should be handled in
subsequent pkey_handler implementations.

Found by Linux Verification Center (linuxtesting.org).</Note>
    </Notes>
    <CVE>CVE-2025-38257</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ASoC: codecs: wcd9335: Fix missing free of regulator supplies

Driver gets and enables all regulator supplies in probe path
(wcd9335_parse_dt() and wcd9335_power_on_reset()), but does not cleanup
in final error paths and in unbind (missing remove() callback).  This
leads to leaked memory and unbalanced regulator enable count during
probe errors or unbind.

Fix this by converting entire code into devm_regulator_bulk_get_enable()
which also greatly simplifies the code.</Note>
    </Notes>
    <CVE>CVE-2025-38259</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nvme-tcp: sanitize request list handling

Validate the request in nvme_tcp_handle_r2t() to ensure it's not part of
any list, otherwise a malicious R2T PDU might inject a loop in request
list processing.</Note>
    </Notes>
    <CVE>CVE-2025-38264</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

serial: jsm: fix NPE during jsm_uart_port_init

No device was set which caused serial_base_ctrl_add to crash.

 BUG: kernel NULL pointer dereference, address: 0000000000000050
 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI
 CPU: 16 UID: 0 PID: 368 Comm: (udev-worker) Not tainted 6.12.25-amd64 #1  Debian 6.12.25-1
 RIP: 0010:serial_base_ctrl_add+0x96/0x120
 Call Trace:
  &lt;TASK&gt;
  serial_core_register_port+0x1a0/0x580
  ? __setup_irq+0x39c/0x660
  ? __kmalloc_cache_noprof+0x111/0x310
  jsm_uart_port_init+0xe8/0x180 [jsm]
  jsm_probe_one+0x1f4/0x410 [jsm]
  local_pci_probe+0x42/0x90
  pci_device_probe+0x22f/0x270
  really_probe+0xdb/0x340
  ? pm_runtime_barrier+0x54/0x90
  ? __pfx___driver_attach+0x10/0x10
  __driver_probe_device+0x78/0x110
  driver_probe_device+0x1f/0xa0
  __driver_attach+0xba/0x1c0
  bus_for_each_dev+0x8c/0xe0
  bus_add_driver+0x112/0x1f0
  driver_register+0x72/0xd0
  jsm_init_module+0x36/0xff0 [jsm]
  ? __pfx_jsm_init_module+0x10/0x10 [jsm]
  do_one_initcall+0x58/0x310
  do_init_module+0x60/0x230

Tested with Digi Neo PCIe 8 port card.</Note>
    </Notes>
    <CVE>CVE-2025-38265</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: typec: tcpm: move tcpm_queue_vdm_unlocked to asynchronous work

A state check was previously added to tcpm_queue_vdm_unlocked to
prevent a deadlock where the DisplayPort Alt Mode driver would be
executing work and attempting to grab the tcpm_lock while the TCPM
was holding the lock and attempting to unregister the altmode, blocking
on the altmode driver's cancel_work_sync call.

Because the state check isn't protected, there is a small window
where the Alt Mode driver could determine that the TCPM is
in a ready state and attempt to grab the lock while the
TCPM grabs the lock and changes the TCPM state to one that
causes the deadlock. The callstack is provided below:

[110121.667392][    C7] Call trace:
[110121.667396][    C7]  __switch_to+0x174/0x338
[110121.667406][    C7]  __schedule+0x608/0x9f0
[110121.667414][    C7]  schedule+0x7c/0xe8
[110121.667423][    C7]  kernfs_drain+0xb0/0x114
[110121.667431][    C7]  __kernfs_remove+0x16c/0x20c
[110121.667436][    C7]  kernfs_remove_by_name_ns+0x74/0xe8
[110121.667442][    C7]  sysfs_remove_group+0x84/0xe8
[110121.667450][    C7]  sysfs_remove_groups+0x34/0x58
[110121.667458][    C7]  device_remove_groups+0x10/0x20
[110121.667464][    C7]  device_release_driver_internal+0x164/0x2e4
[110121.667475][    C7]  device_release_driver+0x18/0x28
[110121.667484][    C7]  bus_remove_device+0xec/0x118
[110121.667491][    C7]  device_del+0x1e8/0x4ac
[110121.667498][    C7]  device_unregister+0x18/0x38
[110121.667504][    C7]  typec_unregister_altmode+0x30/0x44
[110121.667515][    C7]  tcpm_reset_port+0xac/0x370
[110121.667523][    C7]  tcpm_snk_detach+0x84/0xb8
[110121.667529][    C7]  run_state_machine+0x4c0/0x1b68
[110121.667536][    C7]  tcpm_state_machine_work+0x94/0xe4
[110121.667544][    C7]  kthread_worker_fn+0x10c/0x244
[110121.667552][    C7]  kthread+0x104/0x1d4
[110121.667557][    C7]  ret_from_fork+0x10/0x20

[110121.667689][    C7] Workqueue: events dp_altmode_work
[110121.667697][    C7] Call trace:
[110121.667701][    C7]  __switch_to+0x174/0x338
[110121.667710][    C7]  __schedule+0x608/0x9f0
[110121.667717][    C7]  schedule+0x7c/0xe8
[110121.667725][    C7]  schedule_preempt_disabled+0x24/0x40
[110121.667733][    C7]  __mutex_lock+0x408/0xdac
[110121.667741][    C7]  __mutex_lock_slowpath+0x14/0x24
[110121.667748][    C7]  mutex_lock+0x40/0xec
[110121.667757][    C7]  tcpm_altmode_enter+0x78/0xb4
[110121.667764][    C7]  typec_altmode_enter+0xdc/0x10c
[110121.667769][    C7]  dp_altmode_work+0x68/0x164
[110121.667775][    C7]  process_one_work+0x1e4/0x43c
[110121.667783][    C7]  worker_thread+0x25c/0x430
[110121.667789][    C7]  kthread+0x104/0x1d4
[110121.667794][    C7]  ret_from_fork+0x10/0x20

Change tcpm_queue_vdm_unlocked to queue for tcpm_queue_vdm_work,
which can perform the state check while holding the TCPM lock
while the Alt Mode lock is no longer held. This requires a new
struct to hold the vdm data, altmode_vdm_event.</Note>
    </Notes>
    <CVE>CVE-2025-38268</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: dsa: b53: do not enable EEE on bcm63xx

BCM63xx internal switches do not support EEE, but provide multiple RGMII
ports where external PHYs may be connected. If one of these PHYs are EEE
capable, we may try to enable EEE for the MACs, which then hangs the
system on access of the (non-existent) EEE registers.

Fix this by checking if the switch actually supports EEE before
attempting to configure it.</Note>
    </Notes>
    <CVE>CVE-2025-38272</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

phy: qcom-qmp-usb: Fix an NULL vs IS_ERR() bug

The qmp_usb_iomap() helper function currently returns the raw result of
devm_ioremap() for non-exclusive mappings. Since devm_ioremap() may return
a NULL pointer and the caller only checks error pointers with IS_ERR(),
NULL could bypass the check and lead to an invalid dereference.

Fix the issue by checking if devm_ioremap() returns NULL. When it does,
qmp_usb_iomap() now returns an error pointer via IOMEM_ERR_PTR(-ENOMEM),
ensuring safe and consistent error handling.</Note>
    </Notes>
    <CVE>CVE-2025-38275</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mtd: nand: ecc-mxic: Fix use of uninitialized variable ret

If ctx-&gt;steps is zero, the loop processing ECC steps is skipped,
and the variable ret remains uninitialized. It is later checked
and returned, which leads to undefined behavior and may cause
unpredictable results in user space or kernel crashes.

This scenario can be triggered in edge cases such as misconfigured
geometry, ECC engine misuse, or if ctx-&gt;steps is not validated
after initialization.

Initialize ret to zero before the loop to ensure correct and safe
behavior regardless of the ctx-&gt;steps value.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2025-38277</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: Do not include stack ptr register in precision backtracking bookkeeping

Yi Lai reported an issue ([1]) where the following warning appears
in kernel dmesg:
  [   60.643604] verifier backtracking bug
  [   60.643635] WARNING: CPU: 10 PID: 2315 at kernel/bpf/verifier.c:4302 __mark_chain_precision+0x3a6c/0x3e10
  [   60.648428] Modules linked in: bpf_testmod(OE)
  [   60.650471] CPU: 10 UID: 0 PID: 2315 Comm: test_progs Tainted: G           OE       6.15.0-rc4-gef11287f8289-dirty #327 PREEMPT(full)
  [   60.654385] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
  [   60.656682] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
  [   60.660475] RIP: 0010:__mark_chain_precision+0x3a6c/0x3e10
  [   60.662814] Code: 5a 30 84 89 ea e8 c4 d9 01 00 80 3d 3e 7d d8 04 00 0f 85 60 fa ff ff c6 05 31 7d d8 04
                       01 48 c7 c7 00 58 30 84 e8 c4 06 a5 ff &lt;0f&gt; 0b e9 46 fa ff ff 48 ...
  [   60.668720] RSP: 0018:ffff888116cc7298 EFLAGS: 00010246
  [   60.671075] RAX: 54d70e82dfd31900 RBX: ffff888115b65e20 RCX: 0000000000000000
  [   60.673659] RDX: 0000000000000001 RSI: 0000000000000004 RDI: 00000000ffffffff
  [   60.676241] RBP: 0000000000000400 R08: ffff8881f6f23bd3 R09: 1ffff1103ede477a
  [   60.678787] R10: dffffc0000000000 R11: ffffed103ede477b R12: ffff888115b60ae8
  [   60.681420] R13: 1ffff11022b6cbc4 R14: 00000000fffffff2 R15: 0000000000000001
  [   60.684030] FS:  00007fc2aedd80c0(0000) GS:ffff88826fa8a000(0000) knlGS:0000000000000000
  [   60.686837] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  [   60.689027] CR2: 000056325369e000 CR3: 000000011088b002 CR4: 0000000000370ef0
  [   60.691623] Call Trace:
  [   60.692821]  &lt;TASK&gt;
  [   60.693960]  ? __pfx_verbose+0x10/0x10
  [   60.695656]  ? __pfx_disasm_kfunc_name+0x10/0x10
  [   60.697495]  check_cond_jmp_op+0x16f7/0x39b0
  [   60.699237]  do_check+0x58fa/0xab10
  ...

Further analysis shows the warning is at line 4302 as below:

  4294                 /* static subprog call instruction, which
  4295                  * means that we are exiting current subprog,
  4296                  * so only r1-r5 could be still requested as
  4297                  * precise, r0 and r6-r10 or any stack slot in
  4298                  * the current frame should be zero by now
  4299                  */
  4300                 if (bt_reg_mask(bt) &amp; ~BPF_REGMASK_ARGS) {
  4301                         verbose(env, "BUG regs %x\n", bt_reg_mask(bt));
  4302                         WARN_ONCE(1, "verifier backtracking bug");
  4303                         return -EFAULT;
  4304                 }

With the below test (also in the next patch):
  __used __naked static void __bpf_jmp_r10(void)
  {
	asm volatile (
	"r2 = 2314885393468386424 ll;"
	"goto +0;"
	"if r2 &lt;= r10 goto +3;"
	"if r1 &gt;= -1835016 goto +0;"
	"if r2 &lt;= 8 goto +0;"
	"if r3 &lt;= 0 goto +0;"
	"exit;"
	::: __clobber_all);
  }

  SEC("?raw_tp")
  __naked void bpf_jmp_r10(void)
  {
	asm volatile (
	"r3 = 0 ll;"
	"call __bpf_jmp_r10;"
	"r0 = 0;"
	"exit;"
	::: __clobber_all);
  }

The following is the verifier failure log:
  0: (18) r3 = 0x0                      ; R3_w=0
  2: (85) call pc+2
  caller:
   R10=fp0
  callee:
   frame1: R1=ctx() R3_w=0 R10=fp0
  5: frame1: R1=ctx() R3_w=0 R10=fp0
  ; asm volatile ("                                 \ @ verifier_precision.c:184
  5: (18) r2 = 0x20202000256c6c78       ; frame1: R2_w=0x20202000256c6c78
  7: (05) goto pc+0
  8: (bd) if r2 &lt;= r10 goto pc+3        ; frame1: R2_w=0x20202000256c6c78 R10=fp0
  9: (35) if r1 &gt;= 0xffe3fff8 goto pc+0         ; frame1: R1=ctx()
  10: (b5) if r2 &lt;= 0x8 goto pc+0
  mark_precise: frame1: last_idx 10 first_idx 0 subseq_idx -1
  mark_precise: frame1: regs=r2 stack= before 9: (35) if r1 &gt;= 0xffe3fff8 goto pc+0
  mark_precise: frame1: regs=r2 stack= before 8: (bd) if r2 &lt;= r10 goto pc+3
  mark_preci
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-38279</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hisi_acc_vfio_pci: bugfix live migration function without VF device driver

If the VF device driver is not loaded in the Guest OS and we attempt to
perform device data migration, the address of the migrated data will
be NULL.
The live migration recovery operation on the destination side will
access a null address value, which will cause access errors.

Therefore, live migration of VMs without added VF device drivers
does not require device data migration.
In addition, when the queue address data obtained by the destination
is empty, device queue recovery processing will not be performed.</Note>
    </Notes>
    <CVE>CVE-2025-38283</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

pinctrl: at91: Fix possible out-of-boundary access

at91_gpio_probe() doesn't check that given OF alias is not available or
something went wrong when trying to get it. This might have consequences
when accessing gpio_chips array with that value as an index. Note, that
BUG() can be compiled out and hence won't actually perform the required
checks.</Note>
    </Notes>
    <CVE>CVE-2025-38286</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

IB/cm: Drop lockdep assert and WARN when freeing old msg

The send completion handler can run after cm_id has advanced to another
message.  The cm_id lock is not needed in this case, but a recent change
re-used cm_free_priv_msg(), which asserts that the lock is held and
WARNs if the cm_id's currently outstanding msg is different than the one
being freed.</Note>
    </Notes>
    <CVE>CVE-2025-38287</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: smartpqi: Fix smp_processor_id() call trace for preemptible kernels

Correct kernel call trace when calling smp_processor_id() when called in
preemptible kernels by using raw_smp_processor_id().

smp_processor_id() checks to see if preemption is disabled and if not,
issue an error message followed by a call to dump_stack().

Brief example of call trace:
kernel:  check_preemption_disabled: 436 callbacks suppressed
kernel:  BUG: using smp_processor_id() in preemptible [00000000]
         code: kworker/u1025:0/2354
kernel:  caller is pqi_scsi_queue_command+0x183/0x310 [smartpqi]
kernel:  CPU: 129 PID: 2354 Comm: kworker/u1025:0
kernel:  ...
kernel:  Workqueue: writeback wb_workfn (flush-253:0)
kernel:  Call Trace:
kernel:   &lt;TASK&gt;
kernel:   dump_stack_lvl+0x34/0x48
kernel:   check_preemption_disabled+0xdd/0xe0
kernel:   pqi_scsi_queue_command+0x183/0x310 [smartpqi]
kernel:  ...</Note>
    </Notes>
    <CVE>CVE-2025-38288</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: lpfc: Avoid potential ndlp use-after-free in dev_loss_tmo_callbk

Smatch detected a potential use-after-free of an ndlp oject in
dev_loss_tmo_callbk during driver unload or fatal error handling.

Fix by reordering code to avoid potential use-after-free if initial
nodelist reference has been previously removed.</Note>
    </Notes>
    <CVE>CVE-2025-38289</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: fix node corruption in ar-&gt;arvifs list

In current WLAN recovery code flow, ath12k_core_halt() only reinitializes
the "arvifs" list head. This will cause the list node immediately following
the list head to become an invalid list node. Because the prev of that node
still points to the list head "arvifs", but the next of the list head
"arvifs" no longer points to that list node.

When a WLAN recovery occurs during the execution of a vif removal, and it
happens before the spin_lock_bh(&amp;ar-&gt;data_lock) in
ath12k_mac_vdev_delete(), list_del() will detect the previously mentioned
situation, thereby triggering a kernel panic.

The fix is to remove and reinitialize all vif list nodes from the list head
"arvifs" during WLAN halt. The reinitialization is to make the list nodes
valid, ensuring that the list_del() in ath12k_mac_vdev_delete() can execute
normally.

Call trace:
__list_del_entry_valid_or_report+0xd4/0x100 (P)
ath12k_mac_remove_link_interface.isra.0+0xf8/0x2e4 [ath12k]
ath12k_scan_vdev_clean_work+0x40/0x164 [ath12k]
cfg80211_wiphy_work+0xfc/0x100
process_one_work+0x164/0x2d0
worker_thread+0x254/0x380
kthread+0xfc/0x100
ret_from_fork+0x10/0x20

The change is mostly copied from the ath11k patch:
https://lore.kernel.org/all/20250320053145.3445187-1-quic_stonez@quicinc.com/

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1</Note>
    </Notes>
    <CVE>CVE-2025-38290</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: Prevent sending WMI commands to firmware during firmware crash

Currently, we encounter the following kernel call trace when a firmware
crash occurs. This happens because the host sends WMI commands to the
firmware while it is in recovery, causing the commands to fail and
resulting in the kernel call trace.

Set the ATH12K_FLAG_CRASH_FLUSH and ATH12K_FLAG_RECOVERY flags when the
host driver receives the firmware crash notification from MHI. This
prevents sending WMI commands to the firmware during recovery.

Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x75/0xc0
 register_lock_class+0x6be/0x7a0
 ? __lock_acquire+0x644/0x19a0
 __lock_acquire+0x95/0x19a0
 lock_acquire+0x265/0x310
 ? ath12k_ce_send+0xa2/0x210 [ath12k]
 ? find_held_lock+0x34/0xa0
 ? ath12k_ce_send+0x56/0x210 [ath12k]
 _raw_spin_lock_bh+0x33/0x70
 ? ath12k_ce_send+0xa2/0x210 [ath12k]
 ath12k_ce_send+0xa2/0x210 [ath12k]
 ath12k_htc_send+0x178/0x390 [ath12k]
 ath12k_wmi_cmd_send_nowait+0x76/0xa0 [ath12k]
 ath12k_wmi_cmd_send+0x62/0x190 [ath12k]
 ath12k_wmi_pdev_bss_chan_info_request+0x62/0xc0 [ath1
 ath12k_mac_op_get_survey+0x2be/0x310 [ath12k]
 ieee80211_dump_survey+0x99/0x240 [mac80211]
 nl80211_dump_survey+0xe7/0x470 [cfg80211]
 ? kmalloc_reserve+0x59/0xf0
 genl_dumpit+0x24/0x70
 netlink_dump+0x177/0x360
 __netlink_dump_start+0x206/0x280
 genl_family_rcv_msg_dumpit.isra.22+0x8a/0xe0
 ? genl_family_rcv_msg_attrs_parse.isra.23+0xe0/0xe0
 ? genl_op_lock.part.12+0x10/0x10
 ? genl_dumpit+0x70/0x70
 genl_rcv_msg+0x1d0/0x290
 ? nl80211_del_station+0x330/0x330 [cfg80211]
 ? genl_get_cmd_both+0x50/0x50
 netlink_rcv_skb+0x4f/0x100
 genl_rcv+0x1f/0x30
 netlink_unicast+0x1b6/0x260
 netlink_sendmsg+0x31a/0x450
 __sock_sendmsg+0xa8/0xb0
 ____sys_sendmsg+0x1e4/0x260
 ___sys_sendmsg+0x89/0xe0
 ? local_clock_noinstr+0xb/0xc0
 ? rcu_is_watching+0xd/0x40
 ? kfree+0x1de/0x370
 ? __sys_sendmsg+0x7a/0xc0

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1</Note>
    </Notes>
    <CVE>CVE-2025-38291</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: fix invalid access to memory

In ath12k_dp_rx_msdu_coalesce(), rxcb is fetched from skb and boolean
is_continuation is part of rxcb.
Currently, after freeing the skb, the rxcb-&gt;is_continuation accessed
again which is wrong since the memory is already freed.
This might lead use-after-free error.

Hence, fix by locally defining bool is_continuation from rxcb,
so that after freeing skb, is_continuation can be used.

Compile tested only.</Note>
    </Notes>
    <CVE>CVE-2025-38292</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: ath11k: fix node corruption in ar-&gt;arvifs list

In current WLAN recovery code flow, ath11k_core_halt() only
reinitializes the "arvifs" list head. This will cause the
list node immediately following the list head to become an
invalid list node. Because the prev of that node still points
to the list head "arvifs", but the next of the list head "arvifs"
no longer points to that list node.

When a WLAN recovery occurs during the execution of a vif
removal, and it happens before the spin_lock_bh(&amp;ar-&gt;data_lock)
in ath11k_mac_op_remove_interface(), list_del() will detect the
previously mentioned situation, thereby triggering a kernel panic.

The fix is to remove and reinitialize all vif list nodes from the
list head "arvifs" during WLAN halt. The reinitialization is to make
the list nodes valid, ensuring that the list_del() in
ath11k_mac_op_remove_interface() can execute normally.

Call trace:
__list_del_entry_valid_or_report+0xb8/0xd0
ath11k_mac_op_remove_interface+0xb0/0x27c [ath11k]
drv_remove_interface+0x48/0x194 [mac80211]
ieee80211_do_stop+0x6e0/0x844 [mac80211]
ieee80211_stop+0x44/0x17c [mac80211]
__dev_close_many+0xac/0x150
__dev_change_flags+0x194/0x234
dev_change_flags+0x24/0x6c
devinet_ioctl+0x3a0/0x670
inet_ioctl+0x200/0x248
sock_do_ioctl+0x60/0x118
sock_ioctl+0x274/0x35c
__arm64_sys_ioctl+0xac/0xf0
invoke_syscall+0x48/0x114
...

Tested-on: QCA6698AQ hw2.1 PCI WLAN.HSP.1.1-04591-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1</Note>
    </Notes>
    <CVE>CVE-2025-38293</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ASoC: mediatek: mt8195: Set ETDM1/2 IN/OUT to COMP_DUMMY()

ETDM2_IN_BE and ETDM1_OUT_BE are defined as COMP_EMPTY(),
in the case the codec dai_name will be null.

Avoid a crash if the device tree is not assigning a codec
to these links.

[    1.179936] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
[    1.181065] Mem abort info:
[    1.181420]   ESR = 0x0000000096000004
[    1.181892]   EC = 0x25: DABT (current EL), IL = 32 bits
[    1.182576]   SET = 0, FnV = 0
[    1.182964]   EA = 0, S1PTW = 0
[    1.183367]   FSC = 0x04: level 0 translation fault
[    1.183983] Data abort info:
[    1.184406]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[    1.185097]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[    1.185766]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[    1.186439] [0000000000000000] user address but active_mm is swapper
[    1.187239] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
[    1.188029] Modules linked in:
[    1.188420] CPU: 7 UID: 0 PID: 70 Comm: kworker/u32:1 Not tainted 6.14.0-rc4-next-20250226+ #85
[    1.189515] Hardware name: Radxa NIO 12L (DT)
[    1.190065] Workqueue: events_unbound deferred_probe_work_func
[    1.190808] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    1.191683] pc : __pi_strcmp+0x24/0x140
[    1.192170] lr : mt8195_mt6359_soc_card_probe+0x224/0x7b0
[    1.192854] sp : ffff800083473970
[    1.193271] x29: ffff800083473a10 x28: 0000000000001008 x27: 0000000000000002
[    1.194168] x26: ffff800082408960 x25: ffff800082417db0 x24: ffff800082417d88
[    1.195065] x23: 000000000000001e x22: ffff800082dbf480 x21: ffff800082dc07b8
[    1.195961] x20: 0000000000000000 x19: 0000000000000013 x18: 00000000ffffffff
[    1.196858] x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000006
[    1.197755] x14: ffff800082407af0 x13: 6e6f69737265766e x12: 692d6b636f6c6374
[    1.198651] x11: 0000000000000002 x10: ffff80008240b920 x9 : 0000000000000018
[    1.199547] x8 : 0101010101010101 x7 : 0000000000000000 x6 : 0000000000000000
[    1.200443] x5 : 0000000000000000 x4 : 8080808080000000 x3 : 303933383978616d
[    1.201339] x2 : 0000000000000000 x1 : ffff80008240b920 x0 : 0000000000000000
[    1.202236] Call trace:
[    1.202545]  __pi_strcmp+0x24/0x140 (P)
[    1.203029]  mtk_soundcard_common_probe+0x3bc/0x5b8
[    1.203644]  platform_probe+0x70/0xe8
[    1.204106]  really_probe+0xc8/0x3a0
[    1.204556]  __driver_probe_device+0x84/0x160
[    1.205104]  driver_probe_device+0x44/0x130
[    1.205630]  __device_attach_driver+0xc4/0x170
[    1.206189]  bus_for_each_drv+0x8c/0xf8
[    1.206672]  __device_attach+0xa8/0x1c8
[    1.207155]  device_initial_probe+0x1c/0x30
[    1.207681]  bus_probe_device+0xb0/0xc0
[    1.208165]  deferred_probe_work_func+0xa4/0x100
[    1.208747]  process_one_work+0x158/0x3e0
[    1.209254]  worker_thread+0x2c4/0x3e8
[    1.209727]  kthread+0x134/0x1f0
[    1.210136]  ret_from_fork+0x10/0x20
[    1.210589] Code: 54000401 b50002c6 d503201f f86a6803 (f8408402)
[    1.211355] ---[ end trace 0000000000000000 ]---</Note>
    </Notes>
    <CVE>CVE-2025-38299</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

crypto: sun8i-ce-cipher - fix error handling in sun8i_ce_cipher_prepare()

Fix two DMA cleanup issues on the error path in sun8i_ce_cipher_prepare():

1] If dma_map_sg() fails for areq-&gt;dst, the device driver would try to free
   DMA memory it has not allocated in the first place. To fix this, on the
   "theend_sgs" error path, call dma unmap only if the corresponding dma
   map was successful.

2] If the dma_map_single() call for the IV fails, the device driver would
   try to free an invalid DMA memory address on the "theend_iv" path:
   ------------[ cut here ]------------
   DMA-API: sun8i-ce 1904000.crypto: device driver tries to free an invalid DMA memory address
   WARNING: CPU: 2 PID: 69 at kernel/dma/debug.c:968 check_unmap+0x123c/0x1b90
   Modules linked in: skcipher_example(O+)
   CPU: 2 UID: 0 PID: 69 Comm: 1904000.crypto- Tainted: G           O        6.15.0-rc3+ #24 PREEMPT
   Tainted: [O]=OOT_MODULE
   Hardware name: OrangePi Zero2 (DT)
   pc : check_unmap+0x123c/0x1b90
   lr : check_unmap+0x123c/0x1b90
   ...
   Call trace:
    check_unmap+0x123c/0x1b90 (P)
    debug_dma_unmap_page+0xac/0xc0
    dma_unmap_page_attrs+0x1f4/0x5fc
    sun8i_ce_cipher_do_one+0x1bd4/0x1f40
    crypto_pump_work+0x334/0x6e0
    kthread_worker_fn+0x21c/0x438
    kthread+0x374/0x664
    ret_from_fork+0x10/0x20
   ---[ end trace 0000000000000000 ]---

To fix this, check for !dma_mapping_error() before calling
dma_unmap_single() on the "theend_iv" path.</Note>
    </Notes>
    <CVE>CVE-2025-38300</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: eir: Fix possible crashes on eir_create_adv_data

eir_create_adv_data may attempt to add EIR_FLAGS and EIR_TX_POWER
without checking if that would fit.</Note>
    </Notes>
    <CVE>CVE-2025-38303</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: Fix NULL pointer deference on eir_get_service_data

The len parameter is considered optional so it can be NULL so it cannot
be used for skipping to next entry of EIR_SERVICE_DATA.</Note>
    </Notes>
    <CVE>CVE-2025-38304</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ptp: remove ptp-&gt;n_vclocks check logic in ptp_vclock_in_use()

There is no disagreement that we should check both ptp-&gt;is_virtual_clock
and ptp-&gt;n_vclocks to check if the ptp virtual clock is in use.

However, when we acquire ptp-&gt;n_vclocks_mux to read ptp-&gt;n_vclocks in
ptp_vclock_in_use(), we observe a recursive lock in the call trace
starting from n_vclocks_store().

============================================
WARNING: possible recursive locking detected
6.15.0-rc6 #1 Not tainted
--------------------------------------------
syz.0.1540/13807 is trying to acquire lock:
ffff888035a24868 (&amp;ptp-&gt;n_vclocks_mux){+.+.}-{4:4}, at:
 ptp_vclock_in_use drivers/ptp/ptp_private.h:103 [inline]
ffff888035a24868 (&amp;ptp-&gt;n_vclocks_mux){+.+.}-{4:4}, at:
 ptp_clock_unregister+0x21/0x250 drivers/ptp/ptp_clock.c:415

but task is already holding lock:
ffff888030704868 (&amp;ptp-&gt;n_vclocks_mux){+.+.}-{4:4}, at:
 n_vclocks_store+0xf1/0x6d0 drivers/ptp/ptp_sysfs.c:215

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&amp;ptp-&gt;n_vclocks_mux);
  lock(&amp;ptp-&gt;n_vclocks_mux);

 *** DEADLOCK ***
....
============================================

The best way to solve this is to remove the logic that checks
ptp-&gt;n_vclocks in ptp_vclock_in_use().

The reason why this is appropriate is that any path that uses
ptp-&gt;n_vclocks must unconditionally check if ptp-&gt;n_vclocks is greater
than 0 before unregistering vclocks, and all functions are already
written this way. And in the function that uses ptp-&gt;n_vclocks, we
already get ptp-&gt;n_vclocks_mux before unregistering vclocks.

Therefore, we need to remove the redundant check for ptp-&gt;n_vclocks in
ptp_vclock_in_use() to prevent recursive locking.</Note>
    </Notes>
    <CVE>CVE-2025-38305</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ASoC: Intel: avs: Verify content returned by parse_int_array()

The first element of the returned array stores its length. If it is 0,
any manipulation beyond the element at index 0 ends with null-ptr-deref.</Note>
    </Notes>
    <CVE>CVE-2025-38307</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

seg6: Fix validation of nexthop addresses

The kernel currently validates that the length of the provided nexthop
address does not exceed the specified length. This can lead to the
kernel reading uninitialized memory if user space provided a shorter
length than the specified one.

Fix by validating that the provided length exactly matches the specified
one.</Note>
    </Notes>
    <CVE>CVE-2025-38310</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

fbdev: core: fbcvt: avoid division by 0 in fb_cvt_hperiod()

In fb_find_mode_cvt(), iff mode-&gt;refresh somehow happens to be 0x80000000,
cvt.f_refresh will become 0 when multiplying it by 2 due to overflow. It's
then passed to fb_cvt_hperiod(), where it's used as a divider -- division
by 0 will result in kernel oops. Add a sanity check for cvt.f_refresh to
avoid such overflow...

Found by Linux Verification Center (linuxtesting.org) with the Svace static
analysis tool.</Note>
    </Notes>
    <CVE>CVE-2025-38312</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bus: fsl-mc: fix double-free on mc_dev

The blamed commit tried to simplify how the deallocations are done but,
in the process, introduced a double-free on the mc_dev variable.

In case the MC device is a DPRC, a new mc_bus is allocated and the
mc_dev variable is just a reference to one of its fields. In this
circumstance, on the error path only the mc_bus should be freed.

This commit introduces back the following checkpatch warning which is a
false-positive.

WARNING: kfree(NULL) is safe and this check is probably not required
+       if (mc_bus)
+               kfree(mc_bus);</Note>
    </Notes>
    <CVE>CVE-2025-38313</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: btintel: Check dsbr size from EFI variable

Since the size of struct btintel_dsbr is already known, we can just
start there instead of querying the EFI variable size. If the final
result doesn't match what we expect also fail. This fixes a stack buffer
overflow when the EFI variable is larger than struct btintel_dsbr.</Note>
    </Notes>
    <CVE>CVE-2025-38315</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: Fix buffer overflow in debugfs

If the user tries to write more than 32 bytes then it results in memory
corruption.  Fortunately, this is debugfs so it's limited to root users.</Note>
    </Notes>
    <CVE>CVE-2025-38317</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_table

The function atomctrl_initialize_mc_reg_table() and
atomctrl_initialize_mc_reg_table_v2_2() does not check the return
value of smu_atom_get_data_table(). If smu_atom_get_data_table()
fails to retrieve vram_info, it returns NULL which is later
dereferenced.</Note>
    </Notes>
    <CVE>CVE-2025-38319</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: atm: add lec_mutex

syzbot found its way in net/atm/lec.c, and found an error path
in lecd_attach() could leave a dangling pointer in dev_lec[].

Add a mutex to protect dev_lecp[] uses from lecd_attach(),
lec_vcc_attach() and lec_mcast_attach().

Following patch will use this mutex for /proc/net/atm/lec.

BUG: KASAN: slab-use-after-free in lecd_attach net/atm/lec.c:751 [inline]
BUG: KASAN: slab-use-after-free in lane_ioctl+0x2224/0x23e0 net/atm/lec.c:1008
Read of size 8 at addr ffff88807c7b8e68 by task syz.1.17/6142

CPU: 1 UID: 0 PID: 6142 Comm: syz.1.17 Not tainted 6.16.0-rc1-syzkaller-00239-g08215f5486ec #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
Call Trace:
 &lt;TASK&gt;
  __dump_stack lib/dump_stack.c:94 [inline]
  dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
  print_address_description mm/kasan/report.c:408 [inline]
  print_report+0xcd/0x680 mm/kasan/report.c:521
  kasan_report+0xe0/0x110 mm/kasan/report.c:634
  lecd_attach net/atm/lec.c:751 [inline]
  lane_ioctl+0x2224/0x23e0 net/atm/lec.c:1008
  do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159
  sock_do_ioctl+0x118/0x280 net/socket.c:1190
  sock_ioctl+0x227/0x6b0 net/socket.c:1311
  vfs_ioctl fs/ioctl.c:51 [inline]
  __do_sys_ioctl fs/ioctl.c:907 [inline]
  __se_sys_ioctl fs/ioctl.c:893 [inline]
  __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893
  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
  do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
 &lt;/TASK&gt;

Allocated by task 6132:
  kasan_save_stack+0x33/0x60 mm/kasan/common.c:47
  kasan_save_track+0x14/0x30 mm/kasan/common.c:68
  poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
  __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394
  kasan_kmalloc include/linux/kasan.h:260 [inline]
  __do_kmalloc_node mm/slub.c:4328 [inline]
  __kvmalloc_node_noprof+0x27b/0x620 mm/slub.c:5015
  alloc_netdev_mqs+0xd2/0x1570 net/core/dev.c:11711
  lecd_attach net/atm/lec.c:737 [inline]
  lane_ioctl+0x17db/0x23e0 net/atm/lec.c:1008
  do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159
  sock_do_ioctl+0x118/0x280 net/socket.c:1190
  sock_ioctl+0x227/0x6b0 net/socket.c:1311
  vfs_ioctl fs/ioctl.c:51 [inline]
  __do_sys_ioctl fs/ioctl.c:907 [inline]
  __se_sys_ioctl fs/ioctl.c:893 [inline]
  __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893
  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
  do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Freed by task 6132:
  kasan_save_stack+0x33/0x60 mm/kasan/common.c:47
  kasan_save_track+0x14/0x30 mm/kasan/common.c:68
  kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:576
  poison_slab_object mm/kasan/common.c:247 [inline]
  __kasan_slab_free+0x51/0x70 mm/kasan/common.c:264
  kasan_slab_free include/linux/kasan.h:233 [inline]
  slab_free_hook mm/slub.c:2381 [inline]
  slab_free mm/slub.c:4643 [inline]
  kfree+0x2b4/0x4d0 mm/slub.c:4842
  free_netdev+0x6c5/0x910 net/core/dev.c:11892
  lecd_attach net/atm/lec.c:744 [inline]
  lane_ioctl+0x1ce8/0x23e0 net/atm/lec.c:1008
  do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159
  sock_do_ioctl+0x118/0x280 net/socket.c:1190
  sock_ioctl+0x227/0x6b0 net/socket.c:1311
  vfs_ioctl fs/ioctl.c:51 [inline]
  __do_sys_ioctl fs/ioctl.c:907 [inline]
  __se_sys_ioctl fs/ioctl.c:893 [inline]
  __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893</Note>
    </Notes>
    <CVE>CVE-2025-38323</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

aoe: clean device rq_list in aoedev_downdev()

An aoe device's rq_list contains accepted block requests that are
waiting to be transmitted to the aoe target. This queue was added as
part of the conversion to blk_mq. However, the queue was not cleaned out
when an aoe device is downed which caused blk_mq_freeze_queue() to sleep
indefinitely waiting for those requests to complete, causing a hang. This
fix cleans out the queue before calling blk_mq_freeze_queue().</Note>
    </Notes>
    <CVE>CVE-2025-38326</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

jffs2: check jffs2_prealloc_raw_node_refs() result in few other places

Fuzzing hit another invalid pointer dereference due to the lack of
checking whether jffs2_prealloc_raw_node_refs() completed successfully.
Subsequent logic implies that the node refs have been allocated.

Handle that. The code is ready for propagating the error upwards.

KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 1 PID: 5835 Comm: syz-executor145 Not tainted 5.10.234-syzkaller #0
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
RIP: 0010:jffs2_link_node_ref+0xac/0x690 fs/jffs2/nodelist.c:600
Call Trace:
 jffs2_mark_erased_block fs/jffs2/erase.c:460 [inline]
 jffs2_erase_pending_blocks+0x688/0x1860 fs/jffs2/erase.c:118
 jffs2_garbage_collect_pass+0x638/0x1a00 fs/jffs2/gc.c:253
 jffs2_reserve_space+0x3f4/0xad0 fs/jffs2/nodemgmt.c:167
 jffs2_write_inode_range+0x246/0xb50 fs/jffs2/write.c:362
 jffs2_write_end+0x712/0x1110 fs/jffs2/file.c:302
 generic_perform_write+0x2c2/0x500 mm/filemap.c:3347
 __generic_file_write_iter+0x252/0x610 mm/filemap.c:3465
 generic_file_write_iter+0xdb/0x230 mm/filemap.c:3497
 call_write_iter include/linux/fs.h:2039 [inline]
 do_iter_readv_writev+0x46d/0x750 fs/read_write.c:740
 do_iter_write+0x18c/0x710 fs/read_write.c:866
 vfs_writev+0x1db/0x6a0 fs/read_write.c:939
 do_pwritev fs/read_write.c:1036 [inline]
 __do_sys_pwritev fs/read_write.c:1083 [inline]
 __se_sys_pwritev fs/read_write.c:1078 [inline]
 __x64_sys_pwritev+0x235/0x310 fs/read_write.c:1078
 do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x67/0xd1

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.</Note>
    </Notes>
    <CVE>CVE-2025-38328</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: lpfc: Use memcpy() for BIOS version

The strlcat() with FORTIFY support is triggering a panic because it
thinks the target buffer will overflow although the correct target
buffer size is passed in.

Anyway, instead of memset() with 0 followed by a strlcat(), just use
memcpy() and ensure that the resulting buffer is NULL terminated.

BIOSVersion is only used for the lpfc_printf_log() which expects a
properly terminated string.</Note>
    </Notes>
    <CVE>CVE-2025-38332</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

x86/sgx: Prevent attempts to reclaim poisoned pages

TL;DR: SGX page reclaim touches the page to copy its contents to
secondary storage. SGX instructions do not gracefully handle machine
checks. Despite this, the existing SGX code will try to reclaim pages
that it _knows_ are poisoned. Avoid even trying to reclaim poisoned pages.

The longer story:

Pages used by an enclave only get epc_page-&gt;poison set in
arch_memory_failure() but they currently stay on sgx_active_page_list until
sgx_encl_release(), with the SGX_EPC_PAGE_RECLAIMER_TRACKED flag untouched.

epc_page-&gt;poison is not checked in the reclaimer logic meaning that, if other
conditions are met, an attempt will be made to reclaim an EPC page that was
poisoned.  This is bad because 1. we don't want that page to end up added
to another enclave and 2. it is likely to cause one core to shut down
and the kernel to panic.

Specifically, reclaiming uses microcode operations including "EWB" which
accesses the EPC page contents to encrypt and write them out to non-SGX
memory.  Those operations cannot handle MCEs in their accesses other than
by putting the executing core into a special shutdown state (affecting
both threads with HT.)  The kernel will subsequently panic on the
remaining cores seeing the core didn't enter MCE handler(s) in time.

Call sgx_unmark_page_reclaimable() to remove the affected EPC page from
sgx_active_page_list on memory error to stop it being considered for
reclaiming.

Testing epc_page-&gt;poison in sgx_reclaim_pages() would also work but I assume
it's better to add code in the less likely paths.

The affected EPC page is not added to &amp;node-&gt;sgx_poison_page_list until
later in sgx_encl_release()-&gt;sgx_free_epc_page() when it is EREMOVEd.
Membership on other lists doesn't change to avoid changing any of the
lists' semantics except for sgx_active_page_list.  There's a "TBD" comment
in arch_memory_failure() about pre-emptive actions, the goal here is not
to address everything that it may imply.

This also doesn't completely close the time window when a memory error
notification will be fatal (for a not previously poisoned EPC page) --
the MCE can happen after sgx_reclaim_pages() has selected its candidates
or even *inside* a microcode operation (actually easy to trigger due to
the amount of time spent in them.)

The spinlock in sgx_unmark_page_reclaimable() is safe because
memory_failure() runs in process context and no spinlocks are held,
explicitly noted in a mm/memory-failure.c comment.</Note>
    </Notes>
    <CVE>CVE-2025-38334</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Input: gpio-keys - fix a sleep while atomic with PREEMPT_RT

When enabling PREEMPT_RT, the gpio_keys_irq_timer() callback runs in
hard irq context, but the input_event() takes a spin_lock, which isn't
allowed there as it is converted to a rt_spin_lock().

[ 4054.289999] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
[ 4054.290028] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/0
...
[ 4054.290195]  __might_resched+0x13c/0x1f4
[ 4054.290209]  rt_spin_lock+0x54/0x11c
[ 4054.290219]  input_event+0x48/0x80
[ 4054.290230]  gpio_keys_irq_timer+0x4c/0x78
[ 4054.290243]  __hrtimer_run_queues+0x1a4/0x438
[ 4054.290257]  hrtimer_interrupt+0xe4/0x240
[ 4054.290269]  arch_timer_handler_phys+0x2c/0x44
[ 4054.290283]  handle_percpu_devid_irq+0x8c/0x14c
[ 4054.290297]  handle_irq_desc+0x40/0x58
[ 4054.290307]  generic_handle_domain_irq+0x1c/0x28
[ 4054.290316]  gic_handle_irq+0x44/0xcc

Considering the gpio_keys_irq_isr() can run in any context, e.g. it can
be threaded, it seems there's no point in requesting the timer isr to
run in hard irq context.

Relax the hrtimer not to use the hard context.</Note>
    </Notes>
    <CVE>CVE-2025-38335</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ata: pata_via: Force PIO for ATAPI devices on VT6415/VT6330

The controller has a hardware bug that can hard hang the system when
doing ATAPI DMAs without any trace of what happened. Depending on the
device attached, it can also prevent the system from booting.

In this case, the system hangs when reading the ATIP from optical media
with cdrecord -vvv -atip on an _NEC DVD_RW ND-4571A 1-01 and an
Optiarc DVD RW AD-7200A 1.06 attached to an ASRock 990FX Extreme 4,
running at UDMA/33.

The issue can be reproduced by running the same command with a cygwin
build of cdrecord on WinXP, although it requires more attempts to cause
it. The hang in that case is also resolved by forcing PIO. It doesn't
appear that VIA has produced any drivers for that OS, thus no known
workaround exists.

HDDs attached to the controller do not suffer from any DMA issues.</Note>
    </Notes>
    <CVE>CVE-2025-38336</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

jbd2: fix data-race and null-ptr-deref in jbd2_journal_dirty_metadata()

Since handle-&gt;h_transaction may be a NULL pointer, so we should change it
to call is_handle_aborted(handle) first before dereferencing it.

And the following data-race was reported in my fuzzer:

==================================================================
BUG: KCSAN: data-race in jbd2_journal_dirty_metadata / jbd2_journal_dirty_metadata

write to 0xffff888011024104 of 4 bytes by task 10881 on cpu 1:
 jbd2_journal_dirty_metadata+0x2a5/0x770 fs/jbd2/transaction.c:1556
 __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358
 ext4_do_update_inode fs/ext4/inode.c:5220 [inline]
 ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869
 __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074
 ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103
....

read to 0xffff888011024104 of 4 bytes by task 10880 on cpu 0:
 jbd2_journal_dirty_metadata+0xf2/0x770 fs/jbd2/transaction.c:1512
 __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358
 ext4_do_update_inode fs/ext4/inode.c:5220 [inline]
 ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869
 __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074
 ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103
....

value changed: 0x00000000 -&gt; 0x00000001
==================================================================

This issue is caused by missing data-race annotation for jh-&gt;b_modified.
Therefore, the missing annotation needs to be added.</Note>
    </Notes>
    <CVE>CVE-2025-38337</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

fs/nfs/read: fix double-unlock bug in nfs_return_empty_folio()

Sometimes, when a file was read while it was being truncated by
another NFS client, the kernel could deadlock because folio_unlock()
was called twice, and the second call would XOR back the `PG_locked`
flag.

Most of the time (depending on the timing of the truncation), nobody
notices the problem because folio_unlock() gets called three times,
which flips `PG_locked` back off:

 1. vfs_read, nfs_read_folio, ... nfs_read_add_folio,
    nfs_return_empty_folio
 2. vfs_read, nfs_read_folio, ... netfs_read_collection,
    netfs_unlock_abandoned_read_pages
 3. vfs_read, ... nfs_do_read_folio, nfs_read_add_folio,
    nfs_return_empty_folio

The problem is that nfs_read_add_folio() is not supposed to unlock the
folio if fscache is enabled, and a nfs_netfs_folio_unlock() check is
missing in nfs_return_empty_folio().

Rarely this leads to a warning in netfs_read_collection():

 ------------[ cut here ]------------
 R=0000031c: folio 10 is not locked
 WARNING: CPU: 0 PID: 29 at fs/netfs/read_collect.c:133 netfs_read_collection+0x7c0/0xf00
 [...]
 Workqueue: events_unbound netfs_read_collection_worker
 RIP: 0010:netfs_read_collection+0x7c0/0xf00
 [...]
 Call Trace:
  &lt;TASK&gt;
  netfs_read_collection_worker+0x67/0x80
  process_one_work+0x12e/0x2c0
  worker_thread+0x295/0x3a0

Most of the time, however, processes just get stuck forever in
folio_wait_bit_common(), waiting for `PG_locked` to disappear, which
never happens because nobody is really holding the folio lock.</Note>
    </Notes>
    <CVE>CVE-2025-38338</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

software node: Correct a OOB check in software_node_get_reference_args()

software_node_get_reference_args() wants to get @index-th element, so
the property value requires at least '(index + 1) * sizeof(*ref)' bytes
but that can not be guaranteed by current OOB check, and may cause OOB
for malformed property.

Fix by using as OOB check '((index + 1) * sizeof(*ref) &gt; prop-&gt;length)'.</Note>
    </Notes>
    <CVE>CVE-2025-38342</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: mt7996: drop fragments with multicast or broadcast RA

IEEE 802.11 fragmentation can only be applied to unicast frames.
Therefore, drop fragments with multicast or broadcast RA. This patch
addresses vulnerabilities such as CVE-2020-26145.</Note>
    </Notes>
    <CVE>CVE-2025-38343</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ACPICA: fix acpi parse and parseext cache leaks

ACPICA commit 8829e70e1360c81e7a5a901b5d4f48330e021ea5

I'm Seunghun Han, and I work for National Security Research Institute of
South Korea.

I have been doing a research on ACPI and found an ACPI cache leak in ACPI
early abort cases.

Boot log of ACPI cache leak is as follows:
[    0.352414] ACPI: Added _OSI(Module Device)
[    0.353182] ACPI: Added _OSI(Processor Device)
[    0.353182] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.353182] ACPI: Added _OSI(Processor Aggregator Device)
[    0.356028] ACPI: Unable to start the ACPI Interpreter
[    0.356799] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)
[    0.360215] kmem_cache_destroy Acpi-State: Slab cache still has objects
[    0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W
4.12.0-rc4-next-20170608+ #10
[    0.361273] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS
virtual_box 12/01/2006
[    0.361873] Call Trace:
[    0.362243]  ? dump_stack+0x5c/0x81
[    0.362591]  ? kmem_cache_destroy+0x1aa/0x1c0
[    0.362944]  ? acpi_sleep_proc_init+0x27/0x27
[    0.363296]  ? acpi_os_delete_cache+0xa/0x10
[    0.363646]  ? acpi_ut_delete_caches+0x6d/0x7b
[    0.364000]  ? acpi_terminate+0xa/0x14
[    0.364000]  ? acpi_init+0x2af/0x34f
[    0.364000]  ? __class_create+0x4c/0x80
[    0.364000]  ? video_setup+0x7f/0x7f
[    0.364000]  ? acpi_sleep_proc_init+0x27/0x27
[    0.364000]  ? do_one_initcall+0x4e/0x1a0
[    0.364000]  ? kernel_init_freeable+0x189/0x20a
[    0.364000]  ? rest_init+0xc0/0xc0
[    0.364000]  ? kernel_init+0xa/0x100
[    0.364000]  ? ret_from_fork+0x25/0x30

I analyzed this memory leak in detail. I found that “Acpi-State” cache and
“Acpi-Parse” cache were merged because the size of cache objects was same
slab cache size.

I finally found “Acpi-Parse” cache and “Acpi-parse_ext” cache were leaked
using SLAB_NEVER_MERGE flag in kmem_cache_create() function.

Real ACPI cache leak point is as follows:
[    0.360101] ACPI: Added _OSI(Module Device)
[    0.360101] ACPI: Added _OSI(Processor Device)
[    0.360101] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.361043] ACPI: Added _OSI(Processor Aggregator Device)
[    0.364016] ACPI: Unable to start the ACPI Interpreter
[    0.365061] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)
[    0.368174] kmem_cache_destroy Acpi-Parse: Slab cache still has objects
[    0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G        W
4.12.0-rc4-next-20170608+ #8
[    0.371256] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS
virtual_box 12/01/2006
[    0.372000] Call Trace:
[    0.372000]  ? dump_stack+0x5c/0x81
[    0.372000]  ? kmem_cache_destroy+0x1aa/0x1c0
[    0.372000]  ? acpi_sleep_proc_init+0x27/0x27
[    0.372000]  ? acpi_os_delete_cache+0xa/0x10
[    0.372000]  ? acpi_ut_delete_caches+0x56/0x7b
[    0.372000]  ? acpi_terminate+0xa/0x14
[    0.372000]  ? acpi_init+0x2af/0x34f
[    0.372000]  ? __class_create+0x4c/0x80
[    0.372000]  ? video_setup+0x7f/0x7f
[    0.372000]  ? acpi_sleep_proc_init+0x27/0x27
[    0.372000]  ? do_one_initcall+0x4e/0x1a0
[    0.372000]  ? kernel_init_freeable+0x189/0x20a
[    0.372000]  ? rest_init+0xc0/0xc0
[    0.372000]  ? kernel_init+0xa/0x100
[    0.372000]  ? ret_from_fork+0x25/0x30
[    0.388039] kmem_cache_destroy Acpi-parse_ext: Slab cache still has objects
[    0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G        W
4.12.0-rc4-next-20170608+ #8
[    0.390557] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS
virtual_box 12/01/2006
[    0.392000] Call Trace:
[    0.392000]  ? dump_stack+0x5c/0x81
[    0.392000]  ? kmem_cache_destroy+0x1aa/0x1c0
[    0.392000]  ? acpi_sleep_proc_init+0x27/0x27
[    0.392000]  ? acpi_os_delete_cache+0xa/0x10
[    0.392000]  ? acpi_ut_delete_caches+0x6d/0x7b
[    0.392000]  ? acpi_terminate+0xa/0x14
[    0.392000]  ? acpi_init+0x2af/0x3
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-38344</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ACPICA: fix acpi operand cache leak in dswstate.c

ACPICA commit 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732

I found an ACPI cache leak in ACPI early termination and boot continuing case.

When early termination occurs due to malicious ACPI table, Linux kernel
terminates ACPI function and continues to boot process. While kernel terminates
ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak.

Boot log of ACPI operand cache leak is as follows:
&gt;[    0.585957] ACPI: Added _OSI(Module Device)
&gt;[    0.587218] ACPI: Added _OSI(Processor Device)
&gt;[    0.588530] ACPI: Added _OSI(3.0 _SCP Extensions)
&gt;[    0.589790] ACPI: Added _OSI(Processor Aggregator Device)
&gt;[    0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155)
&gt;[    0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88)
&gt;[    0.597858] ACPI: Unable to start the ACPI Interpreter
&gt;[    0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)
&gt;[    0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects
&gt;[    0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26
&gt;[    0.605159] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006
&gt;[    0.609177] Call Trace:
&gt;[    0.610063]  ? dump_stack+0x5c/0x81
&gt;[    0.611118]  ? kmem_cache_destroy+0x1aa/0x1c0
&gt;[    0.612632]  ? acpi_sleep_proc_init+0x27/0x27
&gt;[    0.613906]  ? acpi_os_delete_cache+0xa/0x10
&gt;[    0.617986]  ? acpi_ut_delete_caches+0x3f/0x7b
&gt;[    0.619293]  ? acpi_terminate+0xa/0x14
&gt;[    0.620394]  ? acpi_init+0x2af/0x34f
&gt;[    0.621616]  ? __class_create+0x4c/0x80
&gt;[    0.623412]  ? video_setup+0x7f/0x7f
&gt;[    0.624585]  ? acpi_sleep_proc_init+0x27/0x27
&gt;[    0.625861]  ? do_one_initcall+0x4e/0x1a0
&gt;[    0.627513]  ? kernel_init_freeable+0x19e/0x21f
&gt;[    0.628972]  ? rest_init+0x80/0x80
&gt;[    0.630043]  ? kernel_init+0xa/0x100
&gt;[    0.631084]  ? ret_from_fork+0x25/0x30
&gt;[    0.633343] vgaarb: loaded
&gt;[    0.635036] EDAC MC: Ver: 3.0.0
&gt;[    0.638601] PCI: Probing PCI hardware
&gt;[    0.639833] PCI host bridge to bus 0000:00
&gt;[    0.641031] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
&gt; ... Continue to boot and log is omitted ...

I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_
delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push()
function uses walk_state-&gt;operand_index for start position of the top, but
acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it.
Therefore, this causes acpi operand memory leak.

This cache leak causes a security threat because an old kernel (&lt;= 4.9) shows
memory locations of kernel functions in stack dump. Some malicious users
could use this information to neutralize kernel ASLR.

I made a patch to fix ACPI operand cache leak.</Note>
    </Notes>
    <CVE>CVE-2025-38345</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()

Robert Morris reported:

|If a malicious USB device pretends to be an Intersil p54 wifi
|interface and generates an eeprom_readback message with a large
|eeprom-&gt;v1.len, p54_rx_eeprom_readback() will copy data from the
|message beyond the end of priv-&gt;eeprom.
|
|static void p54_rx_eeprom_readback(struct p54_common *priv,
|                                   struct sk_buff *skb)
|{
|        struct p54_hdr *hdr = (struct p54_hdr *) skb-&gt;data;
|        struct p54_eeprom_lm86 *eeprom = (struct p54_eeprom_lm86 *) hdr-&gt;data;
|
|        if (priv-&gt;fw_var &gt;= 0x509) {
|                memcpy(priv-&gt;eeprom, eeprom-&gt;v2.data,
|                       le16_to_cpu(eeprom-&gt;v2.len));
|        } else {
|                memcpy(priv-&gt;eeprom, eeprom-&gt;v1.data,
|                       le16_to_cpu(eeprom-&gt;v1.len));
|        }
| [...]

The eeprom-&gt;v{1,2}.len is set by the driver in p54_download_eeprom().
The device is supposed to provide the same length back to the driver.
But yes, it's possible (like shown in the report) to alter the value
to something that causes a crash/panic due to overrun.

This patch addresses the issue by adding the size to the common device
context, so p54_rx_eeprom_readback no longer relies on possibly tampered
values... That said, it also checks if the "firmware" altered the value
and no longer copies them.

The one, small saving grace is: Before the driver tries to read the eeprom,
it needs to upload &gt;a&lt; firmware. the vendor firmware has a proprietary
license and as a reason, it is not present on most distributions by
default.</Note>
    </Notes>
    <CVE>CVE-2025-38348</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

eventpoll: don't decrement ep refcount while still holding the ep mutex

Jann Horn points out that epoll is decrementing the ep refcount and then
doing a

    mutex_unlock(&amp;ep-&gt;mtx);

afterwards. That's very wrong, because it can lead to a use-after-free.

That pattern is actually fine for the very last reference, because the
code in question will delay the actual call to "ep_free(ep)" until after
it has unlocked the mutex.

But it's wrong for the much subtler "next to last" case when somebody
*else* may also be dropping their reference and free the ep while we're
still using the mutex.

Note that this is true even if that other user is also using the same ep
mutex: mutexes, unlike spinlocks, can not be used for object ownership,
even if they guarantee mutual exclusion.

A mutex "unlock" operation is not atomic, and as one user is still
accessing the mutex as part of unlocking it, another user can come in
and get the now released mutex and free the data structure while the
first user is still cleaning up.

See our mutex documentation in Documentation/locking/mutex-design.rst,
in particular the section [1] about semantics:

	"mutex_unlock() may access the mutex structure even after it has
	 internally released the lock already - so it's not safe for
	 another context to acquire the mutex and assume that the
	 mutex_unlock() context is not using the structure anymore"

So if we drop our ep ref before the mutex unlock, but we weren't the
last one, we may then unlock the mutex, another user comes in, drops
_their_ reference and releases the 'ep' as it now has no users - all
while the mutex_unlock() is still accessing it.

Fix this by simply moving the ep refcount dropping to outside the mutex:
the refcount itself is atomic, and doesn't need mutex protection (that's
the whole _point_ of refcounts: unlike mutexes, they are inherently
about object lifetimes).</Note>
    </Notes>
    <CVE>CVE-2025-38349</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/sched: Always pass notifications when child class becomes empty

Certain classful qdiscs may invoke their classes' dequeue handler on an
enqueue operation. This may unexpectedly empty the child qdisc and thus
make an in-flight class passive via qlen_notify(). Most qdiscs do not
expect such behaviour at this point in time and may re-activate the
class eventually anyways which will lead to a use-after-free.

The referenced fix commit attempted to fix this behavior for the HFSC
case by moving the backlog accounting around, though this turned out to
be incomplete since the parent's parent may run into the issue too.
The following reproducer demonstrates this use-after-free:

    tc qdisc add dev lo root handle 1: drr
    tc filter add dev lo parent 1: basic classid 1:1
    tc class add dev lo parent 1: classid 1:1 drr
    tc qdisc add dev lo parent 1:1 handle 2: hfsc def 1
    tc class add dev lo parent 2: classid 2:1 hfsc rt m1 8 d 1 m2 0
    tc qdisc add dev lo parent 2:1 handle 3: netem
    tc qdisc add dev lo parent 3:1 handle 4: blackhole

    echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888
    tc class delete dev lo classid 1:1
    echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888

Since backlog accounting issues leading to a use-after-frees on stale
class pointers is a recurring pattern at this point, this patch takes
a different approach. Instead of trying to fix the accounting, the patch
ensures that qdisc_tree_reduce_backlog always calls qlen_notify when
the child qdisc is empty. This solves the problem because deletion of
qdiscs always involves a call to qdisc_reset() and / or
qdisc_purge_queue() which ultimately resets its qlen to 0 thus causing
the following qdisc_tree_reduce_backlog() to report to the parent. Note
that this may call qlen_notify on passive classes multiple times. This
is not a problem after the recent patch series that made all the
classful qdiscs qlen_notify() handlers idempotent.</Note>
    </Notes>
    <CVE>CVE-2025-38350</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

posix-cpu-timers: fix race between handle_posix_cpu_timers() and posix_cpu_timer_del()

If an exiting non-autoreaping task has already passed exit_notify() and
calls handle_posix_cpu_timers() from IRQ, it can be reaped by its parent
or debugger right after unlock_task_sighand().

If a concurrent posix_cpu_timer_del() runs at that moment, it won't be
able to detect timer-&gt;it.cpu.firing != 0: cpu_timer_task_rcu() and/or
lock_task_sighand() will fail.

Add the tsk-&gt;exit_state check into run_posix_cpu_timers() to fix this.

This fix is not needed if CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y, because
exit_task_work() is called before exit_notify(). But the check still
makes sense, task_work_add(&amp;tsk-&gt;posix_cputimers_work.work) will fail
anyway in this case.</Note>
    </Notes>
    <CVE>CVE-2025-38352</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/xe: Fix taking invalid lock on wedge

If device wedges on e.g. GuC upload, the submission is not yet enabled
and the state is not even initialized. Protect the wedge call so it does
nothing in this case. It fixes the following splat:

	[] xe 0000:bf:00.0: [drm] device wedged, needs recovery
	[] ------------[ cut here ]------------
	[] DEBUG_LOCKS_WARN_ON(lock-&gt;magic != lock)
	[] WARNING: CPU: 48 PID: 312 at kernel/locking/mutex.c:564 __mutex_lock+0x8a1/0xe60
	...
	[] RIP: 0010:__mutex_lock+0x8a1/0xe60
	[]  mutex_lock_nested+0x1b/0x30
	[]  xe_guc_submit_wedge+0x80/0x2b0 [xe]</Note>
    </Notes>
    <CVE>CVE-2025-38353</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/msm/gpu: Fix crash when throttling GPU immediately during boot

There is a small chance that the GPU is already hot during boot. In that
case, the call to of_devfreq_cooling_register() will immediately try to
apply devfreq cooling, as seen in the following crash:

  Unable to handle kernel paging request at virtual address 0000000000014110
  pc : a6xx_gpu_busy+0x1c/0x58 [msm]
  lr : msm_devfreq_get_dev_status+0xbc/0x140 [msm]
  Call trace:
   a6xx_gpu_busy+0x1c/0x58 [msm] (P)
   devfreq_simple_ondemand_func+0x3c/0x150
   devfreq_update_target+0x44/0xd8
   qos_max_notifier_call+0x30/0x84
   blocking_notifier_call_chain+0x6c/0xa0
   pm_qos_update_target+0xd0/0x110
   freq_qos_apply+0x3c/0x74
   apply_constraint+0x88/0x148
   __dev_pm_qos_update_request+0x7c/0xcc
   dev_pm_qos_update_request+0x38/0x5c
   devfreq_cooling_set_cur_state+0x98/0xf0
   __thermal_cdev_update+0x64/0xb4
   thermal_cdev_update+0x4c/0x58
   step_wise_manage+0x1f0/0x318
   __thermal_zone_device_update+0x278/0x424
   __thermal_cooling_device_register+0x2bc/0x308
   thermal_of_cooling_device_register+0x10/0x1c
   of_devfreq_cooling_register_power+0x240/0x2bc
   of_devfreq_cooling_register+0x14/0x20
   msm_devfreq_init+0xc4/0x1a0 [msm]
   msm_gpu_init+0x304/0x574 [msm]
   adreno_gpu_init+0x1c4/0x2e0 [msm]
   a6xx_gpu_init+0x5c8/0x9c8 [msm]
   adreno_bind+0x2a8/0x33c [msm]
   ...

At this point we haven't initialized the GMU at all yet, so we cannot read
the GMU registers inside a6xx_gpu_busy(). A similar issue was fixed before
in commit 6694482a70e9 ("drm/msm: Avoid unclocked GMU register access in
6xx gpu_busy"): msm_devfreq_init() does call devfreq_suspend_device(), but
unlike msm_devfreq_suspend(), it doesn't set the df-&gt;suspended flag
accordingly. This means the df-&gt;suspended flag does not match the actual
devfreq state after initialization and msm_devfreq_get_dev_status() will
end up accessing GMU registers, causing the crash.

Fix this by setting df-&gt;suspended correctly during initialization.

Patchwork: https://patchwork.freedesktop.org/patch/650772/</Note>
    </Notes>
    <CVE>CVE-2025-38354</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/xe: Process deferred GGTT node removals on device unwind

While we are indirectly draining our dedicated workqueue ggtt-&gt;wq
that we use to complete asynchronous removal of some GGTT nodes,
this happends as part of the managed-drm unwinding (ggtt_fini_early),
which could be later then manage-device unwinding, where we could
already unmap our MMIO/GMS mapping (mmio_fini).

This was recently observed during unsuccessful VF initialization:

 [ ] xe 0000:00:02.1: probe with driver xe failed with error -62
 [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747340 __xe_bo_unpin_map_no_vm (16 bytes)
 [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747540 __xe_bo_unpin_map_no_vm (16 bytes)
 [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747240 __xe_bo_unpin_map_no_vm (16 bytes)
 [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747040 tiles_fini (16 bytes)
 [ ] xe 0000:00:02.1: DEVRES REL ffff88811e746840 mmio_fini (16 bytes)
 [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747f40 xe_bo_pinned_fini (16 bytes)
 [ ] xe 0000:00:02.1: DEVRES REL ffff88811e746b40 devm_drm_dev_init_release (16 bytes)
 [ ] xe 0000:00:02.1: [drm:drm_managed_release] drmres release begin
 [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef81640 __fini_relay (8 bytes)
 [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80d40 guc_ct_fini (8 bytes)
 [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80040 __drmm_mutex_release (8 bytes)
 [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80140 ggtt_fini_early (8 bytes)

and this was leading to:

 [ ] BUG: unable to handle page fault for address: ffffc900058162a0
 [ ] #PF: supervisor write access in kernel mode
 [ ] #PF: error_code(0x0002) - not-present page
 [ ] Oops: Oops: 0002 [#1] SMP NOPTI
 [ ] Tainted: [W]=WARN
 [ ] Workqueue: xe-ggtt-wq ggtt_node_remove_work_func [xe]
 [ ] RIP: 0010:xe_ggtt_set_pte+0x6d/0x350 [xe]
 [ ] Call Trace:
 [ ]  &lt;TASK&gt;
 [ ]  xe_ggtt_clear+0xb0/0x270 [xe]
 [ ]  ggtt_node_remove+0xbb/0x120 [xe]
 [ ]  ggtt_node_remove_work_func+0x30/0x50 [xe]
 [ ]  process_one_work+0x22b/0x6f0
 [ ]  worker_thread+0x1e8/0x3d

Add managed-device action that will explicitly drain the workqueue
with all pending node removals prior to releasing MMIO/GSM mapping.

(cherry picked from commit 89d2835c3680ab1938e22ad81b1c9f8c686bd391)</Note>
    </Notes>
    <CVE>CVE-2025-38355</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/xe/guc: Explicitly exit CT safe mode on unwind

During driver probe we might be briefly using CT safe mode, which
is based on a delayed work, but usually we are able to stop this
once we have IRQ fully operational.  However, if we abort the probe
quite early then during unwind we might try to destroy the workqueue
while there is still a pending delayed work that attempts to restart
itself which triggers a WARN.

This was recently observed during unsuccessful VF initialization:

 [ ] xe 0000:00:02.1: probe with driver xe failed with error -62
 [ ] ------------[ cut here ]------------
 [ ] workqueue: cannot queue safe_mode_worker_func [xe] on wq xe-g2h-wq
 [ ] WARNING: CPU: 9 PID: 0 at kernel/workqueue.c:2257 __queue_work+0x287/0x710
 [ ] RIP: 0010:__queue_work+0x287/0x710
 [ ] Call Trace:
 [ ]  delayed_work_timer_fn+0x19/0x30
 [ ]  call_timer_fn+0xa1/0x2a0

Exit the CT safe mode on unwind to avoid that warning.

(cherry picked from commit 2ddbb73ec20b98e70a5200cb85deade22ccea2ec)</Note>
    </Notes>
    <CVE>CVE-2025-38356</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check dce_hwseq before dereferencing it

[WHAT]

hws was checked for null earlier in dce110_blank_stream, indicating hws
can be null, and should be checked whenever it is used.

(cherry picked from commit 79db43611ff61280b6de58ce1305e0b2ecf675ad)</Note>
    </Notes>
    <CVE>CVE-2025-38361</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Add null pointer check for get_first_active_display()

The function mod_hdcp_hdcp1_enable_encryption() calls the function
get_first_active_display(), but does not check its return value.
The return value is a null pointer if the display list is empty.
This will lead to a null pointer dereference in
mod_hdcp_hdcp2_enable_encryption().

Add a null pointer check for get_first_active_display() and return
MOD_HDCP_STATUS_DISPLAY_NOT_FOUND if the function return null.</Note>
    </Notes>
    <CVE>CVE-2025-38362</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/tegra: Fix a possible null pointer dereference

In tegra_crtc_reset(), new memory is allocated with kzalloc(), but
no check is performed. Before calling __drm_atomic_helper_crtc_reset,
state should be checked to prevent possible null pointer dereference.</Note>
    </Notes>
    <CVE>CVE-2025-38363</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

maple_tree: fix MA_STATE_PREALLOC flag in mas_preallocate()

Temporarily clear the preallocation flag when explicitly requesting
allocations.  Pre-existing allocations are already counted against the
request through mas_node_count_gfp(), but the allocations will not happen
if the MA_STATE_PREALLOC flag is set.  This flag is meant to avoid
re-allocating in bulk allocation mode, and to detect issues with
preallocation calculations.

The MA_STATE_PREALLOC flag should also always be set on zero allocations
so that detection of underflow allocations will print a WARN_ON() during
consumption.

User visible effect of this flaw is a WARN_ON() followed by a null pointer
dereference when subsequent requests for larger number of nodes is
ignored, such as the vma merge retry in mmap_region() caused by drivers
altering the vma flags (which happens in v6.6, at least)</Note>
    </Notes>
    <CVE>CVE-2025-38364</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix a race between renames and directory logging

We have a race between a rename and directory inode logging that if it
happens and we crash/power fail before the rename completes, the next time
the filesystem is mounted, the log replay code will end up deleting the
file that was being renamed.

This is best explained following a step by step analysis of an interleaving
of steps that lead into this situation.

Consider the initial conditions:

1) We are at transaction N;

2) We have directories A and B created in a past transaction (&lt; N);

3) We have inode X corresponding to a file that has 2 hardlinks, one in
   directory A and the other in directory B, so we'll name them as
   "A/foo_link1" and "B/foo_link2". Both hard links were persisted in a
   past transaction (&lt; N);

4) We have inode Y corresponding to a file that as a single hard link and
   is located in directory A, we'll name it as "A/bar". This file was also
   persisted in a past transaction (&lt; N).

The steps leading to a file loss are the following and for all of them we
are under transaction N:

 1) Link "A/foo_link1" is removed, so inode's X last_unlink_trans field
    is updated to N, through btrfs_unlink() -&gt; btrfs_record_unlink_dir();

 2) Task A starts a rename for inode Y, with the goal of renaming from
    "A/bar" to "A/baz", so we enter btrfs_rename();

 3) Task A inserts the new BTRFS_INODE_REF_KEY for inode Y by calling
    btrfs_insert_inode_ref();

 4) Because the rename happens in the same directory, we don't set the
    last_unlink_trans field of directoty A's inode to the current
    transaction id, that is, we don't cal btrfs_record_unlink_dir();

 5) Task A then removes the entries from directory A (BTRFS_DIR_ITEM_KEY
    and BTRFS_DIR_INDEX_KEY items) when calling __btrfs_unlink_inode()
    (actually the dir index item is added as a delayed item, but the
    effect is the same);

 6) Now before task A adds the new entry "A/baz" to directory A by
    calling btrfs_add_link(), another task, task B is logging inode X;

 7) Task B starts a fsync of inode X and after logging inode X, at
    btrfs_log_inode_parent() it calls btrfs_log_all_parents(), since
    inode X has a last_unlink_trans value of N, set at in step 1;

 8) At btrfs_log_all_parents() we search for all parent directories of
    inode X using the commit root, so we find directories A and B and log
    them. Bu when logging direct A, we don't have a dir index item for
    inode Y anymore, neither the old name "A/bar" nor for the new name
    "A/baz" since the rename has deleted the old name but has not yet
    inserted the new name - task A hasn't called yet btrfs_add_link() to
    do that.

    Note that logging directory A doesn't fallback to a transaction
    commit because its last_unlink_trans has a lower value than the
    current transaction's id (see step 4);

 9) Task B finishes logging directories A and B and gets back to
    btrfs_sync_file() where it calls btrfs_sync_log() to persist the log
    tree;

10) Task B successfully persisted the log tree, btrfs_sync_log() completed
    with success, and a power failure happened.

    We have a log tree without any directory entry for inode Y, so the
    log replay code deletes the entry for inode Y, name "A/bar", from the
    subvolume tree since it doesn't exist in the log tree and the log
    tree is authorative for its index (we logged a BTRFS_DIR_LOG_INDEX_KEY
    item that covers the index range for the dentry that corresponds to
    "A/bar").

    Since there's no other hard link for inode Y and the log replay code
    deletes the name "A/bar", the file is lost.

The issue wouldn't happen if task B synced the log only after task A
called btrfs_log_new_name(), which would update the log with the new name
for inode Y ("A/bar").

Fix this by pinning the log root during renames before removing the old
directory entry, and unpinning af
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-38365</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

dmaengine: idxd: Check availability of workqueue allocated by idxd wq driver before using

Running IDXD workloads in a container with the /dev directory mounted can
trigger a call trace or even a kernel panic when the parent process of the
container is terminated.

This issue occurs because, under certain configurations, Docker does not
properly propagate the mount replica back to the original mount point.

In this case, when the user driver detaches, the WQ is destroyed but it
still calls destroy_workqueue() attempting to completes all pending work.
It's necessary to check wq-&gt;wq and skip the drain if it no longer exists.</Note>
    </Notes>
    <CVE>CVE-2025-38369</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/v3d: Disable interrupts before resetting the GPU

Currently, an interrupt can be triggered during a GPU reset, which can
lead to GPU hangs and NULL pointer dereference in an interrupt context
as shown in the following trace:

 [  314.035040] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000c0
 [  314.043822] Mem abort info:
 [  314.046606]   ESR = 0x0000000096000005
 [  314.050347]   EC = 0x25: DABT (current EL), IL = 32 bits
 [  314.055651]   SET = 0, FnV = 0
 [  314.058695]   EA = 0, S1PTW = 0
 [  314.061826]   FSC = 0x05: level 1 translation fault
 [  314.066694] Data abort info:
 [  314.069564]   ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
 [  314.075039]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
 [  314.080080]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
 [  314.085382] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000102728000
 [  314.091814] [00000000000000c0] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000
 [  314.100511] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP
 [  314.106770] Modules linked in: v3d i2c_brcmstb vc4 snd_soc_hdmi_codec gpu_sched drm_shmem_helper drm_display_helper cec drm_dma_helper drm_kms_helper drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight
 [  314.129654] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.25+rpt-rpi-v8 #1  Debian 1:6.12.25-1+rpt1
 [  314.139388] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT)
 [  314.145211] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 [  314.152165] pc : v3d_irq+0xec/0x2e0 [v3d]
 [  314.156187] lr : v3d_irq+0xe0/0x2e0 [v3d]
 [  314.160198] sp : ffffffc080003ea0
 [  314.163502] x29: ffffffc080003ea0 x28: ffffffec1f184980 x27: 021202b000000000
 [  314.170633] x26: ffffffec1f17f630 x25: ffffff8101372000 x24: ffffffec1f17d9f0
 [  314.177764] x23: 000000000000002a x22: 000000000000002a x21: ffffff8103252000
 [  314.184895] x20: 0000000000000001 x19: 00000000deadbeef x18: 0000000000000000
 [  314.192026] x17: ffffff94e51d2000 x16: ffffffec1dac3cb0 x15: c306000000000000
 [  314.199156] x14: 0000000000000000 x13: b2fc982e03cc5168 x12: 0000000000000001
 [  314.206286] x11: ffffff8103f8bcc0 x10: ffffffec1f196868 x9 : ffffffec1dac3874
 [  314.213416] x8 : 0000000000000000 x7 : 0000000000042a3a x6 : ffffff810017a180
 [  314.220547] x5 : ffffffec1ebad400 x4 : ffffffec1ebad320 x3 : 00000000000bebeb
 [  314.227677] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000
 [  314.234807] Call trace:
 [  314.237243]  v3d_irq+0xec/0x2e0 [v3d]
 [  314.240906]  __handle_irq_event_percpu+0x58/0x218
 [  314.245609]  handle_irq_event+0x54/0xb8
 [  314.249439]  handle_fasteoi_irq+0xac/0x240
 [  314.253527]  handle_irq_desc+0x48/0x68
 [  314.257269]  generic_handle_domain_irq+0x24/0x38
 [  314.261879]  gic_handle_irq+0x48/0xd8
 [  314.265533]  call_on_irq_stack+0x24/0x58
 [  314.269448]  do_interrupt_handler+0x88/0x98
 [  314.273624]  el1_interrupt+0x34/0x68
 [  314.277193]  el1h_64_irq_handler+0x18/0x28
 [  314.281281]  el1h_64_irq+0x64/0x68
 [  314.284673]  default_idle_call+0x3c/0x168
 [  314.288675]  do_idle+0x1fc/0x230
 [  314.291895]  cpu_startup_entry+0x3c/0x50
 [  314.295810]  rest_init+0xe4/0xf0
 [  314.299030]  start_kernel+0x5e8/0x790
 [  314.302684]  __primary_switched+0x80/0x90
 [  314.306691] Code: 940029eb 360ffc13 f9442ea0 52800001 (f9406017)
 [  314.312775] ---[ end trace 0000000000000000 ]---
 [  314.317384] Kernel panic - not syncing: Oops: Fatal exception in interrupt
 [  314.324249] SMP: stopping secondary CPUs
 [  314.328167] Kernel Offset: 0x2b9da00000 from 0xffffffc080000000
 [  314.334076] PHYS_OFFSET: 0x0
 [  314.336946] CPU features: 0x08,00002013,c0200000,0200421b
 [  314.342337] Memory Limit: none
 [  314.345382] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---

Before resetting the G
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-38371</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

IB/mlx5: Fix potential deadlock in MR deregistration

The issue arises when kzalloc() is invoked while holding umem_mutex or
any other lock acquired under umem_mutex. This is problematic because
kzalloc() can trigger fs_reclaim_aqcuire(), which may, in turn, invoke
mmu_notifier_invalidate_range_start(). This function can lead to
mlx5_ib_invalidate_range(), which attempts to acquire umem_mutex again,
resulting in a deadlock.

The problematic flow:
             CPU0                      |              CPU1
---------------------------------------|------------------------------------------------
mlx5_ib_dereg_mr()                     |
 -&gt; revoke_mr()                         |
   -&gt; mutex_lock(&amp;umem_odp-&gt;umem_mutex) |
                                       | mlx5_mkey_cache_init()
                                       |  -&gt; mutex_lock(&amp;dev-&gt;cache.rb_lock)
                                       |  -&gt; mlx5r_cache_create_ent_locked()
                                       |    -&gt; kzalloc(GFP_KERNEL)
                                       |      -&gt; fs_reclaim()
                                       |        -&gt; mmu_notifier_invalidate_range_start()
                                       |          -&gt; mlx5_ib_invalidate_range()
                                       |            -&gt; mutex_lock(&amp;umem_odp-&gt;umem_mutex)
   -&gt; cache_ent_find_and_store()        |
     -&gt; mutex_lock(&amp;dev-&gt;cache.rb_lock) |

Additionally, when kzalloc() is called from within
cache_ent_find_and_store(), we encounter the same deadlock due to
re-acquisition of umem_mutex.

Solve by releasing umem_mutex in dereg_mr() after umr_revoke_mr()
and before acquiring rb_lock. This ensures that we don't hold
umem_mutex while performing memory allocations that could trigger
the reclaim path.

This change prevents the deadlock by ensuring proper lock ordering and
avoiding holding locks during memory allocation operations that could
trigger the reclaim path.

The following lockdep warning demonstrates the deadlock:

 python3/20557 is trying to acquire lock:
 ffff888387542128 (&amp;umem_odp-&gt;umem_mutex){+.+.}-{4:4}, at:
 mlx5_ib_invalidate_range+0x5b/0x550 [mlx5_ib]

 but task is already holding lock:
 ffffffff82f6b840 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}, at:
 unmap_vmas+0x7b/0x1a0

 which lock already depends on the new lock.

 the existing dependency chain (in reverse order) is:

 -&gt; #3 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}:
       fs_reclaim_acquire+0x60/0xd0
       mem_cgroup_css_alloc+0x6f/0x9b0
       cgroup_init_subsys+0xa4/0x240
       cgroup_init+0x1c8/0x510
       start_kernel+0x747/0x760
       x86_64_start_reservations+0x25/0x30
       x86_64_start_kernel+0x73/0x80
       common_startup_64+0x129/0x138

 -&gt; #2 (fs_reclaim){+.+.}-{0:0}:
       fs_reclaim_acquire+0x91/0xd0
       __kmalloc_cache_noprof+0x4d/0x4c0
       mlx5r_cache_create_ent_locked+0x75/0x620 [mlx5_ib]
       mlx5_mkey_cache_init+0x186/0x360 [mlx5_ib]
       mlx5_ib_stage_post_ib_reg_umr_init+0x3c/0x60 [mlx5_ib]
       __mlx5_ib_add+0x4b/0x190 [mlx5_ib]
       mlx5r_probe+0xd9/0x320 [mlx5_ib]
       auxiliary_bus_probe+0x42/0x70
       really_probe+0xdb/0x360
       __driver_probe_device+0x8f/0x130
       driver_probe_device+0x1f/0xb0
       __driver_attach+0xd4/0x1f0
       bus_for_each_dev+0x79/0xd0
       bus_add_driver+0xf0/0x200
       driver_register+0x6e/0xc0
       __auxiliary_driver_register+0x6a/0xc0
       do_one_initcall+0x5e/0x390
       do_init_module+0x88/0x240
       init_module_from_file+0x85/0xc0
       idempotent_init_module+0x104/0x300
       __x64_sys_finit_module+0x68/0xc0
       do_syscall_64+0x6d/0x140
       entry_SYSCALL_64_after_hwframe+0x4b/0x53

 -&gt; #1 (&amp;dev-&gt;cache.rb_lock){+.+.}-{4:4}:
       __mutex_lock+0x98/0xf10
       __mlx5_ib_dereg_mr+0x6f2/0x890 [mlx5_ib]
       mlx5_ib_dereg_mr+0x21/0x110 [mlx5_ib]
       ib_dereg_mr_user+0x85/0x1f0 [ib_core]
  
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-38373</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

virtio-net: ensure the received length does not exceed allocated size

In xdp_linearize_page, when reading the following buffers from the ring,
we forget to check the received length with the true allocate size. This
can lead to an out-of-bound read. This commit adds that missing check.</Note>
    </Notes>
    <CVE>CVE-2025-38375</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: chipidea: udc: disconnect/reconnect from host when do suspend/resume

Shawn and John reported a hang issue during system suspend as below:

 - USB gadget is enabled as Ethernet
 - There is data transfer over USB Ethernet (scp a big file between host
                                             and device)
 - Device is going in/out suspend (echo mem &gt; /sys/power/state)

The root cause is the USB device controller is suspended but the USB bus
is still active which caused the USB host continues to transfer data with
device and the device continues to queue USB requests (in this case, a
delayed TCP ACK packet trigger the issue) after controller is suspended,
however the USB controller clock is already gated off. Then if udc driver
access registers after that point, the system will hang.

The correct way to avoid such issue is to disconnect device from host when
the USB bus is not at suspend state. Then the host will receive disconnect
event and stop data transfer in time. To continue make USB gadget device
work after system resume, this will reconnect device automatically.

To make usb wakeup work if USB bus is already at suspend state, this will
keep connection for it only when USB device controller has enabled wakeup
capability.</Note>
    </Notes>
    <CVE>CVE-2025-38376</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

rose: fix dangling neighbour pointers in rose_rt_device_down()

There are two bugs in rose_rt_device_down() that can cause
use-after-free:

1. The loop bound `t-&gt;count` is modified within the loop, which can
   cause the loop to terminate early and miss some entries.

2. When removing an entry from the neighbour array, the subsequent entries
   are moved up to fill the gap, but the loop index `i` is still
   incremented, causing the next entry to be skipped.

For example, if a node has three neighbours (A, A, B) with count=3 and A
is being removed, the second A is not checked.

    i=0: (A, A, B) -&gt; (A, B) with count=2
          ^ checked
    i=1: (A, B)    -&gt; (A, B) with count=2
             ^ checked (B, not A!)
    i=2: (doesn't occur because i &lt; count is false)

This leaves the second A in the array with count=2, but the rose_neigh
structure has been freed. Code that accesses these entries assumes that
the first `count` entries are valid pointers, causing a use-after-free
when it accesses the dangling pointer.

Fix both issues by iterating over the array in reverse order with a fixed
loop bound. This ensures that all entries are examined and that the removal
of an entry doesn't affect subsequent iterations.</Note>
    </Notes>
    <CVE>CVE-2025-38377</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
    </Notes>
    <CVE>CVE-2025-38380</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix iteration of extrefs during log replay

At __inode_add_ref() when processing extrefs, if we jump into the next
label we have an undefined value of victim_name.len, since we haven't
initialized it before we did the goto. This results in an invalid memory
access in the next iteration of the loop since victim_name.len was not
initialized to the length of the name of the current extref.

Fix this by initializing victim_name.len with the current extref's name
length.</Note>
    </Notes>
    <CVE>CVE-2025-38382</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mtd: spinand: fix memory leak of ECC engine conf

Memory allocated for the ECC engine conf is not released during spinand
cleanup. Below kmemleak trace is seen for this memory leak:

unreferenced object 0xffffff80064f00e0 (size 8):
  comm "swapper/0", pid 1, jiffies 4294937458
  hex dump (first 8 bytes):
    00 00 00 00 00 00 00 00                          ........
  backtrace (crc 0):
    kmemleak_alloc+0x30/0x40
    __kmalloc_cache_noprof+0x208/0x3c0
    spinand_ondie_ecc_init_ctx+0x114/0x200
    nand_ecc_init_ctx+0x70/0xa8
    nanddev_ecc_engine_init+0xec/0x27c
    spinand_probe+0xa2c/0x1620
    spi_mem_probe+0x130/0x21c
    spi_probe+0xf0/0x170
    really_probe+0x17c/0x6e8
    __driver_probe_device+0x17c/0x21c
    driver_probe_device+0x58/0x180
    __device_attach_driver+0x15c/0x1f8
    bus_for_each_drv+0xec/0x150
    __device_attach+0x188/0x24c
    device_initial_probe+0x10/0x20
    bus_probe_device+0x11c/0x160

Fix the leak by calling nanddev_ecc_engine_cleanup() inside
spinand_cleanup().</Note>
    </Notes>
    <CVE>CVE-2025-38384</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: usb: lan78xx: fix WARN in __netif_napi_del_locked on disconnect

Remove redundant netif_napi_del() call from disconnect path.

A WARN may be triggered in __netif_napi_del_locked() during USB device
disconnect:

  WARNING: CPU: 0 PID: 11 at net/core/dev.c:7417 __netif_napi_del_locked+0x2b4/0x350

This happens because netif_napi_del() is called in the disconnect path while
NAPI is still enabled. However, it is not necessary to call netif_napi_del()
explicitly, since unregister_netdev() will handle NAPI teardown automatically
and safely. Removing the redundant call avoids triggering the warning.

Full trace:
 lan78xx 1-1:1.0 enu1: Failed to read register index 0x000000c4. ret = -ENODEV
 lan78xx 1-1:1.0 enu1: Failed to set MAC down with error -ENODEV
 lan78xx 1-1:1.0 enu1: Link is Down
 lan78xx 1-1:1.0 enu1: Failed to read register index 0x00000120. ret = -ENODEV
 ------------[ cut here ]------------
 WARNING: CPU: 0 PID: 11 at net/core/dev.c:7417 __netif_napi_del_locked+0x2b4/0x350
 Modules linked in: flexcan can_dev fuse
 CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 6.16.0-rc2-00624-ge926949dab03 #9 PREEMPT
 Hardware name: SKOV IMX8MP CPU revC - bd500 (DT)
 Workqueue: usb_hub_wq hub_event
 pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 pc : __netif_napi_del_locked+0x2b4/0x350
 lr : __netif_napi_del_locked+0x7c/0x350
 sp : ffffffc085b673c0
 x29: ffffffc085b673c0 x28: ffffff800b7f2000 x27: ffffff800b7f20d8
 x26: ffffff80110bcf58 x25: ffffff80110bd978 x24: 1ffffff0022179eb
 x23: ffffff80110bc000 x22: ffffff800b7f5000 x21: ffffff80110bc000
 x20: ffffff80110bcf38 x19: ffffff80110bcf28 x18: dfffffc000000000
 x17: ffffffc081578940 x16: ffffffc08284cee0 x15: 0000000000000028
 x14: 0000000000000006 x13: 0000000000040000 x12: ffffffb0022179e8
 x11: 1ffffff0022179e7 x10: ffffffb0022179e7 x9 : dfffffc000000000
 x8 : 0000004ffdde8619 x7 : ffffff80110bcf3f x6 : 0000000000000001
 x5 : ffffff80110bcf38 x4 : ffffff80110bcf38 x3 : 0000000000000000
 x2 : 0000000000000000 x1 : 1ffffff0022179e7 x0 : 0000000000000000
 Call trace:
  __netif_napi_del_locked+0x2b4/0x350 (P)
  lan78xx_disconnect+0xf4/0x360
  usb_unbind_interface+0x158/0x718
  device_remove+0x100/0x150
  device_release_driver_internal+0x308/0x478
  device_release_driver+0x1c/0x30
  bus_remove_device+0x1a8/0x368
  device_del+0x2e0/0x7b0
  usb_disable_device+0x244/0x540
  usb_disconnect+0x220/0x758
  hub_event+0x105c/0x35e0
  process_one_work+0x760/0x17b0
  worker_thread+0x768/0xce8
  kthread+0x3bc/0x690
  ret_from_fork+0x10/0x20
 irq event stamp: 211604
 hardirqs last  enabled at (211603): [&lt;ffffffc0828cc9ec&gt;] _raw_spin_unlock_irqrestore+0x84/0x98
 hardirqs last disabled at (211604): [&lt;ffffffc0828a9a84&gt;] el1_dbg+0x24/0x80
 softirqs last  enabled at (211296): [&lt;ffffffc080095f10&gt;] handle_softirqs+0x820/0xbc8
 softirqs last disabled at (210993): [&lt;ffffffc080010288&gt;] __do_softirq+0x18/0x20
 ---[ end trace 0000000000000000 ]---
 lan78xx 1-1:1.0 enu1: failed to kill vid 0081/0</Note>
    </Notes>
    <CVE>CVE-2025-38385</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ACPICA: Refuse to evaluate a method if arguments are missing

As reported in [1], a platform firmware update that increased the number
of method parameters and forgot to update a least one of its callers,
caused ACPICA to crash due to use-after-free.

Since this a result of a clear AML issue that arguably cannot be fixed
up by the interpreter (it cannot produce missing data out of thin air),
address it by making ACPICA refuse to evaluate a method if the caller
attempts to pass fewer arguments than expected to it.</Note>
    </Notes>
    <CVE>CVE-2025-38386</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/mlx5: Initialize obj_event-&gt;obj_sub_list before xa_insert

The obj_event may be loaded immediately after inserted, then if the
list_head is not initialized then we may get a poisonous pointer.  This
fixes the crash below:

 mlx5_core 0000:03:00.0: MLX5E: StrdRq(1) RqSz(8) StrdSz(2048) RxCqeCmprss(0 enhanced)
 mlx5_core.sf mlx5_core.sf.4: firmware version: 32.38.3056
 mlx5_core 0000:03:00.0 en3f0pf0sf2002: renamed from eth0
 mlx5_core.sf mlx5_core.sf.4: Rate limit: 127 rates are supported, range: 0Mbps to 195312Mbps
 IPv6: ADDRCONF(NETDEV_CHANGE): en3f0pf0sf2002: link becomes ready
 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060
 Mem abort info:
   ESR = 0x96000006
   EC = 0x25: DABT (current EL), IL = 32 bits
   SET = 0, FnV = 0
   EA = 0, S1PTW = 0
 Data abort info:
   ISV = 0, ISS = 0x00000006
   CM = 0, WnR = 0
 user pgtable: 4k pages, 48-bit VAs, pgdp=00000007760fb000
 [0000000000000060] pgd=000000076f6d7003, p4d=000000076f6d7003, pud=0000000777841003, pmd=0000000000000000
 Internal error: Oops: 96000006 [#1] SMP
 Modules linked in: ipmb_host(OE) act_mirred(E) cls_flower(E) sch_ingress(E) mptcp_diag(E) udp_diag(E) raw_diag(E) unix_diag(E) tcp_diag(E) inet_diag(E) binfmt_misc(E) bonding(OE) rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) isofs(E) cdrom(E) mst_pciconf(OE) ib_umad(OE) mlx5_ib(OE) ipmb_dev_int(OE) mlx5_core(OE) kpatch_15237886(OEK) mlxdevm(OE) auxiliary(OE) ib_uverbs(OE) ib_core(OE) psample(E) mlxfw(OE) tls(E) sunrpc(E) vfat(E) fat(E) crct10dif_ce(E) ghash_ce(E) sha1_ce(E) sbsa_gwdt(E) virtio_console(E) ext4(E) mbcache(E) jbd2(E) xfs(E) libcrc32c(E) mmc_block(E) virtio_net(E) net_failover(E) failover(E) sha2_ce(E) sha256_arm64(E) nvme(OE) nvme_core(OE) gpio_mlxbf3(OE) mlx_compat(OE) mlxbf_pmc(OE) i2c_mlxbf(OE) sdhci_of_dwcmshc(OE) pinctrl_mlxbf3(OE) mlxbf_pka(OE) gpio_generic(E) i2c_core(E) mmc_core(E) mlxbf_gige(OE) vitesse(E) pwr_mlxbf(OE) mlxbf_tmfifo(OE) micrel(E) mlxbf_bootctl(OE) virtio_ring(E) virtio(E) ipmi_devintf(E) ipmi_msghandler(E)
  [last unloaded: mst_pci]
 CPU: 11 PID: 20913 Comm: rte-worker-11 Kdump: loaded Tainted: G           OE K   5.10.134-13.1.an8.aarch64 #1
 Hardware name: https://www.mellanox.com BlueField-3 SmartNIC Main Card/BlueField-3 SmartNIC Main Card, BIOS 4.2.2.12968 Oct 26 2023
 pstate: a0400089 (NzCv daIf +PAN -UAO -TCO BTYPE=--)
 pc : dispatch_event_fd+0x68/0x300 [mlx5_ib]
 lr : devx_event_notifier+0xcc/0x228 [mlx5_ib]
 sp : ffff80001005bcf0
 x29: ffff80001005bcf0 x28: 0000000000000001
 x27: ffff244e0740a1d8 x26: ffff244e0740a1d0
 x25: ffffda56beff5ae0 x24: ffffda56bf911618
 x23: ffff244e0596a480 x22: ffff244e0596a480
 x21: ffff244d8312ad90 x20: ffff244e0596a480
 x19: fffffffffffffff0 x18: 0000000000000000
 x17: 0000000000000000 x16: ffffda56be66d620
 x15: 0000000000000000 x14: 0000000000000000
 x13: 0000000000000000 x12: 0000000000000000
 x11: 0000000000000040 x10: ffffda56bfcafb50
 x9 : ffffda5655c25f2c x8 : 0000000000000010
 x7 : 0000000000000000 x6 : ffff24545a2e24b8
 x5 : 0000000000000003 x4 : ffff80001005bd28
 x3 : 0000000000000000 x2 : 0000000000000000
 x1 : ffff244e0596a480 x0 : ffff244d8312ad90
 Call trace:
  dispatch_event_fd+0x68/0x300 [mlx5_ib]
  devx_event_notifier+0xcc/0x228 [mlx5_ib]
  atomic_notifier_call_chain+0x58/0x80
  mlx5_eq_async_int+0x148/0x2b0 [mlx5_core]
  atomic_notifier_call_chain+0x58/0x80
  irq_int_handler+0x20/0x30 [mlx5_core]
  __handle_irq_event_percpu+0x60/0x220
  handle_irq_event_percpu+0x3c/0x90
  handle_irq_event+0x58/0x158
  handle_fasteoi_irq+0xfc/0x188
  generic_handle_irq+0x34/0x48
  ...</Note>
    </Notes>
    <CVE>CVE-2025-38387</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/i915/gt: Fix timeline left held on VMA alloc error

The following error has been reported sporadically by CI when a test
unbinds the i915 driver on a ring submission platform:

&lt;4&gt; [239.330153] ------------[ cut here ]------------
&lt;4&gt; [239.330166] i915 0000:00:02.0: [drm] drm_WARN_ON(dev_priv-&gt;mm.shrink_count)
&lt;4&gt; [239.330196] WARNING: CPU: 1 PID: 18570 at drivers/gpu/drm/i915/i915_gem.c:1309 i915_gem_cleanup_early+0x13e/0x150 [i915]
...
&lt;4&gt; [239.330640] RIP: 0010:i915_gem_cleanup_early+0x13e/0x150 [i915]
...
&lt;4&gt; [239.330942] Call Trace:
&lt;4&gt; [239.330944]  &lt;TASK&gt;
&lt;4&gt; [239.330949]  i915_driver_late_release+0x2b/0xa0 [i915]
&lt;4&gt; [239.331202]  i915_driver_release+0x86/0xa0 [i915]
&lt;4&gt; [239.331482]  devm_drm_dev_init_release+0x61/0x90
&lt;4&gt; [239.331494]  devm_action_release+0x15/0x30
&lt;4&gt; [239.331504]  release_nodes+0x3d/0x120
&lt;4&gt; [239.331517]  devres_release_all+0x96/0xd0
&lt;4&gt; [239.331533]  device_unbind_cleanup+0x12/0x80
&lt;4&gt; [239.331543]  device_release_driver_internal+0x23a/0x280
&lt;4&gt; [239.331550]  ? bus_find_device+0xa5/0xe0
&lt;4&gt; [239.331563]  device_driver_detach+0x14/0x20
...
&lt;4&gt; [357.719679] ---[ end trace 0000000000000000 ]---

If the test also unloads the i915 module then that's followed with:

&lt;3&gt; [357.787478] =============================================================================
&lt;3&gt; [357.788006] BUG i915_vma (Tainted: G     U  W        N ): Objects remaining on __kmem_cache_shutdown()
&lt;3&gt; [357.788031] -----------------------------------------------------------------------------
&lt;3&gt; [357.788204] Object 0xffff888109e7f480 @offset=29824
&lt;3&gt; [357.788670] Allocated in i915_vma_instance+0xee/0xc10 [i915] age=292729 cpu=4 pid=2244
&lt;4&gt; [357.788994]  i915_vma_instance+0xee/0xc10 [i915]
&lt;4&gt; [357.789290]  init_status_page+0x7b/0x420 [i915]
&lt;4&gt; [357.789532]  intel_engines_init+0x1d8/0x980 [i915]
&lt;4&gt; [357.789772]  intel_gt_init+0x175/0x450 [i915]
&lt;4&gt; [357.790014]  i915_gem_init+0x113/0x340 [i915]
&lt;4&gt; [357.790281]  i915_driver_probe+0x847/0xed0 [i915]
&lt;4&gt; [357.790504]  i915_pci_probe+0xe6/0x220 [i915]
...

Closer analysis of CI results history has revealed a dependency of the
error on a few IGT tests, namely:
- igt@api_intel_allocator@fork-simple-stress-signal,
- igt@api_intel_allocator@two-level-inception-interruptible,
- igt@gem_linear_blits@interruptible,
- igt@prime_mmap_coherency@ioctl-errors,
which invisibly trigger the issue, then exhibited with first driver unbind
attempt.

All of the above tests perform actions which are actively interrupted with
signals.  Further debugging has allowed to narrow that scope down to
DRM_IOCTL_I915_GEM_EXECBUFFER2, and ring_context_alloc(), specific to ring
submission, in particular.

If successful then that function, or its execlists or GuC submission
equivalent, is supposed to be called only once per GEM context engine,
followed by raise of a flag that prevents the function from being called
again.  The function is expected to unwind its internal errors itself, so
it may be safely called once more after it returns an error.

In case of ring submission, the function first gets a reference to the
engine's legacy timeline and then allocates a VMA.  If the VMA allocation
fails, e.g. when i915_vma_instance() called from inside is interrupted
with a signal, then ring_context_alloc() fails, leaving the timeline held
referenced.  On next I915_GEM_EXECBUFFER2 IOCTL, another reference to the
timeline is got, and only that last one is put on successful completion.
As a consequence, the legacy timeline, with its underlying engine status
page's VMA object, is still held and not released on driver unbind.

Get the legacy timeline only after successful allocation of the context
engine's VMA.

v2: Add a note on other submission methods (Krzysztof Karas):
    Both execlists and GuC submission use lrc_alloc() which seems free
    from a similar issue.

(cherry picked from commit cc43422b3cc79eacff4c5a8ba0d224688ca9dd4f)</Note>
    </Notes>
    <CVE>CVE-2025-38389</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: typec: altmodes/displayport: do not index invalid pin_assignments

A poorly implemented DisplayPort Alt Mode port partner can indicate
that its pin assignment capabilities are greater than the maximum
value, DP_PIN_ASSIGN_F. In this case, calls to pin_assignment_show
will cause a BRK exception due to an out of bounds array access.

Prevent for loop in pin_assignment_show from accessing
invalid values in pin_assignments by adding DP_PIN_ASSIGN_MAX
value in typec_dp.h and using i &lt; DP_PIN_ASSIGN_MAX as a loop
condition.</Note>
    </Notes>
    <CVE>CVE-2025-38391</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

idpf: convert control queue mutex to a spinlock

With VIRTCHNL2_CAP_MACFILTER enabled, the following warning is generated
on module load:

[  324.701677] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:578
[  324.701684] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1582, name: NetworkManager
[  324.701689] preempt_count: 201, expected: 0
[  324.701693] RCU nest depth: 0, expected: 0
[  324.701697] 2 locks held by NetworkManager/1582:
[  324.701702]  #0: ffffffff9f7be770 (rtnl_mutex){....}-{3:3}, at: rtnl_newlink+0x791/0x21e0
[  324.701730]  #1: ff1100216c380368 (_xmit_ETHER){....}-{2:2}, at: __dev_open+0x3f0/0x870
[  324.701749] Preemption disabled at:
[  324.701752] [&lt;ffffffff9cd23b9d&gt;] __dev_open+0x3dd/0x870
[  324.701765] CPU: 30 UID: 0 PID: 1582 Comm: NetworkManager Not tainted 6.15.0-rc5+ #2 PREEMPT(voluntary)
[  324.701771] Hardware name: Intel Corporation M50FCP2SBSTD/M50FCP2SBSTD, BIOS SE5C741.86B.01.01.0001.2211140926 11/14/2022
[  324.701774] Call Trace:
[  324.701777]  &lt;TASK&gt;
[  324.701779]  dump_stack_lvl+0x5d/0x80
[  324.701788]  ? __dev_open+0x3dd/0x870
[  324.701793]  __might_resched.cold+0x1ef/0x23d
&lt;..&gt;
[  324.701818]  __mutex_lock+0x113/0x1b80
&lt;..&gt;
[  324.701917]  idpf_ctlq_clean_sq+0xad/0x4b0 [idpf]
[  324.701935]  ? kasan_save_track+0x14/0x30
[  324.701941]  idpf_mb_clean+0x143/0x380 [idpf]
&lt;..&gt;
[  324.701991]  idpf_send_mb_msg+0x111/0x720 [idpf]
[  324.702009]  idpf_vc_xn_exec+0x4cc/0x990 [idpf]
[  324.702021]  ? rcu_is_watching+0x12/0xc0
[  324.702035]  idpf_add_del_mac_filters+0x3ed/0xb50 [idpf]
&lt;..&gt;
[  324.702122]  __hw_addr_sync_dev+0x1cf/0x300
[  324.702126]  ? find_held_lock+0x32/0x90
[  324.702134]  idpf_set_rx_mode+0x317/0x390 [idpf]
[  324.702152]  __dev_open+0x3f8/0x870
[  324.702159]  ? __pfx___dev_open+0x10/0x10
[  324.702174]  __dev_change_flags+0x443/0x650
&lt;..&gt;
[  324.702208]  netif_change_flags+0x80/0x160
[  324.702218]  do_setlink.isra.0+0x16a0/0x3960
&lt;..&gt;
[  324.702349]  rtnl_newlink+0x12fd/0x21e0

The sequence is as follows:
	rtnl_newlink()-&gt;
	__dev_change_flags()-&gt;
	__dev_open()-&gt;
	dev_set_rx_mode() - &gt;  # disables BH and grabs "dev-&gt;addr_list_lock"
	idpf_set_rx_mode() -&gt;  # proceed only if VIRTCHNL2_CAP_MACFILTER is ON
	__dev_uc_sync() -&gt;
	idpf_add_mac_filter -&gt;
	idpf_add_del_mac_filters -&gt;
	idpf_send_mb_msg() -&gt;
	idpf_mb_clean() -&gt;
	idpf_ctlq_clean_sq()   # mutex_lock(cq_lock)

Fix by converting cq_lock to a spinlock. All operations under the new
lock are safe except freeing the DMA memory, which may use vunmap(). Fix
by requesting a contiguous physical memory for the DMA mapping.</Note>
    </Notes>
    <CVE>CVE-2025-38392</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

NFSv4/pNFS: Fix a race to wake on NFS_LAYOUT_DRAIN

We found a few different systems hung up in writeback waiting on the same
page lock, and one task waiting on the NFS_LAYOUT_DRAIN bit in
pnfs_update_layout(), however the pnfs_layout_hdr's plh_outstanding count
was zero.

It seems most likely that this is another race between the waiter and waker
similar to commit ed0172af5d6f ("SUNRPC: Fix a race to wake a sync task").
Fix it up by applying the advised barrier.</Note>
    </Notes>
    <CVE>CVE-2025-38393</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

regulator: gpio: Fix the out-of-bounds access to drvdata::gpiods

drvdata::gpiods is supposed to hold an array of 'gpio_desc' pointers. But
the memory is allocated for only one pointer. This will lead to
out-of-bounds access later in the code if 'config::ngpios' is &gt; 1. So
fix the code to allocate enough memory to hold 'config::ngpios' of GPIO
descriptors.

While at it, also move the check for memory allocation failure to be below
the allocation to make it more readable.</Note>
    </Notes>
    <CVE>CVE-2025-38395</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

fs: export anon_inode_make_secure_inode() and fix secretmem LSM bypass

Export anon_inode_make_secure_inode() to allow KVM guest_memfd to create
anonymous inodes with proper security context. This replaces the current
pattern of calling alloc_anon_inode() followed by
inode_init_security_anon() for creating security context manually.

This change also fixes a security regression in secretmem where the
S_PRIVATE flag was not cleared after alloc_anon_inode(), causing
LSM/SELinux checks to be bypassed for secretmem file descriptors.

As guest_memfd currently resides in the KVM module, we need to export this
symbol for use outside the core kernel. In the future, guest_memfd might be
moved to core-mm, at which point the symbols no longer would have to be
exported. When/if that happens is still unclear.</Note>
    </Notes>
    <CVE>CVE-2025-38396</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: target: Fix NULL pointer dereference in core_scsi3_decode_spec_i_port()

The function core_scsi3_decode_spec_i_port(), in its error code path,
unconditionally calls core_scsi3_lunacl_undepend_item() passing the
dest_se_deve pointer, which may be NULL.

This can lead to a NULL pointer dereference if dest_se_deve remains
unset.

SPC-3 PR SPEC_I_PT: Unable to locate dest_tpg
Unable to handle kernel paging request at virtual address dfff800000000012
Call trace:
  core_scsi3_lunacl_undepend_item+0x2c/0xf0 [target_core_mod] (P)
  core_scsi3_decode_spec_i_port+0x120c/0x1c30 [target_core_mod]
  core_scsi3_emulate_pro_register+0x6b8/0xcd8 [target_core_mod]
  target_scsi3_emulate_pr_out+0x56c/0x840 [target_core_mod]

Fix this by adding a NULL check before calling
core_scsi3_lunacl_undepend_item()</Note>
    </Notes>
    <CVE>CVE-2025-38399</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nfs: Clean up /proc/net/rpc/nfs when nfs_fs_proc_net_init() fails.

syzbot reported a warning below [1] following a fault injection in
nfs_fs_proc_net_init(). [0]

When nfs_fs_proc_net_init() fails, /proc/net/rpc/nfs is not removed.

Later, rpc_proc_exit() tries to remove /proc/net/rpc, and the warning
is logged as the directory is not empty.

Let's handle the error of nfs_fs_proc_net_init() properly.

[0]:
FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
CPU: 1 UID: 0 PID: 6120 Comm: syz.2.27 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
Call Trace:
 &lt;TASK&gt;
  dump_stack_lvl (lib/dump_stack.c:123)
 should_fail_ex (lib/fault-inject.c:73 lib/fault-inject.c:174)
 should_failslab (mm/failslab.c:46)
 kmem_cache_alloc_noprof (mm/slub.c:4178 mm/slub.c:4204)
 __proc_create (fs/proc/generic.c:427)
 proc_create_reg (fs/proc/generic.c:554)
 proc_create_net_data (fs/proc/proc_net.c:120)
 nfs_fs_proc_net_init (fs/nfs/client.c:1409)
 nfs_net_init (fs/nfs/inode.c:2600)
 ops_init (net/core/net_namespace.c:138)
 setup_net (net/core/net_namespace.c:443)
 copy_net_ns (net/core/net_namespace.c:576)
 create_new_namespaces (kernel/nsproxy.c:110)
 unshare_nsproxy_namespaces (kernel/nsproxy.c:218 (discriminator 4))
 ksys_unshare (kernel/fork.c:3123)
 __x64_sys_unshare (kernel/fork.c:3190)
 do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
 entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
 &lt;/TASK&gt;

[1]:
remove_proc_entry: removing non-empty directory 'net/rpc', leaking at least 'nfs'
 WARNING: CPU: 1 PID: 6120 at fs/proc/generic.c:727 remove_proc_entry+0x45e/0x530 fs/proc/generic.c:727
Modules linked in:
CPU: 1 UID: 0 PID: 6120 Comm: syz.2.27 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
 RIP: 0010:remove_proc_entry+0x45e/0x530 fs/proc/generic.c:727
Code: 3c 02 00 0f 85 85 00 00 00 48 8b 93 d8 00 00 00 4d 89 f0 4c 89 e9 48 c7 c6 40 ba a2 8b 48 c7 c7 60 b9 a2 8b e8 33 81 1d ff 90 &lt;0f&gt; 0b 90 90 e9 5f fe ff ff e8 04 69 5e ff 90 48 b8 00 00 00 00 00
RSP: 0018:ffffc90003637b08 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff88805f534140 RCX: ffffffff817a92c8
RDX: ffff88807da99e00 RSI: ffffffff817a92d5 RDI: 0000000000000001
RBP: ffff888033431ac0 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000001 R12: ffff888033431a00
R13: ffff888033431ae4 R14: ffff888033184724 R15: dffffc0000000000
FS:  0000555580328500(0000) GS:ffff888124a62000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f71733743e0 CR3: 000000007f618000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
  sunrpc_exit_net+0x46/0x90 net/sunrpc/sunrpc_syms.c:76
  ops_exit_list net/core/net_namespace.c:200 [inline]
  ops_undo_list+0x2eb/0xab0 net/core/net_namespace.c:253
  setup_net+0x2e1/0x510 net/core/net_namespace.c:457
  copy_net_ns+0x2a6/0x5f0 net/core/net_namespace.c:574
  create_new_namespaces+0x3ea/0xa90 kernel/nsproxy.c:110
  unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:218
  ksys_unshare+0x45b/0xa40 kernel/fork.c:3121
  __do_sys_unshare kernel/fork.c:3192 [inline]
  __se_sys_unshare kernel/fork.c:3190 [inline]
  __x64_sys_unshare+0x31/0x40 kernel/fork.c:3190
  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
  do_syscall_64+0xcd/0x490 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fa1a6b8e929
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-38400</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mtk-sd: Prevent memory corruption from DMA map failure

If msdc_prepare_data() fails to map the DMA region, the request is
not prepared for data receiving, but msdc_start_data() proceeds
the DMA with previous setting.
Since this will lead a memory corruption, we have to stop the
request operation soon after the msdc_prepare_data() fails to
prepare it.</Note>
    </Notes>
    <CVE>CVE-2025-38401</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vsock/vmci: Clear the vmci transport packet properly when initializing it

In vmci_transport_packet_init memset the vmci_transport_packet before
populating the fields to avoid any uninitialised data being left in the
structure.</Note>
    </Notes>
    <CVE>CVE-2025-38403</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: typec: displayport: Fix potential deadlock

The deadlock can occur due to a recursive lock acquisition of
`cros_typec_altmode_data::mutex`.
The call chain is as follows:
1. cros_typec_altmode_work() acquires the mutex
2. typec_altmode_vdm() -&gt; dp_altmode_vdm() -&gt;
3. typec_altmode_exit() -&gt; cros_typec_altmode_exit()
4. cros_typec_altmode_exit() attempts to acquire the mutex again

To prevent this, defer the `typec_altmode_exit()` call by scheduling
it rather than calling it directly from within the mutex-protected
context.</Note>
    </Notes>
    <CVE>CVE-2025-38404</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: ath6kl: remove WARN on bad firmware input

If the firmware gives bad input, that's nothing to do with
the driver's stack at this point etc., so the WARN_ON()
doesn't add any value. Additionally, this is one of the
top syzbot reports now. Just print a message, and as an
added bonus, print the sizes too.</Note>
    </Notes>
    <CVE>CVE-2025-38406</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/msm: Fix another leak in the submit error path

put_unused_fd() doesn't free the installed file, if we've already done
fd_install().  So we need to also free the sync_file.

Patchwork: https://patchwork.freedesktop.org/patch/653583/</Note>
    </Notes>
    <CVE>CVE-2025-38409</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/msm: Fix a fence leak in submit error path

In error paths, we could unref the submit without calling
drm_sched_entity_push_job(), so msm_job_free() will never get
called.  Since drm_sched_job_cleanup() will NULL out the
s_fence, we can use that to detect this case.

Patchwork: https://patchwork.freedesktop.org/patch/653584/</Note>
    </Notes>
    <CVE>CVE-2025-38410</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

platform/x86: dell-wmi-sysman: Fix WMI data block retrieval in sysfs callbacks

After retrieving WMI data blocks in sysfs callbacks, check for the
validity of them before dereferencing their content.</Note>
    </Notes>
    <CVE>CVE-2025-38412</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: fix GCC_GCC_PCIE_HOT_RST definition for WCN7850

GCC_GCC_PCIE_HOT_RST is wrongly defined for WCN7850, causing kernel crash
on some specific platforms.

Since this register is divergent for WCN7850 and QCN9274, move it to
register table to allow different definitions. Then correct the register
address for WCN7850 to fix this issue.

Note IPQ5332 is not affected as it is not PCIe based device.

Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3</Note>
    </Notes>
    <CVE>CVE-2025-38414</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Squashfs: check return result of sb_min_blocksize

Syzkaller reports an "UBSAN: shift-out-of-bounds in squashfs_bio_read" bug.

Syzkaller forks multiple processes which after mounting the Squashfs
filesystem, issues an ioctl("/dev/loop0", LOOP_SET_BLOCK_SIZE, 0x8000). 
Now if this ioctl occurs at the same time another process is in the
process of mounting a Squashfs filesystem on /dev/loop0, the failure
occurs.  When this happens the following code in squashfs_fill_super()
fails.

----
msblk-&gt;devblksize = sb_min_blocksize(sb, SQUASHFS_DEVBLK_SIZE);
msblk-&gt;devblksize_log2 = ffz(~msblk-&gt;devblksize);
----

sb_min_blocksize() returns 0, which means msblk-&gt;devblksize is set to 0.

As a result, ffz(~msblk-&gt;devblksize) returns 64, and msblk-&gt;devblksize_log2
is set to 64.

This subsequently causes the

UBSAN: shift-out-of-bounds in fs/squashfs/block.c:195:36
shift exponent 64 is too large for 64-bit type 'u64' (aka
'unsigned long long')

This commit adds a check for a 0 return by sb_min_blocksize().</Note>
    </Notes>
    <CVE>CVE-2025-38415</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

NFC: nci: uart: Set tty-&gt;disc_data only in success path

Setting tty-&gt;disc_data before opening the NCI device means we need to
clean it up on error paths.  This also opens some short window if device
starts sending data, even before NCIUARTSETDRIVER IOCTL succeeded
(broken hardware?).  Close the window by exposing tty-&gt;disc_data only on
the success path, when opening of the NCI device and try_module_get()
succeeds.

The code differs in error path in one aspect: tty-&gt;disc_data won't be
ever assigned thus NULL-ified.  This however should not be relevant
difference, because of "tty-&gt;disc_data=NULL" in nci_uart_tty_open().</Note>
    </Notes>
    <CVE>CVE-2025-38416</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ice: fix eswitch code memory leak in reset scenario

Add simple eswitch mode checker in attaching VF procedure and allocate
required port representor memory structures only in switchdev mode.
The reset flows triggers VF (if present) detach/attach procedure.
It might involve VF port representor(s) re-creation if the device is
configured is switchdev mode (not legacy one).
The memory was blindly allocated in current implementation,
regardless of the mode and not freed if in legacy mode.

Kmemeleak trace:
unreferenced object (percpu) 0x7e3bce5b888458 (size 40):
  comm "bash", pid 1784, jiffies 4295743894
  hex dump (first 32 bytes on cpu 45):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace (crc 0):
    pcpu_alloc_noprof+0x4c4/0x7c0
    ice_repr_create+0x66/0x130 [ice]
    ice_repr_create_vf+0x22/0x70 [ice]
    ice_eswitch_attach_vf+0x1b/0xa0 [ice]
    ice_reset_all_vfs+0x1dd/0x2f0 [ice]
    ice_pci_err_resume+0x3b/0xb0 [ice]
    pci_reset_function+0x8f/0x120
    reset_store+0x56/0xa0
    kernfs_fop_write_iter+0x120/0x1b0
    vfs_write+0x31c/0x430
    ksys_write+0x61/0xd0
    do_syscall_64+0x5b/0x180
    entry_SYSCALL_64_after_hwframe+0x76/0x7e

Testing hints (ethX is PF netdev):
- create at least one VF
    echo 1 &gt; /sys/class/net/ethX/device/sriov_numvfs
- trigger the reset
    echo 1 &gt; /sys/class/net/ethX/device/reset</Note>
    </Notes>
    <CVE>CVE-2025-38417</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: carl9170: do not ping device which has failed to load firmware

Syzkaller reports [1, 2] crashes caused by an attempts to ping
the device which has failed to load firmware. Since such a device
doesn't pass 'ieee80211_register_hw()', an internal workqueue
managed by 'ieee80211_queue_work()' is not yet created and an
attempt to queue work on it causes null-ptr-deref.

[1] https://syzkaller.appspot.com/bug?extid=9a4aec827829942045ff
[2] https://syzkaller.appspot.com/bug?extid=0d8afba53e8fb2633217</Note>
    </Notes>
    <CVE>CVE-2025-38420</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

perf: Fix sample vs do_exit()

Baisheng Gao reported an ARM64 crash, which Mark decoded as being a
synchronous external abort -- most likely due to trying to access
MMIO in bad ways.

The crash further shows perf trying to do a user stack sample while in
exit_mmap()'s tlb_finish_mmu() -- i.e. while tearing down the address
space it is trying to access.

It turns out that we stop perf after we tear down the userspace mm; a
receipie for disaster, since perf likes to access userspace for
various reasons.

Flip this order by moving up where we stop perf in do_exit().

Additionally, harden PERF_SAMPLE_CALLCHAIN and PERF_SAMPLE_STACK_USER
to abort when the current task does not have an mm (exit_mm() makes
sure to set current-&gt;mm = NULL; before commencing with the actual
teardown). Such that CPU wide events don't trip on this same problem.</Note>
    </Notes>
    <CVE>CVE-2025-38424</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

i2c: tegra: check msg length in SMBUS block read

For SMBUS block read, do not continue to read if the message length
passed from the device is '0' or greater than the maximum allowed bytes.</Note>
    </Notes>
    <CVE>CVE-2025-38425</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: Add basic validation for RAS header

If RAS header read from EEPROM is corrupted, it could result in trying
to allocate huge memory for reading the records. Add some validation to
header fields.</Note>
    </Notes>
    <CVE>CVE-2025-38426</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

video: screen_info: Relocate framebuffers behind PCI bridges

Apply PCI host-bridge window offsets to screen_info framebuffers. Fixes
invalid access to I/O memory.

Resources behind a PCI host bridge can be relocated by a certain offset
in the kernel's CPU address range used for I/O. The framebuffer memory
range stored in screen_info refers to the CPU addresses as seen during
boot (where the offset is 0). During boot up, firmware may assign a
different memory offset to the PCI host bridge and thereby relocating
the framebuffer address of the PCI graphics device as seen by the kernel.
The information in screen_info must be updated as well.

The helper pcibios_bus_to_resource() performs the relocation of the
screen_info's framebuffer resource (given in PCI bus addresses). The
result matches the I/O-memory resource of the PCI graphics device (given
in CPU addresses). As before, we store away the information necessary to
later update the information in screen_info itself.

Commit 78aa89d1dfba ("firmware/sysfb: Update screen_info for relocated
EFI framebuffers") added the code for updating screen_info. It is based
on similar functionality that pre-existed in efifb. Efifb uses a pointer
to the PCI resource, while the newer code does a memcpy of the region.
Hence efifb sees any updates to the PCI resource and avoids the issue.

v3:
- Only use struct pci_bus_region for PCI bus addresses (Bjorn)
- Clarify address semantics in commit messages and comments (Bjorn)
v2:
- Fixed tags (Takashi, Ivan)
- Updated information on efifb</Note>
    </Notes>
    <CVE>CVE-2025-38427</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Input: ims-pcu - check record size in ims_pcu_flash_firmware()

The "len" variable comes from the firmware and we generally do
trust firmware, but it's always better to double check.  If the "len"
is too large it could result in memory corruption when we do
"memcpy(fragment-&gt;data, rec-&gt;data, len);"</Note>
    </Notes>
    <CVE>CVE-2025-38428</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bus: mhi: ep: Update read pointer only after buffer is written

Inside mhi_ep_ring_add_element, the read pointer (rd_offset) is updated
before the buffer is written, potentially causing race conditions where
the host sees an updated read pointer before the buffer is actually
written. Updating rd_offset prematurely can lead to the host accessing
an uninitialized or incomplete element, resulting in data corruption.

Invoke the buffer write before updating rd_offset to ensure the element
is fully written before signaling its availability.</Note>
    </Notes>
    <CVE>CVE-2025-38429</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nfsd: nfsd4_spo_must_allow() must check this is a v4 compound request

If the request being processed is not a v4 compound request, then
examining the cstate can have undefined results.

This patch adds a check that the rpc procedure being executed
(rq_procinfo) is the NFSPROC4_COMPOUND procedure.</Note>
    </Notes>
    <CVE>CVE-2025-38430</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/scheduler: signal scheduled fence when kill job

When an entity from application B is killed, drm_sched_entity_kill()
removes all jobs belonging to that entity through
drm_sched_entity_kill_jobs_work(). If application A's job depends on a
scheduled fence from application B's job, and that fence is not properly
signaled during the killing process, application A's dependency cannot be
cleared.

This leads to application A hanging indefinitely while waiting for a
dependency that will never be resolved. Fix this issue by ensuring that
scheduled fences are properly signaled when an entity is killed, allowing
dependent applications to continue execution.</Note>
    </Notes>
    <CVE>CVE-2025-38436</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nbd: fix uaf in nbd_genl_connect() error path

There is a use-after-free issue in nbd:

block nbd6: Receive control failed (result -104)
block nbd6: shutting down sockets
==================================================================
BUG: KASAN: slab-use-after-free in recv_work+0x694/0xa80 drivers/block/nbd.c:1022
Write of size 4 at addr ffff8880295de478 by task kworker/u33:0/67

CPU: 2 UID: 0 PID: 67 Comm: kworker/u33:0 Not tainted 6.15.0-rc5-syzkaller-00123-g2c89c1b655c0 #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
Workqueue: nbd6-recv recv_work
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:408 [inline]
 print_report+0xc3/0x670 mm/kasan/report.c:521
 kasan_report+0xe0/0x110 mm/kasan/report.c:634
 check_region_inline mm/kasan/generic.c:183 [inline]
 kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189
 instrument_atomic_read_write include/linux/instrumented.h:96 [inline]
 atomic_dec include/linux/atomic/atomic-instrumented.h:592 [inline]
 recv_work+0x694/0xa80 drivers/block/nbd.c:1022
 process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238
 process_scheduled_works kernel/workqueue.c:3319 [inline]
 worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400
 kthread+0x3c2/0x780 kernel/kthread.c:464
 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
 &lt;/TASK&gt;

nbd_genl_connect() does not properly stop the device on certain
error paths after nbd_start_device() has been called. This causes
the error path to put nbd-&gt;config while recv_work continue to use
the config after putting it, leading to use-after-free in recv_work.

This patch moves nbd_start_device() after the backend file creation.</Note>
    </Notes>
    <CVE>CVE-2025-38443</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: u_serial: Fix race condition in TTY wakeup

A race condition occurs when gs_start_io() calls either gs_start_rx() or
gs_start_tx(), as those functions briefly drop the port_lock for
usb_ep_queue(). This allows gs_close() and gserial_disconnect() to clear
port.tty and port_usb, respectively.

Use the null-safe TTY Port helper function to wake up TTY.

Example
  CPU1:			      CPU2:
  gserial_connect() // lock
  			      gs_close() // await lock
  gs_start_rx()     // unlock
  usb_ep_queue()
  			      gs_close() // lock, reset port.tty and unlock
  gs_start_rx()     // lock
  tty_wakeup()      // NPE</Note>
    </Notes>
    <CVE>CVE-2025-38448</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/gem: Acquire references on GEM handles for framebuffers

A GEM handle can be released while the GEM buffer object is attached
to a DRM framebuffer. This leads to the release of the dma-buf backing
the buffer object, if any. [1] Trying to use the framebuffer in further
mode-setting operations leads to a segmentation fault. Most easily
happens with driver that use shadow planes for vmap-ing the dma-buf
during a page flip. An example is shown below.

[  156.791968] ------------[ cut here ]------------
[  156.796830] WARNING: CPU: 2 PID: 2255 at drivers/dma-buf/dma-buf.c:1527 dma_buf_vmap+0x224/0x430
[...]
[  156.942028] RIP: 0010:dma_buf_vmap+0x224/0x430
[  157.043420] Call Trace:
[  157.045898]  &lt;TASK&gt;
[  157.048030]  ? show_trace_log_lvl+0x1af/0x2c0
[  157.052436]  ? show_trace_log_lvl+0x1af/0x2c0
[  157.056836]  ? show_trace_log_lvl+0x1af/0x2c0
[  157.061253]  ? drm_gem_shmem_vmap+0x74/0x710
[  157.065567]  ? dma_buf_vmap+0x224/0x430
[  157.069446]  ? __warn.cold+0x58/0xe4
[  157.073061]  ? dma_buf_vmap+0x224/0x430
[  157.077111]  ? report_bug+0x1dd/0x390
[  157.080842]  ? handle_bug+0x5e/0xa0
[  157.084389]  ? exc_invalid_op+0x14/0x50
[  157.088291]  ? asm_exc_invalid_op+0x16/0x20
[  157.092548]  ? dma_buf_vmap+0x224/0x430
[  157.096663]  ? dma_resv_get_singleton+0x6d/0x230
[  157.101341]  ? __pfx_dma_buf_vmap+0x10/0x10
[  157.105588]  ? __pfx_dma_resv_get_singleton+0x10/0x10
[  157.110697]  drm_gem_shmem_vmap+0x74/0x710
[  157.114866]  drm_gem_vmap+0xa9/0x1b0
[  157.118763]  drm_gem_vmap_unlocked+0x46/0xa0
[  157.123086]  drm_gem_fb_vmap+0xab/0x300
[  157.126979]  drm_atomic_helper_prepare_planes.part.0+0x487/0xb10
[  157.133032]  ? lockdep_init_map_type+0x19d/0x880
[  157.137701]  drm_atomic_helper_commit+0x13d/0x2e0
[  157.142671]  ? drm_atomic_nonblocking_commit+0xa0/0x180
[  157.147988]  drm_mode_atomic_ioctl+0x766/0xe40
[...]
[  157.346424] ---[ end trace 0000000000000000 ]---

Acquiring GEM handles for the framebuffer's GEM buffer objects prevents
this from happening. The framebuffer's cleanup later puts the handle
references.

Commit 1a148af06000 ("drm/gem-shmem: Use dma_buf from GEM object
instance") triggers the segmentation fault easily by using the dma-buf
field more widely. The underlying issue with reference counting has
been present before.

v2:
- acquire the handle instead of the BO (Christian)
- fix comment style (Christian)
- drop the Fixes tag (Christian)
- rename err_ gotos
- add missing Link tag</Note>
    </Notes>
    <CVE>CVE-2025-38449</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

io_uring/msg_ring: ensure io_kiocb freeing is deferred for RCU

syzbot reports that defer/local task_work adding via msg_ring can hit
a request that has been freed:

CPU: 1 UID: 0 PID: 19356 Comm: iou-wrk-19354 Not tainted 6.16.0-rc4-syzkaller-00108-g17bbde2e1716 #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:408 [inline]
 print_report+0xd2/0x2b0 mm/kasan/report.c:521
 kasan_report+0x118/0x150 mm/kasan/report.c:634
 io_req_local_work_add io_uring/io_uring.c:1184 [inline]
 __io_req_task_work_add+0x589/0x950 io_uring/io_uring.c:1252
 io_msg_remote_post io_uring/msg_ring.c:103 [inline]
 io_msg_data_remote io_uring/msg_ring.c:133 [inline]
 __io_msg_ring_data+0x820/0xaa0 io_uring/msg_ring.c:151
 io_msg_ring_data io_uring/msg_ring.c:173 [inline]
 io_msg_ring+0x134/0xa00 io_uring/msg_ring.c:314
 __io_issue_sqe+0x17e/0x4b0 io_uring/io_uring.c:1739
 io_issue_sqe+0x165/0xfd0 io_uring/io_uring.c:1762
 io_wq_submit_work+0x6e9/0xb90 io_uring/io_uring.c:1874
 io_worker_handle_work+0x7cd/0x1180 io_uring/io-wq.c:642
 io_wq_worker+0x42f/0xeb0 io_uring/io-wq.c:696
 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
 &lt;/TASK&gt;

which is supposed to be safe with how requests are allocated. But msg
ring requests alloc and free on their own, and hence must defer freeing
to a sane time.

Add an rcu_head and use kfree_rcu() in both spots where requests are
freed. Only the one in io_msg_tw_complete() is strictly required as it
has been visible on the other ring, but use it consistently in the other
spot as well.

This should not cause any other issues outside of KASAN rightfully
complaining about it.</Note>
    </Notes>
    <CVE>CVE-2025-38453</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

KVM: SVM: Reject SEV{-ES} intra host migration if vCPU creation is in-flight

Reject migration of SEV{-ES} state if either the source or destination VM
is actively creating a vCPU, i.e. if kvm_vm_ioctl_create_vcpu() is in the
section between incrementing created_vcpus and online_vcpus.  The bulk of
vCPU creation runs _outside_ of kvm-&gt;lock to allow creating multiple vCPUs
in parallel, and so sev_info.es_active can get toggled from false=&gt;true in
the destination VM after (or during) svm_vcpu_create(), resulting in an
SEV{-ES} VM effectively having a non-SEV{-ES} vCPU.

The issue manifests most visibly as a crash when trying to free a vCPU's
NULL VMSA page in an SEV-ES VM, but any number of things can go wrong.

  BUG: unable to handle page fault for address: ffffebde00000000
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 0 P4D 0
  Oops: Oops: 0000 [#1] SMP KASAN NOPTI
  CPU: 227 UID: 0 PID: 64063 Comm: syz.5.60023 Tainted: G     U     O        6.15.0-smp-DEV #2 NONE
  Tainted: [U]=USER, [O]=OOT_MODULE
  Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.52.0-0 10/28/2024
  RIP: 0010:constant_test_bit arch/x86/include/asm/bitops.h:206 [inline]
  RIP: 0010:arch_test_bit arch/x86/include/asm/bitops.h:238 [inline]
  RIP: 0010:_test_bit include/asm-generic/bitops/instrumented-non-atomic.h:142 [inline]
  RIP: 0010:PageHead include/linux/page-flags.h:866 [inline]
  RIP: 0010:___free_pages+0x3e/0x120 mm/page_alloc.c:5067
  Code: &lt;49&gt; f7 06 40 00 00 00 75 05 45 31 ff eb 0c 66 90 4c 89 f0 4c 39 f0
  RSP: 0018:ffff8984551978d0 EFLAGS: 00010246
  RAX: 0000777f80000001 RBX: 0000000000000000 RCX: ffffffff918aeb98
  RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffebde00000000
  RBP: 0000000000000000 R08: ffffebde00000007 R09: 1ffffd7bc0000000
  R10: dffffc0000000000 R11: fffff97bc0000001 R12: dffffc0000000000
  R13: ffff8983e19751a8 R14: ffffebde00000000 R15: 1ffffd7bc0000000
  FS:  0000000000000000(0000) GS:ffff89ee661d3000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: ffffebde00000000 CR3: 000000793ceaa000 CR4: 0000000000350ef0
  DR0: 0000000000000000 DR1: 0000000000000b5f DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
  Call Trace:
   &lt;TASK&gt;
   sev_free_vcpu+0x413/0x630 arch/x86/kvm/svm/sev.c:3169
   svm_vcpu_free+0x13a/0x2a0 arch/x86/kvm/svm/svm.c:1515
   kvm_arch_vcpu_destroy+0x6a/0x1d0 arch/x86/kvm/x86.c:12396
   kvm_vcpu_destroy virt/kvm/kvm_main.c:470 [inline]
   kvm_destroy_vcpus+0xd1/0x300 virt/kvm/kvm_main.c:490
   kvm_arch_destroy_vm+0x636/0x820 arch/x86/kvm/x86.c:12895
   kvm_put_kvm+0xb8e/0xfb0 virt/kvm/kvm_main.c:1310
   kvm_vm_release+0x48/0x60 virt/kvm/kvm_main.c:1369
   __fput+0x3e4/0x9e0 fs/file_table.c:465
   task_work_run+0x1a9/0x220 kernel/task_work.c:227
   exit_task_work include/linux/task_work.h:40 [inline]
   do_exit+0x7f0/0x25b0 kernel/exit.c:953
   do_group_exit+0x203/0x2d0 kernel/exit.c:1102
   get_signal+0x1357/0x1480 kernel/signal.c:3034
   arch_do_signal_or_restart+0x40/0x690 arch/x86/kernel/signal.c:337
   exit_to_user_mode_loop kernel/entry/common.c:111 [inline]
   exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline]
   __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]
   syscall_exit_to_user_mode+0x67/0xb0 kernel/entry/common.c:218
   do_syscall_64+0x7c/0x150 arch/x86/entry/syscall_64.c:100
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  RIP: 0033:0x7f87a898e969
   &lt;/TASK&gt;
  Modules linked in: gq(O)
  gsmi: Log Shutdown Reason 0x03
  CR2: ffffebde00000000
  ---[ end trace 0000000000000000 ]---

Deliberately don't check for a NULL VMSA when freeing the vCPU, as crashing
the host is likely desirable due to the VMSA being consumed by hardware.
E.g. if KVM manages to allow VMRUN on the vCPU, hardware may read/write a
bogus VMSA page.  Accessing P
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-38455</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/sched: Abort __tc_modify_qdisc if parent class does not exist

Lion's patch [1] revealed an ancient bug in the qdisc API.
Whenever a user creates/modifies a qdisc specifying as a parent another
qdisc, the qdisc API will, during grafting, detect that the user is
not trying to attach to a class and reject. However grafting is
performed after qdisc_create (and thus the qdiscs' init callback) is
executed. In qdiscs that eventually call qdisc_tree_reduce_backlog
during init or change (such as fq, hhf, choke, etc), an issue
arises. For example, executing the following commands:

sudo tc qdisc add dev lo root handle a: htb default 2
sudo tc qdisc add dev lo parent a: handle beef fq

Qdiscs such as fq, hhf, choke, etc unconditionally invoke
qdisc_tree_reduce_backlog() in their control path init() or change() which
then causes a failure to find the child class; however, that does not stop
the unconditional invocation of the assumed child qdisc's qlen_notify with
a null class. All these qdiscs make the assumption that class is non-null.

The solution is ensure that qdisc_leaf() which looks up the parent
class, and is invoked prior to qdisc_create(), should return failure on
not finding the class.
In this patch, we leverage qdisc_leaf to return ERR_PTRs whenever the
parentid doesn't correspond to a class, so that we can detect it
earlier on and abort before qdisc_create is called.

[1] https://lore.kernel.org/netdev/d912cbd7-193b-4269-9857-525bee8bbb6a@gmail.com/</Note>
    </Notes>
    <CVE>CVE-2025-38457</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

atm: clip: Fix potential null-ptr-deref in to_atmarpd().

atmarpd is protected by RTNL since commit f3a0592b37b8 ("[ATM]: clip
causes unregister hang").

However, it is not enough because to_atmarpd() is called without RTNL,
especially clip_neigh_solicit() / neigh_ops-&gt;solicit() is unsleepable.

Also, there is no RTNL dependency around atmarpd.

Let's use a private mutex and RCU to protect access to atmarpd in
to_atmarpd().</Note>
    </Notes>
    <CVE>CVE-2025-38460</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vsock: Fix transport_* TOCTOU

Transport assignment may race with module unload. Protect new_transport
from becoming a stale pointer.

This also takes care of an insecure call in vsock_use_local_transport();
add a lockdep assert.

BUG: unable to handle page fault for address: fffffbfff8056000
Oops: Oops: 0000 [#1] SMP KASAN
RIP: 0010:vsock_assign_transport+0x366/0x600
Call Trace:
 vsock_connect+0x59c/0xc40
 __sys_connect+0xe8/0x100
 __x64_sys_connect+0x6e/0xc0
 do_syscall_64+0x92/0x1c0
 entry_SYSCALL_64_after_hwframe+0x4b/0x53</Note>
    </Notes>
    <CVE>CVE-2025-38461</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vsock: Fix transport_{g2h,h2g} TOCTOU

vsock_find_cid() and vsock_dev_do_ioctl() may race with module unload.
transport_{g2h,h2g} may become NULL after the NULL check.

Introduce vsock_transport_local_cid() to protect from a potential
null-ptr-deref.

KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]
RIP: 0010:vsock_find_cid+0x47/0x90
Call Trace:
 __vsock_bind+0x4b2/0x720
 vsock_bind+0x90/0xe0
 __sys_bind+0x14d/0x1e0
 __x64_sys_bind+0x6e/0xc0
 do_syscall_64+0x92/0x1c0
 entry_SYSCALL_64_after_hwframe+0x4b/0x53

KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]
RIP: 0010:vsock_dev_do_ioctl.isra.0+0x58/0xf0
Call Trace:
 __x64_sys_ioctl+0x12d/0x190
 do_syscall_64+0x92/0x1c0
 entry_SYSCALL_64_after_hwframe+0x4b/0x53</Note>
    </Notes>
    <CVE>CVE-2025-38462</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tcp: Correct signedness in skb remaining space calculation

Syzkaller reported a bug [1] where sk-&gt;sk_forward_alloc can overflow.

When we send data, if an skb exists at the tail of the write queue, the
kernel will attempt to append the new data to that skb. However, the code
that checks for available space in the skb is flawed:
'''
copy = size_goal - skb-&gt;len
'''

The types of the variables involved are:
'''
copy: ssize_t (s64 on 64-bit systems)
size_goal: int
skb-&gt;len: unsigned int
'''

Due to C's type promotion rules, the signed size_goal is converted to an
unsigned int to match skb-&gt;len before the subtraction. The result is an
unsigned int.

When this unsigned int result is then assigned to the s64 copy variable,
it is zero-extended, preserving its non-negative value. Consequently, copy
is always &gt;= 0.

Assume we are sending 2GB of data and size_goal has been adjusted to a
value smaller than skb-&gt;len. The subtraction will result in copy holding a
very large positive integer. In the subsequent logic, this large value is
used to update sk-&gt;sk_forward_alloc, which can easily cause it to overflow.

The syzkaller reproducer uses TCP_REPAIR to reliably create this
condition. However, this can also occur in real-world scenarios. The
tcp_bound_to_half_wnd() function can also reduce size_goal to a small
value. This would cause the subsequent tcp_wmem_schedule() to set
sk-&gt;sk_forward_alloc to a value close to INT_MAX. Further memory
allocation requests would then cause sk_forward_alloc to wrap around and
become negative.

[1]: https://syzkaller.appspot.com/bug?extid=de6565462ab540f50e47</Note>
    </Notes>
    <CVE>CVE-2025-38463</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netlink: Fix wraparounds of sk-&gt;sk_rmem_alloc.

Netlink has this pattern in some places

  if (atomic_read(&amp;sk-&gt;sk_rmem_alloc) &gt; sk-&gt;sk_rcvbuf)
  	atomic_add(skb-&gt;truesize, &amp;sk-&gt;sk_rmem_alloc);

, which has the same problem fixed by commit 5a465a0da13e ("udp:
Fix multiple wraparounds of sk-&gt;sk_rmem_alloc.").

For example, if we set INT_MAX to SO_RCVBUFFORCE, the condition
is always false as the two operands are of int.

Then, a single socket can eat as many skb as possible until OOM
happens, and we can see multiple wraparounds of sk-&gt;sk_rmem_alloc.

Let's fix it by using atomic_add_return() and comparing the two
variables as unsigned int.

Before:
  [root@fedora ~]# ss -f netlink
  Recv-Q      Send-Q Local Address:Port                Peer Address:Port
  -1668710080 0               rtnl:nl_wraparound/293               *

After:
  [root@fedora ~]# ss -f netlink
  Recv-Q     Send-Q Local Address:Port                Peer Address:Port
  2147483072 0               rtnl:nl_wraparound/290               *
  ^
  `--- INT_MAX - 576</Note>
    </Notes>
    <CVE>CVE-2025-38465</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/exynos: exynos7_drm_decon: add vblank check in IRQ handling

If there's support for another console device (such as a TTY serial),
the kernel occasionally panics during boot. The panic message and a
relevant snippet of the call stack is as follows:

  Unable to handle kernel NULL pointer dereference at virtual address 000000000000000
  Call trace:
    drm_crtc_handle_vblank+0x10/0x30 (P)
    decon_irq_handler+0x88/0xb4
    [...]

Otherwise, the panics don't happen. This indicates that it's some sort
of race condition.

Add a check to validate if the drm device can handle vblanks before
calling drm_crtc_handle_vblank() to avoid this.</Note>
    </Notes>
    <CVE>CVE-2025-38467</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/sched: Return NULL when htb_lookup_leaf encounters an empty rbtree

htb_lookup_leaf has a BUG_ON that can trigger with the following:

tc qdisc del dev lo root
tc qdisc add dev lo root handle 1: htb default 1
tc class add dev lo parent 1: classid 1:1 htb rate 64bit
tc qdisc add dev lo parent 1:1 handle 2: netem
tc qdisc add dev lo parent 2:1 handle 3: blackhole
ping -I lo -c1 -W0.001 127.0.0.1

The root cause is the following:

1. htb_dequeue calls htb_dequeue_tree which calls the dequeue handler on
   the selected leaf qdisc
2. netem_dequeue calls enqueue on the child qdisc
3. blackhole_enqueue drops the packet and returns a value that is not
   just NET_XMIT_SUCCESS
4. Because of this, netem_dequeue calls qdisc_tree_reduce_backlog, and
   since qlen is now 0, it calls htb_qlen_notify -&gt; htb_deactivate -&gt;
   htb_deactiviate_prios -&gt; htb_remove_class_from_row -&gt; htb_safe_rb_erase
5. As this is the only class in the selected hprio rbtree,
   __rb_change_child in __rb_erase_augmented sets the rb_root pointer to
   NULL
6. Because blackhole_dequeue returns NULL, netem_dequeue returns NULL,
   which causes htb_dequeue_tree to call htb_lookup_leaf with the same
   hprio rbtree, and fail the BUG_ON

The function graph for this scenario is shown here:
 0)               |  htb_enqueue() {
 0) + 13.635 us   |    netem_enqueue();
 0)   4.719 us    |    htb_activate_prios();
 0) # 2249.199 us |  }
 0)               |  htb_dequeue() {
 0)   2.355 us    |    htb_lookup_leaf();
 0)               |    netem_dequeue() {
 0) + 11.061 us   |      blackhole_enqueue();
 0)               |      qdisc_tree_reduce_backlog() {
 0)               |        qdisc_lookup_rcu() {
 0)   1.873 us    |          qdisc_match_from_root();
 0)   6.292 us    |        }
 0)   1.894 us    |        htb_search();
 0)               |        htb_qlen_notify() {
 0)   2.655 us    |          htb_deactivate_prios();
 0)   6.933 us    |        }
 0) + 25.227 us   |      }
 0)   1.983 us    |      blackhole_dequeue();
 0) + 86.553 us   |    }
 0) # 2932.761 us |    qdisc_warn_nonwc();
 0)               |    htb_lookup_leaf() {
 0)               |      BUG_ON();
 ------------------------------------------

The full original bug report can be seen here [1].

We can fix this just by returning NULL instead of the BUG_ON,
as htb_dequeue_tree returns NULL when htb_lookup_leaf returns
NULL.

[1] https://lore.kernel.org/netdev/pF5XOOIim0IuEfhI-SOxTgRvNoDwuux7UHKnE_Y5-zVd4wmGvNk2ceHjKb8ORnzw0cGwfmVu42g9dL7XyJLf1NEzaztboTWcm0Ogxuojoeo=@willsroot.io/</Note>
    </Notes>
    <CVE>CVE-2025-38468</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: vlan: fix VLAN 0 refcount imbalance of toggling filtering during runtime

Assuming the "rx-vlan-filter" feature is enabled on a net device, the
8021q module will automatically add or remove VLAN 0 when the net device
is put administratively up or down, respectively. There are a couple of
problems with the above scheme.

The first problem is a memory leak that can happen if the "rx-vlan-filter"
feature is disabled while the device is running:

 # ip link add bond1 up type bond mode 0
 # ethtool -K bond1 rx-vlan-filter off
 # ip link del dev bond1

When the device is put administratively down the "rx-vlan-filter"
feature is disabled, so the 8021q module will not remove VLAN 0 and the
memory will be leaked [1].

Another problem that can happen is that the kernel can automatically
delete VLAN 0 when the device is put administratively down despite not
adding it when the device was put administratively up since during that
time the "rx-vlan-filter" feature was disabled. null-ptr-unref or
bug_on[2] will be triggered by unregister_vlan_dev() for refcount
imbalance if toggling filtering during runtime:

$ ip link add bond0 type bond mode 0
$ ip link add link bond0 name vlan0 type vlan id 0 protocol 802.1q
$ ethtool -K bond0 rx-vlan-filter off
$ ifconfig bond0 up
$ ethtool -K bond0 rx-vlan-filter on
$ ifconfig bond0 down
$ ip link del vlan0

Root cause is as below:
step1: add vlan0 for real_dev, such as bond, team.
register_vlan_dev
    vlan_vid_add(real_dev,htons(ETH_P_8021Q),0) //refcnt=1
step2: disable vlan filter feature and enable real_dev
step3: change filter from 0 to 1
vlan_device_event
    vlan_filter_push_vids
        ndo_vlan_rx_add_vid //No refcnt added to real_dev vlan0
step4: real_dev down
vlan_device_event
    vlan_vid_del(dev, htons(ETH_P_8021Q), 0); //refcnt=0
        vlan_info_rcu_free //free vlan0
step5: delete vlan0
unregister_vlan_dev
    BUG_ON(!vlan_info); //vlan_info is null

Fix both problems by noting in the VLAN info whether VLAN 0 was
automatically added upon NETDEV_UP and based on that decide whether it
should be deleted upon NETDEV_DOWN, regardless of the state of the
"rx-vlan-filter" feature.

[1]
unreferenced object 0xffff8880068e3100 (size 256):
  comm "ip", pid 384, jiffies 4296130254
  hex dump (first 32 bytes):
    00 20 30 0d 80 88 ff ff 00 00 00 00 00 00 00 00  . 0.............
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace (crc 81ce31fa):
    __kmalloc_cache_noprof+0x2b5/0x340
    vlan_vid_add+0x434/0x940
    vlan_device_event.cold+0x75/0xa8
    notifier_call_chain+0xca/0x150
    __dev_notify_flags+0xe3/0x250
    rtnl_configure_link+0x193/0x260
    rtnl_newlink_create+0x383/0x8e0
    __rtnl_newlink+0x22c/0xa40
    rtnl_newlink+0x627/0xb00
    rtnetlink_rcv_msg+0x6fb/0xb70
    netlink_rcv_skb+0x11f/0x350
    netlink_unicast+0x426/0x710
    netlink_sendmsg+0x75a/0xc20
    __sock_sendmsg+0xc1/0x150
    ____sys_sendmsg+0x5aa/0x7b0
    ___sys_sendmsg+0xfc/0x180

[2]
kernel BUG at net/8021q/vlan.c:99!
Oops: invalid opcode: 0000 [#1] SMP KASAN PTI
CPU: 0 UID: 0 PID: 382 Comm: ip Not tainted 6.16.0-rc3 #61 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:unregister_vlan_dev (net/8021q/vlan.c:99 (discriminator 1))
RSP: 0018:ffff88810badf310 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff88810da84000 RCX: ffffffffb47ceb9a
RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88810e8b43c8
RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6cefe80
R10: ffffffffb677f407 R11: ffff88810badf3c0 R12: ffff88810e8b4000
R13: 0000000000000000 R14: ffff88810642a5c0 R15: 000000000000017e
FS:  00007f1ff68c20c0(0000) GS:ffff888163a24000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f1ff5dad240 CR3: 0000000107e56000 CR4: 00000000000006f0
Call Trace:
 &lt;TASK
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-38470</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tls: always refresh the queue when reading sock

After recent changes in net-next TCP compacts skbs much more
aggressively. This unearthed a bug in TLS where we may try
to operate on an old skb when checking if all skbs in the
queue have matching decrypt state and geometry.

    BUG: KASAN: slab-use-after-free in tls_strp_check_rcv+0x898/0x9a0 [tls]
    (net/tls/tls_strp.c:436 net/tls/tls_strp.c:530 net/tls/tls_strp.c:544)
    Read of size 4 at addr ffff888013085750 by task tls/13529

    CPU: 2 UID: 0 PID: 13529 Comm: tls Not tainted 6.16.0-rc5-virtme
    Call Trace:
     kasan_report+0xca/0x100
     tls_strp_check_rcv+0x898/0x9a0 [tls]
     tls_rx_rec_wait+0x2c9/0x8d0 [tls]
     tls_sw_recvmsg+0x40f/0x1aa0 [tls]
     inet_recvmsg+0x1c3/0x1f0

Always reload the queue, fast path is to have the record in the queue
when we wake, anyway (IOW the path going down "if !strp-&gt;stm.full_len").</Note>
    </Notes>
    <CVE>CVE-2025-38471</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: Fix null-ptr-deref in l2cap_sock_resume_cb()

syzbot reported null-ptr-deref in l2cap_sock_resume_cb(). [0]

l2cap_sock_resume_cb() has a similar problem that was fixed by commit
1bff51ea59a9 ("Bluetooth: fix use-after-free error in lock_sock_nested()").

Since both l2cap_sock_kill() and l2cap_sock_resume_cb() are executed
under l2cap_sock_resume_cb(), we can avoid the issue simply by checking
if chan-&gt;data is NULL.

Let's not access to the killed socket in l2cap_sock_resume_cb().

[0]:
BUG: KASAN: null-ptr-deref in instrument_atomic_write include/linux/instrumented.h:82 [inline]
BUG: KASAN: null-ptr-deref in clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline]
BUG: KASAN: null-ptr-deref in l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711
Write of size 8 at addr 0000000000000570 by task kworker/u9:0/52

CPU: 1 UID: 0 PID: 52 Comm: kworker/u9:0 Not tainted 6.16.0-rc4-syzkaller-g7482bb149b9f #0 PREEMPT
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
Workqueue: hci0 hci_rx_work
Call trace:
 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:501 (C)
 __dump_stack+0x30/0x40 lib/dump_stack.c:94
 dump_stack_lvl+0xd8/0x12c lib/dump_stack.c:120
 print_report+0x58/0x84 mm/kasan/report.c:524
 kasan_report+0xb0/0x110 mm/kasan/report.c:634
 check_region_inline mm/kasan/generic.c:-1 [inline]
 kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:189
 __kasan_check_write+0x20/0x30 mm/kasan/shadow.c:37
 instrument_atomic_write include/linux/instrumented.h:82 [inline]
 clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline]
 l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711
 l2cap_security_cfm+0x524/0xea0 net/bluetooth/l2cap_core.c:7357
 hci_auth_cfm include/net/bluetooth/hci_core.h:2092 [inline]
 hci_auth_complete_evt+0x2e8/0xa4c net/bluetooth/hci_event.c:3514
 hci_event_func net/bluetooth/hci_event.c:7511 [inline]
 hci_event_packet+0x650/0xe9c net/bluetooth/hci_event.c:7565
 hci_rx_work+0x320/0xb18 net/bluetooth/hci_core.c:4070
 process_one_work+0x7e8/0x155c kernel/workqueue.c:3238
 process_scheduled_works kernel/workqueue.c:3321 [inline]
 worker_thread+0x958/0xed8 kernel/workqueue.c:3402
 kthread+0x5fc/0x75c kernel/kthread.c:464
 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:847</Note>
    </Notes>
    <CVE>CVE-2025-38473</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: net: sierra: check for no status endpoint

The driver checks for having three endpoints and
having bulk in and out endpoints, but not that
the third endpoint is interrupt input.
Rectify the omission.</Note>
    </Notes>
    <CVE>CVE-2025-38474</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

smc: Fix various oops due to inet_sock type confusion.

syzbot reported weird splats [0][1] in cipso_v4_sock_setattr() while
freeing inet_sk(sk)-&gt;inet_opt.

The address was freed multiple times even though it was read-only memory.

cipso_v4_sock_setattr() did nothing wrong, and the root cause was type
confusion.

The cited commit made it possible to create smc_sock as an INET socket.

The issue is that struct smc_sock does not have struct inet_sock as the
first member but hijacks AF_INET and AF_INET6 sk_family, which confuses
various places.

In this case, inet_sock.inet_opt was actually smc_sock.clcsk_data_ready(),
which is an address of a function in the text segment.

  $ pahole -C inet_sock vmlinux
  struct inet_sock {
  ...
          struct ip_options_rcu *    inet_opt;             /*   784     8 */

  $ pahole -C smc_sock vmlinux
  struct smc_sock {
  ...
          void                       (*clcsk_data_ready)(struct sock *); /*   784     8 */

The same issue for another field was reported before. [2][3]

At that time, an ugly hack was suggested [4], but it makes both INET
and SMC code error-prone and hard to change.

Also, yet another variant was fixed by a hacky commit 98d4435efcbf3
("net/smc: prevent NULL pointer dereference in txopt_get").

Instead of papering over the root cause by such hacks, we should not
allow non-INET socket to reuse the INET infra.

Let's add inet_sock as the first member of smc_sock.

[0]:
kvfree_call_rcu(): Double-freed call. rcu_head 000000006921da73
WARNING: CPU: 0 PID: 6718 at mm/slab_common.c:1956 kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955
Modules linked in:
CPU: 0 UID: 0 PID: 6718 Comm: syz.0.17 Tainted: G        W           6.16.0-rc4-syzkaller-g7482bb149b9f #0 PREEMPT
Tainted: [W]=WARN
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955
lr : kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955
sp : ffff8000a03a7730
x29: ffff8000a03a7730 x28: 00000000fffffff5 x27: 1fffe000184823d3
x26: dfff800000000000 x25: ffff0000c2411e9e x24: ffff0000dd88da00
x23: ffff8000891ac9a0 x22: 00000000ffffffea x21: ffff8000891ac9a0
x20: ffff8000891ac9a0 x19: ffff80008afc2480 x18: 00000000ffffffff
x17: 0000000000000000 x16: ffff80008ae642c8 x15: ffff700011ede14c
x14: 1ffff00011ede14c x13: 0000000000000004 x12: ffffffffffffffff
x11: ffff700011ede14c x10: 0000000000ff0100 x9 : 5fa3c1ffaf0ff000
x8 : 5fa3c1ffaf0ff000 x7 : 0000000000000001 x6 : 0000000000000001
x5 : ffff8000a03a7078 x4 : ffff80008f766c20 x3 : ffff80008054d360
x2 : 0000000000000000 x1 : 0000000000000201 x0 : 0000000000000000
Call trace:
 kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955 (P)
 cipso_v4_sock_setattr+0x2f0/0x3f4 net/ipv4/cipso_ipv4.c:1914
 netlbl_sock_setattr+0x240/0x334 net/netlabel/netlabel_kapi.c:1000
 smack_netlbl_add+0xa8/0x158 security/smack/smack_lsm.c:2581
 smack_inode_setsecurity+0x378/0x430 security/smack/smack_lsm.c:2912
 security_inode_setsecurity+0x118/0x3c0 security/security.c:2706
 __vfs_setxattr_noperm+0x174/0x5c4 fs/xattr.c:251
 __vfs_setxattr_locked+0x1ec/0x218 fs/xattr.c:295
 vfs_setxattr+0x158/0x2ac fs/xattr.c:321
 do_setxattr fs/xattr.c:636 [inline]
 file_setxattr+0x1b8/0x294 fs/xattr.c:646
 path_setxattrat+0x2ac/0x320 fs/xattr.c:711
 __do_sys_fsetxattr fs/xattr.c:761 [inline]
 __se_sys_fsetxattr fs/xattr.c:758 [inline]
 __arm64_sys_fsetxattr+0xc0/0xdc fs/xattr.c:758
 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
 invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49
 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132
 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151
 el0_svc+0x58/0x180 arch/arm64/kernel/entry-common.c:879
 el0t_64_sync_handler+0x84/0x12c arch/arm64/kernel/entry-common.c:898
 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600

[
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-38475</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

rpl: Fix use-after-free in rpl_do_srh_inline().

Running lwt_dst_cache_ref_loop.sh in selftest with KASAN triggers
the splat below [0].

rpl_do_srh_inline() fetches ipv6_hdr(skb) and accesses it after
skb_cow_head(), which is illegal as the header could be freed then.

Let's fix it by making oldhdr to a local struct instead of a pointer.

[0]:
[root@fedora net]# ./lwt_dst_cache_ref_loop.sh
...
TEST: rpl (input)
[   57.631529] ==================================================================
BUG: KASAN: slab-use-after-free in rpl_do_srh_inline.isra.0 (net/ipv6/rpl_iptunnel.c:174)
Read of size 40 at addr ffff888122bf96d8 by task ping6/1543

CPU: 50 UID: 0 PID: 1543 Comm: ping6 Not tainted 6.16.0-rc5-01302-gfadd1e6231b1 #23 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
 &lt;IRQ&gt;
 dump_stack_lvl (lib/dump_stack.c:122)
 print_report (mm/kasan/report.c:409 mm/kasan/report.c:521)
 kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:636)
 kasan_check_range (mm/kasan/generic.c:175 (discriminator 1) mm/kasan/generic.c:189 (discriminator 1))
 __asan_memmove (mm/kasan/shadow.c:94 (discriminator 2))
 rpl_do_srh_inline.isra.0 (net/ipv6/rpl_iptunnel.c:174)
 rpl_input (net/ipv6/rpl_iptunnel.c:201 net/ipv6/rpl_iptunnel.c:282)
 lwtunnel_input (net/core/lwtunnel.c:459)
 ipv6_rcv (./include/net/dst.h:471 (discriminator 1) ./include/net/dst.h:469 (discriminator 1) net/ipv6/ip6_input.c:79 (discriminator 1) ./include/linux/netfilter.h:317 (discriminator 1) ./include/linux/netfilter.h:311 (discriminator 1) net/ipv6/ip6_input.c:311 (discriminator 1))
 __netif_receive_skb_one_core (net/core/dev.c:5967)
 process_backlog (./include/linux/rcupdate.h:869 net/core/dev.c:6440)
 __napi_poll.constprop.0 (net/core/dev.c:7452)
 net_rx_action (net/core/dev.c:7518 net/core/dev.c:7643)
 handle_softirqs (kernel/softirq.c:579)
 do_softirq (kernel/softirq.c:480 (discriminator 20))
 &lt;/IRQ&gt;
 &lt;TASK&gt;
 __local_bh_enable_ip (kernel/softirq.c:407)
 __dev_queue_xmit (net/core/dev.c:4740)
 ip6_finish_output2 (./include/linux/netdevice.h:3358 ./include/net/neighbour.h:526 ./include/net/neighbour.h:540 net/ipv6/ip6_output.c:141)
 ip6_finish_output (net/ipv6/ip6_output.c:215 net/ipv6/ip6_output.c:226)
 ip6_output (./include/linux/netfilter.h:306 net/ipv6/ip6_output.c:248)
 ip6_send_skb (net/ipv6/ip6_output.c:1983)
 rawv6_sendmsg (net/ipv6/raw.c:588 net/ipv6/raw.c:918)
 __sys_sendto (net/socket.c:714 (discriminator 1) net/socket.c:729 (discriminator 1) net/socket.c:2228 (discriminator 1))
 __x64_sys_sendto (net/socket.c:2231)
 do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))
 entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
RIP: 0033:0x7f68cffb2a06
Code: 5d e8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 75 19 83 e2 39 83 fa 08 75 11 e8 26 ff ff ff 66 0f 1f 44 00 00 48 8b 45 10 0f 05 &lt;48&gt; 8b 5d f8 c9 c3 0f 1f 40 00 f3 0f 1e fa 55 48 89 e5 48 83 ec 08
RSP: 002b:00007ffefb7c53d0 EFLAGS: 00000202 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 0000564cd69f10a0 RCX: 00007f68cffb2a06
RDX: 0000000000000040 RSI: 0000564cd69f10a4 RDI: 0000000000000003
RBP: 00007ffefb7c53f0 R08: 0000564cd6a032ac R09: 000000000000001c
R10: 0000000000000000 R11: 0000000000000202 R12: 0000564cd69f10a4
R13: 0000000000000040 R14: 00007ffefb7c66e0 R15: 0000564cd69f10a0
 &lt;/TASK&gt;

Allocated by task 1543:
 kasan_save_stack (mm/kasan/common.c:48)
 kasan_save_track (mm/kasan/common.c:60 (discriminator 1) mm/kasan/common.c:69 (discriminator 1))
 __kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345)
 kmem_cache_alloc_node_noprof (./include/linux/kasan.h:250 mm/slub.c:4148 mm/slub.c:4197 mm/slub.c:4249)
 kmalloc_reserve (net/core/skbuff.c:581 (discriminator 88))
 __alloc_skb (net/core/skbuff.c:669)
 __ip6_append_data (net/ipv6/ip6_output.c:1672 (discriminator 1))
 ip6_
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-38476</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/sched: sch_qfq: Fix race condition on qfq_aggregate

A race condition can occur when 'agg' is modified in qfq_change_agg
(called during qfq_enqueue) while other threads access it
concurrently. For example, qfq_dump_class may trigger a NULL
dereference, and qfq_delete_class may cause a use-after-free.

This patch addresses the issue by:

1. Moved qfq_destroy_class into the critical section.

2. Added sch_tree_lock protection to qfq_dump_class and
qfq_dump_class_stats.</Note>
    </Notes>
    <CVE>CVE-2025-38477</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

comedi: Fix initialization of data for instructions that write to subdevice

Some Comedi subdevice instruction handlers are known to access
instruction data elements beyond the first `insn-&gt;n` elements in some
cases.  The `do_insn_ioctl()` and `do_insnlist_ioctl()` functions
allocate at least `MIN_SAMPLES` (16) data elements to deal with this,
but they do not initialize all of that.  For Comedi instruction codes
that write to the subdevice, the first `insn-&gt;n` data elements are
copied from user-space, but the remaining elements are left
uninitialized.  That could be a problem if the subdevice instruction
handler reads the uninitialized data.  Ensure that the first
`MIN_SAMPLES` elements are initialized before calling these instruction
handlers, filling the uncopied elements with 0.  For
`do_insnlist_ioctl()`, the same data buffer elements are used for
handling a list of instructions, so ensure the first `MIN_SAMPLES`
elements are initialized for each instruction that writes to the
subdevice.</Note>
    </Notes>
    <CVE>CVE-2025-38478</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

comedi: Fix use of uninitialized data in insn_rw_emulate_bits()

For Comedi `INSN_READ` and `INSN_WRITE` instructions on "digital"
subdevices (subdevice types `COMEDI_SUBD_DI`, `COMEDI_SUBD_DO`, and
`COMEDI_SUBD_DIO`), it is common for the subdevice driver not to have
`insn_read` and `insn_write` handler functions, but to have an
`insn_bits` handler function for handling Comedi `INSN_BITS`
instructions.  In that case, the subdevice's `insn_read` and/or
`insn_write` function handler pointers are set to point to the
`insn_rw_emulate_bits()` function by `__comedi_device_postconfig()`.

For `INSN_WRITE`, `insn_rw_emulate_bits()` currently assumes that the
supplied `data[0]` value is a valid copy from user memory.  It will at
least exist because `do_insnlist_ioctl()` and `do_insn_ioctl()` in
"comedi_fops.c" ensure at lease `MIN_SAMPLES` (16) elements are
allocated.  However, if `insn-&gt;n` is 0 (which is allowable for
`INSN_READ` and `INSN_WRITE` instructions, then `data[0]` may contain
uninitialized data, and certainly contains invalid data, possibly from a
different instruction in the array of instructions handled by
`do_insnlist_ioctl()`.  This will result in an incorrect value being
written to the digital output channel (or to the digital input/output
channel if configured as an output), and may be reflected in the
internal saved state of the channel.

Fix it by returning 0 early if `insn-&gt;n` is 0, before reaching the code
that accesses `data[0]`.  Previously, the function always returned 1 on
success, but it is supposed to be the number of data samples actually
read or written up to `insn-&gt;n`, which is 0 in this case.</Note>
    </Notes>
    <CVE>CVE-2025-38480</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

comedi: Fail COMEDI_INSNLIST ioctl if n_insns is too large

The handling of the `COMEDI_INSNLIST` ioctl allocates a kernel buffer to
hold the array of `struct comedi_insn`, getting the length from the
`n_insns` member of the `struct comedi_insnlist` supplied by the user.
The allocation will fail with a WARNING and a stack dump if it is too
large.

Avoid that by failing with an `-EINVAL` error if the supplied `n_insns`
value is unreasonable.

Define the limit on the `n_insns` value in the `MAX_INSNS` macro.  Set
this to the same value as `MAX_SAMPLES` (65536), which is the maximum
allowed sum of the values of the member `n` in the array of `struct
comedi_insn`, and sensible comedi instructions will have an `n` of at
least 1.</Note>
    </Notes>
    <CVE>CVE-2025-38481</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

comedi: das6402: Fix bit shift out of bounds

When checking for a supported IRQ number, the following test is used:

	/* IRQs 2,3,5,6,7, 10,11,15 are valid for "enhanced" mode */
	if ((1 &lt;&lt; it-&gt;options[1]) &amp; 0x8cec) {

However, `it-&gt;options[i]` is an unchecked `int` value from userspace, so
the shift amount could be negative or out of bounds.  Fix the test by
requiring `it-&gt;options[1]` to be within bounds before proceeding with
the original test.  Valid `it-&gt;options[1]` values that select the IRQ
will be in the range [1,15]. The value 0 explicitly disables the use of
interrupts.</Note>
    </Notes>
    <CVE>CVE-2025-38482</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

comedi: das16m1: Fix bit shift out of bounds

When checking for a supported IRQ number, the following test is used:

	/* only irqs 2, 3, 4, 5, 6, 7, 10, 11, 12, 14, and 15 are valid */
	if ((1 &lt;&lt; it-&gt;options[1]) &amp; 0xdcfc) {

However, `it-&gt;options[i]` is an unchecked `int` value from userspace, so
the shift amount could be negative or out of bounds.  Fix the test by
requiring `it-&gt;options[1]` to be within bounds before proceeding with
the original test.</Note>
    </Notes>
    <CVE>CVE-2025-38483</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iio: accel: fxls8962af: Fix use after free in fxls8962af_fifo_flush

fxls8962af_fifo_flush() uses indio_dev-&gt;active_scan_mask (with
iio_for_each_active_channel()) without making sure the indio_dev
stays in buffer mode.
There is a race if indio_dev exits buffer mode in the middle of the
interrupt that flushes the fifo. Fix this by calling
synchronize_irq() to ensure that no interrupt is currently running when
disabling buffer mode.

Unable to handle kernel NULL pointer dereference at virtual address 00000000 when read
[...]
_find_first_bit_le from fxls8962af_fifo_flush+0x17c/0x290
fxls8962af_fifo_flush from fxls8962af_interrupt+0x80/0x178
fxls8962af_interrupt from irq_thread_fn+0x1c/0x7c
irq_thread_fn from irq_thread+0x110/0x1f4
irq_thread from kthread+0xe0/0xfc
kthread from ret_from_fork+0x14/0x2c</Note>
    </Notes>
    <CVE>CVE-2025-38485</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

soc: aspeed: lpc-snoop: Don't disable channels that aren't enabled

Mitigate e.g. the following:

    # echo 1e789080.lpc-snoop &gt; /sys/bus/platform/drivers/aspeed-lpc-snoop/unbind
    ...
    [  120.363594] Unable to handle kernel NULL pointer dereference at virtual address 00000004 when write
    [  120.373866] [00000004] *pgd=00000000
    [  120.377910] Internal error: Oops: 805 [#1] SMP ARM
    [  120.383306] CPU: 1 UID: 0 PID: 315 Comm: sh Not tainted 6.15.0-rc1-00009-g926217bc7d7d-dirty #20 NONE
    ...
    [  120.679543] Call trace:
    [  120.679559]  misc_deregister from aspeed_lpc_snoop_remove+0x84/0xac
    [  120.692462]  aspeed_lpc_snoop_remove from platform_remove+0x28/0x38
    [  120.700996]  platform_remove from device_release_driver_internal+0x188/0x200
    ...</Note>
    </Notes>
    <CVE>CVE-2025-38487</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL again

Commit 7ded842b356d ("s390/bpf: Fix bpf_plt pointer arithmetic") has
accidentally removed the critical piece of commit c730fce7c70c
("s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL"), causing
intermittent kernel panics in e.g. perf's on_switch() prog to reappear.

Restore the fix and add a comment.</Note>
    </Notes>
    <CVE>CVE-2025-38489</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

HID: core: do not bypass hid_hw_raw_request

hid_hw_raw_request() is actually useful to ensure the provided buffer
and length are valid. Directly calling in the low level transport driver
function bypassed those checks and allowed invalid paramto be used.</Note>
    </Notes>
    <CVE>CVE-2025-38494</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

HID: core: ensure the allocated report buffer can contain the reserved report ID

When the report ID is not used, the low level transport drivers expect
the first byte to be 0. However, currently the allocated buffer not
account for that extra byte, meaning that instead of having 8 guaranteed
bytes for implement to be working, we only have 7.</Note>
    </Notes>
    <CVE>CVE-2025-38495</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

dm-bufio: fix sched in atomic context

If "try_verify_in_tasklet" is set for dm-verity, DM_BUFIO_CLIENT_NO_SLEEP
is enabled for dm-bufio. However, when bufio tries to evict buffers, there
is a chance to trigger scheduling in spin_lock_bh, the following warning
is hit:

BUG: sleeping function called from invalid context at drivers/md/dm-bufio.c:2745
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 123, name: kworker/2:2
preempt_count: 201, expected: 0
RCU nest depth: 0, expected: 0
4 locks held by kworker/2:2/123:
 #0: ffff88800a2d1548 ((wq_completion)dm_bufio_cache){....}-{0:0}, at: process_one_work+0xe46/0x1970
 #1: ffffc90000d97d20 ((work_completion)(&amp;dm_bufio_replacement_work)){....}-{0:0}, at: process_one_work+0x763/0x1970
 #2: ffffffff8555b528 (dm_bufio_clients_lock){....}-{3:3}, at: do_global_cleanup+0x1ce/0x710
 #3: ffff88801d5820b8 (&amp;c-&gt;spinlock){....}-{2:2}, at: do_global_cleanup+0x2a5/0x710
Preemption disabled at:
[&lt;0000000000000000&gt;] 0x0
CPU: 2 UID: 0 PID: 123 Comm: kworker/2:2 Not tainted 6.16.0-rc3-g90548c634bd0 #305 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
Workqueue: dm_bufio_cache do_global_cleanup
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x53/0x70
 __might_resched+0x360/0x4e0
 do_global_cleanup+0x2f5/0x710
 process_one_work+0x7db/0x1970
 worker_thread+0x518/0xea0
 kthread+0x359/0x690
 ret_from_fork+0xf3/0x1b0
 ret_from_fork_asm+0x1a/0x30
 &lt;/TASK&gt;

That can be reproduced by:

  veritysetup format --data-block-size=4096 --hash-block-size=4096 /dev/vda /dev/vdb
  SIZE=$(blockdev --getsz /dev/vda)
  dmsetup create myverity -r --table "0 $SIZE verity 1 /dev/vda /dev/vdb 4096 4096 &lt;data_blocks&gt; 1 sha256 &lt;root_hash&gt; &lt;salt&gt; 1 try_verify_in_tasklet"
  mount /dev/dm-0 /mnt -o ro
  echo 102400 &gt; /sys/module/dm_bufio/parameters/max_cache_size_bytes
  [read files in /mnt]</Note>
    </Notes>
    <CVE>CVE-2025-38496</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: configfs: Fix OOB read on empty string write

When writing an empty string to either 'qw_sign' or 'landingPage'
sysfs attributes, the store functions attempt to access page[l - 1]
before validating that the length 'l' is greater than zero.

This patch fixes the vulnerability by adding a check at the beginning
of os_desc_qw_sign_store() and webusb_landingPage_store() to handle
the zero-length input case gracefully by returning immediately.</Note>
    </Notes>
    <CVE>CVE-2025-38497</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

do_change_type(): refuse to operate on unmounted/not ours mounts

Ensure that propagation settings can only be changed for mounts located
in the caller's mount namespace. This change aligns permission checking
with the rest of mount(2).</Note>
    </Notes>
    <CVE>CVE-2025-38498</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

jfs: fix slab-out-of-bounds read in ea_get()

During the "size_check" label in ea_get(), the code checks if the extended
attribute list (xattr) size matches ea_size. If not, it logs
"ea_get: invalid extended attribute" and calls print_hex_dump().

Here, EALIST_SIZE(ea_buf-&gt;xattr) returns 4110417968, which exceeds
INT_MAX (2,147,483,647). Then ea_size is clamped:

	int size = clamp_t(int, ea_size, 0, EALIST_SIZE(ea_buf-&gt;xattr));

Although clamp_t aims to bound ea_size between 0 and 4110417968, the upper
limit is treated as an int, causing an overflow above 2^31 - 1. This leads
"size" to wrap around and become negative (-184549328).

The "size" is then passed to print_hex_dump() (called "len" in
print_hex_dump()), it is passed as type size_t (an unsigned
type), this is then stored inside a variable called
"int remaining", which is then assigned to "int linelen" which
is then passed to hex_dump_to_buffer(). In print_hex_dump()
the for loop, iterates through 0 to len-1, where len is
18446744073525002176, calling hex_dump_to_buffer()
on each iteration:

	for (i = 0; i &lt; len; i += rowsize) {
		linelen = min(remaining, rowsize);
		remaining -= rowsize;

		hex_dump_to_buffer(ptr + i, linelen, rowsize, groupsize,
				   linebuf, sizeof(linebuf), ascii);

		...
	}

The expected stopping condition (i &lt; len) is effectively broken
since len is corrupted and very large. This eventually leads to
the "ptr+i" being passed to hex_dump_to_buffer() to get closer
to the end of the actual bounds of "ptr", eventually an out of
bounds access is done in hex_dump_to_buffer() in the following
for loop:

	for (j = 0; j &lt; len; j++) {
			if (linebuflen &lt; lx + 2)
				goto overflow2;
			ch = ptr[j];
		...
	}

To fix this we should validate "EALIST_SIZE(ea_buf-&gt;xattr)"
before it is utilised.</Note>
    </Notes>
    <CVE>CVE-2025-39735</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

objtool, spi: amd: Fix out-of-bounds stack access in amd_set_spi_freq()

If speed_hz &lt; AMD_SPI_MIN_HZ, amd_set_spi_freq() iterates over the
entire amd_spi_freq array without breaking out early, causing 'i' to go
beyond the array bounds.

Fix that by stopping the loop when it gets to the last entry, so the low
speed_hz value gets clamped up to AMD_SPI_MIN_HZ.

Fixes the following warning with an UBSAN kernel:

  drivers/spi/spi-amd.o: error: objtool: amd_set_spi_freq() falls through to next function amd_spi_set_opcode()</Note>
    </Notes>
    <CVE>CVE-2025-40014</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">If a `named` caching resolver is configured with `serve-stale-enable` `yes`, and with `stale-answer-client-timeout` set to `0` (the only allowable value other than `disabled`), and if the resolver, in the process of resolving a query, encounters a CNAME chain involving a specific combination of cached or authoritative records, the daemon will abort with an assertion failure.
This issue affects BIND 9 versions 9.20.0 through 9.20.10, 9.21.0 through 9.21.9, and 9.20.9-S1 through 9.20.10-S1.</Note>
    </Notes>
    <CVE>CVE-2025-40777</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Perl threads have a working directory race condition where file operations may target unintended paths.

If a directory handle is open at thread creation, the process-wide current working directory is temporarily changed in order to clone  that handle for the new thread, which is visible from any third (or  more) thread already running. 

This may lead to unintended operations  such as loading code or accessing files from unexpected locations,  which a local attacker may be able to exploit.

The bug was introduced in commit  11a11ecf4bea72b17d250cfb43c897be1341861e and released in Perl version 5.13.6</Note>
    </Notes>
    <CVE>CVE-2025-40909</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Allows the extraction filter to be ignored, allowing symlink targets to point outside the destination directory, and the modification of some file metadata.


You are affected by this vulnerability if using the tarfile  module to extract untrusted tar archives using TarFile.extractall()  or TarFile.extract()  using the filter=  parameter with a value of "data"  or "tar". See the tarfile  extraction filters documentation https://docs.python.org/3/library/tarfile.html#tarfile-extraction-filter   for more information.

Note that for Python 3.14 or later the default value of filter=  changed from "no filtering" to `"data", so if you are relying on this new default behavior then your usage is also affected.

Note that none of these vulnerabilities significantly affect the installation of source distributions which are tar archives as source distributions already allow arbitrary code execution during the build process. However when evaluating source distributions it's important to avoid installing source distributions with suspicious links.</Note>
    </Notes>
    <CVE>CVE-2025-4330</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in GLib, which is vulnerable to an integer overflow in the g_string_insert_unichar() function. When the position at which to insert the character is large, the position will overflow, leading to a buffer underwrite.</Note>
    </Notes>
    <CVE>CVE-2025-4373</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">When using a TarFile.errorlevel = 0  and extracting with a filter the documented behavior is that any filtered members would be skipped and not extracted. However the actual behavior of TarFile.errorlevel = 0  in affected versions is that the member would still be extracted and not skipped.</Note>
    </Notes>
    <CVE>CVE-2025-4435</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">There is an issue in CPython when using `bytes.decode("unicode_escape", error="ignore|replace")`. If you are not using the "unicode_escape" encoding or an error handler your usage is not affected. To work-around this issue you may stop using the error= handler and instead wrap the bytes.decode() call in a try-except catching the DecodeError.</Note>
    </Notes>
    <CVE>CVE-2025-4516</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Allows arbitrary filesystem writes outside the extraction directory during extraction with filter="data".


You are affected by this vulnerability if using the tarfile  module to extract untrusted tar archives using TarFile.extractall()  or TarFile.extract()  using the filter=  parameter with a value of "data"  or "tar". See the tarfile  extraction filters documentation https://docs.python.org/3/library/tarfile.html#tarfile-extraction-filter   for more information.

Note that for Python 3.14 or later the default value of filter=  changed from "no filtering" to `"data", so if you are relying on this new default behavior then your usage is also affected.

Note that none of these vulnerabilities significantly affect the installation of source distributions which are tar archives as source distributions already allow arbitrary code execution during the build process. However when evaluating source distributions it's important to avoid installing source distributions with suspicious links.</Note>
    </Notes>
    <CVE>CVE-2025-4517</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability was found in systemd-coredump. This flaw allows an attacker to force a SUID process to crash and replace it with a non-SUID binary to access the original's privileged process coredump, allowing the attacker to read sensitive data, such as /etc/shadow content, loaded by the original process.

A SUID binary or process has a special type of permission, which allows the process to run with the file owner's permissions, regardless of the user executing the binary. This allows the process to access more restricted data than unprivileged users or processes would be able to. An attacker can leverage this flaw by forcing a SUID process to crash and force the Linux kernel to recycle the process PID before systemd-coredump can analyze the /proc/pid/auxv file. If the attacker wins the race condition, they gain access to the original's SUID process coredump file. They can read sensitive content loaded into memory by the original binary, affecting data confidentiality.</Note>
    </Notes>
    <CVE>CVE-2025-4598</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Tornado is a Python web framework and asynchronous networking library. When Tornado's ``multipart/form-data`` parser encounters certain errors, it logs a warning but continues trying to parse the remainder of the data. This allows remote attackers to generate an extremely high volume of logs, constituting a DoS attack. This DoS is compounded by the fact that the logging subsystem is synchronous. All versions of Tornado prior to 6.5.0 are affected. The vulnerable parser is enabled by default. Upgrade to Tornado version 6.50 to receive a patch. As a workaround, risk can be mitigated by blocking `Content-Type: multipart/form-data` in a proxy.</Note>
    </Notes>
    <CVE>CVE-2025-47287</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">jq is a command-line JSON processor. In versions up to and including 1.7.1, a heap-buffer-overflow is present in function `jv_string_vfmt` in the jq_fuzz_execute harness from oss-fuzz. This crash happens on file jv.c, line 1456 `void* p = malloc(sz);`. As of time of publication, no patched versions are available.</Note>
    </Notes>
    <CVE>CVE-2025-48060</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">There's a vulnerability in the libssh package where when a libssh consumer passes in an unexpectedly large input buffer to ssh_get_fingerprint_hash() function. In such cases the bin_to_base64() function can experience an integer overflow leading to a memory under allocation, when that happens it's possible that the program perform out of bounds write leading to a heap corruption.
This issue affects only 32-bits builds of libssh.</Note>
    </Notes>
    <CVE>CVE-2025-4877</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability was found in libssh, where an uninitialized variable exists under certain conditions in the privatekey_from_file() function. This flaw can be triggered if the file specified by the filename doesn't exist and may lead to possible signing failures or heap corruption.</Note>
    </Notes>
    <CVE>CVE-2025-4878</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">ping in iputils before 20250602 allows a denial of service (application error in adaptive ping mode or incorrect data collection) via a crafted ICMP Echo Reply packet, because a zero timestamp can lead to large intermediate values that have an integer overflow when squared during statistics calculations. NOTE: this issue exists because of an incomplete fix for CVE-2025-47268 (that fix was only about timestamp calculations, and it did not account for a specific scenario where the original timestamp in the ICMP payload is zero).</Note>
    </Notes>
    <CVE>CVE-2025-48964</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">libcurl accidentally skips the certificate verification for QUIC connections when connecting to a host specified as an IP address in the URL. Therefore, it does not detect impostors or man-in-the-middle attacks.</Note>
    </Notes>
    <CVE>CVE-2025-4947</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A use-after-free vulnerability was found in libxml2. This issue occurs when parsing XPath elements under certain circumstances when the XML schematron has the &lt;sch:name path="..."/&gt; schema elements. This flaw allows a malicious actor to craft a malicious XML document used as input for libxml, resulting in the program's crash using libxml or other possible undefined behaviors.</Note>
    </Notes>
    <CVE>CVE-2025-49794</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A NULL pointer dereference vulnerability was found in libxml2 when processing XPath XML expressions. This flaw allows an attacker to craft a malicious XML input to libxml2, leading to a denial of service.</Note>
    </Notes>
    <CVE>CVE-2025-49795</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability was found in libxml2. Processing certain sch:name elements from the input XML file can trigger a memory corruption issue. This flaw allows an attacker to craft a malicious XML input file that can lead libxml to crash, resulting in a denial of service or other possible undefined behavior due to sensitive data being corrupted in memory.</Note>
    </Notes>
    <CVE>CVE-2025-49796</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.</Note>
    </Notes>
    <CVE>CVE-2025-50181</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">libcurl supports *pinning* of the server certificate public key for HTTPS transfers. Due to an omission, this check is not performed when connecting with QUIC for HTTP/3, when the TLS backend is wolfSSL. Documentation says the option works with wolfSSL, failing to specify that it does not for QUIC and HTTP/3. Since pinning makes the transfer succeed if the pin is fine, users could unwittingly connect to an impostor server without noticing.</Note>
    </Notes>
    <CVE>CVE-2025-5025</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A stack buffer overflow was found in Internationl components for unicode (ICU ). While running the genrb binary, the 'subtag' struct overflowed at the SRBRoot::addTag function. This issue may lead to memory corruption and local arbitrary code execution.</Note>
    </Notes>
    <CVE>CVE-2025-5222</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in GNU Coreutils. The sort utility's begfield() function is vulnerable to a heap buffer under-read. The program may access memory outside the allocated buffer if a user runs a crafted command using the traditional key format. A malicious input could lead to a crash or leak sensitive data.</Note>
    </Notes>
    <CVE>CVE-2025-5278</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in the libssh library in versions less than 0.11.2. An out-of-bounds read can be triggered in the sftp_handle function due to an incorrect comparison check that permits the function to access memory beyond the valid handle list and to return an invalid pointer, which is used in further processing. This vulnerability allows an authenticated remote attacker to potentially read unintended memory regions, exposing sensitive information or affect service behavior.</Note>
    </Notes>
    <CVE>CVE-2025-5318</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in libssh versions built with OpenSSL versions older than 3.0, specifically in the ssh_kdf() function responsible for key derivation. Due to inconsistent interpretation of return values where OpenSSL uses 0 to indicate failure and libssh uses 0 for success-the function may mistakenly return a success status even when key derivation fails. This results in uninitialized cryptographic key buffers being used in subsequent communication, potentially compromising SSH sessions' confidentiality, integrity, and availability.</Note>
    </Notes>
    <CVE>CVE-2025-5372</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Due to a mistake in libcurl's WebSocket code, a malicious server can send a
particularly crafted packet which makes libcurl get trapped in an endless
busy-loop.

There is no other way for the application to escape or exit this loop other
than killing the thread/process.

This might be used to DoS libcurl-using application.</Note>
    </Notes>
    <CVE>CVE-2025-5399</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Moby is an open source container framework developed by Docker Inc. that is distributed as Docker Engine, Mirantis Container Runtime, and various other downstream projects/products. In versions 28.2.0 through 28.3.2, when the firewalld service is reloaded it removes all iptables rules including those created by Docker. While Docker should automatically recreate these rules, versions before 28.3.3 fail to recreate the specific rules that block external access to containers. This means that after a firewalld reload, containers with ports published to localhost (like 127.0.0.1:8080) become accessible from remote machines that have network routing to the Docker bridge, even though they should only be accessible from the host itself. The vulnerability only affects explicitly published ports - unpublished ports remain protected. This issue is fixed in version 28.3.3.</Note>
    </Notes>
    <CVE>CVE-2025-54388</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">[This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]

There are multiple issues related to the handling and accessing of guest
memory pages in the viridian code:

 1. A NULL pointer dereference in the updating of the reference TSC area.
    This is CVE-2025-27466.

 2. A NULL pointer dereference by assuming the SIM page is mapped when
    a synthetic timer message has to be delivered.  This is
    CVE-2025-58142.

 3. A race in the mapping of the reference TSC page, where a guest can
    get Xen to free a page while still present in the guest physical to
    machine (p2m) page tables.  This is CVE-2025-58143.</Note>
    </Notes>
    <CVE>CVE-2025-58143</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A Local Privilege Escalation (LPE) vulnerability has been discovered in pam-config within Linux Pluggable Authentication Modules (PAM). This flaw allows an unprivileged local attacker (for example, a user logged in via SSH) to obtain the elevated privileges normally reserved for a physically present, "allow_active" user. The highest risk is that the attacker can then perform all allow_active yes Polkit actions, which are typically restricted to console users, potentially gaining unauthorized control over system configurations, services, or other sensitive operations.</Note>
    </Notes>
    <CVE>CVE-2025-6018</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in libxml2's xmlBuildQName function, where integer overflows in buffer size calculations can lead to a stack-based buffer overflow. This issue can result in memory corruption or a denial of service when processing crafted input.</Note>
    </Notes>
    <CVE>CVE-2025-6021</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in how GLib's GString manages memory when adding data to strings. If a string is already very large, combining it with more input can cause a hidden overflow in the size calculation. This makes the system think it has enough memory when it doesn't. As a result, data may be written past the end of the allocated memory, leading to crashes or memory corruption.</Note>
    </Notes>
    <CVE>CVE-2025-6052</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">The html.parser.HTMLParser class had worse-case quadratic complexity when processing certain crafted malformed inputs potentially leading to amplified denial-of-service.</Note>
    </Notes>
    <CVE>CVE-2025-6069</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in the interactive shell of the xmllint command-line tool, used for parsing XML files. When a user inputs an overly long command, the program does not check the input size properly, which can cause it to crash. This issue might allow attackers to run harmful code in rare configurations without modern protections.</Note>
    </Notes>
    <CVE>CVE-2025-6170</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A NULL pointer dereference flaw was found in the GnuTLS software in _gnutls_figure_common_ciphersuite().</Note>
    </Notes>
    <CVE>CVE-2025-6395</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">There exists a vulnerability in SQLite versions before 3.50.2 where the number of aggregate terms could exceed the number of columns available. This could lead to a memory corruption issue. We recommend upgrading to version 3.50.2 or above.</Note>
    </Notes>
    <CVE>CVE-2025-6965</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in libxslt where the attribute type, atype, flags are modified in a way that corrupts internal memory management. When XSLT functions, such as the key() process, result in tree fragments, this corruption prevents the proper cleanup of ID attributes. As a result, the system may access freed memory, causing crashes or enabling attackers to trigger heap corruption.</Note>
    </Notes>
    <CVE>CVE-2025-7425</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in polkit. When processing an XML policy with 32 or more nested elements in depth, an out-of-bounds write can be triggered. This issue can lead to a crash or other unexpected behavior, and arbitrary code execution is not discarded. To exploit this flaw, a high-privilege account is needed as it's required to place the malicious policy file properly.</Note>
    </Notes>
    <CVE>CVE-2025-7519</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">The regcomp function in the GNU C library version from 2.4 to 2.41 is 
subject to a double free if some previous allocation fails. It can be 
accomplished either by a malloc failure or by using an interposed malloc
 that injects random malloc failures. The double free can allow buffer 
manipulation depending of how the regex is constructed. This issue 
affects all architectures and ABIs supported by the GNU C library.</Note>
    </Notes>
    <CVE>CVE-2025-8058</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">There is a defect in the CPython “tarfile” module affecting the “TarFile” extraction and entry enumeration APIs. The tar implementation would process tar archives with negative offsets without error, resulting in an infinite loop and deadlock during the parsing of maliciously crafted tar archives. 

This vulnerability can be mitigated by including the following patch after importing the “tarfile” module:   https://gist.github.com/sethmlarson/1716ac5b82b73dbcbf23ad2eff8b33e1</Note>
    </Notes>
    <CVE>CVE-2025-8194</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">1. A cookie is set using the `secure` keyword for `https://target` 
 2. curl is redirected to or otherwise made to speak with `http://target` (same 
   hostname, but using clear text HTTP) using the same cookie set 
 3. The same cookie name is set - but with just a slash as path (`path=\"/\",`).
   Since this site is not secure, the cookie *should* just be ignored.
4. A bug in the path comparison logic makes curl read outside a heap buffer
   boundary

The bug either causes a crash or it potentially makes the comparison come to
the wrong conclusion and lets the clear-text site override the contents of the
secure cookie, contrary to expectations and depending on the memory contents
immediately following the single-byte allocation that holds the path.

The presumed and correct behavior would be to plainly ignore the second set of
the cookie since it was already set as secure on a secure host so overriding
it on an insecure host should not be okay.</Note>
    </Notes>
    <CVE>CVE-2025-9086</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
</cvrfdoc>
