<?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:3735-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:3735-1</ID>
    </Identification>
    <Status>Interim</Status>
    <Version>1</Version>
    <RevisionHistory>
      <Revision>
        <Number>1</Number>
        <Date>2026-03-19T09:00:00Z</Date>
        <Description>current</Description>
      </Revision>
    </RevisionHistory>
    <InitialReleaseDate>2025-11-24T01:00:00Z</InitialReleaseDate>
    <CurrentReleaseDate>2025-11-24T01: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:3735-1 / google/sle-micro-6-1-byos-v20251124-x86-64</Note>
    <Note Title="Details" Type="General" Ordinal="2" xml:lang="en">This image update for google/sle-micro-6-1-byos-v20251124-x86-64 contains the following changes:
Package aaa_base was updated:

- Update to version 84.87+git20250903.33e5ba4:  * Correct fix for boo#1247495 (boo#1248158)

- Update to version 84.87+git20250805.3069494:
  * Remove initviocons for tcsh as well and
  * Update csh.login
  * Add missing quoting and remove unneeded uses of eval

- Update to version 84.87+git20250801.f305627:
  * Remove sysconfig.language [bsc#1247286]

- Update to version 84.87+git20250801.b2fa3fe:
  * Allow /etc/locale.conf to have no newline

- Update to version 84.87+git20250429.1cad3bc:
  * Remove alias &amp;quot;you&amp;quot; (boo#1242011)

- Update to version 84.87+git20250425.1664836:
  * Fix bug boo#1241205 by adding missed endif
  * alias.bash: future-proof egrep/fgrep color aliases

- Update to version 84.87+git20250410.71df276:
  * Modern s390x uses TERM=linux for ttysclp&amp;lt;X&amp;gt;

- Update to version 84.87+git20250313.4dd1cfd:
  * DIR_COLORS: add backup and temporary file extensions
  * DIR_COLORS: sort audio formats
  * DIR_COLORS: use cyan for audio formats instead of green
  * DIR_COLORS: add 'avif' to image formats
  * DIR_COLORS: add updated and sorted list of archive formats
  * DIR_COLORS: don't colour DOS/Windows executables
  * DIR_COLORS: update existing colours and add missing ones
  * DIR_COLORS: add COLORTERM and 'st' terminal
  * DIR_COLORS: update file description
  * DIR_COLORS: sort TERM entries
  * DIR_COLORS: remove COLOR, OPTIONS and EIGHTBIT

- Update to version 84.87+git20250313.e71c2f4:
  * Respect PROFILEREAD/CSHRCREAD at shell switch
  * Modernize specfile
  * Add safety quotes and proper escaping
  * Avoid bashisms in build recipe
  * Add setup-systemd-proxy-env
  * profile.{sh,csh}: Drop useless proxy variables cleanup

- Update to version 84.87+git20250102.c08e614:
  * Load distrobox_profile.sh

Package audit:audit-secondary was updated:

- Fix plugin termination when using systemd service units (bsc#1215377)  * add auditd.service-fix-plugin-termination.patch

Package chrony was updated:

- Update to version 4.8:  * Add maxunreach option to limit selection of unreachable sources
  * Add -u option to chronyc to drop root privileges (default
    chronyc user is set by configure script)
  * Fix refclock extpps option to work on Linux &amp;gt;= 6.15
  * Validate refclock samples for reachability updates
  * Obsoletes chrony-unix-socket.patch
  * Obsoletes chrony-remove-chmod.patch

- bsc#1246544: Fix racy socket creation
  * Add chrony-unix-socket.patch
  * Add chrony-remove-chmod.patch
- Update clknetsim to snapshot a2eb0b25.

- Update to version 4.7:
  * Add opencommands directive to select remote monitoring
    commands
  * Add interval option to driftfile directive
  * Add waitsynced and waitunsynced options to local directive
  * Add sanity checks for integer values in configuration
  * Add support for systemd Type=notify service
  * Add RTC refclock driver
  * Allow PHC refclock to be specified with network interface name
  * Donât require multiple refclock samples per poll to simplify
    filter configuration
  * Keep refclock reachable when dropping samples with large delay
  * Improve quantile-based filtering to adapt faster to larger
    delay
  * Improve logging of selection failures
  * Detect clock interference from other processes
  * Try to reopen message log (-l option) on cyclelogs command
  * Fix sourcedir reloading to not multiply sources
  * Fix tracking offset after failed clock step
  * Drop support for NTS with Nettle &amp;lt; 3.6 and GnuTLS &amp;lt; 3.6.14
  * Drop support for building without POSIX threads
- Update clknetsim to snapshot 530d1a5.

- Update to version 4.6.1:
  * Add ntsaeads directive to enable only selected AEAD algorithms
    for NTS.
  * Negotiate use of compliant NTS keys with AES-128-GCM-SIV AEAD
    algorithm.
  * Switch to compliant NTS keys if first response from server is
    NTS NAK.

- Drop rcFOO symlinks for CODE16 (PED-266).

- Update to version 4.6:
  * Add activate option to local directive to set activation threshold
  * Add ipv4 and ipv6 options to server/pool/peer directive
  * Add kod option to ratelimit directive for server KoD RATE support
  * Add leapseclist directive to read NIST/IERS leap-seconds.list file
  * Add ptpdomain directive to set PTP domain for NTP over PTP
  * Allow disabling pidfile
  * Improve copy server option to accept unsynchronised status instantly
  * Log one selection failure on start
  * Add offset command to modify source offset correction
  * Add timestamp sources to ntpdata report
  * Fix crash on sources reload during initstepslew or RTC initialisation
  * Fix source refreshment to not repeat failed name resolving attempts
  * Obsoletes chrony-124-tai.patch
- The project's new home is https://chrony-project.org/ .

- Update clknetsim to snapshot 633a0be: fix missing stat/fstat with
  latest glibc.

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

Package containerd was updated:

- Update to containerd v1.7.29. Upstream release notes:  &amp;lt;https://github.com/containerd/containerd/releases/tag/v1.7.29&amp;gt;
  * CVE-2024-25621 bsc#1253126
  * CVE-2025-64329 bsc#1253132
- Rebase patches:
  * 0001-BUILD-SLE12-revert-btrfs-depend-on-kernel-UAPI-inste.patch

- Update to containerd v1.7.28. Upstream release notes:
  &amp;lt;https://github.com/containerd/containerd/releases/tag/v1.7.28&amp;gt;

Package coreutils:systemd was updated:

- coreutils-9.4.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 coreutils was updated:

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

- 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

Package docker was updated:

- Enable SELinux in default daemon.json config (--selinux-enabled). This has no  practical impact on non-SELinux systems. bsc#1252290

- Update to Docker 28.5.1-ce. See upstream changelog online at
  &amp;lt;https://docs.docker.com/engine/release-notes/28/#2851&amp;gt;
- Rebased 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
  * cli-0001-openSUSE-point-users-to-docker-buildx-package.patch
  * cli-0002-SECRETS-SUSE-default-to-DOCKER_BUILDKIT-0-for-docker.patch
- Remove upstreamed patch:
  - 0007-Add-back-vendor.sum.patch

- Update to Docker 28.5.0-ce. See upstream changelog online at
  &amp;lt;https://docs.docker.com/engine/release-notes/28/#2850&amp;gt;
- Backport &amp;lt;https://github.com/moby/moby/pull/51091&amp;gt; to re-add vendor.sum,
  fixing our builds.
  + 0007-Add-back-vendor.sum.patch
- Rebased 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
  * cli-0001-openSUSE-point-users-to-docker-buildx-package.patch
  * cli-0002-SECRETS-SUSE-default-to-DOCKER_BUILDKIT-0-for-docker.patch

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

- Remove git-core recommends also on openSUSE: the below argument
  is valid for those users too.

- Remove git-core recommends on SLE. Most SLE systems have
  installRecommends=yes by default and thus end up installing git with Docker.
  bsc#1250508
  This feature is mostly intended for developers (&amp;quot;docker build git://&amp;quot;) so
  most users already have the dependency installed, and the error when git is
  missing is fairly straightforward (so they can easily figure out what they
  need to install).

- Update to docker-buildx v0.28.0. Upstream changelog:
  &amp;lt;https://github.com/docker/buildx/releases/tag/v0.28.0&amp;gt;
- Update to Docker 28.4.0-ce. See upstream changelog online at
  &amp;lt;https://docs.docker.com/engine/release-notes/28/#2840&amp;gt;
  * Fixes a nil pointer panic in &amp;quot;docker push&amp;quot;. bsc#1248373
- Rebased 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
  * cli-0001-openSUSE-point-users-to-docker-buildx-package.patch
  * cli-0002-SECRETS-SUSE-default-to-DOCKER_BUILDKIT-0-for-docker.patch

- Update warnings and errors related to &amp;quot;docker buildx ...&amp;quot; so that they
  reference our openSUSE docker-buildx packages.
  + cli-0001-openSUSE-point-users-to-docker-buildx-package.patch
- Enable building docker-buildx for SLE15 systems with SUSEConnect secret
  injection enabled. PED-12534 PED-8905 bsc#1247594
  As docker-buildx does not support our SUSEConnect secret injection (and some
  users depend &amp;quot;docker build&amp;quot; working transparently), patch the docker CLI so
  that &amp;quot;docker build&amp;quot; will no longer automatically call &amp;quot;docker buildx build&amp;quot;,
  effectively making DOCKER_BUILDKIT=0 the default configuration. Users can
  manually use &amp;quot;docker buildx ...&amp;quot; commands or set DOCKER_BUILDKIT=1 in order
  to opt-in to using docker-buildx.
  Users can silence the &amp;quot;docker build&amp;quot; warning by setting DOCKER_BUILDKIT=0
  explicitly.
  In order to inject SCC credentials with docker-buildx, 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.
  + cli-0002-SECRETS-SUSE-default-to-DOCKER_BUILDKIT-0-for-docker.patch

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

Package dracut was updated:

- Update to version 059+suse.641.g906a3d31:  * fix(kernel-modules-extra): remove stray \ before / (bsc#1253029)

- Update to version 059+suse.639.g19f24feb:
  * fix(dracut-util): crash if CMDLINE ends with quotation mark (bsc#1247819)

- Update to version 059+suse.637.g85a5109c:
  * fix(rngd): adjust license to match the license of the whole project
  * fix(dracut): kernel module name normalization in drivers lists (bsc#1241680)
  * fix(dracut-init): assign real path to srcmods (bsc#1241114)

Package glib2 was updated:

- Add glib2-CVE-2025-7039.patch: fix computation of temporary file  name (bsc#1249055 CVE-2025-7039 glgo#GNOME/glib#3716).

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

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 grub2 was updated:

- Fix CVE-2025-54771 (bsc#1252931)  * 0001-kern-file-Call-grub_dl_unref-after-fs-fs_close.patch
- Fix CVE-2025-54770 (bsc#1252930)
  * 0002-net-net-Unregister-net_set_vlan-command-on-unload.patch
- Fix CVE-2025-61662 (bsc#1252933)
  * 0003-gettext-gettext-Unregister-gettext-command-on-module.patch
- Fix CVE-2025-61663 (bsc#1252934)
- Fix CVE-2025-61664 (bsc#1252935)
  * 0004-normal-main-Unregister-commands-on-module-unload.patch
  * 0005-tests-lib-functional_test-Unregister-commands-on-mod.patch
- Fix CVE-2025-61661 (bsc#1252932)
  * 0006-commands-usbtest-Use-correct-string-length-field.patch
  * 0007-commands-usbtest-Ensure-string-length-is-sufficient-.patch
- Bump upstream SBAT generation to 6

- Fix error: /boot/grub2/x86_64-efi/bli.mod not found (bsc#1231591)

- Fix OOM error in loading loopback file (bsc#1230840) (bsc#1249140)
  * 0001-tpm-Skip-loopback-image-measurement.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

- Update the patch to fix &amp;quot;SRK not matched&amp;quot; errors when unsealing
  the key (bsc#1232411) (bsc#1247242)
  * 0001-tpm2-Add-extra-RSA-SRK-types.patch

- Fix CVE-2025-4382: TPM auto-decryption data exposure (bsc#1242971)
  * 0001-kern-rescue_reader-Block-the-rescue-mode-until-the-C.patch
  * 0002-commands-search-Introduce-the-cryptodisk-only-argume.patch
  * 0003-disk-diskfilter-Introduce-the-cryptocheck-command.patch
  * 0004-commands-search-Add-the-diskfilter-support.patch
  * 0005-docs-Document-available-crypto-disks-checks.patch
  * 0006-disk-cryptodisk-Add-the-erase-secrets-function.patch
  * 0007-disk-cryptodisk-Wipe-the-passphrase-from-memory.patch
  * 0008-cryptocheck-Add-quiet-option.patch
- patch rebased
  * 0001-Improve-TPM-key-protection-on-boot-interruptions.patch
  * 0004-Key-revocation-on-out-of-bound-file-access.patch
- patch refrehed
  * 0001-Fix-PowerPC-CAS-reboot-to-evaluate-menu-context.patch
  * 0002-Requiring-authentication-after-tpm-unlock-for-CLI-ac.patch

- Security fixes for 2024
  * 0001-misc-Implement-grub_strlcpy.patch
- Fix CVE-2024-45781 (bsc#1233617)
  * 0002-fs-ufs-Fix-a-heap-OOB-write.patch
- Fix CVE-2024-56737 (bsc#1234958)
- Fix CVE-2024-45782 (bsc#1233615)
  * 0003-fs-hfs-Fix-stack-OOB-write-with-grub_strcpy.patch
- Fix CVE-2024-45780 (bsc#1233614)
  * 0004-fs-tar-Integer-overflow-leads-to-heap-OOB-write.patch
- Fix CVE-2024-45783 (bsc#1233616)
  * 0005-fs-hfsplus-Set-a-grub_errno-if-mount-fails.patch
  * 0006-kern-file-Ensure-file-data-is-set.patch
  * 0007-kern-file-Implement-filesystem-reference-counting.patch
- Fix CVE-2025-0624 (bsc#1236316)
  * 0008-net-Fix-OOB-write-in-grub_net_search_config_file.patch
- Fix CVE-2024-45774 (bsc#1233609)
  * 0009-video-readers-jpeg-Do-not-permit-duplicate-SOF0-mark.patch
- Fix CVE-2024-45775 (bsc#1233610)
  * 0010-commands-extcmd-Missing-check-for-failed-allocation.patch
- Fix CVE-2025-0622 (bsc#1236317)
  * 0011-commands-pgp-Unregister-the-check_signatures-hooks-o.patch
- Fix CVE-2025-0622 (bsc#1236317)
  * 0012-normal-Remove-variables-hooks-on-module-unload.patch
- Fix CVE-2025-0622 (bsc#1236317)
  * 0013-gettext-Remove-variables-hooks-on-module-unload.patch
- Fix CVE-2024-45776 (bsc#1233612)
  * 0014-gettext-Integer-overflow-leads-to-heap-OOB-write-or-.patch
- Fix CVE-2024-45777 (bsc#1233613)
  * 0015-gettext-Integer-overflow-leads-to-heap-OOB-write.patch
- Fix CVE-2025-0690 (bsc#1237012)
  * 0016-commands-read-Fix-an-integer-overflow-when-supplying.patch
- Fix CVE-2025-1118 (bsc#1237013)
  * 0017-commands-minicmd-Block-the-dump-command-in-lockdown-.patch
- Fix CVE-2024-45778 (bsc#1233606)
- Fix CVE-2024-45779 (bsc#1233608)
  * 0018-fs-bfs-Disable-under-lockdown.patch
- Fix CVE-2025-0677 (bsc#1237002)
- Fix CVE-2025-0684 (bsc#1237008)
- Fix CVE-2025-0685 (bsc#1237009)
- Fix CVE-2025-0686 (bsc#1237010)
- Fix CVE-2025-0689 (bsc#1237011)
  * 0019-fs-Disable-many-filesystems-under-lockdown.patch
- Fix CVE-2025-1125 (bsc#1237014)
- Fix CVE-2025-0678 (bsc#1237006)
  * 0020-fs-Prevent-overflows-when-allocating-memory-for-arra.patch
- Updated to upstream version
  * 0002-Requiring-authentication-after-tpm-unlock-for-CLI-ac.patch
- Bump upstream SBAT generation to 5

- Fix CVE-2024-49504 (bsc#1229163) (bsc#1229164)
- Restrict CLI access if the encrypted root device is automatically unlocked by
  the TPM. LUKS password authentication is required for access to be granted
  * 0001-cli_lock-Add-build-option-to-block-command-line-inte.patch
  * 0002-Requiring-authentication-after-tpm-unlock-for-CLI-ac.patch
- Obsolete, as CLI access is now locked and granted access no longer requires
  the previous restrictions
  * 0002-Restrict-file-access-on-cryptodisk-print.patch
  * 0003-Restrict-ls-and-auto-file-completion-on-cryptodisk-p.patch
- Rediff
  * 0004-Key-revocation-on-out-of-bound-file-access.patch

Package kernel-source:kernel-default was updated:

- nbd: restrict sockets to TCP and UDP (bsc#1252774  CVE-2025-40080).
- commit a7c3e39

- kernel-subpackage-spec: Do not doubly-sign modules (bsc#1251930).
- commit 0f034b6

- Delete
  patches.kabi/KVM-x86-pmu-Allow-programming-events-that-match-unsu.patch.
  This avoids a kbuild error in check-patchrv. This patch is not needed
  anyway since 4f5efb71e1f4.
- commit 624b1b2

- vhost: vringh: Modify the return value check (CVE-2025-40051
  bsc#1252858).
- commit 80d9f20

- btrfs: fix the incorrect max_bytes value for
  find_lock_delalloc_range() (git-fixes).
- commit 91a9728

- KVM: x86: Introduce kvm_x86_call() to simplify static calls
  of kvm_x86_ops (git-fixes).
- Refresh
  patches.suse/KVM-x86-Don-t-inject-PV-async-PF-if-SEND_ALWAYS-0-an.patch.
- Refresh
  patches.suse/KVM-x86-Exit-to-userspace-if-fastpath-triggers-one-o.patch.
- Refresh patches.suse/KVM-x86-Introduce-kvm_set_mp_state.patch.
- Refresh
  patches.suse/KVM-x86-Route-non-canonical-checks-in-emulator-throu.patch.
- Refresh
  patches.suse/KVM-x86-model-canonical-checks-more-precisely.patch.
- commit 3454959

- KVM: x86: Replace static_call_cond() with static_call()
  (git-fixes).
- commit 6bb685c

- Update
  patches.suse/ACPI-x86-s2idle-Catch-multiple-ACPI_TYPE_PACKAGE-obj.patch
  (git-fixes CVE-2023-53708 bsc#1252537).
- Update
  patches.suse/ALSA-usb-audio-Fix-NULL-pointer-deference-in-try_to_.patch
  (git-fixes CVE-2025-40085 bsc#1252873).
- Update
  patches.suse/ALSA-usb-audio-fix-race-condition-to-UAF-in-snd_usbm.patch
  (git-fixes CVE-2025-39997 bsc#1252056).
- Update
  patches.suse/ASoC-qcom-audioreach-fix-potential-null-pointer-dere.patch
  (git-fixes CVE-2025-40013 bsc#1252348).
- Update patches.suse/Bluetooth-MGMT-Fix-possible-UAFs.patch
  (git-fixes CVE-2025-39981 bsc#1252060).
- Update
  patches.suse/Bluetooth-hci_event-Fix-UAF-in-hci_acl_create_conn_s.patch
  (git-fixes CVE-2025-39982 bsc#1252083).
- Update
  patches.suse/HID-amd_sfh-Fix-for-shift-out-of-bounds.patch
  (bsc#1012628 CVE-2023-53703 bsc#1252553).
- Update
  patches.suse/Input-uinput-zero-initialize-uinput_ff_upload_compat.patch
  (git-fixes CVE-2025-40035 bsc#1252866).
- Update patches.suse/NFS-Fix-a-potential-data-corruption.patch
  (git-fixes CVE-2023-53711 bsc#1252536).
- Update
  patches.suse/NFSD-Define-a-proc_layoutcommit-for-the-FlexFiles-layout-type.patch
  (git-fixes CVE-2025-40087 bsc#1252909).
- Update
  patches.suse/PCI-endpoint-pci-epf-test-Add-NULL-check-for-DMA-cha.patch
  (git-fixes CVE-2025-40032 bsc#1252841).
- Update
  patches.suse/RDMA-rxe-Fix-race-in-do_task-when-draining.patch
  (git-fixes CVE-2025-40061 bsc#1252849).
- Update
  patches.suse/Squashfs-fix-uninit-value-in-squashfs_get_parent.patch
  (git-fixes CVE-2025-40049 bsc#1252822).
- Update
  patches.suse/USB-gadget-Fix-the-memory-leak-in-raw_gadget-dr.patch
  (bsc#1012628 CVE-2023-53693 bsc#1252489).
- Update
  patches.suse/afs-Fix-potential-null-pointer-dereference-in-afs_put_server.patch
  (git-fixes CVE-2025-40010 bsc#1252332).
- Update
  patches.suse/arm64-csum-Fix-OoB-access-in-IP-checksum-code-for-ne.patch
  (git-fixes CVE-2023-53726 bsc#1252565).
- Update
  patches.suse/arm64-sme-Use-STR-P-to-clear-FFR-context-field-.patch
  (bsc#1012628 CVE-2023-53713 bsc#1252559).
- Update
  patches.suse/blk-iocost-use-spin_lock_irqsave-in-adjust_inus.patch
  (bsc#1012628 CVE-2023-53730 bsc#1252495).
- Update
  patches.suse/bus-fsl-mc-Check-return-value-of-platform_get_resour.patch
  (git-fixes CVE-2025-40029 bsc#1252772).
- Update
  patches.suse/can-etas_es58x-populate-ndo_change_mtu-to-prevent-bu.patch
  (git-fixes CVE-2025-39988 bsc#1252074).
- Update
  patches.suse/can-hi311x-populate-ndo_change_mtu-to-prevent-buffer.patch
  (git-fixes CVE-2025-39987 bsc#1252079).
- Update
  patches.suse/can-mcba_usb-populate-ndo_change_mtu-to-prevent-buff.patch
  (git-fixes CVE-2025-39985 bsc#1252082).
- Update
  patches.suse/can-peak_usb-fix-shift-out-of-bounds-issue.patch
  (git-fixes CVE-2025-40020 bsc#1252679).
- Update
  patches.suse/can-sun4i_can-populate-ndo_change_mtu-to-prevent-buf.patch
  (git-fixes CVE-2025-39986 bsc#1252078).
- Update
  patches.suse/clk-imx-clk-imx8mp-improve-error-handling-in-im.patch
  (bsc#1012628 CVE-2023-53704 bsc#1252490).
- Update
  patches.suse/clocksource-drivers-cadence-ttc-Fix-memory-leak.patch
  (bsc#1012628 CVE-2023-53725 bsc#1252492).
- Update
  patches.suse/crypto-essiv-Check-ssize-for-decryption-and-in-place.patch
  (git-fixes CVE-2025-40019 bsc#1252678).
- Update
  patches.suse/crypto-hisilicon-qm-set-NULL-to-qm-debug.qm_diff_reg.patch
  (git-fixes CVE-2025-40062 bsc#1252850).
- Update
  patches.suse/drm-amdgpu-Fix-integer-overflow-in-amdgpu_cs_p.patch
  (jsc#PED-3527 jsc#PED-5475 jsc#PED-6068 jsc#PED-6070
  jsc#PED-6116 jsc#PED-6120 jsc#PED-5065 jsc#PED-5477 jsc#PED-5511
  jsc#PED-6041 jsc#PED-6069 jsc#PED-6071 CVE-2023-53707
  bsc#1252632).
- Update
  patches.suse/drm-gma500-Fix-null-dereference-in-hdmi-teardown.patch
  (git-fixes CVE-2025-40011 bsc#1252336).
- Update
  patches.suse/drm-sched-Fix-potential-double-free-in-drm_sched_job.patch
  (git-fixes CVE-2025-40096 bsc#1252902).
- Update
  patches.suse/fbcon-fix-integer-overflow-in-fbcon_do_set_font.patch
  (git-fixes CVE-2025-39967 bsc#1252033).
- Update
  patches.suse/fs-udf-fix-OOB-read-in-lengthAllocDescs-handling.patch
  (git-fixes CVE-2025-40044 bsc#1252785).
- Update
  patches.suse/hfsplus-fix-slab-out-of-bounds-read-in-hfsplus_strcasecmp.patch
  (git-fixes CVE-2025-40088 bsc#1252904).
- Update
  patches.suse/hfsplus-fix-slab-out-of-bounds-read-in-hfsplus_uni2asc_followup.patch
  (git-fixes CVE-2025-40082 bsc#1252775).
- Update
  patches.suse/iommu-vt-d-Disallow-dirty-tracking-if-incoherent-pag.patch
  (git-fixes CVE-2025-40058 bsc#1252854).
- Update
  patches.suse/md-raid1-fix-potential-OOB-in-raid1_remove_disk-8b04.patch
  (jsc#PED-7542 CVE-2023-53722 bsc#1252499).
- Update
  patches.suse/media-b2c2-Fix-use-after-free-causing-by-irq_check_w.patch
  (git-fixes CVE-2025-39996 bsc#1252065).
- Update
  patches.suse/media-i2c-tc358743-Fix-use-after-free-bugs-caused-by.patch
  (git-fixes CVE-2025-39995 bsc#1252064).
- Update
  patches.suse/media-rc-fix-races-with-imon_disconnect.patch
  (git-fixes CVE-2025-39993 bsc#1252070).
- Update
  patches.suse/media-tuner-xc5000-Fix-use-after-free-in-xc5000_rele.patch
  (git-fixes CVE-2025-39994 bsc#1252072).
- Update
  patches.suse/media-uvcvideo-Mark-invalid-entities-with-id-UVC_INV.patch
  (git-fixes CVE-2025-40016 bsc#1252346).
- Update
  patches.suse/misc-fastrpc-fix-possible-map-leak-in-fastrpc_put_ar.patch
  (git-fixes CVE-2025-40036 bsc#1252865).
- Update
  patches.suse/net-nfc-nci-Add-parameter-validation-for-packet-data.patch
  (git-fixes CVE-2025-40043 bsc#1252787).
- Update
  patches.suse/net-sched-cls_u32-Undo-tcf_bind_filter-if-u32_r.patch
  (bsc#1012628 CVE-2023-53733 bsc#1252685).
- Update
  patches.suse/net-sched-fq_pie-avoid-stalls-in-fq_pie_timer.patch
  (bsc#1220419 CVE-2023-53727 bsc#1252566).
- Update
  patches.suse/netlink-fix-potential-deadlock-in-netlink_set_e.patch
  (bsc#1012628 CVE-2023-53731 bsc#1252481).
- Update
  patches.suse/nvdimm-Fix-memleak-of-pmu-attr_groups-in-unregister_-85ae.patch
  (jsc#PED-5853 CVE-2023-53697 bsc#1252534).
- Update
  patches.suse/posix-timers-Ensure-timer-ID-search-loop-limit-.patch
  (bsc#1012628 CVE-2023-53728 bsc#1252668).
- Update
  patches.suse/ring-buffer-Do-not-swap-cpu_buffer-during-resi.patch
  (bsc#1012628 CVE-2023-53718 bsc#1252564).
- Update
  patches.suse/riscv-move-memblock_allow_resize-after-linear-m.patch
  (bsc#1012628 CVE-2023-53699 bsc#1252550).
- Update
  patches.suse/smb-client-fix-crypto-buffers-in-non-linear-memory.patch
  (bsc#1250491 boo#1239206 CVE-2025-40052 bsc#1252851).
- Update
  patches.suse/soc-qcom-qmi_encdec-Restrict-string-length-in-decode.patch
  (git-fixes CVE-2023-53729 bsc#1252496).
- Update
  patches.suse/tty-n_gsm-Don-t-block-input-queue-by-waiting-MSC.patch
  (git-fixes CVE-2025-40071 bsc#1252797).
- Update
  patches.suse/wifi-ath11k-fix-NULL-dereference-in-ath11k_qmi_m3_lo.patch
  (git-fixes CVE-2025-39991 bsc#1252075).
- Update
  patches.suse/wifi-ath12k-Fix-a-NULL-pointer-dereference-in-ath12k.patch
  (git-fixes CVE-2023-53721 bsc#1252561).
- Update
  patches.suse/xfrm-xfrm_alloc_spi-shouldn-t-use-0-as-SPI.patch
  (CVE-2025-39797 bsc#1249608 CVE-2025-39965 bsc#1251967).
- Update
  patches.suse/xsk-fix-refcount-underflow-in-error-path.patch
  (bsc#1012628 CVE-2023-53698 bsc#1252479).
- commit 9042362

- coresight: trbe: Return NULL pointer for allocation failures
  (CVE-2025-40060 bsc#1252848).
- commit 4543e34

- regulator: bd718x7: Fix voltages scaled by resistor divider
  (git-fixes).
- regmap: slimbus: fix bus_context pointer in regmap init calls
  (git-fixes).
- commit 20abe4b

- drm/panel: kingdisplay-kd097d04: Disable EoTp (git-fixes).
- drm/panel: sitronix-st7789v: fix sync flags for t28cp45tn89
  (git-fixes).
- drm/etnaviv: fix flush sequence logic (git-fixes).
- drm/msm/dpu: Fix pixel extension sub-sampling (git-fixes).
- drm/msm/a6xx: Fix GMU firmware parser (git-fixes).
- drm/amd/pm/powerplay/smumgr: Fix PCIeBootLinkLevel value on
  Iceland (git-fixes).
- drm/amd/pm/powerplay/smumgr: Fix PCIeBootLinkLevel value on Fiji
  (git-fixes).
- drm/amd/pm: fix smu table id bound check issue in
  smu_cmn_update_table() (git-fixes).
- drm/mediatek: Fix device use-after-free on unbind (git-fixes).
- ASoC: fsl_sai: fix bit order for DSD format (git-fixes).
- ASoC: Intel: avs: Unprepare a stream when XRUN occurs
  (git-fixes).
- ASoC: qdsp6: q6asm: do not sleep while atomic (git-fixes).
- ALSA: usb-audio: fix control pipe direction (git-fixes).
- commit acb4ea2

- smb: client: fix potential cfid UAF in smb2_query_info_compound
  (bsc#1248886).
- commit 5e5239d

- vhost: vringh: Fix copy_to_iter return value check (CVE-2025-40056 bsc#1252826)
- commit 4efa16a

- btrfs: do not assert we found block group item when creating
  free space tree (bsc#1252918 CVE-2025-40100).
- commit 327502f

- btrfs: fix clearing of BTRFS_FS_RELOC_RUNNING if relocation
  already running (git-fixes).
- commit f5ef369

- btrfs: avoid potential out-of-bounds in btrfs_encode_fh()
  (git-fixes).
- commit 8cb68fe

- KVM: x86/mmu: Prevent installing hugepages when mem attributes
  are changing (git-fixes).
- commit 37d594a

- selftests/bpf: Fix a fd leak in error paths in open_netns
  (git-fixes).
- commit 51d3745

- selftests/bpf: Fix umount cgroup2 error in test_sockmap
  (git-fixes).
- commit 24ba5aa

- selftests/bpf: Use bpf_link__destroy in fill_link_info tests
  (git-fixes).
- commit 9809b14

- ACPI: video: Fix use-after-free in
  acpi_video_switch_brightness() (git-fixes).
- ACPI: button: Call input_free_device() on failing input device
  registration (git-fixes).
- fbdev: atyfb: Check if pll_ops-&amp;gt;init_pll failed (git-fixes).
- fbdev: valkyriefb: Fix reference count leak in valkyriefb_init
  (git-fixes).
- net: phy: dp83869: fix STRAP_OPMODE bitmask (git-fixes).
- net: usb: asix_devices: Check return value of
  usbnet_get_endpoints (git-fixes).
- Bluetooth: btmtksdio: Add pmctrl handling for BT closed state
  during reset (git-fixes).
- Bluetooth: hci_sync: fix race in hci_cmd_sync_dequeue_once
  (git-fixes).
- usbnet: Prevents free active kevent (git-fixes).
- wifi: brcmfmac: fix crash while sending Action Frames in
  standalone AP Mode (git-fixes).
- wifi: ath12k: free skb during idr cleanup callback (git-fixes).
- wifi: ath11k: Add missing platform IDs for quirk table
  (git-fixes).
- wifi: ath10k: Fix memory leak on unsupported WMI command
  (git-fixes).
- wifi: mac80211: reset FILS discovery and unsol probe resp
  intervals (git-fixes).
- commit cc1ca5e

- bpf: Explicitly check accesses to bpf_sock_addr (CVE-2025-40078
  bsc#1252789).
- commit 6edd4b3

- KVM: x86: Take irqfds.lock when adding/deleting IRQ bypass
  producer (git-fixes).
- commit fdfcdff

- KVM: x86: Plumb in the vCPU to kvm_x86_ops.hwapic_isr_update()
  (git-fixes).
- commit cb2e3ab

- kdb: Replace deprecated strcpy() with memmove() in vkdb_printf()
  (bsc#1252939).
- commit 7cb788c

- Revert &amp;quot;KVM: VMX: Move LOAD_IA32_PERF_GLOBAL_CTRL errata
  handling out of setup_vmcs_config()&amp;quot; (git-fixes).
- commit 769724a

- hfsplus: fix KMSAN uninit-value issue in hfsplus_delete_cat()
  (git-fixes).
- commit 40898e0

- hfsplus: fix KMSAN uninit-value issue in
  __hfsplus_ext_cache_extent() (git-fixes).
- commit a2e4db9

- hfs: validate record offset in hfsplus_bmap_alloc (git-fixes).
- commit 693ef92

- hfsplus: return EIO when type of hidden directory mismatch in
  hfsplus_fill_super() (git-fixes).
- commit 6aec9cc

- ARM: tegra: Use I/O memcpy to write to IRAM (CVE-2025-39794 bsc#1249595)
- commit ad8d355

- ipvs: Defer ip_vs_ftp unregister during netns cleanup
  (CVE-2025-40018 bsc#1252688).
- commit d48a123

- NFSD: Fix crash in nfsd4_read_release() (git-fixes).
- commit 1a326b8

- Fix Git-commit for patches.suse/cxl-downgrade-a-warning-message-to-debug-level-in-cxl.patch.
- commit 31a5035

- bpf: Allow helper bpf_get_[ns_]current_pid_tgid() for all prog
  types (bsc#1252364).
- commit 82fd58d

- tcp: Don't call reqsk_fastopen_remove() in tcp_conn_request()
  (git-fixes).
- commit fceae30

- octeontx2-pf: Fix potential use after free in otx2_tc_add_flow()
  (CVE-2025-39978 bsc#1252069).
- tcp: Clear tcp_sk(sk)-&amp;gt;fastopen_rsk in tcp_disconnect()
  (CVE-2025-39955 bsc#1251804).
- commit 0468786

- Revert &amp;quot;e1000e: fix heap overflow in e1000_set_eeprom (CVE-2025-39898&amp;quot;
  This reverts commit df2ae2c1bd0dd998b7e23e3d49e90e95ada467f0.
- commit 79fa523

- i40e: add max boundary check for VF filters (CVE-2025-39968
  bsc#1252047).
- i40e: fix validation of VF state in get resources
  (CVE-2025-39969 bsc#1252044).
- i40e: fix idx validation in i40e_validate_queue_map
  (CVE-2025-39972 bsc#1252039).
- i40e: add validation for ring_len param (CVE-2025-39973
  bsc#1252035).
- ice: fix Rx page leak on multi-buffer frames (CVE-2025-39948
  bsc#1251233).
- qed: Don't collect too many protection override GRC elements
  (CVE-2025-39949 bsc#1251177).
- commit 2c4293d

- Delete
  patches.suse/cpuidle-menu-Avoid-discarding-useful-information.patch.
- commit c2e3ac6

- Delete
  patches.suse/cpuidle-governors-menu-Avoid-using-invalid-recent-intervals-data.patch.
- commit b1a47b7

- nvme/tcp: handle tls partially sent records in write_space()
  (git-fixes).
- nvme-multipath: Skip nr_active increments in RETRY disposition
  (git-fixes).
- nvme-pci: Add TUXEDO IBS Gen8 to Samsung sleep quirk
  (git-fixes).
- commit 4b35633

- ACPI: battery: Add synchronization between interface updates
  (git-fixes).
- locking/mutex: Mark devm_mutex_init() as __must_check
  (stable-fixes).
- ACPI: battery: Check for error code from devm_mutex_init()
  call (git-fixes).
- ACPI: battery: initialize mutexes through devm_ APIs
  (stable-fixes).
- accel/ivpu: Add missing MODULE_FIRMWARE metadata (git-fixes).
- locking/mutex: Introduce devm_mutex_init() (stable-fixes).
- commit 7bacc8f

- wifi: rtw89: fix use-after-free in
  rtw89_core_tx_kick_off_and_wait() (CVE-2025-40000 bsc#1252062).
- commit b7a479d

- sched/fair: set_load_weight() must also call reweight_task() (git-fixes)
- commit b185921

- misc: fastrpc: Save actual DMA size in fastrpc_map structure
  (git-fixes).
- Refresh
  patches.suse/misc-fastrpc-Skip-reference-for-DMA-handles.patch.
- commit b472422

- most: usb: hdm_probe: Fix calling put_device() before device
  initialization (git-fixes).
- most: usb: Fix use-after-free in hdm_disconnect (git-fixes).
- misc: fastrpc: Fix dma_buf object leak in fastrpc_map_lookup
  (git-fixes).
- serial: 8250_dw: handle reset control deassert error
  (git-fixes).
- xhci: dbc: enable back DbC in resume if it was enabled before
  suspend (git-fixes).
- spi: spi-nxp-fspi: add extra delay after dll locked (git-fixes).
- net: usb: rtl8150: Fix frame padding (git-fixes).
- HID: multitouch: fix name of Stylus input devices (git-fixes).
- HID: hid-input: only ignore 0 battery events for digitizers
  (git-fixes).
- r8169: fix packet truncation after S4 resume on
  RTL8168H/RTL8111H (git-fixes).
- rtc: interface: Ensure alarm irq is enabled when UIE is enabled
  (stable-fixes).
- rtc: interface: Fix long-standing race when setting alarm
  (stable-fixes).
- PCI: j721e: Fix programming sequence of &amp;quot;strap&amp;quot; settings
  (git-fixes).
- PCI: endpoint: pci-epf-test: Add NULL check for DMA channels
  before release (git-fixes).
- PCI/AER: Support errors introduced by PCIe r6.0 (stable-fixes).
- phy: cadence: cdns-dphy: Update calibration wait time for
  startup state machine (git-fixes).
- phy: cadence: cdns-dphy: Fix PLL lock and O_CMN_READY polling
  (git-fixes).
- phy: cdns-dphy: Store hs_clk_rate and return it (stable-fixes).
- mtd: rawnand: fsmc: Default to autodetect buswidth
  (stable-fixes).
- wifi: mt76: mt7921u: Add VID/PID for Netgear A7500
  (stable-fixes).
- media: nxp: imx8-isi: Drop unused argument to
  mxc_isi_channel_chain() (stable-fixes).
- mfd: intel_soc_pmic_chtdc_ti: Set use_single_read regmap_config
  flag (git-fixes).
- mmc: core: SPI mode remove cmd7 (stable-fixes).
- lib/crypto/curve25519-hacl64: Disable KASAN with clang-17 and
  older (stable-fixes).
- PM: runtime: Add new devm functions (stable-fixes).
- mfd: intel_soc_pmic_chtdc_ti: Drop unneeded assignment for
  cache_type (stable-fixes).
- mfd: intel_soc_pmic_chtdc_ti: Fix invalid regmap-config
  max_register value (stable-fixes).
- PCI: Add PCI_VDEVICE_SUB helper macro (stable-fixes).
- PCI: endpoint: Remove surplus return statement from
  pci_epf_test_clean_dma_chan() (stable-fixes).
- PCI: j721e: Enable ACSPCIE Refclk if
  &amp;quot;ti,syscon-acspcie-proxy-ctrl&amp;quot; exists (stable-fixes).
- misc: fastrpc: Add missing dev_err newlines (stable-fixes).
- commit 9f99f4e

- firmware: arm_scmi: Fix premature SCMI_XFER_FLAG_IS_RAW clearing
  in raw mode (git-fixes).
- drm/sched: Fix potential double free in
  drm_sched_job_add_resv_dependencies (git-fixes).
- drm/rockchip: vop2: use correct destination rectangle height
  check (git-fixes).
- drm/bridge: lt9211: Drop check for last nibble of version
  register (git-fixes).
- drm/amd/powerplay: Fix CIK shutdown temperature (git-fixes).
- drm/amdgpu: use atomic functions with memory barriers for vm
  fault info (git-fixes).
- drm/i915/guc: Skip communication warning on reset in progress
  (git-fixes).
- drm/amd: Check whether secure display TA loaded successfully
  (stable-fixes).
- drm/exynos: exynos7_drm_decon: properly clear channels during
  bind (stable-fixes).
- drm/exynos: exynos7_drm_decon: fix uninitialized crtc reference
  in functions (stable-fixes).
- commit 110d102

- can: netlink: can_changelink(): allow disabling of automatic
  restart (git-fixes).
- can: bxcan: bxcan_start_xmit(): use can_dev_dropped_skb()
  instead of can_dropped_invalid_skb() (git-fixes).
- ASoC: nau8821: Add DMI quirk to bypass jack debounce circuit
  (git-fixes).
- ASoC: nau8821: Generalize helper to clear IRQ status
  (git-fixes).
- ASoC: nau8821: Cancel jdet_work before handling jack ejection
  (git-fixes).
- ASoC: codecs: Fix gain setting ranges for Renesas IDT821034
  codec (git-fixes).
- ALSA: usb-audio: Fix NULL pointer deference in
  try_to_register_card (git-fixes).
- ALSA: firewire: amdtp-stream: fix enum kernel-doc warnings
  (git-fixes).
- accel/qaic: Treat remaining == 0 as error in
  find_and_map_user_pages() (git-fixes).
- Bluetooth: btusb: Add USB ID 2001:332a for D-Link AX9U rev. A1
  (stable-fixes).
- ACPI: property: Add code comments explaining what is going on
  (stable-fixes).
- ACPI: property: Disregard references in data-only subnode lists
  (stable-fixes).
- ACPICA: Allow to skip Global Lock initialization (stable-fixes).
- ACPI: battery: allocate driver data through devm_ APIs
  (stable-fixes).
- drm/msm/adreno: De-spaghettify the use of memory barriers
  (stable-fixes).
- commit e53e617

- spi: cadence-quadspi: Implement refcount to handle unbind
  during busy (CVE-2025-40005 bsc#1252349).
- commit 7406f70

- i40e: fix idx validation in config queues msg (CVE-2025-39971 bsc#1252052)
- commit 70699a8

- i40e: fix input validation logic for action_meta (CVE-2025-39970 bsc#1252051)
- commit 57401e3

- arm64, mm: avoid always making PTE dirty in pte_mkwrite() (git-fixes)
- commit 59db3fb

- arm64: errata: Apply workarounds for Neoverse-V3AE (git-fixes)
- commit da235eb

- arm64: cputype: Add Neoverse-V3AE definitions (git-fixes)
- commit 5587842

- NFSD: Minor cleanup in layoutcommit processing (git-fixes).
- commit baef4e7

- NFSD: Rework encoding and decoding of nfsd4_deviceid
  (git-fixes).
- commit 72f1d28

- hfsplus: fix slab-out-of-bounds read in hfsplus_strcasecmp()
  (git-fixes).
- commit a6f88ab

- xfs: rename the old_crc variable in xlog_recover_process
  (git-fixes).
- commit 677fb8c

- net: fec: Fix possible NPD in fec_enet_phy_reset_after_clk_enable() (CVE-2025-39876 bsc#1250400)
- commit 137f367

- proc: fix type confusion in pde_set_flags() (bsc#1248630)
- commit c6a1bb4

- proc: fix missing pde_set_flags() for net proc files (bsc#1248630)
- commit 539da61

- proc: use the same treatment to check proc_lseek as ones for proc_read_iter et.al (CVE-2025-38653 bsc#1248630)
- commit bcff9b5

- ovl: fix file reference leak when submitting aio (stable-fixes).
- commit 57db5b5

- KVM: x86: Set PVCLOCK_GUEST_STOPPED only for kvmclock, not
  for Xen PV clock (git-fixes).
- commit 85e57cf

- KVM: x86: Don't bleed PVCLOCK_GUEST_STOPPED across PV clocks
  (git-fixes).
- commit cd63f69

- KVM: x86: Process &amp;quot;guest stopped request&amp;quot; once per guest time
  update (git-fixes).
- commit 29a55cf

- add bug reference to existing hv_netvsc change (bsc#1252265)
- commit 95261dd

- KVM: SVM: Inject #GP if memory operand for INVPCID is
  non-canonical (git-fixes).
- commit ed9dfb1

- KVM: x86: Clear pv_unhalted on all transitions to
  KVM_MP_STATE_RUNNABLE (git-fixes).
- commit f4d45de

- KVM: x86: Introduce kvm_set_mp_state() (git-fixes).
- commit 4b1f2ec

- NFS: Fix a race when updating an existing write (bsc#1249319
  bsc#1252236 CVE-2025-39697).
- commit 40cab0c

- nfs: Add missing release on error in
  nfs_lock_and_join_requests() (bsc#1249319 bsc#1252236
  CVE-2025-39697).
- commit b903556

- nfs: fold nfs_page_group_lock_subrequests into
  nfs_lock_and_join_requests (bsc#1249319 bsc#1252236
  CVE-2025-39697).
- commit 13ceff1

- nfs: fold nfs_folio_find_and_lock_request into
  nfs_lock_and_join_requests (bsc#1249319 bsc#1252236
  CVE-2025-39697).
- commit 14874ac

- nfs: simplify nfs_folio_find_and_lock_request (bsc#1249319
  bsc#1252236 CVE-2025-39697).
- commit 1b25c26

- nfs: remove nfs_folio_private_request (bsc#1249319 bsc#1252236
  CVE-2025-39697).
- commit c28ea5d

- nfs: remove dead code for the old swap over NFS implementation
  (bsc#1249319 bsc#1252236 CVE-2025-39697).
- Refresh
  patches.suse/NFS-fix-nfs_release_folio-to-not-deadlock-via-kcompa.patch.
- commit e7a5c52

- kABI fix for KVM: x86: Snapshot the host's DEBUGCTL in common
  x86 (git-fixes).
- commit 0bb2570

- overlayfs: set ctime when setting mtime and atime
  (stable-fixes).
- ovl: fix incorrect fdput() on aio completion (stable-fixes).
- ovl: Always reevaluate the file signature for IMA
  (stable-fixes).
- commit 4cfc4ed

- i40e: fix IRQ freeing in i40e_vsi_request_irq_msix error path (CVE-2025-39911 bsc#1250704)
- commit 627f938

- sched: Fix sched_numa_find_nth_cpu() if mask offline (CVE-2025-39895 bsc#1250721)
- commit 581de7a

- sctp: initialize more fields in sctp_v6_from_sk() (CVE-2025-39812 bsc#1250202)
- commit 56a7db3

- ipv6: sr: Fix MAC comparison to be constant-time (CVE-2025-39702 bsc#1249317)
- commit 3d85c5c

- sctp: linearize cloned gso packets in sctp_rcv (CVE-2025-38718 bsc#1249161)
- commit 0083867

- scsi: qla4xxx: Prevent a potential error pointer dereference (CVE-2025-39676 bsc#1249302)
- commit a3b8686

- net: usb: lan78xx: Add error handling to
  lan78xx_init_mac_address (git-fixes).
- commit f1ec116

- net/mlx5e: Harden uplink netdev access against device unbind
  (CVE-2025-39947 bsc#1251232).
- commit d4278a0

- KVM: x86: Snapshot the host's DEBUGCTL after disabling IRQs
  (git-fixes).
- commit 09e399f

- KVM: x86: Bypass register cache when querying CPL from
  kvm_sched_out() (git-fixes).
- commit 27a06fc

- net: usb: lan78xx: fix use of improperly initialized dev-&amp;gt;chipid
  in lan78xx_reset (git-fixes).
- commit ad26239

- r8152: add error handling in rtl8152_driver_init (git-fixes).
- commit db73d98

- usbnet: Fix using smp_processor_id() in preemptible code
  warnings (git-fixes).
- commit b2c518b

- config.sh: Update IBS project
- commit f8ef735

- cpufreq: scmi: Account for malformed DT in
  scmi_dev_used_by_cpus() (git-fixes).
- commit 149500a

- cpuidle: governors: menu: Avoid using invalid recent intervals
  data (git-fixes).
- commit a4ef664

- hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()
  (git-fixes).
- commit baddd40

- selftests/bpf: Fix backtrace printing for selftests crashes
  (git-fixes).
- commit 63e24c4

- tools/resolve_btfids: Fix build when cross compiling kernel
  with clang (git-fixes).
- commit f4f0a36

- samples/bpf: Fix compilation failure for samples/bpf on
  LoongArch Fedora (git-fixes).
- commit fa036e9

- selftests/bpf: Fix cross-compiling urandom_read (git-fixes).
- commit d19eec5

- selftests/bpf: Fix compile if backtrace support missing in libc
  (git-fixes).
- commit 3353a4b

- selftests/bpf: Fix redefinition errors compiling lwt_reroute.c
  (git-fixes).
- commit b5270ce

- selftests/bpf: Fix C++ compile error from missing _Bool type
  (git-fixes).
- commit 736692a

- selftests/bpf: Fix error compiling test_lru_map.c (git-fixes).
- commit 8aa3099

- selftests/bpf: Fix compile error from rlim_t in sk_storage_map.c
  (git-fixes).
- commit 35f5a49

- perf/core: Fix the WARN_ON_ONCE is out of lock protected region
  (git-fixes).
- perf/x86/intel: Fix crash in icl_update_topdown_event()
  (git-fixes).
- perf/x86: Fix non-sampling (counting) events on certain x86
  platforms (git-fixes).
- commit 814983a

- doc/README.SUSE: Correct the character used for TAINT_NO_SUPPORT
  The character was previously 'N', but upstream used it for TAINT_TEST,
  which prompted the change of TAINT_NO_SUPPORT to 'n'. This occurred in
  commit c35dc3823d08 (&amp;quot;Update to 6.0-rc1&amp;quot;) on master and in d016c04d731d
  (&amp;quot;Bump to 6.4 kernel (jsc#PED-4593)&amp;quot;) for SLE15-SP6 (and onwards).
  Update the documentation to reflect this change.
- commit f42ecf5

- ACPI: property: Do not pass NULL handles to acpi_attach_data()
  (stable-fixes git-fixes).
- commit 19fb175

- ACPI: APEI: GHES: add TAINT_MACHINE_CHECK on GHES panic path
  (stable-fixes).
- commit d0f4111

- cpufreq: CPPC: fix perf_to_khz/khz_to_perf conversion exception
  (git-fixes).
- commit 59c2171

- ACPI: x86: Move acpi_quirk_skip_serdev_enumeration() out of
  CONFIG_X86_ANDROID_TABLETS (stable-fixes).
- commit 793bb70

- cpuidle: qcom-spm: fix device and OF node leaks at probe
  (git-fixes).
- commit 39be628

- cpuidle: menu: Avoid discarding useful information
  (stable-fixes).
- commit b136410

- cpufreq: tegra186: Set target frequency for all cpus in policy
  (git-fixes).
- commit e1cfca8

- cpufreq: intel_pstate: Fix object lifecycle issue in
  update_qos_request() (stable-fixes git-fixes).
- commit 8b10f36

- cpufreq: armada-8k: Fix off by one in
  armada_8k_cpufreq_free_table() (stable-fixes git-fixes).
- commit 3e7dc0b

- cpufreq: scmi: Skip SCMI devices that aren't used by the CPUs
  (stable-fixes).
- commit 2dde40f

- tcp_bpf: Fix copied value in tcp_bpf_sendmsg (bsc#1250650).
- skmsg: Return copied bytes in sk_msg_memcopy_from_iter
  (bsc#1250650).
- commit 5925a0e

- sched/idle: Conditionally handle tick broadcast in
  default_idle_call() (bsc#1248517).
- Update config files.
- commit 1a58311

- x86/idle: Sanitize X86_BUG_AMD_E400 handling (bsc#1248517).
- Refresh
  patches.suse/x86-tdx-Fix-arch_safe_halt-execution-for-TDX-VMs.patch.
- commit be42a2d

- perf/aux: Fix pending disable flow when the AUX ring buffer
  overruns (git-fixes).
- perf/core: Fix WARN in perf_cgroup_switch() (git-fixes).
- perf: Fix cgroup state vs ERROR (git-fixes).
- perf/core: Fix broken throttling when max_samples_per_tick=1
  (git-fixes).
- perf: Ensure bpf_perf_link path is properly serialized
  (git-fixes).
- perf/x86/intel: Only check the group flag for X86 leader
  (git-fixes).
- perf/x86/intel: Allow to update user space GPRs from PEBS
  records (git-fixes).
- perf/x86/intel/uncore: Fix the scale of IIO free running
  counters on SPR (git-fixes).
- perf/x86/intel/uncore: Fix the scale of IIO free running
  counters on ICX (git-fixes).
- perf/x86/intel/uncore: Fix the scale of IIO free running
  counters on SNR (git-fixes).
- perf/core: Fix child_total_time_enabled accounting bug at task
  exit (git-fixes).
- perf/ring_buffer: Allow the EPOLLRDNORM flag for poll
  (git-fixes).
- perf/bpf: Robustify perf_event_free_bpf_prog() (git-fixes).
- perf/hw_breakpoint: Return EOPNOTSUPP for unsupported breakpoint
  type (git-fixes).
- perf/x86/intel: Avoid disable PMU if !cpuc-&amp;gt;enabled in sample
  read (git-fixes).
- perf/x86/intel: Apply static call for drain_pebs (git-fixes).
- perf/amd/ibs: Fix perf_ibs_op.cnt_mask for CurCnt (git-fixes).
- perf/amd/ibs: Fix -&amp;gt;config to sample period calculation for
  OP PMU (git-fixes).
- perf/core: Fix pmus_lock vs. pmus_srcu ordering (git-fixes).
- perf/x86/intel: Use better start period for frequency mode
  (git-fixes).
- perf/core: Fix low freq setting via IOC_PERIOD (git-fixes).
- perf/x86: Fix low freqency setting issue (git-fixes).
- perf/x86/intel/ds: Unconditionally drain PEBS DS when changing
  PEBS_DATA_CFG (git-fixes).
- perf/x86/amd: Warn only on new bits set (git-fixes).
- s390: Initialize psw mask in perf_arch_fetch_caller_regs()
  (git-fixes).
- perf/core: Fix small negative period being ignored (git-fixes).
- perf: Extract a few helpers (git-fixes).
- perf/x86/intel/pt: Fix sampling synchronization (git-fixes).
- perf/x86/intel: Allow to setup LBR for counting event for BPF
  (git-fixes).
- drivers/perf: arm_spe: Use perf_allow_kernel() for permissions
  (git-fixes).
- perf/amd: Prevent grouping of IBS events (git-fixes).
- commit 76eb280

- tls: make sure to abort the stream if headers are bogus
  (CVE-2025-39946 bsc#1251114).
- commit d62deaa

- selftests/bpf: Fix error compiling tc_redirect.c with musl libc
  (git-fixes).
- commit b2a359c

- selftests/bpf: Fix errors compiling cg_storage_multi.h with
  musl libc (git-fixes).
- commit 799529b

- selftests/bpf: Fix errors compiling decap_sanity.c with musl
  libc (git-fixes).
- commit f14b275

- selftests/bpf: Fix errors compiling lwt_redirect.c with musl
  libc (git-fixes).
- commit 498999e

- selftests/bpf: Fix compiling core_reloc.c with musl-libc
  (git-fixes).
- commit eb3a7bd

- selftests/bpf: Fix compiling tcp_rtt.c with musl-libc
  (git-fixes).
- commit 109e7cc

- selftests/bpf: Fix compiling flow_dissector.c with musl-libc
  (git-fixes).
- commit 9b43d04

- selftests/bpf: Fix compiling kfree_skb.c with musl-libc
  (git-fixes).
- commit 442e8bf

- selftests/bpf: Fix compiling parse_tcp_hdr_opt.c with musl-libc
  (git-fixes).
- commit 1f65169

- selftests/bpf: Fix error compiling bpf_iter_setsockopt.c with
  musl libc (git-fixes).
- commit 7613608

- selftests/bpf: Add test for unpinning htab with internal timer
  struct (git-fixes).
- commit 8a1df26

- bpf: Avoid RCU context warning when unpinning htab with internal
  structs (git-fixes).
- commit 73d4d2d

- bpf: Fix metadata_dst leak __bpf_redirect_neigh_v{4,6}
  (git-fixes).
- commit 1a82fe5

- kabi: hide new member allow_subflows in struct mptcp_sock
  (CVE-2025-38552 bsc#1248230).
- commit f51a25e

- mptcp: plug races between subflow fail and subflow creation
  (CVE-2025-38552 bsc#1248230).
- Refresh
  patches.kabi/kabi-hide-new-member-fallback_lock-in-struct-mptcp_s.patch.
  (also delete outdated part of a comment)
- commit fdbbed8

- Update
  patches.suse/ALSA-ac97-Fix-possible-NULL-dereference-in-snd_.patch
  (bsc#1012628 CVE-2023-53648 bsc#1251750).
- Update
  patches.suse/ASoC-codecs-wcd938x-fix-missing-mbhc-init-error.patch
  (bsc#1012628 CVE-2023-53666 bsc#1251760).
- Update
  patches.suse/ASoC-qcom-q6apm-lpass-dais-Fix-NULL-pointer-derefere.patch
  (git-fixes CVE-2025-39938 bsc#1251134).
- Update
  patches.suse/Bluetooth-hci_event-call-disconnect-callback-be.patch
  (bsc#1012628 CVE-2023-53673 bsc#1251763).
- Update
  patches.suse/HID-hyperv-avoid-struct-memcpy-overrun-warning.patch
  (bsc#1012628 CVE-2023-53553 bsc#1251068).
- Update
  patches.suse/KVM-nSVM-Check-instead-of-asserting-on-nested-TSC-sc.patch
  (git-fixes CVE-2023-53663 bsc#1251290).
- Update
  patches.suse/RDMA-rxe-Fix-incomplete-state-save-in-rxe_requester.patch
  (git-fixes CVE-2023-53539 bsc#1251060).
- Update
  patches.suse/USB-Gadget-core-Help-prevent-panic-during-UVC-.patch
  (bsc#1012628 CVE-2023-53580 bsc#1251105).
- Update
  patches.suse/accel-qaic-Fix-a-leak-in-map_user_pages.patch
  (bsc#1012628 CVE-2023-53633 bsc#1251746).
- Update
  patches.suse/bcache-Fix-__bch_btree_node_alloc-to-make-the-f.patch
  (bsc#1012628 CVE-2023-53681 bsc#1251769).
- Update
  patches.suse/bonding-do-not-assume-skb-mac_header-is-set.patch
  (bsc#1012628 CVE-2023-53601 bsc#1251153).
- Update
  patches.suse/bpf-Make-bpf_refcount_acquire-fallible-for-non-.patch
  (bsc#1012628 CVE-2023-53645 bsc#1251321).
- Update
  patches.suse/bpf-cpumap-Handle-skb-as-well-when-clean-up-pt.patch
  (bsc#1012628 CVE-2023-53660 bsc#1251721).
- Update
  patches.suse/bpf-cpumap-Make-sure-kthread-is-running-before.patch
  (bsc#1012628 CVE-2023-53577 bsc#1251028).
- Update
  patches.suse/bpf-reject-unhashed-sockets-in-bpf_sk_assign.patch
  (jsc#PED-6811 CVE-2023-53585 bsc#1251126).
- Update
  patches.suse/btrfs-insert-tree-mod-log-move-in-push_node_lef.patch
  (bsc#1012628 CVE-2023-53538 bsc#1251024).
- Update
  patches.suse/btrfs-output-extra-debug-info-if-we-failed-to-find-a.patch
  (git-fixes CVE-2023-53672 bsc#1251780).
- Update
  patches.suse/btrfs-reject-invalid-reloc-tree-root-keys-with.patch
  (bsc#1012628 CVE-2023-53618 bsc#1251748).
- Update
  patches.suse/cifs-Release-folio-lock-on-fscache-read-hit.patch
  (bsc#1012628 CVE-2023-53593 bsc#1251132).
- Update
  patches.suse/cifs-fix-mid-leak-during-reconnection-after-tim.patch
  (bsc#1012628 CVE-2023-53597 bsc#1251159).
- Update
  patches.suse/clk-Fix-memory-leak-in-devm_clk_notifier_regist.patch
  (bsc#1012628 CVE-2023-53674 bsc#1251764).
- Update
  patches.suse/clk-imx-scu-use-_safe-list-iterator-to-avoid-a-.patch
  (bsc#1012628 CVE-2023-53572 bsc#1251027).
- Update
  patches.suse/cpufreq-amd-pstate-fix-global-sysfs-attribute-.patch
  (bsc#1012628 CVE-2023-53550 bsc#1251071).
- Update
  patches.suse/cpufreq-amd-pstate-ut-Fix-kernel-panic-when-loading-.patch
  (git-fixes CVE-2023-53563 bsc#1251038).
- Update
  patches.suse/crypto-af_alg-Fix-missing-initialisation-affecting-g.patch
  (bsc#1216396 CVE-2023-53599 bsc#1251150).
- Update
  patches.suse/crypto-af_alg-Set-merge-to-zero-early-in-af_alg_send.patch
  (git-fixes CVE-2025-39931 bsc#1251100).
- Update
  patches.suse/dax-Fix-dax_mapping_release-use-after-free.patch
  (bsc#1012628 CVE-2023-53613 bsc#1251119).
- Update
  patches.suse/drivers-base-Free-devm-resources-when-unregistering-.patch
  (jsc#PED-6054 CVE-2023-53596 bsc#1251161).
- Update
  patches.suse/drivers-perf-hisi-Don-t-migrate-perf-to-the-CPU.patch
  (bsc#1012628 CVE-2023-53656 bsc#1251758).
- Update
  patches.suse/drm-amdgpu-unmap-and-remove-csa_va-properly.patch
  (jsc#PED-3527 jsc#PED-5475 jsc#PED-6068 jsc#PED-6070
  jsc#PED-6116 jsc#PED-6120 jsc#PED-5065 jsc#PED-5477 jsc#PED-5511
  jsc#PED-6041 jsc#PED-6069 jsc#PED-6071 CVE-2023-53545
  bsc#1251084).
- Update
  patches.suse/drm-bridge-anx7625-Fix-NULL-pointer-dereference-with.patch
  (git-fixes CVE-2025-39934 bsc#1251146).
- Update
  patches.suse/drm-i915-mark-requests-for-GuC-virtual-engines-to-av.patch
  (jsc#PED-3527 jsc#PED-5475 jsc#PED-6068 jsc#PED-6070
  jsc#PED-6116 jsc#PED-6120 jsc#PED-5065 jsc#PED-5477 jsc#PED-5511
  jsc#PED-6041 jsc#PED-6069 jsc#PED-6071 CVE-2023-53552
  bsc#1251065).
- Update
  patches.suse/drm-i915-perf-add-sentinel-to-xehp_oa_b_counter.patch
  (jsc#PED-3527 jsc#PED-5475 jsc#PED-6068 jsc#PED-6070
  jsc#PED-6116 jsc#PED-6120 jsc#PED-5065 jsc#PED-5477 jsc#PED-5511
  jsc#PED-6041 jsc#PED-6069 jsc#PED-6071 CVE-2023-53646
  bsc#1251742).
- Update
  patches.suse/ext4-fix-memory-leaks-in-ext4_fname_-setup_filename-.patch
  (bsc#1214954 CVE-2023-53662 bsc#1251282).
- Update
  patches.suse/fbdev-omapfb-lcd_mipid-Fix-an-error-handling-pa.patch
  (jsc#PED-3527 jsc#PED-5475 jsc#PED-6068 jsc#PED-6070
  jsc#PED-6116 jsc#PED-6120 jsc#PED-5065 jsc#PED-5477 jsc#PED-5511
  jsc#PED-6041 jsc#PED-6069 jsc#PED-6071 CVE-2023-53650
  bsc#1251283).
- Update
  patches.suse/fprobe-Release-rethook-after-the-ftrace_ops-is-.patch
  (bsc#1012628 CVE-2023-53557 bsc#1251054).
- Update
  patches.suse/gfs2-Fix-possible-data-races-in-gfs2_show_opti.patch
  (bsc#1012628 CVE-2023-53622 bsc#1251777).
- Update patches.suse/gpio-mvebu-fix-irq-domain-leak.patch
  (bsc#1012628 CVE-2023-53579 bsc#1251170).
- Update
  patches.suse/iavf-Fix-out-of-bounds-when-setting-channels-on.patch
  (bsc#1012628 CVE-2023-53659 bsc#1251247).
- Update patches.suse/iavf-Fix-use-after-free-in-free_netdev.patch
  (bsc#1012628 CVE-2023-53556 bsc#1251059).
- Update
  patches.suse/ice-Don-t-tx-before-switchdev-is-fully-configured.patch
  (jsc#PED-4876 CVE-2023-53657 bsc#1251319).
- Update
  patches.suse/ip_vti-fix-potential-slab-use-after-free-in-de.patch
  (bsc#1012628 CVE-2023-53559 bsc#1251052).
- Update patches.suse/ipmi_si-fix-a-memleak-in-try_smi_init.patch
  (git-fixes CVE-2023-53611 bsc#1251123).
- Update
  patches.suse/jfs-fix-invalid-free-of-JFS_IP-ipimap-i_imap-in-diUnmount.patch
  (git-fixes CVE-2023-53616 bsc#1251215).
- Update
  patches.suse/md-don-t-dereference-mddev-after-export_rdev-7dea.patch
  (jsc#PED-7542 CVE-2023-53665 bsc#1251270).
- Update
  patches.suse/media-amphion-fix-REVERSE_INULL-issues-reported-by-c.patch
  (git-fixes CVE-2023-53653 bsc#1251755).
- Update
  patches.suse/memcontrol-ensure-memcg-acquired-by-id-is-properly-s.patch
  (git-fixes CVE-2023-53621 bsc#1251323).
- Update
  patches.suse/mm-damon-core-initialize-damo_filter-list-from.patch
  (bsc#1012628 CVE-2023-53555 bsc#1251056).
- Update
  patches.suse/msft-hv-2870-Drivers-hv-vmbus-Don-t-dereference-ACPI-root-object-.patch
  (git-fixes CVE-2023-53647 bsc#1251732).
- Update
  patches.suse/mtd-rawnand-brcmnand-Fix-potential-out-of-bounds-acc.patch
  (git-fixes CVE-2023-53541 bsc#1251043).
- Update
  patches.suse/net-handshake-fix-null-ptr-deref-in-handshake_nl_don.patch
  (bsc#1220419 CVE-2023-53686 bsc#1251771).
- Update
  patches.suse/net-mlx5-DR-fix-memory-leak-in-mlx5dr_cmd_crea.patch
  (bsc#1012628 CVE-2023-53546 bsc#1251079).
- Update
  patches.suse/net-mlx5e-Check-for-NOT_READY-flag-state-after-.patch
  (bsc#1012628 CVE-2023-53581 bsc#1251106).
- Update
  patches.suse/net-mlx5e-Take-RTNL-lock-when-needed-before-ca.patch
  (bsc#1012628 CVE-2023-53632 bsc#1251269).
- Update
  patches.suse/net-rfkill-gpio-Fix-crash-due-to-dereferencering-uni.patch
  (git-fixes CVE-2025-39937 bsc#1251143).
- Update
  patches.suse/net-usbnet-Fix-WARNING-in-usbnet_start_xmit-us.patch
  (bsc#1012628 CVE-2023-53548 bsc#1251066).
- Update
  patches.suse/netfilter-conntrack-Avoid-nf_ct_helper_hash-use.patch
  (bsc#1012628 CVE-2023-53619 bsc#1251743).
- Update patches.suse/nvme-core-fix-dev_pm_qos-memleak.patch
  (bsc#1012628 CVE-2023-53670 bsc#1251762).
- Update
  patches.suse/octeon_ep-cancel-queued-works-in-probe-error-p.patch
  (bsc#1012628 CVE-2023-53638 bsc#1251328).
- Update
  patches.suse/octeontx2-af-Add-validation-before-accessing-cg.patch
  (bsc#1012628 CVE-2023-53654 bsc#1251756).
- Update
  patches.suse/perf-RISC-V-Remove-PERF_HES_STOPPED-flag-checki.patch
  (bsc#1012628 CVE-2023-53583 bsc#1251108).
- Update
  patches.suse/perf-trace-Really-free-the-evsel-priv-area.patch
  (perf-v6.7 (jsc#PED-6012 jsc#PED-6121) CVE-2023-53649
  bsc#1251749).
- Update
  patches.suse/platform-x86-dell-sysman-Fix-reference-leak.patch
  (git-fixes CVE-2023-53631 bsc#1251529).
- Update
  patches.suse/rcu-tasks-Avoid-pr_info-with-spin-lock-in-cblis.patch
  (bsc#1012628 CVE-2023-53558 bsc#1251081).
- Update
  patches.suse/ring-buffer-Fix-deadloop-issue-on-reading-trace.patch
  (bsc#1012628 CVE-2023-53668 bsc#1251286).
- Update
  patches.suse/s390-zcrypt-don-t-leak-memory-if-dev_set_name-fails.patch
  (git-fixes bsc#1215143 CVE-2023-53568 bsc#1251035).
- Update
  patches.suse/scsi-qla2xxx-Avoid-fcport-pointer-dereference.patch
  (bsc#1012628 CVE-2023-53603 bsc#1251180).
- Update
  patches.suse/scsi-qla2xxx-Fix-deletion-race-condition.patch
  (git-fixes CVE-2023-53615 bsc#1251113).
- Update
  patches.suse/soc-aspeed-socinfo-Add-kfree-for-kstrdup.patch
  (bsc#1012628 CVE-2023-53617 bsc#1251268).
- Update
  patches.suse/spi-bcm-qspi-return-error-if-neither-hif_mspi-n.patch
  (bsc#1012628 CVE-2023-53658 bsc#1251759).
- Update
  patches.suse/staging-ks7010-potential-buffer-overflow-in-ks_.patch
  (bsc#1012628 CVE-2023-53554 bsc#1251057).
- Update
  patches.suse/tracing-histograms-Add-histograms-to-hist_vars-.patch
  (bsc#1012628 CVE-2023-53560 bsc#1251045).
- Update
  patches.suse/tty-serial-samsung_tty-Fix-a-memory-leak-in-s3c-832e231.patch
  (bsc#1012628 CVE-2023-53687 bsc#1251772).
- Update
  patches.suse/tunnels-fix-kasan-splat-when-generating-ipv4-p.patch
  (bsc#1012628 CVE-2023-53600 bsc#1251152).
- Update
  patches.suse/vdpa-Add-features-attr-to-vdpa_nl_policy-for-n.patch
  (bsc#1012628 CVE-2023-53652 bsc#1251754).
- Update
  patches.suse/vdpa-Add-max-vqp-attr-to-vdpa_nl_policy-for-nl.patch
  (bsc#1012628 CVE-2023-53543 bsc#1251083).
- Update
  patches.suse/wifi-ath11k-fix-memory-leak-in-WMI-firmware-sta.patch
  (bsc#1012628 CVE-2023-53602 bsc#1251076).
- Update
  patches.suse/wifi-cfg80211-reject-auth-assoc-to-AP-with-our-addre.patch
  (git-fixes CVE-2023-53540 bsc#1251053).
- Update
  patches.suse/wifi-iwlwifi-mvm-fix-potential-array-out-of-bou.patch
  (bsc#1012628 CVE-2023-53575 bsc#1251067).
- Update
  patches.suse/wifi-mac80211-check-for-station-first-in-client-prob.patch
  (git-fixes CVE-2023-53588 bsc#1251206).
- Update
  patches.suse/wifi-mac80211-increase-scan_ies_len-for-S1G.patch
  (stable-fixes CVE-2025-39957 bsc#1251810).
- Update
  patches.suse/wifi-nl80211-fix-integer-overflow-in-nl80211_p.patch
  (bsc#1012628 CVE-2023-53570 bsc#1251031).
- Update
  patches.suse/wifi-rtw88-delete-timer-and-free-skb-queue-when-unlo.patch
  (git-fixes CVE-2023-53574 bsc#1251222).
- Update
  patches.suse/wifi-wilc1000-avoid-buffer-overflow-in-WID-string-co.patch
  (stable-fixes CVE-2025-39952 bsc#1251216).
- commit 56ea93d

- iommu/vt-d: Disallow dirty tracking if incoherent page walk
  (git-fixes).
- iommu/vt-d: PRS isn't usable if PDS isn't supported (git-fixes).
- commit 9da1184

- mm/page_alloc: fix race condition in unaccepted memory handling
  (CVE-2025-38008 bsc#1244939).
- commit b445cb1

- mm/slub: avoid accessing metadata when pointer is invalid in
  object_err() (CVE-2025-39902 bsc#1250702).
- commit 46c39b3

- NFSD: Define a proc_layoutcommit for the FlexFiles layout type
  (git-fixes).
- commit b115f79

- tracing: Fix filter string testing (git-fixes).
- commit 864d37b

- selftests/tracing: Fix event filter test to retry up to 10 times
  (git-fixes).
- commit a9de969

- tracing/selftests: Fix kprobe event name test for
  .isra. functions (git-fixes).
- commit 6a094d4

- bpf: Check link_create.flags parameter for multi_kprobe
  (git-fixes).
- commit 0e75825

- bpf: Check link_create.flags parameter for multi_uprobe
  (git-fixes).
- commit 10550c7

- ftrace: fix incorrect hash size in register_ftrace_direct()
  (git-fixes).
- commit 9288055

- bpf: Use preempt_count() directly in bpf_send_signal_common()
  (git-fixes).
- commit 9258f2a

- tracing: Correct the refcount if the hist/hist_debug file
  fails to open (git-fixes).
- commit 6e8ac35

- module: Prevent silent truncation of module name in
  delete_module(2) (git-fixes).
- commit 44dc7b7

- tracing: Add down_write(trace_event_sem) when adding trace event
  (bsc#1248211 CVE-2025-38539).
- commit b1816b0

- tracing: Limit access to parser-&amp;gt;buffer when trace_get_user
  failed (bsc#1249286 CVE-2025-39683).
- tracing: Remove unneeded goto out logic (bsc#1249286).
- commit 8eaad3a

- ftrace: Also allocate and copy hash for reading of filter files
  (bsc#1250032 CVE-2025-39813).
- commit 69f706b

- media: i2c: tc358743: Fix use-after-free bugs caused by orphan
  timer in probe (git-fixes).
- commit 4cb2ef2

- media: solo6x10: replace max(a, min(b, c)) by clamp(b, a, c)
  (git-fixes).
- commit eb03975

- ftrace: Fix potential warning in trace_printk_seq during
  ftrace_dump (bsc#1250032 CVE-2025-39813).
- commit 287d6f8

- net: sysfs: Fix /sys/class/net/&amp;lt;iface&amp;gt; path (git-fixes).
- commit 753f6d8

- trace/fgraph: Fix the warning caused by missing unregister
  notifier (bsc#1248211 CVE-2025-38539).
- commit 739d6c6

- i2c: ocores: use devm_ managed clks (git-fixes).
- commit bc09888

- USB: serial: option: add SIMCom 8230C compositions (git-fixes).
- commit fbae6a0

- usb: phy: twl6030: Fix incorrect type for ret (git-fixes).
- commit 2464609

- net: mana: Use page pool fragments for RX buffers instead of
  full pages to improve memory efficiency (bsc#1248754).
- cnic: Fix use-after-free bugs in cnic_delete_task
  (CVE-2025-39945 bsc#1251230).
- commit 8a42c4d

- selinux: fix selinux_xfrm_alloc_user() to set correct ctx_len (git-fixes).
- commit 8628058

- powerpc/powernv/pci: Fix underflow and leak issue (bsc#1215199).
- powerpc/pseries/msi: Fix potential underflow and leak issue
  (bsc#1215199).
- powerpc/kvm: Fix ifdef to remove build warning (bsc#1215199).
- KVM: PPC: Fix misleading interrupts comment in
  kvmppc_prepare_to_enter() (bsc#1215199).
- powerpc: floppy: Add missing checks after DMA map (bsc#1215199).
- powerpc/boot: Fix build with gcc 15 (bsc#1215199).
- commit c79aae4

- crypto: rng - Ensure set_ent is always present (git-fixes).
- USB: serial: option: add SIMCom 8230C compositions
  (stable-fixes).
- wifi: rtlwifi: rtl8192cu: Don't claim USB ID 07b8:8188
  (stable-fixes).
- media: tuner: xc5000: Fix use-after-free in xc5000_release
  (git-fixes).
- driver core/PM: Set power.no_callbacks along with power.no_pm
  (stable-fixes).
- platform/x86/amd/pmc: Add Stellaris Slim Gen6 AMD to spurious
  8042 quirks list (stable-fixes).
- can: rcar_canfd: Fix controller mode setting (stable-fixes).
- can: hi311x: fix null pointer dereference when resuming from
  sleep before interface was enabled (stable-fixes).
- ASoC: rt5682s: Adjust SAR ADC button mode to fix noise issue
  (stable-fixes).
- ASoC: amd: acp: Adjust pdm gain value (stable-fixes).
- platform/x86/amd/pmc: Add MECHREVO Yilong15Pro to spurious_8042
  list (stable-fixes).
- hid: fix I2C read buffer overflow in raw_event() for mcp2221
  (stable-fixes).
- media: tunner: xc5000: Refactor firmware load (stable-fixes).
- commit 6771085

- rtc: optee: fix memory leak on driver removal (git-fixes).
- rtc: x1205: Fix Xicor X1205 vendor prefix (git-fixes).
- commit 3f4b7b9

- drm/amd/display: Disable scaling on DCE6 for now (git-fixes).
- drm/amd/display: Properly disable scaling on DCE6 (git-fixes).
- drm/amd/display: Properly clear SCL_*_FILTER_CONTROL on DCE6
  (git-fixes).
- drm/amd/display: Add missing DCE6 SCL_HORZ_FILTER_INIT* SRIs
  (git-fixes).
- drm/amdgpu: Add additional DCE6 SCL registers (git-fixes).
- drm/nouveau: fix bad ret code in nouveau_bo_move_prep
  (git-fixes).
- drm/vmwgfx: Fix copy-paste typo in validation (git-fixes).
- drm/vmwgfx: Fix Use-after-free in validation (git-fixes).
- drm/vmwgfx: Fix a null-ptr access in the cursor snooper
  (git-fixes).
- ASoC: SOF: ipc4-topology: Correct the minimum host DMA buffer
  size (git-fixes).
- ASoC: SOF: ipc3-topology: Fix multi-core and static pipelines
  tear down (git-fixes).
- fbdev: Fix logic error in &amp;quot;offb&amp;quot; name match (git-fixes).
- gpio: wcd934x: mark the GPIO controller as sleeping (git-fixes).
- crypto: essiv - Check ssize for decryption and in-place
  encryption (git-fixes).
- tpm_tis: Fix incorrect arguments in tpm_tis_probe_irq_single
  (git-fixes).
- commit a90f502

- scsi: libiscsi: Initialize iscsi_conn-&amp;gt;dd_data only if memory
  is allocated (CVE-2025-38700 bsc#1249182).
- scsi: bfa: Double-free fix (CVE-2025-38699 bsc#1249224).
- commit d981d82

- Update
  patches.suse/scsi-lpfc-Fix-buffer-free-clear-order-in-deferred-re.patch
  (bsc#1250519 CVE-2025-39841 bsc#1250274).
  added CVE number and associated bsc
- commit 11a7724

- KVM: x86: Snapshot the host's DEBUGCTL in common x86
  (git-fixes).
- commit 090e1cd

- KVM: SVM: Set RFLAGS.IF=1 in C code, to get VMRUN out of the
  STI shadow (git-fixes).
- Refresh
  patches.suse/x86-bugs-Add-a-Transient-Scheduler-Attacks-mitigation.patch.
- commit ab98159

- KVM: SEV: Validate XCR0 provided by guest in GHCB (git-fixes).
- commit 3926356

- KVM: SVM: Pass through GHCB MSR if and only if VM is an SEV-ES
  guest (git-fixes).
- commit 1163dde

- KVM: SEV: Read save fields from GHCB exactly once (git-fixes).
- commit 0fe255d

- KVM: SEV: Rename kvm_ghcb_get_sw_exit_code() to
  kvm_get_cached_sw_exit_code() (git-fixes).
- commit 16f8d6e

- net: usb: asix: hold PM usage ref to avoid PM/MDIO + RTNL
  deadlock (git-fixes).
- commit 4ae0d43

- fs: writeback: fix use-after-free in __mark_inode_dirty()
  (bsc#1250455 CVE-2025-39866).
- commit 5efc627

- kernfs: Fix UAF in polling when open file is released
  (bsc#1250379 CVE-2025-39881).
- commit 278aed0

- fs: Prevent file descriptor table allocations exceeding INT_MAX
  (bsc#1249512 CVE-2025-39756).
- commit eec00db

- ext4: avoid potential buffer over-read in
  parse_apply_sb_mount_options() (git-fixes).
- commit b98ec86

- ext4: fix checks for orphan inodes (bsc#1250119).
- commit 63ca2b0

- ext4: fix hole length calculation overflow in non-extent inodes
  (git-fixes).
- commit 61cf4bb

- ext4: don't try to clear the orphan_present feature block
  device is r/o (git-fixes).
- commit f4163bf

- ext4: fix reserved gdt blocks handling in fsmap (git-fixes).
- commit 97b5bdf

- ext4: fix fsmap end of range reporting with bigalloc
  (git-fixes).
- commit 91e12c8

- ext4: check fast symlink for ea_inode correctly (git-fixes).
- commit 42b6930

- ext4: preserve SB_I_VERSION on remount (git-fixes).
- commit 4260078

- ext4: fix largest free orders lists corruption on
  mb_optimize_scan switch (git-fixes).
- commit 17d92cc

- ext4: fix zombie groups in average fragment size lists
  (git-fixes).
- commit 321e541

- ext4: ensure i_size is smaller than maxbytes (git-fixes).
- commit 83487b1

- ext4: factor out ext4_get_maxbytes() (git-fixes).
- commit e58bd69

- netfilter: nft_objref: validate objref and objrefmap expressions
  (bsc#1250237).
  No CVE available yet, please see the bugzilla ticket referenced.
- commit 71d77ae

- ext4: fix calculation of credits for extent tree modification
  (git-fixes).
- commit 9ee5795

- ext4: reorder capability check last (git-fixes).
- commit ed8a5ff

- jbd2: do not try to recover wiped journal (git-fixes).
- commit 71d37b6

- ext4: do not convert the unwritten extents if data writeback
  fails (git-fixes).
- commit 9294482

- iomap: handle a post-direct I/O invalidate race in
  iomap_write_delalloc_release (git-fixes).
- commit 1023af1

- iomap: Fix iomap_adjust_read_range for plen calculation
  (git-fixes).
- commit dab9a8e

- fs: udf: fix OOB read in lengthAllocDescs handling (git-fixes).
- commit ab7fa65

- udf: Verify partition map count (git-fixes).
- commit acb53b7

- udf: Make sure i_lenExtents is uptodate on inode eviction
  (git-fixes).
- commit 1f76b28

- isofs: Verify inode mode when loading from disk (git-fixes).
- commit 96bc3c7

- mailbox: zynqmp-ipi: Fix out-of-bounds access in mailbox
  cleanup loop (git-fixes).
- mailbox: zynqmp-ipi: Remove dev.parent check in
  zynqmp_ipi_free_mboxes (git-fixes).
- mailbox: zynqmp-ipi: Remove redundant
  mbox_controller_unregister() call (git-fixes).
- Input: uinput - zero-initialize uinput_ff_upload_compat to
  avoid info leak (git-fixes).
- commit c2e0f2f

- arm64: mte: Do not flag the zero page as PG_mte_tagged (git-fixes)
- commit cf556af

- KVM: x86: Don't inject PV async #PF if SEND_ALWAYS=0 and guest
  state is protected (git-fixes).
- commit fa670d1

- misc: fastrpc: Skip reference for DMA handles (git-fixes).
- misc: fastrpc: fix possible map leak in fastrpc_put_args
  (git-fixes).
- misc: fastrpc: Fix fastrpc_map_lookup operation (git-fixes).
- staging: axis-fifo: flush RX FIFO on read errors (git-fixes).
- staging: axis-fifo: fix TX handling on copy_from_user() failure
  (git-fixes).
- staging: axis-fifo: fix maximum TX packet length check
  (git-fixes).
- clk: at91: peripheral: fix return value (git-fixes).
- clk: mediatek: clk-mux: Do not pass flags to
  clk_mux_determine_rate_flags() (git-fixes).
- clk: mediatek: mt8195-infra_ao: Fix parent for infra_ao_hdmi_26m
  (git-fixes).
- clk: tegra: do not overallocate memory for bpmp clocks
  (git-fixes).
- commit ecaf254

- smb: client: fix crypto buffers in non-linear memory
  (bsc#1250491, boo#1239206).
- commit b5fc334

- usb: xhci: Limit Stop Endpoint retries (git-fixes).
  kABI fixup for 474538b8dd1cd9c666e56cfe8ef60fbb0fb513f4
- commit 6d76064

- kABI workaround for struct atmdev_ops extension (CVE-2025-39828
  bsc#1250205).
- commit ece3f96

- Refresh
  patches.suse/Bluetooth-L2CAP-Fix-not-checking-l2cap_chan-security.patch.
- commit 85c9004

- Refresh
  patches.suse/Bluetooth-hci_core-Fix-calling-mgmt_device_connected.patch.
- commit 9720dbb

- nfsd: nfserr_jukebox in nlm_fopen should lead to a retry
  (git-fixes).
- commit c2be588

- NFSD: Fix destination buffer size in nfsd4_ssc_setup_dul()
  (git-fixes).
- commit 7b5a68a

- sunrpc: fix null pointer dereference on zero-length checksum
  (git-fixes).
- commit c4c654a

- atm: atmtcp: Prevent arbitrary write in atmtcp_recv_control()
  (CVE-2025-39828 bsc#1250205).
- commit a2ac627

- e1000e: fix heap overflow in e1000_set_eeprom (CVE-2025-39898
  bsc#1250742).
- vxlan: Fix NPD when refreshing an FDB entry with a nexthop
  object (CVE-2025-39851 bsc#1250296).
- commit df2ae2c

- ACPI: NFIT: Fix incorrect ndr_desc being reportedin dev_err
  message (git-fixes).
- watchdog: mpc8xxx_wdt: Reload the watchdog timer when enabling
  the watchdog (git-fixes).
- PCI: tegra: Convert struct tegra_msi mask_lock into raw spinlock
  (git-fixes).
- PCI: tegra194: Fix duplicate PLL disable in
  pex_ep_event_pex_rst_assert() (git-fixes).
- PCI: tegra: Fix devm_kcalloc() argument order for port-&amp;gt;phys
  allocation (git-fixes).
- PCI: rcar-host: Drop PMSR spinlock (git-fixes).
- PCI: keystone: Use devm_request_irq() to free
  &amp;quot;ks-pcie-error-irq&amp;quot; on exit (git-fixes).
- PCI: tegra194: Handle errors in BPMP response (git-fixes).
- PCI: tegra194: Fix broken tegra_pcie_ep_raise_msi_irq()
  (git-fixes).
- PCI/IOV: Add PCI rescan-remove locking when enabling/disabling
  SR-IOV (git-fixes).
- PCI/sysfs: Ensure devices are powered for config reads
  (git-fixes).
- PCI/AER: Fix missing uevent on recovery when a reset is
  requested (git-fixes).
- PCI/ERR: Fix uevent on failure to recover (git-fixes).
- dmaengine: Fix dma_async_tx_descriptor-&amp;gt;tx_submit documentation
  (git-fixes).
- phy: rockchip: naneng-combphy: Enable U3 OTG port for RK3568
  (git-fixes).
- media: rc: fix races with imon_disconnect() (git-fixes).
- commit 1710395

- arm64: dts: apple: Add ethernet0 alias for J375 template (git-fixes)
- commit 122f705

- arm64: dts: apple: t8103-j457: Fix PCIe ethernet iommu-map (git-fixes)
- commit 886bc20

- arm64: dts: imx8mp: Correct thermal sensor index (git-fixes)
- commit 2283cd3

- wifi: ath12k: Add MODULE_FIRMWARE() entries (bsc#1250952).
- commit fbc86d9

- scsi: qla2xxx: Fix incorrect sign of error code in
  qla_nvme_xmt_ls_rsp() (git-fixes).
- scsi: qla2xxx: Fix incorrect sign of error code in
  START_SP_W_RETRIES() (git-fixes).
- scsi: qla2xxx: edif: Fix incorrect sign of error code
  (git-fixes).
- scsi: qla2xxx: Use secs_to_jiffies() instead of
  msecs_to_jiffies() (git-fixes).
- scsi: qla2xxx: Remove firmware URL (git-fixes).
- scsi: qla2xxx: Avoid stack frame size warning in qla_dfs
  (git-fixes).
- commit db6525b

- scsi: lpfc: Copyright updates for 14.4.0.11 patches
  (bsc#1250519).
- scsi: lpfc: Update lpfc version to 14.4.0.11 (bsc#1250519).
- scsi: lpfc: Ensure PLOGI_ACC is sent prior to PRLI in Point
  to Point topology (bsc#1250519).
- scsi: lpfc: Check return status of lpfc_reset_flush_io_context
  during TGT_RESET (bsc#1250519).
- scsi: lpfc: Decrement ndlp kref after FDISC retries exhausted
  (bsc#1250519).
- scsi: lpfc: Remove ndlp kref decrement clause for F_Port_Ctrl
  in lpfc_cleanup (bsc#1250519).
- scsi: lpfc: Clean up allocated queues when queue setup mbox
  commands fail (bsc#1250519).
- scsi: lpfc: Abort outstanding ELS WQEs regardless of if rmmod
  is in progress (bsc#1250519).
- scsi: lpfc: Remove unused member variables in struct lpfc_hba
  and lpfc_vport (bsc#1250519).
- scsi: lpfc: Use int type to store negative error codes
  (bsc#1250519).
- scsi: fc: Avoid -Wflex-array-member-not-at-end warnings
  (bsc#1250519).
- scsi: lpfc: use min() to improve code (bsc#1250519).
- scsi: lpfc: Fix buffer free/clear order in deferred receive path
  (bsc#1250519).
- scsi: lpfc: Remove redundant assignment to avoid memory leak
  (bsc#1250519).
- scsi: lpfc: Fix wrong function reference in a comment
  (bsc#1250519).
- commit 9af1a7a

- nvme-fc: use lock accessing port_state and rport state
  (bsc#1245193 bsc#1247500).
- nvmet-fcloop: call done callback even when remote port is gone
  (bsc#1245193 bsc#1247500).
- nvmet-fc: avoid scheduling association deletion twice
  (bsc#1245193 bsc#1247500).
- nvmet-fc: move lsop put work to nvmet_fc_ls_req_op (bsc#1245193
  bsc#1247500).
- commit 9a1d529

- NFSv4.1: fix backchannel max_resp_sz verification check
  (git-fixes).
- commit 8db6e65

- orangefs: Remove unused type in macro fill_default_sys_attrs
  (git-fixes).
- commit 98fbe5c

- ppp: fix memory leak in pad_compress_skb (CVE-2025-39847
  bsc#1250292).
- ice: fix NULL access of tx-&amp;gt;in_use in ice_ll_ts_intr
  (CVE-2025-39854 bsc#1250297).
- vxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop
  objects (CVE-2025-39850 bsc#1250276).
- net/mlx5: Fix lockdep assertion on sync reset unload event
  (CVE-2025-39832 bsc#1249901).
- net/mlx5: Reload auxiliary drivers on fw_activate
  (CVE-2025-39832 bsc#1249901).
- bnxt_en: Fix memory corruption when FW resources change during
  ifdown (CVE-2025-39810 bsc#1249975).
- gve: prevent ethtool ops after shutdown (CVE-2025-38735
  bsc#1249288).
- net/mlx5: Add sync reset drop mode support (CVE-2025-39832
  bsc#1249901).
- commit 703f4a7

- Update
  patches.suse/0780-drm-mediatek-dp-Change-logging-to-dev-for-mtk_dp_aux.patch
  (jsc#PED-3527 jsc#PED-5475 jsc#PED-6068 jsc#PED-6070
  jsc#PED-6116 jsc#PED-6120 jsc#PED-5065 jsc#PED-5477 jsc#PED-5511
  jsc#PED-6041 jsc#PED-6069 jsc#PED-6071 CVE-2023-53325
  bsc#1250035).
- Update
  patches.suse/ACPI-APEI-send-SIGBUS-to-current-task-if-synchronous.patch
  (stable-fixes CVE-2025-39763 bsc#1249615).
- Update
  patches.suse/ACPI-pfr_update-Fix-the-driver-update-version-check.patch
  (git-fixes CVE-2025-39701 bsc#1249308).
- Update
  patches.suse/ACPICA-Add-AML_NO_OPERAND_RESOLVE-flag-to-Timer.patch
  (git-fixes CVE-2023-53395 bsc#1250358).
- Update
  patches.suse/ALSA-hda-ca0132-Fix-buffer-overflow-in-add_tuning_co.patch
  (stable-fixes CVE-2025-39751 bsc#1249538).
- Update
  patches.suse/ALSA-hda-fix-a-possible-null-pointer-dereferen.patch
  (bsc#1012628 CVE-2023-53275 bsc#1250459).
- Update
  patches.suse/ALSA-usb-audio-Validate-UAC3-cluster-segment-descrip.patch
  (git-fixes CVE-2025-39757 bsc#1249515).
- Update
  patches.suse/ALSA-usb-audio-Validate-UAC3-power-domain-descriptor.patch
  (git-fixes CVE-2025-38729 bsc#1249164).
- Update
  patches.suse/ASoC-core-Check-for-rtd-NULL-in-snd_soc_remove_pcm_r.patch
  (stable-fixes CVE-2025-38706 bsc#1249195).
- Update patches.suse/Bluetooth-Fix-hci_suspend_sync-crash.patch
  (git-fixes CVE-2023-53520 bsc#1250957).
- Update
  patches.suse/Bluetooth-Fix-potential-use-after-free-when-clear-ke.patch
  (git-fixes CVE-2023-53386 bsc#1250106).
- Update
  patches.suse/Bluetooth-Fix-use-after-free-in-l2cap_sock_cleanup_l.patch
  (git-fixes CVE-2025-39860 bsc#1250247).
- Update patches.suse/Bluetooth-L2CAP-Fix-use-after-free.patch
  (bsc#1012628 CVE-2023-53305 bsc#1250049).
- Update
  patches.suse/Bluetooth-hci_conn-fail-SCO-ISO-via-hci_conn_failed-.patch
  (git-fixes CVE-2023-53374 bsc#1250196).
- Update
  patches.suse/Bluetooth-l2cap-Check-encryption-key-size-on-incomin.patch
  (git-fixes CVE-2025-39889 bsc#1249833).
- Update
  patches.suse/Bluetooth-use-RCU-for-hci_conn_params-and-itera.patch
  (bsc#1012628 CVE-2023-53252 bsc#1249756).
- Update
  patches.suse/Bluetooth-vhci-Prevent-use-after-free-by-removing-de.patch
  (git-fixes CVE-2025-39861 bsc#1250249).
- Update
  patches.suse/FS-JFS-Fix-null-ptr-deref-Read-in-txBegin.patch
  (bsc#1012628 CVE-2023-53457 bsc#1250763).
- Update
  patches.suse/HID-asus-fix-UAF-via-HID_CLAIMED_INPUT-validation.patch
  (git-fixes CVE-2025-39824 bsc#1250007).
- Update
  patches.suse/HID-hid-ntrig-fix-unable-to-handle-page-fault-in-ntr.patch
  (stable-fixes CVE-2025-39808 bsc#1250088).
- Update
  patches.suse/HID-multitouch-Correct-devm-device-reference-for-hid.patch
  (git-fixes CVE-2023-53454 bsc#1250759).
- Update
  patches.suse/HID-multitouch-fix-slab-out-of-bounds-access-in-mt_r.patch
  (git-fixes CVE-2025-39806 bsc#1249888).
- Update
  patches.suse/IB-hfi1-Fix-possible-panic-during-hotplug-remo.patch
  (bsc#1012628 CVE-2023-53488 bsc#1250825).
- Update
  patches.suse/KVM-arm64-Handle-kvm_arm_init-failure-correctly.patch
  (bsc#1012628 CVE-2023-53319 bsc#1250067).
- Update
  patches.suse/KVM-nSVM-Load-L1-s-TSC-multiplier-based-on-L1-state-.patch
  (git-fixes CVE-2023-53208 bsc#1249698).
- Update
  patches.suse/KVM-s390-diag-fix-racy-access-of-physical-cpu-n.patch
  (bsc#1012628 CVE-2023-53205 bsc#1249677).
- Update
  patches.suse/NFS-Fix-filehandle-bounds-checking-in-nfs_fh_to_dentry.patch
  (git-fixes CVE-2025-39730 bsc#1249296).
- Update
  patches.suse/NFS-Fix-the-setting-of-capabilities-when-automounting-a-new-filesystem.patch
  (git-fixes CVE-2025-39798 bsc#1249774).
- Update
  patches.suse/NFSv4.2-Rework-scratch-handling-for-READ_PLUS-again.patch
  (git-fixes CVE-2023-53360 bsc#1249990).
- Update
  patches.suse/PCI-ASPM-Disable-ASPM-on-MFD-function-removal-t.patch
  (bsc#1012628 CVE-2023-53446 bsc#1250145).
- Update
  patches.suse/PCI-endpoint-Fix-configfs-group-list-head-handling.patch
  (git-fixes CVE-2025-39783 bsc#1249486).
- Update
  patches.suse/PCI-hv-Fix-a-crash-in-hv_pci_restore_msi_msg-during-.patch
  (git-fixes CVE-2023-53175 bsc#1249845).
- Update
  patches.suse/PM-devfreq-Fix-leak-in-devfreq_dev_release.patch
  (git-fixes CVE-2023-53518 bsc#1250923).
- Update
  patches.suse/RDMA-bnxt_re-Properly-order-ib_device_unalloc-.patch
  (bsc#1012628 CVE-2023-53504 bsc#1250813).
- Update
  patches.suse/RDMA-bnxt_re-wraparound-mbox-producer-index.patch
  (bsc#1012628 CVE-2023-53201 bsc#1249687).
- Update
  patches.suse/RDMA-hfi1-fix-possible-divide-by-zero-in-find_hw_thr.patch
  (git-fixes CVE-2025-39742 bsc#1249479).
- Update
  patches.suse/RDMA-mlx5-Return-the-firmware-result-upon-dest.patch
  (bsc#1012628 CVE-2023-53286 bsc#1250325).
- Update
  patches.suse/RDMA-rxe-Fix-unsafe-drain-work-queue-code.patch
  (git-fixes CVE-2023-53528 bsc#1250930).
- Update
  patches.suse/RDMA-siw-Fix-the-sendmsg-byte-count-in-siw_tcp_sendp.patch
  (git-fixes CVE-2025-39758 bsc#1249490).
- Update
  patches.suse/accel-habanalabs-fix-mem-leak-in-capture-user-.patch
  (bsc#1012628 CVE-2023-53367 bsc#1250243).
- Update patches.suse/accel-qaic-Fix-slicing-memory-leak.patch
  (bsc#1012628 CVE-2023-53350 bsc#1250012).
- Update
  patches.suse/accel-qaic-tighten-bounds-checking-in-decode_me.patch
  (bsc#1012628 CVE-2023-53493 bsc#1250820).
- Update
  patches.suse/af_unix-Fix-data-races-around-user-unix_inflight.patch
  (git-fixes CVE-2023-53204 bsc#1249682).
- Update
  patches.suse/arm64-sme-Set-new-vector-length-before-realloca.patch
  (bsc#1012628 CVE-2023-53184 bsc#1249823).
- Update
  patches.suse/ax25-properly-unshare-skbs-in-ax25_kiss_rcv.patch
  (git-fixes CVE-2025-39848 bsc#1250298).
- Update
  patches.suse/batman-adv-fix-OOB-read-write-in-network-coding-deco.patch
  (git-fixes CVE-2025-39839 bsc#1250291).
- Update
  patches.suse/blk-cgroup-Reinit-blkg_iostat_set-after-clearin.patch
  (bsc#1012628 CVE-2023-53421 bsc#1250171).
- Update
  patches.suse/blk-mq-fix-NULL-dereference-on-q-elevator-in-bl.patch
  (bsc#1012628 CVE-2023-53292 bsc#1250163).
- Update
  patches.suse/bpf-Fix-memleak-due-to-fentry-attach-failure.patch
  (bsc#1012628 CVE-2023-53221 bsc#1249662).
- Update
  patches.suse/bpf-cpumap-Fix-memory-leak-in-cpu_map_update_el.patch
  (bsc#1012628 CVE-2023-53441 bsc#1250150).
- Update
  patches.suse/btrfs-abort-transaction-on-unexpected-eb-generation-.patch
  (git-fixes CVE-2025-39800 bsc#1250177).
- Update
  patches.suse/btrfs-add-handling-for-RAID1C23-DUP-to-btrfs_re.patch
  (bsc#1012628 CVE-2023-53243 bsc#1249640).
- Update
  patches.suse/btrfs-don-t-check-PageError-in-__extent_writepa.patch
  (bsc#1012628 CVE-2023-53429 bsc#1250384).
- Update
  patches.suse/btrfs-exit-gracefully-if-reloc-roots-don-t-mat.patch
  (bsc#1012628 CVE-2023-53183 bsc#1249863).
- Update
  patches.suse/btrfs-fix-BUG_ON-condition-in-btrfs_cancel_bal.patch
  (bsc#1012628 CVE-2023-53339 bsc#1250329).
- Update
  patches.suse/btrfs-fix-use-after-free-of-new-block-group-th.patch
  (bsc#1012628 CVE-2023-53187 bsc#1249815).
- Update
  patches.suse/btrfs-qgroup-fix-race-between-quota-disable-and-quot.patch
  (git-fixes CVE-2025-39759 bsc#1249522).
- Update
  patches.suse/btrfs-set_page_extent_mapped-after-read_folio-i.patch
  (bsc#1012628 CVE-2023-53247 bsc#1249870).
- Update
  patches.suse/bus-fsl-mc-don-t-assume-child-devices-are-all-f.patch
  (bsc#1012628 CVE-2023-53362 bsc#1249993).
- Update
  patches.suse/bus-mhi-host-Detect-events-pointing-to-unexpected-TR.patch
  (git-fixes CVE-2025-39790 bsc#1249548).
- Update
  patches.suse/can-gs_usb-fix-time-stamp-counter-initializatio.patch
  (bsc#1012628 CVE-2023-53523 bsc#1250926).
- Update
  patches.suse/can-j1939-implement-NETDEV_UNREGISTER-notification-h.patch
  (git-fixes CVE-2025-39925 bsc#1250736).
- Update
  patches.suse/can-xilinx_can-xcan_write_frame-fix-use-after-free-o.patch
  (git-fixes CVE-2025-39873 bsc#1250371).
- Update
  patches.suse/cifs-prevent-use-after-free-by-freeing-the-cfil.patch
  (bsc#1012628 CVE-2023-53377 bsc#1250161).
- Update
  patches.suse/clk-imx-clk-imx8mn-fix-memory-leak-in-imx8mn_cl.patch
  (bsc#1012628 CVE-2023-53249 bsc#1249642).
- Update
  patches.suse/clk-imx-clk-imxrt1050-fix-memory-leak-in-imxrt1.patch
  (bsc#1012628 CVE-2023-53264 bsc#1249795).
- Update patches.suse/clk-mediatek-fix-of_iomap-memory-leak.patch
  (bsc#1012628 CVE-2023-53424 bsc#1250169).
- Update
  patches.suse/clk-mediatek-mt8183-Add-back-SSPM-related-cloc.patch
  (bsc#1012628 CVE-2023-53274 bsc#1249919).
- Update
  patches.suse/clk-tegra-tegra124-emc-Fix-potential-memory-lea.patch
  (bsc#1012628 CVE-2023-53505 bsc#1250807).
- Update
  patches.suse/comedi-Fix-use-of-uninitialized-memory-in-do_insn_io.patch
  (git-fixes CVE-2025-39684 bsc#1249281).
- Update
  patches.suse/comedi-Make-insn_rw_emulate_bits-do-insn-n-samples.patch
  (git-fixes CVE-2025-39686 bsc#1249312).
- Update
  patches.suse/comedi-fix-race-between-polling-and-detaching.patch
  (git-fixes CVE-2025-38687 bsc#1249177).
- Update
  patches.suse/comedi-pcl726-Prevent-invalid-irq-number.patch
  (git-fixes CVE-2025-39685 bsc#1249282).
- Update
  patches.suse/crypto-qat-flush-misc-workqueue-during-device-shutdo.patch
  (git-fixes CVE-2025-39721 bsc#1249323).
- Update
  patches.suse/cxl-acpi-Fix-a-use-after-free-in-cxl_parse_cfmw.patch
  (bsc#1012628 CVE-2023-53479 bsc#1250837).
- Update
  patches.suse/cxl-downgrade-a-warning-message-to-debug-level-in-cxl.patch
  (bsc#1229165 CVE-2023-53479 bsc#1250837).
- Update
  patches.suse/dma-buf-dma-resv-Stop-leaking-on-krealloc-failu.patch
  (jsc#PED-3527 jsc#PED-5475 jsc#PED-6068 jsc#PED-6070
  jsc#PED-6116 jsc#PED-6120 jsc#PED-5065 jsc#PED-5477 jsc#PED-5511
  jsc#PED-6041 jsc#PED-6069 jsc#PED-6071 CVE-2023-53181
  bsc#1249824).
- Update
  patches.suse/dmaengine-idxd-Fix-double-free-in-idxd_setup_wqs.patch
  (git-fixes CVE-2025-39870 bsc#1250402).
- Update
  patches.suse/dmaengine-idxd-Remove-improper-idxd_free.patch
  (git-fixes CVE-2025-39871 bsc#1250377).
- Update
  patches.suse/dmaengine-qcom-bam_dma-Fix-DT-error-handling-for-num.patch
  (git-fixes CVE-2025-39923 bsc#1250741).
- Update
  patches.suse/dmaengine-ti-edma-Fix-memory-allocation-size-for-que.patch
  (git-fixes CVE-2025-39869 bsc#1250406).
- Update
  patches.suse/drm-amd-display-Add-null-pointer-check-in-mod_hdcp_h.patch
  (git-fixes CVE-2025-39675 bsc#1249263).
- Update
  patches.suse/drm-amd-display-Avoid-a-NULL-pointer-dereference.patch
  (stable-fixes CVE-2025-39693 bsc#1249279).
- Update
  patches.suse/drm-amd-display-Fix-possible-underflow-for-disp.patch
  (jsc#PED-3527 jsc#PED-5475 jsc#PED-6068 jsc#PED-6070
  jsc#PED-6116 jsc#PED-6120 jsc#PED-5065 jsc#PED-5477 jsc#PED-5511
  jsc#PED-6041 jsc#PED-6069 jsc#PED-6071 CVE-2023-53258
  bsc#1249780).
- Update
  patches.suse/drm-amdgpu-fix-calltrace-warning-in-amddrm_bud.patch
  (jsc#PED-3527 jsc#PED-5475 jsc#PED-6068 jsc#PED-6070
  jsc#PED-6116 jsc#PED-6120 jsc#PED-5065 jsc#PED-5477 jsc#PED-5511
  jsc#PED-6041 jsc#PED-6069 jsc#PED-6071 CVE-2023-53152
  bsc#1249883).
- Update
  patches.suse/drm-amdgpu-fix-memory-leak-in-mes-self-test.patch
  (jsc#PED-3527 jsc#PED-5475 jsc#PED-6068 jsc#PED-6070
  jsc#PED-6116 jsc#PED-6120 jsc#PED-5065 jsc#PED-5477 jsc#PED-5511
  jsc#PED-6041 jsc#PED-6069 jsc#PED-6071 CVE-2023-53370
  bsc#1250208).
- Update
  patches.suse/drm-amdgpu-install-stub-fence-into-potential-u.patch
  (jsc#PED-3527 jsc#PED-5475 jsc#PED-6068 jsc#PED-6070
  jsc#PED-6116 jsc#PED-6120 jsc#PED-5065 jsc#PED-5477 jsc#PED-5511
  jsc#PED-6041 jsc#PED-6069 jsc#PED-6071 CVE-2023-53248
  bsc#1249779).
- Update
  patches.suse/drm-amdkfd-Destroy-KFD-debugfs-after-destroy-KFD-wq.patch
  (stable-fixes CVE-2025-39706 bsc#1249413).
- Update
  patches.suse/drm-client-Fix-memory-leak-in-drm_client_modese.patch
  (jsc#PED-3527 jsc#PED-5475 jsc#PED-6068 jsc#PED-6070
  jsc#PED-6116 jsc#PED-6120 jsc#PED-5065 jsc#PED-5477 jsc#PED-5511
  jsc#PED-6041 jsc#PED-6069 jsc#PED-6071 CVE-2023-53288
  bsc#1250058).
- Update
  patches.suse/drm-hisilicon-hibmc-fix-the-hibmc-loaded-failed-bug.patch
  (git-fixes CVE-2025-39772 bsc#1249506).
- Update
  patches.suse/drm-mediatek-fix-potential-OF-node-use-after-free.patch
  (git-fixes CVE-2025-39882 bsc#1250389).
- Update
  patches.suse/drm-msm-dp-Free-resources-after-unregistering-t.patch
  (jsc#PED-3527 jsc#PED-5475 jsc#PED-6068 jsc#PED-6070
  jsc#PED-6116 jsc#PED-6120 jsc#PED-5065 jsc#PED-5477 jsc#PED-5511
  jsc#PED-6041 jsc#PED-6069 jsc#PED-6071 CVE-2023-53316
  bsc#1250066).
- Update
  patches.suse/drm-msm-mdp5-Don-t-leak-some-plane-state.patch
  (jsc#PED-3527 jsc#PED-5475 jsc#PED-6068 jsc#PED-6070
  jsc#PED-6116 jsc#PED-6120 jsc#PED-5065 jsc#PED-5477 jsc#PED-5511
  jsc#PED-6041 jsc#PED-6069 jsc#PED-6071 CVE-2023-53324
  bsc#1250070).
- Update
  patches.suse/drm-nouveau-disp-fix-use-after-free-in-error-h.patch
  (bsc#1012628 bsc#1214073 CVE-2023-53263 bsc#1249861).
- Update
  patches.suse/drm-nouveau-nvif-Fix-potential-memory-leak-in-nvif_v.patch
  (git-fixes CVE-2025-39679 bsc#1249338).
- Update
  patches.suse/drm-radeon-Fix-integer-overflow-in-radeon_cs_pa.patch
  (jsc#PED-3527 jsc#PED-5475 jsc#PED-6068 jsc#PED-6070
  jsc#PED-6116 jsc#PED-6120 jsc#PED-5065 jsc#PED-5477 jsc#PED-5511
  jsc#PED-6041 jsc#PED-6069 jsc#PED-6071 CVE-2023-53309
  bsc#1250055).
- Update patches.suse/drm-tests-helpers-Avoid-a-driver-uaf.patch
  (jsc#PED-3527 jsc#PED-5475 jsc#PED-6068 jsc#PED-6070
  jsc#PED-6116 jsc#PED-6120 jsc#PED-5065 jsc#PED-5477 jsc#PED-5511
  jsc#PED-6041 jsc#PED-6069 jsc#PED-6071 CVE-2023-53235
  bsc#1249785).
- Update
  patches.suse/drm-ttm-check-null-pointer-before-accessing-wh.patch
  (jsc#PED-3527 jsc#PED-5475 jsc#PED-6068 jsc#PED-6070
  jsc#PED-6116 jsc#PED-6120 jsc#PED-5065 jsc#PED-5477 jsc#PED-5511
  jsc#PED-6041 jsc#PED-6069 jsc#PED-6071 CVE-2023-53352
  bsc#1250006).
- Update
  patches.suse/drm-ttm-fix-bulk_move-corruption-when-adding-a-.patch
  (jsc#PED-3527 jsc#PED-5475 jsc#PED-6068 jsc#PED-6070
  jsc#PED-6116 jsc#PED-6120 jsc#PED-5065 jsc#PED-5477 jsc#PED-5511
  jsc#PED-6041 jsc#PED-6069 jsc#PED-6071 CVE-2023-53444
  bsc#1250157).
- Update patches.suse/erofs-Fix-detection-of-atomic-context.patch
  (bsc#1012628 CVE-2023-53231 bsc#1249787).
- Update
  patches.suse/exfat-add-cluster-chain-loop-check-for-dir.patch
  (git-fixes CVE-2025-38692 bsc#1249221).
- Update
  patches.suse/ext2-dax-Fix-ext2_setsize-when-len-is-page-alig.patch
  (bsc#1012628 CVE-2023-53323 bsc#1250069).
- Update
  patches.suse/f2fs-don-t-reset-unchangable-mount-option-in-f2.patch
  (bsc#1012628 CVE-2023-53447 bsc#1250241).
- Update
  patches.suse/fbdev-Fix-vmalloc-out-of-bounds-write-in-fast_imageb.patch
  (stable-fixes CVE-2025-38685 bsc#1249220).
- Update
  patches.suse/fbdev-ep93xx-fb-Do-not-assign-to-struct-fb_info.dev.patch
  (jsc#PED-3527 jsc#PED-5475 jsc#PED-6068 jsc#PED-6070
  jsc#PED-6116 jsc#PED-6120 jsc#PED-5065 jsc#PED-5477 jsc#PED-5511
  jsc#PED-6041 jsc#PED-6069 jsc#PED-6071 CVE-2023-53314
  bsc#1250065).
- Update
  patches.suse/fbdev-fix-potential-buffer-overflow-in-do_register_f.patch
  (stable-fixes CVE-2025-38702 bsc#1249254).
- Update
  patches.suse/fbdev-imxfb-Removed-unneeded-release_mem_region.patch
  (jsc#PED-3527 jsc#PED-5475 jsc#PED-6068 jsc#PED-6070
  jsc#PED-6116 jsc#PED-6120 jsc#PED-5065 jsc#PED-5477 jsc#PED-5511
  jsc#PED-6041 jsc#PED-6069 jsc#PED-6071 CVE-2023-53448
  bsc#1250873).
- Update
  patches.suse/firewire-net-fix-use-after-free-in-fwnet_finis.patch
  (bsc#1012628 CVE-2023-53432 bsc#1250426).
- Update
  patches.suse/firmware-stratix10-svc-Fix-a-potential-resource.patch
  (bsc#1012628 CVE-2023-53255 bsc#1249762).
- Update
  patches.suse/fs-jfs-Fix-UBSAN-array-index-out-of-bounds-in-d.patch
  (bsc#1012628 CVE-2023-53485 bsc#1250872).
- Update
  patches.suse/fs-ntfs3-Enhance-sanity-check-while-generating.patch
  (bsc#1012628 CVE-2023-53328 bsc#1249952).
- Update
  patches.suse/hfs-fix-slab-out-of-bounds-in-hfs_bnode_read.patch
  (git-fixes CVE-2025-38715 bsc#1249196).
- Update
  patches.suse/hfsplus-don-t-use-BUG_ON-in-hfsplus_create_attributes_file.patch
  (git-fixes CVE-2025-38712 bsc#1249194).
- Update
  patches.suse/hfsplus-fix-slab-out-of-bounds-in-hfsplus_bnode_read.patch
  (git-fixes CVE-2025-38714 bsc#1249260).
- Update
  patches.suse/hfsplus-fix-slab-out-of-bounds-read-in-hfsplus_uni2asc.patch
  (git-fixes CVE-2025-38713 bsc#1249200).
- Update
  patches.suse/hsr-Fix-uninit-value-access-in-fill_frame_info.patch
  (bsc#1220419 CVE-2023-53462 bsc#1250878).
- Update
  patches.suse/hwmon-pmbus_core-Fix-NULL-pointer-dereference.patch
  (bsc#1012628 CVE-2023-53206 bsc#1249679).
- Update
  patches.suse/ibmvnic-Do-not-reset-dql-stats-on-NON_FATAL-err.patch
  (bsc#1012628 CVE-2023-53463 bsc#1250867).
- Update
  patches.suse/ice-Block-switchdev-mode-when-ADQ-is-active-an.patch
  (bsc#1012628 CVE-2023-53442 bsc#1250201).
- Update
  patches.suse/icmp6-Fix-null-ptr-deref-of-ip6_null_entry-rt6i.patch
  (bsc#1012628 CVE-2023-53343 bsc#1250022).
- Update
  patches.suse/igb-Fix-igb_down-hung-on-surprise-removal.patch
  (bsc#1012628 CVE-2023-53148 bsc#1249842).
- Update
  patches.suse/iio-imu-bno055-fix-OOB-access-of-hw_xlate-array.patch
  (git-fixes CVE-2025-39719 bsc#1249271).
- Update
  patches.suse/io_uring-wait-interruptibly-for-request-complet.patch
  (bsc#1012628 CVE-2023-53461 bsc#1250941).
- Update
  patches.suse/iommu-amd-iommu_v2-Fix-pasid_state-refcount-dec-hit-.patch
  (git-fixes CVE-2023-53501 bsc#1250815).
- Update
  patches.suse/iommu-arm-smmu-qcom-Add-SM6115-MDSS-compatible.patch
  (git-fixes CVE-2025-39739 bsc#1249542).
- Update
  patches.suse/ip6mr-Fix-skb_under_panic-in-ip6mr_cache_repor.patch
  (bsc#1012628 CVE-2023-53365 bsc#1249988).
- Update
  patches.suse/ipv6-addrconf-fix-a-potential-refcount-underflo.patch
  (bsc#1012628 CVE-2023-53189 bsc#1249894).
- Update
  patches.suse/jbd2-check-jh-b_transaction-before-removing-it-from-.patch
  (bsc#1214953 CVE-2023-53526 bsc#1250928).
- Update patches.suse/jfs-Regular-file-corruption-check.patch
  (git-fixes CVE-2025-38698 bsc#1249255).
- Update
  patches.suse/jfs-jfs_dmap-Validate-db_l2nbperpage-while-moun.patch
  (bsc#1012628 CVE-2023-53222 bsc#1249864).
- Update
  patches.suse/jfs-truncate-good-inode-pages-when-hard-link-is-0.patch
  (git-fixes CVE-2025-39743 bsc#1249489).
- Update
  patches.suse/jfs-upper-bound-check-of-tree-index-in-dbAllocAG.patch
  (git-fixes CVE-2025-38697 bsc#1249257).
- Update
  patches.suse/kobject-Add-sanity-check-for-kset-kobj.ktype-in-kset.patch
  (git-fixes CVE-2023-53480 bsc#1250861).
- Update patches.suse/lwt-Fix-return-values-of-BPF-xmit-ops.patch
  (jsc#PED-6811 CVE-2023-53338 bsc#1250074).
- Update
  patches.suse/mISDN-hfcpci-Fix-warning-when-deleting-uninitialized.patch
  (git-fixes CVE-2025-39833 bsc#1250028).
- Update
  patches.suse/macvlan-add-forgotten-nla_policy-for-IFLA_MACVL.patch
  (bsc#1012628 CVE-2023-53516 bsc#1250918).
- Update
  patches.suse/md-raid10-check-slab-out-of-bounds-in-md_bitmap.patch
  (bsc#1012628 CVE-2023-53357 bsc#1249994).
- Update
  patches.suse/md-raid10-fix-null-ptr-deref-of-mreplace-in-rai.patch
  (bsc#1012628 CVE-2023-53380 bsc#1250198).
- Update
  patches.suse/md-raid10-fix-wrong-setting-of-max_corr_read_er.patch
  (bsc#1012628 CVE-2023-53313 bsc#1249911).
- Update
  patches.suse/md-raid10-prevent-soft-lockup-while-flush-write.patch
  (bsc#1012628 CVE-2023-53151 bsc#1249865).
- Update
  patches.suse/md-raid5-cache-fix-null-ptr-deref-for-r5l_flush_stri-0d0b.patch
  (jsc#PED-7542 CVE-2023-53210 bsc#1249673).
- Update
  patches.suse/media-az6007-Fix-null-ptr-deref-in-az6007_i2c_xfer.patch
  (git-fixes CVE-2023-53220 bsc#1250337).
- Update
  patches.suse/media-dvb-frontends-dib7090p-fix-null-ptr-deref-in-d.patch
  (stable-fixes CVE-2025-38694 bsc#1249272).
- Update
  patches.suse/media-dvb-frontends-w7090p-fix-null-ptr-deref-in-w70.patch
  (stable-fixes CVE-2025-38693 bsc#1249190).
- Update
  patches.suse/media-hi846-fix-usage-of-pm_runtime_get_if_in_u.patch
  (bsc#1012628 CVE-2023-53177 bsc#1249849).
- Update
  patches.suse/media-ipu-bridge-Fix-null-pointer-deref-on-SSDB-PLD-.patch
  (git-fixes CVE-2023-53336 bsc#1250073).
- Update
  patches.suse/media-mdp3-Fix-resource-leaks-in-of_find_device_by_n.patch
  (git-fixes CVE-2023-53385 bsc#1250319).
- Update
  patches.suse/media-platform-mediatek-vpu-fix-NULL-ptr-deref.patch
  (bsc#1012628 CVE-2023-53425 bsc#1250290).
- Update
  patches.suse/media-rainshadow-cec-fix-TOCTOU-race-condition-in-ra.patch
  (git-fixes CVE-2025-39713 bsc#1249321).
- Update
  patches.suse/media-usbtv-Lock-resolution-while-streaming.patch
  (git-fixes CVE-2025-39714 bsc#1249273).
- Update
  patches.suse/media-uvcvideo-Fix-1-byte-out-of-bounds-read-in-uvc_.patch
  (git-fixes CVE-2025-38680 bsc#1249203).
- Update
  patches.suse/media-v4l2-mem2mem-add-lock-to-protect-paramet.patch
  (bsc#1012628 CVE-2023-53519 bsc#1250964).
- Update
  patches.suse/media-venus-Add-a-check-for-packet-size-after-readin.patch
  (git-fixes CVE-2025-39710 bsc#1249304).
- Update
  patches.suse/media-venus-protect-against-spurious-interrupts-duri.patch
  (git-fixes CVE-2025-39709 bsc#1249278).
- Update
  patches.suse/mlxsw-minimal-fix-potential-memory-leak-in-mlxs.patch
  (bsc#1012628 CVE-2023-53195 bsc#1249761).
- Update
  patches.suse/mm-kmem-fix-a-NULL-pointer-dereference-in-obj_.patch
  (bsc#1012628 CVE-2023-53401 bsc#1250120).
- Update
  patches.suse/mm-move-page-table-sync-declarations-to-linux-pgtabl.patch
  (git-fixes CVE-2025-39844 bsc#1250268).
- Update
  patches.suse/mm-ptdump-take-the-memory-hotplug-lock-inside-ptdump_walk_.patch
  (git-fixes CVE-2025-38681 bsc#1249204).
- Update
  patches.suse/modpost-fix-off-by-one-in-is_executable_section.patch
  (bsc#1012628 CVE-2023-53397 bsc#1250125).
- Update patches.suse/mptcp-fix-disconnect-vs-accept-race.patch
  (bsc#1012628 CVE-2023-53490 bsc#1250827).
- Update
  patches.suse/msft-hv-3329-hv_netvsc-Fix-panic-during-namespace-deletion-with-V.patch
  (bsc#1248111 CVE-2025-38683 bsc#1249159).
- Update
  patches.suse/mtd-rawnand-stm32_fmc2-avoid-overlapping-mappings-on.patch
  (git-fixes CVE-2025-39907 bsc#1250713).
- Update
  patches.suse/net-dcb-choose-correct-policy-to-parse-DCB_ATT.patch
  (bsc#1012628 CVE-2023-53369 bsc#1250206).
- Update
  patches.suse/net-dsa-Removed-unneeded-of_node_put-in-felix_p.patch
  (bsc#1012628 CVE-2023-53170 bsc#1249850).
- Update
  patches.suse/net-ena-fix-shift-out-of-bounds-in-exponential-.patch
  (bsc#1012628 CVE-2023-53272 bsc#1249917).
- Update
  patches.suse/net-ethernet-mvpp2_main-fix-possible-OOB-write-in-mv.patch
  (git-fixes CVE-2023-53495 bsc#1250907).
- Update
  patches.suse/net-fix-net_dev_start_xmit-trace-event-vs-skb_t.patch
  (bsc#1012628 CVE-2023-53312 bsc#1250063).
- Update
  patches.suse/net-marvell-prestera-fix-handling-IPv4-routes-.patch
  (bsc#1012628 CVE-2023-53342 bsc#1250029).
- Update
  patches.suse/net-microchip-vcap-api-Fix-possible-memory-leak-for-.patch
  (git-fixes CVE-2023-53303 bsc#1249896).
- Update
  patches.suse/net-mlx5-Unregister-devlink-params-in-case-int.patch
  (bsc#1012628 CVE-2023-53507 bsc#1250808).
- Update
  patches.suse/net-mlx5e-fix-memory-leak-in-mlx5e_fs_tt_redire.patch
  (bsc#1012628 CVE-2023-53371 bsc#1250112).
- Update
  patches.suse/net-mlx5e-xsk-Fix-crash-on-regular-rq-reactiva.patch
  (bsc#1012628 CVE-2023-53394 bsc#1250199).
- Update
  patches.suse/net-rose-convert-use-field-to-refcount_t.patch
  (git-fixes CVE-2025-39826 bsc#1250203).
- Update
  patches.suse/net-rose-include-node-references-in-rose_neigh-refco.patch
  (git-fixes CVE-2025-39827 bsc#1250204).
- Update
  patches.suse/net-usb-asix_devices-Fix-PHY-address-mask-in-MDIO-bu.patch
  (git-fixes CVE-2025-38736 bsc#1249318).
- Update
  patches.suse/net-usb-asix_devices-add-phy_mask-for-ax88772-mdio-b.patch
  (git-fixes CVE-2025-38725 bsc#1249170).
- Update
  patches.suse/netfilter-conntrack-dccp-copy-entire-header-to-.patch
  (CVE-2023-39197 bsc#1012628 bsc#1216976 CVE-2023-53333
  bsc#1249949).
- Update
  patches.suse/netfilter-ipset-add-the-missing-IP_SET_HASH_WITH_NET.patch
  (CVE-2023-42753 bsc#1215150 CVE-2023-53179 bsc#1249825).
- Update
  patches.suse/netfilter-nf_tables-do-not-ignore-genmask-when-.patch
  (bsc#1012628 CVE-2023-31248 bsc#1213061 CVE-2023-53492
  bsc#1250823).
- Update
  patches.suse/netfilter-nft_set_rbtree-fix-overlap-expiration.patch
  (bsc#1012628 CVE-2023-53304 bsc#1249923).
- Update
  patches.suse/netlink-avoid-infinite-retry-looping-in-netlink_unic.patch
  (CVE-2025-38465 bsc#1247118 CVE-2025-38727 bsc#1249166).
- Update
  patches.suse/nfsd-handle-get_client_locked-failure-in-nfsd4_setclientid_confirm.patch
  (git-fixes CVE-2025-38724 bsc#1249169).
- Update
  patches.suse/nilfs2-fix-use-after-free-of-nilfs_root-in-dir.patch
  (bsc#1012628 CVE-2023-53311 bsc#1250062).
- Update
  patches.suse/ntfs-Fix-panic-about-slab-out-of-bounds-caused-.patch
  (bsc#1012628 CVE-2023-53420 bsc#1250186).
- Update
  patches.suse/nubus-Partially-revert-proc_create_single_data-.patch
  (bsc#1012628 CVE-2023-53217 bsc#1249672).
- Update
  patches.suse/null_blk-fix-poll-request-timeout-handling.patch
  (bsc#1216436 CVE-2023-53531 bsc#1250931).
- Update
  patches.suse/ovl-fix-null-pointer-dereference-in-ovl_permiss.patch
  (bsc#1012628 CVE-2023-53260 bsc#1249768).
- Update
  patches.suse/pNFS-Fix-uninited-ptr-deref-in-block-scsi-layout.patch
  (git-fixes CVE-2025-38691 bsc#1249215).
- Update
  patches.suse/pcmcia-Add-error-handling-for-add_interval-in-do_val.patch
  (git-fixes CVE-2025-39920 bsc#1250732).
- Update
  patches.suse/pcmcia-Fix-a-NULL-pointer-dereference-in-__iodyn_fin.patch
  (git-fixes CVE-2025-39846 bsc#1250263).
- Update
  patches.suse/phy-hisilicon-Fix-an-out-of-bounds-check-in-his.patch
  (bsc#1012628 CVE-2023-53238 bsc#1249707).
- Update
  patches.suse/powercap-arm_scmi-Remove-recursion-while-parsing-zon.patch
  (git-fixes CVE-2023-53428 bsc#1250167).
- Update
  patches.suse/powerpc-rtas_flash-allow-user-copy-to-flash-bl.patch
  (bsc#1012628 bsc#1194869 CVE-2023-53487 bsc#1250830).
- Update
  patches.suse/pstore-ram-Check-start-of-empty-przs-during-init.patch
  (git-fixes CVE-2023-53331 bsc#1249950).
- Update
  patches.suse/pwm-lpc32xx-Remove-handling-of-PWM-channels.patch
  (git-fixes CVE-2023-53472 bsc#1250841).
- Update
  patches.suse/rcu-rcuscale-Stop-kfree_scale_thread-thread-s-a.patch
  (bsc#1012628 CVE-2023-53291 bsc#1249926).
- Update
  patches.suse/regulator-da9063-better-fix-null-deref-with-pa.patch
  (bsc#1012628 CVE-2023-53364 bsc#1249984).
- Update
  patches.suse/s390-ism-fix-concurrency-management-in-ism_cmd.patch
  (git-fixes bsc#1248735 CVE-2025-39726 bsc#1249266).
- Update patches.suse/s390-sclp-Fix-SCCB-present-check.patch
  (git-fixes bsc#1249123 CVE-2025-39694 bsc#1249299).
- Update
  patches.suse/sched-fair-Don-t-balance-task-to-its-current-ru.patch
  (bsc#1012628 CVE-2023-53215 bsc#1250397).
- Update
  patches.suse/scsi-core-Fix-possible-memory-leak-if-device_a.patch
  (bsc#1012628 CVE-2023-53174 bsc#1250024).
- Update
  patches.suse/scsi-lpfc-Check-for-hdwq-null-ptr-when-cleaning-up-l.patch
  (bsc#1245260 bsc#1243100 bsc#1246125 CVE-2025-38695
  bsc#1249285).
- Update
  patches.suse/scsi-qla2xxx-Fix-potential-NULL-pointer-derefer.patch
  (bsc#1012628 CVE-2023-53451 bsc#1250831).
- Update
  patches.suse/scsi-qla2xxx-Pointer-may-be-dereferenced.patch
  (bsc#1012628 CVE-2023-53150 bsc#1249853).
- Update
  patches.suse/scsi-qla2xxx-Remove-unused-nvme_ls_waitq-wait-q.patch
  (bsc#1012628 CVE-2023-53280 bsc#1249938).
- Update
  patches.suse/scsi-qla2xxx-Use-raw_smp_processor_id-instead-of-smp.patch
  (bsc#1214928 jsc#PED-5063 CVE-2023-53530 bsc#1250949).
- Update
  patches.suse/scsi-qla2xxx-Wait-for-io-return-on-terminate-rp.patch
  (bsc#1012628 CVE-2023-53322 bsc#1250323).
- Update
  patches.suse/scsi-qla4xxx-Add-length-check-when-parsing-nlattrs.patch
  (git-fixes CVE-2023-53456 bsc#1250765).
- Update
  patches.suse/scsi-snic-Fix-possible-memory-leak-if-device_a.patch
  (bsc#1012628 CVE-2023-53436 bsc#1250156).
- Update
  patches.suse/scsi-storvsc-Fix-handling-of-virtual-Fibre-Cha.patch
  (bsc#1012628 CVE-2023-53245 bsc#1249641).
- Update patches.suse/scsi-ufs-core-Fix-handling-of-lrbp-cmd.patch
  (bsc#1012628 CVE-2023-53510 bsc#1250812).
- Update patches.suse/serial-8250-fix-panic-due-to-PSLVERR.patch
  (git-fixes CVE-2025-39724 bsc#1249265).
- Update
  patches.suse/shmem-use-ramfs_kill_sb-for-kill_sb-method-of-r.patch
  (bsc#1012628 CVE-2023-53391 bsc#1250117).
- Update
  patches.suse/skbuff-skb_segment-Call-zero-copy-functions-before-u.patch
  (bsc#1220419 CVE-2023-53354 bsc#1250004).
- Update
  patches.suse/smb-client-fix-warning-in-cifs_smb3_do_mount.patch
  (bsc#1012628 CVE-2023-53230 bsc#1249866).
- Update
  patches.suse/soundwire-qcom-fix-storing-port-config-out-of-b.patch
  (bsc#1012628 CVE-2023-53465 bsc#1250863).
- Update
  patches.suse/start_kernel-Add-__no_stack_protector-function-.patch
  (bsc#1012628 CVE-2023-53491 bsc#1250942).
- Update
  patches.suse/thunderbolt-Fix-memory-leak-in-tb_handle_dp_ba.patch
  (bsc#1012628 CVE-2023-53527 bsc#1250929).
- Update
  patches.suse/tls-separate-no-async-decryption-request-handling-fr.patch
  (CVE-2024-26584 bsc#1220186 CVE-2024-58240 bsc#1248847).
- Update
  patches.suse/tracing-Fix-null-pointer-dereference-in-tracing.patch
  (bsc#1012628 CVE-2023-53167 bsc#1249712).
- Update
  patches.suse/tracing-Fix-race-issue-between-cpu-buffer-write-and-swap.patch
  (git-fixes CVE-2023-53368 bsc#1249979).
- Update
  patches.suse/ublk-fail-to-recover-device-if-queue-setup-is-i.patch
  (bsc#1012628 CVE-2023-53207 bsc#1249678).
- Update
  patches.suse/ublk-fail-to-start-device-if-queue-setup-is-int.patch
  (bsc#1012628 CVE-2023-53508 bsc#1250809).
- Update
  patches.suse/udf-Fix-uninitialized-array-access-for-some-pat.patch
  (bsc#1012628 CVE-2023-53165 bsc#1250395).
- Update
  patches.suse/usb-cdns3-Put-the-cdns-set-active-part-outside-the-s.patch
  (git-fixes CVE-2023-53287 bsc#1250089).
- Update
  patches.suse/usb-core-config-Prevent-OOB-read-in-SS-endpoint-comp.patch
  (stable-fixes CVE-2025-39760 bsc#1249598).
- Update
  patches.suse/usb-dwc3-Remove-WARN_ON-for-device-endpoint-command-.patch
  (stable-fixes CVE-2025-39801 bsc#1250450).
- Update
  patches.suse/usb-dwc3-qcom-Fix-potential-memory-leak.patch
  (bsc#1012628 CVE-2023-53196 bsc#1249758).
- Update
  patches.suse/usb-gadget-u_serial-Add-null-pointer-check-in-g.patch
  (bsc#1012628 CVE-2023-53356 bsc#1249997).
- Update
  patches.suse/usb-phy-phy-tahvo-fix-memory-leak-in-tahvo_usb_.patch
  (bsc#1012628 CVE-2023-53379 bsc#1250128).
- Update
  patches.suse/virtio-mmio-don-t-break-lifecycle-of-vm_dev.patch
  (bsc#1012628 CVE-2023-53515 bsc#1250917).
- Update patches.suse/vxlan-Fix-nexthop-hash-size.patch
  (bsc#1012628 CVE-2023-53192 bsc#1249897).
- Update
  patches.suse/wifi-ath11k-fix-sleeping-in-atomic-in-ath11k_mac_op_.patch
  (git-fixes CVE-2025-39732 bsc#1249292).
- Update
  patches.suse/wifi-ath12k-Avoid-NULL-pointer-access-during-ma.patch
  (bsc#1012628 CVE-2023-53180 bsc#1249826).
- Update
  patches.suse/wifi-ath12k-Correct-tid-cleanup-when-tid-setup-fails.patch
  (stable-fixes CVE-2025-39750 bsc#1249523).
- Update
  patches.suse/wifi-ath12k-Decrement-TID-on-RX-peer-frag-setup-erro.patch
  (stable-fixes CVE-2025-39761 bsc#1249554).
- Update
  patches.suse/wifi-ath9k-don-t-allow-to-overwrite-ENDPOINT0-a.patch
  (bsc#1012628 CVE-2023-53185 bsc#1249820).
- Update
  patches.suse/wifi-brcmfmac-fix-use-after-free-when-rescheduling-b.patch
  (git-fixes CVE-2025-39863 bsc#1250281).
- Update
  patches.suse/wifi-cfg80211-fix-use-after-free-in-cmp_bss.patch
  (git-fixes CVE-2025-39864 bsc#1250242).
- Update
  patches.suse/wifi-cfg80211-sme-cap-SSID-length-in-__cfg80211_conn.patch
  (git-fixes CVE-2025-39849 bsc#1250266).
- Update
  patches.suse/wifi-iwlwifi-pcie-fix-NULL-pointer-dereference-.patch
  (bsc#1012628 CVE-2023-53251 bsc#1249730).
- Update
  patches.suse/wifi-mac80211-check-S1G-action-frame-size.patch
  (git-fixes CVE-2023-53257 bsc#1249869).
- Update
  patches.suse/wifi-mac80211_hwsim-Fix-possible-NULL-dereferen.patch
  (bsc#1012628 CVE-2023-53209 bsc#1249856).
- Update patches.suse/wifi-mac80211_hwsim-drop-short-frames.patch
  (git-fixes CVE-2023-53321 bsc#1250313).
- Update
  patches.suse/wifi-mwifiex-Fix-OOB-and-integer-underflow-when-rx-p.patch
  (git-fixes CVE-2023-53226 bsc#1249658).
- Update
  patches.suse/wifi-mwifiex-Initialize-the-chan_stats-array-to-zero.patch
  (git-fixes CVE-2025-39891 bsc#1250712).
- Update
  patches.suse/wifi-mwifiex-avoid-possible-NULL-skb-pointer-derefer.patch
  (git-fixes CVE-2023-53384 bsc#1250127).
- Update
  patches.suse/x86-MCE-Always-save-CS-register-on-AMD-Zen-IF-Poison-error.patch
  (git-fixes CVE-2023-53438 bsc#1250180).
- Update
  patches.suse/x86-mm-64-define-ARCH_PAGE_TABLE_SYNC_MASK-and-arch_.patch
  (git-fixes CVE-2025-39845 bsc#1250262).
- Update
  patches.suse/x86-platform-uv-Use-alternate-source-for-socket-to-n.patch
  (bsc#1215696 CVE-2023-53496 bsc#1250905).
- Update
  patches.suse/xfrm-add-NULL-check-in-xfrm_update_ae_params.patch
  (bsc#1012628 bsc#1213666 CVE-2023-3772 CVE-2023-53147
  bsc#1249880).
- Update
  patches.suse/xfrm-fix-slab-use-after-free-in-decode_session.patch
  (bsc#1012628 CVE-2023-53500 bsc#1250816).
- Update
  patches.suse/xsk-Fix-xsk_diag-use-after-free-error-during-socket-.patch
  (bsc#1220419 CVE-2023-53426 bsc#1250166).
- commit ee10a6d

- i40e: Fix potential invalid access when MAC list is empty (CVE-2025-39853 bsc#1250275)
- commit 4246fc5

- RDMA/siw: Always report immediate post SQ errors (git-fixes)
- commit c1b6a15

- RDMA/rxe: Fix race in do_task() when draining (git-fixes)
- commit 650fcb3

- IB/sa: Fix sa_local_svc_timeout_ms read race (git-fixes)
- commit ced2c38

- RDMA/core: Resolve MAC of next-hop device without ARP support (git-fixes)
- commit 9a8b6d9

- RDMA/cm: Rate limit destroy CM ID timeout error message (git-fixes)
- commit 99220cf

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

- RDMA/mlx5: Better estimate max_qp_wr to reflect WQE count (git-fixes)
- commit 665905d

- bus: mhi: host: Do not use uninitialized 'dev' pointer in
  mhi_init_irq_setup() (git-fixes).
- iio: imu: inv_icm42600: Drop redundant pm_runtime
  reinitialization in resume (git-fixes).
- iio: consumers: Fix offset handling in
  iio_convert_raw_to_processed() (git-fixes).
- iio: dac: ad5421: use int type to store negative error codes
  (git-fixes).
- iio: dac: ad5360: use int type to store negative error codes
  (git-fixes).
- iio: frequency: adf4350: Fix ADF4350_REG3_12BIT_CLKDIV_MODE
  (git-fixes).
- iio: frequency: adf4350: Fix prescaler usage (git-fixes).
- iio: xilinx-ams: Fix AMS_ALARM_THR_DIRECT_MASK (git-fixes).
- iio: xilinx-ams: Unmask interrupts after updating alarms
  (git-fixes).
- misc: genwqe: Fix incorrect cmd field being reported in error
  (git-fixes).
- uio: uio_pdrv_genirq: Remove MODULE_DEVICE_TABLE (git-fixes).
- thunderbolt: Compare HMAC values in constant time (git-fixes).
- usb: misc: qcom_eud: Access EUD_MODE_MANAGER2 through secure
  calls (git-fixes).
- usb: host: max3421-hcd: Fix error pointer dereference in probe
  cleanup (git-fixes).
- tty: n_gsm: Don't block input queue by waiting MSC (git-fixes).
- serial: max310x: Add error checking in probe() (git-fixes).
- mtd: rawnand: omap2: fix device leak on probe failure
  (git-fixes).
- HID: intel-ish-ipc: Remove redundant ready check after timeout
  function (git-fixes).
- hwrng: ks-sa - fix division by zero in ks_sa_rng_init
  (git-fixes).
- crypto: hisilicon/qm - set NULL to qm-&amp;gt;debug.qm_diff_regs
  (git-fixes).
- crypto: aspeed - Fix dma_unmap_sg() direction (git-fixes).
- crypto: atmel - Fix dma_unmap_sg() direction (git-fixes).
- crypto: hisilicon/qm - check whether the input function and
  PF are on the same device (git-fixes).
- hwrng: nomadik - add ARM_AMBA dependency (git-fixes).
- crypto: keembay - Add missing check after sg_nents_for_len()
  (git-fixes).
- commit 6795b42

- rpm/check-for-config-changes: ignore CONFIG_SCHED_PROXY_EXEC, too (bsc#1250946)
  CONFIG_SCHED_PROXY_EXEC is set only when the debug is off, exclusive
  to CONFIG_SCHED_CLASS_EXT.
- commit ac06fa9

- drivers/base/node: fix double free in register_one_node()
  (git-fixes).
- commit 205d070

- net: nfc: nci: Add parameter validation for packet data
  (git-fixes).
- net: usb: Remove disruptive netif_wake_queue in
  rtl8150_set_multicast (git-fixes).
- wifi: ath11k: HAL SRNG: don't deinitialize and re-initialize
  again (git-fixes).
- wifi: ath10k: avoid unnecessary wait for service ready message
  (git-fixes).
- wifi: ath11k: fix NULL dereference in ath11k_qmi_m3_load()
  (git-fixes).
- wifi: rtw89: avoid circular locking dependency in
  ser_state_run() (git-fixes).
- wifi: mac80211: fix Rx packet handling when pubsta information
  is not available (git-fixes).
- wifi: mt76: fix potential memory leak in mt76_wmac_probe()
  (git-fixes).
- wifi: mwifiex: send world regulatory domain to driver
  (git-fixes).
- media: b2c2: Fix use-after-free causing by irq_check_work in
  flexcop_pci_remove (git-fixes).
- media: uvcvideo: Mark invalid entities with id
  UVC_INVALID_ENTITY_ID (git-fixes).
- media: i2c: mt9v111: fix incorrect type for ret (git-fixes).
- media: pci: ivtv: Add missing check after DMA map (git-fixes).
- media: cx18: Add missing check after DMA map (git-fixes).
- media: st-delta: avoid excessive stack usage (git-fixes).
- media: v4l2-subdev: Fix alloc failure check in
  v4l2_subdev_call_state_try() (git-fixes).
- wifi: virt_wifi: Fix page fault on connect (stable-fixes).
- mmc: sdhci-cadence: add Mobileye eyeQ support (stable-fixes).
- usb: core: Add 0x prefix to quirks debug output (stable-fixes).
- commit dbb8904

- maple_tree: fix MAPLE_PARENT_RANGE32 and parent pointer docs
  (git-fixes).
- media: rj54n1cb0c: Fix memleak in rj54n1_probe() (git-fixes).
- media: lirc: Fix error handling in lirc_register() (git-fixes).
- media: zoran: Remove zoran_fh structure (git-fixes).
- drm/amdgpu: remove the redeclaration of variable i (git-fixes).
- drm/msm/dpu: fix incorrect type for ret (git-fixes).
- drm/amdkfd: Fix error code sign for EINVAL in svm_ioctl()
  (git-fixes).
- drm/amd/pm: Disable SCLK switching on Oland with high pixel
  clocks (v3) (git-fixes).
- drm/amd/pm: Disable MCLK switching with non-DC at 120 Hz+ (v2)
  (git-fixes).
- drm/amd/pm: Treat zero vblank time as too short in si_dpm (v3)
  (git-fixes).
- drm/amd/pm: Adjust si_upload_smc_data register programming (v3)
  (git-fixes).
- drm/amd/pm: Fix si_upload_smc_data (v3) (git-fixes).
- drm/amd/pm: Disable ULV even if unsupported (v3) (git-fixes).
- drm/amdgpu: Power up UVD 3 for FW validation (v2) (git-fixes).
- drm/rcar-du: dsi: Fix 1/2/3 lane support (git-fixes).
- drm/amd/display: Remove redundant semicolons (git-fixes).
- firewire: core: fix overlooked update of subsystem ABI version
  (git-fixes).
- commit 2161328

- docs: admin-guide: update to current minimum pipe size default
  (git-fixes).
- drivers/base/node: handle error properly in register_one_node()
  (git-fixes).
- Bluetooth: ISO: don't leak skb in ISO_CONT RX (git-fixes).
- Bluetooth: ISO: Fix possible UAF on iso_conn_free (git-fixes).
- Bluetooth: MGMT: Fix not exposing debug UUID on
  MGMT_OP_READ_EXP_FEATURES_INFO (git-fixes).
- drm/radeon/r600_cs: clean up of dead code in r600_cs
  (git-fixes).
- drm/bridge: it6505: select REGMAP_I2C (git-fixes).
- drm/panel: novatek-nt35560: Fix invalid return value
  (git-fixes).
- can: rcar_can: rcar_can_resume(): fix s2ram with PSCI
  (stable-fixes).
- drm/i915/backlight: Return immediately when scale() finds
  invalid parameters (stable-fixes).
- commit 07504f9

- ASoC: wcd934x: fix error handling in wcd934x_codec_parse_data()
  (git-fixes).
- ALSA: usb-audio: fix race condition to UAF in snd_usbmidi_free
  (git-fixes).
- ASoC: Intel: bytcr_rt5651: Fix invalid quirk input mapping
  (git-fixes).
- ASoC: Intel: bytcr_rt5640: Fix invalid quirk input mapping
  (git-fixes).
- ASoC: Intel: bytcht_es8316: Fix invalid quirk input mapping
  (git-fixes).
- ASoC: qcom: audioreach: fix potential null pointer dereference
  (git-fixes).
- ASoC: imx-hdmi: remove cpu_pdev related code (git-fixes).
- ALSA: lx_core: use int type to store negative error codes
  (git-fixes).
- ALSA: usb-audio: Add mute TLV for playback volumes on more
  devices (stable-fixes).
- ALSA: usb-audio: move mixer_quirks' min_mute into common quirk
  (stable-fixes).
- commit 86dd099

- ALSA: usb-audio: Add DSD support for Comtrue USB Audio device
  (stable-fixes).
- ALSA: usb-audio: Fix build with CONFIG_INPUT=n (git-fixes).
- ALSA: usb-audio: Convert comma to semicolon (git-fixes).
- ALSA: usb-audio: Add mixer quirk for Sony DualSense PS5
  (stable-fixes).
- ALSA: usb-audio: Remove unneeded wmb() in mixer_quirks
  (stable-fixes).
- ALSA: usb-audio: Simplify NULL comparison in mixer_quirks
  (stable-fixes).
- ALSA: usb-audio: Avoid multiple assignments in mixer_quirks
  (stable-fixes).
- ALSA: usb-audio: Drop unnecessary parentheses in mixer_quirks
  (stable-fixes).
- ALSA: usb-audio: Fix block comments in mixer_quirks
  (stable-fixes).
- commit 929e260

- Squashfs: reject negative file sizes in squashfs_read_inode()
  (git-fixes).
- commit 2f68e78

- Squashfs: add additional inode sanity checking (git-fixes).
- commit fe46811

- Squashfs: fix uninit-value in squashfs_get_parent (git-fixes).
- commit 126861e

- kbuild/modpost: Continue processing all unresolved symbols
  when KLP_SYM_RELA is found (bsc#1218644, bsc#1250655).
- commit ec0a51c

- Fix BPF selftests compilation error in bpf_iter.c (git-fixes)
  Since SUSE commit 7cae2487c586, BPF selftests fails to compile.
  .../tools/testing/selftests/bpf/prog_tests/bpf_iter.c: In function 'test_task_common_nocheck':
  .../tools/testing/selftests/bpf/prog_tests/bpf_iter.c:231:26: error: implicit declaration of function 'gettid'; did you mean 'getgid'? [-Werror=implicit-function-declaration]
    231 |         skel-&amp;gt;bss-&amp;gt;tid = gettid();
    |                          ^~~~~~
    |                          getgid
  Fix the BPF selftests compilation failure by:
- bpf: handle implicit declaration of function gettid in
  bpf_iter.c
- Refresh
  patches.suse/selftests-bpf-Clean-up-open-coded-gettid-syscall-inv.patch.
- commit 43aa317

- Drivers: hv: Select CONFIG_SYSFB only if EFI is enabled (git-fixes).
- KVM: x86/hyper-v: Skip non-canonical addresses during PV TLB flush (bsc#1246782 CVE-2025-38351).
- Drivers: hv: Always select CONFIG_SYSFB for Hyper-V guests (git-fixes).
- KVM: x86: model canonical checks more precisely (bsc#1246782 CVE-2025-38351).
- KVM: x86: Add X86EMUL_F_MSR and X86EMUL_F_DT_LOAD to aid canonical (bsc#1246782 CVE-2025-38351).
- KVM: x86: Route non-canonical checks in emulator through emulate_ops (bsc#1246782 CVE-2025-38351).
- KVM: x86: drop x86.h include from cpuid.h (bsc#1246782 CVE-2025-38351).
- KVM: x86: Bury guest_cpuid_is_amd_or_hygon() in cpuid.c (bsc#1246782 CVE-2025-38351).
- KVM: SVM: Emulate SYSENTER RIP/RSP behavior for all Intel compat (bsc#1246782 CVE-2025-38351).
- KVM: x86: Inhibit code #DBs in MOV-SS shadow for all Intel compat (bsc#1246782 CVE-2025-38351).
- KVM: x86: Apply Intel's TSC_AUX reserved-bit behavior to Intel compat (bsc#1246782 CVE-2025-38351).
- KVM: x86/pmu: Squash period for checkpointed events based on host (bsc#1246782 CVE-2025-38351).
- commit 6e28165

- Update
  patches.suse/HID-asus-fix-UAF-via-HID_CLAIMED_INPUT-validation.patch
  (CVE-2025-39824 bsc#1250007).
  Added CVE reference
- commit 579a063

- smb: client: fix race with concurrent opens in rename(2)
  (bsc#1250179, CVE-2025-39825).
- commit 4df7381

- bus: fsl-mc: Check return value of platform_get_resource()
  (git-fixes).
- memory: samsung: exynos-srom: Fix of_iomap leak in
  exynos_srom_probe (git-fixes).
- firmware: meson_sm: fix device leak at probe (git-fixes).
- soc: qcom: rpmh-rsc: Unconditionally clear _TRIGGER bit for TCS
  (git-fixes).
- thermal/drivers/qcom/lmh: Add missing IRQ includes (git-fixes).
- ACPI: TAD: Add missing sysfs_remove_group() for ACPI_TAD_RT
  (git-fixes).
- ACPI: property: Fix buffer properties extraction for subnodes
  (git-fixes).
- ACPI: processor: idle: Fix memory leak when register cpuidle
  device failed (git-fixes).
- ACPICA: Fix largest possible resource descriptor index
  (git-fixes).
- ACPI: debug: fix signedness issues in read/write helpers
  (git-fixes).
- PM: sleep: core: Clear power.must_resume in noirq suspend
  error path (git-fixes).
- PM / devfreq: mtk-cci: Fix potential error pointer dereference
  in probe() (git-fixes).
- i3c: master: svc: Recycle unused IBI slot (git-fixes).
- i3c: Fix default I2C adapter timeout value (git-fixes).
- i2c: designware: Add disabling clocks when probe fails
  (git-fixes).
- i2c: mediatek: fix potential incorrect use of I2C_MASTER_WRRD
  (git-fixes).
- pinctrl: renesas: Use int type to store negative error codes
  (git-fixes).
- pinctrl: samsung: Drop unused S3C24xx driver data (git-fixes).
- pinctrl: meson-gxl: add missing i2c_d pinmux (git-fixes).
- pinctrl: equilibrium: Remove redundant semicolons (git-fixes).
- power: supply: max77976_charger: fix constant current reporting
  (git-fixes).
- power: supply: cw2015: Fix a alignment coding style issue
  (git-fixes).
- mfd: rz-mtu3: Fix MTU5 NFCR register offset (git-fixes).
- spi: cadence-quadspi: Flush posted register writes before DAC
  access (git-fixes).
- spi: cadence-quadspi: Flush posted register writes before
  INDAC access (git-fixes).
- spi: mtk-snfi: Remove redundant semicolons (git-fixes).
- spi: bcm2835: Remove redundant semicolons (git-fixes).
- regulator: scmi: Use int type to store negative error codes
  (git-fixes).
- regmap: Remove superfluous check for !config in __regmap_init()
  (git-fixes).
- mfd: vexpress-sysreg: Check the return value of
  devm_gpiochip_add_data() (git-fixes).
- pwm: tiehrpwm: Fix corner case in clock divisor calculation
  (git-fixes).
- pwm: tiehrpwm: Make code comment in .free() more useful
  (git-fixes).
- pwm: berlin: Fix wrong register in suspend/resume (git-fixes).
- hwmon: (mlxreg-fan) Separate methods of fan setting coming
  from different subsystems (git-fixes).
- commit e80711d

- Drop patches.suse/drm-amd-display-Disable-PSR-SU-on-eDP-panels.patch (bsc#1243112)
  The patch caused a regression wrt s2idle on AMD laptops
- commit 5a5bec2

- net/smc: fix UAF on smcsk after smc_listen_out() (CVE-2025-38734
  bsc#1249324).
- commit b4812d3

- Update
  patches.suse/dmaengine-ti-edma-Fix-memory-allocation-size-for-que.patch
  (CVE-2025-39869 bsc#1250406).
  Added CVE reference
- commit 056198e

- writeback: Avoid contention on wb-&amp;gt;list_lock when switching
  inodes (kABI fixup) (bsc#1237776).
- commit 883c841

- netfilter: ctnetlink: remove refcounting in expectation dumpers
  (CVE-2025-39764 bsc#1249513).
- commit 09ba55b

- net/sched: Make cake_enqueue return NET_XMIT_CN when past
  buffer_limit (CVE-2025-39766 bsc#1249510).
- commit c0189b7

- net/sched: Fix backlog accounting in qdisc_dequeue_internal
  (CVE-2025-39677 bsc#1249300).
- commit 3cfca22

- tls: handle data disappearing from under the TLS ULP
  (CVE-2025-38616 bsc#1248512).
- tls: fix lockless read of strp-&amp;gt;msg_ready in -&amp;gt;poll
  (CVE-2025-38616 bsc#1248512).
- commit 8c223c9

- cifs: prevent NULL pointer dereference in UTF16 conversion
  (bsc#1250365, CVE-2025-39838).
- commit 9718aa1

- scsi: core: ufs: Fix a hang in the error handler (CVE-2025-38119
  bsc#1245700).
- commit 43675ce

- writeback: Avoid excessively long inode switching times
  (bsc#1237776).
- commit 77817f2

- writeback: Avoid softlockup when switching many inodes
  (bsc#1237776).
- commit 9ecba0d

- writeback: Avoid contention on wb-&amp;gt;list_lock when switching
  inodes (bsc#1237776).
- commit a591614

- usb: hub: Fix flushing of delayed work used for post resume
  purposes (git-fixes).
- commit 4e89947

- usb: xhci: Avoid queuing redundant Stop Endpoint commands
  (git-fixes).
- commit 4f545a3

- usb: xhci: Limit Stop Endpoint retries (git-fixes).
- commit e78c1d4

- usb: hub: Fix flushing and scheduling of delayed work that
  tunes runtime pm (git-fixes).
- commit ae10133

- xhci: retry Stop Endpoint on buggy NEC controllers (git-fixes).
- Refresh
  patches.suse/usb-xhci-Don-t-change-the-status-of-stalled-TDs-on-f.patch.
- commit beea3a0

- usb: hub: fix detection of high tier USB3 devices behind
  suspended hubs (git-fixes).
- commit 06b2dc7

- bpftool: Fix JSON writer resource leak in version command
  (git-fixes).
- commit d19e155

- EDAC/i10nm: Skip DIMM enumeration on a disabled memory
  controller (git-fixes).
- commit 45a7726

- sched/rt: Fix race in push_rt_task (CVE-2025-38234 bsc#1246057)
- commit 36ede09

- sched/core: Prevent rescheduling when interrupts are disabled (CVE-2024-58090 bsc#1240324)
- commit 5da028c

- xfs: do not propagate ENODATA disk errors into xattr code
  (bsc#1250025 CVE-2025-39835).
- commit 78d977d

- ocfs2: fix recursive semaphore deadlock in fiemap call
  (bsc#1250407 CVE-2025-39885).
- ocfs2: prevent release journal inode after journal shutdown
  (bsc#1250267 CVE-2025-39842).
- commit 3a5de55

- mm/smaps: fix race between smaps_hugetlb_range and migration
  (CVE-2025-39754 bsc#1249524).
- commit 313ab7a

- seccomp: Fix a race with WAIT_KILLABLE_RECV if the tracer
  replies too fast (git-fixes).
- commit fb88d9d

- tty: hvc_console: Call hvc_kick in hvc_write unconditionally
  (bsc#1230062).
- commit 3702f36

- afs: Fix potential null pointer dereference in afs_put_server
  (git-fixes).
- commit 3a230bf

- net/smc: fix one NULL pointer dereference in smc_ib_is_sg_need_sync() (CVE-2025-39857 bsc#1250251)
- commit 7481e31

- selftests/cpufreq: Fix cpufreq basic read and update testcases
  (bsc#1250344).
- commit 83a7790

- drm/ast: Use msleep instead of mdelay for edid read
  (bsc#1250530).
- commit 2fd5794

- net/sched: ets: use old 'nbands' while purging unused classes
  (CVE-2025-38684 bsc#1249156).
- commit e0501b7

- KVM: x86: use array_index_nospec with indices that come from
  guest (CVE-2025-39823 bsc#1250002).
- commit ecf3611

- tee: fix NULL pointer dereference in tee_shm_put (CVE-2025-39865
  bsc#1250294).
- commit 3708eb2

- cpufreq: Initialize cpufreq-based invariance before subsys
  (git-fixes).
- commit 9618c74

- cpufreq: tegra186: Share policy per cluster (stable-fixes).
- commit dac2616

- x86/cpu/hygon: Add missing resctrl_cpu_detect() in bsp_init
  helper (CVE-2025-39681 bsc#1249303).
- commit 5bc51ab

- coresight: Fix memory leak in acpi_buffer-&amp;gt;pointer
  (CVE-2023-53261 bsc#1249770).
- commit 7cf7512

- soc: qcom: mdt_loader: Deal with zero e_shentsize
  (CVE-2025-39787 bsc#1249545).
- soc: qcom: mdt_loader: Fix error return values in
  mdt_header_valid() (CVE-2025-39787 bsc#1249545).
- commit 3946900

- i2c: riic: Allow setting frequencies lower than 50KHz
  (git-fixes).
- soc: qcom: mdt_loader: Ensure we don't read past the ELF header
  (CVE-2025-39787 bsc#1249545).
- commit bb8f700

- sched/isolation: Fix boot crash when maxcpus &amp;lt; first (git-fixes)
- commit f52d7e3

- sched/numa, mm: do not try to migrate memory to memoryless (git-fixes)
- commit d547451

- sched/fair: Remove unused parameter from sched_asym() (git-fixes)
- commit 6507dc9

- sched/fair: Take the scheduling domain into account in (git-fixes)
- commit 3d3501e

- sched/deadline: Collect sched_dl_entity initialization (git-fixes)
- commit 73df41d

- Bluetooth: MGMT: Fix possible UAFs (git-fixes).
- Refresh patches.kabi/hci_dev-centralize-extra-lock.patch.
- commit 358e9ae

- fbcon: Fix OOB access in font allocation (git-fixes).
- commit e730b01

- fbcon: fix integer overflow in fbcon_do_set_font (git-fixes).
- drm/gma500: Fix null dereference in hdmi teardown (git-fixes).
- can: peak_usb: fix shift-out-of-bounds issue (git-fixes).
- can: mcba_usb: populate ndo_change_mtu() to prevent buffer
  overflow (git-fixes).
- can: sun4i_can: populate ndo_change_mtu() to prevent buffer
  overflow (git-fixes).
- can: hi311x: populate ndo_change_mtu() to prevent buffer
  overflow (git-fixes).
- can: etas_es58x: populate ndo_change_mtu() to prevent buffer
  overflow (git-fixes).
- Bluetooth: hci_event: Fix UAF in hci_acl_create_conn_sync
  (git-fixes).
- Bluetooth: hci_sync: Fix hci_resume_advertising_sync
  (git-fixes).
- ALSA: hda/realtek: Fix mute led for HP Laptop 15-dw4xx
  (stable-fixes).
- net: rfkill: gpio: Fix crash due to dereferencering
  uninitialized pointer (git-fixes).
- net: phy: fix phy_uses_state_machine() (git-fixes).
- wifi: wilc1000: avoid buffer overflow in WID string
  configuration (stable-fixes).
- wifi: mac80211: increase scan_ies_len for S1G (stable-fixes).
- wifi: mac80211: fix incorrect type for ret (stable-fixes).
- ALSA: firewire-motu: drop EPOLLOUT from poll return values as
  write is not supported (stable-fixes).
- dmaengine: mediatek: Fix a flag reuse error in
  mtk_cqdma_tx_status() (git-fixes).
- commit f69acd3

- iommu/vt-d: Fix __domain_mapping()'s usage of
  switch_to_super_page() (git-fixes).
- commit 9b4fa49

- net: gso: Forbid IPv6 TSO with extensions on devices with only
  IPV6_CSUM (CVE-2025-39770 bsc#1249508).
- commit 8d2822a

- kabi: Restore layout of parallel_data (bsc1248343).
- commit c7e8448

- padata: Fix pd UAF once and for all (CVE-2025-38584 bsc1248343).
- commit 00470a2

- xfrm: xfrm_alloc_spi shouldn't use 0 as SPI (CVE-2025-39797
  bsc#1249608).
- commit a50d626

- xfrm: Duplicate SPI Handling (CVE-2025-39797 bsc#1249608).
- commit 313a1d3

- kernel-source.spec: Depend on python3-base for build
  Both kernel-binary and kernel-docs already have this dependency.
  Adding it to kernel-source makes it possible to use python in shared
  build scripts.
- commit 72fdedd

- kernel-source: Do not list mkspec and its inputs as sources
  (bsc#1250522).
  This excludes the files from the src.rpm. The next step is to remove
  these files in tar-up so that they do not get uploaded to OBS either.
  As there is only one version of tar-up these files need to be removed
  from all kernels.
- commit e72b8a2

- selftests: bpf: test batch lookup on array of maps with holes
  (git-fixes).
- commit 6ee12a9

- bpf: skip non exist keys in generic_map_lookup_batch
  (git-fixes).
- commit dcb10ca

- kABI: arm64: ftrace: Restore init_module behavior (git-fixes).
- commit 113b4db

- arm64: ftrace: fix unreachable PLT for ftrace_caller in init_module (git-fixes)
- commit 8f9b835

- rpm: Link arch-symbols script from scripts directory.
- commit 90b2abb

- Refresh
  patches.kabi/kABI-fix-for-net-vlan-fix-VLAN-0-refcount-imbalance-.patch.
- commit e192478

- struct ci_hdrc: new member has_short_pkt_limit to end
  (git-fixes).
- commit 5b5fa69

- cgroup: llist: avoid memory tears for llist_node (bsc#1247963).
- commit 854319b

- kabi: add struct cgroup_extra (bsc#1247963).
- commit 5114e86

- cgroup/rstat: Reduce cpu_lock hold time in
  cgroup_rstat_flush_locked() (bsc#1247963).
- commit 2f30983

- cgroup/rstat: Optimize cgroup_rstat_updated_list()
  (bsc#1247963).
- Refresh patches.kabi/kabi-add-struct-cgroup_extra.patch.
- commit 966ee8b

- btrfs: do not allow relocation of partially dropped  subvolumes
  (bsc#1249540 CVE-2025-39738).
- commit 60a9a58

- crypto: qat - add shutdown handler to qat_c3xxx (git-fixes).
- commit 562553d

- crypto: qat - add shutdown handler to qat_c62x (git-fixes).
- commit 95c669b

- rcu: Fix racy re-initialization of irq_work causing hangs (git-fixes)
- commit bc7d88d

- rcu: Fix rcu_read_unlock() deadloop due to IRQ work (bsc#1249494 CVE-2025-39744)
- commit ef20792

- rcu: Protect -&amp;gt;defer_qs_iw_pending from data race (bsc#1249533 CVE-2025-39749)
- commit 2b090f5

- use uniform permission checks for all mount propagation changes
  (git-fixes).
- commit 4b14435

- rcu/exp: Handle RCU expedited grace period kworker allocation (git-fixes)
- commit 7737606

- rcu/exp: Fix RCU expedited parallel grace period kworker (git-fixes)
- commit 19ee671

- crypto: qat - add shutdown handler to qat_dh895xcc (git-fixes).
- commit 7ca55c2

- usb: typec: tcpci: use GENMASK() for TCPC_ROLE_CTRL_CC[12]
  (git-fixes).
- commit 61574e5

- rpm: Link guards script from scripts directory.
- commit e19a893

- usb: typec: maxim_contaminant: re-enable cc toggle if cc is
  open and port is clean (git-fixes).
- commit d3067ea

- usb: typec: maxim_contaminant: disable low power mode when
  reading comparator values (git-fixes).
- commit f661b59

- usb: typec: tcpm/tcpci_maxim: fix non-contaminant CC handling
  (git-fixes).
- commit 38cd076

- usb: typec: tcpm/tcpci_maxim: use GENMASK() for
  TCPC_VENDOR_CC_CTRL2 register (git-fixes).
- commit 2b55585

- usb: dwc3: imx8mp: fix device leak at unbind (git-fixes).
- commit 5a35982

- usb: xhci: Fix invalid pointer dereference in Etron workaround
  (git-fixes).
- commit a8cfeaf

- config.sh: Use Step repository for building Leap kernel
  bs-upload-kernel does not understand the Leap repository layout
- commit cae4664

- usb: typec: fusb302: cache PD RX state (git-fixes).
- commit 3e6c8b0

- usb: dwc3: qcom: Don't leave BCR asserted (git-fixes).
- commit fdef7a6

- xhci: Fix control transfer error on Etron xHCI host (git-fixes).
- commit f7d6da1

- usb: chipidea: add CI_HDRC_HAS_SHORT_PKT_LIMIT flag (git-fixes).
- commit ff0fd10

- fs/nfs/io: make nfs_start_io_*() killable (git-fixes).
- commit 8cf21ec

- Delete patches.kabi/KVM-x86-Re-split-x2APIC-ICR-into-ICR-ICR2-for-AMD-x2.patch
- commit 0a00b28

- kabi: drop kvm_x86_ops from kabi relevant symbols
  Since upstream commit dfc4e6ca04113 (&amp;quot;KVM: x86: Unexport kvm_x86_ops&amp;quot;)
  v5.18-rc1~139^2~153 kvm_x86_ops is no longer exported, so it can be
  dropped from kabi checks.
- commit 4f5efb7

- kABI fix after vsock/virtio: fix `rx_bytes` accounting for
  stream sockets (git-fixes).
- commit dd1042c

- platform/x86: thinkpad_acpi: Handle KCOV __init vs inline
  mismatches (git-fixes).
- commit 7941d4d

- platform/mellanox: mlxbf-pmc: Validate event/enable input
  (git-fixes).
- commit 7bd7d6e

- platform/mellanox: mlxbf-pmc: Remove newline char from event
  name input (git-fixes).
- commit e4c52ac

- platform/x86: dell-wmi-sysman: Fix class device unregistration
  (git-fixes).
- commit c3cf8fd

- platform/x86: think-lmi: Fix class device unregistration
  (git-fixes).
- commit dab00ca

- netfilter: nf_reject: don't leak dst refcount for loopback
  packets (CVE-2025-38732 bsc#1249262).
- commit e613385

- vhost/net: Protect ubufs with rcu read lock in
  vhost_net_ubuf_put() (git-fixes).
- commit b347e0b

- vsock/virtio: Resize receive buffers so that each SKB fits in
  a 4K page (git-fixes).
- commit 64aa75c

- vhost/vsock: Avoid allocating arbitrarily-sized SKBs
  (git-fixes).
- commit 62a440b

- vhost: fail early when __vhost_add_used() fails (git-fixes).
- commit 9d77130

- vhost-scsi: Fix log flooding with target does not exist errors
  (git-fixes).
- commit 2d6a672

- vsock: Fix IOCTL_VM_SOCKETS_GET_LOCAL_CID to check also
  `transport_local` (git-fixes).
- commit 7139f2e

- vsock/virtio: fix `rx_bytes` accounting for stream sockets
  (git-fixes).
- commit c34e345

- IB/mlx5: Fix obj_type mismatch for SRQ event subscriptions (git-fixes)
- commit c2e717d

- vsock: avoid timeout during connect() if the socket is closing
  (git-fixes).
- commit 34796d2

- vhost-scsi: Return queue full for page alloc failures during
  copy (git-fixes).
- commit 3dcf5c3

- vsock: Allow retrying on connect() failure (git-fixes).
- commit 1f9e448

- 9p/xen: fix init sequence (git-fixes).
- commit 22e0fa2

- btrfs: tree-checker: fix the incorrect inode ref size check
  (git-fixes).
- commit 1a69e6a

- KVM: SVM: Sync TPR from LAPIC into VMCB::V_TPR even if AVIC
  is active (git-fixes).
- commit 97c436d

- KVM: x86: Drop pending_smi vs. INIT_RECEIVED check when setting
  MP_STATE (git-fixes).
- commit 1086ea1

- KVM: SVM: Disable interception of SPEC_CTRL iff the MSR exists
  for the guest (git-fixes).
- commit 16aecdb

- KVM: VMX: Extract checking of guest's DEBUGCTL into helper
  (git-fixes).
- commit a89d774

- KVM: x86: avoid underflow when scaling TSC frequency
  (git-fixes).
- commit 1dc5b36

- KVM: x86/xen: Allow 'out of range' event channel ports in IRQ
  routing table (git-fixes).
- commit fc7a1db

- KVM: VMX: Flush shadow VMCS on emergency reboot (git-fixes).
- commit 75149a0

- KVM: SVM: Clear current_vmcb during vCPU free for all *possible*
  CPUs (git-fixes).
- commit 221d435

- KVM: x86: Fully defer to vendor code to decide how to force
  immediate exit (git-fixes).
- commit 9d7cfec

- KVM: VMX: Handle KVM-induced preemption timer exits in fastpath
  for L2 (git-fixes).
- commit 4708423

- KVM: x86: Move handling of is_guest_mode() into fastpath exit
  handlers (git-fixes).
- commit 80f5d63

- btrfs: fix invalid extref key setup when replaying dentry
  (git-fixes).
- commit d51ea66

- KVM: VMX: Handle forced exit due to preemption timer in fastpath
  (git-fixes).
- commit 1eccc09

- KVM: VMX: Re-enter guest in fastpath for &amp;quot;spurious&amp;quot; preemption
  timer exits (git-fixes).
- commit e920f78

- KVM: x86: Plumb &amp;quot;force_immediate_exit&amp;quot; into kvm_entry()
  tracepoint (git-fixes).
- commit d90d7aa

- KVM: arm64: vgic: fix incorrect spinlock API usage (git-fixes).
- commit 972706e

- ext4: do not BUG when INLINE_DATA_FL lacks system.data xattr
  (bsc#1249258 CVE-2025-38701).
- commit f3682c5

- fs/buffer: fix use-after-free when call bh_read() helper
  (bsc#1249374 CVE-2025-39691).
- jbd2: prevent softlockup in jbd2_log_do_checkpoint()
  (bsc#1249526 CVE-2025-39782).
- loop: Avoid updating block size under exclusive owner
  (bsc#1249199 CVE-2025-38709).
- eventpoll: Fix semi-unbounded recursion (bsc#1248392
  CVE-2025-38614).
- commit fc4be97

- PCI: Extend isolated function probing to LoongArch (git-fixes).
- commit d35f4c9

- compiler: remove __ADDRESSABLE_ASM{_STR,}() again (git-fixes).
- commit bf93f6c

- x86/cpu: Add model number for Intel Clearwater Forest processor
  (git-fixes).
- commit 7c8efd9

- wifi: cfg80211: remove cfg80211_inform_single_bss_frame_data()
  (git-fixes).
- commit a72bcdf

- xen/netfront: Fix TX response spurious interrupts (git-fixes).
- commit 5e0ce6f

- KVM: s390: Fix incorrect usage of mmu_notifier_register()
  (git-fixes bsc#1250336).
- commit 64b94c2

- xen/gntdev: remove struct gntdev_copy_batch from stack
  (git-fixes).
- commit 13539ce

- wireless: purelifi: plfxlc: fix memory leak in
  plfxlc_usb_wreq_asyn() (git-fixes).
- commit 5a9e007

- xenbus: Allow PVH dom0 a non-local xenstore (git-fixes).
- commit 81be2ce

- xen: Add support for XenServer 6.1 platform device (git-fixes).
- commit a4daef0

- kabi: restore layout of struct cgroup_rstat_cpu (bsc#1247963).
- commit 05abe8b

- mmc: core: Use GFP_NOIO in ACMD22 (git-fixes).
- commit 58bbbbb

- cgroup: remove per-cpu per-subsystem locks (bsc#1247963).
- cgroup: make css_rstat_updated nmi safe (bsc#1247963).
- cgroup: support to enable nmi-safe css_rstat_updated
  (bsc#1247963).
- commit 2adc7c0

- NFSv4/flexfiles: Fix layout merge mirror check (git-fixes).
- commit fcad211

- SUNRPC: call xs_sock_process_cmsg for all cmsg (git-fixes).
- commit 1f5dab1

- Revert &amp;quot;SUNRPC: Don't allow waiting for exiting tasks&amp;quot;
  (git-fixes).
- commit f25412a

- flexfiles/pNFS: fix NULL checks on result of
  ff_layout_choose_ds_for_read (git-fixes).
- commit 43ddf37

- NFSv4: Clear the NFS_CAP_XATTR flag if not supported by the
  server (git-fixes).
- commit da99754

- NFSv4: Clear the NFS_CAP_FS_LOCATIONS flag if it is not set
  (git-fixes).
- commit 0b05e92

- NFSv4: Don't clear capabilities that won't be reset (git-fixes).
- commit f31092e

- nilfs2: fix CFI failure when accessing /sys/fs/nilfs2/features/*
  (git-fixes).
- commit 4438737

- mmc: mvsdio: Fix dma_unmap_sg() nents value (git-fixes).
- crypto: af_alg - Set merge to zero early in af_alg_sendmsg
  (git-fixes).
- ASoC: qcom: q6apm-lpass-dais: Fix missing set_fmt DAI op for
  I2S (git-fixes).
- ASoC: qcom: audioreach: Fix lpaif_type configuration for the
  I2S interface (git-fixes).
- ASoC: qcom: q6apm-lpass-dais: Fix NULL pointer dereference if
  source graph failed (git-fixes).
- ASoC: wm8974: Correct PLL rate rounding (git-fixes).
- ASoC: wm8940: Correct typo in control name (git-fixes).
- ASoC: wm8940: Correct PLL rate rounding (git-fixes).
- ASoC: SOF: Intel: hda-stream: Fix incorrect variable used in
  error message (git-fixes).
- ALSA: hda: intel-dsp-config: Prevent SEGFAULT if ACPI_HANDLE()
  is NULL (git-fixes).
- ALSA: hda/realtek: Add ALC295 Dell TAS2781 I2C fixup
  (git-fixes).
- drm: bridge: cdns-mhdp8546: Fix missing mutex unlock on error
  path (git-fixes).
- drm: bridge: anx7625: Fix NULL pointer dereference with early
  IRQ (git-fixes).
- USB: serial: option: add Telit Cinterion LE910C4-WWX new
  compositions (stable-fixes).
- USB: serial: option: add Telit Cinterion FN990A w/audio
  compositions (stable-fixes).
- Input: i8042 - add TUXEDO InfinityBook Pro Gen10 AMD to i8042
  quirk table (stable-fixes).
- Input: iqs7222 - avoid enabling unused interrupts
  (stable-fixes).
- drm/amdgpu/vcn: Allow limiting ctx to instance 0 for AV1 at
  any time (stable-fixes).
- drm/amdgpu/vcn4: Fix IB parsing with multiple engine info
  packages (stable-fixes).
- mtd: nand: raw: atmel: Respect tAR, tCLR in read setup timing
  (git-fixes).
- compiler-clang.h: define __SANITIZE_*__ macros only when
  undefined (stable-fixes).
- i2c: i801: Hide Intel Birch Stream SoC TCO WDT (git-fixes).
- mtd: nand: raw: atmel: Fix comment in timings preparation
  (stable-fixes).
- commit 60c59ef

- Drop arm64 patches that may lead to module load failure (bsc#1250057)
  Deleted:
  patches.suse/arm64-ftrace-fix-unreachable-PLT-for-ftrace_caller-in-init.patch
  patches.kabi/kABI-arm64-ftrace-Restore-struct-mod_arch_specific-l.patch
- commit 2621bab

- xfs: rework datasync tracking and execution (bsc#1237449).
- xfs: rearrange code in xfs_inode_item_precommit (bsc#1237449).
- commit 730f72c

- habanalabs: fix UAF in export_dmabuf() (CVE-2025-38722
  bsc#1249163).
- commit 5507c4a

- net: bridge: fix soft lockup in br_multicast_query_expired()
  (CVE-2025-39773 bsc#1249504).
- commit 8e6b9c2

- cgroup: remove cgroup_rstat_flush_atomic() (bsc#1247963).
- commit 45cbf76

- io_uring/net: commit partial buffers on retry (CVE-2025-38730
  bsc#1249172).
- commit 7b5fe24

- selftests/bpf: adapt one more case in test_lru_map to the new
  target_free (git-fixes).
- commit 951807c

- Correct typos of References tags in some patches
- commit 183c46e

- selftests/bpf: Add asserts for netfilter link info (git-fixes).
- commit 443e26f

- bpf: Fix link info netfilter flags to populate defrag flag
  (git-fixes).
- commit d659929

- bpf: Adjust free target to avoid global starvation of LRU map
  (git-fixes).
- commit a87821b

- bpftool: Fix memory leak in dump_xx_nlmsg on realloc failure
  (git-fixes).
- commit fc9c396

- struct l2cap_chan: shift new member rx_avail to end (git-fixes).
- commit df4a4b8

- Bluetooth: compute LE flow credits based on recvbuf space
  (git-fixes).
- Refresh patches.suse/Bluetooth-L2CAP-Fix-deadlock.patch.
- Refresh
  patches.suse/bluetooth-l2cap-sync-sock-recv-cb-and-release.patch.
- commit 89343db

- ppp: fix race conditions in ppp_fill_forward_path
  (CVE-2025-39673 bsc#1249320).
- commit ab5f3b1

- drm/amd/pm: fix null pointer access (CVE-2025-38705
  bsc#1249334).
- commit b78844e

- vsock/virtio: Validate length in packet header before skb_put()
  (CVE-2025-39718 bsc#1249305).
- commit 8072632

- arm64: ftrace: fix unreachable PLT for ftrace_caller in init_module (git-fixes)
- commit 420c073

- Bluetooth: qca: fix wcn3991 device address check (git-fixes).
- commit 9189126

- Bluetooth: qca: fix invalid device address check (git-fixes).
- commit 0795907

- wifi: ath10k: shutdown driver when hardware is unreliable
  (CVE-2025-39746 bsc#1249516).
- commit b5556c6

- cpufreq: CPPC: Mark driver with NEED_UPDATE_LIMITS flag
  (stable-fixes).
- commit 9a8a959

- cpufreq: Exit governor when failed to start old governor
  (stable-fixes).
- commit 39287fb

- cpufreq: Init policy-&amp;gt;rwsem before it may be possibly used
  (git-fixes).
- commit 04861e7

- cpufreq: Initialize cpufreq-based frequency-invariance later
  (git-fixes).
- commit ed31199

- cpufreq: intel_pstate: Always use HWP_DESIRED_PERF in passive
  mode (git-fixes).
- commit 723f0f4

- cpufreq: intel_pstate: Unchecked MSR aceess in legacy mode
  (git-fixes).
- commit 662764f

- cpufreq: cppc: Fix invalid return value in .get() callback
  (git-fixes).
- commit 6fc7d2a

- drm/amd/display: fix a Null pointer dereference vulnerability (bsc#1249295 CVE-2025-39705)
- commit fd61b4f

- pptp: fix pptp_xmit() error path (git-fixes).
- commit 91ca931

- net, hsr: reject HSR frame if skb can't hold tag (CVE-2025-39703
  bsc#1249315).
- netfilter: ctnetlink: fix refcount leak on table dump
  (CVE-2025-38721 bsc#1249176).
- pptp: ensure minimal skb length in pptp_xmit() (CVE-2025-38574
  bsc#1248365).
- commit a50f469

- media: venus: Fix OOB read due to missing payload bound check
  (CVE-2025-38679 bsc#1249202).
- commit 8b1060a

- platform/x86/amd/hsmp: Ensure sock-&amp;gt;metric_tbl_addr is non-NULL
  (CVE-2025-39678 bsc#1249290).
- commit d0b499a

- drivers/base/node: rename __register_one_node() to
  register_one_node() (bsc#1241866).
- commit 806b51c

- drivers/base/node: rename register_memory_blocks_under_node()
  and remove context argument (bsc#1241866).
- commit 9ef69ed

- drivers/base/node: remove register_memory_blocks_under_node()
  function call from register_one_node (bsc#1241866).
- commit 2f00393

- drivers/base/node: remove register_mem_block_under_node_early()
  (bsc#1241866).
- commit 02a1a4a

- drivers/base/node: optimize memory block registration to reduce
  boot time (bsc#1241866).
- commit 3a0dd5e

- cpufreq: scpi: compare kHz instead of Hz (git-fixes).
- commit bd20bfa

- cpufreq: governor: Fix negative 'idle_time' handling in
  dbs_update() (git-fixes).
- commit 7fc2c58

- cpufreq: Use the fixed and coherent frequency for scaling
  capacity (stable-fixes).
- commit 573ea38

- power: supply: bq27xxx: restrict no-battery detection to bq27000
  (git-fixes).
- power: supply: bq27xxx: fix error return in case of no bq27000
  hdq battery (git-fixes).
- commit 7d4436e

- kABI: arm64: ftrace: Restore struct mod_arch_specific layout (git-fixes).
- commit 7f84dae

- arm64: dts: rockchip: Add vcc-supply to SPI flash on (git-fixes)
- commit 06d6c63

- arm64: dts: imx8mp: Fix missing microSD slot vqmmc on Data Modul (git-fixes)
- commit d3f6628

- arm64: dts: imx8mp: Fix missing microSD slot vqmmc on DH electronics (git-fixes)
- commit faa58e2

- arm64: dts: imx8mp-tqma8mpql: fix LDO5 power off (git-fixes)
- commit 775e3f7

- arm64: Mark kernel as tainted on SAE and SError panic (git-fixes)
- commit 833fcf1

- arm64: Handle KCOV __init vs inline mismatches (git-fixes)
- commit 187b48f

- arm64: dts: rockchip: use cs-gpios for spi1 on ringneck (git-fixes)
- commit 8c45279

- arm64: dts: rockchip: disable unrouted USB controllers and PHY on RK3399 Puma with Haikou (git-fixes).
- commit 5a86595

- arm64: dts: rockchip: disable unrouted USB controllers and PHY on (git-fixes)
- commit 655bf48

- arm64: dts: rockchip: fix internal USB hub instability on RK3399 Puma (git-fixes)
- commit d929ee1

- i2c: tegra: Use internal reset when reset property is not available (bsc#1249143)
- commit 7b11853

- tls: fix handling of zero-length records on the rx_list
  (CVE-2025-39682 bsc#1249284).
- commit 409e98c

- kABI workaround for &amp;quot;drm/dp: Add an EDID quirk for the DPCD
  register access probe&amp;quot; (bsc#1248121).
- commit 6cdcefb

- drm/amd/display: Disable DPCD Probe Quirk (bsc#1248121).
- commit 617e84a

- drm/dp: Add an EDID quirk for the DPCD register access probe
  (bsc#1248121).
- Refresh
  patches.suse/drm-Add-kabi-placeholders-to-commonly-used-structs.patch.
- commit db9d8ac

- drm/edid: Add support for quirks visible to DRM core and drivers
  (bsc#1248121).
- drm/edid: Define the quirks in an enum list (bsc#1248121).
- commit bc5a858

- drm/dp: Change AUX DPCD probe address from LANE0_1_STATUS to
  TRAINING_PATTERN_SET (bsc#1248121).
- commit 36a72f9

- Update patches.suse/drm-dp-Change-AUX-DPCD-probe-address-from-DPCD_REV-t.patch (bsc#1248121)
  Move to the cherry-picked 6.16-rc patch, to be applied earlier
- commit 49f20a1

- netfilter: nf_tables: reject duplicate device on updates
  (CVE-2025-38678 bsc#1249126).
- commit 8b40732

- Limit patch filenames to 100 characters (bsc#1249604).
- commit 8a17cff

- iommu/amd: Avoid stack buffer overflow from kernel cmdline
  (CVE-2025-38676 bsc#1248775).
- commit eddb6c4

- phy: ti-pipe3: fix device leak at unbind (git-fixes).
- phy: tegra: xusb: fix device and OF node leak at probe
  (git-fixes).
- dmaengine: dw: dmamux: Fix device reference leak in
  rzn1_dmamux_route_allocate (git-fixes).
- dmaengine: ti: edma: Fix memory allocation size for
  queue_priority_map (git-fixes).
- dmaengine: idxd: Fix double free in idxd_setup_wqs()
  (git-fixes).
- dmaengine: idxd: Fix refcount underflow on module unload
  (git-fixes).
- dmaengine: idxd: Remove improper idxd_free (git-fixes).
- dmaengine: qcom: bam_dma: Fix DT error handling for
  num-channels/ees (git-fixes).
- serial: sc16is7xx: fix bug in flow control levels init
  (git-fixes).
- USB: gadget: dummy-hcd: Fix locking bug in RT-enabled kernels
  (git-fixes).
- xhci: fix memory leak regression when freeing xhci vdev devices
  depth first (git-fixes).
- xhci: dbc: Fix full DbC transfer ring after several reconnects
  (git-fixes).
- commit 517a9a9

- regulator: sy7636a: fix lifecycle of power good gpio
  (git-fixes).
- commit 519b81c

- struct cdc_ncm_ctx: hide new member filtering_supported
  (git-fixes).
- commit 1152814

- drm/amdgpu: fix a memory leak in fence cleanup when unloading
  (git-fixes).
- drm/i915/power: fix size for for_each_set_bit() in abox
  iteration (git-fixes).
- commit 48c87c2

- drm/mediatek: fix potential OF node use-after-free (git-fixes).
- drm/amd/display: use udelay rather than fsleep (git-fixes).
- commit 9e6eea4

- net: usb: qmi_wwan: add Telit Cinterion LE910C4-WWX new
  compositions (git-fixes).
- net: usb: cdc-ncm: check for filtering capability (git-fixes).
- commit ce04178

- cgroup/cpuset: Use static_branch_enable_cpuslocked() on
  cpusets_insane_config_key (bsc#1241166).
- commit 414381b

- s390/vfio-ap: Fix no AP queue sharing allowed message written
  to kernel log (git-fixes bsc#1249488).
- commit e007691

- s390/cpum_cf: Deny all sampling events by counter PMU (git-fixes
  bsc#1249481).
- s390/pai: Deny all events not handled by this PMU (git-fixes
  bsc#1249482).
- commit 85f3e91

- mtd: rawnand: stm32_fmc2: fix ECC overwrite (git-fixes).
- mtd: rawnand: stm32_fmc2: avoid overlapping mappings on ECC
  buffer (git-fixes).
- can: xilinx_can: xcan_write_frame(): fix use-after-free of
  transmitted SKB (git-fixes).
- can: j1939: j1939_local_ecu_get(): undo increment when
  j1939_local_ecu_get() fails (git-fixes).
- can: j1939: j1939_sk_bind(): call j1939_priv_put() immediately
  when j1939_local_ecu_get() failed (git-fixes).
- can: j1939: implement NETDEV_UNREGISTER notification handler
  (git-fixes).
- commit ab68e9b

- net/mlx5e: Remove skb secpath if xfrm state is not found (CVE-2025-38590 bsc#1248360)
- commit ed11350

- rcu-tasks: Maintain real-time response in (bsc#1246298)
- commit 1fbb6ff

- rcu-tasks: Eliminate deadlocks involving do_exit() and RCU (bsc#1246298)
- commit 61288e7

- smb: client: fix use-after-free in cifs_oplock_break
  (bsc#1248199, CVE-2025-38527).
- commit 4692a87

- supported.conf: mark hyperv_drm as external
- net: hv_netvsc: fix loss of early receive events from host
  during channel open (git-fixes).
- hv_netvsc: Fix panic during namespace deletion with VF
  (bsc#1248111).
- hv_netvsc: Set VF priv_flags to IFF_NO_ADDRCONF before open
  to prevent IPv6 addrconf (git-fixes).
- commit 2985c60

- Drop PCI patches that broke kdump capture boot (bsc#1246509)
  Deleted:
  patches.suse/PCI-Explicitly-put-devices-into-D0-when-initializing.patch
  patches.suse/PCI-PM-Set-up-runtime-PM-even-for-devices-without-PC.patch
  Refreshed:
  patches.suse/PCI-Support-Immediate-Readiness-on-devices-without-PM.patch
- commit 70a44f4

- netfilter: nf_tables: split async and sync catchall in two
  functions (git-fixes).
- Refresh
  patches.kabi/kABI-make-nft_trans_gc_catchall-public-again.patch.
- commit b907ff6

- netfilter: nf_tables: Fix entries val in rule reset audit log
  (git-fixes).
- commit a8ae150

- platform/x86/amd/pmc: Add TUXEDO IB Pro Gen10 AMD to spurious
  8042 quirks list (stable-fixes).
- drm/amdgpu: drop hw access in non-DC audio fini (stable-fixes).
- drm/amd/display: Don't warn when missing DCE encoder caps
  (stable-fixes).
- commit 2aad2ce

- ALSA: hda/hdmi: Add pin fix for another HP EliteDesk 800 G4
  model (stable-fixes).
- ALSA: hda/realtek: Fix headset mic for TongFang X6[AF]R5xxY
  (stable-fixes).
- ALSA: usb-audio: Add mute TLV for playback volumes on some
  devices (stable-fixes).
- cpupower: Fix a bug where the -t option of the set subcommand
  was not working (stable-fixes).
- cdc_ncm: Flag Intel OEM version of Fibocom L850-GL as WWAN
  (stable-fixes).
- Bluetooth: hci_sync: Avoid adding default advertising on startup
  (stable-fixes).
- commit 3580eab

- ALSA: hda/realtek - Add new HP ZBook laptop with micmute led
  fixup (stable-fixes).
- commit 0d08638

- ALSA: hda/realtek: Add support for HP Agusta using CS35L41 HDA
  (stable-fixes).
- commit 33271d8

- bpf, bpftool: Fix incorrect disasm pc (git-fixes).
- commit 4188abf

- bpf: bpftool: Setting error code in do_loader() (git-fixes).
- commit 6283bbf

- bpftool: Fix readlink usage in get_fd_type (git-fixes).
- commit ae9652c

- bpftool: fix potential NULL pointer dereferencing in prog_dump()
  (git-fixes).
- commit 171c943

- bpftool: Mount bpffs when pinmaps path not under the bpffs
  (git-fixes).
- commit fb91e0e

- x86/amd_nb: Restrict init function to AMD-based systems (git-fixes).
- commit f7e4409

- x86/rdrand: Disable RDSEED on AMD Cyan Skillfish (git-fixes).
- commit a5e740f

- x86/fpu: Delay instruction pointer fixup until after warning (git-fixes).
- commit 6c7016a

- x86/microcode/AMD: Handle the case of no BIOS microcode (git-fixes).
- commit 8f2342d

- kernel-subpackage-build: Decompress ghost file when compressed version exists (bsc#1249346)
- commit 40606b5

- kABI workaround for RCU tasks exit tracking (bsc#1246298).
- commit 90e8606

- btrfs: always update fstrim_range on failure in FITRIM ioctl
  (git-fixes).
- commit 8b0d717

- netfilter: nf_tables: remove catchall element in GC sync path
  (git-fixes).
- Refresh
  patches.kabi/kABI-make-nft_trans_gc_catchall-public-again.patch.
- commit 6c470e7

- netfilter: nf_tables: revert do not remove elements if set
  backend implements .abort (git-fixes).
- commit 54e2e34

- netfilter: nf_tables: Unbreak audit log reset (git-fixes).
- commit 1d98f3d

- net/mlx5: Check device memory pointer before usage
  (CVE-2025-38645 bsc#1248626).
- commit 1353943

- x86/Kconfig: Always enable ARCH_SPARSEMEM_ENABLE (git-fixes).
- commit 74f5e8a

- ceph: validate snapdirname option length when mounting (git-fixes).
- commit 3370873

- ceph: fix possible integer overflow in ceph_zero_objects() (git-fixes).
- commit 096933b

- x86/CPU/AMD: WARN when setting EFER.AUTOIBRS if and only if the WRMSR  fails (git-fixes).
- commit 1d1b06c

- btrfs: add cancellation points to trim loops (git-fixes).
- btrfs: split remaining space to discard in chunks (git-fixes).
- btrfs: use SECTOR_SHIFT to convert physical offset to LBA
  (git-fixes).
- commit 6bf77bf

- mm/memory-failure: fix infinite UCE for VM_PFNMAP pfn
  (git-fixes).
- commit 6e9d9d9

- mm/hwpoison: do not send SIGBUS to processes with recovered
  clean pages (git-fixes).
- commit 34ad618

- xen: fix UAF in dmabuf_exp_from_pages() (CVE-2025-38595
  bsc#1248380).
- commit 00fd621

- selftests/bpf: Add test cases with CONST_PTR_TO_MAP null checks
  (git-fixes).
- selftests/bpf: Add cmp_map_pointer_with_const test (git-fixes).
- bpf: Make reg_not_null() true for CONST_PTR_TO_MAP (git-fixes).
- commit d187572

- PCI: pnv_php: Fix surprise plug detection and recovery
  (CVE-2025-38623 bsc#1248610).
- commit e872ea6

- file: add take_fd() cleanup helper (CVE-2025-38595 bsc#1248380).
- commit 7ffa1d7

- drm/rockchip: vop2: fail cleanly if missing a primary plane
  for a video-port (CVE-2025-38597 bsc#1248378).
- commit 7f132df

- bpf: Disable migration in nf_hook_run_bpf() (bsc#1248622
  CVE-2025-38640).
- commit b485f08

- btrfs: avoid load/store tearing races when checking if an
  inode was logged (git-fixes).
- commit 60df77c

- btrfs: fix race between setting last_dir_index_offset and
  inode logging (git-fixes).
- commit 9120538

- btrfs: fix race between logging inode and checking if it was
  logged before (git-fixes).
- commit 84758cf

- btrfs: always abort transaction on failure to add block group
  to free space tree (git-fixes).
- commit 55788e0

- btrfs: move transaction aborts to the error site in
  add_block_group_free_space() (git-fixes).
- commit 1bba414

- btrfs: abort transaction on unexpected eb generation at
  btrfs_copy_root() (git-fixes).
- commit 47cbfed

- isolcpus: add missing hunk back (bsc#1236897 bsc#1249206).
  Update
  patches.suse/blk-mq-use-hk-cpus-only-when-isolcpus-managed_irq-is.patch
  (bsc#1236897 bsc#1249206).
- commit d06c033

- btrfs: qgroup: fix race between quota disable and quota rescan
  ioctl (git-fixes).
- commit 6ecd72c

- btrfs: abort transaction during log replay if walk_log_tree()
  failed (git-fixes).
- commit 9ed0531

- netfilter: nf_tables: bogus ENOENT when destroying element
  which does not exist (git-fixes).
- commit 1720cdf

- netfilter: nf_conntrack_bridge: initialize err to 0 (git-fixes).
- commit 37ed3f8

- netfilter: nat: fix ipv6 nat redirect with mapped and scoped
  addresses (git-fixes).
- commit dc55ccf

- netfilter: xt_recent: fix (increase) ipv6 literal buffer length
  (git-fixes).
- commit 9b71437

- netfilter: nf_tables: Carry reset boolean in nft_obj_dump_ctx
  (git-fixes).
- commit 1837d60

- netfilter: nf_tables: nft_obj_filter fits into cb-&amp;gt;ctx
  (git-fixes).
- commit 7ebf747

- netfilter: nf_tables: Carry s_idx in nft_obj_dump_ctx
  (git-fixes).
- commit 94eb28c

- netfilter: nf_tables: A better name for nft_obj_filter
  (git-fixes).
- commit 4e97e28

- netfilter: nf_tables: Unconditionally allocate nft_obj_filter
  (git-fixes).
- commit 71527ef

- netfilter: nf_tables: Drop pointless memset in
  nf_tables_dump_obj (git-fixes).
- commit 457aebd

- netfilter: nf_tables: Introduce nf_tables_getrule_single()
  (git-fixes).
- commit 1f75537

- netfilter: xt_nfacct: don't assume acct name is null-terminated (CVE-2025-38639 bsc#1248674)
- commit e51b72e

- netfilter: nf_tables: Open-code audit log call in
  nf_tables_getrule() (git-fixes).
- commit 05444c9

- netfilter: nft_set_rbtree: prefer sync gc to async worker
  (git-fixes).
- commit 3892bab

- netfilter: nft_set_rbtree: rename gc deactivate+erase function
  (git-fixes).
- commit ee5de41

- netfilter: nf_tables: Drop pointless memset when dumping rules
  (git-fixes).
- commit 9da7ab8

- kABI: netfilter flowtable move gc operation to bottom
  (git-fixes).
- commit 81690ca

- netfilter: flowtable: GC pushes back packets to classic path
  (git-fixes).
- commit 6e4c347

- Update config files. (bsc#1249186)
  Plain run_oldconfig after Kconfig update.
- commit 9d7abe4

- Refresh
  patches.suse/kernel-add-product-identifying-information-to-kernel-build.patch. (bsc#1249186)
- commit 99400d5

- x86/mm/64: define ARCH_PAGE_TABLE_SYNC_MASK and
  arch_sync_kernel_mappings() (git-fixes).
- commit 79df6a3

- mm: introduce and use {pgd,p4d}_populate_kernel() (git-fixes).
- commit b0342dd

- netfilter: nf_tables: audit log object reset once per table
  (git-fixes).
- commit fd6322c

- netfilter: nft_payload: fix wrong mac header matching
  (git-fixes).
- commit d699ba5

- netfilter: nfnetlink_log: silence bogus compiler warning
  (git-fixes).
- commit f57923e

- mm: move page table sync declarations to linux/pgtable.h
  (git-fixes).
- commit 1222abb

- netfilter: nf_tables: do not remove elements if set backend
  implements .abort (git-fixes).
- commit 19ebcee

- netfilter: nf_tables: Deduplicate nft_register_obj audit logs
  (git-fixes).
- commit 649bcef

- kABI workaround for bluetooth discovery_state change
  (CVE-2025-38593 bsc#1248357).
- commit a2afff6

- Bluetooth: hci_sync: fix double free in
  'hci_discovery_filter_clear()' (CVE-2025-38593 bsc#1248357).
- Refresh patches.kabi/bluetooth-hci_dev-kabi-workaround.patch.
- commit c998281

- nouveau: fix disabling the nonstall irq due to storm code
  (git-fixes).
- commit 476894d

- spi: spi-fsl-lpspi: Reset FIFO and disable module on transfer
  abort (git-fixes).
- spi: spi-fsl-lpspi: Set correct chip-select polarity bit
  (git-fixes).
- spi: spi-fsl-lpspi: Fix transmissions when using CONT
  (git-fixes).
- ACPI/IORT: Fix memory leak in iort_rmr_alloc_sids() (git-fixes).
- hwmon: mlxreg-fan: Prevent fans from getting stuck at 0 RPM
  (git-fixes).
- drm/amd/amdgpu: Fix missing error return on kzalloc failure
  (git-fixes).
- drm/bridge: ti-sn65dsi86: fix REFCLK setting (git-fixes).
- pcmcia: Add error handling for add_interval() in
  do_validate_mem() (git-fixes).
- pcmcia: omap: Add missing check for platform_get_resource
  (git-fixes).
- pcmcia: Fix a NULL pointer dereference in
  __iodyn_find_io_region() (git-fixes).
- commit 2aa7ff8

- Update config files: CONFIG_SUSE_HAVE_STABLE_KABI=n for arm64/debug flavor
- commit 7319322

- erofs: fix atomic context detection when
  !CONFIG_DEBUG_LOCK_ALLOC (git-fixes).
- commit 8bbba66

- net: drop UFO packets in udp_rcv_segment() (CVE-2025-38622
  bsc#1248619).
- commit b74a30a

- kABI: adjust new field on ip_ct_sctp struct (git-fixes).
- commit b932c6f

- netfilter: handle the connecting collision properly in
  nf_conntrack_proto_sctp (git-fixes).
- commit 935c934

- smb: client: fix use-after-free in crypt_message when using
  async crypto (bsc#1247239, CVE-2025-38488).
- commit 4fd2db6

- HID: input: report battery status changes immediately
  (git-fixes).
- HID: input: rename hidinput_set_battery_charge_status()
  (stable-fixes).
- commit c8518b5

- wifi: ath12k: Pass ab pointer directly to
  ath12k_dp_tx_get_encap_type() (CVE-2025-38605 bsc#1248334).
- regulator: core: fix NULL dereference on unbind due to stale
  coupling data (CVE-2025-38668 bsc#1248647).
- commit 684e871

- wifi: ath11k: fix group data packet drops during rekey
  (git-fixes).
- commit 8f7f429

- ax25: properly unshare skbs in ax25_kiss_rcv() (git-fixes).
- wifi: cfg80211: sme: cap SSID length in
  __cfg80211_connect_result() (git-fixes).
- wifi: libertas: cap SSID len in lbs_associate() (git-fixes).
- wifi: cw1200: cap SSID length in cw1200_do_join() (git-fixes).
- batman-adv: fix OOB read/write in network-coding decode
  (git-fixes).
- Bluetooth: Fix use-after-free in l2cap_sock_cleanup_listen()
  (git-fixes).
- Bluetooth: vhci: Prevent use-after-free by removing debugfs
  files early (git-fixes).
- mISDN: Fix memory leak in dsp_hwec_enable() (git-fixes).
- xirc2ps_cs: fix register access when enabling FullDuplex
  (git-fixes).
- wifi: iwlwifi: uefi: check DSM item validity (git-fixes).
- wifi: mt76: mt7996: Initialize hdr before passing to
  skb_put_data() (git-fixes).
- wifi: mwifiex: Initialize the chan_stats array to zero
  (git-fixes).
- wifi: brcmfmac: fix use-after-free when rescheduling
  brcmf_btcoex_info work (git-fixes).
- wifi: cfg80211: fix use-after-free in cmp_bss() (git-fixes).
- HID: quirks: add support for Legion Go dual dinput modes
  (stable-fixes).
- HID: hid-ntrig: fix unable to handle page fault in
  ntrig_report_version() (stable-fixes).
- HID: wacom: Add a new Art Pen 2 (stable-fixes).
- Revert &amp;quot;drm/amdgpu: fix incorrect vm flags to map bo&amp;quot;
  (stable-fixes).
- net: rose: fix a typo in rose_clear_routes() (git-fixes).
- net: rose: include node references in rose_neigh refcount
  (git-fixes).
- net: rose: convert 'use' field to refcount_t (git-fixes).
- net: rose: split remove and free operations in
  rose_remove_neigh() (stable-fixes).
- dma/pool: Ensure DMA_DIRECT_REMAP allocations are decrypted
  (stable-fixes).
- ASoC: codecs: tx-macro: correct tx_macro_component_drv name
  (stable-fixes).
- ACPI: EC: Add device to acpi_ec_no_wakeup[] qurik list
  (stable-fixes).
- HID: mcp2221: Handle reads greater than 60 bytes (stable-fixes).
- HID: mcp2221: Don't set bus speed on every transfer
  (stable-fixes).
- commit c45df83

- perf: Revert to requiring CAP_SYS_ADMIN for uprobes (bsc#1247442
  CVE-2025-38466).
- commit 6200f52

- bpf: Properly test iter/task tid filtering (git-fixes).
- commit 7cae248

- bpf: Fix iter/task tid filtering (git-fixes).
- commit 51eef98

- wifi: cfg80211: Add missing lock in cfg80211_check_and_end_cac() (CVE-2025-38643 bsc#1248681)
- commit 913bce0

- netfilter: conntrack: fix extension size table (git-fixes).
- commit 3a3ec96

- netfilter: nf_tables: disallow element removal on anonymous sets
  (git-fixes).
- commit ed5fdf4

- netfilter: nft_set_hash: try later when GC hits EAGAIN on
  iteration (git-fixes).
- commit 1044906

- netfilter: nft_set_pipapo: stop GC iteration if GC transaction
  allocation fails (git-fixes).
- commit 102d93f

- kABI: make nft_trans_gc_catchall() public again (git-fixes).
- commit a176bb1

- netfilter: nft_set_pipapo: call nft_trans_gc_queue_sync()
  in catchall GC (git-fixes).
- commit d64bf79

- kABI fix for &amp;quot;netfilter: nf_tables: Audit log rule reset&amp;quot;
  (git-fixes).
- commit 5173417

- netfilter: nf_tables: Audit log rule reset (git-fixes).
- commit f27562f

- [ceph] parse_longname(): strrchr() expects NUL-terminated string
  (bsc#1248634 CVE-2025-38660).
- commit cc1fe76

- s390/sclp: Fix SCCB present check (git-fixes bsc#1249123).
- s390/time: Use monotonic clock in get_cycles() (git-fixes
  bsc#1249125).
- s390/stp: Remove udelay from stp_sync_clock() (git-fixes
  bsc#1249124).
- hypfs_create_cpu_files(): add missing check for hypfs_mkdir()
  failure (git-fixes bsc#1249122).
- commit a699d99

- Refresh
  patches.kabi/kabi-s390-ism-fix-concurrency-management-in-ism_cmd.patch.
- commit e8175f3

- ext4: remove writable userspace mappings before truncating
  page cache (bsc#1247223).
- commit afc4afd

- rpm: Configure KABI checkingness macro (bsc#1249186)
  The value of the config should match presence of KABI reference data. If
  it mismatches:
- !CONFIG &amp;amp; reference  -&amp;gt; this is bug, immediate fail
- CONFIG &amp;amp; no reference -&amp;gt; OK temporarily, must be resolved eventually
- commit 23c1536

- Kconfig.suse: Add KABI checkiness macro (config) (bsc#1249186)
  The motivation: there are patches.kabi/ patches that restore KABI and
  they check validity of the approach with static_assert()s to prevent
  accidental KABI breakage.
  These asserts are invoked on each arch-flavor and they may signal false
  negatives -- that is KABI restoration patch could break KABI but the
  given arch-flavor defines no KABI.
  The intended use is to disable the compile time checks in patches.kabi/
  (but not to be confused with __GENKSYMS__ that affects how reference is
  calculated).
  The name is chosen so that it mimics HAVE_* macros that are not
  configured manually (but is selected by an arch). In our case it's
  (un)selected by build script depending on whether KABI reference is
  defined for given arch-flavor and whether check is really requested by
  the user. Default value is 'n' so that people building merely via
  Makefile (not RPM with KABI checking) obtain consistent config.
- commit 5e4e9c5

- s390/pci: Allow automatic recovery with minimal driver support
  (git-fixes bsc#1248734 LTC#214880).
- commit 3fdd470

- btrfs: fix data overwriting bug during buffered write when
  block size &amp;lt; page size (git-fixes).
- commit d006c37

- btrfs: make found_logical_ret parameter mandatory for  function
  queue_scrub_stripe() (git-fixes).
- commit da7f7f5

- btrfs: scrub: fix grouping of read IO (git-fixes).
- commit bd555d2

- btrfs: scrub: avoid unnecessary csum tree search  preparing
  stripes (git-fixes).
- commit d485678

- btrfs: scrub: avoid unnecessary extent tree search  preparing
  stripes (git-fixes).
- commit a00c933

- btrfs: scrub: remove scrub_ctx::csum_list member (git-fixes).
- commit fa7dbad

- gfs2: No more self recovery (bsc#1248639 CVE-2025-38659).
- gfs2: Get rid of gfs2_glock_queue_put in signal_our_withdraw
  (bsc#1248639 CVE-2025-38659).
- commit bdb1b5c

- s390/ism: fix concurrency management in ism_cmd() (git-fixes
  bsc#1248735).
- commit 1005186

- usb: xhci: Apply the link chain quirk on NEC isoc endpoints
  (CVE-2025-22022 bsc#1241292).
- commit 8a5182c

- usb: xhci: move link chain bit quirk checks into one helper
  function (CVE-2025-22022 bsc#1241292).
- commit 4cca94b

- nvme-pci: try function level reset on init failure (git-fixes).
- commit 1ee35d9

- ice: Fix a null pointer dereference in ice_copy_and_init_pkg()
  (CVE-2025-38664 bsc#1248628).
- commit 7e27b08

- s390/hypfs: Enable limited access during lockdown (git-fixes
  bsc#1248733 LTC#214881).
- s390/hypfs: Avoid unnecessary ioctl registration in debugfs
  (git-fixes bsc#1248733 LTC#214881).
- commit 97ff25b

- HID: core: Harden s32ton() against conversion to 0 bits (CVE-2025-38556 bsc#1248296)
- commit 1097818

- rxrpc: Fix bug due to prealloc collision (CVE-2025-38544 bsc#1248225)
- commit bc50a3d

- net: libwx: fix the using of Rx buffer DMA (CVE-2025-38533 bsc#1248200)
- commit 8863383

- ice: add NULL check in eswitch lag check (CVE-2025-38526 bsc#1248192)
- commit 7ad8c40

- rxrpc: Fix oops due to non-existence of prealloc backlog struct (CVE-2025-38514 bsc#1248202)
- commit 4ea1963

- idpf: return 0 size for RSS key if not supported (CVE-2025-38402 bsc#1247262)
- commit 1ca20ce

- remoteproc: core: Release rproc-&amp;gt;clean_table after rproc_attach() fails (CVE-2025-38418 bsc#1247137)
- commit 14c64f1

- remoteproc: core: Cleanup acquired resources when rproc_handle_resources() fails in rproc_attach() (CVE-2025-38419 bsc#1247136)
- commit 7e69a49

- genirq/irq_sim: Initialize work context pointers properly (CVE-2025-38408 bsc#1247126)
- commit a8d685c

- ipmi:msghandler: Fix potential memory corruption in ipmi_create_user() (CVE-2025-38456 bsc#1247099)
- commit 8a59cf2

- bcache: fix NULL pointer in cache_set_flush() (CVE-2025-38263 bsc#1246248)
- commit d6d8f29

- Update reference in patches.suse/lib-group_cpus-fix-NULL-pointer-dereference-from-gro.patch (CVE-2025-38255 bsc#1246190 bsc#1236897)
- commit 0bab045

- staging: media: atomisp: Fix stack buffer overflow in
  gmin_get_var_int() (CVE-2025-38585 bsc#1248355).
- commit f7d8b23

- vsock: Do not allow binding to VMADDR_PORT_ANY (bsc#1248511
  CVE-2025-38618).
- commit 0256bd0

- RDMA: hfi1: fix possible divide-by-zero in find_hw_thread_mask() (git-fixes)
- commit 5289b12

- RDMA/core: reduce stack using in nldev_stat_get_doit() (git-fixes)
- commit 1ff622a

- KVM: Allow CPU to reschedule while setting per-page memory
  attributes (bsc#1248186 CVE-2025-38506).
- commit a7f8a41

- slab: Decouple slab_debug and no_hash_pointers (bsc#1249022).
- commit 41f928f

- RAS/AMD/FMPM: Use atl internal.h for INVALID_SPA (bsc#1242034).
- commit ac5d9dc

- RAS/AMD/FMPM: Get masked address (bsc#1242034).
- commit 4171987

- RAS/AMD/ATL: Include row bit in row retirement (bsc#1242034).
- commit fa3fcbb

- Update
  patches.suse/Bluetooth-btnxpuart-Resolve-TX-timeout-error-in-powe.patch
  (bsc#1230557 CVE-2024-58238 bsc#1242754).
- Update
  patches.suse/HID-quirks-Add-quirk-for-2-Chicony-Electronics-HP-5M.patch
  (stable-fixes CVE-2025-38540 bsc#1248208).
- Update
  patches.suse/PCI-pnv_php-Clean-up-allocated-IRQs-on-unplug.patch
  (bsc#1215199 CVE-2025-38624 bsc#1248617).
- Update
  patches.suse/PM-devfreq-Check-governor-before-using-governor-name.patch
  (git-fixes CVE-2025-38609 bsc#1248337).
- Update
  patches.suse/RDMA-hns-Fix-double-destruction-of-rsv_qp.patch
  (git-fixes CVE-2025-38582 bsc#1248349).
- Update
  patches.suse/arm64-entry-Mask-DAIF-in-cpu_switch_to-call_on_irq_stack.patch
  (git-fixes CVE-2025-38670 bsc#1248655).
- Update
  patches.suse/btrfs-fix-assertion-when-building-free-space-tree.patch
  (git-fixes CVE-2025-38503 bsc#1248183).
- Update
  patches.suse/can-netlink-can_changelink-fix-NULL-pointer-deref-of.patch
  (git-fixes CVE-2025-38665 bsc#1248648).
- Update
  patches.suse/clk-davinci-Add-NULL-check-in-davinci_lpsc_clk_regis.patch
  (git-fixes CVE-2025-38635 bsc#1248573).
- Update
  patches.suse/clk-xilinx-vcu-unregister-pll_post-only-if-registere.patch
  (git-fixes CVE-2025-38583 bsc#1248350).
- Update
  patches.suse/comedi-aio_iiro_16-Fix-bit-shift-out-of-bounds.patch
  (git-fixes CVE-2025-38529 bsc#1248196).
- Update
  patches.suse/comedi-pcl812-Fix-bit-shift-out-of-bounds.patch
  (git-fixes CVE-2025-38530 bsc#1248206).
- Update
  patches.suse/crypto-ccp-Fix-crash-when-rebind-ccp-device-for-ccp..patch
  (git-fixes CVE-2025-38581 bsc#1248345).
- Update
  patches.suse/dmaengine-nbpfaxi-Fix-memory-corruption-in-probe.patch
  (git-fixes CVE-2025-38538 bsc#1248213).
- Update patches.suse/drm-amd-display-Fix-vs-typos.patch
  (git-fixes CVE-2024-26661 bsc#1222323).
- Update
  patches.suse/drm-sched-Increment-job-count-before-swapping-tail-s.patch
  (git-fixes CVE-2025-38515 bsc#1248212).
- Update
  patches.suse/drm-tegra-nvdec-Fix-dma_alloc_coherent-error-check.patch
  (git-fixes CVE-2025-38543 bsc#1248214).
- Update
  patches.suse/fbdev-imxfb-Check-fb_add_videomode-to-prevent-null-p.patch
  (git-fixes CVE-2025-38630 bsc#1248575).
- Update
  patches.suse/hfsplus-remove-mutex_lock-check-in-hfsplus_free_extents.patch
  (git-fixes CVE-2025-38650 bsc#1248746).
- Update
  patches.suse/hwmon-corsair-cpro-Validate-the-size-of-the-received.patch
  (git-fixes CVE-2025-38548 bsc#1248228).
- Update
  patches.suse/i2c-qup-jump-out-of-the-loop-in-case-of-timeout.patch
  (git-fixes CVE-2025-38671 bsc#1248652).
- Update
  patches.suse/ipv6-fix-possible-infinite-loop-in-fib6_info_uses_de.patch
  (git-fixes CVE-2025-38587 bsc#1248361).
- Update
  patches.suse/ipv6-mcast-Delay-put-pmc-idev-in-mld_del_delrec.patch
  (git-fixes CVE-2025-38550 bsc#1248227).
- Update
  patches.suse/ipv6-prevent-infinite-loop-in-rt6_nlmsg_size.patch
  (git-fixes CVE-2025-38588 bsc#1248368).
- Update
  patches.suse/ipv6-reject-malicious-packets-in-ipv6_gso_segment.patch
  (git-fixes CVE-2025-38572 bsc#1248399).
- Update
  patches.suse/iwlwifi-Add-missing-check-for-alloc_ordered_workqueu.patch
  (git-fixes CVE-2025-38602 bsc#1248341).
- Update
  patches.suse/kasan-remove-kasan_find_vm_area-to-prevent-possible-.patch
  (git-fixes CVE-2025-38510 bsc#1248166).
- Update
  patches.suse/ksmbd-fix-out-of-bounds-read-in-smb2_sess_setup.patch
  (bsc#1012628 bsc#1213545 CVE-2023-3867).
- Update
  patches.suse/ksmbd-fix-wrong-next-length-validation-of-ea-b.patch
  (bsc#1012628 CVE-2023-4130 bsc#1248164).
- Update patches.suse/ksmbd-validate-command-request-size.patch
  (bsc#1012628 CVE-2023-4515 bsc#1248180).
- Update
  patches.suse/md-make-rdev_addable-usable-for-rcu-mode.patch
  (git-fixes CVE-2025-38621 bsc#1248609).
- Update
  patches.suse/net-packet-fix-a-race-in-packet_set_ring-and-packet_.patch
  (git-fixes CVE-2025-38617 bsc#1248621).
- Update patches.suse/net-phy-Don-t-register-LEDs-for-genphy.patch
  (git-fixes CVE-2025-38537 bsc#1248229).
- Update
  patches.suse/net-sched-Restrict-conditions-for-adding-duplicating.patch
  (git-fixes CVE-2025-38553 bsc#1248255).
- Update
  patches.suse/net-sched-mqprio-fix-stack-out-of-bounds-write-in-tc.patch
  (git-fixes CVE-2025-38568 bsc#1248386).
- Update
  patches.suse/nilfs2-reject-invalid-file-types-when-reading-inodes.patch
  (git-fixes CVE-2025-38663 bsc#1248636).
- Update patches.suse/perf-core-Exit-early-on-perf_mmap-fail.patch
  (CVE-2025-38563 bsc#1248306 dependency CVE-2025-38565
  bsc#1248377).
- Update
  patches.suse/phy-tegra-xusb-Fix-unbalanced-regulator-disable-in-U.patch
  (git-fixes CVE-2025-38535 bsc#1248240).
- Update
  patches.suse/pinctrl-qcom-msm-mark-certain-pins-as-invalid-for-in.patch
  (git-fixes CVE-2025-38516 bsc#1248209).
- Update
  patches.suse/pinmux-fix-race-causing-mux_owner-NULL-with-active-m.patch
  (git-fixes CVE-2025-38632 bsc#1248669).
- Update
  patches.suse/power-supply-cpcap-charger-Fix-null-check-for-power_.patch
  (git-fixes CVE-2025-38634 bsc#1248666).
- Update
  patches.suse/powercap-dtpm_cpu-Fix-NULL-pointer-dereference-in-ge.patch
  (git-fixes CVE-2025-38610 bsc#1248395).
- Update
  patches.suse/powerpc-eeh-Make-EEH-driver-device-hotplug-safe.patch
  (bsc#1215199 CVE-2025-38576 bsc#1248354).
- Update
  patches.suse/staging-fbtft-fix-potential-memory-leak-in-fbtft_fra.patch
  (git-fixes CVE-2025-38612 bsc#1248390).
- Update
  patches.suse/sunrpc-fix-client-side-handling-of-tls-alerts.patch
  (git-fixes CVE-2025-38571 bsc#1248401).
- Update
  patches.suse/sunrpc-fix-handling-of-server-side-tls-alerts.patch
  (git-fixes CVE-2025-38566 bsc#1248374).
- Update
  patches.suse/tls-stop-recv-if-initial-process_rx_list-gave-us-non.patch
  (bsc#1221858 CVE-2024-58239 bsc#1248614).
- Update
  patches.suse/usb-gadget-fix-use-after-free-in-composite_dev_clean.patch
  (git-fixes CVE-2025-38555 bsc#1248297).
- Update
  patches.suse/wifi-ath11k-clear-initialized-flag-for-deinit-ed-srn.patch
  (git-fixes CVE-2025-38601 bsc#1248340).
- Update
  patches.suse/wifi-iwlwifi-Fix-error-code-in-iwl_op_mode_dvm_start.patch
  (git-fixes CVE-2025-38656 bsc#1248643).
- Update
  patches.suse/wifi-mac80211-reject-TDLS-operations-when-station-is.patch
  (git-fixes CVE-2025-38644 bsc#1248748).
- Update
  patches.suse/wifi-mt76-mt7925-Fix-null-ptr-deref-in-mt7925_therma.patch
  (git-fixes CVE-2025-38541 bsc#1248216).
- Update
  patches.suse/wifi-prevent-A-MSDU-attacks-in-mesh-networks.patch
  (stable-fixes CVE-2025-38512 bsc#1248178).
- Update
  patches.suse/wifi-rtl818x-Kill-URBs-before-clearing-tx-status-que.patch
  (git-fixes CVE-2025-38604 bsc#1248333).
- Update
  patches.suse/wifi-rtw89-avoid-NULL-dereference-when-RX-problemati.patch
  (git-fixes CVE-2025-38646 bsc#1248577).
- Update
  patches.suse/wifi-zd1211rw-Fix-potential-NULL-pointer-dereference.patch
  (git-fixes CVE-2025-38513 bsc#1248179).
- commit efc5ee0

- HID: asus: fix UAF via HID_CLAIMED_INPUT validation (git-fixes).
- HID: multitouch: fix slab out-of-bounds access in
  mt_report_fixup() (git-fixes).
- drm/mediatek: Fix device/node reference count leaks in
  mtk_drm_get_all_drm_priv (git-fixes).
- drm/msm/kms: move snapshot init earlier in KMS init (git-fixes).
- drm/msm: Defer fd_install in SUBMIT ioctl (git-fixes).
- drm/nouveau: remove unused memory target test (git-fixes).
- drm/nouveau: remove unused increment in gm200_flcn_pio_imem_wr
  (git-fixes).
- drm/nouveau: fix error path in nvkm_gsp_fwsec_v2 (git-fixes).
- drm/nouveau/disp: Always accept linear modifier (git-fixes).
- mISDN: hfcpci: Fix warning when deleting uninitialized timer
  (git-fixes).
- Bluetooth: hci_sync: fix set_local_name race condition
  (git-fixes).
- Bluetooth: hci_event: Detect if HCI_EV_NUM_COMP_PKTS is
  unbalanced (git-fixes).
- Bluetooth: hci_event: Mark connection as closed during suspend
  disconnect (git-fixes).
- Bluetooth: hci_event: Treat UNKNOWN_CONN_ID on disconnect as
  success (git-fixes).
- commit f54cbc7

- clk: bcm: rpi: Add NULL check in raspberrypi_clk_register() (CVE-2025-38160 bsc#1245780)
- commit f8670f7

- tipc: fix null-ptr-deref when acquiring remote ip of ethernet bearer (CVE-2025-38184 bsc#1245956)
- commit 263759a

- drm/amd/display: Avoid divide by zero by initializing dummy pitch to 1 (CVE-2025-38205 bsc#1246005)
- commit e09f72d

- smb: client: add NULL check in automount_fullpath (CVE-2025-38208 bsc#1245815)
- commit 04d79fb

- net: stmmac: make sure that ptp_rate is not 0 before configuring EST (CVE-2025-38125 bsc#1245710)
- commit 0fcfa4f

- pNFS: Fix disk addr range check in block/scsi layout
  (git-fixes).
- commit c36ff17

- pNFS: Fix stripe mapping in block/scsi layout (git-fixes).
- commit 5bf6a36

- pNFS: Handle RPC size limit for layoutcommits (git-fixes).
- commit 36dee9f

- pNFS: Fix uninited ptr deref in block/scsi layout (git-fixes).
- commit 8d7a7ee

- jfs: truncate good inode pages when hard link is 0 (git-fixes).
- commit 7e762b7

- jfs: Regular file corruption check (git-fixes).
- commit 4f3d801

- jfs: upper bound check of tree index in dbAllocAG (git-fixes).
- commit 997ac87

- hfs: fix slab-out-of-bounds in hfs_bnode_read() (git-fixes).
- commit 1ea8ac2

- hfsplus: fix slab-out-of-bounds in hfsplus_bnode_read()
  (git-fixes).
- commit 34d35cb

- hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()
  (git-fixes).
- commit 07b3674

- hfsplus: don't use BUG_ON() in hfsplus_create_attributes_file()
  (git-fixes).
- commit edddb1c

- hfs: fix not erasing deleted b-tree node issue (git-fixes).
- commit 9b06f84

- fs/orangefs: use snprintf() instead of sprintf() (git-fixes).
- commit 9e05c62

- exfat: add cluster chain loop check for dir (git-fixes).
- commit 50f0877

- drm/amdkfd: Don't call mmput from MMU notifier callback (bsc#1248217 CVE-2025-38520)
- commit c848230

- kernel-binary: Another installation ordering fix (bsc#1241353).
- commit fe14ab5

- drm/amdgpu: fix task hang from failed job submission during
  process kill (git-fixes).
- commit 6aefbfc

- usb: dwc3: Remove WARN_ON for device endpoint command timeouts
  (stable-fixes).
- USB: storage: Ignore driver CD mode for Realtek multi-mode
  Wi-Fi dongles (stable-fixes).
- usb: dwc3: pci: add support for the Intel Wildcat Lake
  (stable-fixes).
- USB: storage: Add unusual-devs entry for Novatek NTK96550-based
  camera (stable-fixes).
- usb: quirks: Add DELAY_INIT quick for another SanDisk 3.2Gen1
  Flash Drive (stable-fixes).
- rtc: ds1307: handle oscillator stop flag (OSF) for ds1341
  (stable-fixes).
- rtc: ds1307: remove clear of oscillator stop flag (OSF) in probe
  (stable-fixes).
- watchdog: sbsa: Adjust keepalive timeout to avoid MediaTek
  WS0 race condition (stable-fixes).
- watchdog: dw_wdt: Fix default timeout (stable-fixes).
- watchdog: iTCO_wdt: Report error if timeout configuration fails
  (stable-fixes).
- soundwire: amd: serialize amd manager resume sequence during
  pm_prepare (stable-fixes).
- power: supply: qcom_battmgr: Add lithium-polymer entry
  (stable-fixes).
- pwm: mediatek: Fix duty and period setting (git-fixes).
- pwm: mediatek: Handle hardware enable and clock enable
  separately (stable-fixes).
- wifi: ath12k: Correct tid cleanup when tid setup fails
  (stable-fixes).
- wifi: ath12k: Add memset and update default rate value in wmi
  tx completion (stable-fixes).
- wifi: cfg80211: reject HTC bit for management frames
  (stable-fixes).
- wifi: rtw89: Lower the timeout in rtw89_fw_read_c2h_reg()
  for USB (stable-fixes).
- wifi: rtw89: Fix rtw89_mac_power_switch() for USB
  (stable-fixes).
- wifi: rtw89: Disable deep power saving for USB/SDIO
  (stable-fixes).
- wifi: iwlwifi: mvm: set gtk id also in older FWs (stable-fixes).
- wifi: iwlwifi: mvm: fix scan request validation (stable-fixes).
- wifi: cfg80211: Fix interface type validation (stable-fixes).
- wifi: mac80211: don't complete management TX on SAE commit
  (stable-fixes).
- wifi: mac80211: fix rx link assignment for non-MLO stations
  (stable-fixes).
- wifi: mt76: mt7915: mcu: re-init MCU before loading FW patch
  (stable-fixes).
- wifi: iwlwifi: dvm: fix potential overflow in rs_fill_link_cmd()
  (stable-fixes).
- wifi: iwlwifi: fw: Fix possible memory leak in
  iwl_fw_dbg_collect (stable-fixes).
- wifi: rtlwifi: fix possible skb memory leak in
  `_rtl_pci_rx_interrupt()` (stable-fixes).
- wifi: rtlwifi: fix possible skb memory leak in
  _rtl_pci_init_one_rxdesc() (stable-fixes).
- wifi: ath12k: Enable REO queue lookup table feature on QCN9274
  hw2.0 (stable-fixes).
- wifi: ath12k: Decrement TID on RX peer frag setup error handling
  (stable-fixes).
- wifi: mac80211: update radar_required in channel context after
  channel switch (stable-fixes).
- wifi: iwlegacy: Check rate_idx range after addition
  (stable-fixes).
- reset: brcmstb: Enable reset drivers for ARCH_BCM2835
  (stable-fixes).
- usb: xhci: print xhci-&amp;gt;xhc_state when queue_command failed
  (stable-fixes).
- usb: typec: ucsi: psy: Set current max to 100mA for BC 1.2
  and Default (stable-fixes).
- usb: xhci: Set avg_trb_len = 8 for EP0 during Address Device
  Command (stable-fixes).
- usb: xhci: Avoid showing warnings for dying controller
  (stable-fixes).
- usb: xhci: Avoid showing errors during surprise removal
  (stable-fixes).
- usb: core: config: Prevent OOB read in SS endpoint companion
  parsing (stable-fixes).
- usb: typec: intel_pmc_mux: Defer probe if SCU IPC isn't present
  (stable-fixes).
- usb: core: usb_submit_urb: downgrade type check (stable-fixes).
- thermal: sysfs: Return ENODATA instead of EAGAIN for reads
  (stable-fixes).
- thermal/drivers/qcom-spmi-temp-alarm: Enable stage 2 shutdown
  when required (stable-fixes).
- pm: cpupower: Fix the snapshot-order of tsc,mperf, clock in
  mperf_stop() (stable-fixes).
- PM: runtime: Clear power.needs_force_resume in
  pm_runtime_reinit() (stable-fixes).
- PM: sleep: console: Fix the black screen issue (stable-fixes).
- PM / devfreq: governor: Replace sscanf() with kstrtoul()
  in set_freq_store() (stable-fixes).
- commit 3e165bb

- net: phy: smsc: add proper reset flags for LAN8710A
  (stable-fixes).
- pinctrl: stm32: Manage irq affinity settings (stable-fixes).
- phy: rockchip-pcie: Properly disable TEST_WRITE strobe signal
  (stable-fixes).
- media: v4l2-common: Reduce warnings about missing
  V4L2_CID_LINK_FREQ control (stable-fixes).
- media: tc358743: Return an appropriate colorspace from
  tc358743_set_fmt (stable-fixes).
- media: tc358743: Check I2C succeeded during probe
  (stable-fixes).
- media: tc358743: Increase FIFO trigger level to 374
  (stable-fixes).
- media: usb: hdpvr: disable zero-length read messages
  (stable-fixes).
- net: phy: micrel: Add ksz9131_resume() (stable-fixes).
- net: thunderbolt: Enable end-to-end flow control also in
  transmit (stable-fixes).
- net: thunderbolt: Fix the parameter passing of
  tb_xdomain_enable_paths()/tb_xdomain_disable_paths()
  (stable-fixes).
- mmc: sdhci-msm: Ensure SD card power isn't ON when card removed
  (stable-fixes).
- mmc: rtsx_usb_sdmmc: Fix error-path in sd_set_power_mode()
  (stable-fixes).
- mei: bus: Check for still connected devices in
  mei_cl_bus_dev_release() (stable-fixes).
- platform/chrome: cros_ec_typec: Defer probe on missing EC parent
  (stable-fixes).
- platform/x86/amd: pmc: Add Lenovo Yoga 6 13ALC6 to pmc quirk
  list (stable-fixes).
- commit 49985d1

- iio: pressure: bmp280: Use IS_ERR() in bmp280_common_probe()
  (git-fixes).
- ipmi: Use dev_warn_ratelimited() for incorrect message warnings
  (stable-fixes).
- ipmi: Fix strcpy source and destination the same (stable-fixes).
- i2c: Force DLL0945 touchpad i2c freq to 100khz (stable-fixes).
- i3c: don't fail if GETHDRCAP is unsupported (stable-fixes).
- i3c: master: Initialize ret in i3c_i2c_notifier_call()
  (stable-fixes).
- hwmon: (emc2305) Set initial PWM minimum value during probe
  based on thermal state (stable-fixes).
- media: dvb-frontends: dib7090p: fix null-ptr-deref in
  dib7090p_rw_on_apb() (stable-fixes).
- media: dvb-frontends: w7090p: fix null-ptr-deref in
  w7090p_tuner_write_serpar and w7090p_tuner_read_serpar
  (stable-fixes).
- media: uvcvideo: Fix bandwidth issue for Alcor camera
  (stable-fixes).
- leds: leds-lp50xx: Handle reg to get correct multi_index
  (stable-fixes).
- iio: adc: ad_sigma_delta: don't overallocate scan buffer
  (stable-fixes).
- iio: imu: inv_icm42600: use = { } instead of memset()
  (stable-fixes).
- iio: adc: ad7768-1: Ensure SYNC_IN pulse minimum timing
  requirement (stable-fixes).
- gpio: wcd934x: check the return value of regmap_update_bits()
  (stable-fixes).
- gpio: tps65912: check the return value of regmap_update_bits()
  (stable-fixes).
- iio: imu: inv_icm42600: switch timestamp type from int64_t
  __aligned(8) to aligned_s64 (stable-fixes).
- commit cf6f726

- drm/amd/display: Fix DP audio DTO1 clock source on DCE 6
  (stable-fixes).
- drm/amd/display: Fill display clock and vblank time in
  dce110_fill_display_configs (stable-fixes).
- drm/amd/display: Find first CRTC and its line time in
  dce110_fill_display_configs (stable-fixes).
- drm/amd/display: Avoid a NULL pointer dereference
  (stable-fixes).
- drm/amdkfd: Destroy KFD debugfs after destroy KFD wq
  (stable-fixes).
- drm/amd/display: Add primary plane to commits for correct VRR
  handling (stable-fixes).
- drm/amdgpu: update mmhub 3.0.1 client id mappings
  (stable-fixes).
- drm/amd: Restore cached power limit during resume
  (stable-fixes).
- fbdev: Fix vmalloc out-of-bounds write in fast_imageblit
  (stable-fixes).
- fbdev: fix potential buffer overflow in
  do_register_framebuffer() (stable-fixes).
- drm/amd/display: Only finalize atomic_obj if it was initialized
  (stable-fixes).
- drm/amd/display: Avoid configuring PSR granularity if PSR-SU
  not supported (stable-fixes).
- drm/amdgpu: Avoid extra evict-restore process (stable-fixes).
- crypto: hisilicon/hpre - fix dma unmap sequence (stable-fixes).
- crypto: jitter - fix intermediary handling (stable-fixes).
- crypto: qat - lower priority for skcipher and aead algorithms
  (stable-fixes).
- crypto: octeontx2 - add timeout for load_fvc completion poll
  (stable-fixes).
- drm/msm: use trylock for debugfs (stable-fixes).
- drm/amd/display: Separate set_gsl from set_gsl_source_select
  (stable-fixes).
- drm/amd/display: Fix 'failed to blank crtc!' (stable-fixes).
- drm/amd: Allow printing VanGogh OD SCLK levels without setting
  dpm to manual (stable-fixes).
- drm/amd/display: Avoid trying AUX transactions on disconnected
  ports (stable-fixes).
- drm/dp: Change AUX DPCD probe address from DPCD_REV to
  LANE0_1_STATUS (stable-fixes).
- drm/ttm: Should to return the evict error (stable-fixes).
- drm/ttm: Respect the shrinker core free target (stable-fixes).
- et131x: Add missing check after DMA map (stable-fixes).
- comedi: fix race between polling and detaching (git-fixes).
- char: misc: Fix improper and inaccurate error code returned
  by misc_init() (stable-fixes).
- commit adab316

- ALSA: hda/realtek: Add support for HP EliteBook x360 830 G6
  and EliteBook 830 G6 (stable-fixes).
- ALSA: hda/realtek: Fix headset mic on HONOR BRB-X
  (stable-fixes).
- ALSA: hda/realtek: Add Framework Laptop 13 (AMD Ryzen AI 300)
  to quirks (stable-fixes).
- ASoC: Intel: avs: Fix uninitialized pointer error in probe()
  (stable-fixes).
- Bluetooth: hci_sock: Reset cookie to zero in
  hci_sock_free_cookie() (stable-fixes).
- ASoC: soc-dapm: set bias_level if snd_soc_dapm_set_bias_level()
  was successed (stable-fixes).
- ASoC: hdac_hdmi: Rate limit logging on connection and
  disconnection (stable-fixes).
- ASoC: core: Check for rtd == NULL in
  snd_soc_remove_pcm_runtime() (stable-fixes).
- ASoC: codecs: rt5640: Retry DEVICE_ID verification
  (stable-fixes).
- commit c1f1889

- ALSA: hda: Handle the jack polling always via a work
  (stable-fixes).
- ALSA: hda: Disable jack polling at shutdown (stable-fixes).
- ALSA: intel8x0: Fix incorrect codec index usage in mixer for
  ICH4 (stable-fixes).
- ALSA: hda/ca0132: Fix buffer overflow in add_tuning_control
  (stable-fixes).
- ALSA: pcm: Rewrite recalculate_boundary() to avoid costly loop
  (stable-fixes).
- ALSA: usb-audio: Avoid precedence issues in mixer_quirks macros
  (stable-fixes).
- ACPI: APEI: send SIGBUS to current task if synchronous memory
  error not recovered (stable-fixes).
- ACPI: processor: fix acpi_object initialization (stable-fixes).
- commit d6d6e01

- xfrm: interface: fix use-after-free after changing collect_md
  xfrm interface (CVE-2025-38500 bsc#1248088).
- rxrpc: Fix recv-recv race of completed call (CVE-2025-38524
  bsc#1248194).
- atm: clip: Fix memory leak of struct clip_vcc (CVE-2025-38546
  bsc#1248223).
- commit 57cffb2

- x86/sev: Evict cache lines during SNP memory validation
  (CVE-2025-38560 bsc#1248312).
- commit 0d489ec

- hid: hide cleanup of hid_descriptor (CVE-2025-38103
  bsc#1245663).
- commit 58f3abc

- HID: usbhid: Eliminate recurrent out-of-bounds bug in
  usbhid_parse() (CVE-2025-38103 bsc#1245663).
- blacklist.conf: removed erroneous entry
- commit 5f4ef22

- rpm/config.sh: Update Leap project
- commit 20eb23b

- selftests/perf_events: Add a mmap() correctness test
  (CVE-2025-38563 bsc#1248306 selftest).
- commit 919a844

- bpf: fix kfunc btf caching for modules (git-fixes).
- commit 5ae4aa5

- perf/core: Prevent VMA split of buffer mappings (CVE-2025-38563
  bsc#1248306).
- commit d1daec3

- perf/core: Exit early on perf_mmap() fail (CVE-2025-38563
  bsc#1248306 dependency).
- commit 4deadd8

- perf/core: Don't leak AUX buffer refcount on allocation failure
  (CVE-2025-38563 bsc#1248306 dependency).
- commit d26658d

- bpf: use kvzmalloc to allocate BPF verifier environment
  (git-fixes).
- commit fd28e75

- selftests/bpf: Verify that sync_linked_regs preserves subreg_def
  (bsc#1234156 CVE-2024-53125).
- commit cee135e

- samples/bpf: Fix compilation errors with cf-protection option
  (git-fixes).
- commit 388c9e8

- selftests/bpf: fexit_sleep: Fix stack allocation for arm64
  (git-fixes).
- commit 2d627c6

- Update config files.
  No functional change, this is only refresh to have configs in sync with
  Kconfig.
- commit 1943697

- Refresh
  patches.kabi/bpf-bpf_link-and-bpf_link_ops-kABI-workaround.patch.
- Refresh
  patches.kabi/kabi-hide-new-member-fallback_lock-in-struct-mptcp_s.patch.
- Refresh
  patches.kabi/kabi-restore-layout-of-struct-mem_control.patch.
- Refresh
  patches.kabi/kabi-restore-layout-of-struct-page_counter.patch.
- Refresh
  patches.kabi/kabi-s390-ism-fix-concurrency-management-in-ism_cmd.patch
- Refresh
  patches.kabi/xsk-Fix-race-condition-in-AF_XDP-generic-RX-path.patch.
  Manual adjustment of guards in KABI workaround patches -- we do not need
  specific conditioning thanks to new macro that is engaged iff needed.
- commit f47a39f

- build_bug.h: Add KABI assert (bsc#1249186).
- commit 7ab6a56

- iio: common: st_sensors: Fix use of uninitialize device structs
  (CVE-2025-38531 bsc#1248205).
- commit 2739cf9

- usb: xhci: Fix slot_id resource race conflict (git-fixes).
- commit 40d11e8

- usb: dwc3: fix fault at system suspend if device was already
  runtime suspended (git-fixes).
- commit 03244f6

- usb: dwc3: core: Fix system suspend on TI AM62 platforms
  (git-fixes).
- commit ae2a72e

- pinctrl: STMFX: add missing HAS_IOMEM dependency (git-fixes).
- most: core: Drop device reference after usage in get_channel()
  (git-fixes).
- usb: storage: realtek_cr: Use correct byte order for
  bcs-&amp;gt;Residue (git-fixes).
- usb: dwc3: Ignore late xferNotReady event to prevent halt
  timeout (git-fixes).
- usb: core: hcd: fix accessing unmapped memory in
  SINGLE_STEP_SET_FEATURE test (git-fixes).
- usb: renesas-xhci: Fix External ROM access timeouts (git-fixes).
- mmc: sdhci-pci-gli: GL9763e: Rename the gli_set_gl9763e()
  for consistency (git-fixes).
- commit f954d9b

- iio: proximity: isl29501: fix buffered read on big-endian
  systems (git-fixes).
- comedi: Make insn_rw_emulate_bits() do insn-&amp;gt;n samples
  (git-fixes).
- comedi: Fix use of uninitialized memory in do_insn_ioctl()
  and do_insnlist_ioctl() (git-fixes).
- comedi: pcl726: Prevent invalid irq number (git-fixes).
- cdx: Fix off-by-one error in cdx_rpmsg_probe() (git-fixes).
- drm/hisilicon/hibmc: fix the hibmc loaded failed bug
  (git-fixes).
- iosys-map: Fix undefined behavior in iosys_map_clear()
  (git-fixes).
- drm/nouveau: fix typos in comments (git-fixes).
- drm/nouveau/nvif: Fix potential memory leak in nvif_vmm_ctor()
  (git-fixes).
- drm/amd/display: Fix fractional fb divider in set_pixel_clock_v3
  (git-fixes).
- drm/amd/display: Adjust DCE 8-10 clock, don't overclock by 15%
  (git-fixes).
- drm/amd/display: Don't overclock DCE 6 by 15% (git-fixes).
- drm/amd/display: Add null pointer check in
  mod_hdcp_hdcp1_create_session() (git-fixes).
- memstick: Fix deadlock by moving removing flag earlier
  (git-fixes).
- ALSA: usb-audio: Use correct sub-type for UAC3 feature unit
  validation (git-fixes).
- ALSA: hda/realtek: Audio disappears on HP 15-fc000 after warm
  boot again (git-fixes).
- ALSA: hda/realtek: Fix headset mic on ASUS Zenbook 14
  (git-fixes).
- ALSA: usb-audio: Fix size validation in convert_chmap_v3()
  (git-fixes).
- commit 0a99e72

- bpf: Reject narrower access to pointer ctx fields (bsc#1248363
  CVE-2025-38591).
- commit 2a67c58

- md: make rdev_addable usable for rcu mode (git-fixes).
- scsi: sd: Make sd shutdown issue START STOP UNIT appropriately
  (git-fixes).
- scsi: Revert &amp;quot;scsi: iscsi: Fix HW conn removal use after free&amp;quot;
  (git-fixes).
- scsi: mpt3sas: Fix a fw_event memory leak (git-fixes).
- scsi: isci: Fix dma_unmap_sg() nents value (git-fixes).
- scsi: mvsas: Fix dma_unmap_sg() nents value (git-fixes).
- scsi: elx: efct: Fix dma_unmap_sg() nents value (git-fixes).
- scsi: core: Fix kernel doc for scsi_track_queue_full()
  (git-fixes).
- scsi: ibmvscsi_tgt: Fix dma_unmap_sg() nents value (git-fixes).
- scsi: mpi3mr: Serialize admin queue BAR writes on 32-bit systems
  (git-fixes).
- scsi: mpi3mr: Fix race between config read submit and interrupt
  completion (git-fixes).
- scsi: mpi3mr: Fix kernel-doc issues in mpi3mr_app.c (git-fixes).
- sunvdc: Balance device refcount in vdc_port_mpgroup_check
  (git-fixes).
- md: allow removing faulty rdev during resync (git-fixes).
- block: mtip32xx: Fix usage of dma_map_sg() (git-fixes).
- ublk: use vmalloc for ublk_device's __queues (git-fixes).
- loop: use kiocb helpers to fix lockdep warning (git-fixes).
- block: fix kobject leak in blk_unregister_queue (git-fixes).
- md/raid1,raid10: strip REQ_NOWAIT from member bios (git-fixes).
- ublk: sanity check add_dev input for underflow (git-fixes).
- aoe: defer rexmit timer downdev work to workqueue (git-fixes).
- commit e0823df

- clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns (CVE-2025-38499 bsc#1247976)
- commit a7416f7

- atm: clip: Fix NULL pointer dereference in vcc_sendmsg() (CVE-2025-38458 bsc#1247116)
- commit 17419dc

- atm: Release atm_dev_mutex after removing procfs in atm_dev_deregister() (CVE-2025-38245 bsc#1246193)
- commit c9503c1

- btrfs: fix adding block group to a reclaim list and the unused
  list during reclaim (git-fixes).
- btrfs: retry block group reclaim without infinite loop
  (git-fixes).
- commit 0a86fac

- btrfs: fix bitmap leak when loading free space cache on
  duplicate entry (git-fixes).
- commit 72cd329

- btrfs: run delayed iputs when flushing delalloc (git-fixes).
- btrfs: update target inode's ctime on unlink (git-fixes).
- commit 8eb6c44

- btrfs: fix data race when accessing the inode's disk_i_size
  at btrfs_drop_extents() (git-fixes).
- commit 04c28bf

- squashfs: fix memory leak in squashfs_fill_super (git-fixes).
- commit 7c9f4fd

- btrfs: convert BUG_ON in btrfs_reloc_cow_block() to proper
  error handling (git-fixes).
- commit 0d7a95c

- btrfs: correctly escape subvol in btrfs_show_options()
  (git-fixes).
- commit 8ae9b3b

- atm: Revert atm_account_tx() if copy_from_iter_full() fails (CVE-2025-38190 bsc#1245973)
- commit ee168d7

- atm: atmtcp: Free invalid length skb in atmtcp_c_send() (CVE-2025-38185 bsc#1246012)
- commit 3034c5a

- md/raid1: Fix stack memory use after return in raid1_reshape (CVE-2025-38445 bsc#1247229)
- commit c07b722

- bpf, ktls: Fix data corruption when using bpf_msg_pop_data()
  in ktls (bsc#1248338 CVE-2025-38608).
- commit 70a5de5

- RDMA/hns: Fix dip entries leak on devices newer than hip09 (git-fixes)
- commit b03653b

- RDMA/bnxt_re: Fix to initialize the PBL array (git-fixes)
- commit 99342e6

- RDMA/bnxt_re: Fix a possible memory leak in the driver (git-fixes)
- commit d8fc453

- RDMA/bnxt_re: Fix to remove workload check in SRQ limit path (git-fixes)
- commit d6073c4

- RDMA/bnxt_re: Fix to do SRQ armena by default (git-fixes)
- commit 43a4c91

- RDMA/erdma: Fix ignored return value of init_kernel_qp (git-fixes)
- commit 184f89d

- atm: clip: Fix infinite recursive call of clip_push() (CVE-2025-38459 bsc#1247119)
- commit cace503

- atm: clip: prevent NULL deref in clip_push() (CVE-2025-38251 bsc#1246181)
- commit 955d194

- bnxt_en: Set DMA unmap len correctly for XDP_REDIRECT (CVE-2025-38439 bsc#1247155)
- commit fad3d81

- ACPI: pfr_update: Fix the driver update version check
  (git-fixes).
- net: usb: asix_devices: Fix PHY address mask in MDIO bus
  initialization (git-fixes).
- Bluetooth: hci_conn: do return error from
  hci_enhanced_setup_sync() (git-fixes).
- Bluetooth: hci_event: fix MTU for BN == 0 in CIS Established
  (git-fixes).
- commit 5ef3e7e

- raid10: cleanup memleak at raid10_make_request (CVE-2025-38444 bsc#1247162)
- commit 08daebe

- net: openvswitch: Fix the dead loop of MPLS parse
  (CVE-2025-38146 bsc#1245767).
- commit 2d16fb7

- Update patches.kabi/kabi-hide-new-member-fallback_lock-in-struct-mptcp_s.patch.
  Perform the build time check that struct mptcp_sock layout only when
  CONFIG_SUSE_KERNEL_SUPPORTED is enabled. Some kernel-debug builds do not
  have the hole we rely on in the kabi hack. (But those do not have to
  preserve kABI so that we can simply disable the check.)
- commit 21df537

- kabi: hide new member fallback_lock in struct mptcp_sock
  (CVE-2025-38491 bsc#1247280).
- mptcp: make fallback action and fallback decision atomic
  (CVE-2025-38491 bsc#1247280).
- mptcp: safety check before fallback (CVE-2025-38491
  bsc#1247280).
- mptcp: reset when MPTCP opts are dropped after join (git-fixes).
- mptcp: fallback when MPTCP opts are dropped after 1st data
  (git-fixes).
- commit 7bb090d

- tipc: Fix use-after-free in tipc_conn_close() (CVE-2025-38464
  bsc#1247112).
- commit 7a2a262

- x86/vmscape: Warn when STIBP is disabled with SMT (bsc#1247483 CVE-2025-40300).
- commit 25dd084

- x86/bugs: Move cpu_bugs_smt_update() down (bsc#1247483 CVE-2025-40300).
- commit 4b9a38a

- x86/vmscape: Enable the mitigation (bsc#1247483 CVE-2025-40300).
- Update config files.
- commit 2ae4103

- bpf: Reject %p% format string in bprintf-like helpers
  (bsc#1248198 CVE-2025-38528).
- commit b8830ae

- md/md-cluster: handle REMOVE message earlier (bsc#1247057).
- commit b9c1ff5

- scsi: target: iscsi: Fix timeout on deleted connection (CVE-2025-38075 bsc#1244734)
- commit 9bfd228

- net: mctp: Don't access ifa_index when missing (CVE-2025-38006 bsc#1244930)
- commit d0d056e

- netfilter: nft_set_pipapo: clamp maximum map bucket size to
  INT_MAX (CVE-2025-38201 bsc#1245977).
- commit 2f63881

- netfilter: flowtable: account for Ethernet header in
  nf_flow_pppoe_proto() (CVE-2025-38441 bsc#1247167).
- commit 0a2f320

- netfilter: nf_conntrack: fix crash due to removal of
  uninitialised entry (CVE-2025-38472 bsc#1247313).
- commit 1779cac

- x86/vmscape: Add conditional IBPB mitigation (bsc#1247483 CVE-2025-40300).
- commit 80ca68e

- x86/vmscape: Enumerate VMSCAPE bug (bsc#1247483 CVE-2025-40300).
- commit ed3190c

- Documentation/hw-vuln: Add VMSCAPE documentation (bsc#1247483 CVE-2025-40300).
- commit 9b7d62a

- powerpc/kernel: Fix ppc_save_regs inclusion in build
  (bsc#1215199).
- powerpc: do not build ppc_save_regs.o always (bsc#1215199).
- commit 3402e7e

- powerpc/eeh: Make EEH driver device hotplug safe (bsc#1215199).
- powerpc/eeh: Export eeh_unfreeze_pe() (bsc#1215199).
- PCI: pnv_php: Work around switches with broken presence
  detection (bsc#1215199).
- PCI: pnv_php: Clean up allocated IRQs on unplug (bsc#1215199).
- arch/powerpc: Remove .interp section in vmlinux (bsc#1215199).
- powerpc/eeh: Rely on dev-&amp;gt;link_active_reporting (bsc#1215199).
- commit 0bddfac

- ata: libata-scsi: Fix CDL control (git-fixes).
- commit c04f51b

- drm/amdgpu: fix incorrect vm flags to map bo (git-fixes).
- ALSA: usb-audio: Validate UAC3 cluster segment descriptors
  (git-fixes).
- ALSA: usb-audio: Validate UAC3 power domain descriptors, too
  (git-fixes).
- gpio: mlxbf3: use platform_get_irq_optional() (git-fixes).
- Revert &amp;quot;gpio: mlxbf3: only get IRQ for device instance 0&amp;quot;
  (git-fixes).
- soc/tegra: pmc: Ensure power-domains are in a known state
  (git-fixes).
- phy: mscc: Fix parsing of unicast frames (git-fixes).
- ALSA: scarlett2: Add retry on -EPROTO from scarlett2_usb_tx()
  (git-fixes).
- selftests: rtnetlink.sh: remove esp4_offload after test
  (git-fixes).
- Bluetooth: btusb: Add USB ID 3625:010b for TP-LINK Archer
  TX10UB Nano (stable-fixes).
- kselftest/arm64: Fix check for setting new VLs in sve-ptrace
  (git-fixes).
- selftests: Fix errno checking in syscall_user_dispatch test
  (git-fixes).
- selftests/tracing: Fix false failure of subsystem event test
  (git-fixes).
- USB: serial: option: add Foxconn T99W709 (stable-fixes).
- ASoC: amd: yc: Add DMI quirk for HP Laptop 17 cp-2033dx
  (stable-fixes).
- ASoC: amd: yc: Add DMI entries to support HP 15-fb1xxx
  (stable-fixes).
- ASoC: Intel: fix SND_SOC_SOF dependencies (stable-fixes).
- ASoC: amd: yc: add DMI quirk for ASUS M6501RM (stable-fixes).
- commit 19adc9d

- net: usb: asix_devices: add phy_mask for ax88772 mdio bus
  (git-fixes).
- commit 206e9eb

- ACPI: processor: perflib: Move problematic pr-&amp;gt;performance check
  (git-fixes).
- commit 742e4e7

- btrfs: fix the length of reserved qgroup to free (bsc#1240708)
- commit e3e4e05

- btrfs: fix qgroup reserve leaks in cow_file_range (CVE-2024-46733 bsc#1230708)
- commit 20ff141

- Move pesign-obs-integration requirement from kernel-syms to kernel devel
  subpackage (bsc#1248108).
- commit e707e41

- mm/ptdump: take the memory hotplug lock inside ptdump_walk_pgd() (git-fixes)
- commit bf13671

- arm64: dts: imx8mm-venice-gw7904: Increase HS400 USDHC clock speed (git-fixes)
- commit 246a69b

- arm64: dts: imx8mm-venice-gw7903: Increase HS400 USDHC clock speed (git-fixes)
- commit 4fac981

- arm64: dts: imx8mn-venice-gw7902: Increase HS400 USDHC clock speed (git-fixes)
- commit 9beeb6d

- arm64: dts: imx8mm-venice-gw7902: Increase HS400 USDHC clock speed (git-fixes)
- commit 173d0a1

- PCI: rockchip: Set Target Link Speed to 5.0 GT/s before
  retraining (git-fixes).
- PCI: rockchip: Use standard PCIe definitions (git-fixes).
- PCI: imx6: Delay link start until configfs 'start' written
  (git-fixes).
- PCI: imx6: Remove apps_reset toggling from
  imx_pcie_{assert/deassert}_core_reset (git-fixes).
- PCI: imx6: Add IMX8MM_EP and IMX8MP_EP fixed 256-byte BAR 4
  in epc_features (git-fixes).
- PCI/portdrv: Use is_pciehp instead of is_hotplug_bridge
  (git-fixes).
- PCI/ACPI: Fix runtime PM ref imbalance on Hot-Plug Capable ports
  (git-fixes).
- kABI: PCI/ACPI: Fix runtime PM ref imbalance on Hot-Plug
  Capable ports (git-fixes).
- PCI: Support Immediate Readiness on devices without PM
  capabilities (git-fixes).
- PCI: apple: Fix missing OF node reference in
  apple_pcie_setup_port (git-fixes).
- PCI: Add ACS quirk for Loongson PCIe (git-fixes).
- commit e24dcd6

- arm64: dts: imx8mm-venice-gw7901: Increase HS400 USDHC clock speed (git-fixes)
- commit 271991a

- arm64: dts: imx8mm-venice-gw700x: Increase HS400 USDHC clock speed (git-fixes)
- commit b77d1e0

- arm64: dts: imx8mn-beacon: Fix HS400 USDHC clock speed (git-fixes)
- commit 3cbe1cf

- arm64: dts: imx8mm-beacon: Fix HS400 USDHC clock speed (git-fixes)
- commit 6d0adbc

- arm64: dts: rockchip: fix endpoint dtc warning for PX30 ISP (git-fixes)
- commit d8b8e5c

- arm64/entry: Mask DAIF in cpu_switch_to(), call_on_irq_stack() (git-fixes)
- commit 81dc70d

- arm64: dts: freescale: imx8mm-verdin: Keep LDO5 always on (git-fixes)
- commit a30082d

- arm64: Filter out SME hwcaps when FEAT_SME isn't implemented (git-fixes)
- commit d67b39d

- arm64: dts: apple: t8103: Fix PCIe BCM4377 nodename (git-fixes)
- commit 3ecd022

- arm64: Restrict pagetable teardown to avoid false warning (git-fixes)
- commit c34ecbe

- arm64: dts: rockchip: Update eMMC for NanoPi R5 series (git-fixes)
- commit b37cb41

- arm64: dts: imx8mp-beacon: Fix RTC capacitive load (git-fixes)
- commit 32c56dd

- arm64: dts: imx8mn-beacon: Fix RTC capacitive load (git-fixes)
- commit ee84ff9

- arm64: dts: imx8mm-beacon: Fix RTC capacitive load (git-fixes)
- commit 7b505c9

- arm64: tegra: Drop remaining serial clock-names and reset-names (git-fixes)
- commit 2981841

- arm64: Add support for HIP09 Spectre-BHB mitigation (git-fixes)
- commit 4ad8521

- arm64: zynqmp: add clock-output-names property in clock nodes (git-fixes)
- commit ba1bbf1

- arm64: tegra: p2597: Fix gpio for vdd-1v8-dis regulator (git-fixes)
- commit 356d85f

- arm64/mm: Check PUD_TYPE_TABLE in pud_bad() (git-fixes)
- commit 1ad9e93

- arm64/cpufeatures/kvm: Add ARMv8.9 FEAT_ECBHB bits in ID_AA64MMFR1 (git-fixes)
- commit 54de7d8

- serial: 8250: fix panic due to PSLVERR (git-fixes).
- commit c91d52e

- drm/amd/display: Add more checks for DSC / HUBP ONO guarantees (bsc#1247078 CVE-2025-38360)
- commit 9101a0c

- net: libwx: remove duplicate page_pool_put_full_page()
  (CVE-2025-38490 bsc#1247243).
- commit f305524

- sunrpc: fix handling of server side tls alerts (git-fixes).
- commit 40fb7b3

- cifs: Fix buffer overflow when parsing NFS reparse points
  (CVE-2024-49996 bsc#1232089).
- commit 50adb2e

- smb: client: fix parsing of device numbers (git-fixes).
- commit 45992a6

- 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 46ad237

- 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 383df22

- 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

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

- 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

- 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

- 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

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

- fs/mnt_idmapping.c: Return -EINVAL when no map is written (bsc#1233120)
- commit 1ef0d72

- 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

- btrfs: return accurate error code on open failure in open_fs_devices() (bsc#1233120)
- commit 53ce95e

- 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

- integrity/platform_certs: Allow loading of keys in the static
  key management mode (jsc#PED-13345 jsc#PED-13343).
- powerpc/secvar: Expose secvars relevant to the key management
  mode (jsc#PED-13345 jsc#PED-13343).
- powerpc/pseries: Correct secvar format representation for
  static key management (jsc#PED-13345 jsc#PED-13343).
- commit f654d9a

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

- 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

- 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

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

- 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

- 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

- 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

- 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

- 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

- 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

- 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

- 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

- 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

- rcu-tasks: Maintain lists to eliminate RCU-tasks/do_exit() (bsc#1246298)
- commit 51bf729

- 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

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

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

- 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 2db834f

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

- 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

- supported.conf: add missing entries explicitly
  Those are implicitly added as unsupported.  List up explicitly.
- commit 06a6015

- 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

- 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

- 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

- rcu-tasks: Initialize data to eliminate RCU-tasks/do_exit() (bsc#1246298)
- commit 8136da5

- 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

- rcu-tasks: Initialize callback lists at rcu_init() time (bsc#1246298)
- commit d73116a

- rcu-tasks: Add data to eliminate RCU-tasks/do_exit() (bsc#1246298)
- commit ee26238

- 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

- 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

- 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

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

- 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

- 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

- config: enable RBD (jsc#PED-13238)
- commit 9e8693b

- 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

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

- 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

- 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

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

- 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

- 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

- 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

- 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

- 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

- 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

- 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

- 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

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

- rpm: Drop support for kabi/arch/ignore-flavor (bsc#1249186)
  It's not used in any active branches and it cannot solve contemporary
  problems.
- commit f86a16a

- 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

Package expat was updated:

- Fix CVE-2025-59375 / bsc#1249584.- Add patch file:
  * CVE-2025-59375.patch

Package libxslt was updated:

- security update- added patches
  CVE-2025-11731 [bsc#1251979], type confusion in exsltFuncResultCompfunction leading to denial of service
  * libxslt-CVE-2025-11731.patch

- security update
- added patches
  CVE-2025-10911 [bsc#1250553], use-after-free with key data stored cross-RVT
  * libxslt-CVE-2025-10911.patch

- security update
- added patches
  CVE-2025-7424 [bsc#1246360], Type confusion in xmlNode.psvi between stylesheet and source nodes
  + libxslt-CVE-2025-7424.patch

Package mozilla-nss was updated:

- Add bmo1990242.patch to move NSS DB password hash away from SHA-1
- update to NSS 3.112.2
  * bmo#1970079 - Prevent leaks during pkcs12 decoding.
  * bmo#1988046 - SEC_ASN1Decode* should ensure it has read as many bytes as each length field indicates
- Adding patch bmo1980465.patch to fix bug on s390x (bmo#1980465)
- Adding patch bmo1956754.patch to fix possible undefined behaviour (bmo#1956754)

- update to NSS 3.112.1
  * bmo#1982742 - restore support for finding certificates by decoded serial number.

- 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
- Removed upstreamed nss-reproducible-chksums.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.

- Updated nss-fips-approved-crypto-non-ec.patch to not pass in
  bad targetKeyLength parameters when checking for FIPS approval
  after keygen. This was causing false rejections.

- Updated nss-fips-approved-crypto-non-ec.patch to approve
  RSA signature verification  mechanisms with PKCS padding and
  legacy moduli (bsc#1222834).

- Updated nss-fips-approved-crypto-non-ec.patch to enforce
  approved curves with the CKK_EC_MONTGOMERY key type (bsc#1224113).

Package libgcrypt was updated:

- Fix running the test suite in FIPS mode [bsc#1246934]  * Add libgcrypt-fix-pkcs12-test-in-FIPS-mode.patch
  * Rebase 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 gpgme was updated:

- Treat empty DISPLAY variable as unset. [bsc#1252425, bsc#1231055]  * To avoid gpgme constructing an invalid gpg command line when
    the DISPLAY variable is empty it can be treated as unset.
  * Add gpgme-Treat-empty-DISPLAY-variable-as-unset.patch
  * Reported upstream: dev.gnupg.org/T7919

Package openssl-3 was updated:

- Security fix: [bsc#1250232 CVE-2025-9230]  * Fix out-of-bounds read &amp;amp; write in RFC 3211 KEK unwrap
  * Add patch openssl3-CVE-2025-9230.patch
- Disable LTO for userspace livepatching [jsc#PED-13245]

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 python311:base 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).

Package sqlite3 was updated:

- bsc#1252217: Add a %license file.
- bsc#1248586: Fix icu-enabled build.

- Update to version 3.50.4:
  * Fix two long-standings cases of the use of uninitialized
    variables in obscure circumstances.

- Update to version 3.50.3:
  * Fix a possible memory error that can occur if a query is made
    against against FTS5 index that has been deliberately corrupted
    in a very specific way.
  * Fix the parser so that it ignored SQL comments in all places of
    a CREATE TRIGGER statement. This resolves a problem that was
    introduced by the introduction of the
    SQLITE_DBCONFIG_ENABLE_COMMENTS feature in version 3.49.0.
  * Fix an incorrect answer due to over-optimization of an AND
    operator.

- Update to 3.50.2:
  * Fix the concat_ws() SQL function so that it includes empty
    strings in the concatenation.
  * Avoid writing frames with no checksums into the wal file if a
    savepoint is rolled back after dirty pages have already been
    spilled into the wal file.
  * Fix the Bitvec object to avoid stack overflow when the
    database is within 60 pages of its maximum size.
  * Fix a problem with UPDATEs on fts5 tables that contain BLOB
    values.
  * Fix an issue with transitive IS constraints on a RIGHT JOIN.
  * 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.
  * Ensure that sqlite3_setlk_timeout() holds the database mutex.

- Update to 3.50 (3.50.1):
  * Improved handling and robust output of control characters
  * sqlite3_rsync no longer requires WAL mode and needs less
    bandwidth
  * Bug fixes and optimized JSON handling
  * Performance optimizations and developer visible fixes

- Update to release 3.49.2:
  * Fix a bug in the NOT NULL optimization of version 3.40.0 that
    can lead to a memory error if abused.
  * Fix the count-of-view optimization so that it does not give an
    incorrect answer for a DISTINCT query.
  * Fix a possible incorrect answer that can result if a UNIQUE
    constraint of a table contains the PRIMARY KEY column and that
    UNIQUE constraint is used by an IN operator.
  * Fix obscure problems with the generate_series() extension
    function.
  * Incremental improvements to the configure/make.

- Add subpackage for the lemon parser generator.
- Add patches:
  * sqlite-3.49.0-fix-lemon-missing-cflags.patch
  * sqlite-3.6.23-lemon-system-template.patch

Package libssh was updated:

- Security fix: [CVE-2025-8277, bsc#1249375]  * Memory Exhaustion via Repeated Key Exchange
  * Add patches:
  - libssh-CVE-2025-8277-packet-Adjust-packet-filter-to-work-wh.patch
  - libssh-CVE-2025-8277-Fix-memory-leak-of-unused-ephemeral-ke.patch
  - libssh-CVE-2025-8277-ecdh-Free-previously-allocated-pubkeys.patch

- Security fix: [CVE-2025-8114, bsc#1246974]
  * NULL pointer dereference when calculating session ID during KEX
  * Add libssh-CVE-2025-8114.patch

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-6021 [bsc#1244580], Integer Overflow in xmlBuildQName() Leads to Stack Buffer Overflow in libxml2
  CVE-2025-6170 [bsc#1244700], stack buffer overflow may lead to a crash
  + libxml2-CVE-2025-6170,6021.patch

Package libzypp was updated:

- runposttrans: strip root prefix from tmppath (bsc#1250343)- fixup! Make ld.so ignore the subarch packages during install
  (bsc#1246912)
- version 17.37.18 (35)

- Make ld.so ignore the subarch packages during install
  (bsc#1246912)
- version 17.37.17 (35)

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 pam was updated:

- Make sure that the buffer containing encrypted passwords get's erased,  before free.
  [pam_modutil_get-overwrite-password-at-free.patch, bsc#1232234,
  CVE-2024-10041]

Package podman was updated:

- Add patch for CVE-2025-9566 (bsc#1249154):  * 0004-CVE-2025-9566-kube-play-don-t-follow-volume-symlinks.patch
- Rebase patches:
  * 0001-CVE-2025-22869-ssh-limit-the-size-of-the-internal-pa.patch
  * 0002-Fix-Remove-appending-rw-as-the-default-mount-option.patch
  * 0003-CVE-2025-6032-machine-init-fix-tls-check.patch

- Add patch for CVE-2025-6032 (bsc#1245320):
  * 0003-CVE-2025-6032-machine-init-fix-tls-check.patch

- Add patch for bsc#1242132:
  * 0002-Fix-Remove-appending-rw-as-the-default-mount-option.patch
- Rebase patches:
  * 0001-CVE-2025-22869-ssh-limit-the-size-of-the-internal-pa.patch
- Removed patches:
  * 0001-vendor-bump-buildah-to-1.37.6-CVE-2024-11218.patch
  * 0002-CVE-2025-27144-vendor-don-t-allow-unbounded-amounts-.patch
  * 0003-CVE-2025-22869-ssh-limit-the-size-of-the-internal-pa.patch
- Drop iptables support in favor of nftables (required by netavark)
- Fix conditional Requires (remove deprecated sle_version macro)
- Update to version 5.4.2:
  * Bump to v5.4.2
  * Add release notes for v5.4.2
  * Fix a potential deadlock during `podman cp`
  * Improve the file format documentation of podman-import.
  * Revert &amp;quot;podman-import only supports gz and tar&amp;quot;
  * Bump buildah to v1.39.4
  * libpod: do not cover idmapped mountpoint
  * test: Fix runc error message
  * oci: report empty exec path as ENOENT
  * test: adapt tests new crun error messages
  * test: remove duplicate test
  * cirrus: test only on f41/rawhide
  * CI: use z1d instance for windows machine testing
  * New images 2025-03-24
  * test/e2e: use go net.Dial() ov nc
  * test: use ncat over nc
  * New images 2025-03-12
  * RPM: Add riscv64 to ExclusiveArch-es
  * Fix HealthCheck log destination, count, and size defaults
  * Win installer test: hardcode latest GH release ID
  * Packit: Fix action script for fetching upstream commit
  * Bump to v5.4.2-dev
  * Bump to v5.4.1
  * update gvproxy version to 0.8.4
  * Update Buildah to v1.39.2
  * Update release notes for v5.4.1
  * Fix reporting summed image size for compat endpoint
  * podman-import only supports gz and tar
  * quadlet kube: correctly mark unit as failed
  * pkg/domain/infra/abi/play.go: fix two nilness issues
  * kube play: don't print start errors twice
  * libpod: race in WaitForConditionWithInterval()
  * libpod: race in WaitForExit() with autoremove
  * Don't try to resolve host path if copying to container from stdin.
  * Use svg for pkginstaller banner
  * Create quota before _data dir for volumes
  * Packit: clarify secondary status in CI
  * Packit/RPM: Display upstream commit SHA in all rpm builds
  * podman run: fix --pids-limit -1 wrt runc
  * vendor: update github.com/go-jose/go-jose/v3 to v3.0.4
  * chore(deps): update module github.com/go-jose/go-jose/v4 to v4.0.5 [security]
  * wire up --retry-delay for artifact pull
  * Revert &amp;quot;silence false positve from golangci-lint&amp;quot;
  * update golangci-lint to v1.64.4
  * update golangci-lint to v1.64.2
  * silence false positve from golangci-lint
  * cmd/podman: refactor Context handling
  * fix new usetesting lint issue
  * Packit/Copr: Fix `podman version` in rpm
  * Remove persist directory when cleaning up Conmon files
  * Bump to v5.4.1-dev
  * Bump to v5.4.0
  * Update release notes for v5.4.0 final
  * In SQLite state, use defaults for empty-string checks
  * Bump FreeBSD version to 13.4
  * docs: add v5.4 to API reference
  * Update rpm/podman.spec
  * RPM: set buildOrigin in LDFLAG
  * RPM: cleanup macro defs
  * Makefile: escape BUILD_ORIGIN properly
  * rootless: fix hang on s390x
  * Set Cirrus DEST_BRANCH appropriately to fix CI
  * Bump to v5.4.0-dev
  * Bump to v5.4.0-rc3
  * Update release notes for v5.4.0-rc3
  * Add BuildOrigin field to podman info
  * artifact: only allow single manifest
  * test/e2e: improve write/removeConf()
  * Add --noheading to artifact ls
  * Add --no-trunc to artifact ls
  * Add type and annotations to artifact add
  * pkg/api: honor cdi devices from the hostconfig
  * util: replace Walk with WalkDir
  * fix(pkg/rootless): avoid memleak during init() contructor.
  * Add `machine init --playbook`
  * RPM: include empty check to silence rpmlint
  * RPM: adjust qemu dependencies
  * Force use of iptables on Windows WSL
  * rpm: add attr as dependency for podman-tests
  * update gvproxy version
  * [v5.4] Bump Buildah to v1.39.0
  * podman exec: correctly support detaching
  * libpod: remove unused ExecStartAndAttach()
  * [v5.4] Bump c/storage to v1.57.1, c/image v5.34.0, c/common v0.62.0
  * Move detection of libkrun and intel
  * Prevent two podman machines running on darwin
  * Remove unnecessary error handling
  * Remove usused Kind() function
  * Bump to v5.4.0-dev
  * Bump to v5.4.0-rc2
  * Update release notes for v5.4.0-rc2
  * Safer use of `filepath.EvalSymlinks()` on Windows
  * error with libkrun on intel-based machines
  * chore(deps): update dependency pytest to v8.3.4
  * test/buildah-bud: skip two new problematic tests on remote
  * Fix podman-restart.service when there are no containers
  * Avoid upgrading from v5.3.1 on Windows
  * Clean up after unexpectedly terminated build
  * system-tests: switch ls with getfattr for selinux tests
  * vendor latest c/{buildah,common,image,storage}
  * Makefile: Add validatepr description for 'make help' output
  * docs: Enhance podman build --secret documentation and add examples
  * docs: mount.md - idmapped mounts only work for root user
  * Define, and use, PodmanExitCleanlyWithOptions
  * Eliminate PodmanSystemdScope
  * Fix image ID query
  * Revert &amp;quot;Use the config digest to compare images loaded/pulled using different methods&amp;quot;
  * Update c/image after https://github.com/containers/image/pull/2613
  * Update expected errors when pulling encrypted images
  * Eliminate PodmanExtraFiles
  * Introduce PodmanTestIntegration.PodmanWithOptions
  * Restructure use of options
  * Inline PodmanBase into callers
  * Pass all of PodmanExecOptions to various [mM]akeOptions functions
  * Turn PodmanAsUserBase into PodmanExecBaseWithOptions
  * Avoid indirect links through quadlet(5)
  * do not set the CreateCommand for API users
  * Add podman manifest rm --ignore
  * Bump to v5.4.0-dev
  * Bump to v5.4.0-rc1
  * fix(deps): update module github.com/containers/gvisor-tap-vsock to v0.8.2
  * podman artifact
  * vendor latest c/{common,image,storage}
  * fix(deps): update module github.com/rootless-containers/rootlesskit/v2 to v2.3.2
  * cirrus: bump macos machine test timeout
  * pkg/machine/e2e: improve podman.exe match
  * pkg/machine/e2e: improve &amp;quot;list machine from all providers&amp;quot;
  * Remove JSON tag from UseImageHosts in ContainerConfig
  * Set network ID if available during container inspect
  * Stop creating a patch for v5.3.1 upgrades on windows
  * compose docs: fix typo
  * Document kube-play CDI support
  * docs: Add quadlet debug method systemd-analyze
  * Replace instances of PodmanExitCleanly in play_kube_test.go
  * docs: add 'initialized' state to status filters
  * fix(deps): update module google.golang.org/protobuf to v1.36.3
  * Switch all calls of assert.Nil to assert.NoError
  * Add --no-hostname option
  * Fix unescaping octal escape sequence in values of Quadlet unit files
  * Remove `.exe` suffix if any
  * Add kube play support for CDI resource allocation
  * add support to `;` for comments in unit files as per systemd documentation
  * Use PodmanExitCleanly in attach_test.go
  * Introduce PodmanTestIntegration.PodmanExitCleanly
  * chore(deps): update dependency setuptools to ~=75.8.0
  * Add newer c/i to support artifacts
  * fix(deps): update module golang.org/x/tools to v0.29.0
  * fix(deps): update module golang.org/x/net to v0.34.0
  * specgenutil: Fix parsing of mount option ptmxmode
  * namespaces: allow configuring keep-id userns size
  * Update description for completion
  * Quadlet - make sure the /etc/containers/systemd/users is traversed in rootless
  * Document .build for Image .container option
  * fix(deps): update module github.com/vbauerster/mpb/v8 to v8.9.1
  * New VM Images
  * update golangci/golangci-lint to v1.63.4
  * fix(deps): update module google.golang.org/protobuf to v1.36.2
  * chore(deps): update dependency setuptools to ~=75.7.0
  * Fixing ~/.ssh/identity handling
  * vendor latest c/common from main
  * fix(deps): update module github.com/shirou/gopsutil/v4 to v4.24.12
  * fix(deps): update module github.com/opencontainers/runc to v1.2.4
  * specgen: fix comment
  * Add hint to restart Podman machine to really accept new certificates
  * fix(deps): update module github.com/onsi/gomega to v1.36.2
  * fix(deps): update module github.com/moby/term to v0.5.2
  * Pass container hostname to netavark
  * Fix slirp4netns typo in podman-network.1.md
  * Add support to ShmSize in Pods with Quadlet
  * fix(deps): update module github.com/onsi/ginkgo/v2 to v2.22.1
  * chore(deps): update module golang.org/x/crypto to v0.31.0 [security]
  * fix(deps): update module golang.org/x/net to v0.33.0 [security]
  * Kube volumes can not container _
  * fix(deps): update module github.com/docker/docker to v27.4.1+incompatible
  * test/system: fix &amp;quot;podman play --build private registry&amp;quot; error
  * test/system: CopyDirectory() do not chown files
  * test/system: remove system dial-stdio test
  * shell completion: respect CONTAINERS_REGISTRIES_CONF
  * fix(deps): update module github.com/cpuguy83/go-md2man/v2 to v2.0.6
  * When generating host volumes for k8s, force to lowercase
  * test: enable newly added test
  * vfkit:â¯Use 0.6.0 binary
  * gvproxy:â¯Use 0.8.1 binary
  * systemd: simplify parser and fix infinite loop
  * Revert &amp;quot;win-installer test: revert to v5.3.0&amp;quot;
  * Avoid rebooting twice when installing WSL
  * Avoid rebooting on Windows when upgrading and WSL isn't installed
  * Add win installer patch
  * Bump WiX toolset version to 5.0.2
  * test/e2e: SkipOnOSVersion() add reason field
  * test/e2e: remove outdated SkipOnOSVersion() calls
  * Update VM images
  * fix(deps): update module golang.org/x/crypto to v0.31.0 [security]
  * fix(deps): update module github.com/crc-org/crc/v2 to v2.45.0
  * fix(deps): update module github.com/opencontainers/runc to v1.2.3
  * quadlet: fix inter-dependency of containers in `Network=`
  * Add man pages to Mac installer
  * fix(deps): update module github.com/onsi/gomega to v1.36.1
  * fix(deps): update module github.com/docker/docker to v27.4.0+incompatible
  * Fix device limitations in podman-remote update on remote systems
  * Use latest version of VS BuildTools
  * bin/docker: fix broken escaping and variable substitution
  * manifest annotate: connect IndexAnnotations
  * Fix panic in `manifest annotate --index`
  * fix(deps): update module github.com/cyphar/filepath-securejoin to v0.3.5
  * fix(deps): update module golang.org/x/net to v0.32.0
  * fix(deps): update module golang.org/x/tools to v0.28.0
  * fix(deps): update module golang.org/x/crypto to v0.30.0
  * fix(deps): update module golang.org/x/sys to v0.28.0
  * Fix overwriting of LinuxResources structure in the database
  * api: replace inspectID with name
  * fix(deps): update github.com/opencontainers/runtime-tools digest to f7e3563
  * Replace ExclusiveArch with ifarch
  * fix(deps): update module github.com/containers/gvisor-tap-vsock to v0.8.1
  * Improve platform specific URL handling in `podman compose` for machines
  * Fix `podman info` with multiple imagestores
  * Switch to fixed common
  * refact: use uptime.minutes instead of uptime.seconds
  * fix(deps): update module github.com/shirou/gopsutil/v4 to v4.24.11
  * fix(deps): update golang.org/x/exp digest to 2d47ceb
  * fix(deps): update github.com/godbus/dbus/v5 digest to c266b19
  * Cover Unix socket in inpect test on Windows platform
  * Add a test for forcing compression and v2s2 format
  * fix(deps): update module github.com/crc-org/vfkit to v0.6.0
  * Package podman-machine on supported architectures only.
  * Fixes missing binary in systemd.
  * stats: ignore errors from containers without cgroups
  * api: Error checking before NULL dereference
  * [skip-ci] Packit/copr: switch to fedora-all
  * make remotesystem: fail early if serial tests fail
  * spec: clamp rlimits without CAP_SYS_RESOURCE
  * Clarify the reason for skip_if_remote
  * Sanity-check that the test is really using partial pulls
  * Fix apparent typos in zstd:chunked tests
  * Fix compilation issues in QEMU machine files (Windows platform)
  * Mount volumes before copying into a container
  * Revert &amp;quot;libpod: remove shutdown.Unregister()&amp;quot;
  * docs: improve documentation for internal networks
  * docs: document bridge mode option
  * [skip-ci] Packit: remove epel and re-enable c9s
  * chore(deps): update dependency golangci/golangci-lint to v1.62.2
  * vendor: update containers/common
  * OWNERS: remove edsantiago
  * fix(deps): update module github.com/onsi/gomega to v1.36.0
  * fix(deps): update github.com/containers/common digest to ceceb40
  * refact: EventerType and improve consistency
  * Add --hosts-file flag to container and pod commands
  * Add nohosts option to /build and /libpod/build
  * fix(deps): update module github.com/stretchr/testify to v1.10.0
  * Quadlet - Use = sign when setting the pull arg for build
  * win-installer test: revert to v5.3.0
  * fix(deps): update module github.com/crc-org/crc/v2 to v2.44.0
  * fix(deps): update module github.com/onsi/ginkgo/v2 to v2.22.0
  * chore(deps): update dependency setuptools to ~=75.6.0
  * Update windows installer tests
  * Windows: don't install WSL/HyperV on update
  * Switch to non-installing WSL by default
  * fix(deps): update github.com/containers/buildah digest to 52437ef
  * Configure HealthCheck with `podman update`
  * CI: --image-volume test: robustify
  * docs: add 5.3 as Reference version
  * Bump CI VMs
  * libpod: pass down NoPivotRoot to Buildah
  * vendor: bump containers/buildah
  * fix(deps): update module github.com/opencontainers/runc to v1.2.2
  * Overlay mounts supersede image volumes &amp;amp; volumes-from
  * libpod: addHosts() prevent nil deref
  * only read ssh_config for non machine connections
  * ssh_config: allow IdentityFile file with tilde
  * ssh_config: do not overwrite values from config file
  * connection: ignore errors when parsing ssh_config
  * Bump bundled krunkit to 0.1.4
  * fix(deps): update module google.golang.org/protobuf to v1.35.2
  * add support for driver-specific options during container creation
  * doc: fix words repetitions
  * Update release notes on main for v5.3.0
  * chore(deps): update dependency setuptools to ~=75.5.0
  * CI: system tests: parallelize 010
  * fix podman machine init --ignition-path
  * vendor: update containers/common
  * spec: clamp rlimits in a userns
  * Add subpath support to volumes in `--mount` option
  * refactor: simplify LinuxNS type definition and String method
  * test/e2e: remove FIPS test
  * vendor containers projects to tagged versions
  * fix(deps): update module github.com/moby/sys/capability to v0.4.0
  * chore(deps): update dependency setuptools to ~=75.4.0
  * system tests: safer install_kube_template()
  * Buildah treadmill tweaks
  * update golangci-lint to v1.62.0
  * fix(deps): update module golang.org/x/net to v0.31.0
  * fix(deps): update module golang.org/x/tools to v0.27.0
  * Revert &amp;quot;Reapply &amp;quot;CI: test nftables driver on fedora&amp;quot;&amp;quot;
  * Yet another bump, f41 with fixed kernel
  * test: add zstd:chunked system tests
  * pkg/machine/e2e: remove dead code
  * fix(deps): update module golang.org/x/crypto to v0.29.0
  * kube SIGINT system test: fix race in timeout handling
  * New `system connection add` tests
  * Update codespell to v2.3.0
  * Avoid printing PR text to stdout in system test
  * Exclude symlink from pre-commit end-of-file-fixer
  * api: Add error check
  * [CI:ALL] Bump main to v5.4.0-dev
  * test/buildah-bud: build new inet helper
  * test/system: add regression test for TZDIR local issue
  * vendor latest c/{buildah,common,image,storage}
  * Reapply &amp;quot;CI: test nftables driver on fedora&amp;quot;
  * Revert &amp;quot;cirrus: test only on f40/rawhide&amp;quot;
  * test f41 VMs
  * AdditionalSupport for SubPath volume mounts
  * wsl-e2e: Add a test to ensure port 2222 is free with usermode networking
  * winmake.ps1: Fix the syntax of the function call Win-SSHProxy
  * volume ls: fix race that caused it to fail
  * gvproxy: Disable port-forwarding on WSL
  * build: update gvisor-tap-vsock to 0.8.0
  * podman: update roadmap
  * Log network creation and removal events in Podman
  * libpod: journald do not lock thread
  * Add key to control if a container can get started by its pod
  * Honor users requests in quadlet files
  * CI: systests: workaround for parallel podman-stop flake
  * Fix inconsistent line ending in win-installer project
  * fix(deps): update module github.com/opencontainers/runc to v1.2.1
  * Quadlet - support image file based mount in container file
  * API: container logs flush status code
  * rework event code to improve API errors
  * events: remove memory eventer
  * libpod: log file use Wait() over event API
  * Makefile: vendor target should always remove toolchain
  * cirrus: check consitent vendoring in test/tools
  * test/tools/go.mod: remove toolchain
  * fix(deps): update module github.com/shirou/gopsutil/v4 to v4.24.10
  * fix(deps): update module github.com/onsi/gomega to v1.35.1
  * doc: explain --interactive in more detail
  * fix(deps): update golang.org/x/exp digest to f66d83c
  * fix(deps): update github.com/opencontainers/runtime-tools digest to 6c9570a
  * fix(deps): update github.com/linuxkit/virtsock digest to cb6a20c
  * add default polling interval to Container.Wait
  * Instrument cleanup tracer to log weird volume removal flake
  * make podman-clean-transient.service work as user
  * Add default remote socket path if empty
  * Use current user if no user specified
  * Add support for ssh_config for connection
  * libpod: use pasta Setup() over Setup2()
  * fix(deps): update module github.com/onsi/ginkgo/v2 to v2.21.0
  * fix(deps): update module github.com/onsi/gomega to v1.35.0
  * logformatter: add cleanup tracer log link
  * docs: fix broken example
  * docs: add missing swagger links for the stable branches
  * readthedocs: build extra formats
  * pkg/machine/e2e: remove debug
  * fix(docs): Integrate pasta in rootless tutorial
  * chore(deps): update dependency setuptools to ~=75.3.0
  * libpod: report cgroups deleted during Stat() call
  * chore: fix some function names in comment
  * CI: parallelize 450-interactive system tests
  * CI: parallelize 520-checkpoint tests
  * CI: make 070-build.bats use safe image names
  * test/system: add podman network reload test to distro gating
  * System tests: clean up unit file leaks
  * healthcheck: do not leak service on failed stop
  * healthcheck: do not leak statup service
  * fix(deps): update module github.com/containers/gvisor-tap-vsock to v0.8.0
  * Add Startup HealthCheck configuration to the podman inspect
  * buildah version display: use progress()
  * new showrun() for displaying and running shell commands
  * Buildah treadmill: redo the .cirrus.yml tweaks
  * Buildah treadmill: more allow-empty options
  * Buildah treadmill: improve test-failure instructions
  * Buildah treadmill: improve wording in test-fail instructions
  * doc: Remove whitespace before comma
  * fix(deps): update module github.com/checkpoint-restore/checkpointctl to v1.3.0
  * ps: fix display of exposed ports
  * ps: do not loop over port protocol
  * readme: Add reference to pasta in the readme
  * test/system: Fix spurious &amp;quot;duplicate tests&amp;quot; failures in pasta tests
  * Improve &amp;quot;podman load - from URL&amp;quot;
  * Try to repair c/storage after removing an additional image store
  * Use the config digest to compare images loaded/pulled using different methods
  * Simplify the additional store test
  * Fix the store choice in &amp;quot;podman pull image with additional store&amp;quot;
  * Bump to v5.3.0-dev
  * Bump to v5.3.0-rc1
  * Set quota on volume root directory, not _data
  * fix(deps): update module github.com/opencontainers/runc to v1.2.0
  * test: set soft ulimit
  * Vagrantfile: Delete
  * Enable pod restore with crun
  * vendor: update c/{buildah,common,image,storage}
  * Fix 330-corrupt-images.bats in composefs test runs
  * quadlet: add default network dependencies to all units
  * quadlet: ensure user units wait for the network
  * add new podman-user-wait-network-online.service
  * contrib/systemd: switch user symlink for file symlinks
  * Makefile: remove some duplication from install.systemd
  * contrib/systemd: move podman-auto-update units
  * quadlet: do not reject RemapUsers=keep-id as root
  * test/e2e: test quadlet with and without --user
  * CI: e2e: fix checkpoint flake
  * APIv2 test fix: image history
  * pasta udp tests: new bytecheck helper
  * Document packaging process
  * [skip-ci] RPM: remove dup Provides
  * Update dependency setuptools to ~=75.2.0
  * System tests: safer pause-image creation
  * Update module github.com/opencontainers/selinux to v1.11.1
  * Added escaping to invoked powershell command for hyperv stubber.
  * use slices.Clone instead of assignment
  * libpod API: only return exit code without conditions
  * Housekeeping: remove duplicates from success_task
  * Thorough overhaul of CONTRIBUTING doc.
  * api: Replace close function in condition body
  * test/e2e: fix default signal exit code test
  * Test new VM build
  * CI: fix changing-rootFsSize flake
  * scp: add option types
  * Unlock mutex before returning from function
  * Note in the README that we are moving to timed releases
  * cirrus: let tar extract figure out the compression
  * Make error messages more descriptive
  * Mention containers.conf settings for podman machine commands
  * [skip-ci] Packit: re-enable CentOS Stream 10/Fedora ELN teasks&amp;quot;
  * cmd: use logrus to print error
  * podman: do not set rlimits to the default value
  * spec: always specify default rlimits
  * vendor: update containers/common
  * Note in the README that we are moving to timed releases
  * Revert &amp;quot;CI: test nftables driver on fedora&amp;quot;
  * cirrus: use zstd over bzip2 for repo archive
  * cirrus: use shared repo_prep/repo_artifacts scripts
  * cirrus: speed up postbuild
  * cirrus: change alt arch task to only compile binaries
  * cirrus: run make with parallel jobs where useful
  * Makefile: allow man-page-check to be run in parallel
  * cirrus: use fastvm for builds
  * test/e2e: skip some Containerized checkpoint tests
  * test: update timezone checks
  * cirrus: update CI images
  * test/e2e: try debug potential pasta issue
  * CI: quadlet system tests: use airgapped testimage
  * Allow removing implicit quadlet systemd dependencies
  * fix(deps): update module github.com/cyphar/filepath-securejoin to v0.3.4
  * libpod API: make wait endpoint better against rm races
  * podman-remote run: improve how we get the exit code
  * [skip-ci] Packit: constrain koji and bodhi jobs to fedora package to avoid dupes
  * 055-rm test: clean up a test, and document
  * CI: remove skips for libkrun
  * Bump bundled krunkit to 0.1.3
  * fix(deps): update module google.golang.org/protobuf to v1.35.0
  * fix(deps): update module golang.org/x/net to v0.30.0
  * server: fix url parsing in info
  * fix(deps): update module golang.org/x/tools to v0.26.0
  * Makefile: fix ginkgo FOCUS option
  * fix(deps): update module golang.org/x/crypto to v0.28.0
  * podman-systemd.unit.5: adjust example options
  * docs: prefer --network to --net
  * fix(deps): update module golang.org/x/term to v0.25.0
  * fix(deps): update module github.com/mattn/go-sqlite3 to v1.14.24
  * fix(deps): update module golang.org/x/sys to v0.26.0
  * OWNERS file audit and update
  * Exposed ports are only included when not --net=host
  * libpod: hasCurrentUserMapped checks for gid too
  * [CI:DOCS] Document TESTFLAGS in test README file
  * Validate the bind-propagation option to `--mount`
  * Fix typo in secret inspect examples
  * Mention `no_hosts` and `base_hosts_file` configs in CLI option docs
  * Fixes for vendoring Buildah
  * vendor: update buildah to latest
  * Makefile - silence skipped tests when focusing on a file
  * vendor: update to latest c/common
  * Quadlet - prefer &amp;quot;param val&amp;quot; over &amp;quot;param=val&amp;quot; to allow env expansion
  * System tests: sdnotify: wait for socket file creation
  * Switch to moby/sys/capability
  * platformInspectContainerHostConfig: rm dead code
  * CI: require and test CI_DESIRED_NETWORK on RHEL
  * Add ExposedPorts to Inspect's ContainerConfig
  * fix(deps): update golang.org/x/exp digest to 701f63a
  * quadlet: allow variables in PublishPort
  * fix(deps): update module github.com/shirou/gopsutil/v4 to v4.24.9
  * fix(deps): update github.com/godbus/dbus/v5 digest to a817f3c
  * Document that zstd:chunked is downgraded to zstd when encrypting
  * fix(deps): update module github.com/cyphar/filepath-securejoin to v0.3.3
  * chore(deps): update dependency ubuntu to v24
  * rpm: do not load iptables modules on f41+
  * adding docs for network-cmd-path
  * Include exposed ports in inspect output when net=host
  * feat(libpod): support kube play tar content-type (#24015)
  * podman mount: some better error wrapping
  * podman mount: ignore ErrLayerUnknown
  * Quadlet - make sure the order of the UnitsDir is deterministic
  * packit: disable Centos Stream/fedora ELN teasks
  * libpod: remove shutdown.Unregister()
  * libpod: rework shutdown handler flow
  * libpod: ensure we are not killed during netns creation
  * Update module github.com/moby/sys/capability to v0.3.0
  * Update documentation of `--no-hosts`, `--hostname`, and `--name` CLI options
  * Update documentation of `--add-host` CLI option
  * System tests: set a default XDG_RUNTIME_DIR
  * Modify machine &amp;quot;Remove machine&amp;quot; test
  * CORS system test: clean up
  * Add --health-max-log-count, --health-max-log-size, --health-log-destination flags
  * troubleshooting: adjust home path in tip 44
  * test/system: For pasta port forwarding tests don't bind socat server
  * Update connection on removal
  * Simplify `RemoveConnections`
  * Move `DefaultMachineName` to `pkg/machine/define`
  * vendor: update containers/image
  * vendor: update containers/storage
  * CI: skip the flaking quadlet test
  * CI: make systemd tests parallel-safe (*)
  * CI: run and collect cleanup tracer logs
  * add epbf program to trace podman cleanup errors
  * CI: parallelize logs test as much as possible
  * CI: format test: use local registry if available
  * CI: make 700-play parallel-safe
  * docs: Fix missing negation
  * bin/docker support warning message suppression from user config dir
  * Update module github.com/docker/docker to v27.3.1+incompatible
  * Quadlet - add full support for Symlinks
  * libpod: setupNetNS() correctly mount netns
  * vendor latest c/common
  * docs: remove usage of deprecated `--storage`
  * Update module github.com/docker/docker to v27.3.0+incompatible
  * CI: Quadlet rootfs test: use container image as rootfs
  * CI: system test registry: use --net=host
  * CI: rm system test: bump grace period
  * CI: system tests: minor documentation on parallel
  * fix typo in error message Fixes: containers/podman#24001
  * CI: system tests: always create pause image
  * CI: quadlet system test: be more forgiving
  * vendor latest c/common
  * CI: make 200-pod parallel-safe
  * allow exposed sctp ports
  * test/e2e: add netns leak check
  * test/system: netns leak check for rootless as well
  * test/system: Improve TODO comments on IPv6 pasta custom DNS forward test
  * test/system: Clarify &amp;quot;Local forwarder&amp;quot; pasta tests
  * test/system: Simplify testing for nameserver connectivity
  * test/system: Consolidate &amp;quot;External resolver&amp;quot; pasta tests
  * test/system: Move test for default forwarder into its own case
  * CI: make 090-events parallel-safe
  * Misc minor test fixes
  * Add network namespace leak check
  * Add workaround for buildah parallel bug
  * registry: lock start attempts
  * Update system test template and README
  * bats log: differentiate parallel tests from sequential
  * ci: bump system tests to fastvm
  * clean_setup: create pause image
  * CI: make 012-manifest parallel-safe
  * podman-manifest-remove: update docs and help output
  * test/system: remove wait workaround
  * wait: fix handling of multiple conditions with exited
  * Match output of Compat Top API to Docker
  * system test parallelization: enable two-pass approach
  * New VMs: test crun 1.17
  * libpod: hides env secrets from container inspect
  * CI: e2e: workaround for events out-of-sequence flake
  * update golangci-lint to 1.61.0
  * libpod: convert owner IDs only with :idmap
  * Podman CLI --add-host with multiple host for a single IP
  * Quadlet - Split getUnitDirs to small functions
  * fix(deps): update module github.com/cpuguy83/go-md2man/v2 to v2.0.5
  * chore(deps): update dependency setuptools to ~=75.1.0
  * Fxi typo in cache-ttl.md
  * Get WSL disk as an OCI artifact
  * CI: make 260-sdnotify parallel-safe
  * quadlet: do not log ENOENT errors
  * pkg/specgen: allow pasta when running inside userns
  * troubleshooting: add tip about the user containers
  * chore(deps): update dependency setuptools to v75
  * Convert windows paths in volume arg of the build command
  * Improve error when starting multiple machines
  * fix(deps): update module github.com/cyphar/filepath-securejoin to v0.3.2
  * Minor typo noticed when reading podman man page
  * Remove `RemoveFilesAndConnections`
  * Add `GetAllMachinesAndRootfulness`
  * rewrite typo osascript
  * typo
  * fix(deps): update module github.com/docker/docker to v27.2.1+incompatible
  * Add radio buttons to select WSL or Hyper-V in windows setup.exe
  * [skip-ci] Packit: split out ELN jobs and reuse fedora downstream targets
  * [skip-ci] Packit: Enable sidetags for bodhi updates
  * vendor: update c/common
  * CI: make 710-kube parallel-safe
  * CI: mark 320-system-df *NOT* parallel safe
  * Add kube play support for image volume source
  * refactor: add sshClient function
  * fix(deps): update module golang.org/x/tools to v0.25.0
  * CI: make 505-pasta parallel safe
  * CI: make 020-tag parallel-safe
  * CI: make 410-selinux parallel-safe
  * Bump VMs. ShellCheck is now built-in
  * troubleshooting: add tip about auto, keep-id, nomap
  * libpod: make use of new pasta option from c/common
  * vendor latest c/common
  * podman images: sort repository with tags
  * Remove containers/common/pkg/config from pkg/util
  * fix(deps): update module golang.org/x/net to v0.29.0
  * fix(deps): update module github.com/mattn/go-sqlite3 to v1.14.23
  * fix(deps): update module golang.org/x/crypto to v0.27.0
  * Fix CI
  * Detect and fix typos using codespell
  * Fix typo: replace buildin with built-in
  * Add codespell config, pre-commit definition, and move options from Makefile
  * prune: support clearing build cache using CleanCacheMount
  * test/e2e: fix network prune flake
  * Add support for Job to kube generate &amp;amp; play
  * Add podman-rootless.7 man page
  * Add DNS, DNSOption and DNSSearch to quadlet pod
  * podman.1.md: improve policy.json section
  * e2e: flake fix: SIGPIPE in hook test
  * libpod: fix rootless cgroup path with --cgroup-parent
  * vendor: update c/storage
  * CI: make 055-rm parallel-safe
  * CI: make 130-kill parallel-safe
  * CI: make 125-import parallel-safe
  * CI: make 110-history parallel-safe
  * CI: system tests: parallelize low-hanging fruit
  * Add disclaimer to `podman machine info` manpage.
  * man pages: refactor two more options
  * update github.com/opencontainers/runc to v1.2.0-rc.3
  * update go.etcd.io/bbolt to v1.3.11
  * update github.com/onsi/{ginkgo,gomega}
  * Update module github.com/shirou/gopsutil to v4
  * packit: update fedora and epel targets
  * bump go to 1.22
  * cirrus: test only on f40/rawhide
  * cirrus: remove CI_DESIRED_NETWORK reference
  * cirrus: prebuild use f40 for extra tests
  * chore(deps): update dependency setuptools to ~=74.1.0
  * libpod: fix HostConfig.Devices output from 'podman inspect' on FreeBSD
  * fix(deps): update golang.org/x/exp digest to 9b4947d
  * Implement publishing API UNIX socket on Windows platforms
  * Vendor c/common:8483ef6022b4
  * quadlet: support container network reusing
  * docs: update read the docs changes
  * CI: parallel-safe network system test
  * Quadlet - Support multiple image tags in .build files
  * fix(deps): update module github.com/vbauerster/mpb/v8 to v8.8.3
  * cirrus: remove _bail_if_test_can_be_skipped
  * cirrus: move renovate check into validate
  * cirrus: remove 3rd party connectivity check
  * cirrus: remove cross jobs for aarch64 and x86_64
  * cirrus: do not upload alt arch cross artifacts
  * cirrus: remove ginkgo-e2e.json artifact
  * cirrus: fix default timeouts
  * github: remove fcos-podman-next-build-prepush
  * Clarify podman machine volume mounting behavior under WSL
  * machine: Add -all-providers flag to machine list
  * Create a podman-troubleshooting man page
  * chore(deps): update dependency setuptools to v74
  * fix(deps): update module github.com/docker/docker to v27.2.0+incompatible
  * Fix an improperly ignored error in SQLite
  * CI: flake workaround: ignore socat waitpid warnings
  * fix(deps): update module github.com/rootless-containers/rootlesskit/v2 to v2.3.1
  * Stop skipping machine volume test on Hyper-V
  * cleanup: add new --stopped-only option
  * fix races in the HTTP attach API
  * cirrus: skip windows/macos machine task on RHEL branches
  * Update module github.com/containers/gvisor-tap-vsock to v0.7.5
  * run: fix detach passthrough and --rmi
  * podman run: ignore image rm error
  * Add support for AddHost in quadlet .pod and .container
  * [CI:DOCS] Update dependency golangci/golangci-lint to v1.60.3
  * update github.com/vishvananda/netlink to v1.3.0
  * build: Update gvisor-tap-vsock to 0.7.5
  * Quote systemd DefaultEnvironment Proxy values, as documented in systemd.conf man page:
  * fix typo in podman-network-create.1.md
  * Use HTTP path prefix of TCP connections to match Docker context behavior
  * Makefile: remotesystem: use real podman server, no --url
  * Update module github.com/openshift/imagebuilder to v1.2.15
  * CI: parallel-safe userns test
  * Update module github.com/onsi/ginkgo/v2 to v2.20.1
  * Add support for IP in quadlet .pod files
  * Specify format to use for referencing fixed bugs.
  * CI: parallel-safe run system test
  * Revert &amp;quot;test/e2e: work around for pasta issue&amp;quot;
  * CI: On vX.Y-rhel branches, ensure that some downstream Jira issue is linked
  * quadlet: support user mapping in pod unit
  * Update Release Process
  * Test new VM build
  * command is not optional to podman exec
  * CI: parallel-safe namespaces system test
  * [CI:DOCS] Update dependency golangci/golangci-lint to v1.60.2
  * quadlet: add key CgroupsMode
  * Fix `podman stop` and `podman run --rmi`
  * quadlet: set infra name to %s-infra
  * chore(deps): update dependency setuptools to v73
  * [skip-ci] Packit: update targets for propose-downstream
  * Do not segfault on hard stop
  * Fix description of :Z to talk about pods
  * CI: disable ginkgo flake retries
  * vendor: update go-criu to latest
  * golangci-lint: make darwin linting happy
  * golangci-lint: make windows linting happy
  * test/e2e: remove kernel version check
  * golangci-lint: remove most skip dirs
  * set !remote build tags where needed
  * update golangci-lint to 1.60.1
  * test/e2e: rm systemd start test
  * fix(deps): update module github.com/vbauerster/mpb/v8 to v8.8.1
  * podman wait: allow waiting for removal of containers
  * libpod: remove UpdateContainerStatus()
  * podman mount: fix storage/libpod ctr race
  * CI: quadlet tests: make parallel-safe
  * CI: system tests: make random_free_port() parallel-safe
  * remove trailing comma in example
  * CI: format test: make parallel-safe
  * Fix podman-docker.sh under -eu shells (fixes #23628)
  * docs: update podman-wait man page
  * libpod: remove duplicated HasVolume() check
  * podman volume rm --force: fix ABBA deadlock
  * test/system: fix network cleanup restart test
  * libpod: do not stop pod on init ctr exit
  * libpod: simplify WaitForExit()
  * CI: remove build-time quay check
  * Fix known_hosts file clogging and remote host id
  * Update docker.io/library/golang Docker tag to v1.23
  * Update dependency setuptools to ~=72.2.0
  * Update module github.com/docker/docker to v27.1.2+incompatible
  * healthcheck system check: reduce raciness
  * CI: healthcheck system test: make parallel-safe
  * Validate renovate config in every PR
  * pkg/machine: Read stderr from ssh-keygen correctly
  * Fix renovate config syntax error
  * CI: 080-pause.bats: make parallel-safe
  * CI: 050-stop.bats: make parallel-safe
  * Additional potential race condition on os.Readdir
  * pkg/bindings/containers: handle ignore for stop
  * remote: fix invalid --cidfile + --ignore
  * Update/simplify renovate config header comment
  * Migrate renovate config to latest schema
  * Fix race condition when listing /dev
  * docs/podman-systemd: Try to clarify `Exec=` more
  * libpod: reset state error on init
  * test/system: pasta_test_do add explicit port check
  * test/e2e: work around new push warning
  * vendor: update c/common to latest
  * stopIfOnlyInfraRemains: log all errors
  * libpod: do not save expected stop errors in ctr state
  * libpod: fix broken saveContainerError()
  * Quadlet: fix filters failure when the search paths are symlinks
  * readme: replace GPG with PGP
  * Drop APIv2 CNI configuration
  * De-duplicate docker-py testing
  * chore(podmansnoop): explain why crun comm is 3
  * libpod: cleanupNetwork() return error
  * fix(deps): update module golang.org/x/sys to v0.24.0
  * Reduce python APIv2 test net dependency
  * Fix not testing registry.conf updates
  * test/e2e: improve command timeout handling
  * Update module github.com/onsi/ginkgo/v2 to v2.20.0
  * Update module github.com/moby/sys/user to v0.3.0
  * Add passwd validate and generate steps
  * podman container cleanup: ignore common errors
  * Quadlet - Allow the user to override the default service name
  * CI: e2e: serialize root containerPort tests
  * Should not force conversion of manifest type to DockerV2ListMediaType
  * fix(deps): update module golang.org/x/tools to v0.24.0
  * fix(deps): update github.com/containers/common digest to 05b2e1f
  * CI: mount system test: parallelize
  * Update module golang.org/x/net to v0.28.0
  * Ignore ERROR_SHARING_VIOLATION error on windows
  * CI: manifest system tests: make parallel-safe
  * Create volume path before state initialization
  * vendor: update c/storage
  * CI: fix broken libkrun test
  * test/e2e: work around for pasta issue
  * test/e2e: fix missing exit code checks
  * Test new CI images
  * Remove another race condition when mounting containers or images
  * fix(deps): update github.com/containers/common digest to c0cc6b7
  * Change Windows installer MajorUpgrade Schedule
  * Ignore missing containers when calling GetExternalContainerLists
  * Remove runc edit to lock to specific version
  * fix(deps): update module golang.org/x/sys to v0.23.0
  * CI: podman-machine: do not use cache registry
  * CI: completion system test: use safename
  * Temporarly disable failing Windows Installer CI test
  * libpod: fix volume copyup with idmap
  * libpod: avoid hang on errors
  * Temp. disable PM basic Volume ops test
  * Add libkrun Mac task
  * Never skip checkout step in release workflow
  * System tests: leak_test: readable output
  * fix(deps): update github.com/docker/go-plugins-helpers digest to 45e2431
  * vendor: bump c/common
  * Version: bump to v5.3.0-dev
  * libpod: inhibit SIGTERM during cleanup()
  * Tweak versions in register_images.go
  * fix network cleanup flake in play kube
  * WIP: Fixes for vendoring Buildah
  * Add --compat-volumes option to build and farm build
  * Bump to Buildah v1.37.0
  * Quadlet test - Split between success, warning and error cases
  * libpod: bind ports before network setup
  * Disable compose-warning-logs if PODMAN_COMPOSE_WARNING_LOGS=false
  * Use new syntax for selinux options in quadlet
  * fix(deps): update module github.com/onsi/gomega to v1.34.1
  * CI: kube test: fix broken external-storage test
  * Update dependency setuptools to v72
  * Convert additional build context paths on Windows
  * pkg/api: do not leak config pointers into specgen
  * Quadlet - Allow the user to set the service name for .pod files
  * Quadlet tests - allow overriding the expected service name
  * fix(deps): update module github.com/moby/sys/user to v0.2.0
  * fix(deps): update module github.com/vbauerster/mpb/v8 to v8.7.5
  * CI: enable root user namespaces
  * libpod: force rootfs for OCI path with idmap
  * fix(deps): update module github.com/onsi/ginkgo/v2 to v2.19.1
  * Add test steps for automount with multi images
  * CI: cp tests: use safename
  * [skip-ci] RPM: podman-iptables.conf only on Fedora
  * CI: 700-play: fix a leaked non-safename
  * test: check that kube generate/play restores the userns
  * test: disable artifacts cache with composefs
  * test: fix podman pull tests
  * vendor: bump c/storage
  * Update module github.com/cyphar/filepath-securejoin to v0.3.1
  * Add /run/containers/systemd, ${XDG_RUNTIME_DIR}/containers/systemd quadlet dirs
  * build: Update gvisor-tap-vsock to 0.7.4
  * test/system: fix borken pasta interface name checks
  * test/system: fix bridge host.containers.internal test
  * api: honor the userns for the infra container
  * play: handle 'private' as 'auto'
  * kube: record infra user namespace
  * infra: user ns annotation higher precedence
  * specgenutil: record the pod userns in the annotations
  * kube: invert branches
  * CI: system log test: use safe names
  * Update encryption tests to avoid a warning if zstd:chunked is the default
  * Fix &amp;quot;podman pull and decrypt&amp;quot;/&amp;quot;from local registry&amp;quot;
  * Use unique image names for the encrypted test images
  * CI: system tests: instrument to allow failure analysis
  * Fix outdated comment for the build step win-gvproxy
  * Add utility to convert VMFile to URL for UNIX sockets
  * Run codespell on source
  * fix(deps): update module github.com/docker/docker to v27.1.0+incompatible
  * chore(deps): update dependency setuptools to ~=71.1.0
  * logformatter: tweaks to pass html tidy
  * More information for podman --remote build and running out of space.
  * Fix windows installer deleting machine provider config file
  * Use uploaded .zip for Windows action
  * pr-should-include-tests: no more CI:DOCS override

- Depend on runc unconditionally, not only on SLE 15 (bsc#1239088)

Package libxml2:python 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-6021 [bsc#1244580], Integer Overflow in xmlBuildQName() Leads to Stack Buffer Overflow in libxml2
  CVE-2025-6170 [bsc#1244700], stack buffer overflow may lead to a crash
  + libxml2-CVE-2025-6170,6021.patch

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)

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

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 runc was updated:

- Update to runc v1.3.3. Upstream changelog is available from  &amp;lt;https://github.com/opencontainers/runc/releases/tag/v1.3.3&amp;gt;. bsc#1252232
  * CVE-2025-31133
  * CVE-2025-52565
  * CVE-2025-52881
- Remove upstreamed patches for bsc#1252232:
  - 2025-11-05-CVEs.patch

[ This update was only released for SLE 12 and 15. ]
- Backport patches for three CVEs. All three vulnerabilities ultimately allow
  (through different methods) for full container breakouts by bypassing runc's
  restrictions for writing to arbitrary /proc files. bsc#1252232
  * CVE-2025-31133
  * CVE-2025-52565
  * CVE-2025-52881
  + 2025-11-05-CVEs.patch

[ This update was only released for SLE 12 and 15. ]
- Update to runc v1.2.7. Upstream changelog is available from
  &amp;lt;https://github.com/opencontainers/runc/releases/tag/v1.2.7&amp;gt;.

- Update to runc v1.3.2. Upstream changelog is available from
  &amp;lt;https://github.com/opencontainers/runc/releases/tag/v1.3.2&amp;gt; bsc#1252110
  - Includes an important fix for the CPUSet translation for cgroupv2.

- Update to runc v1.3.1. Upstream changelog is available from
  &amp;lt;https://github.com/opencontainers/runc/releases/tag/v1.3.1&amp;gt;
- Fix runc 1.3.x builds on SLE-12 by enabling --std=gnu11.

- Update to runc v1.3.0. Upstream changelog is available from
  &amp;lt;https://github.com/opencontainers/runc/releases/tag/v1.3.0&amp;gt;

Package selinux-policy was updated:

- Update to version 20241031+git12.52417acff:  * Mark configfs_t as mountpoint (bsc#1246080, bsc#1250628)

- Update to version 20241031+git10.f4f74e9f2:
  * Label /var/livepatches as lib_t for ULP on micro (bsc#1228879, bsc#1249832)

Package supportutils-plugin-suse-public-cloud was updated:

- Update to version 1.0.9 (bsc#1218762, bsc#1218763)  + Remove duplicate data collection for the plugin itself
  + Collect archive metering data when available
  + Query billing flavor status

Package suse-build-key was updated:

- adjust UID (name + email) of SLES16 signing key with official  names. (bsc#1245223)

Package vim was updated:

- Add patches:  * vim-9.1.1134-revert-putty-terminal-colors.patch
  * reorder-exit-raw-mode.patch
- Remove obsoleted patches:
  * vim-7.3-help_tags.patch
  * vim-7.4-highlight_fstab.patch
  * vim-7.3-mktemp_tutor.patch
- Refresh patches:
  * vim-7.3-sh_is_bash.patch
- Fix the following CVEs and bugs:
  * bsc#1246602 (CVE-2025-53906)
  * bsc#1246604 (CVE-2025-53905)
  * bsc#1247939 (CVE-2025-55158)
  * bsc#1247938 (CVE-2025-55157)
- Update to 9.1.1629:
  9.1.1629: Vim9: Not able to use more than 10 type arguments in a generic function
  9.1.1628: fuzzy.c has a few issues
  9.1.1627: fuzzy matching can be improved
  9.1.1626: cindent: does not handle compound literals
  9.1.1625: Autocompletion slow with include- and tag-completion
  9.1.1624: Cscope not enabled on MacOS
  9.1.1623: Buffer menu does not handle unicode names correctly
  9.1.1622: Patch v9.1.1432 causes performance regressions
  9.1.1621: flicker in popup menu during cmdline autocompletion
  9.1.1620: filetype: composer.lock and symfony.lock files not recognized
  9.1.1619: Incorrect E535 error message
  9.1.1618: completion: incorrect selected index returned from complete_info()
  9.1.1617: Vim9: some error messages can be improved
  9.1.1616: xxd: possible buffer overflow with bitwise output
  9.1.1615: diff format erroneously detected
  9.1.1614: Vim9: possible variable type change
  9.1.1613: tests: test_search leaves a few swapfiles behind
  9.1.1612: Ctrl-G/Ctrl-T do not ignore the end search delimiter
  9.1.1611: possible undefined behaviour in mb_decompose()
  9.1.1610: completion: hang or E684 when 'tagfunc' calls complete()
  9.1.1609: complete: Heap-buffer overflow with complete function
  9.1.1608: No command-line completion for :unsilent {command}
  9.1.1607: :apple command detected as :append
  9.1.1606: filetype: a few more files are not recognized
  9.1.1605: cannot specify scope for chdir()
  9.1.1604: completion: incsearch highlight might be lost
  9.1.1603: completion: cannot use autoloaded funcs in 'complete' F{func}
  9.1.1602: filetype: requirements-*.txt files are not recognized
  9.1.1601: Patch v8.1.0425 was wrong
  9.1.1600: using diff anchors with hidden buffers fails silently
  9.1.1599: :bnext doesn't go to unlisted help buffers
  9.1.1598: filetype: waybar config file is not recognized
  9.1.1597: CI reports leaks in libgtk3 library
  9.1.1596: tests: Test_search_wildmenu_iminsert() depends on help file
  9.1.1595: Wayland: non-portable use of select()
  9.1.1594: completion: search completion throws errors
  9.1.1593: Confusing error when compiling incomplete try block
  9.1.1592: Vim9: crash with classes and garbage collection
  9.1.1591: VMS support can be improved
  9.1.1590: cannot perform autocompletion
  9.1.1589: Cannot disable cscope interface using configure
  9.1.1588: Vim9: cannot split dict inside command block
  9.1.1587: Wayland: timeout not updated before select()
  9.1.1586: Vim9: can define an enum/interface in a function
  9.1.1585: Wayland: gvim still needs GVIM_ENABLE_WAYLAND
  9.1.1584: using ints as boolean type
  9.1.1583: gvim window lost its icons
  9.1.1582: style issue in vim9type.c and vim9generics.c
  9.1.1581: possible memory leak in vim9generics.c
  9.1.1580: possible memory leak in vim9type.c
  9.1.1579: Coverity complains about unchecked return value
  9.1.1578: configure: comment still mentions autoconf 2.71
  9.1.1577: Vim9: no generic support yet
  9.1.1576: cannot easily trigger wildcard expansion
  9.1.1575: tabpanel not drawn correctly with wrapped lines
  9.1.1574: Dead code in mbyte.c
  9.1.1573: Memory leak when pressing Ctrl-D in cmdline mode
  9.1.1572: expanding $var does not escape whitespace for 'path'
  9.1.1571: CmdlineChanged triggered to often
  9.1.1570: Copilot suggested some improvements in cmdexpand.c
  9.1.1569: tests: Vim9 tests can be improved
  9.1.1568: need a few more default highlight groups
  9.1.1567: crash when using inline diff mode
  9.1.1566: self-referenced enum may not get freed
  9.1.1565: configure: does not consider tiny version for wayland
  9.1.1564: crash when opening popup to closing buffer
  9.1.1563: completion: ruler may disappear
  9.1.1562: close button always visible in the 'tabline'
  9.1.1561: configure: wayland test can be improved
  9.1.1560: configure: uses $PKG_CONFIG before it is defined
  9.1.1559: tests: Test_popup_complete_info_01() fails when run alone
  9.1.1558: str2blob() treats NULL string and empty string differently
  9.1.1557: not possible to anchor specific lines in difff mode
  9.1.1556: string handling in cmdexpand.c can be improved
  9.1.1555: completion: repeated insertion of leader
  9.1.1554: crash when omni-completion opens command-line window
  9.1.1553: Vim9: crash when accessing a variable in if condition
  9.1.1552: [security]: path traversal issue in tar.vim
  9.1.1551: [security]: path traversal issue in zip.vim
  9.1.1550: defaults: 'showcmd' is not enabled in non-compatible mode on Unix
  9.1.1549: filetype: pkl files are not recognized
  9.1.1548: filetype: OpenFGA files are not recognized
  9.1.1547: Wayland: missing ifdef
  9.1.1546: Vim9: error with has() and short circuit evaluation
  9.1.1545: typo in os_unix.c
  9.1.1544: :retab cannot be limited to indentation only
  9.1.1543: Wayland: clipboard appears to not be working
  9.1.1542: Coverity complains about uninitialized variable
  9.1.1541: Vim9: error when last enum value ends with a comma
  9.1.1540: completion: menu state wrong on interruption
  9.1.1539: completion: messages don't respect 'shm' setting
  9.1.1537: helptoc: still some issues when markdown code blocks
  9.1.1536: tests: test_plugin_comment uses wrong :Check command
  9.1.1535: the maximum search count uses hard-coded value 99
  9.1.1534: unnecessary code in tabpanel.c
  9.1.1533: helptoc: does not handle code sections in markdown well
  9.1.1532: termdebug: not enough ways to configure breakpoints
  9.1.1531: confusing error with nested legacy function
  9.1.1530: Missing version change in v9.1.1529
  9.1.1529: Win32: the toolbar in the GUI is old and dated
  9.1.1528: completion: crash with getcompletion()
  9.1.1527: Vim9: Crash with string compound assignment
  9.1.1526: completion: search completion match may differ in case
  9.1.1525: tests: testdir/ is a bit messy
  9.1.1524: tests: too many imports in the test suite
  9.1.1523: tests: test_clipmethod fails in non X11 environment
  9.1.1522: tests: still some ANSI escape sequences in test output
  9.1.1521: completion: pum does not reset scroll pos on reopen with 'noselect'
  9.1.1520: completion: search completion doesn't handle 'smartcase' well
  9.1.1519: tests: Test_termdebug_decimal_breakpoints() may fail
  9.1.1518: getcompletiontype() may crash
  9.1.1517: filetype: autopkgtest files are not recognized
  9.1.1516: tests: no test that 'incsearch' is updated after search completion
  9.1.1515: Coverity complains about potential unterminated strings
  9.1.1514: Coverity complains about the use of tmpfile()
  9.1.1513: resizing Vim window causes unexpected internal window width
  9.1.1512: completion: can only complete from keyword characters
  9.1.1511: tests: two edit tests change v:testing from 1 to 0
  9.1.1510: Search completion may use invalid memory
  9.1.1509: patch 9.1.1505 was not good
  9.1.1508: string manipulation can be improved in cmdexpand.c
  9.1.1507: symlinks are resolved on :cd commands
  9.1.1506: tests: missing cleanup in Test_search_cmdline_incsearch_highlight()
  9.1.1505: not possible to return completion type for :ex command
  9.1.1504: filetype: numbat files are not recognized
  9.1.1503: filetype: haxe files are not recognized
  9.1.1502: filetype: quickbms files are not recognized
  9.1.1501: filetype: flix files are not recognized
  9.1.1500: if_python: typo in python error variable
  9.1.1499: MS-Windows: no indication of ARM64 architecture
  9.1.1498: completion: 'complete' funcs behave different to 'omnifunc'
  9.1.1497: Link error with shm_open()
  9.1.1496: terminal: still not highlighting empty cells correctly
  9.1.1495: Wayland: uses $XDG_SEAT to determine seat
  9.1.1494: runtime(tutor): no French translation for Chapter 2
  9.1.1493: manually comparing positions on buffer
  9.1.1492: tests: failure when Wayland compositor fails to start
  9.1.1491: missing out-of-memory checks in cmdexpand.c
  9.1.1490: 'wildchar' does not work in search contexts
  9.1.1489: terminal: no visual highlight of empty cols with empty 'listchars'
  9.1.1488: configure: using obsolete macro AC_PROG_GCC_TRADITIONAL
  9.1.1487: :cl doesn't invoke :clist
  9.1.1486: documentation issues with Wayland
  9.1.1485: missing Wayland clipboard support
  9.1.1484: tests: Turkish locale tests fails on Mac
  9.1.1483: not possible to translation position in buffer
  9.1.1482: scrolling with 'splitkeep' and line()
  9.1.1481: gcc complains about uninitialized variable
  9.1.1480: Turkish translation outdated
  9.1.1479: regression when displaying localized percentage position
  9.1.1478: Unused assignment in ex_uniq()
  9.1.1476: no easy way to deduplicate text
  9.1.1476: missing out-of-memory checks in cmdexpand.c
  9.1.1475: completion: regression when &amp;quot;nearest&amp;quot; in 'completeopt'
  9.1.1474: missing out-of-memory check in mark.c
  9.1.1473: inconsistent range arg for :diffget/diffput
  9.1.1472: if_python: PySequence_Fast_{GET_SIZE,GET_ITEM} removed
  9.1.1471: completion: inconsistent ordering with CTRL-P
  9.1.1470: use-after-free with popup callback on error
  9.1.1469: potential buffer-underflow with invalid hl_id
  9.1.1468: filetype: bright(er)script files are not recognized
  9.1.1467: too many strlen() calls
  9.1.1466: filetype: not all lex files are recognized
  9.1.1465: tabpanel: not correctly drawn with 'equalalways'
  9.1.1464: gv does not work in operator-pending mode
  9.1.1463: Integer overflow in getmarklist() after linewise operation
  9.1.1462: missing change from patch v9.1.1461
  9.1.1461: tabpanel: tabpanel vanishes with popup menu
  9.1.1460: MS-Windows: too many strlen() calls in os_win32.c
  9.1.1459: xxd: coloring output is inefficient
  9.1.1458: tabpanel: tabs not properly updated with 'stpl'
  9.1.1457: compile warning with tabpanelopt
  9.1.1456: comment plugin fails toggling if 'cms' contains \
  9.1.1455: Haiku: dailog objects created with no reference
  9.1.1454: tests: no test for pum at line break position
  9.1.1453: tests: Test_geometry() may fail
  9.1.1452: completion: redundant check for completion flags
  9.1.1451: tabpanel rendering artifacts when scrolling
  9.1.1450: Session has wrong arglist with :tcd and :arglocal
  9.1.1449: typo in pum_display()
  9.1.1448: tabpanel is not displayed correctly when msg_scrolled
  9.1.1447: completion: crash when backspacing with fuzzy completion
  9.1.1446: filetype: cuda-gdb config files are not recognized
  9.1.1445: negative matchfuzzy scores although there is a match
  9.1.1444: Unused assignment in set_fuzzy_score()
  9.1.1443: potential buffer underflow in insertchar()
  9.1.1442: tests: Test_diff_fold_redraw() is insufficient
  9.1.1441: completion: code can be improved
  9.1.1440: too many strlen() calls in os_win32.c
  9.1.1439: Last diff folds not merged
  9.1.1438: tests: Test_breakindent_list_split() fails
  9.1.1437: MS-Windows: internal compile error in uc_list()
  9.1.1436: GUI control code is displayed on the console on startup
  9.1.1435: completion: various flaws in fuzzy completion
  9.1.1434: MS-Windows: missing out-of-memory checks in os_win32.c
  9.1.1433: Unnecessary :if when writing session
  9.1.1432: GTK GUI: Buffer menu does not handle unicode correctly
  9.1.1431: Hit-Enter Prompt when loading session files
  9.1.1430: tabpanel may flicker in the GUI
  9.1.1429: dragging outside the tabpanel changes tabpagenr
  9.1.1428: completion: register completion needs cleanup
  9.1.1427: rendering artifacts with the tabpanel
  9.1.1426: completion: register contents not completed
  9.1.1425: tabpanel: there are still some problems with the tabpanel
  9.1.1424: PMenu selection broken with multi-line selection and limits
  9.1.1423: :tag command not working correctly using Vim9 Script
  9.1.1422: scheduling of complete function can be improved
  9.1.1421: tests: need a test for the new-style tutor.tutor
  9.1.1420: tests: could need some more tests for shebang lines
  9.1.1419: It is difficult to ignore all but some events
  9.1.1418: configures GUI auto detection favors GTK2
  9.1.1417: missing info about register completion in complete_info()
  9.1.1416: completion limits not respected for fuzzy completions
  9.1.1415: potential use-after free when there is an error in 'tabpanel'
  9.1.1414: MS-Windows: compile warnings in os_win32.c
  9.1.1413: spurious CursorHold triggered in GUI on startup
  9.1.1412: tests: Test_tabpanel_tabonly() fails on larger screens
  9.1.1411: crash when calling non-existing function for tabpanel
  9.1.1410: out-of-bounds access with 'completefunc'
  9.1.1409: using f-flag in 'complete' conflicts with Neovim
  9.1.1408: not easily possible to complete from register content
  9.1.1407: Can't use getpos('v') in OptionSet when using setbufvar()
  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
  9.1.1176: wrong indent when expanding multiple lines
  9.1.1175: inconsistent behaviour with exclusive selection and motion commands
  9.1.1174: tests: Test_complete_cmdline() may fail
  9.1.1173: filetype: ABNF files are not detected
  9.1.1172: [security]: overflow with 'nostartofline' and Ex command in tag file
  9.1.1171: tests: wrong arguments passed to assert_equal()
  9.1.1170: wildmenu highlighting in popup can be improved
  9.1.1169: using global variable for get_insert()/get_lambda_name()
  9.1.1168: wrong flags passed down to nextwild()
  9.1.1167: mark '] wrong after copying text object
  9.1.1166: command-line auto-completion hard with wildmenu
  9.1.1165: diff: regression with multi-file diff blocks
  9.1.1164: [security]: code execution with tar.vim and special crafted tar files
  9.1.1163: $MYVIMDIR is set too late
  9.1.1162: completion popup not cleared in cmdline
  9.1.1161: preinsert requires bot &amp;quot;menu&amp;quot; and &amp;quot;menuone&amp;quot; to be set
  9.1.1160: Ctrl-Y does not work well with &amp;quot;preinsert&amp;quot; when completing items
  9.1.1159: $MYVIMDIR may not always be set
  9.1.1158: :verbose set has wrong file name with :compiler!
  9.1.1157: command completion wrong for input()
  9.1.1156: tests: No test for what patch 9.1.1152 fixes
  9.1.1155: Mode message not cleared after :silent message
  9.1.1154: Vim9: not able to use autoload class accross scripts
  9.1.1153: build error on Haiku
  9.1.1152: Patch v9.1.1151 causes problems
  9.1.1151: too many strlen() calls in getchar.c
  9.1.1150: :hi completion may complete to wrong value
  9.1.1149: Unix Makefile does not support Brazilian lang for the installer
  9.1.1148: Vim9: finding imported scripts can be further improved
  9.1.1147: preview-window does not scroll correctly
  9.1.1146: Vim9: wrong context being used when evaluating class member
  9.1.1145: multi-line completion has wrong indentation for last line
  9.1.1144: no way to create raw strings from a blob
  9.1.1143: illegal memory access when putting a register
  9.1.1142: tests: test_startup fails if $HOME/$XDG_CONFIG_HOME is defined
  9.1.1141: Misplaced comment in readfile()
  9.1.1140: filetype: m17ndb files are not detected
  9.1.1139: [fifo] is not displayed when editing a fifo
  9.1.1138: cmdline completion for :hi is too simplistic
  9.1.1137: ins_str() is inefficient by calling STRLEN()
  9.1.1136: Match highlighting marks a buffer region as changed
  9.1.1135: 'suffixesadd' doesn't work with multiple items
  9.1.1134: filetype: Guile init file not recognized
  9.1.1133: filetype: xkb files not recognized everywhere
  9.1.1132: Mark positions wrong after triggering multiline completion
  9.1.1131: potential out-of-memory issue in search.c
  9.1.1130: 'listchars' &amp;quot;precedes&amp;quot; is not drawn on Tabs.
  9.1.1129: missing out-of-memory test in buf_write()
  9.1.1128: patch 9.1.1119 caused a regression with imports
  9.1.1127: preinsert text is not cleaned up correctly
  9.1.1126: patch 9.1.1121 used a wrong way to handle enter
  9.1.1125: cannot loop through pum menu with multiline items
  9.1.1124: No test for 'listchars' &amp;quot;precedes&amp;quot; with double-width char
  9.1.1123: popup hi groups not falling back to defaults
  9.1.1122: too many strlen() calls in findfile.c
  9.1.1121: Enter does not insert newline with &amp;quot;noselect&amp;quot;
  9.1.1120: tests: Test_registers fails
  9.1.1119: Vim9: Not able to use an autoloaded class from another autoloaded script
  9.1.1118: tests: test_termcodes fails
  9.1.1117: there are a few minor style issues
  9.1.1116: Vim9: super not supported in lambda expressions
  9.1.1115: [security]: use-after-free in str_to_reg()
  9.1.1114: enabling termguicolors automatically confuses users
  9.1.1113: tests: Test_terminal_builtin_without_gui waits 2 seconds
  9.1.1112: Inconsistencies in get_next_or_prev_match()
  9.1.1111: Vim9: variable not found in transitive import
  9.1.1110: Vim tests are slow and flaky
  9.1.1109: cmdexpand.c hard to read
  9.1.1108: 'smoothscroll' gets stuck with 'listchars' &amp;quot;eol&amp;quot;
  9.1.1107: cannot loop through completion menu with fuzzy
  9.1.1106: tests: Test_log_nonexistent() causes asan failure
  9.1.1105: Vim9: no support for protected new() method
  9.1.1104: CI: using Ubuntu 22.04 Github runners
  9.1.1103: if_perl: still some compile errors with Perl 5.38
  9.1.1102: tests: Test_WinScrolled_Resized_eiw() uses wrong filename
  9.1.1101: insexpand.c hard to read
  9.1.1100: tests: Test_log_nonexistent only works on Linux
  9.1.1099: Vim9: import with extends may crash
  9.1.1098: leaking memory with completing multi lines
  9.1.1097: --log with non-existent path causes a crash
  9.1.1096: if_perl: Perl 5.38 adds new symbols causing link failure
  9.1.1095: tests: matchparen plugin test wrongly named
  9.1.1094: Vim9: problem finding implemented method in type hierarchy
  9.1.1093: tests: output of test ...win32_ctrl_z depends on python version
  9.1.1092: tests: fix expected return code for python 3.13 on Windows
  9.1.1091: tests: timeout might be a bit too small
  9.1.1090: tests: test_terminwscroll_topline2 unreliable
  9.1.1089: tests: No check when tests are run under Github actions
  9.1.1088: tests: plugin tests are named inconsistently
  9.1.1087: Vim9: import with extends may crash
  9.1.1086: completion doesn't work with multi lines
  9.1.1085: filetype: cmmt files are not recognized
  9.1.1084: Unable to persistently ignore events in a window and its buffers
  9.1.1083: setreg() doesn't correctly handle mbyte chars in blockwise mode
  9.1.1082: unexpected DCS responses may cause out of bounds reads
  9.1.1081: has('bsd') is true for GNU/Hurd
  9.1.1080: filetype: Mill files are not recognized
  9.1.1079: GUI late startup leads to uninitialized scrollbars
  9.1.1078: Terminal ansi colors off by one after tgc reset
  9.1.1077: included syntax items do not understand contains=TOP
  9.1.1076: vim_strnchr() is strange and unnecessary
  9.1.1075: Vim9: len variable not used in compile_load()
  9.1.1074: Strange error when heredoc marker starts with &amp;quot;trim&amp;quot;
  9.1.1073: tests: test_compiler fails on Windows without Maven
  9.1.1072: 'diffopt' &amp;quot;linematch&amp;quot; cannot be used with {n} less than 10
  9.1.1071: args missing after failing to redefine a function
  9.1.1070: Cannot control cursor positioning of getchar()
  9.1.1069: preinsert text completions not deleted with &amp;lt;C-W&amp;gt;/&amp;lt;C-U&amp;gt;
  9.1.1068: getchar() can't distinguish between C-I and Tab
  9.1.1067: tests: Test_termwinscroll_topline2 fails on MacOS
  9.1.1066: heap-use-after-free and stack-use-after-scope with :14verbose
  9.1.1065: no digraph for &amp;quot;Approaches the limit&amp;quot;
  9.1.1064: not possible to use plural forms with gettext()
  9.1.1063: too many strlen() calls in userfunc.c
  9.1.1062: terminal: E315 when dragging the terminal with the mouse
  9.1.1061: tests: test_glvs fails when unarchiver not available
  9.1.1060: Vim always enables 'termguicolors' in a terminal
  9.1.1059: completion: input text deleted with preinsert when adding leader
  9.1.1058: translation(sr): Missing Serbian translation for the tutor
  9.1.1057: Superfluous cleanup steps in test_ins_complete.vim
  9.1.1056: Vim doesn't highlight to be inserted text when completing
  9.1.1055: make install fails because of a missing dependency
  9.1.1054: Vim doesn't work well with TERM=xterm-direct
  9.1.1053: &amp;quot;nosort&amp;quot; enables fuzzy filtering even if &amp;quot;fuzzy&amp;quot; isn't in 'completeopt'
  9.1.1052: tests: off-by-one error in CheckCWD in test_debugger.vim
  9.1.1051: tests: no support for env variables when running Vim in terminal
  9.1.1050: too many strlen() calls in os_unix.c
  9.1.1049: insert-completed items are always sorted
  9.1.1048: crash after scrolling and pasting in silent Ex mode
  9.1.1047: Makefiles uses non-portable syntax
  9.1.1046: fuzzymatching doesn't prefer matching camelcase
  9.1.1045: filetype: N-Tripels and TriG files are not recognized
  9.1.1044: Vim9: Patch 9.1.1014 causes regressions
  9.1.1043: [security]: segfault in win_line()
  9.1.1042: filetype: just files are not recognized
  9.1.1041: Vim9: out-of-bound access when echoing an enum
  9.1.1040: Vim9: imported type cannot be used as func return type
  9.1.1039: Vim9: comments are outdated
  9.1.1038: tests: test_channel.py fails with IPv6
  9.1.1037: Vim9: confusing error when using abstract method via super
  9.1.1036: make install fails when using shadowdir
  9.1.1035: Vim9: memory leak with blob2str()
  9.1.1033: Vim9: compiling abstract method fails without return
  9.1.1033: tests: shaderslang was removed from test_filetype erroneously
  9.1.1032: link error when FEAT_SPELL not defined
  9.1.1031: Coverity complains about insecure data handling
  9.1.1030: filetype: setting bash filetype is backwards incompatible
  9.1.1029: the installer can be improved
  9.1.1028: too many strlen() calls in screen.c
  9.1.1027: no sanitize check when running linematch
  9.1.1026: filetype: swc configuration files are not recognized
  9.1.1025: wrong return type of blob2str()
  9.1.1024: blob2str/str2blob() do not support list of strings
  9.1.1023: Coverity complains about dereferencing NULL pointer
  9.1.1022: linematch option value not completed
  9.1.1021: string might be used without a trailing NUL
  9.1.1020: no way to get current selected item in a async context
  9.1.1019: filetype: fd ignore files are not recognized
  9.1.1018: v9.1.0743 causes regression with diff mode
  9.1.1017: Vim9: Patch 9.1.1013 causes a few problems
  9.1.1016: Not possible to convert string2blob and blob2string
  9.1.1015: Coverity complains about dereferencing NULL value
  9.1.1014: Vim9: variable not found in transitive import
  9.1.1013: Vim9: Regression caused by patch v9.1.0646
  9.1.1012: Vim9: class interface inheritance not correctly working
  9.1.1011: popupmenu internal error with some abbr in completion item
  9.1.1010: filetype: VisualCode setting file not recognized
  9.1.1009: diff feature can be improved
  9.1.1008: tests: test for patch 9.1.1006 doesn't fail without the patch
  9.1.1007: filetype: various ignore are not recognized
  9.1.1006: PmenuMatch completion highlight can be combined
  9.1.1005: completion text is highlighted even with no pattern found
  9.1.1004: tests: a few termdebug tests are flaky
  9.1.1003: [security]: heap-buffer-overflow with visual mode
  9.1.1002: Vim9: unknown func error with interface declaring func var
  9.1.1001: ComplMatchIns highlight hard to read on light background
  9.1.1000: tests: ruby tests fail with Ruby 3.4
  9.1.0999: Vim9: leaking finished exception
  9.1.0998: filetype: TI assembly files are not recognized
  9.1.0997: too many strlen() calls in drawscreen.c
  9.1.0996: ComplMatchIns may highlight wrong text
  9.1.0995: filetype: shaderslang files are not detected
  9.1.0994: Vim9: not able to use comment after opening curly brace
  9.1.0993: New 'cmdheight' behavior may be surprising
  9.1.0992: Vim9: double-free after v9.1.0988
  9.1.0991: v:stacktrace has wrong type in Vim9 script
  9.1.0990: Inconsistent behavior when changing cmdheight
  9.1.0989: Vim9: Whitespace after the final enum value causes a syntax error
  9.1.0988: Vim9: no error when using uninitialized var in new()
  9.1.0987: filetype: cake files are not recognized
  9.1.0986: filetype: 'jj' filetype is a bit imprecise
  9.1.0985: Vim9: some ex commands can be shortened
  9.1.0984: exception handling can be improved
  9.1.0983: not able to get the displayed items in complete_info()
  9.1.0982: TI linker files are not recognized
  9.1.0981: tests: typo in test_filetype.vim
  9.1.0980: no support for base64 en-/decoding functions in Vim Script
  9.1.0979: VMS: type warning with $XDG_VIMRC_FILE
  9.1.0978: GUI tests sometimes fail when setting 'scroll' options
  9.1.0977: filetype: msbuild filetypes are not recognized
  9.1.0976: Vim9: missing return statement with throw
  9.1.0975: Vim9: interpolated string expr not working in object methods
  9.1.0974: typo in change of commit v9.1.0873
  9.1.0973: too many strlen() calls in fileio.c
  9.1.0972: filetype: TI linker map files are not recognized
  9.1.0971: filetype: SLNX files are not recognized
  9.1.0970: VMS: build errors on VMS architecture
  9.1.0969: ghostty not using kitty protocol by default
  9.1.0968: tests: GetFileNameChecks() isn't fully sorted by filetype name
  9.1.0967: SpotBugs compiler setup can be further improved
  9.1.0966: Vim9: :enum command can be shortened
  9.1.0965: filetype: sh filetype set when detecting the use of bash
  9.1.0964: MS-Windows: sed error with MinGW
  9.1.0963: fuzzy-matching does not prefer full match
  9.1.0962: filetype: bun.lock file is not recognized
  9.1.0961: filetype: TI gel files are not recognized
  9.1.0960: filetype: hy history files are not recognized
  9.1.0959: Coverity complains about type conversion
  9.1.0958: filetype: supertux2 config files detected as lisp
  9.1.0957: MS-Windows: conversion warnings
  9.1.0956: completion may crash, completion highlight wrong with preview window
  9.1.0955: Vim9: vim9compile.c can be further improved
  9.1.0954: popupmenu.c can be improved
  9.1.0953: filetype: APKBUILD files not correctly detected
  9.1.0952: Vim9: missing type checking for any type assignment
  9.1.0951: filetype: jshell files are not recognized
  9.1.0950: filetype: fennelrc files are not recognized
  9.1.0949: popups inconsistently shifted to the left
  9.1.0948: Missing cmdline completion for :pbuffer
  9.1.0947: short-description
  9.1.0946: cross-compiling fails on osx-arm64
  9.1.0945: ComplMatchIns highlight doesn't end after inserted text
  9.1.0944: tests: test_registers fails when not run under X11
  9.1.0943: Vim9: vim9compile.c can be further improved
  9.1.0942: a few typos were found
  9.1.0941: ComplMatchIns doesn't work after multibyte chars
  9.1.0940: Wrong cursor shape with &amp;quot;gq&amp;quot; and 'indentexpr' executes :normal
  9.1.0939: make installtutor fails
  9.1.0938: exclusive selection not respected when re-selecting block mode
  9.1.0937: test_undolist() is flaky
  9.1.0936: cannot highlight completed text
  9.1.0935: SpotBugs compiler can be improved
  9.1.0934: hard to view an existing buffer in the preview window
  9.1.0933: Vim9: vim9compile.c can be further improved
  9.1.0932: new Italian tutor not installed
  9.1.0931: ml_get error in terminal buffer
  9.1.0930: tests: test_terminal2 may hang in GUI mode
  9.1.0929: filetype: lalrpop files are not recognized
  9.1.0928: tests: test_popupwin fails because the filter command fails
  9.1.0927: style issues in insexpand.c
  9.1.0926: filetype: Pixi lock files are not recognized
  9.1.0925: Vim9: expression compiled when not necessary
  9.1.0924: patch 9.1.0923 causes issues
  9.1.0923: too many strlen() calls in filepath.c
  9.1.0923: wrong MIN macro in popupmenu.c
  9.1.0921: popupmenu logic is a bit convoluted
  9.1.0920: Vim9: compile_assignment() too long
  9.1.0919: filetype: some assembler files are not recognized
  9.1.0918: tiny Vim crashes with fuzzy buffer completion
  9.1.0917: various vartabstop and shiftround bugs when shifting lines
  9.1.0916: messages.c is exceeding 80 columns
  9.1.0915: GVim: default font size a bit too small
  9.1.0914: Vim9: compile_assignment() is too long
  9.1.0913: no error check for neg values for 'messagesopt'
  9.1.0912: xxd: integer overflow with sparse files and -autoskip
  9.1.0911: Variable name for 'messagesopt' doesn't match short name
  9.1.0910: 'messagesopt' does not check max wait time
  9.1.0909: Vim9: crash when calling instance method
  9.1.0908: not possible to configure :messages
  9.1.0907: printoptions:portrait does not change postscript Orientation
  9.1.0906: filetype: Nvidia PTX files are not recognized
  9.1.0905: Missing information in CompleteDone event
  9.1.0904: Vim9: copy-paste error in class_defining_member()
  9.1.0903: potential overflow in spell_soundfold_wsal()
  9.1.0902: filetype: Conda configuration files are not recognized
  9.1.0901: MS-Windows: vimtutor batch script can be improved
  9.1.0900: Vim9: digraph_getlist() does not accept bool arg
  9.1.0899: default for 'backspace' can be set in C code
  9.1.0898: runtime(compiler): pytest compiler not included
  9.1.0897: filetype: pyrex files are not detected
  9.1.0896: completion list wrong after v9.1.0891
  9.1.0895: default history value is too small
  9.1.0894: No test for what the spotbug compiler parses
  9.1.0893: No test that undofile format does not regress
  9.1.0892: the max value of 'tabheight' is limited by other tabpages
  9.1.0891: building the completion list array is inefficient
  9.1.0890: %! item not allowed for 'rulerformat'
  9.1.0889: Possible unnecessary redraw after adding/deleting lines
  9.1.0888: leftcol property not available in getwininfo()
  9.1.0887: Wrong expression in sign.c
  9.1.0886: filetype: debian control file not detected
  9.1.0885: style of sign.c can be improved
  9.1.0884: gcc warns about uninitialized variable
  9.1.0883: message history cleanup is missing some tests
  9.1.0882: too many strlen() calls in insexpand.c
  9.1.0881: GUI: message dialog may not get focus
  9.1.0880: filetype: C3 files are not recognized
  9.1.0879: source is not consistently formatted
  9.1.0878: termdebug: cannot enable DEBUG mode
  9.1.0877: tests: missing test for termdebug + decimal signs
  9.1.0876: filetype: openCL files are not recognized
  9.1.0875: filetype: hyprlang detection can be improved
  9.1.0874: filetype: karel files are not detected
  9.1.0873: filetype: Vivado files are not recognized
  9.1.0872: No test for W23 message
  9.1.0871: getcellpixels() can be further improved
  9.1.0870: too many strlen() calls in eval.c
  9.1.0869: Problem: curswant not set on gm in folded line
  9.1.0868: the warning about missing clipboard can be improved
  9.1.0867: ins_compl_add() has too many args
  9.1.0866: filetype: LLVM IR files are not recognized
  9.1.0865: filetype: org files are not recognized
  9.1.0864: message history is fixed to 200
  9.1.0863: getcellpixels() can be further improved
  9.1.0862: 'wildmenu' not enabled by default in nocp mode
  9.1.0861: Vim9: no runtime check for object member access of any var
  9.1.0860: tests: mouse_shape tests use hard code sleep value
  9.1.0859: several problems with the GLVS plugin
  9.1.0858: Coverity complains about dead code
  9.1.0857: xxd: --- is incorrectly recognized as end-of-options
  9.1.0856: mouseshape might be wrong on r and gr
  9.1.0855: setting 'cmdheight' may cause hit-enter-prompt
  9.1.0854: cannot get terminal cell size
  9.1.0853: filetype: kubernetes config file not recognized
  9.1.0852: No warning when X11 registers are not available
  9.1.0851: too many strlen() calls in getchar.c
  9.1.0850: Vim9: cannot access nested object inside objects
  9.1.0849: there are a few typos in the source
  9.1.0848: if_lua: v:false/v:true are not evaluated to boolean
  9.1.0847: tests: test_popupwin fails because of updated help file
  9.1.0846: debug symbols for xxd are not cleaned in Makefile
  9.1.0845: vimtutor shell script can be improved
  9.1.0844: if_python: no way to pass local vars to python
  9.1.0843: too many strlen() calls in undo.c
  9.1.0842: not checking for the sync() systemcall
  9.1.0841: tests: still preferring python2 over python3
  9.1.0840: filetype: idris2 files are not recognized
  9.1.0839: filetype: leo files are not recognized
  9.1.0838: vimtutor is bash-specific
  9.1.0837: cross-compiling has some issues
  9.1.0836: The vimtutor can be improved
  9.1.0835: :setglobal doesn't work properly for 'ffu' and 'tsrfu'
  9.1.0834: tests: 2html test fails
  9.1.0833: CI: recent ASAN changes do not work for indent tests
  9.1.0832: :set doesn't work for 'cot' and 'bkc' after :setlocal
  9.1.0831: 'findexpr' can't be used as lambad or Funcref
  9.1.0830: using wrong highlight group for spaces for popupmenu
  9.1.0829: Vim source code uses a mix of tabs and spaces
  9.1.0828: string_T struct could be used more often
  9.1.0827: CI: tests can be improved
  9.1.0826: filetype: sway files are not recognized
  9.1.0825: compile error for non-diff builds
  9.1.0824: too many strlen() calls in register.c
  9.1.0823: filetype: Zephyr overlay files not recognized
  9.1.0822: topline might be changed in diff mode unexpectedly
  9.1.0821: 'findexpr' completion doesn't set v:fname to cmdline argument
  9.1.0820: tests: Mac OS tests are too flaky
  9.1.0819: tests: using findexpr and imported func not tested
  9.1.0818: some global functions are only used in single files
  9.1.0817: termdebug: cannot evaluate expr in a popup
  9.1.0816: tests: not clear what tests cause asan failures
  9.1.0815: &amp;quot;above&amp;quot; virtual text causes wrong 'colorcolumn' position
  9.1.0814: mapset() may remove unrelated mapping
  9.1.0813: no error handling with setglobal and number types
  9.1.0812: Coverity warns about dereferencing NULL ptr
  9.1.0811: :find expansion does not consider 'findexpr'
  9.1.0810: cannot easily adjust the |:find| command
  9.1.0809: filetype: petalinux config files not recognized
  9.1.0808: Terminal scrollback doesn't shrink when decreasing 'termwinscroll'
  9.1.0807: tests: having 'nolist' in modelines isn't always desired
  9.1.0806: tests: no error check when setting global 'briopt'
  9.1.0805: tests: minor issues in gen_opt_test.vim
  9.1.0804: tests: no error check when setting global 'cc'
  9.1.0803: tests: no error check when setting global 'isk'
  9.1.0802: tests: no error check when setting global 'fdm' to empty value
  9.1.0801: tests: no error check when setting global 'termwinkey'
  9.1.0800: tests: no error check when setting global 'termwinsize'
  9.1.0799: tests: gettwinvar()/gettabwinvar() tests are not comprehensive
  9.1.0798: too many strlen() calls in cmdhist.c
  9.1.0797: testing of options can be further improved
  9.1.0796: filetype: libtool files are not recognized
  9.1.0795: filetype: Vivado memory info file are not recognized
  9.1.0794: tests: tests may fail on Windows environment
  9.1.0793: xxd: -e does add one extra space
  9.1.0792: tests: Test_set_values() is not comprehensive enough
  9.1.0791: tests: errors in gen_opt_test.vim are not shown
  9.1.0790: Amiga: AmigaOS4 build should use default runtime (newlib)
  9.1.0789: tests: ':resize + 5' has invalid space after '+'
  9.1.0788: &amp;lt;CSI&amp;gt;27;&amp;lt;mod&amp;gt;u is not decoded to literal Escape in kitty/foot
  9.1.0787: cursor position changed when using hidden terminal
  9.1.0786: tests: quickfix update test does not test location list
  9.1.0785: cannot preserve error position when setting quickfix list
  9.1.0784: there are several problems with python 3.13
  9.1.0783: 'spell' option setting has problems
  9.1.0782: tests: using wrong neomuttlog file name
  9.1.0781: tests: test_filetype fails
  9.1.0780: MS-Windows: incorrect Win32 error checking
  9.1.0779: filetype: neomuttlog files are not recognized
  9.1.0778: filetype: lf config files are not recognized
  9.1.0777: filetype: Some upstream php files are not recognized
  9.1.0776: test_strftime may fail because of missing TZ data
  9.1.0775: tests: not enough tests for setting options
  9.1.0774: &amp;quot;shellcmdline&amp;quot; doesn't work with getcompletion()
  9.1.0773: filetype: some Apache files are not recognized
  9.1.0772: some missing changes from v9.1.0771
  9.1.0771: completion attribute hl_group is confusing
  9.1.0770: current command line completion is a bit limited
  9.1.0769: filetype: MLIR files are not recognized
  9.1.0768: MS-Windows: incorrect cursor position when restoring screen
  9.1.0767: A condition is always true in ex_getln.c
  9.1.0766: too many strlen() calls in ex_getln.c
  9.1.0765: No test for patches 6.2.418 and 7.3.489
  9.1.0764: [security]: use-after-free when closing a buffer
  9.1.0763: tests: cannot run single syntax tests
  9.1.0762: 'cedit', 'termwinkey' and 'wildchar' may not be parsed correctly
  9.1.0761: :cd completion fails on Windows with backslash in path
  9.1.0760: tests: no error reported, if gen_opt_test.vim fails
  9.1.0759: screenpos() may return invalid position
  9.1.0758: it's possible to set an invalid key to 'wildcharm'
  9.1.0757: tests: messages files contains ANSI escape sequences
  9.1.0756: missing change from patch v9.1.0754
  9.1.0755: quickfix list does not handle hardlinks well
  9.1.0754: fixed order of items in insert-mode completion menu
  9.1.0753: Wrong display when typing in diff mode with 'smoothscroll'
  9.1.0752: can set 'cedit' to an invalid value
  9.1.0751: Error callback for term_start() not used
  9.1.0750: there are some Win9x legacy references
  9.1.0749: filetype: http files not recognized
  9.1.0748: :keep* commmands are sometimes misidentified as :k
  9.1.0747: various typos in repo found
  9.1.0746: tests: Test_halfpage_longline() fails on large terminals
  9.1.0745: filetype: bun and deno history files not recognized
  9.1.0744: filetype: notmuch configs are not recognised
  9.1.0743: diff mode does not handle overlapping diffs correctly
  9.1.0742: getcmdprompt() implementation can be improved
  9.1.0741: No way to get prompt for input()/confirm()
  9.1.0740: incorrect internal diff with empty file
  9.1.0739: [security]: use-after-free in ex_getln.c
  9.1.0738: filetype: rapid files are not recognized
  9.1.0737: tests: screendump tests may require a bit more time
  9.1.0736: Unicode tables are outdated
  9.1.0735: filetype: salt files are not recognized
  9.1.0734: filetype: jinja files are not recognized
  9.1.0733: keyword completion does not work with fuzzy
  9.1.0732: xxd: cannot use -b and -i together
  9.1.0731: inconsistent case sensitive extension matching
  9.1.0730: Crash with cursor-screenline and narrow window
  9.1.0729: Wrong cursor-screenline when resizing window
  9.1.0728: [security]: heap-use-after-free in garbage collection with location list user data
  9.1.0727: too many strlen() calls in option.c
  9.1.0726: not using correct python3 API with dynamic linking
  9.1.0725: filetype: swiftinterface files are not recognized
  9.1.0724: if_python: link error with python 3.13 and stable ABI
  9.1.0723: if_python: dynamic linking fails with python3 &amp;gt;= 3.13
  9.1.0722: crash with large id in text_prop interface
  9.1.0721: tests: test_mksession does not consider XDG_CONFIG_HOME
  9.1.0720: Wrong breakindentopt=list:-1 with multibyte or TABs
  9.1.0719: Resetting cell widths can make 'listchars' or 'fillchars' invalid
  9.1.0718: hard to know the users personal Vim Runtime Directory
  9.1.0717: Unnecessary nextcmd NULL checks in parse_command_modifiers()
  9.1.0716: resetting setcellwidth() doesn't update the screen
  9.1.0715: Not correctly parsing color names (after v9.1.0709)
  9.1.0714: tests: GuiEnter_Turkish test may fail
  9.1.0713: Newline causes E749 in Ex mode
  9.1.0712: tests: missing dependency of Test_gettext_makefile
  9.1.0711: tests: test_xxd may file when using different xxd
  9.1.0710: popup window may hide part of Command line
  9.1.0709: GUIEnter event not found in Turkish locale
  9.1.0708: Recursive window update does not account for reset skipcol
  9.1.0707: [security]: invalid cursor position may cause a crash
  9.1.0706: tests: test_gettext fails when using shadow dir
  9.1.0705: Sorting of fuzzy filename completion is not stable
  9.1.0704: inserting with a count is inefficient
  9.1.0703: crash with 2byte encoding and glob2regpat()
  9.1.0702: Patch 9.1.0700 broke CI
  9.1.0701: crash with NFA regex engine when searching for composing chars
  9.1.0700: crash with 2byte encoding and glob2regpat()
  9.1.0699: &amp;quot;dvgo&amp;quot; is not always an inclusive motion
  9.1.0698: tests: &amp;quot;Untitled&amp;quot; file not removed when running Test_crash1_3 alone
  9.1.0697: [security]: heap-buffer-overflow in ins_typebuf
  9.1.0696: installing runtime files fails when using SHADOWDIR
  9.1.0695: tests: test_crash leaves Untitled file around
  9.1.0694: matchparen is slow on a long line
  9.1.0693: Configure doesn't show result when not using python3 stable abi
  9.1.0692: Wrong patlen value in ex_substitute()
  9.1.0691: python3: stable-abi may cause segfault on Python 3.11
  9.1.0690: cannot set special highlight kind in popupmenu
  9.1.0689: [security]: buffer-overflow in do_search() with 'rightleft'
  9.1.0688: Vim9: dereferences NULL pointer in check_type_is_value()
  9.1.0687: Makefile may not install desktop files
  9.1.0686: zip-plugin has problems with special characters
  9.1.0685: too many strlen() calls in usercmd.c
  9.1.0684: completion is inserted on Enter with &amp;quot;noselect&amp;quot;
  9.1.0683: mode() returns wrong value with &amp;lt;Cmd&amp;gt; mapping
  9.1.0682: Vim9: Segfault with uninitialized funcref
  9.1.0681: tests: Analyzing failed screendumps is hard
  9.1.0680: VMS does not have defined uintptr_t
  9.1.0679: Rename from w_closing to w_locked is incomplete
  9.1.0678: [security]: use-after-free in alist_add()
  9.1.0677: :keepp does not retain the substitute pattern
  9.1.0676: style issues with man pages
  9.1.0675: Patch v9.1.0674 causes problems
  9.1.0674: Vim9: compiling abstract method fails because of missing return
  9.1.0673: Vim9: too recursive func calls when calling super-class method
  9.1.0672: marker folds may get corrupted on undo
  9.1.0670: po file encoding fails on *BSD during make
  9.1.0669: if_python: stable python ABI not used by default
  9.1.0668: build-error with python3.12 and stable ABI
  9.1.0667: Some other options reset curswant unnecessarily when set
  9.1.0666: assert_equal() doesn't show multibyte string correctly
  9.1.0665: Locked variable can be changed in a :for loop
  9.1.0664: MS-Windows: console vim did not switch back to main screen on exit
  9.1.0663: tests: zip test still resets 'shellslash' option
  9.1.0662: filecopy() may return wrong value when readlink() fails
  9.1.0661: the zip plugin is not tested.
  9.1.0660: MS-Windows: Shift-Insert does work on old conhost
  9.1.0659: MS-Windows: MSVC Makefile is a bit hard to read
  9.1.0658: Coverity warns about dereferencing NULL pointer.
  9.1.0657: MS-Windows: MSVC build time can be optimized
  9.1.0656: MS-Windows: MSVC Makefile CPU handling can be improved
  9.1.0655: filetype: goaccess config file not recognized
  9.1.0654: completion does not respect completeslash with fuzzy
  9.1.0653: Patch v9.1.0648 not completely right
  9.1.0652: too many strlen() calls in syntax.c
  9.1.0651: ex: trailing dot is optional for :g and :insert/:append
  9.1.0650: Coverity warning in cstrncmp()
  9.1.0649: Wrong comment for &amp;quot;len&amp;quot; argument of call_simple_func()
  9.1.0648: [security] double-free in dialog_changed()
  9.1.0647: [security] use-after-free in tagstack_clear_entry
  9.1.0646: Vim9: imported function may not be found
  9.1.0645: regex: wrong match when searching multi-byte char case-insensitive
  9.1.0644: Unnecessary STRLEN() when applying mapping
  9.1.0643: terminal: cursor may end up on invalid position
  9.1.0642: Check that mapping rhs starts with lhs fails if not simplified
  9.1.0641: MS-Windows: OLE enabled in console version
  9.1.0640: Mingw: Makefile can be improved
  9.1.0639: channel timeout may wrap around
  9.1.0638: E1510 may happen when formatting a message for smsg()
  9.1.0637: MS-Windows: Style issues in MSVC Makefile
  9.1.0636: filetype: ziggy files are not recognized
  9.1.0635: filetype: SuperHTML template files not recognized
  9.1.0634: Ctrl-P not working by default
  9.1.0633: Compilation warnings with `-Wunused-parameter`
  9.1.0632: MS-Windows: Compiler Warnings
  9.1.0631: wrong completion list displayed with non-existing dir + fuzzy completion
  9.1.0630: MS-Windows: build fails with VIMDLL and mzscheme
  9.1.0629: Rename of pum hl_group is incomplete
  9.1.0628: MinGW: coverage files are not cleaned up
  9.1.0627: MinGW: build-error when COVERAGE is enabled
  9.1.0626: Vim9: need more tests with null objects
  9.1.0625: tests: test output all translated messages for all translations
  9.1.0624: ex command modifiers not found
  9.1.0623: Mingw: errors when trying to delete non-existing files
  9.1.0622: MS-Windows: mingw-build can be optimized
  9.1.0621: MS-Windows: startup code can be improved
  9.1.0620: Vim9: segfauls with null objects
  9.1.0619: tests: test_popup fails
  9.1.0618: cannot mark deprecated attributes in completion menu
  9.1.0617: Cursor moves beyond first line of folded end of buffer
  9.1.0616: filetype: Make syntax highlighting off for MS Makefiles
  9.1.0615: Unnecessary STRLEN() in make_percent_swname()
  9.1.0614: tests: screendump tests fail due to recent syntax changes
  9.1.0613: tests: termdebug test may fail and leave file around
  9.1.0612: filetype: deno.lock file not recognized
  9.1.0611: ambiguous mappings not correctly resolved with modifyOtherKeys
  9.1.0610: filetype: OpenGL Shading Language files are not detected
  9.1.0609: outdated comments in Makefile
  9.1.0608: Coverity warns about a few potential issues
  9.1.0607: termdebug: uses inconsistent style
  9.1.0606: tests: generated files may cause failure in test_codestyle
  9.1.0605: internal error with fuzzy completion
  9.1.0604: popup_filter during Press Enter prompt seems to hang
  9.1.0603: filetype: use correct extension for Dracula
  9.1.0602: filetype: Prolog detection can be improved
  9.1.0601: Wrong cursor position with 'breakindent' when wide char doesn't fit
  9.1.0600: Unused function and unused error constants
  9.1.0599: Termdebug: still get E1023 when specifying arguments
  9.1.0598: fuzzy completion does not work with default completion
  9.1.0597: KeyInputPre cannot get the (unmapped typed) key
  9.1.0596: filetype: devscripts config files are not recognized
  9.1.0595: make errors out with the po Makefile
  9.1.0594: Unnecessary redraw when setting 'winfixbuf'
  9.1.0593: filetype: Asymptote files are not recognized
  9.1.0592: runtime: filetype: Mediawiki files are not recognized
  9.1.0591: filetype: *.wl files are not recognized
  9.1.0590: Vim9: crash when accessing getregionpos() return value
  9.1.0589: vi: d{motion} and cw work differently than expected
  9.1.0588: The maze program no longer compiles on newer clang
  9.1.0587: tests: Test_gui_lowlevel_keyevent is still flaky
  9.1.0586: ocaml runtime files are outdated
  9.1.0585: tests: test_cpoptions leaves swapfiles around
  9.1.0584: Warning about redeclaring f_id() non-static
  9.1.0583: filetype: *.pdf_tex files are not recognized
  9.1.0582: Printed line doesn't overwrite colon when pressing Enter in Ex mode
  9.1.0581: Various lines are indented inconsistently
  9.1.0580: :lmap mapping for keypad key not applied when typed in Select mode
  9.1.0579: Ex command is still executed after giving E1247
  9.1.0578: no tests for :Tohtml
  9.1.0577: Unnecessary checks for v:sizeoflong in test_put.vim
  9.1.0576: tests: still an issue with test_gettext_make
  9.1.0575: Wrong comments in alt_tabpage()
  9.1.0574: ex: wrong handling of commands after bar
  9.1.0573: ex: no implicit print for single addresses
  9.1.0572: cannot specify tab page closing behaviour
  9.1.0571: tests: Test_gui_lowlevel_keyevent is flaky
  9.1.0570: tests: test_gettext_make can be improved
  9.1.0569: fnamemodify() treats &amp;quot;..&amp;quot; and &amp;quot;../&amp;quot; differently
  9.1.0568: Cannot expand paths from 'cdpath' setting
  9.1.0567: Cannot use relative paths as findfile() stop directories
  9.1.0566: Stop dir in findfile() doesn't work properly w/o trailing slash
  9.1.0565: Stop directory doesn't work properly in 'tags'
  9.1.0564: id() can be faster
  9.1.0563: Cannot process any Key event
  9.1.0562: tests: inconsistency in test_findfile.vim
  9.1.0561: netbeans: variable used un-initialized (Coverity)
  9.1.0560: bindtextdomain() does not indicate an error
  9.1.0559: translation of vim scripts can be improved
  9.1.0558: filetype: prolog detection can be improved
  9.1.0557: moving in the buffer list doesn't work as documented
  9.1.0556: :bwipe doesn't remove file from jumplist of other tabpages
  9.1.0555: filetype: angular ft detection is still problematic
  9.1.0554: :bw leaves jumplist and tagstack data around
  9.1.0553: filetype: *.mcmeta files are not recognized
  9.1.0552: No test for antlr4 filetype
  9.1.0551: filetype: htmlangular files are not properly detected
  9.1.0550: filetype: antlr4 files are not recognized
  9.1.0549: fuzzycollect regex based completion not working as expected
  9.1.0548: it's not possible to get a unique id for some vars
  9.1.0547: No way to get the arity of a Vim function
  9.1.0546: vim-tiny fails on CTRL-X/CTRL-A
  9.1.0545: MSVC conversion warning
  9.1.0544: filetype: ldapconf files are not recognized
  9.1.0543: Behavior of CursorMovedC is strange
  9.1.0542: Vim9: confusing string() output for object functions
  9.1.0541: failing test with Vim configured without channel
  9.1.0540: Unused assignment in sign_define_cmd()
  9.1.0539: Not enough tests for what v9.1.0535 fixed
  9.1.0538: not possible to assign priority when defining a sign
  9.1.0537: signed number detection for CTRL-X/A can be improved
  9.1.0536: filetype: zone files are not recognized
  9.1.0535: newline escape wrong in ex mode
  9.1.0534: completion wrong with fuzzy when cycling back to original
  9.1.0533: Vim9: need more tests for nested objects equality
  9.1.0532: filetype: Cedar files not recognized
  9.1.0531: resource leak in mch_get_random()
  9.1.0530: xxd: MSVC warning about non-ASCII character
  9.1.0529: silent! causes following try/catch to not work
  9.1.0528: spell completion message still wrong in translations
  9.1.0527: inconsistent parameter in Makefiles for Vim executable
  9.1.0526: Unwanted cursor movement with pagescroll at start of buffer
  9.1.0525: Right release selects immediately when pum is truncated.
  9.1.0524: the recursive parameter in the *_equal functions can be removed
  9.1.0523: Vim9: cannot downcast an object
  9.1.0522: Vim9: string(object) hangs for recursive references
  9.1.0521: if_py: _PyObject_CallFunction_SizeT is dropped in Python 3.13
  9.1.0520: Vim9: incorrect type checking for modifying lists
  9.1.0519: MS-Windows: libvterm compilation can be optimized
  9.1.0518: initialize the random buffer can be improved
  9.1.0517: MS-Windows: too long lines in Make_mvc.mak
  9.1.0516: need more tests for nested dicts and list comparision
  9.1.0515: Vim9: segfault in object_equal()
  9.1.0514: Vim9: issue with comparing objects recursively
  9.1.0513: Vim9: segfault with object comparison
  9.1.0512: Mode message for spell completion doesn't match allowed keys
  9.1.0511: CursorMovedC triggered wrongly with setcmdpos()
  9.1.0510: CI: test_gettext fails on MacOS14 + MSVC Win
  9.1.0509: not possible to translate Vim script messages
  9.1.0508: termdebug plugin can be further improved
  9.1.0507: hard to detect cursor movement in the command line
  9.1.0506: filetype: .envrc &amp;amp; .prettierignore not recognized
  9.1.0505: filetype: Faust files are not recognized
  9.1.0504: inner-tag textobject confused about &amp;quot;&amp;gt;&amp;quot; in attributes
  9.1.0503: cannot use fuzzy keyword completion
  9.1.0502: MS-Windows: too much legacy code
  9.1.0501: too complicated mapping restore in termdebug
  9.1.0500: cannot switch buffer in a popup
  9.1.0499: MS-Windows: doesn't handle symlinks properly
  9.1.0498: getcmdcompltype() interferes with cmdline completion
  9.1.0497: termdebug can be further improved
  9.1.0496: matched text is highlighted case-sensitively
  9.1.0495: Matched text isn't highlighted in cmdline pum
  9.1.0494: Wrong matched text highlighted in pum with 'rightleft'
  9.1.0493: Test for patch 9.1.0489 doesn't fail without the fix
  9.1.0492: filetype: Vim-script files not detected by shebang line
  9.1.0491: Cmdline pum doesn't work properly with 'rightleft'
  9.1.0490: minor style problems with patch 9.1.0487
  9.1.0489: default completion may break with fuzzy
  9.1.0488: Wrong padding for pum &amp;quot;kind&amp;quot; with 'rightleft'
  9.1.0487: completed item not update on fuzzy completion
  9.1.0486: filetype: Snakemake files are not recognized
  9.1.0485: Matched text shouldn't be highlighted in &amp;quot;kind&amp;quot; and &amp;quot;menu&amp;quot;
  9.1.0484: Sorting of completeopt+=fuzzy is not stable
  9.1.0483: glob() not sufficiently tested
  9.1.0482: termdebug plugin needs more love
  9.1.0481: Vim9: term_getjob() throws an exception on error
  9.1.0480: fuzzy string matching executed when not needed
  9.1.0479: fuzzy_match_str_with_pos() does unnecessary list operations
  9.1.0478: potential deref of NULL pointer in fuzzy_match_str_with_pos
  9.1.0477: block_editing errors out when using &amp;lt;enter&amp;gt;
  9.1.0476: Cannot see matched text in popup menu
  9.1.0475: cmod_split modifier is always reset in term_start()
  9.1.0474: CI: Test_ColonEight() fails on github runners
  9.1.0473: term_start() does not clear vertical modifier
  9.1.0472: Inconsistencies between functions for option flags
  9.1.0471: Crash when using autocmd_get() after removing event inside autocmd
  9.1.0470: tests: Test_ColonEight_MultiByte() fails sporadically
  9.1.0469: Cannot have buffer-local value for 'completeopt'
  9.1.0468: GvimExt does not consult HKEY_CURRENT_USER
  9.1.0467: typos in some comments
  9.1.0466: Missing comments for fuzzy completion
  9.1.0465: missing filecopy() function
  9.1.0464: no whitespace padding in commentstring option in ftplugins
  9.1.0463: no fuzzy-matching support for insert-completion
  9.1.0462: eval5() and eval7 are too complex
  9.1.0461: too many strlen() calls in drawline.c
  9.1.0460: filetype: lintstagedrc files are not recognized
  9.1.0459: Vim9: import autoload does not work with symlink
  9.1.0458: Coverity complains about division by zero
  9.1.0457: tests: test_gui fails on Wayland
  9.1.0456: Left shift is incorrect with vartabstop and shiftwidth=0
  9.1.0455: MS-Windows: compiler warning for size_t to int conversion
  9.1.0454: minor issues in test_filetype with rasi test
  9.1.0453: filetype: rasi files are not recognized
  9.1.0452: Configure checks for libelf unnecessarily
  9.1.0451: No test for escaping '&amp;lt;' with shellescape()
  9.1.0450: evalc. code too complex
  9.1.0449: MS-Windows: Compiler warnings
  9.1.0448: compiler warning in eval.c
  9.1.0447: completion may be wrong when deleting all chars
  9.1.0446: getregionpos() inconsistent for partly-selected multibyte char
  9.1.0445: Coverity warning after 9.1.0440
  9.1.0444: Not enough tests for getregion() with multibyte chars
  9.1.0443: Can't use blockwise selection with width for getregion()
  9.1.0442: hare runtime files outdated
  9.1.0441: getregionpos() can't properly indicate positions beyond eol
  9.1.0440: function get_lval() is too long
  9.1.0439: Cannot filter the history
  9.1.0438: Wrong Ex command executed when :g uses '?' as delimiter
  9.1.0437: Motif requires non-const char pointer for XPM  data
  9.1.0436: Crash when using '?' as separator for :s
  9.1.0435: filetype: cygport files are not recognized
  9.1.0434: make errors trying to access autoload/zig
  9.1.0433: Wrong yanking with exclusive selection and ve=all
  9.1.0432: Ancient XPM preprocessor hack may cause build errors
  9.1.0431: eval.c is too long
  9.1.0430: getregionpos() doesn't handle one char selection
  9.1.0429: Coverity complains about eval.c refactor
  9.1.0428: Tag guessing leaves wrong search history with very short names
  9.1.0427: tests: some issues with termdebug mapping test
  9.1.0426: too many strlen() calls in search.c
  9.1.0425: filetype: purescript files are not recognized
  9.1.0424: filetype: slint files are not recognized
  9.1.0423: getregionpos() wrong with blockwise mode and multibyte
  9.1.0422: function echo_string_core() is too long
  9.1.0421: filetype: hyprlang files are not recognized
  9.1.0420: :browse oldfiles prompts even with single entry
  9.1.0419: eval.c not sufficiently tested
  9.1.0418: Cannot move to previous/next rare word
  9.1.0417: if_py: find_module has been removed in Python 3.12.0a7
  9.1.0416: some screen dump tests can be improved
  9.1.0415: Some functions are not tested
  9.1.0414: Unable to leave long line with 'smoothscroll' and 'scrolloff'
  9.1.0413: smoothscroll may cause infinite loop
  9.1.0412: typo in regexp_bt.c in DEBUG code
  9.1.0411: too long functions in eval.c
  9.1.0410: warning about uninitialized variable
  9.1.0409: too many strlen() calls in the regexp engine
  9.1.0408: configure fails on Fedora when including perl
  9.1.0407: Stuck with long line and half-page scrolling
  9.1.0406: Divide by zero with getmousepos() and 'smoothscroll'
  9.1.0405: tests: xxd buffer overflow fails on 32-bit
  9.1.0404: [security] xxd: buffer-overflow with specific flags
  9.1.0403: Vim9: not able to import file from start dir
  9.1.0402: filetype: mdd files detected as zsh filetype
  9.1.0401: filetype: zsh module files are not recognized
  9.1.0400: Vim9: confusing error message for unknown type
  9.1.0399: block_editing errors out when using del
  9.1.0398: Vim9: imported vars are not properly type checked
  9.1.0397: Wrong display with 'smoothscroll' when changing quickfix list
  9.1.0396: filetype: jj files are not recognized
  9.1.0395: getregionpos() may leak memory on error
  9.1.0394: Cannot get a list of positions describing a region
  9.1.0393: 'viewdir' not respecting $XDG_CONFIG_HOME
  9.1.0392: tests: Vim9 debug tests may be flaky
  9.1.0391: Vim9: could improve testing
  9.1.0390: filetype: inko files are not recognized
  9.1.0389: filetype: templ files are not recognized
  9.1.0388: cursor() and getregion() don't handle v:maxcol well
  9.1.0387: Vim9: null value tests not sufficient
  9.1.0386: filetype: stylus files not recognized
  9.1.0385: Vim9: crash with null_class and null_object
  9.1.0384: tests: vt420 terminfo entry may not be found
  9.1.0383: filetype: .out files recognized as tex files
  9.1.0382: filetype: Kbuild files are not recognized
  9.1.0381: cbuffer and similar commands don't accept a range
  9.1.0380: Calculating line height for unnecessary amount of lines
  9.1.0379: There are a few typos
  9.1.0378: Vim9: no comments allowed after class vars
  9.1.0377: Formatting text wrong when 'breakindent' is set
  9.1.0376: Vim9: Trailing commands after class/enum keywords ignored
  9.1.0375: tests: 1-second delay after Test_BufEnter_botline()
  9.1.0374: wrong botline in BufEnter
  9.1.0373: ops.c code uses too many strlen() calls
  9.1.0372: Calling CLEAR_FIELD() on the same struct twice
  9.1.0371: Vim9: compile_def_function() still too long
  9.1.0370: MS-Windows: patch number is zero in installer
  9.1.0369: Vim9: problem when importing autoloaded scripts
  9.1.0368: MS-Windows: Hard to define the Vim Patchlevel with leading zeroes
  9.1.0367: compile_def_function is too long
  9.1.0366: filetype: ondir files are not recognized
  9.1.0365: Crash when typing many keys with D- modifier
  9.1.0364: tests: test_vim9_builtin is a bit slow
  9.1.0363: tests: test_winfixbuf is a bit slow
  9.1.0362: expanding rc config files does not work well
  9.1.0361: Vim9: vim9type.c is too complicated
  9.1.0360: Vim9: does not handle autoloaded variables well
  9.1.0359: MS-Windows: relative import in a script sourced from a buffer doesn't work
  9.1.0358: wrong drawing in GUI with setcellwidth()
  9.1.0357: Page scrolling should place cursor at window boundaries
  9.1.0356: MS-Windows: --remote may change working directory
  9.1.0355: filetype: flake.lock files are not recognized
  9.1.0354: runtime(uci): No support for uci file types
  9.1.0353: tests: Test_autoload_import_relative_compiled fails on Windows
  9.1.0352: Finding cmd modifiers and cmdline-specials is inefficient
  9.1.0351: No test that completing a partial mapping clears 'showcmd'
  9.1.0350: tests: test_vim9_dissamble may fail
  9.1.0349: Vim9: need static type for typealias
  9.1.0348: X11 does not ignore smooth scroll event
  9.1.0347: A few typos in test_xdg when testing gvimrc
  9.1.0346: Patch v9.1.0338 fixed sourcing a script with import
  9.1.0345: Problem: gvimrc not sourced from XDG_CONFIG_HOME
  9.1.0344: Cursor wrong after using setcellwidth() in terminal
  9.1.0343: 'showcmd' wrong for partial mapping with multibyte
  9.1.0342: tests: test_taglist fails when 'helplang' contains non-english
  9.1.0341: Problem: a few memory leaks are found
  9.1.0340: Problem: Error with matchaddpos() and empty list
  9.1.0339: tests: xdg test uses screen dumps
  9.1.0338: Vim9: import through symlinks not correctly handled
  9.1.0337: Missing entry for XDG vimrc file in :version
  9.1.0336: tests: typo in test_xdg
  9.1.0335: String interpolation fails for List type
  9.1.0334: No test for highlight behavior with 'ambiwidth'
  9.1.0333: tests: test_xdg fails on the appimage repo
  9.1.0332: tests: some assert_equal() calls have wrong order of args
  9.1.0331: make install does not install all files

Package zypper was updated:

- Fixed `bash-completion`: `zypper refresh` now ignores  repository priority lines.
- Changes to support building against restructured libzypp in
  stack build (bsc#1230267)
- version 1.14.94

</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-micro-6-1-byos-v20251124-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-micro-6-1-byos-v20251124-x86-64">
      <Branch Type="Product Name" Name="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
        <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
      </Branch>
    </Branch>
    <Branch Type="Product Version" Name="SL-Micro-release-6.1-slfo.1.11.69">
      <FullProductName ProductID="SL-Micro-release-6.1-slfo.1.11.69">SL-Micro-release-6.1-slfo.1.11.69</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="aaa_base-84.87+git20250903.33e5ba4-slfo.1.1_1.1">
      <FullProductName ProductID="aaa_base-84.87+git20250903.33e5ba4-slfo.1.1_1.1">aaa_base-84.87+git20250903.33e5ba4-slfo.1.1_1.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="audit-3.1.1-slfo.1.1_2.1">
      <FullProductName ProductID="audit-3.1.1-slfo.1.1_2.1">audit-3.1.1-slfo.1.1_2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="chrony-4.8-slfo.1.1_1.1">
      <FullProductName ProductID="chrony-4.8-slfo.1.1_1.1">chrony-4.8-slfo.1.1_1.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="chrony-pool-suse-4.8-slfo.1.1_1.1">
      <FullProductName ProductID="chrony-pool-suse-4.8-slfo.1.1_1.1">chrony-pool-suse-4.8-slfo.1.1_1.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cloud-regionsrv-client-10.5.2-slfo.1.1_6.1">
      <FullProductName ProductID="cloud-regionsrv-client-10.5.2-slfo.1.1_6.1">cloud-regionsrv-client-10.5.2-slfo.1.1_6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cloud-regionsrv-client-license-watcher-1.0.0-slfo.1.1_6.1">
      <FullProductName ProductID="cloud-regionsrv-client-license-watcher-1.0.0-slfo.1.1_6.1">cloud-regionsrv-client-license-watcher-1.0.0-slfo.1.1_6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cloud-regionsrv-client-plugin-gce-1.0.0-slfo.1.1_6.1">
      <FullProductName ProductID="cloud-regionsrv-client-plugin-gce-1.0.0-slfo.1.1_6.1">cloud-regionsrv-client-plugin-gce-1.0.0-slfo.1.1_6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="containerd-1.7.29-slfo.1.1_1.1">
      <FullProductName ProductID="containerd-1.7.29-slfo.1.1_1.1">containerd-1.7.29-slfo.1.1_1.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="coreutils-9.4-slfo.1.1_2.1">
      <FullProductName ProductID="coreutils-9.4-slfo.1.1_2.1">coreutils-9.4-slfo.1.1_2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="coreutils-systemd-9.4-slfo.1.1_2.1">
      <FullProductName ProductID="coreutils-systemd-9.4-slfo.1.1_2.1">coreutils-systemd-9.4-slfo.1.1_2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="curl-8.14.1-slfo.1.1_2.1">
      <FullProductName ProductID="curl-8.14.1-slfo.1.1_2.1">curl-8.14.1-slfo.1.1_2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="docker-28.5.1_ce-slfo.1.1_7.1">
      <FullProductName ProductID="docker-28.5.1_ce-slfo.1.1_7.1">docker-28.5.1_ce-slfo.1.1_7.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="docker-buildx-0.29.0-slfo.1.1_7.1">
      <FullProductName ProductID="docker-buildx-0.29.0-slfo.1.1_7.1">docker-buildx-0.29.0-slfo.1.1_7.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="dracut-059+suse.641.g906a3d31-slfo.1.1_1.1">
      <FullProductName ProductID="dracut-059+suse.641.g906a3d31-slfo.1.1_1.1">dracut-059+suse.641.g906a3d31-slfo.1.1_1.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glib2-tools-2.78.6-slfo.1.1_5.1">
      <FullProductName ProductID="glib2-tools-2.78.6-slfo.1.1_5.1">glib2-tools-2.78.6-slfo.1.1_5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="google-osconfig-agent-20250416.02-slfo.1.1_1.1">
      <FullProductName ProductID="google-osconfig-agent-20250416.02-slfo.1.1_1.1">google-osconfig-agent-20250416.02-slfo.1.1_1.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="grub2-2.12-slfo.1.1_3.1">
      <FullProductName ProductID="grub2-2.12-slfo.1.1_3.1">grub2-2.12-slfo.1.1_3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="grub2-i386-pc-2.12-slfo.1.1_3.1">
      <FullProductName ProductID="grub2-i386-pc-2.12-slfo.1.1_3.1">grub2-i386-pc-2.12-slfo.1.1_3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="grub2-snapper-plugin-2.12-slfo.1.1_3.1">
      <FullProductName ProductID="grub2-snapper-plugin-2.12-slfo.1.1_3.1">grub2-snapper-plugin-2.12-slfo.1.1_3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="grub2-x86_64-efi-2.12-slfo.1.1_3.1">
      <FullProductName ProductID="grub2-x86_64-efi-2.12-slfo.1.1_3.1">grub2-x86_64-efi-2.12-slfo.1.1_3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="kernel-default-6.4.0-36.1">
      <FullProductName ProductID="kernel-default-6.4.0-36.1">kernel-default-6.4.0-36.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libaudit1-3.1.1-slfo.1.1_2.1">
      <FullProductName ProductID="libaudit1-3.1.1-slfo.1.1_2.1">libaudit1-3.1.1-slfo.1.1_2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libauparse0-3.1.1-slfo.1.1_2.1">
      <FullProductName ProductID="libauparse0-3.1.1-slfo.1.1_2.1">libauparse0-3.1.1-slfo.1.1_2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libcurl4-8.14.1-slfo.1.1_2.1">
      <FullProductName ProductID="libcurl4-8.14.1-slfo.1.1_2.1">libcurl4-8.14.1-slfo.1.1_2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libexpat1-2.7.1-slfo.1.1_3.1">
      <FullProductName ProductID="libexpat1-2.7.1-slfo.1.1_3.1">libexpat1-2.7.1-slfo.1.1_3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libexslt0-1.1.38-slfo.1.1_5.1">
      <FullProductName ProductID="libexslt0-1.1.38-slfo.1.1_5.1">libexslt0-1.1.38-slfo.1.1_5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libfreebl3-3.112.2-slfo.1.1_1.1">
      <FullProductName ProductID="libfreebl3-3.112.2-slfo.1.1_1.1">libfreebl3-3.112.2-slfo.1.1_1.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgcrypt20-1.10.3-slfo.1.1_3.1">
      <FullProductName ProductID="libgcrypt20-1.10.3-slfo.1.1_3.1">libgcrypt20-1.10.3-slfo.1.1_3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgio-2_0-0-2.78.6-slfo.1.1_5.1">
      <FullProductName ProductID="libgio-2_0-0-2.78.6-slfo.1.1_5.1">libgio-2_0-0-2.78.6-slfo.1.1_5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libglib-2_0-0-2.78.6-slfo.1.1_5.1">
      <FullProductName ProductID="libglib-2_0-0-2.78.6-slfo.1.1_5.1">libglib-2_0-0-2.78.6-slfo.1.1_5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgmodule-2_0-0-2.78.6-slfo.1.1_5.1">
      <FullProductName ProductID="libgmodule-2_0-0-2.78.6-slfo.1.1_5.1">libgmodule-2_0-0-2.78.6-slfo.1.1_5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgnutls30-3.8.3-slfo.1.1_4.1">
      <FullProductName ProductID="libgnutls30-3.8.3-slfo.1.1_4.1">libgnutls30-3.8.3-slfo.1.1_4.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgobject-2_0-0-2.78.6-slfo.1.1_5.1">
      <FullProductName ProductID="libgobject-2_0-0-2.78.6-slfo.1.1_5.1">libgobject-2_0-0-2.78.6-slfo.1.1_5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgpgme11-1.23.0-slfo.1.1_2.1">
      <FullProductName ProductID="libgpgme11-1.23.0-slfo.1.1_2.1">libgpgme11-1.23.0-slfo.1.1_2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libopenssl3-3.1.4-slfo.1.1_7.1">
      <FullProductName ProductID="libopenssl3-3.1.4-slfo.1.1_7.1">libopenssl3-3.1.4-slfo.1.1_7.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libpolkit-agent-1-0-121-slfo.1.1_2.1">
      <FullProductName ProductID="libpolkit-agent-1-0-121-slfo.1.1_2.1">libpolkit-agent-1-0-121-slfo.1.1_2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libpolkit-gobject-1-0-121-slfo.1.1_2.1">
      <FullProductName ProductID="libpolkit-gobject-1-0-121-slfo.1.1_2.1">libpolkit-gobject-1-0-121-slfo.1.1_2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libpython3_11-1_0-3.11.13-slfo.1.1_2.1">
      <FullProductName ProductID="libpython3_11-1_0-3.11.13-slfo.1.1_2.1">libpython3_11-1_0-3.11.13-slfo.1.1_2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsoftokn3-3.112.2-slfo.1.1_1.1">
      <FullProductName ProductID="libsoftokn3-3.112.2-slfo.1.1_1.1">libsoftokn3-3.112.2-slfo.1.1_1.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsqlite3-0-3.50.4-slfo.1.1_1.1">
      <FullProductName ProductID="libsqlite3-0-3.50.4-slfo.1.1_1.1">libsqlite3-0-3.50.4-slfo.1.1_1.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libssh-config-0.10.6-slfo.1.1_3.1">
      <FullProductName ProductID="libssh-config-0.10.6-slfo.1.1_3.1">libssh-config-0.10.6-slfo.1.1_3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libssh4-0.10.6-slfo.1.1_3.1">
      <FullProductName ProductID="libssh4-0.10.6-slfo.1.1_3.1">libssh4-0.10.6-slfo.1.1_3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libxml2-2-2.11.6-slfo.1.1_6.1">
      <FullProductName ProductID="libxml2-2-2.11.6-slfo.1.1_6.1">libxml2-2-2.11.6-slfo.1.1_6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libxml2-tools-2.11.6-slfo.1.1_6.1">
      <FullProductName ProductID="libxml2-tools-2.11.6-slfo.1.1_6.1">libxml2-tools-2.11.6-slfo.1.1_6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libxslt1-1.1.38-slfo.1.1_5.1">
      <FullProductName ProductID="libxslt1-1.1.38-slfo.1.1_5.1">libxslt1-1.1.38-slfo.1.1_5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libzypp-17.37.18-slfo.1.1_1.1">
      <FullProductName ProductID="libzypp-17.37.18-slfo.1.1_1.1">libzypp-17.37.18-slfo.1.1_1.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="mozilla-nspr-4.36-slfo.1.1_1.1">
      <FullProductName ProductID="mozilla-nspr-4.36-slfo.1.1_1.1">mozilla-nspr-4.36-slfo.1.1_1.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="mozilla-nss-3.112.2-slfo.1.1_1.1">
      <FullProductName ProductID="mozilla-nss-3.112.2-slfo.1.1_1.1">mozilla-nss-3.112.2-slfo.1.1_1.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="mozilla-nss-certs-3.112.2-slfo.1.1_1.1">
      <FullProductName ProductID="mozilla-nss-certs-3.112.2-slfo.1.1_1.1">mozilla-nss-certs-3.112.2-slfo.1.1_1.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssl-3-3.1.4-slfo.1.1_7.1">
      <FullProductName ProductID="openssl-3-3.1.4-slfo.1.1_7.1">openssl-3-3.1.4-slfo.1.1_7.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="pam-1.6.1-slfo.1.1_4.1">
      <FullProductName ProductID="pam-1.6.1-slfo.1.1_4.1">pam-1.6.1-slfo.1.1_4.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="podman-5.4.2-slfo.1.1_2.1">
      <FullProductName ProductID="podman-5.4.2-slfo.1.1_2.1">podman-5.4.2-slfo.1.1_2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="polkit-121-slfo.1.1_2.1">
      <FullProductName ProductID="polkit-121-slfo.1.1_2.1">polkit-121-slfo.1.1_2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-audit-3.1.1-slfo.1.1_2.1">
      <FullProductName ProductID="python3-audit-3.1.1-slfo.1.1_2.1">python3-audit-3.1.1-slfo.1.1_2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python311-3.11.13-slfo.1.1_2.1">
      <FullProductName ProductID="python311-3.11.13-slfo.1.1_2.1">python311-3.11.13-slfo.1.1_2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python311-base-3.11.13-slfo.1.1_2.1">
      <FullProductName ProductID="python311-base-3.11.13-slfo.1.1_2.1">python311-base-3.11.13-slfo.1.1_2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python311-libxml2-2.11.6-slfo.1.1_6.1">
      <FullProductName ProductID="python311-libxml2-2.11.6-slfo.1.1_6.1">python311-libxml2-2.11.6-slfo.1.1_6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python311-urllib3-2.1.0-slfo.1.1_2.1">
      <FullProductName ProductID="python311-urllib3-2.1.0-slfo.1.1_2.1">python311-urllib3-2.1.0-slfo.1.1_2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="regionServiceClientConfigGCE-5.0.0-slfo.1.1_1.1">
      <FullProductName ProductID="regionServiceClientConfigGCE-5.0.0-slfo.1.1_1.1">regionServiceClientConfigGCE-5.0.0-slfo.1.1_1.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="runc-1.3.3-slfo.1.1_1.1">
      <FullProductName ProductID="runc-1.3.3-slfo.1.1_1.1">runc-1.3.3-slfo.1.1_1.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="selinux-policy-20241031+git12.52417acff-slfo.1.1_1.1">
      <FullProductName ProductID="selinux-policy-20241031+git12.52417acff-slfo.1.1_1.1">selinux-policy-20241031+git12.52417acff-slfo.1.1_1.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="selinux-policy-targeted-20241031+git12.52417acff-slfo.1.1_1.1">
      <FullProductName ProductID="selinux-policy-targeted-20241031+git12.52417acff-slfo.1.1_1.1">selinux-policy-targeted-20241031+git12.52417acff-slfo.1.1_1.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="supportutils-plugin-suse-public-cloud-1.0.9-slfo.1.1_1.1">
      <FullProductName ProductID="supportutils-plugin-suse-public-cloud-1.0.9-slfo.1.1_1.1">supportutils-plugin-suse-public-cloud-1.0.9-slfo.1.1_1.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="suse-build-key-12.0-slfo.1.1_4.1">
      <FullProductName ProductID="suse-build-key-12.0-slfo.1.1_4.1">suse-build-key-12.0-slfo.1.1_4.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="system-group-audit-3.1.1-slfo.1.1_2.1">
      <FullProductName ProductID="system-group-audit-3.1.1-slfo.1.1_2.1">system-group-audit-3.1.1-slfo.1.1_2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="update-alternatives-1.22.0-slfo.1.1_2.1">
      <FullProductName ProductID="update-alternatives-1.22.0-slfo.1.1_2.1">update-alternatives-1.22.0-slfo.1.1_2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="vim-data-common-9.1.1629-slfo.1.1_1.1">
      <FullProductName ProductID="vim-data-common-9.1.1629-slfo.1.1_1.1">vim-data-common-9.1.1629-slfo.1.1_1.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="vim-small-9.1.1629-slfo.1.1_1.1">
      <FullProductName ProductID="vim-small-9.1.1629-slfo.1.1_1.1">vim-small-9.1.1629-slfo.1.1_1.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="zypper-1.14.94-slfo.1.1_1.1">
      <FullProductName ProductID="zypper-1.14.94-slfo.1.1_1.1">zypper-1.14.94-slfo.1.1_1.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="zypper-needs-restarting-1.14.94-slfo.1.1_1.1">
      <FullProductName ProductID="zypper-needs-restarting-1.14.94-slfo.1.1_1.1">zypper-needs-restarting-1.14.94-slfo.1.1_1.1</FullProductName>
    </Branch>
    <Relationship ProductReference="SL-Micro-release-6.1-slfo.1.11.69" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:SL-Micro-release-6.1-slfo.1.11.69">SL-Micro-release-6.1-slfo.1.11.69 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="aaa_base-84.87+git20250903.33e5ba4-slfo.1.1_1.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:aaa_base-84.87+git20250903.33e5ba4-slfo.1.1_1.1">aaa_base-84.87+git20250903.33e5ba4-slfo.1.1_1.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="audit-3.1.1-slfo.1.1_2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:audit-3.1.1-slfo.1.1_2.1">audit-3.1.1-slfo.1.1_2.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="chrony-4.8-slfo.1.1_1.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:chrony-4.8-slfo.1.1_1.1">chrony-4.8-slfo.1.1_1.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="chrony-pool-suse-4.8-slfo.1.1_1.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:chrony-pool-suse-4.8-slfo.1.1_1.1">chrony-pool-suse-4.8-slfo.1.1_1.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cloud-regionsrv-client-10.5.2-slfo.1.1_6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:cloud-regionsrv-client-10.5.2-slfo.1.1_6.1">cloud-regionsrv-client-10.5.2-slfo.1.1_6.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cloud-regionsrv-client-license-watcher-1.0.0-slfo.1.1_6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:cloud-regionsrv-client-license-watcher-1.0.0-slfo.1.1_6.1">cloud-regionsrv-client-license-watcher-1.0.0-slfo.1.1_6.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cloud-regionsrv-client-plugin-gce-1.0.0-slfo.1.1_6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:cloud-regionsrv-client-plugin-gce-1.0.0-slfo.1.1_6.1">cloud-regionsrv-client-plugin-gce-1.0.0-slfo.1.1_6.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="containerd-1.7.29-slfo.1.1_1.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:containerd-1.7.29-slfo.1.1_1.1">containerd-1.7.29-slfo.1.1_1.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="coreutils-9.4-slfo.1.1_2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:coreutils-9.4-slfo.1.1_2.1">coreutils-9.4-slfo.1.1_2.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="coreutils-systemd-9.4-slfo.1.1_2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:coreutils-systemd-9.4-slfo.1.1_2.1">coreutils-systemd-9.4-slfo.1.1_2.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="curl-8.14.1-slfo.1.1_2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:curl-8.14.1-slfo.1.1_2.1">curl-8.14.1-slfo.1.1_2.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="docker-28.5.1_ce-slfo.1.1_7.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:docker-28.5.1_ce-slfo.1.1_7.1">docker-28.5.1_ce-slfo.1.1_7.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="docker-buildx-0.29.0-slfo.1.1_7.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:docker-buildx-0.29.0-slfo.1.1_7.1">docker-buildx-0.29.0-slfo.1.1_7.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="dracut-059+suse.641.g906a3d31-slfo.1.1_1.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:dracut-059+suse.641.g906a3d31-slfo.1.1_1.1">dracut-059+suse.641.g906a3d31-slfo.1.1_1.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glib2-tools-2.78.6-slfo.1.1_5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:glib2-tools-2.78.6-slfo.1.1_5.1">glib2-tools-2.78.6-slfo.1.1_5.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="google-osconfig-agent-20250416.02-slfo.1.1_1.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:google-osconfig-agent-20250416.02-slfo.1.1_1.1">google-osconfig-agent-20250416.02-slfo.1.1_1.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="grub2-2.12-slfo.1.1_3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:grub2-2.12-slfo.1.1_3.1">grub2-2.12-slfo.1.1_3.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="grub2-i386-pc-2.12-slfo.1.1_3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:grub2-i386-pc-2.12-slfo.1.1_3.1">grub2-i386-pc-2.12-slfo.1.1_3.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="grub2-snapper-plugin-2.12-slfo.1.1_3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:grub2-snapper-plugin-2.12-slfo.1.1_3.1">grub2-snapper-plugin-2.12-slfo.1.1_3.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="grub2-x86_64-efi-2.12-slfo.1.1_3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:grub2-x86_64-efi-2.12-slfo.1.1_3.1">grub2-x86_64-efi-2.12-slfo.1.1_3.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="kernel-default-6.4.0-36.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:kernel-default-6.4.0-36.1">kernel-default-6.4.0-36.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libaudit1-3.1.1-slfo.1.1_2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:libaudit1-3.1.1-slfo.1.1_2.1">libaudit1-3.1.1-slfo.1.1_2.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libauparse0-3.1.1-slfo.1.1_2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:libauparse0-3.1.1-slfo.1.1_2.1">libauparse0-3.1.1-slfo.1.1_2.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libcurl4-8.14.1-slfo.1.1_2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:libcurl4-8.14.1-slfo.1.1_2.1">libcurl4-8.14.1-slfo.1.1_2.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libexpat1-2.7.1-slfo.1.1_3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:libexpat1-2.7.1-slfo.1.1_3.1">libexpat1-2.7.1-slfo.1.1_3.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libexslt0-1.1.38-slfo.1.1_5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:libexslt0-1.1.38-slfo.1.1_5.1">libexslt0-1.1.38-slfo.1.1_5.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libfreebl3-3.112.2-slfo.1.1_1.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:libfreebl3-3.112.2-slfo.1.1_1.1">libfreebl3-3.112.2-slfo.1.1_1.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgcrypt20-1.10.3-slfo.1.1_3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:libgcrypt20-1.10.3-slfo.1.1_3.1">libgcrypt20-1.10.3-slfo.1.1_3.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgio-2_0-0-2.78.6-slfo.1.1_5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:libgio-2_0-0-2.78.6-slfo.1.1_5.1">libgio-2_0-0-2.78.6-slfo.1.1_5.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libglib-2_0-0-2.78.6-slfo.1.1_5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:libglib-2_0-0-2.78.6-slfo.1.1_5.1">libglib-2_0-0-2.78.6-slfo.1.1_5.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgmodule-2_0-0-2.78.6-slfo.1.1_5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:libgmodule-2_0-0-2.78.6-slfo.1.1_5.1">libgmodule-2_0-0-2.78.6-slfo.1.1_5.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgnutls30-3.8.3-slfo.1.1_4.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:libgnutls30-3.8.3-slfo.1.1_4.1">libgnutls30-3.8.3-slfo.1.1_4.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgobject-2_0-0-2.78.6-slfo.1.1_5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:libgobject-2_0-0-2.78.6-slfo.1.1_5.1">libgobject-2_0-0-2.78.6-slfo.1.1_5.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgpgme11-1.23.0-slfo.1.1_2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:libgpgme11-1.23.0-slfo.1.1_2.1">libgpgme11-1.23.0-slfo.1.1_2.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libopenssl3-3.1.4-slfo.1.1_7.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:libopenssl3-3.1.4-slfo.1.1_7.1">libopenssl3-3.1.4-slfo.1.1_7.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libpolkit-agent-1-0-121-slfo.1.1_2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:libpolkit-agent-1-0-121-slfo.1.1_2.1">libpolkit-agent-1-0-121-slfo.1.1_2.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libpolkit-gobject-1-0-121-slfo.1.1_2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:libpolkit-gobject-1-0-121-slfo.1.1_2.1">libpolkit-gobject-1-0-121-slfo.1.1_2.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libpython3_11-1_0-3.11.13-slfo.1.1_2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:libpython3_11-1_0-3.11.13-slfo.1.1_2.1">libpython3_11-1_0-3.11.13-slfo.1.1_2.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsoftokn3-3.112.2-slfo.1.1_1.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:libsoftokn3-3.112.2-slfo.1.1_1.1">libsoftokn3-3.112.2-slfo.1.1_1.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsqlite3-0-3.50.4-slfo.1.1_1.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:libsqlite3-0-3.50.4-slfo.1.1_1.1">libsqlite3-0-3.50.4-slfo.1.1_1.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libssh-config-0.10.6-slfo.1.1_3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:libssh-config-0.10.6-slfo.1.1_3.1">libssh-config-0.10.6-slfo.1.1_3.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libssh4-0.10.6-slfo.1.1_3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:libssh4-0.10.6-slfo.1.1_3.1">libssh4-0.10.6-slfo.1.1_3.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libxml2-2-2.11.6-slfo.1.1_6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:libxml2-2-2.11.6-slfo.1.1_6.1">libxml2-2-2.11.6-slfo.1.1_6.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libxml2-tools-2.11.6-slfo.1.1_6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:libxml2-tools-2.11.6-slfo.1.1_6.1">libxml2-tools-2.11.6-slfo.1.1_6.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libxslt1-1.1.38-slfo.1.1_5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:libxslt1-1.1.38-slfo.1.1_5.1">libxslt1-1.1.38-slfo.1.1_5.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libzypp-17.37.18-slfo.1.1_1.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:libzypp-17.37.18-slfo.1.1_1.1">libzypp-17.37.18-slfo.1.1_1.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="mozilla-nspr-4.36-slfo.1.1_1.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:mozilla-nspr-4.36-slfo.1.1_1.1">mozilla-nspr-4.36-slfo.1.1_1.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="mozilla-nss-3.112.2-slfo.1.1_1.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:mozilla-nss-3.112.2-slfo.1.1_1.1">mozilla-nss-3.112.2-slfo.1.1_1.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="mozilla-nss-certs-3.112.2-slfo.1.1_1.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:mozilla-nss-certs-3.112.2-slfo.1.1_1.1">mozilla-nss-certs-3.112.2-slfo.1.1_1.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssl-3-3.1.4-slfo.1.1_7.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:openssl-3-3.1.4-slfo.1.1_7.1">openssl-3-3.1.4-slfo.1.1_7.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="pam-1.6.1-slfo.1.1_4.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:pam-1.6.1-slfo.1.1_4.1">pam-1.6.1-slfo.1.1_4.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="podman-5.4.2-slfo.1.1_2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:podman-5.4.2-slfo.1.1_2.1">podman-5.4.2-slfo.1.1_2.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="polkit-121-slfo.1.1_2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:polkit-121-slfo.1.1_2.1">polkit-121-slfo.1.1_2.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-audit-3.1.1-slfo.1.1_2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:python3-audit-3.1.1-slfo.1.1_2.1">python3-audit-3.1.1-slfo.1.1_2.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python311-3.11.13-slfo.1.1_2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:python311-3.11.13-slfo.1.1_2.1">python311-3.11.13-slfo.1.1_2.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python311-base-3.11.13-slfo.1.1_2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:python311-base-3.11.13-slfo.1.1_2.1">python311-base-3.11.13-slfo.1.1_2.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python311-libxml2-2.11.6-slfo.1.1_6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:python311-libxml2-2.11.6-slfo.1.1_6.1">python311-libxml2-2.11.6-slfo.1.1_6.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python311-urllib3-2.1.0-slfo.1.1_2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:python311-urllib3-2.1.0-slfo.1.1_2.1">python311-urllib3-2.1.0-slfo.1.1_2.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="regionServiceClientConfigGCE-5.0.0-slfo.1.1_1.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:regionServiceClientConfigGCE-5.0.0-slfo.1.1_1.1">regionServiceClientConfigGCE-5.0.0-slfo.1.1_1.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="runc-1.3.3-slfo.1.1_1.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:runc-1.3.3-slfo.1.1_1.1">runc-1.3.3-slfo.1.1_1.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="selinux-policy-20241031+git12.52417acff-slfo.1.1_1.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:selinux-policy-20241031+git12.52417acff-slfo.1.1_1.1">selinux-policy-20241031+git12.52417acff-slfo.1.1_1.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="selinux-policy-targeted-20241031+git12.52417acff-slfo.1.1_1.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:selinux-policy-targeted-20241031+git12.52417acff-slfo.1.1_1.1">selinux-policy-targeted-20241031+git12.52417acff-slfo.1.1_1.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="supportutils-plugin-suse-public-cloud-1.0.9-slfo.1.1_1.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:supportutils-plugin-suse-public-cloud-1.0.9-slfo.1.1_1.1">supportutils-plugin-suse-public-cloud-1.0.9-slfo.1.1_1.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="suse-build-key-12.0-slfo.1.1_4.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:suse-build-key-12.0-slfo.1.1_4.1">suse-build-key-12.0-slfo.1.1_4.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="system-group-audit-3.1.1-slfo.1.1_2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:system-group-audit-3.1.1-slfo.1.1_2.1">system-group-audit-3.1.1-slfo.1.1_2.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="update-alternatives-1.22.0-slfo.1.1_2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:update-alternatives-1.22.0-slfo.1.1_2.1">update-alternatives-1.22.0-slfo.1.1_2.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="vim-data-common-9.1.1629-slfo.1.1_1.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:vim-data-common-9.1.1629-slfo.1.1_1.1">vim-data-common-9.1.1629-slfo.1.1_1.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="vim-small-9.1.1629-slfo.1.1_1.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:vim-small-9.1.1629-slfo.1.1_1.1">vim-small-9.1.1629-slfo.1.1_1.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="zypper-1.14.94-slfo.1.1_1.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:zypper-1.14.94-slfo.1.1_1.1">zypper-1.14.94-slfo.1.1_1.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="zypper-needs-restarting-1.14.94-slfo.1.1_1.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-1-byos-v20251124-x86-64:zypper-needs-restarting-1.14.94-slfo.1.1_1.1">zypper-needs-restarting-1.14.94-slfo.1.1_1.1 as a component of Public Cloud Image google/sle-micro-6-1-byos-v20251124-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">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">Linux Kernel nftables Use-After-Free Local Privilege Escalation Vulnerability; `nft_chain_lookup_byid()` failed to check whether a chain was active and CAP_NET_ADMIN is in any user or network namespace</Note>
    </Notes>
    <CVE>CVE-2023-31248</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 the Linux kernel's IP framework for transforming packets (XFRM subsystem). This issue may allow a malicious user with CAP_NET_ADMIN privileges to directly dereference a NULL pointer in xfrm_update_ae_params(), leading to a possible kernel crash and denial of service.</Note>
    </Notes>
    <CVE>CVE-2023-3772</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix out of bounds read in smb2_sess_setup

ksmbd does not consider the case of that smb2 session setup is
in compound request. If this is the second payload of the compound,
OOB read issue occurs while processing the first payload in
the smb2_sess_setup().</Note>
    </Notes>
    <CVE>CVE-2023-3867</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 out-of-bounds read vulnerability was found in Netfilter Connection Tracking (conntrack) in the Linux kernel. This flaw allows a remote user to disclose sensitive information via the DCCP protocol.</Note>
    </Notes>
    <CVE>CVE-2023-39197</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix wrong next length validation of ea buffer in smb2_set_ea()

There are multiple smb2_ea_info buffers in FILE_FULL_EA_INFORMATION request
from client. ksmbd find next smb2_ea_info using -&gt;NextEntryOffset of
current smb2_ea_info. ksmbd need to validate buffer length Before
accessing the next ea. ksmbd should check buffer length using buf_len,
not next variable. next is the start offset of current ea that got from
previous ea.</Note>
    </Notes>
    <CVE>CVE-2023-4130</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 array indexing vulnerability was found in the netfilter subsystem of the Linux kernel. A missing macro could lead to a miscalculation of the `h-&gt;nets` array offset, providing attackers with the primitive to arbitrarily increment/decrement a memory buffer out-of-bound. This issue may allow a local user to crash the system or potentially escalate their privileges on the system.</Note>
    </Notes>
    <CVE>CVE-2023-42753</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:

ksmbd: validate command request size

In commit 2b9b8f3b68ed ("ksmbd: validate command payload size"), except
for SMB2_OPLOCK_BREAK_HE command, the request size of other commands
is not checked, it's not expected. Fix it by add check for request
size of other commands.</Note>
    </Notes>
    <CVE>CVE-2023-4515</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

igb: Fix igb_down hung on surprise removal

In a setup where a Thunderbolt hub connects to Ethernet and a display
through USB Type-C, users may experience a hung task timeout when they
remove the cable between the PC and the Thunderbolt hub.
This is because the igb_down function is called multiple times when
the Thunderbolt hub is unplugged. For example, the igb_io_error_detected
triggers the first call, and the igb_remove triggers the second call.
The second call to igb_down will block at napi_synchronize.
Here's the call trace:
    __schedule+0x3b0/0xddb
    ? __mod_timer+0x164/0x5d3
    schedule+0x44/0xa8
    schedule_timeout+0xb2/0x2a4
    ? run_local_timers+0x4e/0x4e
    msleep+0x31/0x38
    igb_down+0x12c/0x22a [igb 6615058754948bfde0bf01429257eb59f13030d4]
    __igb_close+0x6f/0x9c [igb 6615058754948bfde0bf01429257eb59f13030d4]
    igb_close+0x23/0x2b [igb 6615058754948bfde0bf01429257eb59f13030d4]
    __dev_close_many+0x95/0xec
    dev_close_many+0x6e/0x103
    unregister_netdevice_many+0x105/0x5b1
    unregister_netdevice_queue+0xc2/0x10d
    unregister_netdev+0x1c/0x23
    igb_remove+0xa7/0x11c [igb 6615058754948bfde0bf01429257eb59f13030d4]
    pci_device_remove+0x3f/0x9c
    device_release_driver_internal+0xfe/0x1b4
    pci_stop_bus_device+0x5b/0x7f
    pci_stop_bus_device+0x30/0x7f
    pci_stop_bus_device+0x30/0x7f
    pci_stop_and_remove_bus_device+0x12/0x19
    pciehp_unconfigure_device+0x76/0xe9
    pciehp_disable_slot+0x6e/0x131
    pciehp_handle_presence_or_link_change+0x7a/0x3f7
    pciehp_ist+0xbe/0x194
    irq_thread_fn+0x22/0x4d
    ? irq_thread+0x1fd/0x1fd
    irq_thread+0x17b/0x1fd
    ? irq_forced_thread_fn+0x5f/0x5f
    kthread+0x142/0x153
    ? __irq_get_irqchip_state+0x46/0x46
    ? kthread_associate_blkcg+0x71/0x71
    ret_from_fork+0x1f/0x30

In this case, igb_io_error_detected detaches the network interface
and requests a PCIE slot reset, however, the PCIE reset callback is
not being invoked and thus the Ethernet connection breaks down.
As the PCIE error in this case is a non-fatal one, requesting a
slot reset can be avoided.
This patch fixes the task hung issue and preserves Ethernet
connection by ignoring non-fatal PCIE errors.</Note>
    </Notes>
    <CVE>CVE-2023-53148</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: qla2xxx: Pointer may be dereferenced

Klocwork tool reported pointer 'rport' returned from call to function
fc_bsg_to_rport() may be NULL and will be dereferenced.

Add a fix to validate rport before dereferencing.</Note>
    </Notes>
    <CVE>CVE-2023-53150</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/raid10: prevent soft lockup while flush writes

Currently, there is no limit for raid1/raid10 plugged bio. While flushing
writes, raid1 has cond_resched() while raid10 doesn't, and too many
writes can cause soft lockup.

Follow up soft lockup can be triggered easily with writeback test for
raid10 with ramdisks:

watchdog: BUG: soft lockup - CPU#10 stuck for 27s! [md0_raid10:1293]
Call Trace:
 &lt;TASK&gt;
 call_rcu+0x16/0x20
 put_object+0x41/0x80
 __delete_object+0x50/0x90
 delete_object_full+0x2b/0x40
 kmemleak_free+0x46/0xa0
 slab_free_freelist_hook.constprop.0+0xed/0x1a0
 kmem_cache_free+0xfd/0x300
 mempool_free_slab+0x1f/0x30
 mempool_free+0x3a/0x100
 bio_free+0x59/0x80
 bio_put+0xcf/0x2c0
 free_r10bio+0xbf/0xf0
 raid_end_bio_io+0x78/0xb0
 one_write_done+0x8a/0xa0
 raid10_end_write_request+0x1b4/0x430
 bio_endio+0x175/0x320
 brd_submit_bio+0x3b9/0x9b7 [brd]
 __submit_bio+0x69/0xe0
 submit_bio_noacct_nocheck+0x1e6/0x5a0
 submit_bio_noacct+0x38c/0x7e0
 flush_pending_writes+0xf0/0x240
 raid10d+0xac/0x1ed0

Fix the problem by adding cond_resched() to raid10 like what raid1 did.

Note that unlimited plugged bio still need to be optimized, for example,
in the case of lots of dirty pages writeback, this will take lots of
memory and io will spend a long time in plug, hence io latency is bad.</Note>
    </Notes>
    <CVE>CVE-2023-53151</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix calltrace warning in amddrm_buddy_fini

The following call trace is observed when removing the amdgpu driver, which
is caused by that BOs allocated for psp are not freed until removing.

[61811.450562] RIP: 0010:amddrm_buddy_fini.cold+0x29/0x47 [amddrm_buddy]
[61811.450577] Call Trace:
[61811.450577]  &lt;TASK&gt;
[61811.450579]  amdgpu_vram_mgr_fini+0x135/0x1c0 [amdgpu]
[61811.450728]  amdgpu_ttm_fini+0x207/0x290 [amdgpu]
[61811.450870]  amdgpu_bo_fini+0x27/0xa0 [amdgpu]
[61811.451012]  gmc_v9_0_sw_fini+0x4a/0x60 [amdgpu]
[61811.451166]  amdgpu_device_fini_sw+0x117/0x520 [amdgpu]
[61811.451306]  amdgpu_driver_release_kms+0x16/0x30 [amdgpu]
[61811.451447]  devm_drm_dev_init_release+0x4d/0x80 [drm]
[61811.451466]  devm_action_release+0x15/0x20
[61811.451469]  release_nodes+0x40/0xb0
[61811.451471]  devres_release_all+0x9b/0xd0
[61811.451473]  __device_release_driver+0x1bb/0x2a0
[61811.451476]  driver_detach+0xf3/0x140
[61811.451479]  bus_remove_driver+0x6c/0xf0
[61811.451481]  driver_unregister+0x31/0x60
[61811.451483]  pci_unregister_driver+0x40/0x90
[61811.451486]  amdgpu_exit+0x15/0x447 [amdgpu]

For smu v13_0_2, if the GPU supports xgmi, refer to

commit f5c7e7797060 ("drm/amdgpu: Adjust removal control flow for smu v13_0_2"),

it will run gpu recover in AMDGPU_RESET_FOR_DEVICE_REMOVE mode when removing,
which makes all devices in hive list have hw reset but no resume except the
basic ip blocks, then other ip blocks will not call .hw_fini according to
ip_block.status.hw.

Since psp_free_shared_bufs just includes some software operations, so move
it to psp_sw_fini.</Note>
    </Notes>
    <CVE>CVE-2023-53152</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

udf: Fix uninitialized array access for some pathnames

For filenames that begin with . and are between 2 and 5 characters long,
UDF charset conversion code would read uninitialized memory in the
output buffer. The only practical impact is that the name may be prepended a
"unification hash" when it is not actually needed but still it is good
to fix this.</Note>
    </Notes>
    <CVE>CVE-2023-53165</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 null pointer dereference in tracing_err_log_open()

Fix an issue in function 'tracing_err_log_open'.
The function doesn't call 'seq_open' if the file is opened only with
write permissions, which results in 'file-&gt;private_data' being left as null.
If we then use 'lseek' on that opened file, 'seq_lseek' dereferences
'file-&gt;private_data' in 'mutex_lock(&amp;m-&gt;lock)', resulting in a kernel panic.
Writing to this node requires root privileges, therefore this bug
has very little security impact.

Tracefs node: /sys/kernel/tracing/error_log

Example Kernel panic:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038
Call trace:
 mutex_lock+0x30/0x110
 seq_lseek+0x34/0xb8
 __arm64_sys_lseek+0x6c/0xb8
 invoke_syscall+0x58/0x13c
 el0_svc_common+0xc4/0x10c
 do_el0_svc+0x24/0x98
 el0_svc+0x24/0x88
 el0t_64_sync_handler+0x84/0xe4
 el0t_64_sync+0x1b4/0x1b8
Code: d503201f aa0803e0 aa1f03e1 aa0103e9 (c8e97d02)
---[ end trace 561d1b49c12cf8a5 ]---
Kernel panic - not syncing: Oops: Fatal exception</Note>
    </Notes>
    <CVE>CVE-2023-53167</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Removed unneeded of_node_put in felix_parse_ports_node

Remove unnecessary of_node_put from the continue path to prevent
child node from being released twice, which could avoid resource
leak or other unexpected issues.</Note>
    </Notes>
    <CVE>CVE-2023-53170</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: core: Fix possible memory leak if device_add() fails

If device_add() returns error, the name allocated by dev_set_name() needs
be freed. As the comment of device_add() says, put_device() should be used
to decrease the reference count in the error path. So fix this by calling
put_device(), then the name can be freed in kobject_cleanp().</Note>
    </Notes>
    <CVE>CVE-2023-53174</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: hv: Fix a crash in hv_pci_restore_msi_msg() during hibernation

When a Linux VM with an assigned PCI device runs on Hyper-V, if the PCI
device driver is not loaded yet (i.e. MSI-X/MSI is not enabled on the
device yet), doing a VM hibernation triggers a panic in
hv_pci_restore_msi_msg() -&gt; msi_lock_descs(&amp;pdev-&gt;dev), because
pdev-&gt;dev.msi.data is still NULL.

Avoid the panic by checking if MSI-X/MSI is enabled.</Note>
    </Notes>
    <CVE>CVE-2023-53175</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: hi846: fix usage of pm_runtime_get_if_in_use()

pm_runtime_get_if_in_use() does not only return nonzero values when
the device is in use, it can return a negative errno too.

And especially during resuming from system suspend, when runtime pm
is not yet up again, -EAGAIN is being returned, so the subsequent
pm_runtime_put() call results in a refcount underflow.

Fix system-resume by handling -EAGAIN of pm_runtime_get_if_in_use().</Note>
    </Notes>
    <CVE>CVE-2023-53177</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 NULL pointer access during management transmit cleanup

Currently 'ar' reference is not added in skb_cb.
Though this is generally not used during transmit completion
callbacks, on interface removal the remaining idr cleanup callback
uses the ar pointer from skb_cb from management txmgmt_idr. Hence fill them
during transmit call for proper usage to avoid NULL pointer dereference.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1</Note>
    </Notes>
    <CVE>CVE-2023-53180</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/dma-resv: Stop leaking on krealloc() failure

Currently dma_resv_get_fences() will leak the previously
allocated array if the fence iteration got restarted and
the krealloc_array() fails.

Free the old array by hand, and make sure we still clear
the returned *fences so the caller won't end up accessing
freed memory. Some (but not all) of the callers of
dma_resv_get_fences() seem to still trawl through the
array even when dma_resv_get_fences() failed. And let's
zero out *num_fences as well for good measure.</Note>
    </Notes>
    <CVE>CVE-2023-53181</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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-2023-53183</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/sme: Set new vector length before reallocating

As part of fixing the allocation of the buffer for SVE state when changing
SME vector length we introduced an immediate reallocation of the SVE state,
this is also done when changing the SVE vector length for consistency.
Unfortunately this reallocation is done prior to writing the new vector
length to the task struct, meaning the allocation is done with the old
vector length and can lead to memory corruption due to an undersized buffer
being used.

Move the update of the vector length before the allocation to ensure that
the new vector length is taken into account.

For some reason this isn't triggering any problems when running tests on
the arm64 fixes branch (even after repeated tries) but is triggering
issues very often after merge into mainline.</Note>
    </Notes>
    <CVE>CVE-2023-53184</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: don't allow to overwrite ENDPOINT0 attributes

A bad USB device is able to construct a service connection response
message with target endpoint being ENDPOINT0 which is reserved for
HTC_CTRL_RSVD_SVC and should not be modified to be used for any other
services.

Reject such service connection responses.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.</Note>
    </Notes>
    <CVE>CVE-2023-53185</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 use-after-free of new block group that became unused

If a task creates a new block group and that block group becomes unused
before we finish its creation, at btrfs_create_pending_block_groups(),
then when btrfs_mark_bg_unused() is called against the block group, we
assume that the block group is currently in the list of block groups to
reclaim, and we move it out of the list of new block groups and into the
list of unused block groups. This has two consequences:

1) We move it out of the list of new block groups associated to the
   current transaction. So the block group creation is not finished and
   if we attempt to delete the bg because it's unused, we will not find
   the block group item in the extent tree (or the new block group tree),
   its device extent items in the device tree etc, resulting in the
   deletion to fail due to the missing items;

2) We don't increment the reference count on the block group when we
   move it to the list of unused block groups, because we assumed the
   block group was on the list of block groups to reclaim, and in that
   case it already has the correct reference count. However the block
   group was on the list of new block groups, in which case no extra
   reference was taken because it's local to the current task. This
   later results in doing an extra reference count decrement when
   removing the block group from the unused list, eventually leading the
   reference count to 0.

This second case was caught when running generic/297 from fstests, which
produced the following assertion failure and stack trace:

  [589.559] assertion failed: refcount_read(&amp;block_group-&gt;refs) == 1, in fs/btrfs/block-group.c:4299
  [589.559] ------------[ cut here ]------------
  [589.559] kernel BUG at fs/btrfs/block-group.c:4299!
  [589.560] invalid opcode: 0000 [#1] PREEMPT SMP PTI
  [589.560] CPU: 8 PID: 2819134 Comm: umount Tainted: G        W          6.4.0-rc6-btrfs-next-134+ #1
  [589.560] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014
  [589.560] RIP: 0010:btrfs_free_block_groups+0x449/0x4a0 [btrfs]
  [589.561] Code: 68 62 da c0 (...)
  [589.561] RSP: 0018:ffffa55a8c3b3d98 EFLAGS: 00010246
  [589.561] RAX: 0000000000000058 RBX: ffff8f030d7f2000 RCX: 0000000000000000
  [589.562] RDX: 0000000000000000 RSI: ffffffff953f0878 RDI: 00000000ffffffff
  [589.562] RBP: ffff8f030d7f2088 R08: 0000000000000000 R09: ffffa55a8c3b3c50
  [589.562] R10: 0000000000000001 R11: 0000000000000001 R12: ffff8f05850b4c00
  [589.562] R13: ffff8f030d7f2090 R14: ffff8f05850b4cd8 R15: dead000000000100
  [589.563] FS:  00007f497fd2e840(0000) GS:ffff8f09dfc00000(0000) knlGS:0000000000000000
  [589.563] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  [589.563] CR2: 00007f497ff8ec10 CR3: 0000000271472006 CR4: 0000000000370ee0
  [589.563] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  [589.564] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
  [589.564] Call Trace:
  [589.564]  &lt;TASK&gt;
  [589.565]  ? __die_body+0x1b/0x60
  [589.565]  ? die+0x39/0x60
  [589.565]  ? do_trap+0xeb/0x110
  [589.565]  ? btrfs_free_block_groups+0x449/0x4a0 [btrfs]
  [589.566]  ? do_error_trap+0x6a/0x90
  [589.566]  ? btrfs_free_block_groups+0x449/0x4a0 [btrfs]
  [589.566]  ? exc_invalid_op+0x4e/0x70
  [589.566]  ? btrfs_free_block_groups+0x449/0x4a0 [btrfs]
  [589.567]  ? asm_exc_invalid_op+0x16/0x20
  [589.567]  ? btrfs_free_block_groups+0x449/0x4a0 [btrfs]
  [589.567]  ? btrfs_free_block_groups+0x449/0x4a0 [btrfs]
  [589.567]  close_ctree+0x35d/0x560 [btrfs]
  [589.568]  ? fsnotify_sb_delete+0x13e/0x1d0
  [589.568]  ? dispose_list+0x3a/0x50
  [589.568]  ? evict_inodes+0x151/0x1a0
  [589.568]  generic_shutdown_super+0x73/0x1a0
  [589.569]  kill_anon_super+0x14/0x30
  [589.569]  btrfs_kill_super+0x12/0x20 [btrfs]
  [589.569]  deactivate_locked
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-53187</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/addrconf: fix a potential refcount underflow for idev

Now in addrconf_mod_rs_timer(), reference idev depends on whether
rs_timer is not pending. Then modify rs_timer timeout.

There is a time gap in [1], during which if the pending rs_timer
becomes not pending. It will miss to hold idev, but the rs_timer
is activated. Thus rs_timer callback function addrconf_rs_timer()
will be executed and put idev later without holding idev. A refcount
underflow issue for idev can be caused by this.

	if (!timer_pending(&amp;idev-&gt;rs_timer))
		in6_dev_hold(idev);
		  &lt;--------------[1]
	mod_timer(&amp;idev-&gt;rs_timer, jiffies + when);

To fix the issue, hold idev if mod_timer() return 0.</Note>
    </Notes>
    <CVE>CVE-2023-53189</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix nexthop hash size

The nexthop code expects a 31 bit hash, such as what is returned by
fib_multipath_hash() and rt6_multipath_hash(). Passing the 32 bit hash
returned by skb_get_hash() can lead to problems related to the fact that
'int hash' is a negative number when the MSB is set.

In the case of hash threshold nexthop groups, nexthop_select_path_hthr()
will disproportionately select the first nexthop group entry. In the case
of resilient nexthop groups, nexthop_select_path_res() may do an out of
bounds access in nh_buckets[], for example:
    hash = -912054133
    num_nh_buckets = 2
    bucket_index = 65535

which leads to the following panic:

BUG: unable to handle page fault for address: ffffc900025910c8
PGD 100000067 P4D 100000067 PUD 10026b067 PMD 0
Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI
CPU: 4 PID: 856 Comm: kworker/4:3 Not tainted 6.5.0-rc2+ #34
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Workqueue: ipv6_addrconf addrconf_dad_work
RIP: 0010:nexthop_select_path+0x197/0xbf0
Code: c1 e4 05 be 08 00 00 00 4c 8b 35 a4 14 7e 01 4e 8d 6c 25 00 4a 8d 7c 25 08 48 01 dd e8 c2 25 15 ff 49 8d 7d 08 e8 39 13 15 ff &lt;4d&gt; 89 75 08 48 89 ef e8 7d 12 15 ff 48 8b 5d 00 e8 14 55 2f 00 85
RSP: 0018:ffff88810c36f260 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 00000000002000c0 RCX: ffffffffaf02dd77
RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffffc900025910c8
RBP: ffffc900025910c0 R08: 0000000000000001 R09: fffff520004b2219
R10: ffffc900025910cf R11: 31392d2068736168 R12: 00000000002000c0
R13: ffffc900025910c0 R14: 00000000fffef608 R15: ffff88811840e900
FS:  0000000000000000(0000) GS:ffff8881f7000000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffc900025910c8 CR3: 0000000129d00000 CR4: 0000000000750ee0
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 ? __die+0x23/0x70
 ? page_fault_oops+0x1ee/0x5c0
 ? __pfx_is_prefetch.constprop.0+0x10/0x10
 ? __pfx_page_fault_oops+0x10/0x10
 ? search_bpf_extables+0xfe/0x1c0
 ? fixup_exception+0x3b/0x470
 ? exc_page_fault+0xf6/0x110
 ? asm_exc_page_fault+0x26/0x30
 ? nexthop_select_path+0x197/0xbf0
 ? nexthop_select_path+0x197/0xbf0
 ? lock_is_held_type+0xe7/0x140
 vxlan_xmit+0x5b2/0x2340
 ? __lock_acquire+0x92b/0x3370
 ? __pfx_vxlan_xmit+0x10/0x10
 ? __pfx___lock_acquire+0x10/0x10
 ? __pfx_register_lock_class+0x10/0x10
 ? skb_network_protocol+0xce/0x2d0
 ? dev_hard_start_xmit+0xca/0x350
 ? __pfx_vxlan_xmit+0x10/0x10
 dev_hard_start_xmit+0xca/0x350
 __dev_queue_xmit+0x513/0x1e20
 ? __pfx___dev_queue_xmit+0x10/0x10
 ? __pfx_lock_release+0x10/0x10
 ? mark_held_locks+0x44/0x90
 ? skb_push+0x4c/0x80
 ? eth_header+0x81/0xe0
 ? __pfx_eth_header+0x10/0x10
 ? neigh_resolve_output+0x215/0x310
 ? ip6_finish_output2+0x2ba/0xc90
 ip6_finish_output2+0x2ba/0xc90
 ? lock_release+0x236/0x3e0
 ? ip6_mtu+0xbb/0x240
 ? __pfx_ip6_finish_output2+0x10/0x10
 ? find_held_lock+0x83/0xa0
 ? lock_is_held_type+0xe7/0x140
 ip6_finish_output+0x1ee/0x780
 ip6_output+0x138/0x460
 ? __pfx_ip6_output+0x10/0x10
 ? __pfx___lock_acquire+0x10/0x10
 ? __pfx_ip6_finish_output+0x10/0x10
 NF_HOOK.constprop.0+0xc0/0x420
 ? __pfx_NF_HOOK.constprop.0+0x10/0x10
 ? ndisc_send_skb+0x2c0/0x960
 ? __pfx_lock_release+0x10/0x10
 ? __local_bh_enable_ip+0x93/0x110
 ? lock_is_held_type+0xe7/0x140
 ndisc_send_skb+0x4be/0x960
 ? __pfx_ndisc_send_skb+0x10/0x10
 ? mark_held_locks+0x65/0x90
 ? find_held_lock+0x83/0xa0
 ndisc_send_ns+0xb0/0x110
 ? __pfx_ndisc_send_ns+0x10/0x10
 addrconf_dad_work+0x631/0x8e0
 ? lock_acquire+0x180/0x3f0
 ? __pfx_addrconf_dad_work+0x10/0x10
 ? mark_held_locks+0x24/0x90
 process_one_work+0x582/0x9c0
 ? __pfx_process_one_work+0x10/0x10
 ? __pfx_do_raw_spin_lock+0x10/0x10
 ? mark_held_locks+0x24/0x90
 worker_thread+0x93/0x630
 ? __kthread_parkme+0xdc/0x100
 ? __pfx_worker_thread+0x10/0x10
 kthread+0x1a5/0x1e0
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x34/0x60
 
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-53192</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mlxsw: minimal: fix potential memory leak in mlxsw_m_linecards_init

The line cards array is not freed in the error path of
mlxsw_m_linecards_init(), which can lead to a memory leak. Fix by
freeing the array in the error path, thereby making the error path
identical to mlxsw_m_linecards_fini().</Note>
    </Notes>
    <CVE>CVE-2023-53195</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: qcom: Fix potential memory leak

Function dwc3_qcom_probe() allocates memory for resource structure
which is pointed by parent_res pointer. This memory is not
freed. This leads to memory leak. Use stack memory to prevent
memory leak.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2023-53196</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: wraparound mbox producer index

Driver is not handling the wraparound of the mbox producer index correctly.
Currently the wraparound happens once u32 max is reached.

Bit 31 of the producer index register is special and should be set
only once for the first command. Because the producer index overflow
setting bit31 after a long time, FW goes to initialization sequence
and this causes FW hang.

Fix is to wraparound the mbox producer index once it reaches u16 max.</Note>
    </Notes>
    <CVE>CVE-2023-53201</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix data-races around user-&gt;unix_inflight.

user-&gt;unix_inflight is changed under spin_lock(unix_gc_lock),
but too_many_unix_fds() reads it locklessly.

Let's annotate the write/read accesses to user-&gt;unix_inflight.

BUG: KCSAN: data-race in unix_attach_fds / unix_inflight

write to 0xffffffff8546f2d0 of 8 bytes by task 44798 on cpu 1:
 unix_inflight+0x157/0x180 net/unix/scm.c:66
 unix_attach_fds+0x147/0x1e0 net/unix/scm.c:123
 unix_scm_to_skb net/unix/af_unix.c:1827 [inline]
 unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1950
 unix_seqpacket_sendmsg net/unix/af_unix.c:2308 [inline]
 unix_seqpacket_sendmsg+0xba/0x130 net/unix/af_unix.c:2292
 sock_sendmsg_nosec net/socket.c:725 [inline]
 sock_sendmsg+0x148/0x160 net/socket.c:748
 ____sys_sendmsg+0x4e4/0x610 net/socket.c:2494
 ___sys_sendmsg+0xc6/0x140 net/socket.c:2548
 __sys_sendmsg+0x94/0x140 net/socket.c:2577
 __do_sys_sendmsg net/socket.c:2586 [inline]
 __se_sys_sendmsg net/socket.c:2584 [inline]
 __x64_sys_sendmsg+0x45/0x50 net/socket.c:2584
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x6e/0xd8

read to 0xffffffff8546f2d0 of 8 bytes by task 44814 on cpu 0:
 too_many_unix_fds net/unix/scm.c:101 [inline]
 unix_attach_fds+0x54/0x1e0 net/unix/scm.c:110
 unix_scm_to_skb net/unix/af_unix.c:1827 [inline]
 unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1950
 unix_seqpacket_sendmsg net/unix/af_unix.c:2308 [inline]
 unix_seqpacket_sendmsg+0xba/0x130 net/unix/af_unix.c:2292
 sock_sendmsg_nosec net/socket.c:725 [inline]
 sock_sendmsg+0x148/0x160 net/socket.c:748
 ____sys_sendmsg+0x4e4/0x610 net/socket.c:2494
 ___sys_sendmsg+0xc6/0x140 net/socket.c:2548
 __sys_sendmsg+0x94/0x140 net/socket.c:2577
 __do_sys_sendmsg net/socket.c:2586 [inline]
 __se_sys_sendmsg net/socket.c:2584 [inline]
 __x64_sys_sendmsg+0x45/0x50 net/socket.c:2584
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x6e/0xd8

value changed: 0x000000000000000c -&gt; 0x000000000000000d

Reported by Kernel Concurrency Sanitizer on:
CPU: 0 PID: 44814 Comm: systemd-coredum Not tainted 6.4.0-11989-g6843306689af #6
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014</Note>
    </Notes>
    <CVE>CVE-2023-53204</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: s390/diag: fix racy access of physical cpu number in diag 9c handler

We do check for target CPU == -1, but this might change at the time we
are going to use it. Hold the physical target CPU in a local variable to
avoid out-of-bound accesses to the cpu arrays.</Note>
    </Notes>
    <CVE>CVE-2023-53205</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: (pmbus_core) Fix NULL pointer dereference

Pass i2c_client to _pmbus_is_enabled to drop the assumption
that a regulator device is passed in.

This will fix the issue of a NULL pointer dereference when called from
_pmbus_get_flags.</Note>
    </Notes>
    <CVE>CVE-2023-53206</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fail to recover device if queue setup is interrupted

In ublk_ctrl_end_recovery(), if wait_for_completion_interruptible() is
interrupted by signal, queues aren't setup successfully yet, so we
have to fail UBLK_CMD_END_USER_RECOVERY, otherwise kernel oops can be
triggered.</Note>
    </Notes>
    <CVE>CVE-2023-53207</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: nSVM: Load L1's TSC multiplier based on L1 state, not L2 state

When emulating nested VM-Exit, load L1's TSC multiplier if L1's desired
ratio doesn't match the current ratio, not if the ratio L1 is using for
L2 diverges from the default.  Functionally, the end result is the same
as KVM will run L2 with L1's multiplier if L2's multiplier is the default,
i.e. checking that L1's multiplier is loaded is equivalent to checking if
L2 has a non-default multiplier.

However, the assertion that TSC scaling is exposed to L1 is flawed, as
userspace can trigger the WARN at will by writing the MSR and then
updating guest CPUID to hide the feature (modifying guest CPUID is
allowed anytime before KVM_RUN).  E.g. hacking KVM's state_test
selftest to do

                vcpu_set_msr(vcpu, MSR_AMD64_TSC_RATIO, 0);
                vcpu_clear_cpuid_feature(vcpu, X86_FEATURE_TSCRATEMSR);

after restoring state in a new VM+vCPU yields an endless supply of:

  ------------[ cut here ]------------
  WARNING: CPU: 10 PID: 206939 at arch/x86/kvm/svm/nested.c:1105
           nested_svm_vmexit+0x6af/0x720 [kvm_amd]
  Call Trace:
   nested_svm_exit_handled+0x102/0x1f0 [kvm_amd]
   svm_handle_exit+0xb9/0x180 [kvm_amd]
   kvm_arch_vcpu_ioctl_run+0x1eab/0x2570 [kvm]
   kvm_vcpu_ioctl+0x4c9/0x5b0 [kvm]
   ? trace_hardirqs_off+0x4d/0xa0
   __se_sys_ioctl+0x7a/0xc0
   __x64_sys_ioctl+0x21/0x30
   do_syscall_64+0x41/0x90
   entry_SYSCALL_64_after_hwframe+0x63/0xcd

Unlike the nested VMRUN path, hoisting the svm-&gt;tsc_scaling_enabled check
into the if-statement is wrong as KVM needs to ensure L1's multiplier is
loaded in the above scenario.   Alternatively, the WARN_ON() could simply
be deleted, but that would make KVM's behavior even more subtle, e.g. it's
not immediately obvious why it's safe to write MSR_AMD64_TSC_RATIO when
checking only tsc_ratio_msr.</Note>
    </Notes>
    <CVE>CVE-2023-53208</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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_hwsim: Fix possible NULL dereference

In a call to mac80211_hwsim_select_tx_link() the sta pointer might
be NULL, thus need to check that it is not NULL before accessing it.</Note>
    </Notes>
    <CVE>CVE-2023-53209</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:

md/raid5-cache: fix null-ptr-deref for r5l_flush_stripe_to_raid()

r5l_flush_stripe_to_raid() will check if the list 'flushing_ios' is
empty, and then submit 'flush_bio', however, r5l_log_flush_endio()
is clearing the list first and then clear the bio, which will cause
null-ptr-deref:

T1: submit flush io
raid5d
 handle_active_stripes
  r5l_flush_stripe_to_raid
   // list is empty
   // add 'io_end_ios' to the list
   bio_init
   submit_bio
   // io1

T2: io1 is done
r5l_log_flush_endio
 list_splice_tail_init
 // clear the list
			T3: submit new flush io
			...
			r5l_flush_stripe_to_raid
			 // list is empty
			 // add 'io_end_ios' to the list
			 bio_init
 bio_uninit
 // clear bio-&gt;bi_blkg
			 submit_bio
			 // null-ptr-deref

Fix this problem by clearing bio before clearing the list in
r5l_log_flush_endio().</Note>
    </Notes>
    <CVE>CVE-2023-53210</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/fair: Don't balance task to its current running CPU

We've run into the case that the balancer tries to balance a migration
disabled task and trigger the warning in set_task_cpu() like below:

 ------------[ cut here ]------------
 WARNING: CPU: 7 PID: 0 at kernel/sched/core.c:3115 set_task_cpu+0x188/0x240
 Modules linked in: hclgevf xt_CHECKSUM ipt_REJECT nf_reject_ipv4 &lt;...snip&gt;
 CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G           O       6.1.0-rc4+ #1
 Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V5.B221.01 12/09/2021
 pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 pc : set_task_cpu+0x188/0x240
 lr : load_balance+0x5d0/0xc60
 sp : ffff80000803bc70
 x29: ffff80000803bc70 x28: ffff004089e190e8 x27: ffff004089e19040
 x26: ffff007effcabc38 x25: 0000000000000000 x24: 0000000000000001
 x23: ffff80000803be84 x22: 000000000000000c x21: ffffb093e79e2a78
 x20: 000000000000000c x19: ffff004089e19040 x18: 0000000000000000
 x17: 0000000000001fad x16: 0000000000000030 x15: 0000000000000000
 x14: 0000000000000003 x13: 0000000000000000 x12: 0000000000000000
 x11: 0000000000000001 x10: 0000000000000400 x9 : ffffb093e4cee530
 x8 : 00000000fffffffe x7 : 0000000000ce168a x6 : 000000000000013e
 x5 : 00000000ffffffe1 x4 : 0000000000000001 x3 : 0000000000000b2a
 x2 : 0000000000000b2a x1 : ffffb093e6d6c510 x0 : 0000000000000001
 Call trace:
  set_task_cpu+0x188/0x240
  load_balance+0x5d0/0xc60
  rebalance_domains+0x26c/0x380
  _nohz_idle_balance.isra.0+0x1e0/0x370
  run_rebalance_domains+0x6c/0x80
  __do_softirq+0x128/0x3d8
  ____do_softirq+0x18/0x24
  call_on_irq_stack+0x2c/0x38
  do_softirq_own_stack+0x24/0x3c
  __irq_exit_rcu+0xcc/0xf4
  irq_exit_rcu+0x18/0x24
  el1_interrupt+0x4c/0xe4
  el1h_64_irq_handler+0x18/0x2c
  el1h_64_irq+0x74/0x78
  arch_cpu_idle+0x18/0x4c
  default_idle_call+0x58/0x194
  do_idle+0x244/0x2b0
  cpu_startup_entry+0x30/0x3c
  secondary_start_kernel+0x14c/0x190
  __secondary_switched+0xb0/0xb4
 ---[ end trace 0000000000000000 ]---

Further investigation shows that the warning is superfluous, the migration
disabled task is just going to be migrated to its current running CPU.
This is because that on load balance if the dst_cpu is not allowed by the
task, we'll re-select a new_dst_cpu as a candidate. If no task can be
balanced to dst_cpu we'll try to balance the task to the new_dst_cpu
instead. In this case when the migration disabled task is not on CPU it
only allows to run on its current CPU, load balance will select its
current CPU as new_dst_cpu and later triggers the warning above.

The new_dst_cpu is chosen from the env-&gt;dst_grpmask. Currently it
contains CPUs in sched_group_span() and if we have overlapped groups it's
possible to run into this case. This patch makes env-&gt;dst_grpmask of
group_balance_mask() which exclude any CPUs from the busiest group and
solve the issue. For balancing in a domain with no overlapped groups
the behaviour keeps same as before.</Note>
    </Notes>
    <CVE>CVE-2023-53215</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nubus: Partially revert proc_create_single_data() conversion

The conversion to proc_create_single_data() introduced a regression
whereby reading a file in /proc/bus/nubus results in a seg fault:

    # grep -r . /proc/bus/nubus/e/
    Data read fault at 0x00000020 in Super Data (pc=0x1074c2)
    BAD KERNEL BUSERR
    Oops: 00000000
    Modules linked in:
    PC: [&lt;001074c2&gt;] PDE_DATA+0xc/0x16
    SR: 2010  SP: 38284958  a2: 01152370
    d0: 00000001    d1: 01013000    d2: 01002790    d3: 00000000
    d4: 00000001    d5: 0008ce2e    a0: 00000000    a1: 00222a40
    Process grep (pid: 45, task=142f8727)
    Frame format=B ssw=074d isc=2008 isb=4e5e daddr=00000020 dobuf=01199e70
    baddr=001074c8 dibuf=ffffffff ver=f
    Stack from 01199e48:
	    01199e70 00222a58 01002790 00000000 011a3000 01199eb0 015000c0 00000000
	    00000000 01199ec0 01199ec0 000d551a 011a3000 00000001 00000000 00018000
	    d003f000 00000003 00000001 0002800d 01052840 01199fa8 c01f8000 00000000
	    00000029 0b532b80 00000000 00000000 00000029 0b532b80 01199ee4 00103640
	    011198c0 d003f000 00018000 01199fa8 00000000 011198c0 00000000 01199f4c
	    000b3344 011198c0 d003f000 00018000 01199fa8 00000000 00018000 011198c0
    Call Trace: [&lt;00222a58&gt;] nubus_proc_rsrc_show+0x18/0xa0
     [&lt;000d551a&gt;] seq_read+0xc4/0x510
     [&lt;00018000&gt;] fp_fcos+0x2/0x82
     [&lt;0002800d&gt;] __sys_setreuid+0x115/0x1c6
     [&lt;00103640&gt;] proc_reg_read+0x5c/0xb0
     [&lt;00018000&gt;] fp_fcos+0x2/0x82
     [&lt;000b3344&gt;] __vfs_read+0x2c/0x13c
     [&lt;00018000&gt;] fp_fcos+0x2/0x82
     [&lt;00018000&gt;] fp_fcos+0x2/0x82
     [&lt;000b8aa2&gt;] sys_statx+0x60/0x7e
     [&lt;000b34b6&gt;] vfs_read+0x62/0x12a
     [&lt;00018000&gt;] fp_fcos+0x2/0x82
     [&lt;00018000&gt;] fp_fcos+0x2/0x82
     [&lt;000b39c2&gt;] ksys_read+0x48/0xbe
     [&lt;00018000&gt;] fp_fcos+0x2/0x82
     [&lt;000b3a4e&gt;] sys_read+0x16/0x1a
     [&lt;00018000&gt;] fp_fcos+0x2/0x82
     [&lt;00002b84&gt;] syscall+0x8/0xc
     [&lt;00018000&gt;] fp_fcos+0x2/0x82
     [&lt;0000c016&gt;] not_ext+0xa/0x18
    Code: 4e5e 4e75 4e56 0000 206e 0008 2068 ffe8 &lt;2068&gt; 0020 2008 4e5e 4e75 4e56 0000 2f0b 206e 0008 2068 0004 2668 0020 206b ffe8
    Disabling lock debugging due to kernel taint

    Segmentation fault

The proc_create_single_data() conversion does not work because
single_open(file, nubus_proc_rsrc_show, PDE_DATA(inode)) is not
equivalent to the original code.</Note>
    </Notes>
    <CVE>CVE-2023-53217</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: az6007: Fix null-ptr-deref in az6007_i2c_xfer()

In az6007_i2c_xfer, 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 az6007_i2c_xfer. 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 0ed554fd769a
("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")</Note>
    </Notes>
    <CVE>CVE-2023-53220</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 memleak due to fentry attach failure

If it fails to attach fentry, the allocated bpf trampoline image will be
left in the system. That can be verified by checking /proc/kallsyms.

This meamleak can be verified by a simple bpf program as follows:

  SEC("fentry/trap_init")
  int fentry_run()
  {
      return 0;
  }

It will fail to attach trap_init because this function is freed after
kernel init, and then we can find the trampoline image is left in the
system by checking /proc/kallsyms.

  $ tail /proc/kallsyms
  ffffffffc0613000 t bpf_trampoline_6442453466_1  [bpf]
  ffffffffc06c3000 t bpf_trampoline_6442453466_1  [bpf]

  $ bpftool btf dump file /sys/kernel/btf/vmlinux | grep "FUNC 'trap_init'"
  [2522] FUNC 'trap_init' type_id=119 linkage=static

  $ echo $((6442453466 &amp; 0x7fffffff))
  2522

Note that there are two left bpf trampoline images, that is because the
libbpf will fallback to raw tracepoint if -EINVAL is returned.</Note>
    </Notes>
    <CVE>CVE-2023-53221</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: jfs_dmap: Validate db_l2nbperpage while mounting

In jfs_dmap.c at line 381, BLKTODMAP is used to get a logical block
number inside dbFree(). db_l2nbperpage, which is the log2 number of
blocks per page, is passed as an argument to BLKTODMAP which uses it
for shifting.

Syzbot reported a shift out-of-bounds crash because db_l2nbperpage is
too big. This happens because the large value is set without any
validation in dbMount() at line 181.

Thus, make sure that db_l2nbperpage is correct while mounting.

Max number of blocks per page = Page size / Min block size
=&gt; log2(Max num_block per page) = log2(Page size / Min block size)
				= log2(Page size) - log2(Min block size)

=&gt; Max db_l2nbperpage = L2PSIZE - L2MINBLOCKSIZE</Note>
    </Notes>
    <CVE>CVE-2023-53222</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: mwifiex: Fix OOB and integer underflow when rx packets

Make sure mwifiex_process_mgmt_packet,
mwifiex_process_sta_rx_packet and mwifiex_process_uap_rx_packet,
mwifiex_uap_queue_bridged_pkt and mwifiex_process_rx_packet
not out-of-bounds access the skb-&gt;data buffer.</Note>
    </Notes>
    <CVE>CVE-2023-53226</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 warning in cifs_smb3_do_mount()

This fixes the following warning reported by kernel test robot

  fs/smb/client/cifsfs.c:982 cifs_smb3_do_mount() warn: possible
  memory leak of 'cifs_sb'</Note>
    </Notes>
    <CVE>CVE-2023-53230</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

erofs: Fix detection of atomic context

Current check for atomic context is not sufficient as
z_erofs_decompressqueue_endio can be called under rcu lock
from blk_mq_flush_plug_list(). See the stacktrace [1]

In such case we should hand off the decompression work for async
processing rather than trying to do sync decompression in current
context. Patch fixes the detection by checking for
rcu_read_lock_any_held() and while at it use more appropriate
!in_task() check than in_atomic().

Background: Historically erofs would always schedule a kworker for
decompression which would incur the scheduling cost regardless of
the context. But z_erofs_decompressqueue_endio() may not always
be in atomic context and we could actually benefit from doing the
decompression in z_erofs_decompressqueue_endio() if we are in
thread context, for example when running with dm-verity.
This optimization was later added in patch [2] which has shown
improvement in performance benchmarks.

==============================================
[1] Problem stacktrace
[name:core&amp;]BUG: sleeping function called from invalid context at kernel/locking/mutex.c:291
[name:core&amp;]in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 1615, name: CpuMonitorServi
[name:core&amp;]preempt_count: 0, expected: 0
[name:core&amp;]RCU nest depth: 1, expected: 0
CPU: 7 PID: 1615 Comm: CpuMonitorServi Tainted: G S      W  OE      6.1.25-android14-5-maybe-dirty-mainline #1
Hardware name: MT6897 (DT)
Call trace:
 dump_backtrace+0x108/0x15c
 show_stack+0x20/0x30
 dump_stack_lvl+0x6c/0x8c
 dump_stack+0x20/0x48
 __might_resched+0x1fc/0x308
 __might_sleep+0x50/0x88
 mutex_lock+0x2c/0x110
 z_erofs_decompress_queue+0x11c/0xc10
 z_erofs_decompress_kickoff+0x110/0x1a4
 z_erofs_decompressqueue_endio+0x154/0x180
 bio_endio+0x1b0/0x1d8
 __dm_io_complete+0x22c/0x280
 clone_endio+0xe4/0x280
 bio_endio+0x1b0/0x1d8
 blk_update_request+0x138/0x3a4
 blk_mq_plug_issue_direct+0xd4/0x19c
 blk_mq_flush_plug_list+0x2b0/0x354
 __blk_flush_plug+0x110/0x160
 blk_finish_plug+0x30/0x4c
 read_pages+0x2fc/0x370
 page_cache_ra_unbounded+0xa4/0x23c
 page_cache_ra_order+0x290/0x320
 do_sync_mmap_readahead+0x108/0x2c0
 filemap_fault+0x19c/0x52c
 __do_fault+0xc4/0x114
 handle_mm_fault+0x5b4/0x1168
 do_page_fault+0x338/0x4b4
 do_translation_fault+0x40/0x60
 do_mem_abort+0x60/0xc8
 el0_da+0x4c/0xe0
 el0t_64_sync_handler+0xd4/0xfc
 el0t_64_sync+0x1a0/0x1a4

[2] Link: https://lore.kernel.org/all/20210317035448.13921-1-huangjianan@oppo.com/</Note>
    </Notes>
    <CVE>CVE-2023-53231</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/tests: helpers: Avoid a driver uaf

when using __drm_kunit_helper_alloc_drm_device() the driver may be
dereferenced by device-managed resources up until the device is
freed, which is typically later than the kunit-managed resource code
frees it. Fix this by simply make the driver device-managed as well.

In short, the sequence leading to the UAF is as follows:

INIT:
Code allocates a struct device as a kunit-managed resource.
Code allocates a drm driver as a kunit-managed resource.
Code allocates a drm device as a device-managed resource.

EXIT:
Kunit resource cleanup frees the drm driver
Kunit resource cleanup puts the struct device, which starts a
      device-managed resource cleanup
device-managed cleanup calls drm_dev_put()
drm_dev_put() dereferences the (now freed) drm driver -&gt; Boom.

Related KASAN message:
[55272.551542] ==================================================================
[55272.551551] BUG: KASAN: slab-use-after-free in drm_dev_put.part.0+0xd4/0xe0 [drm]
[55272.551603] Read of size 8 at addr ffff888127502828 by task kunit_try_catch/10353

[55272.551612] CPU: 4 PID: 10353 Comm: kunit_try_catch Tainted: G     U           N 6.5.0-rc7+ #155
[55272.551620] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS 0403 01/26/2021
[55272.551626] Call Trace:
[55272.551629]  &lt;TASK&gt;
[55272.551633]  dump_stack_lvl+0x57/0x90
[55272.551639]  print_report+0xcf/0x630
[55272.551645]  ? _raw_spin_lock_irqsave+0x5f/0x70
[55272.551652]  ? drm_dev_put.part.0+0xd4/0xe0 [drm]
[55272.551694]  kasan_report+0xd7/0x110
[55272.551699]  ? drm_dev_put.part.0+0xd4/0xe0 [drm]
[55272.551742]  drm_dev_put.part.0+0xd4/0xe0 [drm]
[55272.551783]  devres_release_all+0x15d/0x1f0
[55272.551790]  ? __pfx_devres_release_all+0x10/0x10
[55272.551797]  device_unbind_cleanup+0x16/0x1a0
[55272.551802]  device_release_driver_internal+0x3e5/0x540
[55272.551808]  ? kobject_put+0x5d/0x4b0
[55272.551814]  bus_remove_device+0x1f1/0x3f0
[55272.551819]  device_del+0x342/0x910
[55272.551826]  ? __pfx_device_del+0x10/0x10
[55272.551830]  ? lock_release+0x339/0x5e0
[55272.551836]  ? kunit_remove_resource+0x128/0x290 [kunit]
[55272.551845]  ? __pfx_lock_release+0x10/0x10
[55272.551851]  platform_device_del.part.0+0x1f/0x1e0
[55272.551856]  ? _raw_spin_unlock_irqrestore+0x30/0x60
[55272.551863]  kunit_remove_resource+0x195/0x290 [kunit]
[55272.551871]  ? _raw_spin_unlock_irqrestore+0x30/0x60
[55272.551877]  kunit_cleanup+0x78/0x120 [kunit]
[55272.551885]  ? __kthread_parkme+0xc1/0x1f0
[55272.551891]  ? __pfx_kunit_try_run_case_cleanup+0x10/0x10 [kunit]
[55272.551900]  ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10 [kunit]
[55272.551909]  kunit_generic_run_threadfn_adapter+0x4a/0x90 [kunit]
[55272.551919]  kthread+0x2e7/0x3c0
[55272.551924]  ? __pfx_kthread+0x10/0x10
[55272.551929]  ret_from_fork+0x2d/0x70
[55272.551935]  ? __pfx_kthread+0x10/0x10
[55272.551940]  ret_from_fork_asm+0x1b/0x30
[55272.551948]  &lt;/TASK&gt;

[55272.551953] Allocated by task 10351:
[55272.551956]  kasan_save_stack+0x1c/0x40
[55272.551962]  kasan_set_track+0x21/0x30
[55272.551966]  __kasan_kmalloc+0x8b/0x90
[55272.551970]  __kmalloc+0x5e/0x160
[55272.551976]  kunit_kmalloc_array+0x1c/0x50 [kunit]
[55272.551984]  drm_exec_test_init+0xfa/0x2c0 [drm_exec_test]
[55272.551991]  kunit_try_run_case+0xdd/0x250 [kunit]
[55272.551999]  kunit_generic_run_threadfn_adapter+0x4a/0x90 [kunit]
[55272.552008]  kthread+0x2e7/0x3c0
[55272.552012]  ret_from_fork+0x2d/0x70
[55272.552017]  ret_from_fork_asm+0x1b/0x30

[55272.552024] Freed by task 10353:
[55272.552027]  kasan_save_stack+0x1c/0x40
[55272.552032]  kasan_set_track+0x21/0x30
[55272.552036]  kasan_save_free_info+0x27/0x40
[55272.552041]  __kasan_slab_free+0x106/0x180
[55272.552046]  slab_free_freelist_hook+0xb3/0x160
[55272.552051]  __kmem_cache_free+0xb2/0x290
[55272.552056]  kunit_remove_resource+0x195/0x290 [kunit]
[55272.552064]  kunit_cleanup+0x7
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-53235</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: hisilicon: Fix an out of bounds check in hisi_inno_phy_probe()

The size of array 'priv-&gt;ports[]' is INNO_PHY_PORT_NUM.

In the for loop, 'i' is used as the index for array 'priv-&gt;ports[]'
with a check (i &gt; INNO_PHY_PORT_NUM) which indicates that
INNO_PHY_PORT_NUM is allowed value for 'i' in the same loop.

This &gt; comparison needs to be changed to &gt;=, otherwise it potentially leads
to an out of bounds write on the next iteration through the loop</Note>
    </Notes>
    <CVE>CVE-2023-53238</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: add handling for RAID1C23/DUP to btrfs_reduce_alloc_profile

Callers of `btrfs_reduce_alloc_profile` expect it to return exactly
one allocation profile flag, and failing to do so may ultimately
result in a WARN_ON and remount-ro when allocating new blocks, like
the below transaction abort on 6.1.

`btrfs_reduce_alloc_profile` has two ways of determining the profile,
first it checks if a conversion balance is currently running and
uses the profile we're converting to. If no balance is currently
running, it returns the max-redundancy profile which at least one
block in the selected block group has.

This works by simply checking each known allocation profile bit in
redundancy order. However, `btrfs_reduce_alloc_profile` has not been
updated as new flags have been added - first with the `DUP` profile
and later with the RAID1C34 profiles.

Because of the way it checks, if we have blocks with different
profiles and at least one is known, that profile will be selected.
However, if none are known we may return a flag set with multiple
allocation profiles set.

This is currently only possible when a balance from one of the three
unhandled profiles to another of the unhandled profiles is canceled
after allocating at least one block using the new profile.

In that case, a transaction abort like the below will occur and the
filesystem will need to be mounted with -o skip_balance to get it
mounted rw again (but the balance cannot be resumed without a
similar abort).

  [770.648] ------------[ cut here ]------------
  [770.648] BTRFS: Transaction aborted (error -22)
  [770.648] WARNING: CPU: 43 PID: 1159593 at fs/btrfs/extent-tree.c:4122 find_free_extent+0x1d94/0x1e00 [btrfs]
  [770.648] CPU: 43 PID: 1159593 Comm: btrfs Tainted: G        W 6.1.0-0.deb11.7-powerpc64le #1  Debian 6.1.20-2~bpo11+1a~test
  [770.648] Hardware name: T2P9D01 REV 1.00 POWER9 0x4e1202 opal:skiboot-bc106a0 PowerNV
  [770.648] NIP:  c00800000f6784fc LR: c00800000f6784f8 CTR: c000000000d746c0
  [770.648] REGS: c000200089afe9a0 TRAP: 0700   Tainted: G        W (6.1.0-0.deb11.7-powerpc64le Debian 6.1.20-2~bpo11+1a~test)
  [770.648] MSR:  9000000002029033 &lt;SF,HV,VEC,EE,ME,IR,DR,RI,LE&gt;  CR: 28848282  XER: 20040000
  [770.648] CFAR: c000000000135110 IRQMASK: 0
	    GPR00: c00800000f6784f8 c000200089afec40 c00800000f7ea800 0000000000000026
	    GPR04: 00000001004820c2 c000200089afea00 c000200089afe9f8 0000000000000027
	    GPR08: c000200ffbfe7f98 c000000002127f90 ffffffffffffffd8 0000000026d6a6e8
	    GPR12: 0000000028848282 c000200fff7f3800 5deadbeef0000122 c00000002269d000
	    GPR16: c0002008c7797c40 c000200089afef17 0000000000000000 0000000000000000
	    GPR20: 0000000000000000 0000000000000001 c000200008bc5a98 0000000000000001
	    GPR24: 0000000000000000 c0000003c73088d0 c000200089afef17 c000000016d3a800
	    GPR28: c0000003c7308800 c00000002269d000 ffffffffffffffea 0000000000000001
  [770.648] NIP [c00800000f6784fc] find_free_extent+0x1d94/0x1e00 [btrfs]
  [770.648] LR [c00800000f6784f8] find_free_extent+0x1d90/0x1e00 [btrfs]
  [770.648] Call Trace:
  [770.648] [c000200089afec40] [c00800000f6784f8] find_free_extent+0x1d90/0x1e00 [btrfs] (unreliable)
  [770.648] [c000200089afed30] [c00800000f681398] btrfs_reserve_extent+0x1a0/0x2f0 [btrfs]
  [770.648] [c000200089afeea0] [c00800000f681bf0] btrfs_alloc_tree_block+0x108/0x670 [btrfs]
  [770.648] [c000200089afeff0] [c00800000f66bd68] __btrfs_cow_block+0x170/0x850 [btrfs]
  [770.648] [c000200089aff100] [c00800000f66c58c] btrfs_cow_block+0x144/0x288 [btrfs]
  [770.648] [c000200089aff1b0] [c00800000f67113c] btrfs_search_slot+0x6b4/0xcb0 [btrfs]
  [770.648] [c000200089aff2a0] [c00800000f679f60] lookup_inline_extent_backref+0x128/0x7c0 [btrfs]
  [770.648] [c000200089aff3b0] [c00800000f67b338] lookup_extent_backref+0x70/0x190 [btrfs]
  [770.648] [c000200089aff470] [c00800000f67b54c] __btrfs_free_extent+0xf4/0x1490 [btrfs]
  [770.648] [
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-53243</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: storvsc: Fix handling of virtual Fibre Channel timeouts

Hyper-V provides the ability to connect Fibre Channel LUNs to the host
system and present them in a guest VM as a SCSI device. I/O to the vFC
device is handled by the storvsc driver. The storvsc driver includes a
partial integration with the FC transport implemented in the generic
portion of the Linux SCSI subsystem so that FC attributes can be displayed
in /sys.  However, the partial integration means that some aspects of vFC
don't work properly. Unfortunately, a full and correct integration isn't
practical because of limitations in what Hyper-V provides to the guest.

In particular, in the context of Hyper-V storvsc, the FC transport timeout
function fc_eh_timed_out() causes a kernel panic because it can't find the
rport and dereferences a NULL pointer. The original patch that added the
call from storvsc_eh_timed_out() to fc_eh_timed_out() is faulty in this
regard.

In many cases a timeout is due to a transient condition, so the situation
can be improved by just continuing to wait like with other I/O requests
issued by storvsc, and avoiding the guaranteed panic. For a permanent
failure, continuing to wait may result in a hung thread instead of a panic,
which again may be better.

So fix the panic by removing the storvsc call to fc_eh_timed_out().  This
allows storvsc to keep waiting for a response.  The change has been tested
by users who experienced a panic in fc_eh_timed_out() due to transient
timeouts, and it solves their problem.

In the future we may want to deprecate the vFC functionality in storvsc
since it can't be fully fixed. But it has current users for whom it is
working well enough, so it should probably stay for a while longer.</Note>
    </Notes>
    <CVE>CVE-2023-53245</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: set_page_extent_mapped after read_folio in btrfs_cont_expand

While trying to get the subpage blocksize tests running, I hit the
following panic on generic/476

  assertion failed: PagePrivate(page) &amp;&amp; page-&gt;private, in fs/btrfs/subpage.c:229
  kernel BUG at fs/btrfs/subpage.c:229!
  Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
  CPU: 1 PID: 1453 Comm: fsstress Not tainted 6.4.0-rc7+ #12
  Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20230301gitf80f052277c8-26.fc38 03/01/2023
  pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
  pc : btrfs_subpage_assert+0xbc/0xf0
  lr : btrfs_subpage_assert+0xbc/0xf0
  Call trace:
   btrfs_subpage_assert+0xbc/0xf0
   btrfs_subpage_clear_checked+0x38/0xc0
   btrfs_page_clear_checked+0x48/0x98
   btrfs_truncate_block+0x5d0/0x6a8
   btrfs_cont_expand+0x5c/0x528
   btrfs_write_check.isra.0+0xf8/0x150
   btrfs_buffered_write+0xb4/0x760
   btrfs_do_write_iter+0x2f8/0x4b0
   btrfs_file_write_iter+0x1c/0x30
   do_iter_readv_writev+0xc8/0x158
   do_iter_write+0x9c/0x210
   vfs_iter_write+0x24/0x40
   iter_file_splice_write+0x224/0x390
   direct_splice_actor+0x38/0x68
   splice_direct_to_actor+0x12c/0x260
   do_splice_direct+0x90/0xe8
   generic_copy_file_range+0x50/0x90
   vfs_copy_file_range+0x29c/0x470
   __arm64_sys_copy_file_range+0xcc/0x498
   invoke_syscall.constprop.0+0x80/0xd8
   do_el0_svc+0x6c/0x168
   el0_svc+0x50/0x1b0
   el0t_64_sync_handler+0x114/0x120
   el0t_64_sync+0x194/0x198

This happens because during btrfs_cont_expand we'll get a page, set it
as mapped, and if it's not Uptodate we'll read it.  However between the
read and re-locking the page we could have called release_folio() on the
page, but left the page in the file mapping.  release_folio() can clear
the page private, and thus further down we blow up when we go to modify
the subpage bits.

Fix this by putting the set_page_extent_mapped() after the read.  This
is safe because read_folio() will call set_page_extent_mapped() before
it does the read, and then if we clear page private but leave it on the
mapping we're completely safe re-setting set_page_extent_mapped().  With
this patch I can now run generic/476 without panicing.</Note>
    </Notes>
    <CVE>CVE-2023-53247</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: install stub fence into potential unused fence pointers

When using cpu to update page tables, vm update fences are unused.
Install stub fence into these fence pointers instead of NULL
to avoid NULL dereference when calling dma_fence_wait() on them.</Note>
    </Notes>
    <CVE>CVE-2023-53248</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

clk: imx: clk-imx8mn: fix memory leak in imx8mn_clocks_probe

Use devm_of_iomap() instead of of_iomap() to automatically handle
the unused ioremap region.

If any error occurs, regions allocated by kzalloc() will leak,
but using devm_kzalloc() instead will automatically free the memory
using devm_kfree().</Note>
    </Notes>
    <CVE>CVE-2023-53249</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: iwlwifi: pcie: fix NULL pointer dereference in iwl_pcie_irq_rx_msix_handler()

rxq can be NULL only when trans_pcie-&gt;rxq is NULL and entry-&gt;entry
is zero. For the case when entry-&gt;entry is not equal to 0, rxq
won't be NULL even if trans_pcie-&gt;rxq is NULL. Modify checker to
check for trans_pcie-&gt;rxq.</Note>
    </Notes>
    <CVE>CVE-2023-53251</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: use RCU for hci_conn_params and iterate safely in hci_sync

hci_update_accept_list_sync iterates over hdev-&gt;pend_le_conns and
hdev-&gt;pend_le_reports, and waits for controller events in the loop body,
without holding hdev lock.

Meanwhile, these lists and the items may be modified e.g. by
le_scan_cleanup. This can invalidate the list cursor or any other item
in the list, resulting to invalid behavior (eg use-after-free).

Use RCU for the hci_conn_params action lists. Since the loop bodies in
hci_sync block and we cannot use RCU or hdev-&gt;lock for the whole loop,
copy list items first and then iterate on the copy. Only the flags field
is written from elsewhere, so READ_ONCE/WRITE_ONCE should guarantee we
read valid values.

Free params everywhere with hci_conn_params_free so the cleanup is
guaranteed to be done properly.

This fixes the following, which can be triggered e.g. by BlueZ new
mgmt-tester case "Add + Remove Device Nowait - Success", or by changing
hci_le_set_cig_params to always return false, and running iso-tester:

==================================================================
BUG: KASAN: slab-use-after-free in hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2536 net/bluetooth/hci_sync.c:2723 net/bluetooth/hci_sync.c:2841)
Read of size 8 at addr ffff888001265018 by task kworker/u3:0/32

Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014
Workqueue: hci0 hci_cmd_sync_work
Call Trace:
&lt;TASK&gt;
dump_stack_lvl (./arch/x86/include/asm/irqflags.h:134 lib/dump_stack.c:107)
print_report (mm/kasan/report.c:320 mm/kasan/report.c:430)
? __virt_addr_valid (./include/linux/mmzone.h:1915 ./include/linux/mmzone.h:2011 arch/x86/mm/physaddr.c:65)
? hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2536 net/bluetooth/hci_sync.c:2723 net/bluetooth/hci_sync.c:2841)
kasan_report (mm/kasan/report.c:538)
? hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2536 net/bluetooth/hci_sync.c:2723 net/bluetooth/hci_sync.c:2841)
hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2536 net/bluetooth/hci_sync.c:2723 net/bluetooth/hci_sync.c:2841)
? __pfx_hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2780)
? mutex_lock (kernel/locking/mutex.c:282)
? __pfx_mutex_lock (kernel/locking/mutex.c:282)
? __pfx_mutex_unlock (kernel/locking/mutex.c:538)
? __pfx_update_passive_scan_sync (net/bluetooth/hci_sync.c:2861)
hci_cmd_sync_work (net/bluetooth/hci_sync.c:306)
process_one_work (./arch/x86/include/asm/preempt.h:27 kernel/workqueue.c:2399)
worker_thread (./include/linux/list.h:292 kernel/workqueue.c:2538)
? __pfx_worker_thread (kernel/workqueue.c:2480)
kthread (kernel/kthread.c:376)
? __pfx_kthread (kernel/kthread.c:331)
ret_from_fork (arch/x86/entry/entry_64.S:314)
&lt;/TASK&gt;

Allocated by task 31:
kasan_save_stack (mm/kasan/common.c:46)
kasan_set_track (mm/kasan/common.c:52)
__kasan_kmalloc (mm/kasan/common.c:374 mm/kasan/common.c:383)
hci_conn_params_add (./include/linux/slab.h:580 ./include/linux/slab.h:720 net/bluetooth/hci_core.c:2277)
hci_connect_le_scan (net/bluetooth/hci_conn.c:1419 net/bluetooth/hci_conn.c:1589)
hci_connect_cis (net/bluetooth/hci_conn.c:2266)
iso_connect_cis (net/bluetooth/iso.c:390)
iso_sock_connect (net/bluetooth/iso.c:899)
__sys_connect (net/socket.c:2003 net/socket.c:2020)
__x64_sys_connect (net/socket.c:2027)
do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)

Freed by task 15:
kasan_save_stack (mm/kasan/common.c:46)
kasan_set_track (mm/kasan/common.c:52)
kasan_save_free_info (mm/kasan/generic.c:523)
__kasan_slab_free (mm/kasan/common.c:238 mm/kasan/common.c:200 mm/kasan/common.c:244)
__kmem_cache_free (mm/slub.c:1807 mm/slub.c:3787 mm/slub.c:3800)
hci_conn_params_del (net/bluetooth/hci_core.c:2323)
le_scan_cleanup (net/bluetooth/hci_conn.c:202)
process_one_work (./arch/x86/include/asm/preempt.
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-53252</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:

firmware: stratix10-svc: Fix a potential resource leak in svc_create_memory_pool()

svc_create_memory_pool() is only called from stratix10_svc_drv_probe().
Most of resources in the probe are managed, but not this memremap() call.

There is also no memunmap() call in the file.

So switch to devm_memremap() to avoid a resource leak.</Note>
    </Notes>
    <CVE>CVE-2023-53255</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: mac80211: check S1G action frame size

Before checking the action code, check that it even
exists in the frame.</Note>
    </Notes>
    <CVE>CVE-2023-53257</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: Fix possible underflow for displays with large vblank

[Why]
Underflow observed when using a display with a large vblank region
and low refresh rate

[How]
Simplify calculation of vblank_nom

Increase value for VBlankNomDefaultUS to 800us</Note>
    </Notes>
    <CVE>CVE-2023-53258</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ovl: fix null pointer dereference in ovl_permission()

Following process:
          P1                     P2
 path_lookupat
  link_path_walk
   inode_permission
    ovl_permission
      ovl_i_path_real(inode, &amp;realpath)
        path-&gt;dentry = ovl_i_dentry_upper(inode)
                          drop_cache
			   __dentry_kill(ovl_dentry)
		            iput(ovl_inode)
		             ovl_destroy_inode(ovl_inode)
		              dput(oi-&gt;__upperdentry)
		               dentry_kill(upperdentry)
		                dentry_unlink_inode
				 upperdentry-&gt;d_inode = NULL
      realinode = d_inode(realpath.dentry) // return NULL
      inode_permission(realinode)
       inode-&gt;i_sb  // NULL pointer dereference
, will trigger an null pointer dereference at realinode:
  [  335.664979] BUG: kernel NULL pointer dereference,
                 address: 0000000000000002
  [  335.668032] CPU: 0 PID: 2592 Comm: ls Not tainted 6.3.0
  [  335.669956] RIP: 0010:inode_permission+0x33/0x2c0
  [  335.678939] Call Trace:
  [  335.679165]  &lt;TASK&gt;
  [  335.679371]  ovl_permission+0xde/0x320
  [  335.679723]  inode_permission+0x15e/0x2c0
  [  335.680090]  link_path_walk+0x115/0x550
  [  335.680771]  path_lookupat.isra.0+0xb2/0x200
  [  335.681170]  filename_lookup+0xda/0x240
  [  335.681922]  vfs_statx+0xa6/0x1f0
  [  335.682233]  vfs_fstatat+0x7b/0xb0

Fetch a reproducer in [Link].

Use the helper ovl_i_path_realinode() to get realinode and then do
non-nullptr checking.</Note>
    </Notes>
    <CVE>CVE-2023-53260</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix memory leak in acpi_buffer-&gt;pointer

There are memory leaks reported by kmemleak:
...
unreferenced object 0xffff00213c141000 (size 1024):
  comm "systemd-udevd", pid 2123, jiffies 4294909467 (age 6062.160s)
  hex dump (first 32 bytes):
    04 00 00 00 02 00 00 00 18 10 14 3c 21 00 ff ff  ...........&lt;!...
    00 00 00 00 00 00 00 00 03 00 00 00 10 00 00 00  ................
  backtrace:
    [&lt;000000004b7c9001&gt;] __kmem_cache_alloc_node+0x2f8/0x348
    [&lt;00000000b0fc7ceb&gt;] __kmalloc+0x58/0x108
    [&lt;0000000064ff4695&gt;] acpi_os_allocate+0x2c/0x68
    [&lt;000000007d57d116&gt;] acpi_ut_initialize_buffer+0x54/0xe0
    [&lt;0000000024583908&gt;] acpi_evaluate_object+0x388/0x438
    [&lt;0000000017b2e72b&gt;] acpi_evaluate_object_typed+0xe8/0x240
    [&lt;000000005df0eac2&gt;] coresight_get_platform_data+0x1b4/0x988 [coresight]
...

The ACPI buffer memory (buf.pointer) should be freed. But the buffer
is also used after returning from acpi_get_dsd_graph().
Move the temporary variables buf to acpi_coresight_parse_graph(),
and free it before the function return to prevent memory leak.</Note>
    </Notes>
    <CVE>CVE-2023-53261</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/nouveau/disp: fix use-after-free in error handling of nouveau_connector_create

We can't simply free the connector after calling drm_connector_init on it.
We need to clean up the drm side first.

It might not fix all regressions from commit 2b5d1c29f6c4
("drm/nouveau/disp: PIOR DP uses GPIO for HPD, not PMGR AUX interrupts"),
but at least it fixes a memory corruption in error handling related to
that commit.</Note>
    </Notes>
    <CVE>CVE-2023-53263</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:

clk: imx: clk-imxrt1050: fix memory leak in imxrt1050_clocks_probe

Use devm_of_iomap() instead of of_iomap() to automatically
handle the unused ioremap region. If any error occurs, regions allocated by
kzalloc() will leak, but using devm_kzalloc() instead will automatically
free the memory using devm_kfree().

Also, fix error handling of hws by adding unregister_hws label, which
unregisters remaining hws when iomap failed.</Note>
    </Notes>
    <CVE>CVE-2023-53264</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: ena: fix shift-out-of-bounds in exponential backoff

The ENA adapters on our instances occasionally reset.  Once recently
logged a UBSAN failure to console in the process:

  UBSAN: shift-out-of-bounds in build/linux/drivers/net/ethernet/amazon/ena/ena_com.c:540:13
  shift exponent 32 is too large for 32-bit type 'unsigned int'
  CPU: 28 PID: 70012 Comm: kworker/u72:2 Kdump: loaded not tainted 5.15.117
  Hardware name: Amazon EC2 c5d.9xlarge/, BIOS 1.0 10/16/2017
  Workqueue: ena ena_fw_reset_device [ena]
  Call Trace:
  &lt;TASK&gt;
  dump_stack_lvl+0x4a/0x63
  dump_stack+0x10/0x16
  ubsan_epilogue+0x9/0x36
  __ubsan_handle_shift_out_of_bounds.cold+0x61/0x10e
  ? __const_udelay+0x43/0x50
  ena_delay_exponential_backoff_us.cold+0x16/0x1e [ena]
  wait_for_reset_state+0x54/0xa0 [ena]
  ena_com_dev_reset+0xc8/0x110 [ena]
  ena_down+0x3fe/0x480 [ena]
  ena_destroy_device+0xeb/0xf0 [ena]
  ena_fw_reset_device+0x30/0x50 [ena]
  process_one_work+0x22b/0x3d0
  worker_thread+0x4d/0x3f0
  ? process_one_work+0x3d0/0x3d0
  kthread+0x12a/0x150
  ? set_kthread_struct+0x50/0x50
  ret_from_fork+0x22/0x30
  &lt;/TASK&gt;

Apparently, the reset delays are getting so large they can trigger a
UBSAN panic.

Looking at the code, the current timeout is capped at 5000us.  Using a
base value of 100us, the current code will overflow after (1&lt;&lt;29).  Even
at values before 32, this function wraps around, perhaps
unintentionally.

Cap the value of the exponent used for this backoff at (1&lt;&lt;16) which is
larger than currently necessary, but large enough to support bigger
values in the future.</Note>
    </Notes>
    <CVE>CVE-2023-53272</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

clk: mediatek: mt8183: Add back SSPM related clocks

This reverts commit 860690a93ef23b567f781c1b631623e27190f101.

On the MT8183, the SSPM related clocks were removed claiming a lack of
usage. This however causes some issues when the driver was converted to
the new simple-probe mechanism. This mechanism allocates enough space
for all the clocks defined in the clock driver, not the highest index
in the DT binding. This leads to out-of-bound writes if their are holes
in the DT binding or the driver (due to deprecated or unimplemented
clocks). These errors can go unnoticed and cause memory corruption,
leading to crashes in unrelated areas, or nothing at all. KASAN will
detect them.

Add the SSPM related clocks back to the MT8183 clock driver to fully
implement the DT binding. The SSPM clocks are for the power management
co-processor, and should never be turned off. They are marked as such.</Note>
    </Notes>
    <CVE>CVE-2023-53274</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: hda: fix a possible null-pointer dereference due to data race in snd_hdac_regmap_sync()

The variable codec-&gt;regmap is often protected by the lock
codec-&gt;regmap_lock when is accessed. However, it is accessed without
holding the lock when is accessed in snd_hdac_regmap_sync():

  if (codec-&gt;regmap)

In my opinion, this may be a harmful race, because if codec-&gt;regmap is
set to NULL right after the condition is checked, a null-pointer
dereference can occur in the called function regcache_sync():

  map-&gt;lock(map-&gt;lock_arg); --&gt; Line 360 in drivers/base/regmap/regcache.c

To fix this possible null-pointer dereference caused by data race, the
mutex_lock coverage is extended to protect the if statement as well as the
function call to regcache_sync().

[ Note: the lack of the regmap_lock itself is harmless for the current
  codec driver implementations, as snd_hdac_regmap_sync() is only for
  PM runtime resume that is prohibited during the codec probe.
  But the change makes the whole code more consistent, so it's merged
  as is -- tiwai ]</Note>
    </Notes>
    <CVE>CVE-2023-53275</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: qla2xxx: Remove unused nvme_ls_waitq wait queue

System crash when qla2x00_start_sp(sp) returns error code EGAIN and wake_up
gets called for uninitialized wait queue sp-&gt;nvme_ls_waitq.

    qla2xxx [0000:37:00.1]-2121:5: Returning existing qpair of ffff8ae2c0513400 for idx=0
    qla2xxx [0000:37:00.1]-700e:5: qla2x00_start_sp failed = 11
    BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
    PGD 0 P4D 0
    Oops: 0000 [#1] SMP NOPTI
    Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 09/03/2021
    Workqueue: nvme-wq nvme_fc_connect_ctrl_work [nvme_fc]
    RIP: 0010:__wake_up_common+0x4c/0x190
    RSP: 0018:ffff95f3e0cb7cd0 EFLAGS: 00010086
    RAX: 0000000000000000 RBX: ffff8b08d3b26328 RCX: 0000000000000000
    RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff8b08d3b26320
    RBP: 0000000000000001 R08: 0000000000000000 R09: ffffffffffffffe8
    R10: 0000000000000000 R11: ffff95f3e0cb7a60 R12: ffff95f3e0cb7d20
    R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000
    FS:  0000000000000000(0000) GS:ffff8b2fdf6c0000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000000 CR3: 0000002f1e410002 CR4: 00000000007706e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    PKRU: 55555554
    Call Trace:
     __wake_up_common_lock+0x7c/0xc0
     qla_nvme_ls_req+0x355/0x4c0 [qla2xxx]
     ? __nvme_fc_send_ls_req+0x260/0x380 [nvme_fc]
     ? nvme_fc_send_ls_req.constprop.42+0x1a/0x45 [nvme_fc]
     ? nvme_fc_connect_ctrl_work.cold.63+0x1e3/0xa7d [nvme_fc]

Remove unused nvme_ls_waitq wait queue. nvme_ls_waitq logic was removed
previously in the commits tagged Fixed: below.</Note>
    </Notes>
    <CVE>CVE-2023-53280</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Return the firmware result upon destroying QP/RQ

Previously when destroying a QP/RQ, the result of the firmware
destruction function was ignored and upper layers weren't informed
about the failure.
Which in turn could lead to various problems since when upper layer
isn't aware of the failure it continues its operation thinking that the
related QP/RQ was successfully destroyed while it actually wasn't,
which could lead to the below kernel WARN.

Currently, we return the correct firmware destruction status to upper
layers which in case of the RQ would be mlx5_ib_destroy_wq() which
was already capable of handling RQ destruction failure or in case of
a QP to destroy_qp_common(), which now would actually warn upon qp
destruction failure.

WARNING: CPU: 3 PID: 995 at drivers/infiniband/core/rdma_core.c:940 uverbs_destroy_ufile_hw+0xcb/0xe0 [ib_uverbs]
Modules linked in: xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_umad ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core overlay mlx5_core fuse
CPU: 3 PID: 995 Comm: python3 Not tainted 5.16.0-rc5+ #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:uverbs_destroy_ufile_hw+0xcb/0xe0 [ib_uverbs]
Code: 41 5c 41 5d 41 5e e9 44 34 f0 e0 48 89 df e8 4c 77 ff ff 49 8b 86 10 01 00 00 48 85 c0 74 a1 4c 89 e7 ff d0 eb 9a 0f 0b eb c1 &lt;0f&gt; 0b be 04 00 00 00 48 89 df e8 b6 f6 ff ff e9 75 ff ff ff 90 0f
RSP: 0018:ffff8881533e3e78 EFLAGS: 00010287
RAX: ffff88811b2cf3e0 RBX: ffff888106209700 RCX: 0000000000000000
RDX: ffff888106209780 RSI: ffff8881533e3d30 RDI: ffff888109b101a0
RBP: 0000000000000001 R08: ffff888127cb381c R09: 0de9890000000009
R10: ffff888127cb3800 R11: 0000000000000000 R12: ffff888106209780
R13: ffff888106209750 R14: ffff888100f20660 R15: 0000000000000000
FS:  00007f8be353b740(0000) GS:ffff88852c980000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f8bd5b117c0 CR3: 000000012cd8a004 CR4: 0000000000370ea0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
 ib_uverbs_close+0x1a/0x90 [ib_uverbs]
 __fput+0x82/0x230
 task_work_run+0x59/0x90
 exit_to_user_mode_prepare+0x138/0x140
 syscall_exit_to_user_mode+0x1d/0x50
 ? __x64_sys_close+0xe/0x40
 do_syscall_64+0x4a/0x90
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f8be3ae0abb
Code: 03 00 00 00 0f 05 48 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 83 43 f9 ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 35 44 89 c7 89 44 24 0c e8 c1 43 f9 ff 8b 44
RSP: 002b:00007ffdb51909c0 EFLAGS: 00000293 ORIG_RAX: 0000000000000003
RAX: 0000000000000000 RBX: 0000557bb7f7c020 RCX: 00007f8be3ae0abb
RDX: 0000557bb7c74010 RSI: 0000557bb7f14ca0 RDI: 0000000000000005
RBP: 0000557bb7fbd598 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000293 R12: 0000557bb7fbd5b8
R13: 0000557bb7fbd5a8 R14: 0000000000001000 R15: 0000557bb7f7c020
 &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2023-53286</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Put the cdns set active part outside the spin lock

The device may be scheduled during the resume process,
so this cannot appear in atomic operations. Since
pm_runtime_set_active will resume suppliers, put set
active outside the spin lock, which is only used to
protect the struct cdns data structure, otherwise the
kernel will report the following warning:

  BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1163
  in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 651, name: sh
  preempt_count: 1, expected: 0
  RCU nest depth: 0, expected: 0
  CPU: 0 PID: 651 Comm: sh Tainted: G        WC         6.1.20 #1
  Hardware name: Freescale i.MX8QM MEK (DT)
  Call trace:
    dump_backtrace.part.0+0xe0/0xf0
    show_stack+0x18/0x30
    dump_stack_lvl+0x64/0x80
    dump_stack+0x1c/0x38
    __might_resched+0x1fc/0x240
    __might_sleep+0x68/0xc0
    __pm_runtime_resume+0x9c/0xe0
    rpm_get_suppliers+0x68/0x1b0
    __pm_runtime_set_status+0x298/0x560
    cdns_resume+0xb0/0x1c0
    cdns3_controller_resume.isra.0+0x1e0/0x250
    cdns3_plat_resume+0x28/0x40</Note>
    </Notes>
    <CVE>CVE-2023-53287</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/client: Fix memory leak in drm_client_modeset_probe

When a new mode is set to modeset-&gt;mode, the previous mode should be freed.
This fixes the following kmemleak report:

drm_mode_duplicate+0x45/0x220 [drm]
drm_client_modeset_probe+0x944/0xf50 [drm]
__drm_fb_helper_initial_config_and_unlock+0xb4/0x2c0 [drm_kms_helper]
drm_fbdev_client_hotplug+0x2bc/0x4d0 [drm_kms_helper]
drm_client_register+0x169/0x240 [drm]
ast_pci_probe+0x142/0x190 [ast]
local_pci_probe+0xdc/0x180
work_for_cpu_fn+0x4e/0xa0
process_one_work+0x8b7/0x1540
worker_thread+0x70a/0xed0
kthread+0x29f/0x340
ret_from_fork+0x1f/0x30</Note>
    </Notes>
    <CVE>CVE-2023-53288</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

rcu/rcuscale: Stop kfree_scale_thread thread(s) after unloading rcuscale

Running the 'kfree_rcu_test' test case [1] results in a splat [2].
The root cause is the kfree_scale_thread thread(s) continue running
after unloading the rcuscale module.  This commit fixes that isue by
invoking kfree_scale_cleanup() from rcu_scale_cleanup() when removing
the rcuscale module.

[1] modprobe rcuscale kfree_rcu_test=1
    // After some time
    rmmod rcuscale
    rmmod torture

[2] BUG: unable to handle page fault for address: ffffffffc0601a87
    #PF: supervisor instruction fetch in kernel mode
    #PF: error_code(0x0010) - not-present page
    PGD 11de4f067 P4D 11de4f067 PUD 11de51067 PMD 112f4d067 PTE 0
    Oops: 0010 [#1] PREEMPT SMP NOPTI
    CPU: 1 PID: 1798 Comm: kfree_scale_thr Not tainted 6.3.0-rc1-rcu+ #1
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015
    RIP: 0010:0xffffffffc0601a87
    Code: Unable to access opcode bytes at 0xffffffffc0601a5d.
    RSP: 0018:ffffb25bc2e57e18 EFLAGS: 00010297
    RAX: 0000000000000000 RBX: ffffffffc061f0b6 RCX: 0000000000000000
    RDX: 0000000000000000 RSI: ffffffff962fd0de RDI: ffffffff962fd0de
    RBP: ffffb25bc2e57ea8 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000
    R13: 0000000000000000 R14: 000000000000000a R15: 00000000001c1dbe
    FS:  0000000000000000(0000) GS:ffff921fa2200000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: ffffffffc0601a5d CR3: 000000011de4c006 CR4: 0000000000370ee0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     &lt;TASK&gt;
     ? kvfree_call_rcu+0xf0/0x3a0
     ? kthread+0xf3/0x120
     ? kthread_complete_and_exit+0x20/0x20
     ? ret_from_fork+0x1f/0x30
     &lt;/TASK&gt;
    Modules linked in: rfkill sunrpc ... [last unloaded: torture]
    CR2: ffffffffc0601a87
    ---[ end trace 0000000000000000 ]---</Note>
    </Notes>
    <CVE>CVE-2023-53291</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

blk-mq: fix NULL dereference on q-&gt;elevator in blk_mq_elv_switch_none

After grabbing q-&gt;sysfs_lock, q-&gt;elevator may become NULL because of
elevator switch.

Fix the NULL dereference on q-&gt;elevator by checking it with lock.</Note>
    </Notes>
    <CVE>CVE-2023-53292</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: microchip: vcap api: Fix possible memory leak for vcap_dup_rule()

Inject fault When select CONFIG_VCAP_KUNIT_TEST, the below memory leak
occurs. If kzalloc() for duprule succeeds, but the following
kmemdup() fails, the duprule, ckf and caf memory will be leaked. So kfree
them in the error path.

unreferenced object 0xffff122744c50600 (size 192):
  comm "kunit_try_catch", pid 346, jiffies 4294896122 (age 911.812s)
  hex dump (first 32 bytes):
    10 27 00 00 04 00 00 00 1e 00 00 00 2c 01 00 00  .'..........,...
    00 00 00 00 00 00 00 00 18 06 c5 44 27 12 ff ff  ...........D'...
  backtrace:
    [&lt;00000000394b0db8&gt;] __kmem_cache_alloc_node+0x274/0x2f8
    [&lt;0000000001bedc67&gt;] kmalloc_trace+0x38/0x88
    [&lt;00000000b0612f98&gt;] vcap_dup_rule+0x50/0x460
    [&lt;000000005d2d3aca&gt;] vcap_add_rule+0x8cc/0x1038
    [&lt;00000000eef9d0f8&gt;] test_vcap_xn_rule_creator.constprop.0.isra.0+0x238/0x494
    [&lt;00000000cbda607b&gt;] vcap_api_rule_remove_in_front_test+0x1ac/0x698
    [&lt;00000000c8766299&gt;] kunit_try_run_case+0xe0/0x20c
    [&lt;00000000c4fe9186&gt;] kunit_generic_run_threadfn_adapter+0x50/0x94
    [&lt;00000000f6864acf&gt;] kthread+0x2e8/0x374
    [&lt;0000000022e639b3&gt;] ret_from_fork+0x10/0x20</Note>
    </Notes>
    <CVE>CVE-2023-53303</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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_rbtree: fix overlap expiration walk

The lazy gc on insert that should remove timed-out entries fails to release
the other half of the interval, if any.

Can be reproduced with tests/shell/testcases/sets/0044interval_overlap_0
in nftables.git and kmemleak enabled kernel.

Second bug is the use of rbe_prev vs. prev pointer.
If rbe_prev() returns NULL after at least one iteration, rbe_prev points
to element that is not an end interval, hence it should not be removed.

Lastly, check the genmask of the end interval if this is active in the
current generation.</Note>
    </Notes>
    <CVE>CVE-2023-53304</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: L2CAP: Fix use-after-free

Fix potential use-after-free in l2cap_le_command_rej.</Note>
    </Notes>
    <CVE>CVE-2023-53305</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/radeon: Fix integer overflow in radeon_cs_parser_init

The type of size is unsigned, if size is 0x40000000, there will be an
integer overflow, size will be zero after size *= sizeof(uint32_t),
will cause uninitialized memory to be referenced later</Note>
    </Notes>
    <CVE>CVE-2023-53309</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nilfs2: fix use-after-free of nilfs_root in dirtying inodes via iput

During unmount process of nilfs2, nothing holds nilfs_root structure after
nilfs2 detaches its writer in nilfs_detach_log_writer().  Previously,
nilfs_evict_inode() could cause use-after-free read for nilfs_root if
inodes are left in "garbage_list" and released by nilfs_dispose_list at
the end of nilfs_detach_log_writer(), and this bug was fixed by commit
9b5a04ac3ad9 ("nilfs2: fix use-after-free bug of nilfs_root in
nilfs_evict_inode()").

However, it turned out that there is another possibility of UAF in the
call path where mark_inode_dirty_sync() is called from iput():

nilfs_detach_log_writer()
  nilfs_dispose_list()
    iput()
      mark_inode_dirty_sync()
        __mark_inode_dirty()
          nilfs_dirty_inode()
            __nilfs_mark_inode_dirty()
              nilfs_load_inode_block() --&gt; causes UAF of nilfs_root struct

This can happen after commit 0ae45f63d4ef ("vfs: add support for a
lazytime mount option"), which changed iput() to call
mark_inode_dirty_sync() on its final reference if i_state has I_DIRTY_TIME
flag and i_nlink is non-zero.

This issue appears after commit 28a65b49eb53 ("nilfs2: do not write dirty
data after degenerating to read-only") when using the syzbot reproducer,
but the issue has potentially existed before.

Fix this issue by adding a "purging flag" to the nilfs structure, setting
that flag while disposing the "garbage_list" and checking it in
__nilfs_mark_inode_dirty().

Unlike commit 9b5a04ac3ad9 ("nilfs2: fix use-after-free bug of nilfs_root
in nilfs_evict_inode()"), this patch does not rely on ns_writer to
determine whether to skip operations, so as not to break recovery on
mount.  The nilfs_salvage_orphan_logs routine dirties the buffer of
salvaged data before attaching the log writer, so changing
__nilfs_mark_inode_dirty() to skip the operation when ns_writer is NULL
will cause recovery write to fail.  The purpose of using the cleanup-only
flag is to allow for narrowing of such conditions.</Note>
    </Notes>
    <CVE>CVE-2023-53311</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 net_dev_start_xmit trace event vs skb_transport_offset()

After blamed commit, we must be more careful about using
skb_transport_offset(), as reminded us by syzbot:

WARNING: CPU: 0 PID: 10 at include/linux/skbuff.h:2868 skb_transport_offset include/linux/skbuff.h:2977 [inline]
WARNING: CPU: 0 PID: 10 at include/linux/skbuff.h:2868 perf_trace_net_dev_start_xmit+0x89a/0xce0 include/trace/events/net.h:14
Modules linked in:
CPU: 0 PID: 10 Comm: kworker/u4:1 Not tainted 6.1.30-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
Workqueue: bat_events batadv_iv_send_outstanding_bat_ogm_packet
RIP: 0010:skb_transport_header include/linux/skbuff.h:2868 [inline]
RIP: 0010:skb_transport_offset include/linux/skbuff.h:2977 [inline]
RIP: 0010:perf_trace_net_dev_start_xmit+0x89a/0xce0 include/trace/events/net.h:14
Code: 8b 04 25 28 00 00 00 48 3b 84 24 c0 00 00 00 0f 85 4e 04 00 00 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc e8 56 22 01 fd &lt;0f&gt; 0b e9 f6 fc ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 86 f9 ff
RSP: 0018:ffffc900002bf700 EFLAGS: 00010293
RAX: ffffffff8485d8ca RBX: 000000000000ffff RCX: ffff888100914280
RDX: 0000000000000000 RSI: 000000000000ffff RDI: 000000000000ffff
RBP: ffffc900002bf818 R08: ffffffff8485d5b6 R09: fffffbfff0f8fb5e
R10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff110217d8f67
R13: ffff88810bec7b3a R14: dffffc0000000000 R15: dffffc0000000000
FS: 0000000000000000(0000) GS:ffff8881f6a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f96cf6d52f0 CR3: 000000012224c000 CR4: 0000000000350ef0
Call Trace:
&lt;TASK&gt;
[&lt;ffffffff84715e35&gt;] trace_net_dev_start_xmit include/trace/events/net.h:14 [inline]
[&lt;ffffffff84715e35&gt;] xmit_one net/core/dev.c:3643 [inline]
[&lt;ffffffff84715e35&gt;] dev_hard_start_xmit+0x705/0x980 net/core/dev.c:3660
[&lt;ffffffff8471a232&gt;] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324
[&lt;ffffffff85416493&gt;] dev_queue_xmit include/linux/netdevice.h:3030 [inline]
[&lt;ffffffff85416493&gt;] batadv_send_skb_packet+0x3f3/0x680 net/batman-adv/send.c:108
[&lt;ffffffff85416744&gt;] batadv_send_broadcast_skb+0x24/0x30 net/batman-adv/send.c:127
[&lt;ffffffff853bc52a&gt;] batadv_iv_ogm_send_to_if net/batman-adv/bat_iv_ogm.c:393 [inline]
[&lt;ffffffff853bc52a&gt;] batadv_iv_ogm_emit net/batman-adv/bat_iv_ogm.c:421 [inline]
[&lt;ffffffff853bc52a&gt;] batadv_iv_send_outstanding_bat_ogm_packet+0x69a/0x840 net/batman-adv/bat_iv_ogm.c:1701
[&lt;ffffffff8151023c&gt;] process_one_work+0x8ac/0x1170 kernel/workqueue.c:2289
[&lt;ffffffff81511938&gt;] worker_thread+0xaa8/0x12d0 kernel/workqueue.c:2436</Note>
    </Notes>
    <CVE>CVE-2023-53312</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/raid10: fix wrong setting of max_corr_read_errors

There is no input check when echo md/max_read_errors and overflow might
occur. Add check of input number.</Note>
    </Notes>
    <CVE>CVE-2023-53313</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/ep93xx-fb: Do not assign to struct fb_info.dev

Do not assing the Linux device to struct fb_info.dev. The call to
register_framebuffer() initializes the field to the fbdev device.
Drivers should not override its value.

Fixes a bug where the driver incorrectly decreases the hardware
device's reference counter and leaks the fbdev device.

v2:
	* add Fixes tag (Dan)</Note>
    </Notes>
    <CVE>CVE-2023-53314</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/dp: Free resources after unregistering them

The DP component's unbind operation walks through the submodules to
unregister and clean things up. But if the unbind happens because the DP
controller itself is being removed, all the memory for those submodules
has just been freed.

Change the order of these operations to avoid the many use-after-free
that otherwise happens in this code path.

Patchwork: https://patchwork.freedesktop.org/patch/542166/</Note>
    </Notes>
    <CVE>CVE-2023-53316</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Handle kvm_arm_init failure correctly in finalize_pkvm

Currently there is no synchronisation between finalize_pkvm() and
kvm_arm_init() initcalls. The finalize_pkvm() proceeds happily even if
kvm_arm_init() fails resulting in the following warning on all the CPUs
and eventually a HYP panic:

  | kvm [1]: IPA Size Limit: 48 bits
  | kvm [1]: Failed to init hyp memory protection
  | kvm [1]: error initializing Hyp mode: -22
  |
  | &lt;snip&gt;
  |
  | WARNING: CPU: 0 PID: 0 at arch/arm64/kvm/pkvm.c:226 _kvm_host_prot_finalize+0x30/0x50
  | Modules linked in:
  | CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.4.0 #237
  | Hardware name: FVP Base RevC (DT)
  | pstate: 634020c5 (nZCv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
  | pc : _kvm_host_prot_finalize+0x30/0x50
  | lr : __flush_smp_call_function_queue+0xd8/0x230
  |
  | Call trace:
  |  _kvm_host_prot_finalize+0x3c/0x50
  |  on_each_cpu_cond_mask+0x3c/0x6c
  |  pkvm_drop_host_privileges+0x4c/0x78
  |  finalize_pkvm+0x3c/0x5c
  |  do_one_initcall+0xcc/0x240
  |  do_initcall_level+0x8c/0xac
  |  do_initcalls+0x54/0x94
  |  do_basic_setup+0x1c/0x28
  |  kernel_init_freeable+0x100/0x16c
  |  kernel_init+0x20/0x1a0
  |  ret_from_fork+0x10/0x20
  | Failed to finalize Hyp protection: -22
  |     dtb=fvp-base-revc.dtb
  | kvm [95]: nVHE hyp BUG at: arch/arm64/kvm/hyp/nvhe/mem_protect.c:540!
  | kvm [95]: nVHE call trace:
  | kvm [95]:  [&lt;ffff800081052984&gt;] __kvm_nvhe_hyp_panic+0xac/0xf8
  | kvm [95]:  [&lt;ffff800081059644&gt;] __kvm_nvhe_handle_host_mem_abort+0x1a0/0x2ac
  | kvm [95]:  [&lt;ffff80008105511c&gt;] __kvm_nvhe_handle_trap+0x4c/0x160
  | kvm [95]:  [&lt;ffff8000810540fc&gt;] __kvm_nvhe___skip_pauth_save+0x4/0x4
  | kvm [95]: ---[ end nVHE call trace ]---
  | kvm [95]: Hyp Offset: 0xfffe8db00ffa0000
  | Kernel panic - not syncing: HYP panic:
  | PS:a34023c9 PC:0000f250710b973c ESR:00000000f2000800
  | FAR:ffff000800cb00d0 HPFAR:000000000880cb00 PAR:0000000000000000
  | VCPU:0000000000000000
  | CPU: 3 PID: 95 Comm: kworker/u16:2 Tainted: G        W          6.4.0 #237
  | Hardware name: FVP Base RevC (DT)
  | Workqueue: rpciod rpc_async_schedule
  | Call trace:
  |  dump_backtrace+0xec/0x108
  |  show_stack+0x18/0x2c
  |  dump_stack_lvl+0x50/0x68
  |  dump_stack+0x18/0x24
  |  panic+0x138/0x33c
  |  nvhe_hyp_panic_handler+0x100/0x184
  |  new_slab+0x23c/0x54c
  |  ___slab_alloc+0x3e4/0x770
  |  kmem_cache_alloc_node+0x1f0/0x278
  |  __alloc_skb+0xdc/0x294
  |  tcp_stream_alloc_skb+0x2c/0xf0
  |  tcp_sendmsg_locked+0x3d0/0xda4
  |  tcp_sendmsg+0x38/0x5c
  |  inet_sendmsg+0x44/0x60
  |  sock_sendmsg+0x1c/0x34
  |  xprt_sock_sendmsg+0xdc/0x274
  |  xs_tcp_send_request+0x1ac/0x28c
  |  xprt_transmit+0xcc/0x300
  |  call_transmit+0x78/0x90
  |  __rpc_execute+0x114/0x3d8
  |  rpc_async_schedule+0x28/0x48
  |  process_one_work+0x1d8/0x314
  |  worker_thread+0x248/0x474
  |  kthread+0xfc/0x184
  |  ret_from_fork+0x10/0x20
  | SMP: stopping secondary CPUs
  | Kernel Offset: 0x57c5cb460000 from 0xffff800080000000
  | PHYS_OFFSET: 0x80000000
  | CPU features: 0x00000000,1035b7a3,ccfe773f
  | Memory Limit: none
  | ---[ end Kernel panic - not syncing: HYP panic:
  | PS:a34023c9 PC:0000f250710b973c ESR:00000000f2000800
  | FAR:ffff000800cb00d0 HPFAR:000000000880cb00 PAR:0000000000000000
  | VCPU:0000000000000000 ]---

Fix it by checking for the successfull initialisation of kvm_arm_init()
in finalize_pkvm() before proceeding any futher.</Note>
    </Notes>
    <CVE>CVE-2023-53319</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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_hwsim: drop short frames

While technically some control frames like ACK are shorter and
end after Address 1, such frames shouldn't be forwarded through
wmediumd or similar userspace, so require the full 3-address
header to avoid accessing invalid memory if shorter frames are
passed in.</Note>
    </Notes>
    <CVE>CVE-2023-53321</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: qla2xxx: Wait for io return on terminate rport

System crash due to use after free.
Current code allows terminate_rport_io to exit before making
sure all IOs has returned. For FCP-2 device, IO's can hang
on in HW because driver has not tear down the session in FW at
first sign of cable pull. When dev_loss_tmo timer pops,
terminate_rport_io is called and upper layer is about to
free various resources. Terminate_rport_io trigger qla to do
the final cleanup, but the cleanup might not be fast enough where it
leave qla still holding on to the same resource.

Wait for IO's to return to upper layer before resources are freed.</Note>
    </Notes>
    <CVE>CVE-2023-53322</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ext2/dax: Fix ext2_setsize when len is page aligned

PAGE_ALIGN(x) macro gives the next highest value which is multiple of
pagesize. But if x is already page aligned then it simply returns x.
So, if x passed is 0 in dax_zero_range() function, that means the
length gets passed as 0 to -&gt;iomap_begin().

In ext2 it then calls ext2_get_blocks -&gt; max_blocks as 0 and hits bug_on
here in ext2_get_blocks().
	BUG_ON(maxblocks == 0);

Instead we should be calling dax_truncate_page() here which takes
care of it. i.e. it only calls dax_zero_range if the offset is not
page/block aligned.

This can be easily triggered with following on fsdax mounted pmem
device.

dd if=/dev/zero of=file count=1 bs=512
truncate -s 0 file

[79.525838] EXT2-fs (pmem0): DAX enabled. Warning: EXPERIMENTAL, use at your own risk
[79.529376] ext2 filesystem being mounted at /mnt1/test supports timestamps until 2038 (0x7fffffff)
[93.793207] ------------[ cut here ]------------
[93.795102] kernel BUG at fs/ext2/inode.c:637!
[93.796904] invalid opcode: 0000 [#1] PREEMPT SMP PTI
[93.798659] CPU: 0 PID: 1192 Comm: truncate Not tainted 6.3.0-rc2-xfstests-00056-g131086faa369 #139
[93.806459] RIP: 0010:ext2_get_blocks.constprop.0+0x524/0x610
&lt;...&gt;
[93.835298] Call Trace:
[93.836253]  &lt;TASK&gt;
[93.837103]  ? lock_acquire+0xf8/0x110
[93.838479]  ? d_lookup+0x69/0xd0
[93.839779]  ext2_iomap_begin+0xa7/0x1c0
[93.841154]  iomap_iter+0xc7/0x150
[93.842425]  dax_zero_range+0x6e/0xa0
[93.843813]  ext2_setsize+0x176/0x1b0
[93.845164]  ext2_setattr+0x151/0x200
[93.846467]  notify_change+0x341/0x4e0
[93.847805]  ? lock_acquire+0xf8/0x110
[93.849143]  ? do_truncate+0x74/0xe0
[93.850452]  ? do_truncate+0x84/0xe0
[93.851739]  do_truncate+0x84/0xe0
[93.852974]  do_sys_ftruncate+0x2b4/0x2f0
[93.854404]  do_syscall_64+0x3f/0x90
[93.855789]  entry_SYSCALL_64_after_hwframe+0x72/0xdc</Note>
    </Notes>
    <CVE>CVE-2023-53323</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/mdp5: Don't leak some plane state

Apparently no one noticed that mdp5 plane states leak like a sieve
ever since we introduced plane_state-&gt;commit refcount a few years ago
in 21a01abbe32a ("drm/atomic: Fix freeing connector/plane state too
early by tracking commits, v3.")

Fix it by using the right helpers.

Patchwork: https://patchwork.freedesktop.org/patch/551236/</Note>
    </Notes>
    <CVE>CVE-2023-53324</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/mediatek: dp: Change logging to dev for mtk_dp_aux_transfer()

Change logging from drm_{err,info}() to dev_{err,info}() in functions
mtk_dp_aux_transfer() and mtk_dp_aux_do_transfer(): this will be
essential to avoid getting NULL pointer kernel panics if any kind
of error happens during AUX transfers happening before the bridge
is attached.

This may potentially start happening in a later commit implementing
aux-bus support, as AUX transfers will be triggered from the panel
driver (for EDID) before the mtk-dp bridge gets attached, and it's
done in preparation for the same.</Note>
    </Notes>
    <CVE>CVE-2023-53325</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/ntfs3: Enhance sanity check while generating attr_list

ni_create_attr_list uses WARN_ON to catch error cases while generating
attribute list, which only prints out stack trace and may not be enough.
This repalces them with more proper error handling flow.

[   59.666332] BUG: kernel NULL pointer dereference, address: 000000000000000e
[   59.673268] #PF: supervisor read access in kernel mode
[   59.678354] #PF: error_code(0x0000) - not-present page
[   59.682831] PGD 8000000005ff1067 P4D 8000000005ff1067 PUD 7dee067 PMD 0
[   59.688556] Oops: 0000 [#1] PREEMPT SMP KASAN PTI
[   59.692642] CPU: 0 PID: 198 Comm: poc Tainted: G    B   W          6.2.0-rc1+ #4
[   59.698868] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
[   59.708795] RIP: 0010:ni_create_attr_list+0x505/0x860
[   59.713657] Code: 7e 10 e8 5e d0 d0 ff 45 0f b7 76 10 48 8d 7b 16 e8 00 d1 d0 ff 66 44 89 73 16 4d 8d 75 0e 4c 89 f7 e8 3f d0 d0 ff 4c 8d8
[   59.731559] RSP: 0018:ffff88800a56f1e0 EFLAGS: 00010282
[   59.735691] RAX: 0000000000000001 RBX: ffff88800b7b5088 RCX: ffffffffb83079fe
[   59.741792] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffffffbb7f9fc0
[   59.748423] RBP: ffff88800a56f3a8 R08: ffff88800b7b50a0 R09: fffffbfff76ff3f9
[   59.754654] R10: ffffffffbb7f9fc7 R11: fffffbfff76ff3f8 R12: ffff88800b756180
[   59.761552] R13: 0000000000000000 R14: 000000000000000e R15: 0000000000000050
[   59.768323] FS:  00007feaa8c96440(0000) GS:ffff88806d400000(0000) knlGS:0000000000000000
[   59.776027] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   59.781395] CR2: 00007f3a2e0b1000 CR3: 000000000a5bc000 CR4: 00000000000006f0
[   59.787607] Call Trace:
[   59.790271]  &lt;TASK&gt;
[   59.792488]  ? __pfx_ni_create_attr_list+0x10/0x10
[   59.797235]  ? kernel_text_address+0xd3/0xe0
[   59.800856]  ? unwind_get_return_address+0x3e/0x60
[   59.805101]  ? __kasan_check_write+0x18/0x20
[   59.809296]  ? preempt_count_sub+0x1c/0xd0
[   59.813421]  ni_ins_attr_ext+0x52c/0x5c0
[   59.817034]  ? __pfx_ni_ins_attr_ext+0x10/0x10
[   59.821926]  ? __vfs_setxattr+0x121/0x170
[   59.825718]  ? __vfs_setxattr_noperm+0x97/0x300
[   59.829562]  ? __vfs_setxattr_locked+0x145/0x170
[   59.833987]  ? vfs_setxattr+0x137/0x2a0
[   59.836732]  ? do_setxattr+0xce/0x150
[   59.839807]  ? setxattr+0x126/0x140
[   59.842353]  ? path_setxattr+0x164/0x180
[   59.845275]  ? __x64_sys_setxattr+0x71/0x90
[   59.848838]  ? do_syscall_64+0x3f/0x90
[   59.851898]  ? entry_SYSCALL_64_after_hwframe+0x72/0xdc
[   59.857046]  ? stack_depot_save+0x17/0x20
[   59.860299]  ni_insert_attr+0x1ba/0x420
[   59.863104]  ? __pfx_ni_insert_attr+0x10/0x10
[   59.867069]  ? preempt_count_sub+0x1c/0xd0
[   59.869897]  ? _raw_spin_unlock_irqrestore+0x2b/0x50
[   59.874088]  ? __create_object+0x3ae/0x5d0
[   59.877865]  ni_insert_resident+0xc4/0x1c0
[   59.881430]  ? __pfx_ni_insert_resident+0x10/0x10
[   59.886355]  ? kasan_save_alloc_info+0x1f/0x30
[   59.891117]  ? __kasan_kmalloc+0x8b/0xa0
[   59.894383]  ntfs_set_ea+0x90d/0xbf0
[   59.897703]  ? __pfx_ntfs_set_ea+0x10/0x10
[   59.901011]  ? kernel_text_address+0xd3/0xe0
[   59.905308]  ? __kernel_text_address+0x16/0x50
[   59.909811]  ? unwind_get_return_address+0x3e/0x60
[   59.914898]  ? __pfx_stack_trace_consume_entry+0x10/0x10
[   59.920250]  ? arch_stack_walk+0xa2/0x100
[   59.924560]  ? filter_irq_stacks+0x27/0x80
[   59.928722]  ntfs_setxattr+0x405/0x440
[   59.932512]  ? __pfx_ntfs_setxattr+0x10/0x10
[   59.936634]  ? kvmalloc_node+0x2d/0x120
[   59.940378]  ? kasan_save_stack+0x41/0x60
[   59.943870]  ? kasan_save_stack+0x2a/0x60
[   59.947719]  ? kasan_set_track+0x29/0x40
[   59.951417]  ? kasan_save_alloc_info+0x1f/0x30
[   59.955733]  ? __kasan_kmalloc+0x8b/0xa0
[   59.959598]  ? __kmalloc_node+0x68/0x150
[   59.963163]  ? kvmalloc_node+0x2d/0x120
[   59.966490]  ? vmemdup_user+0x2b/0xa0
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-53328</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

pstore/ram: Check start of empty przs during init

After commit 30696378f68a ("pstore/ram: Do not treat empty buffers as
valid"), initialization would assume a prz was valid after seeing that
the buffer_size is zero (regardless of the buffer start position). This
unchecked start value means it could be outside the bounds of the buffer,
leading to future access panics when written to:

 sysdump_panic_event+0x3b4/0x5b8
 atomic_notifier_call_chain+0x54/0x90
 panic+0x1c8/0x42c
 die+0x29c/0x2a8
 die_kernel_fault+0x68/0x78
 __do_kernel_fault+0x1c4/0x1e0
 do_bad_area+0x40/0x100
 do_translation_fault+0x68/0x80
 do_mem_abort+0x68/0xf8
 el1_da+0x1c/0xc0
 __raw_writeb+0x38/0x174
 __memcpy_toio+0x40/0xac
 persistent_ram_update+0x44/0x12c
 persistent_ram_write+0x1a8/0x1b8
 ramoops_pstore_write+0x198/0x1e8
 pstore_console_write+0x94/0xe0
 ...

To avoid this, also check if the prz start is 0 during the initialization
phase. If not, the next prz sanity check case will discover it (start &gt;
size) and zap the buffer back to a sane state.

[kees: update commit log with backtrace and clarifications]</Note>
    </Notes>
    <CVE>CVE-2023-53331</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ipu-bridge: Fix null pointer deref on SSDB/PLD parsing warnings

When ipu_bridge_parse_rotation() and ipu_bridge_parse_orientation() run
sensor-&gt;adev is not set yet.

So if either of the dev_warn() calls about unknown values are hit this
will lead to a NULL pointer deref.

Set sensor-&gt;adev earlier, with a borrowed ref to avoid making unrolling
on errors harder, to fix this.</Note>
    </Notes>
    <CVE>CVE-2023-53336</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

lwt: Fix return values of BPF xmit ops

BPF encap ops can return different types of positive values, such like
NET_RX_DROP, NET_XMIT_CN, NETDEV_TX_BUSY, and so on, from function
skb_do_redirect and bpf_lwt_xmit_reroute. At the xmit hook, such return
values would be treated implicitly as LWTUNNEL_XMIT_CONTINUE in
ip(6)_finish_output2. When this happens, skbs that have been freed would
continue to the neighbor subsystem, causing use-after-free bug and
kernel crashes.

To fix the incorrect behavior, skb_do_redirect return values can be
simply discarded, the same as tc-egress behavior. On the other hand,
bpf_lwt_xmit_reroute returns useful errors to local senders, e.g. PMTU
information. Thus convert its return values to avoid the conflict with
LWTUNNEL_XMIT_CONTINUE.</Note>
    </Notes>
    <CVE>CVE-2023-53338</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 BUG_ON condition in btrfs_cancel_balance

Pausing and canceling balance can race to interrupt balance lead to BUG_ON
panic in btrfs_cancel_balance. The BUG_ON condition in btrfs_cancel_balance
does not take this race scenario into account.

However, the race condition has no other side effects. We can fix that.

Reproducing it with panic trace like this:

  kernel BUG at fs/btrfs/volumes.c:4618!
  RIP: 0010:btrfs_cancel_balance+0x5cf/0x6a0
  Call Trace:
   &lt;TASK&gt;
   ? do_nanosleep+0x60/0x120
   ? hrtimer_nanosleep+0xb7/0x1a0
   ? sched_core_clone_cookie+0x70/0x70
   btrfs_ioctl_balance_ctl+0x55/0x70
   btrfs_ioctl+0xa46/0xd20
   __x64_sys_ioctl+0x7d/0xa0
   do_syscall_64+0x38/0x80
   entry_SYSCALL_64_after_hwframe+0x63/0xcd

  Race scenario as follows:
  &gt; mutex_unlock(&amp;fs_info-&gt;balance_mutex);
  &gt; --------------------
  &gt; .......issue pause and cancel req in another thread
  &gt; --------------------
  &gt; ret = __btrfs_balance(fs_info);
  &gt;
  &gt; mutex_lock(&amp;fs_info-&gt;balance_mutex);
  &gt; if (ret == -ECANCELED &amp;&amp; atomic_read(&amp;fs_info-&gt;balance_pause_req)) {
  &gt;         btrfs_info(fs_info, "balance: paused");
  &gt;         btrfs_exclop_balance(fs_info, BTRFS_EXCLOP_BALANCE_PAUSED);
  &gt; }</Note>
    </Notes>
    <CVE>CVE-2023-53339</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: marvell: prestera: fix handling IPv4 routes with nhid

Fix handling IPv4 routes referencing a nexthop via its id by replacing
calls to fib_info_nh() with fib_info_nhc().

Trying to add an IPv4 route referencing a nextop via nhid:

    $ ip link set up swp5
    $ ip a a 10.0.0.1/24 dev swp5
    $ ip nexthop add dev swp5 id 20 via 10.0.0.2
    $ ip route add 10.0.1.0/24 nhid 20

triggers warnings when trying to handle the route:

[  528.805763] ------------[ cut here ]------------
[  528.810437] WARNING: CPU: 3 PID: 53 at include/net/nexthop.h:468 __prestera_fi_is_direct+0x2c/0x68 [prestera]
[  528.820434] Modules linked in: prestera_pci act_gact act_police sch_ingress cls_u32 cls_flower prestera arm64_delta_tn48m_dn_led(O) arm64_delta_tn48m_dn_cpld(O) [last unloaded: prestera_pci]
[  528.837485] CPU: 3 PID: 53 Comm: kworker/u8:3 Tainted: G           O       6.4.5 #1
[  528.845178] Hardware name: delta,tn48m-dn (DT)
[  528.849641] Workqueue: prestera_ordered __prestera_router_fib_event_work [prestera]
[  528.857352] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  528.864347] pc : __prestera_fi_is_direct+0x2c/0x68 [prestera]
[  528.870135] lr : prestera_k_arb_fib_evt+0xb20/0xd50 [prestera]
[  528.876007] sp : ffff80000b20bc90
[  528.879336] x29: ffff80000b20bc90 x28: 0000000000000000 x27: ffff0001374d3a48
[  528.886510] x26: ffff000105604000 x25: ffff000134af8a28 x24: ffff0001374d3800
[  528.893683] x23: ffff000101c89148 x22: ffff000101c89000 x21: ffff000101c89200
[  528.900855] x20: ffff00013641fda0 x19: ffff800009d01088 x18: 0000000000000059
[  528.908027] x17: 0000000000000277 x16: 0000000000000000 x15: 0000000000000000
[  528.915198] x14: 0000000000000003 x13: 00000000000fe400 x12: 0000000000000000
[  528.922371] x11: 0000000000000002 x10: 0000000000000aa0 x9 : ffff8000013d2020
[  528.929543] x8 : 0000000000000018 x7 : 000000007b1703f8 x6 : 000000001ca72f86
[  528.936715] x5 : 0000000033399ea7 x4 : 0000000000000000 x3 : ffff0001374d3acc
[  528.943886] x2 : 0000000000000000 x1 : ffff00010200de00 x0 : ffff000134ae3f80
[  528.951058] Call trace:
[  528.953516]  __prestera_fi_is_direct+0x2c/0x68 [prestera]
[  528.958952]  __prestera_router_fib_event_work+0x100/0x158 [prestera]
[  528.965348]  process_one_work+0x208/0x488
[  528.969387]  worker_thread+0x4c/0x430
[  528.973068]  kthread+0x120/0x138
[  528.976313]  ret_from_fork+0x10/0x20
[  528.979909] ---[ end trace 0000000000000000 ]---
[  528.984998] ------------[ cut here ]------------
[  528.989645] WARNING: CPU: 3 PID: 53 at include/net/nexthop.h:468 __prestera_fi_is_direct+0x2c/0x68 [prestera]
[  528.999628] Modules linked in: prestera_pci act_gact act_police sch_ingress cls_u32 cls_flower prestera arm64_delta_tn48m_dn_led(O) arm64_delta_tn48m_dn_cpld(O) [last unloaded: prestera_pci]
[  529.016676] CPU: 3 PID: 53 Comm: kworker/u8:3 Tainted: G        W  O       6.4.5 #1
[  529.024368] Hardware name: delta,tn48m-dn (DT)
[  529.028830] Workqueue: prestera_ordered __prestera_router_fib_event_work [prestera]
[  529.036539] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  529.043533] pc : __prestera_fi_is_direct+0x2c/0x68 [prestera]
[  529.049318] lr : __prestera_k_arb_fc_apply+0x280/0x2f8 [prestera]
[  529.055452] sp : ffff80000b20bc60
[  529.058781] x29: ffff80000b20bc60 x28: 0000000000000000 x27: ffff0001374d3a48
[  529.065953] x26: ffff000105604000 x25: ffff000134af8a28 x24: ffff0001374d3800
[  529.073126] x23: ffff000101c89148 x22: ffff000101c89148 x21: ffff00013641fda0
[  529.080299] x20: ffff000101c89000 x19: ffff000101c89020 x18: 0000000000000059
[  529.087471] x17: 0000000000000277 x16: 0000000000000000 x15: 0000000000000000
[  529.094642] x14: 0000000000000003 x13: 00000000000fe400 x12: 0000000000000000
[  529.101814] x11: 0000000000000002 x10: 0000000000000aa0 x9 : ffff8000013cee80
[  529.108985] x8 : 0000000000000018 x7 : 000000007b1703f8 x6 
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-53342</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

icmp6: Fix null-ptr-deref of ip6_null_entry-&gt;rt6i_idev in icmp6_dev().

With some IPv6 Ext Hdr (RPL, SRv6, etc.), we can send a packet that
has the link-local address as src and dst IP and will be forwarded to
an external IP in the IPv6 Ext Hdr.

For example, the script below generates a packet whose src IP is the
link-local address and dst is updated to 11::.

  # for f in $(find /proc/sys/net/ -name *seg6_enabled*); do echo 1 &gt; $f; done
  # python3
  &gt;&gt;&gt; from socket import *
  &gt;&gt;&gt; from scapy.all import *
  &gt;&gt;&gt;
  &gt;&gt;&gt; SRC_ADDR = DST_ADDR = "fe80::5054:ff:fe12:3456"
  &gt;&gt;&gt;
  &gt;&gt;&gt; pkt = IPv6(src=SRC_ADDR, dst=DST_ADDR)
  &gt;&gt;&gt; pkt /= IPv6ExtHdrSegmentRouting(type=4, addresses=["11::", "22::"], segleft=1)
  &gt;&gt;&gt;
  &gt;&gt;&gt; sk = socket(AF_INET6, SOCK_RAW, IPPROTO_RAW)
  &gt;&gt;&gt; sk.sendto(bytes(pkt), (DST_ADDR, 0))

For such a packet, we call ip6_route_input() to look up a route for the
next destination in these three functions depending on the header type.

  * ipv6_rthdr_rcv()
  * ipv6_rpl_srh_rcv()
  * ipv6_srh_rcv()

If no route is found, ip6_null_entry is set to skb, and the following
dst_input(skb) calls ip6_pkt_drop().

Finally, in icmp6_dev(), we dereference skb_rt6_info(skb)-&gt;rt6i_idev-&gt;dev
as the input device is the loopback interface.  Then, we have to check if
skb_rt6_info(skb)-&gt;rt6i_idev is NULL or not to avoid NULL pointer deref
for ip6_null_entry.

BUG: kernel NULL pointer dereference, address: 0000000000000000
 PF: supervisor read access in kernel mode
 PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 0 PID: 157 Comm: python3 Not tainted 6.4.0-11996-gb121d614371c #35
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
RIP: 0010:icmp6_send (net/ipv6/icmp.c:436 net/ipv6/icmp.c:503)
Code: fe ff ff 48 c7 40 30 c0 86 5d 83 e8 c6 44 1c 00 e9 c8 fc ff ff 49 8b 46 58 48 83 e0 fe 0f 84 4a fb ff ff 48 8b 80 d0 00 00 00 &lt;48&gt; 8b 00 44 8b 88 e0 00 00 00 e9 34 fb ff ff 4d 85 ed 0f 85 69 01
RSP: 0018:ffffc90000003c70 EFLAGS: 00000286
RAX: 0000000000000000 RBX: 0000000000000001 RCX: 00000000000000e0
RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff888006d72a18
RBP: ffffc90000003d80 R08: 0000000000000000 R09: 0000000000000001
R10: ffffc90000003d98 R11: 0000000000000040 R12: ffff888006d72a10
R13: 0000000000000000 R14: ffff8880057fb800 R15: ffffffff835d86c0
FS:  00007f9dc72ee740(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 00000000057b2000 CR4: 00000000007506f0
PKRU: 55555554
Call Trace:
 &lt;IRQ&gt;
 ip6_pkt_drop (net/ipv6/route.c:4513)
 ipv6_rthdr_rcv (net/ipv6/exthdrs.c:640 net/ipv6/exthdrs.c:686)
 ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:437 (discriminator 5))
 ip6_input_finish (./include/linux/rcupdate.h:781 net/ipv6/ip6_input.c:483)
 __netif_receive_skb_one_core (net/core/dev.c:5455)
 process_backlog (./include/linux/rcupdate.h:781 net/core/dev.c:5895)
 __napi_poll (net/core/dev.c:6460)
 net_rx_action (net/core/dev.c:6529 net/core/dev.c:6660)
 __do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:554)
 do_softirq (kernel/softirq.c:454 kernel/softirq.c:441)
 &lt;/IRQ&gt;
 &lt;TASK&gt;
 __local_bh_enable_ip (kernel/softirq.c:381)
 __dev_queue_xmit (net/core/dev.c:4231)
 ip6_finish_output2 (./include/net/neighbour.h:544 net/ipv6/ip6_output.c:135)
 rawv6_sendmsg (./include/net/dst.h:458 ./include/linux/netfilter.h:303 net/ipv6/raw.c:656 net/ipv6/raw.c:914)
 sock_sendmsg (net/socket.c:725 net/socket.c:748)
 __sys_sendto (net/socket.c:2134)
 __x64_sys_sendto (net/socket.c:2146 net/socket.c:2142 net/socket.c:2142)
 do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)
 entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)
RIP: 0033:0x7f9dc751baea
Code: d8 64 89 02 48 c7 c0 ff f
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-53343</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/qaic: Fix slicing memory leak

The temporary buffer storing slicing configuration data from user is only
freed on error.  This is a memory leak.  Free the buffer unconditionally.</Note>
    </Notes>
    <CVE>CVE-2023-53350</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/ttm: check null pointer before accessing when swapping

Add a check to avoid null pointer dereference as below:

[   90.002283] general protection fault, probably for non-canonical
address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI
[   90.002292] KASAN: null-ptr-deref in range
[0x0000000000000000-0x0000000000000007]
[   90.002346]  ? exc_general_protection+0x159/0x240
[   90.002352]  ? asm_exc_general_protection+0x26/0x30
[   90.002357]  ? ttm_bo_evict_swapout_allowable+0x322/0x5e0 [ttm]
[   90.002365]  ? ttm_bo_evict_swapout_allowable+0x42e/0x5e0 [ttm]
[   90.002373]  ttm_bo_swapout+0x134/0x7f0 [ttm]
[   90.002383]  ? __pfx_ttm_bo_swapout+0x10/0x10 [ttm]
[   90.002391]  ? lock_acquire+0x44d/0x4f0
[   90.002398]  ? ttm_device_swapout+0xa5/0x260 [ttm]
[   90.002412]  ? lock_acquired+0x355/0xa00
[   90.002416]  ? do_raw_spin_trylock+0xb6/0x190
[   90.002421]  ? __pfx_lock_acquired+0x10/0x10
[   90.002426]  ? ttm_global_swapout+0x25/0x210 [ttm]
[   90.002442]  ttm_device_swapout+0x198/0x260 [ttm]
[   90.002456]  ? __pfx_ttm_device_swapout+0x10/0x10 [ttm]
[   90.002472]  ttm_global_swapout+0x75/0x210 [ttm]
[   90.002486]  ttm_tt_populate+0x187/0x3f0 [ttm]
[   90.002501]  ttm_bo_handle_move_mem+0x437/0x590 [ttm]
[   90.002517]  ttm_bo_validate+0x275/0x430 [ttm]
[   90.002530]  ? __pfx_ttm_bo_validate+0x10/0x10 [ttm]
[   90.002544]  ? kasan_save_stack+0x33/0x60
[   90.002550]  ? kasan_set_track+0x25/0x30
[   90.002554]  ? __kasan_kmalloc+0x8f/0xa0
[   90.002558]  ? amdgpu_gtt_mgr_new+0x81/0x420 [amdgpu]
[   90.003023]  ? ttm_resource_alloc+0xf6/0x220 [ttm]
[   90.003038]  amdgpu_bo_pin_restricted+0x2dd/0x8b0 [amdgpu]
[   90.003210]  ? __x64_sys_ioctl+0x131/0x1a0
[   90.003210]  ? do_syscall_64+0x60/0x90</Note>
    </Notes>
    <CVE>CVE-2023-53352</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

skbuff: skb_segment, Call zero copy functions before using skbuff frags

Commit bf5c25d60861 ("skbuff: in skb_segment, call zerocopy functions
once per nskb") added the call to zero copy functions in skb_segment().
The change introduced a bug in skb_segment() because skb_orphan_frags()
may possibly change the number of fragments or allocate new fragments
altogether leaving nrfrags and frag to point to the old values. This can
cause a panic with stacktrace like the one below.

[  193.894380] BUG: kernel NULL pointer dereference, address: 00000000000000bc
[  193.895273] CPU: 13 PID: 18164 Comm: vh-net-17428 Kdump: loaded Tainted: G           O      5.15.123+ #26
[  193.903919] RIP: 0010:skb_segment+0xb0e/0x12f0
[  194.021892] Call Trace:
[  194.027422]  &lt;TASK&gt;
[  194.072861]  tcp_gso_segment+0x107/0x540
[  194.082031]  inet_gso_segment+0x15c/0x3d0
[  194.090783]  skb_mac_gso_segment+0x9f/0x110
[  194.095016]  __skb_gso_segment+0xc1/0x190
[  194.103131]  netem_enqueue+0x290/0xb10 [sch_netem]
[  194.107071]  dev_qdisc_enqueue+0x16/0x70
[  194.110884]  __dev_queue_xmit+0x63b/0xb30
[  194.121670]  bond_start_xmit+0x159/0x380 [bonding]
[  194.128506]  dev_hard_start_xmit+0xc3/0x1e0
[  194.131787]  __dev_queue_xmit+0x8a0/0xb30
[  194.138225]  macvlan_start_xmit+0x4f/0x100 [macvlan]
[  194.141477]  dev_hard_start_xmit+0xc3/0x1e0
[  194.144622]  sch_direct_xmit+0xe3/0x280
[  194.147748]  __dev_queue_xmit+0x54a/0xb30
[  194.154131]  tap_get_user+0x2a8/0x9c0 [tap]
[  194.157358]  tap_sendmsg+0x52/0x8e0 [tap]
[  194.167049]  handle_tx_zerocopy+0x14e/0x4c0 [vhost_net]
[  194.173631]  handle_tx+0xcd/0xe0 [vhost_net]
[  194.176959]  vhost_worker+0x76/0xb0 [vhost]
[  194.183667]  kthread+0x118/0x140
[  194.190358]  ret_from_fork+0x1f/0x30
[  194.193670]  &lt;/TASK&gt;

In this case calling skb_orphan_frags() updated nr_frags leaving nrfrags
local variable in skb_segment() stale. This resulted in the code hitting
i &gt;= nrfrags prematurely and trying to move to next frag_skb using
list_skb pointer, which was NULL, and caused kernel panic. Move the call
to zero copy functions before using frags and nr_frags.</Note>
    </Notes>
    <CVE>CVE-2023-53354</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Add null pointer check in gserial_suspend

Consider a case where gserial_disconnect has already cleared
gser-&gt;ioport. And if gserial_suspend gets called afterwards,
it will lead to accessing of gser-&gt;ioport and thus causing
null pointer dereference.

Avoid this by adding a null pointer check. Added a static
spinlock to prevent gser-&gt;ioport from becoming null after
the newly added null pointer check.</Note>
    </Notes>
    <CVE>CVE-2023-53356</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/raid10: check slab-out-of-bounds in md_bitmap_get_counter

If we write a large number to md/bitmap_set_bits, md_bitmap_checkpage()
will return -EINVAL because 'page &gt;= bitmap-&gt;pages', but the return value
was not checked immediately in md_bitmap_get_counter() in order to set
*blocks value and slab-out-of-bounds occurs.

Move check of 'page &gt;= bitmap-&gt;pages' to md_bitmap_get_counter() and
return directly if true.</Note>
    </Notes>
    <CVE>CVE-2023-53357</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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.2: Rework scratch handling for READ_PLUS (again)

I found that the read code might send multiple requests using the same
nfs_pgio_header, but nfs4_proc_read_setup() is only called once. This is
how we ended up occasionally double-freeing the scratch buffer, but also
means we set a NULL pointer but non-zero length to the xdr scratch
buffer. This results in an oops the first time decoding needs to copy
something to scratch, which frequently happens when decoding READ_PLUS
hole segments.

I fix this by moving scratch handling into the pageio read code. I
provide a function to allocate scratch space for decoding read replies,
and free the scratch buffer when the nfs_pgio_header is freed.</Note>
    </Notes>
    <CVE>CVE-2023-53360</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: don't assume child devices are all fsl-mc devices

Changes in VFIO caused a pseudo-device to be created as child of
fsl-mc devices causing a crash [1] when trying to bind a fsl-mc
device to VFIO. Fix this by checking the device type when enumerating
fsl-mc child devices.

[1]
Modules linked in:
Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
CPU: 6 PID: 1289 Comm: sh Not tainted 6.2.0-rc5-00047-g7c46948a6e9c #2
Hardware name: NXP Layerscape LX2160ARDB (DT)
pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : mc_send_command+0x24/0x1f0
lr : dprc_get_obj_region+0xfc/0x1c0
sp : ffff80000a88b900
x29: ffff80000a88b900 x28: ffff48a9429e1400 x27: 00000000000002b2
x26: ffff48a9429e1718 x25: 0000000000000000 x24: 0000000000000000
x23: ffffd59331ba3918 x22: ffffd59331ba3000 x21: 0000000000000000
x20: ffff80000a88b9b8 x19: 0000000000000000 x18: 0000000000000001
x17: 7270642f636d2d6c x16: 73662e3030303030 x15: ffffffffffffffff
x14: ffffd59330f1d668 x13: ffff48a8727dc389 x12: ffff48a8727dc386
x11: 0000000000000002 x10: 00008ceaf02f35d4 x9 : 0000000000000012
x8 : 0000000000000000 x7 : 0000000000000006 x6 : ffff80000a88bab0
x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff80000a88b9e8
x2 : ffff80000a88b9e8 x1 : 0000000000000000 x0 : ffff48a945142b80
Call trace:
 mc_send_command+0x24/0x1f0
 dprc_get_obj_region+0xfc/0x1c0
 fsl_mc_device_add+0x340/0x590
 fsl_mc_obj_device_add+0xd0/0xf8
 dprc_scan_objects+0x1c4/0x340
 dprc_scan_container+0x38/0x60
 vfio_fsl_mc_probe+0x9c/0xf8
 fsl_mc_driver_probe+0x24/0x70
 really_probe+0xbc/0x2a8
 __driver_probe_device+0x78/0xe0
 device_driver_attach+0x30/0x68
 bind_store+0xa8/0x130
 drv_attr_store+0x24/0x38
 sysfs_kf_write+0x44/0x60
 kernfs_fop_write_iter+0x128/0x1b8
 vfs_write+0x334/0x448
 ksys_write+0x68/0xf0
 __arm64_sys_write+0x1c/0x28
 invoke_syscall+0x44/0x108
 el0_svc_common.constprop.1+0x94/0xf8
 do_el0_svc+0x38/0xb0
 el0_svc+0x20/0x50
 el0t_64_sync_handler+0x98/0xc0
 el0t_64_sync+0x174/0x178
Code: aa0103f4 a9025bf5 d5384100 b9400801 (79401260)
---[ end trace 0000000000000000 ]---</Note>
    </Notes>
    <CVE>CVE-2023-53362</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: da9063: better fix null deref with partial DT

Two versions of the original patch were sent but V1 was merged instead
of V2 due to a mistake.

So update to V2.

The advantage of V2 is that it completely avoids dereferencing the pointer,
even just to take the address, which may fix problems with some compilers.
Both versions work on my gcc 9.4 but use the safer one.</Note>
    </Notes>
    <CVE>CVE-2023-53364</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ip6mr: Fix skb_under_panic in ip6mr_cache_report()

skbuff: skb_under_panic: text:ffffffff88771f69 len:56 put:-4
 head:ffff88805f86a800 data:ffff887f5f86a850 tail:0x88 end:0x2c0 dev:pim6reg
 ------------[ cut here ]------------
 kernel BUG at net/core/skbuff.c:192!
 invalid opcode: 0000 [#1] PREEMPT SMP KASAN
 CPU: 2 PID: 22968 Comm: kworker/2:11 Not tainted 6.5.0-rc3-00044-g0a8db05b571a #236
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
 Workqueue: ipv6_addrconf addrconf_dad_work
 RIP: 0010:skb_panic+0x152/0x1d0
 Call Trace:
  &lt;TASK&gt;
  skb_push+0xc4/0xe0
  ip6mr_cache_report+0xd69/0x19b0
  reg_vif_xmit+0x406/0x690
  dev_hard_start_xmit+0x17e/0x6e0
  __dev_queue_xmit+0x2d6a/0x3d20
  vlan_dev_hard_start_xmit+0x3ab/0x5c0
  dev_hard_start_xmit+0x17e/0x6e0
  __dev_queue_xmit+0x2d6a/0x3d20
  neigh_connected_output+0x3ed/0x570
  ip6_finish_output2+0x5b5/0x1950
  ip6_finish_output+0x693/0x11c0
  ip6_output+0x24b/0x880
  NF_HOOK.constprop.0+0xfd/0x530
  ndisc_send_skb+0x9db/0x1400
  ndisc_send_rs+0x12a/0x6c0
  addrconf_dad_completed+0x3c9/0xea0
  addrconf_dad_work+0x849/0x1420
  process_one_work+0xa22/0x16e0
  worker_thread+0x679/0x10c0
  ret_from_fork+0x28/0x60
  ret_from_fork_asm+0x11/0x20

When setup a vlan device on dev pim6reg, DAD ns packet may sent on reg_vif_xmit().
reg_vif_xmit()
    ip6mr_cache_report()
        skb_push(skb, -skb_network_offset(pkt));//skb_network_offset(pkt) is 4
And skb_push declared as:
	void *skb_push(struct sk_buff *skb, unsigned int len);
		skb-&gt;data -= len;
		//0xffff88805f86a84c - 0xfffffffc = 0xffff887f5f86a850
skb-&gt;data is set to 0xffff887f5f86a850, which is invalid mem addr, lead to skb_push() fails.</Note>
    </Notes>
    <CVE>CVE-2023-53365</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/habanalabs: fix mem leak in capture user mappings

This commit fixes a memory leak caused when clearing the user_mappings
info when a new context is opened immediately after user_mapping is
captured and a hard reset is performed.</Note>
    </Notes>
    <CVE>CVE-2023-53367</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 race issue between cpu buffer write and swap

Warning happened in rb_end_commit() at code:
	if (RB_WARN_ON(cpu_buffer, !local_read(&amp;cpu_buffer-&gt;committing)))

  WARNING: CPU: 0 PID: 139 at kernel/trace/ring_buffer.c:3142
	rb_commit+0x402/0x4a0
  Call Trace:
   ring_buffer_unlock_commit+0x42/0x250
   trace_buffer_unlock_commit_regs+0x3b/0x250
   trace_event_buffer_commit+0xe5/0x440
   trace_event_buffer_reserve+0x11c/0x150
   trace_event_raw_event_sched_switch+0x23c/0x2c0
   __traceiter_sched_switch+0x59/0x80
   __schedule+0x72b/0x1580
   schedule+0x92/0x120
   worker_thread+0xa0/0x6f0

It is because the race between writing event into cpu buffer and swapping
cpu buffer through file per_cpu/cpu0/snapshot:

  Write on CPU 0             Swap buffer by per_cpu/cpu0/snapshot on CPU 1
  --------                   --------
                             tracing_snapshot_write()
                               [...]

  ring_buffer_lock_reserve()
    cpu_buffer = buffer-&gt;buffers[cpu]; // 1. Suppose find 'cpu_buffer_a';
    [...]
    rb_reserve_next_event()
      [...]

                               ring_buffer_swap_cpu()
                                 if (local_read(&amp;cpu_buffer_a-&gt;committing))
                                     goto out_dec;
                                 if (local_read(&amp;cpu_buffer_b-&gt;committing))
                                     goto out_dec;
                                 buffer_a-&gt;buffers[cpu] = cpu_buffer_b;
                                 buffer_b-&gt;buffers[cpu] = cpu_buffer_a;
                                 // 2. cpu_buffer has swapped here.

      rb_start_commit(cpu_buffer);
      if (unlikely(READ_ONCE(cpu_buffer-&gt;buffer)
          != buffer)) { // 3. This check passed due to 'cpu_buffer-&gt;buffer'
        [...]           //    has not changed here.
        return NULL;
      }
                                 cpu_buffer_b-&gt;buffer = buffer_a;
                                 cpu_buffer_a-&gt;buffer = buffer_b;
                                 [...]

      // 4. Reserve event from 'cpu_buffer_a'.

  ring_buffer_unlock_commit()
    [...]
    cpu_buffer = buffer-&gt;buffers[cpu]; // 5. Now find 'cpu_buffer_b' !!!
    rb_commit(cpu_buffer)
      rb_end_commit()  // 6. WARN for the wrong 'committing' state !!!

Based on above analysis, we can easily reproduce by following testcase:
  ``` bash
  #!/bin/bash

  dmesg -n 7
  sysctl -w kernel.panic_on_warn=1
  TR=/sys/kernel/tracing
  echo 7 &gt; ${TR}/buffer_size_kb
  echo "sched:sched_switch" &gt; ${TR}/set_event
  while [ true ]; do
          echo 1 &gt; ${TR}/per_cpu/cpu0/snapshot
  done &amp;
  while [ true ]; do
          echo 1 &gt; ${TR}/per_cpu/cpu0/snapshot
  done &amp;
  while [ true ]; do
          echo 1 &gt; ${TR}/per_cpu/cpu0/snapshot
  done &amp;
  ```

To fix it, IIUC, we can use smp_call_function_single() to do the swap on
the target cpu where the buffer is located, so that above race would be
avoided.</Note>
    </Notes>
    <CVE>CVE-2023-53368</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: dcb: choose correct policy to parse DCB_ATTR_BCN

The dcbnl_bcn_setcfg uses erroneous policy to parse tb[DCB_ATTR_BCN],
which is introduced in commit 859ee3c43812 ("DCB: Add support for DCB
BCN"). Please see the comment in below code

static int dcbnl_bcn_setcfg(...)
{
  ...
  ret = nla_parse_nested_deprecated(..., dcbnl_pfc_up_nest, .. )
  // !!! dcbnl_pfc_up_nest for attributes
  //  DCB_PFC_UP_ATTR_0 to DCB_PFC_UP_ATTR_ALL in enum dcbnl_pfc_up_attrs
  ...
  for (i = DCB_BCN_ATTR_RP_0; i &lt;= DCB_BCN_ATTR_RP_7; i++) {
  // !!! DCB_BCN_ATTR_RP_0 to DCB_BCN_ATTR_RP_7 in enum dcbnl_bcn_attrs
    ...
    value_byte = nla_get_u8(data[i]);
    ...
  }
  ...
  for (i = DCB_BCN_ATTR_BCNA_0; i &lt;= DCB_BCN_ATTR_RI; i++) {
  // !!! DCB_BCN_ATTR_BCNA_0 to DCB_BCN_ATTR_RI in enum dcbnl_bcn_attrs
  ...
    value_int = nla_get_u32(data[i]);
  ...
  }
  ...
}

That is, the nla_parse_nested_deprecated uses dcbnl_pfc_up_nest
attributes to parse nlattr defined in dcbnl_pfc_up_attrs. But the
following access code fetch each nlattr as dcbnl_bcn_attrs attributes.
By looking up the associated nla_policy for dcbnl_bcn_attrs. We can find
the beginning part of these two policies are "same".

static const struct nla_policy dcbnl_pfc_up_nest[...] = {
        [DCB_PFC_UP_ATTR_0]   = {.type = NLA_U8},
        [DCB_PFC_UP_ATTR_1]   = {.type = NLA_U8},
        [DCB_PFC_UP_ATTR_2]   = {.type = NLA_U8},
        [DCB_PFC_UP_ATTR_3]   = {.type = NLA_U8},
        [DCB_PFC_UP_ATTR_4]   = {.type = NLA_U8},
        [DCB_PFC_UP_ATTR_5]   = {.type = NLA_U8},
        [DCB_PFC_UP_ATTR_6]   = {.type = NLA_U8},
        [DCB_PFC_UP_ATTR_7]   = {.type = NLA_U8},
        [DCB_PFC_UP_ATTR_ALL] = {.type = NLA_FLAG},
};

static const struct nla_policy dcbnl_bcn_nest[...] = {
        [DCB_BCN_ATTR_RP_0]         = {.type = NLA_U8},
        [DCB_BCN_ATTR_RP_1]         = {.type = NLA_U8},
        [DCB_BCN_ATTR_RP_2]         = {.type = NLA_U8},
        [DCB_BCN_ATTR_RP_3]         = {.type = NLA_U8},
        [DCB_BCN_ATTR_RP_4]         = {.type = NLA_U8},
        [DCB_BCN_ATTR_RP_5]         = {.type = NLA_U8},
        [DCB_BCN_ATTR_RP_6]         = {.type = NLA_U8},
        [DCB_BCN_ATTR_RP_7]         = {.type = NLA_U8},
        [DCB_BCN_ATTR_RP_ALL]       = {.type = NLA_FLAG},
        // from here is somewhat different
        [DCB_BCN_ATTR_BCNA_0]       = {.type = NLA_U32},
        ...
        [DCB_BCN_ATTR_ALL]          = {.type = NLA_FLAG},
};

Therefore, the current code is buggy and this
nla_parse_nested_deprecated could overflow the dcbnl_pfc_up_nest and use
the adjacent nla_policy to parse attributes from DCB_BCN_ATTR_BCNA_0.

Hence use the correct policy dcbnl_bcn_nest to parse the nested
tb[DCB_ATTR_BCN] TLV.</Note>
    </Notes>
    <CVE>CVE-2023-53369</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix memory leak in mes self test

The fences associated with mes queue have to be freed
up during amdgpu_ring_fini.</Note>
    </Notes>
    <CVE>CVE-2023-53370</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix memory leak in mlx5e_fs_tt_redirect_any_create

The memory pointed to by the fs-&gt;any pointer is not freed in the error
path of mlx5e_fs_tt_redirect_any_create, which can lead to a memory leak.
Fix by freeing the memory in the error path, thereby making the error path
identical to mlx5e_fs_tt_redirect_any_destroy().</Note>
    </Notes>
    <CVE>CVE-2023-53371</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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_conn: fail SCO/ISO via hci_conn_failed if ACL gone early

Not calling hci_(dis)connect_cfm before deleting conn referred to by a
socket generally results to use-after-free.

When cleaning up SCO connections when the parent ACL is deleted too
early, use hci_conn_failed to do the connection cleanup properly.

We also need to clean up ISO connections in a similar situation when
connecting has started but LE Create CIS is not yet sent, so do it too
here.</Note>
    </Notes>
    <CVE>CVE-2023-53374</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: prevent use-after-free by freeing the cfile later

In smb2_compound_op we have a possible use-after-free
which can cause hard to debug problems later on.

This was revealed during stress testing with KASAN enabled
kernel. Fixing it by moving the cfile free call to
a few lines below, after the usage.</Note>
    </Notes>
    <CVE>CVE-2023-53377</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: phy: phy-tahvo: fix memory leak in tahvo_usb_probe()

Smatch reports:
drivers/usb/phy/phy-tahvo.c: tahvo_usb_probe()
warn: missing unwind goto?

After geting irq, if ret &lt; 0, it will return without error handling to
free memory.
Just add error handling to fix this problem.</Note>
    </Notes>
    <CVE>CVE-2023-53379</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/raid10: fix null-ptr-deref of mreplace in raid10_sync_request

There are two check of 'mreplace' in raid10_sync_request(). In the first
check, 'need_replace' will be set and 'mreplace' will be used later if
no-Faulty 'mreplace' exists, In the second check, 'mreplace' will be
set to NULL if it is Faulty, but 'need_replace' will not be changed
accordingly. null-ptr-deref occurs if Faulty is set between two check.

Fix it by merging two checks into one. And replace 'need_replace' with
'mreplace' because their values are always the same.</Note>
    </Notes>
    <CVE>CVE-2023-53380</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: mwifiex: avoid possible NULL skb pointer dereference

In 'mwifiex_handle_uap_rx_forward()', always check the value
returned by 'skb_copy()' to avoid potential NULL pointer
dereference in 'mwifiex_uap_queue_bridged_pkt()', and drop
original skb in case of copying failure.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2023-53384</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: mdp3: Fix resource leaks in of_find_device_by_node

Use put_device to release the object get through of_find_device_by_node,
avoiding resource leaks.</Note>
    </Notes>
    <CVE>CVE-2023-53385</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 potential use-after-free when clear keys

Similar to commit c5d2b6fa26b5 ("Bluetooth: Fix use-after-free in
hci_remove_ltk/hci_remove_irk"). We can not access k after kfree_rcu()
call.</Note>
    </Notes>
    <CVE>CVE-2023-53386</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

shmem: use ramfs_kill_sb() for kill_sb method of ramfs-based tmpfs

As the ramfs-based tmpfs uses ramfs_init_fs_context() for the
init_fs_context method, which allocates fc-&gt;s_fs_info, use ramfs_kill_sb()
to free it and avoid a memory leak.</Note>
    </Notes>
    <CVE>CVE-2023-53391</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: xsk: Fix crash on regular rq reactivation

When the regular rq is reactivated after the XSK socket is closed
it could be reading stale cqes which eventually corrupts the rq.
This leads to no more traffic being received on the regular rq and a
crash on the next close or deactivation of the rq.

Kal Cuttler Conely reported this issue as a crash on the release
path when the xdpsock sample program is stopped (killed) and restarted
in sequence while traffic is running.

This patch flushes all cqes when during the rq flush. The cqe flushing
is done in the reset state of the rq. mlx5e_rq_to_ready code is moved
into the flush function to allow for this.</Note>
    </Notes>
    <CVE>CVE-2023-53394</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Add AML_NO_OPERAND_RESOLVE flag to Timer

ACPICA commit 90310989a0790032f5a0140741ff09b545af4bc5

According to the ACPI specification 19.6.134, no argument is required to be passed for ASL Timer instruction. For taking care of no argument, AML_NO_OPERAND_RESOLVE flag is added to ASL Timer instruction opcode.

When ASL timer instruction interpreted by ACPI interpreter, getting error. After adding AML_NO_OPERAND_RESOLVE flag to ASL Timer instruction opcode, issue is not observed.

=============================================================
UBSAN: array-index-out-of-bounds in acpica/dswexec.c:401:12 index -1 is out of range for type 'union acpi_operand_object *[9]'
CPU: 37 PID: 1678 Comm: cat Not tainted
6.0.0-dev-th500-6.0.y-1+bcf8c46459e407-generic-64k
HW name: NVIDIA BIOS v1.1.1-d7acbfc-dirty 12/19/2022 Call trace:
 dump_backtrace+0xe0/0x130
 show_stack+0x20/0x60
 dump_stack_lvl+0x68/0x84
 dump_stack+0x18/0x34
 ubsan_epilogue+0x10/0x50
 __ubsan_handle_out_of_bounds+0x80/0x90
 acpi_ds_exec_end_op+0x1bc/0x6d8
 acpi_ps_parse_loop+0x57c/0x618
 acpi_ps_parse_aml+0x1e0/0x4b4
 acpi_ps_execute_method+0x24c/0x2b8
 acpi_ns_evaluate+0x3a8/0x4bc
 acpi_evaluate_object+0x15c/0x37c
 acpi_evaluate_integer+0x54/0x15c
 show_power+0x8c/0x12c [acpi_power_meter]</Note>
    </Notes>
    <CVE>CVE-2023-53395</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:

modpost: fix off by one in is_executable_section()

The &gt; comparison should be &gt;= to prevent an out of bounds array
access.</Note>
    </Notes>
    <CVE>CVE-2023-53397</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: kmem: fix a NULL pointer dereference in obj_stock_flush_required()

KCSAN found an issue in obj_stock_flush_required():
stock-&gt;cached_objcg can be reset between the check and dereference:

==================================================================
BUG: KCSAN: data-race in drain_all_stock / drain_obj_stock

write to 0xffff888237c2a2f8 of 8 bytes by task 19625 on cpu 0:
 drain_obj_stock+0x408/0x4e0 mm/memcontrol.c:3306
 refill_obj_stock+0x9c/0x1e0 mm/memcontrol.c:3340
 obj_cgroup_uncharge+0xe/0x10 mm/memcontrol.c:3408
 memcg_slab_free_hook mm/slab.h:587 [inline]
 __cache_free mm/slab.c:3373 [inline]
 __do_kmem_cache_free mm/slab.c:3577 [inline]
 kmem_cache_free+0x105/0x280 mm/slab.c:3602
 __d_free fs/dcache.c:298 [inline]
 dentry_free fs/dcache.c:375 [inline]
 __dentry_kill+0x422/0x4a0 fs/dcache.c:621
 dentry_kill+0x8d/0x1e0
 dput+0x118/0x1f0 fs/dcache.c:913
 __fput+0x3bf/0x570 fs/file_table.c:329
 ____fput+0x15/0x20 fs/file_table.c:349
 task_work_run+0x123/0x160 kernel/task_work.c:179
 resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]
 exit_to_user_mode_loop+0xcf/0xe0 kernel/entry/common.c:171
 exit_to_user_mode_prepare+0x6a/0xa0 kernel/entry/common.c:203
 __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]
 syscall_exit_to_user_mode+0x26/0x140 kernel/entry/common.c:296
 do_syscall_64+0x4d/0xc0 arch/x86/entry/common.c:86
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

read to 0xffff888237c2a2f8 of 8 bytes by task 19632 on cpu 1:
 obj_stock_flush_required mm/memcontrol.c:3319 [inline]
 drain_all_stock+0x174/0x2a0 mm/memcontrol.c:2361
 try_charge_memcg+0x6d0/0xd10 mm/memcontrol.c:2703
 try_charge mm/memcontrol.c:2837 [inline]
 mem_cgroup_charge_skmem+0x51/0x140 mm/memcontrol.c:7290
 sock_reserve_memory+0xb1/0x390 net/core/sock.c:1025
 sk_setsockopt+0x800/0x1e70 net/core/sock.c:1525
 udp_lib_setsockopt+0x99/0x6c0 net/ipv4/udp.c:2692
 udp_setsockopt+0x73/0xa0 net/ipv4/udp.c:2817
 sock_common_setsockopt+0x61/0x70 net/core/sock.c:3668
 __sys_setsockopt+0x1c3/0x230 net/socket.c:2271
 __do_sys_setsockopt net/socket.c:2282 [inline]
 __se_sys_setsockopt net/socket.c:2279 [inline]
 __x64_sys_setsockopt+0x66/0x80 net/socket.c:2279
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

value changed: 0xffff8881382d52c0 -&gt; 0xffff888138893740

Reported by Kernel Concurrency Sanitizer on:
CPU: 1 PID: 19632 Comm: syz-executor.0 Not tainted 6.3.0-rc2-syzkaller-00387-g534293368afa #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023

Fix it by using READ_ONCE()/WRITE_ONCE() for all accesses to
stock-&gt;cached_objcg.</Note>
    </Notes>
    <CVE>CVE-2023-53401</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ntfs: Fix panic about slab-out-of-bounds caused by ntfs_listxattr()

Here is a BUG report from syzbot:

BUG: KASAN: slab-out-of-bounds in ntfs_list_ea fs/ntfs3/xattr.c:191 [inline]
BUG: KASAN: slab-out-of-bounds in ntfs_listxattr+0x401/0x570 fs/ntfs3/xattr.c:710
Read of size 1 at addr ffff888021acaf3d by task syz-executor128/3632

Call Trace:
 ntfs_list_ea fs/ntfs3/xattr.c:191 [inline]
 ntfs_listxattr+0x401/0x570 fs/ntfs3/xattr.c:710
 vfs_listxattr fs/xattr.c:457 [inline]
 listxattr+0x293/0x2d0 fs/xattr.c:804

Fix the logic of ea_all iteration. When the ea-&gt;name_len is 0,
return immediately, or Add2Ptr() would visit invalid memory
in the next loop.

[almaz.alexandrovich@paragon-software.com: lines of the patch have changed]</Note>
    </Notes>
    <CVE>CVE-2023-53420</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

blk-cgroup: Reinit blkg_iostat_set after clearing in blkcg_reset_stats()

When blkg_alloc() is called to allocate a blkcg_gq structure
with the associated blkg_iostat_set's, there are 2 fields within
blkg_iostat_set that requires proper initialization - blkg &amp; sync.
The former field was introduced by commit 3b8cc6298724 ("blk-cgroup:
Optimize blkcg_rstat_flush()") while the later one was introduced by
commit f73316482977 ("blk-cgroup: reimplement basic IO stats using
cgroup rstat").

Unfortunately those fields in the blkg_iostat_set's are not properly
re-initialized when they are cleared in v1's blkcg_reset_stats(). This
can lead to a kernel panic due to NULL pointer access of the blkg
pointer. The missing initialization of sync is less problematic and
can be a problem in a debug kernel due to missing lockdep initialization.

Fix these problems by re-initializing them after memory clearing.</Note>
    </Notes>
    <CVE>CVE-2023-53421</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

clk: mediatek: fix of_iomap memory leak

Smatch reports:
drivers/clk/mediatek/clk-mtk.c:583 mtk_clk_simple_probe() warn:
    'base' from of_iomap() not released on lines: 496.

This problem was also found in linux-next. In mtk_clk_simple_probe(),
base is not released when handling errors
if clk_data is not existed, which may cause a leak.
So free_base should be added here to release base.</Note>
    </Notes>
    <CVE>CVE-2023-53424</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: platform: mediatek: vpu: fix NULL ptr dereference

If pdev is NULL, then it is still dereferenced.

This fixes this smatch warning:

drivers/media/platform/mediatek/vpu/mtk_vpu.c:570 vpu_load_firmware() warn: address of NULL pointer 'pdev'</Note>
    </Notes>
    <CVE>CVE-2023-53425</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 xsk_diag use-after-free error during socket cleanup

Fix a use-after-free error that is possible if the xsk_diag interface
is used after the socket has been unbound from the device. This can
happen either due to the socket being closed or the device
disappearing. In the early days of AF_XDP, the way we tested that a
socket was not bound to a device was to simply check if the netdevice
pointer in the xsk socket structure was NULL. Later, a better system
was introduced by having an explicit state variable in the xsk socket
struct. For example, the state of a socket that is on the way to being
closed and has been unbound from the device is XSK_UNBOUND.

The commit in the Fixes tag below deleted the old way of signalling
that a socket is unbound, setting dev to NULL. This in the belief that
all code using the old way had been exterminated. That was
unfortunately not true as the xsk diagnostics code was still using the
old way and thus does not work as intended when a socket is going
down. Fix this by introducing a test against the state variable. If
the socket is in the state XSK_UNBOUND, simply abort the diagnostic's
netlink operation.</Note>
    </Notes>
    <CVE>CVE-2023-53426</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

powercap: arm_scmi: Remove recursion while parsing zones

Powercap zones can be defined as arranged in a hierarchy of trees and when
registering a zone with powercap_register_zone(), the kernel powercap
subsystem expects this to happen starting from the root zones down to the
leaves; on the other side, de-registration by powercap_deregister_zone()
must begin from the leaf zones.

Available SCMI powercap zones are retrieved dynamically from the platform
at probe time and, while any defined hierarchy between the zones is
described properly in the zones descriptor, the platform returns the
availables zones with no particular well-defined order: as a consequence,
the trees possibly composing the hierarchy of zones have to be somehow
walked properly to register the retrieved zones from the root.

Currently the ARM SCMI Powercap driver walks the zones using a recursive
algorithm; this approach, even though correct and tested can lead to kernel
stack overflow when processing a returned hierarchy of zones composed by
particularly high trees.

Avoid possible kernel stack overflow by substituting the recursive approach
with an iterative one supported by a dynamically allocated stack-like data
structure.</Note>
    </Notes>
    <CVE>CVE-2023-53428</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: don't check PageError in __extent_writepage

__extent_writepage currenly sets PageError whenever any error happens,
and the also checks for PageError to decide if to call error handling.
This leads to very unclear responsibility for cleaning up on errors.
In the VM and generic writeback helpers the basic idea is that once
I/O is fired off all error handling responsibility is delegated to the
end I/O handler.  But if that end I/O handler sets the PageError bit,
and the submitter checks it, the bit could in some cases leak into the
submission context for fast enough I/O.

Fix this by simply not checking PageError and just using the local
ret variable to check for submission errors.  This also fundamentally
solves the long problem documented in a comment in __extent_writepage
by never leaking the error bit into the submission context.</Note>
    </Notes>
    <CVE>CVE-2023-53429</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

firewire: net: fix use after free in fwnet_finish_incoming_packet()

The netif_rx() function frees the skb so we can't dereference it to
save the skb-&gt;len.</Note>
    </Notes>
    <CVE>CVE-2023-53432</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: snic: Fix possible memory leak if device_add() fails

If device_add() returns error, the name allocated by dev_set_name() needs
be freed. As the comment of device_add() says, put_device() should be used
to give up the reference in the error path. So fix this by calling
put_device(), then the name can be freed in kobject_cleanp().</Note>
    </Notes>
    <CVE>CVE-2023-53436</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/MCE: Always save CS register on AMD Zen IF Poison errors

The Instruction Fetch (IF) units on current AMD Zen-based systems do not
guarantee a synchronous #MC is delivered for poison consumption errors.
Therefore, MCG_STATUS[EIPV|RIPV] will not be set. However, the
microarchitecture does guarantee that the exception is delivered within
the same context. In other words, the exact rIP is not known, but the
context is known to not have changed.

There is no architecturally-defined method to determine this behavior.

The Code Segment (CS) register is always valid on such IF unit poison
errors regardless of the value of MCG_STATUS[EIPV|RIPV].

Add a quirk to save the CS register for poison consumption from the IF
unit banks.

This is needed to properly determine the context of the error.
Otherwise, the severity grading function will assume the context is
IN_KERNEL due to the m-&gt;cs value being 0 (the initialized value). This
leads to unnecessary kernel panics on data poison errors due to the
kernel believing the poison consumption occurred in kernel context.</Note>
    </Notes>
    <CVE>CVE-2023-53438</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: cpumap: Fix memory leak in cpu_map_update_elem

Syzkaller reported a memory leak as follows:

BUG: memory leak
unreferenced object 0xff110001198ef748 (size 192):
  comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s)
  hex dump (first 32 bytes):
    00 00 00 00 4a 19 00 00 80 ad e3 e4 fe ff c0 00  ....J...........
    00 b2 d3 0c 01 00 11 ff 28 f5 8e 19 01 00 11 ff  ........(.......
  backtrace:
    [&lt;ffffffffadd28087&gt;] __cpu_map_entry_alloc+0xf7/0xb00
    [&lt;ffffffffadd28d8e&gt;] cpu_map_update_elem+0x2fe/0x3d0
    [&lt;ffffffffadc6d0fd&gt;] bpf_map_update_value.isra.0+0x2bd/0x520
    [&lt;ffffffffadc7349b&gt;] map_update_elem+0x4cb/0x720
    [&lt;ffffffffadc7d983&gt;] __se_sys_bpf+0x8c3/0xb90
    [&lt;ffffffffb029cc80&gt;] do_syscall_64+0x30/0x40
    [&lt;ffffffffb0400099&gt;] entry_SYSCALL_64_after_hwframe+0x61/0xc6

BUG: memory leak
unreferenced object 0xff110001198ef528 (size 192):
  comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s)
  hex dump (first 32 bytes):
    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:
    [&lt;ffffffffadd281f0&gt;] __cpu_map_entry_alloc+0x260/0xb00
    [&lt;ffffffffadd28d8e&gt;] cpu_map_update_elem+0x2fe/0x3d0
    [&lt;ffffffffadc6d0fd&gt;] bpf_map_update_value.isra.0+0x2bd/0x520
    [&lt;ffffffffadc7349b&gt;] map_update_elem+0x4cb/0x720
    [&lt;ffffffffadc7d983&gt;] __se_sys_bpf+0x8c3/0xb90
    [&lt;ffffffffb029cc80&gt;] do_syscall_64+0x30/0x40
    [&lt;ffffffffb0400099&gt;] entry_SYSCALL_64_after_hwframe+0x61/0xc6

BUG: memory leak
unreferenced object 0xff1100010fd93d68 (size 8):
  comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s)
  hex dump (first 8 bytes):
    00 00 00 00 00 00 00 00                          ........
  backtrace:
    [&lt;ffffffffade5db3e&gt;] kvmalloc_node+0x11e/0x170
    [&lt;ffffffffadd28280&gt;] __cpu_map_entry_alloc+0x2f0/0xb00
    [&lt;ffffffffadd28d8e&gt;] cpu_map_update_elem+0x2fe/0x3d0
    [&lt;ffffffffadc6d0fd&gt;] bpf_map_update_value.isra.0+0x2bd/0x520
    [&lt;ffffffffadc7349b&gt;] map_update_elem+0x4cb/0x720
    [&lt;ffffffffadc7d983&gt;] __se_sys_bpf+0x8c3/0xb90
    [&lt;ffffffffb029cc80&gt;] do_syscall_64+0x30/0x40
    [&lt;ffffffffb0400099&gt;] entry_SYSCALL_64_after_hwframe+0x61/0xc6

In the cpu_map_update_elem flow, when kthread_stop is called before
calling the threadfn of rcpu-&gt;kthread, since the KTHREAD_SHOULD_STOP bit
of kthread has been set by kthread_stop, the threadfn of rcpu-&gt;kthread
will never be executed, and rcpu-&gt;refcnt will never be 0, which will
lead to the allocated rcpu, rcpu-&gt;queue and rcpu-&gt;queue-&gt;queue cannot be
released.

Calling kthread_stop before executing kthread's threadfn will return
-EINTR. We can complete the release of memory resources in this state.</Note>
    </Notes>
    <CVE>CVE-2023-53441</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Block switchdev mode when ADQ is active and vice versa

ADQ and switchdev are not supported simultaneously. Enabling both at the
same time can result in nullptr dereference.

To prevent this, check if ADQ is active when changing devlink mode to
switchdev mode, and check if switchdev is active when enabling ADQ.</Note>
    </Notes>
    <CVE>CVE-2023-53442</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/ttm: fix bulk_move corruption when adding a entry

When the resource is the first in the bulk_move range, adding it again
(thus moving it to the tail) will corrupt the list since the first
pointer is not moved. This eventually lead to null pointer deref in
ttm_lru_bulk_move_del()</Note>
    </Notes>
    <CVE>CVE-2023-53444</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/ASPM: Disable ASPM on MFD function removal to avoid use-after-free

Struct pcie_link_state-&gt;downstream is a pointer to the pci_dev of function
0.  Previously we retained that pointer when removing function 0, and
subsequent ASPM policy changes dereferenced it, resulting in a
use-after-free warning from KASAN, e.g.:

  # echo 1 &gt; /sys/bus/pci/devices/0000:03:00.0/remove
  # echo powersave &gt; /sys/module/pcie_aspm/parameters/policy

  BUG: KASAN: slab-use-after-free in pcie_config_aspm_link+0x42d/0x500
  Call Trace:
   kasan_report+0xae/0xe0
   pcie_config_aspm_link+0x42d/0x500
   pcie_aspm_set_policy+0x8e/0x1a0
   param_attr_store+0x162/0x2c0
   module_attr_store+0x3e/0x80

PCIe spec r6.0, sec 7.5.3.7, recommends that software program the same ASPM
Control value in all functions of multi-function devices.

Disable ASPM and free the pcie_link_state when any child function is
removed so we can discard the dangling pcie_link_state-&gt;downstream pointer
and maintain the same ASPM Control configuration for all functions.

[bhelgaas: commit log and comment]</Note>
    </Notes>
    <CVE>CVE-2023-53446</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

f2fs: don't reset unchangable mount option in f2fs_remount()

syzbot reports a bug as below:

general protection fault, probably for non-canonical address 0xdffffc0000000009: 0000 [#1] PREEMPT SMP KASAN
RIP: 0010:__lock_acquire+0x69/0x2000 kernel/locking/lockdep.c:4942
Call Trace:
 lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5691
 __raw_write_lock include/linux/rwlock_api_smp.h:209 [inline]
 _raw_write_lock+0x2e/0x40 kernel/locking/spinlock.c:300
 __drop_extent_tree+0x3ac/0x660 fs/f2fs/extent_cache.c:1100
 f2fs_drop_extent_tree+0x17/0x30 fs/f2fs/extent_cache.c:1116
 f2fs_insert_range+0x2d5/0x3c0 fs/f2fs/file.c:1664
 f2fs_fallocate+0x4e4/0x6d0 fs/f2fs/file.c:1838
 vfs_fallocate+0x54b/0x6b0 fs/open.c:324
 ksys_fallocate fs/open.c:347 [inline]
 __do_sys_fallocate fs/open.c:355 [inline]
 __se_sys_fallocate fs/open.c:353 [inline]
 __x64_sys_fallocate+0xbd/0x100 fs/open.c:353
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

The root cause is race condition as below:
- since it tries to remount rw filesystem, so that do_remount won't
call sb_prepare_remount_readonly to block fallocate, there may be race
condition in between remount and fallocate.
- in f2fs_remount(), default_options() will reset mount option to default
one, and then update it based on result of parse_options(), so there is
a hole which race condition can happen.

Thread A			Thread B
- f2fs_fill_super
 - parse_options
  - clear_opt(READ_EXTENT_CACHE)

- f2fs_remount
 - default_options
  - set_opt(READ_EXTENT_CACHE)
				- f2fs_fallocate
				 - f2fs_insert_range
				  - f2fs_drop_extent_tree
				   - __drop_extent_tree
				    - __may_extent_tree
				     - test_opt(READ_EXTENT_CACHE) return true
				    - write_lock(&amp;et-&gt;lock) access NULL pointer
 - parse_options
  - clear_opt(READ_EXTENT_CACHE)</Note>
    </Notes>
    <CVE>CVE-2023-53447</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: imxfb: Removed unneeded release_mem_region

Remove unnecessary release_mem_region from the error path to prevent
mem region from being released twice, which could avoid resource leak
or other unexpected issues.</Note>
    </Notes>
    <CVE>CVE-2023-53448</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: qla2xxx: Fix potential NULL pointer dereference

Klocwork tool reported 'cur_dsd' may be dereferenced.  Add fix to validate
pointer before dereferencing the pointer.</Note>
    </Notes>
    <CVE>CVE-2023-53451</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: multitouch: Correct devm device reference for hidinput input_dev name

Reference the HID device rather than the input device for the devm
allocation of the input_dev name. Referencing the input_dev would lead to a
use-after-free when the input_dev was unregistered and subsequently fires a
uevent that depends on the name. At the point of firing the uevent, the
name would be freed by devres management.

Use devm_kasprintf to simplify the logic for allocating memory and
formatting the input_dev name string.</Note>
    </Notes>
    <CVE>CVE-2023-53454</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: qla4xxx: Add length check when parsing nlattrs

There are three places that qla4xxx parses nlattrs:

 - qla4xxx_set_chap_entry()

 - qla4xxx_iface_set_param()

 - qla4xxx_sysfs_ddb_set_param()

and each of them directly converts the nlattr to specific pointer of
structure without length checking. This could be dangerous as those
attributes are not validated and a malformed nlattr (e.g., length 0) could
result in an OOB read that leaks heap dirty data.

Add the nla_len check before accessing the nlattr data and return EINVAL if
the length check fails.</Note>
    </Notes>
    <CVE>CVE-2023-53456</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix null-ptr-deref Read in txBegin

 Syzkaller reported an issue where txBegin may be called
 on a superblock in a read-only mounted filesystem which leads
 to NULL pointer deref. This could be solved by checking if
 the filesystem is read-only before calling txBegin, and returning
 with appropiate error code.</Note>
    </Notes>
    <CVE>CVE-2023-53457</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: wait interruptibly for request completions on exit

WHen the ring exits, cleanup is done and the final cancelation and
waiting on completions is done by io_ring_exit_work. That function is
invoked by kworker, which doesn't take any signals. Because of that, it
doesn't really matter if we wait for completions in TASK_INTERRUPTIBLE
or TASK_UNINTERRUPTIBLE state. However, it does matter to the hung task
detection checker!

Normally we expect cancelations and completions to happen rather
quickly. Some test cases, however, will exit the ring and park the
owning task stopped (eg via SIGSTOP). If the owning task needs to run
task_work to complete requests, then io_ring_exit_work won't make any
progress until the task is runnable again. Hence io_ring_exit_work can
trigger the hung task detection, which is particularly problematic if
panic-on-hung-task is enabled.

As the ring exit doesn't take signals to begin with, have it wait
interruptibly rather than uninterruptibly. io_uring has a separate
stuck-exit warning that triggers independently anyway, so we're not
really missing anything by making this switch.</Note>
    </Notes>
    <CVE>CVE-2023-53461</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hsr: Fix uninit-value access in fill_frame_info()

Syzbot reports the following uninit-value access problem.

=====================================================
BUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:601 [inline]
BUG: KMSAN: uninit-value in hsr_forward_skb+0x9bd/0x30f0 net/hsr/hsr_forward.c:616
 fill_frame_info net/hsr/hsr_forward.c:601 [inline]
 hsr_forward_skb+0x9bd/0x30f0 net/hsr/hsr_forward.c:616
 hsr_dev_xmit+0x192/0x330 net/hsr/hsr_device.c:223
 __netdev_start_xmit include/linux/netdevice.h:4889 [inline]
 netdev_start_xmit include/linux/netdevice.h:4903 [inline]
 xmit_one net/core/dev.c:3544 [inline]
 dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3560
 __dev_queue_xmit+0x34d0/0x52a0 net/core/dev.c:4340
 dev_queue_xmit include/linux/netdevice.h:3082 [inline]
 packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276
 packet_snd net/packet/af_packet.c:3087 [inline]
 packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119
 sock_sendmsg_nosec net/socket.c:730 [inline]
 sock_sendmsg net/socket.c:753 [inline]
 __sys_sendto+0x781/0xa30 net/socket.c:2176
 __do_sys_sendto net/socket.c:2188 [inline]
 __se_sys_sendto net/socket.c:2184 [inline]
 __ia32_sys_sendto+0x11f/0x1c0 net/socket.c:2184
 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]
 __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178
 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203
 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246
 entry_SYSENTER_compat_after_hwframe+0x70/0x82

Uninit was created at:
 slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767
 slab_alloc_node mm/slub.c:3478 [inline]
 kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523
 kmalloc_reserve+0x148/0x470 net/core/skbuff.c:559
 __alloc_skb+0x318/0x740 net/core/skbuff.c:644
 alloc_skb include/linux/skbuff.h:1286 [inline]
 alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6299
 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2794
 packet_alloc_skb net/packet/af_packet.c:2936 [inline]
 packet_snd net/packet/af_packet.c:3030 [inline]
 packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119
 sock_sendmsg_nosec net/socket.c:730 [inline]
 sock_sendmsg net/socket.c:753 [inline]
 __sys_sendto+0x781/0xa30 net/socket.c:2176
 __do_sys_sendto net/socket.c:2188 [inline]
 __se_sys_sendto net/socket.c:2184 [inline]
 __ia32_sys_sendto+0x11f/0x1c0 net/socket.c:2184
 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]
 __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178
 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203
 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246
 entry_SYSENTER_compat_after_hwframe+0x70/0x82

It is because VLAN not yet supported in hsr driver. Return error
when protocol is ETH_P_8021Q in fill_frame_info() now to fix it.</Note>
    </Notes>
    <CVE>CVE-2023-53462</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ibmvnic: Do not reset dql stats on NON_FATAL err

All ibmvnic resets, make a call to netdev_tx_reset_queue() when
re-opening the device. netdev_tx_reset_queue() resets the num_queued
and num_completed byte counters. These stats are used in Byte Queue
Limit (BQL) algorithms. The difference between these two stats tracks
the number of bytes currently sitting on the physical NIC. ibmvnic
increases the number of queued bytes though calls to
netdev_tx_sent_queue() in the drivers xmit function. When, VIOS reports
that it is done transmitting bytes, the ibmvnic device increases the
number of completed bytes through calls to netdev_tx_completed_queue().
It is important to note that the driver batches its transmit calls and
num_queued is increased every time that an skb is added to the next
batch, not necessarily when the batch is sent to VIOS for transmission.

Unlike other reset types, a NON FATAL reset will not flush the sub crq
tx buffers. Therefore, it is possible for the batched skb array to be
partially full. So if there is call to netdev_tx_reset_queue() when
re-opening the device, the value of num_queued (0) would not account
for the skb's that are currently batched. Eventually, when the batch
is sent to VIOS, the call to netdev_tx_completed_queue() would increase
num_completed to a value greater than the num_queued. This causes a
BUG_ON crash:

ibmvnic 30000002: Firmware reports error, cause: adapter problem.
Starting recovery...
ibmvnic 30000002: tx error 600
ibmvnic 30000002: tx error 600
ibmvnic 30000002: tx error 600
ibmvnic 30000002: tx error 600
------------[ cut here ]------------
kernel BUG at lib/dynamic_queue_limits.c:27!
Oops: Exception in kernel mode, sig: 5
[....]
NIP dql_completed+0x28/0x1c0
LR ibmvnic_complete_tx.isra.0+0x23c/0x420 [ibmvnic]
Call Trace:
ibmvnic_complete_tx.isra.0+0x3f8/0x420 [ibmvnic] (unreliable)
ibmvnic_interrupt_tx+0x40/0x70 [ibmvnic]
__handle_irq_event_percpu+0x98/0x270
---[ end trace ]---

Therefore, do not reset the dql stats when performing a NON_FATAL reset.</Note>
    </Notes>
    <CVE>CVE-2023-53463</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

soundwire: qcom: fix storing port config out-of-bounds

The 'qcom_swrm_ctrl-&gt;pconfig' has size of QCOM_SDW_MAX_PORTS (14),
however we index it starting from 1, not 0, to match real port numbers.
This can lead to writing port config past 'pconfig' bounds and
overwriting next member of 'qcom_swrm_ctrl' struct.  Reported also by
smatch:

  drivers/soundwire/qcom.c:1269 qcom_swrm_get_port_config() error: buffer overflow 'ctrl-&gt;pconfig' 14 &lt;= 14</Note>
    </Notes>
    <CVE>CVE-2023-53465</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: lpc32xx: Remove handling of PWM channels

Because LPC32xx PWM controllers have only a single output which is
registered as the only PWM device/channel per controller, it is known in
advance that pwm-&gt;hwpwm value is always 0. On basis of this fact
simplify the code by removing operations with pwm-&gt;hwpwm, there is no
controls which require channel number as input.

Even though I wasn't aware at the time when I forward ported that patch,
this fixes a null pointer dereference as lpc32xx-&gt;chip.pwms is NULL
before devm_pwmchip_add() is called.</Note>
    </Notes>
    <CVE>CVE-2023-53472</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/acpi: Fix a use-after-free in cxl_parse_cfmws()

KASAN and KFENCE detected an user-after-free in the CXL driver. This
happens in the cxl_decoder_add() fail path. KASAN prints the following
error:

   BUG: KASAN: slab-use-after-free in cxl_parse_cfmws (drivers/cxl/acpi.c:299)

This happens in cxl_parse_cfmws(), where put_device() is called,
releasing cxld, which is accessed later.

Use the local variables in the dev_err() instead of pointing to the
released memory. Since the dev_err() is printing a resource, change the open
coded print format to use the %pr format specifier.</Note>
    </Notes>
    <CVE>CVE-2023-53479</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

kobject: Add sanity check for kset-&gt;kobj.ktype in kset_register()

When I register a kset in the following way:
	static struct kset my_kset;
	kobject_set_name(&amp;my_kset.kobj, "my_kset");
        ret = kset_register(&amp;my_kset);

A null pointer dereference exception is occurred:
[ 4453.568337] Unable to handle kernel NULL pointer dereference at \
virtual address 0000000000000028
... ...
[ 4453.810361] Call trace:
[ 4453.813062]  kobject_get_ownership+0xc/0x34
[ 4453.817493]  kobject_add_internal+0x98/0x274
[ 4453.822005]  kset_register+0x5c/0xb4
[ 4453.825820]  my_kobj_init+0x44/0x1000 [my_kset]
... ...

Because I didn't initialize my_kset.kobj.ktype.

According to the description in Documentation/core-api/kobject.rst:
 - A ktype is the type of object that embeds a kobject.  Every structure
   that embeds a kobject needs a corresponding ktype.

So add sanity check to make sure kset-&gt;kobj.ktype is not NULL.</Note>
    </Notes>
    <CVE>CVE-2023-53480</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix UBSAN: array-index-out-of-bounds in dbAllocDmapLev

Syzkaller reported the following issue:

UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:1965:6
index -84 is out of range for type 's8[341]' (aka 'signed char[341]')
CPU: 1 PID: 4995 Comm: syz-executor146 Not tainted 6.4.0-rc6-syzkaller-00037-gb6dad5178cea #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
 ubsan_epilogue lib/ubsan.c:217 [inline]
 __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348
 dbAllocDmapLev+0x3e5/0x430 fs/jfs/jfs_dmap.c:1965
 dbAllocCtl+0x113/0x920 fs/jfs/jfs_dmap.c:1809
 dbAllocAG+0x28f/0x10b0 fs/jfs/jfs_dmap.c:1350
 dbAlloc+0x658/0xca0 fs/jfs/jfs_dmap.c:874
 dtSplitUp fs/jfs/jfs_dtree.c:974 [inline]
 dtInsert+0xda7/0x6b00 fs/jfs/jfs_dtree.c:863
 jfs_create+0x7b6/0xbb0 fs/jfs/namei.c:137
 lookup_open fs/namei.c:3492 [inline]
 open_last_lookups fs/namei.c:3560 [inline]
 path_openat+0x13df/0x3170 fs/namei.c:3788
 do_filp_open+0x234/0x490 fs/namei.c:3818
 do_sys_openat2+0x13f/0x500 fs/open.c:1356
 do_sys_open fs/open.c:1372 [inline]
 __do_sys_openat fs/open.c:1388 [inline]
 __se_sys_openat fs/open.c:1383 [inline]
 __x64_sys_openat+0x247/0x290 fs/open.c:1383
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f1f4e33f7e9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 14 00 00 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 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffc21129578 EFLAGS: 00000246 ORIG_RAX: 0000000000000101
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1f4e33f7e9
RDX: 000000000000275a RSI: 0000000020000040 RDI: 00000000ffffff9c
RBP: 00007f1f4e2ff080 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f1f4e2ff110
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
 &lt;/TASK&gt;

The bug occurs when the dbAllocDmapLev()function attempts to access
dp-&gt;tree.stree[leafidx + LEAFIND] while the leafidx value is negative.

To rectify this, the patch introduces a safeguard within the
dbAllocDmapLev() function. A check has been added to verify if leafidx is
negative. If it is, the function immediately returns an I/O error, preventing
any further execution that could potentially cause harm.

Tested via syzbot.</Note>
    </Notes>
    <CVE>CVE-2023-53485</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/rtas_flash: allow user copy to flash block cache objects

With hardened usercopy enabled (CONFIG_HARDENED_USERCOPY=y), using the
/proc/powerpc/rtas/firmware_update interface to prepare a system
firmware update yields a BUG():

  kernel BUG at mm/usercopy.c:102!
  Oops: Exception in kernel mode, sig: 5 [#1]
  LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
  Modules linked in:
  CPU: 0 PID: 2232 Comm: dd Not tainted 6.5.0-rc3+ #2
  Hardware name: IBM,8408-E8E POWER8E (raw) 0x4b0201 0xf000004 of:IBM,FW860.50 (SV860_146) hv:phyp pSeries
  NIP:  c0000000005991d0 LR: c0000000005991cc CTR: 0000000000000000
  REGS: c0000000148c76a0 TRAP: 0700   Not tainted  (6.5.0-rc3+)
  MSR:  8000000000029033 &lt;SF,EE,ME,IR,DR,RI,LE&gt;  CR: 24002242  XER: 0000000c
  CFAR: c0000000001fbd34 IRQMASK: 0
  [ ... GPRs omitted ... ]
  NIP usercopy_abort+0xa0/0xb0
  LR  usercopy_abort+0x9c/0xb0
  Call Trace:
    usercopy_abort+0x9c/0xb0 (unreliable)
    __check_heap_object+0x1b4/0x1d0
    __check_object_size+0x2d0/0x380
    rtas_flash_write+0xe4/0x250
    proc_reg_write+0xfc/0x160
    vfs_write+0xfc/0x4e0
    ksys_write+0x90/0x160
    system_call_exception+0x178/0x320
    system_call_common+0x160/0x2c4

The blocks of the firmware image are copied directly from user memory
to objects allocated from flash_block_cache, so flash_block_cache must
be created using kmem_cache_create_usercopy() to mark it safe for user
access.

[mpe: Trim and indent oops]</Note>
    </Notes>
    <CVE>CVE-2023-53487</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/hfi1: Fix possible panic during hotplug remove

During hotplug remove it is possible that the update counters work
might be pending, and may run after memory has been freed.
Cancel the update counters work before freeing memory.</Note>
    </Notes>
    <CVE>CVE-2023-53488</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 disconnect vs accept race

Despite commit 0ad529d9fd2b ("mptcp: fix possible divide by zero in
recvmsg()"), the mptcp protocol is still prone to a race between
disconnect() (or shutdown) and accept.

The root cause is that the mentioned commit checks the msk-level
flag, but mptcp_stream_accept() does acquire the msk-level lock,
as it can rely directly on the first subflow lock.

As reported by Christoph than can lead to a race where an msk
socket is accepted after that mptcp_subflow_queue_clean() releases
the listener socket lock and just before it takes destructive
actions leading to the following splat:

BUG: kernel NULL pointer dereference, address: 0000000000000012
PGD 5a4ca067 P4D 5a4ca067 PUD 37d4c067 PMD 0
Oops: 0000 [#1] PREEMPT SMP
CPU: 2 PID: 10955 Comm: syz-executor.5 Not tainted 6.5.0-rc1-gdc7b257ee5dd #37
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
RIP: 0010:mptcp_stream_accept+0x1ee/0x2f0 include/net/inet_sock.h:330
Code: 0a 09 00 48 8b 1b 4c 39 e3 74 07 e8 bc 7c 7f fe eb a1 e8 b5 7c 7f fe 4c 8b 6c 24 08 eb 05 e8 a9 7c 7f fe 49 8b 85 d8 09 00 00 &lt;0f&gt; b6 40 12 88 44 24 07 0f b6 6c 24 07 bf 07 00 00 00 89 ee e8 89
RSP: 0018:ffffc90000d07dc0 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffff888037e8d020 RCX: ffff88803b093300
RDX: 0000000000000000 RSI: ffffffff833822c5 RDI: ffffffff8333896a
RBP: 0000607f82031520 R08: ffff88803b093300 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000003e83 R12: ffff888037e8d020
R13: ffff888037e8c680 R14: ffff888009af7900 R15: ffff888009af6880
FS:  00007fc26d708640(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000012 CR3: 0000000066bc5001 CR4: 0000000000370ee0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
 do_accept+0x1ae/0x260 net/socket.c:1872
 __sys_accept4+0x9b/0x110 net/socket.c:1913
 __do_sys_accept4 net/socket.c:1954 [inline]
 __se_sys_accept4 net/socket.c:1951 [inline]
 __x64_sys_accept4+0x20/0x30 net/socket.c:1951
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x47/0xa0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x6e/0xd8

Address the issue by temporary removing the pending request socket
from the accept queue, so that racing accept() can't touch them.

After depleting the msk - the ssk still exists, as plain TCP sockets,
re-insert them into the accept queue, so that later inet_csk_listen_stop()
will complete the tcp socket disposal.</Note>
    </Notes>
    <CVE>CVE-2023-53490</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

start_kernel: Add __no_stack_protector function attribute

Back during the discussion of
commit a9a3ed1eff36 ("x86: Fix early boot crash on gcc-10, third try")
we discussed the need for a function attribute to control the omission
of stack protectors on a per-function basis; at the time Clang had
support for no_stack_protector but GCC did not. This was fixed in
gcc-11. Now that the function attribute is available, let's start using
it.

Callers of boot_init_stack_canary need to use this function attribute
unless they're compiled with -fno-stack-protector, otherwise the canary
stored in the stack slot of the caller will differ upon the call to
boot_init_stack_canary. This will lead to a call to __stack_chk_fail()
then panic.</Note>
    </Notes>
    <CVE>CVE-2023-53491</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/qaic: tighten bounds checking in decode_message()

Copy the bounds checking from encode_message() to decode_message().

This patch addresses the following concerns.  Ensure that there is
enough space for at least one header so that we don't have a negative
size later.

	if (msg_hdr_len &lt; sizeof(*trans_hdr))

Ensure that we have enough space to read the next header from the
msg-&gt;data.

	if (msg_len &gt; msg_hdr_len - sizeof(*trans_hdr))
		return -EINVAL;

Check that the trans_hdr-&gt;len is not below the minimum size:

	if (hdr_len &lt; sizeof(*trans_hdr))

This minimum check ensures that we don't corrupt memory in
decode_passthrough() when we do.

	memcpy(out_trans-&gt;data, in_trans-&gt;data, len - sizeof(in_trans-&gt;hdr));

And finally, use size_add() to prevent an integer overflow:

	if (size_add(msg_len, hdr_len) &gt; msg_hdr_len)</Note>
    </Notes>
    <CVE>CVE-2023-53493</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: mvpp2_main: fix possible OOB write in mvpp2_ethtool_get_rxnfc()

rules is allocated in ethtool_get_rxnfc and the size is determined by
rule_cnt from user space. So rule_cnt needs to be check before using
rules to avoid OOB writing or NULL pointer dereference.</Note>
    </Notes>
    <CVE>CVE-2023-53495</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/platform/uv: Use alternate source for socket to node data

The UV code attempts to build a set of tables to allow it to do
bidirectional socket&lt;=&gt;node lookups.

But when nr_cpus is set to a smaller number than actually present, the
cpu_to_node() mapping information for unused CPUs is not available to
build_socket_tables(). This results in skipping some nodes or sockets
when creating the tables and leaving some -1's for later code to trip.
over, causing oopses.

The problem is that the socket&lt;=&gt;node lookups are created by doing a
loop over all CPUs, then looking up the CPU's APICID and socket. But
if a CPU is not present, there is no way to start this lookup.

Instead of looping over all CPUs, take CPUs out of the equation
entirely. Loop over all APICIDs which are mapped to a valid NUMA node.
Then just extract the socket-id from the APICID.

This avoid tripping over disabled CPUs.</Note>
    </Notes>
    <CVE>CVE-2023-53496</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix slab-use-after-free in decode_session6

When the xfrm device is set to the qdisc of the sfb type, the cb field
of the sent skb may be modified during enqueuing. Then,
slab-use-after-free may occur when the xfrm device sends IPv6 packets.

The stack information is as follows:
BUG: KASAN: slab-use-after-free in decode_session6+0x103f/0x1890
Read of size 1 at addr ffff8881111458ef by task swapper/3/0
CPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.4.0-next-20230707 #409
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014
Call Trace:
&lt;IRQ&gt;
dump_stack_lvl+0xd9/0x150
print_address_description.constprop.0+0x2c/0x3c0
kasan_report+0x11d/0x130
decode_session6+0x103f/0x1890
__xfrm_decode_session+0x54/0xb0
xfrmi_xmit+0x173/0x1ca0
dev_hard_start_xmit+0x187/0x700
sch_direct_xmit+0x1a3/0xc30
__qdisc_run+0x510/0x17a0
__dev_queue_xmit+0x2215/0x3b10
neigh_connected_output+0x3c2/0x550
ip6_finish_output2+0x55a/0x1550
ip6_finish_output+0x6b9/0x1270
ip6_output+0x1f1/0x540
ndisc_send_skb+0xa63/0x1890
ndisc_send_rs+0x132/0x6f0
addrconf_rs_timer+0x3f1/0x870
call_timer_fn+0x1a0/0x580
expire_timers+0x29b/0x4b0
run_timer_softirq+0x326/0x910
__do_softirq+0x1d4/0x905
irq_exit_rcu+0xb7/0x120
sysvec_apic_timer_interrupt+0x97/0xc0
&lt;/IRQ&gt;
&lt;TASK&gt;
asm_sysvec_apic_timer_interrupt+0x1a/0x20
RIP: 0010:intel_idle_hlt+0x23/0x30
Code: 1f 84 00 00 00 00 00 f3 0f 1e fa 41 54 41 89 d4 0f 1f 44 00 00 66 90 0f 1f 44 00 00 0f 00 2d c4 9f ab 00 0f 1f 44 00 00 fb f4 &lt;fa&gt; 44 89 e0 41 5c c3 66 0f 1f 44 00 00 f3 0f 1e fa 41 54 41 89 d4
RSP: 0018:ffffc90000197d78 EFLAGS: 00000246
RAX: 00000000000a83c3 RBX: ffffe8ffffd09c50 RCX: ffffffff8a22d8e5
RDX: 0000000000000001 RSI: ffffffff8d3f8080 RDI: ffffe8ffffd09c50
RBP: ffffffff8d3f8080 R08: 0000000000000001 R09: ffffed1026ba6d9d
R10: ffff888135d36ceb R11: 0000000000000001 R12: 0000000000000001
R13: ffffffff8d3f8100 R14: 0000000000000001 R15: 0000000000000000
cpuidle_enter_state+0xd3/0x6f0
cpuidle_enter+0x4e/0xa0
do_idle+0x2fe/0x3c0
cpu_startup_entry+0x18/0x20
start_secondary+0x200/0x290
secondary_startup_64_no_verify+0x167/0x16b
&lt;/TASK&gt;
Allocated by task 939:
kasan_save_stack+0x22/0x40
kasan_set_track+0x25/0x30
__kasan_slab_alloc+0x7f/0x90
kmem_cache_alloc_node+0x1cd/0x410
kmalloc_reserve+0x165/0x270
__alloc_skb+0x129/0x330
inet6_ifa_notify+0x118/0x230
__ipv6_ifa_notify+0x177/0xbe0
addrconf_dad_completed+0x133/0xe00
addrconf_dad_work+0x764/0x1390
process_one_work+0xa32/0x16f0
worker_thread+0x67d/0x10c0
kthread+0x344/0x440
ret_from_fork+0x1f/0x30
The buggy address belongs to the object at ffff888111145800
which belongs to the cache skbuff_small_head of size 640
The buggy address is located 239 bytes inside of
freed 640-byte region [ffff888111145800, ffff888111145a80)

As commit f855691975bb ("xfrm6: Fix the nexthdr offset in
_decode_session6.") showed, xfrm_decode_session was originally intended
only for the receive path. IP6CB(skb)-&gt;nhoff is not set during
transmission. Therefore, set the cb field in the skb to 0 before
sending packets.</Note>
    </Notes>
    <CVE>CVE-2023-53500</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/iommu_v2: Fix pasid_state refcount dec hit 0 warning on pasid unbind

When unbinding pasid - a race condition exists vs outstanding page faults.

To prevent this, the pasid_state object contains a refcount.
    * set to 1 on pasid bind
    * incremented on each ppr notification start
    * decremented on each ppr notification done
    * decremented on pasid unbind

Since refcount_dec assumes that refcount will never reach 0:
  the current implementation causes the following to be invoked on
  pasid unbind:
        REFCOUNT_WARN("decrement hit 0; leaking memory")

Fix this issue by changing refcount_dec to refcount_dec_and_test
to explicitly handle refcount=1.</Note>
    </Notes>
    <CVE>CVE-2023-53501</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Properly order ib_device_unalloc() to avoid UAF

ib_dealloc_device() should be called only after device cleanup.  Fix the
dealloc sequence.</Note>
    </Notes>
    <CVE>CVE-2023-53504</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

clk: tegra: tegra124-emc: Fix potential memory leak

The tegra and tegra needs to be freed in the error handling path, otherwise
it will be leaked.</Note>
    </Notes>
    <CVE>CVE-2023-53505</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/mlx5: Unregister devlink params in case interface is down

Currently, in case an interface is down, mlx5 driver doesn't
unregister its devlink params, which leads to this WARN[1].
Fix it by unregistering devlink params in that case as well.

[1]
[  295.244769 ] WARNING: CPU: 15 PID: 1 at net/core/devlink.c:9042 devlink_free+0x174/0x1fc
[  295.488379 ] CPU: 15 PID: 1 Comm: shutdown Tainted: G S         OE 5.15.0-1017.19.3.g0677e61-bluefield #g0677e61
[  295.509330 ] Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS 4.2.0.12761 Jun  6 2023
[  295.543096 ] pc : devlink_free+0x174/0x1fc
[  295.551104 ] lr : mlx5_devlink_free+0x18/0x2c [mlx5_core]
[  295.561816 ] sp : ffff80000809b850
[  295.711155 ] Call trace:
[  295.716030 ]  devlink_free+0x174/0x1fc
[  295.723346 ]  mlx5_devlink_free+0x18/0x2c [mlx5_core]
[  295.733351 ]  mlx5_sf_dev_remove+0x98/0xb0 [mlx5_core]
[  295.743534 ]  auxiliary_bus_remove+0x2c/0x50
[  295.751893 ]  __device_release_driver+0x19c/0x280
[  295.761120 ]  device_release_driver+0x34/0x50
[  295.769649 ]  bus_remove_device+0xdc/0x170
[  295.777656 ]  device_del+0x17c/0x3a4
[  295.784620 ]  mlx5_sf_dev_remove+0x28/0xf0 [mlx5_core]
[  295.794800 ]  mlx5_sf_dev_table_destroy+0x98/0x110 [mlx5_core]
[  295.806375 ]  mlx5_unload+0x34/0xd0 [mlx5_core]
[  295.815339 ]  mlx5_unload_one+0x70/0xe4 [mlx5_core]
[  295.824998 ]  shutdown+0xb0/0xd8 [mlx5_core]
[  295.833439 ]  pci_device_shutdown+0x3c/0xa0
[  295.841651 ]  device_shutdown+0x170/0x340
[  295.849486 ]  __do_sys_reboot+0x1f4/0x2a0
[  295.857322 ]  __arm64_sys_reboot+0x2c/0x40
[  295.865329 ]  invoke_syscall+0x78/0x100
[  295.872817 ]  el0_svc_common.constprop.0+0x54/0x184
[  295.882392 ]  do_el0_svc+0x30/0xac
[  295.889008 ]  el0_svc+0x48/0x160
[  295.895278 ]  el0t_64_sync_handler+0xa4/0x130
[  295.903807 ]  el0t_64_sync+0x1a4/0x1a8
[  295.911120 ] ---[ end trace 4f1d2381d00d9dce  ]---</Note>
    </Notes>
    <CVE>CVE-2023-53507</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:

ublk: fail to start device if queue setup is interrupted

In ublk_ctrl_start_dev(), if wait_for_completion_interruptible() is
interrupted by signal, queues aren't setup successfully yet, so we
have to fail UBLK_CMD_START_DEV, otherwise kernel oops can be triggered.

Reported by German when working on qemu-storage-deamon which requires
single thread ublk daemon.</Note>
    </Notes>
    <CVE>CVE-2023-53508</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ufs: core: Fix handling of lrbp-&gt;cmd

ufshcd_queuecommand() may be called two times in a row for a SCSI command
before it is completed. Hence make the following changes:

 - In the functions that submit a command, do not check the old value of
   lrbp-&gt;cmd nor clear lrbp-&gt;cmd in error paths.

 - In ufshcd_release_scsi_cmd(), do not clear lrbp-&gt;cmd.

See also scsi_send_eh_cmnd().

This commit prevents that the following appears if a command times out:

WARNING: at drivers/ufs/core/ufshcd.c:2965 ufshcd_queuecommand+0x6f8/0x9a8
Call trace:
 ufshcd_queuecommand+0x6f8/0x9a8
 scsi_send_eh_cmnd+0x2c0/0x960
 scsi_eh_test_devices+0x100/0x314
 scsi_eh_ready_devs+0xd90/0x114c
 scsi_error_handler+0x2b4/0xb70
 kthread+0x16c/0x1e0</Note>
    </Notes>
    <CVE>CVE-2023-53510</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-mmio: don't break lifecycle of vm_dev

vm_dev has a separate lifecycle because it has a 'struct device'
embedded. Thus, having a release callback for it is correct.

Allocating the vm_dev struct with devres totally breaks this protection,
though. Instead of waiting for the vm_dev release callback, the memory
is freed when the platform_device is removed. Resulting in a
use-after-free when finally the callback is to be called.

To easily see the problem, compile the kernel with
CONFIG_DEBUG_KOBJECT_RELEASE and unbind with sysfs.

The fix is easy, don't use devres in this case.

Found during my research about object lifetime problems.</Note>
    </Notes>
    <CVE>CVE-2023-53515</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

macvlan: add forgotten nla_policy for IFLA_MACVLAN_BC_CUTOFF

The previous commit 954d1fa1ac93 ("macvlan: Add netlink attribute for
broadcast cutoff") added one additional attribute named
IFLA_MACVLAN_BC_CUTOFF to allow broadcast cutfoff.

However, it forgot to describe the nla_policy at macvlan_policy
(drivers/net/macvlan.c). Hence, this suppose NLA_S32 (4 bytes) integer
can be faked as empty (0 bytes) by a malicious user, which could leads
to OOB in heap just like CVE-2023-3773.

To fix it, this commit just completes the nla_policy description for
IFLA_MACVLAN_BC_CUTOFF. This enforces the length check and avoids the
potential OOB read.</Note>
    </Notes>
    <CVE>CVE-2023-53516</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 / devfreq: Fix leak in devfreq_dev_release()

srcu_init_notifier_head() allocates resources that need to be released
with a srcu_cleanup_notifier_head() call.

Reported by kmemleak.</Note>
    </Notes>
    <CVE>CVE-2023-53518</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:

media: v4l2-mem2mem: add lock to protect parameter num_rdy

Getting below error when using KCSAN to check the driver. Adding lock to
protect parameter num_rdy when getting the value with function:
v4l2_m2m_num_src_bufs_ready/v4l2_m2m_num_dst_bufs_ready.

kworker/u16:3: [name:report&amp;]BUG: KCSAN: data-race in v4l2_m2m_buf_queue
kworker/u16:3: [name:report&amp;]

kworker/u16:3: [name:report&amp;]read-write to 0xffffff8105f35b94 of 1 bytes by task 20865 on cpu 7:
kworker/u16:3:   v4l2_m2m_buf_queue+0xd8/0x10c</Note>
    </Notes>
    <CVE>CVE-2023-53519</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 hci_suspend_sync crash

If hci_unregister_dev() frees the hci_dev object but hci_suspend_notifier
may still be accessing it, it can cause the program to crash.
Here's the call trace:
  &lt;4&gt;[102152.653246] Call Trace:
  &lt;4&gt;[102152.653254]  hci_suspend_sync+0x109/0x301 [bluetooth]
  &lt;4&gt;[102152.653259]  hci_suspend_dev+0x78/0xcd [bluetooth]
  &lt;4&gt;[102152.653263]  hci_suspend_notifier+0x42/0x7a [bluetooth]
  &lt;4&gt;[102152.653268]  notifier_call_chain+0x43/0x6b
  &lt;4&gt;[102152.653271]  __blocking_notifier_call_chain+0x48/0x69
  &lt;4&gt;[102152.653273]  __pm_notifier_call_chain+0x22/0x39
  &lt;4&gt;[102152.653276]  pm_suspend+0x287/0x57c
  &lt;4&gt;[102152.653278]  state_store+0xae/0xe5
  &lt;4&gt;[102152.653281]  kernfs_fop_write+0x109/0x173
  &lt;4&gt;[102152.653284]  __vfs_write+0x16f/0x1a2
  &lt;4&gt;[102152.653287]  ? selinux_file_permission+0xca/0x16f
  &lt;4&gt;[102152.653289]  ? security_file_permission+0x36/0x109
  &lt;4&gt;[102152.653291]  vfs_write+0x114/0x21d
  &lt;4&gt;[102152.653293]  __x64_sys_write+0x7b/0xdb
  &lt;4&gt;[102152.653296]  do_syscall_64+0x59/0x194
  &lt;4&gt;[102152.653299]  entry_SYSCALL_64_after_hwframe+0x5c/0xc1

This patch holds the reference count of the hci_dev object while
processing it in hci_suspend_notifier to avoid potential crash
caused by the race condition.</Note>
    </Notes>
    <CVE>CVE-2023-53520</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: gs_usb: fix time stamp counter initialization

If the gs_usb device driver is unloaded (or unbound) before the
interface is shut down, the USB stack first calls the struct
usb_driver::disconnect and then the struct net_device_ops::ndo_stop
callback.

In gs_usb_disconnect() all pending bulk URBs are killed, i.e. no more
RX'ed CAN frames are send from the USB device to the host. Later in
gs_can_close() a reset control message is send to each CAN channel to
remove the controller from the CAN bus. In this race window the USB
device can still receive CAN frames from the bus and internally queue
them to be send to the host.

At least in the current version of the candlelight firmware, the queue
of received CAN frames is not emptied during the reset command. After
loading (or binding) the gs_usb driver, new URBs are submitted during
the struct net_device_ops::ndo_open callback and the candlelight
firmware starts sending its already queued CAN frames to the host.

However, this scenario was not considered when implementing the
hardware timestamp function. The cycle counter/time counter
infrastructure is set up (gs_usb_timestamp_init()) after the USBs are
submitted, resulting in a NULL pointer dereference if
timecounter_cyc2time() (via the call chain:
gs_usb_receive_bulk_callback() -&gt; gs_usb_set_timestamp() -&gt;
gs_usb_skb_set_timestamp()) is called too early.

Move the gs_usb_timestamp_init() function before the URBs are
submitted to fix this problem.

For a comprehensive solution, we need to consider gs_usb devices with
more than 1 channel. The cycle counter/time counter infrastructure is
setup per channel, but the RX URBs are per device. Once gs_can_open()
of _a_ channel has been called, and URBs have been submitted, the
gs_usb_receive_bulk_callback() can be called for _all_ available
channels, even for channels that are not running, yet. As cycle
counter/time counter has not set up, this will again lead to a NULL
pointer dereference.

Convert the cycle counter/time counter from a "per channel" to a "per
device" functionality. Also set it up, before submitting any URBs to
the device.

Further in gs_usb_receive_bulk_callback(), don't process any URBs for
not started CAN channels, only resubmit the URB.</Note>
    </Notes>
    <CVE>CVE-2023-53523</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: check 'jh-&gt;b_transaction' before removing it from checkpoint

Following process will corrupt ext4 image:
Step 1:
jbd2_journal_commit_transaction
 __jbd2_journal_insert_checkpoint(jh, commit_transaction)
 // Put jh into trans1-&gt;t_checkpoint_list
 journal-&gt;j_checkpoint_transactions = commit_transaction
 // Put trans1 into journal-&gt;j_checkpoint_transactions

Step 2:
do_get_write_access
 test_clear_buffer_dirty(bh) // clear buffer dirty，set jbd dirty
 __jbd2_journal_file_buffer(jh, transaction) // jh belongs to trans2

Step 3:
drop_cache
 journal_shrink_one_cp_list
  jbd2_journal_try_remove_checkpoint
   if (!trylock_buffer(bh))  // lock bh, true
   if (buffer_dirty(bh))     // buffer is not dirty
   __jbd2_journal_remove_checkpoint(jh)
   // remove jh from trans1-&gt;t_checkpoint_list

Step 4:
jbd2_log_do_checkpoint
 trans1 = journal-&gt;j_checkpoint_transactions
 // jh is not in trans1-&gt;t_checkpoint_list
 jbd2_cleanup_journal_tail(journal)  // trans1 is done

Step 5: Power cut, trans2 is not committed, jh is lost in next mounting.

Fix it by checking 'jh-&gt;b_transaction' before remove it from checkpoint.</Note>
    </Notes>
    <CVE>CVE-2023-53526</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix memory leak in tb_handle_dp_bandwidth_request()

The memory allocated in tb_queue_dp_bandwidth_request() needs to be
released once the request is handled to avoid leaking it.</Note>
    </Notes>
    <CVE>CVE-2023-53527</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:

RDMA/rxe: Fix unsafe drain work queue code

If create_qp does not fully succeed it is possible for qp cleanup
code to attempt to drain the send or recv work queues before the
queues have been created causing a seg fault. This patch checks
to see if the queues exist before attempting to drain them.</Note>
    </Notes>
    <CVE>CVE-2023-53528</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: qla2xxx: Use raw_smp_processor_id() instead of smp_processor_id()

The following call trace was observed:

localhost kernel: nvme nvme0: NVME-FC{0}: controller connect complete
localhost kernel: BUG: using smp_processor_id() in preemptible [00000000] code: kworker/u129:4/75092
localhost kernel: nvme nvme0: NVME-FC{0}: new ctrl: NQN "nqn.1992-08.com.netapp:sn.b42d198afb4d11ecad6d00a098d6abfa:subsystem.PR_Channel2022_RH84_subsystem_291"
localhost kernel: caller is qla_nvme_post_cmd+0x216/0x1380 [qla2xxx]
localhost kernel: CPU: 6 PID: 75092 Comm: kworker/u129:4 Kdump: loaded Tainted: G    B   W  OE    --------- ---  5.14.0-70.22.1.el9_0.x86_64+debug #1
localhost kernel: Hardware name: HPE ProLiant XL420 Gen10/ProLiant XL420 Gen10, BIOS U39 01/13/2022
localhost kernel: Workqueue: nvme-wq nvme_async_event_work [nvme_core]
localhost kernel: Call Trace:
localhost kernel: dump_stack_lvl+0x57/0x7d
localhost kernel: check_preemption_disabled+0xc8/0xd0
localhost kernel: qla_nvme_post_cmd+0x216/0x1380 [qla2xxx]

Use raw_smp_processor_id() instead of smp_processor_id().

Also use queue_work() across the driver instead of queue_work_on() thus
avoiding usage of smp_processor_id() when CONFIG_DEBUG_PREEMPT is enabled.</Note>
    </Notes>
    <CVE>CVE-2023-53530</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

null_blk: fix poll request timeout handling

When doing io_uring benchmark on /dev/nullb0, it's easy to crash the
kernel if poll requests timeout triggered, as reported by David. [1]

BUG: kernel NULL pointer dereference, address: 0000000000000008
Workqueue: kblockd blk_mq_timeout_work
RIP: 0010:null_timeout_rq+0x4e/0x91
Call Trace:
 ? null_timeout_rq+0x4e/0x91
 blk_mq_handle_expired+0x31/0x4b
 bt_iter+0x68/0x84
 ? bt_tags_iter+0x81/0x81
 __sbitmap_for_each_set.constprop.0+0xb0/0xf2
 ? __blk_mq_complete_request_remote+0xf/0xf
 bt_for_each+0x46/0x64
 ? __blk_mq_complete_request_remote+0xf/0xf
 ? percpu_ref_get_many+0xc/0x2a
 blk_mq_queue_tag_busy_iter+0x14d/0x18e
 blk_mq_timeout_work+0x95/0x127
 process_one_work+0x185/0x263
 worker_thread+0x1b5/0x227

This is indeed a race problem between null_timeout_rq() and null_poll().

null_poll()				null_timeout_rq()
  spin_lock(&amp;nq-&gt;poll_lock)
  list_splice_init(&amp;nq-&gt;poll_list, &amp;list)
  spin_unlock(&amp;nq-&gt;poll_lock)

  while (!list_empty(&amp;list))
    req = list_first_entry()
    list_del_init()
    ...
    blk_mq_add_to_batch()
    // req-&gt;rq_next = NULL
					spin_lock(&amp;nq-&gt;poll_lock)

					// rq-&gt;queuelist-&gt;next == NULL
					list_del_init(&amp;rq-&gt;queuelist)

					spin_unlock(&amp;nq-&gt;poll_lock)

Fix these problems by setting requests state to MQ_RQ_COMPLETE under
nq-&gt;poll_lock protection, in which null_timeout_rq() can safely detect
this race and early return.

Note this patch just fix the kernel panic when request timeout happen.

[1] https://lore.kernel.org/all/3893581.1691785261@warthog.procyon.org.uk/</Note>
    </Notes>
    <CVE>CVE-2023-53531</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: insert tree mod log move in push_node_left

There is a fairly unlikely race condition in tree mod log rewind that
can result in a kernel panic which has the following trace:

  [530.569] BTRFS critical (device sda3): unable to find logical 0 length 4096
  [530.585] BTRFS critical (device sda3): unable to find logical 0 length 4096
  [530.602] BUG: kernel NULL pointer dereference, address: 0000000000000002
  [530.618] #PF: supervisor read access in kernel mode
  [530.629] #PF: error_code(0x0000) - not-present page
  [530.641] PGD 0 P4D 0
  [530.647] Oops: 0000 [#1] SMP
  [530.654] CPU: 30 PID: 398973 Comm: below Kdump: loaded Tainted: G S         O  K   5.12.0-0_fbk13_clang_7455_gb24de3bdb045 #1
  [530.680] Hardware name: Quanta Mono Lake-M.2 SATA 1HY9U9Z001G/Mono Lake-M.2 SATA, BIOS F20_3A15 08/16/2017
  [530.703] RIP: 0010:__btrfs_map_block+0xaa/0xd00
  [530.755] RSP: 0018:ffffc9002c2f7600 EFLAGS: 00010246
  [530.767] RAX: ffffffffffffffea RBX: ffff888292e41000 RCX: f2702d8b8be15100
  [530.784] RDX: ffff88885fda6fb8 RSI: ffff88885fd973c8 RDI: ffff88885fd973c8
  [530.800] RBP: ffff888292e410d0 R08: ffffffff82fd7fd0 R09: 00000000fffeffff
  [530.816] R10: ffffffff82e57fd0 R11: ffffffff82e57d70 R12: 0000000000000000
  [530.832] R13: 0000000000001000 R14: 0000000000001000 R15: ffffc9002c2f76f0
  [530.848] FS:  00007f38d64af000(0000) GS:ffff88885fd80000(0000) knlGS:0000000000000000
  [530.866] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  [530.880] CR2: 0000000000000002 CR3: 00000002b6770004 CR4: 00000000003706e0
  [530.896] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  [530.912] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
  [530.928] Call Trace:
  [530.934]  ? btrfs_printk+0x13b/0x18c
  [530.943]  ? btrfs_bio_counter_inc_blocked+0x3d/0x130
  [530.955]  btrfs_map_bio+0x75/0x330
  [530.963]  ? kmem_cache_alloc+0x12a/0x2d0
  [530.973]  ? btrfs_submit_metadata_bio+0x63/0x100
  [530.984]  btrfs_submit_metadata_bio+0xa4/0x100
  [530.995]  submit_extent_page+0x30f/0x360
  [531.004]  read_extent_buffer_pages+0x49e/0x6d0
  [531.015]  ? submit_extent_page+0x360/0x360
  [531.025]  btree_read_extent_buffer_pages+0x5f/0x150
  [531.037]  read_tree_block+0x37/0x60
  [531.046]  read_block_for_search+0x18b/0x410
  [531.056]  btrfs_search_old_slot+0x198/0x2f0
  [531.066]  resolve_indirect_ref+0xfe/0x6f0
  [531.076]  ? ulist_alloc+0x31/0x60
  [531.084]  ? kmem_cache_alloc_trace+0x12e/0x2b0
  [531.095]  find_parent_nodes+0x720/0x1830
  [531.105]  ? ulist_alloc+0x10/0x60
  [531.113]  iterate_extent_inodes+0xea/0x370
  [531.123]  ? btrfs_previous_extent_item+0x8f/0x110
  [531.134]  ? btrfs_search_path_in_tree+0x240/0x240
  [531.146]  iterate_inodes_from_logical+0x98/0xd0
  [531.157]  ? btrfs_search_path_in_tree+0x240/0x240
  [531.168]  btrfs_ioctl_logical_to_ino+0xd9/0x180
  [531.179]  btrfs_ioctl+0xe2/0x2eb0

This occurs when logical inode resolution takes a tree mod log sequence
number, and then while backref walking hits a rewind on a busy node
which has the following sequence of tree mod log operations (numbers
filled in from a specific example, but they are somewhat arbitrary)

  REMOVE_WHILE_FREEING slot 532
  REMOVE_WHILE_FREEING slot 531
  REMOVE_WHILE_FREEING slot 530
  ...
  REMOVE_WHILE_FREEING slot 0
  REMOVE slot 455
  REMOVE slot 454
  REMOVE slot 453
  ...
  REMOVE slot 0
  ADD slot 455
  ADD slot 454
  ADD slot 453
  ...
  ADD slot 0
  MOVE src slot 0 -&gt; dst slot 456 nritems 533
  REMOVE slot 455
  REMOVE slot 454
  REMOVE slot 453
  ...
  REMOVE slot 0

When this sequence gets applied via btrfs_tree_mod_log_rewind, it
allocates a fresh rewind eb, and first inserts the correct key info for
the 533 elements, then overwrites the first 456 of them, then decrements
the count by 456 via the add ops, then rewinds the move by doing a
memmove from 456:988-&gt;0:532. We have never written anything past 532,
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-53538</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 incomplete state save in rxe_requester

If a send packet is dropped by the IP layer in rxe_requester()
the call to rxe_xmit_packet() can fail with err == -EAGAIN.
To recover, the state of the wqe is restored to the state before
the packet was sent so it can be resent. However, the routines
that save and restore the state miss a significnt part of the
variable state in the wqe, the dma struct which is used to process
through the sge table. And, the state is not saved before the packet
is built which modifies the dma struct.

Under heavy stress testing with many QPs on a fast node sending
large messages to a slow node dropped packets are observed and
the resent packets are corrupted because the dma struct was not
restored. This patch fixes this behavior and allows the test cases
to succeed.</Note>
    </Notes>
    <CVE>CVE-2023-53539</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: reject auth/assoc to AP with our address

If the AP uses our own address as its MLD address or BSSID, then
clearly something's wrong. Reject such connections so we don't
try and fail later.</Note>
    </Notes>
    <CVE>CVE-2023-53540</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 potential out-of-bounds access in oob write

When the oob buffer length is not in multiple of words, the oob write
function does out-of-bounds read on the oob source buffer at the last
iteration. Fix that by always checking length limit on the oob buffer
read and fill with 0xff when reaching the end of the buffer to the oob
registers.</Note>
    </Notes>
    <CVE>CVE-2023-53541</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vdpa: Add max vqp attr to vdpa_nl_policy for nlattr length check

The vdpa_nl_policy structure is used to validate the nlattr when parsing
the incoming nlmsg. It will ensure the attribute being described produces
a valid nlattr pointer in info-&gt;attrs before entering into each handler
in vdpa_nl_ops.

That is to say, the missing part in vdpa_nl_policy may lead to illegal
nlattr after parsing, which could lead to OOB read just like CVE-2023-3773.

This patch adds the missing nla_policy for vdpa max vqp attr to avoid
such bugs.</Note>
    </Notes>
    <CVE>CVE-2023-53543</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: unmap and remove csa_va properly

Root PD BO should be reserved before unmap and remove
a bo_va from VM otherwise lockdep will complain.

v2: check fpriv-&gt;csa_va is not NULL instead of amdgpu_mcbp (christian)

[14616.936827] WARNING: CPU: 6 PID: 1711 at drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1762 amdgpu_vm_bo_del+0x399/0x3f0 [amdgpu]
[14616.937096] Call Trace:
[14616.937097]  &lt;TASK&gt;
[14616.937102]  amdgpu_driver_postclose_kms+0x249/0x2f0 [amdgpu]
[14616.937187]  drm_file_free+0x1d6/0x300 [drm]
[14616.937207]  drm_close_helper.isra.0+0x62/0x70 [drm]
[14616.937220]  drm_release+0x5e/0x100 [drm]
[14616.937234]  __fput+0x9f/0x280
[14616.937239]  ____fput+0xe/0x20
[14616.937241]  task_work_run+0x61/0x90
[14616.937246]  exit_to_user_mode_prepare+0x215/0x220
[14616.937251]  syscall_exit_to_user_mode+0x2a/0x60
[14616.937254]  do_syscall_64+0x48/0x90
[14616.937257]  entry_SYSCALL_64_after_hwframe+0x63/0xcd</Note>
    </Notes>
    <CVE>CVE-2023-53545</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: DR, fix memory leak in mlx5dr_cmd_create_reformat_ctx

when mlx5_cmd_exec failed in mlx5dr_cmd_create_reformat_ctx, the memory
pointed by 'in' is not released, which will cause memory leak. Move memory
release after mlx5_cmd_exec.</Note>
    </Notes>
    <CVE>CVE-2023-53546</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: usbnet: Fix WARNING in usbnet_start_xmit/usb_submit_urb

The syzbot fuzzer identified a problem in the usbnet driver:

usb 1-1: BOGUS urb xfer, pipe 3 != type 1
WARNING: CPU: 0 PID: 754 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504
Modules linked in:
CPU: 0 PID: 754 Comm: kworker/0:2 Not tainted 6.4.0-rc7-syzkaller-00014-g692b7dc87ca6 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
Workqueue: mld mld_ifc_work
RIP: 0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504
Code: 7c 24 18 e8 2c b4 5b fb 48 8b 7c 24 18 e8 42 07 f0 fe 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 a0 c9 fc 8a e8 5a 6f 23 fb &lt;0f&gt; 0b e9 58 f8 ff ff e8 fe b3 5b fb 48 81 c5 c0 05 00 00 e9 84 f7
RSP: 0018:ffffc9000463f568 EFLAGS: 00010086
RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000
RDX: ffff88801eb28000 RSI: ffffffff814c03b7 RDI: 0000000000000001
RBP: ffff8881443b7190 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000003
R13: ffff88802a77cb18 R14: 0000000000000003 R15: ffff888018262500
FS:  0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000556a99c15a18 CR3: 0000000028c71000 CR4: 0000000000350ef0
Call Trace:
 &lt;TASK&gt;
 usbnet_start_xmit+0xfe5/0x2190 drivers/net/usb/usbnet.c:1453
 __netdev_start_xmit include/linux/netdevice.h:4918 [inline]
 netdev_start_xmit include/linux/netdevice.h:4932 [inline]
 xmit_one net/core/dev.c:3578 [inline]
 dev_hard_start_xmit+0x187/0x700 net/core/dev.c:3594
...

This bug is caused by the fact that usbnet trusts the bulk endpoint
addresses its probe routine receives in the driver_info structure, and
it does not check to see that these endpoints actually exist and have
the expected type and directions.

The fix is simply to add such a check.</Note>
    </Notes>
    <CVE>CVE-2023-53548</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

cpufreq: amd-pstate: fix global sysfs attribute type

In commit 3666062b87ec ("cpufreq: amd-pstate: move to use bus_get_dev_root()")
the "amd_pstate" attributes where moved from a dedicated kobject to the
cpu root kobject.

While the dedicated kobject expects to contain kobj_attributes the root
kobject needs device_attributes.

As the changed arguments are not used by the callbacks it works most of
the time.
However CFI will detect this issue:

[ 4947.849350] CFI failure at dev_attr_show+0x24/0x60 (target: show_status+0x0/0x70; expected type: 0x8651b1de)
...
[ 4947.849409] Call Trace:
[ 4947.849410]  &lt;TASK&gt;
[ 4947.849411]  ? __warn+0xcf/0x1c0
[ 4947.849414]  ? dev_attr_show+0x24/0x60
[ 4947.849415]  ? report_cfi_failure+0x4e/0x60
[ 4947.849417]  ? handle_cfi_failure+0x14c/0x1d0
[ 4947.849419]  ? __cfi_show_status+0x10/0x10
[ 4947.849420]  ? handle_bug+0x4f/0x90
[ 4947.849421]  ? exc_invalid_op+0x1a/0x60
[ 4947.849422]  ? asm_exc_invalid_op+0x1a/0x20
[ 4947.849424]  ? __cfi_show_status+0x10/0x10
[ 4947.849425]  ? dev_attr_show+0x24/0x60
[ 4947.849426]  sysfs_kf_seq_show+0xa6/0x110
[ 4947.849433]  seq_read_iter+0x16c/0x4b0
[ 4947.849436]  vfs_read+0x272/0x2d0
[ 4947.849438]  ksys_read+0x72/0xe0
[ 4947.849439]  do_syscall_64+0x76/0xb0
[ 4947.849440]  ? do_user_addr_fault+0x252/0x650
[ 4947.849442]  ? exc_page_fault+0x7a/0x1b0
[ 4947.849443]  entry_SYSCALL_64_after_hwframe+0x72/0xdc</Note>
    </Notes>
    <CVE>CVE-2023-53550</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: mark requests for GuC virtual engines to avoid use-after-free

References to i915_requests may be trapped by userspace inside a
sync_file or dmabuf (dma-resv) and held indefinitely across different
proceses. To counter-act the memory leaks, we try to not to keep
references from the request past their completion.
On the other side on fence release we need to know if rq-&gt;engine
is valid and points to hw engine (true for non-virtual requests).
To make it possible extra bit has been added to rq-&gt;execution_mask,
for marking virtual engines.

(cherry picked from commit 280410677af763f3871b93e794a199cfcf6fb580)</Note>
    </Notes>
    <CVE>CVE-2023-53552</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: hyperv: avoid struct memcpy overrun warning

A previous patch addressed the fortified memcpy warning for most
builds, but I still see this one with gcc-9:

In file included from include/linux/string.h:254,
                 from drivers/hid/hid-hyperv.c:8:
In function 'fortify_memcpy_chk',
    inlined from 'mousevsc_on_receive' at drivers/hid/hid-hyperv.c:272:3:
include/linux/fortify-string.h:583:4: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning]
  583 |    __write_overflow_field(p_size_field, size);
      |    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

My guess is that the WARN_ON() itself is what confuses gcc, so it no
longer sees that there is a correct range check. Rework the code in a
way that helps readability and avoids the warning.</Note>
    </Notes>
    <CVE>CVE-2023-53553</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

staging: ks7010: potential buffer overflow in ks_wlan_set_encode_ext()

The "exc-&gt;key_len" is a u16 that comes from the user.  If it's over
IW_ENCODING_TOKEN_MAX (64) that could lead to memory corruption.</Note>
    </Notes>
    <CVE>CVE-2023-53554</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/damon/core: initialize damo_filter-&gt;list from damos_new_filter()

damos_new_filter() is not initializing the list field of newly allocated
filter object.  However, DAMON sysfs interface and DAMON_RECLAIM are not
initializing it after calling damos_new_filter().  As a result, accessing
uninitialized memory is possible.  Actually, adding multiple DAMOS filters
via DAMON sysfs interface caused NULL pointer dereferencing.  Initialize
the field just after the allocation from damos_new_filter().</Note>
    </Notes>
    <CVE>CVE-2023-53555</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iavf: Fix use-after-free in free_netdev

We do netif_napi_add() for all allocated q_vectors[], but potentially
do netif_napi_del() for part of them, then kfree q_vectors and leave
invalid pointers at dev-&gt;napi_list.

Reproducer:

  [root@host ~]# cat repro.sh
  #!/bin/bash

  pf_dbsf="0000:41:00.0"
  vf0_dbsf="0000:41:02.0"
  g_pids=()

  function do_set_numvf()
  {
      echo 2 &gt;/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs
      sleep $((RANDOM%3+1))
      echo 0 &gt;/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs
      sleep $((RANDOM%3+1))
  }

  function do_set_channel()
  {
      local nic=$(ls -1 --indicator-style=none /sys/bus/pci/devices/${vf0_dbsf}/net/)
      [ -z "$nic" ] &amp;&amp; { sleep $((RANDOM%3)) ; return 1; }
      ifconfig $nic 192.168.18.5 netmask 255.255.255.0
      ifconfig $nic up
      ethtool -L $nic combined 1
      ethtool -L $nic combined 4
      sleep $((RANDOM%3))
  }

  function on_exit()
  {
      local pid
      for pid in "${g_pids[@]}"; do
          kill -0 "$pid" &amp;&gt;/dev/null &amp;&amp; kill "$pid" &amp;&gt;/dev/null
      done
      g_pids=()
  }

  trap "on_exit; exit" EXIT

  while :; do do_set_numvf ; done &amp;
  g_pids+=($!)
  while :; do do_set_channel ; done &amp;
  g_pids+=($!)

  wait

Result:

[ 4093.900222] ==================================================================
[ 4093.900230] BUG: KASAN: use-after-free in free_netdev+0x308/0x390
[ 4093.900232] Read of size 8 at addr ffff88b4dc145640 by task repro.sh/6699
[ 4093.900233]
[ 4093.900236] CPU: 10 PID: 6699 Comm: repro.sh Kdump: loaded Tainted: G           O     --------- -t - 4.18.0 #1
[ 4093.900238] Hardware name: Powerleader PR2008AL/H12DSi-N6, BIOS 2.0 04/09/2021
[ 4093.900239] Call Trace:
[ 4093.900244]  dump_stack+0x71/0xab
[ 4093.900249]  print_address_description+0x6b/0x290
[ 4093.900251]  ? free_netdev+0x308/0x390
[ 4093.900252]  kasan_report+0x14a/0x2b0
[ 4093.900254]  free_netdev+0x308/0x390
[ 4093.900261]  iavf_remove+0x825/0xd20 [iavf]
[ 4093.900265]  pci_device_remove+0xa8/0x1f0
[ 4093.900268]  device_release_driver_internal+0x1c6/0x460
[ 4093.900271]  pci_stop_bus_device+0x101/0x150
[ 4093.900273]  pci_stop_and_remove_bus_device+0xe/0x20
[ 4093.900275]  pci_iov_remove_virtfn+0x187/0x420
[ 4093.900277]  ? pci_iov_add_virtfn+0xe10/0xe10
[ 4093.900278]  ? pci_get_subsys+0x90/0x90
[ 4093.900280]  sriov_disable+0xed/0x3e0
[ 4093.900282]  ? bus_find_device+0x12d/0x1a0
[ 4093.900290]  i40e_free_vfs+0x754/0x1210 [i40e]
[ 4093.900298]  ? i40e_reset_all_vfs+0x880/0x880 [i40e]
[ 4093.900299]  ? pci_get_device+0x7c/0x90
[ 4093.900300]  ? pci_get_subsys+0x90/0x90
[ 4093.900306]  ? pci_vfs_assigned.part.7+0x144/0x210
[ 4093.900309]  ? __mutex_lock_slowpath+0x10/0x10
[ 4093.900315]  i40e_pci_sriov_configure+0x1fa/0x2e0 [i40e]
[ 4093.900318]  sriov_numvfs_store+0x214/0x290
[ 4093.900320]  ? sriov_totalvfs_show+0x30/0x30
[ 4093.900321]  ? __mutex_lock_slowpath+0x10/0x10
[ 4093.900323]  ? __check_object_size+0x15a/0x350
[ 4093.900326]  kernfs_fop_write+0x280/0x3f0
[ 4093.900329]  vfs_write+0x145/0x440
[ 4093.900330]  ksys_write+0xab/0x160
[ 4093.900332]  ? __ia32_sys_read+0xb0/0xb0
[ 4093.900334]  ? fput_many+0x1a/0x120
[ 4093.900335]  ? filp_close+0xf0/0x130
[ 4093.900338]  do_syscall_64+0xa0/0x370
[ 4093.900339]  ? page_fault+0x8/0x30
[ 4093.900341]  entry_SYSCALL_64_after_hwframe+0x65/0xca
[ 4093.900357] RIP: 0033:0x7f16ad4d22c0
[ 4093.900359] Code: 73 01 c3 48 8b 0d d8 cb 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 89 24 2d 00 00 75 10 b8 01 00 00 00 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 fe dd 01 00 48 89 04 24
[ 4093.900360] RSP: 002b:00007ffd6491b7f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 4093.900362] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f16ad4d22c0
[ 4093.900363] RDX: 0000000000000002 RSI: 0000000001a41408 RDI: 0000000000000001
[ 4093.900364] RBP: 0000000001a41408 R08: 00007f16ad7a1780 R09: 00007f16ae1f2700
[ 4093.9003
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-53556</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

fprobe: Release rethook after the ftrace_ops is unregistered

While running bpf selftests it's possible to get following fault:

  general protection fault, probably for non-canonical address \
  0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC NOPTI
  ...
  Call Trace:
   &lt;TASK&gt;
   fprobe_handler+0xc1/0x270
   ? __pfx_bpf_testmod_init+0x10/0x10
   ? __pfx_bpf_testmod_init+0x10/0x10
   ? bpf_fentry_test1+0x5/0x10
   ? bpf_fentry_test1+0x5/0x10
   ? bpf_testmod_init+0x22/0x80
   ? do_one_initcall+0x63/0x2e0
   ? rcu_is_watching+0xd/0x40
   ? kmalloc_trace+0xaf/0xc0
   ? do_init_module+0x60/0x250
   ? __do_sys_finit_module+0xac/0x120
   ? do_syscall_64+0x37/0x90
   ? entry_SYSCALL_64_after_hwframe+0x72/0xdc
   &lt;/TASK&gt;

In unregister_fprobe function we can't release fp-&gt;rethook while it's
possible there are some of its users still running on another cpu.

Moving rethook_free call after fp-&gt;ops is unregistered with
unregister_ftrace_function call.</Note>
    </Notes>
    <CVE>CVE-2023-53557</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

rcu-tasks: Avoid pr_info() with spin lock in cblist_init_generic()

pr_info() is called with rtp-&gt;cbs_gbl_lock spin lock locked.  Because
pr_info() calls printk() that might sleep, this will result in BUG
like below:

[    0.206455] cblist_init_generic: Setting adjustable number of callback queues.
[    0.206463]
[    0.206464] =============================
[    0.206464] [ BUG: Invalid wait context ]
[    0.206465] 5.19.0-00428-g9de1f9c8ca51 #5 Not tainted
[    0.206466] -----------------------------
[    0.206466] swapper/0/1 is trying to lock:
[    0.206467] ffffffffa0167a58 (&amp;port_lock_key){....}-{3:3}, at: serial8250_console_write+0x327/0x4a0
[    0.206473] other info that might help us debug this:
[    0.206473] context-{5:5}
[    0.206474] 3 locks held by swapper/0/1:
[    0.206474]  #0: ffffffff9eb597e0 (rcu_tasks.cbs_gbl_lock){....}-{2:2}, at: cblist_init_generic.constprop.0+0x14/0x1f0
[    0.206478]  #1: ffffffff9eb579c0 (console_lock){+.+.}-{0:0}, at: _printk+0x63/0x7e
[    0.206482]  #2: ffffffff9ea77780 (console_owner){....}-{0:0}, at: console_emit_next_record.constprop.0+0x111/0x330
[    0.206485] stack backtrace:
[    0.206486] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-00428-g9de1f9c8ca51 #5
[    0.206488] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014
[    0.206489] Call Trace:
[    0.206490]  &lt;TASK&gt;
[    0.206491]  dump_stack_lvl+0x6a/0x9f
[    0.206493]  __lock_acquire.cold+0x2d7/0x2fe
[    0.206496]  ? stack_trace_save+0x46/0x70
[    0.206497]  lock_acquire+0xd1/0x2f0
[    0.206499]  ? serial8250_console_write+0x327/0x4a0
[    0.206500]  ? __lock_acquire+0x5c7/0x2720
[    0.206502]  _raw_spin_lock_irqsave+0x3d/0x90
[    0.206504]  ? serial8250_console_write+0x327/0x4a0
[    0.206506]  serial8250_console_write+0x327/0x4a0
[    0.206508]  console_emit_next_record.constprop.0+0x180/0x330
[    0.206511]  console_unlock+0xf7/0x1f0
[    0.206512]  vprintk_emit+0xf7/0x330
[    0.206514]  _printk+0x63/0x7e
[    0.206516]  cblist_init_generic.constprop.0.cold+0x24/0x32
[    0.206518]  rcu_init_tasks_generic+0x5/0xd9
[    0.206522]  kernel_init_freeable+0x15b/0x2a2
[    0.206523]  ? rest_init+0x160/0x160
[    0.206526]  kernel_init+0x11/0x120
[    0.206527]  ret_from_fork+0x1f/0x30
[    0.206530]  &lt;/TASK&gt;
[    0.207018] cblist_init_generic: Setting shift to 1 and lim to 1.

This patch moves pr_info() so that it is called without
rtp-&gt;cbs_gbl_lock locked.</Note>
    </Notes>
    <CVE>CVE-2023-53558</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ip_vti: fix potential slab-use-after-free in decode_session6

When ip_vti device is set to the qdisc of the sfb type, the cb field
of the sent skb may be modified during enqueuing. Then,
slab-use-after-free may occur when ip_vti device sends IPv6 packets.
As commit f855691975bb ("xfrm6: Fix the nexthdr offset in
_decode_session6.") showed, xfrm_decode_session was originally intended
only for the receive path. IP6CB(skb)-&gt;nhoff is not set during
transmission. Therefore, set the cb field in the skb to 0 before
sending packets.</Note>
    </Notes>
    <CVE>CVE-2023-53559</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/histograms: Add histograms to hist_vars if they have referenced variables

Hist triggers can have referenced variables without having direct
variables fields. This can be the case if referenced variables are added
for trigger actions. In this case the newly added references will not
have field variables. Not taking such referenced variables into
consideration can result in a bug where it would be possible to remove
hist trigger with variables being refenced. This will result in a bug
that is easily reproducable like so

$ cd /sys/kernel/tracing
$ echo 'synthetic_sys_enter char[] comm; long id' &gt;&gt; synthetic_events
$ echo 'hist:keys=common_pid.execname,id.syscall:vals=hitcount:comm=common_pid.execname' &gt;&gt; events/raw_syscalls/sys_enter/trigger
$ echo 'hist:keys=common_pid.execname,id.syscall:onmatch(raw_syscalls.sys_enter).synthetic_sys_enter($comm, id)' &gt;&gt; events/raw_syscalls/sys_enter/trigger
$ echo '!hist:keys=common_pid.execname,id.syscall:vals=hitcount:comm=common_pid.execname' &gt;&gt; events/raw_syscalls/sys_enter/trigger

[  100.263533] ==================================================================
[  100.264634] BUG: KASAN: slab-use-after-free in resolve_var_refs+0xc7/0x180
[  100.265520] Read of size 8 at addr ffff88810375d0f0 by task bash/439
[  100.266320]
[  100.266533] CPU: 2 PID: 439 Comm: bash Not tainted 6.5.0-rc1 #4
[  100.267277] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-20220807_005459-localhost 04/01/2014
[  100.268561] Call Trace:
[  100.268902]  &lt;TASK&gt;
[  100.269189]  dump_stack_lvl+0x4c/0x70
[  100.269680]  print_report+0xc5/0x600
[  100.270165]  ? resolve_var_refs+0xc7/0x180
[  100.270697]  ? kasan_complete_mode_report_info+0x80/0x1f0
[  100.271389]  ? resolve_var_refs+0xc7/0x180
[  100.271913]  kasan_report+0xbd/0x100
[  100.272380]  ? resolve_var_refs+0xc7/0x180
[  100.272920]  __asan_load8+0x71/0xa0
[  100.273377]  resolve_var_refs+0xc7/0x180
[  100.273888]  event_hist_trigger+0x749/0x860
[  100.274505]  ? kasan_save_stack+0x2a/0x50
[  100.275024]  ? kasan_set_track+0x29/0x40
[  100.275536]  ? __pfx_event_hist_trigger+0x10/0x10
[  100.276138]  ? ksys_write+0xd1/0x170
[  100.276607]  ? do_syscall_64+0x3c/0x90
[  100.277099]  ? entry_SYSCALL_64_after_hwframe+0x6e/0xd8
[  100.277771]  ? destroy_hist_data+0x446/0x470
[  100.278324]  ? event_hist_trigger_parse+0xa6c/0x3860
[  100.278962]  ? __pfx_event_hist_trigger_parse+0x10/0x10
[  100.279627]  ? __kasan_check_write+0x18/0x20
[  100.280177]  ? mutex_unlock+0x85/0xd0
[  100.280660]  ? __pfx_mutex_unlock+0x10/0x10
[  100.281200]  ? kfree+0x7b/0x120
[  100.281619]  ? ____kasan_slab_free+0x15d/0x1d0
[  100.282197]  ? event_trigger_write+0xac/0x100
[  100.282764]  ? __kasan_slab_free+0x16/0x20
[  100.283293]  ? __kmem_cache_free+0x153/0x2f0
[  100.283844]  ? sched_mm_cid_remote_clear+0xb1/0x250
[  100.284550]  ? __pfx_sched_mm_cid_remote_clear+0x10/0x10
[  100.285221]  ? event_trigger_write+0xbc/0x100
[  100.285781]  ? __kasan_check_read+0x15/0x20
[  100.286321]  ? __bitmap_weight+0x66/0xa0
[  100.286833]  ? _find_next_bit+0x46/0xe0
[  100.287334]  ? task_mm_cid_work+0x37f/0x450
[  100.287872]  event_triggers_call+0x84/0x150
[  100.288408]  trace_event_buffer_commit+0x339/0x430
[  100.289073]  ? ring_buffer_event_data+0x3f/0x60
[  100.292189]  trace_event_raw_event_sys_enter+0x8b/0xe0
[  100.295434]  syscall_trace_enter.constprop.0+0x18f/0x1b0
[  100.298653]  syscall_enter_from_user_mode+0x32/0x40
[  100.301808]  do_syscall_64+0x1a/0x90
[  100.304748]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
[  100.307775] RIP: 0033:0x7f686c75c1cb
[  100.310617] Code: 73 01 c3 48 8b 0d 65 3c 10 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 21 00 00 00 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 35 3c 10 00 f7 d8 64 89 01 48
[  100.317847] RSP: 002b:00007ffc60137a38 EFLAGS: 00000246 ORIG_RAX: 0000000000000021
[  100.321200] RA
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-53560</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

cpufreq: amd-pstate-ut: Fix kernel panic when loading the driver

After loading the amd-pstate-ut driver, amd_pstate_ut_check_perf()
and amd_pstate_ut_check_freq() use cpufreq_cpu_get() to get the policy
of the CPU and mark it as busy.

In these functions, cpufreq_cpu_put() should be used to release the
policy, but it is not, so any other entity trying to access the policy
is blocked indefinitely.

One such scenario is when amd_pstate mode is changed, leading to the
following splat:

[ 1332.103727] INFO: task bash:2929 blocked for more than 120 seconds.
[ 1332.110001]       Not tainted 6.5.0-rc2-amd-pstate-ut #5
[ 1332.115315] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1332.123140] task:bash            state:D stack:0     pid:2929  ppid:2873   flags:0x00004006
[ 1332.123143] Call Trace:
[ 1332.123145]  &lt;TASK&gt;
[ 1332.123148]  __schedule+0x3c1/0x16a0
[ 1332.123154]  ? _raw_read_lock_irqsave+0x2d/0x70
[ 1332.123157]  schedule+0x6f/0x110
[ 1332.123160]  schedule_timeout+0x14f/0x160
[ 1332.123162]  ? preempt_count_add+0x86/0xd0
[ 1332.123165]  __wait_for_common+0x92/0x190
[ 1332.123168]  ? __pfx_schedule_timeout+0x10/0x10
[ 1332.123170]  wait_for_completion+0x28/0x30
[ 1332.123173]  cpufreq_policy_put_kobj+0x4d/0x90
[ 1332.123177]  cpufreq_policy_free+0x157/0x1d0
[ 1332.123178]  ? preempt_count_add+0x58/0xd0
[ 1332.123180]  cpufreq_remove_dev+0xb6/0x100
[ 1332.123182]  subsys_interface_unregister+0x114/0x120
[ 1332.123185]  ? preempt_count_add+0x58/0xd0
[ 1332.123187]  ? __pfx_amd_pstate_change_driver_mode+0x10/0x10
[ 1332.123190]  cpufreq_unregister_driver+0x3b/0xd0
[ 1332.123192]  amd_pstate_change_driver_mode+0x1e/0x50
[ 1332.123194]  store_status+0xe9/0x180
[ 1332.123197]  dev_attr_store+0x1b/0x30
[ 1332.123199]  sysfs_kf_write+0x42/0x50
[ 1332.123202]  kernfs_fop_write_iter+0x143/0x1d0
[ 1332.123204]  vfs_write+0x2df/0x400
[ 1332.123208]  ksys_write+0x6b/0xf0
[ 1332.123210]  __x64_sys_write+0x1d/0x30
[ 1332.123213]  do_syscall_64+0x60/0x90
[ 1332.123216]  ? fpregs_assert_state_consistent+0x2e/0x50
[ 1332.123219]  ? exit_to_user_mode_prepare+0x49/0x1a0
[ 1332.123223]  ? irqentry_exit_to_user_mode+0xd/0x20
[ 1332.123225]  ? irqentry_exit+0x3f/0x50
[ 1332.123226]  ? exc_page_fault+0x8e/0x190
[ 1332.123228]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
[ 1332.123232] RIP: 0033:0x7fa74c514a37
[ 1332.123234] RSP: 002b:00007ffe31dd0788 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 1332.123238] RAX: ffffffffffffffda RBX: 0000000000000008 RCX: 00007fa74c514a37
[ 1332.123239] RDX: 0000000000000008 RSI: 000055e27c447aa0 RDI: 0000000000000001
[ 1332.123241] RBP: 000055e27c447aa0 R08: 00007fa74c5d1460 R09: 000000007fffffff
[ 1332.123242] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000008
[ 1332.123244] R13: 00007fa74c61a780 R14: 00007fa74c616600 R15: 00007fa74c615a00
[ 1332.123247]  &lt;/TASK&gt;

Fix this by calling cpufreq_cpu_put() wherever necessary.

[ rjw: Subject and changelog edits ]</Note>
    </Notes>
    <CVE>CVE-2023-53563</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/zcrypt: don't leak memory if dev_set_name() fails

When dev_set_name() fails, zcdn_create() doesn't free the newly
allocated resources. Do it.</Note>
    </Notes>
    <CVE>CVE-2023-53568</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: nl80211: fix integer overflow in nl80211_parse_mbssid_elems()

nl80211_parse_mbssid_elems() uses a u8 variable num_elems to count the
number of MBSSID elements in the nested netlink attribute attrs, which can
lead to an integer overflow if a user of the nl80211 interface specifies
256 or more elements in the corresponding attribute in userspace. The
integer overflow can lead to a heap buffer overflow as num_elems determines
the size of the trailing array in elems, and this array is thereafter
written to for each element in attrs.

Note that this vulnerability only affects devices with the
wiphy-&gt;mbssid_max_interfaces member set for the wireless physical device
struct in the device driver, and can only be triggered by a process with
CAP_NET_ADMIN capabilities.

Fix this by checking for a maximum of 255 elements in attrs.</Note>
    </Notes>
    <CVE>CVE-2023-53570</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

clk: imx: scu: use _safe list iterator to avoid a use after free

This loop is freeing "clk" so it needs to use list_for_each_entry_safe().
Otherwise it dereferences a freed variable to get the next item on the
loop.</Note>
    </Notes>
    <CVE>CVE-2023-53572</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: delete timer and free skb queue when unloading

Fix possible crash and memory leak on driver unload by deleting
TX purge timer and freeing C2H queue in 'rtw_core_deinit()',
shrink critical section in the latter by freeing COEX queue
out of TX report lock scope.</Note>
    </Notes>
    <CVE>CVE-2023-53574</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: iwlwifi: mvm: fix potential array out of bounds access

Account for IWL_SEC_WEP_KEY_OFFSET when needed while verifying
key_len size in iwl_mvm_sec_key_add().</Note>
    </Notes>
    <CVE>CVE-2023-53575</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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, cpumap: Make sure kthread is running before map update returns

The following warning was reported when running stress-mode enabled
xdp_redirect_cpu with some RT threads:

  ------------[ cut here ]------------
  WARNING: CPU: 4 PID: 65 at kernel/bpf/cpumap.c:135
  CPU: 4 PID: 65 Comm: kworker/4:1 Not tainted 6.5.0-rc2+ #1
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
  Workqueue: events cpu_map_kthread_stop
  RIP: 0010:put_cpu_map_entry+0xda/0x220
  ......
  Call Trace:
   &lt;TASK&gt;
   ? show_regs+0x65/0x70
   ? __warn+0xa5/0x240
   ......
   ? put_cpu_map_entry+0xda/0x220
   cpu_map_kthread_stop+0x41/0x60
   process_one_work+0x6b0/0xb80
   worker_thread+0x96/0x720
   kthread+0x1a5/0x1f0
   ret_from_fork+0x3a/0x70
   ret_from_fork_asm+0x1b/0x30
   &lt;/TASK&gt;

The root cause is the same as commit 436901649731 ("bpf: cpumap: Fix memory
leak in cpu_map_update_elem"). The kthread is stopped prematurely by
kthread_stop() in cpu_map_kthread_stop(), and kthread() doesn't call
cpu_map_kthread_run() at all but XDP program has already queued some
frames or skbs into ptr_ring. So when __cpu_map_ring_cleanup() checks
the ptr_ring, it will find it was not emptied and report a warning.

An alternative fix is to use __cpu_map_ring_cleanup() to drop these
pending frames or skbs when kthread_stop() returns -EINTR, but it may
confuse the user, because these frames or skbs have been handled
correctly by XDP program. So instead of dropping these frames or skbs,
just make sure the per-cpu kthread is running before
__cpu_map_entry_alloc() returns.

After apply the fix, the error handle for kthread_stop() will be
unnecessary because it will always return 0, so just remove it.</Note>
    </Notes>
    <CVE>CVE-2023-53577</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

gpio: mvebu: fix irq domain leak

Uwe Kleine-König pointed out we still have one resource leak in the mvebu
driver triggered on driver detach. Let's address it with a custom devm
action.</Note>
    </Notes>
    <CVE>CVE-2023-53579</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: core: Help prevent panic during UVC unconfigure

Avichal Rakesh reported a kernel panic that occurred when the UVC
gadget driver was removed from a gadget's configuration.  The panic
involves a somewhat complicated interaction between the kernel driver
and a userspace component (as described in the Link tag below), but
the analysis did make one thing clear: The Gadget core should
accomodate gadget drivers calling usb_gadget_deactivate() as part of
their unbind procedure.

Currently this doesn't work.  gadget_unbind_driver() calls
driver-&gt;unbind() while holding the udc-&gt;connect_lock mutex, and
usb_gadget_deactivate() attempts to acquire that mutex, which will
result in a deadlock.

The simple fix is for gadget_unbind_driver() to release the mutex when
invoking the -&gt;unbind() callback.  There is no particular reason for
it to be holding the mutex at that time, and the mutex isn't held
while the -&gt;bind() callback is invoked.  So we'll drop the mutex
before performing the unbind callback and reacquire it afterward.

We'll also add a couple of comments to usb_gadget_activate() and
usb_gadget_deactivate().  Because they run in process context they
must not be called from a gadget driver's -&gt;disconnect() callback,
which (according to the kerneldoc for struct usb_gadget_driver in
include/linux/usb/gadget.h) may run in interrupt context.  This may
help prevent similar bugs from arising in the future.</Note>
    </Notes>
    <CVE>CVE-2023-53580</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Check for NOT_READY flag state after locking

Currently the check for NOT_READY flag is performed before obtaining the
necessary lock. This opens a possibility for race condition when the flow
is concurrently removed from unready_flows list by the workqueue task,
which causes a double-removal from the list and a crash[0]. Fix the issue
by moving the flag check inside the section protected by
uplink_priv-&gt;unready_flows_lock mutex.

[0]:
[44376.389654] general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP
[44376.391665] CPU: 7 PID: 59123 Comm: tc Not tainted 6.4.0-rc4+ #1
[44376.392984] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
[44376.395342] RIP: 0010:mlx5e_tc_del_fdb_flow+0xb3/0x340 [mlx5_core]
[44376.396857] Code: 00 48 8b b8 68 ce 02 00 e8 8a 4d 02 00 4c 8d a8 a8 01 00 00 4c 89 ef e8 8b 79 88 e1 48 8b 83 98 06 00 00 48 8b 93 90 06 00 00 &lt;48&gt; 89 42 08 48 89 10 48 b8 00 01 00 00 00 00 ad de 48 89 83 90 06
[44376.399167] RSP: 0018:ffff88812cc97570 EFLAGS: 00010246
[44376.399680] RAX: dead000000000122 RBX: ffff8881088e3800 RCX: ffff8881881bac00
[44376.400337] RDX: dead000000000100 RSI: ffff88812cc97500 RDI: ffff8881242f71b0
[44376.401001] RBP: ffff88811cbb0940 R08: 0000000000000400 R09: 0000000000000001
[44376.401663] R10: 0000000000000001 R11: 0000000000000000 R12: ffff88812c944000
[44376.402342] R13: ffff8881242f71a8 R14: ffff8881222b4000 R15: 0000000000000000
[44376.402999] FS:  00007f0451104800(0000) GS:ffff88852cb80000(0000) knlGS:0000000000000000
[44376.403787] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[44376.404343] CR2: 0000000000489108 CR3: 0000000123a79003 CR4: 0000000000370ea0
[44376.405004] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[44376.405665] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[44376.406339] Call Trace:
[44376.406651]  &lt;TASK&gt;
[44376.406939]  ? die_addr+0x33/0x90
[44376.407311]  ? exc_general_protection+0x192/0x390
[44376.407795]  ? asm_exc_general_protection+0x22/0x30
[44376.408292]  ? mlx5e_tc_del_fdb_flow+0xb3/0x340 [mlx5_core]
[44376.408876]  __mlx5e_tc_del_fdb_peer_flow+0xbc/0xe0 [mlx5_core]
[44376.409482]  mlx5e_tc_del_flow+0x42/0x210 [mlx5_core]
[44376.410055]  mlx5e_flow_put+0x25/0x50 [mlx5_core]
[44376.410529]  mlx5e_delete_flower+0x24b/0x350 [mlx5_core]
[44376.411043]  tc_setup_cb_reoffload+0x22/0x80
[44376.411462]  fl_reoffload+0x261/0x2f0 [cls_flower]
[44376.411907]  ? mlx5e_rep_indr_setup_ft_cb+0x160/0x160 [mlx5_core]
[44376.412481]  ? mlx5e_rep_indr_setup_ft_cb+0x160/0x160 [mlx5_core]
[44376.413044]  tcf_block_playback_offloads+0x76/0x170
[44376.413497]  tcf_block_unbind+0x7b/0xd0
[44376.413881]  tcf_block_setup+0x17d/0x1c0
[44376.414269]  tcf_block_offload_cmd.isra.0+0xf1/0x130
[44376.414725]  tcf_block_offload_unbind+0x43/0x70
[44376.415153]  __tcf_block_put+0x82/0x150
[44376.415532]  ingress_destroy+0x22/0x30 [sch_ingress]
[44376.415986]  qdisc_destroy+0x3b/0xd0
[44376.416343]  qdisc_graft+0x4d0/0x620
[44376.416706]  tc_get_qdisc+0x1c9/0x3b0
[44376.417074]  rtnetlink_rcv_msg+0x29c/0x390
[44376.419978]  ? rep_movs_alternative+0x3a/0xa0
[44376.420399]  ? rtnl_calcit.isra.0+0x120/0x120
[44376.420813]  netlink_rcv_skb+0x54/0x100
[44376.421192]  netlink_unicast+0x1f6/0x2c0
[44376.421573]  netlink_sendmsg+0x232/0x4a0
[44376.421980]  sock_sendmsg+0x38/0x60
[44376.422328]  ____sys_sendmsg+0x1d0/0x1e0
[44376.422709]  ? copy_msghdr_from_user+0x6d/0xa0
[44376.423127]  ___sys_sendmsg+0x80/0xc0
[44376.423495]  ? ___sys_recvmsg+0x8b/0xc0
[44376.423869]  __sys_sendmsg+0x51/0x90
[44376.424226]  do_syscall_64+0x3d/0x90
[44376.424587]  entry_SYSCALL_64_after_hwframe+0x46/0xb0
[44376.425046] RIP: 0033:0x7f045134f887
[44376.425403] Code: 0a 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-53581</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: RISC-V: Remove PERF_HES_STOPPED flag checking in riscv_pmu_start()

Since commit 096b52fd2bb4 ("perf: RISC-V: throttle perf events") the
perf_sample_event_took() function was added to report time spent in
overflow interrupts. If the interrupt takes too long, the perf framework
will lower the sysctl_perf_event_sample_rate and max_samples_per_tick.
When hwc-&gt;interrupts is larger than max_samples_per_tick, the
hwc-&gt;interrupts will be set to MAX_INTERRUPTS, and events will be
throttled within the __perf_event_account_interrupt() function.

However, the RISC-V PMU driver doesn't call riscv_pmu_stop() to update the
PERF_HES_STOPPED flag after perf_event_overflow() in pmu_sbi_ovf_handler()
function to avoid throttling. When the perf framework unthrottled the event
in the timer interrupt handler, it triggers riscv_pmu_start() function
and causes a WARN_ON_ONCE() warning, as shown below:

 ------------[ cut here ]------------
 WARNING: CPU: 0 PID: 240 at drivers/perf/riscv_pmu.c:184 riscv_pmu_start+0x7c/0x8e
 Modules linked in:
 CPU: 0 PID: 240 Comm: ls Not tainted 6.4-rc4-g19d0788e9ef2 #1
 Hardware name: SiFive (DT)
 epc : riscv_pmu_start+0x7c/0x8e
  ra : riscv_pmu_start+0x28/0x8e
 epc : ffffffff80aef864 ra : ffffffff80aef810 sp : ffff8f80004db6f0
  gp : ffffffff81c83750 tp : ffffaf80069f9bc0 t0 : ffff8f80004db6c0
  t1 : 0000000000000000 t2 : 000000000000001f s0 : ffff8f80004db720
  s1 : ffffaf8008ca1068 a0 : 0000ffffffffffff a1 : 0000000000000000
  a2 : 0000000000000001 a3 : 0000000000000870 a4 : 0000000000000000
  a5 : 0000000000000000 a6 : 0000000000000840 a7 : 0000000000000030
  s2 : 0000000000000000 s3 : ffffaf8005165800 s4 : ffffaf800424da00
  s5 : ffffffffffffffff s6 : ffffffff81cc7590 s7 : 0000000000000000
  s8 : 0000000000000006 s9 : 0000000000000001 s10: ffffaf807efbc340
  s11: ffffaf807efbbf00 t3 : ffffaf8006a16028 t4 : 00000000dbfbb796
  t5 : 0000000700000000 t6 : ffffaf8005269870
 status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003
 [&lt;ffffffff80aef864&gt;] riscv_pmu_start+0x7c/0x8e
 [&lt;ffffffff80185b56&gt;] perf_adjust_freq_unthr_context+0x15e/0x174
 [&lt;ffffffff80188642&gt;] perf_event_task_tick+0x88/0x9c
 [&lt;ffffffff800626a8&gt;] scheduler_tick+0xfe/0x27c
 [&lt;ffffffff800b5640&gt;] update_process_times+0x9a/0xba
 [&lt;ffffffff800c5bd4&gt;] tick_sched_handle+0x32/0x66
 [&lt;ffffffff800c5e0c&gt;] tick_sched_timer+0x64/0xb0
 [&lt;ffffffff800b5e50&gt;] __hrtimer_run_queues+0x156/0x2f4
 [&lt;ffffffff800b6bdc&gt;] hrtimer_interrupt+0xe2/0x1fe
 [&lt;ffffffff80acc9e8&gt;] riscv_timer_interrupt+0x38/0x42
 [&lt;ffffffff80090a16&gt;] handle_percpu_devid_irq+0x90/0x1d2
 [&lt;ffffffff8008a9f4&gt;] generic_handle_domain_irq+0x28/0x36

After referring other PMU drivers like Arm, Loongarch, Csky, and Mips,
they don't call *_pmu_stop() to update with PERF_HES_STOPPED flag
after perf_event_overflow() function nor do they add PERF_HES_STOPPED
flag checking in *_pmu_start() which don't cause this warning.

Thus, it's recommended to remove this unnecessary check in
riscv_pmu_start() function to prevent this warning.</Note>
    </Notes>
    <CVE>CVE-2023-53583</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: reject unhashed sockets in bpf_sk_assign

The semantics for bpf_sk_assign are as follows:

    sk = some_lookup_func()
    bpf_sk_assign(skb, sk)
    bpf_sk_release(sk)

That is, the sk is not consumed by bpf_sk_assign. The function
therefore needs to make sure that sk lives long enough to be
consumed from __inet_lookup_skb. The path through the stack for a
TCPv4 packet is roughly:

  netif_receive_skb_core: takes RCU read lock
    __netif_receive_skb_core:
      sch_handle_ingress:
        tcf_classify:
          bpf_sk_assign()
      deliver_ptype_list_skb:
        deliver_skb:
          ip_packet_type-&gt;func == ip_rcv:
            ip_rcv_core:
            ip_rcv_finish_core:
              dst_input:
                ip_local_deliver:
                  ip_local_deliver_finish:
                    ip_protocol_deliver_rcu:
                      tcp_v4_rcv:
                        __inet_lookup_skb:
                          skb_steal_sock

The existing helper takes advantage of the fact that everything
happens in the same RCU critical section: for sockets with
SOCK_RCU_FREE set bpf_sk_assign never takes a reference.
skb_steal_sock then checks SOCK_RCU_FREE again and does sock_put
if necessary.

This approach assumes that SOCK_RCU_FREE is never set on a sk
between bpf_sk_assign and skb_steal_sock, but this invariant is
violated by unhashed UDP sockets. A new UDP socket is created
in TCP_CLOSE state but without SOCK_RCU_FREE set. That flag is only
added in udp_lib_get_port() which happens when a socket is bound.

When bpf_sk_assign was added it wasn't possible to access unhashed
UDP sockets from BPF, so this wasn't a problem. This changed
in commit 0c48eefae712 ("sock_map: Lift socket state restriction
for datagram sockets"), but the helper wasn't adjusted accordingly.
The following sequence of events will therefore lead to a refcount
leak:

1. Add socket(AF_INET, SOCK_DGRAM) to a sockmap.
2. Pull socket out of sockmap and bpf_sk_assign it. Since
   SOCK_RCU_FREE is not set we increment the refcount.
3. bind() or connect() the socket, setting SOCK_RCU_FREE.
4. skb_steal_sock will now set refcounted = false due to
   SOCK_RCU_FREE.
5. tcp_v4_rcv() skips sock_put().

Fix the problem by rejecting unhashed sockets in bpf_sk_assign().
This matches the behaviour of __inet_lookup_skb which is ultimately
the goal of bpf_sk_assign().</Note>
    </Notes>
    <CVE>CVE-2023-53585</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: mac80211: check for station first in client probe

When probing a client, first check if we have it, and then
check for the channel context, otherwise you can trigger
the warning there easily by probing when the AP isn't even
started yet. Since a client existing means the AP is also
operating, we can then keep the warning.

Also simplify the moved code a bit.</Note>
    </Notes>
    <CVE>CVE-2023-53588</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Release folio lock on fscache read hit.

Under the current code, when cifs_readpage_worker is called, the call
contract is that the callee should unlock the page. This is documented
in the read_folio section of Documentation/filesystems/vfs.rst as:

&gt; The filesystem should unlock the folio once the read has completed,
&gt; whether it was successful or not.

Without this change, when fscache is in use and cache hit occurs during
a read, the page lock is leaked, producing the following stack on
subsequent reads (via mmap) to the page:

$ cat /proc/3890/task/12864/stack
[&lt;0&gt;] folio_wait_bit_common+0x124/0x350
[&lt;0&gt;] filemap_read_folio+0xad/0xf0
[&lt;0&gt;] filemap_fault+0x8b1/0xab0
[&lt;0&gt;] __do_fault+0x39/0x150
[&lt;0&gt;] do_fault+0x25c/0x3e0
[&lt;0&gt;] __handle_mm_fault+0x6ca/0xc70
[&lt;0&gt;] handle_mm_fault+0xe9/0x350
[&lt;0&gt;] do_user_addr_fault+0x225/0x6c0
[&lt;0&gt;] exc_page_fault+0x84/0x1b0
[&lt;0&gt;] asm_exc_page_fault+0x27/0x30

This requires a reboot to resolve; it is a deadlock.

Note however that the call to cifs_readpage_from_fscache does mark the
page clean, but does not free the folio lock. This happens in
__cifs_readpage_from_fscache on success. Releasing the lock at that
point however is not appropriate as cifs_readahead also calls
cifs_readpage_from_fscache and *does* unconditionally release the lock
after its return. This change therefore effectively makes
cifs_readpage_worker work like cifs_readahead.</Note>
    </Notes>
    <CVE>CVE-2023-53593</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: base: Free devm resources when unregistering a device

In the current code, devres_release_all() only gets called if the device
has a bus and has been probed.

This leads to issues when using bus-less or driver-less devices where
the device might never get freed if a managed resource holds a reference
to the device. This is happening in the DRM framework for example.

We should thus call devres_release_all() in the device_del() function to
make sure that the device-managed actions are properly executed when the
device is unregistered, even if it has neither a bus nor a driver.

This is effectively the same change than commit 2f8d16a996da ("devres:
release resources on device_del()") that got reverted by commit
a525a3ddeaca ("driver core: free devres in device_release") over
memory leaks concerns.

This patch effectively combines the two commits mentioned above to
release the resources both on device_del() and device_release() and get
the best of both worlds.</Note>
    </Notes>
    <CVE>CVE-2023-53596</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix mid leak during reconnection after timeout threshold

When the number of responses with status of STATUS_IO_TIMEOUT
exceeds a specified threshold (NUM_STATUS_IO_TIMEOUT), we reconnect
the connection. But we do not return the mid, or the credits
returned for the mid, or reduce the number of in-flight requests.

This bug could result in the server-&gt;in_flight count to go bad,
and also cause a leak in the mids.

This change moves the check to a few lines below where the
response is decrypted, even of the response is read from the
transform header. This way, the code for returning the mids
can be reused.

Also, the cifs_reconnect was reconnecting just the transport
connection before. In case of multi-channel, this may not be
what we want to do after several timeouts. Changed that to
reconnect the session and the tree too.

Also renamed NUM_STATUS_IO_TIMEOUT to a more appropriate name
MAX_STATUS_IO_TIMEOUT.</Note>
    </Notes>
    <CVE>CVE-2023-53597</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: af_alg - Fix missing initialisation affecting gcm-aes-s390

Fix af_alg_alloc_areq() to initialise areq-&gt;first_rsgl.sgl.sgt.sgl to point
to the scatterlist array in areq-&gt;first_rsgl.sgl.sgl.

Without this, the gcm-aes-s390 driver will oops when it tries to do
gcm_walk_start() on req-&gt;dst because req-&gt;dst is set to the value of
areq-&gt;first_rsgl.sgl.sgl by _aead_recvmsg() calling
aead_request_set_crypt().

The problem comes if an empty ciphertext is passed: the loop in
af_alg_get_rsgl() just passes straight out and doesn't set areq-&gt;first_rsgl
up.

This isn't a problem on x86_64 using gcmaes_crypt_by_sg() because, as far
as I can tell, that ignores req-&gt;dst and only uses req-&gt;src[*].

[*] Is this a bug in aesni-intel_glue.c?

The s390x oops looks something like:

 Unable to handle kernel pointer dereference in virtual kernel address space
 Failing address: 0000000a00000000 TEID: 0000000a00000803
 Fault in home space mode while using kernel ASCE.
 AS:00000000a43a0007 R3:0000000000000024
 Oops: 003b ilc:2 [#1] SMP
 ...
 Call Trace:
  [&lt;000003ff7fc3d47e&gt;] gcm_walk_start+0x16/0x28 [aes_s390]
  [&lt;00000000a2a342f2&gt;] crypto_aead_decrypt+0x9a/0xb8
  [&lt;00000000a2a60888&gt;] aead_recvmsg+0x478/0x698
  [&lt;00000000a2e519a0&gt;] sock_recvmsg+0x70/0xb0
  [&lt;00000000a2e51a56&gt;] sock_read_iter+0x76/0xa0
  [&lt;00000000a273e066&gt;] vfs_read+0x26e/0x2a8
  [&lt;00000000a273e8c4&gt;] ksys_read+0xbc/0x100
  [&lt;00000000a311d808&gt;] __do_syscall+0x1d0/0x1f8
  [&lt;00000000a312ff30&gt;] system_call+0x70/0x98
 Last Breaking-Event-Address:
  [&lt;000003ff7fc3e6b4&gt;] gcm_aes_crypt+0x104/0xa68 [aes_s390]</Note>
    </Notes>
    <CVE>CVE-2023-53599</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tunnels: fix kasan splat when generating ipv4 pmtu error

If we try to emit an icmp error in response to a nonliner skb, we get

BUG: KASAN: slab-out-of-bounds in ip_compute_csum+0x134/0x220
Read of size 4 at addr ffff88811c50db00 by task iperf3/1691
CPU: 2 PID: 1691 Comm: iperf3 Not tainted 6.5.0-rc3+ #309
[..]
 kasan_report+0x105/0x140
 ip_compute_csum+0x134/0x220
 iptunnel_pmtud_build_icmp+0x554/0x1020
 skb_tunnel_check_pmtu+0x513/0xb80
 vxlan_xmit_one+0x139e/0x2ef0
 vxlan_xmit+0x1867/0x2760
 dev_hard_start_xmit+0x1ee/0x4f0
 br_dev_queue_push_xmit+0x4d1/0x660
 [..]

ip_compute_csum() cannot deal with nonlinear skbs, so avoid it.
After this change, splat is gone and iperf3 is no longer stuck.</Note>
    </Notes>
    <CVE>CVE-2023-53600</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bonding: do not assume skb mac_header is set

Drivers must not assume in their ndo_start_xmit() that
skbs have their mac_header set. skb-&gt;data is all what is needed.

bonding seems to be one of the last offender as caught by syzbot:

WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 skb_mac_offset include/linux/skbuff.h:2913 [inline]
WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_xmit_hash drivers/net/bonding/bond_main.c:4170 [inline]
WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5149 [inline]
WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_3ad_xor_xmit drivers/net/bonding/bond_main.c:5186 [inline]
WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 __bond_start_xmit drivers/net/bonding/bond_main.c:5442 [inline]
WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_start_xmit+0x14ab/0x19d0 drivers/net/bonding/bond_main.c:5470
Modules linked in:
CPU: 1 PID: 12155 Comm: syz-executor.3 Not tainted 6.1.30-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023
RIP: 0010:skb_mac_header include/linux/skbuff.h:2907 [inline]
RIP: 0010:skb_mac_offset include/linux/skbuff.h:2913 [inline]
RIP: 0010:bond_xmit_hash drivers/net/bonding/bond_main.c:4170 [inline]
RIP: 0010:bond_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5149 [inline]
RIP: 0010:bond_3ad_xor_xmit drivers/net/bonding/bond_main.c:5186 [inline]
RIP: 0010:__bond_start_xmit drivers/net/bonding/bond_main.c:5442 [inline]
RIP: 0010:bond_start_xmit+0x14ab/0x19d0 drivers/net/bonding/bond_main.c:5470
Code: 8b 7c 24 30 e8 76 dd 1a 01 48 85 c0 74 0d 48 89 c3 e8 29 67 2e fe e9 15 ef ff ff e8 1f 67 2e fe e9 10 ef ff ff e8 15 67 2e fe &lt;0f&gt; 0b e9 45 f8 ff ff e8 09 67 2e fe e9 dc fa ff ff e8 ff 66 2e fe
RSP: 0018:ffffc90002fff6e0 EFLAGS: 00010283
RAX: ffffffff835874db RBX: 000000000000ffff RCX: 0000000000040000
RDX: ffffc90004dcf000 RSI: 00000000000000b5 RDI: 00000000000000b6
RBP: ffffc90002fff8b8 R08: ffffffff83586d16 R09: ffffffff83586584
R10: 0000000000000007 R11: ffff8881599fc780 R12: ffff88811b6a7b7e
R13: 1ffff110236d4f6f R14: ffff88811b6a7ac0 R15: 1ffff110236d4f76
FS: 00007f2e9eb47700(0000) GS:ffff8881f6b00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b2e421000 CR3: 000000010e6d4000 CR4: 00000000003526e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
&lt;TASK&gt;
[&lt;ffffffff8471a49f&gt;] netdev_start_xmit include/linux/netdevice.h:4925 [inline]
[&lt;ffffffff8471a49f&gt;] __dev_direct_xmit+0x4ef/0x850 net/core/dev.c:4380
[&lt;ffffffff851d845b&gt;] dev_direct_xmit include/linux/netdevice.h:3043 [inline]
[&lt;ffffffff851d845b&gt;] packet_direct_xmit+0x18b/0x300 net/packet/af_packet.c:284
[&lt;ffffffff851c7472&gt;] packet_snd net/packet/af_packet.c:3112 [inline]
[&lt;ffffffff851c7472&gt;] packet_sendmsg+0x4a22/0x64d0 net/packet/af_packet.c:3143
[&lt;ffffffff8467a4b2&gt;] sock_sendmsg_nosec net/socket.c:716 [inline]
[&lt;ffffffff8467a4b2&gt;] sock_sendmsg net/socket.c:736 [inline]
[&lt;ffffffff8467a4b2&gt;] __sys_sendto+0x472/0x5f0 net/socket.c:2139
[&lt;ffffffff8467a715&gt;] __do_sys_sendto net/socket.c:2151 [inline]
[&lt;ffffffff8467a715&gt;] __se_sys_sendto net/socket.c:2147 [inline]
[&lt;ffffffff8467a715&gt;] __x64_sys_sendto+0xe5/0x100 net/socket.c:2147
[&lt;ffffffff8553071f&gt;] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
[&lt;ffffffff8553071f&gt;] do_syscall_64+0x2f/0x50 arch/x86/entry/common.c:80
[&lt;ffffffff85600087&gt;] entry_SYSCALL_64_after_hwframe+0x63/0xcd</Note>
    </Notes>
    <CVE>CVE-2023-53601</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 memory leak in WMI firmware stats

Memory allocated for firmware pdev, vdev and beacon statistics
are not released during rmmod.

Fix it by calling ath11k_fw_stats_free() function before hardware
unregister.

While at it, avoid calling ath11k_fw_stats_free() while processing
the firmware stats received in the WMI event because the local list
is getting spliced and reinitialised and hence there are no elements
in the list after splicing.

Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1</Note>
    </Notes>
    <CVE>CVE-2023-53602</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: qla2xxx: Avoid fcport pointer dereference

Klocwork reported warning of NULL pointer may be dereferenced.  The routine
exits when sa_ctl is NULL and fcport is allocated after the exit call thus
causing NULL fcport pointer to dereference at the time of exit.

To avoid fcport pointer dereference, exit the routine when sa_ctl is NULL.</Note>
    </Notes>
    <CVE>CVE-2023-53603</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ipmi_si: fix a memleak in try_smi_init()

Kmemleak reported the following leak info in try_smi_init():

unreferenced object 0xffff00018ecf9400 (size 1024):
  comm "modprobe", pid 2707763, jiffies 4300851415 (age 773.308s)
  backtrace:
    [&lt;000000004ca5b312&gt;] __kmalloc+0x4b8/0x7b0
    [&lt;00000000953b1072&gt;] try_smi_init+0x148/0x5dc [ipmi_si]
    [&lt;000000006460d325&gt;] 0xffff800081b10148
    [&lt;0000000039206ea5&gt;] do_one_initcall+0x64/0x2a4
    [&lt;00000000601399ce&gt;] do_init_module+0x50/0x300
    [&lt;000000003c12ba3c&gt;] load_module+0x7a8/0x9e0
    [&lt;00000000c246fffe&gt;] __se_sys_init_module+0x104/0x180
    [&lt;00000000eea99093&gt;] __arm64_sys_init_module+0x24/0x30
    [&lt;0000000021b1ef87&gt;] el0_svc_common.constprop.0+0x94/0x250
    [&lt;0000000070f4f8b7&gt;] do_el0_svc+0x48/0xe0
    [&lt;000000005a05337f&gt;] el0_svc+0x24/0x3c
    [&lt;000000005eb248d6&gt;] el0_sync_handler+0x160/0x164
    [&lt;0000000030a59039&gt;] el0_sync+0x160/0x180

The problem was that when an error occurred before handlers registration
and after allocating `new_smi-&gt;si_sm`, the variable wouldn't be freed in
the error handling afterwards since `shutdown_smi()` hadn't been
registered yet. Fix it by adding a `kfree()` in the error handling path
in `try_smi_init()`.</Note>
    </Notes>
    <CVE>CVE-2023-53611</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

dax: Fix dax_mapping_release() use after free

A CONFIG_DEBUG_KOBJECT_RELEASE test of removing a device-dax region
provider (like modprobe -r dax_hmem) yields:

 kobject: 'mapping0' (ffff93eb460e8800): kobject_release, parent 0000000000000000 (delayed 2000)
 [..]
 DEBUG_LOCKS_WARN_ON(1)
 WARNING: CPU: 23 PID: 282 at kernel/locking/lockdep.c:232 __lock_acquire+0x9fc/0x2260
 [..]
 RIP: 0010:__lock_acquire+0x9fc/0x2260
 [..]
 Call Trace:
  &lt;TASK&gt;
 [..]
  lock_acquire+0xd4/0x2c0
  ? ida_free+0x62/0x130
  _raw_spin_lock_irqsave+0x47/0x70
  ? ida_free+0x62/0x130
  ida_free+0x62/0x130
  dax_mapping_release+0x1f/0x30
  device_release+0x36/0x90
  kobject_delayed_cleanup+0x46/0x150

Due to attempting ida_free() on an ida object that has already been
freed. Devices typically only hold a reference on their parent while
registered. If a child needs a parent object to complete its release it
needs to hold a reference that it drops from its release callback.
Arrange for a dax_mapping to pin its parent dev_dax instance until
dax_mapping_release().</Note>
    </Notes>
    <CVE>CVE-2023-53613</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: qla2xxx: Fix deletion race condition

System crash when using debug kernel due to link list corruption. The cause
of the link list corruption is due to session deletion was allowed to queue
up twice.  Here's the internal trace that show the same port was allowed to
double queue for deletion on different cpu.

20808683956 015 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 1
20808683957 027 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 1

Move the clearing/setting of deleted flag lock.</Note>
    </Notes>
    <CVE>CVE-2023-53615</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 invalid free of JFS_IP(ipimap)-&gt;i_imap in diUnmount

syzbot found an invalid-free in diUnmount:

BUG: KASAN: double-free in slab_free mm/slub.c:3661 [inline]
BUG: KASAN: double-free in __kmem_cache_free+0x71/0x110 mm/slub.c:3674
Free of addr ffff88806f410000 by task syz-executor131/3632

 CPU: 0 PID: 3632 Comm: syz-executor131 Not tainted 6.1.0-rc7-syzkaller-00012-gca57f02295f1 #0
 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
 Call Trace:
  &lt;TASK&gt;
  __dump_stack lib/dump_stack.c:88 [inline]
  dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106
  print_address_description+0x74/0x340 mm/kasan/report.c:284
  print_report+0x107/0x1f0 mm/kasan/report.c:395
  kasan_report_invalid_free+0xac/0xd0 mm/kasan/report.c:460
  ____kasan_slab_free+0xfb/0x120
  kasan_slab_free include/linux/kasan.h:177 [inline]
  slab_free_hook mm/slub.c:1724 [inline]
  slab_free_freelist_hook+0x12e/0x1a0 mm/slub.c:1750
  slab_free mm/slub.c:3661 [inline]
  __kmem_cache_free+0x71/0x110 mm/slub.c:3674
  diUnmount+0xef/0x100 fs/jfs/jfs_imap.c:195
  jfs_umount+0x108/0x370 fs/jfs/jfs_umount.c:63
  jfs_put_super+0x86/0x190 fs/jfs/super.c:194
  generic_shutdown_super+0x130/0x310 fs/super.c:492
  kill_block_super+0x79/0xd0 fs/super.c:1428
  deactivate_locked_super+0xa7/0xf0 fs/super.c:332
  cleanup_mnt+0x494/0x520 fs/namespace.c:1186
  task_work_run+0x243/0x300 kernel/task_work.c:179
  exit_task_work include/linux/task_work.h:38 [inline]
  do_exit+0x664/0x2070 kernel/exit.c:820
  do_group_exit+0x1fd/0x2b0 kernel/exit.c:950
  __do_sys_exit_group kernel/exit.c:961 [inline]
  __se_sys_exit_group kernel/exit.c:959 [inline]
  __x64_sys_exit_group+0x3b/0x40 kernel/exit.c:959
  do_syscall_x64 arch/x86/entry/common.c:50 [inline]
  do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
  entry_SYSCALL_64_after_hwframe+0x63/0xcd
[...]

JFS_IP(ipimap)-&gt;i_imap is not setting to NULL after free in diUnmount.
If jfs_remount() free JFS_IP(ipimap)-&gt;i_imap but then failed at diMount().
JFS_IP(ipimap)-&gt;i_imap will be freed once again.
Fix this problem by setting JFS_IP(ipimap)-&gt;i_imap to NULL after free.</Note>
    </Notes>
    <CVE>CVE-2023-53616</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: socinfo: Add kfree for kstrdup

Add kfree() in the later error handling in order to avoid memory leak.</Note>
    </Notes>
    <CVE>CVE-2023-53617</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: reject invalid reloc tree root keys with stack dump

[BUG]
Syzbot reported a crash that an ASSERT() got triggered inside
prepare_to_merge().

That ASSERT() makes sure the reloc tree is properly pointed back by its
subvolume tree.

[CAUSE]
After more debugging output, it turns out we had an invalid reloc tree:

  BTRFS error (device loop1): reloc tree mismatch, root 8 has no reloc root, expect reloc root key (-8, 132, 8) gen 17

Note the above root key is (TREE_RELOC_OBJECTID, ROOT_ITEM,
QUOTA_TREE_OBJECTID), meaning it's a reloc tree for quota tree.

But reloc trees can only exist for subvolumes, as for non-subvolume
trees, we just COW the involved tree block, no need to create a reloc
tree since those tree blocks won't be shared with other trees.

Only subvolumes tree can share tree blocks with other trees (thus they
have BTRFS_ROOT_SHAREABLE flag).

Thus this new debug output proves my previous assumption that corrupted
on-disk data can trigger that ASSERT().

[FIX]
Besides the dedicated fix and the graceful exit, also let tree-checker to
check such root keys, to make sure reloc trees can only exist for subvolumes.</Note>
    </Notes>
    <CVE>CVE-2023-53618</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: conntrack: Avoid nf_ct_helper_hash uses after free

If nf_conntrack_init_start() fails (for example due to a
register_nf_conntrack_bpf() failure), the nf_conntrack_helper_fini()
clean-up path frees the nf_ct_helper_hash map.

When built with NF_CONNTRACK=y, further netfilter modules (e.g:
netfilter_conntrack_ftp) can still be loaded and call
nf_conntrack_helpers_register(), independently of whether nf_conntrack
initialized correctly. This accesses the nf_ct_helper_hash dangling
pointer and causes a uaf, possibly leading to random memory corruption.

This patch guards nf_conntrack_helper_register() from accessing a freed
or uninitialized nf_ct_helper_hash pointer and fixes possible
uses-after-free when loading a conntrack module.</Note>
    </Notes>
    <CVE>CVE-2023-53619</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

memcontrol: ensure memcg acquired by id is properly set up

In the eviction recency check, we attempt to retrieve the memcg to which
the folio belonged when it was evicted, by the memcg id stored in the
shadow entry.  However, there is a chance that the retrieved memcg is not
the original memcg that has been killed, but a new one which happens to
have the same id.

This is a somewhat unfortunate, but acceptable and rare inaccuracy in the
heuristics.  However, if we retrieve this new memcg between its allocation
and when it is properly attached to the memcg hierarchy, we could run into
the following NULL pointer exception during the memcg hierarchy traversal
done in mem_cgroup_get_nr_swap_pages():

[ 155757.793456] BUG: kernel NULL pointer dereference, address: 00000000000000c0
[ 155757.807568] #PF: supervisor read access in kernel mode
[ 155757.818024] #PF: error_code(0x0000) - not-present page
[ 155757.828482] PGD 401f77067 P4D 401f77067 PUD 401f76067 PMD 0
[ 155757.839985] Oops: 0000 [#1] SMP
[ 155757.887870] RIP: 0010:mem_cgroup_get_nr_swap_pages+0x3d/0xb0
[ 155757.899377] Code: 29 19 4a 02 48 39 f9 74 63 48 8b 97 c0 00 00 00 48 8b b7 58 02 00 00 48 2b b7 c0 01 00 00 48 39 f0 48 0f 4d c6 48 39 d1 74 42 &lt;48&gt; 8b b2 c0 00 00 00 48 8b ba 58 02 00 00 48 2b ba c0 01 00 00 48
[ 155757.937125] RSP: 0018:ffffc9002ecdfbc8 EFLAGS: 00010286
[ 155757.947755] RAX: 00000000003a3b1c RBX: 000007ffffffffff RCX: ffff888280183000
[ 155757.962202] RDX: 0000000000000000 RSI: 0007ffffffffffff RDI: ffff888bbc2d1000
[ 155757.976648] RBP: 0000000000000001 R08: 000000000000000b R09: ffff888ad9cedba0
[ 155757.991094] R10: ffffea0039c07900 R11: 0000000000000010 R12: ffff888b23a7b000
[ 155758.005540] R13: 0000000000000000 R14: ffff888bbc2d1000 R15: 000007ffffc71354
[ 155758.019991] FS:  00007f6234c68640(0000) GS:ffff88903f9c0000(0000) knlGS:0000000000000000
[ 155758.036356] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 155758.048023] CR2: 00000000000000c0 CR3: 0000000a83eb8004 CR4: 00000000007706e0
[ 155758.062473] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 155758.076924] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 155758.091376] PKRU: 55555554
[ 155758.096957] Call Trace:
[ 155758.102016]  &lt;TASK&gt;
[ 155758.106502]  ? __die+0x78/0xc0
[ 155758.112793]  ? page_fault_oops+0x286/0x380
[ 155758.121175]  ? exc_page_fault+0x5d/0x110
[ 155758.129209]  ? asm_exc_page_fault+0x22/0x30
[ 155758.137763]  ? mem_cgroup_get_nr_swap_pages+0x3d/0xb0
[ 155758.148060]  workingset_test_recent+0xda/0x1b0
[ 155758.157133]  workingset_refault+0xca/0x1e0
[ 155758.165508]  filemap_add_folio+0x4d/0x70
[ 155758.173538]  page_cache_ra_unbounded+0xed/0x190
[ 155758.182919]  page_cache_sync_ra+0xd6/0x1e0
[ 155758.191738]  filemap_read+0x68d/0xdf0
[ 155758.199495]  ? mlx5e_napi_poll+0x123/0x940
[ 155758.207981]  ? __napi_schedule+0x55/0x90
[ 155758.216095]  __x64_sys_pread64+0x1d6/0x2c0
[ 155758.224601]  do_syscall_64+0x3d/0x80
[ 155758.232058]  entry_SYSCALL_64_after_hwframe+0x46/0xb0
[ 155758.242473] RIP: 0033:0x7f62c29153b5
[ 155758.249938] Code: e8 48 89 75 f0 89 7d f8 48 89 4d e0 e8 b4 e6 f7 ff 41 89 c0 4c 8b 55 e0 48 8b 55 e8 48 8b 75 f0 8b 7d f8 b8 11 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 33 44 89 c7 48 89 45 f8 e8 e7 e6 f7 ff 48 8b
[ 155758.288005] RSP: 002b:00007f6234c5ffd0 EFLAGS: 00000293 ORIG_RAX: 0000000000000011
[ 155758.303474] RAX: ffffffffffffffda RBX: 00007f628c4e70c0 RCX: 00007f62c29153b5
[ 155758.318075] RDX: 000000000003c041 RSI: 00007f61d2986000 RDI: 0000000000000076
[ 155758.332678] RBP: 00007f6234c5fff0 R08: 0000000000000000 R09: 0000000064d5230c
[ 155758.347452] R10: 000000000027d450 R11: 0000000000000293 R12: 000000000003c041
[ 155758.362044] R13: 00007f61d2986000 R14: 00007f629e11b060 R15: 000000000027d450
[ 155758.376661]  &lt;/TASK&gt;

This patch fixes the issue by moving the memcg's id publication from the
alloc stage to 
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-53621</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

gfs2: Fix possible data races in gfs2_show_options()

Some fields such as gt_logd_secs of the struct gfs2_tune are accessed
without holding the lock gt_spin in gfs2_show_options():

  val = sdp-&gt;sd_tune.gt_logd_secs;
  if (val != 30)
    seq_printf(s, ",commit=%d", val);

And thus can cause data races when gfs2_show_options() and other functions
such as gfs2_reconfigure() are concurrently executed:

  spin_lock(&amp;gt-&gt;gt_spin);
  gt-&gt;gt_logd_secs = newargs-&gt;ar_commit;

To fix these possible data races, the lock sdp-&gt;sd_tune.gt_spin is
acquired before accessing the fields of gfs2_tune and released after these
accesses.

Further changes by Andreas:

- Don't hold the spin lock over the seq_printf operations.</Note>
    </Notes>
    <CVE>CVE-2023-53622</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-sysman: Fix reference leak

If a duplicate attribute is found using kset_find_obj(),
a reference to that attribute is returned. This means
that we need to dispose it accordingly. Use kobject_put()
to dispose the duplicate attribute in such a case.

Compile-tested only.</Note>
    </Notes>
    <CVE>CVE-2023-53631</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Take RTNL lock when needed before calling xdp_set_features()

Hold RTNL lock when calling xdp_set_features() with a registered netdev,
as the call triggers the netdev notifiers. This could happen when
switching from uplink rep to nic profile for example.

This resolves the following call trace:

RTNL: assertion failed at net/core/dev.c (1953)
WARNING: CPU: 6 PID: 112670 at net/core/dev.c:1953 call_netdevice_notifiers_info+0x7c/0x80
Modules linked in: sch_mqprio sch_mqprio_lib act_tunnel_key act_mirred act_skbedit cls_matchall nfnetlink_cttimeout act_gact cls_flower sch_ingress bonding ib_umad ip_gre rdma_ucm mlx5_vfio_pci ipip tunnel4 ip6_gre gre mlx5_ib vfio_pci vfio_pci_core vfio_iommu_type1 ib_uverbs vfio mlx5_core ib_ipoib geneve nf_tables ip6_tunnel tunnel6 iptable_raw openvswitch nsh rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay zram zsmalloc fuse [last unloaded: ib_uverbs]
CPU: 6 PID: 112670 Comm: devlink Not tainted 6.4.0-rc7_for_upstream_min_debug_2023_06_28_17_02 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:call_netdevice_notifiers_info+0x7c/0x80
Code: 90 ff 80 3d 2d 6b f7 00 00 75 c5 ba a1 07 00 00 48 c7 c6 e4 ce 0b 82 48 c7 c7 c8 f4 04 82 c6 05 11 6b f7 00 01 e8 a4 7c 8e ff &lt;0f&gt; 0b eb a2 0f 1f 44 00 00 55 48 89 e5 41 54 48 83 e4 f0 48 83 ec
RSP: 0018:ffff8882a21c3948 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffffffff82e6f880 RCX: 0000000000000027
RDX: ffff88885f99b5c8 RSI: 0000000000000001 RDI: ffff88885f99b5c0
RBP: 0000000000000028 R08: ffff88887ffabaa8 R09: 0000000000000003
R10: ffff88887fecbac0 R11: ffff88887ff7bac0 R12: ffff8882a21c3968
R13: ffff88811c018940 R14: 0000000000000000 R15: ffff8881274401a0
FS:  00007fe141c81800(0000) GS:ffff88885f980000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f787c28b948 CR3: 000000014bcf3005 CR4: 0000000000370ea0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
 ? __warn+0x79/0x120
 ? call_netdevice_notifiers_info+0x7c/0x80
 ? report_bug+0x17c/0x190
 ? handle_bug+0x3c/0x60
 ? exc_invalid_op+0x14/0x70
 ? asm_exc_invalid_op+0x16/0x20
 ? call_netdevice_notifiers_info+0x7c/0x80
 ? call_netdevice_notifiers_info+0x7c/0x80
 call_netdevice_notifiers+0x2e/0x50
 mlx5e_set_xdp_feature+0x21/0x50 [mlx5_core]
 mlx5e_nic_init+0xf1/0x1a0 [mlx5_core]
 mlx5e_netdev_init_profile+0x76/0x110 [mlx5_core]
 mlx5e_netdev_attach_profile+0x1f/0x90 [mlx5_core]
 mlx5e_netdev_change_profile+0x92/0x160 [mlx5_core]
 mlx5e_netdev_attach_nic_profile+0x1b/0x30 [mlx5_core]
 mlx5e_vport_rep_unload+0xaa/0xc0 [mlx5_core]
 __esw_offloads_unload_rep+0x52/0x60 [mlx5_core]
 mlx5_esw_offloads_rep_unload+0x52/0x70 [mlx5_core]
 esw_offloads_unload_rep+0x34/0x70 [mlx5_core]
 esw_offloads_disable+0x2b/0x90 [mlx5_core]
 mlx5_eswitch_disable_locked+0x1b9/0x210 [mlx5_core]
 mlx5_devlink_eswitch_mode_set+0xf5/0x630 [mlx5_core]
 ? devlink_get_from_attrs_lock+0x9e/0x110
 devlink_nl_cmd_eswitch_set_doit+0x60/0xe0
 genl_family_rcv_msg_doit.isra.0+0xc2/0x110
 genl_rcv_msg+0x17d/0x2b0
 ? devlink_get_from_attrs_lock+0x110/0x110
 ? devlink_nl_cmd_eswitch_get_doit+0x290/0x290
 ? devlink_pernet_pre_exit+0xf0/0xf0
 ? genl_family_rcv_msg_doit.isra.0+0x110/0x110
 netlink_rcv_skb+0x54/0x100
 genl_rcv+0x24/0x40
 netlink_unicast+0x1f6/0x2c0
 netlink_sendmsg+0x232/0x4a0
 sock_sendmsg+0x38/0x60
 ? _copy_from_user+0x2a/0x60
 __sys_sendto+0x110/0x160
 ? __count_memcg_events+0x48/0x90
 ? handle_mm_fault+0x161/0x260
 ? do_user_addr_fault+0x278/0x6e0
 __x64_sys_sendto+0x20/0x30
 do_syscall_64+0x3d/0x90
 entry_SYSCALL_64_after_hwframe+0x46/0xb0
RIP: 0033
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-53632</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/qaic: Fix a leak in map_user_pages()

If get_user_pages_fast() allocates some pages but not as many as we
wanted, then the current code leaks those pages.  Call put_page() on
the pages before returning.</Note>
    </Notes>
    <CVE>CVE-2023-53633</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:

octeon_ep: cancel queued works in probe error path

If it fails to get the devices's MAC address, octep_probe exits while
leaving the delayed work intr_poll_task queued. When the work later
runs, it's a use after free.

Move the cancelation of intr_poll_task from octep_remove into
octep_device_cleanup. This does not change anything in the octep_remove
flow, but octep_device_cleanup is called also in the octep_probe error
path, where the cancelation is needed.

Note that the cancelation of ctrl_mbox_task has to follow
intr_poll_task's, because the ctrl_mbox_task may be queued by
intr_poll_task.</Note>
    </Notes>
    <CVE>CVE-2023-53638</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Make bpf_refcount_acquire fallible for non-owning refs

This patch fixes an incorrect assumption made in the original
bpf_refcount series [0], specifically that the BPF program calling
bpf_refcount_acquire on some node can always guarantee that the node is
alive. In that series, the patch adding failure behavior to rbtree_add
and list_push_{front, back} breaks this assumption for non-owning
references.

Consider the following program:

  n = bpf_kptr_xchg(&amp;mapval, NULL);
  /* skip error checking */

  bpf_spin_lock(&amp;l);
  if(bpf_rbtree_add(&amp;t, &amp;n-&gt;rb, less)) {
    bpf_refcount_acquire(n);
    /* Failed to add, do something else with the node */
  }
  bpf_spin_unlock(&amp;l);

It's incorrect to assume that bpf_refcount_acquire will always succeed in this
scenario. bpf_refcount_acquire is being called in a critical section
here, but the lock being held is associated with rbtree t, which isn't
necessarily the lock associated with the tree that the node is already
in. So after bpf_rbtree_add fails to add the node and calls bpf_obj_drop
in it, the program has no ownership of the node's lifetime. Therefore
the node's refcount can be decr'd to 0 at any time after the failing
rbtree_add. If this happens before the refcount_acquire above, the node
might be free'd, and regardless refcount_acquire will be incrementing a
0 refcount.

Later patches in the series exercise this scenario, resulting in the
expected complaint from the kernel (without this patch's changes):

  refcount_t: addition on 0; use-after-free.
  WARNING: CPU: 1 PID: 207 at lib/refcount.c:25 refcount_warn_saturate+0xbc/0x110
  Modules linked in: bpf_testmod(O)
  CPU: 1 PID: 207 Comm: test_progs Tainted: G           O       6.3.0-rc7-02231-g723de1a718a2-dirty #371
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
  RIP: 0010:refcount_warn_saturate+0xbc/0x110
  Code: 6f 64 f6 02 01 e8 84 a3 5c ff 0f 0b eb 9d 80 3d 5e 64 f6 02 00 75 94 48 c7 c7 e0 13 d2 82 c6 05 4e 64 f6 02 01 e8 64 a3 5c ff &lt;0f&gt; 0b e9 7a ff ff ff 80 3d 38 64 f6 02 00 0f 85 6d ff ff ff 48 c7
  RSP: 0018:ffff88810b9179b0 EFLAGS: 00010082
  RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000000
  RDX: 0000000000000202 RSI: 0000000000000008 RDI: ffffffff857c3680
  RBP: ffff88810027d3c0 R08: ffffffff8125f2a4 R09: ffff88810b9176e7
  R10: ffffed1021722edc R11: 746e756f63666572 R12: ffff88810027d388
  R13: ffff88810027d3c0 R14: ffffc900005fe030 R15: ffffc900005fe048
  FS:  00007fee0584a700(0000) GS:ffff88811b280000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00005634a96f6c58 CR3: 0000000108ce9002 CR4: 0000000000770ee0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
  PKRU: 55555554
  Call Trace:
   &lt;TASK&gt;
   bpf_refcount_acquire_impl+0xb5/0xc0

  (rest of output snipped)

The patch addresses this by changing bpf_refcount_acquire_impl to use
refcount_inc_not_zero instead of refcount_inc and marking
bpf_refcount_acquire KF_RET_NULL.

For owning references, though, we know the above scenario is not possible
and thus that bpf_refcount_acquire will always succeed. Some verifier
bookkeeping is added to track "is input owning ref?" for bpf_refcount_acquire
calls and return false from is_kfunc_ret_null for bpf_refcount_acquire on
owning refs despite it being marked KF_RET_NULL.

Existing selftests using bpf_refcount_acquire are modified where
necessary to NULL-check its return value.

  [0]: https://lore.kernel.org/bpf/20230415201811.343116-1-davemarchevsky@fb.com/</Note>
    </Notes>
    <CVE>CVE-2023-53645</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/perf: add sentinel to xehp_oa_b_counters

Arrays passed to reg_in_range_table should end with empty record.

The patch solves KASAN detected bug with signature:
BUG: KASAN: global-out-of-bounds in xehp_is_valid_b_counter_addr+0x2c7/0x350 [i915]
Read of size 4 at addr ffffffffa1555d90 by task perf/1518

CPU: 4 PID: 1518 Comm: perf Tainted: G U 6.4.0-kasan_438-g3303d06107f3+ #1
Hardware name: Intel Corporation Meteor Lake Client Platform/MTL-P DDR5 SODIMM SBS RVP, BIOS MTLPFWI1.R00.3223.D80.2305311348 05/31/2023
Call Trace:
&lt;TASK&gt;
...
xehp_is_valid_b_counter_addr+0x2c7/0x350 [i915]

(cherry picked from commit 2f42c5afb34b5696cf5fe79e744f99be9b218798)</Note>
    </Notes>
    <CVE>CVE-2023-53646</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: hv: vmbus: Don't dereference ACPI root object handle

Since the commit referenced in the Fixes: tag below the VMBus client driver
is walking the ACPI namespace up from the VMBus ACPI device to the ACPI
namespace root object trying to find Hyper-V MMIO ranges.

However, if it is not able to find them it ends trying to walk resources of
the ACPI namespace root object itself.
This object has all-ones handle, which causes a NULL pointer dereference
in the ACPI code (from dereferencing this pointer with an offset).

This in turn causes an oops on boot with VMBus host implementations that do
not provide Hyper-V MMIO ranges in their VMBus ACPI device or its
ancestors.
The QEMU VMBus implementation is an example of such implementation.

I guess providing these ranges is optional, since all tested Windows
versions seem to be able to use VMBus devices without them.

Fix this by explicitly terminating the lookup at the ACPI namespace root
object.

Note that Linux guests under KVM/QEMU do not use the Hyper-V PV interface
by default - they only do so if the KVM PV interface is missing or
disabled.

Example stack trace of such oops:
[ 3.710827] ? __die+0x1f/0x60
[ 3.715030] ? page_fault_oops+0x159/0x460
[ 3.716008] ? exc_page_fault+0x73/0x170
[ 3.716959] ? asm_exc_page_fault+0x22/0x30
[ 3.717957] ? acpi_ns_lookup+0x7a/0x4b0
[ 3.718898] ? acpi_ns_internalize_name+0x79/0xc0
[ 3.720018] acpi_ns_get_node_unlocked+0xb5/0xe0
[ 3.721120] ? acpi_ns_check_object_type+0xfe/0x200
[ 3.722285] ? acpi_rs_convert_aml_to_resource+0x37/0x6e0
[ 3.723559] ? down_timeout+0x3a/0x60
[ 3.724455] ? acpi_ns_get_node+0x3a/0x60
[ 3.725412] acpi_ns_get_node+0x3a/0x60
[ 3.726335] acpi_ns_evaluate+0x1c3/0x2c0
[ 3.727295] acpi_ut_evaluate_object+0x64/0x1b0
[ 3.728400] acpi_rs_get_method_data+0x2b/0x70
[ 3.729476] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus]
[ 3.730940] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus]
[ 3.732411] acpi_walk_resources+0x78/0xd0
[ 3.733398] vmbus_platform_driver_probe+0x9f/0x1d0 [hv_vmbus]
[ 3.734802] platform_probe+0x3d/0x90
[ 3.735684] really_probe+0x19b/0x400
[ 3.736570] ? __device_attach_driver+0x100/0x100
[ 3.737697] __driver_probe_device+0x78/0x160
[ 3.738746] driver_probe_device+0x1f/0x90
[ 3.739743] __driver_attach+0xc2/0x1b0
[ 3.740671] bus_for_each_dev+0x70/0xc0
[ 3.741601] bus_add_driver+0x10e/0x210
[ 3.742527] driver_register+0x55/0xf0
[ 3.744412] ? 0xffffffffc039a000
[ 3.745207] hv_acpi_init+0x3c/0x1000 [hv_vmbus]</Note>
    </Notes>
    <CVE>CVE-2023-53647</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ac97: Fix possible NULL dereference in snd_ac97_mixer

smatch error:
sound/pci/ac97/ac97_codec.c:2354 snd_ac97_mixer() error:
we previously assumed 'rac97' could be null (see line 2072)

remove redundant assignment, return error if rac97 is NULL.</Note>
    </Notes>
    <CVE>CVE-2023-53648</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 trace: Really free the evsel-&gt;priv area

In 3cb4d5e00e037c70 ("perf trace: Free syscall tp fields in
evsel-&gt;priv") it only was freeing if strcmp(evsel-&gt;tp_format-&gt;system,
"syscalls") returned zero, while the corresponding initialization of
evsel-&gt;priv was being performed if it was _not_ zero, i.e. if the tp
system wasn't 'syscalls'.

Just stop looking for that and free it if evsel-&gt;priv was set, which
should be equivalent.

Also use the pre-existing evsel_trace__delete() function.

This resolves these leaks, detected with:

  $ make EXTRA_CFLAGS="-fsanitize=address" BUILD_BPF_SKEL=1 CORESIGHT=1 O=/tmp/build/perf-tools-next -C tools/perf install-bin

  =================================================================
  ==481565==ERROR: LeakSanitizer: detected memory leaks

  Direct leak of 40 byte(s) in 1 object(s) allocated from:
      #0 0x7f7343cba097 in calloc (/lib64/libasan.so.8+0xba097)
      #1 0x987966 in zalloc (/home/acme/bin/perf+0x987966)
      #2 0x52f9b9 in evsel_trace__new /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:307
      #3 0x52f9b9 in evsel__syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:333
      #4 0x52f9b9 in evsel__init_raw_syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:458
      #5 0x52f9b9 in perf_evsel__raw_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:480
      #6 0x540e8b in trace__add_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3212
      #7 0x540e8b in trace__run /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3891
      #8 0x540e8b in cmd_trace /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:5156
      #9 0x5ef262 in run_builtin /home/acme/git/perf-tools-next/tools/perf/perf.c:323
      #10 0x4196da in handle_internal_command /home/acme/git/perf-tools-next/tools/perf/perf.c:377
      #11 0x4196da in run_argv /home/acme/git/perf-tools-next/tools/perf/perf.c:421
      #12 0x4196da in main /home/acme/git/perf-tools-next/tools/perf/perf.c:537
      #13 0x7f7342c4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)

  Direct leak of 40 byte(s) in 1 object(s) allocated from:
      #0 0x7f7343cba097 in calloc (/lib64/libasan.so.8+0xba097)
      #1 0x987966 in zalloc (/home/acme/bin/perf+0x987966)
      #2 0x52f9b9 in evsel_trace__new /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:307
      #3 0x52f9b9 in evsel__syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:333
      #4 0x52f9b9 in evsel__init_raw_syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:458
      #5 0x52f9b9 in perf_evsel__raw_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:480
      #6 0x540dd1 in trace__add_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3205
      #7 0x540dd1 in trace__run /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3891
      #8 0x540dd1 in cmd_trace /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:5156
      #9 0x5ef262 in run_builtin /home/acme/git/perf-tools-next/tools/perf/perf.c:323
      #10 0x4196da in handle_internal_command /home/acme/git/perf-tools-next/tools/perf/perf.c:377
      #11 0x4196da in run_argv /home/acme/git/perf-tools-next/tools/perf/perf.c:421
      #12 0x4196da in main /home/acme/git/perf-tools-next/tools/perf/perf.c:537
      #13 0x7f7342c4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)

  SUMMARY: AddressSanitizer: 80 byte(s) leaked in 2 allocation(s).
  [root@quaco ~]#

With this we plug all leaks with "perf trace sleep 1".</Note>
    </Notes>
    <CVE>CVE-2023-53649</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: lcd_mipid: Fix an error handling path in mipid_spi_probe()

If 'mipid_detect()' fails, we must free 'md' to avoid a memory leak.</Note>
    </Notes>
    <CVE>CVE-2023-53650</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vdpa: Add features attr to vdpa_nl_policy for nlattr length check

The vdpa_nl_policy structure is used to validate the nlattr when parsing
the incoming nlmsg. It will ensure the attribute being described produces
a valid nlattr pointer in info-&gt;attrs before entering into each handler
in vdpa_nl_ops.

That is to say, the missing part in vdpa_nl_policy may lead to illegal
nlattr after parsing, which could lead to OOB read just like CVE-2023-3773.

This patch adds the missing nla_policy for vdpa features attr to avoid
such bugs.</Note>
    </Notes>
    <CVE>CVE-2023-53652</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: amphion: fix REVERSE_INULL issues reported by coverity

null-checking of a pointor is suggested before dereferencing it</Note>
    </Notes>
    <CVE>CVE-2023-53653</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

octeontx2-af: Add validation before accessing cgx and lmac

with the addition of new MAC blocks like CN10K RPM and CN10KB
RPM_USX, LMACs are noncontiguous and CGX blocks are also
noncontiguous. But during RVU driver initialization, the driver
is assuming they are contiguous and trying to access
cgx or lmac with their id which is resulting in kernel panic.

This patch fixes the issue by adding proper checks.

[   23.219150] pc : cgx_lmac_read+0x38/0x70
[   23.219154] lr : rvu_program_channels+0x3f0/0x498
[   23.223852] sp : ffff000100d6fc80
[   23.227158] x29: ffff000100d6fc80 x28: ffff00010009f880 x27:
000000000000005a
[   23.234288] x26: ffff000102586768 x25: 0000000000002500 x24:
fffffffffff0f000</Note>
    </Notes>
    <CVE>CVE-2023-53654</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/perf: hisi: Don't migrate perf to the CPU going to teardown

The driver needs to migrate the perf context if the current using CPU going
to teardown. By the time calling the cpuhp::teardown() callback the
cpu_online_mask() hasn't updated yet and still includes the CPU going to
teardown. In current driver's implementation we may migrate the context
to the teardown CPU and leads to the below calltrace:

...
[  368.104662][  T932] task:cpuhp/0         state:D stack:    0 pid:   15 ppid:     2 flags:0x00000008
[  368.113699][  T932] Call trace:
[  368.116834][  T932]  __switch_to+0x7c/0xbc
[  368.120924][  T932]  __schedule+0x338/0x6f0
[  368.125098][  T932]  schedule+0x50/0xe0
[  368.128926][  T932]  schedule_preempt_disabled+0x18/0x24
[  368.134229][  T932]  __mutex_lock.constprop.0+0x1d4/0x5dc
[  368.139617][  T932]  __mutex_lock_slowpath+0x1c/0x30
[  368.144573][  T932]  mutex_lock+0x50/0x60
[  368.148579][  T932]  perf_pmu_migrate_context+0x84/0x2b0
[  368.153884][  T932]  hisi_pcie_pmu_offline_cpu+0x90/0xe0 [hisi_pcie_pmu]
[  368.160579][  T932]  cpuhp_invoke_callback+0x2a0/0x650
[  368.165707][  T932]  cpuhp_thread_fun+0xe4/0x190
[  368.170316][  T932]  smpboot_thread_fn+0x15c/0x1a0
[  368.175099][  T932]  kthread+0x108/0x13c
[  368.179012][  T932]  ret_from_fork+0x10/0x18
...

Use function cpumask_any_but() to find one correct active cpu to fixes
this issue.</Note>
    </Notes>
    <CVE>CVE-2023-53656</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Don't tx before switchdev is fully configured

There is possibility that ice_eswitch_port_start_xmit might be
called while some resources are still not allocated which might
cause NULL pointer dereference. Fix this by checking if switchdev
configuration was finished.</Note>
    </Notes>
    <CVE>CVE-2023-53657</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: bcm-qspi: return error if neither hif_mspi nor mspi is available

If neither a "hif_mspi" nor "mspi" resource is present, the driver will
just early exit in probe but still return success. Apart from not doing
anything meaningful, this would then also lead to a null pointer access
on removal, as platform_get_drvdata() would return NULL, which it would
then try to dereference when trying to unregister the spi master.

Fix this by unconditionally calling devm_ioremap_resource(), as it can
handle a NULL res and will then return a viable ERR_PTR() if we get one.

The "return 0;" was previously a "goto qspi_resource_err;" where then
ret was returned, but since ret was still initialized to 0 at this place
this was a valid conversion in 63c5395bb7a9 ("spi: bcm-qspi: Fix
use-after-free on unbind"). The issue was not introduced by this commit,
only made more obvious.</Note>
    </Notes>
    <CVE>CVE-2023-53658</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iavf: Fix out-of-bounds when setting channels on remove

If we set channels greater during iavf_remove(), and waiting reset done
would be timeout, then returned with error but changed num_active_queues
directly, that will lead to OOB like the following logs. Because the
num_active_queues is greater than tx/rx_rings[] allocated actually.

Reproducer:

  [root@host ~]# cat repro.sh
  #!/bin/bash

  pf_dbsf="0000:41:00.0"
  vf0_dbsf="0000:41:02.0"
  g_pids=()

  function do_set_numvf()
  {
      echo 2 &gt;/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs
      sleep $((RANDOM%3+1))
      echo 0 &gt;/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs
      sleep $((RANDOM%3+1))
  }

  function do_set_channel()
  {
      local nic=$(ls -1 --indicator-style=none /sys/bus/pci/devices/${vf0_dbsf}/net/)
      [ -z "$nic" ] &amp;&amp; { sleep $((RANDOM%3)) ; return 1; }
      ifconfig $nic 192.168.18.5 netmask 255.255.255.0
      ifconfig $nic up
      ethtool -L $nic combined 1
      ethtool -L $nic combined 4
      sleep $((RANDOM%3))
  }

  function on_exit()
  {
      local pid
      for pid in "${g_pids[@]}"; do
          kill -0 "$pid" &amp;&gt;/dev/null &amp;&amp; kill "$pid" &amp;&gt;/dev/null
      done
      g_pids=()
  }

  trap "on_exit; exit" EXIT

  while :; do do_set_numvf ; done &amp;
  g_pids+=($!)
  while :; do do_set_channel ; done &amp;
  g_pids+=($!)

  wait

Result:

[ 3506.152887] iavf 0000:41:02.0: Removing device
[ 3510.400799] ==================================================================
[ 3510.400820] BUG: KASAN: slab-out-of-bounds in iavf_free_all_tx_resources+0x156/0x160 [iavf]
[ 3510.400823] Read of size 8 at addr ffff88b6f9311008 by task repro.sh/55536
[ 3510.400823]
[ 3510.400830] CPU: 101 PID: 55536 Comm: repro.sh Kdump: loaded Tainted: G           O     --------- -t - 4.18.0 #1
[ 3510.400832] Hardware name: Powerleader PR2008AL/H12DSi-N6, BIOS 2.0 04/09/2021
[ 3510.400835] Call Trace:
[ 3510.400851]  dump_stack+0x71/0xab
[ 3510.400860]  print_address_description+0x6b/0x290
[ 3510.400865]  ? iavf_free_all_tx_resources+0x156/0x160 [iavf]
[ 3510.400868]  kasan_report+0x14a/0x2b0
[ 3510.400873]  iavf_free_all_tx_resources+0x156/0x160 [iavf]
[ 3510.400880]  iavf_remove+0x2b6/0xc70 [iavf]
[ 3510.400884]  ? iavf_free_all_rx_resources+0x160/0x160 [iavf]
[ 3510.400891]  ? wait_woken+0x1d0/0x1d0
[ 3510.400895]  ? notifier_call_chain+0xc1/0x130
[ 3510.400903]  pci_device_remove+0xa8/0x1f0
[ 3510.400910]  device_release_driver_internal+0x1c6/0x460
[ 3510.400916]  pci_stop_bus_device+0x101/0x150
[ 3510.400919]  pci_stop_and_remove_bus_device+0xe/0x20
[ 3510.400924]  pci_iov_remove_virtfn+0x187/0x420
[ 3510.400927]  ? pci_iov_add_virtfn+0xe10/0xe10
[ 3510.400929]  ? pci_get_subsys+0x90/0x90
[ 3510.400932]  sriov_disable+0xed/0x3e0
[ 3510.400936]  ? bus_find_device+0x12d/0x1a0
[ 3510.400953]  i40e_free_vfs+0x754/0x1210 [i40e]
[ 3510.400966]  ? i40e_reset_all_vfs+0x880/0x880 [i40e]
[ 3510.400968]  ? pci_get_device+0x7c/0x90
[ 3510.400970]  ? pci_get_subsys+0x90/0x90
[ 3510.400982]  ? pci_vfs_assigned.part.7+0x144/0x210
[ 3510.400987]  ? __mutex_lock_slowpath+0x10/0x10
[ 3510.400996]  i40e_pci_sriov_configure+0x1fa/0x2e0 [i40e]
[ 3510.401001]  sriov_numvfs_store+0x214/0x290
[ 3510.401005]  ? sriov_totalvfs_show+0x30/0x30
[ 3510.401007]  ? __mutex_lock_slowpath+0x10/0x10
[ 3510.401011]  ? __check_object_size+0x15a/0x350
[ 3510.401018]  kernfs_fop_write+0x280/0x3f0
[ 3510.401022]  vfs_write+0x145/0x440
[ 3510.401025]  ksys_write+0xab/0x160
[ 3510.401028]  ? __ia32_sys_read+0xb0/0xb0
[ 3510.401031]  ? fput_many+0x1a/0x120
[ 3510.401032]  ? filp_close+0xf0/0x130
[ 3510.401038]  do_syscall_64+0xa0/0x370
[ 3510.401041]  ? page_fault+0x8/0x30
[ 3510.401043]  entry_SYSCALL_64_after_hwframe+0x65/0xca
[ 3510.401073] RIP: 0033:0x7f3a9bb842c0
[ 3510.401079] Code: 73 01 c3 48 8b 0d d8 cb 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 89 24 2d 00 00 75 10 b8 01 00 00 00 0f 05 &lt;48&gt; 3d 
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-53659</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:

bpf, cpumap: Handle skb as well when clean up ptr_ring

The following warning was reported when running xdp_redirect_cpu with
both skb-mode and stress-mode enabled:

  ------------[ cut here ]------------
  Incorrect XDP memory type (-2128176192) usage
  WARNING: CPU: 7 PID: 1442 at net/core/xdp.c:405
  Modules linked in:
  CPU: 7 PID: 1442 Comm: kworker/7:0 Tainted: G  6.5.0-rc2+ #1
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
  Workqueue: events __cpu_map_entry_free
  RIP: 0010:__xdp_return+0x1e4/0x4a0
  ......
  Call Trace:
   &lt;TASK&gt;
   ? show_regs+0x65/0x70
   ? __warn+0xa5/0x240
   ? __xdp_return+0x1e4/0x4a0
   ......
   xdp_return_frame+0x4d/0x150
   __cpu_map_entry_free+0xf9/0x230
   process_one_work+0x6b0/0xb80
   worker_thread+0x96/0x720
   kthread+0x1a5/0x1f0
   ret_from_fork+0x3a/0x70
   ret_from_fork_asm+0x1b/0x30
   &lt;/TASK&gt;

The reason for the warning is twofold. One is due to the kthread
cpu_map_kthread_run() is stopped prematurely. Another one is
__cpu_map_ring_cleanup() doesn't handle skb mode and treats skbs in
ptr_ring as XDP frames.

Prematurely-stopped kthread will be fixed by the preceding patch and
ptr_ring will be empty when __cpu_map_ring_cleanup() is called. But
as the comments in __cpu_map_ring_cleanup() said, handling and freeing
skbs in ptr_ring as well to "catch any broken behaviour gracefully".</Note>
    </Notes>
    <CVE>CVE-2023-53660</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix memory leaks in ext4_fname_{setup_filename,prepare_lookup}

If the filename casefolding fails, we'll be leaking memory from the
fscrypt_name struct, namely from the 'crypto_buf.name' member.

Make sure we free it in the error path on both ext4_fname_setup_filename()
and ext4_fname_prepare_lookup() functions.</Note>
    </Notes>
    <CVE>CVE-2023-53662</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: nSVM: Check instead of asserting on nested TSC scaling support

Check for nested TSC scaling support on nested SVM VMRUN instead of
asserting that TSC scaling is exposed to L1 if L1's MSR_AMD64_TSC_RATIO
has diverged from KVM's default.  Userspace can trigger the WARN at will
by writing the MSR and then updating guest CPUID to hide the feature
(modifying guest CPUID is allowed anytime before KVM_RUN).  E.g. hacking
KVM's state_test selftest to do

		vcpu_set_msr(vcpu, MSR_AMD64_TSC_RATIO, 0);
		vcpu_clear_cpuid_feature(vcpu, X86_FEATURE_TSCRATEMSR);

after restoring state in a new VM+vCPU yields an endless supply of:

  ------------[ cut here ]------------
  WARNING: CPU: 164 PID: 62565 at arch/x86/kvm/svm/nested.c:699
           nested_vmcb02_prepare_control+0x3d6/0x3f0 [kvm_amd]
  Call Trace:
   &lt;TASK&gt;
   enter_svm_guest_mode+0x114/0x560 [kvm_amd]
   nested_svm_vmrun+0x260/0x330 [kvm_amd]
   vmrun_interception+0x29/0x30 [kvm_amd]
   svm_invoke_exit_handler+0x35/0x100 [kvm_amd]
   svm_handle_exit+0xe7/0x180 [kvm_amd]
   kvm_arch_vcpu_ioctl_run+0x1eab/0x2570 [kvm]
   kvm_vcpu_ioctl+0x4c9/0x5b0 [kvm]
   __se_sys_ioctl+0x7a/0xc0
   __x64_sys_ioctl+0x21/0x30
   do_syscall_64+0x41/0x90
   entry_SYSCALL_64_after_hwframe+0x63/0xcd
  RIP: 0033:0x45ca1b

Note, the nested #VMEXIT path has the same flaw, but needs a different
fix and will be handled separately.</Note>
    </Notes>
    <CVE>CVE-2023-53663</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: don't dereference mddev after export_rdev()

Except for initial reference, mddev-&gt;kobject is referenced by
rdev-&gt;kobject, and if the last rdev is freed, there is no guarantee that
mddev is still valid. Hence mddev should not be used anymore after
export_rdev().

This problem can be triggered by following test for mdadm at very
low rate:

New file: mdadm/tests/23rdev-lifetime

devname=${dev0##*/}
devt=`cat /sys/block/$devname/dev`
pid=""
runtime=2

clean_up_test() {
        pill -9 $pid
        echo clear &gt; /sys/block/md0/md/array_state
}

trap 'clean_up_test' EXIT

add_by_sysfs() {
        while true; do
                echo $devt &gt; /sys/block/md0/md/new_dev
        done
}

remove_by_sysfs(){
        while true; do
                echo remove &gt; /sys/block/md0/md/dev-${devname}/state
        done
}

echo md0 &gt; /sys/module/md_mod/parameters/new_array || die "create md0 failed"

add_by_sysfs &amp;
pid="$pid $!"

remove_by_sysfs &amp;
pid="$pid $!"

sleep $runtime
exit 0

Test cmd:

./test --save-logs --logdir=/tmp/ --keep-going --dev=loop --tests=23rdev-lifetime

Test result:

general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bcb: 0000 [#4] PREEMPT SMP
CPU: 0 PID: 1292 Comm: test Tainted: G      D W          6.5.0-rc2-00121-g01e55c376936 #562
RIP: 0010:md_wakeup_thread+0x9e/0x320 [md_mod]
Call Trace:
 &lt;TASK&gt;
 mddev_unlock+0x1b6/0x310 [md_mod]
 rdev_attr_store+0xec/0x190 [md_mod]
 sysfs_kf_write+0x52/0x70
 kernfs_fop_write_iter+0x19a/0x2a0
 vfs_write+0x3b5/0x770
 ksys_write+0x74/0x150
 __x64_sys_write+0x22/0x30
 do_syscall_64+0x40/0x90
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Fix this problem by don't dereference mddev after export_rdev().</Note>
    </Notes>
    <CVE>CVE-2023-53665</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: wcd938x: fix missing mbhc init error handling

MBHC initialisation can fail so add the missing error handling to avoid
dereferencing an error pointer when later configuring the jack:

    Unable to handle kernel paging request at virtual address fffffffffffffff8

    pc : wcd_mbhc_start+0x28/0x380 [snd_soc_wcd_mbhc]
    lr : wcd938x_codec_set_jack+0x28/0x48 [snd_soc_wcd938x]

    Call trace:
     wcd_mbhc_start+0x28/0x380 [snd_soc_wcd_mbhc]
     wcd938x_codec_set_jack+0x28/0x48 [snd_soc_wcd938x]
     snd_soc_component_set_jack+0x28/0x8c [snd_soc_core]
     qcom_snd_wcd_jack_setup+0x7c/0x19c [snd_soc_qcom_common]
     sc8280xp_snd_init+0x20/0x2c [snd_soc_sc8280xp]
     snd_soc_link_init+0x28/0x90 [snd_soc_core]
     snd_soc_bind_card+0x628/0xbfc [snd_soc_core]
     snd_soc_register_card+0xec/0x104 [snd_soc_core]
     devm_snd_soc_register_card+0x4c/0xa4 [snd_soc_core]
     sc8280xp_platform_probe+0xf0/0x108 [snd_soc_sc8280xp]</Note>
    </Notes>
    <CVE>CVE-2023-53666</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ring-buffer: Fix deadloop issue on reading trace_pipe

Soft lockup occurs when reading file 'trace_pipe':

  watchdog: BUG: soft lockup - CPU#6 stuck for 22s! [cat:4488]
  [...]
  RIP: 0010:ring_buffer_empty_cpu+0xed/0x170
  RSP: 0018:ffff88810dd6fc48 EFLAGS: 00000246
  RAX: 0000000000000000 RBX: 0000000000000246 RCX: ffffffff93d1aaeb
  RDX: ffff88810a280040 RSI: 0000000000000008 RDI: ffff88811164b218
  RBP: ffff88811164b218 R08: 0000000000000000 R09: ffff88815156600f
  R10: ffffed102a2acc01 R11: 0000000000000001 R12: 0000000051651901
  R13: 0000000000000000 R14: ffff888115e49500 R15: 0000000000000000
  [...]
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f8d853c2000 CR3: 000000010dcd8000 CR4: 00000000000006e0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
  Call Trace:
   __find_next_entry+0x1a8/0x4b0
   ? peek_next_entry+0x250/0x250
   ? down_write+0xa5/0x120
   ? down_write_killable+0x130/0x130
   trace_find_next_entry_inc+0x3b/0x1d0
   tracing_read_pipe+0x423/0xae0
   ? tracing_splice_read_pipe+0xcb0/0xcb0
   vfs_read+0x16b/0x490
   ksys_read+0x105/0x210
   ? __ia32_sys_pwrite64+0x200/0x200
   ? switch_fpu_return+0x108/0x220
   do_syscall_64+0x33/0x40
   entry_SYSCALL_64_after_hwframe+0x61/0xc6

Through the vmcore, I found it's because in tracing_read_pipe(),
ring_buffer_empty_cpu() found some buffer is not empty but then it
cannot read anything due to "rb_num_of_entries() == 0" always true,
Then it infinitely loop the procedure due to user buffer not been
filled, see following code path:

  tracing_read_pipe() {
    ... ...
    waitagain:
      tracing_wait_pipe() // 1. find non-empty buffer here
      trace_find_next_entry_inc()  // 2. loop here try to find an entry
        __find_next_entry()
          ring_buffer_empty_cpu();  // 3. find non-empty buffer
          peek_next_entry()  // 4. but peek always return NULL
            ring_buffer_peek()
              rb_buffer_peek()
                rb_get_reader_page()
                  // 5. because rb_num_of_entries() == 0 always true here
                  //    then return NULL
      // 6. user buffer not been filled so goto 'waitgain'
      //    and eventually leads to an deadloop in kernel!!!
  }

By some analyzing, I found that when resetting ringbuffer, the 'entries'
of its pages are not all cleared (see rb_reset_cpu()). Then when reducing
the ringbuffer, and if some reduced pages exist dirty 'entries' data, they
will be added into 'cpu_buffer-&gt;overrun' (see rb_remove_pages()), which
cause wrong 'overrun' count and eventually cause the deadloop issue.

To fix it, we need to clear every pages in rb_reset_cpu().</Note>
    </Notes>
    <CVE>CVE-2023-53668</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-core: fix dev_pm_qos memleak

Call dev_pm_qos_hide_latency_tolerance() in the error unwind patch to
avoid following kmemleak:-

blktests (master) # kmemleak-clear; ./check nvme/044;
blktests (master) # kmemleak-scan ; kmemleak-show
nvme/044 (Test bi-directional authentication)                [passed]
    runtime  2.111s  ...  2.124s
unreferenced object 0xffff888110c46240 (size 96):
  comm "nvme", pid 33461, jiffies 4345365353 (age 75.586s)
  hex dump (first 32 bytes):
    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:
    [&lt;0000000069ac2cec&gt;] kmalloc_trace+0x25/0x90
    [&lt;000000006acc66d5&gt;] dev_pm_qos_update_user_latency_tolerance+0x6f/0x100
    [&lt;00000000cc376ea7&gt;] nvme_init_ctrl+0x38e/0x410 [nvme_core]
    [&lt;000000007df61b4b&gt;] 0xffffffffc05e88b3
    [&lt;00000000d152b985&gt;] 0xffffffffc05744cb
    [&lt;00000000f04a4041&gt;] vfs_write+0xc5/0x3c0
    [&lt;00000000f9491baf&gt;] ksys_write+0x5f/0xe0
    [&lt;000000001c46513d&gt;] do_syscall_64+0x3b/0x90
    [&lt;00000000ecf348fe&gt;] entry_SYSCALL_64_after_hwframe+0x72/0xdc</Note>
    </Notes>
    <CVE>CVE-2023-53670</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: output extra debug info if we failed to find an inline backref

[BUG]
Syzbot reported several warning triggered inside
lookup_inline_extent_backref().

[CAUSE]
As usual, the reproducer doesn't reliably trigger locally here, but at
least we know the WARN_ON() is triggered when an inline backref can not
be found, and it can only be triggered when @insert is true. (I.e.
inserting a new inline backref, which means the backref should already
exist)

[ENHANCEMENT]
After the WARN_ON(), dump all the parameters and the extent tree
leaf to help debug.</Note>
    </Notes>
    <CVE>CVE-2023-53672</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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_event: call disconnect callback before deleting conn

In hci_cs_disconnect, we do hci_conn_del even if disconnection failed.

ISO, L2CAP and SCO connections refer to the hci_conn without
hci_conn_get, so disconn_cfm must be called so they can clean up their
conn, otherwise use-after-free occurs.

ISO:
==========================================================
iso_sock_connect:880: sk 00000000eabd6557
iso_connect_cis:356: 70:1a:b8:98:ff:a2 -&gt; 28:3d:c2:4a:7e:da
...
iso_conn_add:140: hcon 000000001696f1fd conn 00000000b6251073
hci_dev_put:1487: hci0 orig refcnt 17
__iso_chan_add:214: conn 00000000b6251073
iso_sock_clear_timer:117: sock 00000000eabd6557 state 3
...
hci_rx_work:4085: hci0 Event packet
hci_event_packet:7601: hci0: event 0x0f
hci_cmd_status_evt:4346: hci0: opcode 0x0406
hci_cs_disconnect:2760: hci0: status 0x0c
hci_sent_cmd_data:3107: hci0 opcode 0x0406
hci_conn_del:1151: hci0 hcon 000000001696f1fd handle 2560
hci_conn_unlink:1102: hci0: hcon 000000001696f1fd
hci_conn_drop:1451: hcon 00000000d8521aaf orig refcnt 2
hci_chan_list_flush:2780: hcon 000000001696f1fd
hci_dev_put:1487: hci0 orig refcnt 21
hci_dev_put:1487: hci0 orig refcnt 20
hci_req_cmd_complete:3978: opcode 0x0406 status 0x0c
... &lt;no iso_* activity on sk/conn&gt; ...
iso_sock_sendmsg:1098: sock 00000000dea5e2e0, sk 00000000eabd6557
BUG: kernel NULL pointer dereference, address: 0000000000000668
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP PTI
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014
RIP: 0010:iso_sock_sendmsg (net/bluetooth/iso.c:1112) bluetooth
==========================================================

L2CAP:
==================================================================
hci_cmd_status_evt:4359: hci0: opcode 0x0406
hci_cs_disconnect:2760: hci0: status 0x0c
hci_sent_cmd_data:3085: hci0 opcode 0x0406
hci_conn_del:1151: hci0 hcon ffff88800c999000 handle 3585
hci_conn_unlink:1102: hci0: hcon ffff88800c999000
hci_chan_list_flush:2780: hcon ffff88800c999000
hci_chan_del:2761: hci0 hcon ffff88800c999000 chan ffff888018ddd280
...
BUG: KASAN: slab-use-after-free in hci_send_acl+0x2d/0x540 [bluetooth]
Read of size 8 at addr ffff888018ddd298 by task bluetoothd/1175

CPU: 0 PID: 1175 Comm: bluetoothd Tainted: G            E      6.4.0-rc4+ #2
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x5b/0x90
 print_report+0xcf/0x670
 ? __virt_addr_valid+0xf8/0x180
 ? hci_send_acl+0x2d/0x540 [bluetooth]
 kasan_report+0xa8/0xe0
 ? hci_send_acl+0x2d/0x540 [bluetooth]
 hci_send_acl+0x2d/0x540 [bluetooth]
 ? __pfx___lock_acquire+0x10/0x10
 l2cap_chan_send+0x1fd/0x1300 [bluetooth]
 ? l2cap_sock_sendmsg+0xf2/0x170 [bluetooth]
 ? __pfx_l2cap_chan_send+0x10/0x10 [bluetooth]
 ? lock_release+0x1d5/0x3c0
 ? mark_held_locks+0x1a/0x90
 l2cap_sock_sendmsg+0x100/0x170 [bluetooth]
 sock_write_iter+0x275/0x280
 ? __pfx_sock_write_iter+0x10/0x10
 ? __pfx___lock_acquire+0x10/0x10
 do_iter_readv_writev+0x176/0x220
 ? __pfx_do_iter_readv_writev+0x10/0x10
 ? find_held_lock+0x83/0xa0
 ? selinux_file_permission+0x13e/0x210
 do_iter_write+0xda/0x340
 vfs_writev+0x1b4/0x400
 ? __pfx_vfs_writev+0x10/0x10
 ? __seccomp_filter+0x112/0x750
 ? populate_seccomp_data+0x182/0x220
 ? __fget_light+0xdf/0x100
 ? do_writev+0x19d/0x210
 do_writev+0x19d/0x210
 ? __pfx_do_writev+0x10/0x10
 ? mark_held_locks+0x1a/0x90
 do_syscall_64+0x60/0x90
 ? lockdep_hardirqs_on_prepare+0x149/0x210
 ? do_syscall_64+0x6c/0x90
 ? lockdep_hardirqs_on_prepare+0x149/0x210
 entry_SYSCALL_64_after_hwframe+0x72/0xdc
RIP: 0033:0x7ff45cb23e64
Code: 15 d1 1f 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d 9d a7 0d 00 00 74 13 b8 14 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89
RSP: 002b:00007fff21ae09b8 EFLAGS: 00000202 ORIG_RAX: 0000000000000014
RAX: ffffffffffffffda RBX: 
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-53673</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:

clk: Fix memory leak in devm_clk_notifier_register()

devm_clk_notifier_register() allocates a devres resource for clk
notifier but didn't register that to the device, so the notifier didn't
get unregistered on device detach and the allocated resource was leaked.

Fix the issue by registering the resource through devres_add().

This issue was found with kmemleak on a Chromebook.</Note>
    </Notes>
    <CVE>CVE-2023-53674</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:

bcache: Fix __bch_btree_node_alloc to make the failure behavior consistent

In some specific situations, the return value of __bch_btree_node_alloc
may be NULL. This may lead to a potential NULL pointer dereference in
caller function like a calling chain :
btree_split-&gt;bch_btree_node_alloc-&gt;__bch_btree_node_alloc.

Fix it by initializing the return value in __bch_btree_node_alloc.</Note>
    </Notes>
    <CVE>CVE-2023-53681</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 null-ptr-deref in handshake_nl_done_doit()

We should not call trace_handshake_cmd_done_err() if socket lookup has failed.

Also we should call trace_handshake_cmd_done_err() before releasing the file,
otherwise dereferencing sock-&gt;sk can return garbage.

This also reverts 7afc6d0a107f ("net/handshake: Fix uninitialized local variable")

Unable to handle kernel paging request at virtual address dfff800000000003
KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
Mem abort info:
ESR = 0x0000000096000005
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x05: level 1 translation fault
Data abort info:
ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
CM = 0, WnR = 0, TnD = 0, TagAccess = 0
GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[dfff800000000003] address between user and kernel address ranges
Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP
Modules linked in:
CPU: 1 PID: 5986 Comm: syz-executor292 Not tainted 6.5.0-rc7-syzkaller-gfe4469582053 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : handshake_nl_done_doit+0x198/0x9c8 net/handshake/netlink.c:193
lr : handshake_nl_done_doit+0x180/0x9c8
sp : ffff800096e37180
x29: ffff800096e37200 x28: 1ffff00012dc6e34 x27: dfff800000000000
x26: ffff800096e373d0 x25: 0000000000000000 x24: 00000000ffffffa8
x23: ffff800096e373f0 x22: 1ffff00012dc6e38 x21: 0000000000000000
x20: ffff800096e371c0 x19: 0000000000000018 x18: 0000000000000000
x17: 0000000000000000 x16: ffff800080516cc4 x15: 0000000000000001
x14: 1fffe0001b14aa3b x13: 0000000000000000 x12: 0000000000000000
x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000003
x8 : 0000000000000003 x7 : ffff800080afe47c x6 : 0000000000000000
x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff800080a88078
x2 : 0000000000000001 x1 : 00000000ffffffa8 x0 : 0000000000000000
Call trace:
handshake_nl_done_doit+0x198/0x9c8 net/handshake/netlink.c:193
genl_family_rcv_msg_doit net/netlink/genetlink.c:970 [inline]
genl_family_rcv_msg net/netlink/genetlink.c:1050 [inline]
genl_rcv_msg+0x96c/0xc50 net/netlink/genetlink.c:1067
netlink_rcv_skb+0x214/0x3c4 net/netlink/af_netlink.c:2549
genl_rcv+0x38/0x50 net/netlink/genetlink.c:1078
netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]
netlink_unicast+0x660/0x8d4 net/netlink/af_netlink.c:1365
netlink_sendmsg+0x834/0xb18 net/netlink/af_netlink.c:1914
sock_sendmsg_nosec net/socket.c:725 [inline]
sock_sendmsg net/socket.c:748 [inline]
____sys_sendmsg+0x56c/0x840 net/socket.c:2494
___sys_sendmsg net/socket.c:2548 [inline]
__sys_sendmsg+0x26c/0x33c net/socket.c:2577
__do_sys_sendmsg net/socket.c:2586 [inline]
__se_sys_sendmsg net/socket.c:2584 [inline]
__arm64_sys_sendmsg+0x80/0x94 net/socket.c:2584
__invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]
invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51
el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136
do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155
el0_svc+0x58/0x16c arch/arm64/kernel/entry-common.c:678
el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696
el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591
Code: 12800108 b90043e8 910062b3 d343fe68 (387b6908)</Note>
    </Notes>
    <CVE>CVE-2023-53686</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: serial: samsung_tty: Fix a memory leak in s3c24xx_serial_getclk() when iterating clk

When the best clk is searched, we iterate over all possible clk.

If we find a better match, the previous one, if any, needs to be freed.
If a better match has already been found, we still need to free the new
one, otherwise it leaks.</Note>
    </Notes>
    <CVE>CVE-2023-53687</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:

USB: gadget: Fix the memory leak in raw_gadget driver

Currently, increasing raw_dev-&gt;count happens before invoke the
raw_queue_event(), if the raw_queue_event() return error, invoke
raw_release() will not trigger the dev_free() to be called.

[  268.905865][ T5067] raw-gadget.0 gadget.0: failed to queue event
[  268.912053][ T5067] udc dummy_udc.0: failed to start USB Raw Gadget: -12
[  268.918885][ T5067] raw-gadget.0: probe of gadget.0 failed with error -12
[  268.925956][ T5067] UDC core: USB Raw Gadget: couldn't find an available UDC or it's busy
[  268.934657][ T5067] misc raw-gadget: fail, usb_gadget_register_driver returned -16

BUG: memory leak

[&lt;ffffffff8154bf94&gt;] kmalloc_trace+0x24/0x90 mm/slab_common.c:1076
[&lt;ffffffff8347eb55&gt;] kmalloc include/linux/slab.h:582 [inline]
[&lt;ffffffff8347eb55&gt;] kzalloc include/linux/slab.h:703 [inline]
[&lt;ffffffff8347eb55&gt;] dev_new drivers/usb/gadget/legacy/raw_gadget.c:191 [inline]
[&lt;ffffffff8347eb55&gt;] raw_open+0x45/0x110 drivers/usb/gadget/legacy/raw_gadget.c:385
[&lt;ffffffff827d1d09&gt;] misc_open+0x1a9/0x1f0 drivers/char/misc.c:165

[&lt;ffffffff8154bf94&gt;] kmalloc_trace+0x24/0x90 mm/slab_common.c:1076
[&lt;ffffffff8347cd2f&gt;] kmalloc include/linux/slab.h:582 [inline]
[&lt;ffffffff8347cd2f&gt;] raw_ioctl_init+0xdf/0x410 drivers/usb/gadget/legacy/raw_gadget.c:460
[&lt;ffffffff8347dfe9&gt;] raw_ioctl+0x5f9/0x1120 drivers/usb/gadget/legacy/raw_gadget.c:1250
[&lt;ffffffff81685173&gt;] vfs_ioctl fs/ioctl.c:51 [inline]

[&lt;ffffffff8154bf94&gt;] kmalloc_trace+0x24/0x90 mm/slab_common.c:1076
[&lt;ffffffff833ecc6a&gt;] kmalloc include/linux/slab.h:582 [inline]
[&lt;ffffffff833ecc6a&gt;] kzalloc include/linux/slab.h:703 [inline]
[&lt;ffffffff833ecc6a&gt;] dummy_alloc_request+0x5a/0xe0 drivers/usb/gadget/udc/dummy_hcd.c:665
[&lt;ffffffff833e9132&gt;] usb_ep_alloc_request+0x22/0xd0 drivers/usb/gadget/udc/core.c:196
[&lt;ffffffff8347f13d&gt;] gadget_bind+0x6d/0x370 drivers/usb/gadget/legacy/raw_gadget.c:292

This commit therefore invoke kref_get() under the condition that
raw_queue_event() return success.</Note>
    </Notes>
    <CVE>CVE-2023-53693</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nvdimm: Fix memleak of pmu attr_groups in unregister_nvdimm_pmu()

Memory pointed by 'nd_pmu-&gt;pmu.attr_groups' is allocated in function
'register_nvdimm_pmu' and is lost after 'kfree(nd_pmu)' call in function
'unregister_nvdimm_pmu'.</Note>
    </Notes>
    <CVE>CVE-2023-53697</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:

xsk: fix refcount underflow in error path

Fix a refcount underflow problem reported by syzbot that can happen
when a system is running out of memory. If xp_alloc_tx_descs() fails,
and it can only fail due to not having enough memory, then the error
path is triggered. In this error path, the refcount of the pool is
decremented as it has incremented before. However, the reference to
the pool in the socket was not nulled. This means that when the socket
is closed later, the socket teardown logic will think that there is a
pool attached to the socket and try to decrease the refcount again,
leading to a refcount underflow.

I chose this fix as it involved adding just a single line. Another
option would have been to move xp_get_pool() and the assignment of
xs-&gt;pool to after the if-statement and using xs_umem-&gt;pool instead of
xs-&gt;pool in the whole if-statement resulting in somewhat simpler code,
but this would have led to much more churn in the code base perhaps
making it harder to backport.</Note>
    </Notes>
    <CVE>CVE-2023-53698</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:

riscv: move memblock_allow_resize() after linear mapping is ready

The initial memblock metadata is accessed from kernel image mapping. The
regions arrays need to "reallocated" from memblock and accessed through
linear mapping to cover more memblock regions. So the resizing should
not be allowed until linear mapping is ready. Note that there are
memblock allocations when building linear mapping.

This patch is similar to 24cc61d8cb5a ("arm64: memblock: don't permit
memblock resizing until linear mapping is up").

In following log, many memblock regions are reserved before
create_linear_mapping_page_table(). And then it triggered reallocation
of memblock.reserved.regions and memcpy the old array in kernel image
mapping to the new array in linear mapping which caused a page fault.

[    0.000000] memblock_reserve: [0x00000000bf01f000-0x00000000bf01ffff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6
[    0.000000] memblock_reserve: [0x00000000bf021000-0x00000000bf021fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6
[    0.000000] memblock_reserve: [0x00000000bf023000-0x00000000bf023fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6
[    0.000000] memblock_reserve: [0x00000000bf025000-0x00000000bf025fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6
[    0.000000] memblock_reserve: [0x00000000bf027000-0x00000000bf027fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6
[    0.000000] memblock_reserve: [0x00000000bf029000-0x00000000bf029fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6
[    0.000000] memblock_reserve: [0x00000000bf02b000-0x00000000bf02bfff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6
[    0.000000] memblock_reserve: [0x00000000bf02d000-0x00000000bf02dfff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6
[    0.000000] memblock_reserve: [0x00000000bf02f000-0x00000000bf02ffff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6
[    0.000000] memblock_reserve: [0x00000000bf030000-0x00000000bf030fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6
[    0.000000] OF: reserved mem: 0x0000000080000000..0x000000008007ffff (512 KiB) map non-reusable mmode_resv0@80000000
[    0.000000] memblock_reserve: [0x00000000bf000000-0x00000000bf001fed] paging_init+0x19a/0x5ae
[    0.000000] memblock_phys_alloc_range: 4096 bytes align=0x1000 from=0x0000000000000000 max_addr=0x0000000000000000 alloc_pmd_fixmap+0x14/0x1c
[    0.000000] memblock_reserve: [0x000000017ffff000-0x000000017fffffff] memblock_alloc_range_nid+0xb8/0x128
[    0.000000] memblock: reserved is doubled to 256 at [0x000000017fffd000-0x000000017fffe7ff]
[    0.000000] Unable to handle kernel paging request at virtual address ff600000ffffd000
[    0.000000] Oops [#1]
[    0.000000] Modules linked in:
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.4.0-rc1-00011-g99a670b2069c #66
[    0.000000] Hardware name: riscv-virtio,qemu (DT)
[    0.000000] epc : __memcpy+0x60/0xf8
[    0.000000]  ra : memblock_double_array+0x192/0x248
[    0.000000] epc : ffffffff8081d214 ra : ffffffff80a3dfc0 sp : ffffffff81403bd0
[    0.000000]  gp : ffffffff814fbb38 tp : ffffffff8140dac0 t0 : 0000000001600000
[    0.000000]  t1 : 0000000000000000 t2 : 000000008f001000 s0 : ffffffff81403c60
[    0.000000]  s1 : ffffffff80c0bc98 a0 : ff600000ffffd000 a1 : ffffffff80c0bcd8
[    0.000000]  a2 : 0000000000000c00 a3 : ffffffff80c0c8d8 a4 : 0000000080000000
[    0.000000]  a5 : 0000000000080000 a6 : 0000000000000000 a7 : 0000000080200000
[    0.000000]  s2 : ff600000ffffd000 s3 : 0000000000002000 s4 : 0000000000000c00
[    0.000000]  s5 : ffffffff80c0bc60 s6 : ffffffff80c0bcc8 s7 : 0000000000000000
[    0.000000]  s8 : ffffffff814fd0a8 s9 : 000000017fffe7ff s10: 0000000000000000
[    0.000000]  s11: 0000000000001000 t3 : 0000000000001000 t4 : 0000000000000000
[    0.000000]  t5 : 000000008f003000 t6 : ff600000ffffd000
[    0.000000] status: 0000000200000100 badaddr: ff600000ffffd000 cause: 000000000000000f
[    0.000000] [&lt;fff
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-53699</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: amd_sfh: Fix for shift-out-of-bounds

Shift operation of 'exp' and 'shift' variables exceeds the maximum number
of shift values in the u32 range leading to UBSAN shift-out-of-bounds.

...
[    6.120512] UBSAN: shift-out-of-bounds in drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_desc.c:149:50
[    6.120598] shift exponent 104 is too large for 64-bit type 'long unsigned int'
[    6.120659] CPU: 4 PID: 96 Comm: kworker/4:1 Not tainted 6.4.0amd_1-next-20230519-dirty #10
[    6.120665] Hardware name: AMD Birman-PHX/Birman-PHX, BIOS SFH_with_HPD_SEN.FD 04/05/2023
[    6.120667] Workqueue: events amd_sfh_work_buffer [amd_sfh]
[    6.120687] Call Trace:
[    6.120690]  &lt;TASK&gt;
[    6.120694]  dump_stack_lvl+0x48/0x70
[    6.120704]  dump_stack+0x10/0x20
[    6.120707]  ubsan_epilogue+0x9/0x40
[    6.120716]  __ubsan_handle_shift_out_of_bounds+0x10f/0x170
[    6.120720]  ? psi_group_change+0x25f/0x4b0
[    6.120729]  float_to_int.cold+0x18/0xba [amd_sfh]
[    6.120739]  get_input_rep+0x57/0x340 [amd_sfh]
[    6.120748]  ? __schedule+0xba7/0x1b60
[    6.120756]  ? __pfx_get_input_rep+0x10/0x10 [amd_sfh]
[    6.120764]  amd_sfh_work_buffer+0x91/0x180 [amd_sfh]
[    6.120772]  process_one_work+0x229/0x430
[    6.120780]  worker_thread+0x4a/0x3c0
[    6.120784]  ? __pfx_worker_thread+0x10/0x10
[    6.120788]  kthread+0xf7/0x130
[    6.120792]  ? __pfx_kthread+0x10/0x10
[    6.120795]  ret_from_fork+0x29/0x50
[    6.120804]  &lt;/TASK&gt;
...

Fix this by adding the condition to validate shift ranges.</Note>
    </Notes>
    <CVE>CVE-2023-53703</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

clk: imx: clk-imx8mp: improve error handling in imx8mp_clocks_probe()

Replace of_iomap() and kzalloc() with devm_of_iomap() and devm_kzalloc()
which can automatically release the related memory when the device
or driver is removed or unloaded to avoid potential memory leak.

In this case, iounmap(anatop_base) in line 427,433 are removed
as manual release is not required.

Besides, referring to clk-imx8mq.c, check the return code of
of_clk_add_hw_provider, if it returns negtive, print error info
and unregister hws, which makes the program more robust.</Note>
    </Notes>
    <CVE>CVE-2023-53704</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: Fix integer overflow in amdgpu_cs_pass1

The type of size is unsigned int, if size is 0x40000000, there will
be an integer overflow, size will be zero after size *= sizeof(uint32_t),
will cause uninitialized memory to be referenced later.</Note>
    </Notes>
    <CVE>CVE-2023-53707</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: x86: s2idle: Catch multiple ACPI_TYPE_PACKAGE objects

If a badly constructed firmware includes multiple `ACPI_TYPE_PACKAGE`
objects while evaluating the AMD LPS0 _DSM, there will be a memory
leak.  Explicitly guard against this.</Note>
    </Notes>
    <CVE>CVE-2023-53708</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:

NFS: Fix a potential data corruption

We must ensure that the subrequests are joined back into the head before
we can retransmit a request. If the head was not on the commit lists,
because the server wrote it synchronously, we still need to add it back
to the retransmission list.
Add a call that mirrors the effect of nfs_cancel_remove_inode() for
O_DIRECT.</Note>
    </Notes>
    <CVE>CVE-2023-53711</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: sme: Use STR P to clear FFR context field in streaming SVE mode

The FFR is a predicate register which can vary between 16 and 256 bits
in size depending upon the configured vector length. When saving the
SVE state in streaming SVE mode, the FFR register is inaccessible and
so commit 9f5848665788 ("arm64/sve: Make access to FFR optional") simply
clears the FFR field of the in-memory context structure. Unfortunately,
it achieves this using an unconditional 8-byte store and so if the SME
vector length is anything other than 64 bytes in size we will either
fail to clear the entire field or, worse, we will corrupt memory
immediately following the structure. This has led to intermittent kfence
splats in CI [1] and can trigger kmalloc Redzone corruption messages
when running the 'fp-stress' kselftest:

 | =============================================================================
 | BUG kmalloc-1k (Not tainted): kmalloc Redzone overwritten
 | -----------------------------------------------------------------------------
 |
 | 0xffff000809bf1e22-0xffff000809bf1e27 @offset=7714. First byte 0x0 instead of 0xcc
 | Allocated in do_sme_acc+0x9c/0x220 age=2613 cpu=1 pid=531
 |  __kmalloc+0x8c/0xcc
 |  do_sme_acc+0x9c/0x220
 |  ...

Replace the 8-byte store with a store of a predicate register which has
been zero-initialised with PFALSE, ensuring that the entire field is
cleared in memory.

[1] https://lore.kernel.org/r/CA+G9fYtU7HsV0R0dp4XEH5xXHSJFw8KyDf5VQrLLfMxWfxQkag@mail.gmail.com</Note>
    </Notes>
    <CVE>CVE-2023-53713</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:

ring-buffer: Do not swap cpu_buffer during resize process

When ring_buffer_swap_cpu was called during resize process,
the cpu buffer was swapped in the middle, resulting in incorrect state.
Continuing to run in the wrong state will result in oops.

This issue can be easily reproduced using the following two scripts:
/tmp # cat test1.sh
//#! /bin/sh
for i in `seq 0 100000`
do
         echo 2000 &gt; /sys/kernel/debug/tracing/buffer_size_kb
         sleep 0.5
         echo 5000 &gt; /sys/kernel/debug/tracing/buffer_size_kb
         sleep 0.5
done
/tmp # cat test2.sh
//#! /bin/sh
for i in `seq 0 100000`
do
        echo irqsoff &gt; /sys/kernel/debug/tracing/current_tracer
        sleep 1
        echo nop &gt; /sys/kernel/debug/tracing/current_tracer
        sleep 1
done
/tmp # ./test1.sh &amp;
/tmp # ./test2.sh &amp;

A typical oops log is as follows, sometimes with other different oops logs.

[  231.711293] WARNING: CPU: 0 PID: 9 at kernel/trace/ring_buffer.c:2026 rb_update_pages+0x378/0x3f8
[  231.713375] Modules linked in:
[  231.714735] CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G        W          6.5.0-rc1-00276-g20edcec23f92 #15
[  231.716750] Hardware name: linux,dummy-virt (DT)
[  231.718152] Workqueue: events update_pages_handler
[  231.719714] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  231.721171] pc : rb_update_pages+0x378/0x3f8
[  231.722212] lr : rb_update_pages+0x25c/0x3f8
[  231.723248] sp : ffff800082b9bd50
[  231.724169] x29: ffff800082b9bd50 x28: ffff8000825f7000 x27: 0000000000000000
[  231.726102] x26: 0000000000000001 x25: fffffffffffff010 x24: 0000000000000ff0
[  231.728122] x23: ffff0000c3a0b600 x22: ffff0000c3a0b5c0 x21: fffffffffffffe0a
[  231.730203] x20: ffff0000c3a0b600 x19: ffff0000c0102400 x18: 0000000000000000
[  231.732329] x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffffe7aa8510
[  231.734212] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000002
[  231.736291] x11: ffff8000826998a8 x10: ffff800082b9baf0 x9 : ffff800081137558
[  231.738195] x8 : fffffc00030e82c8 x7 : 0000000000000000 x6 : 0000000000000001
[  231.740192] x5 : ffff0000ffbafe00 x4 : 0000000000000000 x3 : 0000000000000000
[  231.742118] x2 : 00000000000006aa x1 : 0000000000000001 x0 : ffff0000c0007208
[  231.744196] Call trace:
[  231.744892]  rb_update_pages+0x378/0x3f8
[  231.745893]  update_pages_handler+0x1c/0x38
[  231.746893]  process_one_work+0x1f0/0x468
[  231.747852]  worker_thread+0x54/0x410
[  231.748737]  kthread+0x124/0x138
[  231.749549]  ret_from_fork+0x10/0x20
[  231.750434] ---[ end trace 0000000000000000 ]---
[  233.720486] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
[  233.721696] Mem abort info:
[  233.721935]   ESR = 0x0000000096000004
[  233.722283]   EC = 0x25: DABT (current EL), IL = 32 bits
[  233.722596]   SET = 0, FnV = 0
[  233.722805]   EA = 0, S1PTW = 0
[  233.723026]   FSC = 0x04: level 0 translation fault
[  233.723458] Data abort info:
[  233.723734]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[  233.724176]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[  233.724589]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[  233.725075] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000104943000
[  233.725592] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000
[  233.726231] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
[  233.726720] Modules linked in:
[  233.727007] CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G        W          6.5.0-rc1-00276-g20edcec23f92 #15
[  233.727777] Hardware name: linux,dummy-virt (DT)
[  233.728225] Workqueue: events update_pages_handler
[  233.728655] pstate: 200000c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  233.729054] pc : rb_update_pages+0x1a8/0x3f8
[  233.729334] lr : rb_update_pages+0x154/0x3f8
[  233.729592] sp : ffff800082b9bd50
[  233.729792] x29: ffff800082b9bd50 x28: ffff8000825f7000 x27: 00000000
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-53718</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 a NULL pointer dereference in ath12k_mac_op_hw_scan()

In ath12k_mac_op_hw_scan(), the return value of kzalloc() is directly
used in memcpy(), which may lead to a NULL pointer dereference on
failure of kzalloc().

Fix this bug by adding a check of arg.extraie.ptr.

Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0-03427-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.15378.4</Note>
    </Notes>
    <CVE>CVE-2023-53721</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: raid1: fix potential OOB in raid1_remove_disk()

If rddev-&gt;raid_disk is greater than mddev-&gt;raid_disks, there will be
an out-of-bounds in raid1_remove_disk(). We have already found
similar reports as follows:

1) commit d17f744e883b ("md-raid10: fix KASAN warning")
2) commit 1ebc2cec0b7d ("dm raid: fix KASAN warning in raid5_remove_disk")

Fix this bug by checking whether the "number" variable is
valid.</Note>
    </Notes>
    <CVE>CVE-2023-53722</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:

clocksource/drivers/cadence-ttc: Fix memory leak in ttc_timer_probe

Smatch reports:
drivers/clocksource/timer-cadence-ttc.c:529 ttc_timer_probe()
warn: 'timer_baseaddr' from of_iomap() not released on lines: 498,508,516.

timer_baseaddr may have the problem of not being released after use,
I replaced it with the devm_of_iomap() function and added the clk_put()
function to cleanup the "clk_ce" and "clk_cs".</Note>
    </Notes>
    <CVE>CVE-2023-53725</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:

arm64: csum: Fix OoB access in IP checksum code for negative lengths

Although commit c2c24edb1d9c ("arm64: csum: Fix pathological zero-length
calls") added an early return for zero-length input, syzkaller has
popped up with an example of a _negative_ length which causes an
undefined shift and an out-of-bounds read:

 | BUG: KASAN: slab-out-of-bounds in do_csum+0x44/0x254 arch/arm64/lib/csum.c:39
 | Read of size 4294966928 at addr ffff0000d7ac0170 by task syz-executor412/5975
 |
 | CPU: 0 PID: 5975 Comm: syz-executor412 Not tainted 6.4.0-rc4-syzkaller-g908f31f2a05b #0
 | Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023
 | Call trace:
 |  dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:233
 |  show_stack+0x2c/0x44 arch/arm64/kernel/stacktrace.c:240
 |  __dump_stack lib/dump_stack.c:88 [inline]
 |  dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106
 |  print_address_description mm/kasan/report.c:351 [inline]
 |  print_report+0x174/0x514 mm/kasan/report.c:462
 |  kasan_report+0xd4/0x130 mm/kasan/report.c:572
 |  kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:187
 |  __kasan_check_read+0x20/0x30 mm/kasan/shadow.c:31
 |  do_csum+0x44/0x254 arch/arm64/lib/csum.c:39
 |  csum_partial+0x30/0x58 lib/checksum.c:128
 |  gso_make_checksum include/linux/skbuff.h:4928 [inline]
 |  __udp_gso_segment+0xaf4/0x1bc4 net/ipv4/udp_offload.c:332
 |  udp6_ufo_fragment+0x540/0xca0 net/ipv6/udp_offload.c:47
 |  ipv6_gso_segment+0x5cc/0x1760 net/ipv6/ip6_offload.c:119
 |  skb_mac_gso_segment+0x2b4/0x5b0 net/core/gro.c:141
 |  __skb_gso_segment+0x250/0x3d0 net/core/dev.c:3401
 |  skb_gso_segment include/linux/netdevice.h:4859 [inline]
 |  validate_xmit_skb+0x364/0xdbc net/core/dev.c:3659
 |  validate_xmit_skb_list+0x94/0x130 net/core/dev.c:3709
 |  sch_direct_xmit+0xe8/0x548 net/sched/sch_generic.c:327
 |  __dev_xmit_skb net/core/dev.c:3805 [inline]
 |  __dev_queue_xmit+0x147c/0x3318 net/core/dev.c:4210
 |  dev_queue_xmit include/linux/netdevice.h:3085 [inline]
 |  packet_xmit+0x6c/0x318 net/packet/af_packet.c:276
 |  packet_snd net/packet/af_packet.c:3081 [inline]
 |  packet_sendmsg+0x376c/0x4c98 net/packet/af_packet.c:3113
 |  sock_sendmsg_nosec net/socket.c:724 [inline]
 |  sock_sendmsg net/socket.c:747 [inline]
 |  __sys_sendto+0x3b4/0x538 net/socket.c:2144

Extend the early return to reject negative lengths as well, aligning our
implementation with the generic code in lib/checksum.c</Note>
    </Notes>
    <CVE>CVE-2023-53726</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fq_pie: avoid stalls in fq_pie_timer()

When setting a high number of flows (limit being 65536),
fq_pie_timer() is currently using too much time as syzbot reported.

Add logic to yield the cpu every 2048 flows (less than 150 usec
on debug kernels).
It should also help by not blocking qdisc fast paths for too long.
Worst case (65536 flows) would need 31 jiffies for a complete scan.

Relevant extract from syzbot report:

rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { 0-.... } 2663 jiffies s: 873 root: 0x1/.
rcu: blocking rcu_node structures (internal RCU debug):
Sending NMI from CPU 1 to CPUs 0:
NMI backtrace for cpu 0
CPU: 0 PID: 5177 Comm: syz-executor273 Not tainted 6.5.0-syzkaller-00453-g727dbda16b83 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023
RIP: 0010:check_kcov_mode kernel/kcov.c:173 [inline]
RIP: 0010:write_comp_data+0x21/0x90 kernel/kcov.c:236
Code: 2e 0f 1f 84 00 00 00 00 00 65 8b 05 01 b2 7d 7e 49 89 f1 89 c6 49 89 d2 81 e6 00 01 00 00 49 89 f8 65 48 8b 14 25 80 b9 03 00 &lt;a9&gt; 00 01 ff 00 74 0e 85 f6 74 59 8b 82 04 16 00 00 85 c0 74 4f 8b
RSP: 0018:ffffc90000007bb8 EFLAGS: 00000206
RAX: 0000000000000101 RBX: ffffc9000dc0d140 RCX: ffffffff885893b0
RDX: ffff88807c075940 RSI: 0000000000000100 RDI: 0000000000000001
RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffffc9000dc0d178
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS:  0000555555d54380(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f6b442f6130 CR3: 000000006fe1c000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;NMI&gt;
 &lt;/NMI&gt;
 &lt;IRQ&gt;
 pie_calculate_probability+0x480/0x850 net/sched/sch_pie.c:415
 fq_pie_timer+0x1da/0x4f0 net/sched/sch_fq_pie.c:387
 call_timer_fn+0x1a0/0x580 kernel/time/timer.c:1700</Note>
    </Notes>
    <CVE>CVE-2023-53727</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-timers: Ensure timer ID search-loop limit is valid

posix_timer_add() tries to allocate a posix timer ID by starting from the
cached ID which was stored by the last successful allocation.

This is done in a loop searching the ID space for a free slot one by
one. The loop has to terminate when the search wrapped around to the
starting point.

But that's racy vs. establishing the starting point. That is read out
lockless, which leads to the following problem:

CPU0	  	      	     	   CPU1
posix_timer_add()
  start = sig-&gt;posix_timer_id;
  lock(hash_lock);
  ...				   posix_timer_add()
  if (++sig-&gt;posix_timer_id &lt; 0)
      			             start = sig-&gt;posix_timer_id;
     sig-&gt;posix_timer_id = 0;

So CPU1 can observe a negative start value, i.e. -1, and the loop break
never happens because the condition can never be true:

  if (sig-&gt;posix_timer_id == start)
     break;

While this is unlikely to ever turn into an endless loop as the ID space is
huge (INT_MAX), the racy read of the start value caught the attention of
KCSAN and Dmitry unearthed that incorrectness.

Rewrite it so that all id operations are under the hash lock.</Note>
    </Notes>
    <CVE>CVE-2023-53728</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: qcom: qmi_encdec: Restrict string length in decode

The QMI TLV value for strings in a lot of qmi element info structures
account for null terminated strings with MAX_LEN + 1. If a string is
actually MAX_LEN + 1 length, this will cause an out of bounds access
when the NULL character is appended in decoding.</Note>
    </Notes>
    <CVE>CVE-2023-53729</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

blk-iocost: use spin_lock_irqsave in adjust_inuse_and_calc_cost

adjust_inuse_and_calc_cost() use spin_lock_irq() and IRQ will be enabled
when unlock. DEADLOCK might happen if we have held other locks and disabled
IRQ before invoking it.

Fix it by using spin_lock_irqsave() instead, which can keep IRQ state
consistent with before when unlock.

  ================================
  WARNING: inconsistent lock state
  5.10.0-02758-g8e5f91fd772f #26 Not tainted
  --------------------------------
  inconsistent {IN-HARDIRQ-W} -&gt; {HARDIRQ-ON-W} usage.
  kworker/2:3/388 [HC0[0]:SC0[0]:HE0:SE1] takes:
  ffff888118c00c28 (&amp;bfqd-&gt;lock){?.-.}-{2:2}, at: spin_lock_irq
  ffff888118c00c28 (&amp;bfqd-&gt;lock){?.-.}-{2:2}, at: bfq_bio_merge+0x141/0x390
  {IN-HARDIRQ-W} state was registered at:
    __lock_acquire+0x3d7/0x1070
    lock_acquire+0x197/0x4a0
    __raw_spin_lock_irqsave
    _raw_spin_lock_irqsave+0x3b/0x60
    bfq_idle_slice_timer_body
    bfq_idle_slice_timer+0x53/0x1d0
    __run_hrtimer+0x477/0xa70
    __hrtimer_run_queues+0x1c6/0x2d0
    hrtimer_interrupt+0x302/0x9e0
    local_apic_timer_interrupt
    __sysvec_apic_timer_interrupt+0xfd/0x420
    run_sysvec_on_irqstack_cond
    sysvec_apic_timer_interrupt+0x46/0xa0
    asm_sysvec_apic_timer_interrupt+0x12/0x20
  irq event stamp: 837522
  hardirqs last  enabled at (837521): [&lt;ffffffff84b9419d&gt;] __raw_spin_unlock_irqrestore
  hardirqs last  enabled at (837521): [&lt;ffffffff84b9419d&gt;] _raw_spin_unlock_irqrestore+0x3d/0x40
  hardirqs last disabled at (837522): [&lt;ffffffff84b93fa3&gt;] __raw_spin_lock_irq
  hardirqs last disabled at (837522): [&lt;ffffffff84b93fa3&gt;] _raw_spin_lock_irq+0x43/0x50
  softirqs last  enabled at (835852): [&lt;ffffffff84e00558&gt;] __do_softirq+0x558/0x8ec
  softirqs last disabled at (835845): [&lt;ffffffff84c010ff&gt;] asm_call_irq_on_stack+0xf/0x20

  other info that might help us debug this:
   Possible unsafe locking scenario:

         CPU0
         ----
    lock(&amp;bfqd-&gt;lock);
    &lt;Interrupt&gt;
      lock(&amp;bfqd-&gt;lock);

   *** DEADLOCK ***

  3 locks held by kworker/2:3/388:
   #0: ffff888107af0f38 ((wq_completion)kthrotld){+.+.}-{0:0}, at: process_one_work+0x742/0x13f0
   #1: ffff8881176bfdd8 ((work_completion)(&amp;td-&gt;dispatch_work)){+.+.}-{0:0}, at: process_one_work+0x777/0x13f0
   #2: ffff888118c00c28 (&amp;bfqd-&gt;lock){?.-.}-{2:2}, at: spin_lock_irq
   #2: ffff888118c00c28 (&amp;bfqd-&gt;lock){?.-.}-{2:2}, at: bfq_bio_merge+0x141/0x390

  stack backtrace:
  CPU: 2 PID: 388 Comm: kworker/2:3 Not tainted 5.10.0-02758-g8e5f91fd772f #26
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
  Workqueue: kthrotld blk_throtl_dispatch_work_fn
  Call Trace:
   __dump_stack lib/dump_stack.c:77 [inline]
   dump_stack+0x107/0x167
   print_usage_bug
   valid_state
   mark_lock_irq.cold+0x32/0x3a
   mark_lock+0x693/0xbc0
   mark_held_locks+0x9e/0xe0
   __trace_hardirqs_on_caller
   lockdep_hardirqs_on_prepare.part.0+0x151/0x360
   trace_hardirqs_on+0x5b/0x180
   __raw_spin_unlock_irq
   _raw_spin_unlock_irq+0x24/0x40
   spin_unlock_irq
   adjust_inuse_and_calc_cost+0x4fb/0x970
   ioc_rqos_merge+0x277/0x740
   __rq_qos_merge+0x62/0xb0
   rq_qos_merge
   bio_attempt_back_merge+0x12c/0x4a0
   blk_mq_sched_try_merge+0x1b6/0x4d0
   bfq_bio_merge+0x24a/0x390
   __blk_mq_sched_bio_merge+0xa6/0x460
   blk_mq_sched_bio_merge
   blk_mq_submit_bio+0x2e7/0x1ee0
   __submit_bio_noacct_mq+0x175/0x3b0
   submit_bio_noacct+0x1fb/0x270
   blk_throtl_dispatch_work_fn+0x1ef/0x2b0
   process_one_work+0x83e/0x13f0
   process_scheduled_works
   worker_thread+0x7e3/0xd80
   kthread+0x353/0x470
   ret_from_fork+0x1f/0x30</Note>
    </Notes>
    <CVE>CVE-2023-53730</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 potential deadlock in netlink_set_err()

syzbot reported a possible deadlock in netlink_set_err() [1]

A similar issue was fixed in commit 1d482e666b8e ("netlink: disable IRQs
for netlink_lock_table()") in netlink_lock_table()

This patch adds IRQ safety to netlink_set_err() and __netlink_diag_dump()
which were not covered by cited commit.

[1]

WARNING: possible irq lock inversion dependency detected
6.4.0-rc6-syzkaller-00240-g4e9f0ec38852 #0 Not tainted

syz-executor.2/23011 just changed the state of lock:
ffffffff8e1a7a58 (nl_table_lock){.+.?}-{2:2}, at: netlink_set_err+0x2e/0x3a0 net/netlink/af_netlink.c:1612
but this lock was taken by another, SOFTIRQ-safe lock in the past:
 (&amp;local-&gt;queue_stop_reason_lock){..-.}-{2:2}

and interrupts could create inverse lock ordering between them.

other info that might help us debug this:
 Possible interrupt unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(nl_table_lock);
                               local_irq_disable();
                               lock(&amp;local-&gt;queue_stop_reason_lock);
                               lock(nl_table_lock);
  &lt;Interrupt&gt;
    lock(&amp;local-&gt;queue_stop_reason_lock);

 *** DEADLOCK ***</Note>
    </Notes>
    <CVE>CVE-2023-53731</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: cls_u32: Undo tcf_bind_filter if u32_replace_hw_knode

When u32_replace_hw_knode fails, we need to undo the tcf_bind_filter
operation done at u32_set_parms.</Note>
    </Notes>
    <CVE>CVE-2023-53733</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">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">A vulnerability was found in `podman build` and `buildah.` This issue occurs in a container breakout by using --jobs=2 and a race condition when building a malicious Containerfile. SELinux might mitigate it, but even with SELinux on, it still allows the enumeration of files and directories on the host.</Note>
    </Notes>
    <CVE>CVE-2024-11218</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">containerd is an open-source container runtime. Versions 0.1.0 through 1.7.28, 2.0.0-beta.0 through 2.0.6, 2.1.0-beta.0 through 2.1.4 and 2.2.0-beta.0 through 2.2.0-rc.1 have an overly broad default permission vulnerability. Directory paths `/var/lib/containerd`, `/run/containerd/io.containerd.grpc.v1.cri` and `/run/containerd/io.containerd.sandbox.controller.v1.shim` were all created with incorrect permissions. This issue is fixed in versions 1.7.29, 2.0.7, 2.1.5 and 2.2.0. Workarounds include updating system administrator permissions so the host can manually chmod the directories to not have group or world accessible permissions, or to run containerd in rootless mode.</Note>
    </Notes>
    <CVE>CVE-2024-25621</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: tls: handle backlogging of crypto requests

Since we're setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on our
requests to the crypto API, crypto_aead_{encrypt,decrypt} can return
 -EBUSY instead of -EINPROGRESS in valid situations. For example, when
the cryptd queue for AESNI is full (easy to trigger with an
artificially low cryptd.cryptd_max_cpu_qlen), requests will be enqueued
to the backlog but still processed. In that case, the async callback
will also be called twice: first with err == -EINPROGRESS, which it
seems we can just ignore, then with err == 0.

Compared to Sabrina's original patch this version uses the new
tls_*crypt_async_wait() helpers and converts the EBUSY to
EINPROGRESS to avoid having to modify all the error handling
paths. The handling is identical.</Note>
    </Notes>
    <CVE>CVE-2024-26584</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: Add NULL test for 'timing generator' in 'dcn21_set_pipe()'

In "u32 otg_inst = pipe_ctx-&gt;stream_res.tg-&gt;inst;"
pipe_ctx-&gt;stream_res.tg could be NULL, it is relying on the caller to
ensure the tg is not NULL.</Note>
    </Notes>
    <CVE>CVE-2024-26661</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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">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:

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">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">A flaw was found in grub2. A specially crafted JPEG file can cause the JPEG parser of grub2 to incorrectly check the bounds of its internal buffers, resulting in an out-of-bounds write. The possibility of overwriting sensitive information to bypass secure boot protections is not discarded.</Note>
    </Notes>
    <CVE>CVE-2024-45774</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 grub2 where the grub_extcmd_dispatcher() function calls grub_arg_list_alloc() to allocate memory for the grub's argument list. However, it fails to check in case the memory allocation fails. Once the allocation fails, a NULL point will be processed by the parse_option() function, leading grub to crash or, in some rare scenarios, corrupt the IVT data.</Note>
    </Notes>
    <CVE>CVE-2024-45775</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 reading the language .mo file in grub_mofile_open(), grub2 fails to verify an integer overflow when allocating its internal buffer. A crafted .mo file may lead the buffer size calculation to overflow, leading to out-of-bound reads and writes. This flaw allows an attacker to leak sensitive data or overwrite critical data, possibly circumventing secure boot protections.</Note>
    </Notes>
    <CVE>CVE-2024-45776</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 grub2. The calculation of the translation buffer when reading a language .mo file in grub_gettext_getstr_from_position() may overflow, leading to a Out-of-bound write. This issue can be leveraged by an attacker to overwrite grub2's sensitive heap data, eventually leading to the circumvention of secure boot protections.</Note>
    </Notes>
    <CVE>CVE-2024-45777</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 flaw was found when reading a BFS file system. A crafted BFS filesystem may lead to an uncontrolled loop, causing grub2 to crash.</Note>
    </Notes>
    <CVE>CVE-2024-45778</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 integer overflow flaw was found in the BFS file system driver in grub2. When reading a file with an indirect extent map, grub2 fails to validate the number of extent entries to be read. A crafted or corrupted BFS filesystem may cause an integer overflow during the file reading, leading to a heap of bounds read. As a consequence, sensitive data may be leaked, or grub2 will crash.</Note>
    </Notes>
    <CVE>CVE-2024-45779</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 grub2. When reading tar files, grub2 allocates an internal buffer for the file name. However, it fails to properly verify the allocation against possible integer overflows. It's possible to cause the allocation length to overflow with a crafted tar file, leading to a heap out-of-bounds write. This flaw eventually allows an attacker to circumvent secure boot protections.</Note>
    </Notes>
    <CVE>CVE-2024-45780</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 grub2. When reading a symbolic link's name from a UFS filesystem, grub2 fails to validate the string length taken as an input. The lack of validation may lead to a heap out-of-bounds write, causing data integrity issues and eventually allowing an attacker to circumvent secure boot protections.</Note>
    </Notes>
    <CVE>CVE-2024-45781</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 HFS filesystem. When reading an HFS volume's name at grub_fs_mount(), the HFS filesystem driver performs a strcpy() using the user-provided volume name as input without properly validating the volume name's length. This issue may read to a heap-based out-of-bounds writer, impacting grub's sensitive data integrity and eventually leading to a secure boot protection bypass.</Note>
    </Notes>
    <CVE>CVE-2024-45782</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 grub2. When failing to mount an HFS+ grub, the hfsplus filesystem driver doesn't properly set an ERRNO value. This issue may lead to a NULL pointer access.</Note>
    </Notes>
    <CVE>CVE-2024-45783</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 qgroup reserve leaks in cow_file_range

In the buffered write path, the dirty page owns the qgroup reserve until
it creates an ordered_extent.

Therefore, any errors that occur before the ordered_extent is created
must free that reservation, or else the space is leaked. The fstest
generic/475 exercises various IO error paths, and is able to trigger
errors in cow_file_range where we fail to get to allocating the ordered
extent. Note that because we *do* clear delalloc, we are likely to
remove the inode from the delalloc list, so the inodes/pages to not have
invalidate/launder called on them in the commit abort path.

This results in failures at the unmount stage of the test that look like:

  BTRFS: error (device dm-8 state EA) in cleanup_transaction:2018: errno=-5 IO failure
  BTRFS: error (device dm-8 state EA) in btrfs_replace_file_extents:2416: errno=-5 IO failure
  BTRFS warning (device dm-8 state EA): qgroup 0/5 has unreleased space, type 0 rsv 28672
  ------------[ cut here ]------------
  WARNING: CPU: 3 PID: 22588 at fs/btrfs/disk-io.c:4333 close_ctree+0x222/0x4d0 [btrfs]
  Modules linked in: btrfs blake2b_generic libcrc32c xor zstd_compress raid6_pq
  CPU: 3 PID: 22588 Comm: umount Kdump: loaded Tainted: G W          6.10.0-rc7-gab56fde445b8 #21
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014
  RIP: 0010:close_ctree+0x222/0x4d0 [btrfs]
  RSP: 0018:ffffb4465283be00 EFLAGS: 00010202
  RAX: 0000000000000001 RBX: ffffa1a1818e1000 RCX: 0000000000000001
  RDX: 0000000000000000 RSI: ffffb4465283bbe0 RDI: ffffa1a19374fcb8
  RBP: ffffa1a1818e13c0 R08: 0000000100028b16 R09: 0000000000000000
  R10: 0000000000000003 R11: 0000000000000003 R12: ffffa1a18ad7972c
  R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
  FS:  00007f9168312b80(0000) GS:ffffa1a4afcc0000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f91683c9140 CR3: 000000010acaa000 CR4: 00000000000006f0
  Call Trace:
   &lt;TASK&gt;
   ? close_ctree+0x222/0x4d0 [btrfs]
   ? __warn.cold+0x8e/0xea
   ? close_ctree+0x222/0x4d0 [btrfs]
   ? report_bug+0xff/0x140
   ? handle_bug+0x3b/0x70
   ? exc_invalid_op+0x17/0x70
   ? asm_exc_invalid_op+0x1a/0x20
   ? close_ctree+0x222/0x4d0 [btrfs]
   generic_shutdown_super+0x70/0x160
   kill_anon_super+0x11/0x40
   btrfs_kill_super+0x11/0x20 [btrfs]
   deactivate_locked_super+0x2e/0xa0
   cleanup_mnt+0xb5/0x150
   task_work_run+0x57/0x80
   syscall_exit_to_user_mode+0x121/0x130
   do_syscall_64+0xab/0x1a0
   entry_SYSCALL_64_after_hwframe+0x77/0x7f
  RIP: 0033:0x7f916847a887
  ---[ end trace 0000000000000000 ]---
  BTRFS error (device dm-8 state EA): qgroup reserved space leaked

Cases 2 and 3 in the out_reserve path both pertain to this type of leak
and must free the reserved qgroup data. Because it is already an error
path, I opted not to handle the possible errors in
btrfs_free_qgroup_data.</Note>
    </Notes>
    <CVE>CVE-2024-46733</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">grub2 allowed attackers with access to the grub shell to access files on the encrypted disks.</Note>
    </Notes>
    <CVE>CVE-2024-49504</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

cifs: Fix buffer overflow when parsing NFS reparse points

ReparseDataLength is sum of the InodeType size and DataBuffer size.
So to get DataBuffer size it is needed to subtract InodeType's size from
ReparseDataLength.

Function cifs_strndup_from_utf16() is currentlly accessing buf-&gt;DataBuffer
at position after the end of the buffer because it does not subtract
InodeType size from the length. Fix this problem and correctly subtract
variable len.

Member InodeType is present only when reparse buffer is large enough. Check
for ReparseDataLength before accessing InodeType to prevent another invalid
memory access.

Major and minor rdev values are present also only when reparse buffer is
large enough. Check for reparse buffer size before calling reparse_mkdev().</Note>
    </Notes>
    <CVE>CVE-2024-49996</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: sync_linked_regs() must preserve subreg_def

Range propagation must not affect subreg_def marks, otherwise the
following example is rewritten by verifier incorrectly when
BPF_F_TEST_RND_HI32 flag is set:

  0: call bpf_ktime_get_ns                   call bpf_ktime_get_ns
  1: r0 &amp;= 0x7fffffff       after verifier   r0 &amp;= 0x7fffffff
  2: w1 = w0                rewrites         w1 = w0
  3: if w0 &lt; 10 goto +0     --------------&gt;  r11 = 0x2f5674a6     (r)
  4: r1 &gt;&gt;= 32                               r11 &lt;&lt;= 32           (r)
  5: r0 = r1                                 r1 |= r11            (r)
  6: exit;                                   if w0 &lt; 0xa goto pc+0
                                             r1 &gt;&gt;= 32
                                             r0 = r1
                                             exit

(or zero extension of w1 at (2) is missing for architectures that
 require zero extension for upper register half).

The following happens w/o this patch:
- r0 is marked as not a subreg at (0);
- w1 is marked as subreg at (2);
- w1 subreg_def is overridden at (3) by copy_register_state();
- w1 is read at (5) but mark_insn_zext() does not mark (2)
  for zero extension, because w1 subreg_def is not set;
- because of BPF_F_TEST_RND_HI32 flag verifier inserts random
  value for hi32 bits of (2) (marked (r));
- this random value is read at (5).</Note>
    </Notes>
    <CVE>CVE-2024-53125</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">GNU GRUB (aka GRUB2) through 2.12 has a heap-based buffer overflow in fs/hfs.c via crafted sblock data in an HFS filesystem.</Note>
    </Notes>
    <CVE>CVE-2024-56737</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">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:

sched/core: Prevent rescheduling when interrupts are disabled

David reported a warning observed while loop testing kexec jump:

  Interrupts enabled after irqrouter_resume+0x0/0x50
  WARNING: CPU: 0 PID: 560 at drivers/base/syscore.c:103 syscore_resume+0x18a/0x220
   kernel_kexec+0xf6/0x180
   __do_sys_reboot+0x206/0x250
   do_syscall_64+0x95/0x180

The corresponding interrupt flag trace:

  hardirqs last  enabled at (15573): [&lt;ffffffffa8281b8e&gt;] __up_console_sem+0x7e/0x90
  hardirqs last disabled at (15580): [&lt;ffffffffa8281b73&gt;] __up_console_sem+0x63/0x90

That means __up_console_sem() was invoked with interrupts enabled. Further
instrumentation revealed that in the interrupt disabled section of kexec
jump one of the syscore_suspend() callbacks woke up a task, which set the
NEED_RESCHED flag. A later callback in the resume path invoked
cond_resched() which in turn led to the invocation of the scheduler:

  __cond_resched+0x21/0x60
  down_timeout+0x18/0x60
  acpi_os_wait_semaphore+0x4c/0x80
  acpi_ut_acquire_mutex+0x3d/0x100
  acpi_ns_get_node+0x27/0x60
  acpi_ns_evaluate+0x1cb/0x2d0
  acpi_rs_set_srs_method_data+0x156/0x190
  acpi_pci_link_set+0x11c/0x290
  irqrouter_resume+0x54/0x60
  syscore_resume+0x6a/0x200
  kernel_kexec+0x145/0x1c0
  __do_sys_reboot+0xeb/0x240
  do_syscall_64+0x95/0x180

This is a long standing problem, which probably got more visible with
the recent printk changes. Something does a task wakeup and the
scheduler sets the NEED_RESCHED flag. cond_resched() sees it set and
invokes schedule() from a completely bogus context. The scheduler
enables interrupts after context switching, which causes the above
warning at the end.

Quite some of the code paths in syscore_suspend()/resume() can result in
triggering a wakeup with the exactly same consequences. They might not
have done so yet, but as they share a lot of code with normal operations
it's just a question of time.

The problem only affects the PREEMPT_NONE and PREEMPT_VOLUNTARY scheduling
models. Full preemption is not affected as cond_resched() is disabled and
the preemption check preemptible() takes the interrupt disabled flag into
account.

Cure the problem by adding a corresponding check into cond_resched().</Note>
    </Notes>
    <CVE>CVE-2024-58090</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: btnxpuart: Resolve TX timeout error in power save stress test

This fixes the tx timeout issue seen while running a stress test on
btnxpuart for couple of hours, such that the interval between two HCI
commands coincide with the power save timeout value of 2 seconds.

Test procedure using bash script:
&lt;load btnxpuart.ko&gt;
hciconfig hci0 up
//Enable Power Save feature
hcitool -i hci0 cmd 3f 23 02 00 00
while (true)
do
    hciconfig hci0 leadv
    sleep 2
    hciconfig hci0 noleadv
    sleep 2
done

Error log, after adding few more debug prints:
Bluetooth: btnxpuart_queue_skb(): 01 0A 20 01 00
Bluetooth: hci0: Set UART break: on, status=0
Bluetooth: hci0: btnxpuart_tx_wakeup() tx_work scheduled
Bluetooth: hci0: btnxpuart_tx_work() dequeue: 01 0A 20 01 00
Can't set advertise mode on hci0: Connection timed out (110)
Bluetooth: hci0: command 0x200a tx timeout

When the power save mechanism turns on UART break, and btnxpuart_tx_work()
is scheduled simultaneously, psdata-&gt;ps_state is read as PS_STATE_AWAKE,
which prevents the psdata-&gt;work from being scheduled, which is responsible
to turn OFF UART break.

This issue is fixed by adding a ps_lock mutex around UART break on/off as
well as around ps_state read/write.
btnxpuart_tx_wakeup() will now read updated ps_state value. If ps_state is
PS_STATE_SLEEP, it will first schedule psdata-&gt;work, and then it will
reschedule itself once UART break has been turned off and ps_state is
PS_STATE_AWAKE.

Tested above script for 50,000 iterations and TX timeout error was not
observed anymore.</Note>
    </Notes>
    <CVE>CVE-2024-58238</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: stop recv() if initial process_rx_list gave us non-DATA

If we have a non-DATA record on the rx_list and another record of the
same type still on the queue, we will end up merging them:
 - process_rx_list copies the non-DATA record
 - we start the loop and process the first available record since it's
   of the same type
 - we break out of the loop since the record was not DATA

Just check the record type and jump to the end in case process_rx_list
did some work.</Note>
    </Notes>
    <CVE>CVE-2024-58239</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 command/gpg. In some scenarios, hooks created by loaded modules are not removed when the related module is unloaded. This flaw allows an attacker to force grub2 to call the hooks once the module that registered it was unloaded, leading to a use-after-free vulnerability. If correctly exploited, this vulnerability may result in arbitrary code execution, eventually allowing the attacker to bypass secure boot protections.</Note>
    </Notes>
    <CVE>CVE-2025-0622</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 grub2. During the network boot process, when trying to search for the configuration file, grub copies data from a user controlled environment variable into an internal buffer using the grub_strcpy() function. During this step, it fails to consider the environment variable length when allocating the internal buffer, resulting in an out-of-bounds write. If correctly exploited, this issue may result in remote code execution through the same network segment grub is searching for the boot information, which can be used to by-pass secure boot protections.</Note>
    </Notes>
    <CVE>CVE-2025-0624</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 grub2. When performing a symlink lookup, the grub's UFS module checks the inode's data size to allocate the internal buffer to read the file content, however, it fails to check if the symlink data size has overflown. When this occurs, grub_malloc() may be called with a smaller value than needed. When further reading the data from the disk into the buffer, the grub_ufs_lookup_symlink() function will write past the end of the allocated size. An attack can leverage this by crafting a malicious filesystem, and as a result, it will corrupt data stored in the heap, allowing for arbitrary code execution used to by-pass secure boot mechanisms.</Note>
    </Notes>
    <CVE>CVE-2025-0677</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 grub2. When reading data from a squash4 filesystem, grub's squash4 fs module uses user-controlled parameters from the filesystem geometry to determine the internal buffer size, however, it improperly checks for integer overflows. A maliciously crafted filesystem may lead some of those buffer size calculations to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result, the direct_read() will perform a heap based out-of-bounds write during data reading. This flaw may be leveraged to corrupt grub's internal critical data and may result in arbitrary code execution, by-passing secure boot protections.</Note>
    </Notes>
    <CVE>CVE-2025-0678</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 grub2. When performing a symlink lookup from a reiserfs filesystem, grub's reiserfs fs module uses user-controlled parameters from the filesystem geometry to determine the internal buffer size, however, it improperly checks for integer overflows. A maliciouly crafted filesystem may lead some of those buffer size calculations to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result, the grub_reiserfs_read_symlink() will call grub_reiserfs_read_real() with a overflown length parameter, leading to a heap based out-of-bounds write during data reading. This flaw may be leveraged to corrupt grub's internal critical data and can result in arbitrary code execution, by-passing secure boot protections.</Note>
    </Notes>
    <CVE>CVE-2025-0684</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 grub2. When reading data from a jfs filesystem, grub's jfs filesystem module uses user-controlled parameters from the filesystem geometry to determine the internal buffer size, however, it improperly checks for integer overflows. A maliciouly crafted filesystem may lead some of those buffer size calculations to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result, the grub_jfs_lookup_symlink() function will write past the internal buffer length during grub_jfs_read_file(). This issue can be leveraged to corrupt grub's internal critical data and may result in arbitrary code execution, by-passing secure boot protections.</Note>
    </Notes>
    <CVE>CVE-2025-0685</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 grub2. When performing a symlink lookup from a romfs filesystem, grub's romfs filesystem module uses user-controlled parameters from the filesystem geometry to determine the internal buffer size, however, it improperly checks for integer overflows. A maliciously crafted filesystem may lead some of those buffer size calculations to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result, the grub_romfs_read_symlink() may cause out-of-bounds writes when the calling grub_disk_read() function. This issue may be leveraged to corrupt grub's internal critical data and can result in arbitrary code execution by-passing secure boot protections.</Note>
    </Notes>
    <CVE>CVE-2025-0686</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 reading data from disk, the grub's UDF filesystem module utilizes the user controlled data length metadata to allocate its internal buffers. In certain scenarios, while iterating through disk sectors, it assumes the read size from the disk is always smaller than the allocated buffer size which is not guaranteed. A crafted filesystem image may lead to a heap-based buffer overflow resulting in critical data to be corrupted, resulting in the risk of arbitrary code execution by-passing secure boot protections.</Note>
    </Notes>
    <CVE>CVE-2025-0689</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 read command is used to read the keyboard input from the user, while reads it keeps the input length in a 32-bit integer value which is further used to reallocate the line buffer to accept the next character. During this process, with a line big enough it's possible to make this variable to overflow leading to a out-of-bounds write in the heap based buffer. This flaw may be leveraged to corrupt grub's internal critical data and secure boot bypass is not discarded as consequence.</Note>
    </Notes>
    <CVE>CVE-2025-0690</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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">A use-after-free vulnerability was found in libxslt while parsing xsl nodes that may lead to the dereference of expired pointers and application crash.</Note>
    </Notes>
    <CVE>CVE-2025-10911</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 grub2. Grub's dump command is not blocked when grub is in lockdown mode, which allows the user to read any memory information, and an attacker may leverage this in order to extract signatures, salts, and other sensitive information from the memory.</Note>
    </Notes>
    <CVE>CVE-2025-1118</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 reading data from a hfs filesystem, grub's hfs filesystem module uses user-controlled parameters from the filesystem metadata to calculate the internal buffers size, however it misses to properly check for integer overflows. A maliciouly crafted filesystem may lead some of those buffer size calculation to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result the hfsplus_open_compressed_real() function will write past of the internal buffer length. This flaw may be leveraged to corrupt grub's internal critical data and may result in arbitrary code execution by-passing secure boot protections.</Note>
    </Notes>
    <CVE>CVE-2025-1125</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 exsltFuncResultComp() function of libxslt, which handles EXSLT &lt;func:result&gt; elements during stylesheet parsing. Due to improper type handling, the function may treat an XML document node as a regular XML element node, resulting in a type confusion. This can cause unexpected memory reads and potential crashes. While difficult to exploit, the flaw could lead to application instability or denial of service.</Note>
    </Notes>
    <CVE>CVE-2025-11731</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: 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:

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:

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:

usb: xhci: Apply the link chain quirk on NEC isoc endpoints

Two clearly different specimens of NEC uPD720200 (one with start/stop
bug, one without) were seen to cause IOMMU faults after some Missed
Service Errors. Faulting address is immediately after a transfer ring
segment and patched dynamic debug messages revealed that the MSE was
received when waiting for a TD near the end of that segment:

[ 1.041954] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0
[ 1.042120] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09000 flags=0x0000]
[ 1.042146] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000]

It gets even funnier if the next page is a ring segment accessible to
the HC. Below, it reports MSE in segment at ff1e8000, plows through a
zero-filled page at ff1e9000 and starts reporting events for TRBs in
page at ff1ea000 every microframe, instead of jumping to seg ff1e6000.

[ 7.041671] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0
[ 7.041999] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0
[ 7.042011] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint
[ 7.042028] xhci_hcd: All TDs skipped for slot 1 ep 2. Clear skip flag.
[ 7.042134] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint
[ 7.042138] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31
[ 7.042144] xhci_hcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820
[ 7.042259] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint
[ 7.042262] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31
[ 7.042266] xhci_hcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820

At some point completion events change from Isoch Buffer Overrun to
Short Packet and the HC finally finds cycle bit mismatch in ff1ec000.

[ 7.098130] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13
[ 7.098132] xhci_hcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820
[ 7.098254] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13
[ 7.098256] xhci_hcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820
[ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2

It's possible that data from the isochronous device were written to
random buffers of pending TDs on other endpoints (either IN or OUT),
other devices or even other HCs in the same IOMMU domain.

Lastly, an error from a different USB device on another HC. Was it
caused by the above? I don't know, but it may have been. The disk
was working without any other issues and generated PCIe traffic to
starve the NEC of upstream BW and trigger those MSEs. The two HCs
shared one x1 slot by means of a commercial "PCIe splitter" board.

[ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhci_hcd
[ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s
[ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00
[ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0

Fortunately, it appears that this ridiculous bug is avoided by setting
the chain bit of Link TRBs on isochronous rings. Other ancient HCs are
known which also expect the bit to be set and they ignore Link TRBs if
it's not. Reportedly, 0.95 spec guaranteed that the bit is set.

The bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reports
tens of MSEs per second and runs into the bug within seconds. Chaining
Link TRBs allows the same workload to run for many minutes, many times.

No ne
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-22022</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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">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">Go JOSE provides an implementation of the Javascript Object Signing and Encryption set of standards in Go, including support for JSON Web Encryption (JWE), JSON Web Signature (JWS), and JSON Web Token (JWT) standards. In versions on the 4.x branch prior to version 4.0.5, when parsing compact JWS or JWE input, Go JOSE could use excessive memory. The code used strings.Split(token, ".") to split JWT tokens, which is vulnerable to excessive memory consumption when processing maliciously crafted tokens with a large number of `.` characters.  An attacker could exploit this by sending numerous malformed tokens, leading to memory exhaustion and a Denial of Service. Version 4.0.5 fixes this issue. As a workaround, applications could pre-validate that payloads passed to Go JOSE do not contain an excessive number of `.` characters.</Note>
    </Notes>
    <CVE>CVE-2025-27144</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">runc is a CLI tool for spawning and running containers according to the OCI specification. In versions 1.2.7 and below, 1.3.0-rc.1 through 1.3.1, 1.4.0-rc.1 and 1.4.0-rc.2 files, runc would not perform sufficient verification that the source of the bind-mount (i.e., the container's /dev/null) was actually a real /dev/null inode when using the container's /dev/null to mask. This exposes two methods of attack:  an arbitrary mount gadget, leading to host information disclosure, host denial of service, container escape, or a bypassing of maskedPaths. This issue is fixed in versions 1.2.8, 1.3.3 and 1.4.0-rc.3.</Note>
    </Notes>
    <CVE>CVE-2025-31133</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:

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:

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:

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:

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:

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:

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:

net: mctp: Don't access ifa_index when missing

In mctp_dump_addrinfo, ifa_index can be used to filter interfaces, but
only when the struct ifaddrmsg is provided. Otherwise it will be
comparing to uninitialised memory - reproducible in the syzkaller case from
dhcpd, or busybox "ip addr show".

The kernel MCTP implementation has always filtered by ifa_index, so
existing userspace programs expecting to dump MCTP addresses must
already be passing a valid ifa_index value (either 0 or a real index).

BUG: KMSAN: uninit-value in mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128
 mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128
 rtnl_dump_all+0x3ec/0x5b0 net/core/rtnetlink.c:4380
 rtnl_dumpit+0xd5/0x2f0 net/core/rtnetlink.c:6824
 netlink_dump+0x97b/0x1690 net/netlink/af_netlink.c:2309</Note>
    </Notes>
    <CVE>CVE-2025-38006</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/page_alloc: fix race condition in unaccepted memory handling

The page allocator tracks the number of zones that have unaccepted memory
using static_branch_enc/dec() and uses that static branch in hot paths to
determine if it needs to deal with unaccepted memory.

Borislav and Thomas pointed out that the tracking is racy: operations on
static_branch are not serialized against adding/removing unaccepted pages
to/from the zone.

Sanity checks inside static_branch machinery detects it:

WARNING: CPU: 0 PID: 10 at kernel/jump_label.c:276 __static_key_slow_dec_cpuslocked+0x8e/0xa0

The comment around the WARN() explains the problem:

	/*
	 * Warn about the '-1' case though; since that means a
	 * decrement is concurrent with a first (0-&gt;1) increment. IOW
	 * people are trying to disable something that wasn't yet fully
	 * enabled. This suggests an ordering problem on the user side.
	 */

The effect of this static_branch optimization is only visible on
microbenchmark.

Instead of adding more complexity around it, remove it altogether.</Note>
    </Notes>
    <CVE>CVE-2025-38008</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

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:

__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:

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:

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:

scsi: target: iscsi: Fix timeout on deleted connection

NOPIN response timer may expire on a deleted connection and crash with
such logs:

Did not receive response to NOPIN on CID: 0, failing connection for I_T Nexus (null),i,0x00023d000125,iqn.2017-01.com.iscsi.target,t,0x3d

BUG: Kernel NULL pointer dereference on read at 0x00000000
NIP  strlcpy+0x8/0xb0
LR iscsit_fill_cxn_timeout_err_stats+0x5c/0xc0 [iscsi_target_mod]
Call Trace:
 iscsit_handle_nopin_response_timeout+0xfc/0x120 [iscsi_target_mod]
 call_timer_fn+0x58/0x1f0
 run_timer_softirq+0x740/0x860
 __do_softirq+0x16c/0x420
 irq_exit+0x188/0x1c0
 timer_interrupt+0x184/0x410

That is because nopin response timer may be re-started on nopin timer
expiration.

Stop nopin timer before stopping the nopin response timer to be sure
that no one of them will be re-started.</Note>
    </Notes>
    <CVE>CVE-2025-38075</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

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:

HID: usbhid: Eliminate recurrent out-of-bounds bug in usbhid_parse()

Update struct hid_descriptor to better reflect the mandatory and
optional parts of the HID Descriptor as per USB HID 1.11 specification.
Note: the kernel currently does not parse any optional HID class
descriptors, only the mandatory report descriptor.

Update all references to member element desc[0] to rpt_desc.

Add test to verify bLength and bNumDescriptors values are valid.

Replace the for loop with direct access to the mandatory HID class
descriptor member for the report descriptor. This eliminates the
possibility of getting an out-of-bounds fault.

Add a warning message if the HID descriptor contains any unsupported
optional HID class descriptors.</Note>
    </Notes>
    <CVE>CVE-2025-38103</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:

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:

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:

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:

scsi: core: ufs: Fix a hang in the error handler

ufshcd_err_handling_prepare() calls ufshcd_rpm_get_sync(). The latter
function can only succeed if UFSHCD_EH_IN_PROGRESS is not set because
resuming involves submitting a SCSI command and ufshcd_queuecommand()
returns SCSI_MLQUEUE_HOST_BUSY if UFSHCD_EH_IN_PROGRESS is set. Fix this
hang by setting UFSHCD_EH_IN_PROGRESS after ufshcd_rpm_get_sync() has
been called instead of before.

Backtrace:
__switch_to+0x174/0x338
__schedule+0x600/0x9e4
schedule+0x7c/0xe8
schedule_timeout+0xa4/0x1c8
io_schedule_timeout+0x48/0x70
wait_for_common_io+0xa8/0x160 //waiting on START_STOP
wait_for_completion_io_timeout+0x10/0x20
blk_execute_rq+0xe4/0x1e4
scsi_execute_cmd+0x108/0x244
ufshcd_set_dev_pwr_mode+0xe8/0x250
__ufshcd_wl_resume+0x94/0x354
ufshcd_wl_runtime_resume+0x3c/0x174
scsi_runtime_resume+0x64/0xa4
rpm_resume+0x15c/0xa1c
__pm_runtime_resume+0x4c/0x90 // Runtime resume ongoing
ufshcd_err_handler+0x1a0/0xd08
process_one_work+0x174/0x808
worker_thread+0x15c/0x490
kthread+0xf4/0x1ec
ret_from_fork+0x10/0x20

[ bvanassche: rewrote patch description ]</Note>
    </Notes>
    <CVE>CVE-2025-38119</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 EST

If the ptp_rate recorded earlier in the driver happens to be 0, this
bogus value will propagate up to EST configuration, where it will
trigger a division by 0.

Prevent this division by 0 by adding the corresponding check and error
code.</Note>
    </Notes>
    <CVE>CVE-2025-38125</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

net: openvswitch: Fix the dead loop of MPLS parse

The unexpected MPLS packet may not end with the bottom label stack.
When there are many stacks, The label count value has wrapped around.
A dead loop occurs, soft lockup/CPU stuck finally.

stack backtrace:
UBSAN: array-index-out-of-bounds in /build/linux-0Pa0xK/linux-5.15.0/net/openvswitch/flow.c:662:26
index -1 is out of range for type '__be32 [3]'
CPU: 34 PID: 0 Comm: swapper/34 Kdump: loaded Tainted: G           OE   5.15.0-121-generic #131-Ubuntu
Hardware name: Dell Inc. PowerEdge C6420/0JP9TF, BIOS 2.12.2 07/14/2021
Call Trace:
 &lt;IRQ&gt;
 show_stack+0x52/0x5c
 dump_stack_lvl+0x4a/0x63
 dump_stack+0x10/0x16
 ubsan_epilogue+0x9/0x36
 __ubsan_handle_out_of_bounds.cold+0x44/0x49
 key_extract_l3l4+0x82a/0x840 [openvswitch]
 ? kfree_skbmem+0x52/0xa0
 key_extract+0x9c/0x2b0 [openvswitch]
 ovs_flow_key_extract+0x124/0x350 [openvswitch]
 ovs_vport_receive+0x61/0xd0 [openvswitch]
 ? kernel_init_free_pages.part.0+0x4a/0x70
 ? get_page_from_freelist+0x353/0x540
 netdev_port_receive+0xc4/0x180 [openvswitch]
 ? netdev_port_receive+0x180/0x180 [openvswitch]
 netdev_frame_hook+0x1f/0x40 [openvswitch]
 __netif_receive_skb_core.constprop.0+0x23a/0xf00
 __netif_receive_skb_list_core+0xfa/0x240
 netif_receive_skb_list_internal+0x18e/0x2a0
 napi_complete_done+0x7a/0x1c0
 bnxt_poll+0x155/0x1c0 [bnxt_en]
 __napi_poll+0x30/0x180
 net_rx_action+0x126/0x280
 ? bnxt_msix+0x67/0x80 [bnxt_en]
 handle_softirqs+0xda/0x2d0
 irq_exit_rcu+0x96/0xc0
 common_interrupt+0x8e/0xa0
 &lt;/IRQ&gt;</Note>
    </Notes>
    <CVE>CVE-2025-38146</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

clk: bcm: rpi: Add NULL check in raspberrypi_clk_register()

devm_kasprintf() returns NULL when memory allocation fails. Currently,
raspberrypi_clk_register() 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-38160</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

tipc: fix null-ptr-deref when acquiring remote ip of ethernet bearer

The reproduction steps:
1. create a tun interface
2. enable l2 bearer
3. TIPC_NL_UDP_GET_REMOTEIP with media name set to tun

tipc: Started in network mode
tipc: Node identity 8af312d38a21, cluster identity 4711
tipc: Enabled bearer &lt;eth:syz_tun&gt;, priority 1
Oops: general protection fault
KASAN: null-ptr-deref in range
CPU: 1 UID: 1000 PID: 559 Comm: poc Not tainted 6.16.0-rc1+ #117 PREEMPT
Hardware name: QEMU Ubuntu 24.04 PC
RIP: 0010:tipc_udp_nl_dump_remoteip+0x4a4/0x8f0

the ub was in fact a struct dev.

when bid != 0 &amp;&amp; skip_cnt != 0, bearer_list[bid] may be NULL or
other media when other thread changes it.

fix this by checking media_id.</Note>
    </Notes>
    <CVE>CVE-2025-38184</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: atmtcp: Free invalid length skb in atmtcp_c_send().

syzbot reported the splat below. [0]

vcc_sendmsg() copies data passed from userspace to skb and passes
it to vcc-&gt;dev-&gt;ops-&gt;send().

atmtcp_c_send() accesses skb-&gt;data as struct atmtcp_hdr after
checking if skb-&gt;len is 0, but it's not enough.

Also, when skb-&gt;len == 0, skb and sk (vcc) were leaked because
dev_kfree_skb() is not called and sk_wmem_alloc adjustment is missing
to revert atm_account_tx() in vcc_sendmsg(), which is expected
to be done in atm_pop_raw().

Let's properly free skb with an invalid length in atmtcp_c_send().

[0]:
BUG: KMSAN: uninit-value in atmtcp_c_send+0x255/0xed0 drivers/atm/atmtcp.c:294
 atmtcp_c_send+0x255/0xed0 drivers/atm/atmtcp.c:294
 vcc_sendmsg+0xd7c/0xff0 net/atm/common.c:644
 sock_sendmsg_nosec net/socket.c:712 [inline]
 __sock_sendmsg+0x330/0x3d0 net/socket.c:727
 ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2566
 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620
 __sys_sendmsg net/socket.c:2652 [inline]
 __do_sys_sendmsg net/socket.c:2657 [inline]
 __se_sys_sendmsg net/socket.c:2655 [inline]
 __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2655
 x64_sys_call+0x32fb/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:47
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Uninit was created at:
 slab_post_alloc_hook mm/slub.c:4154 [inline]
 slab_alloc_node mm/slub.c:4197 [inline]
 kmem_cache_alloc_node_noprof+0x818/0xf00 mm/slub.c:4249
 kmalloc_reserve+0x13c/0x4b0 net/core/skbuff.c:579
 __alloc_skb+0x347/0x7d0 net/core/skbuff.c:670
 alloc_skb include/linux/skbuff.h:1336 [inline]
 vcc_sendmsg+0xb40/0xff0 net/atm/common.c:628
 sock_sendmsg_nosec net/socket.c:712 [inline]
 __sock_sendmsg+0x330/0x3d0 net/socket.c:727
 ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2566
 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620
 __sys_sendmsg net/socket.c:2652 [inline]
 __do_sys_sendmsg net/socket.c:2657 [inline]
 __se_sys_sendmsg net/socket.c:2655 [inline]
 __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2655
 x64_sys_call+0x32fb/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:47
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

CPU: 1 UID: 0 PID: 5798 Comm: syz-executor192 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(undef)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025</Note>
    </Notes>
    <CVE>CVE-2025-38185</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

atm: Revert atm_account_tx() if copy_from_iter_full() fails.

In vcc_sendmsg(), we account skb-&gt;truesize to sk-&gt;sk_wmem_alloc by
atm_account_tx().

It is expected to be reverted by atm_pop_raw() later called by
vcc-&gt;dev-&gt;ops-&gt;send(vcc, skb).

However, vcc_sendmsg() misses the same revert when copy_from_iter_full()
fails, and then we will leak a socket.

Let's factorise the revert part as atm_return_tx() and call it in
the failure path.

Note that the corresponding sk_wmem_alloc operation can be found in
alloc_tx() as of the blamed commit.

  $ git blame -L:alloc_tx net/atm/common.c c55fa3cccbc2c~</Note>
    </Notes>
    <CVE>CVE-2025-38190</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

netfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAX

Otherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof()
when resizing hashtable because __GFP_NOWARN is unset.

Similar to:

  b541ba7d1f5a ("netfilter: conntrack: clamp maximum hashtable size to INT_MAX")</Note>
    </Notes>
    <CVE>CVE-2025-38201</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

drm/amd/display: Avoid divide by zero by initializing dummy pitch to 1

[Why]
If the dummy values in `populate_dummy_dml_surface_cfg()` aren't updated
then they can lead to a divide by zero in downstream callers like
CalculateVMAndRowBytes()

[How]
Initialize dummy value to a value to avoid divide by zero.</Note>
    </Notes>
    <CVE>CVE-2025-38205</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

smb: client: add NULL check in automount_fullpath

page is checked for null in __build_path_from_dentry_optional_prefix
when tcon-&gt;origin_fullpath is not set. However, the check is missing when
it is set.
Add a check to prevent a potential NULL pointer dereference.</Note>
    </Notes>
    <CVE>CVE-2025-38208</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

sched/rt: Fix race in push_rt_task

Overview
========
When a CPU chooses to call push_rt_task and picks a task to push to
another CPU's runqueue then it will call find_lock_lowest_rq method
which would take a double lock on both CPUs' runqueues. If one of the
locks aren't readily available, it may lead to dropping the current
runqueue lock and reacquiring both the locks at once. During this window
it is possible that the task is already migrated and is running on some
other CPU. These cases are already handled. However, if the task is
migrated and has already been executed and another CPU is now trying to
wake it up (ttwu) such that it is queued again on the runqeue
(on_rq is 1) and also if the task was run by the same CPU, then the
current checks will pass even though the task was migrated out and is no
longer in the pushable tasks list.

Crashes
=======
This bug resulted in quite a few flavors of crashes triggering kernel
panics with various crash signatures such as assert failures, page
faults, null pointer dereferences, and queue corruption errors all
coming from scheduler itself.

Some of the crashes:
-&gt; kernel BUG at kernel/sched/rt.c:1616! BUG_ON(idx &gt;= MAX_RT_PRIO)
   Call Trace:
   ? __die_body+0x1a/0x60
   ? die+0x2a/0x50
   ? do_trap+0x85/0x100
   ? pick_next_task_rt+0x6e/0x1d0
   ? do_error_trap+0x64/0xa0
   ? pick_next_task_rt+0x6e/0x1d0
   ? exc_invalid_op+0x4c/0x60
   ? pick_next_task_rt+0x6e/0x1d0
   ? asm_exc_invalid_op+0x12/0x20
   ? pick_next_task_rt+0x6e/0x1d0
   __schedule+0x5cb/0x790
   ? update_ts_time_stats+0x55/0x70
   schedule_idle+0x1e/0x40
   do_idle+0x15e/0x200
   cpu_startup_entry+0x19/0x20
   start_secondary+0x117/0x160
   secondary_startup_64_no_verify+0xb0/0xbb

-&gt; BUG: kernel NULL pointer dereference, address: 00000000000000c0
   Call Trace:
   ? __die_body+0x1a/0x60
   ? no_context+0x183/0x350
   ? __warn+0x8a/0xe0
   ? exc_page_fault+0x3d6/0x520
   ? asm_exc_page_fault+0x1e/0x30
   ? pick_next_task_rt+0xb5/0x1d0
   ? pick_next_task_rt+0x8c/0x1d0
   __schedule+0x583/0x7e0
   ? update_ts_time_stats+0x55/0x70
   schedule_idle+0x1e/0x40
   do_idle+0x15e/0x200
   cpu_startup_entry+0x19/0x20
   start_secondary+0x117/0x160
   secondary_startup_64_no_verify+0xb0/0xbb

-&gt; BUG: unable to handle page fault for address: ffff9464daea5900
   kernel BUG at kernel/sched/rt.c:1861! BUG_ON(rq-&gt;cpu != task_cpu(p))

-&gt; kernel BUG at kernel/sched/rt.c:1055! BUG_ON(!rq-&gt;nr_running)
   Call Trace:
   ? __die_body+0x1a/0x60
   ? die+0x2a/0x50
   ? do_trap+0x85/0x100
   ? dequeue_top_rt_rq+0xa2/0xb0
   ? do_error_trap+0x64/0xa0
   ? dequeue_top_rt_rq+0xa2/0xb0
   ? exc_invalid_op+0x4c/0x60
   ? dequeue_top_rt_rq+0xa2/0xb0
   ? asm_exc_invalid_op+0x12/0x20
   ? dequeue_top_rt_rq+0xa2/0xb0
   dequeue_rt_entity+0x1f/0x70
   dequeue_task_rt+0x2d/0x70
   __schedule+0x1a8/0x7e0
   ? blk_finish_plug+0x25/0x40
   schedule+0x3c/0xb0
   futex_wait_queue_me+0xb6/0x120
   futex_wait+0xd9/0x240
   do_futex+0x344/0xa90
   ? get_mm_exe_file+0x30/0x60
   ? audit_exe_compare+0x58/0x70
   ? audit_filter_rules.constprop.26+0x65e/0x1220
   __x64_sys_futex+0x148/0x1f0
   do_syscall_64+0x30/0x80
   entry_SYSCALL_64_after_hwframe+0x62/0xc7

-&gt; BUG: unable to handle page fault for address: ffff8cf3608bc2c0
   Call Trace:
   ? __die_body+0x1a/0x60
   ? no_context+0x183/0x350
   ? spurious_kernel_fault+0x171/0x1c0
   ? exc_page_fault+0x3b6/0x520
   ? plist_check_list+0x15/0x40
   ? plist_check_list+0x2e/0x40
   ? asm_exc_page_fault+0x1e/0x30
   ? _cond_resched+0x15/0x30
   ? futex_wait_queue_me+0xc8/0x120
   ? futex_wait+0xd9/0x240
   ? try_to_wake_up+0x1b8/0x490
   ? futex_wake+0x78/0x160
   ? do_futex+0xcd/0xa90
   ? plist_check_list+0x15/0x40
   ? plist_check_list+0x2e/0x40
   ? plist_del+0x6a/0xd0
   ? plist_check_list+0x15/0x40
   ? plist_check_list+0x2e/0x40
   ? dequeue_pushable_task+0x20/0x70
   ? __schedule+0x382/0x7e0
   ? asm_sysvec_reschedule_i
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-38234</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: 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:

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:

atm: Release atm_dev_mutex after removing procfs in atm_dev_deregister().

syzbot reported a warning below during atm_dev_register(). [0]

Before creating a new device and procfs/sysfs for it, atm_dev_register()
looks up a duplicated device by __atm_dev_lookup().  These operations are
done under atm_dev_mutex.

However, when removing a device in atm_dev_deregister(), it releases the
mutex just after removing the device from the list that __atm_dev_lookup()
iterates over.

So, there will be a small race window where the device does not exist on
the device list but procfs/sysfs are still not removed, triggering the
splat.

Let's hold the mutex until procfs/sysfs are removed in
atm_dev_deregister().

[0]:
proc_dir_entry 'atm/atmtcp:0' already registered
WARNING: CPU: 0 PID: 5919 at fs/proc/generic.c:377 proc_register+0x455/0x5f0 fs/proc/generic.c:377
Modules linked in:
CPU: 0 UID: 0 PID: 5919 Comm: syz-executor284 Not tainted 6.16.0-rc2-syzkaller-00047-g52da431bf03b #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
RIP: 0010:proc_register+0x455/0x5f0 fs/proc/generic.c:377
Code: 48 89 f9 48 c1 e9 03 80 3c 01 00 0f 85 a2 01 00 00 48 8b 44 24 10 48 c7 c7 20 c0 c2 8b 48 8b b0 d8 00 00 00 e8 0c 02 1c ff 90 &lt;0f&gt; 0b 90 90 48 c7 c7 80 f2 82 8e e8 0b de 23 09 48 8b 4c 24 28 48
RSP: 0018:ffffc9000466fa30 EFLAGS: 00010282
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817ae248
RDX: ffff888026280000 RSI: ffffffff817ae255 RDI: 0000000000000001
RBP: ffff8880232bed48 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: ffff888076ed2140
R13: dffffc0000000000 R14: ffff888078a61340 R15: ffffed100edda444
FS:  00007f38b3b0c6c0(0000) GS:ffff888124753000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f38b3bdf953 CR3: 0000000076d58000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
 proc_create_data+0xbe/0x110 fs/proc/generic.c:585
 atm_proc_dev_register+0x112/0x1e0 net/atm/proc.c:361
 atm_dev_register+0x46d/0x890 net/atm/resources.c:113
 atmtcp_create+0x77/0x210 drivers/atm/atmtcp.c:369
 atmtcp_attach drivers/atm/atmtcp.c:403 [inline]
 atmtcp_ioctl+0x2f9/0xd60 drivers/atm/atmtcp.c:464
 do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159
 sock_do_ioctl+0x115/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+0x18b/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
RIP: 0033:0x7f38b3b74459
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 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 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f38b3b0c198 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007f38b3bfe318 RCX: 00007f38b3b74459
RDX: 0000000000000000 RSI: 0000000000006180 RDI: 0000000000000005
RBP: 00007f38b3bfe310 R08: 65732f636f72702f R09: 65732f636f72702f
R10: 65732f636f72702f R11: 0000000000000246 R12: 00007f38b3bcb0ac
R13: 00007f38b3b0c1a0 R14: 0000200000000200 R15: 00007f38b3bcb03b
 &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2025-38245</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

atm: clip: prevent NULL deref in clip_push()

Blamed commit missed that vcc_destroy_socket() calls
clip_push() with a NULL skb.

If clip_devs is NULL, clip_push() then crashes when reading
skb-&gt;truesize.</Note>
    </Notes>
    <CVE>CVE-2025-38251</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

lib/group_cpus: fix NULL pointer dereference from group_cpus_evenly()

While testing null_blk with configfs, echo 0 &gt; poll_queues will trigger
following panic:

BUG: kernel NULL pointer dereference, address: 0000000000000010
Oops: Oops: 0000 [#1] SMP NOPTI
CPU: 27 UID: 0 PID: 920 Comm: bash Not tainted 6.15.0-02023-gadbdb95c8696-dirty #1238 PREEMPT(undef)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014
RIP: 0010:__bitmap_or+0x48/0x70
Call Trace:
 &lt;TASK&gt;
 __group_cpus_evenly+0x822/0x8c0
 group_cpus_evenly+0x2d9/0x490
 blk_mq_map_queues+0x1e/0x110
 null_map_queues+0xc9/0x170 [null_blk]
 blk_mq_update_queue_map+0xdb/0x160
 blk_mq_update_nr_hw_queues+0x22b/0x560
 nullb_update_nr_hw_queues+0x71/0xf0 [null_blk]
 nullb_device_poll_queues_store+0xa4/0x130 [null_blk]
 configfs_write_iter+0x109/0x1d0
 vfs_write+0x26e/0x6f0
 ksys_write+0x79/0x180
 __x64_sys_write+0x1d/0x30
 x64_sys_call+0x45c4/0x45f0
 do_syscall_64+0xa5/0x240
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Root cause is that numgrps is set to 0, and ZERO_SIZE_PTR is returned from
kcalloc(), and later ZERO_SIZE_PTR will be deferenced.

Fix the problem by checking numgrps first in group_cpus_evenly(), and
return NULL directly if numgrps is zero.

[yukuai3@huawei.com: also fix the non-SMP version]</Note>
    </Notes>
    <CVE>CVE-2025-38255</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

bcache: fix NULL pointer in cache_set_flush()

1. LINE#1794 - LINE#1887 is some codes about function of
   bch_cache_set_alloc().
2. LINE#2078 - LINE#2142 is some codes about function of
   register_cache_set().
3. register_cache_set() will call bch_cache_set_alloc() in LINE#2098.

 1794 struct cache_set *bch_cache_set_alloc(struct cache_sb *sb)
 1795 {
 ...
 1860         if (!(c-&gt;devices = kcalloc(c-&gt;nr_uuids, sizeof(void *), GFP_KERNEL)) ||
 1861             mempool_init_slab_pool(&amp;c-&gt;search, 32, bch_search_cache) ||
 1862             mempool_init_kmalloc_pool(&amp;c-&gt;bio_meta, 2,
 1863                                 sizeof(struct bbio) + sizeof(struct bio_vec) *
 1864                                 bucket_pages(c)) ||
 1865             mempool_init_kmalloc_pool(&amp;c-&gt;fill_iter, 1, iter_size) ||
 1866             bioset_init(&amp;c-&gt;bio_split, 4, offsetof(struct bbio, bio),
 1867                         BIOSET_NEED_BVECS|BIOSET_NEED_RESCUER) ||
 1868             !(c-&gt;uuids = alloc_bucket_pages(GFP_KERNEL, c)) ||
 1869             !(c-&gt;moving_gc_wq = alloc_workqueue("bcache_gc",
 1870                                                 WQ_MEM_RECLAIM, 0)) ||
 1871             bch_journal_alloc(c) ||
 1872             bch_btree_cache_alloc(c) ||
 1873             bch_open_buckets_alloc(c) ||
 1874             bch_bset_sort_state_init(&amp;c-&gt;sort, ilog2(c-&gt;btree_pages)))
 1875                 goto err;
                      ^^^^^^^^
 1876
 ...
 1883         return c;
 1884 err:
 1885         bch_cache_set_unregister(c);
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 1886         return NULL;
 1887 }
 ...
 2078 static const char *register_cache_set(struct cache *ca)
 2079 {
 ...
 2098         c = bch_cache_set_alloc(&amp;ca-&gt;sb);
 2099         if (!c)
 2100                 return err;
                      ^^^^^^^^^^
 ...
 2128         ca-&gt;set = c;
 2129         ca-&gt;set-&gt;cache[ca-&gt;sb.nr_this_dev] = ca;
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 ...
 2138         return NULL;
 2139 err:
 2140         bch_cache_set_unregister(c);
 2141         return err;
 2142 }

(1) If LINE#1860 - LINE#1874 is true, then do 'goto err'(LINE#1875) and
    call bch_cache_set_unregister()(LINE#1885).
(2) As (1) return NULL(LINE#1886), LINE#2098 - LINE#2100 would return.
(3) As (2) has returned, LINE#2128 - LINE#2129 would do *not* give the
    value to c-&gt;cache[], it means that c-&gt;cache[] is NULL.

LINE#1624 - LINE#1665 is some codes about function of cache_set_flush().
As (1), in LINE#1885 call
bch_cache_set_unregister()
---&gt; bch_cache_set_stop()
     ---&gt; closure_queue()
          -.-&gt; cache_set_flush() (as below LINE#1624)

 1624 static void cache_set_flush(struct closure *cl)
 1625 {
 ...
 1654         for_each_cache(ca, c, i)
 1655                 if (ca-&gt;alloc_thread)
                          ^^
 1656                         kthread_stop(ca-&gt;alloc_thread);
 ...
 1665 }

(4) In LINE#1655 ca is NULL(see (3)) in cache_set_flush() then the
    kernel crash occurred as below:
[  846.712887] bcache: register_cache() error drbd6: cannot allocate memory
[  846.713242] bcache: register_bcache() error : failed to register device
[  846.713336] bcache: cache_set_free() Cache set 2f84bdc1-498a-4f2f-98a7-01946bf54287 unregistered
[  846.713768] BUG: unable to handle kernel NULL pointer dereference at 00000000000009f8
[  846.714790] PGD 0 P4D 0
[  846.715129] Oops: 0000 [#1] SMP PTI
[  846.715472] CPU: 19 PID: 5057 Comm: kworker/19:16 Kdump: loaded Tainted: G           OE    --------- -  - 4.18.0-147.5.1.el8_1.5es.3.x86_64 #1
[  846.716082] Hardware name: ESPAN GI-25212/X11DPL-i, BIOS 2.1 06/15/2018
[  846.716451] Workqueue: events cache_set_flush [bcache]
[  846.716808] RIP: 0010:cache_set_flush+0xc9/0x1b0 [bcache]
[  846.717155] Code: 00 4c 89 a5 b0 03 00 00 48 8b 85 68 f6 ff ff a8 08 0f 84 88 00 00 00 31 db 66 83 bd 3c f7 ff ff 00 48 8b 85 48 ff ff ff 74 28 &lt;48&gt; 8b b8 f8 09 00 0
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-38263</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

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:

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

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:

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:

KVM: x86/hyper-v: Skip non-canonical addresses during PV TLB flush

In KVM guests with Hyper-V hypercalls enabled, the hypercalls
HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST and HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX
allow a guest to request invalidation of portions of a virtual TLB.
For this, the hypercall parameter includes a list of GVAs that are supposed
to be invalidated.

However, when non-canonical GVAs are passed, there is currently no
filtering in place and they are eventually passed to checked invocations of
INVVPID on Intel / INVLPGA on AMD.  While AMD's INVLPGA silently ignores
non-canonical addresses (effectively a no-op), Intel's INVVPID explicitly
signals VM-Fail and ultimately triggers the WARN_ONCE in invvpid_error():

  invvpid failed: ext=0x0 vpid=1 gva=0xaaaaaaaaaaaaa000
  WARNING: CPU: 6 PID: 326 at arch/x86/kvm/vmx/vmx.c:482
  invvpid_error+0x91/0xa0 [kvm_intel]
  Modules linked in: kvm_intel kvm 9pnet_virtio irqbypass fuse
  CPU: 6 UID: 0 PID: 326 Comm: kvm-vm Not tainted 6.15.0 #14 PREEMPT(voluntary)
  RIP: 0010:invvpid_error+0x91/0xa0 [kvm_intel]
  Call Trace:
    vmx_flush_tlb_gva+0x320/0x490 [kvm_intel]
    kvm_hv_vcpu_flush_tlb+0x24f/0x4f0 [kvm]
    kvm_arch_vcpu_ioctl_run+0x3013/0x5810 [kvm]

Hyper-V documents that invalid GVAs (those that are beyond a partition's
GVA space) are to be ignored.  While not completely clear whether this
ruling also applies to non-canonical GVAs, it is likely fine to make that
assumption, and manual testing on Azure confirms "real" Hyper-V interprets
the specification in the same way.

Skip non-canonical GVAs when processing the list of address to avoid
tripping the INVVPID failure.  Alternatively, KVM could filter out "bad"
GVAs before inserting into the FIFO, but practically speaking the only
downside of pushing validation to the final processing is that doing so
is suboptimal for the guest, and no well-behaved guest will request TLB
flushes for non-canonical addresses.</Note>
    </Notes>
    <CVE>CVE-2025-38351</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/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/amd/display: Add more checks for DSC / HUBP ONO guarantees

[WHY]
For non-zero DSC instances it's possible that the HUBP domain required
to drive it for sequential ONO ASICs isn't met, potentially causing
the logic to the tile to enter an undefined state leading to a system
hang.

[HOW]
Add more checks to ensure that the HUBP domain matching the DSC instance
is appropriately powered.

(cherry picked from commit da63df07112e5a9857a8d2aaa04255c4206754ec)</Note>
    </Notes>
    <CVE>CVE-2025-38360</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

idpf: return 0 size for RSS key if not supported

Returning -EOPNOTSUPP from function returning u32 is leading to
cast and invalid size value as a result.

-EOPNOTSUPP as a size probably will lead to allocation fail.

Command: ethtool -x eth0
It is visible on all devices that don't have RSS caps set.

[  136.615917] Call Trace:
[  136.615921]  &lt;TASK&gt;
[  136.615927]  ? __warn+0x89/0x130
[  136.615942]  ? __alloc_frozen_pages_noprof+0x322/0x330
[  136.615953]  ? report_bug+0x164/0x190
[  136.615968]  ? handle_bug+0x58/0x90
[  136.615979]  ? exc_invalid_op+0x17/0x70
[  136.615987]  ? asm_exc_invalid_op+0x1a/0x20
[  136.616001]  ? rss_prepare_get.constprop.0+0xb9/0x170
[  136.616016]  ? __alloc_frozen_pages_noprof+0x322/0x330
[  136.616028]  __alloc_pages_noprof+0xe/0x20
[  136.616038]  ___kmalloc_large_node+0x80/0x110
[  136.616072]  __kmalloc_large_node_noprof+0x1d/0xa0
[  136.616081]  __kmalloc_noprof+0x32c/0x4c0
[  136.616098]  ? rss_prepare_get.constprop.0+0xb9/0x170
[  136.616105]  rss_prepare_get.constprop.0+0xb9/0x170
[  136.616114]  ethnl_default_doit+0x107/0x3d0
[  136.616131]  genl_family_rcv_msg_doit+0x100/0x160
[  136.616147]  genl_rcv_msg+0x1b8/0x2c0
[  136.616156]  ? __pfx_ethnl_default_doit+0x10/0x10
[  136.616168]  ? __pfx_genl_rcv_msg+0x10/0x10
[  136.616176]  netlink_rcv_skb+0x58/0x110
[  136.616186]  genl_rcv+0x28/0x40
[  136.616195]  netlink_unicast+0x19b/0x290
[  136.616206]  netlink_sendmsg+0x222/0x490
[  136.616215]  __sys_sendto+0x1fd/0x210
[  136.616233]  __x64_sys_sendto+0x24/0x30
[  136.616242]  do_syscall_64+0x82/0x160
[  136.616252]  ? __sys_recvmsg+0x83/0xe0
[  136.616265]  ? syscall_exit_to_user_mode+0x10/0x210
[  136.616275]  ? do_syscall_64+0x8e/0x160
[  136.616282]  ? __count_memcg_events+0xa1/0x130
[  136.616295]  ? count_memcg_events.constprop.0+0x1a/0x30
[  136.616306]  ? handle_mm_fault+0xae/0x2d0
[  136.616319]  ? do_user_addr_fault+0x379/0x670
[  136.616328]  ? clear_bhb_loop+0x45/0xa0
[  136.616340]  ? clear_bhb_loop+0x45/0xa0
[  136.616349]  ? clear_bhb_loop+0x45/0xa0
[  136.616359]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[  136.616369] RIP: 0033:0x7fd30ba7b047
[  136.616376] Code: 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d bd d5 0c 00 00 41 89 ca 74 10 b8 2c 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 71 c3 55 48 83 ec 30 44 89 4c 24 2c 4c 89 44
[  136.616381] RSP: 002b:00007ffde1796d68 EFLAGS: 00000202 ORIG_RAX: 000000000000002c
[  136.616388] RAX: ffffffffffffffda RBX: 000055d7bd89f2a0 RCX: 00007fd30ba7b047
[  136.616392] RDX: 0000000000000028 RSI: 000055d7bd89f3b0 RDI: 0000000000000003
[  136.616396] RBP: 00007ffde1796e10 R08: 00007fd30bb4e200 R09: 000000000000000c
[  136.616399] R10: 0000000000000000 R11: 0000000000000202 R12: 000055d7bd89f340
[  136.616403] R13: 000055d7bd89f3b0 R14: 000055d78943f200 R15: 0000000000000000</Note>
    </Notes>
    <CVE>CVE-2025-38402</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

genirq/irq_sim: Initialize work context pointers properly

Initialize `ops` member's pointers properly by using kzalloc() instead of
kmalloc() when allocating the simulation work context. Otherwise the
pointers contain random content leading to invalid dereferencing.</Note>
    </Notes>
    <CVE>CVE-2025-38408</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

remoteproc: core: Release rproc-&gt;clean_table after rproc_attach() fails

When rproc-&gt;state = RPROC_DETACHED is attached to remote processor
through rproc_attach(), if rproc_handle_resources() returns failure,
then the clean table should be released, otherwise the following
memory leak will occur.

unreferenced object 0xffff000086a99800 (size 1024):
comm "kworker/u12:3", pid 59, jiffies 4294893670 (age 121.140s)
hex dump (first 32 bytes):
00 00 00 00 00 80 00 00 00 00 00 00 00 00 10 00 ............
00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00 ............
backtrace:
 [&lt;000000008bbe4ca8&gt;] slab_post_alloc_hook+0x98/0x3fc
 [&lt;000000003b8a272b&gt;] __kmem_cache_alloc_node+0x13c/0x230
 [&lt;000000007a507c51&gt;] __kmalloc_node_track_caller+0x5c/0x260
 [&lt;0000000037818dae&gt;] kmemdup+0x34/0x60
 [&lt;00000000610f7f57&gt;] rproc_boot+0x35c/0x56c
 [&lt;0000000065f8871a&gt;] rproc_add+0x124/0x17c
 [&lt;00000000497416ee&gt;] imx_rproc_probe+0x4ec/0x5d4
 [&lt;000000003bcaa37d&gt;] platform_probe+0x68/0xd8
 [&lt;00000000771577f9&gt;] really_probe+0x110/0x27c
 [&lt;00000000531fea59&gt;] __driver_probe_device+0x78/0x12c
 [&lt;0000000080036a04&gt;] driver_probe_device+0x3c/0x118
 [&lt;000000007e0bddcb&gt;] __device_attach_driver+0xb8/0xf8
 [&lt;000000000cf1fa33&gt;] bus_for_each_drv+0x84/0xe4
 [&lt;000000001a53b53e&gt;] __device_attach+0xfc/0x18c
 [&lt;00000000d1a2a32c&gt;] device_initial_probe+0x14/0x20
 [&lt;00000000d8f8b7ae&gt;] bus_probe_device+0xb0/0xb4
 unreferenced object 0xffff0000864c9690 (size 16):</Note>
    </Notes>
    <CVE>CVE-2025-38418</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

remoteproc: core: Cleanup acquired resources when rproc_handle_resources() fails in rproc_attach()

When rproc-&gt;state = RPROC_DETACHED and rproc_attach() is used
to attach to the remote processor, if rproc_handle_resources()
returns a failure, the resources allocated by imx_rproc_prepare()
should be released, otherwise the following memory leak will occur.

Since almost the same thing is done in imx_rproc_prepare() and
rproc_resource_cleanup(), Function rproc_resource_cleanup() is able
to deal with empty lists so it is better to fix the "goto" statements
in rproc_attach(). replace the "unprepare_device" goto statement with
"clean_up_resources" and get rid of the "unprepare_device" label.

unreferenced object 0xffff0000861c5d00 (size 128):
comm "kworker/u12:3", pid 59, jiffies 4294893509 (age 149.220s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 02 88 00 00 00 00 00 00 10 00 00 00 00 00 ............
backtrace:
 [&lt;00000000f949fe18&gt;] slab_post_alloc_hook+0x98/0x37c
 [&lt;00000000adbfb3e7&gt;] __kmem_cache_alloc_node+0x138/0x2e0
 [&lt;00000000521c0345&gt;] kmalloc_trace+0x40/0x158
 [&lt;000000004e330a49&gt;] rproc_mem_entry_init+0x60/0xf8
 [&lt;000000002815755e&gt;] imx_rproc_prepare+0xe0/0x180
 [&lt;0000000003f61b4e&gt;] rproc_boot+0x2ec/0x528
 [&lt;00000000e7e994ac&gt;] rproc_add+0x124/0x17c
 [&lt;0000000048594076&gt;] imx_rproc_probe+0x4ec/0x5d4
 [&lt;00000000efc298a1&gt;] platform_probe+0x68/0xd8
 [&lt;00000000110be6fe&gt;] really_probe+0x110/0x27c
 [&lt;00000000e245c0ae&gt;] __driver_probe_device+0x78/0x12c
 [&lt;00000000f61f6f5e&gt;] driver_probe_device+0x3c/0x118
 [&lt;00000000a7874938&gt;] __device_attach_driver+0xb8/0xf8
 [&lt;0000000065319e69&gt;] bus_for_each_drv+0x84/0xe4
 [&lt;00000000db3eb243&gt;] __device_attach+0xfc/0x18c
 [&lt;0000000072e4e1a4&gt;] device_initial_probe+0x14/0x20</Note>
    </Notes>
    <CVE>CVE-2025-38419</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

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:

bnxt_en: Set DMA unmap len correctly for XDP_REDIRECT

When transmitting an XDP_REDIRECT packet, call dma_unmap_len_set()
with the proper length instead of 0.  This bug triggers this warning
on a system with IOMMU enabled:

WARNING: CPU: 36 PID: 0 at drivers/iommu/dma-iommu.c:842 __iommu_dma_unmap+0x159/0x170
RIP: 0010:__iommu_dma_unmap+0x159/0x170
Code: a8 00 00 00 00 48 c7 45 b0 00 00 00 00 48 c7 45 c8 00 00 00 00 48 c7 45 a0 ff ff ff ff 4c 89 45
b8 4c 89 45 c0 e9 77 ff ff ff &lt;0f&gt; 0b e9 60 ff ff ff e8 8b bf 6a 00 66 66 2e 0f 1f 84 00 00 00 00
RSP: 0018:ff22d31181150c88 EFLAGS: 00010206
RAX: 0000000000002000 RBX: 00000000e13a0000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ff22d31181150cf0 R08: ff22d31181150ca8 R09: 0000000000000000
R10: 0000000000000000 R11: ff22d311d36c9d80 R12: 0000000000001000
R13: ff13544d10645010 R14: ff22d31181150c90 R15: ff13544d0b2bac00
FS: 0000000000000000(0000) GS:ff13550908a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005be909dacff8 CR3: 0008000173408003 CR4: 0000000000f71ef0
PKRU: 55555554
Call Trace:
&lt;IRQ&gt;
? show_regs+0x6d/0x80
? __warn+0x89/0x160
? __iommu_dma_unmap+0x159/0x170
? report_bug+0x17e/0x1b0
? handle_bug+0x46/0x90
? exc_invalid_op+0x18/0x80
? asm_exc_invalid_op+0x1b/0x20
? __iommu_dma_unmap+0x159/0x170
? __iommu_dma_unmap+0xb3/0x170
iommu_dma_unmap_page+0x4f/0x100
dma_unmap_page_attrs+0x52/0x220
? srso_alias_return_thunk+0x5/0xfbef5
? xdp_return_frame+0x2e/0xd0
bnxt_tx_int_xdp+0xdf/0x440 [bnxt_en]
__bnxt_poll_work_done+0x81/0x1e0 [bnxt_en]
bnxt_poll+0xd3/0x1e0 [bnxt_en]</Note>
    </Notes>
    <CVE>CVE-2025-38439</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:

netfilter: flowtable: account for Ethernet header in nf_flow_pppoe_proto()

syzbot found a potential access to uninit-value in nf_flow_pppoe_proto()

Blamed commit forgot the Ethernet header.

BUG: KMSAN: uninit-value in nf_flow_offload_inet_hook+0x7e4/0x940 net/netfilter/nf_flow_table_inet.c:27
  nf_flow_offload_inet_hook+0x7e4/0x940 net/netfilter/nf_flow_table_inet.c:27
  nf_hook_entry_hookfn include/linux/netfilter.h:157 [inline]
  nf_hook_slow+0xe1/0x3d0 net/netfilter/core.c:623
  nf_hook_ingress include/linux/netfilter_netdev.h:34 [inline]
  nf_ingress net/core/dev.c:5742 [inline]
  __netif_receive_skb_core+0x4aff/0x70c0 net/core/dev.c:5837
  __netif_receive_skb_one_core net/core/dev.c:5975 [inline]
  __netif_receive_skb+0xcc/0xac0 net/core/dev.c:6090
  netif_receive_skb_internal net/core/dev.c:6176 [inline]
  netif_receive_skb+0x57/0x630 net/core/dev.c:6235
  tun_rx_batched+0x1df/0x980 drivers/net/tun.c:1485
  tun_get_user+0x4ee0/0x6b40 drivers/net/tun.c:1938
  tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1984
  new_sync_write fs/read_write.c:593 [inline]
  vfs_write+0xb4b/0x1580 fs/read_write.c:686
  ksys_write fs/read_write.c:738 [inline]
  __do_sys_write fs/read_write.c:749 [inline]</Note>
    </Notes>
    <CVE>CVE-2025-38441</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

raid10: cleanup memleak at raid10_make_request

If raid10_read_request or raid10_write_request registers a new
request and the REQ_NOWAIT flag is set, the code does not
free the malloc from the mempool.

unreferenced object 0xffff8884802c3200 (size 192):
   comm "fio", pid 9197, jiffies 4298078271
   hex dump (first 32 bytes):
     00 00 00 00 00 00 00 00 88 41 02 00 00 00 00 00  .........A......
     08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
   backtrace (crc c1a049a2):
     __kmalloc+0x2bb/0x450
     mempool_alloc+0x11b/0x320
     raid10_make_request+0x19e/0x650 [raid10]
     md_handle_request+0x3b3/0x9e0
     __submit_bio+0x394/0x560
     __submit_bio_noacct+0x145/0x530
     submit_bio_noacct_nocheck+0x682/0x830
     __blkdev_direct_IO_async+0x4dc/0x6b0
     blkdev_read_iter+0x1e5/0x3b0
     __io_read+0x230/0x1110
     io_read+0x13/0x30
     io_issue_sqe+0x134/0x1180
     io_submit_sqes+0x48c/0xe90
     __do_sys_io_uring_enter+0x574/0x8b0
     do_syscall_64+0x5c/0xe0
     entry_SYSCALL_64_after_hwframe+0x76/0x7e

V4: changing backing tree to see if CKI tests will pass.
The patch code has not changed between any versions.</Note>
    </Notes>
    <CVE>CVE-2025-38444</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/raid1: Fix stack memory use after return in raid1_reshape

In the raid1_reshape function, newpool is
allocated on the stack and assigned to conf-&gt;r1bio_pool.
This results in conf-&gt;r1bio_pool.wait.head pointing
to a stack address.
Accessing this address later can lead to a kernel panic.

Example access path:

raid1_reshape()
{
	// newpool is on the stack
	mempool_t newpool, oldpool;
	// initialize newpool.wait.head to stack address
	mempool_init(&amp;newpool, ...);
	conf-&gt;r1bio_pool = newpool;
}

raid1_read_request() or raid1_write_request()
{
	alloc_r1bio()
	{
		mempool_alloc()
		{
			// if pool-&gt;alloc fails
			remove_element()
			{
				--pool-&gt;curr_nr;
			}
		}
	}
}

mempool_free()
{
	if (pool-&gt;curr_nr &lt; pool-&gt;min_nr) {
		// pool-&gt;wait.head is a stack address
		// wake_up() will try to access this invalid address
		// which leads to a kernel panic
		return;
		wake_up(&amp;pool-&gt;wait);
	}
}

Fix:
reinit conf-&gt;r1bio_pool.wait after assigning newpool.</Note>
    </Notes>
    <CVE>CVE-2025-38445</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

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:

ipmi:msghandler: Fix potential memory corruption in ipmi_create_user()

The "intf" list iterator is an invalid pointer if the correct
"intf-&gt;intf_num" is not found.  Calling atomic_dec(&amp;intf-&gt;nr_users) on
and invalid pointer will lead to memory corruption.

We don't really need to call atomic_dec() if we haven't called
atomic_add_return() so update the if (intf-&gt;in_shutdown) path as well.</Note>
    </Notes>
    <CVE>CVE-2025-38456</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 NULL pointer dereference in vcc_sendmsg()

atmarpd_dev_ops does not implement the send method, which may cause crash
as bellow.

BUG: kernel NULL pointer dereference, address: 0000000000000000
PGD 0 P4D 0
Oops: Oops: 0010 [#1] SMP KASAN NOPTI
CPU: 0 UID: 0 PID: 5324 Comm: syz.0.0 Not tainted 6.15.0-rc6-syzkaller-00346-g5723cc3450bc #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
RIP: 0010:0x0
Code: Unable to access opcode bytes at 0xffffffffffffffd6.
RSP: 0018:ffffc9000d3cf778 EFLAGS: 00010246
RAX: 1ffffffff1910dd1 RBX: 00000000000000c0 RCX: dffffc0000000000
RDX: ffffc9000dc82000 RSI: ffff88803e4c4640 RDI: ffff888052cd0000
RBP: ffffc9000d3cf8d0 R08: ffff888052c9143f R09: 1ffff1100a592287
R10: dffffc0000000000 R11: 0000000000000000 R12: 1ffff92001a79f00
R13: ffff888052cd0000 R14: ffff88803e4c4640 R15: ffffffff8c886e88
FS:  00007fbc762566c0(0000) GS:ffff88808d6c2000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffffffffd6 CR3: 0000000041f1b000 CR4: 0000000000352ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
 vcc_sendmsg+0xa10/0xc50 net/atm/common.c:644
 sock_sendmsg_nosec net/socket.c:712 [inline]
 __sock_sendmsg+0x219/0x270 net/socket.c:727
 ____sys_sendmsg+0x52d/0x830 net/socket.c:2566
 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2620
 __sys_sendmmsg+0x227/0x430 net/socket.c:2709
 __do_sys_sendmmsg net/socket.c:2736 [inline]
 __se_sys_sendmmsg net/socket.c:2733 [inline]
 __x64_sys_sendmmsg+0xa0/0xc0 net/socket.c:2733
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xf6/0x210 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f</Note>
    </Notes>
    <CVE>CVE-2025-38458</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 infinite recursive call of clip_push().

syzbot reported the splat below. [0]

This happens if we call ioctl(ATMARP_MKIP) more than once.

During the first call, clip_mkip() sets clip_push() to vcc-&gt;push(),
and the second call copies it to clip_vcc-&gt;old_push().

Later, when the socket is close()d, vcc_destroy_socket() passes
NULL skb to clip_push(), which calls clip_vcc-&gt;old_push(),
triggering the infinite recursion.

Let's prevent the second ioctl(ATMARP_MKIP) by checking
vcc-&gt;user_back, which is allocated by the first call as clip_vcc.

Note also that we use lock_sock() to prevent racy calls.

[0]:
BUG: TASK stack guard page was hit at ffffc9000d66fff8 (stack is ffffc9000d670000..ffffc9000d678000)
Oops: stack guard page: 0000 [#1] SMP KASAN NOPTI
CPU: 0 UID: 0 PID: 5322 Comm: syz.0.0 Not tainted 6.16.0-rc4-syzkaller #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
RIP: 0010:clip_push+0x5/0x720 net/atm/clip.c:191
Code: e0 8f aa 8c e8 1c ad 5b fa eb ae 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 55 &lt;41&gt; 57 41 56 41 55 41 54 53 48 83 ec 20 48 89 f3 49 89 fd 48 bd 00
RSP: 0018:ffffc9000d670000 EFLAGS: 00010246
RAX: 1ffff1100235a4a5 RBX: ffff888011ad2508 RCX: ffff8880003c0000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888037f01000
RBP: dffffc0000000000 R08: ffffffff8fa104f7 R09: 1ffffffff1f4209e
R10: dffffc0000000000 R11: ffffffff8a99b300 R12: ffffffff8a99b300
R13: ffff888037f01000 R14: ffff888011ad2500 R15: ffff888037f01578
FS:  000055557ab6d500(0000) GS:ffff88808d250000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffc9000d66fff8 CR3: 0000000043172000 CR4: 0000000000352ef0
Call Trace:
 &lt;TASK&gt;
 clip_push+0x6dc/0x720 net/atm/clip.c:200
 clip_push+0x6dc/0x720 net/atm/clip.c:200
 clip_push+0x6dc/0x720 net/atm/clip.c:200
...
 clip_push+0x6dc/0x720 net/atm/clip.c:200
 clip_push+0x6dc/0x720 net/atm/clip.c:200
 clip_push+0x6dc/0x720 net/atm/clip.c:200
 vcc_destroy_socket net/atm/common.c:183 [inline]
 vcc_release+0x157/0x460 net/atm/common.c:205
 __sock_release net/socket.c:647 [inline]
 sock_close+0xc0/0x240 net/socket.c:1391
 __fput+0x449/0xa70 fs/file_table.c:465
 task_work_run+0x1d1/0x260 kernel/task_work.c:227
 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
 exit_to_user_mode_loop+0xec/0x110 kernel/entry/common.c:114
 exit_to_user_mode_prepare include/linux/entry-common.h:330 [inline]
 syscall_exit_to_user_mode_work include/linux/entry-common.h:414 [inline]
 syscall_exit_to_user_mode include/linux/entry-common.h:449 [inline]
 do_syscall_64+0x2bd/0x3b0 arch/x86/entry/syscall_64.c:100
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7ff31c98e929
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:00007fffb5aa1f78 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4
RAX: 0000000000000000 RBX: 0000000000012747 RCX: 00007ff31c98e929
RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003
RBP: 00007ff31cbb7ba0 R08: 0000000000000001 R09: 0000000db5aa226f
R10: 00007ff31c7ff030 R11: 0000000000000246 R12: 00007ff31cbb608c
R13: 00007ff31cbb6080 R14: ffffffffffffffff R15: 00007fffb5aa2090
 &lt;/TASK&gt;
Modules linked in:</Note>
    </Notes>
    <CVE>CVE-2025-38459</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

tipc: Fix use-after-free in tipc_conn_close().

syzbot reported a null-ptr-deref in tipc_conn_close() during netns
dismantle. [0]

tipc_topsrv_stop() iterates tipc_net(net)-&gt;topsrv-&gt;conn_idr and calls
tipc_conn_close() for each tipc_conn.

The problem is that tipc_conn_close() is called after releasing the
IDR lock.

At the same time, there might be tipc_conn_recv_work() running and it
could call tipc_conn_close() for the same tipc_conn and release its
last -&gt;kref.

Once we release the IDR lock in tipc_topsrv_stop(), there is no
guarantee that the tipc_conn is alive.

Let's hold the ref before releasing the lock and put the ref after
tipc_conn_close() in tipc_topsrv_stop().

[0]:
BUG: KASAN: use-after-free in tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165
Read of size 8 at addr ffff888099305a08 by task kworker/u4:3/435

CPU: 0 PID: 435 Comm: kworker/u4:3 Not tainted 4.19.204-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: netns cleanup_net
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1fc/0x2ef lib/dump_stack.c:118
 print_address_description.cold+0x54/0x219 mm/kasan/report.c:256
 kasan_report_error.cold+0x8a/0x1b9 mm/kasan/report.c:354
 kasan_report mm/kasan/report.c:412 [inline]
 __asan_report_load8_noabort+0x88/0x90 mm/kasan/report.c:433
 tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165
 tipc_topsrv_stop net/tipc/topsrv.c:701 [inline]
 tipc_topsrv_exit_net+0x27b/0x5c0 net/tipc/topsrv.c:722
 ops_exit_list+0xa5/0x150 net/core/net_namespace.c:153
 cleanup_net+0x3b4/0x8b0 net/core/net_namespace.c:553
 process_one_work+0x864/0x1570 kernel/workqueue.c:2153
 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296
 kthread+0x33f/0x460 kernel/kthread.c:259
 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415

Allocated by task 23:
 kmem_cache_alloc_trace+0x12f/0x380 mm/slab.c:3625
 kmalloc include/linux/slab.h:515 [inline]
 kzalloc include/linux/slab.h:709 [inline]
 tipc_conn_alloc+0x43/0x4f0 net/tipc/topsrv.c:192
 tipc_topsrv_accept+0x1b5/0x280 net/tipc/topsrv.c:470
 process_one_work+0x864/0x1570 kernel/workqueue.c:2153
 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296
 kthread+0x33f/0x460 kernel/kthread.c:259
 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415

Freed by task 23:
 __cache_free mm/slab.c:3503 [inline]
 kfree+0xcc/0x210 mm/slab.c:3822
 tipc_conn_kref_release net/tipc/topsrv.c:150 [inline]
 kref_put include/linux/kref.h:70 [inline]
 conn_put+0x2cd/0x3a0 net/tipc/topsrv.c:155
 process_one_work+0x864/0x1570 kernel/workqueue.c:2153
 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296
 kthread+0x33f/0x460 kernel/kthread.c:259
 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415

The buggy address belongs to the object at ffff888099305a00
 which belongs to the cache kmalloc-512 of size 512
The buggy address is located 8 bytes inside of
 512-byte region [ffff888099305a00, ffff888099305c00)
The buggy address belongs to the page:
page:ffffea000264c140 count:1 mapcount:0 mapping:ffff88813bff0940 index:0x0
flags: 0xfff00000000100(slab)
raw: 00fff00000000100 ffffea00028b6b88 ffffea0002cd2b08 ffff88813bff0940
raw: 0000000000000000 ffff888099305000 0000000100000006 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff888099305900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff888099305980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
&gt;ffff888099305a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                      ^
 ffff888099305a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff888099305b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb</Note>
    </Notes>
    <CVE>CVE-2025-38464</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

perf: Revert to requiring CAP_SYS_ADMIN for uprobes

Jann reports that uprobes can be used destructively when used in the
middle of an instruction. The kernel only verifies there is a valid
instruction at the requested offset, but due to variable instruction
length cannot determine if this is an instruction as seen by the
intended execution stream.

Additionally, Mark Rutland notes that on architectures that mix data
in the text segment (like arm64), a similar things can be done if the
data word is 'mistaken' for an instruction.

As such, require CAP_SYS_ADMIN for uprobes.</Note>
    </Notes>
    <CVE>CVE-2025-38466</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

netfilter: nf_conntrack: fix crash due to removal of uninitialised entry

A crash in conntrack was reported while trying to unlink the conntrack
entry from the hash bucket list:
    [exception RIP: __nf_ct_delete_from_lists+172]
    [..]
 #7 [ff539b5a2b043aa0] nf_ct_delete at ffffffffc124d421 [nf_conntrack]
 #8 [ff539b5a2b043ad0] nf_ct_gc_expired at ffffffffc124d999 [nf_conntrack]
 #9 [ff539b5a2b043ae0] __nf_conntrack_find_get at ffffffffc124efbc [nf_conntrack]
    [..]

The nf_conn struct is marked as allocated from slab but appears to be in
a partially initialised state:

 ct hlist pointer is garbage; looks like the ct hash value
 (hence crash).
 ct-&gt;status is equal to IPS_CONFIRMED|IPS_DYING, which is expected
 ct-&gt;timeout is 30000 (=30s), which is unexpected.

Everything else looks like normal udp conntrack entry.  If we ignore
ct-&gt;status and pretend its 0, the entry matches those that are newly
allocated but not yet inserted into the hash:
  - ct hlist pointers are overloaded and store/cache the raw tuple hash
  - ct-&gt;timeout matches the relative time expected for a new udp flow
    rather than the absolute 'jiffies' value.

If it were not for the presence of IPS_CONFIRMED,
__nf_conntrack_find_get() would have skipped the entry.

Theory is that we did hit following race:

cpu x 			cpu y			cpu z
 found entry E		found entry E
 E is expired		&lt;preemption&gt;
 nf_ct_delete()
 return E to rcu slab
					init_conntrack
					E is re-inited,
					ct-&gt;status set to 0
					reply tuplehash hnnode.pprev
					stores hash value.

cpu y found E right before it was deleted on cpu x.
E is now re-inited on cpu z.  cpu y was preempted before
checking for expiry and/or confirm bit.

					-&gt;refcnt set to 1
					E now owned by skb
					-&gt;timeout set to 30000

If cpu y were to resume now, it would observe E as
expired but would skip E due to missing CONFIRMED bit.

					nf_conntrack_confirm gets called
					sets: ct-&gt;status |= CONFIRMED
					This is wrong: E is not yet added
					to hashtable.

cpu y resumes, it observes E as expired but CONFIRMED:
			&lt;resumes&gt;
			nf_ct_expired()
			 -&gt; yes (ct-&gt;timeout is 30s)
			confirmed bit set.

cpu y will try to delete E from the hashtable:
			nf_ct_delete() -&gt; set DYING bit
			__nf_ct_delete_from_lists

Even this scenario doesn't guarantee a crash:
cpu z still holds the table bucket lock(s) so y blocks:

			wait for spinlock held by z

					CONFIRMED is set but there is no
					guarantee ct will be added to hash:
					"chaintoolong" or "clash resolution"
					logic both skip the insert step.
					reply hnnode.pprev still stores the
					hash value.

					unlocks spinlock
					return NF_DROP
			&lt;unblocks, then
			 crashes on hlist_nulls_del_rcu pprev&gt;

In case CPU z does insert the entry into the hashtable, cpu y will unlink
E again right away but no crash occurs.

Without 'cpu y' race, 'garbage' hlist is of no consequence:
ct refcnt remains at 1, eventually skb will be free'd and E gets
destroyed via: nf_conntrack_put -&gt; nf_conntrack_destroy -&gt; nf_ct_destroy.

To resolve this, move the IPS_CONFIRMED assignment after the table
insertion but before the unlock.

Pablo points out that the confirm-bit-store could be reordered to happen
before hlist add resp. the timeout fixup, so switch to set_bit and
before_atomic memory barrier to prevent this.

It doesn't matter if other CPUs can observe a newly inserted entry right
before the CONFIRMED bit was set:

Such event cannot be distinguished from above "E is the old incarnation"
case: the entry will be skipped.

Also change nf_ct_should_gc() to first check the confirmed bit.

The gc sequence is:
 1. Check if entry has expired, if not skip to next entry
 2. Obtain a reference to the expired entry.
 3. Call nf_ct_should_gc() to double-check step 1.

nf_ct_should_gc() is thus called only for entries that already failed an
expiry check. After this patch, once the confirmed bit check pas
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-38472</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

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:

smb: client: fix use-after-free in crypt_message when using async crypto

The CVE-2024-50047 fix removed asynchronous crypto handling from
crypt_message(), assuming all crypto operations are synchronous.
However, when hardware crypto accelerators are used, this can cause
use-after-free crashes:

  crypt_message()
    // Allocate the creq buffer containing the req
    creq = smb2_get_aead_req(..., &amp;req);

    // Async encryption returns -EINPROGRESS immediately
    rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req);

    // Free creq while async operation is still in progress
    kvfree_sensitive(creq, ...);

Hardware crypto modules often implement async AEAD operations for
performance. When crypto_aead_encrypt/decrypt() returns -EINPROGRESS,
the operation completes asynchronously. Without crypto_wait_req(),
the function immediately frees the request buffer, leading to crashes
when the driver later accesses the freed memory.

This results in a use-after-free condition when the hardware crypto
driver later accesses the freed request structure, leading to kernel
crashes with NULL pointer dereferences.

The issue occurs because crypto_alloc_aead() with mask=0 doesn't
guarantee synchronous operation. Even without CRYPTO_ALG_ASYNC in
the mask, async implementations can be selected.

Fix by restoring the async crypto handling:
- DECLARE_CRYPTO_WAIT(wait) for completion tracking
- aead_request_set_callback() for async completion notification
- crypto_wait_req() to wait for operation completion

This ensures the request buffer isn't freed until the crypto operation
completes, whether synchronous or asynchronous, while preserving the
CVE-2024-50047 fix.</Note>
    </Notes>
    <CVE>CVE-2025-38488</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:

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:

net: libwx: remove duplicate page_pool_put_full_page()

page_pool_put_full_page() should only be invoked when freeing Rx buffers
or building a skb if the size is too short. At other times, the pages
need to be reused. So remove the redundant page put. In the original
code, double free pages cause kernel panic:

[  876.949834]  __irq_exit_rcu+0xc7/0x130
[  876.949836]  common_interrupt+0xb8/0xd0
[  876.949838]  &lt;/IRQ&gt;
[  876.949838]  &lt;TASK&gt;
[  876.949840]  asm_common_interrupt+0x22/0x40
[  876.949841] RIP: 0010:cpuidle_enter_state+0xc2/0x420
[  876.949843] Code: 00 00 e8 d1 1d 5e ff e8 ac f0 ff ff 49 89 c5 0f 1f 44 00 00 31 ff e8 cd fc 5c ff 45 84 ff 0f 85 40 02 00 00 fb 0f 1f 44 00 00 &lt;45&gt; 85 f6 0f 88 84 01 00 00 49 63 d6 48 8d 04 52 48 8d 04 82 49 8d
[  876.949844] RSP: 0018:ffffaa7340267e78 EFLAGS: 00000246
[  876.949845] RAX: ffff9e3f135be000 RBX: 0000000000000002 RCX: 0000000000000000
[  876.949846] RDX: 000000cc2dc4cb7c RSI: ffffffff89ee49ae RDI: ffffffff89ef9f9e
[  876.949847] RBP: ffff9e378f940800 R08: 0000000000000002 R09: 00000000000000ed
[  876.949848] R10: 000000000000afc8 R11: ffff9e3e9e5a9b6c R12: ffffffff8a6d8580
[  876.949849] R13: 000000cc2dc4cb7c R14: 0000000000000002 R15: 0000000000000000
[  876.949852]  ? cpuidle_enter_state+0xb3/0x420
[  876.949855]  cpuidle_enter+0x29/0x40
[  876.949857]  cpuidle_idle_call+0xfd/0x170
[  876.949859]  do_idle+0x7a/0xc0
[  876.949861]  cpu_startup_entry+0x25/0x30
[  876.949862]  start_secondary+0x117/0x140
[  876.949864]  common_startup_64+0x13e/0x148
[  876.949867]  &lt;/TASK&gt;
[  876.949868] ---[ end trace 0000000000000000 ]---
[  876.949869] ------------[ cut here ]------------
[  876.949870] list_del corruption, ffffead40445a348-&gt;next is NULL
[  876.949873] WARNING: CPU: 14 PID: 0 at lib/list_debug.c:52 __list_del_entry_valid_or_report+0x67/0x120
[  876.949875] Modules linked in: snd_hrtimer(E) bnep(E) binfmt_misc(E) amdgpu(E) squashfs(E) vfat(E) loop(E) fat(E) amd_atl(E) snd_hda_codec_realtek(E) intel_rapl_msr(E) snd_hda_codec_generic(E) intel_rapl_common(E) snd_hda_scodec_component(E) snd_hda_codec_hdmi(E) snd_hda_intel(E) edac_mce_amd(E) snd_intel_dspcfg(E) snd_hda_codec(E) snd_hda_core(E) amdxcp(E) kvm_amd(E) snd_hwdep(E) gpu_sched(E) drm_panel_backlight_quirks(E) cec(E) snd_pcm(E) drm_buddy(E) snd_seq_dummy(E) drm_ttm_helper(E) btusb(E) kvm(E) snd_seq_oss(E) btrtl(E) ttm(E) btintel(E) snd_seq_midi(E) btbcm(E) drm_exec(E) snd_seq_midi_event(E) i2c_algo_bit(E) snd_rawmidi(E) bluetooth(E) drm_suballoc_helper(E) irqbypass(E) snd_seq(E) ghash_clmulni_intel(E) sha512_ssse3(E) drm_display_helper(E) aesni_intel(E) snd_seq_device(E) rfkill(E) snd_timer(E) gf128mul(E) drm_client_lib(E) drm_kms_helper(E) snd(E) i2c_piix4(E) joydev(E) soundcore(E) wmi_bmof(E) ccp(E) k10temp(E) i2c_smbus(E) gpio_amdpt(E) i2c_designware_platform(E) gpio_generic(E) sg(E)
[  876.949914]  i2c_designware_core(E) sch_fq_codel(E) parport_pc(E) drm(E) ppdev(E) lp(E) parport(E) fuse(E) nfnetlink(E) ip_tables(E) ext4 crc16 mbcache jbd2 sd_mod sfp mdio_i2c i2c_core txgbe ahci ngbe pcs_xpcs libahci libwx r8169 phylink libata realtek ptp pps_core video wmi
[  876.949933] CPU: 14 UID: 0 PID: 0 Comm: swapper/14 Kdump: loaded Tainted: G        W   E       6.16.0-rc2+ #20 PREEMPT(voluntary)
[  876.949935] Tainted: [W]=WARN, [E]=UNSIGNED_MODULE
[  876.949936] Hardware name: Micro-Star International Co., Ltd. MS-7E16/X670E GAMING PLUS WIFI (MS-7E16), BIOS 1.90 12/31/2024
[  876.949936] RIP: 0010:__list_del_entry_valid_or_report+0x67/0x120
[  876.949938] Code: 00 00 00 48 39 7d 08 0f 85 a6 00 00 00 5b b8 01 00 00 00 5d 41 5c e9 73 0d 93 ff 48 89 fe 48 c7 c7 a0 31 e8 89 e8 59 7c b3 ff &lt;0f&gt; 0b 31 c0 5b 5d 41 5c e9 57 0d 93 ff 48 89 fe 48 c7 c7 c8 31 e8
[  876.949940] RSP: 0018:ffffaa73405d0c60 EFLAGS: 00010282
[  876.949941] RAX: 0000000000000000 RBX: ffffead40445a348 RCX: 0000000000000000
[  876.949942] RDX: 0000000000000105 RSI: 00000
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-38490</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:

mptcp: make fallback action and fallback decision atomic

Syzkaller reported the following splat:

  WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 __mptcp_do_fallback net/mptcp/protocol.h:1223 [inline]
  WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcp_do_fallback net/mptcp/protocol.h:1244 [inline]
  WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 check_fully_established net/mptcp/options.c:982 [inline]
  WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcp_incoming_options+0x21a8/0x2510 net/mptcp/options.c:1153
  Modules linked in:
  CPU: 1 UID: 0 PID: 7704 Comm: syz.3.1419 Not tainted 6.16.0-rc3-gbd5ce2324dba #20 PREEMPT(voluntary)
  Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
  RIP: 0010:__mptcp_do_fallback net/mptcp/protocol.h:1223 [inline]
  RIP: 0010:mptcp_do_fallback net/mptcp/protocol.h:1244 [inline]
  RIP: 0010:check_fully_established net/mptcp/options.c:982 [inline]
  RIP: 0010:mptcp_incoming_options+0x21a8/0x2510 net/mptcp/options.c:1153
  Code: 24 18 e8 bb 2a 00 fd e9 1b df ff ff e8 b1 21 0f 00 e8 ec 5f c4 fc 44 0f b7 ac 24 b0 00 00 00 e9 54 f1 ff ff e8 d9 5f c4 fc 90 &lt;0f&gt; 0b 90 e9 b8 f4 ff ff e8 8b 2a 00 fd e9 8d e6 ff ff e8 81 2a 00
  RSP: 0018:ffff8880a3f08448 EFLAGS: 00010246
  RAX: 0000000000000000 RBX: ffff8880180a8000 RCX: ffffffff84afcf45
  RDX: ffff888090223700 RSI: ffffffff84afdaa7 RDI: 0000000000000001
  RBP: ffff888017955780 R08: 0000000000000001 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
  R13: ffff8880180a8910 R14: ffff8880a3e9d058 R15: 0000000000000000
  FS:  00005555791b8500(0000) GS:ffff88811c495000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 000000110c2800b7 CR3: 0000000058e44000 CR4: 0000000000350ef0
  Call Trace:
   &lt;IRQ&gt;
   tcp_reset+0x26f/0x2b0 net/ipv4/tcp_input.c:4432
   tcp_validate_incoming+0x1057/0x1b60 net/ipv4/tcp_input.c:5975
   tcp_rcv_established+0x5b5/0x21f0 net/ipv4/tcp_input.c:6166
   tcp_v4_do_rcv+0x5dc/0xa70 net/ipv4/tcp_ipv4.c:1925
   tcp_v4_rcv+0x3473/0x44a0 net/ipv4/tcp_ipv4.c:2363
   ip_protocol_deliver_rcu+0xba/0x480 net/ipv4/ip_input.c:205
   ip_local_deliver_finish+0x2f1/0x500 net/ipv4/ip_input.c:233
   NF_HOOK include/linux/netfilter.h:317 [inline]
   NF_HOOK include/linux/netfilter.h:311 [inline]
   ip_local_deliver+0x1be/0x560 net/ipv4/ip_input.c:254
   dst_input include/net/dst.h:469 [inline]
   ip_rcv_finish net/ipv4/ip_input.c:447 [inline]
   NF_HOOK include/linux/netfilter.h:317 [inline]
   NF_HOOK include/linux/netfilter.h:311 [inline]
   ip_rcv+0x514/0x810 net/ipv4/ip_input.c:567
   __netif_receive_skb_one_core+0x197/0x1e0 net/core/dev.c:5975
   __netif_receive_skb+0x1f/0x120 net/core/dev.c:6088
   process_backlog+0x301/0x1360 net/core/dev.c:6440
   __napi_poll.constprop.0+0xba/0x550 net/core/dev.c:7453
   napi_poll net/core/dev.c:7517 [inline]
   net_rx_action+0xb44/0x1010 net/core/dev.c:7644
   handle_softirqs+0x1d0/0x770 kernel/softirq.c:579
   do_softirq+0x3f/0x90 kernel/softirq.c:480
   &lt;/IRQ&gt;
   &lt;TASK&gt;
   __local_bh_enable_ip+0xed/0x110 kernel/softirq.c:407
   local_bh_enable include/linux/bottom_half.h:33 [inline]
   inet_csk_listen_stop+0x2c5/0x1070 net/ipv4/inet_connection_sock.c:1524
   mptcp_check_listen_stop.part.0+0x1cc/0x220 net/mptcp/protocol.c:2985
   mptcp_check_listen_stop net/mptcp/mib.h:118 [inline]
   __mptcp_close+0x9b9/0xbd0 net/mptcp/protocol.c:3000
   mptcp_close+0x2f/0x140 net/mptcp/protocol.c:3066
   inet_release+0xed/0x200 net/ipv4/af_inet.c:435
   inet6_release+0x4f/0x70 net/ipv6/af_inet6.c:487
   __sock_release+0xb3/0x270 net/socket.c:649
   sock_close+0x1c/0x30 net/socket.c:1439
   __fput+0x402/0xb70 fs/file_table.c:465
   task_work_run+0x150/0x240 kernel/task_work.c:227
   resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
   exit_to_user_mode_loop+0xd4
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-38491</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns

What we want is to verify there is that clone won't expose something
hidden by a mount we wouldn't be able to undo.  "Wouldn't be able to undo"
may be a result of MNT_LOCKED on a child, but it may also come from
lacking admin rights in the userns of the namespace mount belongs to.

clone_private_mnt() checks the former, but not the latter.

There's a number of rather confusing CAP_SYS_ADMIN checks in various
userns during the mount, especially with the new mount API; they serve
different purposes and in case of clone_private_mnt() they usually,
but not always end up covering the missing check mentioned above.</Note>
    </Notes>
    <CVE>CVE-2025-38499</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: interface: fix use-after-free after changing collect_md xfrm interface

collect_md property on xfrm interfaces can only be set on device creation,
thus xfrmi_changelink() should fail when called on such interfaces.

The check to enforce this was done only in the case where the xi was
returned from xfrmi_locate() which doesn't look for the collect_md
interface, and thus the validation was never reached.

Calling changelink would thus errornously place the special interface xi
in the xfrmi_net-&gt;xfrmi hash, but since it also exists in the
xfrmi_net-&gt;collect_md_xfrmi pointer it would lead to a double free when
the net namespace was taken down [1].

Change the check to use the xi from netdev_priv which is available earlier
in the function to prevent changes in xfrm collect_md interfaces.

[1] resulting oops:
[    8.516540] kernel BUG at net/core/dev.c:12029!
[    8.516552] Oops: invalid opcode: 0000 [#1] SMP NOPTI
[    8.516559] CPU: 0 UID: 0 PID: 12 Comm: kworker/u80:0 Not tainted 6.15.0-virtme #5 PREEMPT(voluntary)
[    8.516565] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[    8.516569] Workqueue: netns cleanup_net
[    8.516579] RIP: 0010:unregister_netdevice_many_notify+0x101/0xab0
[    8.516590] Code: 90 0f 0b 90 48 8b b0 78 01 00 00 48 8b 90 80 01 00 00 48 89 56 08 48 89 32 4c 89 80 78 01 00 00 48 89 b8 80 01 00 00 eb ac 90 &lt;0f&gt; 0b 48 8b 45 00 4c 8d a0 88 fe ff ff 48 39 c5 74 5c 41 80 bc 24
[    8.516593] RSP: 0018:ffffa93b8006bd30 EFLAGS: 00010206
[    8.516598] RAX: ffff98fe4226e000 RBX: ffffa93b8006bd58 RCX: ffffa93b8006bc60
[    8.516601] RDX: 0000000000000004 RSI: 0000000000000000 RDI: dead000000000122
[    8.516603] RBP: ffffa93b8006bdd8 R08: dead000000000100 R09: ffff98fe4133c100
[    8.516605] R10: 0000000000000000 R11: 00000000000003d2 R12: ffffa93b8006be00
[    8.516608] R13: ffffffff96c1a510 R14: ffffffff96c1a510 R15: ffffa93b8006be00
[    8.516615] FS:  0000000000000000(0000) GS:ffff98fee73b7000(0000) knlGS:0000000000000000
[    8.516619] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    8.516622] CR2: 00007fcd2abd0700 CR3: 000000003aa40000 CR4: 0000000000752ef0
[    8.516625] PKRU: 55555554
[    8.516627] Call Trace:
[    8.516632]  &lt;TASK&gt;
[    8.516635]  ? rtnl_is_locked+0x15/0x20
[    8.516641]  ? unregister_netdevice_queue+0x29/0xf0
[    8.516650]  ops_undo_list+0x1f2/0x220
[    8.516659]  cleanup_net+0x1ad/0x2e0
[    8.516664]  process_one_work+0x160/0x380
[    8.516673]  worker_thread+0x2aa/0x3c0
[    8.516679]  ? __pfx_worker_thread+0x10/0x10
[    8.516686]  kthread+0xfb/0x200
[    8.516690]  ? __pfx_kthread+0x10/0x10
[    8.516693]  ? __pfx_kthread+0x10/0x10
[    8.516697]  ret_from_fork+0x82/0xf0
[    8.516705]  ? __pfx_kthread+0x10/0x10
[    8.516709]  ret_from_fork_asm+0x1a/0x30
[    8.516718]  &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2025-38500</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 assertion when building free space tree

When building the free space tree with the block group tree feature
enabled, we can hit an assertion failure like this:

  BTRFS info (device loop0 state M): rebuilding free space tree
  assertion failed: ret == 0, in fs/btrfs/free-space-tree.c:1102
  ------------[ cut here ]------------
  kernel BUG at fs/btrfs/free-space-tree.c:1102!
  Internal error: Oops - BUG: 00000000f2000800 [#1]  SMP
  Modules linked in:
  CPU: 1 UID: 0 PID: 6592 Comm: syz-executor322 Not tainted 6.15.0-rc7-syzkaller-gd7fa1af5b33e #0 PREEMPT
  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 : populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102
  lr : populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102
  sp : ffff8000a4ce7600
  x29: ffff8000a4ce76e0 x28: ffff0000c9bc6000 x27: ffff0000ddfff3d8
  x26: ffff0000ddfff378 x25: dfff800000000000 x24: 0000000000000001
  x23: ffff8000a4ce7660 x22: ffff70001499cecc x21: ffff0000e1d8c160
  x20: ffff0000e1cb7800 x19: ffff0000e1d8c0b0 x18: 00000000ffffffff
  x17: ffff800092f39000 x16: ffff80008ad27e48 x15: ffff700011e740c0
  x14: 1ffff00011e740c0 x13: 0000000000000004 x12: ffffffffffffffff
  x11: ffff700011e740c0 x10: 0000000000ff0100 x9 : 94ef24f55d2dbc00
  x8 : 94ef24f55d2dbc00 x7 : 0000000000000001 x6 : 0000000000000001
  x5 : ffff8000a4ce6f98 x4 : ffff80008f415ba0 x3 : ffff800080548ef0
  x2 : 0000000000000000 x1 : 0000000100000000 x0 : 000000000000003e
  Call trace:
   populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 (P)
   btrfs_rebuild_free_space_tree+0x14c/0x54c fs/btrfs/free-space-tree.c:1337
   btrfs_start_pre_rw_mount+0xa78/0xe10 fs/btrfs/disk-io.c:3074
   btrfs_remount_rw fs/btrfs/super.c:1319 [inline]
   btrfs_reconfigure+0x828/0x2418 fs/btrfs/super.c:1543
   reconfigure_super+0x1d4/0x6f0 fs/super.c:1083
   do_remount fs/namespace.c:3365 [inline]
   path_mount+0xb34/0xde0 fs/namespace.c:4200
   do_mount fs/namespace.c:4221 [inline]
   __do_sys_mount fs/namespace.c:4432 [inline]
   __se_sys_mount fs/namespace.c:4409 [inline]
   __arm64_sys_mount+0x3e8/0x468 fs/namespace.c:4409
   __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
  Code: f0047182 91178042 528089c3 9771d47b (d4210000)
  ---[ end trace 0000000000000000 ]---

This happens because we are processing an empty block group, which has
no extents allocated from it, there are no items for this block group,
including the block group item since block group items are stored in a
dedicated tree when using the block group tree feature. It also means
this is the block group with the highest start offset, so there are no
higher keys in the extent root, hence btrfs_search_slot_for_read()
returns 1 (no higher key found).

Fix this by asserting 'ret' is 0 only if the block group tree feature
is not enabled, in which case we should find a block group item for
the block group since it's stored in the extent root and block group
item keys are greater than extent item keys (the value for
BTRFS_BLOCK_GROUP_ITEM_KEY is 192 and for BTRFS_EXTENT_ITEM_KEY and
BTRFS_METADATA_ITEM_KEY the values are 168 and 169 respectively).
In case 'ret' is 1, we just need to add a record to the free space
tree which spans the whole block group, and we can achieve this by
making 'ret == 0' as the while loop's condition.</Note>
    </Notes>
    <CVE>CVE-2025-38503</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Allow CPU to reschedule while setting per-page memory attributes

When running an SEV-SNP guest with a sufficiently large amount of memory (1TB+),
the host can experience CPU soft lockups when running an operation in
kvm_vm_set_mem_attributes() to set memory attributes on the whole
range of guest memory.

watchdog: BUG: soft lockup - CPU#8 stuck for 26s! [qemu-kvm:6372]
CPU: 8 UID: 0 PID: 6372 Comm: qemu-kvm Kdump: loaded Not tainted 6.15.0-rc7.20250520.el9uek.rc1.x86_64 #1 PREEMPT(voluntary)
Hardware name: Oracle Corporation ORACLE SERVER E4-2c/Asm,MB Tray,2U,E4-2c, BIOS 78016600 11/13/2024
RIP: 0010:xas_create+0x78/0x1f0
Code: 00 00 00 41 80 fc 01 0f 84 82 00 00 00 ba 06 00 00 00 bd 06 00 00 00 49 8b 45 08 4d 8d 65 08 41 39 d6 73 20 83 ed 06 48 85 c0 &lt;74&gt; 67 48 89 c2 83 e2 03 48 83 fa 02 75 0c 48 3d 00 10 00 00 0f 87
RSP: 0018:ffffad890a34b940 EFLAGS: 00000286
RAX: ffff96f30b261daa RBX: ffffad890a34b9c8 RCX: 0000000000000000
RDX: 000000000000001e RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000018 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffffad890a356868
R13: ffffad890a356860 R14: 0000000000000000 R15: ffffad890a356868
FS:  00007f5578a2a400(0000) GS:ffff97ed317e1000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f015c70fb18 CR3: 00000001109fd006 CR4: 0000000000f70ef0
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 xas_store+0x58/0x630
 __xa_store+0xa5/0x130
 xa_store+0x2c/0x50
 kvm_vm_set_mem_attributes+0x343/0x710 [kvm]
 kvm_vm_ioctl+0x796/0xab0 [kvm]
 __x64_sys_ioctl+0xa3/0xd0
 do_syscall_64+0x8c/0x7a0
 entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x7f5578d031bb
Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 2d 4c 0f 00 f7 d8 64 89 01 48
RSP: 002b:00007ffe0a742b88 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 000000004020aed2 RCX: 00007f5578d031bb
RDX: 00007ffe0a742c80 RSI: 000000004020aed2 RDI: 000000000000000b
RBP: 0000010000000000 R08: 0000010000000000 R09: 0000017680000000
R10: 0000000000000080 R11: 0000000000000246 R12: 00005575e5f95120
R13: 00007ffe0a742c80 R14: 0000000000000008 R15: 00005575e5f961e0

While looping through the range of memory setting the attributes,
call cond_resched() to give the scheduler a chance to run a higher
priority task on the runqueue if necessary and avoid staying in
kernel mode long enough to trigger the lockup.</Note>
    </Notes>
    <CVE>CVE-2025-38506</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:

kasan: remove kasan_find_vm_area() to prevent possible deadlock

find_vm_area() couldn't be called in atomic_context.  If find_vm_area() is
called to reports vm area information, kasan can trigger deadlock like:

CPU0                                CPU1
vmalloc();
 alloc_vmap_area();
  spin_lock(&amp;vn-&gt;busy.lock)
                                    spin_lock_bh(&amp;some_lock);
   &lt;interrupt occurs&gt;
   &lt;in softirq&gt;
   spin_lock(&amp;some_lock);
                                    &lt;access invalid address&gt;
                                    kasan_report();
                                     print_report();
                                      print_address_description();
                                       kasan_find_vm_area();
                                        find_vm_area();
                                         spin_lock(&amp;vn-&gt;busy.lock) // deadlock!

To prevent possible deadlock while kasan reports, remove kasan_find_vm_area().</Note>
    </Notes>
    <CVE>CVE-2025-38510</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: prevent A-MSDU attacks in mesh networks

This patch is a mitigation to prevent the A-MSDU spoofing vulnerability
for mesh networks. The initial update to the IEEE 802.11 standard, in
response to the FragAttacks, missed this case (CVE-2025-27558). It can
be considered a variant of CVE-2020-24588 but for mesh networks.

This patch tries to detect if a standard MSDU was turned into an A-MSDU
by an adversary. This is done by parsing a received A-MSDU as a standard
MSDU, calculating the length of the Mesh Control header, and seeing if
the 6 bytes after this header equal the start of an rfc1042 header. If
equal, this is a strong indication of an ongoing attack attempt.

This defense was tested with mac80211_hwsim against a mesh network that
uses an empty Mesh Address Extension field, i.e., when four addresses
are used, and when using a 12-byte Mesh Address Extension field, i.e.,
when six addresses are used. Functionality of normal MSDUs and A-MSDUs
was also tested, and confirmed working, when using both an empty and
12-byte Mesh Address Extension field.

It was also tested with mac80211_hwsim that A-MSDU attacks in non-mesh
networks keep being detected and prevented.

Note that the vulnerability being patched, and the defense being
implemented, was also discussed in the following paper and in the
following IEEE 802.11 presentation:

https://papers.mathyvanhoef.com/wisec2025.pdf
https://mentor.ieee.org/802.11/dcn/25/11-25-0949-00-000m-a-msdu-mesh-spoof-protection.docx</Note>
    </Notes>
    <CVE>CVE-2025-38512</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: zd1211rw: Fix potential NULL pointer dereference in zd_mac_tx_to_dev()

There is a potential NULL pointer dereference in zd_mac_tx_to_dev(). For
example, the following is possible:

    	T0			    		T1
zd_mac_tx_to_dev()
  /* len == skb_queue_len(q) */
  while (len &gt; ZD_MAC_MAX_ACK_WAITERS) {

					  filter_ack()
					    spin_lock_irqsave(&amp;q-&gt;lock, flags);
					    /* position == skb_queue_len(q) */
					    for (i=1; i&lt;position; i++)
				    	      skb = __skb_dequeue(q)

					    if (mac-&gt;type == NL80211_IFTYPE_AP)
					      skb = __skb_dequeue(q);
					    spin_unlock_irqrestore(&amp;q-&gt;lock, flags);

    skb_dequeue() -&gt; NULL

Since there is a small gap between checking skb queue length and skb being
unconditionally dequeued in zd_mac_tx_to_dev(), skb_dequeue() can return NULL.
Then the pointer is passed to zd_mac_tx_status() where it is dereferenced.

In order to avoid potential NULL pointer dereference due to situations like
above, check if skb is not NULL before passing it to zd_mac_tx_status().

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2025-38513</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 oops due to non-existence of prealloc backlog struct

If an AF_RXRPC service socket is opened and bound, but calls are
preallocated, then rxrpc_alloc_incoming_call() will oops because the
rxrpc_backlog struct doesn't get allocated until the first preallocation is
made.

Fix this by returning NULL from rxrpc_alloc_incoming_call() if there is no
backlog struct.  This will cause the incoming call to be aborted.</Note>
    </Notes>
    <CVE>CVE-2025-38514</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/sched: Increment job count before swapping tail spsc queue

A small race exists between spsc_queue_push and the run-job worker, in
which spsc_queue_push may return not-first while the run-job worker has
already idled due to the job count being zero. If this race occurs, job
scheduling stops, leading to hangs while waiting on the job's DMA
fences.

Seal this race by incrementing the job count before appending to the
SPSC queue.

This race was observed on a drm-tip 6.16-rc1 build with the Xe driver in
an SVM test case.</Note>
    </Notes>
    <CVE>CVE-2025-38515</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: qcom: msm: mark certain pins as invalid for interrupts

On some platforms, the UFS-reset pin has no interrupt logic in TLMM but
is nevertheless registered as a GPIO in the kernel. This enables the
user-space to trigger a BUG() in the pinctrl-msm driver by running, for
example: `gpiomon -c 0 113` on RB2.

The exact culprit is requesting pins whose intr_detection_width setting
is not 1 or 2 for interrupts. This hits a BUG() in
msm_gpio_irq_set_type(). Potentially crashing the kernel due to an
invalid request from user-space is not optimal, so let's go through the
pins and mark those that would fail the check as invalid for the irq chip
as we should not even register them as available irqs.

This function can be extended if we determine that there are more
corner-cases like this.</Note>
    </Notes>
    <CVE>CVE-2025-38516</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Don't call mmput from MMU notifier callback

If the process is exiting, the mmput inside mmu notifier callback from
compactd or fork or numa balancing could release the last reference
of mm struct to call exit_mmap and free_pgtable, this triggers deadlock
with below backtrace.

The deadlock will leak kfd process as mmu notifier release is not called
and cause VRAM leaking.

The fix is to take mm reference mmget_non_zero when adding prange to the
deferred list to pair with mmput in deferred list work.

If prange split and add into pchild list, the pchild work_item.mm is not
used, so remove the mm parameter from svm_range_unmap_split and
svm_range_add_child.

The backtrace of hung task:

 INFO: task python:348105 blocked for more than 64512 seconds.
 Call Trace:
  __schedule+0x1c3/0x550
  schedule+0x46/0xb0
  rwsem_down_write_slowpath+0x24b/0x4c0
  unlink_anon_vmas+0xb1/0x1c0
  free_pgtables+0xa9/0x130
  exit_mmap+0xbc/0x1a0
  mmput+0x5a/0x140
  svm_range_cpu_invalidate_pagetables+0x2b/0x40 [amdgpu]
  mn_itree_invalidate+0x72/0xc0
  __mmu_notifier_invalidate_range_start+0x48/0x60
  try_to_unmap_one+0x10fa/0x1400
  rmap_walk_anon+0x196/0x460
  try_to_unmap+0xbb/0x210
  migrate_page_unmap+0x54d/0x7e0
  migrate_pages_batch+0x1c3/0xae0
  migrate_pages_sync+0x98/0x240
  migrate_pages+0x25c/0x520
  compact_zone+0x29d/0x590
  compact_zone_order+0xb6/0xf0
  try_to_compact_pages+0xbe/0x220
  __alloc_pages_direct_compact+0x96/0x1a0
  __alloc_pages_slowpath+0x410/0x930
  __alloc_pages_nodemask+0x3a9/0x3e0
  do_huge_pmd_anonymous_page+0xd7/0x3e0
  __handle_mm_fault+0x5e3/0x5f0
  handle_mm_fault+0xf7/0x2e0
  hmm_vma_fault.isra.0+0x4d/0xa0
  walk_pmd_range.isra.0+0xa8/0x310
  walk_pud_range+0x167/0x240
  walk_pgd_range+0x55/0x100
  __walk_page_range+0x87/0x90
  walk_page_range+0xf6/0x160
  hmm_range_fault+0x4f/0x90
  amdgpu_hmm_range_get_pages+0x123/0x230 [amdgpu]
  amdgpu_ttm_tt_get_user_pages+0xb1/0x150 [amdgpu]
  init_user_pages+0xb1/0x2a0 [amdgpu]
  amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x543/0x7d0 [amdgpu]
  kfd_ioctl_alloc_memory_of_gpu+0x24c/0x4e0 [amdgpu]
  kfd_ioctl+0x29d/0x500 [amdgpu]

(cherry picked from commit a29e067bd38946f752b0ef855f3dfff87e77bec7)</Note>
    </Notes>
    <CVE>CVE-2025-38520</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 recv-recv race of completed call

If a call receives an event (such as incoming data), the call gets placed
on the socket's queue and a thread in recvmsg can be awakened to go and
process it.  Once the thread has picked up the call off of the queue,
further events will cause it to be requeued, and once the socket lock is
dropped (recvmsg uses call-&gt;user_mutex to allow the socket to be used in
parallel), a second thread can come in and its recvmsg can pop the call off
the socket queue again.

In such a case, the first thread will be receiving stuff from the call and
the second thread will be blocked on call-&gt;user_mutex.  The first thread
can, at this point, process both the event that it picked call for and the
event that the second thread picked the call for and may see the call
terminate - in which case the call will be "released", decoupling the call
from the user call ID assigned to it (RXRPC_USER_CALL_ID in the control
message).

The first thread will return okay, but then the second thread will wake up
holding the user_mutex and, if it sees that the call has been released by
the first thread, it will BUG thusly:

	kernel BUG at net/rxrpc/recvmsg.c:474!

Fix this by just dequeuing the call and ignoring it if it is seen to be
already released.  We can't tell userspace about it anyway as the user call
ID has become stale.</Note>
    </Notes>
    <CVE>CVE-2025-38524</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: add NULL check in eswitch lag check

The function ice_lag_is_switchdev_running() is being called from outside of
the LAG event handler code.  This results in the lag-&gt;upper_netdev being
NULL sometimes.  To avoid a NULL-pointer dereference, there needs to be a
check before it is dereferenced.</Note>
    </Notes>
    <CVE>CVE-2025-38526</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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_oplock_break

A race condition can occur in cifs_oplock_break() leading to a
use-after-free of the cinode structure when unmounting:

  cifs_oplock_break()
    _cifsFileInfo_put(cfile)
      cifsFileInfo_put_final()
        cifs_sb_deactive()
          [last ref, start releasing sb]
            kill_sb()
              kill_anon_super()
                generic_shutdown_super()
                  evict_inodes()
                    dispose_list()
                      evict()
                        destroy_inode()
                          call_rcu(&amp;inode-&gt;i_rcu, i_callback)
    spin_lock(&amp;cinode-&gt;open_file_lock)  &lt;- OK
                            [later] i_callback()
                              cifs_free_inode()
                                kmem_cache_free(cinode)
    spin_unlock(&amp;cinode-&gt;open_file_lock)  &lt;- UAF
    cifs_done_oplock_break(cinode)       &lt;- UAF

The issue occurs when umount has already released its reference to the
superblock. When _cifsFileInfo_put() calls cifs_sb_deactive(), this
releases the last reference, triggering the immediate cleanup of all
inodes under RCU. However, cifs_oplock_break() continues to access the
cinode after this point, resulting in use-after-free.

Fix this by holding an extra reference to the superblock during the
entire oplock break operation. This ensures that the superblock and
its inodes remain valid until the oplock break completes.</Note>
    </Notes>
    <CVE>CVE-2025-38527</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Reject %p% format string in bprintf-like helpers

static const char fmt[] = "%p%";
    bpf_trace_printk(fmt, sizeof(fmt));

The above BPF program isn't rejected and causes a kernel warning at
runtime:

    Please remove unsupported %\x00 in format string
    WARNING: CPU: 1 PID: 7244 at lib/vsprintf.c:2680 format_decode+0x49c/0x5d0

This happens because bpf_bprintf_prepare skips over the second %,
detected as punctuation, while processing %p. This patch fixes it by
not skipping over punctuation. %\x00 is then processed in the next
iteration and rejected.</Note>
    </Notes>
    <CVE>CVE-2025-38528</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: aio_iiro_16: Fix bit shift out of bounds

When checking for a supported IRQ number, the following test is used:

	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.  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-38529</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: pcl812: Fix bit shift out of bounds

When checking for a supported IRQ number, the following test is used:

	if ((1 &lt;&lt; it-&gt;options[1]) &amp; board-&gt;irq_bits) {

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-38530</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: common: st_sensors: Fix use of uninitialize device structs

Throughout the various probe functions &amp;indio_dev-&gt;dev is used before it
is initialized. This caused a kernel panic in st_sensors_power_enable()
when the call to devm_regulator_bulk_get_enable() fails and then calls
dev_err_probe() with the uninitialized device.

This seems to only cause a panic with dev_err_probe(), dev_err(),
dev_warn() and dev_info() don't seem to cause a panic, but are fixed
as well.

The issue is reported and traced here: [1]</Note>
    </Notes>
    <CVE>CVE-2025-38531</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: libwx: fix the using of Rx buffer DMA

The wx_rx_buffer structure contained two DMA address fields: 'dma' and
'page_dma'. However, only 'page_dma' was actually initialized and used
to program the Rx descriptor. But 'dma' was uninitialized and used in
some paths.

This could lead to undefined behavior, including DMA errors or
use-after-free, if the uninitialized 'dma' was used. Althrough such
error has not yet occurred, it is worth fixing in the code.</Note>
    </Notes>
    <CVE>CVE-2025-38533</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix unbalanced regulator disable in UTMI PHY mode

When transitioning from USB_ROLE_DEVICE to USB_ROLE_NONE, the code
assumed that the regulator should be disabled. However, if the regulator
is marked as always-on, regulator_is_enabled() continues to return true,
leading to an incorrect attempt to disable a regulator which is not
enabled.

This can result in warnings such as:

[  250.155624] WARNING: CPU: 1 PID: 7326 at drivers/regulator/core.c:3004
_regulator_disable+0xe4/0x1a0
[  250.155652] unbalanced disables for VIN_SYS_5V0

To fix this, we move the regulator control logic into
tegra186_xusb_padctl_id_override() function since it's directly related
to the ID override state. The regulator is now only disabled when the role
transitions from USB_ROLE_HOST to USB_ROLE_NONE, by checking the VBUS_ID
register. This ensures that regulator enable/disable operations are
properly balanced and only occur when actually transitioning to/from host
mode.</Note>
    </Notes>
    <CVE>CVE-2025-38535</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Don't register LEDs for genphy

If a PHY has no driver, the genphy driver is probed/removed directly in
phy_attach/detach. If the PHY's ofnode has an "leds" subnode, then the
LEDs will be (un)registered when probing/removing the genphy driver.
This could occur if the leds are for a non-generic driver that isn't
loaded for whatever reason. Synchronously removing the PHY device in
phy_detach leads to the following deadlock:

rtnl_lock()
ndo_close()
    ...
    phy_detach()
        phy_remove()
            phy_leds_unregister()
                led_classdev_unregister()
                    led_trigger_set()
                        netdev_trigger_deactivate()
                            unregister_netdevice_notifier()
                                rtnl_lock()

There is a corresponding deadlock on the open/register side of things
(and that one is reported by lockdep), but it requires a race while this
one is deterministic.

Generic PHYs do not support LEDs anyway, so don't bother registering
them.</Note>
    </Notes>
    <CVE>CVE-2025-38537</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: nbpfaxi: Fix memory corruption in probe()

The nbpf-&gt;chan[] array is allocated earlier in the nbpf_probe() function
and it has "num_channels" elements.  These three loops iterate one
element farther than they should and corrupt memory.

The changes to the second loop are more involved.  In this case, we're
copying data from the irqbuf[] array into the nbpf-&gt;chan[] array.  If
the data in irqbuf[i] is the error IRQ then we skip it, so the iterators
are not in sync.  I added a check to ensure that we don't go beyond the
end of the irqbuf[] array.  I'm pretty sure this can't happen, but it
seemed harmless to add a check.

On the other hand, after the loop has ended there is a check to ensure
that the "chan" iterator is where we expect it to be.  In the original
code we went one element beyond the end of the array so the iterator
wasn't in the correct place and it would always return -EINVAL.  However,
now it will always be in the correct place.  I deleted the check since
we know the result.</Note>
    </Notes>
    <CVE>CVE-2025-38538</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Add down_write(trace_event_sem) when adding trace event

When a module is loaded, it adds trace events defined by the module. It
may also need to modify the modules trace printk formats to replace enum
names with their values.

If two modules are loaded at the same time, the adding of the event to the
ftrace_events list can corrupt the walking of the list in the code that is
modifying the printk format strings and crash the kernel.

The addition of the event should take the trace_event_sem for write while
it adds the new event.

Also add a lockdep_assert_held() on that semaphore in
__trace_add_event_dirs() as it iterates the list.</Note>
    </Notes>
    <CVE>CVE-2025-38539</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: quirks: Add quirk for 2 Chicony Electronics HP 5MP Cameras

The Chicony Electronics HP 5MP Cameras (USB ID 04F2:B824 &amp; 04F2:B82C)
report a HID sensor interface that is not actually implemented.
Attempting to access this non-functional sensor via iio_info causes
system hangs as runtime PM tries to wake up an unresponsive sensor.

Add these 2 devices to the HID ignore list since the sensor interface is
non-functional by design and should not be exposed to userspace.</Note>
    </Notes>
    <CVE>CVE-2025-38540</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: mt7925: Fix null-ptr-deref in mt7925_thermal_init()

devm_kasprintf() returns NULL on error. Currently, mt7925_thermal_init()
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-38541</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: nvdec: Fix dma_alloc_coherent error check

Check for NULL return value with dma_alloc_coherent, in line with
Robin's fix for vic.c in 'drm/tegra: vic: Fix DMA API misuse'.</Note>
    </Notes>
    <CVE>CVE-2025-38543</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 bug due to prealloc collision

When userspace is using AF_RXRPC to provide a server, it has to preallocate
incoming calls and assign to them call IDs that will be used to thread
related recvmsg() and sendmsg() together.  The preallocated call IDs will
automatically be attached to calls as they come in until the pool is empty.

To the kernel, the call IDs are just arbitrary numbers, but userspace can
use the call ID to hold a pointer to prepared structs.  In any case, the
user isn't permitted to create two calls with the same call ID (call IDs
become available again when the call ends) and EBADSLT should result from
sendmsg() if an attempt is made to preallocate a call with an in-use call
ID.

However, the cleanup in the error handling will trigger both assertions in
rxrpc_cleanup_call() because the call isn't marked complete and isn't
marked as having been released.

Fix this by setting the call state in rxrpc_service_prealloc_one() and then
marking it as being released before calling the cleanup function.</Note>
    </Notes>
    <CVE>CVE-2025-38544</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 memory leak of struct clip_vcc.

ioctl(ATMARP_MKIP) allocates struct clip_vcc and set it to
vcc-&gt;user_back.

The code assumes that vcc_destroy_socket() passes NULL skb
to vcc-&gt;push() when the socket is close()d, and then clip_push()
frees clip_vcc.

However, ioctl(ATMARPD_CTRL) sets NULL to vcc-&gt;push() in
atm_init_atmarp(), resulting in memory leak.

Let's serialise two ioctl() by lock_sock() and check vcc-&gt;push()
in atm_init_atmarp() to prevent memleak.</Note>
    </Notes>
    <CVE>CVE-2025-38546</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: (corsair-cpro) Validate the size of the received input buffer

Add buffer_recv_size to store the size of the received bytes.
Validate buffer_recv_size in send_usb_cmd().</Note>
    </Notes>
    <CVE>CVE-2025-38548</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: mcast: Delay put pmc-&gt;idev in mld_del_delrec()

pmc-&gt;idev is still used in ip6_mc_clear_src(), so as mld_clear_delrec()
does, the reference should be put after ip6_mc_clear_src() return.</Note>
    </Notes>
    <CVE>CVE-2025-38550</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: plug races between subflow fail and subflow creation

We have races similar to the one addressed by the previous patch between
subflow failing and additional subflow creation. They are just harder to
trigger.

The solution is similar. Use a separate flag to track the condition
'socket state prevent any additional subflow creation' protected by the
fallback lock.

The socket fallback makes such flag true, and also receiving or sending
an MP_FAIL option.

The field 'allow_infinite_fallback' is now always touched under the
relevant lock, we can drop the ONCE annotation on write.</Note>
    </Notes>
    <CVE>CVE-2025-38552</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Restrict conditions for adding duplicating netems to qdisc tree

netem_enqueue's duplication prevention logic breaks when a netem
resides in a qdisc tree with other netems - this can lead to a
soft lockup and OOM loop in netem_dequeue, as seen in [1].
Ensure that a duplicating netem cannot exist in a tree with other
netems.

Previous approaches suggested in discussions in chronological order:

1) Track duplication status or ttl in the sk_buff struct. Considered
too specific a use case to extend such a struct, though this would
be a resilient fix and address other previous and potential future
DOS bugs like the one described in loopy fun [2].

2) Restrict netem_enqueue recursion depth like in act_mirred with a
per cpu variable. However, netem_dequeue can call enqueue on its
child, and the depth restriction could be bypassed if the child is a
netem.

3) Use the same approach as in 2, but add metadata in netem_skb_cb
to handle the netem_dequeue case and track a packet's involvement
in duplication. This is an overly complex approach, and Jamal
notes that the skb cb can be overwritten to circumvent this
safeguard.

4) Prevent the addition of a netem to a qdisc tree if its ancestral
path contains a netem. However, filters and actions can cause a
packet to change paths when re-enqueued to the root from netem
duplication, leading us to the current solution: prevent a
duplicating netem from inhabiting the same tree as other netems.

[1] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/
[2] https://lwn.net/Articles/719297/</Note>
    </Notes>
    <CVE>CVE-2025-38553</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 : fix use-after-free in composite_dev_cleanup()

1. In func configfs_composite_bind() -&gt; composite_os_desc_req_prepare():
if kmalloc fails, the pointer cdev-&gt;os_desc_req will be freed but not
set to NULL. Then it will return a failure to the upper-level function.
2. in func configfs_composite_bind() -&gt; composite_dev_cleanup():
it will checks whether cdev-&gt;os_desc_req is NULL. If it is not NULL, it
will attempt to use it.This will lead to a use-after-free issue.

BUG: KASAN: use-after-free in composite_dev_cleanup+0xf4/0x2c0
Read of size 8 at addr 0000004827837a00 by task init/1

CPU: 10 PID: 1 Comm: init Tainted: G           O      5.10.97-oh #1
 kasan_report+0x188/0x1cc
 __asan_load8+0xb4/0xbc
 composite_dev_cleanup+0xf4/0x2c0
 configfs_composite_bind+0x210/0x7ac
 udc_bind_to_driver+0xb4/0x1ec
 usb_gadget_probe_driver+0xec/0x21c
 gadget_dev_desc_UDC_store+0x264/0x27c</Note>
    </Notes>
    <CVE>CVE-2025-38555</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: Harden s32ton() against conversion to 0 bits

Testing by the syzbot fuzzer showed that the HID core gets a
shift-out-of-bounds exception when it tries to convert a 32-bit
quantity to a 0-bit quantity.  Ideally this should never occur, but
there are buggy devices and some might have a report field with size
set to zero; we shouldn't reject the report or the device just because
of that.

Instead, harden the s32ton() routine so that it returns a reasonable
result instead of crashing when it is called with the number of bits
set to 0 -- the same as what snto32() does.</Note>
    </Notes>
    <CVE>CVE-2025-38556</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/sev: Evict cache lines during SNP memory validation

An SNP cache coherency vulnerability requires a cache line eviction
mitigation when validating memory after a page state change to private.
The specific mitigation is to touch the first and last byte of each 4K
page that is being validated. There is no need to perform the mitigation
when performing a page state change to shared and rescinding validation.

CPUID bit Fn8000001F_EBX[31] defines the COHERENCY_SFW_NO CPUID bit
that, when set, indicates that the software mitigation for this
vulnerability is not needed.

Implement the mitigation and invoke it when validating memory (making it
private) and the COHERENCY_SFW_NO bit is not set, indicating the SNP
guest is vulnerable.</Note>
    </Notes>
    <CVE>CVE-2025-38560</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:

perf/core: Prevent VMA split of buffer mappings

The perf mmap code is careful about mmap()'ing the user page with the
ringbuffer and additionally the auxiliary buffer, when the event supports
it. Once the first mapping is established, subsequent mapping have to use
the same offset and the same size in both cases. The reference counting for
the ringbuffer and the auxiliary buffer depends on this being correct.

Though perf does not prevent that a related mapping is split via mmap(2),
munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls,
which take reference counts, but then the subsequent perf_mmap_close()
calls are not longer fulfilling the offset and size checks. This leads to
reference count leaks.

As perf already has the requirement for subsequent mappings to match the
initial mapping, the obvious consequence is that VMA splits, caused by
resizing of a mapping or partial unmapping, have to be prevented.

Implement the vm_operations_struct::may_split() callback and return
unconditionally -EINVAL.

That ensures that the mapping offsets and sizes cannot be changed after the
fact. Remapping to a different fixed address with the same size is still
possible as it takes the references for the new mapping and drops those of
the old mapping.</Note>
    </Notes>
    <CVE>CVE-2025-38563</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:

sunrpc: fix handling of server side tls alerts

Scott Mayhew discovered a security exploit in NFS over TLS in
tls_alert_recv() due to its assumption it can read data from
the msg iterator's kvec..

kTLS implementation splits TLS non-data record payload between
the control message buffer (which includes the type such as TLS
aler or TLS cipher change) and the rest of the payload (say TLS
alert's level/description) which goes into the msg payload buffer.

This patch proposes to rework how control messages are setup and
used by sock_recvmsg().

If no control message structure is setup, kTLS layer will read and
process TLS data record types. As soon as it encounters a TLS control
message, it would return an error. At that point, NFS can setup a
kvec backed msg buffer and read in the control message such as a
TLS alert. Msg iterator can advance the kvec pointer as a part of
the copy process thus we need to revert the iterator before calling
into the tls_alert_recv.</Note>
    </Notes>
    <CVE>CVE-2025-38566</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: mqprio: fix stack out-of-bounds write in tc entry parsing

TCA_MQPRIO_TC_ENTRY_INDEX is validated using
NLA_POLICY_MAX(NLA_U32, TC_QOPT_MAX_QUEUE), which allows the value
TC_QOPT_MAX_QUEUE (16). This leads to a 4-byte out-of-bounds stack
write in the fp[] array, which only has room for 16 elements (0-15).

Fix this by changing the policy to allow only up to TC_QOPT_MAX_QUEUE - 1.</Note>
    </Notes>
    <CVE>CVE-2025-38568</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix client side handling of tls alerts

A security exploit was discovered in NFS over TLS in tls_alert_recv
due to its assumption that there is valid data in the msghdr's
iterator's kvec.

Instead, this patch proposes the rework how control messages are
setup and used by sock_recvmsg().

If no control message structure is setup, kTLS layer will read and
process TLS data record types. As soon as it encounters a TLS control
message, it would return an error. At that point, NFS can setup a kvec
backed control buffer and read in the control message such as a TLS
alert. Scott found that a msg iterator can advance the kvec pointer
as a part of the copy process thus we need to revert the iterator
before calling into the tls_alert_recv.</Note>
    </Notes>
    <CVE>CVE-2025-38571</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:

ipv6: reject malicious packets in ipv6_gso_segment()

syzbot was able to craft a packet with very long IPv6 extension headers
leading to an overflow of skb-&gt;transport_header.

This 16bit field has a limited range.

Add skb_reset_transport_header_careful() helper and use it
from ipv6_gso_segment()

WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 skb_reset_transport_header include/linux/skbuff.h:3032 [inline]
WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151
Modules linked in:
CPU: 0 UID: 0 PID: 5871 Comm: syz-executor211 Not tainted 6.16.0-rc6-syzkaller-g7abc678e3084 #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025
 RIP: 0010:skb_reset_transport_header include/linux/skbuff.h:3032 [inline]
 RIP: 0010:ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151
Call Trace:
 &lt;TASK&gt;
  skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53
  nsh_gso_segment+0x54a/0xe10 net/nsh/nsh.c:110
  skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53
  __skb_gso_segment+0x342/0x510 net/core/gso.c:124
  skb_gso_segment include/net/gso.h:83 [inline]
  validate_xmit_skb+0x857/0x11b0 net/core/dev.c:3950
  validate_xmit_skb_list+0x84/0x120 net/core/dev.c:4000
  sch_direct_xmit+0xd3/0x4b0 net/sched/sch_generic.c:329
  __dev_xmit_skb net/core/dev.c:4102 [inline]
  __dev_queue_xmit+0x17b6/0x3a70 net/core/dev.c:4679</Note>
    </Notes>
    <CVE>CVE-2025-38572</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:

pptp: ensure minimal skb length in pptp_xmit()

Commit aabc6596ffb3 ("net: ppp: Add bound checking for skb data
on ppp_sync_txmung") fixed ppp_sync_txmunge()

We need a similar fix in pptp_xmit(), otherwise we might
read uninit data as reported by syzbot.

BUG: KMSAN: uninit-value in pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193
  pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193
  ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2290 [inline]
  ppp_input+0x1d6/0xe60 drivers/net/ppp/ppp_generic.c:2314
  pppoe_rcv_core+0x1e8/0x760 drivers/net/ppp/pppoe.c:379
  sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148
  __release_sock+0x1d3/0x330 net/core/sock.c:3213
  release_sock+0x6b/0x270 net/core/sock.c:3767
  pppoe_sendmsg+0x15d/0xcb0 drivers/net/ppp/pppoe.c:904
  sock_sendmsg_nosec net/socket.c:712 [inline]
  __sock_sendmsg+0x330/0x3d0 net/socket.c:727
  ____sys_sendmsg+0x893/0xd80 net/socket.c:2566
  ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620
  __sys_sendmmsg+0x2d9/0x7c0 net/socket.c:2709</Note>
    </Notes>
    <CVE>CVE-2025-38574</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/eeh: Make EEH driver device hotplug safe

Multiple race conditions existed between the PCIe hotplug driver and the
EEH driver, leading to a variety of kernel oopses of the same general
nature:

&lt;pcie device unplug&gt;
&lt;eeh driver trigger&gt;
&lt;hotplug removal trigger&gt;
&lt;pcie tree reconfiguration&gt;
&lt;eeh recovery next step&gt;
&lt;oops in EEH driver bus iteration loop&gt;

A second class of oops is also seen when the underlying bus disappears
during device recovery.

Refactor the EEH module to be PCI rescan and remove safe.  Also clean
up a few minor formatting / readability issues.</Note>
    </Notes>
    <CVE>CVE-2025-38576</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ccp - Fix crash when rebind ccp device for ccp.ko

When CONFIG_CRYPTO_DEV_CCP_DEBUGFS is enabled, rebinding
the ccp device causes the following crash:

$ echo '0000:0a:00.2' &gt; /sys/bus/pci/drivers/ccp/unbind
$ echo '0000:0a:00.2' &gt; /sys/bus/pci/drivers/ccp/bind

[  204.976930] BUG: kernel NULL pointer dereference, address: 0000000000000098
[  204.978026] #PF: supervisor write access in kernel mode
[  204.979126] #PF: error_code(0x0002) - not-present page
[  204.980226] PGD 0 P4D 0
[  204.981317] Oops: Oops: 0002 [#1] SMP NOPTI
...
[  204.997852] Call Trace:
[  204.999074]  &lt;TASK&gt;
[  205.000297]  start_creating+0x9f/0x1c0
[  205.001533]  debugfs_create_dir+0x1f/0x170
[  205.002769]  ? srso_return_thunk+0x5/0x5f
[  205.004000]  ccp5_debugfs_setup+0x87/0x170 [ccp]
[  205.005241]  ccp5_init+0x8b2/0x960 [ccp]
[  205.006469]  ccp_dev_init+0xd4/0x150 [ccp]
[  205.007709]  sp_init+0x5f/0x80 [ccp]
[  205.008942]  sp_pci_probe+0x283/0x2e0 [ccp]
[  205.010165]  ? srso_return_thunk+0x5/0x5f
[  205.011376]  local_pci_probe+0x4f/0xb0
[  205.012584]  pci_device_probe+0xdb/0x230
[  205.013810]  really_probe+0xed/0x380
[  205.015024]  __driver_probe_device+0x7e/0x160
[  205.016240]  device_driver_attach+0x2f/0x60
[  205.017457]  bind_store+0x7c/0xb0
[  205.018663]  drv_attr_store+0x28/0x40
[  205.019868]  sysfs_kf_write+0x5f/0x70
[  205.021065]  kernfs_fop_write_iter+0x145/0x1d0
[  205.022267]  vfs_write+0x308/0x440
[  205.023453]  ksys_write+0x6d/0xe0
[  205.024616]  __x64_sys_write+0x1e/0x30
[  205.025778]  x64_sys_call+0x16ba/0x2150
[  205.026942]  do_syscall_64+0x56/0x1e0
[  205.028108]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[  205.029276] RIP: 0033:0x7fbc36f10104
[  205.030420] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 e1 08 2e 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5

This patch sets ccp_debugfs_dir to NULL after destroying it in
ccp5_debugfs_destroy, allowing the directory dentry to be
recreated when rebinding the ccp device.

Tested on AMD Ryzen 7 1700X.</Note>
    </Notes>
    <CVE>CVE-2025-38581</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/hns: Fix double destruction of rsv_qp

rsv_qp may be double destroyed in error flow, first in free_mr_init(),
and then in hns_roce_exit(). Fix it by moving the free_mr_init() call
into hns_roce_v2_init().

list_del corruption, ffff589732eb9b50-&gt;next is LIST_POISON1 (dead000000000100)
WARNING: CPU: 8 PID: 1047115 at lib/list_debug.c:53 __list_del_entry_valid+0x148/0x240
...
Call trace:
 __list_del_entry_valid+0x148/0x240
 hns_roce_qp_remove+0x4c/0x3f0 [hns_roce_hw_v2]
 hns_roce_v2_destroy_qp_common+0x1dc/0x5f4 [hns_roce_hw_v2]
 hns_roce_v2_destroy_qp+0x22c/0x46c [hns_roce_hw_v2]
 free_mr_exit+0x6c/0x120 [hns_roce_hw_v2]
 hns_roce_v2_exit+0x170/0x200 [hns_roce_hw_v2]
 hns_roce_exit+0x118/0x350 [hns_roce_hw_v2]
 __hns_roce_hw_v2_init_instance+0x1c8/0x304 [hns_roce_hw_v2]
 hns_roce_hw_v2_reset_notify_init+0x170/0x21c [hns_roce_hw_v2]
 hns_roce_hw_v2_reset_notify+0x6c/0x190 [hns_roce_hw_v2]
 hclge_notify_roce_client+0x6c/0x160 [hclge]
 hclge_reset_rebuild+0x150/0x5c0 [hclge]
 hclge_reset+0x10c/0x140 [hclge]
 hclge_reset_subtask+0x80/0x104 [hclge]
 hclge_reset_service_task+0x168/0x3ac [hclge]
 hclge_service_task+0x50/0x100 [hclge]
 process_one_work+0x250/0x9a0
 worker_thread+0x324/0x990
 kthread+0x190/0x210
 ret_from_fork+0x10/0x18</Note>
    </Notes>
    <CVE>CVE-2025-38582</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

clk: xilinx: vcu: unregister pll_post only if registered correctly

If registration of pll_post is failed, it will be set to NULL or ERR,
unregistering same will fail with following call trace:

Unable to handle kernel NULL pointer dereference at virtual address 008
pc : clk_hw_unregister+0xc/0x20
lr : clk_hw_unregister_fixed_factor+0x18/0x30
sp : ffff800011923850
...
Call trace:
 clk_hw_unregister+0xc/0x20
 clk_hw_unregister_fixed_factor+0x18/0x30
 xvcu_unregister_clock_provider+0xcc/0xf4 [xlnx_vcu]
 xvcu_probe+0x2bc/0x53c [xlnx_vcu]</Note>
    </Notes>
    <CVE>CVE-2025-38583</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix pd UAF once and for all

There is a race condition/UAF in padata_reorder that goes back
to the initial commit.  A reference count is taken at the start
of the process in padata_do_parallel, and released at the end in
padata_serial_worker.

This reference count is (and only is) required for padata_replace
to function correctly.  If padata_replace is never called then
there is no issue.

In the function padata_reorder which serves as the core of padata,
as soon as padata is added to queue-&gt;serial.list, and the associated
spin lock released, that padata may be processed and the reference
count on pd would go away.

Fix this by getting the next padata before the squeue-&gt;serial lock
is released.

In order to make this possible, simplify padata_reorder by only
calling it once the next padata arrives.</Note>
    </Notes>
    <CVE>CVE-2025-38584</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

staging: media: atomisp: Fix stack buffer overflow in gmin_get_var_int()

When gmin_get_config_var() calls efi.get_variable() and the EFI variable
is larger than the expected buffer size, two behaviors combine to create
a stack buffer overflow:

1. gmin_get_config_var() does not return the proper error code when
   efi.get_variable() fails. It returns the stale 'ret' value from
   earlier operations instead of indicating the EFI failure.

2. When efi.get_variable() returns EFI_BUFFER_TOO_SMALL, it updates
   *out_len to the required buffer size but writes no data to the output
   buffer. However, due to bug #1, gmin_get_var_int() believes the call
   succeeded.

The caller gmin_get_var_int() then performs:
- Allocates val[CFG_VAR_NAME_MAX + 1] (65 bytes) on stack
- Calls gmin_get_config_var(dev, is_gmin, var, val, &amp;len) with len=64
- If EFI variable is &gt;64 bytes, efi.get_variable() sets len=required_size
- Due to bug #1, thinks call succeeded with len=required_size
- Executes val[len] = 0, writing past end of 65-byte stack buffer

This creates a stack buffer overflow when EFI variables are larger than
64 bytes. Since EFI variables can be controlled by firmware or system
configuration, this could potentially be exploited for code execution.

Fix the bug by returning proper error codes from gmin_get_config_var()
based on EFI status instead of stale 'ret' value.

The gmin_get_var_int() function is called during device initialization
for camera sensor configuration on Intel Bay Trail and Cherry Trail
platforms using the atomisp camera stack.</Note>
    </Notes>
    <CVE>CVE-2025-38585</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:

ipv6: fix possible infinite loop in fib6_info_uses_dev()

fib6_info_uses_dev() seems to rely on RCU without an explicit
protection.

Like the prior fix in rt6_nlmsg_size(),
we need to make sure fib6_del_route() or fib6_add_rt2node()
have not removed the anchor from the list, or we risk an infinite loop.</Note>
    </Notes>
    <CVE>CVE-2025-38587</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: prevent infinite loop in rt6_nlmsg_size()

While testing prior patch, I was able to trigger
an infinite loop in rt6_nlmsg_size() in the following place:

list_for_each_entry_rcu(sibling, &amp;f6i-&gt;fib6_siblings,
			fib6_siblings) {
	rt6_nh_nlmsg_size(sibling-&gt;fib6_nh, &amp;nexthop_len);
}

This is because fib6_del_route() and fib6_add_rt2node()
uses list_del_rcu(), which can confuse rcu readers,
because they might no longer see the head of the list.

Restart the loop if f6i-&gt;fib6_nsiblings is zero.</Note>
    </Notes>
    <CVE>CVE-2025-38588</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/mlx5e: Remove skb secpath if xfrm state is not found

Hardware returns a unique identifier for a decrypted packet's xfrm
state, this state is looked up in an xarray. However, the state might
have been freed by the time of this lookup.

Currently, if the state is not found, only a counter is incremented.
The secpath (sp) extension on the skb is not removed, resulting in
sp-&gt;len becoming 0.

Subsequently, functions like __xfrm_policy_check() attempt to access
fields such as xfrm_input_state(skb)-&gt;xso.type (which dereferences
sp-&gt;xvec[sp-&gt;len - 1]) without first validating sp-&gt;len. This leads to
a crash when dereferencing an invalid state pointer.

This patch prevents the crash by explicitly removing the secpath
extension from the skb if the xfrm state is not found after hardware
decryption. This ensures downstream functions do not operate on a
zero-length secpath.

 BUG: unable to handle page fault for address: ffffffff000002c8
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 282e067 P4D 282e067 PUD 0
 Oops: Oops: 0000 [#1] SMP
 CPU: 12 UID: 0 PID: 0 Comm: swapper/12 Not tainted 6.15.0-rc7_for_upstream_min_debug_2025_05_27_22_44 #1 NONE
 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
 RIP: 0010:__xfrm_policy_check+0x61a/0xa30
 Code: b6 77 7f 83 e6 02 74 14 4d 8b af d8 00 00 00 41 0f b6 45 05 c1 e0 03 48 98 49 01 c5 41 8b 45 00 83 e8 01 48 98 49 8b 44 c5 10 &lt;0f&gt; b6 80 c8 02 00 00 83 e0 0c 3c 04 0f 84 0c 02 00 00 31 ff 80 fa
 RSP: 0018:ffff88885fb04918 EFLAGS: 00010297
 RAX: ffffffff00000000 RBX: 0000000000000002 RCX: 0000000000000000
 RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000000
 RBP: ffffffff8311af80 R08: 0000000000000020 R09: 00000000c2eda353
 R10: ffff88812be2bbc8 R11: 000000001faab533 R12: ffff88885fb049c8
 R13: ffff88812be2bbc8 R14: 0000000000000000 R15: ffff88811896ae00
 FS:  0000000000000000(0000) GS:ffff8888dca82000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: ffffffff000002c8 CR3: 0000000243050002 CR4: 0000000000372eb0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
 Call Trace:
  &lt;IRQ&gt;
  ? try_to_wake_up+0x108/0x4c0
  ? udp4_lib_lookup2+0xbe/0x150
  ? udp_lib_lport_inuse+0x100/0x100
  ? __udp4_lib_lookup+0x2b0/0x410
  __xfrm_policy_check2.constprop.0+0x11e/0x130
  udp_queue_rcv_one_skb+0x1d/0x530
  udp_unicast_rcv_skb+0x76/0x90
  __udp4_lib_rcv+0xa64/0xe90
  ip_protocol_deliver_rcu+0x20/0x130
  ip_local_deliver_finish+0x75/0xa0
  ip_local_deliver+0xc1/0xd0
  ? ip_protocol_deliver_rcu+0x130/0x130
  ip_sublist_rcv+0x1f9/0x240
  ? ip_rcv_finish_core+0x430/0x430
  ip_list_rcv+0xfc/0x130
  __netif_receive_skb_list_core+0x181/0x1e0
  netif_receive_skb_list_internal+0x200/0x360
  ? mlx5e_build_rx_skb+0x1bc/0xda0 [mlx5_core]
  gro_receive_skb+0xfd/0x210
  mlx5e_handle_rx_cqe_mpwrq+0x141/0x280 [mlx5_core]
  mlx5e_poll_rx_cq+0xcc/0x8e0 [mlx5_core]
  ? mlx5e_handle_rx_dim+0x91/0xd0 [mlx5_core]
  mlx5e_napi_poll+0x114/0xab0 [mlx5_core]
  __napi_poll+0x25/0x170
  net_rx_action+0x32d/0x3a0
  ? mlx5_eq_comp_int+0x8d/0x280 [mlx5_core]
  ? notifier_call_chain+0x33/0xa0
  handle_softirqs+0xda/0x250
  irq_exit_rcu+0x6d/0xc0
  common_interrupt+0x81/0xa0
  &lt;/IRQ&gt;</Note>
    </Notes>
    <CVE>CVE-2025-38590</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Reject narrower access to pointer ctx fields

The following BPF program, simplified from a syzkaller repro, causes a
kernel warning:

    r0 = *(u8 *)(r1 + 169);
    exit;

With pointer field sk being at offset 168 in __sk_buff. This access is
detected as a narrower read in bpf_skb_is_valid_access because it
doesn't match offsetof(struct __sk_buff, sk). It is therefore allowed
and later proceeds to bpf_convert_ctx_access. Note that for the
"is_narrower_load" case in the convert_ctx_accesses(), the insn-&gt;off
is aligned, so the cnt may not be 0 because it matches the
offsetof(struct __sk_buff, sk) in the bpf_convert_ctx_access. However,
the target_size stays 0 and the verifier errors with a kernel warning:

    verifier bug: error during ctx access conversion(1)

This patch fixes that to return a proper "invalid bpf_context access
off=X size=Y" error on the load instruction.

The same issue affects multiple other fields in context structures that
allow narrow access. Some other non-affected fields (for sk_msg,
sk_lookup, and sockopt) were also changed to use bpf_ctx_range_ptr for
consistency.

Note this syzkaller crash was reported in the "Closes" link below, which
used to be about a different bug, fixed in
commit fce7bd8e385a ("bpf/verifier: Handle BPF_LOAD_ACQ instructions
in insn_def_regno()"). Because syzbot somehow confused the two bugs,
the new crash and repro didn't get reported to the mailing list.</Note>
    </Notes>
    <CVE>CVE-2025-38591</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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_sync: fix double free in 'hci_discovery_filter_clear()'

Function 'hci_discovery_filter_clear()' frees 'uuids' array and then
sets it to NULL. There is a tiny chance of the following race:

'hci_cmd_sync_work()'

 'update_passive_scan_sync()'

   'hci_update_passive_scan_sync()'

     'hci_discovery_filter_clear()'
       kfree(uuids);

       &lt;-------------------------preempted--------------------------------&gt;
                                           'start_service_discovery()'

                                             'hci_discovery_filter_clear()'
                                               kfree(uuids); // DOUBLE FREE

       &lt;-------------------------preempted--------------------------------&gt;

      uuids = NULL;

To fix it let's add locking around 'kfree()' call and NULL pointer
assignment. Otherwise the following backtrace fires:

[ ] ------------[ cut here ]------------
[ ] kernel BUG at mm/slub.c:547!
[ ] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
[ ] CPU: 3 UID: 0 PID: 246 Comm: bluetoothd Tainted: G O 6.12.19-kernel #1
[ ] Tainted: [O]=OOT_MODULE
[ ] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ ] pc : __slab_free+0xf8/0x348
[ ] lr : __slab_free+0x48/0x348
...
[ ] Call trace:
[ ]  __slab_free+0xf8/0x348
[ ]  kfree+0x164/0x27c
[ ]  start_service_discovery+0x1d0/0x2c0
[ ]  hci_sock_sendmsg+0x518/0x924
[ ]  __sock_sendmsg+0x54/0x60
[ ]  sock_write_iter+0x98/0xf8
[ ]  do_iter_readv_writev+0xe4/0x1c8
[ ]  vfs_writev+0x128/0x2b0
[ ]  do_writev+0xfc/0x118
[ ]  __arm64_sys_writev+0x20/0x2c
[ ]  invoke_syscall+0x68/0xf0
[ ]  el0_svc_common.constprop.0+0x40/0xe0
[ ]  do_el0_svc+0x1c/0x28
[ ]  el0_svc+0x30/0xd0
[ ]  el0t_64_sync_handler+0x100/0x12c
[ ]  el0t_64_sync+0x194/0x198
[ ] Code: 8b0002e6 eb17031f 54fffbe1 d503201f (d4210000)
[ ] ---[ end trace 0000000000000000 ]---</Note>
    </Notes>
    <CVE>CVE-2025-38593</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

xen: fix UAF in dmabuf_exp_from_pages()

[dma_buf_fd() fixes; no preferences regarding the tree it goes through -
up to xen folks]

As soon as we'd inserted a file reference into descriptor table, another
thread could close it.  That's fine for the case when all we are doing is
returning that descriptor to userland (it's a race, but it's a userland
race and there's nothing the kernel can do about it).  However, if we
follow fd_install() with any kind of access to objects that would be
destroyed on close (be it the struct file itself or anything destroyed
by its -&gt;release()), we have a UAF.

dma_buf_fd() is a combination of reserving a descriptor and fd_install().
gntdev dmabuf_exp_from_pages() calls it and then proceeds to access the
objects destroyed on close - starting with gntdev_dmabuf itself.

Fix that by doing reserving descriptor before anything else and do
fd_install() only when everything had been set up.</Note>
    </Notes>
    <CVE>CVE-2025-38595</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/rockchip: vop2: fail cleanly if missing a primary plane for a video-port

Each window of a vop2 is usable by a specific set of video ports, so while
binding the vop2, we look through the list of available windows trying to
find one designated as primary-plane and usable by that specific port.

The code later wants to use drm_crtc_init_with_planes with that found
primary plane, but nothing has checked so far if a primary plane was
actually found.

For whatever reason, the rk3576 vp2 does not have a usable primary window
(if vp0 is also in use) which brought the issue to light and ended in a
null-pointer dereference further down.

As we expect a primary-plane to exist for a video-port, add a check at
the end of the window-iteration and fail probing if none was found.</Note>
    </Notes>
    <CVE>CVE-2025-38597</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: clear initialized flag for deinit-ed srng lists

In a number of cases we see kernel panics on resume due
to ath11k kernel page fault, which happens under the
following circumstances:

1) First ath11k_hal_dump_srng_stats() call

 Last interrupt received for each group:
 ath11k_pci 0000:01:00.0: group_id 0 22511ms before
 ath11k_pci 0000:01:00.0: group_id 1 14440788ms before
 [..]
 ath11k_pci 0000:01:00.0: failed to receive control response completion, polling..
 ath11k_pci 0000:01:00.0: Service connect timeout
 ath11k_pci 0000:01:00.0: failed to connect to HTT: -110
 ath11k_pci 0000:01:00.0: failed to start core: -110
 ath11k_pci 0000:01:00.0: firmware crashed: MHI_CB_EE_RDDM
 ath11k_pci 0000:01:00.0: already resetting count 2
 ath11k_pci 0000:01:00.0: failed to wait wlan mode request (mode 4): -110
 ath11k_pci 0000:01:00.0: qmi failed to send wlan mode off: -110
 ath11k_pci 0000:01:00.0: failed to reconfigure driver on crash recovery
 [..]

2) At this point reconfiguration fails (we have 2 resets) and
  ath11k_core_reconfigure_on_crash() calls ath11k_hal_srng_deinit()
  which destroys srng lists.  However, it does not reset per-list
  -&gt;initialized flag.

3) Second ath11k_hal_dump_srng_stats() call sees stale -&gt;initialized
  flag and attempts to dump srng stats:

 Last interrupt received for each group:
 ath11k_pci 0000:01:00.0: group_id 0 66785ms before
 ath11k_pci 0000:01:00.0: group_id 1 14485062ms before
 ath11k_pci 0000:01:00.0: group_id 2 14485062ms before
 ath11k_pci 0000:01:00.0: group_id 3 14485062ms before
 ath11k_pci 0000:01:00.0: group_id 4 14780845ms before
 ath11k_pci 0000:01:00.0: group_id 5 14780845ms before
 ath11k_pci 0000:01:00.0: group_id 6 14485062ms before
 ath11k_pci 0000:01:00.0: group_id 7 66814ms before
 ath11k_pci 0000:01:00.0: group_id 8 68997ms before
 ath11k_pci 0000:01:00.0: group_id 9 67588ms before
 ath11k_pci 0000:01:00.0: group_id 10 69511ms before
 BUG: unable to handle page fault for address: ffffa007404eb010
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 100000067 P4D 100000067 PUD 10022d067 PMD 100b01067 PTE 0
 Oops: 0000 [#1] PREEMPT SMP NOPTI
 RIP: 0010:ath11k_hal_dump_srng_stats+0x2b4/0x3b0 [ath11k]
 Call Trace:
 &lt;TASK&gt;
 ? __die_body+0xae/0xb0
 ? page_fault_oops+0x381/0x3e0
 ? exc_page_fault+0x69/0xa0
 ? asm_exc_page_fault+0x22/0x30
 ? ath11k_hal_dump_srng_stats+0x2b4/0x3b0 [ath11k (HASH:6cea 4)]
 ath11k_qmi_driver_event_work+0xbd/0x1050 [ath11k (HASH:6cea 4)]
 worker_thread+0x389/0x930
 kthread+0x149/0x170

Clear per-list -&gt;initialized flag in ath11k_hal_srng_deinit().</Note>
    </Notes>
    <CVE>CVE-2025-38601</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iwlwifi: Add missing check for alloc_ordered_workqueue

Add check for the return value of alloc_ordered_workqueue since it may
return NULL pointer.</Note>
    </Notes>
    <CVE>CVE-2025-38602</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: rtl818x: Kill URBs before clearing tx status queue

In rtl8187_stop() move the call of usb_kill_anchored_urbs() before clearing
b_tx_status.queue. This change prevents callbacks from using already freed
skb due to anchor was not killed before freeing such skb.

 BUG: kernel NULL pointer dereference, address: 0000000000000080
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 0 P4D 0
 Oops: Oops: 0000 [#1] SMP NOPTI
 CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Not tainted 6.15.0 #8 PREEMPT(voluntary)
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015
 RIP: 0010:ieee80211_tx_status_irqsafe+0x21/0xc0 [mac80211]
 Call Trace:
  &lt;IRQ&gt;
  rtl8187_tx_cb+0x116/0x150 [rtl8187]
  __usb_hcd_giveback_urb+0x9d/0x120
  usb_giveback_urb_bh+0xbb/0x140
  process_one_work+0x19b/0x3c0
  bh_worker+0x1a7/0x210
  tasklet_action+0x10/0x30
  handle_softirqs+0xf0/0x340
  __irq_exit_rcu+0xcd/0xf0
  common_interrupt+0x85/0xa0
  &lt;/IRQ&gt;

Tested on RTL8187BvE device.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2025-38604</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Pass ab pointer directly to ath12k_dp_tx_get_encap_type()

In ath12k_dp_tx_get_encap_type(), the arvif parameter is only used to
retrieve the ab pointer. In vdev delete sequence the arvif-&gt;ar could
become NULL and that would trigger kernel panic.
Since the caller ath12k_dp_tx() already has a valid ab pointer, pass it
directly to avoid panic and unnecessary dereferencing.

PC points to "ath12k_dp_tx+0x228/0x988 [ath12k]"
LR points to "ath12k_dp_tx+0xc8/0x988 [ath12k]".
The Backtrace obtained is as follows:
ath12k_dp_tx+0x228/0x988 [ath12k]
ath12k_mac_tx_check_max_limit+0x608/0x920 [ath12k]
ieee80211_process_measurement_req+0x320/0x348 [mac80211]
ieee80211_tx_dequeue+0x9ac/0x1518 [mac80211]
ieee80211_tx_dequeue+0xb14/0x1518 [mac80211]
ieee80211_tx_prepare_skb+0x224/0x254 [mac80211]
ieee80211_xmit+0xec/0x100 [mac80211]
__ieee80211_subif_start_xmit+0xc50/0xf40 [mac80211]
ieee80211_subif_start_xmit+0x2e8/0x308 [mac80211]
netdev_start_xmit+0x150/0x18c
dev_hard_start_xmit+0x74/0xc0

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1</Note>
    </Notes>
    <CVE>CVE-2025-38605</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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, ktls: Fix data corruption when using bpf_msg_pop_data() in ktls

When sending plaintext data, we initially calculated the corresponding
ciphertext length. However, if we later reduced the plaintext data length
via socket policy, we failed to recalculate the ciphertext length.

This results in transmitting buffers containing uninitialized data during
ciphertext transmission.

This causes uninitialized bytes to be appended after a complete
"Application Data" packet, leading to errors on the receiving end when
parsing TLS record.</Note>
    </Notes>
    <CVE>CVE-2025-38608</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:

PM / devfreq: Check governor before using governor-&gt;name

Commit 96ffcdf239de ("PM / devfreq: Remove redundant governor_name from
struct devfreq") removes governor_name and uses governor-&gt;name to replace
it. But devfreq-&gt;governor may be NULL and directly using
devfreq-&gt;governor-&gt;name may cause null pointer exception. Move the check of
governor to before using governor-&gt;name.</Note>
    </Notes>
    <CVE>CVE-2025-38609</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

powercap: dtpm_cpu: Fix NULL pointer dereference in get_pd_power_uw()

The get_pd_power_uw() function can crash with a NULL pointer dereference
when em_cpu_get() returns NULL. This occurs when a CPU becomes impossible
during runtime, causing get_cpu_device() to return NULL, which propagates
through em_cpu_get() and leads to a crash when em_span_cpus() dereferences
the NULL pointer.

Add a NULL check after em_cpu_get() and return 0 if unavailable,
matching the existing fallback behavior in __dtpm_cpu_setup().

[ rjw: Drop an excess empty code line ]</Note>
    </Notes>
    <CVE>CVE-2025-38610</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

staging: fbtft: fix potential memory leak in fbtft_framebuffer_alloc()

In the error paths after fb_info structure is successfully allocated,
the memory allocated in fb_deferred_io_init() for info-&gt;pagerefs is not
freed. Fix that by adding the cleanup function on the error path.</Note>
    </Notes>
    <CVE>CVE-2025-38612</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix semi-unbounded recursion

Ensure that epoll instances can never form a graph deeper than
EP_MAX_NESTS+1 links.

Currently, ep_loop_check_proc() ensures that the graph is loop-free and
does some recursion depth checks, but those recursion depth checks don't
limit the depth of the resulting tree for two reasons:

 - They don't look upwards in the tree.
 - If there are multiple downwards paths of different lengths, only one of
   the paths is actually considered for the depth check since commit
   28d82dc1c4ed ("epoll: limit paths").

Essentially, the current recursion depth check in ep_loop_check_proc() just
serves to prevent it from recursing too deeply while checking for loops.

A more thorough check is done in reverse_path_check() after the new graph
edge has already been created; this checks, among other things, that no
paths going upwards from any non-epoll file with a length of more than 5
edges exist. However, this check does not apply to non-epoll files.

As a result, it is possible to recurse to a depth of at least roughly 500,
tested on v6.15. (I am unsure if deeper recursion is possible; and this may
have changed with commit 8c44dac8add7 ("eventpoll: Fix priority inversion
problem").)

To fix it:

1. In ep_loop_check_proc(), note the subtree depth of each visited node,
and use subtree depths for the total depth calculation even when a subtree
has already been visited.
2. Add ep_get_upwards_depth_proc() for similarly determining the maximum
depth of an upwards walk.
3. In ep_loop_check(), use these values to limit the total path length
between epoll nodes to EP_MAX_NESTS edges.</Note>
    </Notes>
    <CVE>CVE-2025-38614</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: handle data disappearing from under the TLS ULP

TLS expects that it owns the receive queue of the TCP socket.
This cannot be guaranteed in case the reader of the TCP socket
entered before the TLS ULP was installed, or uses some non-standard
read API (eg. zerocopy ones). Replace the WARN_ON() and a buggy
early exit (which leaves anchor pointing to a freed skb) with real
error handling. Wipe the parsing state and tell the reader to retry.

We already reload the anchor every time we (re)acquire the socket lock,
so the only condition we need to avoid is an out of bounds read
(not having enough bytes in the socket for previously parsed record len).

If some data was read from under TLS but there's enough in the queue
we'll reload and decrypt what is most likely not a valid TLS record.
Leading to some undefined behavior from TLS perspective (corrupting
a stream? missing an alert? missing an attack?) but no kernel crash
should take place.</Note>
    </Notes>
    <CVE>CVE-2025-38616</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/packet: fix a race in packet_set_ring() and packet_notifier()

When packet_set_ring() releases po-&gt;bind_lock, another thread can
run packet_notifier() and process an NETDEV_UP event.

This race and the fix are both similar to that of commit 15fe076edea7
("net/packet: fix a race in packet_bind() and packet_notifier()").

There too the packet_notifier NETDEV_UP event managed to run while a
po-&gt;bind_lock critical section had to be temporarily released. And
the fix was similarly to temporarily set po-&gt;num to zero to keep
the socket unhooked until the lock is retaken.

The po-&gt;bind_lock in packet_set_ring and packet_notifier precede the
introduction of git history.</Note>
    </Notes>
    <CVE>CVE-2025-38617</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:

vsock: Do not allow binding to VMADDR_PORT_ANY

It is possible for a vsock to autobind to VMADDR_PORT_ANY. This can
cause a use-after-free when a connection is made to the bound socket.
The socket returned by accept() also has port VMADDR_PORT_ANY but is not
on the list of unbound sockets. Binding it will result in an extra
refcount decrement similar to the one fixed in fcdd2242c023 (vsock: Keep
the binding until socket destruction).

Modify the check in __vsock_bind_connectible() to also prevent binding
to VMADDR_PORT_ANY.</Note>
    </Notes>
    <CVE>CVE-2025-38618</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:

md: make rdev_addable usable for rcu mode

Our testcase trigger panic:

BUG: kernel NULL pointer dereference, address: 00000000000000e0
...
Oops: Oops: 0000 [#1] SMP NOPTI
CPU: 2 UID: 0 PID: 85 Comm: kworker/2:1 Not tainted 6.16.0+ #94
PREEMPT(none)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.16.1-2.fc37 04/01/2014
Workqueue: md_misc md_start_sync
RIP: 0010:rdev_addable+0x4d/0xf0
...
Call Trace:
 &lt;TASK&gt;
 md_start_sync+0x329/0x480
 process_one_work+0x226/0x6d0
 worker_thread+0x19e/0x340
 kthread+0x10f/0x250
 ret_from_fork+0x14d/0x180
 ret_from_fork_asm+0x1a/0x30
 &lt;/TASK&gt;
Modules linked in: raid10
CR2: 00000000000000e0
---[ end trace 0000000000000000 ]---
RIP: 0010:rdev_addable+0x4d/0xf0

md_spares_need_change in md_start_sync will call rdev_addable which
protected by rcu_read_lock/rcu_read_unlock. This rcu context will help
protect rdev won't be released, but rdev-&gt;mddev will be set to NULL
before we call synchronize_rcu in md_kick_rdev_from_array. Fix this by
using READ_ONCE and check does rdev-&gt;mddev still alive.</Note>
    </Notes>
    <CVE>CVE-2025-38621</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: drop UFO packets in udp_rcv_segment()

When sending a packet with virtio_net_hdr to tun device, if the gso_type
in virtio_net_hdr is SKB_GSO_UDP and the gso_size is less than udphdr
size, below crash may happen.

  ------------[ cut here ]------------
  kernel BUG at net/core/skbuff.c:4572!
  Oops: invalid opcode: 0000 [#1] SMP NOPTI
  CPU: 0 UID: 0 PID: 62 Comm: mytest Not tainted 6.16.0-rc7 #203 PREEMPT(voluntary)
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  RIP: 0010:skb_pull_rcsum+0x8e/0xa0
  Code: 00 00 5b c3 cc cc cc cc 8b 93 88 00 00 00 f7 da e8 37 44 38 00 f7 d8 89 83 88 00 00 00 48 8b 83 c8 00 00 00 5b c3 cc cc cc cc &lt;0f&gt; 0b 0f 0b 66 66 2e 0f 1f 84 00 000
  RSP: 0018:ffffc900001fba38 EFLAGS: 00000297
  RAX: 0000000000000004 RBX: ffff8880040c1000 RCX: ffffc900001fb948
  RDX: ffff888003e6d700 RSI: 0000000000000008 RDI: ffff88800411a062
  RBP: ffff8880040c1000 R08: 0000000000000000 R09: 0000000000000001
  R10: ffff888003606c00 R11: 0000000000000001 R12: 0000000000000000
  R13: ffff888004060900 R14: ffff888004050000 R15: ffff888004060900
  FS:  000000002406d3c0(0000) GS:ffff888084a19000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000000020000040 CR3: 0000000004007000 CR4: 00000000000006f0
  Call Trace:
   &lt;TASK&gt;
   udp_queue_rcv_one_skb+0x176/0x4b0 net/ipv4/udp.c:2445
   udp_queue_rcv_skb+0x155/0x1f0 net/ipv4/udp.c:2475
   udp_unicast_rcv_skb+0x71/0x90 net/ipv4/udp.c:2626
   __udp4_lib_rcv+0x433/0xb00 net/ipv4/udp.c:2690
   ip_protocol_deliver_rcu+0xa6/0x160 net/ipv4/ip_input.c:205
   ip_local_deliver_finish+0x72/0x90 net/ipv4/ip_input.c:233
   ip_sublist_rcv_finish+0x5f/0x70 net/ipv4/ip_input.c:579
   ip_sublist_rcv+0x122/0x1b0 net/ipv4/ip_input.c:636
   ip_list_rcv+0xf7/0x130 net/ipv4/ip_input.c:670
   __netif_receive_skb_list_core+0x21d/0x240 net/core/dev.c:6067
   netif_receive_skb_list_internal+0x186/0x2b0 net/core/dev.c:6210
   napi_complete_done+0x78/0x180 net/core/dev.c:6580
   tun_get_user+0xa63/0x1120 drivers/net/tun.c:1909
   tun_chr_write_iter+0x65/0xb0 drivers/net/tun.c:1984
   vfs_write+0x300/0x420 fs/read_write.c:593
   ksys_write+0x60/0xd0 fs/read_write.c:686
   do_syscall_64+0x50/0x1c0 arch/x86/entry/syscall_64.c:63
   &lt;/TASK&gt;

To trigger gso segment in udp_queue_rcv_skb(), we should also set option
UDP_ENCAP_ESPINUDP to enable udp_sk(sk)-&gt;encap_rcv. When the encap_rcv
hook return 1 in udp_queue_rcv_one_skb(), udp_csum_pull_header() will try
to pull udphdr, but the skb size has been segmented to gso size, which
leads to this crash.

Previous commit cf329aa42b66 ("udp: cope with UDP GRO packet misdirection")
introduces segmentation in UDP receive path only for GRO, which was never
intended to be used for UFO, so drop UFO packets in udp_rcv_segment().</Note>
    </Notes>
    <CVE>CVE-2025-38622</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: pnv_php: Fix surprise plug detection and recovery

The existing PowerNV hotplug code did not handle surprise plug events
correctly, leading to a complete failure of the hotplug system after device
removal and a required reboot to detect new devices.

This comes down to two issues:

 1) When a device is surprise removed, often the bridge upstream
    port will cause a PE freeze on the PHB.  If this freeze is not
    cleared, the MSI interrupts from the bridge hotplug notification
    logic will not be received by the kernel, stalling all plug events
    on all slots associated with the PE.

 2) When a device is removed from a slot, regardless of surprise or
    programmatic removal, the associated PHB/PE ls left frozen.
    If this freeze is not cleared via a fundamental reset, skiboot
    is unable to clear the freeze and cannot retrain / rescan the
    slot.  This also requires a reboot to clear the freeze and redetect
    the device in the slot.

Issue the appropriate unfreeze and rescan commands on hotplug events,
and don't oops on hotplug if pci_bus_to_OF_node() returns NULL.

[bhelgaas: tidy comments]</Note>
    </Notes>
    <CVE>CVE-2025-38623</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:

PCI: pnv_php: Clean up allocated IRQs on unplug

When the root of a nested PCIe bridge configuration is unplugged, the
pnv_php driver leaked the allocated IRQ resources for the child bridges'
hotplug event notifications, resulting in a panic.

Fix this by walking all child buses and deallocating all its IRQ resources
before calling pci_hp_remove_devices().

Also modify the lifetime of the workqueue at struct pnv_php_slot::wq so
that it is only destroyed in pnv_php_free_slot(), instead of
pnv_php_disable_irq(). This is required since pnv_php_disable_irq() will
now be called by workers triggered by hot unplug interrupts, so the
workqueue needs to stay allocated.

The abridged kernel panic that occurs without this patch is as follows:

  WARNING: CPU: 0 PID: 687 at kernel/irq/msi.c:292 msi_device_data_release+0x6c/0x9c
  CPU: 0 UID: 0 PID: 687 Comm: bash Not tainted 6.14.0-rc5+ #2
  Call Trace:
   msi_device_data_release+0x34/0x9c (unreliable)
   release_nodes+0x64/0x13c
   devres_release_all+0xc0/0x140
   device_del+0x2d4/0x46c
   pci_destroy_dev+0x5c/0x194
   pci_hp_remove_devices+0x90/0x128
   pci_hp_remove_devices+0x44/0x128
   pnv_php_disable_slot+0x54/0xd4
   power_write_file+0xf8/0x18c
   pci_slot_attr_store+0x40/0x5c
   sysfs_kf_write+0x64/0x78
   kernfs_fop_write_iter+0x1b0/0x290
   vfs_write+0x3bc/0x50c
   ksys_write+0x84/0x140
   system_call_exception+0x124/0x230
   system_call_vectored_common+0x15c/0x2ec

[bhelgaas: tidy comments]</Note>
    </Notes>
    <CVE>CVE-2025-38624</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: imxfb: Check fb_add_videomode to prevent null-ptr-deref

fb_add_videomode() can fail with -ENOMEM when its internal kmalloc() cannot
allocate a struct fb_modelist.  If that happens, the modelist stays empty but
the driver continues to register.  Add a check for its return value to prevent
poteintial null-ptr-deref, which is similar to the commit 17186f1f90d3 ("fbdev:
Fix do_register_framebuffer to prevent null-ptr-deref in fb_videomode_to_var").</Note>
    </Notes>
    <CVE>CVE-2025-38630</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

pinmux: fix race causing mux_owner NULL with active mux_usecount

commit 5a3e85c3c397 ("pinmux: Use sequential access to access
desc-&gt;pinmux data") tried to address the issue when two client of the
same gpio calls pinctrl_select_state() for the same functionality, was
resulting in NULL pointer issue while accessing desc-&gt;mux_owner.
However, issue was not completely fixed due to the way it was handled
and it can still result in the same NULL pointer.

The issue occurs due to the following interleaving:

     cpu0 (process A)                   cpu1 (process B)

      pin_request() {                   pin_free() {

                                         mutex_lock()
                                         desc-&gt;mux_usecount--; //becomes 0
                                         ..
                                         mutex_unlock()

  mutex_lock(desc-&gt;mux)
  desc-&gt;mux_usecount++; // becomes 1
  desc-&gt;mux_owner = owner;
  mutex_unlock(desc-&gt;mux)

                                         mutex_lock(desc-&gt;mux)
                                         desc-&gt;mux_owner = NULL;
                                         mutex_unlock(desc-&gt;mux)

This sequence leads to a state where the pin appears to be in use
(`mux_usecount == 1`) but has no owner (`mux_owner == NULL`), which can
cause NULL pointer on next pin_request on the same pin.

Ensure that updates to mux_usecount and mux_owner are performed
atomically under the same lock. Only clear mux_owner when mux_usecount
reaches zero and no new owner has been assigned.</Note>
    </Notes>
    <CVE>CVE-2025-38632</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

power: supply: cpcap-charger: Fix null check for power_supply_get_by_name

In the cpcap_usb_detect() function, the power_supply_get_by_name()
function may return `NULL` instead of an error pointer.
To prevent potential null pointer dereferences, Added a null check.</Note>
    </Notes>
    <CVE>CVE-2025-38634</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

clk: davinci: Add NULL check in davinci_lpsc_clk_register()

devm_kasprintf() returns NULL when memory allocation fails. Currently,
davinci_lpsc_clk_register() does not check for this case, which results
in a NULL pointer dereference.

Add NULL check after devm_kasprintf() to prevent this issue and ensuring
no resources are left allocated.</Note>
    </Notes>
    <CVE>CVE-2025-38635</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: xt_nfacct: don't assume acct name is null-terminated

BUG: KASAN: slab-out-of-bounds in .. lib/vsprintf.c:721
Read of size 1 at addr ffff88801eac95c8 by task syz-executor183/5851
[..]
 string+0x231/0x2b0 lib/vsprintf.c:721
 vsnprintf+0x739/0xf00 lib/vsprintf.c:2874
 [..]
 nfacct_mt_checkentry+0xd2/0xe0 net/netfilter/xt_nfacct.c:41
 xt_check_match+0x3d1/0xab0 net/netfilter/x_tables.c:523

nfnl_acct_find_get() handles non-null input, but the error
printk relied on its presence.</Note>
    </Notes>
    <CVE>CVE-2025-38639</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Disable migration in nf_hook_run_bpf().

syzbot reported that the netfilter bpf prog can be called without
migration disabled in xmit path.

Then the assertion in __bpf_prog_run() fails, triggering the splat
below. [0]

Let's use bpf_prog_run_pin_on_cpu() in nf_hook_run_bpf().

[0]:
BUG: assuming non migratable context at ./include/linux/filter.h:703
in_atomic(): 0, irqs_disabled(): 0, migration_disabled() 0 pid: 5829, name: sshd-session
3 locks held by sshd-session/5829:
 #0: ffff88807b4e4218 (sk_lock-AF_INET){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1667 [inline]
 #0: ffff88807b4e4218 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x20/0x50 net/ipv4/tcp.c:1395
 #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline]
 #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline]
 #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: __ip_queue_xmit+0x69/0x26c0 net/ipv4/ip_output.c:470
 #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline]
 #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline]
 #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: nf_hook+0xb2/0x680 include/linux/netfilter.h:241
CPU: 0 UID: 0 PID: 5829 Comm: sshd-session Not tainted 6.16.0-rc6-syzkaller-00002-g155a3c003e55 #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+0x16c/0x1f0 lib/dump_stack.c:120
 __cant_migrate kernel/sched/core.c:8860 [inline]
 __cant_migrate+0x1c7/0x250 kernel/sched/core.c:8834
 __bpf_prog_run include/linux/filter.h:703 [inline]
 bpf_prog_run include/linux/filter.h:725 [inline]
 nf_hook_run_bpf+0x83/0x1e0 net/netfilter/nf_bpf_link.c:20
 nf_hook_entry_hookfn include/linux/netfilter.h:157 [inline]
 nf_hook_slow+0xbb/0x200 net/netfilter/core.c:623
 nf_hook+0x370/0x680 include/linux/netfilter.h:272
 NF_HOOK_COND include/linux/netfilter.h:305 [inline]
 ip_output+0x1bc/0x2a0 net/ipv4/ip_output.c:433
 dst_output include/net/dst.h:459 [inline]
 ip_local_out net/ipv4/ip_output.c:129 [inline]
 __ip_queue_xmit+0x1d7d/0x26c0 net/ipv4/ip_output.c:527
 __tcp_transmit_skb+0x2686/0x3e90 net/ipv4/tcp_output.c:1479
 tcp_transmit_skb net/ipv4/tcp_output.c:1497 [inline]
 tcp_write_xmit+0x1274/0x84e0 net/ipv4/tcp_output.c:2838
 __tcp_push_pending_frames+0xaf/0x390 net/ipv4/tcp_output.c:3021
 tcp_push+0x225/0x700 net/ipv4/tcp.c:759
 tcp_sendmsg_locked+0x1870/0x42b0 net/ipv4/tcp.c:1359
 tcp_sendmsg+0x2e/0x50 net/ipv4/tcp.c:1396
 inet_sendmsg+0xb9/0x140 net/ipv4/af_inet.c:851
 sock_sendmsg_nosec net/socket.c:712 [inline]
 __sock_sendmsg net/socket.c:727 [inline]
 sock_write_iter+0x4aa/0x5b0 net/socket.c:1131
 new_sync_write fs/read_write.c:593 [inline]
 vfs_write+0x6c7/0x1150 fs/read_write.c:686
 ksys_write+0x1f8/0x250 fs/read_write.c:738
 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
RIP: 0033:0x7fe7d365d407
Code: 48 89 fa 4c 89 df e8 38 aa 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
RSP:</Note>
    </Notes>
    <CVE>CVE-2025-38640</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Add missing lock in cfg80211_check_and_end_cac()

Callers of wdev_chandef() must hold the wiphy mutex.

But the worker cfg80211_propagate_cac_done_wk() never takes the lock.
Which triggers the warning below with the mesh_peer_connected_dfs
test from hostapd and not (yet) released mac80211 code changes:

WARNING: CPU: 0 PID: 495 at net/wireless/chan.c:1552 wdev_chandef+0x60/0x165
Modules linked in:
CPU: 0 UID: 0 PID: 495 Comm: kworker/u4:2 Not tainted 6.14.0-rc5-wt-g03960e6f9d47 #33 13c287eeabfe1efea01c0bcc863723ab082e17cf
Workqueue: cfg80211 cfg80211_propagate_cac_done_wk
Stack:
 00000000 00000001 ffffff00 6093267c
 00000000 6002ec30 6d577c50 60037608
 00000000 67e8d108 6063717b 00000000
Call Trace:
 [&lt;6002ec30&gt;] ? _printk+0x0/0x98
 [&lt;6003c2b3&gt;] show_stack+0x10e/0x11a
 [&lt;6002ec30&gt;] ? _printk+0x0/0x98
 [&lt;60037608&gt;] dump_stack_lvl+0x71/0xb8
 [&lt;6063717b&gt;] ? wdev_chandef+0x60/0x165
 [&lt;6003766d&gt;] dump_stack+0x1e/0x20
 [&lt;6005d1b7&gt;] __warn+0x101/0x20f
 [&lt;6005d3a8&gt;] warn_slowpath_fmt+0xe3/0x15d
 [&lt;600b0c5c&gt;] ? mark_lock.part.0+0x0/0x4ec
 [&lt;60751191&gt;] ? __this_cpu_preempt_check+0x0/0x16
 [&lt;600b11a2&gt;] ? mark_held_locks+0x5a/0x6e
 [&lt;6005d2c5&gt;] ? warn_slowpath_fmt+0x0/0x15d
 [&lt;60052e53&gt;] ? unblock_signals+0x3a/0xe7
 [&lt;60052f2d&gt;] ? um_set_signals+0x2d/0x43
 [&lt;60751191&gt;] ? __this_cpu_preempt_check+0x0/0x16
 [&lt;607508b2&gt;] ? lock_is_held_type+0x207/0x21f
 [&lt;6063717b&gt;] wdev_chandef+0x60/0x165
 [&lt;605f89b4&gt;] regulatory_propagate_dfs_state+0x247/0x43f
 [&lt;60052f00&gt;] ? um_set_signals+0x0/0x43
 [&lt;605e6bfd&gt;] cfg80211_propagate_cac_done_wk+0x3a/0x4a
 [&lt;6007e460&gt;] process_scheduled_works+0x3bc/0x60e
 [&lt;6007d0ec&gt;] ? move_linked_works+0x4d/0x81
 [&lt;6007d120&gt;] ? assign_work+0x0/0xaa
 [&lt;6007f81f&gt;] worker_thread+0x220/0x2dc
 [&lt;600786ef&gt;] ? set_pf_worker+0x0/0x57
 [&lt;60087c96&gt;] ? to_kthread+0x0/0x43
 [&lt;6008ab3c&gt;] kthread+0x2d3/0x2e2
 [&lt;6007f5ff&gt;] ? worker_thread+0x0/0x2dc
 [&lt;6006c05b&gt;] ? calculate_sigpending+0x0/0x56
 [&lt;6003b37d&gt;] new_thread_handler+0x4a/0x64
irq event stamp: 614611
hardirqs last  enabled at (614621): [&lt;00000000600bc96b&gt;] __up_console_sem+0x82/0xaf
hardirqs last disabled at (614630): [&lt;00000000600bc92c&gt;] __up_console_sem+0x43/0xaf
softirqs last  enabled at (614268): [&lt;00000000606c55c6&gt;] __ieee80211_wake_queue+0x933/0x985
softirqs last disabled at (614266): [&lt;00000000606c52d6&gt;] __ieee80211_wake_queue+0x643/0x985</Note>
    </Notes>
    <CVE>CVE-2025-38643</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: reject TDLS operations when station is not associated

syzbot triggered a WARN in ieee80211_tdls_oper() by sending
NL80211_TDLS_ENABLE_LINK immediately after NL80211_CMD_CONNECT,
before association completed and without prior TDLS setup.

This left internal state like sdata-&gt;u.mgd.tdls_peer uninitialized,
leading to a WARN_ON() in code paths that assumed it was valid.

Reject the operation early if not in station mode or not associated.</Note>
    </Notes>
    <CVE>CVE-2025-38644</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/mlx5: Check device memory pointer before usage

Add a NULL check before accessing device memory to prevent a crash if
dev-&gt;dm allocation in mlx5_init_once() fails.</Note>
    </Notes>
    <CVE>CVE-2025-38645</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: rtw89: avoid NULL dereference when RX problematic packet on unsupported 6 GHz band

With a quite rare chance, RX report might be problematic to make SW think
a packet is received on 6 GHz band even if the chip does not support 6 GHz
band actually. Since SW won't initialize stuffs for unsupported bands, NULL
dereference will happen then in the sequence, rtw89_vif_rx_stats_iter() -&gt;
rtw89_core_cancel_6ghz_probe_tx(). So, add a check to avoid it.

The following is a crash log for this case.

 BUG: kernel NULL pointer dereference, address: 0000000000000032
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 0 P4D 0
 Oops: 0000 [#1] PREEMPT SMP NOPTI
 CPU: 1 PID: 1907 Comm: irq/131-rtw89_p Tainted: G     U             6.6.56-05896-g89f5fb0eb30b #1 (HASH:1400 4)
 Hardware name: Google Telith/Telith, BIOS Google_Telith.15217.747.0 11/12/2024
 RIP: 0010:rtw89_vif_rx_stats_iter+0xd2/0x310 [rtw89_core]
 Code: 4c 89 7d c8 48 89 55 c0 49 8d 44 24 02 48 89 45 b8 45 31 ff eb 11
 41 c6 45 3a 01 41 b7 01 4d 8b 6d 00 4d 39 f5 74 42 8b 43 10 &lt;41&gt; 33 45
 32 0f b7 4b 14 66 41 33 4d 36 0f b7 c9 09 c1 74 d8 4d 85
 RSP: 0018:ffff9f3080138ca0 EFLAGS: 00010246
 RAX: 00000000b8bf5770 RBX: ffff91b5e8c639c0 RCX: 0000000000000011
 RDX: ffff91b582de1be8 RSI: 0000000000000000 RDI: ffff91b5e8c639e6
 RBP: ffff9f3080138d00 R08: 0000000000000000 R09: 0000000000000000
 R10: ffff91b59de70000 R11: ffffffffc069be50 R12: ffff91b5e8c639e4
 R13: 0000000000000000 R14: ffff91b5828020b8 R15: 0000000000000000
 FS:  0000000000000000(0000) GS:ffff91b8efa40000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000032 CR3: 00000002bf838000 CR4: 0000000000750ee0
 PKRU: 55555554
 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_rtw89_vif_rx_stats_iter+0x10/0x10 [rtw89_core (HASH:1400 5)]
  ? rtw89_vif_rx_stats_iter+0xd2/0x310 [rtw89_core (HASH:1400 5)]
  __iterate_interfaces+0x59/0x110 [mac80211 (HASH:1400 6)]
  ? __pfx_rtw89_vif_rx_stats_iter+0x10/0x10 [rtw89_core (HASH:1400 5)]
  ? __pfx_rtw89_vif_rx_stats_iter+0x10/0x10 [rtw89_core (HASH:1400 5)]
  ieee80211_iterate_active_interfaces_atomic+0x36/0x50 [mac80211 (HASH:1400 6)]
  rtw89_core_rx_to_mac80211+0xfd/0x1b0 [rtw89_core (HASH:1400 5)]
  rtw89_core_rx+0x43a/0x980 [rtw89_core (HASH:1400 5)]</Note>
    </Notes>
    <CVE>CVE-2025-38646</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hfsplus: remove mutex_lock check in hfsplus_free_extents

Syzbot reported an issue in hfsplus filesystem:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 4400 at fs/hfsplus/extents.c:346
	hfsplus_free_extents+0x700/0xad0
Call Trace:
&lt;TASK&gt;
hfsplus_file_truncate+0x768/0xbb0 fs/hfsplus/extents.c:606
hfsplus_write_begin+0xc2/0xd0 fs/hfsplus/inode.c:56
cont_expand_zero fs/buffer.c:2383 [inline]
cont_write_begin+0x2cf/0x860 fs/buffer.c:2446
hfsplus_write_begin+0x86/0xd0 fs/hfsplus/inode.c:52
generic_cont_expand_simple+0x151/0x250 fs/buffer.c:2347
hfsplus_setattr+0x168/0x280 fs/hfsplus/inode.c:263
notify_change+0xe38/0x10f0 fs/attr.c:420
do_truncate+0x1fb/0x2e0 fs/open.c:65
do_sys_ftruncate+0x2eb/0x380 fs/open.c:193
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd

To avoid deadlock, Commit 31651c607151 ("hfsplus: avoid deadlock
on file truncation") unlock extree before hfsplus_free_extents(),
and add check wheather extree is locked in hfsplus_free_extents().

However, when operations such as hfsplus_file_release,
hfsplus_setattr, hfsplus_unlink, and hfsplus_get_block are executed
concurrently in different files, it is very likely to trigger the
WARN_ON, which will lead syzbot and xfstest to consider it as an
abnormality.

The comment above this warning also describes one of the easy
triggering situations, which can easily trigger and cause
xfstest&amp;syzbot to report errors.

[task A]			[task B]
-&gt;hfsplus_file_release
  -&gt;hfsplus_file_truncate
    -&gt;hfs_find_init
      -&gt;mutex_lock
    -&gt;mutex_unlock
				-&gt;hfsplus_write_begin
				  -&gt;hfsplus_get_block
				    -&gt;hfsplus_file_extend
				      -&gt;hfsplus_ext_read_extent
				        -&gt;hfs_find_init
					  -&gt;mutex_lock
    -&gt;hfsplus_free_extents
      WARN_ON(mutex_is_locked) !!!

Several threads could try to lock the shared extents tree.
And warning can be triggered in one thread when another thread
has locked the tree. This is the wrong behavior of the code and
we need to remove the warning.</Note>
    </Notes>
    <CVE>CVE-2025-38650</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

proc: use the same treatment to check proc_lseek as ones for proc_read_iter et.al

Check pde-&gt;proc_ops-&gt;proc_lseek directly may cause UAF in rmmod scenario. 
It's a gap in proc_reg_open() after commit 654b33ada4ab("proc: fix UAF in
proc_get_inode()").  Followed by AI Viro's suggestion, fix it in same
manner.</Note>
    </Notes>
    <CVE>CVE-2025-38653</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 error code in iwl_op_mode_dvm_start()

Preserve the error code if iwl_setup_deferred_work() fails.  The current
code returns ERR_PTR(0) (which is NULL) on this path.  I believe the
missing error code potentially leads to a use after free involving
debugfs.</Note>
    </Notes>
    <CVE>CVE-2025-38656</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

gfs2: No more self recovery

When a node withdraws and it turns out that it is the only node that has
the filesystem mounted, gfs2 currently tries to replay the local journal
to bring the filesystem back into a consistent state.  Not only is that
a very bad idea, it has also never worked because gfs2_recover_func()
will refuse to do anything during a withdraw.

However, before even getting to this point, gfs2_recover_func()
dereferences sdp-&gt;sd_jdesc-&gt;jd_inode.  This was a use-after-free before
commit 04133b607a78 ("gfs2: Prevent double iput for journal on error")
and is a NULL pointer dereference since then.

Simply get rid of self recovery to fix that.</Note>
    </Notes>
    <CVE>CVE-2025-38659</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:

[ceph] parse_longname(): strrchr() expects NUL-terminated string

... and parse_longname() is not guaranteed that.  That's the reason
why it uses kmemdup_nul() to build the argument for kstrtou64();
the problem is, kstrtou64() is not the only thing that need it.

Just get a NUL-terminated copy of the entire thing and be done
with that...</Note>
    </Notes>
    <CVE>CVE-2025-38660</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nilfs2: reject invalid file types when reading inodes

To prevent inodes with invalid file types from tripping through the vfs
and causing malfunctions or assertion failures, add a missing sanity check
when reading an inode from a block device.  If the file type is not valid,
treat it as a filesystem error.</Note>
    </Notes>
    <CVE>CVE-2025-38663</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 a null pointer dereference in ice_copy_and_init_pkg()

Add check for the return value of devm_kmemdup()
to prevent potential null pointer dereference.</Note>
    </Notes>
    <CVE>CVE-2025-38664</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: netlink: can_changelink(): fix NULL pointer deref of struct can_priv::do_set_mode

Andrei Lalaev reported a NULL pointer deref when a CAN device is
restarted from Bus Off and the driver does not implement the struct
can_priv::do_set_mode callback.

There are 2 code path that call struct can_priv::do_set_mode:
- directly by a manual restart from the user space, via
  can_changelink()
- delayed automatic restart after bus off (deactivated by default)

To prevent the NULL pointer deference, refuse a manual restart or
configure the automatic restart delay in can_changelink() and report
the error via extack to user space.

As an additional safety measure let can_restart() return an error if
can_priv::do_set_mode is not set instead of dereferencing it
unchecked.</Note>
    </Notes>
    <CVE>CVE-2025-38665</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: core: fix NULL dereference on unbind due to stale coupling data

Failing to reset coupling_desc.n_coupled after freeing coupled_rdevs can
lead to NULL pointer dereference when regulators are accessed post-unbind.

This can happen during runtime PM or other regulator operations that rely
on coupling metadata.

For example, on ridesx4, unbinding the 'reg-dummy' platform device triggers
a panic in regulator_lock_recursive() due to stale coupling state.

Ensure n_coupled is set to 0 to prevent access to invalid pointers.</Note>
    </Notes>
    <CVE>CVE-2025-38668</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/entry: Mask DAIF in cpu_switch_to(), call_on_irq_stack()

`cpu_switch_to()` and `call_on_irq_stack()` manipulate SP to change
to different stacks along with the Shadow Call Stack if it is enabled.
Those two stack changes cannot be done atomically and both functions
can be interrupted by SErrors or Debug Exceptions which, though unlikely,
is very much broken : if interrupted, we can end up with mismatched stacks
and Shadow Call Stack leading to clobbered stacks.

In `cpu_switch_to()`, it can happen when SP_EL0 points to the new task,
but x18 stills points to the old task's SCS. When the interrupt handler
tries to save the task's SCS pointer, it will save the old task
SCS pointer (x18) into the new task struct (pointed to by SP_EL0),
clobbering it.

In `call_on_irq_stack()`, it can happen when switching from the task stack
to the IRQ stack and when switching back. In both cases, we can be
interrupted when the SCS pointer points to the IRQ SCS, but SP points to
the task stack. The nested interrupt handler pushes its return addresses
on the IRQ SCS. It then detects that SP points to the task stack,
calls `call_on_irq_stack()` and clobbers the task SCS pointer with
the IRQ SCS pointer, which it will also use !

This leads to tasks returning to addresses on the wrong SCS,
or even on the IRQ SCS, triggering kernel panics via CONFIG_VMAP_STACK
or FPAC if enabled.

This is possible on a default config, but unlikely.
However, when enabling CONFIG_ARM64_PSEUDO_NMI, DAIF is unmasked and
instead the GIC is responsible for filtering what interrupts the CPU
should receive based on priority.
Given the goal of emulating NMIs, pseudo-NMIs can be received by the CPU
even in `cpu_switch_to()` and `call_on_irq_stack()`, possibly *very*
frequently depending on the system configuration and workload, leading
to unpredictable kernel panics.

Completely mask DAIF in `cpu_switch_to()` and restore it when returning.
Do the same in `call_on_irq_stack()`, but restore and mask around
the branch.
Mask DAIF even if CONFIG_SHADOW_CALL_STACK is not enabled for consistency
of behaviour between all configurations.

Introduce and use an assembly macro for saving and masking DAIF,
as the existing one saves but only masks IF.</Note>
    </Notes>
    <CVE>CVE-2025-38670</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: qup: jump out of the loop in case of timeout

Original logic only sets the return value but doesn't jump out of the
loop if the bus is kept active by a client. This is not expected. A
malicious or buggy i2c client can hang the kernel in this case and
should be avoided. This is observed during a long time test with a
PCA953x GPIO extender.

Fix it by changing the logic to not only sets the return value, but also
jumps out of the loop and return to the caller with -ETIMEDOUT.</Note>
    </Notes>
    <CVE>CVE-2025-38671</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Avoid stack buffer overflow from kernel cmdline

While the kernel command line is considered trusted in most environments,
avoid writing 1 byte past the end of "acpiid" if the "str" argument is
maximum length.</Note>
    </Notes>
    <CVE>CVE-2025-38676</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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_tables: reject duplicate device on updates

A chain/flowtable update with duplicated devices in the same batch is
possible. Unfortunately, netdev event path only removes the first
device that is found, leaving unregistered the hook of the duplicated
device.

Check if a duplicated device exists in the transaction batch, bail out
with EEXIST in such case.

WARNING is hit when unregistering the hook:

 [49042.221275] WARNING: CPU: 4 PID: 8425 at net/netfilter/core.c:340 nf_hook_entry_head+0xaa/0x150
 [49042.221375] CPU: 4 UID: 0 PID: 8425 Comm: nft Tainted: G S                  6.16.0+ #170 PREEMPT(full)
 [...]
 [49042.221382] RIP: 0010:nf_hook_entry_head+0xaa/0x150</Note>
    </Notes>
    <CVE>CVE-2025-38678</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: venus: Fix OOB read due to missing payload bound check

Currently, The event_seq_changed() handler processes a variable number
of properties sent by the firmware. The number of properties is indicated
by the firmware and used to iterate over the payload. However, the
payload size is not being validated against the actual message length.

This can lead to out-of-bounds memory access if the firmware provides a
property count that exceeds the data available in the payload. Such a
condition can result in kernel crashes or potential information leaks if
memory beyond the buffer is accessed.

Fix this by properly validating the remaining size of the payload before
each property access and updating bounds accordingly as properties are
parsed.

This ensures that property parsing is safely bounded within the received
message buffer and protects against malformed or malicious firmware
behavior.</Note>
    </Notes>
    <CVE>CVE-2025-38679</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: uvcvideo: Fix 1-byte out-of-bounds read in uvc_parse_format()

The buffer length check before calling uvc_parse_format() only ensured
that the buffer has at least 3 bytes (buflen &gt; 2), buf the function
accesses buffer[3], requiring at least 4 bytes.

This can lead to an out-of-bounds read if the buffer has exactly 3 bytes.

Fix it by checking that the buffer has at least 4 bytes in
uvc_parse_format().</Note>
    </Notes>
    <CVE>CVE-2025-38680</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/ptdump: take the memory hotplug lock inside ptdump_walk_pgd()

Memory hot remove unmaps and tears down various kernel page table regions
as required.  The ptdump code can race with concurrent modifications of
the kernel page tables.  When leaf entries are modified concurrently, the
dump code may log stale or inconsistent information for a VA range, but
this is otherwise not harmful.

But when intermediate levels of kernel page table are freed, the dump code
will continue to use memory that has been freed and potentially
reallocated for another purpose.  In such cases, the ptdump code may
dereference bogus addresses, leading to a number of potential problems.

To avoid the above mentioned race condition, platforms such as arm64,
riscv and s390 take memory hotplug lock, while dumping kernel page table
via the sysfs interface /sys/kernel/debug/kernel_page_tables.

Similar race condition exists while checking for pages that might have
been marked W+X via /sys/kernel/debug/kernel_page_tables/check_wx_pages
which in turn calls ptdump_check_wx().  Instead of solving this race
condition again, let's just move the memory hotplug lock inside generic
ptdump_check_wx() which will benefit both the scenarios.

Drop get_online_mems() and put_online_mems() combination from all existing
platform ptdump code paths.</Note>
    </Notes>
    <CVE>CVE-2025-38681</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hv_netvsc: Fix panic during namespace deletion with VF

The existing code move the VF NIC to new namespace when NETDEV_REGISTER is
received on netvsc NIC. During deletion of the namespace,
default_device_exit_batch() &gt;&gt; default_device_exit_net() is called. When
netvsc NIC is moved back and registered to the default namespace, it
automatically brings VF NIC back to the default namespace. This will cause
the default_device_exit_net() &gt;&gt; for_each_netdev_safe loop unable to detect
the list end, and hit NULL ptr:

[  231.449420] mana 7870:00:00.0 enP30832s1: Moved VF to namespace with: eth0
[  231.449656] BUG: kernel NULL pointer dereference, address: 0000000000000010
[  231.450246] #PF: supervisor read access in kernel mode
[  231.450579] #PF: error_code(0x0000) - not-present page
[  231.450916] PGD 17b8a8067 P4D 0
[  231.451163] Oops: Oops: 0000 [#1] SMP NOPTI
[  231.451450] CPU: 82 UID: 0 PID: 1394 Comm: kworker/u768:1 Not tainted 6.16.0-rc4+ #3 VOLUNTARY
[  231.452042] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/21/2024
[  231.452692] Workqueue: netns cleanup_net
[  231.452947] RIP: 0010:default_device_exit_batch+0x16c/0x3f0
[  231.453326] Code: c0 0c f5 b3 e8 d5 db fe ff 48 85 c0 74 15 48 c7 c2 f8 fd ca b2 be 10 00 00 00 48 8d 7d c0 e8 7b 77 25 00 49 8b 86 28 01 00 00 &lt;48&gt; 8b 50 10 4c 8b 2a 4c 8d 62 f0 49 83 ed 10 4c 39 e0 0f 84 d6 00
[  231.454294] RSP: 0018:ff75fc7c9bf9fd00 EFLAGS: 00010246
[  231.454610] RAX: 0000000000000000 RBX: 0000000000000002 RCX: 61c8864680b583eb
[  231.455094] RDX: ff1fa9f71462d800 RSI: ff75fc7c9bf9fd38 RDI: 0000000030766564
[  231.455686] RBP: ff75fc7c9bf9fd78 R08: 0000000000000000 R09: 0000000000000000
[  231.456126] R10: 0000000000000001 R11: 0000000000000004 R12: ff1fa9f70088e340
[  231.456621] R13: ff1fa9f70088e340 R14: ffffffffb3f50c20 R15: ff1fa9f7103e6340
[  231.457161] FS:  0000000000000000(0000) GS:ff1faa6783a08000(0000) knlGS:0000000000000000
[  231.457707] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  231.458031] CR2: 0000000000000010 CR3: 0000000179ab2006 CR4: 0000000000b73ef0
[  231.458434] Call Trace:
[  231.458600]  &lt;TASK&gt;
[  231.458777]  ops_undo_list+0x100/0x220
[  231.459015]  cleanup_net+0x1b8/0x300
[  231.459285]  process_one_work+0x184/0x340

To fix it, move the ns change to a workqueue, and take rtnl_lock to avoid
changing the netdev list when default_device_exit_net() is using it.</Note>
    </Notes>
    <CVE>CVE-2025-38683</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: use old 'nbands' while purging unused classes

Shuang reported sch_ets test-case [1] crashing in ets_class_qlen_notify()
after recent changes from Lion [2]. The problem is: in ets_qdisc_change()
we purge unused DWRR queues; the value of 'q-&gt;nbands' is the new one, and
the cleanup should be done with the old one. The problem is here since my
first attempts to fix ets_qdisc_change(), but it surfaced again after the
recent qdisc len accounting fixes. Fix it purging idle DWRR queues before
assigning a new value of 'q-&gt;nbands', so that all purge operations find a
consistent configuration:

 - old 'q-&gt;nbands' because it's needed by ets_class_find()
 - old 'q-&gt;nstrict' because it's needed by ets_class_is_strict()

 BUG: kernel NULL pointer dereference, address: 0000000000000000
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 0 P4D 0
 Oops: Oops: 0000 [#1] SMP NOPTI
 CPU: 62 UID: 0 PID: 39457 Comm: tc Kdump: loaded Not tainted 6.12.0-116.el10.x86_64 #1 PREEMPT(voluntary)
 Hardware name: Dell Inc. PowerEdge R640/06DKY5, BIOS 2.12.2 07/09/2021
 RIP: 0010:__list_del_entry_valid_or_report+0x4/0x80
 Code: ff 4c 39 c7 0f 84 39 19 8e ff b8 01 00 00 00 c3 cc cc cc cc 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa &lt;48&gt; 8b 17 48 8b 4f 08 48 85 d2 0f 84 56 19 8e ff 48 85 c9 0f 84 ab
 RSP: 0018:ffffba186009f400 EFLAGS: 00010202
 RAX: 00000000000000d6 RBX: 0000000000000000 RCX: 0000000000000004
 RDX: ffff9f0fa29b69c0 RSI: 0000000000000000 RDI: 0000000000000000
 RBP: ffffffffc12c2400 R08: 0000000000000008 R09: 0000000000000004
 R10: ffffffffffffffff R11: 0000000000000004 R12: 0000000000000000
 R13: ffff9f0f8cfe0000 R14: 0000000000100005 R15: 0000000000000000
 FS:  00007f2154f37480(0000) GS:ffff9f269c1c0000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000000 CR3: 00000001530be001 CR4: 00000000007726f0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
 PKRU: 55555554
 Call Trace:
  &lt;TASK&gt;
  ets_class_qlen_notify+0x65/0x90 [sch_ets]
  qdisc_tree_reduce_backlog+0x74/0x110
  ets_qdisc_change+0x630/0xa40 [sch_ets]
  __tc_modify_qdisc.constprop.0+0x216/0x7f0
  tc_modify_qdisc+0x7c/0x120
  rtnetlink_rcv_msg+0x145/0x3f0
  netlink_rcv_skb+0x53/0x100
  netlink_unicast+0x245/0x390
  netlink_sendmsg+0x21b/0x470
  ____sys_sendmsg+0x39d/0x3d0
  ___sys_sendmsg+0x9a/0xe0
  __sys_sendmsg+0x7a/0xd0
  do_syscall_64+0x7d/0x160
  entry_SYSCALL_64_after_hwframe+0x76/0x7e
 RIP: 0033:0x7f2155114084
 Code: 89 02 b8 ff ff ff ff eb bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 80 3d 25 f0 0c 00 00 74 13 b8 2e 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89
 RSP: 002b:00007fff1fd7a988 EFLAGS: 00000202 ORIG_RAX: 000000000000002e
 RAX: ffffffffffffffda RBX: 0000560ec063e5e0 RCX: 00007f2155114084
 RDX: 0000000000000000 RSI: 00007fff1fd7a9f0 RDI: 0000000000000003
 RBP: 00007fff1fd7aa60 R08: 0000000000000010 R09: 000000000000003f
 R10: 0000560ee9b3a010 R11: 0000000000000202 R12: 00007fff1fd7aae0
 R13: 000000006891ccde R14: 0000560ec063e5e0 R15: 00007fff1fd7aad0
  &lt;/TASK&gt;

 [1] https://lore.kernel.org/netdev/e08c7f4a6882f260011909a868311c6e9b54f3e4.1639153474.git.dcaratti@redhat.com/
 [2] https://lore.kernel.org/netdev/d912cbd7-193b-4269-9857-525bee8bbb6a@gmail.com/</Note>
    </Notes>
    <CVE>CVE-2025-38684</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 vmalloc out-of-bounds write in fast_imageblit

This issue triggers when a userspace program does an ioctl
FBIOPUT_CON2FBMAP by passing console number and frame buffer number.
Ideally this maps console to frame buffer and updates the screen if
console is visible.

As part of mapping it has to do resize of console according to frame
buffer info. if this resize fails and returns from vc_do_resize() and
continues further. At this point console and new frame buffer are mapped
and sets display vars. Despite failure still it continue to proceed
updating the screen at later stages where vc_data is related to previous
frame buffer and frame buffer info and display vars are mapped to new
frame buffer and eventully leading to out-of-bounds write in
fast_imageblit(). This bheviour is excepted only when fg_console is
equal to requested console which is a visible console and updates screen
with invalid struct references in fbcon_putcs().</Note>
    </Notes>
    <CVE>CVE-2025-38685</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 race between polling and detaching

syzbot reports a use-after-free in comedi in the below link, which is
due to comedi gladly removing the allocated async area even though poll
requests are still active on the wait_queue_head inside of it. This can
cause a use-after-free when the poll entries are later triggered or
removed, as the memory for the wait_queue_head has been freed.  We need
to check there are no tasks queued on any of the subdevices' wait queues
before allowing the device to be detached by the `COMEDI_DEVCONFIG`
ioctl.

Tasks will read-lock `dev-&gt;attach_lock` before adding themselves to the
subdevice wait queue, so fix the problem in the `COMEDI_DEVCONFIG` ioctl
handler by write-locking `dev-&gt;attach_lock` before checking that all of
the subdevices are safe to be deleted.  This includes testing for any
sleepers on the subdevices' wait queues.  It remains locked until the
device has been detached.  This requires the `comedi_device_detach()`
function to be refactored slightly, moving the bulk of it into new
function `comedi_device_detach_locked()`.

Note that the refactor of `comedi_device_detach()` results in
`comedi_device_cancel_all()` now being called while `dev-&gt;attach_lock`
is write-locked, which wasn't the case previously, but that does not
matter.

Thanks to Jens Axboe for diagnosing the problem and co-developing this
patch.</Note>
    </Notes>
    <CVE>CVE-2025-38687</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

pNFS: Fix uninited ptr deref in block/scsi layout

The error occurs on the third attempt to encode extents. When function
ext_tree_prepare_commit() reallocates a larger buffer to retry encoding
extents, the "layoutupdate_pages" page array is initialized only after the
retry loop. But ext_tree_free_commitdata() is called on every iteration
and tries to put pages in the array, thus dereferencing uninitialized
pointers.

An additional problem is that there is no limit on the maximum possible
buffer_size. When there are too many extents, the client may create a
layoutcommit that is larger than the maximum possible RPC size accepted
by the server.

During testing, we observed two typical scenarios. First, one memory page
for extents is enough when we work with small files, append data to the
end of the file, or preallocate extents before writing. But when we fill
a new large file without preallocating, the number of extents can be huge,
and counting the number of written extents in ext_tree_encode_commit()
does not help much. Since this number increases even more between
unlocking and locking of ext_tree, the reallocated buffer may not be
large enough again and again.</Note>
    </Notes>
    <CVE>CVE-2025-38691</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: add cluster chain loop check for dir

An infinite loop may occur if the following conditions occur due to
file system corruption.

(1) Condition for exfat_count_dir_entries() to loop infinitely.
    - The cluster chain includes a loop.
    - There is no UNUSED entry in the cluster chain.

(2) Condition for exfat_create_upcase_table() to loop infinitely.
    - The cluster chain of the root directory includes a loop.
    - There are no UNUSED entry and up-case table entry in the cluster
      chain of the root directory.

(3) Condition for exfat_load_bitmap() to loop infinitely.
    - The cluster chain of the root directory includes a loop.
    - There are no UNUSED entry and bitmap entry in the cluster chain
      of the root directory.

(4) Condition for exfat_find_dir_entry() to loop infinitely.
    - The cluster chain includes a loop.
    - The unused directory entries were exhausted by some operation.

(5) Condition for exfat_check_dir_empty() to loop infinitely.
    - The cluster chain includes a loop.
    - The unused directory entries were exhausted by some operation.
    - All files and sub-directories under the directory are deleted.

This commit adds checks to break the above infinite loop.</Note>
    </Notes>
    <CVE>CVE-2025-38692</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: dvb-frontends: w7090p: fix null-ptr-deref in w7090p_tuner_write_serpar and w7090p_tuner_read_serpar

In w7090p_tuner_write_serpar, msg is controlled by user. When msg[0].buf is null and msg[0].len is zero, former checks on msg[0].buf would be passed. If accessing msg[0].buf[2] without sanity check, null pointer deref would happen. We add
check on msg[0].len to prevent crash.

Similar commit: commit 0ed554fd769a ("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")</Note>
    </Notes>
    <CVE>CVE-2025-38693</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: dvb-frontends: dib7090p: fix null-ptr-deref in dib7090p_rw_on_apb()

In dib7090p_rw_on_apb, msg is controlled by user. When msg[0].buf is null and
msg[0].len is zero, former checks on msg[0].buf would be passed. If accessing
msg[0].buf[2] without sanity check, null pointer deref would happen. We add
check on msg[0].len to prevent crash. Similar issue occurs when access
msg[1].buf[0] and msg[1].buf[1].

Similar commit: commit 0ed554fd769a ("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")</Note>
    </Notes>
    <CVE>CVE-2025-38694</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Check for hdwq null ptr when cleaning up lpfc_vport structure

If a call to lpfc_sli4_read_rev() from lpfc_sli4_hba_setup() fails, the
resultant cleanup routine lpfc_sli4_vport_delete_fcp_xri_aborted() may
occur before sli4_hba.hdwqs are allocated.  This may result in a null
pointer dereference when attempting to take the abts_io_buf_list_lock for
the first hardware queue.  Fix by adding a null ptr check on
phba-&gt;sli4_hba.hdwq and early return because this situation means there
must have been an error during port initialization.</Note>
    </Notes>
    <CVE>CVE-2025-38695</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: upper bound check of tree index in dbAllocAG

When computing the tree index in dbAllocAG, we never check if we are
out of bounds realative to the size of the stree.
This could happen in a scenario where the filesystem metadata are
corrupted.</Note>
    </Notes>
    <CVE>CVE-2025-38697</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: Regular file corruption check

The reproducer builds a corrupted file on disk with a negative i_size value.
Add a check when opening this file to avoid subsequent operation failures.</Note>
    </Notes>
    <CVE>CVE-2025-38698</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: bfa: Double-free fix

When the bfad_im_probe() function fails during initialization, the memory
pointed to by bfad-&gt;im is freed without setting bfad-&gt;im to NULL.

Subsequently, during driver uninstallation, when the state machine enters
the bfad_sm_stopping state and calls the bfad_im_probe_undo() function,
it attempts to free the memory pointed to by bfad-&gt;im again, thereby
triggering a double-free vulnerability.

Set bfad-&gt;im to NULL if probing fails.</Note>
    </Notes>
    <CVE>CVE-2025-38699</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: libiscsi: Initialize iscsi_conn-&gt;dd_data only if memory is allocated

In case of an ib_fast_reg_mr allocation failure during iSER setup, the
machine hits a panic because iscsi_conn-&gt;dd_data is initialized
unconditionally, even when no memory is allocated (dd_size == 0).  This
leads invalid pointer dereference during connection teardown.

Fix by setting iscsi_conn-&gt;dd_data only if memory is actually allocated.

Panic trace:
------------
 iser: iser_create_fastreg_desc: Failed to allocate ib_fast_reg_mr err=-12
 iser: iser_alloc_rx_descriptors: failed allocating rx descriptors / data buffers
 BUG: unable to handle page fault for address: fffffffffffffff8
 RIP: 0010:swake_up_locked.part.5+0xa/0x40
 Call Trace:
  complete+0x31/0x40
  iscsi_iser_conn_stop+0x88/0xb0 [ib_iser]
  iscsi_stop_conn+0x66/0xc0 [scsi_transport_iscsi]
  iscsi_if_stop_conn+0x14a/0x150 [scsi_transport_iscsi]
  iscsi_if_rx+0x1135/0x1834 [scsi_transport_iscsi]
  ? netlink_lookup+0x12f/0x1b0
  ? netlink_deliver_tap+0x2c/0x200
  netlink_unicast+0x1ab/0x280
  netlink_sendmsg+0x257/0x4f0
  ? _copy_from_user+0x29/0x60
  sock_sendmsg+0x5f/0x70</Note>
    </Notes>
    <CVE>CVE-2025-38700</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: do not BUG when INLINE_DATA_FL lacks system.data xattr

A syzbot fuzzed image triggered a BUG_ON in ext4_update_inline_data()
when an inode had the INLINE_DATA_FL flag set but was missing the
system.data extended attribute.

Since this can happen due to a maiciouly fuzzed file system, we
shouldn't BUG, but rather, report it as a corrupted file system.

Add similar replacements of BUG_ON with EXT4_ERROR_INODE() ii
ext4_create_inline_data() and ext4_inline_data_truncate().</Note>
    </Notes>
    <CVE>CVE-2025-38701</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 potential buffer overflow in do_register_framebuffer()

The current implementation may lead to buffer overflow when:
1.  Unregistration creates NULL gaps in registered_fb[]
2.  All array slots become occupied despite num_registered_fb &lt; FB_MAX
3.  The registration loop exceeds array bounds

Add boundary check to prevent registered_fb[FB_MAX] access.</Note>
    </Notes>
    <CVE>CVE-2025-38702</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix null pointer access

Writing a string without delimiters (' ', '\n', '\0') to the under
gpu_od/fan_ctrl sysfs or pp_power_profile_mode for the CUSTOM profile
will result in a null pointer dereference.</Note>
    </Notes>
    <CVE>CVE-2025-38705</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: core: Check for rtd == NULL in snd_soc_remove_pcm_runtime()

snd_soc_remove_pcm_runtime() might be called with rtd == NULL which will
leads to null pointer dereference.
This was reproduced with topology loading and marking a link as ignore
due to missing hardware component on the system.
On module removal the soc_tplg_remove_link() would call
snd_soc_remove_pcm_runtime() with rtd == NULL since the link was ignored,
no runtime was created.</Note>
    </Notes>
    <CVE>CVE-2025-38706</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

loop: Avoid updating block size under exclusive owner

Syzbot came up with a reproducer where a loop device block size is
changed underneath a mounted filesystem. This causes a mismatch between
the block device block size and the block size stored in the superblock
causing confusion in various places such as fs/buffer.c. The particular
issue triggered by syzbot was a warning in __getblk_slow() due to
requested buffer size not matching block device block size.

Fix the problem by getting exclusive hold of the loop device to change
its block size. This fails if somebody (such as filesystem) has already
an exclusive ownership of the block device and thus prevents modifying
the loop device under some exclusive owner which doesn't expect it.</Note>
    </Notes>
    <CVE>CVE-2025-38709</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hfsplus: don't use BUG_ON() in hfsplus_create_attributes_file()

When the volume header contains erroneous values that do not reflect
the actual state of the filesystem, hfsplus_fill_super() assumes that
the attributes file is not yet created, which later results in hitting
BUG_ON() when hfsplus_create_attributes_file() is called. Replace this
BUG_ON() with -EIO error with a message to suggest running fsck tool.</Note>
    </Notes>
    <CVE>CVE-2025-38712</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()

The hfsplus_readdir() method is capable to crash by calling
hfsplus_uni2asc():

[  667.121659][ T9805] ==================================================================
[  667.122651][ T9805] BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0x902/0xa10
[  667.123627][ T9805] Read of size 2 at addr ffff88802592f40c by task repro/9805
[  667.124578][ T9805]
[  667.124876][ T9805] CPU: 3 UID: 0 PID: 9805 Comm: repro Not tainted 6.16.0-rc3 #1 PREEMPT(full)
[  667.124886][ T9805] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[  667.124890][ T9805] Call Trace:
[  667.124893][ T9805]  &lt;TASK&gt;
[  667.124896][ T9805]  dump_stack_lvl+0x10e/0x1f0
[  667.124911][ T9805]  print_report+0xd0/0x660
[  667.124920][ T9805]  ? __virt_addr_valid+0x81/0x610
[  667.124928][ T9805]  ? __phys_addr+0xe8/0x180
[  667.124934][ T9805]  ? hfsplus_uni2asc+0x902/0xa10
[  667.124942][ T9805]  kasan_report+0xc6/0x100
[  667.124950][ T9805]  ? hfsplus_uni2asc+0x902/0xa10
[  667.124959][ T9805]  hfsplus_uni2asc+0x902/0xa10
[  667.124966][ T9805]  ? hfsplus_bnode_read+0x14b/0x360
[  667.124974][ T9805]  hfsplus_readdir+0x845/0xfc0
[  667.124984][ T9805]  ? __pfx_hfsplus_readdir+0x10/0x10
[  667.124994][ T9805]  ? stack_trace_save+0x8e/0xc0
[  667.125008][ T9805]  ? iterate_dir+0x18b/0xb20
[  667.125015][ T9805]  ? trace_lock_acquire+0x85/0xd0
[  667.125022][ T9805]  ? lock_acquire+0x30/0x80
[  667.125029][ T9805]  ? iterate_dir+0x18b/0xb20
[  667.125037][ T9805]  ? down_read_killable+0x1ed/0x4c0
[  667.125044][ T9805]  ? putname+0x154/0x1a0
[  667.125051][ T9805]  ? __pfx_down_read_killable+0x10/0x10
[  667.125058][ T9805]  ? apparmor_file_permission+0x239/0x3e0
[  667.125069][ T9805]  iterate_dir+0x296/0xb20
[  667.125076][ T9805]  __x64_sys_getdents64+0x13c/0x2c0
[  667.125084][ T9805]  ? __pfx___x64_sys_getdents64+0x10/0x10
[  667.125091][ T9805]  ? __x64_sys_openat+0x141/0x200
[  667.125126][ T9805]  ? __pfx_filldir64+0x10/0x10
[  667.125134][ T9805]  ? do_user_addr_fault+0x7fe/0x12f0
[  667.125143][ T9805]  do_syscall_64+0xc9/0x480
[  667.125151][ T9805]  entry_SYSCALL_64_after_hwframe+0x77/0x7f
[  667.125158][ T9805] RIP: 0033:0x7fa8753b2fc9
[  667.125164][ T9805] 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 48
[  667.125172][ T9805] RSP: 002b:00007ffe96f8e0f8 EFLAGS: 00000217 ORIG_RAX: 00000000000000d9
[  667.125181][ T9805] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa8753b2fc9
[  667.125185][ T9805] RDX: 0000000000000400 RSI: 00002000000063c0 RDI: 0000000000000004
[  667.125190][ T9805] RBP: 00007ffe96f8e110 R08: 00007ffe96f8e110 R09: 00007ffe96f8e110
[  667.125195][ T9805] R10: 0000000000000000 R11: 0000000000000217 R12: 0000556b1e3b4260
[  667.125199][ T9805] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[  667.125207][ T9805]  &lt;/TASK&gt;
[  667.125210][ T9805]
[  667.145632][ T9805] Allocated by task 9805:
[  667.145991][ T9805]  kasan_save_stack+0x20/0x40
[  667.146352][ T9805]  kasan_save_track+0x14/0x30
[  667.146717][ T9805]  __kasan_kmalloc+0xaa/0xb0
[  667.147065][ T9805]  __kmalloc_noprof+0x205/0x550
[  667.147448][ T9805]  hfsplus_find_init+0x95/0x1f0
[  667.147813][ T9805]  hfsplus_readdir+0x220/0xfc0
[  667.148174][ T9805]  iterate_dir+0x296/0xb20
[  667.148549][ T9805]  __x64_sys_getdents64+0x13c/0x2c0
[  667.148937][ T9805]  do_syscall_64+0xc9/0x480
[  667.149291][ T9805]  entry_SYSCALL_64_after_hwframe+0x77/0x7f
[  667.149809][ T9805]
[  667.150030][ T9805] The buggy address belongs to the object at ffff88802592f000
[  667.150030][ T9805]  which belongs to the cache kmalloc-2k of size 2048
[  667.151282][ T9805] The buggy address is located 0 bytes to the right of
[  667.151282][ T9805]  allocated 1036-byte region [ffff88802592f000, ffff88802592f40c)
[  667.1
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-38713</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hfsplus: fix slab-out-of-bounds in hfsplus_bnode_read()

The hfsplus_bnode_read() method can trigger the issue:

[  174.852007][ T9784] ==================================================================
[  174.852709][ T9784] BUG: KASAN: slab-out-of-bounds in hfsplus_bnode_read+0x2f4/0x360
[  174.853412][ T9784] Read of size 8 at addr ffff88810b5fc6c0 by task repro/9784
[  174.854059][ T9784]
[  174.854272][ T9784] CPU: 1 UID: 0 PID: 9784 Comm: repro Not tainted 6.16.0-rc3 #7 PREEMPT(full)
[  174.854281][ T9784] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[  174.854286][ T9784] Call Trace:
[  174.854289][ T9784]  &lt;TASK&gt;
[  174.854292][ T9784]  dump_stack_lvl+0x10e/0x1f0
[  174.854305][ T9784]  print_report+0xd0/0x660
[  174.854315][ T9784]  ? __virt_addr_valid+0x81/0x610
[  174.854323][ T9784]  ? __phys_addr+0xe8/0x180
[  174.854330][ T9784]  ? hfsplus_bnode_read+0x2f4/0x360
[  174.854337][ T9784]  kasan_report+0xc6/0x100
[  174.854346][ T9784]  ? hfsplus_bnode_read+0x2f4/0x360
[  174.854354][ T9784]  hfsplus_bnode_read+0x2f4/0x360
[  174.854362][ T9784]  hfsplus_bnode_dump+0x2ec/0x380
[  174.854370][ T9784]  ? __pfx_hfsplus_bnode_dump+0x10/0x10
[  174.854377][ T9784]  ? hfsplus_bnode_write_u16+0x83/0xb0
[  174.854385][ T9784]  ? srcu_gp_start+0xd0/0x310
[  174.854393][ T9784]  ? __mark_inode_dirty+0x29e/0xe40
[  174.854402][ T9784]  hfsplus_brec_remove+0x3d2/0x4e0
[  174.854411][ T9784]  __hfsplus_delete_attr+0x290/0x3a0
[  174.854419][ T9784]  ? __pfx_hfs_find_1st_rec_by_cnid+0x10/0x10
[  174.854427][ T9784]  ? __pfx___hfsplus_delete_attr+0x10/0x10
[  174.854436][ T9784]  ? __asan_memset+0x23/0x50
[  174.854450][ T9784]  hfsplus_delete_all_attrs+0x262/0x320
[  174.854459][ T9784]  ? __pfx_hfsplus_delete_all_attrs+0x10/0x10
[  174.854469][ T9784]  ? rcu_is_watching+0x12/0xc0
[  174.854476][ T9784]  ? __mark_inode_dirty+0x29e/0xe40
[  174.854483][ T9784]  hfsplus_delete_cat+0x845/0xde0
[  174.854493][ T9784]  ? __pfx_hfsplus_delete_cat+0x10/0x10
[  174.854507][ T9784]  hfsplus_unlink+0x1ca/0x7c0
[  174.854516][ T9784]  ? __pfx_hfsplus_unlink+0x10/0x10
[  174.854525][ T9784]  ? down_write+0x148/0x200
[  174.854532][ T9784]  ? __pfx_down_write+0x10/0x10
[  174.854540][ T9784]  vfs_unlink+0x2fe/0x9b0
[  174.854549][ T9784]  do_unlinkat+0x490/0x670
[  174.854557][ T9784]  ? __pfx_do_unlinkat+0x10/0x10
[  174.854565][ T9784]  ? __might_fault+0xbc/0x130
[  174.854576][ T9784]  ? getname_flags.part.0+0x1c5/0x550
[  174.854584][ T9784]  __x64_sys_unlink+0xc5/0x110
[  174.854592][ T9784]  do_syscall_64+0xc9/0x480
[  174.854600][ T9784]  entry_SYSCALL_64_after_hwframe+0x77/0x7f
[  174.854608][ T9784] RIP: 0033:0x7f6fdf4c3167
[  174.854614][ T9784] Code: f0 ff ff 73 01 c3 48 8b 0d 26 0d 0e 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 08
[  174.854622][ T9784] RSP: 002b:00007ffcb948bca8 EFLAGS: 00000206 ORIG_RAX: 0000000000000057
[  174.854630][ T9784] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f6fdf4c3167
[  174.854636][ T9784] RDX: 00007ffcb948bcc0 RSI: 00007ffcb948bcc0 RDI: 00007ffcb948bd50
[  174.854641][ T9784] RBP: 00007ffcb948cd90 R08: 0000000000000001 R09: 00007ffcb948bb40
[  174.854645][ T9784] R10: 00007f6fdf564fc0 R11: 0000000000000206 R12: 0000561e1bc9c2d0
[  174.854650][ T9784] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[  174.854658][ T9784]  &lt;/TASK&gt;
[  174.854661][ T9784]
[  174.879281][ T9784] Allocated by task 9784:
[  174.879664][ T9784]  kasan_save_stack+0x20/0x40
[  174.880082][ T9784]  kasan_save_track+0x14/0x30
[  174.880500][ T9784]  __kasan_kmalloc+0xaa/0xb0
[  174.880908][ T9784]  __kmalloc_noprof+0x205/0x550
[  174.881337][ T9784]  __hfs_bnode_create+0x107/0x890
[  174.881779][ T9784]  hfsplus_bnode_find+0x2d0/0xd10
[  174.882222][ T9784]  hfsplus_brec_find+0x2b0/0x520
[  174.882659][ T9784]  hfsplus_delete_all_attrs+0x23b/0x3
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-38714</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hfs: fix slab-out-of-bounds in hfs_bnode_read()

This patch introduces is_bnode_offset_valid() method that checks
the requested offset value. Also, it introduces
check_and_correct_requested_length() method that checks and
correct the requested length (if it is necessary). These methods
are used in hfs_bnode_read(), hfs_bnode_write(), hfs_bnode_clear(),
hfs_bnode_copy(), and hfs_bnode_move() with the goal to prevent
the access out of allocated memory and triggering the crash.</Note>
    </Notes>
    <CVE>CVE-2025-38715</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: linearize cloned gso packets in sctp_rcv

A cloned head skb still shares these frag skbs in fraglist with the
original head skb. It's not safe to access these frag skbs.

syzbot reported two use-of-uninitialized-memory bugs caused by this:

  BUG: KMSAN: uninit-value in sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211
   sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211
   sctp_assoc_bh_rcv+0x1a7/0xc50 net/sctp/associola.c:998
   sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88
   sctp_backlog_rcv+0x397/0xdb0 net/sctp/input.c:331
   sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1122
   __release_sock+0x1da/0x330 net/core/sock.c:3106
   release_sock+0x6b/0x250 net/core/sock.c:3660
   sctp_wait_for_connect+0x487/0x820 net/sctp/socket.c:9360
   sctp_sendmsg_to_asoc+0x1ec1/0x1f00 net/sctp/socket.c:1885
   sctp_sendmsg+0x32b9/0x4a80 net/sctp/socket.c:2031
   inet_sendmsg+0x25a/0x280 net/ipv4/af_inet.c:851
   sock_sendmsg_nosec net/socket.c:718 [inline]

and

  BUG: KMSAN: uninit-value in sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987
   sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987
   sctp_inq_push+0x2a3/0x350 net/sctp/inqueue.c:88
   sctp_backlog_rcv+0x3c7/0xda0 net/sctp/input.c:331
   sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148
   __release_sock+0x1d3/0x330 net/core/sock.c:3213
   release_sock+0x6b/0x270 net/core/sock.c:3767
   sctp_wait_for_connect+0x458/0x820 net/sctp/socket.c:9367
   sctp_sendmsg_to_asoc+0x223a/0x2260 net/sctp/socket.c:1886
   sctp_sendmsg+0x3910/0x49f0 net/sctp/socket.c:2032
   inet_sendmsg+0x269/0x2a0 net/ipv4/af_inet.c:851
   sock_sendmsg_nosec net/socket.c:712 [inline]

This patch fixes it by linearizing cloned gso packets in sctp_rcv().</Note>
    </Notes>
    <CVE>CVE-2025-38718</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ctnetlink: fix refcount leak on table dump

There is a reference count leak in ctnetlink_dump_table():
      if (res &lt; 0) {
                nf_conntrack_get(&amp;ct-&gt;ct_general); // HERE
                cb-&gt;args[1] = (unsigned long)ct;
                ...

While its very unlikely, its possible that ct == last.
If this happens, then the refcount of ct was already incremented.
This 2nd increment is never undone.

This prevents the conntrack object from being released, which in turn
keeps prevents cnet-&gt;count from dropping back to 0.

This will then block the netns dismantle (or conntrack rmmod) as
nf_conntrack_cleanup_net_list() will wait forever.

This can be reproduced by running conntrack_resize.sh selftest in a loop.
It takes ~20 minutes for me on a preemptible kernel on average before
I see a runaway kworker spinning in nf_conntrack_cleanup_net_list.

One fix would to change this to:
        if (res &lt; 0) {
		if (ct != last)
	                nf_conntrack_get(&amp;ct-&gt;ct_general);

But this reference counting isn't needed in the first place.
We can just store a cookie value instead.

A followup patch will do the same for ctnetlink_exp_dump_table,
it looks to me as if this has the same problem and like
ctnetlink_dump_table, we only need a 'skip hint', not the actual
object so we can apply the same cookie strategy there as well.</Note>
    </Notes>
    <CVE>CVE-2025-38721</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

habanalabs: fix UAF in export_dmabuf()

As soon as we'd inserted a file reference into descriptor table, another
thread could close it.  That's fine for the case when all we are doing is
returning that descriptor to userland (it's a race, but it's a userland
race and there's nothing the kernel can do about it).  However, if we
follow fd_install() with any kind of access to objects that would be
destroyed on close (be it the struct file itself or anything destroyed
by its -&gt;release()), we have a UAF.

dma_buf_fd() is a combination of reserving a descriptor and fd_install().
habanalabs export_dmabuf() calls it and then proceeds to access the
objects destroyed on close.  In particular, it grabs an extra reference to
another struct file that will be dropped as part of -&gt;release() for ours;
that "will be" is actually "might have already been".

Fix that by reserving descriptor before anything else and do fd_install()
only when everything had been set up.  As a side benefit, we no longer
have the failure exit with file already created, but reference to
underlying file (as well as -&gt;dmabuf_export_cnt, etc.) not grabbed yet;
unlike dma_buf_fd(), fd_install() can't fail.</Note>
    </Notes>
    <CVE>CVE-2025-38722</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: handle get_client_locked() failure in nfsd4_setclientid_confirm()

Lei Lu recently reported that nfsd4_setclientid_confirm() did not check
the return value from get_client_locked(). a SETCLIENTID_CONFIRM could
race with a confirmed client expiring and fail to get a reference. That
could later lead to a UAF.

Fix this by getting a reference early in the case where there is an
extant confirmed client. If that fails then treat it as if there were no
confirmed client found at all.

In the case where the unconfirmed client is expiring, just fail and
return the result from get_client_locked().</Note>
    </Notes>
    <CVE>CVE-2025-38724</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: asix_devices: add phy_mask for ax88772 mdio bus

Without setting phy_mask for ax88772 mdio bus, current driver may create
at most 32 mdio phy devices with phy address range from 0x00 ~ 0x1f.
DLink DUB-E100 H/W Ver B1 is such a device. However, only one main phy
device will bind to net phy driver. This is creating issue during system
suspend/resume since phy_polling_mode() in phy_state_machine() will
directly deference member of phydev-&gt;drv for non-main phy devices. Then
NULL pointer dereference issue will occur. Due to only external phy or
internal phy is necessary, add phy_mask for ax88772 mdio bus to workarnoud
the issue.</Note>
    </Notes>
    <CVE>CVE-2025-38725</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Validate UAC3 power domain descriptors, too

UAC3 power domain descriptors need to be verified with its variable
bLength for avoiding the unexpected OOB accesses by malicious
firmware, too.</Note>
    </Notes>
    <CVE>CVE-2025-38729</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/net: commit partial buffers on retry

Ring provided buffers are potentially only valid within the single
execution context in which they were acquired. io_uring deals with this
and invalidates them on retry. But on the networking side, if
MSG_WAITALL is set, or if the socket is of the streaming type and too
little was processed, then it will hang on to the buffer rather than
recycle or commit it. This is problematic for two reasons:

1) If someone unregisters the provided buffer ring before a later retry,
   then the req-&gt;buf_list will no longer be valid.

2) If multiple sockers are using the same buffer group, then multiple
   receives can consume the same memory. This can cause data corruption
   in the application, as either receive could land in the same
   userspace buffer.

Fix this by disallowing partial retries from pinning a provided buffer
across multiple executions, if ring provided buffers are used.</Note>
    </Notes>
    <CVE>CVE-2025-38730</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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_reject: don't leak dst refcount for loopback packets

recent patches to add a WARN() when replacing skb dst entry found an
old bug:

WARNING: include/linux/skbuff.h:1165 skb_dst_check_unset include/linux/skbuff.h:1164 [inline]
WARNING: include/linux/skbuff.h:1165 skb_dst_set include/linux/skbuff.h:1210 [inline]
WARNING: include/linux/skbuff.h:1165 nf_reject_fill_skb_dst+0x2a4/0x330 net/ipv4/netfilter/nf_reject_ipv4.c:234
[..]
Call Trace:
 nf_send_unreach+0x17b/0x6e0 net/ipv4/netfilter/nf_reject_ipv4.c:325
 nft_reject_inet_eval+0x4bc/0x690 net/netfilter/nft_reject_inet.c:27
 expr_call_ops_eval net/netfilter/nf_tables_core.c:237 [inline]
 ..

This is because blamed commit forgot about loopback packets.
Such packets already have a dst_entry attached, even at PRE_ROUTING stage.

Instead of checking hook just check if the skb already has a route
attached to it.</Note>
    </Notes>
    <CVE>CVE-2025-38732</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 UAF on smcsk after smc_listen_out()

BPF CI testing report a UAF issue:

  [   16.446633] BUG: kernel NULL pointer dereference, address: 000000000000003  0
  [   16.447134] #PF: supervisor read access in kernel mod  e
  [   16.447516] #PF: error_code(0x0000) - not-present pag  e
  [   16.447878] PGD 0 P4D   0
  [   16.448063] Oops: Oops: 0000 [#1] PREEMPT SMP NOPT  I
  [   16.448409] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Tainted: G           OE      6.13.0-rc3-g89e8a75fda73-dirty #4  2
  [   16.449124] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODUL  E
  [   16.449502] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/201  4
  [   16.450201] Workqueue: smc_hs_wq smc_listen_wor  k
  [   16.450531] RIP: 0010:smc_listen_work+0xc02/0x159  0
  [   16.452158] RSP: 0018:ffffb5ab40053d98 EFLAGS: 0001024  6
  [   16.452526] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 000000000000030  0
  [   16.452994] RDX: 0000000000000280 RSI: 00003513840053f0 RDI: 000000000000000  0
  [   16.453492] RBP: ffffa097808e3800 R08: ffffa09782dba1e0 R09: 000000000000000  5
  [   16.453987] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa0978274640  0
  [   16.454497] R13: 0000000000000000 R14: 0000000000000000 R15: ffffa09782d4092  0
  [   16.454996] FS:  0000000000000000(0000) GS:ffffa097bbc00000(0000) knlGS:000000000000000  0
  [   16.455557] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003  3
  [   16.455961] CR2: 0000000000000030 CR3: 0000000102788004 CR4: 0000000000770ef  0
  [   16.456459] PKRU: 5555555  4
  [   16.456654] Call Trace  :
  [   16.456832]  &lt;TASK  &gt;
  [   16.456989]  ? __die+0x23/0x7  0
  [   16.457215]  ? page_fault_oops+0x180/0x4c  0
  [   16.457508]  ? __lock_acquire+0x3e6/0x249  0
  [   16.457801]  ? exc_page_fault+0x68/0x20  0
  [   16.458080]  ? asm_exc_page_fault+0x26/0x3  0
  [   16.458389]  ? smc_listen_work+0xc02/0x159  0
  [   16.458689]  ? smc_listen_work+0xc02/0x159  0
  [   16.458987]  ? lock_is_held_type+0x8f/0x10  0
  [   16.459284]  process_one_work+0x1ea/0x6d  0
  [   16.459570]  worker_thread+0x1c3/0x38  0
  [   16.459839]  ? __pfx_worker_thread+0x10/0x1  0
  [   16.460144]  kthread+0xe0/0x11  0
  [   16.460372]  ? __pfx_kthread+0x10/0x1  0
  [   16.460640]  ret_from_fork+0x31/0x5  0
  [   16.460896]  ? __pfx_kthread+0x10/0x1  0
  [   16.461166]  ret_from_fork_asm+0x1a/0x3  0
  [   16.461453]  &lt;/TASK  &gt;
  [   16.461616] Modules linked in: bpf_testmod(OE) [last unloaded: bpf_testmod(OE)  ]
  [   16.462134] CR2: 000000000000003  0
  [   16.462380] ---[ end trace 0000000000000000 ]---
  [   16.462710] RIP: 0010:smc_listen_work+0xc02/0x1590

The direct cause of this issue is that after smc_listen_out_connected(),
newclcsock-&gt;sk may be NULL since it will releases the smcsk. Therefore,
if the application closes the socket immediately after accept,
newclcsock-&gt;sk can be NULL. A possible execution order could be as
follows:

smc_listen_work                                 | userspace
-----------------------------------------------------------------
lock_sock(sk)                                   |
smc_listen_out_connected()                      |
| \- smc_listen_out                             |
|    | \- release_sock                          |
     | |- sk-&gt;sk_data_ready()                   |
                                                | fd = accept();
                                                | close(fd);
                                                |  \- socket-&gt;sk = NULL;
/* newclcsock-&gt;sk is NULL now */
SMC_STAT_SERV_SUCC_INC(sock_net(newclcsock-&gt;sk))

Since smc_listen_out_connected() will not fail, simply swapping the order
of the code can easily fix this issue.</Note>
    </Notes>
    <CVE>CVE-2025-38734</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: prevent ethtool ops after shutdown

A crash can occur if an ethtool operation is invoked
after shutdown() is called.

shutdown() is invoked during system shutdown to stop DMA operations
without performing expensive deallocations. It is discouraged to
unregister the netdev in this path, so the device may still be visible
to userspace and kernel helpers.

In gve, shutdown() tears down most internal data structures. If an
ethtool operation is dispatched after shutdown(), it will dereference
freed or NULL pointers, leading to a kernel panic. While graceful
shutdown normally quiesces userspace before invoking the reboot
syscall, forced shutdowns (as observed on GCP VMs) can still trigger
this path.

Fix by calling netif_device_detach() in shutdown().
This marks the device as detached so the ethtool ioctl handler
will skip dispatching operations to the driver.</Note>
    </Notes>
    <CVE>CVE-2025-38735</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: asix_devices: Fix PHY address mask in MDIO bus initialization

Syzbot reported shift-out-of-bounds exception on MDIO bus initialization.

The PHY address should be masked to 5 bits (0-31). Without this
mask, invalid PHY addresses could be used, potentially causing issues
with MDIO bus operations.

Fix this by masking the PHY address with 0x1f (31 decimal) to ensure
it stays within the valid range.</Note>
    </Notes>
    <CVE>CVE-2025-38736</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ppp: fix race conditions in ppp_fill_forward_path

ppp_fill_forward_path() has two race conditions:

1. The ppp-&gt;channels list can change between list_empty() and
   list_first_entry(), as ppp_lock() is not held. If the only channel
   is deleted in ppp_disconnect_channel(), list_first_entry() may
   access an empty head or a freed entry, and trigger a panic.

2. pch-&gt;chan can be NULL. When ppp_unregister_channel() is called,
   pch-&gt;chan is set to NULL before pch is removed from ppp-&gt;channels.

Fix these by using a lockless RCU approach:
- Use list_first_or_null_rcu() to safely test and access the first list
  entry.
- Convert list modifications on ppp-&gt;channels to their RCU variants and
  add synchronize_net() after removal.
- Check for a NULL pch-&gt;chan before dereferencing it.</Note>
    </Notes>
    <CVE>CVE-2025-39673</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 in mod_hdcp_hdcp1_create_session()

The function mod_hdcp_hdcp1_create_session() 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.

Add a null pointer check for get_first_active_display() and return
MOD_HDCP_STATUS_DISPLAY_NOT_FOUND if the function return null.

This is similar to the commit c3e9826a2202
("drm/amd/display: Add null pointer check for get_first_active_display()").

(cherry picked from commit 5e43eb3cd731649c4f8b9134f857be62a416c893)</Note>
    </Notes>
    <CVE>CVE-2025-39675</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: qla4xxx: Prevent a potential error pointer dereference

The qla4xxx_get_ep_fwdb() function is supposed to return NULL on error,
but qla4xxx_ep_connect() returns error pointers.  Propagating the error
pointers will lead to an Oops in the caller, so change the error pointers
to NULL.</Note>
    </Notes>
    <CVE>CVE-2025-39676</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 backlog accounting in qdisc_dequeue_internal

This issue applies for the following qdiscs: hhf, fq, fq_codel, and
fq_pie, and occurs in their change handlers when adjusting to the new
limit. The problem is the following in the values passed to the
subsequent qdisc_tree_reduce_backlog call given a tbf parent:

   When the tbf parent runs out of tokens, skbs of these qdiscs will
   be placed in gso_skb. Their peek handlers are qdisc_peek_dequeued,
   which accounts for both qlen and backlog. However, in the case of
   qdisc_dequeue_internal, ONLY qlen is accounted for when pulling
   from gso_skb. This means that these qdiscs are missing a
   qdisc_qstats_backlog_dec when dropping packets to satisfy the
   new limit in their change handlers.

   One can observe this issue with the following (with tc patched to
   support a limit of 0):

   export TARGET=fq
   tc qdisc del dev lo root
   tc qdisc add dev lo root handle 1: tbf rate 8bit burst 100b latency 1ms
   tc qdisc replace dev lo handle 3: parent 1:1 $TARGET limit 1000
   echo ''; echo 'add child'; tc -s -d qdisc show dev lo
   ping -I lo -f -c2 -s32 -W0.001 127.0.0.1 2&gt;&amp;1 &gt;/dev/null
   echo ''; echo 'after ping'; tc -s -d qdisc show dev lo
   tc qdisc change dev lo handle 3: parent 1:1 $TARGET limit 0
   echo ''; echo 'after limit drop'; tc -s -d qdisc show dev lo
   tc qdisc replace dev lo handle 2: parent 1:1 sfq
   echo ''; echo 'post graft'; tc -s -d qdisc show dev lo

   The second to last show command shows 0 packets but a positive
   number (74) of backlog bytes. The problem becomes clearer in the
   last show command, where qdisc_purge_queue triggers
   qdisc_tree_reduce_backlog with the positive backlog and causes an
   underflow in the tbf parent's backlog (4096 Mb instead of 0).

To fix this issue, the codepath for all clients of qdisc_dequeue_internal
has been simplified: codel, pie, hhf, fq, fq_pie, and fq_codel.
qdisc_dequeue_internal handles the backlog adjustments for all cases that
do not directly use the dequeue handler.

The old fq_codel_change limit adjustment loop accumulated the arguments to
the subsequent qdisc_tree_reduce_backlog call through the cstats field.
However, this is confusing and error prone as fq_codel_dequeue could also
potentially mutate this field (which qdisc_dequeue_internal calls in the
non gso_skb case), so we have unified the code here with other qdiscs.</Note>
    </Notes>
    <CVE>CVE-2025-39677</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/amd/hsmp: Ensure sock-&gt;metric_tbl_addr is non-NULL

If metric table address is not allocated, accessing metrics_bin will
result in a NULL pointer dereference, so add a check.</Note>
    </Notes>
    <CVE>CVE-2025-39678</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/nvif: Fix potential memory leak in nvif_vmm_ctor().

When the nvif_vmm_type is invalid, we will return error directly
without freeing the args in nvif_vmm_ctor(), which leading a memory
leak. Fix it by setting the ret -EINVAL and goto done.</Note>
    </Notes>
    <CVE>CVE-2025-39679</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/cpu/hygon: Add missing resctrl_cpu_detect() in bsp_init helper

Since

  923f3a2b48bd ("x86/resctrl: Query LLC monitoring properties once during boot")

resctrl_cpu_detect() has been moved from common CPU initialization code to
the vendor-specific BSP init helper, while Hygon didn't put that call in their
code.

This triggers a division by zero fault during early booting stage on our
machines with X86_FEATURE_CQM* supported, where get_rdt_mon_resources() tries
to calculate mon_l3_config with uninitialized boot_cpu_data.x86_cache_occ_scale.

Add the missing resctrl_cpu_detect() in the Hygon BSP init helper.

  [ bp: Massage commit message. ]</Note>
    </Notes>
    <CVE>CVE-2025-39681</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix handling of zero-length records on the rx_list

Each recvmsg() call must process either
 - only contiguous DATA records (any number of them)
 - one non-DATA record

If the next record has different type than what has already been
processed we break out of the main processing loop. If the record
has already been decrypted (which may be the case for TLS 1.3 where
we don't know type until decryption) we queue the pending record
to the rx_list. Next recvmsg() will pick it up from there.

Queuing the skb to rx_list after zero-copy decrypt is not possible,
since in that case we decrypted directly to the user space buffer,
and we don't have an skb to queue (darg.skb points to the ciphertext
skb for access to metadata like length).

Only data records are allowed zero-copy, and we break the processing
loop after each non-data record. So we should never zero-copy and
then find out that the record type has changed. The corner case
we missed is when the initial record comes from rx_list, and it's
zero length.</Note>
    </Notes>
    <CVE>CVE-2025-39682</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: Limit access to parser-&gt;buffer when trace_get_user failed

When the length of the string written to set_ftrace_filter exceeds
FTRACE_BUFF_MAX, the following KASAN alarm will be triggered:

BUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0
Read of size 1 at addr ffff0000d00bd5ba by task ash/165

CPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirty
Hardware name: linux,dummy-virt (DT)
Call trace:
 show_stack+0x34/0x50 (C)
 dump_stack_lvl+0xa0/0x158
 print_address_description.constprop.0+0x88/0x398
 print_report+0xb0/0x280
 kasan_report+0xa4/0xf0
 __asan_report_load1_noabort+0x20/0x30
 strsep+0x18c/0x1b0
 ftrace_process_regex.isra.0+0x100/0x2d8
 ftrace_regex_release+0x484/0x618
 __fput+0x364/0xa58
 ____fput+0x28/0x40
 task_work_run+0x154/0x278
 do_notify_resume+0x1f0/0x220
 el0_svc+0xec/0xf0
 el0t_64_sync_handler+0xa0/0xe8
 el0t_64_sync+0x1ac/0x1b0

The reason is that trace_get_user will fail when processing a string
longer than FTRACE_BUFF_MAX, but not set the end of parser-&gt;buffer to 0.
Then an OOB access will be triggered in ftrace_regex_release-&gt;
ftrace_process_regex-&gt;strsep-&gt;strpbrk. We can solve this problem by
limiting access to parser-&gt;buffer when trace_get_user failed.</Note>
    </Notes>
    <CVE>CVE-2025-39683</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 memory in do_insn_ioctl() and do_insnlist_ioctl()

syzbot reports a KMSAN kernel-infoleak in `do_insn_ioctl()`.  A kernel
buffer is allocated to hold `insn-&gt;n` samples (each of which is an
`unsigned int`).  For some instruction types, `insn-&gt;n` samples are
copied back to user-space, unless an error code is being returned.  The
problem is that not all the instruction handlers that need to return
data to userspace fill in the whole `insn-&gt;n` samples, so that there is
an information leak.  There is a similar syzbot report for
`do_insnlist_ioctl()`, although it does not have a reproducer for it at
the time of writing.

One culprit is `insn_rw_emulate_bits()` which is used as the handler for
`INSN_READ` or `INSN_WRITE` instructions for subdevices that do not have
a specific handler for that instruction, but do have an `INSN_BITS`
handler.  For `INSN_READ` it only fills in at most 1 sample, so if
`insn-&gt;n` is greater than 1, the remaining `insn-&gt;n - 1` samples copied
to userspace will be uninitialized kernel data.

Another culprit is `vm80xx_ai_insn_read()` in the "vm80xx" driver.  It
never returns an error, even if it fails to fill the buffer.

Fix it in `do_insn_ioctl()` and `do_insnlist_ioctl()` by making sure
that uninitialized parts of the allocated buffer are zeroed before
handling each instruction.

Thanks to Arnaud Lecomte for their fix to `do_insn_ioctl()`.  That fix
replaced the call to `kmalloc_array()` with `kcalloc()`, but it is not
always necessary to clear the whole buffer.</Note>
    </Notes>
    <CVE>CVE-2025-39684</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: pcl726: Prevent invalid irq number

The reproducer passed in an irq number(0x80008000) that was too large,
which triggered the oob.

Added an interrupt number check to prevent users from passing in an irq
number that was too large.

If `it-&gt;options[1]` is 31, then `1 &lt;&lt; it-&gt;options[1]` is still invalid
because it shifts a 1-bit into the sign bit (which is UB in C).
Possible solutions include reducing the upper bound on the
`it-&gt;options[1]` value to 30 or lower, or using `1U &lt;&lt; it-&gt;options[1]`.

The old code would just not attempt to request the IRQ if the
`options[1]` value were invalid.  And it would still configure the
device without interrupts even if the call to `request_irq` returned an
error.  So it would be better to combine this test with the test below.</Note>
    </Notes>
    <CVE>CVE-2025-39685</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Make insn_rw_emulate_bits() do insn-&gt;n samples

The `insn_rw_emulate_bits()` function is used as a default handler for
`INSN_READ` instructions for subdevices that have a handler for
`INSN_BITS` but not for `INSN_READ`.  Similarly, it is used as a default
handler for `INSN_WRITE` instructions for subdevices that have a handler
for `INSN_BITS` but not for `INSN_WRITE`. It works by emulating the
`INSN_READ` or `INSN_WRITE` instruction handling with a constructed
`INSN_BITS` instruction.  However, `INSN_READ` and `INSN_WRITE`
instructions are supposed to be able read or write multiple samples,
indicated by the `insn-&gt;n` value, but `insn_rw_emulate_bits()` currently
only handles a single sample.  For `INSN_READ`, the comedi core will
copy `insn-&gt;n` samples back to user-space.  (That triggered KASAN
kernel-infoleak errors when `insn-&gt;n` was greater than 1, but that is
being fixed more generally elsewhere in the comedi core.)

Make `insn_rw_emulate_bits()` either handle `insn-&gt;n` samples, or return
an error, to conform to the general expectation for `INSN_READ` and
`INSN_WRITE` handlers.</Note>
    </Notes>
    <CVE>CVE-2025-39686</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/buffer: fix use-after-free when call bh_read() helper

There's issue as follows:
BUG: KASAN: stack-out-of-bounds in end_buffer_read_sync+0xe3/0x110
Read of size 8 at addr ffffc9000168f7f8 by task swapper/3/0
CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.16.0-862.14.0.6.x86_64
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
Call Trace:
 &lt;IRQ&gt;
 dump_stack_lvl+0x55/0x70
 print_address_description.constprop.0+0x2c/0x390
 print_report+0xb4/0x270
 kasan_report+0xb8/0xf0
 end_buffer_read_sync+0xe3/0x110
 end_bio_bh_io_sync+0x56/0x80
 blk_update_request+0x30a/0x720
 scsi_end_request+0x51/0x2b0
 scsi_io_completion+0xe3/0x480
 ? scsi_device_unbusy+0x11e/0x160
 blk_complete_reqs+0x7b/0x90
 handle_softirqs+0xef/0x370
 irq_exit_rcu+0xa5/0xd0
 sysvec_apic_timer_interrupt+0x6e/0x90
 &lt;/IRQ&gt;

 Above issue happens when do ntfs3 filesystem mount, issue may happens
 as follows:
           mount                            IRQ
ntfs_fill_super
  read_cache_page
    do_read_cache_folio
      filemap_read_folio
        mpage_read_folio
	 do_mpage_readpage
	  ntfs_get_block_vbo
	   bh_read
	     submit_bh
	     wait_on_buffer(bh);
	                            blk_complete_reqs
				     scsi_io_completion
				      scsi_end_request
				       blk_update_request
				        end_bio_bh_io_sync
					 end_buffer_read_sync
					  __end_buffer_read_notouch
					   unlock_buffer

            wait_on_buffer(bh);--&gt; return will return to caller

					  put_bh
					    --&gt; trigger stack-out-of-bounds
In the mpage_read_folio() function, the stack variable 'map_bh' is
passed to ntfs_get_block_vbo(). Once unlock_buffer() unlocks and
wait_on_buffer() returns to continue processing, the stack variable
is likely to be reclaimed. Consequently, during the end_buffer_read_sync()
process, calling put_bh() may result in stack overrun.

If the bh is not allocated on the stack, it belongs to a folio.  Freeing
a buffer head which belongs to a folio is done by drop_buffers() which
will fail to free buffers which are still locked.  So it is safe to call
put_bh() before __end_buffer_read_notouch().</Note>
    </Notes>
    <CVE>CVE-2025-39691</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Avoid a NULL pointer dereference

[WHY]
Although unlikely drm_atomic_get_new_connector_state() or
drm_atomic_get_old_connector_state() can return NULL.

[HOW]
Check returns before dereference.

(cherry picked from commit 1e5e8d672fec9f2ab352be121be971877bff2af9)</Note>
    </Notes>
    <CVE>CVE-2025-39693</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/sclp: Fix SCCB present check

Tracing code called by the SCLP interrupt handler contains early exits
if the SCCB address associated with an interrupt is NULL. This check is
performed after physical to virtual address translation.

If the kernel identity mapping does not start at address zero, the
resulting virtual address is never zero, so that the NULL checks won't
work. Subsequently this may result in incorrect accesses to the first
page of the identity mapping.

Fix this by introducing a function that handles the NULL case before
address translation.</Note>
    </Notes>
    <CVE>CVE-2025-39694</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix a race when updating an existing write

After nfs_lock_and_join_requests() tests for whether the request is
still attached to the mapping, nothing prevents a call to
nfs_inode_remove_request() from succeeding until we actually lock the
page group.
The reason is that whoever called nfs_inode_remove_request() doesn't
necessarily have a lock on the page group head.

So in order to avoid races, let's take the page group lock earlier in
nfs_lock_and_join_requests(), and hold it across the removal of the
request in nfs_inode_remove_request().</Note>
    </Notes>
    <CVE>CVE-2025-39697</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: pfr_update: Fix the driver update version check

The security-version-number check should be used rather
than the runtime version check for driver updates.

Otherwise, the firmware update would fail when the update binary had
a lower runtime version number than the current one.

[ rjw: Changelog edits ]</Note>
    </Notes>
    <CVE>CVE-2025-39701</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: sr: Fix MAC comparison to be constant-time

To prevent timing attacks, MACs need to be compared in constant time.
Use the appropriate helper function for this.</Note>
    </Notes>
    <CVE>CVE-2025-39702</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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, hsr: reject HSR frame if skb can't hold tag

Receiving HSR frame with insufficient space to hold HSR tag in the skb
can result in a crash (kernel BUG):

[   45.390915] skbuff: skb_under_panic: text:ffffffff86f32cac len:26 put:14 head:ffff888042418000 data:ffff888042417ff4 tail:0xe end:0x180 dev:bridge_slave_1
[   45.392559] ------------[ cut here ]------------
[   45.392912] kernel BUG at net/core/skbuff.c:211!
[   45.393276] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI
[   45.393809] CPU: 1 UID: 0 PID: 2496 Comm: reproducer Not tainted 6.15.0 #12 PREEMPT(undef)
[   45.394433] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
[   45.395273] RIP: 0010:skb_panic+0x15b/0x1d0

&lt;snip registers, remove unreliable trace&gt;

[   45.402911] Call Trace:
[   45.403105]  &lt;IRQ&gt;
[   45.404470]  skb_push+0xcd/0xf0
[   45.404726]  br_dev_queue_push_xmit+0x7c/0x6c0
[   45.406513]  br_forward_finish+0x128/0x260
[   45.408483]  __br_forward+0x42d/0x590
[   45.409464]  maybe_deliver+0x2eb/0x420
[   45.409763]  br_flood+0x174/0x4a0
[   45.410030]  br_handle_frame_finish+0xc7c/0x1bc0
[   45.411618]  br_handle_frame+0xac3/0x1230
[   45.413674]  __netif_receive_skb_core.constprop.0+0x808/0x3df0
[   45.422966]  __netif_receive_skb_one_core+0xb4/0x1f0
[   45.424478]  __netif_receive_skb+0x22/0x170
[   45.424806]  process_backlog+0x242/0x6d0
[   45.425116]  __napi_poll+0xbb/0x630
[   45.425394]  net_rx_action+0x4d1/0xcc0
[   45.427613]  handle_softirqs+0x1a4/0x580
[   45.427926]  do_softirq+0x74/0x90
[   45.428196]  &lt;/IRQ&gt;

This issue was found by syzkaller.

The panic happens in br_dev_queue_push_xmit() once it receives a
corrupted skb with ETH header already pushed in linear data. When it
attempts the skb_push() call, there's not enough headroom and
skb_push() panics.

The corrupted skb is put on the queue by HSR layer, which makes a
sequence of unintended transformations when it receives a specific
corrupted HSR frame (with incomplete TAG).

Fix it by dropping and consuming frames that are not long enough to
contain both ethernet and hsr headers.

Alternative fix would be to check for enough headroom before skb_push()
in br_dev_queue_push_xmit().

In the reproducer, this is injected via AF_PACKET, but I don't easily
see why it couldn't be sent over the wire from adjacent network.

Further Details:

In the reproducer, the following network interface chain is set up:

 ────────────────┐    ────────────────┐
| veth0_to_hsr   ├───┤  hsr_slave0    ┼───┐
 ────────────────┘    ────────────────┘   |
                                          |  ──────┐
                                          ├─┤ hsr0 ├───┐
                                          |  ──────┘   |
 ────────────────┐    ────────────────┐   |            | ────────┐
| veth1_to_hsr   ┼───┤  hsr_slave1    ├───┘             ┤        |
 ────────────────┘    ────────────────┘                 ┼ bridge |
                                                       ||        |
                                                       | ────────┘
                                                       |
                                         ───────┐      |
                                        |  ...  ├──────┘
                                         ───────┘

To trigger the events leading up to crash, reproducer sends a corrupted
HSR fr
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-39703</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 a Null pointer dereference vulnerability

[Why]
A null pointer dereference vulnerability exists in the AMD display driver's
(DC module) cleanup function dc_destruct().
When display control context (dc-&gt;ctx) construction fails
(due to memory allocation failure), this pointer remains NULL.
During subsequent error handling when dc_destruct() is called,
there's no NULL check before dereferencing the perf_trace member
(dc-&gt;ctx-&gt;perf_trace), causing a kernel null pointer dereference crash.

[How]
Check if dc-&gt;ctx is non-NULL before dereferencing.

(Updated commit text and removed unnecessary error message)
(cherry picked from commit 9dd8e2ba268c636c240a918e0a31e6feaee19404)</Note>
    </Notes>
    <CVE>CVE-2025-39705</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Destroy KFD debugfs after destroy KFD wq

Since KFD proc content was moved to kernel debugfs, we can't destroy KFD
debugfs before kfd_process_destroy_wq. Move kfd_process_destroy_wq prior
to kfd_debugfs_fini to fix a kernel NULL pointer problem. It happens
when /sys/kernel/debug/kfd was already destroyed in kfd_debugfs_fini but
kfd_process_destroy_wq calls kfd_debugfs_remove_process. This line
    debugfs_remove_recursive(entry-&gt;proc_dentry);
tries to remove /sys/kernel/debug/kfd/proc/&lt;pid&gt; while
/sys/kernel/debug/kfd is already gone. It hangs the kernel by kernel
NULL pointer.

(cherry picked from commit 0333052d90683d88531558dcfdbf2525cc37c233)</Note>
    </Notes>
    <CVE>CVE-2025-39706</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: protect against spurious interrupts during probe

Make sure the interrupt handler is initialized before the interrupt is
registered.

If the IRQ is registered before hfi_create(), it's possible that an
interrupt fires before the handler setup is complete, leading to a NULL
dereference.

This error condition has been observed during system boot on Rb3Gen2.</Note>
    </Notes>
    <CVE>CVE-2025-39709</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Add a check for packet size after reading from shared memory

Add a check to ensure that the packet size does not exceed the number of
available words after reading the packet header from shared memory. This
ensures that the size provided by the firmware is safe to process and
prevent potential out-of-bounds memory access.</Note>
    </Notes>
    <CVE>CVE-2025-39710</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: rainshadow-cec: fix TOCTOU race condition in rain_interrupt()

In the interrupt handler rain_interrupt(), the buffer full check on
rain-&gt;buf_len is performed before acquiring rain-&gt;buf_lock. This
creates a Time-of-Check to Time-of-Use (TOCTOU) race condition, as
rain-&gt;buf_len is concurrently accessed and modified in the work
handler rain_irq_work_handler() under the same lock.

Multiple interrupt invocations can race, with each reading buf_len
before it becomes full and then proceeding. This can lead to both
interrupts attempting to write to the buffer, incrementing buf_len
beyond its capacity (DATA_SIZE) and causing a buffer overflow.

Fix this bug by moving the spin_lock() to before the buffer full
check. This ensures that the check and the subsequent buffer modification
are performed atomically, preventing the race condition. An corresponding
spin_unlock() is added to the overflow path to correctly release the
lock.

This possible bug was found by an experimental static analysis tool
developed by our team.</Note>
    </Notes>
    <CVE>CVE-2025-39713</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: usbtv: Lock resolution while streaming

When an program is streaming (ffplay) and another program (qv4l2)
changes the TV standard from NTSC to PAL, the kernel crashes due to trying
to copy to unmapped memory.

Changing from NTSC to PAL increases the resolution in the usbtv struct,
but the video plane buffer isn't adjusted, so it overflows.

[hverkuil: call vb2_is_busy instead of vb2_is_streaming]</Note>
    </Notes>
    <CVE>CVE-2025-39714</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/virtio: Validate length in packet header before skb_put()

When receiving a vsock packet in the guest, only the virtqueue buffer
size is validated prior to virtio_vsock_skb_rx_put(). Unfortunately,
virtio_vsock_skb_rx_put() uses the length from the packet header as the
length argument to skb_put(), potentially resulting in SKB overflow if
the host has gone wonky.

Validate the length as advertised by the packet header before calling
virtio_vsock_skb_rx_put().</Note>
    </Notes>
    <CVE>CVE-2025-39718</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: bno055: fix OOB access of hw_xlate array

Fix a potential out-of-bounds array access of the hw_xlate array in
bno055.c.

In bno055_get_regmask(), hw_xlate was iterated over the length of the
vals array instead of the length of the hw_xlate array. In the case of
bno055_gyr_scale, the vals array is larger than the hw_xlate array,
so this could result in an out-of-bounds access. In practice, this
shouldn't happen though because a match should always be found which
breaks out of the for loop before it iterates beyond the end of the
hw_xlate array.

By adding a new hw_xlate_len field to the bno055_sysfs_attr, we can be
sure we are iterating over the correct length.</Note>
    </Notes>
    <CVE>CVE-2025-39719</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: qat - flush misc workqueue during device shutdown

Repeated loading and unloading of a device specific QAT driver, for
example qat_4xxx, in a tight loop can lead to a crash due to a
use-after-free scenario. This occurs when a power management (PM)
interrupt triggers just before the device-specific driver (e.g.,
qat_4xxx.ko) is unloaded, while the core driver (intel_qat.ko) remains
loaded.

Since the driver uses a shared workqueue (`qat_misc_wq`) across all
devices and owned by intel_qat.ko, a deferred routine from the
device-specific driver may still be pending in the queue. If this
routine executes after the driver is unloaded, it can dereference freed
memory, resulting in a page fault and kernel crash like the following:

    BUG: unable to handle page fault for address: ffa000002e50a01c
    #PF: supervisor read access in kernel mode
    RIP: 0010:pm_bh_handler+0x1d2/0x250 [intel_qat]
    Call Trace:
      pm_bh_handler+0x1d2/0x250 [intel_qat]
      process_one_work+0x171/0x340
      worker_thread+0x277/0x3a0
      kthread+0xf0/0x120
      ret_from_fork+0x2d/0x50

To prevent this, flush the misc workqueue during device shutdown to
ensure that all pending work items are completed before the driver is
unloaded.

Note: This approach may slightly increase shutdown latency if the
workqueue contains jobs from other devices, but it ensures correctness
and stability.</Note>
    </Notes>
    <CVE>CVE-2025-39721</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: 8250: fix panic due to PSLVERR

When the PSLVERR_RESP_EN parameter is set to 1, the device generates
an error response if an attempt is made to read an empty RBR (Receive
Buffer Register) while the FIFO is enabled.

In serial8250_do_startup(), calling serial_port_out(port, UART_LCR,
UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes
dw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter
function enables the FIFO via serial_out(p, UART_FCR, p-&gt;fcr).
Execution proceeds to the serial_port_in(port, UART_RX).
This satisfies the PSLVERR trigger condition.

When another CPU (e.g., using printk()) is accessing the UART (UART
is busy), the current CPU fails the check (value &amp; ~UART_LCR_SPAR) ==
(lcr &amp; ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter
dw8250_force_idle().

Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port-&gt;lock
to fix this issue.

Panic backtrace:
[    0.442336] Oops - unknown exception [#1]
[    0.442343] epc : dw8250_serial_in32+0x1e/0x4a
[    0.442351]  ra : serial8250_do_startup+0x2c8/0x88e
...
[    0.442416] console_on_rootfs+0x26/0x70</Note>
    </Notes>
    <CVE>CVE-2025-39724</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/ism: fix concurrency management in ism_cmd()

The s390x ISM device data sheet clearly states that only one
request-response sequence is allowable per ISM function at any point in
time.  Unfortunately as of today the s390/ism driver in Linux does not
honor that requirement. This patch aims to rectify that.

This problem was discovered based on Aliaksei's bug report which states
that for certain workloads the ISM functions end up entering error state
(with PEC 2 as seen from the logs) after a while and as a consequence
connections handled by the respective function break, and for future
connection requests the ISM device is not considered -- given it is in a
dysfunctional state. During further debugging PEC 3A was observed as
well.

A kernel message like
[ 1211.244319] zpci: 061a:00:00.0: Event 0x2 reports an error for PCI function 0x61a
is a reliable indicator of the stated function entering error state
with PEC 2. Let me also point out that a kernel message like
[ 1211.244325] zpci: 061a:00:00.0: The ism driver bound to the device does not support error recovery
is a reliable indicator that the ISM function won't be auto-recovered
because the ISM driver currently lacks support for it.

On a technical level, without this synchronization, commands (inputs to
the FW) may be partially or fully overwritten (corrupted) by another CPU
trying to issue commands on the same function. There is hard evidence that
this can lead to DMB token values being used as DMB IOVAs, leading to
PEC 2 PCI events indicating invalid DMA. But this is only one of the
failure modes imaginable. In theory even completely losing one command
and executing another one twice and then trying to interpret the outputs
as if the command we intended to execute was actually executed and not
the other one is also possible.  Frankly, I don't feel confident about
providing an exhaustive list of possible consequences.</Note>
    </Notes>
    <CVE>CVE-2025-39726</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix filehandle bounds checking in nfs_fh_to_dentry()

The function needs to check the minimal filehandle length before it can
access the embedded filehandle.</Note>
    </Notes>
    <CVE>CVE-2025-39730</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 sleeping-in-atomic in ath11k_mac_op_set_bitrate_mask()

ath11k_mac_disable_peer_fixed_rate() is passed as the iterator to
ieee80211_iterate_stations_atomic(). Note in this case the iterator is
required to be atomic, however ath11k_mac_disable_peer_fixed_rate() does
not follow it as it might sleep. Consequently below warning is seen:

BUG: sleeping function called from invalid context at wmi.c:304
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl
 __might_resched.cold
 ath11k_wmi_cmd_send
 ath11k_wmi_set_peer_param
 ath11k_mac_disable_peer_fixed_rate
 ieee80211_iterate_stations_atomic
 ath11k_mac_op_set_bitrate_mask.cold

Change to ieee80211_iterate_stations_mtx() to fix this issue.

Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30</Note>
    </Notes>
    <CVE>CVE-2025-39732</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 allow relocation of partially dropped subvolumes

[BUG]
There is an internal report that balance triggered transaction abort,
with the following call trace:

  item 85 key (594509824 169 0) itemoff 12599 itemsize 33
          extent refs 1 gen 197740 flags 2
          ref#0: tree block backref root 7
  item 86 key (594558976 169 0) itemoff 12566 itemsize 33
          extent refs 1 gen 197522 flags 2
          ref#0: tree block backref root 7
 ...
 BTRFS error (device loop0): extent item not found for insert, bytenr 594526208 num_bytes 16384 parent 449921024 root_objectid 934 owner 1 offset 0
 BTRFS error (device loop0): failed to run delayed ref for logical 594526208 num_bytes 16384 type 182 action 1 ref_mod 1: -117
 ------------[ cut here ]------------
 BTRFS: Transaction aborted (error -117)
 WARNING: CPU: 1 PID: 6963 at ../fs/btrfs/extent-tree.c:2168 btrfs_run_delayed_refs+0xfa/0x110 [btrfs]

And btrfs check doesn't report anything wrong related to the extent
tree.

[CAUSE]
The cause is a little complex, firstly the extent tree indeed doesn't
have the backref for 594526208.

The extent tree only have the following two backrefs around that bytenr
on-disk:

        item 65 key (594509824 METADATA_ITEM 0) itemoff 13880 itemsize 33
                refs 1 gen 197740 flags TREE_BLOCK
                tree block skinny level 0
                (176 0x7) tree block backref root CSUM_TREE
        item 66 key (594558976 METADATA_ITEM 0) itemoff 13847 itemsize 33
                refs 1 gen 197522 flags TREE_BLOCK
                tree block skinny level 0
                (176 0x7) tree block backref root CSUM_TREE

But the such missing backref item is not an corruption on disk, as the
offending delayed ref belongs to subvolume 934, and that subvolume is
being dropped:

        item 0 key (934 ROOT_ITEM 198229) itemoff 15844 itemsize 439
                generation 198229 root_dirid 256 bytenr 10741039104 byte_limit 0 bytes_used 345571328
                last_snapshot 198229 flags 0x1000000000001(RDONLY) refs 0
                drop_progress key (206324 EXTENT_DATA 2711650304) drop_level 2
                level 2 generation_v2 198229

And that offending tree block 594526208 is inside the dropped range of
that subvolume.  That explains why there is no backref item for that
bytenr and why btrfs check is not reporting anything wrong.

But this also shows another problem, as btrfs will do all the orphan
subvolume cleanup at a read-write mount.

So half-dropped subvolume should not exist after an RW mount, and
balance itself is also exclusive to subvolume cleanup, meaning we
shouldn't hit a subvolume half-dropped during relocation.

The root cause is, there is no orphan item for this subvolume.
In fact there are 5 subvolumes from around 2021 that have the same
problem.

It looks like the original report has some older kernels running, and
caused those zombie subvolumes.

Thankfully upstream commit 8d488a8c7ba2 ("btrfs: fix subvolume/snapshot
deletion not triggered on mount") has long fixed the bug.

[ENHANCEMENT]
For repairing such old fs, btrfs-progs will be enhanced.

Considering how delayed the problem will show up (at run delayed ref
time) and at that time we have to abort transaction already, it is too
late.

Instead here we reject any half-dropped subvolume for reloc tree at the
earliest time, preventing confusion and extra time wasted on debugging
similar bugs.</Note>
    </Notes>
    <CVE>CVE-2025-39738</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/arm-smmu-qcom: Add SM6115 MDSS compatible

Add the SM6115 MDSS compatible to clients compatible list, as it also
needs that workaround.
Without this workaround, for example, QRB4210 RB2 which is based on
SM4250/SM6115 generates a lot of smmu unhandled context faults during
boot:

arm_smmu_context_fault: 116854 callbacks suppressed
arm-smmu c600000.iommu: Unhandled context fault: fsr=0x402,
iova=0x5c0ec600, fsynr=0x320021, cbfrsynra=0x420, cb=5
arm-smmu c600000.iommu: FSR    = 00000402 [Format=2 TF], SID=0x420
arm-smmu c600000.iommu: FSYNR0 = 00320021 [S1CBNDX=50 PNU PLVL=1]
arm-smmu c600000.iommu: Unhandled context fault: fsr=0x402,
iova=0x5c0d7800, fsynr=0x320021, cbfrsynra=0x420, cb=5
arm-smmu c600000.iommu: FSR    = 00000402 [Format=2 TF], SID=0x420

and also failed initialisation of lontium lt9611uxc, gpu and dpu is
observed:
(binding MDSS components triggered by lt9611uxc have failed)

 ------------[ cut here ]------------
 !aspace
 WARNING: CPU: 6 PID: 324 at drivers/gpu/drm/msm/msm_gem_vma.c:130 msm_gem_vma_init+0x150/0x18c [msm]
 Modules linked in: ... (long list of modules)
 CPU: 6 UID: 0 PID: 324 Comm: (udev-worker) Not tainted 6.15.0-03037-gaacc73ceeb8b #4 PREEMPT
 Hardware name: Qualcomm Technologies, Inc. QRB4210 RB2 (DT)
 pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 pc : msm_gem_vma_init+0x150/0x18c [msm]
 lr : msm_gem_vma_init+0x150/0x18c [msm]
 sp : ffff80008144b280
  		...
 Call trace:
  msm_gem_vma_init+0x150/0x18c [msm] (P)
  get_vma_locked+0xc0/0x194 [msm]
  msm_gem_get_and_pin_iova_range+0x4c/0xdc [msm]
  msm_gem_kernel_new+0x48/0x160 [msm]
  msm_gpu_init+0x34c/0x53c [msm]
  adreno_gpu_init+0x1b0/0x2d8 [msm]
  a6xx_gpu_init+0x1e8/0x9e0 [msm]
  adreno_bind+0x2b8/0x348 [msm]
  component_bind_all+0x100/0x230
  msm_drm_bind+0x13c/0x3d0 [msm]
  try_to_bring_up_aggregate_device+0x164/0x1d0
  __component_add+0xa4/0x174
  component_add+0x14/0x20
  dsi_dev_attach+0x20/0x34 [msm]
  dsi_host_attach+0x58/0x98 [msm]
  devm_mipi_dsi_attach+0x34/0x90
  lt9611uxc_attach_dsi.isra.0+0x94/0x124 [lontium_lt9611uxc]
  lt9611uxc_probe+0x540/0x5fc [lontium_lt9611uxc]
  i2c_device_probe+0x148/0x2a8
  really_probe+0xbc/0x2c0
  __driver_probe_device+0x78/0x120
  driver_probe_device+0x3c/0x154
  __driver_attach+0x90/0x1a0
  bus_for_each_dev+0x68/0xb8
  driver_attach+0x24/0x30
  bus_add_driver+0xe4/0x208
  driver_register+0x68/0x124
  i2c_register_driver+0x48/0xcc
  lt9611uxc_driver_init+0x20/0x1000 [lontium_lt9611uxc]
  do_one_initcall+0x60/0x1d4
  do_init_module+0x54/0x1fc
  load_module+0x1748/0x1c8c
  init_module_from_file+0x74/0xa0
  __arm64_sys_finit_module+0x130/0x2f8
  invoke_syscall+0x48/0x104
  el0_svc_common.constprop.0+0xc0/0xe0
  do_el0_svc+0x1c/0x28
  el0_svc+0x2c/0x80
  el0t_64_sync_handler+0x10c/0x138
  el0t_64_sync+0x198/0x19c
 ---[ end trace 0000000000000000 ]---
 msm_dpu 5e01000.display-controller: [drm:msm_gpu_init [msm]] *ERROR* could not allocate memptrs: -22
 msm_dpu 5e01000.display-controller: failed to load adreno gpu
 platform a400000.remoteproc:glink-edge:apr:service@7:dais: Adding to iommu group 19
 msm_dpu 5e01000.display-controller: failed to bind 5900000.gpu (ops a3xx_ops [msm]): -22
 msm_dpu 5e01000.display-controller: adev bind failed: -22
 lt9611uxc 0-002b: failed to attach dsi to host
 lt9611uxc 0-002b: probe with driver lt9611uxc failed with error -22</Note>
    </Notes>
    <CVE>CVE-2025-39739</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: hfi1: fix possible divide-by-zero in find_hw_thread_mask()

The function divides number of online CPUs by num_core_siblings, and
later checks the divider by zero. This implies a possibility to get
and divide-by-zero runtime error. Fix it by moving the check prior to
division. This also helps to save one indentation level.</Note>
    </Notes>
    <CVE>CVE-2025-39742</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: truncate good inode pages when hard link is 0

The fileset value of the inode copy from the disk by the reproducer is
AGGR_RESERVED_I. When executing evict, its hard link number is 0, so its
inode pages are not truncated. This causes the bugon to be triggered when
executing clear_inode() because nrpages is greater than 0.</Note>
    </Notes>
    <CVE>CVE-2025-39743</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:

rcu: Fix rcu_read_unlock() deadloop due to IRQ work

During rcu_read_unlock_special(), if this happens during irq_exit(), we
can lockup if an IPI is issued. This is because the IPI itself triggers
the irq_exit() path causing a recursive lock up.

This is precisely what Xiongfeng found when invoking a BPF program on
the trace_tick_stop() tracepoint As shown in the trace below. Fix by
managing the irq_work state correctly.

irq_exit()
  __irq_exit_rcu()
    /* in_hardirq() returns false after this */
    preempt_count_sub(HARDIRQ_OFFSET)
    tick_irq_exit()
      tick_nohz_irq_exit()
	    tick_nohz_stop_sched_tick()
	      trace_tick_stop()  /* a bpf prog is hooked on this trace point */
		   __bpf_trace_tick_stop()
		      bpf_trace_run2()
			    rcu_read_unlock_special()
                              /* will send a IPI to itself */
			      irq_work_queue_on(&amp;rdp-&gt;defer_qs_iw, rdp-&gt;cpu);

A simple reproducer can also be obtained by doing the following in
tick_irq_exit(). It will hang on boot without the patch:

  static inline void tick_irq_exit(void)
  {
 +	rcu_read_lock();
 +	WRITE_ONCE(current-&gt;rcu_read_unlock_special.b.need_qs, true);
 +	rcu_read_unlock();
 +

[neeraj: Apply Frederic's suggested fix for PREEMPT_RT]</Note>
    </Notes>
    <CVE>CVE-2025-39744</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ath10k: shutdown driver when hardware is unreliable

In rare cases, ath10k may lose connection with the PCIe bus due to
some unknown reasons, which could further lead to system crashes during
resuming due to watchdog timeout:

ath10k_pci 0000:01:00.0: wmi command 20486 timeout, restarting hardware
ath10k_pci 0000:01:00.0: already restarting
ath10k_pci 0000:01:00.0: failed to stop WMI vdev 0: -11
ath10k_pci 0000:01:00.0: failed to stop vdev 0: -11
ieee80211 phy0: PM: **** DPM device timeout ****
Call Trace:
 panic+0x125/0x315
 dpm_watchdog_set+0x54/0x54
 dpm_watchdog_handler+0x57/0x57
 call_timer_fn+0x31/0x13c

At this point, all WMI commands will timeout and attempt to restart
device. So set a threshold for consecutive restart failures. If the
threshold is exceeded, consider the hardware is unreliable and all
ath10k operations should be skipped to avoid system crash.

fail_cont_count and pending_recovery are atomic variables, and
do not involve complex conditional logic. Therefore, even if recovery
check and reconfig complete are executed concurrently, the recovery
mechanism will not be broken.

Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1</Note>
    </Notes>
    <CVE>CVE-2025-39746</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

rcu: Protect -&gt;defer_qs_iw_pending from data race

On kernels built with CONFIG_IRQ_WORK=y, when rcu_read_unlock() is
invoked within an interrupts-disabled region of code [1], it will invoke
rcu_read_unlock_special(), which uses an irq-work handler to force the
system to notice when the RCU read-side critical section actually ends.
That end won't happen until interrupts are enabled at the soonest.

In some kernels, such as those booted with rcutree.use_softirq=y, the
irq-work handler is used unconditionally.

The per-CPU rcu_data structure's -&gt;defer_qs_iw_pending field is
updated by the irq-work handler and is both read and updated by
rcu_read_unlock_special().  This resulted in the following KCSAN splat:

------------------------------------------------------------------------

BUG: KCSAN: data-race in rcu_preempt_deferred_qs_handler / rcu_read_unlock_special

read to 0xffff96b95f42d8d8 of 1 bytes by task 90 on cpu 8:
 rcu_read_unlock_special+0x175/0x260
 __rcu_read_unlock+0x92/0xa0
 rt_spin_unlock+0x9b/0xc0
 __local_bh_enable+0x10d/0x170
 __local_bh_enable_ip+0xfb/0x150
 rcu_do_batch+0x595/0xc40
 rcu_cpu_kthread+0x4e9/0x830
 smpboot_thread_fn+0x24d/0x3b0
 kthread+0x3bd/0x410
 ret_from_fork+0x35/0x40
 ret_from_fork_asm+0x1a/0x30

write to 0xffff96b95f42d8d8 of 1 bytes by task 88 on cpu 8:
 rcu_preempt_deferred_qs_handler+0x1e/0x30
 irq_work_single+0xaf/0x160
 run_irq_workd+0x91/0xc0
 smpboot_thread_fn+0x24d/0x3b0
 kthread+0x3bd/0x410
 ret_from_fork+0x35/0x40
 ret_from_fork_asm+0x1a/0x30

no locks held by irq_work/8/88.
irq event stamp: 200272
hardirqs last  enabled at (200272): [&lt;ffffffffb0f56121&gt;] finish_task_switch+0x131/0x320
hardirqs last disabled at (200271): [&lt;ffffffffb25c7859&gt;] __schedule+0x129/0xd70
softirqs last  enabled at (0): [&lt;ffffffffb0ee093f&gt;] copy_process+0x4df/0x1cc0
softirqs last disabled at (0): [&lt;0000000000000000&gt;] 0x0

------------------------------------------------------------------------

The problem is that irq-work handlers run with interrupts enabled, which
means that rcu_preempt_deferred_qs_handler() could be interrupted,
and that interrupt handler might contain an RCU read-side critical
section, which might invoke rcu_read_unlock_special().  In the strict
KCSAN mode of operation used by RCU, this constitutes a data race on
the -&gt;defer_qs_iw_pending field.

This commit therefore disables interrupts across the portion of the
rcu_preempt_deferred_qs_handler() that updates the -&gt;defer_qs_iw_pending
field.  This suffices because this handler is not a fast path.</Note>
    </Notes>
    <CVE>CVE-2025-39749</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Correct tid cleanup when tid setup fails

Currently, if any error occurs during ath12k_dp_rx_peer_tid_setup(),
the tid value is already incremented, even though the corresponding
TID is not actually allocated. Proceed to
ath12k_dp_rx_peer_tid_delete() starting from unallocated tid,
which might leads to freeing unallocated TID and cause potential
crash or out-of-bounds access.

Hence, fix by correctly decrementing tid before cleanup to match only
the successfully allocated TIDs.

Also, remove tid-- from failure case of ath12k_dp_rx_peer_frag_setup(),
as decrementing the tid before cleanup in loop will take care of this.

Compile tested only.</Note>
    </Notes>
    <CVE>CVE-2025-39750</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-39751</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/smaps: fix race between smaps_hugetlb_range and migration

smaps_hugetlb_range() handles the pte without holdling ptl, and may be
concurrenct with migration, leaing to BUG_ON in pfn_swap_entry_to_page(). 
The race is as follows.

smaps_hugetlb_range              migrate_pages
  huge_ptep_get
                                   remove_migration_ptes
				   folio_unlock
  pfn_swap_entry_folio
    BUG_ON

To fix it, hold ptl lock in smaps_hugetlb_range().</Note>
    </Notes>
    <CVE>CVE-2025-39754</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Prevent file descriptor table allocations exceeding INT_MAX

When sysctl_nr_open is set to a very high value (for example, 1073741816
as set by systemd), processes attempting to use file descriptors near
the limit can trigger massive memory allocation attempts that exceed
INT_MAX, resulting in a WARNING in mm/slub.c:

  WARNING: CPU: 0 PID: 44 at mm/slub.c:5027 __kvmalloc_node_noprof+0x21a/0x288

This happens because kvmalloc_array() and kvmalloc() check if the
requested size exceeds INT_MAX and emit a warning when the allocation is
not flagged with __GFP_NOWARN.

Specifically, when nr_open is set to 1073741816 (0x3ffffff8) and a
process calls dup2(oldfd, 1073741880), the kernel attempts to allocate:
- File descriptor array: 1073741880 * 8 bytes = 8,589,935,040 bytes
- Multiple bitmaps: ~400MB
- Total allocation size: &gt; 8GB (exceeding INT_MAX = 2,147,483,647)

Reproducer:
1. Set /proc/sys/fs/nr_open to 1073741816:
   # echo 1073741816 &gt; /proc/sys/fs/nr_open

2. Run a program that uses a high file descriptor:
   #include &lt;unistd.h&gt;
   #include &lt;sys/resource.h&gt;

   int main() {
       struct rlimit rlim = {1073741824, 1073741824};
       setrlimit(RLIMIT_NOFILE, &amp;rlim);
       dup2(2, 1073741880);  // Triggers the warning
       return 0;
   }

3. Observe WARNING in dmesg at mm/slub.c:5027

systemd commit a8b627a introduced automatic bumping of fs.nr_open to the
maximum possible value. The rationale was that systems with memory
control groups (memcg) no longer need separate file descriptor limits
since memory is properly accounted. However, this change overlooked
that:

1. The kernel's allocation functions still enforce INT_MAX as a maximum
   size regardless of memcg accounting
2. Programs and tests that legitimately test file descriptor limits can
   inadvertently trigger massive allocations
3. The resulting allocations (&gt;8GB) are impractical and will always fail

systemd's algorithm starts with INT_MAX and keeps halving the value
until the kernel accepts it. On most systems, this results in nr_open
being set to 1073741816 (0x3ffffff8), which is just under 1GB of file
descriptors.

While processes rarely use file descriptors near this limit in normal
operation, certain selftests (like
tools/testing/selftests/core/unshare_test.c) and programs that test file
descriptor limits can trigger this issue.

Fix this by adding a check in alloc_fdtable() to ensure the requested
allocation size does not exceed INT_MAX. This causes the operation to
fail with -EMFILE instead of triggering a kernel warning and avoids the
impractical &gt;8GB memory allocation request.</Note>
    </Notes>
    <CVE>CVE-2025-39756</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Validate UAC3 cluster segment descriptors

UAC3 class segment descriptors need to be verified whether their sizes
match with the declared lengths and whether they fit with the
allocated buffer sizes, too.  Otherwise malicious firmware may lead to
the unexpected OOB accesses.</Note>
    </Notes>
    <CVE>CVE-2025-39757</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/siw: Fix the sendmsg byte count in siw_tcp_sendpages

Ever since commit c2ff29e99a76 ("siw: Inline do_tcp_sendpages()"),
we have been doing this:

static int siw_tcp_sendpages(struct socket *s, struct page **page, int offset,
                             size_t size)
[...]
        /* Calculate the number of bytes we need to push, for this page
         * specifically */
        size_t bytes = min_t(size_t, PAGE_SIZE - offset, size);
        /* If we can't splice it, then copy it in, as normal */
        if (!sendpage_ok(page[i]))
                msg.msg_flags &amp;= ~MSG_SPLICE_PAGES;
        /* Set the bvec pointing to the page, with len $bytes */
        bvec_set_page(&amp;bvec, page[i], bytes, offset);
        /* Set the iter to $size, aka the size of the whole sendpages (!!!) */
        iov_iter_bvec(&amp;msg.msg_iter, ITER_SOURCE, &amp;bvec, 1, size);
try_page_again:
        lock_sock(sk);
        /* Sendmsg with $size size (!!!) */
        rv = tcp_sendmsg_locked(sk, &amp;msg, size);

This means we've been sending oversized iov_iters and tcp_sendmsg calls
for a while. This has a been a benign bug because sendpage_ok() always
returned true. With the recent slab allocator changes being slowly
introduced into next (that disallow sendpage on large kmalloc
allocations), we have recently hit out-of-bounds crashes, due to slight
differences in iov_iter behavior between the MSG_SPLICE_PAGES and
"regular" copy paths:

(MSG_SPLICE_PAGES)
skb_splice_from_iter
  iov_iter_extract_pages
    iov_iter_extract_bvec_pages
      uses i-&gt;nr_segs to correctly stop in its tracks before OoB'ing everywhere
  skb_splice_from_iter gets a "short" read

(!MSG_SPLICE_PAGES)
skb_copy_to_page_nocache copy=iov_iter_count
 [...]
   copy_from_iter
        /* this doesn't help */
        if (unlikely(iter-&gt;count &lt; len))
                len = iter-&gt;count;
          iterate_bvec
            ... and we run off the bvecs

Fix this by properly setting the iov_iter's byte count, plus sending the
correct byte count to tcp_sendmsg_locked.</Note>
    </Notes>
    <CVE>CVE-2025-39758</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: qgroup: fix race between quota disable and quota rescan ioctl

There's a race between a task disabling quotas and another running the
rescan ioctl that can result in a use-after-free of qgroup records from
the fs_info-&gt;qgroup_tree rbtree.

This happens as follows:

1) Task A enters btrfs_ioctl_quota_rescan() -&gt; btrfs_qgroup_rescan();

2) Task B enters btrfs_quota_disable() and calls
   btrfs_qgroup_wait_for_completion(), which does nothing because at that
   point fs_info-&gt;qgroup_rescan_running is false (it wasn't set yet by
   task A);

3) Task B calls btrfs_free_qgroup_config() which starts freeing qgroups
   from fs_info-&gt;qgroup_tree without taking the lock fs_info-&gt;qgroup_lock;

4) Task A enters qgroup_rescan_zero_tracking() which starts iterating
   the fs_info-&gt;qgroup_tree tree while holding fs_info-&gt;qgroup_lock,
   but task B is freeing qgroup records from that tree without holding
   the lock, resulting in a use-after-free.

Fix this by taking fs_info-&gt;qgroup_lock at btrfs_free_qgroup_config().
Also at btrfs_qgroup_rescan() don't start the rescan worker if quotas
were already disabled.</Note>
    </Notes>
    <CVE>CVE-2025-39759</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: core: config: Prevent OOB read in SS endpoint companion parsing

usb_parse_ss_endpoint_companion() checks descriptor type before length,
enabling a potentially odd read outside of the buffer size.

Fix this up by checking the size first before looking at any of the
fields in the descriptor.</Note>
    </Notes>
    <CVE>CVE-2025-39760</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Decrement TID on RX peer frag setup error handling

Currently, TID is not decremented before peer cleanup, during error
handling path of ath12k_dp_rx_peer_frag_setup(). This could lead to
out-of-bounds access in peer-&gt;rx_tid[].

Hence, add a decrement operation for TID, before peer cleanup to
ensures proper cleanup and prevents out-of-bounds access issues when
the RX peer frag setup fails.

Found during code review. Compile tested only.</Note>
    </Notes>
    <CVE>CVE-2025-39761</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:

ACPI: APEI: send SIGBUS to current task if synchronous memory error not recovered

If a synchronous error is detected as a result of user-space process
triggering a 2-bit uncorrected error, the CPU will take a synchronous
error exception such as Synchronous External Abort (SEA) on Arm64. The
kernel will queue a memory_failure() work which poisons the related
page, unmaps the page, and then sends a SIGBUS to the process, so that
a system wide panic can be avoided.

However, no memory_failure() work will be queued when abnormal
synchronous errors occur. These errors can include situations like
invalid PA, unexpected severity, no memory failure config support,
invalid GUID section, etc. In such a case, the user-space process will
trigger SEA again.  This loop can potentially exceed the platform
firmware threshold or even trigger a kernel hard lockup, leading to a
system reboot.

Fix it by performing a force kill if no memory_failure() work is queued
for synchronous errors.

[ rjw: Changelog edits ]</Note>
    </Notes>
    <CVE>CVE-2025-39763</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ctnetlink: remove refcounting in expectation dumpers

Same pattern as previous patch: do not keep the expectation object
alive via refcount, only store a cookie value and then use that
as the skip hint for dump resumption.

AFAICS this has the same issue as the one resolved in the conntrack
dumper, when we do
  if (!refcount_inc_not_zero(&amp;exp-&gt;use))

to increment the refcount, there is a chance that exp == last, which
causes a double-increment of the refcount and subsequent memory leak.</Note>
    </Notes>
    <CVE>CVE-2025-39764</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Make cake_enqueue return NET_XMIT_CN when past buffer_limit

The following setup can trigger a WARNING in htb_activate due to
the condition: !cl-&gt;leaf.q-&gt;q.qlen

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 f: \
       cake memlimit 1b
ping -I lo -f -c1 -s64 -W0.001 127.0.0.1

This is because the low memlimit leads to a low buffer_limit, which
causes packet dropping. However, cake_enqueue still returns
NET_XMIT_SUCCESS, causing htb_enqueue to call htb_activate with an
empty child qdisc. We should return NET_XMIT_CN when packets are
dropped from the same tin and flow.

I do not believe return value of NET_XMIT_CN is necessary for packet
drops in the case of ack filtering, as that is meant to optimize
performance, not to signal congestion.</Note>
    </Notes>
    <CVE>CVE-2025-39766</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: gso: Forbid IPv6 TSO with extensions on devices with only IPV6_CSUM

When performing Generic Segmentation Offload (GSO) on an IPv6 packet that
contains extension headers, the kernel incorrectly requests checksum offload
if the egress device only advertises NETIF_F_IPV6_CSUM feature, which has
a strict contract: it supports checksum offload only for plain TCP or UDP
over IPv6 and explicitly does not support packets with extension headers.
The current GSO logic violates this contract by failing to disable the feature
for packets with extension headers, such as those used in GREoIPv6 tunnels.

This violation results in the device being asked to perform an operation
it cannot support, leading to a `skb_warn_bad_offload` warning and a collapse
of network throughput. While device TSO/USO is correctly bypassed in favor
of software GSO for these packets, the GSO stack must be explicitly told not
to request checksum offload.

Mask NETIF_F_IPV6_CSUM, NETIF_F_TSO6 and NETIF_F_GSO_UDP_L4
in gso_features_check if the IPv6 header contains extension headers to compute
checksum in software.

The exception is a BIG TCP extension, which, as stated in commit
68e068cabd2c6c53 ("net: reenable NETIF_F_IPV6_CSUM offload for BIG TCP packets"):
"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."

kernel log output (truncated):
WARNING: CPU: 1 PID: 5273 at net/core/dev.c:3535 skb_warn_bad_offload+0x81/0x140
...
Call Trace:
 &lt;TASK&gt;
 skb_checksum_help+0x12a/0x1f0
 validate_xmit_skb+0x1a3/0x2d0
 validate_xmit_skb_list+0x4f/0x80
 sch_direct_xmit+0x1a2/0x380
 __dev_xmit_skb+0x242/0x670
 __dev_queue_xmit+0x3fc/0x7f0
 ip6_finish_output2+0x25e/0x5d0
 ip6_finish_output+0x1fc/0x3f0
 ip6_tnl_xmit+0x608/0xc00 [ip6_tunnel]
 ip6gre_tunnel_xmit+0x1c0/0x390 [ip6_gre]
 dev_hard_start_xmit+0x63/0x1c0
 __dev_queue_xmit+0x6d0/0x7f0
 ip6_finish_output2+0x214/0x5d0
 ip6_finish_output+0x1fc/0x3f0
 ip6_xmit+0x2ca/0x6f0
 ip6_finish_output+0x1fc/0x3f0
 ip6_xmit+0x2ca/0x6f0
 inet6_csk_xmit+0xeb/0x150
 __tcp_transmit_skb+0x555/0xa80
 tcp_write_xmit+0x32a/0xe90
 tcp_sendmsg_locked+0x437/0x1110
 tcp_sendmsg+0x2f/0x50
...
skb linear:   00000000: e4 3d 1a 7d ec 30 e4 3d 1a 7e 5d 90 86 dd 60 0e
skb linear:   00000010: 00 0a 1b 34 3c 40 20 11 00 00 00 00 00 00 00 00
skb linear:   00000020: 00 00 00 00 00 12 20 11 00 00 00 00 00 00 00 00
skb linear:   00000030: 00 00 00 00 00 11 2f 00 04 01 04 01 01 00 00 00
skb linear:   00000040: 86 dd 60 0e 00 0a 1b 00 06 40 20 23 00 00 00 00
skb linear:   00000050: 00 00 00 00 00 00 00 00 00 12 20 23 00 00 00 00
skb linear:   00000060: 00 00 00 00 00 00 00 00 00 11 bf 96 14 51 13 f9
skb linear:   00000070: ae 27 a0 a8 2b e3 80 18 00 40 5b 6f 00 00 01 01
skb linear:   00000080: 08 0a 42 d4 50 d5 4b 70 f8 1a</Note>
    </Notes>
    <CVE>CVE-2025-39770</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/hisilicon/hibmc: fix the hibmc loaded failed bug

When hibmc loaded failed, the driver use hibmc_unload to free the
resource, but the mutexes in mode.config are not init, which will
access an NULL pointer. Just change goto statement to return, because
hibnc_hw_init() doesn't need to free anything.</Note>
    </Notes>
    <CVE>CVE-2025-39772</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: bridge: fix soft lockup in br_multicast_query_expired()

When set multicast_query_interval to a large value, the local variable
'time' in br_multicast_send_query() may overflow. If the time is smaller
than jiffies, the timer will expire immediately, and then call mod_timer()
again, which creates a loop and may trigger the following soft lockup
issue.

  watchdog: BUG: soft lockup - CPU#1 stuck for 221s! [rb_consumer:66]
  CPU: 1 UID: 0 PID: 66 Comm: rb_consumer Not tainted 6.16.0+ #259 PREEMPT(none)
  Call Trace:
   &lt;IRQ&gt;
   __netdev_alloc_skb+0x2e/0x3a0
   br_ip6_multicast_alloc_query+0x212/0x1b70
   __br_multicast_send_query+0x376/0xac0
   br_multicast_send_query+0x299/0x510
   br_multicast_query_expired.constprop.0+0x16d/0x1b0
   call_timer_fn+0x3b/0x2a0
   __run_timers+0x619/0x950
   run_timer_softirq+0x11c/0x220
   handle_softirqs+0x18e/0x560
   __irq_exit_rcu+0x158/0x1a0
   sysvec_apic_timer_interrupt+0x76/0x90
   &lt;/IRQ&gt;

This issue can be reproduced with:
  ip link add br0 type bridge
  echo 1 &gt; /sys/class/net/br0/bridge/multicast_querier
  echo 0xffffffffffffffff &gt;
  	/sys/class/net/br0/bridge/multicast_query_interval
  ip link set dev br0 up

The multicast_startup_query_interval can also cause this issue. Similar to
the commit 99b40610956a ("net: bridge: mcast: add and enforce query
interval minimum"), add check for the query interval maximum to fix this
issue.</Note>
    </Notes>
    <CVE>CVE-2025-39773</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: prevent softlockup in jbd2_log_do_checkpoint()

Both jbd2_log_do_checkpoint() and jbd2_journal_shrink_checkpoint_list()
periodically release j_list_lock after processing a batch of buffers to
avoid long hold times on the j_list_lock. However, since both functions
contend for j_list_lock, the combined time spent waiting and processing
can be significant.

jbd2_journal_shrink_checkpoint_list() explicitly calls cond_resched() when
need_resched() is true to avoid softlockups during prolonged operations.
But jbd2_log_do_checkpoint() only exits its loop when need_resched() is
true, relying on potentially sleeping functions like __flush_batch() or
wait_on_buffer() to trigger rescheduling. If those functions do not sleep,
the kernel may hit a softlockup.

watchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373]
CPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10
Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017
Workqueue: writeback wb_workfn (flush-7:2)
pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : native_queued_spin_lock_slowpath+0x358/0x418
lr : jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]
Call trace:
 native_queued_spin_lock_slowpath+0x358/0x418
 jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]
 __jbd2_log_wait_for_space+0xfc/0x2f8 [jbd2]
 add_transaction_credits+0x3bc/0x418 [jbd2]
 start_this_handle+0xf8/0x560 [jbd2]
 jbd2__journal_start+0x118/0x228 [jbd2]
 __ext4_journal_start_sb+0x110/0x188 [ext4]
 ext4_do_writepages+0x3dc/0x740 [ext4]
 ext4_writepages+0xa4/0x190 [ext4]
 do_writepages+0x94/0x228
 __writeback_single_inode+0x48/0x318
 writeback_sb_inodes+0x204/0x590
 __writeback_inodes_wb+0x54/0xf8
 wb_writeback+0x2cc/0x3d8
 wb_do_writeback+0x2e0/0x2f8
 wb_workfn+0x80/0x2a8
 process_one_work+0x178/0x3e8
 worker_thread+0x234/0x3b8
 kthread+0xf0/0x108
 ret_from_fork+0x10/0x20

So explicitly call cond_resched() in jbd2_log_do_checkpoint() to avoid
softlockup.</Note>
    </Notes>
    <CVE>CVE-2025-39782</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: endpoint: Fix configfs group list head handling

Doing a list_del() on the epf_group field of struct pci_epf_driver in
pci_epf_remove_cfs() is not correct as this field is a list head, not
a list entry. This list_del() call triggers a KASAN warning when an
endpoint function driver which has a configfs attribute group is torn
down:

==================================================================
BUG: KASAN: slab-use-after-free in pci_epf_remove_cfs+0x17c/0x198
Write of size 8 at addr ffff00010f4a0d80 by task rmmod/319

CPU: 3 UID: 0 PID: 319 Comm: rmmod Not tainted 6.16.0-rc2 #1 NONE
Hardware name: Radxa ROCK 5B (DT)
Call trace:
show_stack+0x2c/0x84 (C)
dump_stack_lvl+0x70/0x98
print_report+0x17c/0x538
kasan_report+0xb8/0x190
__asan_report_store8_noabort+0x20/0x2c
pci_epf_remove_cfs+0x17c/0x198
pci_epf_unregister_driver+0x18/0x30
nvmet_pci_epf_cleanup_module+0x24/0x30 [nvmet_pci_epf]
__arm64_sys_delete_module+0x264/0x424
invoke_syscall+0x70/0x260
el0_svc_common.constprop.0+0xac/0x230
do_el0_svc+0x40/0x58
el0_svc+0x48/0xdc
el0t_64_sync_handler+0x10c/0x138
el0t_64_sync+0x198/0x19c
...

Remove this incorrect list_del() call from pci_epf_remove_cfs().</Note>
    </Notes>
    <CVE>CVE-2025-39783</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: qcom: mdt_loader: Ensure we don't read past the ELF header

When the MDT loader is used in remoteproc, the ELF header is sanitized
beforehand, but that's not necessary the case for other clients.

Validate the size of the firmware buffer to ensure that we don't read
past the end as we iterate over the header. e_phentsize and e_shentsize
are validated as well, to ensure that the assumptions about step size in
the traversal are valid.</Note>
    </Notes>
    <CVE>CVE-2025-39787</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Detect events pointing to unexpected TREs

When a remote device sends a completion event to the host, it contains a
pointer to the consumed TRE. The host uses this pointer to process all of
the TREs between it and the host's local copy of the ring's read pointer.
This works when processing completion for chained transactions, but can
lead to nasty results if the device sends an event for a single-element
transaction with a read pointer that is multiple elements ahead of the
host's read pointer.

For instance, if the host accesses an event ring while the device is
updating it, the pointer inside of the event might still point to an old
TRE. If the host uses the channel's xfer_cb() to directly free the buffer
pointed to by the TRE, the buffer will be double-freed.

This behavior was observed on an ep that used upstream EP stack without
'commit 6f18d174b73d ("bus: mhi: ep: Update read pointer only after buffer
is written")'. Where the device updated the events ring pointer before
updating the event contents, so it left a window where the host was able to
access the stale data the event pointed to, before the device had the
chance to update them. The usual pattern was that the host received an
event pointing to a TRE that is not immediately after the last processed
one, so it got treated as if it was a chained transaction, processing all
of the TREs in between the two read pointers.

This commit aims to harden the host by ensuring transactions where the
event points to a TRE that isn't local_rp + 1 are chained.

[mani: added stable tag and reworded commit message]</Note>
    </Notes>
    <CVE>CVE-2025-39790</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:

ARM: tegra: Use I/O memcpy to write to IRAM

Kasan crashes the kernel trying to check boundaries when using the
normal memcpy.</Note>
    </Notes>
    <CVE>CVE-2025-39794</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Duplicate SPI Handling

The issue originates when Strongswan initiates an XFRM_MSG_ALLOCSPI
Netlink message, which triggers the kernel function xfrm_alloc_spi().
This function is expected to ensure uniqueness of the Security Parameter
Index (SPI) for inbound Security Associations (SAs). However, it can
return success even when the requested SPI is already in use, leading
to duplicate SPIs assigned to multiple inbound SAs, differentiated
only by their destination addresses.

This behavior causes inconsistencies during SPI lookups for inbound packets.
Since the lookup may return an arbitrary SA among those with the same SPI,
packet processing can fail, resulting in packet drops.

According to RFC 4301 section 4.4.2 , for inbound processing a unicast SA
is uniquely identified by the SPI and optionally protocol.

Reproducing the Issue Reliably:
To consistently reproduce the problem, restrict the available SPI range in
charon.conf : spi_min = 0x10000000 spi_max = 0x10000002
This limits the system to only 2 usable SPI values.
Next, create more than 2 Child SA. each using unique pair of src/dst address.
As soon as the 3rd Child SA is initiated, it will be assigned a duplicate
SPI, since the SPI pool is already exhausted.
With a narrow SPI range, the issue is consistently reproducible.
With a broader/default range, it becomes rare and unpredictable.

Current implementation:
xfrm_spi_hash() lookup function computes hash using daddr, proto, and family.
So if two SAs have the same SPI but different destination addresses, then
they will:
a. Hash into different buckets
b. Be stored in different linked lists (byspi + h)
c. Not be seen in the same hlist_for_each_entry_rcu() iteration.
As a result, the lookup will result in NULL and kernel allows that Duplicate SPI

Proposed Change:
xfrm_state_lookup_spi_proto() does a truly global search - across all states,
regardless of hash bucket and matches SPI and proto.</Note>
    </Notes>
    <CVE>CVE-2025-39797</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix the setting of capabilities when automounting a new filesystem

Capabilities cannot be inherited when we cross into a new filesystem.
They need to be reset to the minimal defaults, and then probed for
again.</Note>
    </Notes>
    <CVE>CVE-2025-39798</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: abort transaction on unexpected eb generation at btrfs_copy_root()

If we find an unexpected generation for the extent buffer we are cloning
at btrfs_copy_root(), we just WARN_ON() and don't error out and abort the
transaction, meaning we allow to persist metadata with an unexpected
generation. Instead of warning only, abort the transaction and return
-EUCLEAN.</Note>
    </Notes>
    <CVE>CVE-2025-39800</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Remove WARN_ON for device endpoint command timeouts

This commit addresses a rarely observed endpoint command timeout
which causes kernel panic due to warn when 'panic_on_warn' is enabled
and unnecessary call trace prints when 'panic_on_warn' is disabled.
It is seen during fast software-controlled connect/disconnect testcases.
The following is one such endpoint command timeout that we observed:

1. Connect
   =======
-&gt;dwc3_thread_interrupt
 -&gt;dwc3_ep0_interrupt
  -&gt;configfs_composite_setup
   -&gt;composite_setup
    -&gt;usb_ep_queue
     -&gt;dwc3_gadget_ep0_queue
      -&gt;__dwc3_gadget_ep0_queue
       -&gt;__dwc3_ep0_do_control_data
        -&gt;dwc3_send_gadget_ep_cmd

2. Disconnect
   ==========
-&gt;dwc3_thread_interrupt
 -&gt;dwc3_gadget_disconnect_interrupt
  -&gt;dwc3_ep0_reset_state
   -&gt;dwc3_ep0_end_control_data
    -&gt;dwc3_send_gadget_ep_cmd

In the issue scenario, in Exynos platforms, we observed that control
transfers for the previous connect have not yet been completed and end
transfer command sent as a part of the disconnect sequence and
processing of USB_ENDPOINT_HALT feature request from the host timeout.
This maybe an expected scenario since the controller is processing EP
commands sent as a part of the previous connect. It maybe better to
remove WARN_ON in all places where device endpoint commands are sent to
avoid unnecessary kernel panic due to warn.</Note>
    </Notes>
    <CVE>CVE-2025-39801</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: multitouch: fix slab out-of-bounds access in mt_report_fixup()

A malicious HID device can trigger a slab out-of-bounds during
mt_report_fixup() by passing in report descriptor smaller than
607 bytes. mt_report_fixup() attempts to patch byte offset 607
of the descriptor with 0x25 by first checking if byte offset
607 is 0x15 however it lacks bounds checks to verify if the
descriptor is big enough before conducting this check. Fix
this bug by ensuring the descriptor size is at least 608
bytes before accessing it.

Below is the KASAN splat after the out of bounds access happens:

[   13.671954] ==================================================================
[   13.672667] BUG: KASAN: slab-out-of-bounds in mt_report_fixup+0x103/0x110
[   13.673297] Read of size 1 at addr ffff888103df39df by task kworker/0:1/10
[   13.673297]
[   13.673297] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.15.0-00005-gec5d573d83f4-dirty #3
[   13.673297] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/04
[   13.673297] Call Trace:
[   13.673297]  &lt;TASK&gt;
[   13.673297]  dump_stack_lvl+0x5f/0x80
[   13.673297]  print_report+0xd1/0x660
[   13.673297]  kasan_report+0xe5/0x120
[   13.673297]  __asan_report_load1_noabort+0x18/0x20
[   13.673297]  mt_report_fixup+0x103/0x110
[   13.673297]  hid_open_report+0x1ef/0x810
[   13.673297]  mt_probe+0x422/0x960
[   13.673297]  hid_device_probe+0x2e2/0x6f0
[   13.673297]  really_probe+0x1c6/0x6b0
[   13.673297]  __driver_probe_device+0x24f/0x310
[   13.673297]  driver_probe_device+0x4e/0x220
[   13.673297]  __device_attach_driver+0x169/0x320
[   13.673297]  bus_for_each_drv+0x11d/0x1b0
[   13.673297]  __device_attach+0x1b8/0x3e0
[   13.673297]  device_initial_probe+0x12/0x20
[   13.673297]  bus_probe_device+0x13d/0x180
[   13.673297]  device_add+0xe3a/0x1670
[   13.673297]  hid_add_device+0x31d/0xa40
[...]</Note>
    </Notes>
    <CVE>CVE-2025-39806</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: hid-ntrig: fix unable to handle page fault in ntrig_report_version()

in ntrig_report_version(), hdev parameter passed from hid_probe().
sending descriptor to /dev/uhid can make hdev-&gt;dev.parent-&gt;parent to null
if hdev-&gt;dev.parent-&gt;parent is null, usb_dev has
invalid address(0xffffffffffffff58) that hid_to_usb_dev(hdev) returned
when usb_rcvctrlpipe() use usb_dev,it trigger
page fault error for address(0xffffffffffffff58)

add null check logic to ntrig_report_version()
before calling hid_to_usb_dev()</Note>
    </Notes>
    <CVE>CVE-2025-39808</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 memory corruption when FW resources change during ifdown

bnxt_set_dflt_rings() assumes that it is always called before any TC has
been created.  So it doesn't take bp-&gt;num_tc into account and assumes
that it is always 0 or 1.

In the FW resource or capability change scenario, the FW will return
flags in bnxt_hwrm_if_change() that will cause the driver to
reinitialize and call bnxt_cancel_reservations().  This will lead to
bnxt_init_dflt_ring_mode() calling bnxt_set_dflt_rings() and bp-&gt;num_tc
may be greater than 1.  This will cause bp-&gt;tx_ring[] to be sized too
small and cause memory corruption in bnxt_alloc_cp_rings().

Fix it by properly scaling the TX rings by bp-&gt;num_tc in the code
paths mentioned above.  Add 2 helper functions to determine
bp-&gt;tx_nr_rings and bp-&gt;tx_nr_rings_per_tc.</Note>
    </Notes>
    <CVE>CVE-2025-39810</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: initialize more fields in sctp_v6_from_sk()

syzbot found that sin6_scope_id was not properly initialized,
leading to undefined behavior.

Clear sin6_scope_id and sin6_flowinfo.

BUG: KMSAN: uninit-value in __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649
  __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649
  sctp_inet6_cmp_addr+0x4f2/0x510 net/sctp/ipv6.c:983
  sctp_bind_addr_conflict+0x22a/0x3b0 net/sctp/bind_addr.c:390
  sctp_get_port_local+0x21eb/0x2440 net/sctp/socket.c:8452
  sctp_get_port net/sctp/socket.c:8523 [inline]
  sctp_listen_start net/sctp/socket.c:8567 [inline]
  sctp_inet_listen+0x710/0xfd0 net/sctp/socket.c:8636
  __sys_listen_socket net/socket.c:1912 [inline]
  __sys_listen net/socket.c:1927 [inline]
  __do_sys_listen net/socket.c:1932 [inline]
  __se_sys_listen net/socket.c:1930 [inline]
  __x64_sys_listen+0x343/0x4c0 net/socket.c:1930
  x64_sys_call+0x271d/0x3e20 arch/x86/include/generated/asm/syscalls_64.h:51
  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
  do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Local variable addr.i.i created at:
  sctp_get_port net/sctp/socket.c:8515 [inline]
  sctp_listen_start net/sctp/socket.c:8567 [inline]
  sctp_inet_listen+0x650/0xfd0 net/sctp/socket.c:8636
  __sys_listen_socket net/socket.c:1912 [inline]
  __sys_listen net/socket.c:1927 [inline]
  __do_sys_listen net/socket.c:1932 [inline]
  __se_sys_listen net/socket.c:1930 [inline]
  __x64_sys_listen+0x343/0x4c0 net/socket.c:1930</Note>
    </Notes>
    <CVE>CVE-2025-39812</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix potential warning in trace_printk_seq during ftrace_dump

When calling ftrace_dump_one() concurrently with reading trace_pipe,
a WARN_ON_ONCE() in trace_printk_seq() can be triggered due to a race
condition.

The issue occurs because:

CPU0 (ftrace_dump)                              CPU1 (reader)
echo z &gt; /proc/sysrq-trigger

!trace_empty(&amp;iter)
trace_iterator_reset(&amp;iter) &lt;- len = size = 0
                                                cat /sys/kernel/tracing/trace_pipe
trace_find_next_entry_inc(&amp;iter)
  __find_next_entry
    ring_buffer_empty_cpu &lt;- all empty
  return NULL

trace_printk_seq(&amp;iter.seq)
  WARN_ON_ONCE(s-&gt;seq.len &gt;= s-&gt;seq.size)

In the context between trace_empty() and trace_find_next_entry_inc()
during ftrace_dump, the ring buffer data was consumed by other readers.
This caused trace_find_next_entry_inc to return NULL, failing to populate
`iter.seq`. At this point, due to the prior trace_iterator_reset, both
`iter.seq.len` and `iter.seq.size` were set to 0. Since they are equal,
the WARN_ON_ONCE condition is triggered.

Move the trace_printk_seq() into the if block that checks to make sure the
return value of trace_find_next_entry_inc() is non-NULL in
ftrace_dump_one(), ensuring the 'iter.seq' is properly populated before
subsequent operations.</Note>
    </Notes>
    <CVE>CVE-2025-39813</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: use array_index_nospec with indices that come from guest

min and dest_id are guest-controlled indices. Using array_index_nospec()
after the bounds checks clamps these values to mitigate speculative execution
side-channels.</Note>
    </Notes>
    <CVE>CVE-2025-39823</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: asus: fix UAF via HID_CLAIMED_INPUT validation

After hid_hw_start() is called hidinput_connect() will eventually be
called to set up the device with the input layer since the
HID_CONNECT_DEFAULT connect mask is used. During hidinput_connect()
all input and output reports are processed and corresponding hid_inputs
are allocated and configured via hidinput_configure_usages(). This
process involves slot tagging report fields and configuring usages
by setting relevant bits in the capability bitmaps. However it is possible
that the capability bitmaps are not set at all leading to the subsequent
hidinput_has_been_populated() check to fail leading to the freeing of the
hid_input and the underlying input device.

This becomes problematic because a malicious HID device like a
ASUS ROG N-Key keyboard can trigger the above scenario via a
specially crafted descriptor which then leads to a user-after-free
when the name of the freed input device is written to later on after
hid_hw_start(). Below, report 93 intentionally utilises the
HID_UP_UNDEFINED Usage Page which is skipped during usage
configuration, leading to the frees.

0x05, 0x0D,        // Usage Page (Digitizer)
0x09, 0x05,        // Usage (Touch Pad)
0xA1, 0x01,        // Collection (Application)
0x85, 0x0D,        //   Report ID (13)
0x06, 0x00, 0xFF,  //   Usage Page (Vendor Defined 0xFF00)
0x09, 0xC5,        //   Usage (0xC5)
0x15, 0x00,        //   Logical Minimum (0)
0x26, 0xFF, 0x00,  //   Logical Maximum (255)
0x75, 0x08,        //   Report Size (8)
0x95, 0x04,        //   Report Count (4)
0xB1, 0x02,        //   Feature (Data,Var,Abs)
0x85, 0x5D,        //   Report ID (93)
0x06, 0x00, 0x00,  //   Usage Page (Undefined)
0x09, 0x01,        //   Usage (0x01)
0x15, 0x00,        //   Logical Minimum (0)
0x26, 0xFF, 0x00,  //   Logical Maximum (255)
0x75, 0x08,        //   Report Size (8)
0x95, 0x1B,        //   Report Count (27)
0x81, 0x02,        //   Input (Data,Var,Abs)
0xC0,              // End Collection

Below is the KASAN splat after triggering the UAF:

[   21.672709] ==================================================================
[   21.673700] BUG: KASAN: slab-use-after-free in asus_probe+0xeeb/0xf80
[   21.673700] Write of size 8 at addr ffff88810a0ac000 by task kworker/1:2/54
[   21.673700]
[   21.673700] CPU: 1 UID: 0 PID: 54 Comm: kworker/1:2 Not tainted 6.16.0-rc4-g9773391cf4dd-dirty #36 PREEMPT(voluntary)
[   21.673700] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
[   21.673700] Call Trace:
[   21.673700]  &lt;TASK&gt;
[   21.673700]  dump_stack_lvl+0x5f/0x80
[   21.673700]  print_report+0xd1/0x660
[   21.673700]  kasan_report+0xe5/0x120
[   21.673700]  __asan_report_store8_noabort+0x1b/0x30
[   21.673700]  asus_probe+0xeeb/0xf80
[   21.673700]  hid_device_probe+0x2ee/0x700
[   21.673700]  really_probe+0x1c6/0x6b0
[   21.673700]  __driver_probe_device+0x24f/0x310
[   21.673700]  driver_probe_device+0x4e/0x220
[...]
[   21.673700]
[   21.673700] Allocated by task 54:
[   21.673700]  kasan_save_stack+0x3d/0x60
[   21.673700]  kasan_save_track+0x18/0x40
[   21.673700]  kasan_save_alloc_info+0x3b/0x50
[   21.673700]  __kasan_kmalloc+0x9c/0xa0
[   21.673700]  __kmalloc_cache_noprof+0x139/0x340
[   21.673700]  input_allocate_device+0x44/0x370
[   21.673700]  hidinput_connect+0xcb6/0x2630
[   21.673700]  hid_connect+0xf74/0x1d60
[   21.673700]  hid_hw_start+0x8c/0x110
[   21.673700]  asus_probe+0x5a3/0xf80
[   21.673700]  hid_device_probe+0x2ee/0x700
[   21.673700]  really_probe+0x1c6/0x6b0
[   21.673700]  __driver_probe_device+0x24f/0x310
[   21.673700]  driver_probe_device+0x4e/0x220
[...]
[   21.673700]
[   21.673700] Freed by task 54:
[   21.673700]  kasan_save_stack+0x3d/0x60
[   21.673700]  kasan_save_track+0x18/0x40
[   21.673700]  kasan_save_free_info+0x3f/0x60
[   21.673700]  __kasan_slab_free+0x3c/0x50
[   21.673700]  kfre
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-39824</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 race with concurrent opens in rename(2)

Besides sending the rename request to the server, the rename process
also involves closing any deferred close, waiting for outstanding I/O
to complete as well as marking all existing open handles as deleted to
prevent them from deferring closes, which increases the race window
for potential concurrent opens on the target file.

Fix this by unhashing the dentry in advance to prevent any concurrent
opens on the target.</Note>
    </Notes>
    <CVE>CVE-2025-39825</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: rose: convert 'use' field to refcount_t

The 'use' field in struct rose_neigh is used as a reference counter but
lacks atomicity. This can lead to race conditions where a rose_neigh
structure is freed while still being referenced by other code paths.

For example, when rose_neigh-&gt;use becomes zero during an ioctl operation
via rose_rt_ioctl(), the structure may be removed while its timer is
still active, potentially causing use-after-free issues.

This patch changes the type of 'use' from unsigned short to refcount_t and
updates all code paths to use rose_neigh_hold() and rose_neigh_put() which
operate reference counts atomically.</Note>
    </Notes>
    <CVE>CVE-2025-39826</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: rose: include node references in rose_neigh refcount

Current implementation maintains two separate reference counting
mechanisms: the 'count' field in struct rose_neigh tracks references from
rose_node structures, while the 'use' field (now refcount_t) tracks
references from rose_sock.

This patch merges these two reference counting systems using 'use' field
for proper reference management. Specifically, this patch adds incrementing
and decrementing of rose_neigh-&gt;use when rose_neigh-&gt;count is incremented
or decremented.

This patch also modifies rose_rt_free(), rose_rt_device_down() and
rose_clear_route() to properly release references to rose_neigh objects
before freeing a rose_node through rose_remove_node().

These changes ensure rose_neigh structures are properly freed only when
all references, including those from rose_node structures, are released.
As a result, this resolves a slab-use-after-free issue reported by Syzbot.</Note>
    </Notes>
    <CVE>CVE-2025-39827</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:

atm: atmtcp: Prevent arbitrary write in atmtcp_recv_control().

syzbot reported the splat below. [0]

When atmtcp_v_open() or atmtcp_v_close() is called via connect()
or close(), atmtcp_send_control() is called to send an in-kernel
special message.

The message has ATMTCP_HDR_MAGIC in atmtcp_control.hdr.length.
Also, a pointer of struct atm_vcc is set to atmtcp_control.vcc.

The notable thing is struct atmtcp_control is uAPI but has a
space for an in-kernel pointer.

  struct atmtcp_control {
  	struct atmtcp_hdr hdr;	/* must be first */
  ...
  	atm_kptr_t vcc;		/* both directions */
  ...
  } __ATM_API_ALIGN;

  typedef struct { unsigned char _[8]; } __ATM_API_ALIGN atm_kptr_t;

The special message is processed in atmtcp_recv_control() called
from atmtcp_c_send().

atmtcp_c_send() is vcc-&gt;dev-&gt;ops-&gt;send() and called from 2 paths:

  1. .ndo_start_xmit() (vcc-&gt;send() == atm_send_aal0())
  2. vcc_sendmsg()

The problem is sendmsg() does not validate the message length and
userspace can abuse atmtcp_recv_control() to overwrite any kptr
by atmtcp_control.

Let's add a new -&gt;pre_send() hook to validate messages from sendmsg().

[0]:
Oops: general protection fault, probably for non-canonical address 0xdffffc00200000ab: 0000 [#1] SMP KASAN PTI
KASAN: probably user-memory-access in range [0x0000000100000558-0x000000010000055f]
CPU: 0 UID: 0 PID: 5865 Comm: syz-executor331 Not tainted 6.17.0-rc1-syzkaller-00215-gbab3ce404553 #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025
RIP: 0010:atmtcp_recv_control drivers/atm/atmtcp.c:93 [inline]
RIP: 0010:atmtcp_c_send+0x1da/0x950 drivers/atm/atmtcp.c:297
Code: 4d 8d 75 1a 4c 89 f0 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 15 06 00 00 41 0f b7 1e 4d 8d b7 60 05 00 00 4c 89 f0 48 c1 e8 03 &lt;42&gt; 0f b6 04 20 84 c0 0f 85 13 06 00 00 66 41 89 1e 4d 8d 75 1c 4c
RSP: 0018:ffffc90003f5f810 EFLAGS: 00010203
RAX: 00000000200000ab RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffff88802a510000 RSI: 00000000ffffffff RDI: ffff888030a6068c
RBP: ffff88802699fb40 R08: ffff888030a606eb R09: 1ffff1100614c0dd
R10: dffffc0000000000 R11: ffffffff8718fc40 R12: dffffc0000000000
R13: ffff888030a60680 R14: 000000010000055f R15: 00000000ffffffff
FS:  00007f8d7e9236c0(0000) GS:ffff888125c1c000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000045ad50 CR3: 0000000075bde000 CR4: 00000000003526f0
Call Trace:
 &lt;TASK&gt;
 vcc_sendmsg+0xa10/0xc60 net/atm/common.c:645
 sock_sendmsg_nosec net/socket.c:714 [inline]
 __sock_sendmsg+0x219/0x270 net/socket.c:729
 ____sys_sendmsg+0x505/0x830 net/socket.c:2614
 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668
 __sys_sendmsg net/socket.c:2700 [inline]
 __do_sys_sendmsg net/socket.c:2705 [inline]
 __se_sys_sendmsg net/socket.c:2703 [inline]
 __x64_sys_sendmsg+0x19b/0x260 net/socket.c:2703
 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:0x7f8d7e96a4a9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 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 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f8d7e923198 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007f8d7e9f4308 RCX: 00007f8d7e96a4a9
RDX: 0000000000000000 RSI: 0000200000000240 RDI: 0000000000000005
RBP: 00007f8d7e9f4300 R08: 65732f636f72702f R09: 65732f636f72702f
R10: 65732f636f72702f R11: 0000000000000246 R12: 00007f8d7e9c10ac
R13: 00007f8d7e9231a0 R14: 0000200000000200 R15: 0000200000000250
 &lt;/TASK&gt;
Modules linked in:</Note>
    </Notes>
    <CVE>CVE-2025-39828</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 lockdep assertion on sync reset unload event

Fix lockdep assertion triggered during sync reset unload event. When the
sync reset flow is initiated using the devlink reload fw_activate
option, the PF already holds the devlink lock while handling unload
event. In this case, delegate sync reset unload event handling back to
the devlink callback process to avoid double-locking and resolve the
lockdep warning.

Kernel log:
WARNING: CPU: 9 PID: 1578 at devl_assert_locked+0x31/0x40
[...]
Call Trace:
&lt;TASK&gt;
 mlx5_unload_one_devl_locked+0x2c/0xc0 [mlx5_core]
 mlx5_sync_reset_unload_event+0xaf/0x2f0 [mlx5_core]
 process_one_work+0x222/0x640
 worker_thread+0x199/0x350
 kthread+0x10b/0x230
 ? __pfx_worker_thread+0x10/0x10
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x8e/0x100
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1a/0x30
&lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2025-39832</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mISDN: hfcpci: Fix warning when deleting uninitialized timer

With CONFIG_DEBUG_OBJECTS_TIMERS unloading hfcpci module leads
to the following splat:

[  250.215892] ODEBUG: assert_init not available (active state 0) object: ffffffffc01a3dc0 object type: timer_list hint: 0x0
[  250.217520] WARNING: CPU: 0 PID: 233 at lib/debugobjects.c:612 debug_print_object+0x1b6/0x2c0
[  250.218775] Modules linked in: hfcpci(-) mISDN_core
[  250.219537] CPU: 0 UID: 0 PID: 233 Comm: rmmod Not tainted 6.17.0-rc2-g6f713187ac98 #2 PREEMPT(voluntary)
[  250.220940] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[  250.222377] RIP: 0010:debug_print_object+0x1b6/0x2c0
[  250.223131] Code: fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 75 4f 41 56 48 8b 14 dd a0 4e 01 9f 48 89 ee 48 c7 c7 20 46 01 9f e8 cb 84d
[  250.225805] RSP: 0018:ffff888015ea7c08 EFLAGS: 00010286
[  250.226608] RAX: 0000000000000000 RBX: 0000000000000005 RCX: ffffffff9be93a95
[  250.227708] RDX: 1ffff1100d945138 RSI: 0000000000000008 RDI: ffff88806ca289c0
[  250.228993] RBP: ffffffff9f014a00 R08: 0000000000000001 R09: ffffed1002bd4f39
[  250.230043] R10: ffff888015ea79cf R11: 0000000000000001 R12: 0000000000000001
[  250.231185] R13: ffffffff9eea0520 R14: 0000000000000000 R15: ffff888015ea7cc8
[  250.232454] FS:  00007f3208f01540(0000) GS:ffff8880caf5a000(0000) knlGS:0000000000000000
[  250.233851] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  250.234856] CR2: 00007f32090a7421 CR3: 0000000004d63000 CR4: 00000000000006f0
[  250.236117] Call Trace:
[  250.236599]  &lt;TASK&gt;
[  250.236967]  ? trace_irq_enable.constprop.0+0xd4/0x130
[  250.237920]  debug_object_assert_init+0x1f6/0x310
[  250.238762]  ? __pfx_debug_object_assert_init+0x10/0x10
[  250.239658]  ? __lock_acquire+0xdea/0x1c70
[  250.240369]  __try_to_del_timer_sync+0x69/0x140
[  250.241172]  ? __pfx___try_to_del_timer_sync+0x10/0x10
[  250.242058]  ? __timer_delete_sync+0xc6/0x120
[  250.242842]  ? lock_acquire+0x30/0x80
[  250.243474]  ? __timer_delete_sync+0xc6/0x120
[  250.244262]  __timer_delete_sync+0x98/0x120
[  250.245015]  HFC_cleanup+0x10/0x20 [hfcpci]
[  250.245704]  __do_sys_delete_module+0x348/0x510
[  250.246461]  ? __pfx___do_sys_delete_module+0x10/0x10
[  250.247338]  do_syscall_64+0xc1/0x360
[  250.247924]  entry_SYSCALL_64_after_hwframe+0x77/0x7f

Fix this by initializing hfc_tl timer with DEFINE_TIMER macro.
Also, use mod_timer instead of manual timeout update.</Note>
    </Notes>
    <CVE>CVE-2025-39833</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

xfs: do not propagate ENODATA disk errors into xattr code

ENODATA (aka ENOATTR) has a very specific meaning in the xfs xattr code;
namely, that the requested attribute name could not be found.

However, a medium error from disk may also return ENODATA. At best,
this medium error may escape to userspace as "attribute not found"
when in fact it's an IO (disk) error.

At worst, we may oops in xfs_attr_leaf_get() when we do:

	error = xfs_attr_leaf_hasname(args, &amp;bp);
	if (error == -ENOATTR)  {
		xfs_trans_brelse(args-&gt;trans, bp);
		return error;
	}

because an ENODATA/ENOATTR error from disk leaves us with a null bp,
and the xfs_trans_brelse will then null-deref it.

As discussed on the list, we really need to modify the lower level
IO functions to trap all disk errors and ensure that we don't let
unique errors like this leak up into higher xfs functions - many
like this should be remapped to EIO.

However, this patch directly addresses a reported bug in the xattr
code, and should be safe to backport to stable kernels. A larger-scope
patch to handle more unique errors at lower levels can follow later.

(Note, prior to 07120f1abdff we did not oops, but we did return the
wrong error code to userspace.)</Note>
    </Notes>
    <CVE>CVE-2025-39835</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: prevent NULL pointer dereference in UTF16 conversion

There can be a NULL pointer dereference bug here. NULL is passed to
__cifs_sfu_make_node without checks, which passes it unchecked to
cifs_strndup_to_utf16, which in turn passes it to
cifs_local_to_utf16_bytes where '*from' is dereferenced, causing a crash.

This patch adds a check for NULL 'src' in cifs_strndup_to_utf16 and
returns NULL early to prevent dereferencing NULL pointer.

Found by Linux Verification Center (linuxtesting.org) with SVACE</Note>
    </Notes>
    <CVE>CVE-2025-39838</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

batman-adv: fix OOB read/write in network-coding decode

batadv_nc_skb_decode_packet() trusts coded_len and checks only against
skb-&gt;len. XOR starts at sizeof(struct batadv_unicast_packet), reducing
payload headroom, and the source skb length is not verified, allowing an
out-of-bounds read and a small out-of-bounds write.

Validate that coded_len fits within the payload area of both destination
and source sk_buffs before XORing.</Note>
    </Notes>
    <CVE>CVE-2025-39839</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix buffer free/clear order in deferred receive path

Fix a use-after-free window by correcting the buffer release sequence in
the deferred receive path. The code freed the RQ buffer first and only
then cleared the context pointer under the lock. Concurrent paths (e.g.,
ABTS and the repost path) also inspect and release the same pointer under
the lock, so the old order could lead to double-free/UAF.

Note that the repost path already uses the correct pattern: detach the
pointer under the lock, then free it after dropping the lock. The
deferred path should do the same.</Note>
    </Notes>
    <CVE>CVE-2025-39841</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ocfs2: prevent release journal inode after journal shutdown

Before calling ocfs2_delete_osb(), ocfs2_journal_shutdown() has already
been executed in ocfs2_dismount_volume(), so osb-&gt;journal must be NULL. 
Therefore, the following calltrace will inevitably fail when it reaches
jbd2_journal_release_jbd_inode().

ocfs2_dismount_volume()-&gt;
  ocfs2_delete_osb()-&gt;
    ocfs2_free_slot_info()-&gt;
      __ocfs2_free_slot_info()-&gt;
        evict()-&gt;
          ocfs2_evict_inode()-&gt;
            ocfs2_clear_inode()-&gt;
	      jbd2_journal_release_jbd_inode(osb-&gt;journal-&gt;j_journal,

Adding osb-&gt;journal checks will prevent null-ptr-deref during the above
execution path.</Note>
    </Notes>
    <CVE>CVE-2025-39842</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: move page table sync declarations to linux/pgtable.h

During our internal testing, we started observing intermittent boot
failures when the machine uses 4-level paging and has a large amount of
persistent memory:

  BUG: unable to handle page fault for address: ffffe70000000034
  #PF: supervisor write access in kernel mode
  #PF: error_code(0x0002) - not-present page
  PGD 0 P4D 0 
  Oops: 0002 [#1] SMP NOPTI
  RIP: 0010:__init_single_page+0x9/0x6d
  Call Trace:
   &lt;TASK&gt;
   __init_zone_device_page+0x17/0x5d
   memmap_init_zone_device+0x154/0x1bb
   pagemap_range+0x2e0/0x40f
   memremap_pages+0x10b/0x2f0
   devm_memremap_pages+0x1e/0x60
   dev_dax_probe+0xce/0x2ec [device_dax]
   dax_bus_probe+0x6d/0xc9
   [... snip ...]
   &lt;/TASK&gt;

It turns out that the kernel panics while initializing vmemmap (struct
page array) when the vmemmap region spans two PGD entries, because the new
PGD entry is only installed in init_mm.pgd, but not in the page tables of
other tasks.

And looking at __populate_section_memmap():
  if (vmemmap_can_optimize(altmap, pgmap))                                
          // does not sync top level page tables
          r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap);
  else                                                                    
          // sync top level page tables in x86
          r = vmemmap_populate(start, end, nid, altmap);

In the normal path, vmemmap_populate() in arch/x86/mm/init_64.c
synchronizes the top level page table (See commit 9b861528a801 ("x86-64,
mem: Update all PGDs for direct mapping and vmemmap mapping changes")) so
that all tasks in the system can see the new vmemmap area.

However, when vmemmap_can_optimize() returns true, the optimized path
skips synchronization of top-level page tables.  This is because
vmemmap_populate_compound_pages() is implemented in core MM code, which
does not handle synchronization of the top-level page tables.  Instead,
the core MM has historically relied on each architecture to perform this
synchronization manually.

We're not the first party to encounter a crash caused by not-sync'd top
level page tables: earlier this year, Gwan-gyeong Mun attempted to address
the issue [1] [2] after hitting a kernel panic when x86 code accessed the
vmemmap area before the corresponding top-level entries were synced.  At
that time, the issue was believed to be triggered only when struct page
was enlarged for debugging purposes, and the patch did not get further
updates.

It turns out that current approach of relying on each arch to handle the
page table sync manually is fragile because 1) it's easy to forget to sync
the top level page table, and 2) it's also easy to overlook that the
kernel should not access the vmemmap and direct mapping areas before the
sync.

# The solution: Make page table sync more code robust and harder to miss

To address this, Dave Hansen suggested [3] [4] introducing
{pgd,p4d}_populate_kernel() for updating kernel portion of the page tables
and allow each architecture to explicitly perform synchronization when
installing top-level entries.  With this approach, we no longer need to
worry about missing the sync step, reducing the risk of future
regressions.

The new interface reuses existing ARCH_PAGE_TABLE_SYNC_MASK,
PGTBL_P*D_MODIFIED and arch_sync_kernel_mappings() facility used by
vmalloc and ioremap to synchronize page tables.

pgd_populate_kernel() looks like this:
static inline void pgd_populate_kernel(unsigned long addr, pgd_t *pgd,
                                       p4d_t *p4d)
{
        pgd_populate(&amp;init_mm, pgd, p4d);
        if (ARCH_PAGE_TABLE_SYNC_MASK &amp; PGTBL_PGD_MODIFIED)
                arch_sync_kernel_mappings(addr, addr);
}

It is worth noting that vmalloc() and apply_to_range() carefully
synchronizes page tables by calling p*d_alloc_track() and
arch_sync_kernel_mappings(), and thus they are not affected by
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-39844</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/64: define ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings()

Define ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() to ensure
page tables are properly synchronized when calling p*d_populate_kernel().

For 5-level paging, synchronization is performed via
pgd_populate_kernel().  In 4-level paging, pgd_populate() is a no-op, so
synchronization is instead performed at the P4D level via
p4d_populate_kernel().

This fixes intermittent boot failures on systems using 4-level paging and
a large amount of persistent memory:

  BUG: unable to handle page fault for address: ffffe70000000034
  #PF: supervisor write access in kernel mode
  #PF: error_code(0x0002) - not-present page
  PGD 0 P4D 0
  Oops: 0002 [#1] SMP NOPTI
  RIP: 0010:__init_single_page+0x9/0x6d
  Call Trace:
   &lt;TASK&gt;
   __init_zone_device_page+0x17/0x5d
   memmap_init_zone_device+0x154/0x1bb
   pagemap_range+0x2e0/0x40f
   memremap_pages+0x10b/0x2f0
   devm_memremap_pages+0x1e/0x60
   dev_dax_probe+0xce/0x2ec [device_dax]
   dax_bus_probe+0x6d/0xc9
   [... snip ...]
   &lt;/TASK&gt;

It also fixes a crash in vmemmap_set_pmd() caused by accessing vmemmap
before sync_global_pgds() [1]:

  BUG: unable to handle page fault for address: ffffeb3ff1200000
  #PF: supervisor write access in kernel mode
  #PF: error_code(0x0002) - not-present page
  PGD 0 P4D 0
  Oops: Oops: 0002 [#1] PREEMPT SMP NOPTI
  Tainted: [W]=WARN
  RIP: 0010:vmemmap_set_pmd+0xff/0x230
   &lt;TASK&gt;
   vmemmap_populate_hugepages+0x176/0x180
   vmemmap_populate+0x34/0x80
   __populate_section_memmap+0x41/0x90
   sparse_add_section+0x121/0x3e0
   __add_pages+0xba/0x150
   add_pages+0x1d/0x70
   memremap_pages+0x3dc/0x810
   devm_memremap_pages+0x1c/0x60
   xe_devm_add+0x8b/0x100 [xe]
   xe_tile_init_noalloc+0x6a/0x70 [xe]
   xe_device_probe+0x48c/0x740 [xe]
   [... snip ...]</Note>
    </Notes>
    <CVE>CVE-2025-39845</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

pcmcia: Fix a NULL pointer dereference in __iodyn_find_io_region()

In __iodyn_find_io_region(), pcmcia_make_resource() is assigned to
res and used in pci_bus_alloc_resource(). There is a dereference of res
in pci_bus_alloc_resource(), which could lead to a NULL pointer
dereference on failure of pcmcia_make_resource().

Fix this bug by adding a check of res.</Note>
    </Notes>
    <CVE>CVE-2025-39846</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ppp: fix memory leak in pad_compress_skb

If alloc_skb() fails in pad_compress_skb(), it returns NULL without
releasing the old skb. The caller does:

    skb = pad_compress_skb(ppp, skb);
    if (!skb)
        goto drop;

drop:
    kfree_skb(skb);

When pad_compress_skb() returns NULL, the reference to the old skb is
lost and kfree_skb(skb) ends up doing nothing, leading to a memory leak.

Align pad_compress_skb() semantics with realloc(): only free the old
skb if allocation and compression succeed.  At the call site, use the
new_skb variable so the original skb is not lost when pad_compress_skb()
fails.</Note>
    </Notes>
    <CVE>CVE-2025-39847</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ax25: properly unshare skbs in ax25_kiss_rcv()

Bernard Pidoux reported a regression apparently caused by commit
c353e8983e0d ("net: introduce per netns packet chains").

skb-&gt;dev becomes NULL and we crash in __netif_receive_skb_core().

Before above commit, different kind of bugs or corruptions could happen
without a major crash.

But the root cause is that ax25_kiss_rcv() can queue/mangle input skb
without checking if this skb is shared or not.

Many thanks to Bernard Pidoux for his help, diagnosis and tests.

We had a similar issue years ago fixed with commit 7aaed57c5c28
("phonet: properly unshare skbs in phonet_rcv()").</Note>
    </Notes>
    <CVE>CVE-2025-39848</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: sme: cap SSID length in __cfg80211_connect_result()

If the ssid-&gt;datalen is more than IEEE80211_MAX_SSID_LEN (32) it would
lead to memory corruption so add some bounds checking.</Note>
    </Notes>
    <CVE>CVE-2025-39849</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix NPD in {arp,neigh}_reduce() when using nexthop objects

When the "proxy" option is enabled on a VXLAN device, the device will
suppress ARP requests and IPv6 Neighbor Solicitation messages if it is
able to reply on behalf of the remote host. That is, if a matching and
valid neighbor entry is configured on the VXLAN device whose MAC address
is not behind the "any" remote (0.0.0.0 / ::).

The code currently assumes that the FDB entry for the neighbor's MAC
address points to a valid remote destination, but this is incorrect if
the entry is associated with an FDB nexthop group. This can result in a
NPD [1][3] which can be reproduced using [2][4].

Fix by checking that the remote destination exists before dereferencing
it.

[1]
BUG: kernel NULL pointer dereference, address: 0000000000000000
[...]
CPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014
RIP: 0010:vxlan_xmit+0xb58/0x15f0
[...]
Call Trace:
 &lt;TASK&gt;
 dev_hard_start_xmit+0x5d/0x1c0
 __dev_queue_xmit+0x246/0xfd0
 packet_sendmsg+0x113a/0x1850
 __sock_sendmsg+0x38/0x70
 __sys_sendto+0x126/0x180
 __x64_sys_sendto+0x24/0x30
 do_syscall_64+0xa4/0x260
 entry_SYSCALL_64_after_hwframe+0x4b/0x53

[2]
 #!/bin/bash

 ip address add 192.0.2.1/32 dev lo

 ip nexthop add id 1 via 192.0.2.2 fdb
 ip nexthop add id 10 group 1 fdb

 ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy

 ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0

 bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10

 arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3

[3]
BUG: kernel NULL pointer dereference, address: 0000000000000000
[...]
CPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014
RIP: 0010:vxlan_xmit+0x803/0x1600
[...]
Call Trace:
 &lt;TASK&gt;
 dev_hard_start_xmit+0x5d/0x1c0
 __dev_queue_xmit+0x246/0xfd0
 ip6_finish_output2+0x210/0x6c0
 ip6_finish_output+0x1af/0x2b0
 ip6_mr_output+0x92/0x3e0
 ip6_send_skb+0x30/0x90
 rawv6_sendmsg+0xe6e/0x12e0
 __sock_sendmsg+0x38/0x70
 __sys_sendto+0x126/0x180
 __x64_sys_sendto+0x24/0x30
 do_syscall_64+0xa4/0x260
 entry_SYSCALL_64_after_hwframe+0x4b/0x53
RIP: 0033:0x7f383422ec77

[4]
 #!/bin/bash

 ip address add 2001:db8:1::1/128 dev lo

 ip nexthop add id 1 via 2001:db8:1::1 fdb
 ip nexthop add id 10 group 1 fdb

 ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy

 ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0

 bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10

 ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0</Note>
    </Notes>
    <CVE>CVE-2025-39850</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix NPD when refreshing an FDB entry with a nexthop object

VXLAN FDB entries can point to either a remote destination or an FDB
nexthop group. The latter is usually used in EVPN deployments where
learning is disabled.

However, when learning is enabled, an incoming packet might try to
refresh an FDB entry that points to an FDB nexthop group and therefore
does not have a remote. Such packets should be dropped, but they are
only dropped after dereferencing the non-existent remote, resulting in a
NPD [1] which can be reproduced using [2].

Fix by dropping such packets earlier. Remove the misleading comment from
first_remote_rcu().

[1]
BUG: kernel NULL pointer dereference, address: 0000000000000000
[...]
CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014
RIP: 0010:vxlan_snoop+0x98/0x1e0
[...]
Call Trace:
 &lt;TASK&gt;
 vxlan_encap_bypass+0x209/0x240
 encap_bypass_if_local+0xb1/0x100
 vxlan_xmit_one+0x1375/0x17e0
 vxlan_xmit+0x6b4/0x15f0
 dev_hard_start_xmit+0x5d/0x1c0
 __dev_queue_xmit+0x246/0xfd0
 packet_sendmsg+0x113a/0x1850
 __sock_sendmsg+0x38/0x70
 __sys_sendto+0x126/0x180
 __x64_sys_sendto+0x24/0x30
 do_syscall_64+0xa4/0x260
 entry_SYSCALL_64_after_hwframe+0x4b/0x53

[2]
 #!/bin/bash

 ip address add 192.0.2.1/32 dev lo
 ip address add 192.0.2.2/32 dev lo

 ip nexthop add id 1 via 192.0.2.3 fdb
 ip nexthop add id 10 group 1 fdb

 ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass
 ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning

 bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020
 bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10

 mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q</Note>
    </Notes>
    <CVE>CVE-2025-39851</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 potential invalid access when MAC list is empty

list_first_entry() never returns NULL - if the list is empty, it still
returns a pointer to an invalid object, leading to potential invalid
memory access when dereferenced.

Fix this by using list_first_entry_or_null instead of list_first_entry.</Note>
    </Notes>
    <CVE>CVE-2025-39853</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 NULL access of tx-&gt;in_use in ice_ll_ts_intr

Recent versions of the E810 firmware have support for an extra interrupt to
handle report of the "low latency" Tx timestamps coming from the
specialized low latency firmware interface. Instead of polling the
registers, software can wait until the low latency interrupt is fired.

This logic makes use of the Tx timestamp tracking structure, ice_ptp_tx, as
it uses the same "ready" bitmap to track which Tx timestamps complete.

Unfortunately, the ice_ll_ts_intr() function does not check if the
tracker is initialized before its first access. This results in NULL
dereference or use-after-free bugs similar to the issues fixed in the
ice_ptp_ts_irq() function.

Fix this by only checking the in_use bitmap (and other fields) if the
tracker is marked as initialized. The reset flow will clear the init field
under lock before it tears the tracker down, thus preventing any
use-after-free or NULL access.</Note>
    </Notes>
    <CVE>CVE-2025-39854</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 one NULL pointer dereference in smc_ib_is_sg_need_sync()

BUG: kernel NULL pointer dereference, address: 00000000000002ec
PGD 0 P4D 0
Oops: Oops: 0000 [#1] SMP PTI
CPU: 28 UID: 0 PID: 343 Comm: kworker/28:1 Kdump: loaded Tainted: G        OE       6.17.0-rc2+ #9 NONE
Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
Workqueue: smc_hs_wq smc_listen_work [smc]
RIP: 0010:smc_ib_is_sg_need_sync+0x9e/0xd0 [smc]
...
Call Trace:
 &lt;TASK&gt;
 smcr_buf_map_link+0x211/0x2a0 [smc]
 __smc_buf_create+0x522/0x970 [smc]
 smc_buf_create+0x3a/0x110 [smc]
 smc_find_rdma_v2_device_serv+0x18f/0x240 [smc]
 ? smc_vlan_by_tcpsk+0x7e/0xe0 [smc]
 smc_listen_find_device+0x1dd/0x2b0 [smc]
 smc_listen_work+0x30f/0x580 [smc]
 process_one_work+0x18c/0x340
 worker_thread+0x242/0x360
 kthread+0xe7/0x220
 ret_from_fork+0x13a/0x160
 ret_from_fork_asm+0x1a/0x30
 &lt;/TASK&gt;

If the software RoCE device is used, ibdev-&gt;dma_device is a null pointer.
As a result, the problem occurs. Null pointer detection is added to
prevent problems.</Note>
    </Notes>
    <CVE>CVE-2025-39857</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 use-after-free in l2cap_sock_cleanup_listen()

syzbot reported the splat below without a repro.

In the splat, a single thread calling bt_accept_dequeue() freed sk
and touched it after that.

The root cause would be the racy l2cap_sock_cleanup_listen() call
added by the cited commit.

bt_accept_dequeue() is called under lock_sock() except for
l2cap_sock_release().

Two threads could see the same socket during the list iteration
in bt_accept_dequeue():

  CPU1                        CPU2 (close())
  ----                        ----
  sock_hold(sk)               sock_hold(sk);
  lock_sock(sk)   &lt;-- block close()
  sock_put(sk)
  bt_accept_unlink(sk)
    sock_put(sk)  &lt;-- refcnt by bt_accept_enqueue()
  release_sock(sk)
                              lock_sock(sk)
                              sock_put(sk)
                              bt_accept_unlink(sk)
                                sock_put(sk)        &lt;-- last refcnt
                              bt_accept_unlink(sk)  &lt;-- UAF

Depending on the timing, the other thread could show up in the
"Freed by task" part.

Let's call l2cap_sock_cleanup_listen() under lock_sock() in
l2cap_sock_release().

[0]:
BUG: KASAN: slab-use-after-free in debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline]
BUG: KASAN: slab-use-after-free in do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115
Read of size 4 at addr ffff88803b7eb1c4 by task syz.5.3276/16995
CPU: 3 UID: 0 PID: 16995 Comm: syz.5.3276 Not tainted syzkaller #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
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:378 [inline]
 print_report+0xcd/0x630 mm/kasan/report.c:482
 kasan_report+0xe0/0x110 mm/kasan/report.c:595
 debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline]
 do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115
 spin_lock_bh include/linux/spinlock.h:356 [inline]
 release_sock+0x21/0x220 net/core/sock.c:3746
 bt_accept_dequeue+0x505/0x600 net/bluetooth/af_bluetooth.c:312
 l2cap_sock_cleanup_listen+0x5c/0x2a0 net/bluetooth/l2cap_sock.c:1451
 l2cap_sock_release+0x5c/0x210 net/bluetooth/l2cap_sock.c:1425
 __sock_release+0xb3/0x270 net/socket.c:649
 sock_close+0x1c/0x30 net/socket.c:1439
 __fput+0x3ff/0xb70 fs/file_table.c:468
 task_work_run+0x14d/0x240 kernel/task_work.c:227
 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
 exit_to_user_mode_loop+0xeb/0x110 kernel/entry/common.c:43
 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline]
 syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline]
 syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline]
 do_syscall_64+0x3f6/0x4c0 arch/x86/entry/syscall_64.c:100
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f2accf8ebe9
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:00007ffdb6cb1378 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4
RAX: 0000000000000000 RBX: 00000000000426fb RCX: 00007f2accf8ebe9
RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003
RBP: 00007f2acd1b7da0 R08: 0000000000000001 R09: 00000012b6cb166f
R10: 0000001b30e20000 R11: 0000000000000246 R12: 00007f2acd1b609c
R13: 00007f2acd1b6090 R14: ffffffffffffffff R15: 00007ffdb6cb1490
 &lt;/TASK&gt;

Allocated by task 5326:
 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:388 [inline]
 __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:405
 kasan_kmalloc include/linux/kasan.h:260 [inline]
 __do_kmalloc_node mm/slub.c:4365 [inline]
 __kmalloc_nopro
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-39860</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: vhci: Prevent use-after-free by removing debugfs files early

Move the creation of debugfs files into a dedicated function, and ensure
they are explicitly removed during vhci_release(), before associated
data structures are freed.

Previously, debugfs files such as "force_suspend", "force_wakeup", and
others were created under hdev-&gt;debugfs but not removed in
vhci_release(). Since vhci_release() frees the backing vhci_data
structure, any access to these files after release would result in
use-after-free errors.

Although hdev-&gt;debugfs is later freed in hci_release_dev(), user can
access files after vhci_data is freed but before hdev-&gt;debugfs is
released.</Note>
    </Notes>
    <CVE>CVE-2025-39861</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info work

The brcmf_btcoex_detach() only shuts down the btcoex timer, if the
flag timer_on is false. However, the brcmf_btcoex_timerfunc(), which
runs as timer handler, sets timer_on to false. This creates critical
race conditions:

1.If brcmf_btcoex_detach() is called while brcmf_btcoex_timerfunc()
is executing, it may observe timer_on as false and skip the call to
timer_shutdown_sync().

2.The brcmf_btcoex_timerfunc() may then reschedule the brcmf_btcoex_info
worker after the cancel_work_sync() has been executed, resulting in
use-after-free bugs.

The use-after-free bugs occur in two distinct scenarios, depending on
the timing of when the brcmf_btcoex_info struct is freed relative to
the execution of its worker thread.

Scenario 1: Freed before the worker is scheduled

The brcmf_btcoex_info is deallocated before the worker is scheduled.
A race condition can occur when schedule_work(&amp;bt_local-&gt;work) is
called after the target memory has been freed. The sequence of events
is detailed below:

CPU0                           | CPU1
brcmf_btcoex_detach            | brcmf_btcoex_timerfunc
                               |   bt_local-&gt;timer_on = false;
  if (cfg-&gt;btcoex-&gt;timer_on)   |
    ...                        |
  cancel_work_sync();          |
  ...                          |
  kfree(cfg-&gt;btcoex); // FREE  |
                               |   schedule_work(&amp;bt_local-&gt;work); // USE

Scenario 2: Freed after the worker is scheduled

The brcmf_btcoex_info is freed after the worker has been scheduled
but before or during its execution. In this case, statements within
the brcmf_btcoex_handler() - such as the container_of macro and
subsequent dereferences of the brcmf_btcoex_info object will cause
a use-after-free access. The following timeline illustrates this
scenario:

CPU0                            | CPU1
brcmf_btcoex_detach             | brcmf_btcoex_timerfunc
                                |   bt_local-&gt;timer_on = false;
  if (cfg-&gt;btcoex-&gt;timer_on)    |
    ...                         |
  cancel_work_sync();           |
  ...                           |   schedule_work(); // Reschedule
                                |
  kfree(cfg-&gt;btcoex); // FREE   |   brcmf_btcoex_handler() // Worker
  /*                            |     btci = container_of(....); // USE
   The kfree() above could      |     ...
   also occur at any point      |     btci-&gt; // USE
   during the worker's execution|
   */                           |

To resolve the race conditions, drop the conditional check and call
timer_shutdown_sync() directly. It can deactivate the timer reliably,
regardless of its current state. Once stopped, the timer_on state is
then set to false.</Note>
    </Notes>
    <CVE>CVE-2025-39863</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 use-after-free in cmp_bss()

Following bss_free() quirk introduced in commit 776b3580178f
("cfg80211: track hidden SSID networks properly"), adjust
cfg80211_update_known_bss() to free the last beacon frame
elements only if they're not shared via the corresponding
'hidden_beacon_bss' pointer.</Note>
    </Notes>
    <CVE>CVE-2025-39864</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tee: fix NULL pointer dereference in tee_shm_put

tee_shm_put have NULL pointer dereference:

__optee_disable_shm_cache --&gt;
	shm = reg_pair_to_ptr(...);//shm maybe return NULL
        tee_shm_free(shm); --&gt;
		tee_shm_put(shm);//crash

Add check in tee_shm_put to fix it.

panic log:
Unable to handle kernel paging request at virtual address 0000000000100cca
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
user pgtable: 4k pages, 48-bit VAs, pgdp=0000002049d07000
[0000000000100cca] pgd=0000000000000000, p4d=0000000000000000
Internal error: Oops: 0000000096000004 [#1] SMP
CPU: 2 PID: 14442 Comm: systemd-sleep Tainted: P OE ------- ----
6.6.0-39-generic #38
Source Version: 938b255f6cb8817c95b0dd5c8c2944acfce94b07
Hardware name: greatwall GW-001Y1A-FTH, BIOS Great Wall BIOS V3.0
10/26/2022
pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : tee_shm_put+0x24/0x188
lr : tee_shm_free+0x14/0x28
sp : ffff001f98f9faf0
x29: ffff001f98f9faf0 x28: ffff0020df543cc0 x27: 0000000000000000
x26: ffff001f811344a0 x25: ffff8000818dac00 x24: ffff800082d8d048
x23: ffff001f850fcd18 x22: 0000000000000001 x21: ffff001f98f9fb88
x20: ffff001f83e76218 x19: ffff001f83e761e0 x18: 000000000000ffff
x17: 303a30303a303030 x16: 0000000000000000 x15: 0000000000000003
x14: 0000000000000001 x13: 0000000000000000 x12: 0101010101010101
x11: 0000000000000001 x10: 0000000000000001 x9 : ffff800080e08d0c
x8 : ffff001f98f9fb88 x7 : 0000000000000000 x6 : 0000000000000000
x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
x2 : ffff001f83e761e0 x1 : 00000000ffff001f x0 : 0000000000100cca
Call trace:
tee_shm_put+0x24/0x188
tee_shm_free+0x14/0x28
__optee_disable_shm_cache+0xa8/0x108
optee_shutdown+0x28/0x38
platform_shutdown+0x28/0x40
device_shutdown+0x144/0x2b0
kernel_power_off+0x3c/0x80
hibernate+0x35c/0x388
state_store+0x64/0x80
kobj_attr_store+0x14/0x28
sysfs_kf_write+0x48/0x60
kernfs_fop_write_iter+0x128/0x1c0
vfs_write+0x270/0x370
ksys_write+0x6c/0x100
__arm64_sys_write+0x20/0x30
invoke_syscall+0x4c/0x120
el0_svc_common.constprop.0+0x44/0xf0
do_el0_svc+0x24/0x38
el0_svc+0x24/0x88
el0t_64_sync_handler+0x134/0x150
el0t_64_sync+0x14c/0x15</Note>
    </Notes>
    <CVE>CVE-2025-39865</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: writeback: fix use-after-free in __mark_inode_dirty()

An use-after-free issue occurred when __mark_inode_dirty() get the
bdi_writeback that was in the progress of switching.

CPU: 1 PID: 562 Comm: systemd-random- Not tainted 6.6.56-gb4403bd46a8e #1
......
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __mark_inode_dirty+0x124/0x418
lr : __mark_inode_dirty+0x118/0x418
sp : ffffffc08c9dbbc0
........
Call trace:
 __mark_inode_dirty+0x124/0x418
 generic_update_time+0x4c/0x60
 file_modified+0xcc/0xd0
 ext4_buffered_write_iter+0x58/0x124
 ext4_file_write_iter+0x54/0x704
 vfs_write+0x1c0/0x308
 ksys_write+0x74/0x10c
 __arm64_sys_write+0x1c/0x28
 invoke_syscall+0x48/0x114
 el0_svc_common.constprop.0+0xc0/0xe0
 do_el0_svc+0x1c/0x28
 el0_svc+0x40/0xe4
 el0t_64_sync_handler+0x120/0x12c
 el0t_64_sync+0x194/0x198

Root cause is:

systemd-random-seed                         kworker
----------------------------------------------------------------------
___mark_inode_dirty                     inode_switch_wbs_work_fn

  spin_lock(&amp;inode-&gt;i_lock);
  inode_attach_wb
  locked_inode_to_wb_and_lock_list
     get inode-&gt;i_wb
     spin_unlock(&amp;inode-&gt;i_lock);
     spin_lock(&amp;wb-&gt;list_lock)
  spin_lock(&amp;inode-&gt;i_lock)
  inode_io_list_move_locked
  spin_unlock(&amp;wb-&gt;list_lock)
  spin_unlock(&amp;inode-&gt;i_lock)
                                    spin_lock(&amp;old_wb-&gt;list_lock)
                                      inode_do_switch_wbs
                                        spin_lock(&amp;inode-&gt;i_lock)
                                        inode-&gt;i_wb = new_wb
                                        spin_unlock(&amp;inode-&gt;i_lock)
                                    spin_unlock(&amp;old_wb-&gt;list_lock)
                                    wb_put_many(old_wb, nr_switched)
                                      cgwb_release
                                      old wb released
  wb_wakeup_delayed() accesses wb,
  then trigger the use-after-free
  issue

Fix this race condition by holding inode spinlock until
wb_wakeup_delayed() finished.</Note>
    </Notes>
    <CVE>CVE-2025-39866</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: edma: Fix memory allocation size for queue_priority_map

Fix a critical memory allocation bug in edma_setup_from_hw() where
queue_priority_map was allocated with insufficient memory. The code
declared queue_priority_map as s8 (*)[2] (pointer to array of 2 s8),
but allocated memory using sizeof(s8) instead of the correct size.

This caused out-of-bounds memory writes when accessing:
  queue_priority_map[i][0] = i;
  queue_priority_map[i][1] = i;

The bug manifested as kernel crashes with "Oops - undefined instruction"
on ARM platforms (BeagleBoard-X15) during EDMA driver probe, as the
memory corruption triggered kernel hardening features on Clang.

Change the allocation to use sizeof(*queue_priority_map) which
automatically gets the correct size for the 2D array structure.</Note>
    </Notes>
    <CVE>CVE-2025-39869</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 double free in idxd_setup_wqs()

The clean up in idxd_setup_wqs() has had a couple bugs because the error
handling is a bit subtle.  It's simpler to just re-write it in a cleaner
way.  The issues here are:

1) If "idxd-&gt;max_wqs" is &lt;= 0 then we call put_device(conf_dev) when
   "conf_dev" hasn't been initialized.
2) If kzalloc_node() fails then again "conf_dev" is invalid.  It's
   either uninitialized or it points to the "conf_dev" from the
   previous iteration so it leads to a double free.

It's better to free partial loop iterations within the loop and then
the unwinding at the end can handle whole loop iterations.  I also
renamed the labels to describe what the goto does and not where the goto
was located.</Note>
    </Notes>
    <CVE>CVE-2025-39870</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Remove improper idxd_free

The call to idxd_free() introduces a duplicate put_device() leading to a
reference count underflow:
refcount_t: underflow; use-after-free.
WARNING: CPU: 15 PID: 4428 at lib/refcount.c:28 refcount_warn_saturate+0xbe/0x110
...
Call Trace:
 &lt;TASK&gt;
  idxd_remove+0xe4/0x120 [idxd]
  pci_device_remove+0x3f/0xb0
  device_release_driver_internal+0x197/0x200
  driver_detach+0x48/0x90
  bus_remove_driver+0x74/0xf0
  pci_unregister_driver+0x2e/0xb0
  idxd_exit_module+0x34/0x7a0 [idxd]
  __do_sys_delete_module.constprop.0+0x183/0x280
  do_syscall_64+0x54/0xd70
  entry_SYSCALL_64_after_hwframe+0x76/0x7e

The idxd_unregister_devices() which is invoked at the very beginning of
idxd_remove(), already takes care of the necessary put_device() through the
following call path:
idxd_unregister_devices() -&gt; device_unregister() -&gt; put_device()

In addition, when CONFIG_DEBUG_KOBJECT_RELEASE is enabled, put_device() may
trigger asynchronous cleanup via schedule_delayed_work(). If idxd_free() is
called immediately after, it can result in a use-after-free.

Remove the improper idxd_free() to avoid both the refcount underflow and
potential memory corruption during module unload.</Note>
    </Notes>
    <CVE>CVE-2025-39871</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: xilinx_can: xcan_write_frame(): fix use-after-free of transmitted SKB

can_put_echo_skb() takes ownership of the SKB and it may be freed
during or after the call.

However, xilinx_can xcan_write_frame() keeps using SKB after the call.

Fix that by only calling can_put_echo_skb() after the code is done
touching the SKB.

The tx_lock is held for the entire xcan_write_frame() execution and
also on the can_get_echo_skb() side so the order of operations does not
matter.

An earlier fix commit 3d3c817c3a40 ("can: xilinx_can: Fix usage of skb
memory") did not move the can_put_echo_skb() call far enough.

[mkl: add "commit" in front of sha1 in patch description]
[mkl: fix indention]</Note>
    </Notes>
    <CVE>CVE-2025-39873</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fec: Fix possible NPD in fec_enet_phy_reset_after_clk_enable()

The function of_phy_find_device may return NULL, so we need to take
care before dereferencing phy_dev.</Note>
    </Notes>
    <CVE>CVE-2025-39876</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

kernfs: Fix UAF in polling when open file is released

A use-after-free (UAF) vulnerability was identified in the PSI (Pressure
Stall Information) monitoring mechanism:

BUG: KASAN: slab-use-after-free in psi_trigger_poll+0x3c/0x140
Read of size 8 at addr ffff3de3d50bd308 by task systemd/1

psi_trigger_poll+0x3c/0x140
cgroup_pressure_poll+0x70/0xa0
cgroup_file_poll+0x8c/0x100
kernfs_fop_poll+0x11c/0x1c0
ep_item_poll.isra.0+0x188/0x2c0

Allocated by task 1:
cgroup_file_open+0x88/0x388
kernfs_fop_open+0x73c/0xaf0
do_dentry_open+0x5fc/0x1200
vfs_open+0xa0/0x3f0
do_open+0x7e8/0xd08
path_openat+0x2fc/0x6b0
do_filp_open+0x174/0x368

Freed by task 8462:
cgroup_file_release+0x130/0x1f8
kernfs_drain_open_files+0x17c/0x440
kernfs_drain+0x2dc/0x360
kernfs_show+0x1b8/0x288
cgroup_file_show+0x150/0x268
cgroup_pressure_write+0x1dc/0x340
cgroup_file_write+0x274/0x548

Reproduction Steps:
1. Open test/cpu.pressure and establish epoll monitoring
2. Disable monitoring: echo 0 &gt; test/cgroup.pressure
3. Re-enable monitoring: echo 1 &gt; test/cgroup.pressure

The race condition occurs because:
1. When cgroup.pressure is disabled (echo 0 &gt; cgroup.pressure), it:
   - Releases PSI triggers via cgroup_file_release()
   - Frees of-&gt;priv through kernfs_drain_open_files()
2. While epoll still holds reference to the file and continues polling
3. Re-enabling (echo 1 &gt; cgroup.pressure) accesses freed of-&gt;priv

epolling			disable/enable cgroup.pressure
fd=open(cpu.pressure)
while(1)
...
epoll_wait
kernfs_fop_poll
kernfs_get_active = true	echo 0 &gt; cgroup.pressure
...				cgroup_file_show
				kernfs_show
				// inactive kn
				kernfs_drain_open_files
				cft-&gt;release(of);
				kfree(ctx);
				...
kernfs_get_active = false
				echo 1 &gt; cgroup.pressure
				kernfs_show
				kernfs_activate_one(kn);
kernfs_fop_poll
kernfs_get_active = true
cgroup_file_poll
psi_trigger_poll
// UAF
...
end: close(fd)

To address this issue, introduce kernfs_get_active_of() for kernfs open
files to obtain active references. This function will fail if the open file
has been released. Replace kernfs_get_active() with kernfs_get_active_of()
to prevent further operations on released file descriptors.</Note>
    </Notes>
    <CVE>CVE-2025-39881</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix potential OF node use-after-free

The for_each_child_of_node() helper drops the reference it takes to each
node as it iterates over children and an explicit of_node_put() is only
needed when exiting the loop early.

Drop the recently introduced bogus additional reference count decrement
at each iteration that could potentially lead to a use-after-free.</Note>
    </Notes>
    <CVE>CVE-2025-39882</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ocfs2: fix recursive semaphore deadlock in fiemap call

syzbot detected a OCFS2 hang due to a recursive semaphore on a
FS_IOC_FIEMAP of the extent list on a specially crafted mmap file.

context_switch kernel/sched/core.c:5357 [inline]
   __schedule+0x1798/0x4cc0 kernel/sched/core.c:6961
   __schedule_loop kernel/sched/core.c:7043 [inline]
   schedule+0x165/0x360 kernel/sched/core.c:7058
   schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7115
   rwsem_down_write_slowpath+0x872/0xfe0 kernel/locking/rwsem.c:1185
   __down_write_common kernel/locking/rwsem.c:1317 [inline]
   __down_write kernel/locking/rwsem.c:1326 [inline]
   down_write+0x1ab/0x1f0 kernel/locking/rwsem.c:1591
   ocfs2_page_mkwrite+0x2ff/0xc40 fs/ocfs2/mmap.c:142
   do_page_mkwrite+0x14d/0x310 mm/memory.c:3361
   wp_page_shared mm/memory.c:3762 [inline]
   do_wp_page+0x268d/0x5800 mm/memory.c:3981
   handle_pte_fault mm/memory.c:6068 [inline]
   __handle_mm_fault+0x1033/0x5440 mm/memory.c:6195
   handle_mm_fault+0x40a/0x8e0 mm/memory.c:6364
   do_user_addr_fault+0x764/0x1390 arch/x86/mm/fault.c:1387
   handle_page_fault arch/x86/mm/fault.c:1476 [inline]
   exc_page_fault+0x76/0xf0 arch/x86/mm/fault.c:1532
   asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:623
RIP: 0010:copy_user_generic arch/x86/include/asm/uaccess_64.h:126 [inline]
RIP: 0010:raw_copy_to_user arch/x86/include/asm/uaccess_64.h:147 [inline]
RIP: 0010:_inline_copy_to_user include/linux/uaccess.h:197 [inline]
RIP: 0010:_copy_to_user+0x85/0xb0 lib/usercopy.c:26
Code: e8 00 bc f7 fc 4d 39 fc 72 3d 4d 39 ec 77 38 e8 91 b9 f7 fc 4c 89
f7 89 de e8 47 25 5b fd 0f 01 cb 4c 89 ff 48 89 d9 4c 89 f6 &lt;f3&gt; a4 0f
1f 00 48 89 cb 0f 01 ca 48 89 d8 5b 41 5c 41 5d 41 5e 41
RSP: 0018:ffffc9000403f950 EFLAGS: 00050256
RAX: ffffffff84c7f101 RBX: 0000000000000038 RCX: 0000000000000038
RDX: 0000000000000000 RSI: ffffc9000403f9e0 RDI: 0000200000000060
RBP: ffffc9000403fa90 R08: ffffc9000403fa17 R09: 1ffff92000807f42
R10: dffffc0000000000 R11: fffff52000807f43 R12: 0000200000000098
R13: 00007ffffffff000 R14: ffffc9000403f9e0 R15: 0000200000000060
   copy_to_user include/linux/uaccess.h:225 [inline]
   fiemap_fill_next_extent+0x1c0/0x390 fs/ioctl.c:145
   ocfs2_fiemap+0x888/0xc90 fs/ocfs2/extent_map.c:806
   ioctl_fiemap fs/ioctl.c:220 [inline]
   do_vfs_ioctl+0x1173/0x1430 fs/ioctl.c:532
   __do_sys_ioctl fs/ioctl.c:596 [inline]
   __se_sys_ioctl+0x82/0x170 fs/ioctl.c:584
   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:0x7f5f13850fd9
RSP: 002b:00007ffe3b3518b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000200000000000 RCX: 00007f5f13850fd9
RDX: 0000200000000040 RSI: 00000000c020660b RDI: 0000000000000004
RBP: 6165627472616568 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe3b3518f0
R13: 00007ffe3b351b18 R14: 431bde82d7b634db R15: 00007f5f1389a03b

ocfs2_fiemap() takes a read lock of the ip_alloc_sem semaphore (since
v2.6.22-527-g7307de80510a) and calls fiemap_fill_next_extent() to read the
extent list of this running mmap executable.  The user supplied buffer to
hold the fiemap information page faults calling ocfs2_page_mkwrite() which
will take a write lock (since v2.6.27-38-g00dc417fa3e7) of the same
semaphore.  This recursive semaphore will hold filesystem locks and causes
a hang of the fileystem.

The ip_alloc_sem protects the inode extent list and size.  Release the
read semphore before calling fiemap_fill_next_extent() in ocfs2_fiemap()
and ocfs2_fiemap_inline().  This does an unnecessary semaphore lock/unlock
on the last extent but simplifies the error path.</Note>
    </Notes>
    <CVE>CVE-2025-39885</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: l2cap: Check encryption key size on incoming connection

This is required for passing GAP/SEC/SEM/BI-04-C PTS test case:
  Security Mode 4 Level 4, Responder - Invalid Encryption Key Size
  - 128 bit

This tests the security key with size from 1 to 15 bytes while the
Security Mode 4 Level 4 requests 16 bytes key size.

Currently PTS fails with the following logs:
- expected:Connection Response:
    Code: [3 (0x03)] Code
    Identifier: (lt)WildCard: Exists(gt)
    Length: [8 (0x0008)]
    Destination CID: (lt)WildCard: Exists(gt)
    Source CID: [64 (0x0040)]
    Result: [3 (0x0003)] Connection refused - Security block
    Status: (lt)WildCard: Exists(gt),
but received:Connection Response:
    Code: [3 (0x03)] Code
    Identifier: [1 (0x01)]
    Length: [8 (0x0008)]
    Destination CID: [64 (0x0040)]
    Source CID: [64 (0x0040)]
    Result: [0 (0x0000)] Connection Successful
    Status: [0 (0x0000)] No further information available

And HCI logs:
&lt; HCI Command: Read Encrypti.. (0x05|0x0008) plen 2
        Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.)
&gt; HCI Event: Command Complete (0x0e) plen 7
      Read Encryption Key Size (0x05|0x0008) ncmd 1
        Status: Success (0x00)
        Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.)
        Key size: 7
&gt; ACL Data RX: Handle 14 flags 0x02 dlen 12
      L2CAP: Connection Request (0x02) ident 1 len 4
        PSM: 4097 (0x1001)
        Source CID: 64
&lt; ACL Data TX: Handle 14 flags 0x00 dlen 16
      L2CAP: Connection Response (0x03) ident 1 len 8
        Destination CID: 64
        Source CID: 64
        Result: Connection successful (0x0000)
        Status: No further information available (0x0000)</Note>
    </Notes>
    <CVE>CVE-2025-39889</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: mwifiex: Initialize the chan_stats array to zero

The adapter-&gt;chan_stats[] array is initialized in
mwifiex_init_channel_scan_gap() with vmalloc(), which doesn't zero out
memory.  The array is filled in mwifiex_update_chan_statistics()
and then the user can query the data in mwifiex_cfg80211_dump_survey().

There are two potential issues here.  What if the user calls
mwifiex_cfg80211_dump_survey() before the data has been filled in.
Also the mwifiex_update_chan_statistics() function doesn't necessarily
initialize the whole array.  Since the array was not initialized at
the start that could result in an information leak.

Also this array is pretty small.  It's a maximum of 900 bytes so it's
more appropriate to use kcalloc() instead vmalloc().</Note>
    </Notes>
    <CVE>CVE-2025-39891</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix sched_numa_find_nth_cpu() if mask offline

sched_numa_find_nth_cpu() uses a bsearch to look for the 'closest'
CPU in sched_domains_numa_masks and given cpus mask. However they
might not intersect if all CPUs in the cpus mask are offline. bsearch
will return NULL in that case, bail out instead of dereferencing a
bogus pointer.

The previous behaviour lead to this bug when using maxcpus=4 on an
rk3399 (LLLLbb) (i.e. booting with all big CPUs offline):

[    1.422922] Unable to handle kernel paging request at virtual address ffffff8000000000
[    1.423635] Mem abort info:
[    1.423889]   ESR = 0x0000000096000006
[    1.424227]   EC = 0x25: DABT (current EL), IL = 32 bits
[    1.424715]   SET = 0, FnV = 0
[    1.424995]   EA = 0, S1PTW = 0
[    1.425279]   FSC = 0x06: level 2 translation fault
[    1.425735] Data abort info:
[    1.425998]   ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000
[    1.426499]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[    1.426952]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[    1.427428] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000004a9f000
[    1.428038] [ffffff8000000000] pgd=18000000f7fff403, p4d=18000000f7fff403, pud=18000000f7fff403, pmd=0000000000000000
[    1.429014] Internal error: Oops: 0000000096000006 [#1]  SMP
[    1.429525] Modules linked in:
[    1.429813] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc4-dirty #343 PREEMPT
[    1.430559] Hardware name: Pine64 RockPro64 v2.1 (DT)
[    1.431012] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    1.431634] pc : sched_numa_find_nth_cpu+0x2a0/0x488
[    1.432094] lr : sched_numa_find_nth_cpu+0x284/0x488
[    1.432543] sp : ffffffc084e1b960
[    1.432843] x29: ffffffc084e1b960 x28: ffffff80078a8800 x27: ffffffc0846eb1d0
[    1.433495] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
[    1.434144] x23: 0000000000000000 x22: fffffffffff7f093 x21: ffffffc081de6378
[    1.434792] x20: 0000000000000000 x19: 0000000ffff7f093 x18: 00000000ffffffff
[    1.435441] x17: 3030303866666666 x16: 66663d736b73616d x15: ffffffc104e1b5b7
[    1.436091] x14: 0000000000000000 x13: ffffffc084712860 x12: 0000000000000372
[    1.436739] x11: 0000000000000126 x10: ffffffc08476a860 x9 : ffffffc084712860
[    1.437389] x8 : 00000000ffffefff x7 : ffffffc08476a860 x6 : 0000000000000000
[    1.438036] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000
[    1.438683] x2 : 0000000000000000 x1 : ffffffc0846eb000 x0 : ffffff8000407b68
[    1.439332] Call trace:
[    1.439559]  sched_numa_find_nth_cpu+0x2a0/0x488 (P)
[    1.440016]  smp_call_function_any+0xc8/0xd0
[    1.440416]  armv8_pmu_init+0x58/0x27c
[    1.440770]  armv8_cortex_a72_pmu_init+0x20/0x2c
[    1.441199]  arm_pmu_device_probe+0x1e4/0x5e8
[    1.441603]  armv8_pmu_device_probe+0x1c/0x28
[    1.442007]  platform_probe+0x5c/0xac
[    1.442347]  really_probe+0xbc/0x298
[    1.442683]  __driver_probe_device+0x78/0x12c
[    1.443087]  driver_probe_device+0xdc/0x160
[    1.443475]  __driver_attach+0x94/0x19c
[    1.443833]  bus_for_each_dev+0x74/0xd4
[    1.444190]  driver_attach+0x24/0x30
[    1.444525]  bus_add_driver+0xe4/0x208
[    1.444874]  driver_register+0x60/0x128
[    1.445233]  __platform_driver_register+0x24/0x30
[    1.445662]  armv8_pmu_driver_init+0x28/0x4c
[    1.446059]  do_one_initcall+0x44/0x25c
[    1.446416]  kernel_init_freeable+0x1dc/0x3bc
[    1.446820]  kernel_init+0x20/0x1d8
[    1.447151]  ret_from_fork+0x10/0x20
[    1.447493] Code: 90022e21 f000e5f5 910de2b5 2a1703e2 (f8767803)
[    1.448040] ---[ end trace 0000000000000000 ]---
[    1.448483] note: swapper/0[1] exited with preempt_count 1
[    1.449047] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[    1.449741] SMP: stopping secondary CPUs
[    1.450105] Kernel Offset: disabled
[    1.450419] CPU features: 0x000000,00080000,20002001,0400421b
[    
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-39895</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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-39898</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/slub: avoid accessing metadata when pointer is invalid in object_err()

object_err() reports details of an object for further debugging, such as
the freelist pointer, redzone, etc. However, if the pointer is invalid,
attempting to access object metadata can lead to a crash since it does
not point to a valid object.

One known path to the crash is when alloc_consistency_checks()
determines the pointer to the allocated object is invalid because of a
freelist corruption, and calls object_err() to report it. The debug code
should report and handle the corruption gracefully and not crash in the
process.

In case the pointer is NULL or check_valid_pointer() returns false for
the pointer, only print the pointer value and skip accessing metadata.</Note>
    </Notes>
    <CVE>CVE-2025-39902</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: stm32_fmc2: avoid overlapping mappings on ECC buffer

Avoid below overlapping mappings by using a contiguous
non-cacheable buffer.

[    4.077708] DMA-API: stm32_fmc2_nfc 48810000.nand-controller: cacheline tracking EEXIST,
overlapping mappings aren't supported
[    4.089103] WARNING: CPU: 1 PID: 44 at kernel/dma/debug.c:568 add_dma_entry+0x23c/0x300
[    4.097071] Modules linked in:
[    4.100101] CPU: 1 PID: 44 Comm: kworker/u4:2 Not tainted 6.1.82 #1
[    4.106346] Hardware name: STMicroelectronics STM32MP257F VALID1 SNOR / MB1704 (LPDDR4 Power discrete) + MB1703 + MB1708 (SNOR MB1730) (DT)
[    4.118824] Workqueue: events_unbound deferred_probe_work_func
[    4.124674] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    4.131624] pc : add_dma_entry+0x23c/0x300
[    4.135658] lr : add_dma_entry+0x23c/0x300
[    4.139792] sp : ffff800009dbb490
[    4.143016] x29: ffff800009dbb4a0 x28: 0000000004008022 x27: ffff8000098a6000
[    4.150174] x26: 0000000000000000 x25: ffff8000099e7000 x24: ffff8000099e7de8
[    4.157231] x23: 00000000ffffffff x22: 0000000000000000 x21: ffff8000098a6a20
[    4.164388] x20: ffff000080964180 x19: ffff800009819ba0 x18: 0000000000000006
[    4.171545] x17: 6361727420656e69 x16: 6c6568636163203a x15: 72656c6c6f72746e
[    4.178602] x14: 6f632d646e616e2e x13: ffff800009832f58 x12: 00000000000004ec
[    4.185759] x11: 00000000000001a4 x10: ffff80000988af58 x9 : ffff800009832f58
[    4.192916] x8 : 00000000ffffefff x7 : ffff80000988af58 x6 : 80000000fffff000
[    4.199972] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000
[    4.207128] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000812d2c40
[    4.214185] Call trace:
[    4.216605]  add_dma_entry+0x23c/0x300
[    4.220338]  debug_dma_map_sg+0x198/0x350
[    4.224373]  __dma_map_sg_attrs+0xa0/0x110
[    4.228411]  dma_map_sg_attrs+0x10/0x2c
[    4.232247]  stm32_fmc2_nfc_xfer.isra.0+0x1c8/0x3fc
[    4.237088]  stm32_fmc2_nfc_seq_read_page+0xc8/0x174
[    4.242127]  nand_read_oob+0x1d4/0x8e0
[    4.245861]  mtd_read_oob_std+0x58/0x84
[    4.249596]  mtd_read_oob+0x90/0x150
[    4.253231]  mtd_read+0x68/0xac</Note>
    </Notes>
    <CVE>CVE-2025-39907</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 IRQ freeing in i40e_vsi_request_irq_msix error path

If request_irq() in i40e_vsi_request_irq_msix() fails in an iteration
later than the first, the error path wants to free the IRQs requested
so far. However, it uses the wrong dev_id argument for free_irq(), so
it does not free the IRQs correctly and instead triggers the warning:

 Trying to free already-free IRQ 173
 WARNING: CPU: 25 PID: 1091 at kernel/irq/manage.c:1829 __free_irq+0x192/0x2c0
 Modules linked in: i40e(+) [...]
 CPU: 25 UID: 0 PID: 1091 Comm: NetworkManager Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy)
 Hardware name: [...]
 RIP: 0010:__free_irq+0x192/0x2c0
 [...]
 Call Trace:
  &lt;TASK&gt;
  free_irq+0x32/0x70
  i40e_vsi_request_irq_msix.cold+0x63/0x8b [i40e]
  i40e_vsi_request_irq+0x79/0x80 [i40e]
  i40e_vsi_open+0x21f/0x2f0 [i40e]
  i40e_open+0x63/0x130 [i40e]
  __dev_open+0xfc/0x210
  __dev_change_flags+0x1fc/0x240
  netif_change_flags+0x27/0x70
  do_setlink.isra.0+0x341/0xc70
  rtnl_newlink+0x468/0x860
  rtnetlink_rcv_msg+0x375/0x450
  netlink_rcv_skb+0x5c/0x110
  netlink_unicast+0x288/0x3c0
  netlink_sendmsg+0x20d/0x430
  ____sys_sendmsg+0x3a2/0x3d0
  ___sys_sendmsg+0x99/0xe0
  __sys_sendmsg+0x8a/0xf0
  do_syscall_64+0x82/0x2c0
  entry_SYSCALL_64_after_hwframe+0x76/0x7e
  [...]
  &lt;/TASK&gt;
 ---[ end trace 0000000000000000 ]---

Use the same dev_id for free_irq() as for request_irq().

I tested this with inserting code to fail intentionally.</Note>
    </Notes>
    <CVE>CVE-2025-39911</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

pcmcia: Add error handling for add_interval() in do_validate_mem()

In the do_validate_mem(), the call to add_interval() does not
handle errors. If kmalloc() fails in add_interval(), it could
result in a null pointer being inserted into the linked list,
leading to illegal memory access when sub_interval() is called
next.

This patch adds an error handling for the add_interval(). If
add_interval() returns an error, the function will return early
with the error code.</Note>
    </Notes>
    <CVE>CVE-2025-39920</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: qcom: bam_dma: Fix DT error handling for num-channels/ees

When we don't have a clock specified in the device tree, we have no way to
ensure the BAM is on. This is often the case for remotely-controlled or
remotely-powered BAM instances. In this case, we need to read num-channels
from the DT to have all the necessary information to complete probing.

However, at the moment invalid device trees without clock and without
num-channels still continue probing, because the error handling is missing
return statements. The driver will then later try to read the number of
channels from the registers. This is unsafe, because it relies on boot
firmware and lucky timing to succeed. Unfortunately, the lack of proper
error handling here has been abused for several Qualcomm SoCs upstream,
causing early boot crashes in several situations [1, 2].

Avoid these early crashes by erroring out when any of the required DT
properties are missing. Note that this will break some of the existing DTs
upstream (mainly BAM instances related to the crypto engine). However,
clearly these DTs have never been tested properly, since the error in the
kernel log was just ignored. It's safer to disable the crypto engine for
these broken DTBs.

[1]: https://lore.kernel.org/r/CY01EKQVWE36.B9X5TDXAREPF@fairphone.com/
[2]: https://lore.kernel.org/r/20230626145959.646747-1-krzysztof.kozlowski@linaro.org/</Note>
    </Notes>
    <CVE>CVE-2025-39923</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: j1939: implement NETDEV_UNREGISTER notification handler

syzbot is reporting

  unregister_netdevice: waiting for vcan0 to become free. Usage count = 2

problem, for j1939 protocol did not have NETDEV_UNREGISTER notification
handler for undoing changes made by j1939_sk_bind().

Commit 25fe97cb7620 ("can: j1939: move j1939_priv_put() into sk_destruct
callback") expects that a call to j1939_priv_put() can be unconditionally
delayed until j1939_sk_sock_destruct() is called. But we need to call
j1939_priv_put() against an extra ref held by j1939_sk_bind() call
(as a part of undoing changes made by j1939_sk_bind()) as soon as
NETDEV_UNREGISTER notification fires (i.e. before j1939_sk_sock_destruct()
is called via j1939_sk_release()). Otherwise, the extra ref on "struct
j1939_priv" held by j1939_sk_bind() call prevents "struct net_device" from
dropping the usage count to 1; making it impossible for
unregister_netdevice() to continue.

[mkl: remove space in front of label]</Note>
    </Notes>
    <CVE>CVE-2025-39925</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: af_alg - Set merge to zero early in af_alg_sendmsg

If an error causes af_alg_sendmsg to abort, ctx-&gt;merge may contain
a garbage value from the previous loop.  This may then trigger a
crash on the next entry into af_alg_sendmsg when it attempts to do
a merge that can't be done.

Fix this by setting ctx-&gt;merge to zero near the start of the loop.</Note>
    </Notes>
    <CVE>CVE-2025-39931</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: bridge: anx7625: Fix NULL pointer dereference with early IRQ

If the interrupt occurs before resource initialization is complete, the
interrupt handler/worker may access uninitialized data such as the I2C
tcpc_client device, potentially leading to NULL pointer dereference.</Note>
    </Notes>
    <CVE>CVE-2025-39934</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: rfkill: gpio: Fix crash due to dereferencering uninitialized pointer

Since commit 7d5e9737efda ("net: rfkill: gpio: get the name and type from
device property") rfkill_find_type() gets called with the possibly
uninitialized "const char *type_name;" local variable.

On x86 systems when rfkill-gpio binds to a "BCM4752" or "LNV4752"
acpi_device, the rfkill-&gt;type is set based on the ACPI acpi_device_id:

        rfkill-&gt;type = (unsigned)id-&gt;driver_data;

and there is no "type" property so device_property_read_string() will fail
and leave type_name uninitialized, leading to a potential crash.

rfkill_find_type() does accept a NULL pointer, fix the potential crash
by initializing type_name to NULL.

Note likely sofar this has not been caught because:

1. Not many x86 machines actually have a "BCM4752"/"LNV4752" acpi_device
2. The stack happened to contain NULL where type_name is stored</Note>
    </Notes>
    <CVE>CVE-2025-39937</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: q6apm-lpass-dais: Fix NULL pointer dereference if source graph failed

If earlier opening of source graph fails (e.g. ADSP rejects due to
incorrect audioreach topology), the graph is closed and
"dai_data-&gt;graph[dai-&gt;id]" is assigned NULL.  Preparing the DAI for sink
graph continues though and next call to q6apm_lpass_dai_prepare()
receives dai_data-&gt;graph[dai-&gt;id]=NULL leading to NULL pointer
exception:

  qcom-apm gprsvc:service:2:1: Error (1) Processing 0x01001002 cmd
  qcom-apm gprsvc:service:2:1: DSP returned error[1001002] 1
  q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: fail to start APM port 78
  q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: ASoC: error at snd_soc_pcm_dai_prepare on TX_CODEC_DMA_TX_3: -22
  Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a8
  ...
  Call trace:
   q6apm_graph_media_format_pcm+0x48/0x120 (P)
   q6apm_lpass_dai_prepare+0x110/0x1b4
   snd_soc_pcm_dai_prepare+0x74/0x108
   __soc_pcm_prepare+0x44/0x160
   dpcm_be_dai_prepare+0x124/0x1c0</Note>
    </Notes>
    <CVE>CVE-2025-39938</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

cnic: Fix use-after-free bugs in cnic_delete_task

The original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(),
which does not guarantee that the delayed work item 'delete_task' has
fully completed if it was already running. Additionally, the delayed work
item is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() only
blocks and waits for work items that were already queued to the
workqueue prior to its invocation. Any work items submitted after
flush_workqueue() is called are not included in the set of tasks that the
flush operation awaits. This means that after the cyclic work items have
finished executing, a delayed work item may still exist in the workqueue.
This leads to use-after-free scenarios where the cnic_dev is deallocated
by cnic_free_dev(), while delete_task remains active and attempt to
dereference cnic_dev in cnic_delete_task().

A typical race condition is illustrated below:

CPU 0 (cleanup)              | CPU 1 (delayed work callback)
cnic_netdev_event()          |
  cnic_stop_hw()             | cnic_delete_task()
    cnic_cm_stop_bnx2x_hw()  | ...
      cancel_delayed_work()  | /* the queue_delayed_work()
      flush_workqueue()      |    executes after flush_workqueue()*/
                             | queue_delayed_work()
  cnic_free_dev(dev)//free   | cnic_delete_task() //new instance
                             |   dev = cp-&gt;dev; //use

Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure
that the cyclic delayed work item is properly canceled and that any
ongoing execution of the work item completes before the cnic_dev is
deallocated. Furthermore, since cancel_delayed_work_sync() uses
__flush_work(work, true) to synchronously wait for any currently
executing instance of the work item to finish, the flush_workqueue()
becomes redundant and should be removed.

This bug was identified through static analysis. To reproduce the issue
and validate the fix, I simulated the cnic PCI device in QEMU and
introduced intentional delays - such as inserting calls to ssleep()
within the cnic_delete_task() function - to increase the likelihood
of triggering the bug.</Note>
    </Notes>
    <CVE>CVE-2025-39945</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: make sure to abort the stream if headers are bogus

Normally we wait for the socket to buffer up the whole record
before we service it. If the socket has a tiny buffer, however,
we read out the data sooner, to prevent connection stalls.
Make sure that we abort the connection when we find out late
that the record is actually invalid. Retrying the parsing is
fine in itself but since we copy some more data each time
before we parse we can overflow the allocated skb space.

Constructing a scenario in which we're under pressure without
enough data in the socket to parse the length upfront is quite
hard. syzbot figured out a way to do this by serving us the header
in small OOB sends, and then filling in the recvbuf with a large
normal send.

Make sure that tls_rx_msg_size() aborts strp, if we reach
an invalid record there's really no way to recover.</Note>
    </Notes>
    <CVE>CVE-2025-39946</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Harden uplink netdev access against device unbind

The function mlx5_uplink_netdev_get() gets the uplink netdevice
pointer from mdev-&gt;mlx5e_res.uplink_netdev. However, the netdevice can
be removed and its pointer cleared when unbound from the mlx5_core.eth
driver. This results in a NULL pointer, causing a kernel panic.

 BUG: unable to handle page fault for address: 0000000000001300
 at RIP: 0010:mlx5e_vport_rep_load+0x22a/0x270 [mlx5_core]
 Call Trace:
  &lt;TASK&gt;
  mlx5_esw_offloads_rep_load+0x68/0xe0 [mlx5_core]
  esw_offloads_enable+0x593/0x910 [mlx5_core]
  mlx5_eswitch_enable_locked+0x341/0x420 [mlx5_core]
  mlx5_devlink_eswitch_mode_set+0x17e/0x3a0 [mlx5_core]
  devlink_nl_eswitch_set_doit+0x60/0xd0
  genl_family_rcv_msg_doit+0xe0/0x130
  genl_rcv_msg+0x183/0x290
  netlink_rcv_skb+0x4b/0xf0
  genl_rcv+0x24/0x40
  netlink_unicast+0x255/0x380
  netlink_sendmsg+0x1f3/0x420
  __sock_sendmsg+0x38/0x60
  __sys_sendto+0x119/0x180
  do_syscall_64+0x53/0x1d0
  entry_SYSCALL_64_after_hwframe+0x4b/0x53

Ensure the pointer is valid before use by checking it for NULL. If it
is valid, immediately call netdev_hold() to take a reference, and
preventing the netdevice from being freed while it is in use.</Note>
    </Notes>
    <CVE>CVE-2025-39947</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 Rx page leak on multi-buffer frames

The ice_put_rx_mbuf() function handles calling ice_put_rx_buf() for each
buffer in the current frame. This function was introduced as part of
handling multi-buffer XDP support in the ice driver.

It works by iterating over the buffers from first_desc up to 1 plus the
total number of fragments in the frame, cached from before the XDP program
was executed.

If the hardware posts a descriptor with a size of 0, the logic used in
ice_put_rx_mbuf() breaks. Such descriptors get skipped and don't get added
as fragments in ice_add_xdp_frag. Since the buffer isn't counted as a
fragment, we do not iterate over it in ice_put_rx_mbuf(), and thus we don't
call ice_put_rx_buf().

Because we don't call ice_put_rx_buf(), we don't attempt to re-use the
page or free it. This leaves a stale page in the ring, as we don't
increment next_to_alloc.

The ice_reuse_rx_page() assumes that the next_to_alloc has been incremented
properly, and that it always points to a buffer with a NULL page. Since
this function doesn't check, it will happily recycle a page over the top
of the next_to_alloc buffer, losing track of the old page.

Note that this leak only occurs for multi-buffer frames. The
ice_put_rx_mbuf() function always handles at least one buffer, so a
single-buffer frame will always get handled correctly. It is not clear
precisely why the hardware hands us descriptors with a size of 0 sometimes,
but it happens somewhat regularly with "jumbo frames" used by 9K MTU.

To fix ice_put_rx_mbuf(), we need to make sure to call ice_put_rx_buf() on
all buffers between first_desc and next_to_clean. Borrow the logic of a
similar function in i40e used for this same purpose. Use the same logic
also in ice_get_pgcnts().

Instead of iterating over just the number of fragments, use a loop which
iterates until the current index reaches to the next_to_clean element just
past the current frame. Unlike i40e, the ice_put_rx_mbuf() function does
call ice_put_rx_buf() on the last buffer of the frame indicating the end of
packet.

For non-linear (multi-buffer) frames, we need to take care when adjusting
the pagecnt_bias. An XDP program might release fragments from the tail of
the frame, in which case that fragment page is already released. Only
update the pagecnt_bias for the first descriptor and fragments still
remaining post-XDP program. Take care to only access the shared info for
fragmented buffers, as this avoids a significant cache miss.

The xdp_xmit value only needs to be updated if an XDP program is run, and
only once per packet. Drop the xdp_xmit pointer argument from
ice_put_rx_mbuf(). Instead, set xdp_xmit in the ice_clean_rx_irq() function
directly. This avoids needing to pass the argument and avoids an extra
bit-wise OR for each buffer in the frame.

Move the increment of the ntc local variable to ensure its updated *before*
all calls to ice_get_pgcnts() or ice_put_rx_mbuf(), as the loop logic
requires the index of the element just after the current frame.

Now that we use an index pointer in the ring to identify the packet, we no
longer need to track or cache the number of fragments in the rx_ring.</Note>
    </Notes>
    <CVE>CVE-2025-39948</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

qed: Don't collect too many protection override GRC elements

In the protection override dump path, the firmware can return far too
many GRC elements, resulting in attempting to write past the end of the
previously-kmalloc'ed dump buffer.

This will result in a kernel panic with reason:

 BUG: unable to handle kernel paging request at ADDRESS

where "ADDRESS" is just past the end of the protection override dump
buffer. The start address of the buffer is:
 p_hwfn-&gt;cdev-&gt;dbg_features[DBG_FEATURE_PROTECTION_OVERRIDE].dump_buf
and the size of the buffer is buf_size in the same data structure.

The panic can be arrived at from either the qede Ethernet driver path:

    [exception RIP: qed_grc_dump_addr_range+0x108]
 qed_protection_override_dump at ffffffffc02662ed [qed]
 qed_dbg_protection_override_dump at ffffffffc0267792 [qed]
 qed_dbg_feature at ffffffffc026aa8f [qed]
 qed_dbg_all_data at ffffffffc026b211 [qed]
 qed_fw_fatal_reporter_dump at ffffffffc027298a [qed]
 devlink_health_do_dump at ffffffff82497f61
 devlink_health_report at ffffffff8249cf29
 qed_report_fatal_error at ffffffffc0272baf [qed]
 qede_sp_task at ffffffffc045ed32 [qede]
 process_one_work at ffffffff81d19783

or the qedf storage driver path:

    [exception RIP: qed_grc_dump_addr_range+0x108]
 qed_protection_override_dump at ffffffffc068b2ed [qed]
 qed_dbg_protection_override_dump at ffffffffc068c792 [qed]
 qed_dbg_feature at ffffffffc068fa8f [qed]
 qed_dbg_all_data at ffffffffc0690211 [qed]
 qed_fw_fatal_reporter_dump at ffffffffc069798a [qed]
 devlink_health_do_dump at ffffffff8aa95e51
 devlink_health_report at ffffffff8aa9ae19
 qed_report_fatal_error at ffffffffc0697baf [qed]
 qed_hw_err_notify at ffffffffc06d32d7 [qed]
 qed_spq_post at ffffffffc06b1011 [qed]
 qed_fcoe_destroy_conn at ffffffffc06b2e91 [qed]
 qedf_cleanup_fcport at ffffffffc05e7597 [qedf]
 qedf_rport_event_handler at ffffffffc05e7bf7 [qedf]
 fc_rport_work at ffffffffc02da715 [libfc]
 process_one_work at ffffffff8a319663

Resolve this by clamping the firmware's return value to the maximum
number of legal elements the firmware should return.</Note>
    </Notes>
    <CVE>CVE-2025-39949</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: wilc1000: avoid buffer overflow in WID string configuration

Fix the following copy overflow warning identified by Smatch checker.

 drivers/net/wireless/microchip/wilc1000/wlan_cfg.c:184 wilc_wlan_parse_response_frame()
        error: '__memcpy()' 'cfg-&gt;s[i]-&gt;str' copy overflow (512 vs 65537)

This patch introduces size check before accessing the memory buffer.
The checks are base on the WID type of received data from the firmware.
For WID string configuration, the size limit is determined by individual
element size in 'struct wilc_cfg_str_vals' that is maintained in 'len' field
of 'struct wilc_cfg_str'.</Note>
    </Notes>
    <CVE>CVE-2025-39952</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Clear tcp_sk(sk)-&gt;fastopen_rsk in tcp_disconnect().

syzbot reported the splat below where a socket had tcp_sk(sk)-&gt;fastopen_rsk
in the TCP_ESTABLISHED state. [0]

syzbot reused the server-side TCP Fast Open socket as a new client before
the TFO socket completes 3WHS:

  1. accept()
  2. connect(AF_UNSPEC)
  3. connect() to another destination

As of accept(), sk-&gt;sk_state is TCP_SYN_RECV, and tcp_disconnect() changes
it to TCP_CLOSE and makes connect() possible, which restarts timers.

Since tcp_disconnect() forgot to clear tcp_sk(sk)-&gt;fastopen_rsk, the
retransmit timer triggered the warning and the intended packet was not
retransmitted.

Let's call reqsk_fastopen_remove() in tcp_disconnect().

[0]:
WARNING: CPU: 2 PID: 0 at net/ipv4/tcp_timer.c:542 tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))
Modules linked in:
CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))
Code: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 &lt;0f&gt; 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3e
RSP: 0018:ffffc900002f8d40 EFLAGS: 00010293
RAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017
RDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400
RBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8
R10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540
R13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0
FS:  0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0
Call Trace:
 &lt;IRQ&gt;
 tcp_write_timer (net/ipv4/tcp_timer.c:738)
 call_timer_fn (kernel/time/timer.c:1747)
 __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2372)
 timer_expire_remote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135)
 tmigr_handle_remote_up (kernel/time/timer_migration.c:944 kernel/time/timer_migration.c:1035)
 __walk_groups.isra.0 (kernel/time/timer_migration.c:533 (discriminator 1))
 tmigr_handle_remote (kernel/time/timer_migration.c:1096)
 handle_softirqs (./arch/x86/include/asm/jump_label.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580)
 irq_exit_rcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696)
 sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35))
 &lt;/IRQ&gt;</Note>
    </Notes>
    <CVE>CVE-2025-39955</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: increase scan_ies_len for S1G

Currently the S1G capability element is not taken into account
for the scan_ies_len, which leads to a buffer length validation
failure in ieee80211_prep_hw_scan() and subsequent WARN in
__ieee80211_start_scan(). This prevents hw scanning from functioning.
To fix ensure we accommodate for the S1G capability length.</Note>
    </Notes>
    <CVE>CVE-2025-39957</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:

fbcon: fix integer overflow in fbcon_do_set_font

Fix integer overflow vulnerabilities in fbcon_do_set_font() where font
size calculations could overflow when handling user-controlled font
parameters.

The vulnerabilities occur when:
1. CALC_FONTSZ(h, pitch, charcount) performs h * pith * charcount
   multiplication with user-controlled values that can overflow.
2. FONT_EXTRA_WORDS * sizeof(int) + size addition can also overflow
3. This results in smaller allocations than expected, leading to buffer
   overflows during font data copying.

Add explicit overflow checking using check_mul_overflow() and
check_add_overflow() kernel helpers to safety validate all size
calculations before allocation.</Note>
    </Notes>
    <CVE>CVE-2025-39967</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: add max boundary check for VF filters

There is no check for max filters that VF can request. Add it.</Note>
    </Notes>
    <CVE>CVE-2025-39968</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:

i40e: fix validation of VF state in get resources

VF state I40E_VF_STATE_ACTIVE is not the only state in which
VF is actually active so it should not be used to determine
if a VF is allowed to obtain resources.

Use I40E_VF_STATE_RESOURCES_LOADED that is set only in
i40e_vc_get_vf_resources_msg() and cleared during reset.</Note>
    </Notes>
    <CVE>CVE-2025-39969</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 input validation logic for action_meta

Fix condition to check 'greater or equal' to prevent OOB dereference.</Note>
    </Notes>
    <CVE>CVE-2025-39970</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 idx validation in config queues msg

Ensure idx is within range of active/initialized TCs when iterating over
vf-&gt;ch[idx] in i40e_vc_config_queues_msg().</Note>
    </Notes>
    <CVE>CVE-2025-39971</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 idx validation in i40e_validate_queue_map

Ensure idx is within range of active/initialized TCs when iterating over
vf-&gt;ch[idx] in i40e_validate_queue_map().</Note>
    </Notes>
    <CVE>CVE-2025-39972</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: add validation for ring_len param

The `ring_len` parameter provided by the virtual function (VF)
is assigned directly to the hardware memory context (HMC) without
any validation.

To address this, introduce an upper boundary check for both Tx and Rx
queue lengths. The maximum number of descriptors supported by the
hardware is 8k-32.
Additionally, enforce alignment constraints: Tx rings must be a multiple
of 8, and Rx rings must be a multiple of 32.</Note>
    </Notes>
    <CVE>CVE-2025-39973</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:

octeontx2-pf: Fix potential use after free in otx2_tc_add_flow()

This code calls kfree_rcu(new_node, rcu) and then dereferences "new_node"
and then dereferences it on the next line.  Two lines later, we take
a mutex so I don't think this is an RCU safe region.  Re-order it to do
the dereferences before queuing up the free.</Note>
    </Notes>
    <CVE>CVE-2025-39978</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: MGMT: Fix possible UAFs

This attemps to fix possible UAFs caused by struct mgmt_pending being
freed while still being processed like in the following trace, in order
to fix mgmt_pending_valid is introduce and use to check if the
mgmt_pending hasn't been removed from the pending list, on the complete
callbacks it is used to check and in addtion remove the cmd from the list
while holding mgmt_pending_lock to avoid TOCTOU problems since if the cmd
is left on the list it can still be accessed and freed.

BUG: KASAN: slab-use-after-free in mgmt_add_adv_patterns_monitor_sync+0x35/0x50 net/bluetooth/mgmt.c:5223
Read of size 8 at addr ffff8880709d4dc0 by task kworker/u11:0/55

CPU: 0 UID: 0 PID: 55 Comm: kworker/u11:0 Not tainted 6.16.4 #2 PREEMPT(full)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 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:378 [inline]
 print_report+0xca/0x240 mm/kasan/report.c:482
 kasan_report+0x118/0x150 mm/kasan/report.c:595
 mgmt_add_adv_patterns_monitor_sync+0x35/0x50 net/bluetooth/mgmt.c:5223
 hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332
 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 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16.4/arch/x86/entry/entry_64.S:245
 &lt;/TASK&gt;

Allocated by task 12210:
 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:4364
 kmalloc_noprof include/linux/slab.h:905 [inline]
 kzalloc_noprof include/linux/slab.h:1039 [inline]
 mgmt_pending_new+0x65/0x1e0 net/bluetooth/mgmt_util.c:269
 mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296
 __add_adv_patterns_monitor+0x130/0x200 net/bluetooth/mgmt.c:5247
 add_adv_patterns_monitor+0x214/0x360 net/bluetooth/mgmt.c:5364
 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:714 [inline]
 __sock_sendmsg+0x219/0x270 net/socket.c:729
 sock_write_iter+0x258/0x330 net/socket.c:1133
 new_sync_write fs/read_write.c:593 [inline]
 vfs_write+0x5c9/0xb30 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 12221:
 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:2381 [inline]
 slab_free mm/slub.c:4648 [inline]
 kfree+0x18e/0x440 mm/slub.c:4847
 mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline]
 mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257
 __mgmt_power_off+0x169/0x350 net/bluetooth/mgmt.c:9444
 hci_dev_close_sync+0x754/0x1330 net/bluetooth/hci_sync.c:5290
 hci_dev_do_close net/bluetooth/hci_core.c:501 [inline]
 hci_dev_close+0x108/0x200 net/bluetooth/hci_core.c:526
 sock_do_ioctl+0xd9/0x300 net/socket.c:1192
 sock_ioctl+0x576/0x790 net/socket.c:1313
 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+0xf
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-39981</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: hci_event: Fix UAF in hci_acl_create_conn_sync

This fixes the following UFA in hci_acl_create_conn_sync where a
connection still pending is command submission (conn-&gt;state == BT_OPEN)
maybe freed, also since this also can happen with the likes of
hci_le_create_conn_sync fix it as well:

BUG: KASAN: slab-use-after-free in hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861
Write of size 2 at addr ffff88805ffcc038 by task kworker/u11:2/9541

CPU: 1 UID: 0 PID: 9541 Comm: kworker/u11:2 Not tainted 6.16.0-rc7 #3 PREEMPT(full)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
Workqueue: hci3 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:378 [inline]
 print_report+0xca/0x230 mm/kasan/report.c:480
 kasan_report+0x118/0x150 mm/kasan/report.c:593
 hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861
 hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332
 process_one_work kernel/workqueue.c:3238 [inline]
 process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321
 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402
 kthread+0x70e/0x8a0 kernel/kthread.c:464
 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148
 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245
 &lt;/TASK&gt;

Allocated by task 123736:
 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]
 __hci_conn_add+0x233/0x1b30 net/bluetooth/hci_conn.c:939
 hci_conn_add_unset net/bluetooth/hci_conn.c:1051 [inline]
 hci_connect_acl+0x16c/0x4e0 net/bluetooth/hci_conn.c:1634
 pair_device+0x418/0xa70 net/bluetooth/mgmt.c:3556
 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+0x54b/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 103680:
 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:2381 [inline]
 slab_free mm/slub.c:4643 [inline]
 kfree+0x18e/0x440 mm/slub.c:4842
 device_release+0x9c/0x1c0
 kobject_cleanup lib/kobject.c:689 [inline]
 kobject_release lib/kobject.c:720 [inline]
 kref_put include/linux/kref.h:65 [inline]
 kobject_put+0x22b/0x480 lib/kobject.c:737
 hci_conn_cleanup net/bluetooth/hci_conn.c:175 [inline]
 hci_conn_del+0x8ff/0xcb0 net/bluetooth/hci_conn.c:1173
 hci_conn_complete_evt+0x3c7/0x1040 net/bluetooth/hci_event.c:3199
 hci_event_func net/bluetooth/hci_event.c:7477 [inline]
 hci_event_packet+0x7e0/0x1200 net/bluetooth/hci_event.c:7531
 hci_rx_work+0x46a/0xe80 net/bluetooth/hci_core.c:4070
 process_one_work kernel/workqueue.c:3238 [inline]
 process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321
 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402
 kthread+0x70e/0x8a0 kernel/kthread.c:464
 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148
 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/sour
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-39982</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: mcba_usb: populate ndo_change_mtu() to prevent buffer overflow

Sending an PF_PACKET allows to bypass the CAN framework logic and to
directly reach the xmit() function of a CAN driver. The only check
which is performed by the PF_PACKET framework is to make sure that
skb-&gt;len fits the interface's MTU.

Unfortunately, because the mcba_usb driver does not populate its
net_device_ops-&gt;ndo_change_mtu(), it is possible for an attacker to
configure an invalid MTU by doing, for example:

  $ ip link set can0 mtu 9999

After doing so, the attacker could open a PF_PACKET socket using the
ETH_P_CANXL protocol:

	socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))

to inject a malicious CAN XL frames. For example:

	struct canxl_frame frame = {
		.flags = 0xff,
		.len = 2048,
	};

The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
check that the skb is valid, unfortunately under above conditions, the
malicious packet is able to go through can_dev_dropped_skb() checks:

  1. the skb-&gt;protocol is set to ETH_P_CANXL which is valid (the
     function does not check the actual device capabilities).

  2. the length is a valid CAN XL length.

And so, mcba_usb_start_xmit() receives a CAN XL frame which it is not
able to correctly handle and will thus misinterpret it as a CAN frame.

This can result in a buffer overflow. The driver will consume cf-&gt;len
as-is with no further checks on these lines:

	usb_msg.dlc = cf-&gt;len;

	memcpy(usb_msg.data, cf-&gt;data, usb_msg.dlc);

Here, cf-&gt;len corresponds to the flags field of the CAN XL frame. In
our previous example, we set canxl_frame-&gt;flags to 0xff. Because the
maximum expected length is 8, a buffer overflow of 247 bytes occurs!

Populate net_device_ops-&gt;ndo_change_mtu() to ensure that the
interface's MTU can not be set to anything bigger than CAN_MTU. By
fixing the root cause, this prevents the buffer overflow.</Note>
    </Notes>
    <CVE>CVE-2025-39985</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: sun4i_can: populate ndo_change_mtu() to prevent buffer overflow

Sending an PF_PACKET allows to bypass the CAN framework logic and to
directly reach the xmit() function of a CAN driver. The only check
which is performed by the PF_PACKET framework is to make sure that
skb-&gt;len fits the interface's MTU.

Unfortunately, because the sun4i_can driver does not populate its
net_device_ops-&gt;ndo_change_mtu(), it is possible for an attacker to
configure an invalid MTU by doing, for example:

  $ ip link set can0 mtu 9999

After doing so, the attacker could open a PF_PACKET socket using the
ETH_P_CANXL protocol:

	socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))

to inject a malicious CAN XL frames. For example:

	struct canxl_frame frame = {
		.flags = 0xff,
		.len = 2048,
	};

The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
check that the skb is valid, unfortunately under above conditions, the
malicious packet is able to go through can_dev_dropped_skb() checks:

  1. the skb-&gt;protocol is set to ETH_P_CANXL which is valid (the
     function does not check the actual device capabilities).

  2. the length is a valid CAN XL length.

And so, sun4ican_start_xmit() receives a CAN XL frame which it is not
able to correctly handle and will thus misinterpret it as a CAN frame.

This can result in a buffer overflow. The driver will consume cf-&gt;len
as-is with no further checks on this line:

	dlc = cf-&gt;len;

Here, cf-&gt;len corresponds to the flags field of the CAN XL frame. In
our previous example, we set canxl_frame-&gt;flags to 0xff. Because the
maximum expected length is 8, a buffer overflow of 247 bytes occurs a
couple line below when doing:

	for (i = 0; i &lt; dlc; i++)
		writel(cf-&gt;data[i], priv-&gt;base + (dreg + i * 4));

Populate net_device_ops-&gt;ndo_change_mtu() to ensure that the
interface's MTU can not be set to anything bigger than CAN_MTU. By
fixing the root cause, this prevents the buffer overflow.</Note>
    </Notes>
    <CVE>CVE-2025-39986</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: hi311x: populate ndo_change_mtu() to prevent buffer overflow

Sending an PF_PACKET allows to bypass the CAN framework logic and to
directly reach the xmit() function of a CAN driver. The only check
which is performed by the PF_PACKET framework is to make sure that
skb-&gt;len fits the interface's MTU.

Unfortunately, because the sun4i_can driver does not populate its
net_device_ops-&gt;ndo_change_mtu(), it is possible for an attacker to
configure an invalid MTU by doing, for example:

  $ ip link set can0 mtu 9999

After doing so, the attacker could open a PF_PACKET socket using the
ETH_P_CANXL protocol:

	socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))

to inject a malicious CAN XL frames. For example:

	struct canxl_frame frame = {
		.flags = 0xff,
		.len = 2048,
	};

The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
check that the skb is valid, unfortunately under above conditions, the
malicious packet is able to go through can_dev_dropped_skb() checks:

  1. the skb-&gt;protocol is set to ETH_P_CANXL which is valid (the
     function does not check the actual device capabilities).

  2. the length is a valid CAN XL length.

And so, hi3110_hard_start_xmit() receives a CAN XL frame which it is
not able to correctly handle and will thus misinterpret it as a CAN
frame. The driver will consume frame-&gt;len as-is with no further
checks.

This can result in a buffer overflow later on in hi3110_hw_tx() on
this line:

	memcpy(buf + HI3110_FIFO_EXT_DATA_OFF,
	       frame-&gt;data, frame-&gt;len);

Here, frame-&gt;len corresponds to the flags field of the CAN XL frame.
In our previous example, we set canxl_frame-&gt;flags to 0xff. Because
the maximum expected length is 8, a buffer overflow of 247 bytes
occurs!

Populate net_device_ops-&gt;ndo_change_mtu() to ensure that the
interface's MTU can not be set to anything bigger than CAN_MTU. By
fixing the root cause, this prevents the buffer overflow.</Note>
    </Notes>
    <CVE>CVE-2025-39987</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow

Sending an PF_PACKET allows to bypass the CAN framework logic and to
directly reach the xmit() function of a CAN driver. The only check
which is performed by the PF_PACKET framework is to make sure that
skb-&gt;len fits the interface's MTU.

Unfortunately, because the etas_es58x driver does not populate its
net_device_ops-&gt;ndo_change_mtu(), it is possible for an attacker to
configure an invalid MTU by doing, for example:

  $ ip link set can0 mtu 9999

After doing so, the attacker could open a PF_PACKET socket using the
ETH_P_CANXL protocol:

	socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL));

to inject a malicious CAN XL frames. For example:

	struct canxl_frame frame = {
		.flags = 0xff,
		.len = 2048,
	};

The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
check that the skb is valid, unfortunately under above conditions, the
malicious packet is able to go through can_dev_dropped_skb() checks:

  1. the skb-&gt;protocol is set to ETH_P_CANXL which is valid (the
     function does not check the actual device capabilities).

  2. the length is a valid CAN XL length.

And so, es58x_start_xmit() receives a CAN XL frame which it is not
able to correctly handle and will thus misinterpret it as a CAN(FD)
frame.

This can result in a buffer overflow. For example, using the es581.4
variant, the frame will be dispatched to es581_4_tx_can_msg(), go
through the last check at the beginning of this function:

	if (can_is_canfd_skb(skb))
		return -EMSGSIZE;

and reach this line:

	memcpy(tx_can_msg-&gt;data, cf-&gt;data, cf-&gt;len);

Here, cf-&gt;len corresponds to the flags field of the CAN XL frame. In
our previous example, we set canxl_frame-&gt;flags to 0xff. Because the
maximum expected length is 8, a buffer overflow of 247 bytes occurs!

Populate net_device_ops-&gt;ndo_change_mtu() to ensure that the
interface's MTU can not be set to anything bigger than CAN_MTU or
CANFD_MTU (depending on the device capabilities). By fixing the root
cause, this prevents the buffer overflow.</Note>
    </Notes>
    <CVE>CVE-2025-39988</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 NULL dereference in ath11k_qmi_m3_load()

If ab-&gt;fw.m3_data points to data, then fw pointer remains null.
Further, if m3_mem is not allocated, then fw is dereferenced to be
passed to ath11k_err function.

Replace fw-&gt;size by m3_len.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2025-39991</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: rc: fix races with imon_disconnect()

Syzbot reports a KASAN issue as below:
BUG: KASAN: use-after-free in __create_pipe include/linux/usb.h:1945 [inline]
BUG: KASAN: use-after-free in send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627
Read of size 4 at addr ffff8880256fb000 by task syz-executor314/4465

CPU: 2 PID: 4465 Comm: syz-executor314 Not tainted 6.0.0-rc1-syzkaller #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
Call Trace:
 &lt;TASK&gt;
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:317 [inline]
print_report.cold+0x2ba/0x6e9 mm/kasan/report.c:433
kasan_report+0xb1/0x1e0 mm/kasan/report.c:495
__create_pipe include/linux/usb.h:1945 [inline]
send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627
vfd_write+0x2d9/0x550 drivers/media/rc/imon.c:991
vfs_write+0x2d7/0xdd0 fs/read_write.c:576
ksys_write+0x127/0x250 fs/read_write.c:631
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd

The iMON driver improperly releases the usb_device reference in
imon_disconnect without coordinating with active users of the
device.

Specifically, the fields usbdev_intf0 and usbdev_intf1 are not
protected by the users counter (ictx-&gt;users). During probe,
imon_init_intf0 or imon_init_intf1 increments the usb_device
reference count depending on the interface. However, during
disconnect, usb_put_dev is called unconditionally, regardless of
actual usage.

As a result, if vfd_write or other operations are still in
progress after disconnect, this can lead to a use-after-free of
the usb_device pointer.

Thread 1 vfd_write                      Thread 2 imon_disconnect
                                        ...
                                        if
                                          usb_put_dev(ictx-&gt;usbdev_intf0)
                                        else
                                          usb_put_dev(ictx-&gt;usbdev_intf1)
...
while
  send_packet
    if
      pipe = usb_sndintpipe(
        ictx-&gt;usbdev_intf0) UAF
    else
      pipe = usb_sndctrlpipe(
        ictx-&gt;usbdev_intf0, 0) UAF

Guard access to usbdev_intf0 and usbdev_intf1 after disconnect by
checking ictx-&gt;disconnected in all writer paths. Add early return
with -ENODEV in send_packet(), vfd_write(), lcd_write() and
display_open() if the device is no longer present.

Set and read ictx-&gt;disconnected under ictx-&gt;lock to ensure memory
synchronization. Acquire the lock in imon_disconnect() before setting
the flag to synchronize with any ongoing operations.

Ensure writers exit early and safely after disconnect before the USB
core proceeds with cleanup.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.</Note>
    </Notes>
    <CVE>CVE-2025-39993</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: tuner: xc5000: Fix use-after-free in xc5000_release

The original code uses cancel_delayed_work() in xc5000_release(), which
does not guarantee that the delayed work item timer_sleep has fully
completed if it was already running. This leads to use-after-free scenarios
where xc5000_release() may free the xc5000_priv while timer_sleep is still
active and attempts to dereference the xc5000_priv.

A typical race condition is illustrated below:

CPU 0 (release thread)                 | CPU 1 (delayed work callback)
xc5000_release()                       | xc5000_do_timer_sleep()
  cancel_delayed_work()                |
  hybrid_tuner_release_state(priv)     |
    kfree(priv)                        |
                                       |   priv = container_of() // UAF

Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure
that the timer_sleep is properly canceled before the xc5000_priv memory
is deallocated.

A deadlock concern was considered: xc5000_release() is called in a process
context and is not holding any locks that the timer_sleep work item might
also need. Therefore, the use of the _sync() variant is safe here.

This bug was initially identified through static analysis.

[hverkuil: fix typo in Subject: tunner -&gt; tuner]</Note>
    </Notes>
    <CVE>CVE-2025-39994</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: i2c: tc358743: Fix use-after-free bugs caused by orphan timer in probe

The state-&gt;timer is a cyclic timer that schedules work_i2c_poll and
delayed_work_enable_hotplug, while rearming itself. Using timer_delete()
fails to guarantee the timer isn't still running when destroyed, similarly
cancel_delayed_work() cannot ensure delayed_work_enable_hotplug has
terminated if already executing. During probe failure after timer
initialization, these may continue running as orphans and reference the
already-freed tc358743_state object through tc358743_irq_poll_timer.

The following is the trace captured by KASAN.

BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0
Write of size 8 at addr ffff88800ded83c8 by task swapper/1/0
...
Call Trace:
 &lt;IRQ&gt;
 dump_stack_lvl+0x55/0x70
 print_report+0xcf/0x610
 ? __pfx_sched_balance_find_src_group+0x10/0x10
 ? __run_timer_base.part.0+0x7d7/0x8c0
 kasan_report+0xb8/0xf0
 ? __run_timer_base.part.0+0x7d7/0x8c0
 __run_timer_base.part.0+0x7d7/0x8c0
 ? rcu_sched_clock_irq+0xb06/0x27d0
 ? __pfx___run_timer_base.part.0+0x10/0x10
 ? try_to_wake_up+0xb15/0x1960
 ? tmigr_update_events+0x280/0x740
 ? _raw_spin_lock_irq+0x80/0xe0
 ? __pfx__raw_spin_lock_irq+0x10/0x10
 tmigr_handle_remote_up+0x603/0x7e0
 ? __pfx_tmigr_handle_remote_up+0x10/0x10
 ? sched_balance_trigger+0x98/0x9f0
 ? sched_tick+0x221/0x5a0
 ? _raw_spin_lock_irq+0x80/0xe0
 ? __pfx__raw_spin_lock_irq+0x10/0x10
 ? tick_nohz_handler+0x339/0x440
 ? __pfx_tmigr_handle_remote_up+0x10/0x10
 __walk_groups.isra.0+0x42/0x150
 tmigr_handle_remote+0x1f4/0x2e0
 ? __pfx_tmigr_handle_remote+0x10/0x10
 ? ktime_get+0x60/0x140
 ? lapic_next_event+0x11/0x20
 ? clockevents_program_event+0x1d4/0x2a0
 ? hrtimer_interrupt+0x322/0x780
 handle_softirqs+0x16a/0x550
 irq_exit_rcu+0xaf/0xe0
 sysvec_apic_timer_interrupt+0x70/0x80
 &lt;/IRQ&gt;
...

Allocated by task 141:
 kasan_save_stack+0x24/0x50
 kasan_save_track+0x14/0x30
 __kasan_kmalloc+0x7f/0x90
 __kmalloc_node_track_caller_noprof+0x198/0x430
 devm_kmalloc+0x7b/0x1e0
 tc358743_probe+0xb7/0x610  i2c_device_probe+0x51d/0x880
 really_probe+0x1ca/0x5c0
 __driver_probe_device+0x248/0x310
 driver_probe_device+0x44/0x120
 __device_attach_driver+0x174/0x220
 bus_for_each_drv+0x100/0x190
 __device_attach+0x206/0x370
 bus_probe_device+0x123/0x170
 device_add+0xd25/0x1470
 i2c_new_client_device+0x7a0/0xcd0
 do_one_initcall+0x89/0x300
 do_init_module+0x29d/0x7f0
 load_module+0x4f48/0x69e0
 init_module_from_file+0xe4/0x150
 idempotent_init_module+0x320/0x670
 __x64_sys_finit_module+0xbd/0x120
 do_syscall_64+0xac/0x280
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Freed by task 141:
 kasan_save_stack+0x24/0x50
 kasan_save_track+0x14/0x30
 kasan_save_free_info+0x3a/0x60
 __kasan_slab_free+0x3f/0x50
 kfree+0x137/0x370
 release_nodes+0xa4/0x100
 devres_release_group+0x1b2/0x380
 i2c_device_probe+0x694/0x880
 really_probe+0x1ca/0x5c0
 __driver_probe_device+0x248/0x310
 driver_probe_device+0x44/0x120
 __device_attach_driver+0x174/0x220
 bus_for_each_drv+0x100/0x190
 __device_attach+0x206/0x370
 bus_probe_device+0x123/0x170
 device_add+0xd25/0x1470
 i2c_new_client_device+0x7a0/0xcd0
 do_one_initcall+0x89/0x300
 do_init_module+0x29d/0x7f0
 load_module+0x4f48/0x69e0
 init_module_from_file+0xe4/0x150
 idempotent_init_module+0x320/0x670
 __x64_sys_finit_module+0xbd/0x120
 do_syscall_64+0xac/0x280
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
...

Replace timer_delete() with timer_delete_sync() and cancel_delayed_work()
with cancel_delayed_work_sync() to ensure proper termination of timer and
work items before resource cleanup.

This bug was initially identified through static analysis. For reproduction
and testing, I created a functional emulation of the tc358743 device via a
kernel module and introduced faults through the debugfs interface.</Note>
    </Notes>
    <CVE>CVE-2025-39995</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: b2c2: Fix use-after-free causing by irq_check_work in flexcop_pci_remove

The original code uses cancel_delayed_work() in flexcop_pci_remove(), which
does not guarantee that the delayed work item irq_check_work has fully
completed if it was already running. This leads to use-after-free scenarios
where flexcop_pci_remove() may free the flexcop_device while irq_check_work
is still active and attempts to dereference the device.

A typical race condition is illustrated below:

CPU 0 (remove)                         | CPU 1 (delayed work callback)
flexcop_pci_remove()                   | flexcop_pci_irq_check_work()
  cancel_delayed_work()                |
  flexcop_device_kfree(fc_pci-&gt;fc_dev) |
                                       |   fc = fc_pci-&gt;fc_dev; // UAF

This is confirmed by a KASAN report:

==================================================================
BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0
Write of size 8 at addr ffff8880093aa8c8 by task bash/135
...
Call Trace:
 &lt;IRQ&gt;
 dump_stack_lvl+0x55/0x70
 print_report+0xcf/0x610
 ? __run_timer_base.part.0+0x7d7/0x8c0
 kasan_report+0xb8/0xf0
 ? __run_timer_base.part.0+0x7d7/0x8c0
 __run_timer_base.part.0+0x7d7/0x8c0
 ? __pfx___run_timer_base.part.0+0x10/0x10
 ? __pfx_read_tsc+0x10/0x10
 ? ktime_get+0x60/0x140
 ? lapic_next_event+0x11/0x20
 ? clockevents_program_event+0x1d4/0x2a0
 run_timer_softirq+0xd1/0x190
 handle_softirqs+0x16a/0x550
 irq_exit_rcu+0xaf/0xe0
 sysvec_apic_timer_interrupt+0x70/0x80
 &lt;/IRQ&gt;
...

Allocated by task 1:
 kasan_save_stack+0x24/0x50
 kasan_save_track+0x14/0x30
 __kasan_kmalloc+0x7f/0x90
 __kmalloc_noprof+0x1be/0x460
 flexcop_device_kmalloc+0x54/0xe0
 flexcop_pci_probe+0x1f/0x9d0
 local_pci_probe+0xdc/0x190
 pci_device_probe+0x2fe/0x470
 really_probe+0x1ca/0x5c0
 __driver_probe_device+0x248/0x310
 driver_probe_device+0x44/0x120
 __driver_attach+0xd2/0x310
 bus_for_each_dev+0xed/0x170
 bus_add_driver+0x208/0x500
 driver_register+0x132/0x460
 do_one_initcall+0x89/0x300
 kernel_init_freeable+0x40d/0x720
 kernel_init+0x1a/0x150
 ret_from_fork+0x10c/0x1a0
 ret_from_fork_asm+0x1a/0x30

Freed by task 135:
 kasan_save_stack+0x24/0x50
 kasan_save_track+0x14/0x30
 kasan_save_free_info+0x3a/0x60
 __kasan_slab_free+0x3f/0x50
 kfree+0x137/0x370
 flexcop_device_kfree+0x32/0x50
 pci_device_remove+0xa6/0x1d0
 device_release_driver_internal+0xf8/0x210
 pci_stop_bus_device+0x105/0x150
 pci_stop_and_remove_bus_device_locked+0x15/0x30
 remove_store+0xcc/0xe0
 kernfs_fop_write_iter+0x2c3/0x440
 vfs_write+0x871/0xd70
 ksys_write+0xee/0x1c0
 do_syscall_64+0xac/0x280
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
...

Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure
that the delayed work item is properly canceled and any executing delayed
work has finished before the device memory is deallocated.

This bug was initially identified through static analysis. To reproduce
and test it, I simulated the B2C2 FlexCop PCI device in QEMU and introduced
artificial delays within the flexcop_pci_irq_check_work() function to
increase the likelihood of triggering the bug.</Note>
    </Notes>
    <CVE>CVE-2025-39996</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 race condition to UAF in snd_usbmidi_free

The previous commit 0718a78f6a9f ("ALSA: usb-audio: Kill timer properly at
removal") patched a UAF issue caused by the error timer.

However, because the error timer kill added in this patch occurs after the
endpoint delete, a race condition to UAF still occurs, albeit rarely.

Additionally, since kill-cleanup for urb is also missing, freed memory can
be accessed in interrupt context related to urb, which can cause UAF.

Therefore, to prevent this, error timer and urb must be killed before
freeing the heap memory.</Note>
    </Notes>
    <CVE>CVE-2025-39997</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: rtw89: fix use-after-free in rtw89_core_tx_kick_off_and_wait()

There is a bug observed when rtw89_core_tx_kick_off_and_wait() tries to
access already freed skb_data:

 BUG: KFENCE: use-after-free write in rtw89_core_tx_kick_off_and_wait drivers/net/wireless/realtek/rtw89/core.c:1110

 CPU: 6 UID: 0 PID: 41377 Comm: kworker/u64:24 Not tainted  6.17.0-rc1+ #1 PREEMPT(lazy)
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS edk2-20250523-14.fc42 05/23/2025
 Workqueue: events_unbound cfg80211_wiphy_work [cfg80211]

 Use-after-free write at 0x0000000020309d9d (in kfence-#251):
 rtw89_core_tx_kick_off_and_wait drivers/net/wireless/realtek/rtw89/core.c:1110
 rtw89_core_scan_complete drivers/net/wireless/realtek/rtw89/core.c:5338
 rtw89_hw_scan_complete_cb drivers/net/wireless/realtek/rtw89/fw.c:7979
 rtw89_chanctx_proceed_cb drivers/net/wireless/realtek/rtw89/chan.c:3165
 rtw89_chanctx_proceed drivers/net/wireless/realtek/rtw89/chan.h:141
 rtw89_hw_scan_complete drivers/net/wireless/realtek/rtw89/fw.c:8012
 rtw89_mac_c2h_scanofld_rsp drivers/net/wireless/realtek/rtw89/mac.c:5059
 rtw89_fw_c2h_work drivers/net/wireless/realtek/rtw89/fw.c:6758
 process_one_work kernel/workqueue.c:3241
 worker_thread kernel/workqueue.c:3400
 kthread kernel/kthread.c:463
 ret_from_fork arch/x86/kernel/process.c:154
 ret_from_fork_asm arch/x86/entry/entry_64.S:258

 kfence-#251: 0x0000000056e2393d-0x000000009943cb62, size=232, cache=skbuff_head_cache

 allocated by task 41377 on cpu 6 at 77869.159548s (0.009551s ago):
 __alloc_skb net/core/skbuff.c:659
 __netdev_alloc_skb net/core/skbuff.c:734
 ieee80211_nullfunc_get net/mac80211/tx.c:5844
 rtw89_core_send_nullfunc drivers/net/wireless/realtek/rtw89/core.c:3431
 rtw89_core_scan_complete drivers/net/wireless/realtek/rtw89/core.c:5338
 rtw89_hw_scan_complete_cb drivers/net/wireless/realtek/rtw89/fw.c:7979
 rtw89_chanctx_proceed_cb drivers/net/wireless/realtek/rtw89/chan.c:3165
 rtw89_chanctx_proceed drivers/net/wireless/realtek/rtw89/chan.c:3194
 rtw89_hw_scan_complete drivers/net/wireless/realtek/rtw89/fw.c:8012
 rtw89_mac_c2h_scanofld_rsp drivers/net/wireless/realtek/rtw89/mac.c:5059
 rtw89_fw_c2h_work drivers/net/wireless/realtek/rtw89/fw.c:6758
 process_one_work kernel/workqueue.c:3241
 worker_thread kernel/workqueue.c:3400
 kthread kernel/kthread.c:463
 ret_from_fork arch/x86/kernel/process.c:154
 ret_from_fork_asm arch/x86/entry/entry_64.S:258

 freed by task 1045 on cpu 9 at 77869.168393s (0.001557s ago):
 ieee80211_tx_status_skb net/mac80211/status.c:1117
 rtw89_pci_release_txwd_skb drivers/net/wireless/realtek/rtw89/pci.c:564
 rtw89_pci_release_tx_skbs.isra.0 drivers/net/wireless/realtek/rtw89/pci.c:651
 rtw89_pci_release_tx drivers/net/wireless/realtek/rtw89/pci.c:676
 rtw89_pci_napi_poll drivers/net/wireless/realtek/rtw89/pci.c:4238
 __napi_poll net/core/dev.c:7495
 net_rx_action net/core/dev.c:7557 net/core/dev.c:7684
 handle_softirqs kernel/softirq.c:580
 do_softirq.part.0 kernel/softirq.c:480
 __local_bh_enable_ip kernel/softirq.c:407
 rtw89_pci_interrupt_threadfn drivers/net/wireless/realtek/rtw89/pci.c:927
 irq_thread_fn kernel/irq/manage.c:1133
 irq_thread kernel/irq/manage.c:1257
 kthread kernel/kthread.c:463
 ret_from_fork arch/x86/kernel/process.c:154
 ret_from_fork_asm arch/x86/entry/entry_64.S:258

It is a consequence of a race between the waiting and the signaling side
of the completion:

            Waiting thread                            Completing thread

rtw89_core_tx_kick_off_and_wait()
  rcu_assign_pointer(skb_data-&gt;wait, wait)
  /* start waiting */
  wait_for_completion_timeout()
                                                rtw89_pci_tx_status()
                                                  rtw89_core_tx_wait_complete()
                                                    rcu_read_lock()
                                                    /* signals completion and
   
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-40000</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: cadence-quadspi: Implement refcount to handle unbind during busy

driver support indirect read and indirect write operation with
assumption no force device removal(unbind) operation. However
force device removal(removal) is still available to root superuser.

Unbinding driver during operation causes kernel crash. This changes
ensure driver able to handle such operation for indirect read and
indirect write by implementing refcount to track attached devices
to the controller and gracefully wait and until attached devices
remove operation completed before proceed with removal operation.</Note>
    </Notes>
    <CVE>CVE-2025-40005</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

afs: Fix potential null pointer dereference in afs_put_server

afs_put_server() accessed server-&gt;debug_id before the NULL check, which
could lead to a null pointer dereference. Move the debug_id assignment,
ensuring we never dereference a NULL server pointer.</Note>
    </Notes>
    <CVE>CVE-2025-40010</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/gma500: Fix null dereference in hdmi teardown

pci_set_drvdata sets the value of pdev-&gt;driver_data to NULL,
after which the driver_data obtained from the same dev is
dereferenced in oaktrail_hdmi_i2c_exit, and the i2c_dev is
extracted from it. To prevent this, swap these calls.

Found by Linux Verification Center (linuxtesting.org) with Svacer.</Note>
    </Notes>
    <CVE>CVE-2025-40011</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: audioreach: fix potential null pointer dereference

It is possible that the topology parsing function
audioreach_widget_load_module_common() could return NULL or an error
pointer. Add missing NULL check so that we do not dereference it.</Note>
    </Notes>
    <CVE>CVE-2025-40013</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_ID

Per UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero
unique ID.

```
Each Unit and Terminal within the video function is assigned a unique
identification number, the Unit ID (UID) or Terminal ID (TID), contained in
the bUnitID or bTerminalID field of the descriptor. The value 0x00 is
reserved for undefined ID,
```

If we add a new entity with id 0 or a duplicated ID, it will be marked
as UVC_INVALID_ENTITY_ID.

In a previous attempt commit 3dd075fe8ebb ("media: uvcvideo: Require
entities to have a non-zero unique ID"), we ignored all the invalid units,
this broke a lot of non-compatible cameras. Hopefully we are more lucky
this time.

This also prevents some syzkaller reproducers from triggering warnings due
to a chain of entities referring to themselves. In one particular case, an
Output Unit is connected to an Input Unit, both with the same ID of 1. But
when looking up for the source ID of the Output Unit, that same entity is
found instead of the input entity, which leads to such warnings.

In another case, a backward chain was considered finished as the source ID
was 0. Later on, that entity was found, but its pads were not valid.

Here is a sample stack trace for one of those cases.

[   20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd
[   20.830206] usb 1-1: Using ep0 maxpacket: 8
[   20.833501] usb 1-1: config 0 descriptor??
[   21.038518] usb 1-1: string descriptor 0 read error: -71
[   21.038893] usb 1-1: Found UVC 0.00 device &lt;unnamed&gt; (2833:0201)
[   21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized!
[   21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized!
[   21.042218] ------------[ cut here ]------------
[   21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0
[   21.043195] Modules linked in:
[   21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444
[   21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
[   21.044639] Workqueue: usb_hub_wq hub_event
[   21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0
[   21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 &lt;0f&gt; 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00
[   21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246
[   21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1
[   21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290
[   21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000
[   21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003
[   21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000
[   21.049648] FS:  0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000
[   21.050271] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0
[   21.051136] PKRU: 55555554
[   21.051331] Call Trace:
[   21.051480]  &lt;TASK&gt;
[   21.051611]  ? __warn+0xc4/0x210
[   21.051861]  ? media_create_pad_link+0x2c4/0x2e0
[   21.052252]  ? report_bug+0x11b/0x1a0
[   21.052540]  ? trace_hardirqs_on+0x31/0x40
[   21.052901]  ? handle_bug+0x3d/0x70
[   21.053197]  ? exc_invalid_op+0x1a/0x50
[   21.053511]  ? asm_exc_invalid_op+0x1a/0x20
[   21.053924]  ? media_create_pad_link+0x91/0x2e0
[   21.054364]  ? media_create_pad_link+0x2c4/0x2e0
[   21.054834]  ? media_create_pad_link+0x91/0x2e0
[   21.055131]  ? _raw_spin_unlock+0x1e/0x40
[   21.055441]  ? __v4l2_device_register_subdev+0x202/0x210
[   21.055837]  uvc_mc_register_entities+0x358/0x400
[   21.056144]  uvc_register_chains+0x1
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-40016</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:

ipvs: Defer ip_vs_ftp unregister during netns cleanup

On the netns cleanup path, __ip_vs_ftp_exit() may unregister ip_vs_ftp
before connections with valid cp-&gt;app pointers are flushed, leading to a
use-after-free.

Fix this by introducing a global `exiting_module` flag, set to true in
ip_vs_ftp_exit() before unregistering the pernet subsystem. In
__ip_vs_ftp_exit(), skip ip_vs_ftp unregister if called during netns
cleanup (when exiting_module is false) and defer it to
__ip_vs_cleanup_batch(), which unregisters all apps after all connections
are flushed. If called during module exit, unregister ip_vs_ftp
immediately.</Note>
    </Notes>
    <CVE>CVE-2025-40018</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: essiv - Check ssize for decryption and in-place encryption

Move the ssize check to the start in essiv_aead_crypt so that
it's also checked for decryption and in-place encryption.</Note>
    </Notes>
    <CVE>CVE-2025-40019</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: peak_usb: fix shift-out-of-bounds issue

Explicitly uses a 64-bit constant when the number of bits used for its
shifting is 32 (which is the case for PC CAN FD interfaces supported by
this driver).

[mkl: update subject, apply manually]</Note>
    </Notes>
    <CVE>CVE-2025-40020</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Check return value of platform_get_resource()

platform_get_resource() returns NULL in case of failure, so check its
return value and propagate the error in order to prevent NULL pointer
dereference.</Note>
    </Notes>
    <CVE>CVE-2025-40029</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: endpoint: pci-epf-test: Add NULL check for DMA channels before release

The fields dma_chan_tx and dma_chan_rx of the struct pci_epf_test can be
NULL even after EPF initialization. Then it is prudent to check that
they have non-NULL values before releasing the channels. Add the checks
in pci_epf_test_clean_dma_chan().

Without the checks, NULL pointer dereferences happen and they can lead
to a kernel panic in some cases:

  Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050
  Call trace:
   dma_release_channel+0x2c/0x120 (P)
   pci_epf_test_epc_deinit+0x94/0xc0 [pci_epf_test]
   pci_epc_deinit_notify+0x74/0xc0
   tegra_pcie_ep_pex_rst_irq+0x250/0x5d8
   irq_thread_fn+0x34/0xb8
   irq_thread+0x18c/0x2e8
   kthread+0x14c/0x210
   ret_from_fork+0x10/0x20

[mani: trimmed the stack trace]</Note>
    </Notes>
    <CVE>CVE-2025-40032</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: uinput - zero-initialize uinput_ff_upload_compat to avoid info leak

Struct ff_effect_compat is embedded twice inside
uinput_ff_upload_compat, contains internal padding. In particular, there
is a hole after struct ff_replay to satisfy alignment requirements for
the following union member. Without clearing the structure,
copy_to_user() may leak stack data to userspace.

Initialize ff_up_compat to zero before filling valid fields.</Note>
    </Notes>
    <CVE>CVE-2025-40035</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fastrpc: fix possible map leak in fastrpc_put_args

copy_to_user() failure would cause an early return without cleaning up
the fdlist, which has been updated by the DSP. This could lead to map
leak. Fix this by redirecting to a cleanup path on failure, ensuring
that all mapped buffers are properly released before returning.</Note>
    </Notes>
    <CVE>CVE-2025-40036</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: nfc: nci: Add parameter validation for packet data

Syzbot reported an uninitialized value bug in nci_init_req, which was
introduced by commit 5aca7966d2a7 ("Merge tag
'perf-tools-fixes-for-v6.17-2025-09-16' of
git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools").

This bug arises due to very limited and poor input validation
that was done at nic_valid_size(). This validation only
validates the skb-&gt;len (directly reflects size provided at the
userspace interface) with the length provided in the buffer
itself (interpreted as NCI_HEADER). This leads to the processing
of memory content at the address assuming the correct layout
per what opcode requires there. This leads to the accesses to
buffer of `skb_buff-&gt;data` which is not assigned anything yet.

Following the same silent drop of packets of invalid sizes at
`nic_valid_size()`, add validation of the data in the respective
handlers and return error values in case of failure. Release
the skb if error values are returned from handlers in
`nci_nft_packet` and effectively do a silent drop

Possible TODO: because we silently drop the packets, the
call to `nci_request` will be waiting for completion of request
and will face timeouts. These timeouts can get excessively logged
in the dmesg. A proper handling of them may require to export
`nci_request_cancel` (or propagate error handling from the
nft packets handlers).</Note>
    </Notes>
    <CVE>CVE-2025-40043</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: udf: fix OOB read in lengthAllocDescs handling

When parsing Allocation Extent Descriptor, lengthAllocDescs comes from
on-disk data and must be validated against the block size. Crafted or
corrupted images may set lengthAllocDescs so that the total descriptor
length (sizeof(allocExtDesc) + lengthAllocDescs) exceeds the buffer,
leading udf_update_tag() to call crc_itu_t() on out-of-bounds memory and
trigger a KASAN use-after-free read.

BUG: KASAN: use-after-free in crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60
Read of size 1 at addr ffff888041e7d000 by task syz-executor317/5309

CPU: 0 UID: 0 PID: 5309 Comm: syz-executor317 Not tainted 6.12.0-rc4-syzkaller-00261-g850925a8133c #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:377 [inline]
 print_report+0x169/0x550 mm/kasan/report.c:488
 kasan_report+0x143/0x180 mm/kasan/report.c:601
 crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60
 udf_update_tag+0x70/0x6a0 fs/udf/misc.c:261
 udf_write_aext+0x4d8/0x7b0 fs/udf/inode.c:2179
 extent_trunc+0x2f7/0x4a0 fs/udf/truncate.c:46
 udf_truncate_tail_extent+0x527/0x7e0 fs/udf/truncate.c:106
 udf_release_file+0xc1/0x120 fs/udf/file.c:185
 __fput+0x23f/0x880 fs/file_table.c:431
 task_work_run+0x24f/0x310 kernel/task_work.c:239
 exit_task_work include/linux/task_work.h:43 [inline]
 do_exit+0xa2f/0x28e0 kernel/exit.c:939
 do_group_exit+0x207/0x2c0 kernel/exit.c:1088
 __do_sys_exit_group kernel/exit.c:1099 [inline]
 __se_sys_exit_group kernel/exit.c:1097 [inline]
 __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097
 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
 &lt;/TASK&gt;

Validate the computed total length against epos-&gt;bh-&gt;b_size.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.</Note>
    </Notes>
    <CVE>CVE-2025-40044</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix uninit-value in squashfs_get_parent

Syzkaller reports a "KMSAN: uninit-value in squashfs_get_parent" bug.

This is caused by open_by_handle_at() being called with a file handle
containing an invalid parent inode number.  In particular the inode number
is that of a symbolic link, rather than a directory.

Squashfs_get_parent() gets called with that symbolic link inode, and
accesses the parent member field.

	unsigned int parent_ino = squashfs_i(inode)-&gt;parent;

Because non-directory inodes in Squashfs do not have a parent value, this
is uninitialised, and this causes an uninitialised value access.

The fix is to initialise parent with the invalid inode 0, which will cause
an EINVAL error to be returned.

Regular inodes used to share the parent field with the block_list_start
field.  This is removed in this commit to enable the parent field to
contain the invalid inode number 0.</Note>
    </Notes>
    <CVE>CVE-2025-40049</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: vringh: Modify the return value check

The return value of copy_from_iter and copy_to_iter can't be negative,
check whether the copied lengths are equal.</Note>
    </Notes>
    <CVE>CVE-2025-40051</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 crypto buffers in non-linear memory

The crypto API, through the scatterlist API, expects input buffers to be
in linear memory.  We handle this with the cifs_sg_set_buf() helper
that converts vmalloc'd memory to their corresponding pages.

However, when we allocate our aead_request buffer (@creq in
smb2ops.c::crypt_message()), we do so with kvzalloc(), which possibly
puts aead_request-&gt;__ctx in vmalloc area.

AEAD algorithm then uses -&gt;__ctx for its private/internal data and
operations, and uses sg_set_buf() for such data on a few places.

This works fine as long as @creq falls into kmalloc zone (small
requests) or vmalloc'd memory is still within linear range.

Tasks' stacks are vmalloc'd by default (CONFIG_VMAP_STACK=y), so too
many tasks will increment the base stacks' addresses to a point where
virt_addr_valid(buf) will fail (BUG() in sg_set_buf()) when that
happens.

In practice: too many parallel reads and writes on an encrypted mount
will trigger this bug.

To fix this, always alloc @creq with kmalloc() instead.
Also drop the @sensitive_size variable/arguments since
kfree_sensitive() doesn't need it.

Backtrace:

[  945.272081] ------------[ cut here ]------------
[  945.272774] kernel BUG at include/linux/scatterlist.h:209!
[  945.273520] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI
[  945.274412] CPU: 7 UID: 0 PID: 56 Comm: kworker/u33:0 Kdump: loaded Not tainted 6.15.0-lku-11779-g8e9d6efccdd7-dirty #1 PREEMPT(voluntary)
[  945.275736] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014
[  945.276877] Workqueue: writeback wb_workfn (flush-cifs-2)
[  945.277457] RIP: 0010:crypto_gcm_init_common+0x1f9/0x220
[  945.278018] Code: b0 00 00 00 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 48 c7 c0 00 00 00 80 48 2b 05 5c 58 e5 00 e9 58 ff ff ff &lt;0f&gt; 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 48 c7 04 24 01 00 00 00 48 8b
[  945.279992] RSP: 0018:ffffc90000a27360 EFLAGS: 00010246
[  945.280578] RAX: 0000000000000000 RBX: ffffc90001d85060 RCX: 0000000000000030
[  945.281376] RDX: 0000000000080000 RSI: 0000000000000000 RDI: ffffc90081d85070
[  945.282145] RBP: ffffc90001d85010 R08: ffffc90001d85000 R09: 0000000000000000
[  945.282898] R10: ffffc90001d85090 R11: 0000000000001000 R12: ffffc90001d85070
[  945.283656] R13: ffff888113522948 R14: ffffc90001d85060 R15: ffffc90001d85010
[  945.284407] FS:  0000000000000000(0000) GS:ffff8882e66cf000(0000) knlGS:0000000000000000
[  945.285262] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  945.285884] CR2: 00007fa7ffdd31f4 CR3: 000000010540d000 CR4: 0000000000350ef0
[  945.286683] Call Trace:
[  945.286952]  &lt;TASK&gt;
[  945.287184]  ? crypt_message+0x33f/0xad0 [cifs]
[  945.287719]  crypto_gcm_encrypt+0x36/0xe0
[  945.288152]  crypt_message+0x54a/0xad0 [cifs]
[  945.288724]  smb3_init_transform_rq+0x277/0x300 [cifs]
[  945.289300]  smb_send_rqst+0xa3/0x160 [cifs]
[  945.289944]  cifs_call_async+0x178/0x340 [cifs]
[  945.290514]  ? __pfx_smb2_writev_callback+0x10/0x10 [cifs]
[  945.291177]  smb2_async_writev+0x3e3/0x670 [cifs]
[  945.291759]  ? find_held_lock+0x32/0x90
[  945.292212]  ? netfs_advance_write+0xf2/0x310
[  945.292723]  netfs_advance_write+0xf2/0x310
[  945.293210]  netfs_write_folio+0x346/0xcc0
[  945.293689]  ? __pfx__raw_spin_unlock_irq+0x10/0x10
[  945.294250]  netfs_writepages+0x117/0x460
[  945.294724]  do_writepages+0xbe/0x170
[  945.295152]  ? find_held_lock+0x32/0x90
[  945.295600]  ? kvm_sched_clock_read+0x11/0x20
[  945.296103]  __writeback_single_inode+0x56/0x4b0
[  945.296643]  writeback_sb_inodes+0x229/0x550
[  945.297140]  __writeback_inodes_wb+0x4c/0xe0
[  945.297642]  wb_writeback+0x2f1/0x3f0
[  945.298069]  wb_workfn+0x300/0x490
[  945.298472]  process_one_work+0x1fe/0x590
[  945.298949]  worker_thread+0x1ce/0x3c0
[  945.299397]  ? __pfx_worker_thread+0x10/0x10
[  945.299900]  kthr
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-40052</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: vringh: Fix copy_to_iter return value check

The return value of copy_to_iter can't be negative, check whether the
copied length is equal to the requested length instead of checking for
negative values.</Note>
    </Notes>
    <CVE>CVE-2025-40056</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/vt-d: Disallow dirty tracking if incoherent page walk

Dirty page tracking relies on the IOMMU atomically updating the dirty bit
in the paging-structure entry. For this operation to succeed, the paging-
structure memory must be coherent between the IOMMU and the CPU. In
another word, if the iommu page walk is incoherent, dirty page tracking
doesn't work.

The Intel VT-d specification, Section 3.10 "Snoop Behavior" states:

"Remapping hardware encountering the need to atomically update A/EA/D bits
 in a paging-structure entry that is not snooped will result in a non-
 recoverable fault."

To prevent an IOMMU from being incorrectly configured for dirty page
tracking when it is operating in an incoherent mode, mark SSADS as
supported only when both ecap_slads and ecap_smpwc are supported.</Note>
    </Notes>
    <CVE>CVE-2025-40058</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: trbe: Return NULL pointer for allocation failures

When the TRBE driver fails to allocate a buffer, it currently returns
the error code "-ENOMEM". However, the caller etm_setup_aux() only
checks for a NULL pointer, so it misses the error. As a result, the
driver continues and eventually causes a kernel panic.

Fix this by returning a NULL pointer from arm_trbe_alloc_buffer() on
allocation failures. This allows that the callers can properly handle
the failure.</Note>
    </Notes>
    <CVE>CVE-2025-40060</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 race in do_task() when draining

When do_task() exhausts its iteration budget (!ret), it sets the state
to TASK_STATE_IDLE to reschedule, without a secondary check on the
current task-&gt;state. This can overwrite the TASK_STATE_DRAINING state
set by a concurrent call to rxe_cleanup_task() or rxe_disable_task().

While state changes are protected by a spinlock, both rxe_cleanup_task()
and rxe_disable_task() release the lock while waiting for the task to
finish draining in the while(!is_done(task)) loop. The race occurs if
do_task() hits its iteration limit and acquires the lock in this window.
The cleanup logic may then proceed while the task incorrectly
reschedules itself, leading to a potential use-after-free.

This bug was introduced during the migration from tasklets to workqueues,
where the special handling for the draining case was lost.

Fix this by restoring the original pre-migration behavior. If the state is
TASK_STATE_DRAINING when iterations are exhausted, set cont to 1 to
force a new loop iteration. This allows the task to finish its work, so
that a subsequent iteration can reach the switch statement and correctly
transition the state to TASK_STATE_DRAINED, stopping the task as intended.</Note>
    </Notes>
    <CVE>CVE-2025-40061</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: hisilicon/qm - set NULL to qm-&gt;debug.qm_diff_regs

When the initialization of qm-&gt;debug.acc_diff_reg fails,
the probe process does not exit. However, after qm-&gt;debug.qm_diff_regs is
freed, it is not set to NULL. This can lead to a double free when the
remove process attempts to free it again. Therefore, qm-&gt;debug.qm_diff_regs
should be set to NULL after it is freed.</Note>
    </Notes>
    <CVE>CVE-2025-40062</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: n_gsm: Don't block input queue by waiting MSC

Currently gsm_queue() processes incoming frames and when opening
a DLC channel it calls gsm_dlci_open() which calls gsm_modem_update().
If basic mode is used it calls gsm_modem_upd_via_msc() and it
cannot block the input queue by waiting the response to come
into the same input queue.

Instead allow sending Modem Status Command without waiting for remote
end to respond. Define a new function gsm_modem_send_initial_msc()
for this purpose. As MSC is only valid for basic encoding, it does
not do anything for advanced or when convergence layer type 2 is used.</Note>
    </Notes>
    <CVE>CVE-2025-40071</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Explicitly check accesses to bpf_sock_addr

Syzkaller found a kernel warning on the following sock_addr program:

    0: r0 = 0
    1: r2 = *(u32 *)(r1 +60)
    2: exit

which triggers:

    verifier bug: error during ctx access conversion (0)

This is happening because offset 60 in bpf_sock_addr corresponds to an
implicit padding of 4 bytes, right after msg_src_ip4. Access to this
padding isn't rejected in sock_addr_is_valid_access and it thus later
fails to convert the access.

This patch fixes it by explicitly checking the various fields of
bpf_sock_addr in sock_addr_is_valid_access.

I checked the other ctx structures and is_valid_access functions and
didn't find any other similar cases. Other cases of (properly handled)
padding are covered in new tests in a subsequent patch.</Note>
    </Notes>
    <CVE>CVE-2025-40078</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: restrict sockets to TCP and UDP

Recently, syzbot started to abuse NBD with all kinds of sockets.

Commit cf1b2326b734 ("nbd: verify socket is supported during setup")
made sure the socket supported a shutdown() method.

Explicitely accept TCP and UNIX stream sockets.</Note>
    </Notes>
    <CVE>CVE-2025-40080</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()

BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186
Read of size 2 at addr ffff8880289ef218 by task syz.6.248/14290

CPU: 0 UID: 0 PID: 14290 Comm: syz.6.248 Not tainted 6.16.4 #1 PREEMPT(full)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x116/0x1b0 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:378 [inline]
 print_report+0xca/0x5f0 mm/kasan/report.c:482
 kasan_report+0xca/0x100 mm/kasan/report.c:595
 hfsplus_uni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186
 hfsplus_listxattr+0x5b6/0xbd0 fs/hfsplus/xattr.c:738
 vfs_listxattr+0xbe/0x140 fs/xattr.c:493
 listxattr+0xee/0x190 fs/xattr.c:924
 filename_listxattr fs/xattr.c:958 [inline]
 path_listxattrat+0x143/0x360 fs/xattr.c:988
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xcb/0x4c0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fe0e9fae16d
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:00007fe0eae67f98 EFLAGS: 00000246 ORIG_RAX: 00000000000000c3
RAX: ffffffffffffffda RBX: 00007fe0ea205fa0 RCX: 00007fe0e9fae16d
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000200000000000
RBP: 00007fe0ea0480f0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fe0ea206038 R14: 00007fe0ea205fa0 R15: 00007fe0eae48000
 &lt;/TASK&gt;

Allocated by task 14290:
 kasan_save_stack+0x24/0x50 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:4333 [inline]
 __kmalloc_noprof+0x219/0x540 mm/slub.c:4345
 kmalloc_noprof include/linux/slab.h:909 [inline]
 hfsplus_find_init+0x95/0x1f0 fs/hfsplus/bfind.c:21
 hfsplus_listxattr+0x331/0xbd0 fs/hfsplus/xattr.c:697
 vfs_listxattr+0xbe/0x140 fs/xattr.c:493
 listxattr+0xee/0x190 fs/xattr.c:924
 filename_listxattr fs/xattr.c:958 [inline]
 path_listxattrat+0x143/0x360 fs/xattr.c:988
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xcb/0x4c0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

When hfsplus_uni2asc is called from hfsplus_listxattr,
it actually passes in a struct hfsplus_attr_unistr*.
The size of the corresponding structure is different from that of hfsplus_unistr,
so the previous fix (94458781aee6) is insufficient.
The pointer on the unicode buffer is still going beyond the allocated memory.

This patch introduces two warpper functions hfsplus_uni2asc_xattr_str and
hfsplus_uni2asc_str to process two unicode buffers,
struct hfsplus_attr_unistr* and struct hfsplus_unistr* respectively.
When ustrlen value is bigger than the allocated memory size,
the ustrlen value is limited to an safe size.</Note>
    </Notes>
    <CVE>CVE-2025-40082</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 NULL pointer deference in try_to_register_card

In try_to_register_card(), the return value of usb_ifnum_to_if() is
passed directly to usb_interface_claimed() without a NULL check, which
will lead to a NULL pointer dereference when creating an invalid
USB audio device. Fix this by adding a check to ensure the interface
pointer is valid before passing it to usb_interface_claimed().</Note>
    </Notes>
    <CVE>CVE-2025-40085</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Define a proc_layoutcommit for the FlexFiles layout type

Avoid a crash if a pNFS client should happen to send a LAYOUTCOMMIT
operation on a FlexFiles layout.</Note>
    </Notes>
    <CVE>CVE-2025-40087</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hfsplus: fix slab-out-of-bounds read in hfsplus_strcasecmp()

The hfsplus_strcasecmp() logic can trigger the issue:

[  117.317703][ T9855] ==================================================================
[  117.318353][ T9855] BUG: KASAN: slab-out-of-bounds in hfsplus_strcasecmp+0x1bc/0x490
[  117.318991][ T9855] Read of size 2 at addr ffff88802160f40c by task repro/9855
[  117.319577][ T9855]
[  117.319773][ T9855] CPU: 0 UID: 0 PID: 9855 Comm: repro Not tainted 6.17.0-rc6 #33 PREEMPT(full)
[  117.319780][ T9855] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[  117.319783][ T9855] Call Trace:
[  117.319785][ T9855]  &lt;TASK&gt;
[  117.319788][ T9855]  dump_stack_lvl+0x1c1/0x2a0
[  117.319795][ T9855]  ? __virt_addr_valid+0x1c8/0x5c0
[  117.319803][ T9855]  ? __pfx_dump_stack_lvl+0x10/0x10
[  117.319808][ T9855]  ? rcu_is_watching+0x15/0xb0
[  117.319816][ T9855]  ? lock_release+0x4b/0x3e0
[  117.319821][ T9855]  ? __kasan_check_byte+0x12/0x40
[  117.319828][ T9855]  ? __virt_addr_valid+0x1c8/0x5c0
[  117.319835][ T9855]  ? __virt_addr_valid+0x4a5/0x5c0
[  117.319842][ T9855]  print_report+0x17e/0x7e0
[  117.319848][ T9855]  ? __virt_addr_valid+0x1c8/0x5c0
[  117.319855][ T9855]  ? __virt_addr_valid+0x4a5/0x5c0
[  117.319862][ T9855]  ? __phys_addr+0xd3/0x180
[  117.319869][ T9855]  ? hfsplus_strcasecmp+0x1bc/0x490
[  117.319876][ T9855]  kasan_report+0x147/0x180
[  117.319882][ T9855]  ? hfsplus_strcasecmp+0x1bc/0x490
[  117.319891][ T9855]  hfsplus_strcasecmp+0x1bc/0x490
[  117.319900][ T9855]  ? __pfx_hfsplus_cat_case_cmp_key+0x10/0x10
[  117.319906][ T9855]  hfs_find_rec_by_key+0xa9/0x1e0
[  117.319913][ T9855]  __hfsplus_brec_find+0x18e/0x470
[  117.319920][ T9855]  ? __pfx_hfsplus_bnode_find+0x10/0x10
[  117.319926][ T9855]  ? __pfx_hfs_find_rec_by_key+0x10/0x10
[  117.319933][ T9855]  ? __pfx___hfsplus_brec_find+0x10/0x10
[  117.319942][ T9855]  hfsplus_brec_find+0x28f/0x510
[  117.319949][ T9855]  ? __pfx_hfs_find_rec_by_key+0x10/0x10
[  117.319956][ T9855]  ? __pfx_hfsplus_brec_find+0x10/0x10
[  117.319963][ T9855]  ? __kmalloc_noprof+0x2a9/0x510
[  117.319969][ T9855]  ? hfsplus_find_init+0x8c/0x1d0
[  117.319976][ T9855]  hfsplus_brec_read+0x2b/0x120
[  117.319983][ T9855]  hfsplus_lookup+0x2aa/0x890
[  117.319990][ T9855]  ? __pfx_hfsplus_lookup+0x10/0x10
[  117.320003][ T9855]  ? d_alloc_parallel+0x2f0/0x15e0
[  117.320008][ T9855]  ? __lock_acquire+0xaec/0xd80
[  117.320013][ T9855]  ? __pfx_d_alloc_parallel+0x10/0x10
[  117.320019][ T9855]  ? __raw_spin_lock_init+0x45/0x100
[  117.320026][ T9855]  ? __init_waitqueue_head+0xa9/0x150
[  117.320034][ T9855]  __lookup_slow+0x297/0x3d0
[  117.320039][ T9855]  ? __pfx___lookup_slow+0x10/0x10
[  117.320045][ T9855]  ? down_read+0x1ad/0x2e0
[  117.320055][ T9855]  lookup_slow+0x53/0x70
[  117.320065][ T9855]  walk_component+0x2f0/0x430
[  117.320073][ T9855]  path_lookupat+0x169/0x440
[  117.320081][ T9855]  filename_lookup+0x212/0x590
[  117.320089][ T9855]  ? __pfx_filename_lookup+0x10/0x10
[  117.320098][ T9855]  ? strncpy_from_user+0x150/0x290
[  117.320105][ T9855]  ? getname_flags+0x1e5/0x540
[  117.320112][ T9855]  user_path_at+0x3a/0x60
[  117.320117][ T9855]  __x64_sys_umount+0xee/0x160
[  117.320123][ T9855]  ? __pfx___x64_sys_umount+0x10/0x10
[  117.320129][ T9855]  ? do_syscall_64+0xb7/0x3a0
[  117.320135][ T9855]  ? entry_SYSCALL_64_after_hwframe+0x77/0x7f
[  117.320141][ T9855]  ? entry_SYSCALL_64_after_hwframe+0x77/0x7f
[  117.320145][ T9855]  do_syscall_64+0xf3/0x3a0
[  117.320150][ T9855]  ? exc_page_fault+0x9f/0xf0
[  117.320154][ T9855]  entry_SYSCALL_64_after_hwframe+0x77/0x7f
[  117.320158][ T9855] RIP: 0033:0x7f7dd7908b07
[  117.320163][ T9855] Code: 23 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 08
[  117.320167][ T9855] RSP: 002b:00007ffd5ebd9698 EFLAGS: 00000202 
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-40088</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/sched: Fix potential double free in drm_sched_job_add_resv_dependencies

When adding dependencies with drm_sched_job_add_dependency(), that
function consumes the fence reference both on success and failure, so in
the latter case the dma_fence_put() on the error path (xarray failed to
expand) is a double free.

Interestingly this bug appears to have been present ever since
commit ebd5f74255b9 ("drm/sched: Add dependency tracking"), since the code
back then looked like this:

drm_sched_job_add_implicit_dependencies():
...
       for (i = 0; i &lt; fence_count; i++) {
               ret = drm_sched_job_add_dependency(job, fences[i]);
               if (ret)
                       break;
       }

       for (; i &lt; fence_count; i++)
               dma_fence_put(fences[i]);

Which means for the failing 'i' the dma_fence_put was already a double
free. Possibly there were no users at that time, or the test cases were
insufficient to hit it.

The bug was then only noticed and fixed after
commit 9c2ba265352a ("drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2")
landed, with its fixup of
commit 4eaf02d6076c ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies").

At that point it was a slightly different flavour of a double free, which
commit 963d0b356935 ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies harder")
noticed and attempted to fix.

But it only moved the double free from happening inside the
drm_sched_job_add_dependency(), when releasing the reference not yet
obtained, to the caller, when releasing the reference already released by
the former in the failure case.

As such it is not easy to identify the right target for the fixes tag so
lets keep it simple and just continue the chain.

While fixing we also improve the comment and explain the reason for taking
the reference and not dropping it.</Note>
    </Notes>
    <CVE>CVE-2025-40096</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 assert we found block group item when creating free space tree

Currently, when building a free space tree at populate_free_space_tree(),
if we are not using the block group tree feature, we always expect to find
block group items (either extent items or a block group item with key type
BTRFS_BLOCK_GROUP_ITEM_KEY) when we search the extent tree with
btrfs_search_slot_for_read(), so we assert that we found an item. However
this expectation is wrong since we can have a new block group created in
the current transaction which is still empty and for which we still have
not added the block group's item to the extent tree, in which case we do
not have any items in the extent tree associated to the block group.

The insertion of a new block group's block group item in the extent tree
happens at btrfs_create_pending_block_groups() when it calls the helper
insert_block_group_item(). This typically is done when a transaction
handle is released, committed or when running delayed refs (either as
part of a transaction commit or when serving tickets for space reservation
if we are low on free space).

So remove the assertion at populate_free_space_tree() even when the block
group tree feature is not enabled and update the comment to mention this
case.

Syzbot reported this with the following stack trace:

  BTRFS info (device loop3 state M): rebuilding free space tree
  assertion failed: ret == 0 :: 0, in fs/btrfs/free-space-tree.c:1115
  ------------[ cut here ]------------
  kernel BUG at fs/btrfs/free-space-tree.c:1115!
  Oops: invalid opcode: 0000 [#1] SMP KASAN PTI
  CPU: 1 UID: 0 PID: 6352 Comm: syz.3.25 Not tainted syzkaller #0 PREEMPT(full)
  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025
  RIP: 0010:populate_free_space_tree+0x700/0x710 fs/btrfs/free-space-tree.c:1115
  Code: ff ff e8 d3 (...)
  RSP: 0018:ffffc9000430f780 EFLAGS: 00010246
  RAX: 0000000000000043 RBX: ffff88805b709630 RCX: fea61d0e2e79d000
  RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000
  RBP: ffffc9000430f8b0 R08: ffffc9000430f4a7 R09: 1ffff92000861e94
  R10: dffffc0000000000 R11: fffff52000861e95 R12: 0000000000000001
  R13: 1ffff92000861f00 R14: dffffc0000000000 R15: 0000000000000000
  FS:  00007f424d9fe6c0(0000) GS:ffff888125afc000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007fd78ad212c0 CR3: 0000000076d68000 CR4: 00000000003526f0
  Call Trace:
   &lt;TASK&gt;
   btrfs_rebuild_free_space_tree+0x1ba/0x6d0 fs/btrfs/free-space-tree.c:1364
   btrfs_start_pre_rw_mount+0x128f/0x1bf0 fs/btrfs/disk-io.c:3062
   btrfs_remount_rw fs/btrfs/super.c:1334 [inline]
   btrfs_reconfigure+0xaed/0x2160 fs/btrfs/super.c:1559
   reconfigure_super+0x227/0x890 fs/super.c:1076
   do_remount fs/namespace.c:3279 [inline]
   path_mount+0xd1a/0xfe0 fs/namespace.c:4027
   do_mount fs/namespace.c:4048 [inline]
   __do_sys_mount fs/namespace.c:4236 [inline]
   __se_sys_mount+0x313/0x410 fs/namespace.c:4213
   do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
   do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94
   entry_SYSCALL_64_after_hwframe+0x77/0x7f
   RIP: 0033:0x7f424e39066a
  Code: d8 64 89 02 (...)
  RSP: 002b:00007f424d9fde68 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
  RAX: ffffffffffffffda RBX: 00007f424d9fdef0 RCX: 00007f424e39066a
  RDX: 0000200000000180 RSI: 0000200000000380 RDI: 0000000000000000
  RBP: 0000200000000180 R08: 00007f424d9fdef0 R09: 0000000000000020
  R10: 0000000000000020 R11: 0000000000000246 R12: 0000200000000380
  R13: 00007f424d9fdeb0 R14: 0000000000000000 R15: 00002000000002c0
   &lt;/TASK&gt;
  Modules linked in:
  ---[ end trace 0000000000000000 ]---</Note>
    </Notes>
    <CVE>CVE-2025-40100</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/vmscape: Add conditional IBPB mitigation

VMSCAPE is a vulnerability that exploits insufficient branch predictor
isolation between a guest and a userspace hypervisor (like QEMU). Existing
mitigations already protect kernel/KVM from a malicious guest. Userspace
can additionally be protected by flushing the branch predictors after a
VMexit.

Since it is the userspace that consumes the poisoned branch predictors,
conditionally issue an IBPB after a VMexit and before returning to
userspace. Workloads that frequently switch between hypervisor and
userspace will incur the most overhead from the new IBPB.

This new IBPB is not integrated with the existing IBPB sites. For
instance, a task can use the existing speculation control prctl() to
get an IBPB at context switch time. With this implementation, the
IBPB is doubled up: one at context switch and another before running
userspace.

The intent is to integrate and optimize these cases post-embargo.

[ dhansen: elaborate on suboptimal IBPB solution ]</Note>
    </Notes>
    <CVE>CVE-2025-40300</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 systems utilizing LUKS-encrypted disks with GRUB configured for TPM-based auto-decryption. When GRUB is set to automatically decrypt disks using keys stored in the TPM, it reads the decryption key into system memory. If an attacker with physical access can corrupt the underlying filesystem superblock, GRUB will fail to locate a valid filesystem and enter rescue mode. At this point, the disk is already decrypted, and the decryption key remains loaded in system memory. This scenario may allow an attacker with physical access to access the unencrypted data without any further authentication, thereby compromising data confidentiality. Furthermore, the ability to force this state through filesystem corruption also presents a data integrity concern.</Note>
    </Notes>
    <CVE>CVE-2025-4382</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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">runc is a CLI tool for spawning and running containers according to the OCI specification. Versions 1.0.0-rc3 through 1.2.7, 1.3.0-rc.1 through 1.3.2, and 1.4.0-rc.1 through 1.4.0-rc.2, due to insufficient checks when bind-mounting `/dev/pts/$n` to `/dev/console` inside the container, an attacker can trick runc into bind-mounting paths which would normally be made read-only or be masked onto a path that the attacker can write to. This attack is very similar in concept and application to CVE-2025-31133, except that it attacks a similar vulnerability in a different target (namely, the bind-mount of `/dev/pts/$n` to `/dev/console` as configured for all containers that allocate a console). This happens after `pivot_root(2)`, so this cannot be used to write to host files directly -- however, as with CVE-2025-31133, this can load to denial of service of the host or a container breakout by providing the attacker with a writable copy of `/proc/sysrq-trigger` or `/proc/sys/kernel/core_pattern` (respectively). This issue is fixed in versions 1.2.8, 1.3.3 and 1.4.0-rc.3.</Note>
    </Notes>
    <CVE>CVE-2025-52565</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">runc is a CLI tool for spawning and running containers according to the OCI specification. In versions 1.2.7, 1.3.2 and 1.4.0-rc.2, an attacker can trick runc into misdirecting writes to /proc to other procfs files through the use of a racing container with shared mounts (we have also verified this attack is possible to exploit using a standard Dockerfile with docker buildx build as that also permits triggering parallel execution of containers with custom shared mounts configured). This redirect could be through symbolic links in a tmpfs or theoretically other methods such as regular bind-mounts. While similar, the mitigation applied for the related CVE, CVE-2019-19921, was fairly limited and effectively only caused runc to verify that when LSM labels are written they are actually procfs files. This issue is fixed in versions 1.2.8, 1.3.3, and 1.4.0-rc.3.</Note>
    </Notes>
    <CVE>CVE-2025-52881</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">Vim is an open source, command line text editor. Prior to version 9.1.1552, a path traversal issue in Vim's tar.vim plugin can allow overwriting of arbitrary files when opening specially crafted tar archives. Impact is low because this exploit requires direct user interaction. However, successfully exploitation can lead to overwriting sensitive files or placing executable code in privileged locations, depending on the permissions of the process editing the archive. The victim must edit such a file using Vim which will reveal the filename and the file content, a careful user may suspect some strange things going on. Successful exploitation could results in the ability to execute arbitrary commands on the underlying operating system. Version 9.1.1552 contains a patch for the vulnerability.</Note>
    </Notes>
    <CVE>CVE-2025-53905</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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. Prior to version 9.1.1551, a path traversal issue in Vim's zip.vim plugin can allow overwriting of arbitrary files when opening specially crafted zip archives. Impact is low because this exploit requires direct user interaction. However, successfully exploitation can lead to overwriting sensitive files or placing executable code in privileged locations, depending on the permissions of the process editing the archive. The victim must edit such a file using Vim which will reveal the filename and the file content, a careful user may suspect some strange things going on. Successful exploitation could results in the ability to execute arbitrary commands on the underlying operating system. Version 9.1.1551 contains a patch for the vulnerability.</Note>
    </Notes>
    <CVE>CVE-2025-53906</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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">A vulnerability has been identified in the GRUB2 bootloader's network module that poses an immediate Denial of Service (DoS) risk. This flaw is a Use-after-Free issue, caused because the net_set_vlan command is not properly unregistered when the network module is unloaded from memory. An attacker who can execute this command can force the system to access memory locations that are no longer valid. Successful exploitation leads directly to system instability, which can result in a complete crash and halt system availability</Note>
    </Notes>
    <CVE>CVE-2025-54770</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 has been identified in the GNU GRUB (Grand Unified Bootloader). The flaw occurs because the file-closing process incorrectly retains a memory pointer, leaving an invalid reference to a file system structure. An attacker could exploit this vulnerability to cause grub to crash, leading to a Denial of Service. Possible data integrity or confidentiality compromise is not discarded.</Note>
    </Notes>
    <CVE>CVE-2025-54771</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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. In versions from 9.1.1231 to before 9.1.1400, When processing nested tuples in Vim script, an error during evaluation can trigger a use-after-free in Vim's internal tuple reference management. Specifically, the tuple_unref() function may access already freed memory due to improper lifetime handling, leading to memory corruption. The exploit requires direct user interaction, as the script must be explicitly executed within Vim. This issue has been patched in version 9.1.1400.</Note>
    </Notes>
    <CVE>CVE-2025-55157</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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. In versions from 9.1.1231 to before 9.1.1406, when processing nested tuples during Vim9 script import operations, an error during evaluation can trigger a double-free in Vim's internal typed value (typval_T) management. Specifically, the clear_tv() function may attempt to free memory that has already been deallocated, due to improper lifetime handling in the handle_import / ex_import code paths. The vulnerability can only be triggered if a user explicitly opens and executes a specially crafted Vim script. This issue has been patched in version 9.1.1406.</Note>
    </Notes>
    <CVE>CVE-2025-55158</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">libexpat in Expat before 2.7.2 allows attackers to trigger large dynamic memory allocations via a small document that is submitted for parsing.</Note>
    </Notes>
    <CVE>CVE-2025-59375</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 Podman. The podman machine init command fails to verify the TLS certificate when downloading the VM images from an OCI registry. This issue results in a Man In The Middle attack.</Note>
    </Notes>
    <CVE>CVE-2025-6032</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">A vulnerability has been identified in the GRUB (Grand Unified Bootloader) component. This flaw occurs because the bootloader mishandles string conversion when reading information from a USB device, allowing an attacker to exploit inconsistent length values. A local attacker can connect a maliciously configured USB device during the boot sequence to trigger this issue. A successful exploitation may lead GRUB to crash, leading to a Denial of Service. Data corruption may be also possible, although given the complexity of the exploit the impact is most likely limited.</Note>
    </Notes>
    <CVE>CVE-2025-61661</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 has been discovered in GRUB's gettext module. This flaw stems from a programming error where the gettext command remains registered in memory after its module is unloaded. An attacker can exploit this condition by invoking the orphaned command, causing the application to access a memory location that is no longer valid. An attacker could exploit this vulnerability to cause grub to crash, leading to a Denial of Service. Possible data integrity or confidentiality compromise is not discarded.</Note>
    </Notes>
    <CVE>CVE-2025-61662</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 has been identified in the GRUB2 bootloader's normal command that poses an immediate Denial of Service (DoS) risk. This flaw is a Use-after-Free issue, caused because the normal command is not properly unregistered when the module is unloaded. An attacker who can execute this command can force the system to access memory locations that are no longer valid. Successful exploitation leads directly to system instability, which can result in a complete crash and halt system availability. Impact on the data integrity and confidentiality is also not discarded.</Note>
    </Notes>
    <CVE>CVE-2025-61663</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 in the GRUB2 bootloader has been identified in the normal module. This flaw, a memory Use After Free issue, occurs because the normal_exit command is not properly unregistered when its related module is unloaded. An attacker can exploit this condition by invoking the command after the module has been removed, causing the system to improperly access a previously freed memory location. This leads to a system crash or possible impacts in data confidentiality and integrity.</Note>
    </Notes>
    <CVE>CVE-2025-61664</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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">containerd is an open-source container runtime. Versions 1.7.28 and below, 2.0.0-beta.0 through 2.0.6, 2.1.0-beta.0 through 2.1.4, and 2.2.0-beta.0 through 2.2.0-rc.1 contain a bug in the CRI Attach implementation where a user can exhaust memory on the host due to goroutine leaks. This issue is fixed in versions 1.7.29, 2.0.7, 2.1.5 and 2.2.0. To workaround this vulnerability, users can set up an admission controller to control accesses to pods/attach resources.</Note>
    </Notes>
    <CVE>CVE-2025-64329</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 glib. An integer overflow during temporary file creation leads to an out-of-bounds memory access, allowing an attacker to potentially perform path traversal or access private temporary file content by creating symbolic links. This vulnerability allows a local attacker to manipulate file paths and access unauthorized data. The core issue stems from insufficient validation of file path lengths during temporary file operations.</Note>
    </Notes>
    <CVE>CVE-2025-7039</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 libxslt library. The same memory field, psvi, is used for both stylesheet and input data, which can lead to type confusion during XML transformations. This vulnerability allows an attacker to crash the application or corrupt memory. In some cases, it may lead to denial of service or unexpected behavior.</Note>
    </Notes>
    <CVE>CVE-2025-7424</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">A flaw was found in libssh, a library that implements the SSH protocol. When calculating the session ID during the key exchange (KEX) process, an allocation failure in cryptographic functions may lead to a NULL pointer dereference. This issue can cause the client or server to crash.</Note>
    </Notes>
    <CVE>CVE-2025-8114</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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">A flaw was found in libssh's handling of key exchange (KEX) processes when a client repeatedly sends incorrect KEX guesses. The library fails to free memory during these rekey operations, which can gradually exhaust system memory. This issue can lead to crashes on the client side, particularly when using libgcrypt, which impacts application stability and availability.</Note>
    </Notes>
    <CVE>CVE-2025-8277</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">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>
  <Vulnerability 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: An application trying to decrypt CMS messages encrypted using
password based encryption can trigger an out-of-bounds read and write.

Impact summary: This out-of-bounds read may trigger a crash which leads to
Denial of Service for an application. The out-of-bounds write can cause
a memory corruption which can have various consequences including
a Denial of Service or Execution of attacker-supplied code.

Although the consequences of a successful exploit of this vulnerability
could be severe, the probability that the attacker would be able to
perform it is low. Besides, password based (PWRI) encryption support in CMS
messages is very rarely used. For that reason the issue was assessed as
Moderate severity according to our Security Policy.

The FIPS modules in 3.5, 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by this
issue, as the CMS implementation is outside the OpenSSL FIPS module
boundary.</Note>
    </Notes>
    <CVE>CVE-2025-9230</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's a vulnerability in podman where an attacker may use the kube play command to overwrite host files when the kube file container a Secrete or a ConfigMap volume mount and such volume contains a symbolic link to a host file path. In a successful attack, the attacker can only control the target file to be overwritten but not the content to be written into the file.

Binary-Affected: podman
Upstream-version-introduced: v4.0.0
Upstream-version-fixed: v5.6.1</Note>
    </Notes>
    <CVE>CVE-2025-9566</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
</cvrfdoc>
