SUSE-IU-2025:1815-1 SUSE Image security@suse.de SUSE Security Team SUSE Image SUSE-IU-2025:1815-1 Interim 1 1 2026-03-19T08:55:16Z current 2025-07-09T01:00:00Z 2025-07-09T01:00:00Z cve-database/bin/generate-cvrf-publiccloud.pl 2021-02-18T01:00:00Z Image update for SUSE-IU-2025:1815-1 / google/sles-12-sp5-sap-v20250709-x86-64 This image update for google/sles-12-sp5-sap-v20250709-x86-64 contains the following changes: Package libxml2 was updated: - security update- added patches CVE-2025-32414 [bsc#1241551], out-of-bounds read when parsing text via the Python API + libxml2-CVE-2025-32414.patch CVE-2025-32415 [bsc#1241453], a crafted XML document may lead to a heap-based buffer under-read + libxml2-CVE-2025-32415.patch Package pacemaker was updated: - pacemaker-attrd: use %PRIu32 format specifier instead of %u for node id (bsc#1239629, gh#ClusterLabs/pacemaker#3860) * bsc#1239629-0004-Log-pacemaker-attrd-use-PRIu32-format-specifier-inst.patch - libcrmcluster: correctly log node id (bsc#1239629, gh#ClusterLabs/pacemaker#3860) * bsc#1239629-0003-Log-libcrmcluster-correctly-log-node-id.patch - pacemaker-attrd: prevent segfault if a peer leaves when its name is unknown yet (bsc#1239629, gh#ClusterLabs/pacemaker#3860) * bsc#1239629-0001-Fix-pacemaker-attrd-prevent-segfault-if-a-peer-leave.patch - spec: create a temporary file in /run directory (bsc#1239770) - libcrmservices: Unref the dbus connection... (gh#ClusterLabs/pacemaker#3841) * pacemaker#3841-0002-Refactor-libcrmservices-Unref-the-dbus-connection.patch - libcrmservices: Don't leak msg if systemd_proxy is NULL. (gh#ClusterLabs/pacemaker#3841) * pacemaker#3841-0001-Low-libcrmservices-Don-t-leak-msg-if-systemd_proxy-i.patch - cts-scheduler: update tests for considering parents of an unmanaged resource active on the node (gh#ClusterLabs/pacemaker#3842, bsc#1238519) * bsc#1238519-0002-Test-cts-scheduler-update-tests-for-considering-pare.patch - libpe_status: consider parents of an unmanaged resource active on the node (gh#ClusterLabs/pacemaker#3842, bsc#1238519) * bsc#1238519-0001-Fix-libpe_status-consider-parents-of-an-unmanaged-re.patch - various: address format-overflow warnings (gh#ClusterLabs/pacemaker#3795) * pacemaker#3795-0001-Low-various-address-format-overflow-warnings.patch - libpacemaker: set fail-count to INFINITY for fatal failures (gh#ClusterLabs/pacemaker#3772) * pacemaker#3772-0002-Fix-libpacemaker-set-fail-count-to-INFINITY-for-fata.patch - libpacemaker: add PCMK__XA_FAILED_START_OFFSET and PCMK__XA_FAILED_STOP_OFFSET (gh#ClusterLabs/pacemaker#3772) * pacemaker#3772-0001-Refactor-libpacemaker-add-PCMK__XA_FAILED_START_OFFS.patch Package icu was updated: - Add icu-CVE-2025-5222.patch: Backport 2c667e3 from upstream, ICU-22973 Fix buffer overflow by using CharString. (CVE-2025-5222, bsc#1243721) - Add icu-CVE-2025-5222-shim06_9e4365c.patch Backport 9e4365c from upstream, ICU-10810 genrb: preflight strings on final parse tree, not while building the tree. To prepare dependence code for CVE-2025-5222 fix. (CVE-2025-5222, bsc#1243721) - Add icu-CVE-2025-5222-shim05_7496867.patch: Backport 7496867 from markusicu upstream, which is tree merged to icu. ICU-9101 build all source/data/coll/ tailorings, except search, with new CollationBuilder. To prepare dependence code for CVE-2025-5222 fix. (CVE-2025-5222, bsc#1243721) - Add icu-CVE-2025-5222-shim04_8067293.patch: Backport 8067293 from upstream, ICU-10043 ignore the genrb - -omitCollationRules flag while importing rules. To prepare dependence code for CVE-2025-5222 fix. (CVE-2025-5222, bsc#1243721) - Add icu-CVE-2025-5222-shim03-dd72356.patch: Backport dd72356 from upstream, ICU-11276 Adding UChar* method in CharString. To prepare dependence code for CVE-2025-5222 fix. (CVE-2025-5222, bsc#1243721) - Add icu-CVE-2025-5222-shim02_80a6684.patch: Backport 80a6684 from upstream, ICU-11794 change error handling of CharString::appendInvariantChars(). To prepare dependence code for CVE-2025-5222 fix. (CVE-2025-5222, bsc#1243721) - Add icu-CVE-2025-5222-shim01.patch: Include stringpiece.h charstr.h for following source porting. To prepare dependence code for CVE-2025-5222 fix. (CVE-2025-5222, bsc#1243721) Package suse-build-key was updated: - add and run a import-suse-build-key script, which will be run after installation using a systemd timer. (jsc#PED-2777) Package cloud-regionsrv-client was updated: - Update version to 10.4.0 + Remove repositories when the package is being removed We do not want to leave repositories behind refering to the plugin that is being removed when the package gets removed (bsc#1240310, bsc#1240311) + Turn docker into an optional setup (jsc#PCT-560) Change the Requires into a Recommends and adapt the code accordingly + Support flexible licenses in GCE (jsc#PCT-531) + Drop the azure-addon package it is geting replaced by the license-watcher package which has a generic implementation of the same functionality. + Handle cache inconsistencies (bsc#1218345) + Properly handle the zypper root target argument (bsc#1240997) Package iputils was updated: - Security fix [bsc#1242300, CVE-2025-47268] * integer overflow in RTT calculation can lead to undefined behavior * Add iputils-CVE-2025-47268.patch Package google-cloud-sap-agent was updated: - Update to version v3.7: (bsc#1238831, bsc#1238833) * No public description * Moving CG disk validation to CheckPreConditions * Fix issue with filling in ha_hosts in HANA systems * Use updated UAP method for Guest Actions * Fix grep command used for landscape ID discovery * Correct arguments used by HANA disk discovery. * Add tagged disks to discovery data sent to Data Warehouse * Identify disks by mount point in SAP System data. * Auto updated compiled protocol buffers * Add collection for WLM Pacemaker alias IP setting. * Add the Maintenance Events Sample Dashboard * Auto updated compiled protocol buffers * Remove obsolete events proto from sapagent * Auto updated compiled protocol buffers * Add collection for WLM Pacemaker health check and internal load balancer metrics. * Auto updated compiled protocol buffers * Add collection for WLM Pacemaker SAPInstance automatic recover and monitor settings. * Remove restart logic used in configure OTE. Rely on config poller. * fixing TypedValue * migrating from the platform integration/common/shared to sharedlibraries * Default topology to SCALE_UP for non-HANA DBs. * Remove restarting from guestactions Package python-setuptools was updated: - Add patch CVE-2025-47273.patch to fix A path traversal vulnerability. (bsc#1243313, CVE-2025-47273, gh#pypa/setuptools@250a6d17978f) Package pam-config was updated: - Stop adding pam_env in AUTH stack, and be sure to put this module at the really end of the SESSION stack. [bsc#1243226, CVE-2025-6018, remove-pam_env-from-auth-stack.patch] Package pam was updated: - pam_namespace: convert functions that may operate on a user-controlled path to operate on file descriptors instead of absolute path. And keep the bind-mount protection from protect_mount() as a defense in depthmeasure. [bsc#1244509 pam_inline-introduce-pam_asprintf-pam_snprintf-and-p.patch, pam_namespace-fix-potential-privilege-escalation.patch, pam_namespace-add-flags-to-indicate-path-safety.patch, pam_namespace-secure_opendir-do-not-look-at-the-grou.patch] - pam_namespace-fix-potential-privilege-escalation.patch adapted and includes changes from upstream commits: ds6242a, bc856cd. * pam_namespace fix logic in return value handling * pam_namespace move functions around - pam_env: Change the default to not read the user .pam_environment file [bsc#1243226, CVE-2025-6018, pam_env-change-the-default-to-not-read-the-user-env.patch] 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 perl was updated: - do not change the current directory when cloning an open directory handle [bnc#1244079] [CVE-2025-40909] new patch: perl-dirdup.diff Package ca-certificates-mozilla was updated: - Fix awk to compare (missing a =) and give the following output: [#] NSS_BUILTINS_LIBRARY_VERSION &quot;2.74&quot; - pass file argument to awk (bsc#1240009) - update to 2.74 state of Mozilla SSL root CAs: Removed: * SwissSign Silver CA - G2 Added: * D-TRUST BR Root CA 2 2023 * D-TRUST EV Root CA 2 2023 - remove extensive signature printing in comments of the cert bundle - Define two macros to break a build cycle with p11-kit. - Updated to 2.72 state of Mozilla SSL root CAs (bsc#1234798) Removed: - SecureSign RootCA11 - Security Communication RootCA3 Added: - TWCA CYBER Root CA - TWCA Global Root CA G2 - SecureSign Root CA12 - SecureSign Root CA14 - SecureSign Root CA15 Package timezone was updated: - Update to 2025b: * New zone for Aysén Region in Chile (America/Coyhaique) which moves from -04/-03 to -03 - Refresh patches * revert-philippines-historical-data.patch * tzdata-china.diff Package expat was updated: - version update to 2.7.1 for SLE-12- modified sources % expatfaq.html - deleted patches - config-guess-sub-update.patch (upstreamed) - expat-2.1.0-CVE-2016-9063.patch (upstreamed) - expat-2.1.0-heap_buffer_overflow.patch (upstreamed) - expat-2.1.0-parser_crashes_on_malformed_input.patch (upstreamed) - expat-2.1.1-CVE-2012-6702.patch (upstreamed) - expat-CVE-2017-9233.patch (upstreamed) - expat-CVE-2018-20843.patch (upstreamed) - expat-CVE-2019-15903-tests.patch (upstreamed) - expat-CVE-2019-15903.patch (upstreamed) - expat-CVE-2021-45960.patch (upstreamed) - expat-CVE-2021-46143.patch (upstreamed) - expat-CVE-2022-22822.patch (upstreamed) - expat-CVE-2022-22823.patch (upstreamed) - expat-CVE-2022-22824.patch (upstreamed) - expat-CVE-2022-22825.patch (upstreamed) - expat-CVE-2022-22826.patch (upstreamed) - expat-CVE-2022-22827.patch (upstreamed) - expat-CVE-2022-23852.patch (upstreamed) - expat-CVE-2022-23990.patch (upstreamed) - expat-CVE-2022-25235.patch (upstreamed) - expat-CVE-2022-25236-relax-fix.patch (upstreamed) - expat-CVE-2022-25236.patch (upstreamed) - expat-CVE-2022-25313-fix-regression.patch (upstreamed) - expat-CVE-2022-25313.patch (upstreamed) - expat-CVE-2022-25314-before.patch (upstreamed) - expat-CVE-2022-25314.patch (upstreamed) - expat-CVE-2022-25315.patch (upstreamed) - expat-CVE-2022-40674.patch (upstreamed) - expat-CVE-2022-43680.patch (upstreamed) - expat-CVE-2023-52425-1.patch (upstreamed) - expat-CVE-2023-52425-2.patch (upstreamed) - expat-CVE-2023-52425-backport-parser-changes.patch (upstreamed) - expat-CVE-2023-52425-fix-tests.patch (upstreamed) - expat-CVE-2024-45490.patch (upstreamed) - expat-CVE-2024-45491.patch (upstreamed) - expat-CVE-2024-45492.patch (upstreamed) - expat-CVE-2024-50602.patch (upstreamed) - expat-alloc-size.patch (upstreamed) - expat-visibility.patch (upstreamed) - version update to 2.7.1 Bug fixes: [#980] #989 Restore event pointer behavior from Expat 2.6.4 (that the fix to CVE-2024-8176 changed in 2.7.0); affected API functions are: - XML_GetCurrentByteCount - XML_GetCurrentByteIndex - XML_GetCurrentColumnNumber - XML_GetCurrentLineNumber - XML_GetInputContext Other changes: [#976] #977 Autotools: Integrate files &quot;fuzz/xml_lpm_fuzzer.{cpp,proto}&quot; with Automake that were missing from 2.7.0 release tarballs [#983] #984 Fix printf format specifiers for 32bit Emscripten [#992] docs: Promote OpenSSF Best Practices self-certification [#978] tests/benchmark: Resolve mistaken double close [#986] Address compiler warnings [#990] #993 Version info bumped from 11:1:10 (libexpat*.so.1.10.1) to 11:2:10 (libexpat*.so.1.10.2); see https://verbump.de/ for what these numbers do Infrastructure: [#982] CI: Start running Perl XML::Parser integration tests [#987] CI: Enforce Clang Static Analyzer clean code [#991] CI: Re-enable warning clang-analyzer-valist.Uninitialized for clang-tidy [#981] CI: Cover compilation with musl [#983] #984 CI: Cover compilation with 32bit Emscripten [#976] #977 CI: Protect against fuzzer files missing from future release archives - version update to 2.7.0 (CVE-2024-8176 [bsc#1239618]) * Security fixes: [#893] #973 CVE-2024-8176 -- Fix crash from chaining a large number of entities caused by stack overflow by resolving use of recursion, for all three uses of entities: - general entities in character data (&quot;&lt;e&gt;&amp;g1;&lt;/e&gt;&quot;) - general entities in attribute values (&quot;&lt;e k1='&amp;g1;'/&gt;&quot;) - parameter entities (&quot;%p1;&quot;) Known impact is (reliable and easy) denial of service: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H/E:H/RL:O/RC:C (Base Score: 7.5, Temporal Score: 7.2) Please note that a layer of compression around XML can significantly reduce the minimum attack payload size. * Other changes: [#935] #937 Autotools: Make generated CMake files look for libexpat.@SO_MAJOR@.dylib on macOS [#925] Autotools: Sync CMake templates with CMake 3.29 [#945] #962 #966 CMake: Drop support for CMake &lt;3.13 [#942] CMake: Small fuzzing related improvements [#921] docs: Add missing documentation of error code XML_ERROR_NOT_STARTED that was introduced with 2.6.4 [#941] docs: Document need for C++11 compiler for use from C++ [#959] tests/benchmark: Fix a (harmless) TOCTTOU [#944] Windows: Fix installer target location of file xmlwf.xml for CMake [#953] Windows: Address warning -Wunknown-warning-option about -Wno-pedantic-ms-format from LLVM MinGW [#971] Address Cppcheck warnings [#969] #970 Mass-migrate links from http:// to https:// [#947] #958 .. [#974] #975 Document changes since the previous release [#974] #975 Version info bumped from 11:0:10 (libexpat*.so.1.10.0) to 11:1:10 (libexpat*.so.1.10.1); see https://verbump.de/ for what these numbers do - no source changes, just adding jira reference: jsc#SLE-21253 Package resource-agents was updated: - L3: DB2 resource agent forcefully shuts down database, risking data loss — ref:_00D1igLOd._500TrYJM7l:ref (bsc#1241692) Remove bad patch: 0001-db2-HADR-add-STANDBY-REMOTE_CATCHUP_PENDING-DISCONNE.patch Package _product:sle-sdk-release was updated: Package sqlite3 was updated: - Sync version 3.49.1 from Factory (jsc#SLE-16032): * CVE-2025-29087, bsc#1241020: Fix a bug in the concat_ws() function, introduced in version 3.44.0, that could lead to a memory error if the separator string is very large (hundreds of megabytes). * CVE-2025-29088, bsc#1241078: Enhanced the SQLITE_DBCONFIG_LOOKASIDE interface to make it more robust against misuse. * Obsoletes sqlite3-rtree-i686.patch 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; scoos * remove support for Windows 16 bit * renamed the prwin16.h header to prwin.h * configure was updated from 2.69 to 2.71 * various build, test and automation script fixes * major parts of the source code were reformatted Package mozilla-nss was updated: - update to NSS 3.112 * bmo#1963792 - Fix alias for mac workers on try * bmo#1966786 - ensure all options can be configured with SSL_OptionSet and SSL_OptionSetDefault * bmo#1931930 - ABI/API break in ssl certificate processing * bmo#1955971 - remove unnecessary assertion in sec_asn1d_init_state_based_on_template * bmo#1965754 - update taskgraph to v14.2.1 * bmo#1964358 - Workflow for automation of the release on GitHub when pushing a tag * bmo#1952860 - fix faulty assertions in SEC_ASN1DecoderUpdate * bmo#1934877 - Renegotiations should use a fresh ECH GREASE buffer * bmo#1951396 - update taskgraph to v14.1.1 * bmo#1962503 - Partial fix for ACVP build CI job * bmo#1961827 - Initialize find in sftk_searchDatabase * bmo#1963121 - Add clang-18 to extra builds * bmo#1963044 - Fault tolerant git fetch for fuzzing * bmo#1962556 - Tolerate intermittent failures in ssl_policy_pkix_ocsp * bmo#1962770 - fix compiler warnings when DEBUG_ASN1D_STATES or CMSDEBUG are set * bmo#1961835 - fix content type tag check in NSS_CMSMessage_ContainsCertsOrCrls * bmo#1963102 - Remove Cryptofuzz CI version check - update to NSS 3.111 * bmo#1930806 - FIPS changes need to be upstreamed: force ems policy * bmo#1957685 - Turn off Websites Trust Bit from CAs * bmo#1937338 - Update nssckbi version following April 2025 Batch of Changes * bmo#1943135 - Disable SMIME ‘trust bit’ for GoDaddy CAs * bmo#1874383 - Replaced deprecated sprintf function with snprintf in dbtool.c * bmo#1954612 - Need up update NSS for PKCS 3.1 * bmo#1773374 - avoid leaking localCert if it is already set in ssl3_FillInCachedSID * bmo#1953097 - Decrease ASAN quarantine size for Cryptofuzz in CI * bmo#1943962 - selfserv: Add support for zlib certificate compression - update to NSS 3.110 * bmo#1930806 - FIPS changes need to be upstreamed: force ems policy * bmo#1954724 - Prevent excess allocations in sslBuffer_Grow * bmo#1953429 - Remove Crl templates from ASN1 fuzz target * bmo#1953429 - Remove CERT_CrlTemplate from ASN1 fuzz target * bmo#1952855 - Fix memory leak in NSS_CMSMessage_IsSigned * bmo#1930807 - NSS policy updates * bmo#1951161 - Improve locking in nssPKIObject_GetInstances * bmo#1951394 - Fix race in sdb_GetMetaData * bmo#1951800 - Fix member access within null pointer * bmo#1950077 - Increase smime fuzzer memory limit * bmo#1949677 - Enable resumption when using custom extensions * bmo#1952568 - change CN of server12 test certificate * bmo#1949118 - Part 2: Add missing check in NSS_CMSDigestContext_FinishSingle * bmo#1949118 - Part 1: Fix smime UBSan errors * bmo#1930806 - FIPS changes need to be upstreamed: updated key checks * bmo#1951491 - Don't build libpkix in static builds * bmo#1951395 - handle `-p all` in try syntax * bmo#1951346 - fix opt-make builds to actually be opt * bmo#1951346 - fix opt-static builds to actually be opt * bmo#1916439 - Remove extraneous assert - Removed upstreamed nss-fips-stricter-dh.patch - Added bmo1962556.patch to fix test failures - Rebased nss-fips-approved-crypto-non-ec.patch nss-fips-combined-hash-sign-dsa-ecdsa.patch - update to NSS 3.109 * bmo#1939512 - Call BL_Init before RNG_RNGInit() so that special SHA instructions can be used if available * bmo#1930807 - NSS policy updates - fix inaccurate key policy issues * bmo#1945883 - SMIME fuzz target * bmo#1914256 - ASN1 decoder fuzz target * bmo#1936001 - Part 2: Revert “Extract testcases from ssl gtests for fuzzing” * bmo#1915155 - Add fuzz/README.md * bmo#1936001 - Part 4: Fix tstclnt arguments script * bmo#1944545 - Extend pkcs7 fuzz target * bmo#1912320 - Extend certDN fuzz target * bmo#1944300 - revert changes to HACL* files from bug 1866841 * bmo#1936001 - Part 3: Package frida corpus script - update to NSS 3.108 * bmo#1923285 - libclang-16 -&gt; libclang-19 * bmo#1939086 - Turn off Secure Email Trust Bit for Security Communication ECC RootCA1 * bmo#1937332 - Turn off Secure Email Trust Bit for BJCA Global Root CA1 and BJCA Global Root CA2 * bmo#1915902 - Remove SwissSign Silver CA – G2 * bmo#1938245 - Add D-Trust 2023 TLS Roots to NSS * bmo#1942301 - fix fips test failure on windows * bmo#1935925 - change default sensitivity of KEM keys * bmo#1936001 - Part 1: Introduce frida hooks and script * bmo#1942350 - add missing arm_neon.h include to gcm.c * bmo#1831552 - ci: update windows workers to win2022 * bmo#1831552 - strip trailing carriage returns in tools tests * bmo#1880256 - work around unix/windows path translation issues in cert test script * bmo#1831552 - ci: let the windows setup script work without $m * bmo#1880255 - detect msys * bmo#1936680 - add a specialized CTR_Update variant for AES-GCM * bmo#1930807 - NSS policy updates * bmo#1930806 - FIPS changes need to be upstreamed: FIPS 140-3 RNG * bmo#1930806 - FIPS changes need to be upstreamed: Add SafeZero * bmo#1930806 - FIPS changes need to be upstreamed - updated POST * bmo#1933031 - Segmentation fault in SECITEM_Hash during pkcs12 processing * bmo#1929922 - Extending NSS with LoadModuleFromFunction functionality * bmo#1935984 - Ensure zero-initialization of collectArgs.cert * bmo#1934526 - pkcs7 fuzz target use CERT_DestroyCertificate * bmo#1915898 - Fix actual underlying ODR violations issue * bmo#1184059 - mozilla::pkix: allow reference ID labels to begin and/or end with hyphens * bmo#1927953 - don't look for secmod.db in nssutil_ReadSecmodDB if NSS_DISABLE_DBM is set * bmo#1934526 - Fix memory leak in pkcs7 fuzz target * bmo#1934529 - Set -O2 for ASan builds in CI * bmo#1934543 - Change branch of tlsfuzzer dependency * bmo#1915898 - Run tests in CI for ASan builds with detect_odr_violation=1 * bmo#1934241 - Fix coverage failure in CI * bmo#1934213 - Add fuzzing for delegated credentials, DTLS short header and Tls13BackendEch * bmo#1927142 - Add fuzzing for SSL_EnableTls13GreaseEch and SSL_SetDtls13VersionWorkaround * bmo#1913677 - Part 3: Restructure fuzz/ * bmo#1931925 - Extract testcases from ssl gtests for fuzzing * bmo#1923037 - Force Cryptofuzz to use NSS in CI * bmo#1923037 - Fix Cryptofuzz on 32 bit in CI * bmo#1933154 - Update Cryptofuzz repository link * bmo#1926256 - fix build error from 9505f79d * bmo#1926256 - simplify error handling in get_token_objects_for_cache * bmo#1931973 - nss doc: fix a warning * bmo#1930797 - pkcs12 fixes from RHEL need to be picked up - remove obsolete patches * nss-fips-safe-memset.patch * nss-bmo1930797.patch - update to NSS 3.107 * bmo#1923038 - Remove MPI fuzz targets. * bmo#1925512 - Remove globals `lockStatus` and `locksEverDisabled`. * bmo#1919015 - Enable PKCS8 fuzz target. * bmo#1923037 - Integrate Cryptofuzz in CI. * bmo#1913677 - Part 2: Set tls server target socket options in config class * bmo#1913677 - Part 1: Set tls client target socket options in config class * bmo#1913680 - Support building with thread sanitizer. * bmo#1922392 - set nssckbi version number to 2.72. * bmo#1919913 - remove Websites Trust Bit from Entrust Root Certification Authority - G4. * bmo#1920641 - remove Security Communication RootCA3 root cert. * bmo#1918559 - remove SecureSign RootCA11 root cert. * bmo#1922387 - Add distrust-after for TLS to Entrust Roots. * bmo#1927096 - update expected error code in pk12util pbmac1 tests. * bmo#1929041 - Use random tstclnt args with handshake collection script * bmo#1920466 - Remove extraneous assert in ssl3gthr.c. * bmo#1928402 - Adding missing release notes for NSS_3_105. * bmo#1874451 - Enable the disabled mlkem tests for dtls. * bmo#1874451 - NSS gtests filter cleans up the constucted buffer before the use. * bmo#1925505 - Make ssl_SetDefaultsFromEnvironment thread-safe. * bmo#1925503 - Remove short circuit test from ssl_Init. - fix build on loongarch64 (setting it as 64bit arch) - Remove upstreamed bmo-1400603.patch - Added nss-bmo1930797.patch to fix failing tests in testsuite - update to NSS 3.106 * bmo#1925975 - NSS 3.106 should be distributed with NSPR 4.36. * bmo#1923767 - pk12util: improve error handling in p12U_ReadPKCS12File. * bmo#1899402 - Correctly destroy bulkkey in error scenario. * bmo#1919997 - PKCS7 fuzz target, r=djackson,nss-reviewers. * bmo#1923002 - Extract certificates with handshake collection script. * bmo#1923006 - Specify len_control for fuzz targets. * bmo#1923280 - Fix memory leak in dumpCertificatePEM. * bmo#1102981 - Fix UBSan errors for SECU_PrintCertificate and SECU_PrintCertificateBasicInfo. * bmo#1921528 - add new error codes to mozilla::pkix for Firefox to use. * bmo#1921768 - allow null phKey in NSC_DeriveKey. * bmo#1921801 - Only create seed corpus zip from existing corpus. * bmo#1826035 - Use explicit allowlist for for KDF PRFS. * bmo#1920138 - Increase optimization level for fuzz builds. * bmo#1920470 - Remove incorrect assert. * bmo#1914870 - Use libFuzzer options from fuzz/options/\*.options in CI. * bmo#1920945 - Polish corpus collection for automation. * bmo#1917572 - Detect new and unfuzzed SSL options. * bmo#1804646 - PKCS12 fuzzing target. - requires NSPR 4.36 - update to NSS 3.105 * bmo#1915792 - Allow importing PKCS#8 private EC keys missing public key * bmo#1909768 - UBSAN fix: applying zero offset to null pointer in sslsnce.c * bmo#1919577 - set KRML_MUSTINLINE=inline in makefile builds * bmo#1918965 - Don't set CKA_SIGN for CKK_EC_MONTGOMERY private keys * bmo#1918767 - override default definition of KRML_MUSTINLINE * bmo#1916525 - libssl support for mlkem768x25519 * bmo#1916524 - support for ML-KEM-768 in softoken and pk11wrap * bmo#1866841 - Add Libcrux implementation of ML-KEM 768 to FreeBL * bmo#1911912 - Avoid misuse of ctype(3) functions * bmo#1917311 - part 2: run clang-format * bmo#1917311 - part 1: upgrade to clang-format 13 * bmo#1916953 - clang-format fuzz * bmo#1910370 - DTLS client message buffer may not empty be on retransmit * bmo#1916413 - Optionally print config for TLS client and server fuzz target * bmo#1916059 - Fix some simple documentation issues in NSS. * bmo#1915439 - improve performance of NSC_FindObjectsInit when template has CKA_TOKEN attr * bmo#1912828 - define CKM_NSS_ECDHE_NO_PAIRWISE_CHECK_KEY_PAIR_GEN - Fix build error under Leap by rebasing nss-fips-safe-memset.patch. - update to NSS 3.104 * bmo#1910071 - Copy original corpus to heap-allocated buffer * bmo#1910079 - Fix min ssl version for DTLS client fuzzer * bmo#1908990 - Remove OS2 support just like we did on NSPR * bmo#1910605 - clang-format NSS improvements * bmo#1902078 - Adding basicutil.h to use HexString2SECItem function * bmo#1908990 - removing dirent.c from build * bmo#1902078 - Allow handing in keymaterial to shlibsign to make the output reproducible * bmo#1908990 - remove nec4.3, sunos4, riscos and SNI references * bmo#1908990 - remove other old OS (BSDI, old HP UX, NCR, openunix, sco, unixware or reliantUnix * bmo#1908990 - remove mentions of WIN95 * bmo#1908990 - remove mentions of WIN16 * bmo#1913750 - More explicit directory naming * bmo#1913755 - Add more options to TLS server fuzz target * bmo#1913675 - Add more options to TLS client fuzz target * bmo#1835240 - Use OSS-Fuzz corpus in NSS CI * bmo#1908012 - set nssckbi version number to 2.70. * bmo#1914499 - Remove Email Trust bit from ACCVRAIZ1 root cert. * bmo#1908009 - Remove Email Trust bit from certSIGN ROOT CA. * bmo#1908006 - Add Cybertrust Japan Roots to NSS. * bmo#1908004 - Add Taiwan CA Roots to NSS. * bmo#1911354 - remove search by decoded serial in nssToken_FindCertificateByIssuerAndSerialNumber * bmo#1913132 - Fix tstclnt CI build failure * bmo#1913047 - vfyserv: ensure peer cert chain is in db for CERT_VerifyCertificateNow * bmo#1912427 - Enable all supported protocol versions for UDP * bmo#1910361 - Actually use random PSK hash type * bmo#1911576 - Initialize NSS DB once * bmo#1910361 - Additional ECH cipher suites and PSK hash types * bmo#1903604 - Automate corpus file generation for TLS client Fuzzer * bmo#1910364 - Fix crash with UNSAFE_FUZZER_MODE * bmo#1910605 - clang-format shlibsign.c - remove obsolete nss-reproducible-builds.patch - update to NSS 3.103 * bmo#1908623 - move list size check after lock acquisition in sftk_PutObjectToList. * bmo#1899542 - Add fuzzing support for SSL_ENABLE_POST_HANDSHAKE_AUTH, * bmo#1909638 - Follow-up to fix test for presence of file nspr.patch. * bmo#1903783 - Adjust libFuzzer size limits * bmo#1899542 - Add fuzzing support for SSL_SetCertificateCompressionAlgorithm, SSL_SetClientEchConfigs, SSL_VersionRangeSet and SSL_AddExternalPsk * bmo#1899542 - Add fuzzing support for SSL_ENABLE_GREASE and SSL_ENABLE_CH_EXTENSION_PERMUTATION - Add nss-reproducible-builds.patch to make the rpms reproducible, by using a hardcoded, static key to generate the checksums (*.chk-files) - Updated nss-fips-approved-crypto-non-ec.patch to enforce approved curves with the CKK_EC_MONTGOMERY key type (bsc#1224113). - update to NSS 3.102.1 * bmo#1905691 - ChaChaXor to return after the function - update to NSS 3.102 * bmo#1880351 - Add Valgrind annotations to freebl Chacha20-Poly1305. * bmo#1901932 - missing sqlite header. * bmo#1901080 - GLOBALTRUST 2020: Set Distrust After for TLS and S/MIME. * bmo#1615298 - improve certutil keyUsage, extKeyUsage, and nsCertType keyword handling. * bmo#1660676 - correct length of raw SPKI data before printing in pp utility. - Add nss-reproducible-chksums.patch to make NSS-build reproducible Use key from openssl (bsc#1081723) - Updated nss-fips-approved-crypto-non-ec.patch to exclude the SHA-1 hash from SLI approval. Package wget was updated: - Drop support for shorthand URLs * Breaking change to fix CVE-2024-10524. [+ drop-support-for-shorthand-URLs.patch, bsc#1233773] Package kbd was updated: - Don't search for resources in the current directory. It can cause unwanted side effects or even infinite loop (bsc#1237230, kbd-ignore-working-directory-1.patch, kbd-ignore-working-directory-2.patch, kbd-ignore-working-directory-3.patch). Package openssh was updated: - Add openssh-bsc1232533-big-motd-failure.patch (bsc#1232533), fixing failures with very large MOTDs. Thanks to Ali Abdallah &lt;ali.abdallah@suse.com&gt;. Package _product:sle-live-patching-release was updated: Package python3-requests was updated: - Add CVE-2024-47081.patch upstream patch, fixes netrc credential leak (gh#psf/requests#6965, CVE-2024-47081, bsc#1244039) Package apparmor was updated: - Add dac_read_search capability for unix_chkpwd to allow it to read the shadow file even if it has 000 permissions. This is needed after the CVE-2024-10041 fix in PAM. * unix-chkpwd-add-read-capability.path, bsc#1241678 - Addapt the allow-pam_unix-to-execute-unix_chkpwd.patch for SLE12. (bsc#1241876) - Remove revert-abi-change-for-unix_chkpwd.patch - Allow pam_unix to execute unix_chkpwd with abi/3.0 - remove dovecot-unix_chkpwd.diff - Add allow-pam_unix-to-execute-unix_chkpwd.patch - Add revert-abi-change-for-unix_chkpwd.patch (bsc#1234452, bsc#1232234) Package SAPHanaSR was updated: - Version bump to 0.162.5 * SAPHanaSRTools.pm: fix problem with new pacemaker-node_state attribute content to show the correct node state in SAPHanaSR-monitor. (bsc#1243447, bsc#1243723) * enhance observability of the RAs and update version string * SAPHanaSR-hookHelper - use full path to call crm_node (bsc#1216918) * demo script SAPHanaSR-upgrade-to-angi-demo: fix check for package SAPHanaSR-angi available in the active repositories fix removal of the classic rpms * update man pages: SAPHanaSR_basic_cluster.7 SAPHanaSR.7 SAPHanaSR_upgrade_to_angi.7 SAPHanaSR_maintenance_examples.7 SAPHanaSR-showAttr.8 SAPHanaSR-upgrade-to-angi-demo.8 SAPHanaSR.py.7 susChkSrv.py.7 susCostOpt.py.7 ocf_suse_SAPHana.7 Package google-guest-configs was updated: - Check that %{_sysconfdir}/sysconfig/network/ifcfg-eth0 actually exists before making any modifications to it (bsc#1241112) Package python-requests was updated: - Add CVE-2024-47081.patch upstream patch, fixes netrc credential leak (gh#psf/requests#6965, CVE-2024-47081, bsc#1244039) Package google-guest-agent was updated: - Update to version 20250506.01 (bsc#1243254, bsc#1243505) * Make sure agent added connections are activated by NM (#534) - from version 20250506.00 * wrap NSS cache refresh in a goroutine (#533) - from version 20250502.01 * Wicked: Only reload interfaces for which configurations are written or changed. (#524) - from version 20250502.00 * Add AuthorizedKeysCompat to windows packaging (#530) * Remove error messages from gce_workload_cert_refresh and metadata script runner (#527) * Update guest-logging-go dependency (#526) * Add 'created-by' metadata, and pass it as option to logging library (#508) * Revert &quot;oslogin: Correctly handle newlines at the end of modified files (#520)&quot; (#523) * Re-enable disabled services if the core plugin was enabled (#522) * Enable guest services on package upgrade (#519) * oslogin: Correctly handle newlines at the end of modified files (#520) * Fix core plugin path (#518) * Fix package build issues (#517) * Fix dependencies ran go mod tidy -v (#515) * Fix debian build path (#514) * Bundle compat metadata script runner binary in package (#513) * Bump golang.org/x/net from 0.27.0 to 0.36.0 (#512) * Update startup/shutdown services to launch compat manager (#503) * Bundle new gce metadata script runner binary in agent package (#502) * Revert &quot;Revert bundling new binaries in the package (#509)&quot; (#511) - from version 20250418.00 * Re-enable disabled services if the core plugin was enabled (#521) - from version 20250414.00 * Add AuthorizedKeysCompat to windows packaging (#530) * Remove error messages from gce_workload_cert_refresh and metadata script runner (#527) * Update guest-logging-go dependency (#526) * Add 'created-by' metadata, and pass it as option to logging library (#508) * Revert &quot;oslogin: Correctly handle newlines at the end of modified files (#520)&quot; (#523) * Re-enable disabled services if the core plugin was enabled (#522) * Enable guest services on package upgrade (#519) * oslogin: Correctly handle newlines at the end of modified files (#520) * Fix core plugin path (#518) * Fix package build issues (#517) * Fix dependencies ran go mod tidy -v (#515) * Fix debian build path (#514) * Bundle compat metadata script runner binary in package (#513) * Bump golang.org/x/net from 0.27.0 to 0.36.0 (#512) * Update startup/shutdown services to launch compat manager (#503) * Bundle new gce metadata script runner binary in agent package (#502) * Revert &quot;Revert bundling new binaries in the package (#509)&quot; (#511) Package augeas was updated: - Add patch, fix for bsc#1239909 / CVE-2025-2588: * CVE-2025-2588.patch Package systemd was updated: - Apply coredump sysctl settings on systemd package updates/removals.- Add 6007-coredump-use-d-in-kernel-core-pattern.patch (bsc#1243935 CVE-2025-4598) - Add the following patches (bsc#1241079 bsc#1241586) 6004-core-rename-queued_message-pending_reload_message.patch 6005-core-when-we-can-t-send-the-pending-reload-message-s.patch 6006-core-make-sure-we-don-t-throttle-change-signal-gener.patch- - Import commit 866467ea64074193d226d09a3779c1ff0bec63b0 2aee6d7daf basic/hashmap: add cleanup of memory pools (#7164) 908ac43c61 core: add valgrind helper for daemon-reexec 5357cabb02 sd-bus: fix a memory leak in message_new_reply() (#7636) db07d03e46 sd-bus: unify three code-paths which free struct bus_container 732f02acb0 bus-message: use structured initialization to avoid use of unitialized memory - Add 6002-sd-bus-add-APIs-to-query-the-current-read-and-write-.patch and 6003-core-don-t-process-dbus-unit-and-job-queue-when-ther.patch (bsc#1231211 bsc#1231211) - Don't try to restart the udev socket units anymore (bsc#1228809) There's currently no way to restart a socket activable service and its socket units &quot;atomically&quot; and safely. Package vim was updated: - Fix bsc#1228776 / CVE-2024-41965.- Fix bsc#1239602 / CVE-2025-29768. - Refresh patch: vim-7.3-sh_is_bash.patch - Update to 9.1.1406: 9.1.1406: crash when importing invalid tuple 9.1.1405: tests: no test for mapping with special keys in session file 9.1.1404: wrong link to Chapter 2 in new-tutor 9.1.1403: expansion of 'tabpanelopt' value adds wrong values 9.1.1402: multi-byte mappings not properly stored in session file 9.1.1401: list not materialized in prop_list() 9.1.1400: [security]: use-after-free when evaluating tuple fails 9.1.1399: tests: test_codestyle fails for auto-generated files 9.1.1398: completion: trunc does not follow Pmenu highlighting attributes 9.1.1397: tabpanel not correctly updated on :tabonly 9.1.1396: 'errorformat' is a global option 9.1.1395: search_stat not reset when pattern differs in case 9.1.1394: tabpanel not correctly redrawn on tabonly 9.1.1393: missing test for switching buffers and reusing curbuf 9.1.1392: missing patch number 9.1.1391: Vim does not have a vertical tabpanel 9.1.1390: style: more wrong indentation 9.1.1389: completion: still some issue when 'isexpand' contains a space 9.1.1388: Scrolling one line too far with 'nosmoothscroll' page scrolling 9.1.1387: memory leak when buflist_new() fails to reuse curbuf 9.1.1386: MS-Windows: some minor problems building on AARCH64 9.1.1385: inefficient loop for 'nosmoothscroll' scrolling 9.1.1384: still some problem with the new tutors filetype plugin 9.1.1383: completion: 'isexpand' option does not handle space char correct 9.1.1382: if_ruby: unused compiler warnings from ruby internals 9.1.1381: completion: cannot return to original text 9.1.1380: 'eventignorewin' only checked for current buffer 9.1.1379: MS-Windows: error when running evim when space in path 9.1.1378: sign without text overwrites number option 9.1.1377: patch v9.1.1370 causes some GTK warning messages 9.1.1376: quickfix dummy buffer may remain as dummy buffer 9.1.1375: [security]: possible heap UAF with quickfix dummy buffer 9.1.1374: completion: 'smartcase' not respected when filtering matches 9.1.1373: 'completeopt' checking logic can be simplified 9.1.1372: style: braces issues in various files 9.1.1371: style: indentation and brace issues in insexpand.c 9.1.1370: CI Tests favor GTK2 over GTK3 9.1.1369: configure still using autoconf 2.71 9.1.1368: GTK3 and GTK4 will drop numeric cursor support. 9.1.1367: too many strlen() calls in gui.c 9.1.1366: v9.1.1364 unintentionally changed sign.c and sound.c 9.1.1365: MS-Windows: compile warnings and too many strlen() calls 9.1.1364: style: more indentation issues 9.1.1363: style: inconsistent indentation in various files 9.1.1362: Vim9: type ignored when adding tuple to instance list var 9.1.1361: [security]: possible use-after-free when closing a buffer 9.1.1360: filetype: GNU Radio companion files are not recognized 9.1.1359: filetype: GNU Radio config files are not recognized 9.1.1358: if_lua: compile warnings with gcc15 9.1.1357: Vim incorrectly escapes tags with &quot;[&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' &quot;preinsert&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 &quot;kind&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 &quot;:&quot; 9.1.1285: Vim9: no error message for missing method after &quot;super.&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&lt;type&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&lt;object&lt;any&gt;&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' &quot;inline:&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' &quot;eol&quot; doesn't affect &quot;gM&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: &quot;shellcmdline&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() &quot;camelcase&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: &quot;above&quot; virtual text breaks cursorlineopt=number 9.1.1182: No cmdline completion for 'completefuzzycollect' 9.1.1181: Unnecessary STRLEN() calls in insexpand.c 9.1.1180: short-description 9.1.1179: too many strlen() calls in misc2.c 9.1.1178: not possible to generate completion candidates using fuzzy matching 9.1.1177: filetype: tera files not detected Package pciutils was updated: - Apply &quot;fix-lack-of-exposure-of-pci_init-for-libpci_3.2.patch&quot; to fix the biosdevname utility, which was broken by an update to pcituils 3.5.x because the newer version forgot to export pci_init() for library version LIBPCI_3.2. [bsc#1241994] Package screen was updated: - also use tty fd passing after a suspend (MSG_CONT) new patch: sendfdcont.diff - do not chmod the tty for multiattach, rely on tty fd passing instead [bsc#1242269] [CVE-2025-46802] new patch: nottychmod.diff Package freetype2 was updated: - Added patch: * CVE-2025-23022.patch + fixes bsc#1235670, CVE-2025-23022: signed integer overflow in cf2_doFlex in cff/cf2intrp.c + also fixes an overflow in cf2_hintmap_insertHint in src/cff/cf2hints.c + it is a backport of upstream commits e66d7300 and 3802ca8b Package kernel-default was updated: - x86/bugs: Fix BHI retpoline check (git-fixes).- commit 67aed4a - x86/bugs: Fix BHI handling of RRSBA (git-fixes). - Refresh patches.suse/x86-bhi-do-not-set-BHI_DIS_S-in-32-bit-mode.patch. - commit dab1e97 - x86/bugs: Cache the value of MSR_IA32_ARCH_CAPABILITIES (git-fixes). - commit 01a0a7a - x86/bugs: Fix return type of spectre_bhi_state() (git-fixes). - commit 198eac5 - btrfs: don't BUG_ON() when 0 reference count at btrfs_lookup_extent_info() (bsc#1230786 CVE-2024-46751). - commit ed57497 - Refresh patches.suse/x86-bhi-Add-BHI-mitigation-knob.patch. Fix a couple of issues with this backport, namely: 1. Wrong upstream commit id used 2. Missing hunk dealing with RETPOLINE being enabled on RRSBA CPUs, thus obviating the need to have BHI mitigation explicitly enabled. - commit daaf354 - Update patches.suse/0084-dm-ioctl-fix-misbehavior-if-list_versions-races-with-module-loading.patch (git-fixes CVE-2022-49771 bsc#1242686). - Update patches.suse/Bluetooth-L2CAP-Fix-use-after-free-caused-by-l2cap_r.patch (CVE-2022-3564 bsc#1206073 CVE-2022-49910 bsc#1242452). - Update patches.suse/Bluetooth-L2CAP-fix-use-after-free-in-l2cap_conn_del.patch (CVE-2025-21969 bsc#1240784 CVE-2022-49909 bsc#1242453). - Update patches.suse/Bluetooth-btsdio-fix-use-after-free-bug-in-btsdio_re.patch (CVE-2023-1989 bsc#1210336 CVE-2023-53145 bsc#1243047). - Update patches.suse/SUNRPC-Fix-a-server-shutdown-leak.patch (git-fixes CVE-2023-53131 bsc#1242377). - Update patches.suse/arm64-bpf-Add-BHB-mitigation-to-the-epilogue-for-cBP.patch (bsc#1242778 CVE-2025-37948 bsc#1243649). - Update patches.suse/arm64-bpf-Only-mitigate-cBPF-programs-loaded-by-unpr.patch (bsc#1242778 CVE-2025-37963 bsc#1243660). - Update patches.suse/bpf-sockmap-Fix-the-sk-sk_forward_alloc-warning-of-s.patch (bsc#1235485 CVE-2024-56633 CVE-2022-49877 bsc#1242483). - Update patches.suse/cifs-Fix-connections-leak-when-tlink-setup-failed.patch (bsc#1190317 CVE-2022-49822 bsc#1242544). - Update patches.suse/dm-stats-check-for-and-propagate-alloc_percpu-failur-d3aa.patch (git-fixes CVE-2023-53044 bsc#1242759). - Update patches.suse/ext4-fix-WARNING-in-ext4_update_inline_data.patch (bsc#1213012 CVE-2023-53100 bsc#1242790). - Update patches.suse/ext4-fix-warning-in-ext4_da_release_space.patch (bsc#1206887 CVE-2022-49880 bsc#1242734). - Update patches.suse/ext4-zero-i_disksize-when-initializing-the-bootloade.patch (bsc#1213013 CVE-2023-53101 bsc#1242791). - Update patches.suse/ftrace-Fix-invalid-address-access-in-lookup_rec-when-index-is-0.patch (git-fixes CVE-2023-53075 bsc#1242218). - Update patches.suse/ftrace-Fix-use-after-free-for-dynamic-ftrace_ops.patch (git-fixes CVE-2022-49892 bsc#1242449). - Update patches.suse/gfs2-Check-sb_bsize_shift-after-reading-superblock.patch (git-fixes CVE-2022-49769 bsc#1242440). - Update patches.suse/ibmvnic-Free-rwi-on-reset-success.patch (bsc#1184350 ltc#191533 git-fixes CVE-2022-49906 bsc#1242464). - Update patches.suse/igb-revert-rtnl_lock-that-causes-deadlock.patch (git-fixes CVE-2023-53060 bsc#1242241). - Update patches.suse/ila-do-not-generate-empty-messages-in-ila_xlat_nl_cm.patch (git-fixes CVE-2023-53141 bsc#1242362). - Update patches.suse/mISDN-fix-misuse-of-put_device-in-mISDN_register_dev.patch (CVE-2022-49915 bsc#1242409 CVE-2022-49818 bsc#1242527). - Update patches.suse/net-iucv-Fix-size-of-interrupt-data.patch (bsc#1211466 CVE-2023-53108 bsc#1242422). - Update patches.suse/net-tunnels-annotate-lockless-accesses-to-dev-needed_headroom.patch (CVE-2024-26804 bsc#1222629 CVE-2023-53109 bsc#1242405). - Update patches.suse/net-usb-lan78xx-Limit-packet-length-to-skb-len.patch (git-fixes CVE-2023-53068 bsc#1242239). - Update patches.suse/net-usb-smsc75xx-Limit-packet-length-to-skb-len.patch (git-fixes CVE-2023-53125 bsc#1242285). - Update patches.suse/net-usb-smsc95xx-Limit-packet-length-to-skb-len.patch (git-fixes CVE-2023-53062 bsc#1242228). - Update patches.suse/net_sched-keep-alloc_hash-updated-after-hash-allocat.patch (git-fixes CVE-2020-36791 bsc#1242835). - Update patches.suse/nfc-pn533-initialize-struct-pn533_out_arg-properly.patch (CVE-2022-48875 bsc#1229516 CVE-2023-53119 bsc#1242370). - Update patches.suse/nfc-st-nci-Fix-use-after-free-bug-in-ndlc_remove-due.patch (git-fixes bsc#1210337 CVE-2023-1990 CVE-2023-53106 bsc#1242215). - Update patches.suse/nfs4-Fix-kmemleak-when-allocate-slot-failed.patch (git-fixes CVE-2022-49927 bsc#1242416). - Update patches.suse/nfsd-decrease-sc_count-directly-if-fail-to-queue-dl_.patch (CVE-2025-22025 bsc#1241361 CVE-2025-37871 bsc#1242949). - Update patches.suse/ring-buffer-Check-for-NULL-cpu_buffer-in-ring_buffer_wake_waiters.patch (git-fixes CVE-2022-49889 bsc#1242455). - Update patches.suse/sch_htb-make-htb_deactivate-idempotent.patch (CVE-2025-37798 bsc#1242414 CVE-2025-37953 bsc#1243543). - Update patches.suse/sch_htb-make-htb_qlen_notify-idempotent.patch (CVE-2025-37798 bsc#1242414 CVE-2025-37932 bsc#1243627). - Update patches.suse/scsi-core-Remove-the-proc-scsi-proc_name-directory-earlier.patch (git-fixes CVE-2023-53140 bsc#1242372). - Update patches.suse/scsi-mpt3sas-Fix-NULL-pointer-access-in-mpt3sas_transport_port_add.patch (git-fixes CVE-2023-53124 bsc#1242165). - Update patches.suse/scsi-qla2xxx-Perform-lockless-command-completion-in-.patch (git-fixes CVE-2023-53041 bsc#1242747). - Update patches.suse/scsi-qla2xxx-Synchronize-the-IOCB-count-to-be-in-ord.patch (bsc#1209292 bsc#1209684 bsc#1209556 CVE-2023-53056 bsc#1242219). - Update patches.suse/scsi-scsi_dh_alua-Fix-memleak-for-qdata-in-alua_activate.patch (git-fixes CVE-2023-53078 bsc#1242231). - Update patches.suse/scsi-zfcp-Fix-double-free-of-FSF-request-when-qdio-send-fails (git-fixes CVE-2022-49789 bsc#1242366). - Update patches.suse/tcp-tcp_make_synack-can-be-called-from-process-conte.patch (git-fixes CVE-2023-53121 bsc#1242225). - Update patches.suse/udf-Fix-a-slab-out-of-bounds-write-bug-in-udf_find_e.patch (bsc#1206649 CVE-2022-49846 bsc#1242716). - commit 69b5e67 - drm/scheduler: fix fence ref counting (bsc#1242691 CVE-2022-49829) - commit 14778ea - net: sched: extract qstats update code into functions (CVE-2024-26740 bsc#1222563). - refresh patches.suse/net-sched-act_mirred-don-t-override-retval-if-we-alr.patch - commit e226feb - net/sched: act_mirred: use the backlog for mirred ingress (CVE-2024-26740 bsc#1222563). - refresh patches.suse/net-sched-act_mirred-don-t-override-retval-if-we-alr.patch - act_mirred: use the backlog for nested calls to mirred ingress (CVE-2024-26740 bsc#1222563). - net/sched: act_mirred: refactor the handle of xmit (CVE-2024-26740 bsc#1222563). - cleanup patches.suse/net-smc-Transitional-solution-for-clcsock-race-issue.patch drop net/sched/act_mirred.c part which was a combination of unrelated commits which are going to be backported separately now - refresh patches.suse/net-sched-act_mirred-don-t-override-retval-if-we-alr.patch - net: sched: don't expose action qstats to skb_tc_reinsert() (CVE-2024-26740 bsc#1222563). - net: sched: refactor reinsert action (CVE-2024-26740 bsc#1222563). - commit 7ca05e8 - can: peak_usb: fix use after free bugs (bsc#1241407 CVE-2021-47670). - blacklist.conf: blacklisted in error - commit 3cc9a48 - xenbus: Use kref to track req lifetime (bsc#1243541 CVE-2025-37949). - commit e59a814 - 9p/net: fix improper handling of bogus negative read/write replies (bsc#1243077 CVE-2025-37879). - commit fe1bf4b - usb: gadget: u_audio: don't let userspace block driver unbind (CVE-2023-53045 bsc#1242756) - commit 96aa745 - tipc: fix the msg-&gt;req tlv len check in tipc_nl_compat_name_table_dump_header (CVE-2022-49862 bsc#1242755) - commit d64fec6 - net: macvlan: fix memory leaks of macvlan_common_newlink (CVE-2022-49853 bsc#1242688) - commit d85ed83 - dmaengine: mv_xor_v2: Fix a resource leak in mv_xor_v2_remove() (CVE-2022-49861 bsc#1242580) - commit f8dabfc - ipv6: addrlabel: fix infoleak when sending struct ifaddrlblmsg to network (CVE-2022-49865 bsc#1242570) - commit 8923317 - net_sched: sch_sfq: move the limit validation (CVE-2025-37752 bsc#1242504) - commit 3268e2e - net_sched: sch_sfq: use a temporary work area for validating configuration (bsc#1232504) - commit e350897 - net: ena: Fix error handling in ena_init() (CVE-2022-49813 bsc#1242497) - commit 55f4ea4 - net: mdio: fix undefined behavior in bit shift for __mdiobus_register (CVE-2022-49907 bsc#1242450) - commit 35b4747 - i40e: Fix kernel crash during reboot when adapter is in recovery mode (CVE-2023-53114 bsc#1242398) - commit 9232bee - ALSA: hda: fix potential memleak in 'add_widget_node' (CVE-2022-49835 bsc#1242385) - commit b245eca - nfc: nfcmrvl: Fix potential memory leak in nfcmrvl_i2c_nci_send() (CVE-2022-49922 bsc#1242378) - commit ec5842a - ALSA: usb-audio: Drop snd_BUG_ON() from snd_usbmidi_output_open() (CVE-2022-49772 bsc#1242147) - commit 05dc09a - Remove debug flavor (bsc#1243919). This is only released in Leap, and we don't have Leap 42 anymore. - commit c8f417b - HID: hyperv: fix possible memory leak in mousevsc_probe() (CVE-2022-49874 bsc#1242478). - commit 4edbe8d - Refresh patches.suse/netfilter-nf_tables-Reject-tables-of-unsupported-fam.patch. Adjusted the backported patch as it caused a regression. bsc#1218752 - commit 9c294ed - ipv6: Fix signed integer overflow in __ip6_append_data (CVE-2022-49728 bsc#1239111). - commit e5a4bfa - devm-helpers: Add resource managed version of work init (bsc#1242745) - commit af41987 - pinctrl: devicetree: fix refcount leak in pinctrl_dt_to_map() (bsc#1242154) - commit 28b2ba4 - nfc: fdp: add null check of devm_kmalloc_array in fdp_nci_i2c_read_device_properties (CVE-2023-53139 bsc#1242361) - commit 2977dda - misc/vmw_vmci: fix an infoleak in vmci_host_do_receive_datagram() (CVE-2022-49788 bsc#1242353) - commit 9e63e91 - mmc: sdhci-pci: Fix possible memory leak caused by missing pci_dev_put() (CVE-2022-49787 bsc#1242352) - commit e6bd23b - qed/qed_sriov: guard against NULL derefs from qed_iov_get_vf_info (CVE-2023-53066 bsc#1242227) - commit 3926868 - pinctrl: devicetree: fix null pointer dereferencing in pinctrl_dt_to_map (CVE-2022-49832 bsc#1242154) - commit 18c2436 - HID: intel-ish-hid: ipc: Fix dev_err usage with uninitialized dev-&gt;devc (bsc#1242745) - commit eb37482 - HID: intel-ish-hid: ipc: Fix potential use-after-free in work function (CVE-2023-53039 bsc#1242745) - commit 09f159d - workqueue: Add resource managed version of delayed work init (bsc#1242745) - commit 26c1fec - sunrpc: fix one UAF issue caused by sunrpc kernel tcp socket (CVE-2024-53168 bsc#1234887). - commit 14cbc36 - ACPI: CPPC: Avoid out of bounds access when parsing _CPC data (CVE-2022-49145 bsc#1238162). - commit 470a12c - mtd: phram: Add the kernel lock down check (bsc#1232649). - commit 9010162 - net/sched: initialize noop_qdisc owner (git-fixes). - commit 2dfc668 - nfc: nxp-nci: Fix potential memory leak in nxp_nci_send() (CVE-2022-49923 bsc#1242394) - commit 90c2109 - NFC: nxp-nci: remove unnecessary labels (bsc#1242394) - commit 211515d - isofs: Prevent the use of too small fid (CVE-2025-37780 bsc#1242786) - commit 66b8f1c - wifi: mac80211: Purge vif txq in ieee80211_do_stop() (CVE-2025-37794 bsc#1242566) - commit be7520f - wifi: at76c50x: fix use after free access in at76_disconnect (CVE-2025-37796 bsc#1242727) - commit 926c6d8 - ext4: fix off-by-one error in do_split (CVE-2025-23150 bsc#1242513) - commit 63c211a - net: phy: leds: fix memory leak (CVE-2025-37989 bsc#1243511). - commit 80b696b - kabi: hide owner from struct Qdisc (CVE-2024-27010, bsc#1223720). - net/sched: Fix mirred deadlock on device recursion (CVE-2024-27010, bsc#1223720). - commit 2646651 - Refresh patches.suse/net-mlx5-Fix-steering-rules-cleanup.patch. - commit cad4104 - nfc: nfcmrvl: Fix memory leak in nfcmrvl_play_deferred (CVE-2022-49729 bsc#1239060) - commit e4a37ce - net_sched: skbprio: Remove overly strict queue assertions (CVE-2025-38637 bsc#1241657). - commit a3f71a8 - usbnet:fix NPE during rx_complete (CVE-2025-22050 bsc#1241441) - commit b29f445 - thermal: int340x: Add NULL check for adev (CVE-2025-23136 bsc#1241357) - commit aca813f - btrfs: do not clean up repair bio if submit fails (CVE-2022-49168 bsc#1238109). - commit eb3f122 - ALSA: hda/via: Avoid potential array out-of-bound in add_secret_dac_path() (CVE-2023-52988 bsc#1240293) - commit 47e6e52 - x86/i8259: Mark legacy PIC interrupts with IRQ_LEVEL (CVE-2023-52993 bsc#1240297) - commit b8c925f - firewire: fix memory leak for payload of request subaction to IEC 61883-1 FCP region (CVE-2023-52989 bsc#1240266) - commit 4f68c93 - w1: fix WARNING after calling w1_process() (CVE-2022-49751 bsc#1240254) - commit 9507421 - nfc: fdp: Fix potential memory leak in fdp_nci_send() (CVE-2022-49924 bsc#1242426) - commit 1ff0fc5 - PM / devfreq: rk3399_dmc: Disable edev on remove() (CVE-2022-49460 bsc#1238892) - commit 556bc32 - dmaengine: ti: Fix refcount leak in ti_dra7_xbar_route_allocate (CVE-2022-49652 bsc#1238871) - commit d4f6d8a - ath9k_htc: fix potential out of bounds access with invalid rxstatus-&gt;rs_keyix (CVE-2022-49503 bsc#1238868) - commit b38fbf8 - irqchip/gic-v3: Fix refcount leak in gic_populate_ppi_partitions (CVE-2022-49715 bsc#1238818) - commit c85152c - irqchip: gic-v3: Use of_cpu_node_to_id helper (bsc#1238818) - commit 955125a - net/mlx5: Fix steering rules cleanup (CVE-2023-53079 bsc#1242765). - commit 4ab30d6 - ata: libata-transport: fix double ata_host_put() in ata_tport_add() (CVE-2022-49826 bsc#1242549). - commit a0074f3 - net_sched: hfsc: Fix a potential UAF in hfsc_dequeue() too (CVE-2025-37823 bsc#1242924). - commit 9b2e245 - team: better TEAM_OPTION_TYPE_STRING validation (CVE-2025-21787 bsc#1238774) - commit c0334f8 - btrfs: fix inode list leak during backref walking at resolve_indirect_refs() (CVE-2022-49914 bsc#1242427). - commit f13d5c5 - thermal: core: prevent potential string overflow (CVE-2023-52868 bsc#1225044) - commit 45a76bf - bpf, test_run: Fix alignment problem in bpf_prog_test_run_skb() (CVE-2022-49840 bsc#1242447). - commit 19b730c - nfsd: decrease sc_count directly if fail to queue dl_recall (CVE-2025-22025 bsc#1241361). - commit 5566843 - nfsd: put dl_stid if fail to queue dl_recall (CVE-2025-22025 bsc#1241361). - commit 36e54e4 - pfifo_tail_enqueue: Drop new packet when sch-&gt;limit == 0 (CVE-2025-21702 bsc#1237312) - commit 2cd0611 - usb: cdc-acm: Check control transfer buffer size before access (CVE-2025-21704 bnc#1237571) - commit 25db018 - ptp: Ensure info-&gt;enable callback is always set (CVE-2025-21814 bsc#1238473) - commit 04ecd88 - net/niu: Niu requires MSIX ENTRY_DATA fields touch before entry reads (CVE-2025-37833 bsc#1242868). - PCI/MSI: Add an option to write MSIX ENTRY_DATA before any reads (CVE-2025-37833 bsc#1242868). - commit 07a4c2c - drm/amdgpu: handle amdgpu_cgs_create_device() errors in amd_powerplay_create() (CVE-2025-37852 bsc#1243074). - commit 85e74d7 - net: mvpp2: parser fix QinQ (CVE-2025-22060 bsc#1241526). - Refresh patches.suse/net-mvpp2-Prevent-parser-TCAM-memory-corruption.patch. - commit 39cd74b - nfsd: fix nfs4_openowner leak when concurrent nfsd4_open occur (bsc#1235632 CVE-2024-56779). - commit 6133296 - x86/smpboot: Remove unused phys_id variable (git-commit). This fixes a build warning. - commit ceba46a - kernel/resource: fix kfree() of bootmem memory again (CVE-2022-49190 bsc#1238130). - commit 48c0013 - drm: msm: fix possible memory leak in mdp5_crtc_cursor_set() (CVE-2022-49467 bsc#1238815) - commit 9b240ea - drm/i915/selftests: fix subtraction overflow bug (CVE-2022-49635 bsc#1238806) - commit c5c18ff - net: ppp: Add bound checking for skb data on ppp_sync_txmung (CVE-2025-37749 bsc#1242859) - commit a8fe412 - netlabel: Fix NULL pointer exception caused by CALIPSO on IPv4 sockets (CVE-2025-22063 bsc#1241351) - commit 69b9c55 - tcp: cdg: allow tcp_cdg_release() to be called multiple times (CVE-2022-49775 bsc#1242245) - commit 462783c - PCI: vmd: Make vmd_dev::cfg_lock a raw_spinlock_t type (CVE-2025-23161 bsc#1242792). - commit b40664f - ocfs2: fix the issue with discontiguous allocation in the global_bitmap (git-fixes). - commit e15ed3a - nfsd: fix race between laundromat and free_stateid() (CVE-2024-50106 bsc#1232882). - commit a790b42 - dmaengine: zynqmp_dma: In struct zynqmp_dma_chan fix desc_size data type (bsc#1238394 CVE-2022-49320). - commit 436663c - btrfs: fix inode list leak during backref walking at find_parent_nodes() (bsc#1242470 CVE-2022-49913). - commit c05de9e - btrfs: replace BUG_ON() with error handling at update_ref_for_cow() (bsc#1230794 CVE-2024-46752). - commit acac3f6 - Btrfs: don't iterate mod seq list when putting a tree mod seq (bsc#1242472 CVE-2022-49898). - btrfs: always pin deleted leaves when there are active tree mod log users (bsc#1242472 CVE-2022-49898). - btrfs: fix tree mod log mishandling of reallocated nodes (bsc#1242472 CVE-2022-49898). - btrfs: use a bit to track the existence of tree mod log users (bsc#1242472 CVE-2022-49898). - btrfs: use the new bit BTRFS_FS_TREE_MOD_LOG_USERS at btrfs_free_tree_block() (bsc#1242472 CVE-2022-49898). - Refresh patches.suse/0002-btrfs-Remove-fsid-metadata_fsid-fields-from-btrfs_in.patch. - commit dacb815 - memcg_write_event_control(): fix a user-triggerable oops (CVE-2024-45021 bsc#1230434). - commit 4e6c9d7 - IB/hfi1: Correctly move list in sc_disable() (CVE-2022-49931 bsc#1242382) - commit 581a698 - RDMA/core: Fix null-ptr-deref in ib_core_cleanup() (CVE-2022-49925 bsc#1242371) - commit 629991b - rtl818x: Prevent using not initialized queues (CVE-2022-49326 bsc#1238646) - commit 2e4f859 - drm/rockchip: vop: fix possible null-ptr-deref in vop_bind() (CVE-2022-49491 bsc#1238539) - commit cacfaf7 - driver core: fix deadlock in __device_attach (CVE-2022-49371 bsc#1238546) - commit e1fc85e - Refresh patches.suse/tpm-tis-Double-the-timeout-B-to-4s.patch. - commit db263b9 - Update patches.suse/USB-usbfs-Don-t-WARN-about-excessively-large-memory-.patch (bsc#1222004 CVE-2021-47170 CVE-2021-20320). - commit 2ffa0a7 - Update patches.suse/sctp-fail-if-no-bound-addresses-can-be-used-for-a-gi.patch (bsc#1206677 CVE-2023-1074). - commit 2c70e65 - media: streamzap: fix race between device disconnection and urb callback (CVE-2025-22027 bsc#1241369). - commit 45f284f - ASoC: soc-utils: Remove __exit for snd_soc_util_exit() (CVE-2022-49842 bsc#1242484). - commit dfda6bc - ASoC: core: Fix use-after-free in snd_soc_exit() (CVE-2022-49842 bsc#1242484). - commit 89ba7b3 - btrfs: always report error in run_one_delayed_ref() (CVE-2022-49761 bsc#1240261) - commit e432f24 - netfilter: conntrack: clamp maximum hashtable size to INT_MAX (CVE-2025-21648 bsc#1236142) - commit 9316b29 - media: usb: go7007: s2250-board: fix leak in probe() (CVE-2022-49253 bsc#1238420) - commit db86595 - sfc: fix kernel panic when creating VF (CVE-2022-49625 bsc#1238411) - commit bcdf72a - arm64: insn: Fix two bugs in encoding 32-bit logical immediates (bsc#1242778). - commit 538ec8a - arm64: insn: Add encoder for bitwise operations using literals (bsc#1242778). - arm64: insn: Add N immediate encoding (bsc#1242778). - commit e6408da - sch_htb: make htb_deactivate() idempotent (CVE-2025-37798 bsc#1242414). - sch_qfq: make qfq_qlen_notify() idempotent (CVE-2025-37798 bsc#1242414). - sch_hfsc: make hfsc_qlen_notify() idempotent (CVE-2025-37798 bsc#1242414). - sch_drr: make drr_qlen_notify() idempotent (CVE-2025-37798 bsc#1242414). - sch_htb: make htb_qlen_notify() idempotent (CVE-2025-37798 bsc#1242414). - commit 85d67da - bonding: Fix memory leak when changing bond type to Ethernet (CVE-2023-53103 bsc#1242408). - commit 03cee1f - bonding: restore bond's IFF_SLAVE flag if a non-eth dev enslave fails (CVE-2023-53103 bsc#1242408). - bonding: restore IFF_MASTER/SLAVE flags on bond enslave ether type change (CVE-2023-53103 bsc#1242408). - commit c76a60e - Revert &quot;kABI workaround for changeing the variable length type to size_t&quot; Will evaluate again the CVE and resend the patch if needed This reverts commit 467381126c46febb6e9adeba40f4439ab1b7f3cd. - commit 859f819 - Revert &quot;ipv6: Fix signed integer overflow in __ip6_append_data&quot; Will evaluate again the CVE and resend the patch if needed This reverts commit 0c4609a89f1351bc34d1fdf73c438d3665a48988. - commit 9b99659 - Fix cpufeatures kABI Refresh patches.kabi/cpufeatures-kabi-fix.patch. - commit aeb0991 - Refresh patches.suse/0022-arm64-Use-the-clearbhb-instruction-in-mitigations.patch. Bring in AARCH64_INSN_HINT_CLEARBHB, which was present in the mainline patch. - commit 7ece652 - Bring back 'enum bhb_mitigation_bits' and system_bhb_mitigations (bsc#1242778) - Refresh patches.suse/0019-arm64-Mitigate-spectre-style-branch-history-side-cha.patch. - Refresh patches.suse/0022-arm64-Use-the-clearbhb-instruction-in-mitigations.patch. - commit a6c8f92 - ath9k_htc: fix uninit value bugs (CVE-2022-49235 bsc#1238333) - commit d0592f5 - drm/tegra: Fix reference leak in tegra_dsi_ganged_probe (CVE-2022-49216 bsc#1238338) Refresh patches.suse/0001-drm-tegra-dsi-Add-missing-check-for-of_find_device_b.patch. - commit dff7d50 - mtd: rawnand: atmel: fix refcount issue in atmel_nand_controller_init (CVE-2022-49212 bsc#1238331) - commit fd64ee9 - phy: qcom-qmp: fix reset-controller leak on probe errors (CVE-2022-49396 bsc#1238289) - commit 64c16d6 - arm64: bpf: Add BHB mitigation to the epilogue for cBPF programs (bsc#1242778). - commit d71d27e - arm64: proton-pack: Add new CPUs 'k' values for branch mitigation (bsc#1242778). - arm64: bpf: Only mitigate cBPF programs loaded by unprivileged users (bsc#1242778). - arm64: proton-pack: Expose whether the branchy loop k value (bsc#1242778). - arm64: proton-pack: Expose whether the platform is mitigated by firmware (bsc#1242778). - arm64: insn: Add support for encoding DSB (bsc#1242778). - commit ebb0869 - Refresh patches.suse/x86-bhi-do-not-set-BHI_DIS_S-in-32-bit-mode.patch. - Refresh patches.suse/x86-bpf-add-IBHF-call-at-end-of-classic-BPF.patch. - Refresh patches.suse/x86-bpf-call-branch-history-clearing-sequence-on-exit.patch. Update the patch-mainline header, these patches are expected to be found upstream at a later date. - commit 8ba543d - net: openvswitch: fix nested key length validation in the set() action (CVE-2025-37789 bsc#1242762). - commit a168326 - tty: serial: fsl_lpuart: fix race on RX DMA shutdown (CVE-2023-53094 bsc#1242288). - commit 053969f - Update patches.suse/bpf-Verifer-adjust_scalar_min_max_vals-to-always-call-update_reg_bounds.patch (bsc#1194227 CVE-2021-4159). - commit 33266c3 - Update patches.suse/s390-bpf-Wrap-JIT-macro-parameter-usages-in-parentheses.patch (bsc#1190601 CVE-2021-20320). - Update patches.suse/s390-bpf-fix-64-bit-subtraction-of-the-0x80000000-constant.patch (bsc#1190601 CVE-2021-20320). - Update patches.suse/s390-bpf-fix-branch-shortening-during-codegen-pass.patch (bsc#1190601 CVE-2021-20320). - Update patches.suse/s390-bpf-fix-optimizing-out-zero-extensions.patch (bsc#1190601 CVE-2021-20320). - Update patches.suse/s390-bpf-implement-jitting-of-BPF_ALU-BPF_ARSH-BPF_.patch (bsc#1190601 CVE-2021-20320). - commit 3b96b15 - scsi: iscsi_tcp: Fix UAF during logout when accessing the shost ipaddress (CVE-2023-52975 bsc#1240322). - scsi: iscsi: Move pool freeing (CVE-2023-52975 bsc#1240322). - commit d8d45ff - netfilter: socket: Lookup orig tuple for IPv6 SNAT (CVE-2025-22021 bsc#1241282). - commit 3b93136 - xsk: Add missing overflow check in xdp_umem_reg (CVE-2023-53080 bsc#1242287). - commit 8b15409 - net_sched: hfsc: Fix a UAF vulnerability in class handling (CVE-2025-37797 bsc#1242417). - commit 66a1309 - codel: remove sch-&gt;q.qlen check before qdisc_tree_reduce_backlog() (CVE-2025-37798 bsc#1242414). - commit 7a9bb75 - hfs/hfsplus: fix slab-out-of-bounds in hfs_bnode_read_key (bsc#1242770 CVE-2025-37782). - commit 51b3882 - udp: Fix memory accounting leak (CVE-2025-22058 bsc#1241332). - commit 229f687 - fbdev: hyperv_fb: Simplify hvfb_putmem (git-fixes). - commit 67adb16 - Bluetooth: fix null ptr deref on hci_sync_conn_complete_evt (bsc#1238032 CVE-2022-49139). - commit b38b106 - net: stmmac: fix dma queue left shift overflow issue (CVE-2022-49592 bsc#1238311). - commit 1b0d1c7 - Bluetooth: fix dangling sco_conn and use-after-free in sco_sock_timeout (bsc#1238071 CVE-2022-49474). - commit 6360cef - x86/bhi: Do not set BHI_DIS_S in 32-bit mode (bsc#1242778). - x86/bpf: Add IBHF call at end of classic BPF (bsc#1242778). - x86/bpf: Call branch history clearing sequence on exit (bsc#1242778). - commit 59473c9 - fbdev: hyperv_fb: Allow graceful removal of framebuffer (git-fixes CVE-2025-21976 bsc#1241145). - Delete patches.suse/suse-hv-hyperv_fb-rmmod.patch, no longer needed. - commit a082a24 - net: gso: fix panic on frag_list with mixed head alloc types (CVE-2022-49872 bsc#1242594). - commit 3e759e0 - mISDN: fix possible memory leak in mISDN_dsp_element_register() (CVE-2022-49821 bsc#1242542). - commit 22495af - mISDN: fix misuse of put_device() in mISDN_register_device() (CVE-2022-49915 bsc#1242409). - commit 2af5c07 - mISDN: fix possible memory leak in mISDN_register_device() (CVE-2022-49915 bsc#1242409). - commit 1096349 - net: tun: call napi_schedule_prep() to ensure we own a napi (CVE-2022-49871 bsc#1242558). - net: tun: Fix memory leaks of napi_get_frags (CVE-2022-49871 bsc#1242558). - macvlan: enforce a consistent minimal mtu (CVE-2022-49776 bsc#1242248). - commit de7a2f0 - Update patches.suse/dm-crypt-add-cond_resched-to-dmcrypt_write-fb29.patch (git-fixes CVE-2023-53051 bsc#1242284). - commit a2c06ba - Regression in CVE-2024-56641 fix (CVE-2024-56641, bsc#1235526, bsc#1242319). - commit a257d42 - soc: rockchip: Fix refcount leak in rockchip_grf_init (CVE-2022-49382 bsc#1238306) - commit b778a78 - ALSA: firewire-lib: fix uninitialized flag for AV/C deferred transaction (CVE-2022-49248 bsc#1238284) - commit 340a548 - tty: fix deadlock caused by calling printk() under tty_port-&gt;lock (CVE-2022-49441 bsc#1238263) - commit 1148c0f - Refresh patches.suse/suse-hv-hyperv_fb-rmmod.patch. Fix the following warning: drivers/video/fbdev/hyperv_fb.c:1363:20: warning: 'hvfb_drv_exit' defined but not used - commit ce05eff - audit: Send netlink ACK before setting connection in auditd_set (bsc#1231450). - commit f8c00d6 - Update patches.suse/can-dev-can_get_echo_skb-prevent-call-to-kfree_skb-i.patch (git-fixes CVE-2020-36789 bsc#1241408). - Update patches.suse/can-dev-can_restart-fix-use-after-free-bug.patch (git-fixes CVE-2021-47668 bsc#1241404). - Update patches.suse/can-vxcan-vxcan_xmit-fix-use-after-free-bug.patch (git-fixes CVE-2021-47669 bsc#1241405). - Update patches.suse/fou-fix-initialization-of-grc.patch (CVE-2024-46763 bsc#1230764 CVE-2024-46865 bsc#1231103). - Update patches.suse/ndisc-use-RCU-protection-in-ndisc_alloc_skb.patch (bsc#1239994 CVE-2025-21764 bsc#1237885). - commit fcb2f6d - cifs: Fix integer overflow while processing actimeo mount option (git-fixes). - commit 0c62491 - cifs: Fix integer overflow while processing acdirmax mount option (CVE-2025-21963 bsc#1240717). - commit 6c82fff - net: annotate races around sk-&gt;sk_bound_dev_if (CVE-2022-49420 bsc#1238887). - commit e87db68 - cifs: Fix integer overflow while processing acregmax mount option (CVE-2025-21964 bsc#1240740). - commit 759fa98 - hyperv_fb: disable rmmod (bsc#1241145, CVE-2025-21976). - commit 001b30c - drm/msm/disp/dpu1: set vbif hw config to NULL to avoid use after memory free during pm runtime resume (CVE-2022-49489 bsc#1238244) - commit 70ef453 - drm/amd/display: Fix a NULL pointer dereference in amdgpu_dm_connector_add_common_modes() (CVE-2022-49232 bsc#1238139) - commit 233d2c0 - remoteproc: qcom_q6v5_mss: Fix some leaks in q6v5_alloc_memory_region (CVE-2022-49188 bsc#1238138) - commit 2da2636 - remoteproc: qcom_q6v5_mss: Extract mba/mpss from memory-region (bsc#1238138) - commit 2730746 - PM: core: keep irq flags in device_pm_check_callbacks() (CVE-2022-49175 bsc#1238099) - commit ab8e651 - pinctrl: renesas: core: Fix possible null-ptr-deref in sh_pfc_map_resources() (CVE-2022-49445 bsc#1238019) - commit 27189c5 - ibmvnic: Use kernel helpers for hex dumps (CVE-2025-22104 bsc#1241550) - commit bc8cac0 - kABI workaround for changeing the variable length type to size_t (CVE-2022-49728 bsc#1239111). - commit 4673811 - ipv6: Fix signed integer overflow in __ip6_append_data (CVE-2022-49728 bsc#1239111). - commit 0c4609a - igmp: Fix data-races around sysctl_igmp_llm_reports (CVE-2022-49590 bsc#1238844). - commit ffcf577 - ipv6: mcast: add RCU protection to mld_newpack() (CVE-2025-21758 bsc#1238737). - commit ca8335c - net: ipv6: fix dst ref loops in rpl, seg6 and ioam6 lwtunnels (CVE-2025-21768 bsc#1238714). - commit 4d13df3 - atm: Fix NULL pointer dereference (CVE-2025-22018 bsc#1241266) - commit bc9b2c6 - drivers: staging: rtl8192u: Fix deadlock in ieee80211_beacons_stop() (CVE-2022-49305 bsc#1238645) - commit f20b488 - Bluetooth: Fix use after free in hci_send_acl (bsc#1237984 CVE-2022-49111). - commit 3cd0c1c - net: mvpp2: Prevent parser TCAM memory corruption (CVE-2025-22060 bsc#1241526). - commit 37e999b - Revert &quot;exec: fix the racy usage of fs_struct-&gt;in_exec (CVE-2025-22029&quot; This reverts commit 14a10bfdc080f8fa12291efe393e7af680537978. This turned out to be not an issue. See https://bugzilla.suse.com/show_bug.cgi?id=1241378#c4 - commit 4a60e73 - net: ibmveth: make veth_pool_store stop hanging (CVE-2025-22053 bsc#1241373). - commit 4494ff2 - netfilter: IDLETIMER: Fix for possible ABBA deadlock (CVE-2024-54683 bsc#1235729). - commit 938d034 - exec: fix the racy usage of fs_struct-&gt;in_exec (CVE-2025-22029 bsc#1241378). - commit 14a10bf - bfq: Make sure bfqg for which we are queueing requests is online (bsc#1238307 CVE-2022-49411). - blacklist.conf: Remove commit from blacklist - commit 4daae62 - bfq: Track whether bfq_group is still online (bsc#1238307 CVE-2022-49411). - commit e167d48 - ext4: fix OOB read when checking dotdot dir (bsc#1241640 CVE-2025-37785). - commit 0093423 - filemap: Fix bounds checking in filemap_read() (bsc#1234209 CVE-2024-50272 bsc#1233461). - commit e0c4cb2 - fs: relax assertions on failure to encode file handles (bsc#1236086 CVE-2024-57924). - commit ee1cce6 - Update references in patches.suse/ext4-fixup-pages-without-buffers.patch (bsc#1205495 CVE-2022-49171 bsc#1238093). - commit 3a68ec8 - tpm: Change to kvalloc() in eventlog/acpi.c (CVE-2024-58005 bsc#1237873) - commit 055cc9d - nvme-tcp: fix potential memory corruption in nvme_tcp_recv_pdu() (bsc#1240714 CVE-2025-21927). - commit 1b9235e - bpf, selftests: Add verifier test case for imm=0,umin=0,umax=1 scalar (bsc#1238803 CVE-2022-49658). - commit 76015e8 - bpf: Fix insufficient bounds propagation from adjust_scalar_min_max_vals (bsc#1238803 CVE-2022-49658). - commit a84c655 - dlm: prevent NPD when writing a positive value to event_done (bsc#1241601 CVE-2025-23131). - commit d96b67e - PCI/ASPM: Fix link state exit during switch upstream function removal (CVE-2024-58093 bsc#1241347). - commit 323974a - RDMA/mlx5: Fix mlx5_poll_one() cur_qp update flow (CVE-2025-22086 bsc#1241458) - commit 9222451 - drm/amdgpu/cs: make commands with 0 chunks illegal behaviour (CVE-2022-49335 bsc#1238377) - commit 093b1d6 - drm/amd/amdgpu/amdgpu_cs: fix refcount leak of a dma_fence obj (CVE-2022-49137 bsc#1238155) - commit c883f61 - printk: Fix signed integer overflow when defining LOG_BUF_LEN_MAX (bsc#1237950 CVE-2024-58017 bsc#1239112). - commit 7c45b05 - fou: fix initialization of grc (CVE-2024-46763 bsc#1230764). - commit 34d05f5 - drop_monitor: fix incorrect initialization order (CVE-2025-21862 bsc#1239474). - net: openvswitch: fix leak of nested actions (CVE-2022-49086 bsc#1238037). - commit 907826c - fou: Fix null-ptr-deref in GRO (CVE-2024-46763 bsc#1230764). - commit 87825b6 - net: fix geneve_opt length integer overflow (CVE-2025-22055 bsc#1241371). - commit 7a515dd - hwpoison, memory_hotplug: lock folio before unmap hwpoisoned folio (CVE-2025-21931 bsc#1240709). - commit 4b52623 - skbuff: introduce skb_pull_data (bsc#1235038 CVE-2024-56590). - commit 4f3bce2 - rds: sysctl: rds_tcp_{rcv,snd}buf: avoid using current-&gt;nsproxy (CVE-2025-21635 bsc#1236111). - commit 30122f9 - Bluetooth: hci_core: Fix not checking skb length on hci_acldata_packet (bsc#1235038 CVE-2024-56590). - commit 2b46315 - partitions: mac: fix handling of bogus partition table (CVE-2025-21772 bsc#1238911). - scsi: lpfc: Resolve NULL ptr dereference after an ELS LOGO is aborted (CVE-2022-49730 bsc#1239070). - scsi: lpfc: Fix resource leak in lpfc_sli4_send_seq_to_ulp() (CVE-2022-49521 bsc#1238938). - scsi: lpfc: Fix call trace observed during I/O with CMF enabled (CVE-2022-49537 bsc#1238930). - scsi: lpfc: Protect memory leak for NPIV ports sending PLOGI_RJT (CVE-2022-49534 bsc#1238893). - scsi: lpfc: Fix null pointer dereference after failing to issue FLOGI and PLOGI (CVE-2022-49535 bsc#1238937). - commit 9071ce6 - scsi: lpfc: Fix SCSI I/O completion and abort handler deadlock (CVE-2022-49536 bsc#1238838). - Refresh patches.suse/scsi-lpfc-Validate-hdwq-pointers-before-dereferencin.patch. - commit 1f1a811 - block, bfq: don't move oom_bfqq (CVE-2022-49179 bsc#1238092). - commit 08606de - drivers/base/node.c: fix compaction sysfs file leak (CVE-2022-49442 bsc#1238243) - commit 769486d - dmaengine: Fix double increment of client_count in dma_chan_get() (CVE-2022-49753 bsc#1240250) - commit 8be64a3 - tcp: add accessors to read/set tp-&gt;snd_cwnd (CVE-2022-49325 bsc#1238398). - Refresh patches.suse/tcp-fix-tcp_mtup_probe_success-vs-wrong-snd_cwnd.patch. - commit 00d8ac0 - net: altera: Fix refcount leak in altera_tse_mdio_create (CVE-2022-49351 bsc#1237939). - commit 3aeeb63 - mac80211: fix potential double free on mesh join (CVE-2022-49290 bsc#1238156) - commit 1243bb0 - wifi: rtlwifi: fix memory leaks and invalid access at probe error path (CVE-2024-58063 bsc#1238984) - commit fac1ba9 - wifi: brcmfmac: Check the return value of of_property_read_string_index() (CVE-2025-21750 bsc#1238905) - commit f37f3e1 - wifi: brcmfmac: use strreplace() in brcmf_of_probe() (bsc#1238905) - commit af07444 - brcmfmac: of: remove redundant variable len (bsc#1238905) - commit 990953e - brcmfmac: of: Use devm_kstrdup for board_type &amp; check for errors (bsc#1238905) - commit d9e8c8a - net: nfc: Fix use-after-free in local_cleanup() (CVE-2023-53023 bsc#1240309) - commit f91c2a0 - i40e: Fix call trace in setup_tx_descriptors (CVE-2022-49725 bsc#1238016) - commit 4f6a558 - net: gso: fix ownership in __udp_gso_segment (CVE-2025-21926 bsc#1240712). - commit 112bb59 - wifi: cfg80211: regulatory: improve invalid hints checking (CVE-2025-21910 bsc#1240583). - commit 2ad169d - wifi: nl80211: reject cooked mode if it is set along with other flags (CVE-2025-21909 bsc#1240590). - commit b2acee6 - net: atm: fix use after free in lec_send() (CVE-2025-22004 bsc#1240835). - commit cc63f73 - drm/plane: Move range check for format_count earlier (CVE-2021-47659 bsc#1237839) - commit cc111ee - dm integrity: fix memory corruption when tag_size is less than digest size (CVE-2022-49044 bsc#1237840) - commit be90f4e - net/smc: Fix NULL pointer dereference in smc_pnet_find_ib() (CVE-2022-49060 bsc#1237845) - commit 867ee3a - drm/amdkfd: Check for potential null return of kmalloc_array() (CVE-2022-49055 bsc#1237868) - commit afbd83d - driver: base: fix UAF when driver_attach failed (CVE-2022-49385 bsc#1237951) - commit 3dcc3aa - drm/msm/mdp4: Fix refcount leak in mdp4_modeset_init_intf (CVE-2022-49693 bsc#1237954) - commit d40fafb - PM / devfreq: exynos-ppmu: Fix refcount leak in of_get_devfreq_events (CVE-2022-49668 bsc#1237957) - commit fff3251 - media: pvrusb2: fix array-index-out-of-bounds in pvr2_i2c_core_init (CVE-2022-49478 bsc#1238000) - commit 5c8c17f - media: cx25821: Fix the warning when removing the module (CVE-2022-49525 bsc#1238022) - commit 8b2ba54 - scsi: lpfc: Move cfg_log_verbose check before calling lpfc_dmp_dbg() (CVE-2022-49542 bsc#1238722). - commit 2fbb1a4 - scsi: pm8001: Fix tag leaks on error (CVE-2022-49121 bsc#1237926). - Refresh patches.suse/scsi-pm8001-Fix-memory-leak-in-pm8001_chip_fw_flash_.patch. - commit 1183fb2 - block: fix integer overflow in BLKSECDISCARD (CVE-2024-49994 bsc#1237757). - scsi: lpfc: Inhibit aborts if external loopback plug is inserted (CVE-2022-49504 bsc#1238835). - scsi: hisi_sas: Free irq vectors in order for v3 HW (CVE-2022-49118 bsc#1237979). - bfq: fix use-after-free in bfq_dispatch_request (CVE-2022-49176 bsc#1238097). - commit 61a23eb - Refresh patches.suse/net-usb-usbnet-restore-usb-d-name-exception-for-loca.patch. Patch has been accepted upstream. Moving to correct section. - commit 44e2f7a - drm/amd/display: Assign normalized_pix_clk when color depth = 14 (bsc#1240739 CVE-2025-21956) - commit 8258112 - regulator: check that dummy regulator has been probed before using it (CVE-2025-22008 bsc#1240942). - commit e222593 - drm/amd/display: Fix null check for pipe_ctx-&gt;plane_state in (bsc#1240701 CVE-2025-21941) - commit 4fd9018 - blk-throttle: Set BIO_THROTTLED when bio has been throttled (CVE-2022-49465 bsc#1238919). - commit 885f88f - usb: xhci: Fix NULL pointer dereference on certain command aborts (CVE-2024-57981 bsc#1237912) - commit a6014fc - media: uvcvideo: Fix double free in error path (CVE-2024-57980 bsc#1237911) - commit c75a886 - NFC: nci: Add bounds checking in nci_hci_create_pipe() (CVE-2025-21735 bsc#1238497) - commit 1703ca8 - drm/msm/gem: prevent integer overflow in msm_ioctl_gem_submit() (CVE-2024-52559 bsc#1238507) - commit 151c011 - Bluetooth: L2CAP: handle NULL sock pointer in l2cap_sock_alloc (CVE-2024-58009 bsc#1238760) - commit f77505b - KVM: x86: Reject Hyper-V's SEND_IPI hypercalls if local APIC isn't in-kernel (CVE-2025-21779 bsc#1238768) - commit c0bacb1 - netfilter: xtables: fix typo causing some targets not to load on IPv6 (CVE-2024-50038 bsc#1231910). - netfilter: xtables: avoid NFPROTO_UNSPEC where needed (CVE-2024-50038 bsc#1231910). - commit 758059b - RDMA/hns: Fix soft lockup during bt pages loop (CVE-2025-22010 bsc#1240943) - commit 4f43f30 - i2c: designware: use casting of u64 in clock multiplication to avoid overflow (CVE-2022-49749 bsc#1240243) - commit 8e8de37 - HID: appleir: Fix potential NULL dereference at raw event handle (CVE-2025-21948 bsc#1240703) - commit 00a5124 - scsi: qla1280: Fix kernel oops when debug level &gt; 2 (CVE-2025-21957 bsc#1240742) - commit bd23d83 - net: let net.core.dev_weight always be non-zero (CVE-2025-21806 bsc#1238746) - commit f158377 - net: Fix data-races around weight_p and dev_weight_[rt]x_bias (bsc#1238746) - commit f948447 - Bluetooth: L2CAP: Fix build errors in some archs (CVE-2025-21969 bsc#1240784). - commit 7b7dc2b - Bluetooth: L2CAP: fix use-after-free in l2cap_conn_del() (CVE-2025-21969 bsc#1240784). - Bluetooth: L2CAP: Fix l2cap_global_chan_by_psm regression (CVE-2025-21969 bsc#1240784). - commit 45ad638 - kABI workaround for l2cap_conn changes (CVE-2025-21969 bsc#1240784). - commit 7316449 - Bluetooth: L2CAP: Fix corrupted list in hci_chan_del (CVE-2025-21969 bsc#1240784). - Bluetooth: L2CAP: Fix use-after-free caused by l2cap_chan_put (CVE-2025-21969 bsc#1240784). - commit afacee7 - Bluetooth: Fix error code in chan_alloc_skb_cb() (bsc#1240582 CVE-2025-22007). - commit b580f9e - drm/radeon: fix uninitialized size issue in radeon_vce_cs_parse() (CVE-2025-21996 bsc#1240801). - commit 4ea5dea - usb: atm: cxacru: fix a flaw in existing endpoint checks (bsc#1240582 CVE-2025-21916). - commit e17a34b - Bluetooth: L2CAP: Fix slab-use-after-free Read in l2cap_send_cmd (CVE-2025-21969 bsc#1240784). - commit 900222a - iscsi_ibft: Fix UBSAN shift-out-of-bounds warning in ibft_attr_show_nic() (CVE-2025-21993 bsc#1240797). - commit 1c1b4a4 - tpm: tis: Double the timeout B to 4s (bsc#1235870). - commit e4e19da - tpm, tpm_tis: Workaround failed command reception on Infineon devices (bsc#1235870). - commit 87601ca - ppp: Fix KMSAN uninit-value warning with bpf (CVE-2025-21922 bsc#1240639). - commit ca66710 - arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array (CVE-2025-21785 bsc#1238747) - commit 24fbd3b - rapidio: add check for rio_add_net() in rio_scan_alloc_net() (CVE-2025-21935 bsc#1240700). - rapidio: fix an API misues when rio_add_net() fails (CVE-2025-21934 bsc#1240708). - commit df62006 - macsec: fix UAF bug for real_dev (CVE-2022-49390 bsc#1238233) - commit d0ae16a - dax: make sure inodes are flushed before destroy cache (CVE-2022-49220 bsc#1237936) - commit dd8bb0a - sysctl: Fix data races in proc_douintvec() (CVE-2022-49641 bsc#1237831) - commit 1859db6 - gpu: host1x: Fix a memory leak in 'host1x_remove()' (CVE-2021-47648 bsc#1237725) - commit 565f8ec - qede: confirm skb is allocated before using (CVE-2022-49084 bsc#1237751) - commit a2a6334 - net: fix data-races around sk-&gt;sk_forward_alloc (CVE-2024-53124 bsc#1234074). - commit 7d9d482 - netfilter: conntrack: re-fetch conntrack after insertion (CVE-2022-49561 bsc#1238537). - commit d3e0ad2 - netfilter: ipset: Fix overflow before widen in the bitmap_ip_create() function (CVE-2023-53032 bsc#1240270). - commit 7dde838 - ipv4: prevent potential spectre v1 gadget in ip_metrics_convert() (CVE-2023-52997 bsc#1240303). - commit ed98686 - sysctl: Fix data races in proc_douintvec_minmax() (CVE-2022-49640 bsc#1237782) - commit 0dfbf72 - kernel/sysctl.c: define minmax conv functions in terms of non-minmax versions (bsc#1237782) - commit 1263b48 - Update references for patches.suse/kernel-sysctl.c-add-missing-range-check-in-do_proc_d.patch (bsc#1237782 bsc#1051510) - commit 51d8dd8 - pipe: reject F_SETPIPE_SZ with size over UINT_MAX (bsc#1237782) - commit 57c3c8a - pipe, sysctl: remove pipe_proc_fn() (bsc#1237782) - commit 5b47dc3 - pipe, sysctl: drop 'min' parameter from pipe-max-size converter (bsc#1237782) - commit 559c162 - sysctl: check for UINT_MAX before unsigned int min/max (bsc#1237782) - commit 6169ace - pipe: add proc_dopipe_max_size() to safely assign pipe_max_size (bsc#1237782) - commit 2f6a8d2 - Update references for patches.suse/pipe-match-pipe_max_size-data-type-with-procfs.patch (bsc#1237782 git-fixes) - commit 4bc1ec0 - nfc: st21nfca: fix memory leaks in EVT_TRANSACTION handling (CVE-2022-49331 bsc#1237813) - commit 8331408 - phy: qcom-qmp: fix struct clk leak on probe errors (CVE-2022-49397 bsc#1237823) - commit 29ed697 - KVM: VMX: Prevent RSB underflow before vmenter (CVE-2022-49610 bsc#1238952). - commit bea6096 - x86/kexec: Fix double-free of elf header buffer (git-fixes CVE-2022-49546 bsc#1238750). - x86/kexec: fix memory leak of elf header buffer (CVE-2022-49546 bsc#1238750). - commit 69722e9 - Refresh patches.suse/ipv6-icmp-convert-to-dev_net_rcu.patch. - commit 8cd0e69 - bpf, sockmap: Fix double uncharge the mem of sk_msg (CVE-2022-49205 bsc#1238335). - commit f6c5311 - af_netlink: Fix shift out of bounds in group mask calculation (CVE-2022-49197 bsc#1238455). - commit 9a4a535 - uprobes: Reject the shared zeropage in uprobe_write_opcode() (CVE-2025-21881 bsc#1240185) - commit f4218b4 - firmware: dmi-sysfs: Fix null-ptr-deref in dmi_sysfs_register_handle (bsc#1238467) - commit 1cd86ca - scsi: target: tcmu: Fix possible page UAF (CVE-2022-49053 bsc#1237918). - commit beef048 - mm/khugepaged: fix -&gt;anon_vma race (CVE-2023-52935 bsc#1240276). - commit a534f8f - usbnet: gl620a: fix endpoint checking in genelink_bind() (bsc#1240172 CVE-2025-21877). - commit 4ca0b45 - Refresh patches.suse/ipv4-use-RCU-protection-in-ip_dst_mtu_maybe_forward.patch. - commit 22f6eba - netem: Update sch-&gt;q.qlen before qdisc_tree_reduce_backlog() (git-fixes CVE-2025-21703 bsc#1237313). - commit cbd2039 - net: sfp: fix memory leak in sfp_probe() (CVE-2022-49619 bsc#1239003) - commit 04c9c14 - net: tipc: fix possible refcount leak in tipc_sk_create() (CVE-2022-49620 bsc#1239002) - commit 73f1781 - team: prevent adding a device which is already a team device lower (CVE-2024-58071 bsc#1238970 - commit 850cca8 - tcp: tcp_rtx_synack() can be called from process context (CVE-2022-49372 bsc#1238251). - commit 2b7ccd1 - af_unix: Fix a data-race in unix_dgram_peer_wake_me() (CVE-2022-49344 bsc#1237988). - commit 906cfb9 - net/sched: netem: account for backlog updates from child qdisc (CVE-2024-56770 bsc#1235637). - net/smc: fix LGR and link use-after-free issue (CVE-2024-56640 bsc#1235436). - netlink: terminate outstanding dump on socket close (CVE-2024-53140 bsc#1234222). - commit fa3efff - net: mana: Support holes in device list reply msg (bsc#1240133). - ipvlan: ensure network headers are in skb linear part (CVE-2025-21891 bsc#1240186). - bnxt: Do not read past the end of test names (CVE-2023-53010 bsc#1240290). - net: mdio: validate parameter addr in mdiobus_get_phy() (CVE-2023-53019 bsc#1240286). - commit 44816a5 - wifi: brcmfmac: Check the count value of channel spec to prevent out-of-bounds reads (CVE-2022-49740 bsc#1240233). - commit 0c49112 - Update patches.suse/ibmvnic-Don-t-reference-skb-after-sending-to-VIOS.patch (CVE-2025-21858 bsc#1239468 CVE-2025-21855 bsc#1239484). - commit f98b7e1 - Update patches.suse/media-cx24116-prevent-overflows-on-SNR-calculus.patch (CVE-2024-50290 bsc#1233479 bsc#1225742). - Update patches.suse/media-dvbdev-prevent-the-risk-of-out-of-memory-acces.patch (CVE-2024-53063 bsc#1233557 bsc#1225742). - commit 3bb8dac - Update patches.suse/HID-betop-check-shape-of-output-reports.patch (git-fixes bsc#1207186 CVE-2023-53015 bsc#1240288). - Update patches.suse/Squashfs-fix-handling-and-sanity-checking-of-xattr_i.patch (git-fixes CVE-2023-52933 bsc#1240275). - Update patches.suse/bpf-Fix-pointer-leak-due-to-insufficient-speculative.patch (bsc#1231375 CVE-2023-53024 bsc#1240272). - Update patches.suse/cifs-Fix-oops-due-to-uncleared-server-smbd_conn-in-reconnect.patch (bsc#1190317 CVE-2023-53006 bsc#1240208). - Update patches.suse/cifs-fix-potential-memory-leaks-in-session-setup.patch (bsc#1190317 CVE-2023-53008 bsc#1240318). - Update patches.suse/netlink-prevent-potential-spectre-v1-gadgets.patch (bsc#1209547 CVE-2017-5753 CVE-2023-53000 bsc#1240227). - Update patches.suse/powerpc-imc-pmu-Fix-use-of-mutex-in-IRQs-disabled-se.patch (bsc#1054914 fate#322448 git-fixes CVE-2023-53031 bsc#1240285). - Update patches.suse/scsi-iscsi_tcp-Fix-UAF-during-login-when-accessing-the-shost-ipaddress.patch (bsc#1210647 CVE-2023-2162 CVE-2023-52974 bsc#1240213). - Update patches.suse/squashfs-harden-sanity-check-in-squashfs_read_xattr_.patch (git-fixes CVE-2023-52979 bsc#1240282). - Update patches.suse/tracing-Make-sure-trace_printk-can-output-as-soon-as-it-can-be-used.patch (git-fixes CVE-2023-53007 bsc#1240229). - Update patches.suse/vc_screen-move-load-of-struct-vc_data-pointer-in-vcs.patch (bsc#1213167 CVE-2023-3567 CVE-2023-52973 bsc#1240218). - commit 5c75cc8 - Update patches.suse/cpufreq-governor-Use-kobject-release-method-to-free-dbs_data.patch (bsc#1237800 CVE-2022-49513). - commit d961554 - um: Fix out-of-bounds read in LDT setup (CVE-2022-49395 bsc#1237953) - commit 9b1534c - firmware: dmi-sysfs: Fix memory leak in dmi_sysfs_register_handle (CVE-2022-49370 bsc#1238467) - commit 56fb9f5 - ipw2x00: Fix potential NULL dereference in libipw_xmit() (CVE-2022-49544 bsc#1238721) - commit b1c6aa1 - tee: optee: Fix supplicant wait loop (CVE-2025-21871 bsc#1240183). - commit dd819c0 - team: add ethtool get_link_ksettings (bsc#1228909). - commit 29a7164 - Refresh patches.suse/net-remove-two-BUG-from-skb_checksum_help.patch. - commit f154628 - cpufreq: governor: Use kobject release() method to free dbs_data (bsc#1237800). - dbs_data kABI workaround (bsc#1237800 CVE-2022-49513). - commit 1891c97 - cpufreq: Move to_gov_attr_set() to cpufreq.h (bsc#1237800 CVE-2022-49513). - commit af55b29 - net: usb: usbnet: restore usb%d name exception for local mac addresses (bsc#1234480). - commit c9b9e0d - scsi: pm8001: Fix memory leak in pm8001_chip_fw_flash_update_req() (CVE-2022-49119 bsc#1237925) - commit 3b2e4a3 - scsi: pm8001: Fix task leak in pm8001_send_abort_all() (CVE-2022-49120 bsc#1237969) - commit 5941b1a - RDMA/hfi1: Prevent use of lock before it is initialized (CVE-2022-49433 bsc#1238268) - commit 6b108b0 - drm/msm/hdmi: check return value after calling platform_get_resource_byname() (CVE-2022-49495 bsc#1237932). - commit 250e248 - ipv6: mcast: extend RCU protection in igmp6_send() (CVE-2025-21759 bsc#1238738). - commit de67669 - ndisc: extend RCU protection in ndisc_send_skb() (CVE-2025-21760 bsc#1238763). - commit bbd5bed - vrf: use RCU protection in l3mdev_l3_out() (CVE-2025-21791 bsc#1238512). - commit 67aac47 - arp: use RCU protection in arp_xmit() (CVE-2025-21762 bsc#1238780). - commit 86c524f - neighbour: use RCU protection in __neigh_notify() (CVE-2025-21763 bsc#1237897). - commit d195b5b - ndisc: use RCU protection in ndisc_alloc_skb() (bsc#1239994). - commit f3d8410 - ndisc: ndisc_send_redirect() must use dev_get_by_index_rcu() (bsc#1239994). - commit 794c7eb - ipv6: Use RCU in ip6_input() (bsc#1239994). - commit 81adbde - ipv6: icmp: convert to dev_net_rcu() (bsc#1239994). - commit 86dda00 - ipv6: use RCU protection in ip6_default_advmss() (CVE-2025-21765 bsc#1237906). - commit 00b5f63 - ipv4: use RCU protection in __ip_rt_update_pmtu() (CVE-2025-21766 bsc#1238754). - commit ae267d9 - ipv4: use RCU protection in inet_select_addr() (bsc#1239994). - commit 442e2c4 - ipv4: use RCU protection in rt_is_expired() (bsc#1239994). - commit 6439cd7 - ipv4: use RCU protection in ip_dst_mtu_maybe_forward() (bsc#1239994). - commit 6b0f168 - ipv4: add RCU protection to ip4_dst_hoplimit() (bsc#1239994). - commit fc7ba98 - net: add dev_net_rcu() helper (bsc#1239994). - commit 51827b8 - net: treat possible_net_t net pointer as an RCU one and add read_pnet_rcu() (bsc#1239994). - commit a3369f3 - drm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_table (CVE-2024-58052 bsc#1238986). - commit 9320da0 - KVM: Explicitly verify target vCPU is online in kvm_get_vcpu() (CVE-2024-58083 bsc#1239036). - commit 22cf047 - nfp: bpf: Add check for nfp_app_ctrl_msg_alloc() (CVE-2025-21848 bsc#1239479). - commit 55016a1 - igc: Reinstate IGC_REMOVED logic and implement it properly (CVE-2022-49605 bsc#1238433). - commit 5af1e50 - net: dsa: mv88e6xxx: Fix refcount leak in mv88e6xxx_mdios_register (CVE-2022-49367 bsc#1238447). - commit 3ebb662 - net: tun: unlink NAPI from device on destruction (CVE-2022-49672 bsc#1238816). - commit e432fa1 - kABI fix for tcp: properly terminate timers for kernel sockets (CVE-2024-35910 bsc#1224489). - commit 03a709f - ip: Fix data-races around sysctl_ip_prot_sock. (CVE-2022-49578 bsc#1238794) - commit 55c2c0e - kABI fix for mptcp: add sk_stop_timer_sync helper (CVE-2024-35910 bsc#1224489). - commit d3152b9 - mptcp: add sk_stop_timer_sync helper (CVE-2024-35910 bsc#1224489). - Refresh patches.suse/net-add-sock_init_data_uid.patch. - commit b72feae - net: remove two BUG() from skb_checksum_help() (CVE-2022-49497 bsc#1238946). - commit 243b7fc - net: bonding: fix use-after-free after 802.3ad slave unbind (CVE-2022-49667 bsc#1238282) - commit bd21be6 - wifi: mac80211: fix use-after-free in chanctx code (CVE-2022-49416 bsc#1238293) - commit 40d129d - bus: fsl-mc-bus: fix KASAN use-after-free in fsl_mc_bus_remove() (CVE-2022-49711 bsc#1238416) - commit 1048344 - media: pci: cx23885: Fix the error handling in cx23885_initdev() (CVE-2022-49524 bsc#1238949) - commit 45001c2 - NFC: NULL out the dev-&gt;rfkill to prevent UAF (CVE-2022-49505 bsc#1238615) - commit 8dd4c4d - kABI: protect mr_ifc_count change (CVE-2022-49589 bsc#1238598). - igmp: Fix data-races around sysctl_igmp_qrv (CVE-2022-49589 bsc#1238598). - net: igmp: increase size of mr_ifc_count (CVE-2022-49589 bsc#1238598). - net: igmp: fix data-race in igmp_ifc_timer_expire() (CVE-2022-49589 bsc#1238598). - commit 3efb324 - i2c: dev: check return value when calling dev_set_name() (CVE-2022-49046 bsc#1237842) - commit de84566 - btrfs: fix qgroup reserve overflow the qgroup limit (CVE-2022-49075 bsc#1237733). - commit bf9031a - ceph: fix inode reference leakage in ceph_get_snapdir() (CVE-2022-49109 bsc#1237836) - commit d418afc - ceph: fix up error handling with snapdirs (bsc#1237836) - commit f7001b0 - ubi: ubi_create_volume: Fix use-after-free when volume creation failed (CVE-2022-49388 bsc#1237934) - commit 0d5c203 - ceph: fix memory leak in ceph_readdir when note_last_dentry returns error (CVE-2022-49107 bsc#1237973) - commit 40beec1 - ila: serialize calls to nf_register_net_hooks() (CVE-2024-57900 bsc#1235973). - commit d69423e - tcp: properly terminate timers for kernel sockets (CVE-2024-35910 bsc#1224489). - commit 5ce5df8 - ACPI: PAD: fix crash in exit_round_robin() (bsc#1232370 CVE-2024-49935). - commit e03632e - Update patches.suse/netfilter-nf_tables-initialize-registers-in-nft_do_c.patch (CVE-2022-1016 bsc#1197227 CVE-2022-49293 bsc#1239454). - commit cedf6cd - fbdev: omap: use threaded IRQ for LCD DMA (bsc#1239174 CVE-2025-21821) - commit f159c1f - drm/amd/pm: fix double free in si_parse_power_table() (bsc#1238944 CVE-2022-49530) - commit dfebfa5 - net: phy: micrel: Allow probing without .driver_data (CVE-2022-49472 bsc#1238951). - ice: always check VF VSI pointer values (CVE-2022-49516 bsc#1238953). - commit f9c1961 - geneve: Suppress list corruption splat in geneve_destroy_tunnels() (CVE-2025-21858 bsc#1239468). - gtp: Suppress list corruption splat in gtp_net_exit_batch_rtnl() (CVE-2025-21865 bsc#1239481). - ibmvnic: Don't reference skb after sending to VIOS (CVE-2025-21858 bsc#1239468). - geneve: Fix use-after-free in geneve_find_dev() (CVE-2025-21858 bsc#1239468). - commit 7c11337 - net: fix SO_REUSEPORT return code (bsc#1239448) - commit 3c526b1 - nfsd: clear acl_access/acl_default after releasing them (bsc#1238716 CVE-2025-21796). - commit d1c11c1 - acct: perform last write from workqueue (CVE-2025-21846 bsc#1239508). - commit 5fc1617 - irqchip/gic-v3: Fix GICR_CTLR.RWP polling (git-fixes CVE-2022-49074 bsc#1237728). - commit 9f6dc13 - media: staging: media: zoran: calculate the right buffer number for zoran_reap_stat_com (CVE-2021-47645 bsc#1237767). - commit eab4973 - PCI: Avoid putting some root ports into D3 on TUXEDO Sirius Gen1 (CVE-2025-21831 bsc#1239039). - commit 10f73c4 - net/smc: check iparea_offset and ipv6_prefixes_cnt when receiving proposal msg (CVE-2024-49571 bsc#1235733). - commit ef9a771 - kABI fix for l2tp: prevent possible tunnel refcount underflow (CVE-2024-49940 bsc#1232812). Upstream commit 24256415d186 (&quot;l2tp: prevent possible tunnel refcount underflow&quot;) changed the API of `l2tp_session_set_header_len()` and this patch re-introduces the API in that version. - commit 803eb4b - l2tp: prevent possible tunnel refcount underflow (CVE-2024-49940 bsc#1232812). - commit 377601f - drm/msm/mdp5: Return error code in mdp5_mixer_release when deadlock (bsc#1238600 CVE-2022-49488) - commit b961f00 - bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is full (bsc#1238252 CVE-2022-49209). - commit aeb9c23 - scripts: fix incorrect regex escape With Tumbleweed's recent switch to Python 3.13 recently I noticed several syntax warning related to regex .../scripts/python/suse_git/patch.py:57: SyntaxWarning: invalid escape sequence '\*' break_matcher = re.compile(b&quot;(---|\*\*\*|Index:)[ \t][^ \t]|^diff -&quot;) .../scripts/python/git_sort/git_sort.py:490: SyntaxWarning: invalid escape sequence '\.' version_match = re.compile(&quot;refs/tags/v(2\.6\.\d+|\d\.\d+)(-rc\d+)?$&quot;) .../scripts/python/git_sort/git_sort.py:578: SyntaxWarning: invalid escape sequence '\.' m = re.search(&quot;v([0-9]+)\.([0-9]+)(|-rc([0-9]+))$&quot;, tags[-1]) Fix them by using raw string/byte literal instead. Link: https://docs.python.org/3/reference/lexical_analysis.html#string-and-bytes-literals - commit 74871be - netpoll: Fix race condition in netpoll_owner_active (CVE-2024-41005 bsc#1227858). - net: make sure napi_list is safe for RCU traversal (CVE-2024-41005 bsc#1227858). - commit b55492f - net: usb: aqc111: Fix out-of-bounds accesses in RX fixup (bsc#1237903 CVE-2022-49051). - commit eb6ef6f - usb: musb: sunxi: Fix accessing an released usb phy (bsc#1233458 CVE-2024-50269). - commit 14a906c - USB: hub: Ignore non-compliant devices with too many configs or interfaces (bsc#1238909 CVE-2025-21776). - commit 6d1cc77 - net: usb: rtl8150: enable basic endpoint checking (bsc#1239087 CVE-2025-21708). - commit 582b035 - Refresh patches.suse/net-smc-fix-kernel-panic-caused-by-race-of-smc_sock.patch. - commit 89c4c51 - ALSA: usb-audio: Cancel pending work at closing a MIDI substream (CVE-2022-49545 bsc#1238729). - commit c5aef00 - net_sched: sch_sfq: don't allow 1 packet limit (CVE-2024-57996 bsc#1239076). - commit 30f09ff - wifi: brcmfmac: fix NULL pointer dereference in brcmf_txfinalize() (CVE-2025-21744 bsc#1238903). - commit af88382 - Update patches.suse/0006-dm-raid-fix-accesses-beyond-end-of-raid-member-array.patch (git-fixes CVE-2022-49674 bsc#1239041). - Update patches.suse/0013-block-don-t-delete-queue-kobject-before-its-children.patch (git-fixes CVE-2022-49259 bsc#1238413). - Update patches.suse/0013-dm-mirror-log-round-up-region-bitmap-size-to-BITS_PE.patch (git-fixes CVE-2022-49710 bsc#1238417). - Update patches.suse/0015-bfq-Update-cgroup-information-before-merging-bio.patch (git-fixes CVE-2022-49413 bsc#1238710). - Update patches.suse/0074-dm-ioctl-prevent-potential-spectre-v1-gadget.patch (git-fixes CVE-2022-49122 bsc#1237983). - Update patches.suse/0077-nbd-call-genl_unregister_family-first-in-nbd_cleanup.patch (git-fixes CVE-2022-49295 bsc#1238707). - Update patches.suse/0078-nbd-fix-race-between-nbd_alloc_config-and-module-removal.patch (git-fixes CVE-2022-49300 bsc#1238183). - Update patches.suse/0079-nbd-fix-io-hung-while-disconnecting-device.patch (git-fixes CVE-2022-49297 bsc#1238469). - Update patches.suse/ALSA-pcm-Fix-potential-AB-BA-lock-with-buffer_mutex-.patch (CVE-2022-1048 bsc#1197331 CVE-2022-49272 bsc#1238272). - Update patches.suse/ALSA-pcm-Fix-races-among-concurrent-hw_params-and-hw.patch (CVE-2022-1048 bsc#1197331 CVE-2022-49291 bsc#1238705). - Update patches.suse/ALSA-pcm-Fix-races-among-concurrent-prealloc-proc-wr.patch (CVE-2022-1048 bsc#1197331 CVE-2022-49288 bsc#1238271). - Update patches.suse/ALSA-pcm-oss-Fix-race-at-SNDCTL_DSP_SYNC.patch (CVE-2022-3303 bsc#1203769 CVE-2022-49733 bsc#1238454). - Update patches.suse/Bluetooth-hci_qca-Use-del_timer_sync-before-freeing.patch (git-fixes CVE-2022-49555 bsc#1238231). - Update patches.suse/NFSD-prevent-underflow-in-nfssvc_decode_writeargs.patch (git-fixes CVE-2022-49280 bsc#1238630). - Update patches.suse/PCI-Avoid-pci_dev_lock-AB-BA-deadlock-with-sriov_num.patch (git-fixes CVE-2022-49434 bsc#1238916). - Update patches.suse/RDMA-hfi1-Prevent-panic-when-SDMA-is-disabled.patch (git-fixes CVE-2022-49429 bsc#1238889). - Update patches.suse/SUNRPC-Fix-the-svc_deferred_event-trace-class.patch (git-fixes CVE-2022-49065 bsc#1237739). - Update patches.suse/bpf-sockmap-Fix-more-uncharged-while-msg-has-more_da.patch (bsc#1235485 CVE-2024-56633 CVE-2022-49204 bsc#1238240). - Update patches.suse/cgroup-Use-separate-src-dst-nodes-when-preloading-css_sets-for-migration.patch (bsc#1201610 CVE-2022-49647 bsc#1238805). - Update patches.suse/cifs-fix-handlecache-and-multiuser.patch (bsc#1190317 CVE-2022-49281 bsc#1238635). - Update patches.suse/cifs-potential-buffer-overflow-in-handling-symlinks.patch (bsc#1190317 CVE-2022-49058 bsc#1237814). - Update patches.suse/cifs-prevent-bad-output-lengths-in-smb2_ioctl_query_info-.patch (bsc#1190317 CVE-2022-49271 bsc#1238626). - Update patches.suse/crypto-qat-fix-memory-leak-in-RSA.patch (git-fixes CVE-2022-49566 bsc#1238266). - Update patches.suse/dlm-fix-plock-invalid-read.patch (git-fixes CVE-2022-49407 bsc#1238180). - Update patches.suse/dm-raid-fix-KASAN-warning-in-raid5_add_disks.patch (git-fixes CVE-2022-49673 bsc#1238933). - Update patches.suse/drbd-Fix-five-use-after-free-bugs-in-get_initial_state (git-fixes CVE-2022-49085 bsc#1238036). - Update patches.suse/drivers-usb-host-Fix-deadlock-in-oxu_bus_suspend.patch (git-fixes CVE-2022-49313 bsc#1238633). - Update patches.suse/drm-virtio-fix-NULL-pointer-dereference-in-virtio_gp.patch (git-fixes CVE-2022-49532 bsc#1238925). - Update patches.suse/exec-Force-single-empty-string-when-argv-is-empty.patch (bsc#1200571 CVE-2022-49264 bsc#1237815). - Update patches.suse/ext4-add-reserved-GDT-blocks-check.patch (bsc#1202712 CVE-2022-49707 bsc#1239035). - Update patches.suse/ext4-avoid-cycles-in-directory-h-tree.patch (bsc#1198577 CVE-2022-1184 CVE-2022-49343 bsc#1238382). - Update patches.suse/ext4-fix-bug_on-ext4_mb_use_inode_pa.patch (bsc#1200810 CVE-2022-49708 bsc#1238599). - Update patches.suse/ext4-fix-bug_on-in-__es_tree_search.patch (bsc#1200809 CVE-2022-49409 bsc#1238279). - Update patches.suse/ext4-fix-bug_on-in-ext4_writepages.patch (bsc#1200872 CVE-2022-49347 bsc#1238393). - Update patches.suse/ext4-fix-race-condition-between-ext4_write-and-ext4_.patch (bsc#1200807 CVE-2022-49414 bsc#1238623). - Update patches.suse/ext4-fix-use-after-free-in-ext4_rename_dir_prepare.patch (bsc#1200871 CVE-2022-49349 bsc#1238372). - Update patches.suse/icmp-Fix-data-races-around-sysctl.patch (CVE-2024-47678 bsc#1231854 git-fixes CVE-2022-49638 bsc#1238613). - Update patches.suse/ixgbe-Add-locking-to-prevent-panic-when-setting-srio.patch (git-fixes CVE-2022-49584 bsc#1237933). - Update patches.suse/list-fix-a-data-race-around-ep-rdllist.patch (git-fixes CVE-2022-49443 bsc#1238434). - Update patches.suse/md-bitmap-don-t-set-sb-values-if-can-t-pass-sanity-c.patch (bsc#1197158 CVE-2022-49526 bsc#1238030). - Update patches.suse/module-fix-e_shstrndx-.sh_size-0-OOB-access.patch (git-fixes CVE-2022-49444 bsc#1238127). - Update patches.suse/msft-hv-2556-Drivers-hv-vmbus-Fix-potential-crash-on-module-unloa.patch (git-fixes CVE-2022-49098 bsc#1238079). - Update patches.suse/mxser-fix-xmit_buf-leak-in-activate-when-LSR-0xff.patch (git-fixes CVE-2022-49191 bsc#1238133). - Update patches.suse/net-asix-add-proper-error-handling-of-usb-read-error.patch (git-fixes CVE-2022-49226 bsc#1238336). - Update patches.suse/nvme-pci-fix-a-NULL-pointer-dereference-in-nvme_allo.patch (git-fixes CVE-2022-49492 bsc#1238954). - Update patches.suse/ocfs2-dlmfs-fix-error-handling-of-user_dlm_destroy_l.patch (git-fixes CVE-2022-49337 bsc#1238376). - Update patches.suse/powerpc-pseries-Fix-use-after-free-in-remove_phb_dyn.patch (bsc#1065729 bsc#1198660 ltc#197803 CVE-2022-49196 bsc#1238274). - Update patches.suse/powerpc-tm-Fix-more-userspace-r13-corruption.patch (bsc#1065729 CVE-2022-49164 bsc#1238108). - Update patches.suse/powerpc-xics-fix-refcount-leak-in-icp_opal_init.patch (bsc#1065729 CVE-2022-49432 bsc#1238950). - Update patches.suse/powerpc-xive-Fix-refcount-leak-in-xive_spapr_init.patch (fate#322438 git-fixes CVE-2022-49437 bsc#1238443). - Update patches.suse/powerpc-xive-spapr-correct-bitmap-allocation-size.patch (fate#322438 git-fixes CVE-2022-49623 bsc#1239040). - Update patches.suse/scsi-libfc-Fix-use-after-free-in-fc_exch_abts_resp.patch (git-fixes CVE-2022-49114 bsc#1238146). - Update patches.suse/scsi-lpfc-Address-NULL-pointer-dereference-after-sta.patch (git-fixes CVE-2022-49332 bsc#1238236). - Update patches.suse/scsi-pm8001-Fix-abort-all-task-initialization (git-fixes CVE-2022-49217 bsc#1238313). - Update patches.suse/scsi-qla2xxx-Fix-crash-during-module-load-unload-tes.patch (bsc#1197661 CVE-2022-49160 bsc#1238172). - Update patches.suse/scsi-qla2xxx-Fix-premature-hw-access-after-PCI-error.patch (bsc#1195823 CVE-2022-49157 bsc#1238169). - Update patches.suse/scsi-qla2xxx-Fix-scheduling-while-atomic.patch (bsc#1195823 CVE-2022-49156 bsc#1238168). - Update patches.suse/scsi-qla2xxx-Fix-warning-message-due-to-adisc-being-.patch (bsc#1195823 CVE-2022-49158 bsc#1238170). - Update patches.suse/scsi-qla2xxx-Implement-ref-count-for-SRB.patch (bsc#1195823 CVE-2022-49159 bsc#1238171). - Update patches.suse/scsi-qla2xxx-Suppress-a-kernel-complaint-in-qla_crea.patch (bsc#1195823 CVE-2022-49155 bsc#1237941). - Update patches.suse/scsi-zorro7xx-Fix-a-resource-leak-in-zorro7xx_remove_one (git-fixes CVE-2022-49095 bsc#1237752). - Update patches.suse/tcp-fix-tcp_mtup_probe_success-vs-wrong-snd_cwnd.patch (bsc#1218450 CVE-2022-49330 bsc#1238378). - Update patches.suse/tpm-fix-reference-counting-for-struct-tpm_chip.patch (CVE-2022-2977 bsc#1202672 CVE-2022-49287 bsc#1238276). - Update patches.suse/tracing-Fix-sleeping-function-called-from-invalid-context-on-RT-kernel.patch (git-fixes CVE-2022-49322 bsc#1238396). - Update patches.suse/usb-dwc2-Fix-memory-leak-in-dwc2_hcd_init.patch (git-fixes CVE-2022-49713 bsc#1238419). - Update patches.suse/usb-usbip-fix-a-refcount-leak-in-stub_probe.patch (git-fixes CVE-2022-49389 bsc#1238257). - Update patches.suse/usbnet-fix-memory-leak-in-error-case.patch (git-fixes CVE-2022-49657 bsc#1238269). - Update patches.suse/veth-Ensure-eth-header-is-in-skb-s-linear-part.patch (git-fixes CVE-2022-49066 bsc#1237722). - Update patches.suse/video-fbdev-clcdfb-Fix-refcount-leak-in-clcdfb_of_vr.patch (bsc#1129770 CVE-2022-49421 bsc#1238819). - Update patches.suse/virtio_console-eliminate-anonymous-module_init-modul.patch (git-fixes CVE-2022-49100 bsc#1237735). - Update patches.suse/virtio_net-fix-xdp_rxq_info-bug-after-suspend-resume.patch (git-fixes CVE-2022-49687 bsc#1238181). - Update patches.suse/x86-speculation-fill-rsb-on-vmexit-for-ibrs.patch (bsc#1201726 CVE-2022-26373 CVE-2022-49611 bsc#1238618). - Update patches.suse/xen-netback-avoid-entering-xenvif_rx_next_skb-with-a.patch (bsc#1201381 CVE-2022-49649 bsc#1238612). - Update patches.suse/xprtrdma-treat-all-calls-not-a-bcall-when-bc_serv-is.patch (git-fixes CVE-2022-49321 bsc#1238373). - commit c156b3c - Update patches.suse/0008-video-fbdev-smscufx-Fix-null-ptr-deref-in-ufx_usb_pr.patch (bsc#1129770 CVE-2021-47652 bsc#1237721). - Update patches.suse/ath5k-fix-OOB-in-ath5k_eeprom_read_pcal_info_5111.patch (git-fixes CVE-2021-47633 bsc#1237768). - commit 9ae3067 - rdma/cxgb4: Prevent potential integer overflow on 32bit (CVE-2024-57973 bsc#1238531) - commit dbbc8b2 - RDMA/hfi1: Fix potential integer multiplication overflow errors (CVE-2022-49404 bsc#1238430) - commit 80a20e6 - nfc: nci: add flush_workqueue to prevent uaf (CVE-2022-49059 bsc#1238007) - commit 305c681 - ipv6: Fix signed integer overflow in l2tp_ip6_sendmsg (CVE-2022-49727 bsc#1239059) - commit 7f3b150 - can: m_can: m_can_tx_handler(): fix use after free of skb (CVE-2022-49275 bsc#1238719) - commit 1fdfcc6 - crypto: qat - add param check for DH (CVE-2022-49564 bsc#1238789) - commit 7f4f28c - crypto: qat - add param check for RSA (CVE-2022-49563 bsc#1238787) - commit f87e665 - wifi: brcmsmac: add gain range check to wlc_phy_iqcal_gainparams_nphy() (CVE-2024-58014 bsc#1239109) - commit fe78d7b - orangefs: fix a oob in orangefs_debug_write (git-fixes bsc#1239117 CVE-2025-21782). - commit 6a7a2b9 - ALSA: jack: Fix mutex call in snd_jack_report() (CVE-2022-49538 bsc#1238843). - commit 0a9be43 - kABI workaround for snd_jack.input_dev_lock field (CVE-2022-49538 bsc#1238843). - commit 0decf9d - ALSA: jack: Access input_dev under mutex (CVE-2022-49538 bsc#1238843). - ath10k: skip ath10k_halt during suspend for driver state RESTARTING (CVE-2022-49519 bsc#1238943). - commit b758634 - extcon: Modify extcon device to be created after driver data is set (CVE-2022-49308 bsc#1238654). - commit bb2d5d7 - ALSA: oss: Fix PCM OSS buffer allocation overflow (CVE-2022-49292 bsc#1238625). - commit 05f3e03 - wifi: rtlwifi: remove unused check_buddy_priv (CVE-2024-58072 bsc#1238964). - commit ca6cdaf - perf/core: Fix data race between perf_event_set_output() and perf_mmap_close() (CVE-2022-49607 bsc#1238817). - commit 7d0651a - kABI workaround for pps changes (CVE-2024-57979 bsc#1238521). - commit ecc73ae - pps: Fix a use-after-free (CVE-2024-57979 bsc#1238521). - commit 5e01f6b - net: hns3: fix oops when unload drivers paralleling (CVE-2025-21802 bsc#1238751). - be2net: Fix buffer overflow in be_get_module_eeprom (CVE-2022-49581 bsc#1238540). - commit f8f5e83 - tpm: use try_get_ops() in tpm-space.c (CVE-2022-49286 bsc#1238647). - commit 0f153ea - ipvs: fix UB due to uninitialized stack access in ip_vs_protocol_init() (CVE-2024-53680 bsc#1235715). - commit 8dac11a - kABI workaround for bluetooth hci_conn struct change (CVE-2024-36968 bsc#1226130). - commit be09290 - Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init() (CVE-2024-36968 bsc#1226130). - commit 930b6c7 - scsi: qedf: Ensure the copied buf is NUL terminated (CVE-2024-38559 bsc#1226785). - commit 15b9d87 Package lifecycle-data-sle-live-patching was updated: Package libxslt was updated: - Security fixes: * Fix use-after-free of XPath context node [bsc#1239625, CVE-2025-24855] * Fix UAF related to excluded namespaces [bsc#1239637, CVE-2024-55549] * Add patches: - libxslt-CVE-2024-55549.patch - libxslt-CVE-2025-24855.patch Package sudo was updated: - Fix a possilbe local privilege escalation via the --host option [bsc#1245274, CVE-2025-32462] Package glib2 was updated: - Add glib2-CVE-2025-4373.patch: carefully handle gssize parameters (bsc#1242844 CVE-2025-4373 glgo#GNOME/glib#3677). Package rsync was updated: - Fix bsc#1239649 - rsync bwlimit=0 option was broken by CVE-2024-12088 fix. * Add rsync-fix-bwlimit.patch * bwlimit=0 specifies no limit properly now. Package python-instance-billing-flavor-check was updated: - Update to version 1.0.1 + Fix infinite loop (bsc#1242064) + Fix bug in update infrastructure request (bsc#1242064) The CVRF data is provided by SUSE under the Creative Commons License 4.0 with Attribution (CC-BY-4.0). https://publiccloudimagechangeinfo.suse.com/google/sles-12-sp5-sap-v20250709-x86-64/ Public Cloud Image Info https://www.suse.com/support/security/rating/ SUSE Security Ratings Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 SAPHanaSR-0.162.5-3.45.1 SAPHanaSR-doc-0.162.5-3.45.1 augeas-1.10.1-4.6.1 augeas-lenses-1.10.1-4.6.1 ca-certificates-mozilla-2.74-12.51.1 cloud-regionsrv-client-10.4.0-52.127.1 cloud-regionsrv-client-plugin-gce-1.0.0-52.127.1 cluster-md-kmp-default-4.12.14-122.261.1 dlm-kmp-default-4.12.14-122.261.1 expat-2.7.1-21.43.1 gfs2-kmp-default-4.12.14-122.261.1 glib2-tools-2.48.2-12.46.1 google-cloud-sap-agent-3.7-6.46.2 google-guest-agent-20250506.01-1.53.1 google-guest-configs-20241205.00-1.43.1 google-osconfig-agent-20250416.02-1.41.1 iputils-s20161105-11.9.1 kbd-2.0.4-8.13.1 kbd-legacy-2.0.4-8.13.1 kernel-default-4.12.14-122.261.1 ldirectord-4.3.018.a7fb5035-3.113.3 libapparmor1-2.8.2-56.26.1 libaugeas0-1.10.1-4.6.1 libexpat1-2.7.1-21.43.1 libfreebl3-3.112-58.130.1 libfreetype6-2.6.3-7.24.1 libgio-2_0-0-2.48.2-12.46.1 libglib-2_0-0-2.48.2-12.46.1 libgmodule-2_0-0-2.48.2-12.46.1 libgobject-2_0-0-2.48.2-12.46.1 libgthread-2_0-0-2.48.2-12.46.1 libicu52_1-52.1-8.16.1 libicu52_1-data-52.1-8.16.1 libpacemaker3-1.1.24+20210811.f5abda0ee-3.46.2 libpci3-3.5.6-11.9.1 libseccomp2-2.5.3-11.9.1 libsoftokn3-3.112-58.130.1 libsqlite3-0-3.49.1-9.33.1 libsystemd0-228-157.72.1 libudev1-228-157.72.1 libxml2-2-2.9.4-46.84.1 libxml2-tools-2.9.4-46.84.1 libxslt-tools-1.1.28-17.18.1 libxslt1-1.1.28-17.18.1 lifecycle-data-sle-live-patching-1-10.161.1 mozilla-nspr-4.36-19.32.1 mozilla-nss-3.112-58.130.1 mozilla-nss-certs-3.112-58.130.1 ocfs2-kmp-default-4.12.14-122.261.1 openssh-7.2p2-81.29.4 pacemaker-1.1.24+20210811.f5abda0ee-3.46.2 pacemaker-cli-1.1.24+20210811.f5abda0ee-3.46.2 pam-1.1.8-24.71.1 pam-config-0.89-5.8.1 pciutils-3.5.6-11.9.1 perl-5.18.2-12.29.1 perl-base-5.18.2-12.29.1 python-instance-billing-flavor-check-1.0.1-1.23.1 python-requests-2.24.0-8.23.1 python-setuptools-40.6.2-4.27.1 python3-requests-2.24.0-8.20.1 python3-setuptools-40.6.2-4.27.1 resource-agents-4.3.018.a7fb5035-3.113.3 rsync-3.1.3-3.28.1 screen-4.0.4-23.9.1 sqlite3-3.49.1-9.33.1 sqlite3-tcl-3.49.1-9.33.1 sudo-1.8.27-4.54.1 suse-build-key-12.0-7.22.1 systemd-228-157.72.1 systemd-sysvinit-228-157.72.1 timezone-2025b-74.85.2 udev-228-157.72.1 vim-9.1.1406-17.48.1 vim-data-common-9.1.1406-17.48.1 wget-1.14-21.25.1 SAPHanaSR-0.162.5-3.45.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 SAPHanaSR-doc-0.162.5-3.45.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 augeas-1.10.1-4.6.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 augeas-lenses-1.10.1-4.6.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 ca-certificates-mozilla-2.74-12.51.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 cloud-regionsrv-client-10.4.0-52.127.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 cloud-regionsrv-client-plugin-gce-1.0.0-52.127.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 cluster-md-kmp-default-4.12.14-122.261.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 dlm-kmp-default-4.12.14-122.261.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 expat-2.7.1-21.43.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 gfs2-kmp-default-4.12.14-122.261.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 glib2-tools-2.48.2-12.46.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 google-cloud-sap-agent-3.7-6.46.2 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 google-guest-agent-20250506.01-1.53.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 google-guest-configs-20241205.00-1.43.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 google-osconfig-agent-20250416.02-1.41.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 iputils-s20161105-11.9.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 kbd-2.0.4-8.13.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 kbd-legacy-2.0.4-8.13.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 kernel-default-4.12.14-122.261.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 ldirectord-4.3.018.a7fb5035-3.113.3 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 libapparmor1-2.8.2-56.26.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 libaugeas0-1.10.1-4.6.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 libexpat1-2.7.1-21.43.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 libfreebl3-3.112-58.130.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 libfreetype6-2.6.3-7.24.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 libgio-2_0-0-2.48.2-12.46.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 libglib-2_0-0-2.48.2-12.46.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 libgmodule-2_0-0-2.48.2-12.46.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 libgobject-2_0-0-2.48.2-12.46.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 libgthread-2_0-0-2.48.2-12.46.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 libicu52_1-52.1-8.16.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 libicu52_1-data-52.1-8.16.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 libpacemaker3-1.1.24+20210811.f5abda0ee-3.46.2 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 libpci3-3.5.6-11.9.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 libseccomp2-2.5.3-11.9.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 libsoftokn3-3.112-58.130.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 libsqlite3-0-3.49.1-9.33.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 libsystemd0-228-157.72.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 libudev1-228-157.72.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 libxml2-2-2.9.4-46.84.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 libxml2-tools-2.9.4-46.84.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 libxslt-tools-1.1.28-17.18.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 libxslt1-1.1.28-17.18.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 lifecycle-data-sle-live-patching-1-10.161.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 mozilla-nspr-4.36-19.32.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 mozilla-nss-3.112-58.130.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 mozilla-nss-certs-3.112-58.130.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 ocfs2-kmp-default-4.12.14-122.261.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 openssh-7.2p2-81.29.4 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 pacemaker-1.1.24+20210811.f5abda0ee-3.46.2 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 pacemaker-cli-1.1.24+20210811.f5abda0ee-3.46.2 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 pam-1.1.8-24.71.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 pam-config-0.89-5.8.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 pciutils-3.5.6-11.9.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 perl-5.18.2-12.29.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 perl-base-5.18.2-12.29.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 python-instance-billing-flavor-check-1.0.1-1.23.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 python-requests-2.24.0-8.23.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 python-setuptools-40.6.2-4.27.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 python3-requests-2.24.0-8.20.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 python3-setuptools-40.6.2-4.27.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 resource-agents-4.3.018.a7fb5035-3.113.3 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 rsync-3.1.3-3.28.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 screen-4.0.4-23.9.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 sqlite3-3.49.1-9.33.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 sqlite3-tcl-3.49.1-9.33.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 sudo-1.8.27-4.54.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 suse-build-key-12.0-7.22.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 systemd-228-157.72.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 systemd-sysvinit-228-157.72.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 timezone-2025b-74.85.2 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 udev-228-157.72.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 vim-9.1.1406-17.48.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 vim-data-common-9.1.1406-17.48.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 wget-1.14-21.25.1 as a component of Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64 Expat, when used in a parser that has not called XML_SetHashSalt or passed it a seed of 0, makes it easier for context-dependent attackers to defeat cryptographic protection mechanisms via vectors involving use of the srand function. CVE-2012-6702 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:expat-2.7.1-21.43.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libexpat1-2.7.1-21.43.1 moderate 4.3 AV:N/AC:M/Au:N/C:N/I:P/A:N An integer overflow during the parsing of XML using the Expat library. This vulnerability affects Firefox < 50. CVE-2016-9063 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:expat-2.7.1-21.43.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libexpat1-2.7.1-21.43.1 critical 7.5 AV:N/AC:L/Au:N/C:P/I:P/A:P Systems with microprocessors utilizing speculative execution and branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis. CVE-2017-5753 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 important 4.7 AV:L/AC:M/Au:N/C:C/I:N/A:N XML External Entity vulnerability in libexpat 2.2.0 and earlier (Expat XML Parser Library) allows attackers to put the parser in an infinite loop using a malformed external entity definition from an external DTD. CVE-2017-9233 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:expat-2.7.1-21.43.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libexpat1-2.7.1-21.43.1 important 5 AV:N/AC:L/Au:N/C:N/I:N/A:P In libexpat in Expat before 2.2.7, XML input including XML names that contain a large number of colons could make the XML parser consume a high amount of RAM and CPU resources while processing (enough to be usable for denial-of-service attacks). CVE-2018-20843 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:expat-2.7.1-21.43.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libexpat1-2.7.1-21.43.1 moderate 7.8 AV:N/AC:L/Au:N/C:N/I:N/A:C In libexpat before 2.2.8, crafted XML input could fool the parser into changing from DTD parsing to document parsing too early; a consecutive call to XML_GetCurrentLineNumber (or XML_GetCurrentColumnNumber) then resulted in a heap-based buffer over-read. CVE-2019-15903 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:expat-2.7.1-21.43.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libexpat1-2.7.1-21.43.1 important 5 AV:N/AC:L/Au:N/C:N/I:N/A:P In the Linux kernel, the following vulnerability has been resolved: can: dev: can_get_echo_skb(): prevent call to kfree_skb() in hard IRQ context If a driver calls can_get_echo_skb() during a hardware IRQ (which is often, but not always, the case), the 'WARN_ON(in_irq)' in net/core/skbuff.c#skb_release_head_state() might be triggered, under network congestion circumstances, together with the potential risk of a NULL pointer dereference. The root cause of this issue is the call to kfree_skb() instead of dev_kfree_skb_irq() in net/core/dev.c#enqueue_to_backlog(). This patch prevents the skb to be freed within the call to netif_rx() by incrementing its reference count with skb_get(). The skb is finally freed by one of the in-irq-context safe functions: dev_consume_skb_any() or dev_kfree_skb_any(). The "any" version is used because some drivers might call can_get_echo_skb() in a normal context. The reason for this issue to occur is that initially, in the core network stack, loopback skb were not supposed to be received in hardware IRQ context. The CAN stack is an exeption. This bug was previously reported back in 2017 in [1] but the proposed patch never got accepted. While [1] directly modifies net/core/dev.c, we try to propose here a smoother modification local to CAN network stack (the assumption behind is that only CAN devices are affected by this issue). [1] http://lore.kernel.org/r/57a3ffb6-3309-3ad5-5a34-e93c3fe3614d@cetitec.com CVE-2020-36789 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net_sched: keep alloc_hash updated after hash allocation In commit 599be01ee567 ("net_sched: fix an OOB access in cls_tcindex") I moved cp->hash calculation before the first tcindex_alloc_perfect_hash(), but cp->alloc_hash is left untouched. This difference could lead to another out of bound access. cp->alloc_hash should always be the size allocated, we should update it after this tcindex_alloc_perfect_hash(). CVE-2020-36791 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate A flaw was found in s390 eBPF JIT in bpf_jit_insn in arch/s390/net/bpf_jit_comp.c in the Linux kernel. In this flaw, a local attacker with special user privilege can circumvent the verifier and may lead to a confidentiality problem. CVE-2021-20320 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate 2.1 AV:L/AC:L/Au:N/C:P/I:N/A:N A vulnerability was found in the Linux kernel's EBPF verifier when handling internal data structures. Internal memory locations could be returned to userspace. A local attacker with the permissions to insert eBPF code to the kernel can use this to leak internal kernel memory details defeating some of the exploit mitigations in place for the kernel. CVE-2021-4159 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In Expat (aka libexpat) before 2.4.3, a left shift by 29 (or more) places in the storeAtts function in xmlparse.c can lead to realloc misbehavior (e.g., allocating too few bytes, or only freeing memory). CVE-2021-45960 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:expat-2.7.1-21.43.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libexpat1-2.7.1-21.43.1 moderate 9 AV:N/AC:L/Au:S/C:C/I:C/A:C In doProlog in xmlparse.c in Expat (aka libexpat) before 2.4.3, an integer overflow exists for m_groupSize. CVE-2021-46143 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:expat-2.7.1-21.43.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libexpat1-2.7.1-21.43.1 important 6.8 AV:N/AC:M/Au:N/C:P/I:P/A:P In the Linux kernel, the following vulnerability has been resolved: USB: usbfs: Don't WARN about excessively large memory allocations Syzbot found that the kernel generates a WARNing if the user tries to submit a bulk transfer through usbfs with a buffer that is way too large. This isn't a bug in the kernel; it's merely an invalid request from the user and the usbfs code does handle it correctly. In theory the same thing can happen with async transfers, or with the packet descriptor table for isochronous transfers. To prevent the MM subsystem from complaining about these bad allocation requests, add the __GFP_NOWARN flag to the kmalloc calls for these buffers. CVE-2021-47170 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ath5k: fix OOB in ath5k_eeprom_read_pcal_info_5111 The bug was found during fuzzing. Stacktrace locates it in ath5k_eeprom_convert_pcal_info_5111. When none of the curve is selected in the loop, idx can go up to AR5K_EEPROM_N_PD_CURVES. The line makes pd out of bound. pd = &chinfo[pier].pd_curves[idx]; There are many OOB writes using pd later in the code. So I added a sanity check for idx. Checks for other loops involving AR5K_EEPROM_N_PD_CURVES are not needed as the loop index is not used outside the loops. The patch is NOT tested with real device. The following is the fuzzing report BUG: KASAN: slab-out-of-bounds in ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] Write of size 1 at addr ffff8880174a4d60 by task modprobe/214 CPU: 0 PID: 214 Comm: modprobe Not tainted 5.6.0 #1 Call Trace: dump_stack+0x76/0xa0 print_address_description.constprop.0+0x16/0x200 ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] __kasan_report.cold+0x37/0x7c ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] kasan_report+0xe/0x20 ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] ? apic_timer_interrupt+0xa/0x20 ? ath5k_eeprom_init_11a_pcal_freq+0xbc0/0xbc0 [ath5k] ? ath5k_pci_eeprom_read+0x228/0x3c0 [ath5k] ath5k_eeprom_init+0x2513/0x6290 [ath5k] ? ath5k_eeprom_init_11a_pcal_freq+0xbc0/0xbc0 [ath5k] ? usleep_range+0xb8/0x100 ? apic_timer_interrupt+0xa/0x20 ? ath5k_eeprom_read_pcal_info_2413+0x2f20/0x2f20 [ath5k] ath5k_hw_init+0xb60/0x1970 [ath5k] ath5k_init_ah+0x6fe/0x2530 [ath5k] ? kasprintf+0xa6/0xe0 ? ath5k_stop+0x140/0x140 [ath5k] ? _dev_notice+0xf6/0xf6 ? apic_timer_interrupt+0xa/0x20 ath5k_pci_probe.cold+0x29a/0x3d6 [ath5k] ? ath5k_pci_eeprom_read+0x3c0/0x3c0 [ath5k] ? mutex_lock+0x89/0xd0 ? ath5k_pci_eeprom_read+0x3c0/0x3c0 [ath5k] local_pci_probe+0xd3/0x160 pci_device_probe+0x23f/0x3e0 ? pci_device_remove+0x280/0x280 ? pci_device_remove+0x280/0x280 really_probe+0x209/0x5d0 CVE-2021-47633 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 important In the Linux kernel, the following vulnerability has been resolved: media: staging: media: zoran: calculate the right buffer number for zoran_reap_stat_com On the case tmp_dcim=1, the index of buffer is miscalculated. This generate a NULL pointer dereference later. So let's fix the calcul and add a check to prevent this to reappear. CVE-2021-47645 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix a memory leak in 'host1x_remove()' Add a missing 'host1x_channel_list_free()' call in the remove function, as already done in the error handling path of the probe function. CVE-2021-47648 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: video: fbdev: smscufx: Fix null-ptr-deref in ufx_usb_probe() I got a null-ptr-deref report: BUG: kernel NULL pointer dereference, address: 0000000000000000 ... RIP: 0010:fb_destroy_modelist+0x38/0x100 ... Call Trace: ufx_usb_probe.cold+0x2b5/0xac1 [smscufx] usb_probe_interface+0x1aa/0x3c0 [usbcore] really_probe+0x167/0x460 ... ret_from_fork+0x1f/0x30 If fb_alloc_cmap() fails in ufx_usb_probe(), fb_destroy_modelist() will be called to destroy modelist in the error handling path. But modelist has not been initialized yet, so it will result in null-ptr-deref. Initialize modelist before calling fb_alloc_cmap() to fix this bug. CVE-2021-47652 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/plane: Move range check for format_count earlier While the check for format_count > 64 in __drm_universal_plane_init() shouldn't be hit (it's a WARN_ON), in its current position it will then leak the plane->format_types array and fail to call drm_mode_object_unregister() leaking the modeset identifier. Move it to the start of the function to avoid allocating those resources in the first place. CVE-2021-47659 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: can: dev: can_restart: fix use after free bug After calling netif_rx_ni(skb), dereferencing skb is unsafe. Especially, the can_frame cf which aliases skb memory is accessed after the netif_rx_ni() in: stats->rx_bytes += cf->len; Reordering the lines solves the issue. CVE-2021-47668 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: can: vxcan: vxcan_xmit: fix use after free bug After calling netif_rx_ni(skb), dereferencing skb is unsafe. Especially, the canfd_frame cfd which aliases skb memory is accessed after the netif_rx_ni(). CVE-2021-47669 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: can: peak_usb: fix use after free bugs After calling peak_usb_netif_rx_ni(skb), dereferencing skb is unsafe. Especially, the can_frame cf which aliases skb memory is accessed after the peak_usb_netif_rx_ni(). Reordering the lines solves the issue. CVE-2021-47670 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate A flaw was found in the Linux kernel in net/netfilter/nf_tables_core.c:nft_do_chain, which can cause a use-after-free. This issue needs to handle 'return' with proper preconditions, as it can lead to a kernel information leak problem caused by a local, unprivileged attacker. CVE-2022-1016 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate A use-after-free flaw was found in the Linux kernel's sound subsystem in the way a user triggers concurrent calls of PCM hw_params. The hw_free ioctls or similar race condition happens inside ALSA PCM for other ioctls. This flaw allows a local user to crash or potentially escalate their privileges on the system. CVE-2022-1048 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 important 6.9 AV:L/AC:M/Au:N/C:C/I:C/A:C A use-after-free flaw was found in fs/ext4/namei.c:dx_insert_block() in the Linux kernel's filesystem sub-component. This flaw allows a local attacker with a user privilege to cause a denial of service. CVE-2022-1184 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate addBinding in xmlparse.c in Expat (aka libexpat) before 2.4.3 has an integer overflow. CVE-2022-22822 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:expat-2.7.1-21.43.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libexpat1-2.7.1-21.43.1 important 7.5 AV:N/AC:L/Au:N/C:P/I:P/A:P build_model in xmlparse.c in Expat (aka libexpat) before 2.4.3 has an integer overflow. CVE-2022-22823 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:expat-2.7.1-21.43.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libexpat1-2.7.1-21.43.1 important 7.5 AV:N/AC:L/Au:N/C:P/I:P/A:P defineAttribute in xmlparse.c in Expat (aka libexpat) before 2.4.3 has an integer overflow. CVE-2022-22824 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:expat-2.7.1-21.43.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libexpat1-2.7.1-21.43.1 important 7.5 AV:N/AC:L/Au:N/C:P/I:P/A:P lookup in xmlparse.c in Expat (aka libexpat) before 2.4.3 has an integer overflow. CVE-2022-22825 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:expat-2.7.1-21.43.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libexpat1-2.7.1-21.43.1 important 6.8 AV:N/AC:M/Au:N/C:P/I:P/A:P nextScaffoldPart in xmlparse.c in Expat (aka libexpat) before 2.4.3 has an integer overflow. CVE-2022-22826 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:expat-2.7.1-21.43.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libexpat1-2.7.1-21.43.1 important 6.8 AV:N/AC:M/Au:N/C:P/I:P/A:P storeAtts in xmlparse.c in Expat (aka libexpat) before 2.4.3 has an integer overflow. CVE-2022-22827 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:expat-2.7.1-21.43.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libexpat1-2.7.1-21.43.1 important 6.8 AV:N/AC:M/Au:N/C:P/I:P/A:P Expat (aka libexpat) before 2.4.4 has a signed integer overflow in XML_GetBuffer, for configurations with a nonzero XML_CONTEXT_BYTES. CVE-2022-23852 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:expat-2.7.1-21.43.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libexpat1-2.7.1-21.43.1 important 7.5 AV:N/AC:L/Au:N/C:P/I:P/A:P Expat (aka libexpat) before 2.4.4 has an integer overflow in the doProlog function. CVE-2022-23990 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:expat-2.7.1-21.43.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libexpat1-2.7.1-21.43.1 important 5 AV:N/AC:L/Au:N/C:N/I:N/A:P xmltok_impl.c in Expat (aka libexpat) before 2.4.5 lacks certain validation of encoding, such as checks for whether a UTF-8 character is valid in a certain context. CVE-2022-25235 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:expat-2.7.1-21.43.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libexpat1-2.7.1-21.43.1 important 7.5 AV:N/AC:L/Au:N/C:P/I:P/A:P xmlparse.c in Expat (aka libexpat) before 2.4.5 allows attackers to insert namespace-separator characters into namespace URIs. CVE-2022-25236 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:expat-2.7.1-21.43.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libexpat1-2.7.1-21.43.1 important 7.5 AV:N/AC:L/Au:N/C:P/I:P/A:P In Expat (aka libexpat) before 2.4.5, an attacker can trigger stack exhaustion in build_model via a large nesting depth in the DTD element. CVE-2022-25313 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:expat-2.7.1-21.43.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libexpat1-2.7.1-21.43.1 moderate 4.3 AV:N/AC:M/Au:N/C:N/I:N/A:P In Expat (aka libexpat) before 2.4.5, there is an integer overflow in copyString. CVE-2022-25314 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:expat-2.7.1-21.43.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libexpat1-2.7.1-21.43.1 important 5 AV:N/AC:L/Au:N/C:N/I:N/A:P In Expat (aka libexpat) before 2.4.5, there is an integer overflow in storeRawNames. CVE-2022-25315 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:expat-2.7.1-21.43.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libexpat1-2.7.1-21.43.1 important 7.5 AV:N/AC:L/Au:N/C:P/I:P/A:P Non-transparent sharing of return predictor targets between contexts in some Intel(R) Processors may allow an authorized user to potentially enable information disclosure via local access. CVE-2022-26373 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate A flaw was found in the Linux kernel implementation of proxied virtualized TPM devices. On a system where virtualized TPM devices are configured (this is not the default) a local attacker can create a use-after-free and create a situation where it may be possible to escalate privileges on the system. CVE-2022-2977 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate A race condition flaw was found in the Linux kernel sound subsystem due to improper locking. It could lead to a NULL pointer dereference while handling the SNDCTL_DSP_SYNC ioctl. A privileged local user (root or member of the audio group) could use this flaw to crash the system, resulting in a denial of service condition CVE-2022-3303 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate A vulnerability classified as critical was found in Linux Kernel. Affected by this vulnerability is the function l2cap_reassemble_sdu of the file net/bluetooth/l2cap_core.c of the component Bluetooth. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. The associated identifier of this vulnerability is VDB-211087. CVE-2022-3564 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 important libexpat before 2.4.9 has a use-after-free in the doContent function in xmlparse.c. CVE-2022-40674 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:expat-2.7.1-21.43.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libexpat1-2.7.1-21.43.1 important In libexpat through 2.4.9, there is a use-after free caused by overeager destruction of a shared DTD in XML_ExternalEntityParserCreate in out-of-memory situations. CVE-2022-43680 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:expat-2.7.1-21.43.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libexpat1-2.7.1-21.43.1 important In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: sdata can be NULL during AMPDU start ieee80211_tx_ba_session_handle_start() may get NULL for sdata when a deauthentication is ongoing. Here a trace triggering the race with the hostapd test multi_ap_fronthaul_on_ap: (gdb) list *drv_ampdu_action+0x46 0x8b16 is in drv_ampdu_action (net/mac80211/driver-ops.c:396). 391 int ret = -EOPNOTSUPP; 392 393 might_sleep(); 394 395 sdata = get_bss_sdata(sdata); 396 if (!check_sdata_in_driver(sdata)) 397 return -EIO; 398 399 trace_drv_ampdu_action(local, sdata, params); 400 wlan0: moving STA 02:00:00:00:03:00 to state 3 wlan0: associated wlan0: deauthenticating from 02:00:00:00:03:00 by local choice (Reason: 3=DEAUTH_LEAVING) wlan3.sta1: Open BA session requested for 02:00:00:00:00:00 tid 0 wlan3.sta1: dropped frame to 02:00:00:00:00:00 (unauthorized port) wlan0: moving STA 02:00:00:00:03:00 to state 2 wlan0: moving STA 02:00:00:00:03:00 to state 1 wlan0: Removed STA 02:00:00:00:03:00 wlan0: Destroyed STA 02:00:00:00:03:00 BUG: unable to handle page fault for address: fffffffffffffb48 PGD 11814067 P4D 11814067 PUD 11816067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 2 PID: 133397 Comm: kworker/u16:1 Tainted: G W 6.1.0-rc8-wt+ #59 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014 Workqueue: phy3 ieee80211_ba_session_work [mac80211] RIP: 0010:drv_ampdu_action+0x46/0x280 [mac80211] Code: 53 48 89 f3 be 89 01 00 00 e8 d6 43 bf ef e8 21 46 81 f0 83 bb a0 1b 00 00 04 75 0e 48 8b 9b 28 0d 00 00 48 81 eb 10 0e 00 00 <8b> 93 58 09 00 00 f6 c2 20 0f 84 3b 01 00 00 8b 05 dd 1c 0f 00 85 RSP: 0018:ffffc900025ebd20 EFLAGS: 00010287 RAX: 0000000000000000 RBX: fffffffffffff1f0 RCX: ffff888102228240 RDX: 0000000080000000 RSI: ffffffff918c5de0 RDI: ffff888102228b40 RBP: ffffc900025ebd40 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000001 R11: 0000000000000000 R12: ffff888118c18ec0 R13: 0000000000000000 R14: ffffc900025ebd60 R15: ffff888018b7efb8 FS: 0000000000000000(0000) GS:ffff88817a600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: fffffffffffffb48 CR3: 0000000105228006 CR4: 0000000000170ee0 Call Trace: <TASK> ieee80211_tx_ba_session_handle_start+0xd0/0x190 [mac80211] ieee80211_ba_session_work+0xff/0x2e0 [mac80211] process_one_work+0x29f/0x620 worker_thread+0x4d/0x3d0 ? process_one_work+0x620/0x620 kthread+0xfb/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 </TASK> CVE-2022-48875 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: dm integrity: fix memory corruption when tag_size is less than digest size It is possible to set up dm-integrity in such a way that the "tag_size" parameter is less than the actual digest size. In this situation, a part of the digest beyond tag_size is ignored. In this case, dm-integrity would write beyond the end of the ic->recalc_tags array and corrupt memory. The corruption happened in integrity_recalc->integrity_sector_checksum->crypto_shash_final. Fix this corruption by increasing the tags array so that it has enough padding at the end to accomodate the loop in integrity_recalc() being able to write a full digest size for the last member of the tags array. CVE-2022-49044 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: i2c: dev: check return value when calling dev_set_name() If dev_set_name() fails, the dev_name() is null, check the return value of dev_set_name() to avoid the null-ptr-deref. CVE-2022-49046 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: usb: aqc111: Fix out-of-bounds accesses in RX fixup aqc111_rx_fixup() contains several out-of-bounds accesses that can be triggered by a malicious (or defective) USB device, in particular: - The metadata array (desc_offset..desc_offset+2*pkt_count) can be out of bounds, causing OOB reads and (on big-endian systems) OOB endianness flips. - A packet can overlap the metadata array, causing a later OOB endianness flip to corrupt data used by a cloned SKB that has already been handed off into the network stack. - A packet SKB can be constructed whose tail is far beyond its end, causing out-of-bounds heap data to be considered part of the SKB's data. Found doing variant analysis. Tested it with another driver (ax88179_178a), since I don't have a aqc111 device to test it, but the code looks very similar. CVE-2022-49051 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcmu: Fix possible page UAF tcmu_try_get_data_page() looks up pages under cmdr_lock, but it does not take refcount properly and just returns page pointer. When tcmu_try_get_data_page() returns, the returned page may have been freed by tcmu_blocks_release(). We need to get_page() under cmdr_lock to avoid concurrent tcmu_blocks_release(). CVE-2022-49053 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 important In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check for potential null return of kmalloc_array() As the kmalloc_array() may return null, the 'event_waiters[i].wait' would lead to null-pointer dereference. Therefore, it is better to check the return value of kmalloc_array() to avoid this confusion. CVE-2022-49055 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: cifs: potential buffer overflow in handling symlinks Smatch printed a warning: arch/x86/crypto/poly1305_glue.c:198 poly1305_update_arch() error: __memcpy() 'dctx->buf' too small (16 vs u32max) It's caused because Smatch marks 'link_len' as untrusted since it comes from sscanf(). Add a check to ensure that 'link_len' is not larger than the size of the 'link_str' buffer. CVE-2022-49058 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: nfc: nci: add flush_workqueue to prevent uaf Our detector found a concurrent use-after-free bug when detaching an NCI device. The main reason for this bug is the unexpected scheduling between the used delayed mechanism (timer and workqueue). The race can be demonstrated below: Thread-1 Thread-2 | nci_dev_up() | nci_open_device() | __nci_request(nci_reset_req) | nci_send_cmd | queue_work(cmd_work) nci_unregister_device() | nci_close_device() | ... del_timer_sync(cmd_timer)[1] | ... | Worker nci_free_device() | nci_cmd_work() kfree(ndev)[3] | mod_timer(cmd_timer)[2] In short, the cleanup routine thought that the cmd_timer has already been detached by [1] but the mod_timer can re-attach the timer [2], even it is already released [3], resulting in UAF. This UAF is easy to trigger, crash trace by POC is like below [ 66.703713] ================================================================== [ 66.703974] BUG: KASAN: use-after-free in enqueue_timer+0x448/0x490 [ 66.703974] Write of size 8 at addr ffff888009fb7058 by task kworker/u4:1/33 [ 66.703974] [ 66.703974] CPU: 1 PID: 33 Comm: kworker/u4:1 Not tainted 5.18.0-rc2 #5 [ 66.703974] Workqueue: nfc2_nci_cmd_wq nci_cmd_work [ 66.703974] Call Trace: [ 66.703974] <TASK> [ 66.703974] dump_stack_lvl+0x57/0x7d [ 66.703974] print_report.cold+0x5e/0x5db [ 66.703974] ? enqueue_timer+0x448/0x490 [ 66.703974] kasan_report+0xbe/0x1c0 [ 66.703974] ? enqueue_timer+0x448/0x490 [ 66.703974] enqueue_timer+0x448/0x490 [ 66.703974] __mod_timer+0x5e6/0xb80 [ 66.703974] ? mark_held_locks+0x9e/0xe0 [ 66.703974] ? try_to_del_timer_sync+0xf0/0xf0 [ 66.703974] ? lockdep_hardirqs_on_prepare+0x17b/0x410 [ 66.703974] ? queue_work_on+0x61/0x80 [ 66.703974] ? lockdep_hardirqs_on+0xbf/0x130 [ 66.703974] process_one_work+0x8bb/0x1510 [ 66.703974] ? lockdep_hardirqs_on_prepare+0x410/0x410 [ 66.703974] ? pwq_dec_nr_in_flight+0x230/0x230 [ 66.703974] ? rwlock_bug.part.0+0x90/0x90 [ 66.703974] ? _raw_spin_lock_irq+0x41/0x50 [ 66.703974] worker_thread+0x575/0x1190 [ 66.703974] ? process_one_work+0x1510/0x1510 [ 66.703974] kthread+0x2a0/0x340 [ 66.703974] ? kthread_complete_and_exit+0x20/0x20 [ 66.703974] ret_from_fork+0x22/0x30 [ 66.703974] </TASK> [ 66.703974] [ 66.703974] Allocated by task 267: [ 66.703974] kasan_save_stack+0x1e/0x40 [ 66.703974] __kasan_kmalloc+0x81/0xa0 [ 66.703974] nci_allocate_device+0xd3/0x390 [ 66.703974] nfcmrvl_nci_register_dev+0x183/0x2c0 [ 66.703974] nfcmrvl_nci_uart_open+0xf2/0x1dd [ 66.703974] nci_uart_tty_ioctl+0x2c3/0x4a0 [ 66.703974] tty_ioctl+0x764/0x1310 [ 66.703974] __x64_sys_ioctl+0x122/0x190 [ 66.703974] do_syscall_64+0x3b/0x90 [ 66.703974] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 66.703974] [ 66.703974] Freed by task 406: [ 66.703974] kasan_save_stack+0x1e/0x40 [ 66.703974] kasan_set_track+0x21/0x30 [ 66.703974] kasan_set_free_info+0x20/0x30 [ 66.703974] __kasan_slab_free+0x108/0x170 [ 66.703974] kfree+0xb0/0x330 [ 66.703974] nfcmrvl_nci_unregister_dev+0x90/0xd0 [ 66.703974] nci_uart_tty_close+0xdf/0x180 [ 66.703974] tty_ldisc_kill+0x73/0x110 [ 66.703974] tty_ldisc_hangup+0x281/0x5b0 [ 66.703974] __tty_hangup.part.0+0x431/0x890 [ 66.703974] tty_release+0x3a8/0xc80 [ 66.703974] __fput+0x1f0/0x8c0 [ 66.703974] task_work_run+0xc9/0x170 [ 66.703974] exit_to_user_mode_prepare+0x194/0x1a0 [ 66.703974] syscall_exit_to_user_mode+0x19/0x50 [ 66.703974] do_syscall_64+0x48/0x90 [ 66.703974] entry_SYSCALL_64_after_hwframe+0x44/0x ---truncated--- CVE-2022-49059 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net/smc: Fix NULL pointer dereference in smc_pnet_find_ib() dev_name() was called with dev.parent as argument but without to NULL-check it before. Solve this by checking the pointer before the call to dev_name(). CVE-2022-49060 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Fix the svc_deferred_event trace class Fix a NULL deref crash that occurs when an svc_rqst is deferred while the sunrpc tracing subsystem is enabled. svc_revisit() sets dr->xprt to NULL, so it can't be relied upon in the tracepoint to provide the remote's address. Unfortunately we can't revert the "svc_deferred_class" hunk in commit ece200ddd54b ("sunrpc: Save remote presentation address in svc_xprt for trace events") because there is now a specific check of event format specifiers for unsafe dereferences. The warning that check emits is: event svc_defer_recv has unsafe dereference of argument 1 A "%pISpc" format specifier with a "struct sockaddr *" is indeed flagged by this check. Instead, take the brute-force approach used by the svcrdma_qp_error tracepoint. Convert the dr::addr field into a presentation address in the TP_fast_assign() arm of the trace event, and store that as a string. This fix can be backported to -stable kernels. In the meantime, commit c6ced22997ad ("tracing: Update print fmt check to handle new __get_sockaddr() macro") is now in v5.18, so this wonky fix can be replaced with __sockaddr() and friends properly during the v5.19 merge window. CVE-2022-49065 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: veth: Ensure eth header is in skb's linear part After feeding a decapsulated packet to a veth device with act_mirred, skb_headlen() may be 0. But veth_xmit() calls __dev_forward_skb(), which expects at least ETH_HLEN byte of linear data (as __dev_forward_skb2() calls eth_type_trans(), which pulls ETH_HLEN bytes unconditionally). Use pskb_may_pull() to ensure veth_xmit() respects this constraint. kernel BUG at include/linux/skbuff.h:2328! RIP: 0010:eth_type_trans+0xcf/0x140 Call Trace: <IRQ> __dev_forward_skb2+0xe3/0x160 veth_xmit+0x6e/0x250 [veth] dev_hard_start_xmit+0xc7/0x200 __dev_queue_xmit+0x47f/0x520 ? skb_ensure_writable+0x85/0xa0 ? skb_mpls_pop+0x98/0x1c0 tcf_mirred_act+0x442/0x47e [act_mirred] tcf_action_exec+0x86/0x140 fl_classify+0x1d8/0x1e0 [cls_flower] ? dma_pte_clear_level+0x129/0x1a0 ? dma_pte_clear_level+0x129/0x1a0 ? prb_fill_curr_block+0x2f/0xc0 ? skb_copy_bits+0x11a/0x220 __tcf_classify+0x58/0x110 tcf_classify_ingress+0x6b/0x140 __netif_receive_skb_core.constprop.0+0x47d/0xfd0 ? __iommu_dma_unmap_swiotlb+0x44/0x90 __netif_receive_skb_one_core+0x3d/0xa0 netif_receive_skb+0x116/0x170 be_process_rx+0x22f/0x330 [be2net] be_poll+0x13c/0x370 [be2net] __napi_poll+0x2a/0x170 net_rx_action+0x22f/0x2f0 __do_softirq+0xca/0x2a8 __irq_exit_rcu+0xc1/0xe0 common_interrupt+0x83/0xa0 CVE-2022-49066 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3: Fix GICR_CTLR.RWP polling It turns out that our polling of RWP is totally wrong when checking for it in the redistributors, as we test the *distributor* bit index, whereas it is a different bit number in the RDs... Oopsie boo. This is embarassing. Not only because it is wrong, but also because it took *8 years* to notice the blunder... Just fix the damn thing. CVE-2022-49074 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: btrfs: fix qgroup reserve overflow the qgroup limit We use extent_changeset->bytes_changed in qgroup_reserve_data() to record how many bytes we set for EXTENT_QGROUP_RESERVED state. Currently the bytes_changed is set as "unsigned int", and it will overflow if we try to fallocate a range larger than 4GiB. The result is we reserve less bytes and eventually break the qgroup limit. Unlike regular buffered/direct write, which we use one changeset for each ordered extent, which can never be larger than 256M. For fallocate, we use one changeset for the whole range, thus it no longer respects the 256M per extent limit, and caused the problem. The following example test script reproduces the problem: $ cat qgroup-overflow.sh #!/bin/bash DEV=/dev/sdj MNT=/mnt/sdj mkfs.btrfs -f $DEV mount $DEV $MNT # Set qgroup limit to 2GiB. btrfs quota enable $MNT btrfs qgroup limit 2G $MNT # Try to fallocate a 3GiB file. This should fail. echo echo "Try to fallocate a 3GiB file..." fallocate -l 3G $MNT/3G.file # Try to fallocate a 5GiB file. echo echo "Try to fallocate a 5GiB file..." fallocate -l 5G $MNT/5G.file # See we break the qgroup limit. echo sync btrfs qgroup show -r $MNT umount $MNT When running the test: $ ./qgroup-overflow.sh (...) Try to fallocate a 3GiB file... fallocate: fallocate failed: Disk quota exceeded Try to fallocate a 5GiB file... qgroupid rfer excl max_rfer -------- ---- ---- -------- 0/5 5.00GiB 5.00GiB 2.00GiB Since we have no control of how bytes_changed is used, it's better to set it to u64. CVE-2022-49075 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: qede: confirm skb is allocated before using qede_build_skb() assumes build_skb() always works and goes straight to skb_reserve(). However, build_skb() can fail under memory pressure. This results in a kernel panic because the skb to reserve is NULL. Add a check in case build_skb() failed to allocate and return NULL. The NULL return is handled correctly in callers to qede_build_skb(). CVE-2022-49084 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: drbd: Fix five use after free bugs in get_initial_state In get_initial_state, it calls notify_initial_state_done(skb,..) if cb->args[5]==1. If genlmsg_put() failed in notify_initial_state_done(), the skb will be freed by nlmsg_free(skb). Then get_initial_state will goto out and the freed skb will be used by return value skb->len, which is a uaf bug. What's worse, the same problem goes even further: skb can also be freed in the notify_*_state_change -> notify_*_state calls below. Thus 4 additional uaf bugs happened. My patch lets the problem callee functions: notify_initial_state_done and notify_*_state_change return an error code if errors happen. So that the error codes could be propagated and the uaf bugs can be avoid. v2 reports a compilation warning. This v3 fixed this warning and built successfully in my local environment with no additional warnings. v2: https://lore.kernel.org/patchwork/patch/1435218/ CVE-2022-49085 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix leak of nested actions While parsing user-provided actions, openvswitch module may dynamically allocate memory and store pointers in the internal copy of the actions. So this memory has to be freed while destroying the actions. Currently there are only two such actions: ct() and set(). However, there are many actions that can hold nested lists of actions and ovs_nla_free_flow_actions() just jumps over them leaking the memory. For example, removal of the flow with the following actions will lead to a leak of the memory allocated by nf_ct_tmpl_alloc(): actions:clone(ct(commit),0) Non-freed set() action may also leak the 'dst' structure for the tunnel info including device references. Under certain conditions with a high rate of flow rotation that may cause significant memory leak problem (2MB per second in reporter's case). The problem is also hard to mitigate, because the user doesn't have direct control over the datapath flows generated by OVS. Fix that by iterating over all the nested actions and freeing everything that needs to be freed recursively. New build time assertion should protect us from this problem if new actions will be added in the future. Unfortunately, openvswitch module doesn't use NLA_F_NESTED, so all attributes has to be explicitly checked. sample() and clone() actions are mixing extra attributes into the user-provided action list. That prevents some code generalization too. CVE-2022-49086 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: zorro7xx: Fix a resource leak in zorro7xx_remove_one() The error handling path of the probe releases a resource that is not freed in the remove function. In some cases, a ioremap() must be undone. Add the missing iounmap() call in the remove function. CVE-2022-49095 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Fix potential crash on module unload The vmbus driver relies on the panic notifier infrastructure to perform some operations when a panic event is detected. Since vmbus can be built as module, it is required that the driver handles both registering and unregistering such panic notifier callback. After commit 74347a99e73a ("x86/Hyper-V: Unload vmbus channel in hv panic callback") though, the panic notifier registration is done unconditionally in the module initialization routine whereas the unregistering procedure is conditionally guarded and executes only if HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE capability is set. This patch fixes that by unconditionally unregistering the panic notifier in the module's exit routine as well. CVE-2022-49098 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: virtio_console: eliminate anonymous module_init & module_exit Eliminate anonymous module_init() and module_exit(), which can lead to confusion or ambiguity when reading System.map, crashes/oops/bugs, or an initcall_debug log. Give each of these init and exit functions unique driver-specific names to eliminate the anonymous names. Example 1: (System.map) ffffffff832fc78c t init ffffffff832fc79e t init ffffffff832fc8f8 t init Example 2: (initcall_debug log) calling init+0x0/0x12 @ 1 initcall init+0x0/0x12 returned 0 after 15 usecs calling init+0x0/0x60 @ 1 initcall init+0x0/0x60 returned 0 after 2 usecs calling init+0x0/0x9a @ 1 initcall init+0x0/0x9a returned 0 after 74 usecs CVE-2022-49100 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ceph: fix memory leak in ceph_readdir when note_last_dentry returns error Reset the last_readdir at the same time, and add a comment explaining why we don't free last_readdir when dir_emit returns false. CVE-2022-49107 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ceph: fix inode reference leakage in ceph_get_snapdir() The ceph_get_inode() will search for or insert a new inode into the hash for the given vino, and return a reference to it. If new is non-NULL, its reference is consumed. We should release the reference when in error handing cases. CVE-2022-49109 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix use after free in hci_send_acl This fixes the following trace caused by receiving HCI_EV_DISCONN_PHY_LINK_COMPLETE which does call hci_conn_del without first checking if conn->type is in fact AMP_LINK and in case it is do properly cleanup upper layers with hci_disconn_cfm: ================================================================== BUG: KASAN: use-after-free in hci_send_acl+0xaba/0xc50 Read of size 8 at addr ffff88800e404818 by task bluetoothd/142 CPU: 0 PID: 142 Comm: bluetoothd Not tainted 5.17.0-rc5-00006-gda4022eeac1a #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x45/0x59 print_address_description.constprop.0+0x1f/0x150 kasan_report.cold+0x7f/0x11b hci_send_acl+0xaba/0xc50 l2cap_do_send+0x23f/0x3d0 l2cap_chan_send+0xc06/0x2cc0 l2cap_sock_sendmsg+0x201/0x2b0 sock_sendmsg+0xdc/0x110 sock_write_iter+0x20f/0x370 do_iter_readv_writev+0x343/0x690 do_iter_write+0x132/0x640 vfs_writev+0x198/0x570 do_writev+0x202/0x280 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RSP: 002b:00007ffce8a099b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014 Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 14 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10 RDX: 0000000000000001 RSI: 00007ffce8a099e0 RDI: 0000000000000015 RAX: ffffffffffffffda RBX: 00007ffce8a099e0 RCX: 00007f788fc3cf77 R10: 00007ffce8af7080 R11: 0000000000000246 R12: 000055e4ccf75580 RBP: 0000000000000015 R08: 0000000000000002 R09: 0000000000000001 </TASK> R13: 000055e4ccf754a0 R14: 000055e4ccf75cd0 R15: 000055e4ccf4a6b0 Allocated by task 45: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0x81/0xa0 hci_chan_create+0x9a/0x2f0 l2cap_conn_add.part.0+0x1a/0xdc0 l2cap_connect_cfm+0x236/0x1000 le_conn_complete_evt+0x15a7/0x1db0 hci_le_conn_complete_evt+0x226/0x2c0 hci_le_meta_evt+0x247/0x450 hci_event_packet+0x61b/0xe90 hci_rx_work+0x4d5/0xc50 process_one_work+0x8fb/0x15a0 worker_thread+0x576/0x1240 kthread+0x29d/0x340 ret_from_fork+0x1f/0x30 Freed by task 45: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_set_free_info+0x20/0x30 __kasan_slab_free+0xfb/0x130 kfree+0xac/0x350 hci_conn_cleanup+0x101/0x6a0 hci_conn_del+0x27e/0x6c0 hci_disconn_phylink_complete_evt+0xe0/0x120 hci_event_packet+0x812/0xe90 hci_rx_work+0x4d5/0xc50 process_one_work+0x8fb/0x15a0 worker_thread+0x576/0x1240 kthread+0x29d/0x340 ret_from_fork+0x1f/0x30 The buggy address belongs to the object at ffff88800c0f0500 The buggy address is located 24 bytes inside of which belongs to the cache kmalloc-128 of size 128 The buggy address belongs to the page: 128-byte region [ffff88800c0f0500, ffff88800c0f0580) flags: 0x100000000000200(slab|node=0|zone=1) page:00000000fe45cd86 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xc0f0 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 raw: 0100000000000200 ffffea00003a2c80 dead000000000004 ffff8880078418c0 page dumped because: kasan: bad access detected ffff88800c0f0400: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc Memory state around the buggy address: >ffff88800c0f0500: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88800c0f0480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88800c0f0580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ---truncated--- CVE-2022-49111 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: libfc: Fix use after free in fc_exch_abts_resp() fc_exch_release(ep) will decrease the ep's reference count. When the reference count reaches zero, it is freed. But ep is still used in the following code, which will lead to a use after free. Return after the fc_exch_release() call to avoid use after free. CVE-2022-49114 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: hisi_sas: Free irq vectors in order for v3 HW If the driver probe fails to request the channel IRQ or fatal IRQ, the driver will free the IRQ vectors before freeing the IRQs in free_irq(), and this will cause a kernel BUG like this: ------------[ cut here ]------------ kernel BUG at drivers/pci/msi.c:369! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Call trace: free_msi_irqs+0x118/0x13c pci_disable_msi+0xfc/0x120 pci_free_irq_vectors+0x24/0x3c hisi_sas_v3_probe+0x360/0x9d0 [hisi_sas_v3_hw] local_pci_probe+0x44/0xb0 work_for_cpu_fn+0x20/0x34 process_one_work+0x1d0/0x340 worker_thread+0x2e0/0x460 kthread+0x180/0x190 ret_from_fork+0x10/0x20 ---[ end trace b88990335b610c11 ]--- So we use devm_add_action() to control the order in which we free the vectors. CVE-2022-49118 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Fix memory leak in pm8001_chip_fw_flash_update_req() In pm8001_chip_fw_flash_update_build(), if pm8001_chip_fw_flash_update_build() fails, the struct fw_control_ex allocated must be freed. CVE-2022-49119 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Fix task leak in pm8001_send_abort_all() In pm8001_send_abort_all(), make sure to free the allocated sas task if pm8001_tag_alloc() or pm8001_mpi_build_cmd() fail. CVE-2022-49120 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Fix tag leaks on error In pm8001_chip_set_dev_state_req(), pm8001_chip_fw_flash_update_req(), pm80xx_chip_phy_ctl_req() and pm8001_chip_reg_dev_req() add missing calls to pm8001_tag_free() to free the allocated tag when pm8001_mpi_build_cmd() fails. Similarly, in pm8001_exec_internal_task_abort(), if the chip ->task_abort method fails, the tag allocated for the abort request task must be freed. Add the missing call to pm8001_tag_free(). CVE-2022-49121 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: dm ioctl: prevent potential spectre v1 gadget It appears like cmd could be a Spectre v1 gadget as it's supplied by a user and used as an array index. Prevent the contents of kernel memory from being leaked to userspace via speculative execution by using array_index_nospec. CVE-2022-49122 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/amd/amdgpu/amdgpu_cs: fix refcount leak of a dma_fence obj This issue takes place in an error path in amdgpu_cs_fence_to_handle_ioctl(). When `info->in.what` falls into default case, the function simply returns -EINVAL, forgetting to decrement the reference count of a dma_fence obj, which is bumped earlier by amdgpu_cs_get_fence(). This may result in reference count leaks. Fix it by decreasing the refcount of specific object before returning the error code. CVE-2022-49137 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 low In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix null ptr deref on hci_sync_conn_complete_evt This event is just specified for SCO and eSCO link types. On the reception of a HCI_Synchronous_Connection_Complete for a BDADDR of an existing LE connection, LE link type and a status that triggers the second case of the packet processing a NULL pointer dereference happens, as conn->link is NULL. CVE-2022-49139 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Avoid out of bounds access when parsing _CPC data If the NumEntries field in the _CPC return package is less than 2, do not attempt to access the "Revision" element of that package, because it may not be present then. BugLink: https://lore.kernel.org/lkml/20220322143534.GC32582@xsang-OptiPlex-9020/ CVE-2022-49145 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Suppress a kernel complaint in qla_create_qpair() [ 12.323788] BUG: using smp_processor_id() in preemptible [00000000] code: systemd-udevd/1020 [ 12.332297] caller is qla2xxx_create_qpair+0x32a/0x5d0 [qla2xxx] [ 12.338417] CPU: 7 PID: 1020 Comm: systemd-udevd Tainted: G I --------- --- 5.14.0-29.el9.x86_64 #1 [ 12.348827] Hardware name: Dell Inc. PowerEdge R610/0F0XJ6, BIOS 6.6.0 05/22/2018 [ 12.356356] Call Trace: [ 12.358821] dump_stack_lvl+0x34/0x44 [ 12.362514] check_preemption_disabled+0xd9/0xe0 [ 12.367164] qla2xxx_create_qpair+0x32a/0x5d0 [qla2xxx] [ 12.372481] qla2x00_probe_one+0xa3a/0x1b80 [qla2xxx] [ 12.377617] ? _raw_spin_lock_irqsave+0x19/0x40 [ 12.384284] local_pci_probe+0x42/0x80 [ 12.390162] ? pci_match_device+0xd7/0x110 [ 12.396366] pci_device_probe+0xfd/0x1b0 [ 12.402372] really_probe+0x1e7/0x3e0 [ 12.408114] __driver_probe_device+0xfe/0x180 [ 12.414544] driver_probe_device+0x1e/0x90 [ 12.420685] __driver_attach+0xc0/0x1c0 [ 12.426536] ? __device_attach_driver+0xe0/0xe0 [ 12.433061] ? __device_attach_driver+0xe0/0xe0 [ 12.439538] bus_for_each_dev+0x78/0xc0 [ 12.445294] bus_add_driver+0x12b/0x1e0 [ 12.451021] driver_register+0x8f/0xe0 [ 12.456631] ? 0xffffffffc07bc000 [ 12.461773] qla2x00_module_init+0x1be/0x229 [qla2xxx] [ 12.468776] do_one_initcall+0x44/0x200 [ 12.474401] ? load_module+0xad3/0xba0 [ 12.479908] ? kmem_cache_alloc_trace+0x45/0x410 [ 12.486268] do_init_module+0x5c/0x280 [ 12.491730] __do_sys_init_module+0x12e/0x1b0 [ 12.497785] do_syscall_64+0x3b/0x90 [ 12.503029] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 12.509764] RIP: 0033:0x7f554f73ab2e CVE-2022-49155 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix scheduling while atomic The driver makes a call into midlayer (fc_remote_port_delete) which can put the thread to sleep. The thread that originates the call is in interrupt context. The combination of the two trigger a crash. Schedule the call in non-interrupt context where it is more safe. kernel: BUG: scheduling while atomic: swapper/7/0/0x00010000 kernel: Call Trace: kernel: <IRQ> kernel: dump_stack+0x66/0x81 kernel: __schedule_bug.cold.90+0x5/0x1d kernel: __schedule+0x7af/0x960 kernel: schedule+0x28/0x80 kernel: schedule_timeout+0x26d/0x3b0 kernel: wait_for_completion+0xb4/0x140 kernel: ? wake_up_q+0x70/0x70 kernel: __wait_rcu_gp+0x12c/0x160 kernel: ? sdev_evt_alloc+0xc0/0x180 [scsi_mod] kernel: synchronize_sched+0x6c/0x80 kernel: ? call_rcu_bh+0x20/0x20 kernel: ? __bpf_trace_rcu_invoke_callback+0x10/0x10 kernel: sdev_evt_alloc+0xfd/0x180 [scsi_mod] kernel: starget_for_each_device+0x85/0xb0 [scsi_mod] kernel: ? scsi_init_io+0x360/0x3d0 [scsi_mod] kernel: scsi_init_io+0x388/0x3d0 [scsi_mod] kernel: device_for_each_child+0x54/0x90 kernel: fc_remote_port_delete+0x70/0xe0 [scsi_transport_fc] kernel: qla2x00_schedule_rport_del+0x62/0xf0 [qla2xxx] kernel: qla2x00_mark_device_lost+0x9c/0xd0 [qla2xxx] kernel: qla24xx_handle_plogi_done_event+0x55f/0x570 [qla2xxx] kernel: qla2x00_async_login_sp_done+0xd2/0x100 [qla2xxx] kernel: qla24xx_logio_entry+0x13a/0x3c0 [qla2xxx] kernel: qla24xx_process_response_queue+0x306/0x400 [qla2xxx] kernel: qla24xx_msix_rsp_q+0x3f/0xb0 [qla2xxx] kernel: __handle_irq_event_percpu+0x40/0x180 kernel: handle_irq_event_percpu+0x30/0x80 kernel: handle_irq_event+0x36/0x60 CVE-2022-49156 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix premature hw access after PCI error After a recoverable PCI error has been detected and recovered, qla driver needs to check to see if the error condition still persist and/or wait for the OS to give the resume signal. Sep 8 22:26:03 localhost kernel: WARNING: CPU: 9 PID: 124606 at qla_tmpl.c:440 qla27xx_fwdt_entry_t266+0x55/0x60 [qla2xxx] Sep 8 22:26:03 localhost kernel: RIP: 0010:qla27xx_fwdt_entry_t266+0x55/0x60 [qla2xxx] Sep 8 22:26:03 localhost kernel: Call Trace: Sep 8 22:26:03 localhost kernel: ? qla27xx_walk_template+0xb1/0x1b0 [qla2xxx] Sep 8 22:26:03 localhost kernel: ? qla27xx_execute_fwdt_template+0x12a/0x160 [qla2xxx] Sep 8 22:26:03 localhost kernel: ? qla27xx_fwdump+0xa0/0x1c0 [qla2xxx] Sep 8 22:26:03 localhost kernel: ? qla2xxx_pci_mmio_enabled+0xfb/0x120 [qla2xxx] Sep 8 22:26:03 localhost kernel: ? report_mmio_enabled+0x44/0x80 Sep 8 22:26:03 localhost kernel: ? report_slot_reset+0x80/0x80 Sep 8 22:26:03 localhost kernel: ? pci_walk_bus+0x70/0x90 Sep 8 22:26:03 localhost kernel: ? aer_dev_correctable_show+0xc0/0xc0 Sep 8 22:26:03 localhost kernel: ? pcie_do_recovery+0x1bb/0x240 Sep 8 22:26:03 localhost kernel: ? aer_recover_work_func+0xaa/0xd0 Sep 8 22:26:03 localhost kernel: ? process_one_work+0x1a7/0x360 .. Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-8041:22: detected PCI disconnect. Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-107ff:22: qla27xx_fwdt_entry_t262: dump ram MB failed. Area 5h start 198013h end 198013h Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-107ff:22: Unable to capture FW dump Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-1015:22: cmd=0x0, waited 5221 msecs Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-680d:22: mmio enabled returning. Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-d04c:22: MBX Command timeout for cmd 0, iocontrol=ffffffff jiffies=10140f2e5 mb[0-3]=[0xffff 0xffff 0xffff 0xffff] CVE-2022-49157 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 low In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix warning message due to adisc being flushed Fix warning message due to adisc being flushed. Linux kernel triggered a warning message where a different error code type is not matching up with the expected type. Add additional translation of one error code type to another. WARNING: CPU: 2 PID: 1131623 at drivers/scsi/qla2xxx/qla_init.c:498 qla2x00_async_adisc_sp_done+0x294/0x2b0 [qla2xxx] CPU: 2 PID: 1131623 Comm: drmgr Not tainted 5.13.0-rc1-autotest #1 .. GPR28: c000000aaa9c8890 c0080000079ab678 c00000140a104800 c00000002bd19000 NIP [c00800000790857c] qla2x00_async_adisc_sp_done+0x294/0x2b0 [qla2xxx] LR [c008000007908578] qla2x00_async_adisc_sp_done+0x290/0x2b0 [qla2xxx] Call Trace: [c00000001cdc3620] [c008000007908578] qla2x00_async_adisc_sp_done+0x290/0x2b0 [qla2xxx] (unreliable) [c00000001cdc3710] [c0080000078f3080] __qla2x00_abort_all_cmds+0x1b8/0x580 [qla2xxx] [c00000001cdc3840] [c0080000078f589c] qla2x00_abort_all_cmds+0x34/0xd0 [qla2xxx] [c00000001cdc3880] [c0080000079153d8] qla2x00_abort_isp_cleanup+0x3f0/0x570 [qla2xxx] [c00000001cdc3920] [c0080000078fb7e8] qla2x00_remove_one+0x3d0/0x480 [qla2xxx] [c00000001cdc39b0] [c00000000071c274] pci_device_remove+0x64/0x120 [c00000001cdc39f0] [c0000000007fb818] device_release_driver_internal+0x168/0x2a0 [c00000001cdc3a30] [c00000000070e304] pci_stop_bus_device+0xb4/0x100 [c00000001cdc3a70] [c00000000070e4f0] pci_stop_and_remove_bus_device+0x20/0x40 [c00000001cdc3aa0] [c000000000073940] pci_hp_remove_devices+0x90/0x130 [c00000001cdc3b30] [c0080000070704d0] disable_slot+0x38/0x90 [rpaphp] [ c00000001cdc3b60] [c00000000073eb4c] power_write_file+0xcc/0x180 [c00000001cdc3be0] [c0000000007354bc] pci_slot_attr_store+0x3c/0x60 [c00000001cdc3c00] [c00000000055f820] sysfs_kf_write+0x60/0x80 [c00000001cdc3c20] [c00000000055df10] kernfs_fop_write_iter+0x1a0/0x290 [c00000001cdc3c70] [c000000000447c4c] new_sync_write+0x14c/0x1d0 [c00000001cdc3d10] [c00000000044b134] vfs_write+0x224/0x330 [c00000001cdc3d60] [c00000000044b3f4] ksys_write+0x74/0x130 [c00000001cdc3db0] [c00000000002df70] system_call_exception+0x150/0x2d0 [c00000001cdc3e10] [c00000000000d45c] system_call_common+0xec/0x278 CVE-2022-49158 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Implement ref count for SRB The timeout handler and the done function are racing. When qla2x00_async_iocb_timeout() starts to run it can be preempted by the normal response path (via the firmware?). qla24xx_async_gpsc_sp_done() releases the SRB unconditionally. When scheduling back to qla2x00_async_iocb_timeout() qla24xx_async_abort_cmd() will access an freed sp->qpair pointer: qla2xxx [0000:83:00.0]-2871:0: Async-gpsc timeout - hdl=63d portid=234500 50:06:0e:80:08:77:b6:21. qla2xxx [0000:83:00.0]-2853:0: Async done-gpsc res 0, WWPN 50:06:0e:80:08:77:b6:21 qla2xxx [0000:83:00.0]-2854:0: Async-gpsc OUT WWPN 20:45:00:27:f8:75:33:00 speeds=2c00 speed=0400. qla2xxx [0000:83:00.0]-28d8:0: qla24xx_handle_gpsc_event 50:06:0e:80:08:77:b6:21 DS 7 LS 6 rc 0 login 1|1 rscn 1|0 lid 5 BUG: unable to handle kernel NULL pointer dereference at 0000000000000004 IP: qla24xx_async_abort_cmd+0x1b/0x1c0 [qla2xxx] Obvious solution to this is to introduce a reference counter. One reference is taken for the normal code path (the 'good' case) and one for the timeout path. As we always race between the normal good case and the timeout/abort handler we need to serialize it. Also we cannot assume any order between the handlers. Since this is slow path we can use proper synchronization via locks. When we are able to cancel a timer (del_timer returns 1) we know there can't be any error handling in progress because the timeout handler hasn't expired yet, thus we can safely decrement the refcounter by one. If we are not able to cancel the timer, we know an abort handler is running. We have to make sure we call sp->done() in the abort handlers before calling kref_put(). CVE-2022-49159 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix crash during module load unload test During purex packet handling the driver was incorrectly freeing a pre-allocated structure. Fix this by skipping that entry. System crashed with the following stack during a module unload test. Call Trace: sbitmap_init_node+0x7f/0x1e0 sbitmap_queue_init_node+0x24/0x150 blk_mq_init_bitmaps+0x3d/0xa0 blk_mq_init_tags+0x68/0x90 blk_mq_alloc_map_and_rqs+0x44/0x120 blk_mq_alloc_set_map_and_rqs+0x63/0x150 blk_mq_alloc_tag_set+0x11b/0x230 scsi_add_host_with_dma.cold+0x3f/0x245 qla2x00_probe_one+0xd5a/0x1b80 [qla2xxx] Call Trace with slub_debug and debug kernel: kasan_report_invalid_free+0x50/0x80 __kasan_slab_free+0x137/0x150 slab_free_freelist_hook+0xc6/0x190 kfree+0xe8/0x2e0 qla2x00_free_device+0x3bb/0x5d0 [qla2xxx] qla2x00_remove_one+0x668/0xcf0 [qla2xxx] CVE-2022-49160 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: powerpc/tm: Fix more userspace r13 corruption Commit cf13435b730a ("powerpc/tm: Fix userspace r13 corruption") fixes a problem in treclaim where a SLB miss can occur on the thread_struct->ckpt_regs while SCRATCH0 is live with the saved user r13 value, clobbering it with the kernel r13 and ultimately resulting in kernel r13 being stored in ckpt_regs. There is an equivalent problem in trechkpt where the user r13 value is loaded into r13 from chkpt_regs to be recheckpointed, but a SLB miss could occur on ckpt_regs accesses after that, which will result in r13 being clobbered with a kernel value and that will get recheckpointed and then restored to user registers. The same memory page is accessed right before this critical window where a SLB miss could cause corruption, so hitting the bug requires the SLB entry be removed within a small window of instructions, which is possible if a SLB related MCE hits there. PAPR also permits the hypervisor to discard this SLB entry (because slb_shadow->persistent is only set to SLB_NUM_BOLTED) although it's not known whether any implementations would do this (KVM does not). So this is an extremely unlikely bug, only found by inspection. Fix this by also storing user r13 in a temporary location on the kernel stack and don't change the r13 register from kernel r13 until the RI=0 critical section that does not fault. The SCRATCH0 change is not strictly part of the fix, it's only used in the RI=0 section so it does not have the same problem as the previous SCRATCH0 bug. CVE-2022-49164 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: btrfs: do not clean up repair bio if submit fails The submit helper will always run bio_endio() on the bio if it fails to submit, so cleaning up the bio just leads to a variety of use-after-free and NULL pointer dereference bugs because we race with the endio function that is cleaning up the bio. Instead just return BLK_STS_OK as the repair function has to continue to process the rest of the pages, and the endio for the repair bio will do the appropriate cleanup for the page that it was given. CVE-2022-49168 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ext4: don't BUG if someone dirty pages without asking ext4 first [un]pin_user_pages_remote is dirtying pages without properly warning the file system in advance. A related race was noted by Jan Kara in 2018[1]; however, more recently instead of it being a very hard-to-hit race, it could be reliably triggered by process_vm_writev(2) which was discovered by Syzbot[2]. This is technically a bug in mm/gup.c, but arguably ext4 is fragile in that if some other kernel subsystem dirty pages without properly notifying the file system using page_mkwrite(), ext4 will BUG, while other file systems will not BUG (although data will still be lost). So instead of crashing with a BUG, issue a warning (since there may be potential data loss) and just mark the page as clean to avoid unprivileged denial of service attacks until the problem can be properly fixed. More discussion and background can be found in the thread starting at [2]. [1] https://lore.kernel.org/linux-mm/20180103100430.GE4911@quack2.suse.cz [2] https://lore.kernel.org/r/Yg0m6IjcNmfaSokM@google.com CVE-2022-49171 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: PM: core: keep irq flags in device_pm_check_callbacks() The function device_pm_check_callbacks() can be called under the spin lock (in the reported case it happens from genpd_add_device() -> dev_pm_domain_set(), when the genpd uses spinlocks rather than mutexes. However this function uncoditionally uses spin_lock_irq() / spin_unlock_irq(), thus not preserving the CPU flags. Use the irqsave/irqrestore instead. The backtrace for the reference: [ 2.752010] ------------[ cut here ]------------ [ 2.756769] raw_local_irq_restore() called with IRQs enabled [ 2.762596] WARNING: CPU: 4 PID: 1 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x34/0x50 [ 2.772338] Modules linked in: [ 2.775487] CPU: 4 PID: 1 Comm: swapper/0 Tainted: G S 5.17.0-rc6-00384-ge330d0d82eff-dirty #684 [ 2.781384] Freeing initrd memory: 46024K [ 2.785839] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2.785841] pc : warn_bogus_irq_restore+0x34/0x50 [ 2.785844] lr : warn_bogus_irq_restore+0x34/0x50 [ 2.785846] sp : ffff80000805b7d0 [ 2.785847] x29: ffff80000805b7d0 x28: 0000000000000000 x27: 0000000000000002 [ 2.785850] x26: ffffd40e80930b18 x25: ffff7ee2329192b8 x24: ffff7edfc9f60800 [ 2.785853] x23: ffffd40e80930b18 x22: ffffd40e80930d30 x21: ffff7edfc0dffa00 [ 2.785856] x20: ffff7edfc09e3768 x19: 0000000000000000 x18: ffffffffffffffff [ 2.845775] x17: 6572206f74206465 x16: 6c696166203a3030 x15: ffff80008805b4f7 [ 2.853108] x14: 0000000000000000 x13: ffffd40e809550b0 x12: 00000000000003d8 [ 2.860441] x11: 0000000000000148 x10: ffffd40e809550b0 x9 : ffffd40e809550b0 [ 2.867774] x8 : 00000000ffffefff x7 : ffffd40e809ad0b0 x6 : ffffd40e809ad0b0 [ 2.875107] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.882440] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff7edfc03a8000 [ 2.889774] Call trace: [ 2.892290] warn_bogus_irq_restore+0x34/0x50 [ 2.896770] _raw_spin_unlock_irqrestore+0x94/0xa0 [ 2.901690] genpd_unlock_spin+0x20/0x30 [ 2.905724] genpd_add_device+0x100/0x2d0 [ 2.909850] __genpd_dev_pm_attach+0xa8/0x23c [ 2.914329] genpd_dev_pm_attach_by_id+0xc4/0x190 [ 2.919167] genpd_dev_pm_attach_by_name+0x3c/0xd0 [ 2.924086] dev_pm_domain_attach_by_name+0x24/0x30 [ 2.929102] psci_dt_attach_cpu+0x24/0x90 [ 2.933230] psci_cpuidle_probe+0x2d4/0x46c [ 2.937534] platform_probe+0x68/0xe0 [ 2.941304] really_probe.part.0+0x9c/0x2fc [ 2.945605] __driver_probe_device+0x98/0x144 [ 2.950085] driver_probe_device+0x44/0x15c [ 2.954385] __device_attach_driver+0xb8/0x120 [ 2.958950] bus_for_each_drv+0x78/0xd0 [ 2.962896] __device_attach+0xd8/0x180 [ 2.966843] device_initial_probe+0x14/0x20 [ 2.971144] bus_probe_device+0x9c/0xa4 [ 2.975092] device_add+0x380/0x88c [ 2.978679] platform_device_add+0x114/0x234 [ 2.983067] platform_device_register_full+0x100/0x190 [ 2.988344] psci_idle_init+0x6c/0xb0 [ 2.992113] do_one_initcall+0x74/0x3a0 [ 2.996060] kernel_init_freeable+0x2fc/0x384 [ 3.000543] kernel_init+0x28/0x130 [ 3.004132] ret_from_fork+0x10/0x20 [ 3.007817] irq event stamp: 319826 [ 3.011404] hardirqs last enabled at (319825): [<ffffd40e7eda0268>] __up_console_sem+0x78/0x84 [ 3.020332] hardirqs last disabled at (319826): [<ffffd40e7fd6d9d8>] el1_dbg+0x24/0x8c [ 3.028458] softirqs last enabled at (318312): [<ffffd40e7ec90410>] _stext+0x410/0x588 [ 3.036678] softirqs last disabled at (318299): [<ffffd40e7ed1bf68>] __irq_exit_rcu+0x158/0x174 [ 3.045607] ---[ end trace 0000000000000000 ]--- CVE-2022-49175 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: bfq: fix use-after-free in bfq_dispatch_request KASAN reports a use-after-free report when doing normal scsi-mq test [69832.239032] ================================================================== [69832.241810] BUG: KASAN: use-after-free in bfq_dispatch_request+0x1045/0x44b0 [69832.243267] Read of size 8 at addr ffff88802622ba88 by task kworker/3:1H/155 [69832.244656] [69832.245007] CPU: 3 PID: 155 Comm: kworker/3:1H Not tainted 5.10.0-10295-g576c6382529e #8 [69832.246626] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [69832.249069] Workqueue: kblockd blk_mq_run_work_fn [69832.250022] Call Trace: [69832.250541] dump_stack+0x9b/0xce [69832.251232] ? bfq_dispatch_request+0x1045/0x44b0 [69832.252243] print_address_description.constprop.6+0x3e/0x60 [69832.253381] ? __cpuidle_text_end+0x5/0x5 [69832.254211] ? vprintk_func+0x6b/0x120 [69832.254994] ? bfq_dispatch_request+0x1045/0x44b0 [69832.255952] ? bfq_dispatch_request+0x1045/0x44b0 [69832.256914] kasan_report.cold.9+0x22/0x3a [69832.257753] ? bfq_dispatch_request+0x1045/0x44b0 [69832.258755] check_memory_region+0x1c1/0x1e0 [69832.260248] bfq_dispatch_request+0x1045/0x44b0 [69832.261181] ? bfq_bfqq_expire+0x2440/0x2440 [69832.262032] ? blk_mq_delay_run_hw_queues+0xf9/0x170 [69832.263022] __blk_mq_do_dispatch_sched+0x52f/0x830 [69832.264011] ? blk_mq_sched_request_inserted+0x100/0x100 [69832.265101] __blk_mq_sched_dispatch_requests+0x398/0x4f0 [69832.266206] ? blk_mq_do_dispatch_ctx+0x570/0x570 [69832.267147] ? __switch_to+0x5f4/0xee0 [69832.267898] blk_mq_sched_dispatch_requests+0xdf/0x140 [69832.268946] __blk_mq_run_hw_queue+0xc0/0x270 [69832.269840] blk_mq_run_work_fn+0x51/0x60 [69832.278170] process_one_work+0x6d4/0xfe0 [69832.278984] worker_thread+0x91/0xc80 [69832.279726] ? __kthread_parkme+0xb0/0x110 [69832.280554] ? process_one_work+0xfe0/0xfe0 [69832.281414] kthread+0x32d/0x3f0 [69832.282082] ? kthread_park+0x170/0x170 [69832.282849] ret_from_fork+0x1f/0x30 [69832.283573] [69832.283886] Allocated by task 7725: [69832.284599] kasan_save_stack+0x19/0x40 [69832.285385] __kasan_kmalloc.constprop.2+0xc1/0xd0 [69832.286350] kmem_cache_alloc_node+0x13f/0x460 [69832.287237] bfq_get_queue+0x3d4/0x1140 [69832.287993] bfq_get_bfqq_handle_split+0x103/0x510 [69832.289015] bfq_init_rq+0x337/0x2d50 [69832.289749] bfq_insert_requests+0x304/0x4e10 [69832.290634] blk_mq_sched_insert_requests+0x13e/0x390 [69832.291629] blk_mq_flush_plug_list+0x4b4/0x760 [69832.292538] blk_flush_plug_list+0x2c5/0x480 [69832.293392] io_schedule_prepare+0xb2/0xd0 [69832.294209] io_schedule_timeout+0x13/0x80 [69832.295014] wait_for_common_io.constprop.1+0x13c/0x270 [69832.296137] submit_bio_wait+0x103/0x1a0 [69832.296932] blkdev_issue_discard+0xe6/0x160 [69832.297794] blk_ioctl_discard+0x219/0x290 [69832.298614] blkdev_common_ioctl+0x50a/0x1750 [69832.304715] blkdev_ioctl+0x470/0x600 [69832.305474] block_ioctl+0xde/0x120 [69832.306232] vfs_ioctl+0x6c/0xc0 [69832.306877] __se_sys_ioctl+0x90/0xa0 [69832.307629] do_syscall_64+0x2d/0x40 [69832.308362] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [69832.309382] [69832.309701] Freed by task 155: [69832.310328] kasan_save_stack+0x19/0x40 [69832.311121] kasan_set_track+0x1c/0x30 [69832.311868] kasan_set_free_info+0x1b/0x30 [69832.312699] __kasan_slab_free+0x111/0x160 [69832.313524] kmem_cache_free+0x94/0x460 [69832.314367] bfq_put_queue+0x582/0x940 [69832.315112] __bfq_bfqd_reset_in_service+0x166/0x1d0 [69832.317275] bfq_bfqq_expire+0xb27/0x2440 [69832.318084] bfq_dispatch_request+0x697/0x44b0 [69832.318991] __blk_mq_do_dispatch_sched+0x52f/0x830 [69832.319984] __blk_mq_sched_dispatch_requests+0x398/0x4f0 [69832.321087] blk_mq_sched_dispatch_requests+0xdf/0x140 [69832.322225] __blk_mq_run_hw_queue+0xc0/0x270 [69832.323114] blk_mq_run_work_fn+0x51/0x6 ---truncated--- CVE-2022-49176 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: block, bfq: don't move oom_bfqq Our test report a UAF: [ 2073.019181] ================================================================== [ 2073.019188] BUG: KASAN: use-after-free in __bfq_put_async_bfqq+0xa0/0x168 [ 2073.019191] Write of size 8 at addr ffff8000ccf64128 by task rmmod/72584 [ 2073.019192] [ 2073.019196] CPU: 0 PID: 72584 Comm: rmmod Kdump: loaded Not tainted 4.19.90-yk #5 [ 2073.019198] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 2073.019200] Call trace: [ 2073.019203] dump_backtrace+0x0/0x310 [ 2073.019206] show_stack+0x28/0x38 [ 2073.019210] dump_stack+0xec/0x15c [ 2073.019216] print_address_description+0x68/0x2d0 [ 2073.019220] kasan_report+0x238/0x2f0 [ 2073.019224] __asan_store8+0x88/0xb0 [ 2073.019229] __bfq_put_async_bfqq+0xa0/0x168 [ 2073.019233] bfq_put_async_queues+0xbc/0x208 [ 2073.019236] bfq_pd_offline+0x178/0x238 [ 2073.019240] blkcg_deactivate_policy+0x1f0/0x420 [ 2073.019244] bfq_exit_queue+0x128/0x178 [ 2073.019249] blk_mq_exit_sched+0x12c/0x160 [ 2073.019252] elevator_exit+0xc8/0xd0 [ 2073.019256] blk_exit_queue+0x50/0x88 [ 2073.019259] blk_cleanup_queue+0x228/0x3d8 [ 2073.019267] null_del_dev+0xfc/0x1e0 [null_blk] [ 2073.019274] null_exit+0x90/0x114 [null_blk] [ 2073.019278] __arm64_sys_delete_module+0x358/0x5a0 [ 2073.019282] el0_svc_common+0xc8/0x320 [ 2073.019287] el0_svc_handler+0xf8/0x160 [ 2073.019290] el0_svc+0x10/0x218 [ 2073.019291] [ 2073.019294] Allocated by task 14163: [ 2073.019301] kasan_kmalloc+0xe0/0x190 [ 2073.019305] kmem_cache_alloc_node_trace+0x1cc/0x418 [ 2073.019308] bfq_pd_alloc+0x54/0x118 [ 2073.019313] blkcg_activate_policy+0x250/0x460 [ 2073.019317] bfq_create_group_hierarchy+0x38/0x110 [ 2073.019321] bfq_init_queue+0x6d0/0x948 [ 2073.019325] blk_mq_init_sched+0x1d8/0x390 [ 2073.019330] elevator_switch_mq+0x88/0x170 [ 2073.019334] elevator_switch+0x140/0x270 [ 2073.019338] elv_iosched_store+0x1a4/0x2a0 [ 2073.019342] queue_attr_store+0x90/0xe0 [ 2073.019348] sysfs_kf_write+0xa8/0xe8 [ 2073.019351] kernfs_fop_write+0x1f8/0x378 [ 2073.019359] __vfs_write+0xe0/0x360 [ 2073.019363] vfs_write+0xf0/0x270 [ 2073.019367] ksys_write+0xdc/0x1b8 [ 2073.019371] __arm64_sys_write+0x50/0x60 [ 2073.019375] el0_svc_common+0xc8/0x320 [ 2073.019380] el0_svc_handler+0xf8/0x160 [ 2073.019383] el0_svc+0x10/0x218 [ 2073.019385] [ 2073.019387] Freed by task 72584: [ 2073.019391] __kasan_slab_free+0x120/0x228 [ 2073.019394] kasan_slab_free+0x10/0x18 [ 2073.019397] kfree+0x94/0x368 [ 2073.019400] bfqg_put+0x64/0xb0 [ 2073.019404] bfqg_and_blkg_put+0x90/0xb0 [ 2073.019408] bfq_put_queue+0x220/0x228 [ 2073.019413] __bfq_put_async_bfqq+0x98/0x168 [ 2073.019416] bfq_put_async_queues+0xbc/0x208 [ 2073.019420] bfq_pd_offline+0x178/0x238 [ 2073.019424] blkcg_deactivate_policy+0x1f0/0x420 [ 2073.019429] bfq_exit_queue+0x128/0x178 [ 2073.019433] blk_mq_exit_sched+0x12c/0x160 [ 2073.019437] elevator_exit+0xc8/0xd0 [ 2073.019440] blk_exit_queue+0x50/0x88 [ 2073.019443] blk_cleanup_queue+0x228/0x3d8 [ 2073.019451] null_del_dev+0xfc/0x1e0 [null_blk] [ 2073.019459] null_exit+0x90/0x114 [null_blk] [ 2073.019462] __arm64_sys_delete_module+0x358/0x5a0 [ 2073.019467] el0_svc_common+0xc8/0x320 [ 2073.019471] el0_svc_handler+0xf8/0x160 [ 2073.019474] el0_svc+0x10/0x218 [ 2073.019475] [ 2073.019479] The buggy address belongs to the object at ffff8000ccf63f00 which belongs to the cache kmalloc-1024 of size 1024 [ 2073.019484] The buggy address is located 552 bytes inside of 1024-byte region [ffff8000ccf63f00, ffff8000ccf64300) [ 2073.019486] The buggy address belongs to the page: [ 2073.019492] page:ffff7e000333d800 count:1 mapcount:0 mapping:ffff8000c0003a00 index:0x0 compound_mapcount: 0 [ 2073.020123] flags: 0x7ffff0000008100(slab|head) [ 2073.020403] raw: 07ffff0000008100 ffff7e0003334c08 ffff7e00001f5a08 ffff8000c0003a00 [ 2073.020409] ra ---truncated--- CVE-2022-49179 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: remoteproc: qcom_q6v5_mss: Fix some leaks in q6v5_alloc_memory_region The device_node pointer is returned by of_parse_phandle() or of_get_child_by_name() with refcount incremented. We should use of_node_put() on it when done. This function only call of_node_put(node) when of_address_to_resource succeeds, missing error cases. CVE-2022-49188 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: kernel/resource: fix kfree() of bootmem memory again Since commit ebff7d8f270d ("mem hotunplug: fix kfree() of bootmem memory"), we could get a resource allocated during boot via alloc_resource(). And it's required to release the resource using free_resource(). Howerver, many people use kfree directly which will result in kernel BUG. In order to fix this without fixing every call site, just leak a couple of bytes in such corner case. CVE-2022-49190 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: mxser: fix xmit_buf leak in activate when LSR == 0xff When LSR is 0xff in ->activate() (rather unlike), we return an error. Provided ->shutdown() is not called when ->activate() fails, nothing actually frees the buffer in this case. Fix this by properly freeing the buffer in a designated label. We jump there also from the "!info->type" if now too. CVE-2022-49191 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Fix use after free in remove_phb_dynamic() In remove_phb_dynamic() we use &phb->io_resource, after we've called device_unregister(&host_bridge->dev). But the unregister may have freed phb, because pcibios_free_controller_deferred() is the release function for the host_bridge. If there are no outstanding references when we call device_unregister() then phb will be freed out from under us. This has gone mainly unnoticed, but with slub_debug and page_poison enabled it can lead to a crash: PID: 7574 TASK: c0000000d492cb80 CPU: 13 COMMAND: "drmgr" #0 [c0000000e4f075a0] crash_kexec at c00000000027d7dc #1 [c0000000e4f075d0] oops_end at c000000000029608 #2 [c0000000e4f07650] __bad_page_fault at c0000000000904b4 #3 [c0000000e4f076c0] do_bad_slb_fault at c00000000009a5a8 #4 [c0000000e4f076f0] data_access_slb_common_virt at c000000000008b30 Data SLB Access [380] exception frame: R0: c000000000167250 R1: c0000000e4f07a00 R2: c000000002a46100 R3: c000000002b39ce8 R4: 00000000000000c0 R5: 00000000000000a9 R6: 3894674d000000c0 R7: 0000000000000000 R8: 00000000000000ff R9: 0000000000000100 R10: 6b6b6b6b6b6b6b6b R11: 0000000000008000 R12: c00000000023da80 R13: c0000009ffd38b00 R14: 0000000000000000 R15: 000000011c87f0f0 R16: 0000000000000006 R17: 0000000000000003 R18: 0000000000000002 R19: 0000000000000004 R20: 0000000000000005 R21: 000000011c87ede8 R22: 000000011c87c5a8 R23: 000000011c87d3a0 R24: 0000000000000000 R25: 0000000000000001 R26: c0000000e4f07cc8 R27: c00000004d1cc400 R28: c0080000031d00e8 R29: c00000004d23d800 R30: c00000004d1d2400 R31: c00000004d1d2540 NIP: c000000000167258 MSR: 8000000000009033 OR3: c000000000e9f474 CTR: 0000000000000000 LR: c000000000167250 XER: 0000000020040003 CCR: 0000000024088420 MQ: 0000000000000000 DAR: 6b6b6b6b6b6b6ba3 DSISR: c0000000e4f07920 Syscall Result: fffffffffffffff2 [NIP : release_resource+56] [LR : release_resource+48] #5 [c0000000e4f07a00] release_resource at c000000000167258 (unreliable) #6 [c0000000e4f07a30] remove_phb_dynamic at c000000000105648 #7 [c0000000e4f07ab0] dlpar_remove_slot at c0080000031a09e8 [rpadlpar_io] #8 [c0000000e4f07b50] remove_slot_store at c0080000031a0b9c [rpadlpar_io] #9 [c0000000e4f07be0] kobj_attr_store at c000000000817d8c #10 [c0000000e4f07c00] sysfs_kf_write at c00000000063e504 #11 [c0000000e4f07c20] kernfs_fop_write_iter at c00000000063d868 #12 [c0000000e4f07c70] new_sync_write at c00000000054339c #13 [c0000000e4f07d10] vfs_write at c000000000546624 #14 [c0000000e4f07d60] ksys_write at c0000000005469f4 #15 [c0000000e4f07db0] system_call_exception at c000000000030840 #16 [c0000000e4f07e10] system_call_vectored_common at c00000000000c168 To avoid it, we can take a reference to the host_bridge->dev until we're done using phb. Then when we drop the reference the phb will be freed. CVE-2022-49196 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: af_netlink: Fix shift out of bounds in group mask calculation When a netlink message is received, netlink_recvmsg() fills in the address of the sender. One of the fields is the 32-bit bitfield nl_groups, which carries the multicast group on which the message was received. The least significant bit corresponds to group 1, and therefore the highest group that the field can represent is 32. Above that, the UB sanitizer flags the out-of-bounds shift attempts. Which bits end up being set in such case is implementation defined, but it's either going to be a wrong non-zero value, or zero, which is at least not misleading. Make the latter choice deterministic by always setting to 0 for higher-numbered multicast groups. To get information about membership in groups >= 32, userspace is expected to use nl_pktinfo control messages[0], which are enabled by NETLINK_PKTINFO socket option. [0] https://lwn.net/Articles/147608/ The way to trigger this issue is e.g. through monitoring the BRVLAN group: # bridge monitor vlan & # ip link add name br type bridge Which produces the following citation: UBSAN: shift-out-of-bounds in net/netlink/af_netlink.c:162:19 shift exponent 32 is too large for 32-bit type 'int' CVE-2022-49197 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix double uncharge the mem of sk_msg If tcp_bpf_sendmsg is running during a tear down operation, psock may be freed. tcp_bpf_sendmsg() tcp_bpf_send_verdict() sk_msg_return() tcp_bpf_sendmsg_redir() unlikely(!psock)) sk_msg_free() The mem of msg has been uncharged in tcp_bpf_send_verdict() by sk_msg_return(), and would be uncharged by sk_msg_free() again. When psock is null, we can simply returning an error code, this would then trigger the sk_msg_free_nocharge in the error path of __SK_REDIRECT and would have the side effect of throwing an error up to user space. This would be a slight change in behavior from user side but would look the same as an error if the redirect on the socket threw an error. This issue can cause the following info: WARNING: CPU: 0 PID: 2136 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260 Call Trace: <TASK> __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 worker_thread+0x30/0x350 ? process_one_work+0x3c0/0x3c0 kthread+0xe6/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 </TASK> CVE-2022-49205 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is full If tcp_bpf_sendmsg() is running while sk msg is full. When sk_msg_alloc() returns -ENOMEM error, tcp_bpf_sendmsg() goes to wait_for_memory. If partial memory has been alloced by sk_msg_alloc(), that is, msg_tx->sg.size is greater than osize after sk_msg_alloc(), memleak occurs. To fix we use sk_msg_trim() to release the allocated memory, then goto wait for memory. Other call paths of sk_msg_alloc() have the similar issue, such as tls_sw_sendmsg(), so handle sk_msg_trim logic inside sk_msg_alloc(), as Cong Wang suggested. This issue can cause the following info: WARNING: CPU: 3 PID: 7950 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0 Call Trace: <TASK> inet_csk_destroy_sock+0x55/0x110 __tcp_close+0x279/0x470 tcp_close+0x1f/0x60 inet_release+0x3f/0x80 __sock_release+0x3d/0xb0 sock_close+0x11/0x20 __fput+0x92/0x250 task_work_run+0x6a/0xa0 do_exit+0x33b/0xb60 do_group_exit+0x2f/0xa0 get_signal+0xb6/0x950 arch_do_signal_or_restart+0xac/0x2a0 exit_to_user_mode_prepare+0xa9/0x200 syscall_exit_to_user_mode+0x12/0x30 do_syscall_64+0x46/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae </TASK> WARNING: CPU: 3 PID: 2094 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260 Call Trace: <TASK> __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 kthread+0xe6/0x110 ret_from_fork+0x22/0x30 </TASK> CVE-2022-49209 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: atmel: fix refcount issue in atmel_nand_controller_init The reference counting issue happens in several error handling paths on a refcounted object "nc->dmac". In these paths, the function simply returns the error code, forgetting to balance the reference count of "nc->dmac", increased earlier by dma_request_channel(), which may cause refcount leaks. Fix it by decrementing the refcount of specific object in those error paths. CVE-2022-49212 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Fix reference leak in tegra_dsi_ganged_probe The reference taken by 'of_find_device_by_node()' must be released when not needed anymore. Add put_device() call to fix this. CVE-2022-49216 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Fix abort all task initialization In pm80xx_send_abort_all(), the n_elem field of the ccb used is not initialized to 0. This missing initialization sometimes lead to the task completion path seeing the ccb with a non-zero n_elem resulting in the execution of invalid dma_unmap_sg() calls in pm8001_ccb_task_free(), causing a crash such as: [ 197.676341] RIP: 0010:iommu_dma_unmap_sg+0x6d/0x280 [ 197.700204] RSP: 0018:ffff889bbcf89c88 EFLAGS: 00010012 [ 197.705485] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff83d0bda0 [ 197.712687] RDX: 0000000000000002 RSI: 0000000000000000 RDI: ffff88810dffc0d0 [ 197.719887] RBP: 0000000000000000 R08: 0000000000000000 R09: ffff8881c790098b [ 197.727089] R10: ffffed1038f20131 R11: 0000000000000001 R12: 0000000000000000 [ 197.734296] R13: ffff88810dffc0d0 R14: 0000000000000010 R15: 0000000000000000 [ 197.741493] FS: 0000000000000000(0000) GS:ffff889bbcf80000(0000) knlGS:0000000000000000 [ 197.749659] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 197.755459] CR2: 00007f16c1b42734 CR3: 0000000004814000 CR4: 0000000000350ee0 [ 197.762656] Call Trace: [ 197.765127] <IRQ> [ 197.767162] pm8001_ccb_task_free+0x5f1/0x820 [pm80xx] [ 197.772364] ? do_raw_spin_unlock+0x54/0x220 [ 197.776680] pm8001_mpi_task_abort_resp+0x2ce/0x4f0 [pm80xx] [ 197.782406] process_oq+0xe85/0x7890 [pm80xx] [ 197.786817] ? lock_acquire+0x194/0x490 [ 197.790697] ? handle_irq_event+0x10e/0x1b0 [ 197.794920] ? mpi_sata_completion+0x2d70/0x2d70 [pm80xx] [ 197.800378] ? __wake_up_bit+0x100/0x100 [ 197.804340] ? lock_is_held_type+0x98/0x110 [ 197.808565] pm80xx_chip_isr+0x94/0x130 [pm80xx] [ 197.813243] tasklet_action_common.constprop.0+0x24b/0x2f0 [ 197.818785] __do_softirq+0x1b5/0x82d [ 197.822485] ? do_raw_spin_unlock+0x54/0x220 [ 197.826799] __irq_exit_rcu+0x17e/0x1e0 [ 197.830678] irq_exit_rcu+0xa/0x20 [ 197.834114] common_interrupt+0x78/0x90 [ 197.840051] </IRQ> [ 197.844236] <TASK> [ 197.848397] asm_common_interrupt+0x1e/0x40 Avoid this issue by always initializing the ccb n_elem field to 0 in pm8001_send_abort_all(), pm8001_send_read_log() and pm80xx_send_abort_all(). CVE-2022-49217 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: dax: make sure inodes are flushed before destroy cache A bug can be triggered by following command $ modprobe nd_pmem && modprobe -r nd_pmem [ 10.060014] BUG dax_cache (Not tainted): Objects remaining in dax_cache on __kmem_cache_shutdown() [ 10.060938] Slab 0x0000000085b729ac objects=9 used=1 fp=0x000000004f5ae469 flags=0x200000000010200(slab|head|node) [ 10.062433] Call Trace: [ 10.062673] dump_stack_lvl+0x34/0x44 [ 10.062865] slab_err+0x90/0xd0 [ 10.063619] __kmem_cache_shutdown+0x13b/0x2f0 [ 10.063848] kmem_cache_destroy+0x4a/0x110 [ 10.064058] __x64_sys_delete_module+0x265/0x300 This is caused by dax_fs_exit() not flushing inodes before destroy cache. To fix this issue, call rcu_barrier() before destroy cache. CVE-2022-49220 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: asix: add proper error handling of usb read errors Syzbot once again hit uninit value in asix driver. The problem still the same -- asix_read_cmd() reads less bytes, than was requested by caller. Since all read requests are performed via asix_read_cmd() let's catch usb related error there and add __must_check notation to be sure all callers actually check return value. So, this patch adds sanity check inside asix_read_cmd(), that simply checks if bytes read are not less, than was requested and adds missing error handling of asix_read_cmd() all across the driver code. CVE-2022-49226 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix a NULL pointer dereference in amdgpu_dm_connector_add_common_modes() In amdgpu_dm_connector_add_common_modes(), amdgpu_dm_create_common_mode() is assigned to mode and is passed to drm_mode_probed_add() directly after that. drm_mode_probed_add() passes &mode->head to list_add_tail(), and there is a dereference of it in list_add_tail() without recoveries, which could lead to NULL pointer dereference on failure of amdgpu_dm_create_common_mode(). Fix this by adding a NULL check of mode. This bug was found by a static analyzer. Builds with 'make allyesconfig' show no new warnings, and our static analyzer no longer warns about this code. CVE-2022-49232 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ath9k_htc: fix uninit value bugs Syzbot reported 2 KMSAN bugs in ath9k. All of them are caused by missing field initialization. In htc_connect_service() svc_meta_len and pad are not initialized. Based on code it looks like in current skb there is no service data, so simply initialize svc_meta_len to 0. htc_issue_send() does not initialize htc_frame_hdr::control array. Based on firmware code, it will initialize it by itself, so simply zero whole array to make KMSAN happy Fail logs: BUG: KMSAN: kernel-usb-infoleak in usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 hif_usb_send_regout drivers/net/wireless/ath/ath9k/hif_usb.c:127 [inline] hif_usb_send+0x5f0/0x16f0 drivers/net/wireless/ath/ath9k/hif_usb.c:479 htc_issue_send drivers/net/wireless/ath/ath9k/htc_hst.c:34 [inline] htc_connect_service+0x143e/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:275 ... Uninit was created at: slab_post_alloc_hook mm/slab.h:524 [inline] slab_alloc_node mm/slub.c:3251 [inline] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974 kmalloc_reserve net/core/skbuff.c:354 [inline] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1126 [inline] htc_connect_service+0x1029/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:258 ... Bytes 4-7 of 18 are uninitialized Memory access of size 18 starts at ffff888027377e00 BUG: KMSAN: kernel-usb-infoleak in usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 hif_usb_send_regout drivers/net/wireless/ath/ath9k/hif_usb.c:127 [inline] hif_usb_send+0x5f0/0x16f0 drivers/net/wireless/ath/ath9k/hif_usb.c:479 htc_issue_send drivers/net/wireless/ath/ath9k/htc_hst.c:34 [inline] htc_connect_service+0x143e/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:275 ... Uninit was created at: slab_post_alloc_hook mm/slab.h:524 [inline] slab_alloc_node mm/slub.c:3251 [inline] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974 kmalloc_reserve net/core/skbuff.c:354 [inline] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1126 [inline] htc_connect_service+0x1029/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:258 ... Bytes 16-17 of 18 are uninitialized Memory access of size 18 starts at ffff888027377e00 CVE-2022-49235 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-lib: fix uninitialized flag for AV/C deferred transaction AV/C deferred transaction was supported at a commit 00a7bb81c20f ("ALSA: firewire-lib: Add support for deferred transaction") while 'deferrable' flag can be uninitialized for non-control/notify AV/C transactions. UBSAN reports it: kernel: ================================================================================ kernel: UBSAN: invalid-load in /build/linux-aa0B4d/linux-5.15.0/sound/firewire/fcp.c:363:9 kernel: load of value 158 is not a valid value for type '_Bool' kernel: CPU: 3 PID: 182227 Comm: irq/35-firewire Tainted: P OE 5.15.0-18-generic #18-Ubuntu kernel: Hardware name: Gigabyte Technology Co., Ltd. AX370-Gaming 5/AX370-Gaming 5, BIOS F42b 08/01/2019 kernel: Call Trace: kernel: <IRQ> kernel: show_stack+0x52/0x58 kernel: dump_stack_lvl+0x4a/0x5f kernel: dump_stack+0x10/0x12 kernel: ubsan_epilogue+0x9/0x45 kernel: __ubsan_handle_load_invalid_value.cold+0x44/0x49 kernel: fcp_response.part.0.cold+0x1a/0x2b [snd_firewire_lib] kernel: fcp_response+0x28/0x30 [snd_firewire_lib] kernel: fw_core_handle_request+0x230/0x3d0 [firewire_core] kernel: handle_ar_packet+0x1d9/0x200 [firewire_ohci] kernel: ? handle_ar_packet+0x1d9/0x200 [firewire_ohci] kernel: ? transmit_complete_callback+0x9f/0x120 [firewire_core] kernel: ar_context_tasklet+0xa8/0x2e0 [firewire_ohci] kernel: tasklet_action_common.constprop.0+0xea/0xf0 kernel: tasklet_action+0x22/0x30 kernel: __do_softirq+0xd9/0x2e3 kernel: ? irq_finalize_oneshot.part.0+0xf0/0xf0 kernel: do_softirq+0x75/0xa0 kernel: </IRQ> kernel: <TASK> kernel: __local_bh_enable_ip+0x50/0x60 kernel: irq_forced_thread_fn+0x7e/0x90 kernel: irq_thread+0xba/0x190 kernel: ? irq_thread_fn+0x60/0x60 kernel: kthread+0x11e/0x140 kernel: ? irq_thread_check_affinity+0xf0/0xf0 kernel: ? set_kthread_struct+0x50/0x50 kernel: ret_from_fork+0x22/0x30 kernel: </TASK> kernel: ================================================================================ This commit fixes the bug. The bug has no disadvantage for the non- control/notify AV/C transactions since the flag has an effect for AV/C response with INTERIM (0x0f) status which is not used for the transactions in AV/C general specification. CVE-2022-49248 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: usb: go7007: s2250-board: fix leak in probe() Call i2c_unregister_device(audio) on this error path. CVE-2022-49253 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: block: don't delete queue kobject before its children kobjects aren't supposed to be deleted before their child kobjects are deleted. Apparently this is usually benign; however, a WARN will be triggered if one of the child kobjects has a named attribute group: sysfs group 'modes' not found for kobject 'crypto' WARNING: CPU: 0 PID: 1 at fs/sysfs/group.c:278 sysfs_remove_group+0x72/0x80 ... Call Trace: sysfs_remove_groups+0x29/0x40 fs/sysfs/group.c:312 __kobject_del+0x20/0x80 lib/kobject.c:611 kobject_cleanup+0xa4/0x140 lib/kobject.c:696 kobject_release lib/kobject.c:736 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x53/0x70 lib/kobject.c:753 blk_crypto_sysfs_unregister+0x10/0x20 block/blk-crypto-sysfs.c:159 blk_unregister_queue+0xb0/0x110 block/blk-sysfs.c:962 del_gendisk+0x117/0x250 block/genhd.c:610 Fix this by moving the kobject_del() and the corresponding kobject_uevent() to the correct place. CVE-2022-49259 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: exec: Force single empty string when argv is empty Quoting[1] Ariadne Conill: "In several other operating systems, it is a hard requirement that the second argument to execve(2) be the name of a program, thus prohibiting a scenario where argc < 1. POSIX 2017 also recommends this behaviour, but it is not an explicit requirement[2]: The argument arg0 should point to a filename string that is associated with the process being started by one of the exec functions. ... Interestingly, Michael Kerrisk opened an issue about this in 2008[3], but there was no consensus to support fixing this issue then. Hopefully now that CVE-2021-4034 shows practical exploitative use[4] of this bug in a shellcode, we can reconsider. This issue is being tracked in the KSPP issue tracker[5]." While the initial code searches[6][7] turned up what appeared to be mostly corner case tests, trying to that just reject argv == NULL (or an immediately terminated pointer list) quickly started tripping[8] existing userspace programs. The next best approach is forcing a single empty string into argv and adjusting argc to match. The number of programs depending on argc == 0 seems a smaller set than those calling execve with a NULL argv. Account for the additional stack space in bprm_stack_limits(). Inject an empty string when argc == 0 (and set argc = 1). Warn about the case so userspace has some notice about the change: process './argc0' launched './argc0' with NULL argv: empty string added Additionally WARN() and reject NULL argv usage for kernel threads. [1] https://lore.kernel.org/lkml/20220127000724.15106-1-ariadne@dereferenced.org/ [2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html [3] https://bugzilla.kernel.org/show_bug.cgi?id=8408 [4] https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt [5] https://github.com/KSPP/linux/issues/176 [6] https://codesearch.debian.net/search?q=execve%5C+*%5C%28%5B%5E%2C%5D%2B%2C+*NULL&literal=0 [7] https://codesearch.debian.net/search?q=execlp%3F%5Cs*%5C%28%5B%5E%2C%5D%2B%2C%5Cs*NULL&literal=0 [8] https://lore.kernel.org/lkml/20220131144352.GE16385@xsang-OptiPlex-9020/ CVE-2022-49264 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: cifs: prevent bad output lengths in smb2_ioctl_query_info() When calling smb2_ioctl_query_info() with smb_query_info::flags=PASSTHRU_FSCTL and smb_query_info::output_buffer_length=0, the following would return 0x10 buffer = memdup_user(arg + sizeof(struct smb_query_info), qi.output_buffer_length); if (IS_ERR(buffer)) { kfree(vars); return PTR_ERR(buffer); } rather than a valid pointer thus making IS_ERR() check fail. This would then cause a NULL ptr deference in @buffer when accessing it later in smb2_ioctl_query_ioctl(). While at it, prevent having a @buffer smaller than 8 bytes to correctly handle SMB2_SET_INFO FileEndOfFileInformation requests when smb_query_info::flags=PASSTHRU_SET_INFO. Here is a small C reproducer which triggers a NULL ptr in @buffer when passing an invalid smb_query_info::flags #include <stdio.h> #include <stdlib.h> #include <stdint.h> #include <unistd.h> #include <fcntl.h> #include <sys/ioctl.h> #define die(s) perror(s), exit(1) #define QUERY_INFO 0xc018cf07 int main(int argc, char *argv[]) { int fd; if (argc < 2) exit(1); fd = open(argv[1], O_RDONLY); if (fd == -1) die("open"); if (ioctl(fd, QUERY_INFO, (uint32_t[]) { 0, 0, 0, 4, 0, 0}) == -1) die("ioctl"); close(fd); return 0; } mount.cifs //srv/share /mnt -o ... gcc repro.c && ./a.out /mnt/f0 [ 114.138620] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI [ 114.139310] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] [ 114.139775] CPU: 2 PID: 995 Comm: a.out Not tainted 5.17.0-rc8 #1 [ 114.140148] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014 [ 114.140818] RIP: 0010:smb2_ioctl_query_info+0x206/0x410 [cifs] [ 114.141221] Code: 00 00 00 00 fc ff df 48 c1 ea 03 80 3c 02 00 0f 85 c8 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 7b 28 4c 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 9c 01 00 00 49 8b 3f e8 58 02 fb ff 48 8b 14 24 [ 114.142348] RSP: 0018:ffffc90000b47b00 EFLAGS: 00010256 [ 114.142692] RAX: dffffc0000000000 RBX: ffff888115503200 RCX: ffffffffa020580d [ 114.143119] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffffa043a380 [ 114.143544] RBP: ffff888115503278 R08: 0000000000000001 R09: 0000000000000003 [ 114.143983] R10: fffffbfff4087470 R11: 0000000000000001 R12: ffff888115503288 [ 114.144424] R13: 00000000ffffffea R14: ffff888115503228 R15: 0000000000000000 [ 114.144852] FS: 00007f7aeabdf740(0000) GS:ffff888151600000(0000) knlGS:0000000000000000 [ 114.145338] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 114.145692] CR2: 00007f7aeacfdf5e CR3: 000000012000e000 CR4: 0000000000350ee0 [ 114.146131] Call Trace: [ 114.146291] <TASK> [ 114.146432] ? smb2_query_reparse_tag+0x890/0x890 [cifs] [ 114.146800] ? cifs_mapchar+0x460/0x460 [cifs] [ 114.147121] ? rcu_read_lock_sched_held+0x3f/0x70 [ 114.147412] ? cifs_strndup_to_utf16+0x15b/0x250 [cifs] [ 114.147775] ? dentry_path_raw+0xa6/0xf0 [ 114.148024] ? cifs_convert_path_to_utf16+0x198/0x220 [cifs] [ 114.148413] ? smb2_check_message+0x1080/0x1080 [cifs] [ 114.148766] ? rcu_read_lock_sched_held+0x3f/0x70 [ 114.149065] cifs_ioctl+0x1577/0x3320 [cifs] [ 114.149371] ? lock_downgrade+0x6f0/0x6f0 [ 114.149631] ? cifs_readdir+0x2e60/0x2e60 [cifs] [ 114.149956] ? rcu_read_lock_sched_held+0x3f/0x70 [ 114.150250] ? __rseq_handle_notify_resume+0x80b/0xbe0 [ 114.150562] ? __up_read+0x192/0x710 [ 114.150791] ? __ia32_sys_rseq+0xf0/0xf0 [ 114.151025] ? __x64_sys_openat+0x11f/0x1d0 [ 114.151296] __x64_sys_ioctl+0x127/0x190 [ 114.151549] do_syscall_64+0x3b/0x90 [ 114.151768] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 114.152079] RIP: 0033:0x7f7aead043df [ 114.152306] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 ---truncated--- CVE-2022-49271 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: can: m_can: m_can_tx_handler(): fix use after free of skb can_put_echo_skb() will clone skb then free the skb. Move the can_put_echo_skb() for the m_can version 3.0.x directly before the start of the xmit in hardware, similar to the 3.1.x branch. CVE-2022-49275 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 important In the Linux kernel, the following vulnerability has been resolved: NFSD: prevent underflow in nfssvc_decode_writeargs() Smatch complains: fs/nfsd/nfsxdr.c:341 nfssvc_decode_writeargs() warn: no lower bound on 'args->len' Change the type to unsigned to prevent this issue. CVE-2022-49280 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: cifs: fix handlecache and multiuser In multiuser each individual user has their own tcon structure for the share and thus their own handle for a cached directory. When we umount such a share we much make sure to release the pinned down dentry for each such tcon and not just the master tcon. Otherwise we will get nasty warnings on umount that dentries are still in use: [ 3459.590047] BUG: Dentry 00000000115c6f41{i=12000000019d95,n=/} still in use\ (2) [unmount of cifs cifs] ... [ 3459.590492] Call Trace: [ 3459.590500] d_walk+0x61/0x2a0 [ 3459.590518] ? shrink_lock_dentry.part.0+0xe0/0xe0 [ 3459.590526] shrink_dcache_for_umount+0x49/0x110 [ 3459.590535] generic_shutdown_super+0x1a/0x110 [ 3459.590542] kill_anon_super+0x14/0x30 [ 3459.590549] cifs_kill_sb+0xf5/0x104 [cifs] [ 3459.590773] deactivate_locked_super+0x36/0xa0 [ 3459.590782] cleanup_mnt+0x131/0x190 [ 3459.590789] task_work_run+0x5c/0x90 [ 3459.590798] exit_to_user_mode_loop+0x151/0x160 [ 3459.590809] exit_to_user_mode_prepare+0x83/0xd0 [ 3459.590818] syscall_exit_to_user_mode+0x12/0x30 [ 3459.590828] do_syscall_64+0x48/0x90 [ 3459.590833] entry_SYSCALL_64_after_hwframe+0x44/0xae CVE-2022-49281 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: tpm: use try_get_ops() in tpm-space.c As part of the series conversion to remove nested TPM operations: https://lore.kernel.org/all/20190205224723.19671-1-jarkko.sakkinen@linux.intel.com/ exposure of the chip->tpm_mutex was removed from much of the upper level code. In this conversion, tpm2_del_space() was missed. This didn't matter much because it's usually called closely after a converted operation, so there's only a very tiny race window where the chip can be removed before the space flushing is done which causes a NULL deref on the mutex. However, there are reports of this window being hit in practice, so fix this by converting tpm2_del_space() to use tpm_try_get_ops(), which performs all the teardown checks before acquring the mutex. CVE-2022-49286 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: mac80211: fix potential double free on mesh join While commit 6a01afcf8468 ("mac80211: mesh: Free ie data when leaving mesh") fixed a memory leak on mesh leave / teardown it introduced a potential memory corruption caused by a double free when rejoining the mesh: ieee80211_leave_mesh() -> kfree(sdata->u.mesh.ie); ... ieee80211_join_mesh() -> copy_mesh_setup() -> old_ie = ifmsh->ie; -> kfree(old_ie); This double free / kernel panics can be reproduced by using wpa_supplicant with an encrypted mesh (if set up without encryption via "iw" then ifmsh->ie is always NULL, which avoids this issue). And then calling: $ iw dev mesh0 mesh leave $ iw dev mesh0 mesh join my-mesh Note that typically these commands are not used / working when using wpa_supplicant. And it seems that wpa_supplicant or wpa_cli are going through a NETDEV_DOWN/NETDEV_UP cycle between a mesh leave and mesh join where the NETDEV_UP resets the mesh.ie to NULL via a memcpy of default_mesh_setup in cfg80211_netdev_notifier_call, which then avoids the memory corruption, too. The issue was first observed in an application which was not using wpa_supplicant but "Senf" instead, which implements its own calls to nl80211. Fixing the issue by removing the kfree()'ing of the mesh IE in the mesh join function and leaving it solely up to the mesh leave to free the mesh IE. CVE-2022-49290 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ALSA: oss: Fix PCM OSS buffer allocation overflow We've got syzbot reports hitting INT_MAX overflow at vmalloc() allocation that is called from snd_pcm_plug_alloc(). Although we apply the restrictions to input parameters, it's based only on the hw_params of the underlying PCM device. Since the PCM OSS layer allocates a temporary buffer for the data conversion, the size may become unexpectedly large when more channels or higher rates is given; in the reported case, it went over INT_MAX, hence it hits WARN_ON(). This patch is an attempt to avoid such an overflow and an allocation for too large buffers. First off, it adds the limit of 1MB as the upper bound for period bytes. This must be large enough for all use cases, and we really don't want to handle a larger temporary buffer than this size. The size check is performed at two places, where the original period bytes is calculated and where the plugin buffer size is calculated. In addition, the driver uses array_size() and array3_size() for multiplications to catch overflows for the converted period size and buffer bytes. CVE-2022-49292 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: nbd: call genl_unregister_family() first in nbd_cleanup() Otherwise there may be race between module removal and the handling of netlink command, which can lead to the oops as shown below: BUG: kernel NULL pointer dereference, address: 0000000000000098 Oops: 0002 [#1] SMP PTI CPU: 1 PID: 31299 Comm: nbd-client Tainted: G E 5.14.0-rc4 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:down_write+0x1a/0x50 Call Trace: start_creating+0x89/0x130 debugfs_create_dir+0x1b/0x130 nbd_start_device+0x13d/0x390 [nbd] nbd_genl_connect+0x42f/0x748 [nbd] genl_family_rcv_msg_doit.isra.0+0xec/0x150 genl_rcv_msg+0xe5/0x1e0 netlink_rcv_skb+0x55/0x100 genl_rcv+0x29/0x40 netlink_unicast+0x1a8/0x250 netlink_sendmsg+0x21b/0x430 ____sys_sendmsg+0x2a4/0x2d0 ___sys_sendmsg+0x81/0xc0 __sys_sendmsg+0x62/0xb0 __x64_sys_sendmsg+0x1f/0x30 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae Modules linked in: nbd(E-) CVE-2022-49295 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: nbd: fix io hung while disconnecting device In our tests, "qemu-nbd" triggers a io hung: INFO: task qemu-nbd:11445 blocked for more than 368 seconds. Not tainted 5.18.0-rc3-next-20220422-00003-g2176915513ca #884 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:qemu-nbd state:D stack: 0 pid:11445 ppid: 1 flags:0x00000000 Call Trace: <TASK> __schedule+0x480/0x1050 ? _raw_spin_lock_irqsave+0x3e/0xb0 schedule+0x9c/0x1b0 blk_mq_freeze_queue_wait+0x9d/0xf0 ? ipi_rseq+0x70/0x70 blk_mq_freeze_queue+0x2b/0x40 nbd_add_socket+0x6b/0x270 [nbd] nbd_ioctl+0x383/0x510 [nbd] blkdev_ioctl+0x18e/0x3e0 __x64_sys_ioctl+0xac/0x120 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fd8ff706577 RSP: 002b:00007fd8fcdfebf8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000040000000 RCX: 00007fd8ff706577 RDX: 000000000000000d RSI: 000000000000ab00 RDI: 000000000000000f RBP: 000000000000000f R08: 000000000000fbe8 R09: 000055fe497c62b0 R10: 00000002aff20000 R11: 0000000000000246 R12: 000000000000006d R13: 0000000000000000 R14: 00007ffe82dc5e70 R15: 00007fd8fcdff9c0 "qemu-ndb -d" will call ioctl 'NBD_DISCONNECT' first, however, following message was found: block nbd0: Send disconnect failed -32 Which indicate that something is wrong with the server. Then, "qemu-nbd -d" will call ioctl 'NBD_CLEAR_SOCK', however ioctl can't clear requests after commit 2516ab1543fd("nbd: only clear the queue on device teardown"). And in the meantime, request can't complete through timeout because nbd_xmit_timeout() will always return 'BLK_EH_RESET_TIMER', which means such request will never be completed in this situation. Now that the flag 'NBD_CMD_INFLIGHT' can make sure requests won't complete multiple times, switch back to call nbd_clear_sock() in nbd_clear_sock_ioctl(), so that inflight requests can be cleared. CVE-2022-49297 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: nbd: fix race between nbd_alloc_config() and module removal When nbd module is being removing, nbd_alloc_config() may be called concurrently by nbd_genl_connect(), although try_module_get() will return false, but nbd_alloc_config() doesn't handle it. The race may lead to the leak of nbd_config and its related resources (e.g, recv_workq) and oops in nbd_read_stat() due to the unload of nbd module as shown below: BUG: kernel NULL pointer dereference, address: 0000000000000040 Oops: 0000 [#1] SMP PTI CPU: 5 PID: 13840 Comm: kworker/u17:33 Not tainted 5.14.0+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Workqueue: knbd16-recv recv_work [nbd] RIP: 0010:nbd_read_stat.cold+0x130/0x1a4 [nbd] Call Trace: recv_work+0x3b/0xb0 [nbd] process_one_work+0x1ed/0x390 worker_thread+0x4a/0x3d0 kthread+0x12a/0x150 ret_from_fork+0x22/0x30 Fixing it by checking the return value of try_module_get() in nbd_alloc_config(). As nbd_alloc_config() may return ERR_PTR(-ENODEV), assign nbd->config only when nbd_alloc_config() succeeds to ensure the value of nbd->config is binary (valid or NULL). Also adding a debug message to check the reference counter of nbd_config during module removal. CVE-2022-49300 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: drivers: staging: rtl8192u: Fix deadlock in ieee80211_beacons_stop() There is a deadlock in ieee80211_beacons_stop(), which is shown below: (Thread 1) | (Thread 2) | ieee80211_send_beacon() ieee80211_beacons_stop() | mod_timer() spin_lock_irqsave() //(1) | (wait a time) ... | ieee80211_send_beacon_cb() del_timer_sync() | spin_lock_irqsave() //(2) (wait timer to stop) | ... We hold ieee->beacon_lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need ieee->beacon_lock in position (2) of thread 2. As a result, ieee80211_beacons_stop() will block forever. This patch extracts del_timer_sync() from the protection of spin_lock_irqsave(), which could let timer handler to obtain the needed lock. CVE-2022-49305 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: extcon: Modify extcon device to be created after driver data is set Currently, someone can invoke the sysfs such as state_show() intermittently before dev_set_drvdata() is done. And it can be a cause of kernel Oops because of edev is Null at that time. So modified the driver registration to after setting drviver data. - Oops's backtrace. Backtrace: [<c067865c>] (state_show) from [<c05222e8>] (dev_attr_show) [<c05222c0>] (dev_attr_show) from [<c02c66e0>] (sysfs_kf_seq_show) [<c02c6648>] (sysfs_kf_seq_show) from [<c02c496c>] (kernfs_seq_show) [<c02c4938>] (kernfs_seq_show) from [<c025e2a0>] (seq_read) [<c025e11c>] (seq_read) from [<c02c50a0>] (kernfs_fop_read) [<c02c5064>] (kernfs_fop_read) from [<c0231cac>] (__vfs_read) [<c0231c5c>] (__vfs_read) from [<c0231ee0>] (vfs_read) [<c0231e34>] (vfs_read) from [<c0232464>] (ksys_read) [<c02323f0>] (ksys_read) from [<c02324fc>] (sys_read) [<c02324e4>] (sys_read) from [<c00091d0>] (__sys_trace_return) CVE-2022-49308 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: drivers: usb: host: Fix deadlock in oxu_bus_suspend() There is a deadlock in oxu_bus_suspend(), which is shown below: (Thread 1) | (Thread 2) | timer_action() oxu_bus_suspend() | mod_timer() spin_lock_irq() //(1) | (wait a time) ... | oxu_watchdog() del_timer_sync() | spin_lock_irq() //(2) (wait timer to stop) | ... We hold oxu->lock in position (1) of thread 1, and use del_timer_sync() to wait timer to stop, but timer handler also need oxu->lock in position (2) of thread 2. As a result, oxu_bus_suspend() will block forever. This patch extracts del_timer_sync() from the protection of spin_lock_irq(), which could let timer handler to obtain the needed lock. CVE-2022-49313 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: dmaengine: zynqmp_dma: In struct zynqmp_dma_chan fix desc_size data type In zynqmp_dma_alloc/free_chan_resources functions there is a potential overflow in the below expressions. dma_alloc_coherent(chan->dev, (2 * chan->desc_size * ZYNQMP_DMA_NUM_DESCS), &chan->desc_pool_p, GFP_KERNEL); dma_free_coherent(chan->dev,(2 * ZYNQMP_DMA_DESC_SIZE(chan) * ZYNQMP_DMA_NUM_DESCS), chan->desc_pool_v, chan->desc_pool_p); The arguments desc_size and ZYNQMP_DMA_NUM_DESCS were 32 bit. Though this overflow condition is not observed but it is a potential problem in the case of 32-bit multiplication. Hence fix it by changing the desc_size data type to size_t. In addition to coverity fix it also reuse ZYNQMP_DMA_DESC_SIZE macro in dma_alloc_coherent API argument. Addresses-Coverity: Event overflow_before_widen. CVE-2022-49320 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: xprtrdma: treat all calls not a bcall when bc_serv is NULL When a rdma server returns a fault format reply, nfs v3 client may treats it as a bcall when bc service is not exist. The debug message at rpcrdma_bc_receive_call are, [56579.837169] RPC: rpcrdma_bc_receive_call: callback XID 00000001, length=20 [56579.837174] RPC: rpcrdma_bc_receive_call: 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 After that, rpcrdma_bc_receive_call will meets NULL pointer as, [ 226.057890] BUG: unable to handle kernel NULL pointer dereference at 00000000000000c8 ... [ 226.058704] RIP: 0010:_raw_spin_lock+0xc/0x20 ... [ 226.059732] Call Trace: [ 226.059878] rpcrdma_bc_receive_call+0x138/0x327 [rpcrdma] [ 226.060011] __ib_process_cq+0x89/0x170 [ib_core] [ 226.060092] ib_cq_poll_work+0x26/0x80 [ib_core] [ 226.060257] process_one_work+0x1a7/0x360 [ 226.060367] ? create_worker+0x1a0/0x1a0 [ 226.060440] worker_thread+0x30/0x390 [ 226.060500] ? create_worker+0x1a0/0x1a0 [ 226.060574] kthread+0x116/0x130 [ 226.060661] ? kthread_flush_work_fn+0x10/0x10 [ 226.060724] ret_from_fork+0x35/0x40 ... CVE-2022-49321 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: tracing: Fix sleeping function called from invalid context on RT kernel When setting bootparams="trace_event=initcall:initcall_start tp_printk=1" in the cmdline, the output_printk() was called, and the spin_lock_irqsave() was called in the atomic and irq disable interrupt context suitation. On the PREEMPT_RT kernel, these locks are replaced with sleepable rt-spinlock, so the stack calltrace will be triggered. Fix it by raw_spin_lock_irqsave when PREEMPT_RT and "trace_event=initcall:initcall_start tp_printk=1" enabled. BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0 preempt_count: 2, expected: 0 RCU nest depth: 0, expected: 0 Preemption disabled at: [<ffffffff8992303e>] try_to_wake_up+0x7e/0xba0 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.17.1-rt17+ #19 34c5812404187a875f32bee7977f7367f9679ea7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x60/0x8c dump_stack+0x10/0x12 __might_resched.cold+0x11d/0x155 rt_spin_lock+0x40/0x70 trace_event_buffer_commit+0x2fa/0x4c0 ? map_vsyscall+0x93/0x93 trace_event_raw_event_initcall_start+0xbe/0x110 ? perf_trace_initcall_finish+0x210/0x210 ? probe_sched_wakeup+0x34/0x40 ? ttwu_do_wakeup+0xda/0x310 ? trace_hardirqs_on+0x35/0x170 ? map_vsyscall+0x93/0x93 do_one_initcall+0x217/0x3c0 ? trace_event_raw_event_initcall_level+0x170/0x170 ? push_cpu_stop+0x400/0x400 ? cblist_init_generic+0x241/0x290 kernel_init_freeable+0x1ac/0x347 ? _raw_spin_unlock_irq+0x65/0x80 ? rest_init+0xf0/0xf0 kernel_init+0x1e/0x150 ret_from_fork+0x22/0x30 </TASK> CVE-2022-49322 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: tcp: add accessors to read/set tp->snd_cwnd We had various bugs over the years with code breaking the assumption that tp->snd_cwnd is greater than zero. Lately, syzbot reported the WARN_ON_ONCE(!tp->prior_cwnd) added in commit 8b8a321ff72c ("tcp: fix zero cwnd in tcp_cwnd_reduction") can trigger, and without a repro we would have to spend considerable time finding the bug. Instead of complaining too late, we want to catch where and when tp->snd_cwnd is set to an illegal value. CVE-2022-49325 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: rtl818x: Prevent using not initialized queues Using not existing queues can panic the kernel with rtl8180/rtl8185 cards. Ignore the skb priority for those cards, they only have one tx queue. Pierre Asselin (pa@panix.com) reported the kernel crash in the Gentoo forum: https://forums.gentoo.org/viewtopic-t-1147832-postdays-0-postorder-asc-start-25.html He also confirmed that this patch fixes the issue. In summary this happened: After updating wpa_supplicant from 2.9 to 2.10 the kernel crashed with a "divide error: 0000" when connecting to an AP. Control port tx now tries to use IEEE80211_AC_VO for the priority, which wpa_supplicants starts to use in 2.10. Since only the rtl8187se part of the driver supports QoS, the priority of the skb is set to IEEE80211_AC_BE (2) by mac80211 for rtl8180/rtl8185 cards. rtl8180 is then unconditionally reading out the priority and finally crashes on drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c line 544 without this patch: idx = (ring->idx + skb_queue_len(&ring->queue)) % ring->entries "ring->entries" is zero for rtl8180/rtl8185 cards, tx_ring[2] never got initialized. CVE-2022-49326 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: tcp: fix tcp_mtup_probe_success vs wrong snd_cwnd syzbot got a new report [1] finally pointing to a very old bug, added in initial support for MTU probing. tcp_mtu_probe() has checks about starting an MTU probe if tcp_snd_cwnd(tp) >= 11. But nothing prevents tcp_snd_cwnd(tp) to be reduced later and before the MTU probe succeeds. This bug would lead to potential zero-divides. Debugging added in commit 40570375356c ("tcp: add accessors to read/set tp->snd_cwnd") has paid off :) While we are at it, address potential overflows in this code. [1] WARNING: CPU: 1 PID: 14132 at include/net/tcp.h:1219 tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712 Modules linked in: CPU: 1 PID: 14132 Comm: syz-executor.2 Not tainted 5.18.0-syzkaller-07857-gbabf0bb978e3 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:tcp_snd_cwnd_set include/net/tcp.h:1219 [inline] RIP: 0010:tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712 Code: 74 08 48 89 ef e8 da 80 17 f9 48 8b 45 00 65 48 ff 80 80 03 00 00 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 aa b0 c5 f8 <0f> 0b e9 16 fe ff ff 48 8b 4c 24 08 80 e1 07 38 c1 0f 8c c7 fc ff RSP: 0018:ffffc900079e70f8 EFLAGS: 00010287 RAX: ffffffff88c0f7f6 RBX: ffff8880756e7a80 RCX: 0000000000040000 RDX: ffffc9000c6c4000 RSI: 0000000000031f9e RDI: 0000000000031f9f RBP: 0000000000000000 R08: ffffffff88c0f606 R09: ffffc900079e7520 R10: ffffed101011226d R11: 1ffff1101011226c R12: 1ffff1100eadcf50 R13: ffff8880756e72c0 R14: 1ffff1100eadcf89 R15: dffffc0000000000 FS: 00007f643236e700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1ab3f1e2a0 CR3: 0000000064fe7000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> tcp_clean_rtx_queue+0x223a/0x2da0 net/ipv4/tcp_input.c:3356 tcp_ack+0x1962/0x3c90 net/ipv4/tcp_input.c:3861 tcp_rcv_established+0x7c8/0x1ac0 net/ipv4/tcp_input.c:5973 tcp_v6_do_rcv+0x57b/0x1210 net/ipv6/tcp_ipv6.c:1476 sk_backlog_rcv include/net/sock.h:1061 [inline] __release_sock+0x1d8/0x4c0 net/core/sock.c:2849 release_sock+0x5d/0x1c0 net/core/sock.c:3404 sk_stream_wait_memory+0x700/0xdc0 net/core/stream.c:145 tcp_sendmsg_locked+0x111d/0x3fc0 net/ipv4/tcp.c:1410 tcp_sendmsg+0x2c/0x40 net/ipv4/tcp.c:1448 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] __sys_sendto+0x439/0x5c0 net/socket.c:2119 __do_sys_sendto net/socket.c:2131 [inline] __se_sys_sendto net/socket.c:2127 [inline] __x64_sys_sendto+0xda/0xf0 net/socket.c:2127 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f6431289109 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 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f643236e168 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f643139c100 RCX: 00007f6431289109 RDX: 00000000d0d0c2ac RSI: 0000000020000080 RDI: 000000000000000a RBP: 00007f64312e308d R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fff372533af R14: 00007f643236e300 R15: 0000000000022000 CVE-2022-49330 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: nfc: st21nfca: fix memory leaks in EVT_TRANSACTION handling Error paths do not free previously allocated memory. Add devm_kfree() to those failure paths. CVE-2022-49331 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Address NULL pointer dereference after starget_to_rport() Calls to starget_to_rport() may return NULL. Add check for NULL rport before dereference. CVE-2022-49332 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/cs: make commands with 0 chunks illegal behaviour. Submitting a cs with 0 chunks, causes an oops later, found trying to execute the wrong userspace driver. MESA_LOADER_DRIVER_OVERRIDE=v3d glxinfo [172536.665184] BUG: kernel NULL pointer dereference, address: 00000000000001d8 [172536.665188] #PF: supervisor read access in kernel mode [172536.665189] #PF: error_code(0x0000) - not-present page [172536.665191] PGD 6712a0067 P4D 6712a0067 PUD 5af9ff067 PMD 0 [172536.665195] Oops: 0000 [#1] SMP NOPTI [172536.665197] CPU: 7 PID: 2769838 Comm: glxinfo Tainted: P O 5.10.81 #1-NixOS [172536.665199] Hardware name: To be filled by O.E.M. To be filled by O.E.M./CROSSHAIR V FORMULA-Z, BIOS 2201 03/23/2015 [172536.665272] RIP: 0010:amdgpu_cs_ioctl+0x96/0x1ce0 [amdgpu] [172536.665274] Code: 75 18 00 00 4c 8b b2 88 00 00 00 8b 46 08 48 89 54 24 68 49 89 f7 4c 89 5c 24 60 31 d2 4c 89 74 24 30 85 c0 0f 85 c0 01 00 00 <48> 83 ba d8 01 00 00 00 48 8b b4 24 90 00 00 00 74 16 48 8b 46 10 [172536.665276] RSP: 0018:ffffb47c0e81bbe0 EFLAGS: 00010246 [172536.665277] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [172536.665278] RDX: 0000000000000000 RSI: ffffb47c0e81be28 RDI: ffffb47c0e81bd68 [172536.665279] RBP: ffff936524080010 R08: 0000000000000000 R09: ffffb47c0e81be38 [172536.665281] R10: ffff936524080010 R11: ffff936524080000 R12: ffffb47c0e81bc40 [172536.665282] R13: ffffb47c0e81be28 R14: ffff9367bc410000 R15: ffffb47c0e81be28 [172536.665283] FS: 00007fe35e05d740(0000) GS:ffff936c1edc0000(0000) knlGS:0000000000000000 [172536.665284] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [172536.665286] CR2: 00000000000001d8 CR3: 0000000532e46000 CR4: 00000000000406e0 [172536.665287] Call Trace: [172536.665322] ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu] [172536.665332] drm_ioctl_kernel+0xaa/0xf0 [drm] [172536.665338] drm_ioctl+0x201/0x3b0 [drm] [172536.665369] ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu] [172536.665372] ? selinux_file_ioctl+0x135/0x230 [172536.665399] amdgpu_drm_ioctl+0x49/0x80 [amdgpu] [172536.665403] __x64_sys_ioctl+0x83/0xb0 [172536.665406] do_syscall_64+0x33/0x40 [172536.665409] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2018 CVE-2022-49335 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ocfs2: dlmfs: fix error handling of user_dlm_destroy_lock When user_dlm_destroy_lock failed, it didn't clean up the flags it set before exit. For USER_LOCK_IN_TEARDOWN, if this function fails because of lock is still in used, next time when unlink invokes this function, it will return succeed, and then unlink will remove inode and dentry if lock is not in used(file closed), but the dlm lock is still linked in dlm lock resource, then when bast come in, it will trigger a panic due to user-after-free. See the following panic call trace. To fix this, USER_LOCK_IN_TEARDOWN should be reverted if fail. And also error should be returned if USER_LOCK_IN_TEARDOWN is set to let user know that unlink fail. For the case of ocfs2_dlm_unlock failure, besides USER_LOCK_IN_TEARDOWN, USER_LOCK_BUSY is also required to be cleared. Even though spin lock is released in between, but USER_LOCK_IN_TEARDOWN is still set, for USER_LOCK_BUSY, if before every place that waits on this flag, USER_LOCK_IN_TEARDOWN is checked to bail out, that will make sure no flow waits on the busy flag set by user_dlm_destroy_lock(), then we can simplely revert USER_LOCK_BUSY when ocfs2_dlm_unlock fails. Fix user_dlm_cluster_lock() which is the only function not following this. [ 941.336392] (python,26174,16):dlmfs_unlink:562 ERROR: unlink 004fb0000060000b5a90b8c847b72e1, error -16 from destroy [ 989.757536] ------------[ cut here ]------------ [ 989.757709] kernel BUG at fs/ocfs2/dlmfs/userdlm.c:173! [ 989.757876] invalid opcode: 0000 [#1] SMP [ 989.758027] Modules linked in: ksplice_2zhuk2jr_ib_ipoib_new(O) ksplice_2zhuk2jr(O) mptctl mptbase xen_netback xen_blkback xen_gntalloc xen_gntdev xen_evtchn cdc_ether usbnet mii ocfs2 jbd2 rpcsec_gss_krb5 auth_rpcgss nfsv4 nfsv3 nfs_acl nfs fscache lockd grace ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs bnx2fc fcoe libfcoe libfc scsi_transport_fc sunrpc ipmi_devintf bridge stp llc rds_rdma rds bonding ib_sdp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm falcon_lsm_serviceable(PE) falcon_nf_netcontain(PE) mlx4_vnic falcon_kal(E) falcon_lsm_pinned_13402(E) mlx4_ib ib_sa ib_mad ib_core ib_addr xenfs xen_privcmd dm_multipath iTCO_wdt iTCO_vendor_support pcspkr sb_edac edac_core i2c_i801 lpc_ich mfd_core ipmi_ssif i2c_core ipmi_si ipmi_msghandler [ 989.760686] ioatdma sg ext3 jbd mbcache sd_mod ahci libahci ixgbe dca ptp pps_core vxlan udp_tunnel ip6_udp_tunnel megaraid_sas mlx4_core crc32c_intel be2iscsi bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi ipv6 cxgb3 mdio libiscsi_tcp qla4xxx iscsi_boot_sysfs libiscsi scsi_transport_iscsi wmi dm_mirror dm_region_hash dm_log dm_mod [last unloaded: ksplice_2zhuk2jr_ib_ipoib_old] [ 989.761987] CPU: 10 PID: 19102 Comm: dlm_thread Tainted: P OE 4.1.12-124.57.1.el6uek.x86_64 #2 [ 989.762290] Hardware name: Oracle Corporation ORACLE SERVER X5-2/ASM,MOTHERBOARD,1U, BIOS 30350100 06/17/2021 [ 989.762599] task: ffff880178af6200 ti: ffff88017f7c8000 task.ti: ffff88017f7c8000 [ 989.762848] RIP: e030:[<ffffffffc07d4316>] [<ffffffffc07d4316>] __user_dlm_queue_lockres.part.4+0x76/0x80 [ocfs2_dlmfs] [ 989.763185] RSP: e02b:ffff88017f7cbcb8 EFLAGS: 00010246 [ 989.763353] RAX: 0000000000000000 RBX: ffff880174d48008 RCX: 0000000000000003 [ 989.763565] RDX: 0000000000120012 RSI: 0000000000000003 RDI: ffff880174d48170 [ 989.763778] RBP: ffff88017f7cbcc8 R08: ffff88021f4293b0 R09: 0000000000000000 [ 989.763991] R10: ffff880179c8c000 R11: 0000000000000003 R12: ffff880174d48008 [ 989.764204] R13: 0000000000000003 R14: ffff880179c8c000 R15: ffff88021db7a000 [ 989.764422] FS: 0000000000000000(0000) GS:ffff880247480000(0000) knlGS:ffff880247480000 [ 989.764685] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 989.764865] CR2: ffff8000007f6800 CR3: 0000000001ae0000 CR4: 0000000000042660 [ 989.765081] Stack: [ 989.765167] 00000000000 ---truncated--- CVE-2022-49337 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: af_unix: Fix a data-race in unix_dgram_peer_wake_me(). unix_dgram_poll() calls unix_dgram_peer_wake_me() without `other`'s lock held and check if its receive queue is full. Here we need to use unix_recvq_full_lockless() instead of unix_recvq_full(), otherwise KCSAN will report a data-race. CVE-2022-49344 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ext4: fix bug_on in ext4_writepages we got issue as follows: EXT4-fs error (device loop0): ext4_mb_generate_buddy:1141: group 0, block bitmap and bg descriptor inconsistent: 25 vs 31513 free cls ------------[ cut here ]------------ kernel BUG at fs/ext4/inode.c:2708! invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 2 PID: 2147 Comm: rep Not tainted 5.18.0-rc2-next-20220413+ #155 RIP: 0010:ext4_writepages+0x1977/0x1c10 RSP: 0018:ffff88811d3e7880 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88811c098000 RDX: 0000000000000000 RSI: ffff88811c098000 RDI: 0000000000000002 RBP: ffff888128140f50 R08: ffffffffb1ff6387 R09: 0000000000000000 R10: 0000000000000007 R11: ffffed10250281ea R12: 0000000000000001 R13: 00000000000000a4 R14: ffff88811d3e7bb8 R15: ffff888128141028 FS: 00007f443aed9740(0000) GS:ffff8883aef00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020007200 CR3: 000000011c2a4000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> do_writepages+0x130/0x3a0 filemap_fdatawrite_wbc+0x83/0xa0 filemap_flush+0xab/0xe0 ext4_alloc_da_blocks+0x51/0x120 __ext4_ioctl+0x1534/0x3210 __x64_sys_ioctl+0x12c/0x170 do_syscall_64+0x3b/0x90 It may happen as follows: 1. write inline_data inode vfs_write new_sync_write ext4_file_write_iter ext4_buffered_write_iter generic_perform_write ext4_da_write_begin ext4_da_write_inline_data_begin -> If inline data size too small will allocate block to write, then mapping will has dirty page ext4_da_convert_inline_data_to_extent ->clear EXT4_STATE_MAY_INLINE_DATA 2. fallocate do_vfs_ioctl ioctl_preallocate vfs_fallocate ext4_fallocate ext4_convert_inline_data ext4_convert_inline_data_nolock ext4_map_blocks -> fail will goto restore data ext4_restore_inline_data ext4_create_inline_data ext4_write_inline_data ext4_set_inode_state -> set inode EXT4_STATE_MAY_INLINE_DATA 3. writepages __ext4_ioctl ext4_alloc_da_blocks filemap_flush filemap_fdatawrite_wbc do_writepages ext4_writepages if (ext4_has_inline_data(inode)) BUG_ON(ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)) The root cause of this issue is we destory inline data until call ext4_writepages under delay allocation mode. But there maybe already convert from inline to extent. To solve this issue, we call filemap_flush first.. CVE-2022-49347 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ext4: fix use-after-free in ext4_rename_dir_prepare We got issue as follows: EXT4-fs (loop0): mounted filesystem without journal. Opts: ,errors=continue ext4_get_first_dir_block: bh->b_data=0xffff88810bee6000 len=34478 ext4_get_first_dir_block: *parent_de=0xffff88810beee6ae bh->b_data=0xffff88810bee6000 ext4_rename_dir_prepare: [1] parent_de=0xffff88810beee6ae ================================================================== BUG: KASAN: use-after-free in ext4_rename_dir_prepare+0x152/0x220 Read of size 4 at addr ffff88810beee6ae by task rep/1895 CPU: 13 PID: 1895 Comm: rep Not tainted 5.10.0+ #241 Call Trace: dump_stack+0xbe/0xf9 print_address_description.constprop.0+0x1e/0x220 kasan_report.cold+0x37/0x7f ext4_rename_dir_prepare+0x152/0x220 ext4_rename+0xf44/0x1ad0 ext4_rename2+0x11c/0x170 vfs_rename+0xa84/0x1440 do_renameat2+0x683/0x8f0 __x64_sys_renameat+0x53/0x60 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f45a6fc41c9 RSP: 002b:00007ffc5a470218 EFLAGS: 00000246 ORIG_RAX: 0000000000000108 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f45a6fc41c9 RDX: 0000000000000005 RSI: 0000000020000180 RDI: 0000000000000005 RBP: 00007ffc5a470240 R08: 00007ffc5a470160 R09: 0000000020000080 R10: 00000000200001c0 R11: 0000000000000246 R12: 0000000000400bb0 R13: 00007ffc5a470320 R14: 0000000000000000 R15: 0000000000000000 The buggy address belongs to the page: page:00000000440015ce refcount:0 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x10beee flags: 0x200000000000000() raw: 0200000000000000 ffffea00043ff4c8 ffffea0004325608 0000000000000000 raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88810beee580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88810beee600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff88810beee680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88810beee700: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88810beee780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== Disabling lock debugging due to kernel taint ext4_rename_dir_prepare: [2] parent_de->inode=3537895424 ext4_rename_dir_prepare: [3] dir=0xffff888124170140 ext4_rename_dir_prepare: [4] ino=2 ext4_rename_dir_prepare: ent->dir->i_ino=2 parent=-757071872 Reason is first directory entry which 'rec_len' is 34478, then will get illegal parent entry. Now, we do not check directory entry after read directory block in 'ext4_get_first_dir_block'. To solve this issue, check directory entry in 'ext4_get_first_dir_block'. [ Trigger an ext4_error() instead of just warning if the directory is missing a '.' or '..' entry. Also make sure we return an error code if the file system is corrupted. -TYT ] CVE-2022-49349 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: altera: Fix refcount leak in altera_tse_mdio_create Every iteration of for_each_child_of_node() decrements the reference count of the previous node. When break from a for_each_child_of_node() loop, we need to explicitly call of_node_put() on the child node when not need anymore. Add missing of_node_put() to avoid refcount leak. CVE-2022-49351 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: Fix refcount leak in mv88e6xxx_mdios_register of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. mv88e6xxx_mdio_register() pass the device node to of_mdiobus_register(). We don't need the device node after it. Add missing of_node_put() to avoid refcount leak. CVE-2022-49367 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: firmware: dmi-sysfs: Fix memory leak in dmi_sysfs_register_handle kobject_init_and_add() takes reference even when it fails. According to the doc of kobject_init_and_add() If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Fix this issue by calling kobject_put(). CVE-2022-49370 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: driver core: fix deadlock in __device_attach In __device_attach function, The lock holding logic is as follows: ... __device_attach device_lock(dev) // get lock dev async_schedule_dev(__device_attach_async_helper, dev); // func async_schedule_node async_schedule_node_domain(func) entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC); /* when fail or work limit, sync to execute func, but __device_attach_async_helper will get lock dev as well, which will lead to A-A deadlock. */ if (!entry || atomic_read(&entry_count) > MAX_WORK) { func; else queue_work_node(node, system_unbound_wq, &entry->work) device_unlock(dev) As shown above, when it is allowed to do async probes, because of out of memory or work limit, async work is not allowed, to do sync execute instead. it will lead to A-A deadlock because of __device_attach_async_helper getting lock dev. To fix the deadlock, move the async_schedule_dev outside device_lock, as we can see, in async_schedule_node_domain, the parameter of queue_work_node is system_unbound_wq, so it can accept concurrent operations. which will also not change the code logic, and will not lead to deadlock. CVE-2022-49371 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: tcp: tcp_rtx_synack() can be called from process context Laurent reported the enclosed report [1] This bug triggers with following coditions: 0) Kernel built with CONFIG_DEBUG_PREEMPT=y 1) A new passive FastOpen TCP socket is created. This FO socket waits for an ACK coming from client to be a complete ESTABLISHED one. 2) A socket operation on this socket goes through lock_sock() release_sock() dance. 3) While the socket is owned by the user in step 2), a retransmit of the SYN is received and stored in socket backlog. 4) At release_sock() time, the socket backlog is processed while in process context. 5) A SYNACK packet is cooked in response of the SYN retransmit. 6) -> tcp_rtx_synack() is called in process context. Before blamed commit, tcp_rtx_synack() was always called from BH handler, from a timer handler. Fix this by using TCP_INC_STATS() & NET_INC_STATS() which do not assume caller is in non preemptible context. [1] BUG: using __this_cpu_add() in preemptible [00000000] code: epollpep/2180 caller is tcp_rtx_synack.part.0+0x36/0xc0 CPU: 10 PID: 2180 Comm: epollpep Tainted: G OE 5.16.0-0.bpo.4-amd64 #1 Debian 5.16.12-1~bpo11+1 Hardware name: Supermicro SYS-5039MC-H8TRF/X11SCD-F, BIOS 1.7 11/23/2021 Call Trace: <TASK> dump_stack_lvl+0x48/0x5e check_preemption_disabled+0xde/0xe0 tcp_rtx_synack.part.0+0x36/0xc0 tcp_rtx_synack+0x8d/0xa0 ? kmem_cache_alloc+0x2e0/0x3e0 ? apparmor_file_alloc_security+0x3b/0x1f0 inet_rtx_syn_ack+0x16/0x30 tcp_check_req+0x367/0x610 tcp_rcv_state_process+0x91/0xf60 ? get_nohz_timer_target+0x18/0x1a0 ? lock_timer_base+0x61/0x80 ? preempt_count_add+0x68/0xa0 tcp_v4_do_rcv+0xbd/0x270 __release_sock+0x6d/0xb0 release_sock+0x2b/0x90 sock_setsockopt+0x138/0x1140 ? __sys_getsockname+0x7e/0xc0 ? aa_sk_perm+0x3e/0x1a0 __sys_setsockopt+0x198/0x1e0 __x64_sys_setsockopt+0x21/0x30 do_syscall_64+0x38/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae CVE-2022-49372 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: soc: rockchip: Fix refcount leak in rockchip_grf_init of_find_matching_node_and_match returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. CVE-2022-49382 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: driver: base: fix UAF when driver_attach failed When driver_attach(drv); failed, the driver_private will be freed. But it has been added to the bus, which caused a UAF. To fix it, we need to delete it from the bus when failed. CVE-2022-49385 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ubi: ubi_create_volume: Fix use-after-free when volume creation failed There is an use-after-free problem for 'eba_tbl' in ubi_create_volume()'s error handling path: ubi_eba_replace_table(vol, eba_tbl) vol->eba_tbl = tbl out_mapping: ubi_eba_destroy_table(eba_tbl) // Free 'eba_tbl' out_unlock: put_device(&vol->dev) vol_release kfree(tbl->entries) // UAF Fix it by removing redundant 'eba_tbl' releasing. Fetch a reproducer in [Link]. CVE-2022-49388 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: usb: usbip: fix a refcount leak in stub_probe() usb_get_dev() is called in stub_device_alloc(). When stub_probe() fails after that, usb_put_dev() needs to be called to release the reference. Fix this by moving usb_put_dev() to sdev_free error path handling. Find this by code review. CVE-2022-49389 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: macsec: fix UAF bug for real_dev Create a new macsec device but not get reference to real_dev. That can not ensure that real_dev is freed after macsec. That will trigger the UAF bug for real_dev as following: ================================================================== BUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 Call Trace: ... macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 dev_get_iflink+0x73/0xe0 net/core/dev.c:637 default_operstate net/core/link_watch.c:42 [inline] rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54 linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161 Allocated by task 22209: ... alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549 rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235 veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748 Freed by task 8: ... kfree+0xd6/0x4d0 mm/slub.c:4552 kvfree+0x42/0x50 mm/util.c:615 device_release+0x9f/0x240 drivers/base/core.c:2229 kobject_cleanup lib/kobject.c:673 [inline] kobject_release lib/kobject.c:704 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x1c8/0x540 lib/kobject.c:721 netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327 After commit faab39f63c1f ("net: allow out-of-order netdev unregistration") and commit e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev"), we can add dev_hold_track() in macsec_dev_init() and dev_put_track() in macsec_free_netdev() to fix the problem. CVE-2022-49390 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: um: Fix out-of-bounds read in LDT setup syscall_stub_data() expects the data_count parameter to be the number of longs, not bytes. ================================================================== BUG: KASAN: stack-out-of-bounds in syscall_stub_data+0x70/0xe0 Read of size 128 at addr 000000006411f6f0 by task swapper/1 CPU: 0 PID: 1 Comm: swapper Not tainted 5.18.0+ #18 Call Trace: show_stack.cold+0x166/0x2a7 __dump_stack+0x3a/0x43 dump_stack_lvl+0x1f/0x27 print_report.cold+0xdb/0xf81 kasan_report+0x119/0x1f0 kasan_check_range+0x3a3/0x440 memcpy+0x52/0x140 syscall_stub_data+0x70/0xe0 write_ldt_entry+0xac/0x190 init_new_ldt+0x515/0x960 init_new_context+0x2c4/0x4d0 mm_init.constprop.0+0x5ed/0x760 mm_alloc+0x118/0x170 0x60033f48 do_one_initcall+0x1d7/0x860 0x60003e7b kernel_init+0x6e/0x3d4 new_thread_handler+0x1e7/0x2c0 The buggy address belongs to stack of task swapper/1 and is located at offset 64 in frame: init_new_ldt+0x0/0x960 This frame has 2 objects: [32, 40) 'addr' [64, 80) 'desc' ================================================================== CVE-2022-49395 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: phy: qcom-qmp: fix reset-controller leak on probe errors Make sure to release the lane reset controller in case of a late probe error (e.g. probe deferral). Note that due to the reset controller being defined in devicetree in "lane" child nodes, devm_reset_control_get_exclusive() cannot be used directly. CVE-2022-49396 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: phy: qcom-qmp: fix struct clk leak on probe errors Make sure to release the pipe clock reference in case of a late probe error (e.g. probe deferral). CVE-2022-49397 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Fix potential integer multiplication overflow errors When multiplying of different types, an overflow is possible even when storing the result in a larger type. This is because the conversion is done after the multiplication. So arithmetic overflow and thus in incorrect value is possible. Correct an instance of this in the inter packet delay calculation. Fix by ensuring one of the operands is u64 which will promote the other to u64 as well ensuring no overflow. CVE-2022-49404 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: dlm: fix plock invalid read This patch fixes an invalid read showed by KASAN. A unlock will allocate a "struct plock_op" and a followed send_op() will append it to a global send_list data structure. In some cases a followed dev_read() moves it to recv_list and dev_write() will cast it to "struct plock_xop" and access fields which are only available in those structures. At this point an invalid read happens by accessing those fields. To fix this issue the "callback" field is moved to "struct plock_op" to indicate that a cast to "plock_xop" is allowed and does the additional "plock_xop" handling if set. Example of the KASAN output which showed the invalid read: [ 2064.296453] ================================================================== [ 2064.304852] BUG: KASAN: slab-out-of-bounds in dev_write+0x52b/0x5a0 [dlm] [ 2064.306491] Read of size 8 at addr ffff88800ef227d8 by task dlm_controld/7484 [ 2064.308168] [ 2064.308575] CPU: 0 PID: 7484 Comm: dlm_controld Kdump: loaded Not tainted 5.14.0+ #9 [ 2064.310292] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 [ 2064.311618] Call Trace: [ 2064.312218] dump_stack_lvl+0x56/0x7b [ 2064.313150] print_address_description.constprop.8+0x21/0x150 [ 2064.314578] ? dev_write+0x52b/0x5a0 [dlm] [ 2064.315610] ? dev_write+0x52b/0x5a0 [dlm] [ 2064.316595] kasan_report.cold.14+0x7f/0x11b [ 2064.317674] ? dev_write+0x52b/0x5a0 [dlm] [ 2064.318687] dev_write+0x52b/0x5a0 [dlm] [ 2064.319629] ? dev_read+0x4a0/0x4a0 [dlm] [ 2064.320713] ? bpf_lsm_kernfs_init_security+0x10/0x10 [ 2064.321926] vfs_write+0x17e/0x930 [ 2064.322769] ? __fget_light+0x1aa/0x220 [ 2064.323753] ksys_write+0xf1/0x1c0 [ 2064.324548] ? __ia32_sys_read+0xb0/0xb0 [ 2064.325464] do_syscall_64+0x3a/0x80 [ 2064.326387] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 2064.327606] RIP: 0033:0x7f807e4ba96f [ 2064.328470] Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 39 87 f8 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 7c 87 f8 ff 48 [ 2064.332902] RSP: 002b:00007ffd50cfe6e0 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 [ 2064.334658] RAX: ffffffffffffffda RBX: 000055cc3886eb30 RCX: 00007f807e4ba96f [ 2064.336275] RDX: 0000000000000040 RSI: 00007ffd50cfe7e0 RDI: 0000000000000010 [ 2064.337980] RBP: 00007ffd50cfe7e0 R08: 0000000000000000 R09: 0000000000000001 [ 2064.339560] R10: 000055cc3886eb30 R11: 0000000000000293 R12: 000055cc3886eb80 [ 2064.341237] R13: 000055cc3886eb00 R14: 000055cc3886f590 R15: 0000000000000001 [ 2064.342857] [ 2064.343226] Allocated by task 12438: [ 2064.344057] kasan_save_stack+0x1c/0x40 [ 2064.345079] __kasan_kmalloc+0x84/0xa0 [ 2064.345933] kmem_cache_alloc_trace+0x13b/0x220 [ 2064.346953] dlm_posix_unlock+0xec/0x720 [dlm] [ 2064.348811] do_lock_file_wait.part.32+0xca/0x1d0 [ 2064.351070] fcntl_setlk+0x281/0xbc0 [ 2064.352879] do_fcntl+0x5e4/0xfe0 [ 2064.354657] __x64_sys_fcntl+0x11f/0x170 [ 2064.356550] do_syscall_64+0x3a/0x80 [ 2064.358259] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 2064.360745] [ 2064.361511] Last potentially related work creation: [ 2064.363957] kasan_save_stack+0x1c/0x40 [ 2064.365811] __kasan_record_aux_stack+0xaf/0xc0 [ 2064.368100] call_rcu+0x11b/0xf70 [ 2064.369785] dlm_process_incoming_buffer+0x47d/0xfd0 [dlm] [ 2064.372404] receive_from_sock+0x290/0x770 [dlm] [ 2064.374607] process_recv_sockets+0x32/0x40 [dlm] [ 2064.377290] process_one_work+0x9a8/0x16e0 [ 2064.379357] worker_thread+0x87/0xbf0 [ 2064.381188] kthread+0x3ac/0x490 [ 2064.383460] ret_from_fork+0x22/0x30 [ 2064.385588] [ 2064.386518] Second to last potentially related work creation: [ 2064.389219] kasan_save_stack+0x1c/0x40 [ 2064.391043] __kasan_record_aux_stack+0xaf/0xc0 [ 2064.393303] call_rcu+0x11b/0xf70 [ 2064.394885] dlm_process_incoming_buffer+0x47d/0xfd0 [dlm] [ 2064.397694] receive_from_sock+0x290/0x770 ---truncated--- CVE-2022-49407 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ext4: fix bug_on in __es_tree_search Hulk Robot reported a BUG_ON: ================================================================== kernel BUG at fs/ext4/extents_status.c:199! [...] RIP: 0010:ext4_es_end fs/ext4/extents_status.c:199 [inline] RIP: 0010:__es_tree_search+0x1e0/0x260 fs/ext4/extents_status.c:217 [...] Call Trace: ext4_es_cache_extent+0x109/0x340 fs/ext4/extents_status.c:766 ext4_cache_extents+0x239/0x2e0 fs/ext4/extents.c:561 ext4_find_extent+0x6b7/0xa20 fs/ext4/extents.c:964 ext4_ext_map_blocks+0x16b/0x4b70 fs/ext4/extents.c:4384 ext4_map_blocks+0xe26/0x19f0 fs/ext4/inode.c:567 ext4_getblk+0x320/0x4c0 fs/ext4/inode.c:980 ext4_bread+0x2d/0x170 fs/ext4/inode.c:1031 ext4_quota_read+0x248/0x320 fs/ext4/super.c:6257 v2_read_header+0x78/0x110 fs/quota/quota_v2.c:63 v2_check_quota_file+0x76/0x230 fs/quota/quota_v2.c:82 vfs_load_quota_inode+0x5d1/0x1530 fs/quota/dquot.c:2368 dquot_enable+0x28a/0x330 fs/quota/dquot.c:2490 ext4_quota_enable fs/ext4/super.c:6137 [inline] ext4_enable_quotas+0x5d7/0x960 fs/ext4/super.c:6163 ext4_fill_super+0xa7c9/0xdc00 fs/ext4/super.c:4754 mount_bdev+0x2e9/0x3b0 fs/super.c:1158 mount_fs+0x4b/0x1e4 fs/super.c:1261 [...] ================================================================== Above issue may happen as follows: ------------------------------------- ext4_fill_super ext4_enable_quotas ext4_quota_enable ext4_iget __ext4_iget ext4_ext_check_inode ext4_ext_check __ext4_ext_check ext4_valid_extent_entries Check for overlapping extents does't take effect dquot_enable vfs_load_quota_inode v2_check_quota_file v2_read_header ext4_quota_read ext4_bread ext4_getblk ext4_map_blocks ext4_ext_map_blocks ext4_find_extent ext4_cache_extents ext4_es_cache_extent ext4_es_cache_extent __es_tree_search ext4_es_end BUG_ON(es->es_lblk + es->es_len < es->es_lblk) The error ext4 extents is as follows: 0af3 0300 0400 0000 00000000 extent_header 00000000 0100 0000 12000000 extent1 00000000 0100 0000 18000000 extent2 02000000 0400 0000 14000000 extent3 In the ext4_valid_extent_entries function, if prev is 0, no error is returned even if lblock<=prev. This was intended to skip the check on the first extent, but in the error image above, prev=0+1-1=0 when checking the second extent, so even though lblock<=prev, the function does not return an error. As a result, bug_ON occurs in __es_tree_search and the system panics. To solve this problem, we only need to check that: 1. The lblock of the first extent is not less than 0. 2. The lblock of the next extent is not less than the next block of the previous extent. The same applies to extent_idx. CVE-2022-49409 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: bfq: Make sure bfqg for which we are queueing requests is online Bios queued into BFQ IO scheduler can be associated with a cgroup that was already offlined. This may then cause insertion of this bfq_group into a service tree. But this bfq_group will get freed as soon as last bio associated with it is completed leading to use after free issues for service tree users. Fix the problem by making sure we always operate on online bfq_group. If the bfq_group associated with the bio is not online, we pick the first online parent. CVE-2022-49411 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: bfq: Update cgroup information before merging bio When the process is migrated to a different cgroup (or in case of writeback just starts submitting bios associated with a different cgroup) bfq_merge_bio() can operate with stale cgroup information in bic. Thus the bio can be merged to a request from a different cgroup or it can result in merging of bfqqs for different cgroups or bfqqs of already dead cgroups and causing possible use-after-free issues. Fix the problem by updating cgroup information in bfq_merge_bio(). CVE-2022-49413 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 important In the Linux kernel, the following vulnerability has been resolved: ext4: fix race condition between ext4_write and ext4_convert_inline_data Hulk Robot reported a BUG_ON: ================================================================== EXT4-fs error (device loop3): ext4_mb_generate_buddy:805: group 0, block bitmap and bg descriptor inconsistent: 25 vs 31513 free clusters kernel BUG at fs/ext4/ext4_jbd2.c:53! invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 PID: 25371 Comm: syz-executor.3 Not tainted 5.10.0+ #1 RIP: 0010:ext4_put_nojournal fs/ext4/ext4_jbd2.c:53 [inline] RIP: 0010:__ext4_journal_stop+0x10e/0x110 fs/ext4/ext4_jbd2.c:116 [...] Call Trace: ext4_write_inline_data_end+0x59a/0x730 fs/ext4/inline.c:795 generic_perform_write+0x279/0x3c0 mm/filemap.c:3344 ext4_buffered_write_iter+0x2e3/0x3d0 fs/ext4/file.c:270 ext4_file_write_iter+0x30a/0x11c0 fs/ext4/file.c:520 do_iter_readv_writev+0x339/0x3c0 fs/read_write.c:732 do_iter_write+0x107/0x430 fs/read_write.c:861 vfs_writev fs/read_write.c:934 [inline] do_pwritev+0x1e5/0x380 fs/read_write.c:1031 [...] ================================================================== Above issue may happen as follows: cpu1 cpu2 __________________________|__________________________ do_pwritev vfs_writev do_iter_write ext4_file_write_iter ext4_buffered_write_iter generic_perform_write ext4_da_write_begin vfs_fallocate ext4_fallocate ext4_convert_inline_data ext4_convert_inline_data_nolock ext4_destroy_inline_data_nolock clear EXT4_STATE_MAY_INLINE_DATA ext4_map_blocks ext4_ext_map_blocks ext4_mb_new_blocks ext4_mb_regular_allocator ext4_mb_good_group_nolock ext4_mb_init_group ext4_mb_init_cache ext4_mb_generate_buddy --> error ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA) ext4_restore_inline_data set EXT4_STATE_MAY_INLINE_DATA ext4_block_write_begin ext4_da_write_end ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA) ext4_write_inline_data_end handle=NULL ext4_journal_stop(handle) __ext4_journal_stop ext4_put_nojournal(handle) ref_cnt = (unsigned long)handle BUG_ON(ref_cnt == 0) ---> BUG_ON The lock held by ext4_convert_inline_data is xattr_sem, but the lock held by generic_perform_write is i_rwsem. Therefore, the two locks can be concurrent. To solve above issue, we add inode_lock() for ext4_convert_inline_data(). At the same time, move ext4_convert_inline_data() in front of ext4_punch_hole(), remove similar handling from ext4_punch_hole(). CVE-2022-49414 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix use-after-free in chanctx code In ieee80211_vif_use_reserved_context(), when we have an old context and the new context's replace_state is set to IEEE80211_CHANCTX_REPLACE_NONE, we free the old context in ieee80211_vif_use_reserved_reassign(). Therefore, we cannot check the old_ctx anymore, so we should set it to NULL after this point. However, since the new_ctx replace state is clearly not IEEE80211_CHANCTX_REPLACES_OTHER, we're not going to do anything else in this function and can just return to avoid accessing the freed old_ctx. CVE-2022-49416 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: annotate races around sk->sk_bound_dev_if UDP sendmsg() is lockless, and reads sk->sk_bound_dev_if while this field can be changed by another thread. Adds minimal annotations to avoid KCSAN splats for UDP. Following patches will add more annotations to potential lockless readers. BUG: KCSAN: data-race in __ip6_datagram_connect / udpv6_sendmsg write to 0xffff888136d47a94 of 4 bytes by task 7681 on cpu 0: __ip6_datagram_connect+0x6e2/0x930 net/ipv6/datagram.c:221 ip6_datagram_connect+0x2a/0x40 net/ipv6/datagram.c:272 inet_dgram_connect+0x107/0x190 net/ipv4/af_inet.c:576 __sys_connect_file net/socket.c:1900 [inline] __sys_connect+0x197/0x1b0 net/socket.c:1917 __do_sys_connect net/socket.c:1927 [inline] __se_sys_connect net/socket.c:1924 [inline] __x64_sys_connect+0x3d/0x50 net/socket.c:1924 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x50 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff888136d47a94 of 4 bytes by task 7670 on cpu 1: udpv6_sendmsg+0xc60/0x16e0 net/ipv6/udp.c:1436 inet6_sendmsg+0x5f/0x80 net/ipv6/af_inet6.c:652 sock_sendmsg_nosec net/socket.c:705 [inline] sock_sendmsg net/socket.c:725 [inline] ____sys_sendmsg+0x39a/0x510 net/socket.c:2413 ___sys_sendmsg net/socket.c:2467 [inline] __sys_sendmmsg+0x267/0x4c0 net/socket.c:2553 __do_sys_sendmmsg net/socket.c:2582 [inline] __se_sys_sendmmsg net/socket.c:2579 [inline] __x64_sys_sendmmsg+0x53/0x60 net/socket.c:2579 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x50 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0x00000000 -> 0xffffff9b Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 7670 Comm: syz-executor.3 Tainted: G W 5.18.0-rc1-syzkaller-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 I chose to not add Fixes: tag because race has minor consequences and stable teams busy enough. CVE-2022-49420 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: video: fbdev: clcdfb: Fix refcount leak in clcdfb_of_vram_setup of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. CVE-2022-49421 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Prevent panic when SDMA is disabled If the hfi1 module is loaded with HFI1_CAP_SDMA off, a call to hfi1_write_iter() will dereference a NULL pointer and panic. A typical stack frame is: sdma_select_user_engine [hfi1] hfi1_user_sdma_process_request [hfi1] hfi1_write_iter [hfi1] do_iter_readv_writev do_iter_write vfs_writev do_writev do_syscall_64 The fix is to test for SDMA in hfi1_write_iter() and fail the I/O with EINVAL. CVE-2022-49429 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: powerpc/xics: fix refcount leak in icp_opal_init() The of_find_compatible_node() function returns a node pointer with refcount incremented, use of_node_put() on it when done. CVE-2022-49432 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Prevent use of lock before it is initialized If there is a failure during probe of hfi1 before the sdma_map_lock is initialized, the call to hfi1_free_devdata() will attempt to use a lock that has not been initialized. If the locking correctness validator is on then an INFO message and stack trace resembling the following may be seen: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. Call Trace: register_lock_class+0x11b/0x880 __lock_acquire+0xf3/0x7930 lock_acquire+0xff/0x2d0 _raw_spin_lock_irq+0x46/0x60 sdma_clean+0x42a/0x660 [hfi1] hfi1_free_devdata+0x3a7/0x420 [hfi1] init_one+0x867/0x11a0 [hfi1] pci_device_probe+0x40e/0x8d0 The use of sdma_map_lock in sdma_clean() is for freeing the sdma_map memory, and sdma_map is not allocated/initialized until after sdma_map_lock has been initialized. This code only needs to be run if sdma_map is not NULL, and so checking for that condition will avoid trying to use the lock before it is initialized. CVE-2022-49433 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: PCI: Avoid pci_dev_lock() AB/BA deadlock with sriov_numvfs_store() The sysfs sriov_numvfs_store() path acquires the device lock before the config space access lock: sriov_numvfs_store device_lock # A (1) acquire device lock sriov_configure vfio_pci_sriov_configure # (for example) vfio_pci_core_sriov_configure pci_disable_sriov sriov_disable pci_cfg_access_lock pci_wait_cfg # B (4) wait for dev->block_cfg_access == 0 Previously, pci_dev_lock() acquired the config space access lock before the device lock: pci_dev_lock pci_cfg_access_lock dev->block_cfg_access = 1 # B (2) set dev->block_cfg_access = 1 device_lock # A (3) wait for device lock Any path that uses pci_dev_lock(), e.g., pci_reset_function(), may deadlock with sriov_numvfs_store() if the operations occur in the sequence (1) (2) (3) (4). Avoid the deadlock by reversing the order in pci_dev_lock() so it acquires the device lock before the config space access lock, the same as the sriov_numvfs_store() path. [bhelgaas: combined and adapted commit log from Jay Zhou's independent subsequent posting: https://lore.kernel.org/r/20220404062539.1710-1-jianjay.zhou@huawei.com] CVE-2022-49434 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: powerpc/xive: Fix refcount leak in xive_spapr_init of_find_compatible_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. CVE-2022-49437 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: tty: fix deadlock caused by calling printk() under tty_port->lock pty_write() invokes kmalloc() which may invoke a normal printk() to print failure message. This can cause a deadlock in the scenario reported by syz-bot below: CPU0 CPU1 CPU2 ---- ---- ---- lock(console_owner); lock(&port_lock_key); lock(&port->lock); lock(&port_lock_key); lock(&port->lock); lock(console_owner); As commit dbdda842fe96 ("printk: Add console owner and waiter logic to load balance console writes") said, such deadlock can be prevented by using printk_deferred() in kmalloc() (which is invoked in the section guarded by the port->lock). But there are too many printk() on the kmalloc() path, and kmalloc() can be called from anywhere, so changing printk() to printk_deferred() is too complicated and inelegant. Therefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so that printk() will not be called, and this deadlock problem can be avoided. Syzbot reported the following lockdep error: ====================================================== WARNING: possible circular locking dependency detected 5.4.143-00237-g08ccc19a-dirty #10 Not tainted ------------------------------------------------------ syz-executor.4/29420 is trying to acquire lock: ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline] ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023 but task is already holding lock: ffff8880119c9158 (&port->lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&port->lock){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 tty_port_tty_get drivers/tty/tty_port.c:288 [inline] <-- lock(&port->lock); tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47 serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767 serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854 serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] <-- lock(&port_lock_key); serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870 serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126 __handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156 [...] -> #1 (&port_lock_key){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198 <-- lock(&port_lock_key); call_console_drivers kernel/printk/printk.c:1819 [inline] console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504 vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024 <-- lock(console_owner); vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394 printk+0xba/0xed kernel/printk/printk.c:2084 register_console+0x8b3/0xc10 kernel/printk/printk.c:2829 univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681 console_init+0x49d/0x6d3 kernel/printk/printk.c:2915 start_kernel+0x5e9/0x879 init/main.c:713 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241 -> #0 (console_owner){....}-{0:0}: [...] lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734 console_trylock_spinning kernel/printk/printk.c:1773 ---truncated--- CVE-2022-49441 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: drivers/base/node.c: fix compaction sysfs file leak Compaction sysfs file is created via compaction_register_node in register_node. But we forgot to remove it in unregister_node. Thus compaction sysfs file is leaked. Using compaction_unregister_node to fix this issue. CVE-2022-49442 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: list: fix a data-race around ep->rdllist ep_poll() first calls ep_events_available() with no lock held and checks if ep->rdllist is empty by list_empty_careful(), which reads rdllist->prev. Thus all accesses to it need some protection to avoid store/load-tearing. Note INIT_LIST_HEAD_RCU() already has the annotation for both prev and next. Commit bf3b9f6372c4 ("epoll: Add busy poll support to epoll with socket fds.") added the first lockless ep_events_available(), and commit c5a282e9635e ("fs/epoll: reduce the scope of wq lock in epoll_wait()") made some ep_events_available() calls lockless and added single call under a lock, finally commit e59d3c64cba6 ("epoll: eliminate unnecessary lock for zero timeout") made the last ep_events_available() lockless. BUG: KCSAN: data-race in do_epoll_wait / do_epoll_wait write to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0: INIT_LIST_HEAD include/linux/list.h:38 [inline] list_splice_init include/linux/list.h:492 [inline] ep_start_scan fs/eventpoll.c:622 [inline] ep_send_events fs/eventpoll.c:1656 [inline] ep_poll fs/eventpoll.c:1806 [inline] do_epoll_wait+0x4eb/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1: list_empty_careful include/linux/list.h:329 [inline] ep_events_available fs/eventpoll.c:381 [inline] ep_poll fs/eventpoll.c:1797 [inline] do_epoll_wait+0x279/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0xffff88810480c7d0 -> 0xffff888103c15098 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 1799 Comm: syz-fuzzer Tainted: G W 5.17.0-rc7-syzkaller-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 CVE-2022-49443 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: module: fix [e_shstrndx].sh_size=0 OOB access It is trivial to craft a module to trigger OOB access in this line: if (info->secstrings[strhdr->sh_size - 1] != '\0') { BUG: unable to handle page fault for address: ffffc90000aa0fff PGD 100000067 P4D 100000067 PUD 100066067 PMD 10436f067 PTE 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 7 PID: 1215 Comm: insmod Not tainted 5.18.0-rc5-00007-g9bf578647087-dirty #10 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/01/2014 RIP: 0010:load_module+0x19b/0x2391 [rebased patch onto modules-next] CVE-2022-49444 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: pinctrl: renesas: core: Fix possible null-ptr-deref in sh_pfc_map_resources() It will cause null-ptr-deref when using 'res', if platform_get_resource() returns NULL, so move using 'res' after devm_ioremap_resource() that will check it to avoid null-ptr-deref. And use devm_platform_get_and_ioremap_resource() to simplify code. CVE-2022-49445 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: rk3399_dmc: Disable edev on remove() Otherwise we hit an unablanced enable-count when unbinding the DFI device: [ 1279.659119] ------------[ cut here ]------------ [ 1279.659179] WARNING: CPU: 2 PID: 5638 at drivers/devfreq/devfreq-event.c:360 devfreq_event_remove_edev+0x84/0x8c ... [ 1279.659352] Hardware name: Google Kevin (DT) [ 1279.659363] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO BTYPE=--) [ 1279.659371] pc : devfreq_event_remove_edev+0x84/0x8c [ 1279.659380] lr : devm_devfreq_event_release+0x1c/0x28 ... [ 1279.659571] Call trace: [ 1279.659582] devfreq_event_remove_edev+0x84/0x8c [ 1279.659590] devm_devfreq_event_release+0x1c/0x28 [ 1279.659602] release_nodes+0x1cc/0x244 [ 1279.659611] devres_release_all+0x44/0x60 [ 1279.659621] device_release_driver_internal+0x11c/0x1ac [ 1279.659629] device_driver_detach+0x20/0x2c [ 1279.659641] unbind_store+0x7c/0xb0 [ 1279.659650] drv_attr_store+0x2c/0x40 [ 1279.659663] sysfs_kf_write+0x44/0x58 [ 1279.659672] kernfs_fop_write_iter+0xf4/0x190 [ 1279.659684] vfs_write+0x2b0/0x2e4 [ 1279.659693] ksys_write+0x80/0xec [ 1279.659701] __arm64_sys_write+0x24/0x30 [ 1279.659714] el0_svc_common+0xf0/0x1d8 [ 1279.659724] do_el0_svc_compat+0x28/0x3c [ 1279.659738] el0_svc_compat+0x10/0x1c [ 1279.659746] el0_sync_compat_handler+0xa8/0xcc [ 1279.659758] el0_sync_compat+0x188/0x1c0 [ 1279.659768] ---[ end trace cec200e5094155b4 ]--- CVE-2022-49460 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: blk-throttle: Set BIO_THROTTLED when bio has been throttled 1.In current process, all bio will set the BIO_THROTTLED flag after __blk_throtl_bio(). 2.If bio needs to be throttled, it will start the timer and stop submit bio directly. Bio will submit in blk_throtl_dispatch_work_fn() when the timer expires.But in the current process, if bio is throttled. The BIO_THROTTLED will be set to bio after timer start. If the bio has been completed, it may cause use-after-free blow. BUG: KASAN: use-after-free in blk_throtl_bio+0x12f0/0x2c70 Read of size 2 at addr ffff88801b8902d4 by task fio/26380 dump_stack+0x9b/0xce print_address_description.constprop.6+0x3e/0x60 kasan_report.cold.9+0x22/0x3a blk_throtl_bio+0x12f0/0x2c70 submit_bio_checks+0x701/0x1550 submit_bio_noacct+0x83/0xc80 submit_bio+0xa7/0x330 mpage_readahead+0x380/0x500 read_pages+0x1c1/0xbf0 page_cache_ra_unbounded+0x471/0x6f0 do_page_cache_ra+0xda/0x110 ondemand_readahead+0x442/0xae0 page_cache_async_ra+0x210/0x300 generic_file_buffered_read+0x4d9/0x2130 generic_file_read_iter+0x315/0x490 blkdev_read_iter+0x113/0x1b0 aio_read+0x2ad/0x450 io_submit_one+0xc8e/0x1d60 __se_sys_io_submit+0x125/0x350 do_syscall_64+0x2d/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Allocated by task 26380: kasan_save_stack+0x19/0x40 __kasan_kmalloc.constprop.2+0xc1/0xd0 kmem_cache_alloc+0x146/0x440 mempool_alloc+0x125/0x2f0 bio_alloc_bioset+0x353/0x590 mpage_alloc+0x3b/0x240 do_mpage_readpage+0xddf/0x1ef0 mpage_readahead+0x264/0x500 read_pages+0x1c1/0xbf0 page_cache_ra_unbounded+0x471/0x6f0 do_page_cache_ra+0xda/0x110 ondemand_readahead+0x442/0xae0 page_cache_async_ra+0x210/0x300 generic_file_buffered_read+0x4d9/0x2130 generic_file_read_iter+0x315/0x490 blkdev_read_iter+0x113/0x1b0 aio_read+0x2ad/0x450 io_submit_one+0xc8e/0x1d60 __se_sys_io_submit+0x125/0x350 do_syscall_64+0x2d/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Freed by task 0: kasan_save_stack+0x19/0x40 kasan_set_track+0x1c/0x30 kasan_set_free_info+0x1b/0x30 __kasan_slab_free+0x111/0x160 kmem_cache_free+0x94/0x460 mempool_free+0xd6/0x320 bio_free+0xe0/0x130 bio_put+0xab/0xe0 bio_endio+0x3a6/0x5d0 blk_update_request+0x590/0x1370 scsi_end_request+0x7d/0x400 scsi_io_completion+0x1aa/0xe50 scsi_softirq_done+0x11b/0x240 blk_mq_complete_request+0xd4/0x120 scsi_mq_done+0xf0/0x200 virtscsi_vq_done+0xbc/0x150 vring_interrupt+0x179/0x390 __handle_irq_event_percpu+0xf7/0x490 handle_irq_event_percpu+0x7b/0x160 handle_irq_event+0xcc/0x170 handle_edge_irq+0x215/0xb20 common_interrupt+0x60/0x120 asm_common_interrupt+0x1e/0x40 Fix this by move BIO_THROTTLED set into the queue_lock. CVE-2022-49465 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 important In the Linux kernel, the following vulnerability has been resolved: drm: msm: fix possible memory leak in mdp5_crtc_cursor_set() drm_gem_object_lookup will call drm_gem_object_get inside. So cursor_bo needs to be put when msm_gem_get_and_pin_iova fails. CVE-2022-49467 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: phy: micrel: Allow probing without .driver_data Currently, if the .probe element is present in the phy_driver structure and the .driver_data is not, a NULL pointer dereference happens. Allow passing .probe without .driver_data by inserting NULL checks for priv->type. CVE-2022-49472 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix dangling sco_conn and use-after-free in sco_sock_timeout Connecting the same socket twice consecutively in sco_sock_connect() could lead to a race condition where two sco_conn objects are created but only one is associated with the socket. If the socket is closed before the SCO connection is established, the timer associated with the dangling sco_conn object won't be canceled. As the sock object is being freed, the use-after-free problem happens when the timer callback function sco_sock_timeout() accesses the socket. Here's the call trace: dump_stack+0x107/0x163 ? refcount_inc+0x1c/ print_address_description.constprop.0+0x1c/0x47e ? refcount_inc+0x1c/0x7b kasan_report+0x13a/0x173 ? refcount_inc+0x1c/0x7b check_memory_region+0x132/0x139 refcount_inc+0x1c/0x7b sco_sock_timeout+0xb2/0x1ba process_one_work+0x739/0xbd1 ? cancel_delayed_work+0x13f/0x13f ? __raw_spin_lock_init+0xf0/0xf0 ? to_kthread+0x59/0x85 worker_thread+0x593/0x70e kthread+0x346/0x35a ? drain_workqueue+0x31a/0x31a ? kthread_bind+0x4b/0x4b ret_from_fork+0x1f/0x30 CVE-2022-49474 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix array-index-out-of-bounds in pvr2_i2c_core_init Syzbot reported that -1 is used as array index. The problem was in missing validation check. hdw->unit_number is initialized with -1 and then if init table walk fails this value remains unchanged. Since code blindly uses this member for array indexing adding sanity check is the easiest fix for that. hdw->workpoll initialization moved upper to prevent warning in __flush_work. CVE-2022-49478 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/msm/mdp5: Return error code in mdp5_mixer_release when deadlock is detected There is a possibility for mdp5_get_global_state to return -EDEADLK when acquiring the modeset lock, but currently global_state in mdp5_mixer_release doesn't check for if an error is returned. To avoid a NULL dereference error, let's have mdp5_mixer_release check if an error is returned and propagate that error. Patchwork: https://patchwork.freedesktop.org/patch/485181/ CVE-2022-49488 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/msm/disp/dpu1: set vbif hw config to NULL to avoid use after memory free during pm runtime resume BUG: Unable to handle kernel paging request at virtual address 006b6b6b6b6b6be3 Call trace: dpu_vbif_init_memtypes+0x40/0xb8 dpu_runtime_resume+0xcc/0x1c0 pm_generic_runtime_resume+0x30/0x44 __genpd_runtime_resume+0x68/0x7c genpd_runtime_resume+0x134/0x258 __rpm_callback+0x98/0x138 rpm_callback+0x30/0x88 rpm_resume+0x36c/0x49c __pm_runtime_resume+0x80/0xb0 dpu_core_irq_uninstall+0x30/0xb0 dpu_irq_uninstall+0x18/0x24 msm_drm_uninit+0xd8/0x16c Patchwork: https://patchwork.freedesktop.org/patch/483255/ [DB: fixed Fixes tag] CVE-2022-49489 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: vop: fix possible null-ptr-deref in vop_bind() It will cause null-ptr-deref in resource_size(), if platform_get_resource() returns NULL, move calling resource_size() after devm_ioremap_resource() that will check 'res' to avoid null-ptr-deref. CVE-2022-49491 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: nvme-pci: fix a NULL pointer dereference in nvme_alloc_admin_tags In nvme_alloc_admin_tags, the admin_q can be set to an error (typically -ENOMEM) if the blk_mq_init_queue call fails to set up the queue, which is checked immediately after the call. However, when we return the error message up the stack, to nvme_reset_work the error takes us to nvme_remove_dead_ctrl() nvme_dev_disable() nvme_suspend_queue(&dev->queues[0]). Here, we only check that the admin_q is non-NULL, rather than not an error or NULL, and begin quiescing a queue that never existed, leading to bad / NULL pointer dereference. CVE-2022-49492 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/msm/hdmi: check return value after calling platform_get_resource_byname() It will cause null-ptr-deref if platform_get_resource_byname() returns NULL, we need check the return value. Patchwork: https://patchwork.freedesktop.org/patch/482992/ CVE-2022-49495 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: remove two BUG() from skb_checksum_help() I have a syzbot report that managed to get a crash in skb_checksum_help() If syzbot can trigger these BUG(), it makes sense to replace them with more friendly WARN_ON_ONCE() since skb_checksum_help() can instead return an error code. Note that syzbot will still crash there, until real bug is fixed. CVE-2022-49497 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ath9k_htc: fix potential out of bounds access with invalid rxstatus->rs_keyix The "rxstatus->rs_keyix" eventually gets passed to test_bit() so we need to ensure that it is within the bitmap. drivers/net/wireless/ath/ath9k/common.c:46 ath9k_cmn_rx_accept() error: passing untrusted data 'rx_stats->rs_keyix' to 'test_bit()' CVE-2022-49503 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Inhibit aborts if external loopback plug is inserted After running a short external loopback test, when the external loopback is removed and a normal cable inserted that is directly connected to a target device, the system oops in the llpfc_set_rrq_active() routine. When the loopback was inserted an FLOGI was transmit. As we're looped back, we receive the FLOGI request. The FLOGI is ABTS'd as we recognize the same wppn thus understand it's a loopback. However, as the ABTS sends address information the port is not set to (fffffe), the ABTS is dropped on the wire. A short 1 frame loopback test is run and completes before the ABTS times out. The looback is unplugged and the new cable plugged in, and the an FLOGI to the new device occurs and completes. Due to a mixup in ref counting the completion of the new FLOGI releases the fabric ndlp. Then the original ABTS completes and references the released ndlp generating the oops. Correct by no-op'ing the ABTS when in loopback mode (it will be dropped anyway). Added a flag to track the mode to recognize when it should be no-op'd. CVE-2022-49504 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: NFC: NULL out the dev->rfkill to prevent UAF Commit 3e3b5dfcd16a ("NFC: reorder the logic in nfc_{un,}register_device") assumes the device_is_registered() in function nfc_dev_up() will help to check when the rfkill is unregistered. However, this check only take effect when device_del(&dev->dev) is done in nfc_unregister_device(). Hence, the rfkill object is still possible be dereferenced. The crash trace in latest kernel (5.18-rc2): [ 68.760105] ================================================================== [ 68.760330] BUG: KASAN: use-after-free in __lock_acquire+0x3ec1/0x6750 [ 68.760756] Read of size 8 at addr ffff888009c93018 by task fuzz/313 [ 68.760756] [ 68.760756] CPU: 0 PID: 313 Comm: fuzz Not tainted 5.18.0-rc2 #4 [ 68.760756] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 68.760756] Call Trace: [ 68.760756] <TASK> [ 68.760756] dump_stack_lvl+0x57/0x7d [ 68.760756] print_report.cold+0x5e/0x5db [ 68.760756] ? __lock_acquire+0x3ec1/0x6750 [ 68.760756] kasan_report+0xbe/0x1c0 [ 68.760756] ? __lock_acquire+0x3ec1/0x6750 [ 68.760756] __lock_acquire+0x3ec1/0x6750 [ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410 [ 68.760756] ? register_lock_class+0x18d0/0x18d0 [ 68.760756] lock_acquire+0x1ac/0x4f0 [ 68.760756] ? rfkill_blocked+0xe/0x60 [ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410 [ 68.760756] ? mutex_lock_io_nested+0x12c0/0x12c0 [ 68.760756] ? nla_get_range_signed+0x540/0x540 [ 68.760756] ? _raw_spin_lock_irqsave+0x4e/0x50 [ 68.760756] _raw_spin_lock_irqsave+0x39/0x50 [ 68.760756] ? rfkill_blocked+0xe/0x60 [ 68.760756] rfkill_blocked+0xe/0x60 [ 68.760756] nfc_dev_up+0x84/0x260 [ 68.760756] nfc_genl_dev_up+0x90/0xe0 [ 68.760756] genl_family_rcv_msg_doit+0x1f4/0x2f0 [ 68.760756] ? genl_family_rcv_msg_attrs_parse.constprop.0+0x230/0x230 [ 68.760756] ? security_capable+0x51/0x90 [ 68.760756] genl_rcv_msg+0x280/0x500 [ 68.760756] ? genl_get_cmd+0x3c0/0x3c0 [ 68.760756] ? lock_acquire+0x1ac/0x4f0 [ 68.760756] ? nfc_genl_dev_down+0xe0/0xe0 [ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410 [ 68.760756] netlink_rcv_skb+0x11b/0x340 [ 68.760756] ? genl_get_cmd+0x3c0/0x3c0 [ 68.760756] ? netlink_ack+0x9c0/0x9c0 [ 68.760756] ? netlink_deliver_tap+0x136/0xb00 [ 68.760756] genl_rcv+0x1f/0x30 [ 68.760756] netlink_unicast+0x430/0x710 [ 68.760756] ? memset+0x20/0x40 [ 68.760756] ? netlink_attachskb+0x740/0x740 [ 68.760756] ? __build_skb_around+0x1f4/0x2a0 [ 68.760756] netlink_sendmsg+0x75d/0xc00 [ 68.760756] ? netlink_unicast+0x710/0x710 [ 68.760756] ? netlink_unicast+0x710/0x710 [ 68.760756] sock_sendmsg+0xdf/0x110 [ 68.760756] __sys_sendto+0x19e/0x270 [ 68.760756] ? __ia32_sys_getpeername+0xa0/0xa0 [ 68.760756] ? fd_install+0x178/0x4c0 [ 68.760756] ? fd_install+0x195/0x4c0 [ 68.760756] ? kernel_fpu_begin_mask+0x1c0/0x1c0 [ 68.760756] __x64_sys_sendto+0xd8/0x1b0 [ 68.760756] ? lockdep_hardirqs_on+0xbf/0x130 [ 68.760756] ? syscall_enter_from_user_mode+0x1d/0x50 [ 68.760756] do_syscall_64+0x3b/0x90 [ 68.760756] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 68.760756] RIP: 0033:0x7f67fb50e6b3 ... [ 68.760756] RSP: 002b:00007f67fa91fe90 EFLAGS: 00000293 ORIG_RAX: 000000000000002c [ 68.760756] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f67fb50e6b3 [ 68.760756] RDX: 000000000000001c RSI: 0000559354603090 RDI: 0000000000000003 [ 68.760756] RBP: 00007f67fa91ff00 R08: 00007f67fa91fedc R09: 000000000000000c [ 68.760756] R10: 0000000000000000 R11: 0000000000000293 R12: 00007ffe824d496e [ 68.760756] R13: 00007ffe824d496f R14: 00007f67fa120000 R15: 0000000000000003 [ 68.760756] </TASK> [ 68.760756] [ 68.760756] Allocated by task 279: [ 68.760756] kasan_save_stack+0x1e/0x40 [ ---truncated--- CVE-2022-49505 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: cpufreq: governor: Use kobject release() method to free dbs_data The struct dbs_data embeds a struct gov_attr_set and the struct gov_attr_set embeds a kobject. Since every kobject must have a release() method and we can't use kfree() to free it directly, so introduce cpufreq_dbs_data_release() to release the dbs_data via the kobject::release() method. This fixes the calltrace like below: ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x34 WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100 Modules linked in: CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536 Hardware name: Marvell OcteonTX CN96XX board (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : debug_print_object+0xb8/0x100 lr : debug_print_object+0xb8/0x100 sp : ffff80001dfcf9a0 x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000 x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210 x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118 x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000 x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8 x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14 x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0 x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001 x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040 Call trace: debug_print_object+0xb8/0x100 __debug_check_no_obj_freed+0x1d0/0x25c debug_check_no_obj_freed+0x24/0xa0 kfree+0x11c/0x440 cpufreq_dbs_governor_exit+0xa8/0xac cpufreq_exit_governor+0x44/0x90 cpufreq_set_policy+0x29c/0x570 store_scaling_governor+0x110/0x154 store+0xb0/0xe0 sysfs_kf_write+0x58/0x84 kernfs_fop_write_iter+0x12c/0x1c0 new_sync_write+0xf0/0x18c vfs_write+0x1cc/0x220 ksys_write+0x74/0x100 __arm64_sys_write+0x28/0x3c invoke_syscall.constprop.0+0x58/0xf0 do_el0_svc+0x70/0x170 el0_svc+0x54/0x190 el0t_64_sync_handler+0xa4/0x130 el0t_64_sync+0x1a0/0x1a4 irq event stamp: 189006 hardirqs last enabled at (189005): [<ffff8000080849d0>] finish_task_switch.isra.0+0xe0/0x2c0 hardirqs last disabled at (189006): [<ffff8000090667a4>] el1_dbg+0x24/0xa0 softirqs last enabled at (188966): [<ffff8000080106d0>] __do_softirq+0x4b0/0x6a0 softirqs last disabled at (188957): [<ffff80000804a618>] __irq_exit_rcu+0x108/0x1a4 [ rjw: Because can be freed by the gov_attr_set_put() in cpufreq_dbs_governor_exit() now, it is also necessary to put the invocation of the governor ->exit() callback into the new cpufreq_dbs_data_release() function. ] CVE-2022-49513 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ice: always check VF VSI pointer values The ice_get_vf_vsi function can return NULL in some cases, such as if handling messages during a reset where the VSI is being removed and recreated. Several places throughout the driver do not bother to check whether this VSI pointer is valid. Static analysis tools maybe report issues because they detect paths where a potentially NULL pointer could be dereferenced. Fix this by checking the return value of ice_get_vf_vsi everywhere. CVE-2022-49516 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ath10k: skip ath10k_halt during suspend for driver state RESTARTING Double free crash is observed when FW recovery(caused by wmi timeout/crash) is followed by immediate suspend event. The FW recovery is triggered by ath10k_core_restart() which calls driver clean up via ath10k_halt(). When the suspend event occurs between the FW recovery, the restart worker thread is put into frozen state until suspend completes. The suspend event triggers ath10k_stop() which again triggers ath10k_halt() The double invocation of ath10k_halt() causes ath10k_htt_rx_free() to be called twice(Note: ath10k_htt_rx_alloc was not called by restart worker thread because of its frozen state), causing the crash. To fix this, during the suspend flow, skip call to ath10k_halt() in ath10k_stop() when the current driver state is ATH10K_STATE_RESTARTING. Also, for driver state ATH10K_STATE_RESTARTING, call ath10k_wait_for_suspend() in ath10k_stop(). This is because call to ath10k_wait_for_suspend() is skipped later in [ath10k_halt() > ath10k_core_stop()] for the driver state ATH10K_STATE_RESTARTING. The frozen restart worker thread will be cancelled during resume when the device comes out of suspend. Below is the crash stack for reference: [ 428.469167] ------------[ cut here ]------------ [ 428.469180] kernel BUG at mm/slub.c:4150! [ 428.469193] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 428.469219] Workqueue: events_unbound async_run_entry_fn [ 428.469230] RIP: 0010:kfree+0x319/0x31b [ 428.469241] RSP: 0018:ffffa1fac015fc30 EFLAGS: 00010246 [ 428.469247] RAX: ffffedb10419d108 RBX: ffff8c05262b0000 [ 428.469252] RDX: ffff8c04a8c07000 RSI: 0000000000000000 [ 428.469256] RBP: ffffa1fac015fc78 R08: 0000000000000000 [ 428.469276] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 428.469285] Call Trace: [ 428.469295] ? dma_free_attrs+0x5f/0x7d [ 428.469320] ath10k_core_stop+0x5b/0x6f [ 428.469336] ath10k_halt+0x126/0x177 [ 428.469352] ath10k_stop+0x41/0x7e [ 428.469387] drv_stop+0x88/0x10e [ 428.469410] __ieee80211_suspend+0x297/0x411 [ 428.469441] rdev_suspend+0x6e/0xd0 [ 428.469462] wiphy_suspend+0xb1/0x105 [ 428.469483] ? name_show+0x2d/0x2d [ 428.469490] dpm_run_callback+0x8c/0x126 [ 428.469511] ? name_show+0x2d/0x2d [ 428.469517] __device_suspend+0x2e7/0x41b [ 428.469523] async_suspend+0x1f/0x93 [ 428.469529] async_run_entry_fn+0x3d/0xd1 [ 428.469535] process_one_work+0x1b1/0x329 [ 428.469541] worker_thread+0x213/0x372 [ 428.469547] kthread+0x150/0x15f [ 428.469552] ? pr_cont_work+0x58/0x58 [ 428.469558] ? kthread_blkcg+0x31/0x31 Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1 CVE-2022-49519 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix resource leak in lpfc_sli4_send_seq_to_ulp() If no handler is found in lpfc_complete_unsol_iocb() to match the rctl of a received frame, the frame is dropped and resources are leaked. Fix by returning resources when discarding an unhandled frame type. Update lpfc_fc_frame_check() handling of NOP basic link service. CVE-2022-49521 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: pci: cx23885: Fix the error handling in cx23885_initdev() When the driver fails to call the dma_set_mask(), the driver will get the following splat: [ 55.853884] BUG: KASAN: use-after-free in __process_removed_driver+0x3c/0x240 [ 55.854486] Read of size 8 at addr ffff88810de60408 by task modprobe/590 [ 55.856822] Call Trace: [ 55.860327] __process_removed_driver+0x3c/0x240 [ 55.861347] bus_for_each_dev+0x102/0x160 [ 55.861681] i2c_del_driver+0x2f/0x50 This is because the driver has initialized the i2c related resources in cx23885_dev_setup() but not released them in error handling, fix this bug by modifying the error path that jumps after failing to call the dma_set_mask(). CVE-2022-49524 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: cx25821: Fix the warning when removing the module When removing the module, we will get the following warning: [ 14.746697] remove_proc_entry: removing non-empty directory 'irq/21', leaking at least 'cx25821[1]' [ 14.747449] WARNING: CPU: 4 PID: 368 at fs/proc/generic.c:717 remove_proc_entry+0x389/0x3f0 [ 14.751611] RIP: 0010:remove_proc_entry+0x389/0x3f0 [ 14.759589] Call Trace: [ 14.759792] <TASK> [ 14.759975] unregister_irq_proc+0x14c/0x170 [ 14.760340] irq_free_descs+0x94/0xe0 [ 14.760640] mp_unmap_irq+0xb6/0x100 [ 14.760937] acpi_unregister_gsi_ioapic+0x27/0x40 [ 14.761334] acpi_pci_irq_disable+0x1d3/0x320 [ 14.761688] pci_disable_device+0x1ad/0x380 [ 14.762027] ? _raw_spin_unlock_irqrestore+0x2d/0x60 [ 14.762442] ? cx25821_shutdown+0x20/0x9f0 [cx25821] [ 14.762848] cx25821_finidev+0x48/0xc0 [cx25821] [ 14.763242] pci_device_remove+0x92/0x240 Fix this by freeing the irq before call pci_disable_device(). CVE-2022-49525 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: md/bitmap: don't set sb values if can't pass sanity check If bitmap area contains invalid data, kernel will crash then mdadm triggers "Segmentation fault". This is cluster-md speical bug. In non-clustered env, mdadm will handle broken metadata case. In clustered array, only kernel space handles bitmap slot info. But even this bug only happened in clustered env, current sanity check is wrong, the code should be changed. How to trigger: (faulty injection) dd if=/dev/zero bs=1M count=1 oflag=direct of=/dev/sda dd if=/dev/zero bs=1M count=1 oflag=direct of=/dev/sdb mdadm -C /dev/md0 -b clustered -e 1.2 -n 2 -l mirror /dev/sda /dev/sdb mdadm -Ss echo aaa > magic.txt == below modifying slot 2 bitmap data == dd if=magic.txt of=/dev/sda seek=16384 bs=1 count=3 <== destroy magic dd if=/dev/zero of=/dev/sda seek=16436 bs=1 count=4 <== ZERO chunksize mdadm -A /dev/md0 /dev/sda /dev/sdb == kernel crashes. mdadm outputs "Segmentation fault" == Reason of kernel crash: In md_bitmap_read_sb (called by md_bitmap_create), bad bitmap magic didn't block chunksize assignment, and zero value made DIV_ROUND_UP_SECTOR_T() trigger "divide error". Crash log: kernel: md: md0 stopped. kernel: md/raid1:md0: not clean -- starting background reconstruction kernel: md/raid1:md0: active with 2 out of 2 mirrors kernel: dlm: ... ... kernel: md-cluster: Joined cluster 44810aba-38bb-e6b8-daca-bc97a0b254aa slot 1 kernel: md0: invalid bitmap file superblock: bad magic kernel: md_bitmap_copy_from_slot can't get bitmap from slot 2 kernel: md-cluster: Could not gather bitmaps from slot 2 kernel: divide error: 0000 [#1] SMP NOPTI kernel: CPU: 0 PID: 1603 Comm: mdadm Not tainted 5.14.6-1-default kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) kernel: RIP: 0010:md_bitmap_create+0x1d1/0x850 [md_mod] kernel: RSP: 0018:ffffc22ac0843ba0 EFLAGS: 00010246 kernel: ... ... kernel: Call Trace: kernel: ? dlm_lock_sync+0xd0/0xd0 [md_cluster 77fe..7a0] kernel: md_bitmap_copy_from_slot+0x2c/0x290 [md_mod 24ea..d3a] kernel: load_bitmaps+0xec/0x210 [md_cluster 77fe..7a0] kernel: md_bitmap_load+0x81/0x1e0 [md_mod 24ea..d3a] kernel: do_md_run+0x30/0x100 [md_mod 24ea..d3a] kernel: md_ioctl+0x1290/0x15a0 [md_mod 24ea....d3a] kernel: ? mddev_unlock+0xaa/0x130 [md_mod 24ea..d3a] kernel: ? blkdev_ioctl+0xb1/0x2b0 kernel: block_ioctl+0x3b/0x40 kernel: __x64_sys_ioctl+0x7f/0xb0 kernel: do_syscall_64+0x59/0x80 kernel: ? exit_to_user_mode_prepare+0x1ab/0x230 kernel: ? syscall_exit_to_user_mode+0x18/0x40 kernel: ? do_syscall_64+0x69/0x80 kernel: entry_SYSCALL_64_after_hwframe+0x44/0xae kernel: RIP: 0033:0x7f4a15fa722b kernel: ... ... kernel: ---[ end trace 8afa7612f559c868 ]--- kernel: RIP: 0010:md_bitmap_create+0x1d1/0x850 [md_mod] CVE-2022-49526 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: fix double free in si_parse_power_table() In function si_parse_power_table(), array adev->pm.dpm.ps and its member is allocated. If the allocation of each member fails, the array itself is freed and returned with an error code. However, the array is later freed again in si_dpm_fini() function which is called when the function returns an error. This leads to potential double free of the array adev->pm.dpm.ps, as well as leak of its array members, since the members are not freed in the allocation function and the array is not nulled when freed. In addition adev->pm.dpm.num_ps, which keeps track of the allocated array member, is not updated until the member allocation is successfully finished, this could also lead to either use after free, or uninitialized variable access in si_dpm_fini(). Fix this by postponing the free of the array until si_dpm_fini() and increment adev->pm.dpm.num_ps everytime the array member is allocated. CVE-2022-49530 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/virtio: fix NULL pointer dereference in virtio_gpu_conn_get_modes drm_cvt_mode may return NULL and we should check it. This bug is found by syzkaller: FAULT_INJECTION stacktrace: [ 168.567394] FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 1 [ 168.567403] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1 [ 168.567406] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 168.567408] Call trace: [ 168.567414] dump_backtrace+0x0/0x310 [ 168.567418] show_stack+0x28/0x38 [ 168.567423] dump_stack+0xec/0x15c [ 168.567427] should_fail+0x3ac/0x3d0 [ 168.567437] __should_failslab+0xb8/0x120 [ 168.567441] should_failslab+0x28/0xc0 [ 168.567445] kmem_cache_alloc_trace+0x50/0x640 [ 168.567454] drm_mode_create+0x40/0x90 [ 168.567458] drm_cvt_mode+0x48/0xc78 [ 168.567477] virtio_gpu_conn_get_modes+0xa8/0x140 [virtio_gpu] [ 168.567485] drm_helper_probe_single_connector_modes+0x3a4/0xd80 [ 168.567492] drm_mode_getconnector+0x2e0/0xa70 [ 168.567496] drm_ioctl_kernel+0x11c/0x1d8 [ 168.567514] drm_ioctl+0x558/0x6d0 [ 168.567522] do_vfs_ioctl+0x160/0xf30 [ 168.567525] ksys_ioctl+0x98/0xd8 [ 168.567530] __arm64_sys_ioctl+0x50/0xc8 [ 168.567536] el0_svc_common+0xc8/0x320 [ 168.567540] el0_svc_handler+0xf8/0x160 [ 168.567544] el0_svc+0x10/0x218 KASAN stacktrace: [ 168.567561] BUG: KASAN: null-ptr-deref in virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu] [ 168.567565] Read of size 4 at addr 0000000000000054 by task syz/6425 [ 168.567566] [ 168.567571] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1 [ 168.567573] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 168.567575] Call trace: [ 168.567578] dump_backtrace+0x0/0x310 [ 168.567582] show_stack+0x28/0x38 [ 168.567586] dump_stack+0xec/0x15c [ 168.567591] kasan_report+0x244/0x2f0 [ 168.567594] __asan_load4+0x58/0xb0 [ 168.567607] virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu] [ 168.567612] drm_helper_probe_single_connector_modes+0x3a4/0xd80 [ 168.567617] drm_mode_getconnector+0x2e0/0xa70 [ 168.567621] drm_ioctl_kernel+0x11c/0x1d8 [ 168.567624] drm_ioctl+0x558/0x6d0 [ 168.567628] do_vfs_ioctl+0x160/0xf30 [ 168.567632] ksys_ioctl+0x98/0xd8 [ 168.567636] __arm64_sys_ioctl+0x50/0xc8 [ 168.567641] el0_svc_common+0xc8/0x320 [ 168.567645] el0_svc_handler+0xf8/0x160 [ 168.567649] el0_svc+0x10/0x218 CVE-2022-49532 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Protect memory leak for NPIV ports sending PLOGI_RJT There is a potential memory leak in lpfc_ignore_els_cmpl() and lpfc_els_rsp_reject() that was allocated from NPIV PLOGI_RJT (lpfc_rcv_plogi()'s login_mbox). Check if cmdiocb->context_un.mbox was allocated in lpfc_ignore_els_cmpl(), and then free it back to phba->mbox_mem_pool along with mbox->ctx_buf for service parameters. For lpfc_els_rsp_reject() failure, free both the ctx_buf for service parameters and the login_mbox. CVE-2022-49534 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 low In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix null pointer dereference after failing to issue FLOGI and PLOGI If lpfc_issue_els_flogi() fails and returns non-zero status, the node reference count is decremented to trigger the release of the nodelist structure. However, if there is a prior registration or dev-loss-evt work pending, the node may be released prematurely. When dev-loss-evt completes, the released node is referenced causing a use-after-free null pointer dereference. Similarly, when processing non-zero ELS PLOGI completion status in lpfc_cmpl_els_plogi(), the ndlp flags are checked for a transport registration before triggering node removal. If dev-loss-evt work is pending, the node may be released prematurely and a subsequent call to lpfc_dev_loss_tmo_handler() results in a use after free ndlp dereference. Add test for pending dev-loss before decrementing the node reference count for FLOGI, PLOGI, PRLI, and ADISC handling. CVE-2022-49535 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix SCSI I/O completion and abort handler deadlock During stress I/O tests with 500+ vports, hard LOCKUP call traces are observed. CPU A: native_queued_spin_lock_slowpath+0x192 _raw_spin_lock_irqsave+0x32 lpfc_handle_fcp_err+0x4c6 lpfc_fcp_io_cmd_wqe_cmpl+0x964 lpfc_sli4_fp_handle_cqe+0x266 __lpfc_sli4_process_cq+0x105 __lpfc_sli4_hba_process_cq+0x3c lpfc_cq_poll_hdler+0x16 irq_poll_softirq+0x76 __softirqentry_text_start+0xe4 irq_exit+0xf7 do_IRQ+0x7f CPU B: native_queued_spin_lock_slowpath+0x5b _raw_spin_lock+0x1c lpfc_abort_handler+0x13e scmd_eh_abort_handler+0x85 process_one_work+0x1a7 worker_thread+0x30 kthread+0x112 ret_from_fork+0x1f Diagram of lockup: CPUA CPUB ---- ---- lpfc_cmd->buf_lock phba->hbalock lpfc_cmd->buf_lock phba->hbalock Fix by reordering the taking of the lpfc_cmd->buf_lock and phba->hbalock in lpfc_abort_handler routine so that it tries to take the lpfc_cmd->buf_lock first before phba->hbalock. CVE-2022-49536 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix call trace observed during I/O with CMF enabled The following was seen with CMF enabled: BUG: using smp_processor_id() in preemptible code: systemd-udevd/31711 kernel: caller is lpfc_update_cmf_cmd+0x214/0x420 [lpfc] kernel: CPU: 12 PID: 31711 Comm: systemd-udevd kernel: Call Trace: kernel: <TASK> kernel: dump_stack_lvl+0x44/0x57 kernel: check_preemption_disabled+0xbf/0xe0 kernel: lpfc_update_cmf_cmd+0x214/0x420 [lpfc] kernel: lpfc_nvme_fcp_io_submit+0x23b4/0x4df0 [lpfc] this_cpu_ptr() calls smp_processor_id() in a preemptible context. Fix by using per_cpu_ptr() with raw_smp_processor_id() instead. CVE-2022-49537 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ALSA: jack: Access input_dev under mutex It is possible when using ASoC that input_dev is unregistered while calling snd_jack_report, which causes NULL pointer dereference. In order to prevent this serialize access to input_dev using mutex lock. CVE-2022-49538 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Move cfg_log_verbose check before calling lpfc_dmp_dbg() In an attempt to log message 0126 with LOG_TRACE_EVENT, the following hard lockup call trace hangs the system. Call Trace: _raw_spin_lock_irqsave+0x32/0x40 lpfc_dmp_dbg.part.32+0x28/0x220 [lpfc] lpfc_cmpl_els_fdisc+0x145/0x460 [lpfc] lpfc_sli_cancel_jobs+0x92/0xd0 [lpfc] lpfc_els_flush_cmd+0x43c/0x670 [lpfc] lpfc_els_flush_all_cmd+0x37/0x60 [lpfc] lpfc_sli4_async_event_proc+0x956/0x1720 [lpfc] lpfc_do_work+0x1485/0x1d70 [lpfc] kthread+0x112/0x130 ret_from_fork+0x1f/0x40 Kernel panic - not syncing: Hard LOCKUP The same CPU tries to claim the phba->port_list_lock twice. Move the cfg_log_verbose checks as part of the lpfc_printf_vlog() and lpfc_printf_log() macros before calling lpfc_dmp_dbg(). There is no need to take the phba->port_list_lock within lpfc_dmp_dbg(). CVE-2022-49542 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ipw2x00: Fix potential NULL dereference in libipw_xmit() crypt and crypt->ops could be null, so we need to checking null before dereference CVE-2022-49544 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Cancel pending work at closing a MIDI substream At closing a USB MIDI output substream, there might be still a pending work, which would eventually access the rawmidi runtime object that is being released. For fixing the race, make sure to cancel the pending work at closing. CVE-2022-49545 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 important In the Linux kernel, the following vulnerability has been resolved: x86/kexec: fix memory leak of elf header buffer This is reported by kmemleak detector: unreferenced object 0xffffc900002a9000 (size 4096): comm "kexec", pid 14950, jiffies 4295110793 (age 373.951s) hex dump (first 32 bytes): 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 .ELF............ 04 00 3e 00 01 00 00 00 00 00 00 00 00 00 00 00 ..>............. backtrace: [<0000000016a8ef9f>] __vmalloc_node_range+0x101/0x170 [<000000002b66b6c0>] __vmalloc_node+0xb4/0x160 [<00000000ad40107d>] crash_prepare_elf64_headers+0x8e/0xcd0 [<0000000019afff23>] crash_load_segments+0x260/0x470 [<0000000019ebe95c>] bzImage64_load+0x814/0xad0 [<0000000093e16b05>] arch_kexec_kernel_image_load+0x1be/0x2a0 [<000000009ef2fc88>] kimage_file_alloc_init+0x2ec/0x5a0 [<0000000038f5a97a>] __do_sys_kexec_file_load+0x28d/0x530 [<0000000087c19992>] do_syscall_64+0x3b/0x90 [<0000000066e063a4>] entry_SYSCALL_64_after_hwframe+0x44/0xae In crash_prepare_elf64_headers(), a buffer is allocated via vmalloc() to store elf headers. While it's not freed back to system correctly when kdump kernel is reloaded or unloaded. Then memory leak is caused. Fix it by introducing x86 specific function arch_kimage_file_post_load_cleanup(), and freeing the buffer there. And also remove the incorrect elf header buffer freeing code. Before calling arch specific kexec_file loading function, the image instance has been initialized. So 'image->elf_headers' must be NULL. It doesn't make sense to free the elf header buffer in the place. Three different people have reported three bugs about the memory leak on x86_64 inside Redhat. CVE-2022-49546 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 low In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_qca: Use del_timer_sync() before freeing While looking at a crash report on a timer list being corrupted, which usually happens when a timer is freed while still active. This is commonly triggered by code calling del_timer() instead of del_timer_sync() just before freeing. One possible culprit is the hci_qca driver, which does exactly that. Eric mentioned that wake_retrans_timer could be rearmed via the work queue, so also move the destruction of the work queue before del_timer_sync(). CVE-2022-49555 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack: re-fetch conntrack after insertion In case the conntrack is clashing, insertion can free skb->_nfct and set skb->_nfct to the already-confirmed entry. This wasn't found before because the conntrack entry and the extension space used to free'd after an rcu grace period, plus the race needs events enabled to trigger. CVE-2022-49561 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: crypto: qat - add param check for RSA Reject requests with a source buffer that is bigger than the size of the key. This is to prevent a possible integer underflow that might happen when copying the source scatterlist into a linear buffer. CVE-2022-49563 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 important In the Linux kernel, the following vulnerability has been resolved: crypto: qat - add param check for DH Reject requests with a source buffer that is bigger than the size of the key. This is to prevent a possible integer underflow that might happen when copying the source scatterlist into a linear buffer. CVE-2022-49564 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 important In the Linux kernel, the following vulnerability has been resolved: crypto: qat - fix memory leak in RSA When an RSA key represented in form 2 (as defined in PKCS #1 V2.1) is used, some components of the private key persist even after the TFM is released. Replace the explicit calls to free the buffers in qat_rsa_exit_tfm() with a call to qat_rsa_clear_ctx() which frees all buffers referenced in the TFM context. CVE-2022-49566 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ip: Fix data-races around sysctl_ip_prot_sock. sysctl_ip_prot_sock is accessed concurrently, and there is always a chance of data-race. So, all readers and writers need some basic protection to avoid load/store-tearing. CVE-2022-49578 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: be2net: Fix buffer overflow in be_get_module_eeprom be_cmd_read_port_transceiver_data assumes that it is given a buffer that is at least PAGE_DATA_LEN long, or twice that if the module supports SFF 8472. However, this is not always the case. Fix this by passing the desired offset and length to be_cmd_read_port_transceiver_data so that we only copy the bytes once. CVE-2022-49581 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ixgbe: Add locking to prevent panic when setting sriov_numvfs to zero It is possible to disable VFs while the PF driver is processing requests from the VF driver. This can result in a panic. BUG: unable to handle kernel paging request at 000000000000106c PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 8 PID: 0 Comm: swapper/8 Kdump: loaded Tainted: G I --------- - Hardware name: Dell Inc. PowerEdge R740/06WXJT, BIOS 2.8.2 08/27/2020 RIP: 0010:ixgbe_msg_task+0x4c8/0x1690 [ixgbe] Code: 00 00 48 8d 04 40 48 c1 e0 05 89 7c 24 24 89 fd 48 89 44 24 10 83 ff 01 0f 84 b8 04 00 00 4c 8b 64 24 10 4d 03 a5 48 22 00 00 <41> 80 7c 24 4c 00 0f 84 8a 03 00 00 0f b7 c7 83 f8 08 0f 84 8f 0a RSP: 0018:ffffb337869f8df8 EFLAGS: 00010002 RAX: 0000000000001020 RBX: 0000000000000000 RCX: 000000000000002b RDX: 0000000000000002 RSI: 0000000000000008 RDI: 0000000000000006 RBP: 0000000000000006 R08: 0000000000000002 R09: 0000000000029780 R10: 00006957d8f42832 R11: 0000000000000000 R12: 0000000000001020 R13: ffff8a00e8978ac0 R14: 000000000000002b R15: ffff8a00e8979c80 FS: 0000000000000000(0000) GS:ffff8a07dfd00000(0000) knlGS:00000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000106c CR3: 0000000063e10004 CR4: 00000000007726e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> ? ttwu_do_wakeup+0x19/0x140 ? try_to_wake_up+0x1cd/0x550 ? ixgbevf_update_xcast_mode+0x71/0xc0 [ixgbevf] ixgbe_msix_other+0x17e/0x310 [ixgbe] __handle_irq_event_percpu+0x40/0x180 handle_irq_event_percpu+0x30/0x80 handle_irq_event+0x36/0x53 handle_edge_irq+0x82/0x190 handle_irq+0x1c/0x30 do_IRQ+0x49/0xd0 common_interrupt+0xf/0xf This can be eventually be reproduced with the following script: while : do echo 63 > /sys/class/net/<devname>/device/sriov_numvfs sleep 1 echo 0 > /sys/class/net/<devname>/device/sriov_numvfs sleep 1 done Add lock when disabling SR-IOV to prevent process VF mailbox communication. CVE-2022-49584 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: igmp: Fix data-races around sysctl_igmp_qrv. While reading sysctl_igmp_qrv, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers. This test can be packed into a helper, so such changes will be in the follow-up series after net is merged into net-next. qrv ?: READ_ONCE(net->ipv4.sysctl_igmp_qrv); CVE-2022-49589 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: igmp: Fix data-races around sysctl_igmp_llm_reports. While reading sysctl_igmp_llm_reports, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers. This test can be packed into a helper, so such changes will be in the follow-up series after net is merged into net-next. if (ipv4_is_local_multicast(pmc->multiaddr) && !READ_ONCE(net->ipv4.sysctl_igmp_llm_reports)) CVE-2022-49590 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix dma queue left shift overflow issue When queue number is > 4, left shift overflows due to 32 bits integer variable. Mask calculation is wrong for MTL_RXQ_DMA_MAP1. If CONFIG_UBSAN is enabled, kernel dumps below warning: [ 10.363842] ================================================================== [ 10.363882] UBSAN: shift-out-of-bounds in /build/linux-intel-iotg-5.15-8e6Tf4/ linux-intel-iotg-5.15-5.15.0/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c:224:12 [ 10.363929] shift exponent 40 is too large for 32-bit type 'unsigned int' [ 10.363953] CPU: 1 PID: 599 Comm: NetworkManager Not tainted 5.15.0-1003-intel-iotg [ 10.363956] Hardware name: ADLINK Technology Inc. LEC-EL/LEC-EL, BIOS 0.15.11 12/22/2021 [ 10.363958] Call Trace: [ 10.363960] <TASK> [ 10.363963] dump_stack_lvl+0x4a/0x5f [ 10.363971] dump_stack+0x10/0x12 [ 10.363974] ubsan_epilogue+0x9/0x45 [ 10.363976] __ubsan_handle_shift_out_of_bounds.cold+0x61/0x10e [ 10.363979] ? wake_up_klogd+0x4a/0x50 [ 10.363983] ? vprintk_emit+0x8f/0x240 [ 10.363986] dwmac4_map_mtl_dma.cold+0x42/0x91 [stmmac] [ 10.364001] stmmac_mtl_configuration+0x1ce/0x7a0 [stmmac] [ 10.364009] ? dwmac410_dma_init_channel+0x70/0x70 [stmmac] [ 10.364020] stmmac_hw_setup.cold+0xf/0xb14 [stmmac] [ 10.364030] ? page_pool_alloc_pages+0x4d/0x70 [ 10.364034] ? stmmac_clear_tx_descriptors+0x6e/0xe0 [stmmac] [ 10.364042] stmmac_open+0x39e/0x920 [stmmac] [ 10.364050] __dev_open+0xf0/0x1a0 [ 10.364054] __dev_change_flags+0x188/0x1f0 [ 10.364057] dev_change_flags+0x26/0x60 [ 10.364059] do_setlink+0x908/0xc40 [ 10.364062] ? do_setlink+0xb10/0xc40 [ 10.364064] ? __nla_validate_parse+0x4c/0x1a0 [ 10.364068] __rtnl_newlink+0x597/0xa10 [ 10.364072] ? __nla_reserve+0x41/0x50 [ 10.364074] ? __kmalloc_node_track_caller+0x1d0/0x4d0 [ 10.364079] ? pskb_expand_head+0x75/0x310 [ 10.364082] ? nla_reserve_64bit+0x21/0x40 [ 10.364086] ? skb_free_head+0x65/0x80 [ 10.364089] ? security_sock_rcv_skb+0x2c/0x50 [ 10.364094] ? __cond_resched+0x19/0x30 [ 10.364097] ? kmem_cache_alloc_trace+0x15a/0x420 [ 10.364100] rtnl_newlink+0x49/0x70 This change fixes MTL_RXQ_DMA_MAP1 mask issue and channel/queue mapping warning. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=216195 CVE-2022-49592 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: igc: Reinstate IGC_REMOVED logic and implement it properly The initially merged version of the igc driver code (via commit 146740f9abc4, "igc: Add support for PF") contained the following IGC_REMOVED checks in the igc_rd32/wr32() MMIO accessors: u32 igc_rd32(struct igc_hw *hw, u32 reg) { u8 __iomem *hw_addr = READ_ONCE(hw->hw_addr); u32 value = 0; if (IGC_REMOVED(hw_addr)) return ~value; value = readl(&hw_addr[reg]); /* reads should not return all F's */ if (!(~value) && (!reg || !(~readl(hw_addr)))) hw->hw_addr = NULL; return value; } And: #define wr32(reg, val) \ do { \ u8 __iomem *hw_addr = READ_ONCE((hw)->hw_addr); \ if (!IGC_REMOVED(hw_addr)) \ writel((val), &hw_addr[(reg)]); \ } while (0) E.g. igb has similar checks in its MMIO accessors, and has a similar macro E1000_REMOVED, which is implemented as follows: #define E1000_REMOVED(h) unlikely(!(h)) These checks serve to detect and take note of an 0xffffffff MMIO read return from the device, which can be caused by a PCIe link flap or some other kind of PCI bus error, and to avoid performing MMIO reads and writes from that point onwards. However, the IGC_REMOVED macro was not originally implemented: #ifndef IGC_REMOVED #define IGC_REMOVED(a) (0) #endif /* IGC_REMOVED */ This led to the IGC_REMOVED logic to be removed entirely in a subsequent commit (commit 3c215fb18e70, "igc: remove IGC_REMOVED function"), with the rationale that such checks matter only for virtualization and that igc does not support virtualization -- but a PCIe device can become detached even without virtualization being in use, and without proper checks, a PCIe bus error affecting an igc adapter will lead to various NULL pointer dereferences, as the first access after the error will set hw->hw_addr to NULL, and subsequent accesses will blindly dereference this now-NULL pointer. This patch reinstates the IGC_REMOVED checks in igc_rd32/wr32(), and implements IGC_REMOVED the way it is done for igb, by checking for the unlikely() case of hw_addr being NULL. This change prevents the oopses seen when a PCIe link flap occurs on an igc adapter. CVE-2022-49605 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix data race between perf_event_set_output() and perf_mmap_close() Yang Jihing reported a race between perf_event_set_output() and perf_mmap_close(): CPU1 CPU2 perf_mmap_close(e2) if (atomic_dec_and_test(&e2->rb->mmap_count)) // 1 - > 0 detach_rest = true ioctl(e1, IOC_SET_OUTPUT, e2) perf_event_set_output(e1, e2) ... list_for_each_entry_rcu(e, &e2->rb->event_list, rb_entry) ring_buffer_attach(e, NULL); // e1 isn't yet added and // therefore not detached ring_buffer_attach(e1, e2->rb) list_add_rcu(&e1->rb_entry, &e2->rb->event_list) After this; e1 is attached to an unmapped rb and a subsequent perf_mmap() will loop forever more: again: mutex_lock(&e->mmap_mutex); if (event->rb) { ... if (!atomic_inc_not_zero(&e->rb->mmap_count)) { ... mutex_unlock(&e->mmap_mutex); goto again; } } The loop in perf_mmap_close() holds e2->mmap_mutex, while the attach in perf_event_set_output() holds e1->mmap_mutex. As such there is no serialization to avoid this race. Change perf_event_set_output() to take both e1->mmap_mutex and e2->mmap_mutex to alleviate that problem. Additionally, have the loop in perf_mmap() detach the rb directly, this avoids having to wait for the concurrent perf_mmap_close() to get around to doing it to make progress. CVE-2022-49607 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Prevent RSB underflow before vmenter On VMX, there are some balanced returns between the time the guest's SPEC_CTRL value is written, and the vmenter. Balanced returns (matched by a preceding call) are usually ok, but it's at least theoretically possible an NMI with a deep call stack could empty the RSB before one of the returns. For maximum paranoia, don't allow *any* returns (balanced or otherwise) between the SPEC_CTRL write and the vmenter. [ bp: Fix 32-bit build. ] CVE-2022-49610 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: sfp: fix memory leak in sfp_probe() sfp_probe() allocates a memory chunk from sfp with sfp_alloc(). When devm_add_action() fails, sfp is not freed, which leads to a memory leak. We should use devm_add_action_or_reset() instead of devm_add_action(). CVE-2022-49619 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 low In the Linux kernel, the following vulnerability has been resolved: net: tipc: fix possible refcount leak in tipc_sk_create() Free sk in case tipc_sk_insert() fails. CVE-2022-49620 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 low In the Linux kernel, the following vulnerability has been resolved: powerpc/xive/spapr: correct bitmap allocation size kasan detects access beyond the end of the xibm->bitmap allocation: BUG: KASAN: slab-out-of-bounds in _find_first_zero_bit+0x40/0x140 Read of size 8 at addr c00000001d1d0118 by task swapper/0/1 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc2-00001-g90df023b36dd #28 Call Trace: [c00000001d98f770] [c0000000012baab8] dump_stack_lvl+0xac/0x108 (unreliable) [c00000001d98f7b0] [c00000000068faac] print_report+0x37c/0x710 [c00000001d98f880] [c0000000006902c0] kasan_report+0x110/0x354 [c00000001d98f950] [c000000000692324] __asan_load8+0xa4/0xe0 [c00000001d98f970] [c0000000011c6ed0] _find_first_zero_bit+0x40/0x140 [c00000001d98f9b0] [c0000000000dbfbc] xive_spapr_get_ipi+0xcc/0x260 [c00000001d98fa70] [c0000000000d6d28] xive_setup_cpu_ipi+0x1e8/0x450 [c00000001d98fb30] [c000000004032a20] pSeries_smp_probe+0x5c/0x118 [c00000001d98fb60] [c000000004018b44] smp_prepare_cpus+0x944/0x9ac [c00000001d98fc90] [c000000004009f9c] kernel_init_freeable+0x2d4/0x640 [c00000001d98fd90] [c0000000000131e8] kernel_init+0x28/0x1d0 [c00000001d98fe10] [c00000000000cd54] ret_from_kernel_thread+0x5c/0x64 Allocated by task 0: kasan_save_stack+0x34/0x70 __kasan_kmalloc+0xb4/0xf0 __kmalloc+0x268/0x540 xive_spapr_init+0x4d0/0x77c pseries_init_irq+0x40/0x27c init_IRQ+0x44/0x84 start_kernel+0x2a4/0x538 start_here_common+0x1c/0x20 The buggy address belongs to the object at c00000001d1d0118 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes inside of 8-byte region [c00000001d1d0118, c00000001d1d0120) The buggy address belongs to the physical page: page:c00c000000074740 refcount:1 mapcount:0 mapping:0000000000000000 index:0xc00000001d1d0558 pfn:0x1d1d flags: 0x7ffff000000200(slab|node=0|zone=0|lastcpupid=0x7ffff) raw: 007ffff000000200 c00000001d0003c8 c00000001d0003c8 c00000001d010480 raw: c00000001d1d0558 0000000001e1000a 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: c00000001d1d0000: fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0080: fc fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc >c00000001d1d0100: fc fc fc 02 fc fc fc fc fc fc fc fc fc fc fc fc ^ c00000001d1d0180: fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0200: fc fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc This happens because the allocation uses the wrong unit (bits) when it should pass (BITS_TO_LONGS(count) * sizeof(long)) or equivalent. With small numbers of bits, the allocated object can be smaller than sizeof(long), which results in invalid accesses. Use bitmap_zalloc() to allocate and initialize the irq bitmap, paired with bitmap_free() for consistency. CVE-2022-49623 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: sfc: fix kernel panic when creating VF When creating VFs a kernel panic can happen when calling to efx_ef10_try_update_nic_stats_vf. When releasing a DMA coherent buffer, sometimes, I don't know in what specific circumstances, it has to unmap memory with vunmap. It is disallowed to do that in IRQ context or with BH disabled. Otherwise, we hit this line in vunmap, causing the crash: BUG_ON(in_interrupt()); This patch reenables BH to release the buffer. Log messages when the bug is hit: kernel BUG at mm/vmalloc.c:2727! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 6 PID: 1462 Comm: NetworkManager Kdump: loaded Tainted: G I --------- --- 5.14.0-119.el9.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/06WXJT, BIOS 2.8.2 08/27/2020 RIP: 0010:vunmap+0x2e/0x30 ...skip... Call Trace: __iommu_dma_free+0x96/0x100 efx_nic_free_buffer+0x2b/0x40 [sfc] efx_ef10_try_update_nic_stats_vf+0x14a/0x1c0 [sfc] efx_ef10_update_stats_vf+0x18/0x40 [sfc] efx_start_all+0x15e/0x1d0 [sfc] efx_net_open+0x5a/0xe0 [sfc] __dev_open+0xe7/0x1a0 __dev_change_flags+0x1d7/0x240 dev_change_flags+0x21/0x60 ...skip... CVE-2022-49625 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/i915/selftests: fix subtraction overflow bug On some machines hole_end can be small enough to cause subtraction overflow. On the other side (addr + 2 * min_alignment) can overflow in case of mock tests. This patch should handle both cases. (cherry picked from commit ab3edc679c552a466e4bf0b11af3666008bd65a2) CVE-2022-49635 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: sysctl: Fix data races in proc_douintvec_minmax(). A sysctl variable is accessed concurrently, and there is always a chance of data-race. So, all readers and writers need some basic protection to avoid load/store-tearing. This patch changes proc_douintvec_minmax() to use READ_ONCE() and WRITE_ONCE() internally to fix data-races on the sysctl side. For now, proc_douintvec_minmax() itself is tolerant to a data-race, but we still need to add annotations on the other subsystem's side. CVE-2022-49640 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: sysctl: Fix data races in proc_douintvec(). A sysctl variable is accessed concurrently, and there is always a chance of data-race. So, all readers and writers need some basic protection to avoid load/store-tearing. This patch changes proc_douintvec() to use READ_ONCE() and WRITE_ONCE() internally to fix data-races on the sysctl side. For now, proc_douintvec() itself is tolerant to a data-race, but we still need to add annotations on the other subsystem's side. CVE-2022-49641 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: cgroup: Use separate src/dst nodes when preloading css_sets for migration Each cset (css_set) is pinned by its tasks. When we're moving tasks around across csets for a migration, we need to hold the source and destination csets to ensure that they don't go away while we're moving tasks about. This is done by linking cset->mg_preload_node on either the mgctx->preloaded_src_csets or mgctx->preloaded_dst_csets list. Using the same cset->mg_preload_node for both the src and dst lists was deemed okay as a cset can't be both the source and destination at the same time. Unfortunately, this overloading becomes problematic when multiple tasks are involved in a migration and some of them are identity noop migrations while others are actually moving across cgroups. For example, this can happen with the following sequence on cgroup1: #1> mkdir -p /sys/fs/cgroup/misc/a/b #2> echo $$ > /sys/fs/cgroup/misc/a/cgroup.procs #3> RUN_A_COMMAND_WHICH_CREATES_MULTIPLE_THREADS & #4> PID=$! #5> echo $PID > /sys/fs/cgroup/misc/a/b/tasks #6> echo $PID > /sys/fs/cgroup/misc/a/cgroup.procs the process including the group leader back into a. In this final migration, non-leader threads would be doing identity migration while the group leader is doing an actual one. After #3, let's say the whole process was in cset A, and that after #4, the leader moves to cset B. Then, during #6, the following happens: 1. cgroup_migrate_add_src() is called on B for the leader. 2. cgroup_migrate_add_src() is called on A for the other threads. 3. cgroup_migrate_prepare_dst() is called. It scans the src list. 4. It notices that B wants to migrate to A, so it tries to A to the dst list but realizes that its ->mg_preload_node is already busy. 5. and then it notices A wants to migrate to A as it's an identity migration, it culls it by list_del_init()'ing its ->mg_preload_node and putting references accordingly. 6. The rest of migration takes place with B on the src list but nothing on the dst list. This means that A isn't held while migration is in progress. If all tasks leave A before the migration finishes and the incoming task pins it, the cset will be destroyed leading to use-after-free. This is caused by overloading cset->mg_preload_node for both src and dst preload lists. We wanted to exclude the cset from the src list but ended up inadvertently excluding it from the dst list too. This patch fixes the issue by separating out cset->mg_preload_node into ->mg_src_preload_node and ->mg_dst_preload_node, so that the src and dst preloadings don't interfere with each other. CVE-2022-49647 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: xen/netback: avoid entering xenvif_rx_next_skb() with an empty rx queue xenvif_rx_next_skb() is expecting the rx queue not being empty, but in case the loop in xenvif_rx_action() is doing multiple iterations, the availability of another skb in the rx queue is not being checked. This can lead to crashes: [40072.537261] BUG: unable to handle kernel NULL pointer dereference at 0000000000000080 [40072.537407] IP: xenvif_rx_skb+0x23/0x590 [xen_netback] [40072.537534] PGD 0 P4D 0 [40072.537644] Oops: 0000 [#1] SMP NOPTI [40072.537749] CPU: 0 PID: 12505 Comm: v1-c40247-q2-gu Not tainted 4.12.14-122.121-default #1 SLE12-SP5 [40072.537867] Hardware name: HP ProLiant DL580 Gen9/ProLiant DL580 Gen9, BIOS U17 11/23/2021 [40072.537999] task: ffff880433b38100 task.stack: ffffc90043d40000 [40072.538112] RIP: e030:xenvif_rx_skb+0x23/0x590 [xen_netback] [40072.538217] RSP: e02b:ffffc90043d43de0 EFLAGS: 00010246 [40072.538319] RAX: 0000000000000000 RBX: ffffc90043cd7cd0 RCX: 00000000000000f7 [40072.538430] RDX: 0000000000000000 RSI: 0000000000000006 RDI: ffffc90043d43df8 [40072.538531] RBP: 000000000000003f R08: 000077ff80000000 R09: 0000000000000008 [40072.538644] R10: 0000000000007ff0 R11: 00000000000008f6 R12: ffffc90043ce2708 [40072.538745] R13: 0000000000000000 R14: ffffc90043d43ed0 R15: ffff88043ea748c0 [40072.538861] FS: 0000000000000000(0000) GS:ffff880484600000(0000) knlGS:0000000000000000 [40072.538988] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 [40072.539088] CR2: 0000000000000080 CR3: 0000000407ac8000 CR4: 0000000000040660 [40072.539211] Call Trace: [40072.539319] xenvif_rx_action+0x71/0x90 [xen_netback] [40072.539429] xenvif_kthread_guest_rx+0x14a/0x29c [xen_netback] Fix that by stopping the loop in case the rx queue becomes empty. CVE-2022-49649 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: Fix refcount leak in ti_dra7_xbar_route_allocate of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not needed anymore. Add missing of_node_put() in to fix this. CVE-2022-49652 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: usbnet: fix memory leak in error case usbnet_write_cmd_async() mixed up which buffers need to be freed in which error case. v2: add Fixes tag v3: fix uninitialized buf pointer CVE-2022-49657 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: bpf: Fix insufficient bounds propagation from adjust_scalar_min_max_vals Kuee reported a corner case where the tnum becomes constant after the call to __reg_bound_offset(), but the register's bounds are not, that is, its min bounds are still not equal to the register's max bounds. This in turn allows to leak pointers through turning a pointer register as is into an unknown scalar via adjust_ptr_min_max_vals(). Before: func#0 @0 0: R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) 0: (b7) r0 = 1 ; R0_w=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) 1: (b7) r3 = 0 ; R3_w=scalar(imm=0,umax=0,var_off=(0x0; 0x0)) 2: (87) r3 = -r3 ; R3_w=scalar() 3: (87) r3 = -r3 ; R3_w=scalar() 4: (47) r3 |= 32767 ; R3_w=scalar(smin=-9223372036854743041,umin=32767,var_off=(0x7fff; 0xffffffffffff8000),s32_min=-2147450881) 5: (75) if r3 s>= 0x0 goto pc+1 ; R3_w=scalar(umin=9223372036854808575,var_off=(0x8000000000007fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767) 6: (95) exit from 5 to 7: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) 7: (d5) if r3 s<= 0x8000 goto pc+1 ; R3=scalar(umin=32769,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767) 8: (95) exit from 7 to 9: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=32768,var_off=(0x7fff; 0x8000)) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) 9: (07) r3 += -32767 ; R3_w=scalar(imm=0,umax=1,var_off=(0x0; 0x0)) <--- [*] 10: (95) exit What can be seen here is that R3=scalar(umin=32767,umax=32768,var_off=(0x7fff; 0x8000)) after the operation R3 += -32767 results in a 'malformed' constant, that is, R3_w=scalar(imm=0,umax=1,var_off=(0x0; 0x0)). Intersecting with var_off has not been done at that point via __update_reg_bounds(), which would have improved the umax to be equal to umin. Refactor the tnum <> min/max bounds information flow into a reg_bounds_sync() helper and use it consistently everywhere. After the fix, bounds have been corrected to R3_w=scalar(imm=0,umax=0,var_off=(0x0; 0x0)) and thus the register is regarded as a 'proper' constant scalar of 0. After: func#0 @0 0: R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) 0: (b7) r0 = 1 ; R0_w=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) 1: (b7) r3 = 0 ; R3_w=scalar(imm=0,umax=0,var_off=(0x0; 0x0)) 2: (87) r3 = -r3 ; R3_w=scalar() 3: (87) r3 = -r3 ; R3_w=scalar() 4: (47) r3 |= 32767 ; R3_w=scalar(smin=-9223372036854743041,umin=32767,var_off=(0x7fff; 0xffffffffffff8000),s32_min=-2147450881) 5: (75) if r3 s>= 0x0 goto pc+1 ; R3_w=scalar(umin=9223372036854808575,var_off=(0x8000000000007fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767) 6: (95) exit from 5 to 7: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) 7: (d5) if r3 s<= 0x8000 goto pc+1 ; R3=scalar(umin=32769,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767) 8: (95) exit from 7 to 9: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=32768,var_off=(0x7fff; 0x8000)) R10=fp(off=0 ---truncated--- CVE-2022-49658 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free after 802.3ad slave unbind commit 0622cab0341c ("bonding: fix 802.3ad aggregator reselection"), resolve case, when there is several aggregation groups in the same bond. bond_3ad_unbind_slave will invalidate (clear) aggregator when __agg_active_ports return zero. So, ad_clear_agg can be executed even, when num_of_ports!=0. Than bond_3ad_unbind_slave can be executed again for, previously cleared aggregator. NOTE: at this time bond_3ad_unbind_slave will not update slave ports list, because lag_ports==NULL. So, here we got slave ports, pointing to freed aggregator memory. Fix with checking actual number of ports in group (as was before commit 0622cab0341c ("bonding: fix 802.3ad aggregator reselection") ), before ad_clear_agg(). The KASAN logs are as follows: [ 767.617392] ================================================================== [ 767.630776] BUG: KASAN: use-after-free in bond_3ad_state_machine_handler+0x13dc/0x1470 [ 767.638764] Read of size 2 at addr ffff00011ba9d430 by task kworker/u8:7/767 [ 767.647361] CPU: 3 PID: 767 Comm: kworker/u8:7 Tainted: G O 5.15.11 #15 [ 767.655329] Hardware name: DNI AmazonGo1 A7040 board (DT) [ 767.660760] Workqueue: lacp_1 bond_3ad_state_machine_handler [ 767.666468] Call trace: [ 767.668930] dump_backtrace+0x0/0x2d0 [ 767.672625] show_stack+0x24/0x30 [ 767.675965] dump_stack_lvl+0x68/0x84 [ 767.679659] print_address_description.constprop.0+0x74/0x2b8 [ 767.685451] kasan_report+0x1f0/0x260 [ 767.689148] __asan_load2+0x94/0xd0 [ 767.692667] bond_3ad_state_machine_handler+0x13dc/0x1470 CVE-2022-49667 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: exynos-ppmu: Fix refcount leak in of_get_devfreq_events of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. This function only calls of_node_put() in normal path, missing it in error paths. Add missing of_node_put() to avoid refcount leak. CVE-2022-49668 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: tun: unlink NAPI from device on destruction Syzbot found a race between tun file and device destruction. NAPIs live in struct tun_file which can get destroyed before the netdev so we have to del them explicitly. The current code is missing deleting the NAPI if the queue was detached first. CVE-2022-49672 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: dm raid: fix KASAN warning in raid5_add_disks There's a KASAN warning in raid5_add_disk when running the LVM testsuite. The warning happens in the test lvconvert-raid-reshape-linear_to_raid6-single-type.sh. We fix the warning by verifying that rdev->saved_raid_disk is within limits. CVE-2022-49673 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: dm raid: fix accesses beyond end of raid member array On dm-raid table load (using raid_ctr), dm-raid allocates an array rs->devs[rs->raid_disks] for the raid device members. rs->raid_disks is defined by the number of raid metadata and image tupples passed into the target's constructor. In the case of RAID layout changes being requested, that number can be different from the current number of members for existing raid sets as defined in their superblocks. Example RAID layout changes include: - raid1 legs being added/removed - raid4/5/6/10 number of stripes changed (stripe reshaping) - takeover to higher raid level (e.g. raid5 -> raid6) When accessing array members, rs->raid_disks must be used in control loops instead of the potentially larger value in rs->md.raid_disks. Otherwise it will cause memory access beyond the end of the rs->devs array. Fix this by changing code that is prone to out-of-bounds access. Also fix validate_raid_redundancy() to validate all devices that are added. Also, use braces to help clean up raid_iterate_devices(). The out-of-bounds memory accesses was discovered using KASAN. This commit was verified to pass all LVM2 RAID tests (with KASAN enabled). CVE-2022-49674 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: virtio_net: fix xdp_rxq_info bug after suspend/resume The following sequence currently causes a driver bug warning when using virtio_net: # ip link set eth0 up # echo mem > /sys/power/state (or e.g. # rtcwake -s 10 -m mem) <resume> # ip link set eth0 down Missing register, driver bug WARNING: CPU: 0 PID: 375 at net/core/xdp.c:138 xdp_rxq_info_unreg+0x58/0x60 Call trace: xdp_rxq_info_unreg+0x58/0x60 virtnet_close+0x58/0xac __dev_close_many+0xac/0x140 __dev_change_flags+0xd8/0x210 dev_change_flags+0x24/0x64 do_setlink+0x230/0xdd0 ... This happens because virtnet_freeze() frees the receive_queue completely (including struct xdp_rxq_info) but does not call xdp_rxq_info_unreg(). Similarly, virtnet_restore() sets up the receive_queue again but does not call xdp_rxq_info_reg(). Actually, parts of virtnet_freeze_down() and virtnet_restore_up() are almost identical to virtnet_close() and virtnet_open(): only the calls to xdp_rxq_info_(un)reg() are missing. This means that we can fix this easily and avoid such problems in the future by just calling virtnet_close()/open() from the freeze/restore handlers. Aside from adding the missing xdp_rxq_info calls the only difference is that the refill work is only cancelled if netif_running(). However, this should not make any functional difference since the refill work should only be active if the network interface is actually up. CVE-2022-49687 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/msm/mdp4: Fix refcount leak in mdp4_modeset_init_intf of_graph_get_remote_node() returns remote device node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. Patchwork: https://patchwork.freedesktop.org/patch/488473/ CVE-2022-49693 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ext4: add reserved GDT blocks check We capture a NULL pointer issue when resizing a corrupt ext4 image which is freshly clear resize_inode feature (not run e2fsck). It could be simply reproduced by following steps. The problem is because of the resize_inode feature was cleared, and it will convert the filesystem to meta_bg mode in ext4_resize_fs(), but the es->s_reserved_gdt_blocks was not reduced to zero, so could we mistakenly call reserve_backup_gdb() and passing an uninitialized resize_inode to it when adding new group descriptors. mkfs.ext4 /dev/sda 3G tune2fs -O ^resize_inode /dev/sda #forget to run requested e2fsck mount /dev/sda /mnt resize2fs /dev/sda 8G ======== BUG: kernel NULL pointer dereference, address: 0000000000000028 CPU: 19 PID: 3243 Comm: resize2fs Not tainted 5.18.0-rc7-00001-gfde086c5ebfd #748 ... RIP: 0010:ext4_flex_group_add+0xe08/0x2570 ... Call Trace: <TASK> ext4_resize_fs+0xbec/0x1660 __ext4_ioctl+0x1749/0x24e0 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0xa6/0x110 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f2dd739617b ======== The fix is simple, add a check in ext4_resize_begin() to make sure that the es->s_reserved_gdt_blocks is zero when the resize_inode feature is disabled. CVE-2022-49707 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ext4: fix bug_on ext4_mb_use_inode_pa Hulk Robot reported a BUG_ON: ================================================================== kernel BUG at fs/ext4/mballoc.c:3211! [...] RIP: 0010:ext4_mb_mark_diskspace_used.cold+0x85/0x136f [...] Call Trace: ext4_mb_new_blocks+0x9df/0x5d30 ext4_ext_map_blocks+0x1803/0x4d80 ext4_map_blocks+0x3a4/0x1a10 ext4_writepages+0x126d/0x2c30 do_writepages+0x7f/0x1b0 __filemap_fdatawrite_range+0x285/0x3b0 file_write_and_wait_range+0xb1/0x140 ext4_sync_file+0x1aa/0xca0 vfs_fsync_range+0xfb/0x260 do_fsync+0x48/0xa0 [...] ================================================================== Above issue may happen as follows: ------------------------------------- do_fsync vfs_fsync_range ext4_sync_file file_write_and_wait_range __filemap_fdatawrite_range do_writepages ext4_writepages mpage_map_and_submit_extent mpage_map_one_extent ext4_map_blocks ext4_mb_new_blocks ext4_mb_normalize_request >>> start + size <= ac->ac_o_ex.fe_logical ext4_mb_regular_allocator ext4_mb_simple_scan_group ext4_mb_use_best_found ext4_mb_new_preallocation ext4_mb_new_inode_pa ext4_mb_use_inode_pa >>> set ac->ac_b_ex.fe_len <= 0 ext4_mb_mark_diskspace_used >>> BUG_ON(ac->ac_b_ex.fe_len <= 0); we can easily reproduce this problem with the following commands: `fallocate -l100M disk` `mkfs.ext4 -b 1024 -g 256 disk` `mount disk /mnt` `fsstress -d /mnt -l 0 -n 1000 -p 1` The size must be smaller than or equal to EXT4_BLOCKS_PER_GROUP. Therefore, "start + size <= ac->ac_o_ex.fe_logical" may occur when the size is truncated. So start should be the start position of the group where ac_o_ex.fe_logical is located after alignment. In addition, when the value of fe_logical or EXT4_BLOCKS_PER_GROUP is very large, the value calculated by start_off is more accurate. CVE-2022-49708 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: dm mirror log: round up region bitmap size to BITS_PER_LONG The code in dm-log rounds up bitset_size to 32 bits. It then uses find_next_zero_bit_le on the allocated region. find_next_zero_bit_le accesses the bitmap using unsigned long pointers. So, on 64-bit architectures, it may access 4 bytes beyond the allocated size. Fix this bug by rounding up bitset_size to BITS_PER_LONG. This bug was found by running the lvm2 testsuite with kasan. CVE-2022-49710 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: bus: fsl-mc-bus: fix KASAN use-after-free in fsl_mc_bus_remove() In fsl_mc_bus_remove(), mc->root_mc_bus_dev->mc_io is passed to fsl_destroy_mc_io(). However, mc->root_mc_bus_dev is already freed in fsl_mc_device_remove(). Then reference to mc->root_mc_bus_dev->mc_io triggers KASAN use-after-free. To avoid the use-after-free, keep the reference to mc->root_mc_bus_dev->mc_io in a local variable and pass to fsl_destroy_mc_io(). This patch needs rework to apply to kernels older than v5.15. CVE-2022-49711 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: usb: dwc2: Fix memory leak in dwc2_hcd_init usb_create_hcd will alloc memory for hcd, and we should call usb_put_hcd to free it when platform_get_resource() fails to prevent memory leak. goto error2 label instead error1 to fix this. CVE-2022-49713 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3: Fix refcount leak in gic_populate_ppi_partitions of_find_node_by_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. CVE-2022-49715 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: i40e: Fix call trace in setup_tx_descriptors After PF reset and ethtool -t there was call trace in dmesg sometimes leading to panic. When there was some time, around 5 seconds, between reset and test there were no errors. Problem was that pf reset calls i40e_vsi_close in prep_for_reset and ethtool -t calls i40e_vsi_close in diag_test. If there was not enough time between those commands the second i40e_vsi_close starts before previous i40e_vsi_close was done which leads to crash. Add check to diag_test if pf is in reset and don't start offline tests if it is true. Add netif_info("testing failed") into unhappy path of i40e_diag_test() CVE-2022-49725 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix signed integer overflow in l2tp_ip6_sendmsg When len >= INT_MAX - transhdrlen, ulen = len + transhdrlen will be overflow. To fix, we can follow what udpv6 does and subtract the transhdrlen from the max. CVE-2022-49727 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix signed integer overflow in __ip6_append_data Resurrect ubsan overflow checks and ubsan report this warning, fix it by change the variable [length] type to size_t. UBSAN: signed-integer-overflow in net/ipv6/ip6_output.c:1489:19 2147479552 + 8567 cannot be represented in type 'int' CPU: 0 PID: 253 Comm: err Not tainted 5.16.0+ #1 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0x214/0x230 show_stack+0x30/0x78 dump_stack_lvl+0xf8/0x118 dump_stack+0x18/0x30 ubsan_epilogue+0x18/0x60 handle_overflow+0xd0/0xf0 __ubsan_handle_add_overflow+0x34/0x44 __ip6_append_data.isra.48+0x1598/0x1688 ip6_append_data+0x128/0x260 udpv6_sendmsg+0x680/0xdd0 inet6_sendmsg+0x54/0x90 sock_sendmsg+0x70/0x88 ____sys_sendmsg+0xe8/0x368 ___sys_sendmsg+0x98/0xe0 __sys_sendmmsg+0xf4/0x3b8 __arm64_sys_sendmmsg+0x34/0x48 invoke_syscall+0x64/0x160 el0_svc_common.constprop.4+0x124/0x300 do_el0_svc+0x44/0xc8 el0_svc+0x3c/0x1e8 el0t_64_sync_handler+0x88/0xb0 el0t_64_sync+0x16c/0x170 Changes since v1: -Change the variable [length] type to unsigned, as Eric Dumazet suggested. Changes since v2: -Don't change exthdrlen type in ip6_make_skb, as Paolo Abeni suggested. Changes since v3: -Don't change ulen type in udpv6_sendmsg and l2tp_ip6_sendmsg, as Jakub Kicinski suggested. CVE-2022-49728 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: nfc: nfcmrvl: Fix memory leak in nfcmrvl_play_deferred Similar to the handling of play_deferred in commit 19cfe912c37b ("Bluetooth: btusb: Fix memory leak in play_deferred"), we thought a patch might be needed here as well. Currently usb_submit_urb is called directly to submit deferred tx urbs after unanchor them. So the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urb and cause memory leak. Put those urbs in tx_anchor to avoid the leak, and also fix the error handling. CVE-2022-49729 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 low This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. CVE-2022-49730 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Check the count value of channel spec to prevent out-of-bounds reads This patch fixes slab-out-of-bounds reads in brcmfmac that occur in brcmf_construct_chaninfo() and brcmf_enable_bw40_2g() when the count value of channel specifications provided by the device is greater than the length of 'list->element[]', decided by the size of the 'list' allocated with kzalloc(). The patch adds checks that make the functions free the buffer and return -EINVAL if that is the case. Note that the negative return is handled by the caller, brcmf_setup_wiphybands() or brcmf_cfg80211_attach(). Found by a modified version of syzkaller. Crash Report from brcmf_construct_chaninfo(): ================================================================== BUG: KASAN: slab-out-of-bounds in brcmf_setup_wiphybands+0x1238/0x1430 Read of size 4 at addr ffff888115f24600 by task kworker/0:2/1896 CPU: 0 PID: 1896 Comm: kworker/0:2 Tainted: G W O 5.14.0+ #132 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 Workqueue: usb_hub_wq hub_event Call Trace: dump_stack_lvl+0x57/0x7d print_address_description.constprop.0.cold+0x93/0x334 kasan_report.cold+0x83/0xdf brcmf_setup_wiphybands+0x1238/0x1430 brcmf_cfg80211_attach+0x2118/0x3fd0 brcmf_attach+0x389/0xd40 brcmf_usb_probe+0x12de/0x1690 usb_probe_interface+0x25f/0x710 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 bus_for_each_drv+0x123/0x1a0 __device_attach+0x207/0x330 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 usb_set_configuration+0x984/0x1770 usb_generic_driver_probe+0x69/0x90 usb_probe_device+0x9c/0x220 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 bus_for_each_drv+0x123/0x1a0 __device_attach+0x207/0x330 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 usb_new_device.cold+0x463/0xf66 hub_event+0x10d5/0x3330 process_one_work+0x873/0x13e0 worker_thread+0x8b/0xd10 kthread+0x379/0x450 ret_from_fork+0x1f/0x30 Allocated by task 1896: kasan_save_stack+0x1b/0x40 __kasan_kmalloc+0x7c/0x90 kmem_cache_alloc_trace+0x19e/0x330 brcmf_setup_wiphybands+0x290/0x1430 brcmf_cfg80211_attach+0x2118/0x3fd0 brcmf_attach+0x389/0xd40 brcmf_usb_probe+0x12de/0x1690 usb_probe_interface+0x25f/0x710 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 bus_for_each_drv+0x123/0x1a0 __device_attach+0x207/0x330 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 usb_set_configuration+0x984/0x1770 usb_generic_driver_probe+0x69/0x90 usb_probe_device+0x9c/0x220 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 bus_for_each_drv+0x123/0x1a0 __device_attach+0x207/0x330 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 usb_new_device.cold+0x463/0xf66 hub_event+0x10d5/0x3330 process_one_work+0x873/0x13e0 worker_thread+0x8b/0xd10 kthread+0x379/0x450 ret_from_fork+0x1f/0x30 The buggy address belongs to the object at ffff888115f24000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 1536 bytes inside of 2048-byte region [ffff888115f24000, ffff888115f24800) Memory state around the buggy address: ffff888115f24500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888115f24580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff888115f24600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff888115f24680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff888115f24700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Crash Report from brcmf_enable_bw40_2g(): ========== ---truncated--- CVE-2022-49740 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: i2c: designware: use casting of u64 in clock multiplication to avoid overflow In functions i2c_dw_scl_lcnt() and i2c_dw_scl_hcnt() may have overflow by depending on the values of the given parameters including the ic_clk. For example in our use case where ic_clk is larger than one million, multiplication of ic_clk * 4700 will result in 32 bit overflow. Add cast of u64 to the calculation to avoid multiplication overflow, and use the corresponding define for divide. CVE-2022-49749 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: w1: fix WARNING after calling w1_process() I got the following WARNING message while removing driver(ds2482): ------------[ cut here ]------------ do not call blocking ops when !TASK_RUNNING; state=1 set at [<000000002d50bfb6>] w1_process+0x9e/0x1d0 [wire] WARNING: CPU: 0 PID: 262 at kernel/sched/core.c:9817 __might_sleep+0x98/0xa0 CPU: 0 PID: 262 Comm: w1_bus_master1 Tainted: G N 6.1.0-rc3+ #307 RIP: 0010:__might_sleep+0x98/0xa0 Call Trace: exit_signals+0x6c/0x550 do_exit+0x2b4/0x17e0 kthread_exit+0x52/0x60 kthread+0x16d/0x1e0 ret_from_fork+0x1f/0x30 The state of task is set to TASK_INTERRUPTIBLE in loop in w1_process(), set it to TASK_RUNNING when it breaks out of the loop to avoid the warning. CVE-2022-49751 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: dmaengine: Fix double increment of client_count in dma_chan_get() The first time dma_chan_get() is called for a channel the channel client_count is incorrectly incremented twice for public channels, first in balance_ref_count(), and again prior to returning. This results in an incorrect client count which will lead to the channel resources not being freed when they should be. A simple test of repeated module load and unload of async_tx on a Dell Power Edge R7425 also shows this resulting in a kref underflow warning. [ 124.329662] async_tx: api initialized (async) [ 129.000627] async_tx: api initialized (async) [ 130.047839] ------------[ cut here ]------------ [ 130.052472] refcount_t: underflow; use-after-free. [ 130.057279] WARNING: CPU: 3 PID: 19364 at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110 [ 130.065811] Modules linked in: async_tx(-) rfkill intel_rapl_msr intel_rapl_common amd64_edac edac_mce_amd ipmi_ssif kvm_amd dcdbas kvm mgag200 drm_shmem_helper acpi_ipmi irqbypass drm_kms_helper ipmi_si syscopyarea sysfillrect rapl pcspkr ipmi_devintf sysimgblt fb_sys_fops k10temp i2c_piix4 ipmi_msghandler acpi_power_meter acpi_cpufreq vfat fat drm fuse xfs libcrc32c sd_mod t10_pi sg ahci crct10dif_pclmul libahci crc32_pclmul crc32c_intel ghash_clmulni_intel igb megaraid_sas i40e libata i2c_algo_bit ccp sp5100_tco dca dm_mirror dm_region_hash dm_log dm_mod [last unloaded: async_tx] [ 130.117361] CPU: 3 PID: 19364 Comm: modprobe Kdump: loaded Not tainted 5.14.0-185.el9.x86_64 #1 [ 130.126091] Hardware name: Dell Inc. PowerEdge R7425/02MJ3T, BIOS 1.18.0 01/17/2022 [ 130.133806] RIP: 0010:refcount_warn_saturate+0xba/0x110 [ 130.139041] Code: 01 01 e8 6d bd 55 00 0f 0b e9 72 9d 8a 00 80 3d 26 18 9c 01 00 75 85 48 c7 c7 f8 a3 03 9d c6 05 16 18 9c 01 01 e8 4a bd 55 00 <0f> 0b e9 4f 9d 8a 00 80 3d 01 18 9c 01 00 0f 85 5e ff ff ff 48 c7 [ 130.157807] RSP: 0018:ffffbf98898afe68 EFLAGS: 00010286 [ 130.163036] RAX: 0000000000000000 RBX: ffff9da06028e598 RCX: 0000000000000000 [ 130.170172] RDX: ffff9daf9de26480 RSI: ffff9daf9de198a0 RDI: ffff9daf9de198a0 [ 130.177316] RBP: ffff9da7cddf3970 R08: 0000000000000000 R09: 00000000ffff7fff [ 130.184459] R10: ffffbf98898afd00 R11: ffffffff9d9e8c28 R12: ffff9da7cddf1970 [ 130.191596] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 130.198739] FS: 00007f646435c740(0000) GS:ffff9daf9de00000(0000) knlGS:0000000000000000 [ 130.206832] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 130.212586] CR2: 00007f6463b214f0 CR3: 00000008ab98c000 CR4: 00000000003506e0 [ 130.219729] Call Trace: [ 130.222192] <TASK> [ 130.224305] dma_chan_put+0x10d/0x110 [ 130.227988] dmaengine_put+0x7a/0xa0 [ 130.231575] __do_sys_delete_module.constprop.0+0x178/0x280 [ 130.237157] ? syscall_trace_enter.constprop.0+0x145/0x1d0 [ 130.242652] do_syscall_64+0x5c/0x90 [ 130.246240] ? exc_page_fault+0x62/0x150 [ 130.250178] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 130.255243] RIP: 0033:0x7f6463a3f5ab [ 130.258830] Code: 73 01 c3 48 8b 0d 75 a8 1b 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 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 45 a8 1b 00 f7 d8 64 89 01 48 [ 130.277591] RSP: 002b:00007fff22f972c8 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 [ 130.285164] RAX: ffffffffffffffda RBX: 000055b6786edd40 RCX: 00007f6463a3f5ab [ 130.292303] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 000055b6786edda8 [ 130.299443] RBP: 000055b6786edd40 R08: 0000000000000000 R09: 0000000000000000 [ 130.306584] R10: 00007f6463b9eac0 R11: 0000000000000206 R12: 000055b6786edda8 [ 130.313731] R13: 0000000000000000 R14: 000055b6786edda8 R15: 00007fff22f995f8 [ 130.320875] </TASK> [ 130.323081] ---[ end trace eff7156d56b5cf25 ]--- cat /sys/class/dma/dma0chan*/in_use would get the wrong result. 2 2 2 Test-by: Jie Hai <haijie1@huawei.com> CVE-2022-49753 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: btrfs: always report error in run_one_delayed_ref() Currently we have a btrfs_debug() for run_one_delayed_ref() failure, but if end users hit such problem, there will be no chance that btrfs_debug() is enabled. This can lead to very little useful info for debugging. This patch will: - Add extra info for error reporting Including: * logical bytenr * num_bytes * type * action * ref_mod - Replace the btrfs_debug() with btrfs_err() - Move the error reporting into run_one_delayed_ref() This is to avoid use-after-free, the @node can be freed in the caller. This error should only be triggered at most once. As if run_one_delayed_ref() failed, we trigger the error message, then causing the call chain to error out: btrfs_run_delayed_refs() `- btrfs_run_delayed_refs() `- btrfs_run_delayed_refs_for_head() `- run_one_delayed_ref() And we will abort the current transaction in btrfs_run_delayed_refs(). If we have to run delayed refs for the abort transaction, run_one_delayed_ref() will just cleanup the refs and do nothing, thus no new error messages would be output. CVE-2022-49761 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: gfs2: Check sb_bsize_shift after reading superblock Fuzzers like to scribble over sb_bsize_shift but in reality it's very unlikely that this field would be corrupted on its own. Nevertheless it should be checked to avoid the possibility of messy mount errors due to bad calculations. It's always a fixed value based on the block size so we can just check that it's the expected value. Tested with: mkfs.gfs2 -O -p lock_nolock /dev/vdb for i in 0 -1 64 65 32 33; do gfs2_edit -p sb field sb_bsize_shift $i /dev/vdb mount /dev/vdb /mnt/test && umount /mnt/test done Before this patch we get a withdraw after [ 76.413681] gfs2: fsid=loop0.0: fatal: invalid metadata block [ 76.413681] bh = 19 (type: exp=5, found=4) [ 76.413681] function = gfs2_meta_buffer, file = fs/gfs2/meta_io.c, line = 492 and with UBSAN configured we also get complaints like [ 76.373395] UBSAN: shift-out-of-bounds in fs/gfs2/ops_fstype.c:295:19 [ 76.373815] shift exponent 4294967287 is too large for 64-bit type 'long unsigned int' After the patch, these complaints don't appear, mount fails immediately and we get an explanation in dmesg. CVE-2022-49769 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: dm ioctl: fix misbehavior if list_versions races with module loading __list_versions will first estimate the required space using the "dm_target_iterate(list_version_get_needed, &needed)" call and then will fill the space using the "dm_target_iterate(list_version_get_info, &iter_info)" call. Each of these calls locks the targets using the "down_read(&_lock)" and "up_read(&_lock)" calls, however between the first and second "dm_target_iterate" there is no lock held and the target modules can be loaded at this point, so the second "dm_target_iterate" call may need more space than what was the first "dm_target_iterate" returned. The code tries to handle this overflow (see the beginning of list_version_get_info), however this handling is incorrect. The code sets "param->data_size = param->data_start + needed" and "iter_info.end = (char *)vers+len" - "needed" is the size returned by the first dm_target_iterate call; "len" is the size of the buffer allocated by userspace. "len" may be greater than "needed"; in this case, the code will write up to "len" bytes into the buffer, however param->data_size is set to "needed", so it may write data past the param->data_size value. The ioctl interface copies only up to param->data_size into userspace, thus part of the result will be truncated. Fix this bug by setting "iter_info.end = (char *)vers + needed;" - this guarantees that the second "dm_target_iterate" call will write only up to the "needed" buffer and it will exit with "DM_BUFFER_FULL_FLAG" if it overflows the "needed" space - in this case, userspace will allocate a larger buffer and retry. Note that there is also a bug in list_version_get_needed - we need to add "strlen(tt->name) + 1" to the needed size, not "strlen(tt->name)". CVE-2022-49771 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Drop snd_BUG_ON() from snd_usbmidi_output_open() snd_usbmidi_output_open() has a check of the NULL port with snd_BUG_ON(). snd_BUG_ON() was used as this shouldn't have happened, but in reality, the NULL port may be seen when the device gives an invalid endpoint setup at the descriptor, hence the driver skips the allocation. That is, the check itself is valid and snd_BUG_ON() should be dropped from there. Otherwise it's confusing as if it were a real bug, as recently syzbot stumbled on it. CVE-2022-49772 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: tcp: cdg: allow tcp_cdg_release() to be called multiple times Apparently, mptcp is able to call tcp_disconnect() on an already disconnected flow. This is generally fine, unless current congestion control is CDG, because it might trigger a double-free [1] Instead of fixing MPTCP, and future bugs, we can make tcp_disconnect() more resilient. [1] BUG: KASAN: double-free in slab_free mm/slub.c:3539 [inline] BUG: KASAN: double-free in kfree+0xe2/0x580 mm/slub.c:4567 CPU: 0 PID: 3645 Comm: kworker/0:7 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Workqueue: events mptcp_worker Call Trace: <TASK> __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/0x719 mm/kasan/report.c:433 kasan_report_invalid_free+0x81/0x190 mm/kasan/report.c:462 ____kasan_slab_free+0x18b/0x1c0 mm/kasan/common.c:356 kasan_slab_free include/linux/kasan.h:200 [inline] slab_free_hook mm/slub.c:1759 [inline] slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1785 slab_free mm/slub.c:3539 [inline] kfree+0xe2/0x580 mm/slub.c:4567 tcp_disconnect+0x980/0x1e20 net/ipv4/tcp.c:3145 __mptcp_close_ssk+0x5ca/0x7e0 net/mptcp/protocol.c:2327 mptcp_do_fastclose net/mptcp/protocol.c:2592 [inline] mptcp_worker+0x78c/0xff0 net/mptcp/protocol.c:2627 process_one_work+0x991/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e4/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK> Allocated by task 3671: kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38 kasan_set_track mm/kasan/common.c:45 [inline] set_alloc_info mm/kasan/common.c:437 [inline] ____kasan_kmalloc mm/kasan/common.c:516 [inline] ____kasan_kmalloc mm/kasan/common.c:475 [inline] __kasan_kmalloc+0xa9/0xd0 mm/kasan/common.c:525 kmalloc_array include/linux/slab.h:640 [inline] kcalloc include/linux/slab.h:671 [inline] tcp_cdg_init+0x10d/0x170 net/ipv4/tcp_cdg.c:380 tcp_init_congestion_control+0xab/0x550 net/ipv4/tcp_cong.c:193 tcp_reinit_congestion_control net/ipv4/tcp_cong.c:217 [inline] tcp_set_congestion_control+0x96c/0xaa0 net/ipv4/tcp_cong.c:391 do_tcp_setsockopt+0x505/0x2320 net/ipv4/tcp.c:3513 tcp_setsockopt+0xd4/0x100 net/ipv4/tcp.c:3801 mptcp_setsockopt+0x35f/0x2570 net/mptcp/sockopt.c:844 __sys_setsockopt+0x2d6/0x690 net/socket.c:2252 __do_sys_setsockopt net/socket.c:2263 [inline] __se_sys_setsockopt net/socket.c:2260 [inline] __x64_sys_setsockopt+0xba/0x150 net/socket.c:2260 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 Freed by task 16: kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38 kasan_set_track+0x21/0x30 mm/kasan/common.c:45 kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370 ____kasan_slab_free mm/kasan/common.c:367 [inline] ____kasan_slab_free+0x166/0x1c0 mm/kasan/common.c:329 kasan_slab_free include/linux/kasan.h:200 [inline] slab_free_hook mm/slub.c:1759 [inline] slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1785 slab_free mm/slub.c:3539 [inline] kfree+0xe2/0x580 mm/slub.c:4567 tcp_cleanup_congestion_control+0x70/0x120 net/ipv4/tcp_cong.c:226 tcp_v4_destroy_sock+0xdd/0x750 net/ipv4/tcp_ipv4.c:2254 tcp_v6_destroy_sock+0x11/0x20 net/ipv6/tcp_ipv6.c:1969 inet_csk_destroy_sock+0x196/0x440 net/ipv4/inet_connection_sock.c:1157 tcp_done+0x23b/0x340 net/ipv4/tcp.c:4649 tcp_rcv_state_process+0x40e7/0x4990 net/ipv4/tcp_input.c:6624 tcp_v6_do_rcv+0x3fc/0x13c0 net/ipv6/tcp_ipv6.c:1525 tcp_v6_rcv+0x2e8e/0x3830 net/ipv6/tcp_ipv6.c:1759 ip6_protocol_deliver_rcu+0x2db/0x1950 net/ipv6/ip6_input.c:439 ip6_input_finish+0x14c/0x2c0 net/ipv6/ip6_input.c:484 NF_HOOK include/linux/netfilter.h:302 [inline] NF_HOOK include/linux/netfilter.h:296 [inline] ip6_input+0x9c/0xd ---truncated--- CVE-2022-49775 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 important In the Linux kernel, the following vulnerability has been resolved: macvlan: enforce a consistent minimal mtu macvlan should enforce a minimal mtu of 68, even at link creation. This patch avoids the current behavior (which could lead to crashes in ipv6 stack if the link is brought up) $ ip link add macvlan1 link eno1 mtu 8 type macvlan # This should fail ! $ ip link sh dev macvlan1 5: macvlan1@eno1: <BROADCAST,MULTICAST> mtu 8 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 02:47:6c:24:74:82 brd ff:ff:ff:ff:ff:ff $ ip link set macvlan1 mtu 67 Error: mtu less than device minimum. $ ip link set macvlan1 mtu 68 $ ip link set macvlan1 mtu 8 Error: mtu less than device minimum. CVE-2022-49776 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: mmc: sdhci-pci: Fix possible memory leak caused by missing pci_dev_put() pci_get_device() will increase the reference count for the returned pci_dev. We need to use pci_dev_put() to decrease the reference count before amd_probe() returns. There is no problem for the 'smbus_dev == NULL' branch because pci_dev_put() can also handle the NULL input parameter case. CVE-2022-49787 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: misc/vmw_vmci: fix an infoleak in vmci_host_do_receive_datagram() `struct vmci_event_qp` allocated by qp_notify_peer() contains padding, which may carry uninitialized data to the userspace, as observed by KMSAN: BUG: KMSAN: kernel-infoleak in instrument_copy_to_user ./include/linux/instrumented.h:121 instrument_copy_to_user ./include/linux/instrumented.h:121 _copy_to_user+0x5f/0xb0 lib/usercopy.c:33 copy_to_user ./include/linux/uaccess.h:169 vmci_host_do_receive_datagram drivers/misc/vmw_vmci/vmci_host.c:431 vmci_host_unlocked_ioctl+0x33d/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:925 vfs_ioctl fs/ioctl.c:51 ... Uninit was stored to memory at: kmemdup+0x74/0xb0 mm/util.c:131 dg_dispatch_as_host drivers/misc/vmw_vmci/vmci_datagram.c:271 vmci_datagram_dispatch+0x4f8/0xfc0 drivers/misc/vmw_vmci/vmci_datagram.c:339 qp_notify_peer+0x19a/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1479 qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662 qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750 vmci_qp_broker_alloc+0x96/0xd0 drivers/misc/vmw_vmci/vmci_queue_pair.c:1940 vmci_host_do_alloc_queuepair drivers/misc/vmw_vmci/vmci_host.c:488 vmci_host_unlocked_ioctl+0x24fd/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:927 ... Local variable ev created at: qp_notify_peer+0x54/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1456 qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662 qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750 Bytes 28-31 of 48 are uninitialized Memory access of size 48 starts at ffff888035155e00 Data copied to user address 0000000020000100 Use memset() to prevent the infoleaks. Also speculatively fix qp_notify_peer_local(), which may suffer from the same problem. CVE-2022-49788 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: zfcp: Fix double free of FSF request when qdio send fails We used to use the wrong type of integer in 'zfcp_fsf_req_send()' to cache the FSF request ID when sending a new FSF request. This is used in case the sending fails and we need to remove the request from our internal hash table again (so we don't keep an invalid reference and use it when we free the request again). In 'zfcp_fsf_req_send()' we used to cache the ID as 'int' (signed and 32 bit wide), but the rest of the zfcp code (and the firmware specification) handles the ID as 'unsigned long'/'u64' (unsigned and 64 bit wide [s390x ELF ABI]). For one this has the obvious problem that when the ID grows past 32 bit (this can happen reasonably fast) it is truncated to 32 bit when storing it in the cache variable and so doesn't match the original ID anymore. The second less obvious problem is that even when the original ID has not yet grown past 32 bit, as soon as the 32nd bit is set in the original ID (0x80000000 = 2'147'483'648) we will have a mismatch when we cast it back to 'unsigned long'. As the cached variable is of a signed type, the compiler will choose a sign-extending instruction to load the 32 bit variable into a 64 bit register (e.g.: 'lgf %r11,188(%r15)'). So once we pass the cached variable into 'zfcp_reqlist_find_rm()' to remove the request again all the leading zeros will be flipped to ones to extend the sign and won't match the original ID anymore (this has been observed in practice). If we can't successfully remove the request from the hash table again after 'zfcp_qdio_send()' fails (this happens regularly when zfcp cannot notify the adapter about new work because the adapter is already gone during e.g. a ChpID toggle) we will end up with a double free. We unconditionally free the request in the calling function when 'zfcp_fsf_req_send()' fails, but because the request is still in the hash table we end up with a stale memory reference, and once the zfcp adapter is either reset during recovery or shutdown we end up freeing the same memory twice. The resulting stack traces vary depending on the kernel and have no direct correlation to the place where the bug occurs. Here are three examples that have been seen in practice: list_del corruption. next->prev should be 00000001b9d13800, but was 00000000dead4ead. (next=00000001bd131a00) ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:62! monitor event: 0040 ilc:2 [#1] PREEMPT SMP Modules linked in: ... CPU: 9 PID: 1617 Comm: zfcperp0.0.1740 Kdump: loaded Hardware name: ... Krnl PSW : 0704d00180000000 00000003cbeea1f8 (__list_del_entry_valid+0x98/0x140) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3 Krnl GPRS: 00000000916d12f1 0000000080000000 000000000000006d 00000003cb665cd6 0000000000000001 0000000000000000 0000000000000000 00000000d28d21e8 00000000d3844000 00000380099efd28 00000001bd131a00 00000001b9d13800 00000000d3290100 0000000000000000 00000003cbeea1f4 00000380099efc70 Krnl Code: 00000003cbeea1e8: c020004f68a7 larl %r2,00000003cc8d7336 00000003cbeea1ee: c0e50027fd65 brasl %r14,00000003cc3e9cb8 #00000003cbeea1f4: af000000 mc 0,0 >00000003cbeea1f8: c02000920440 larl %r2,00000003cd12aa78 00000003cbeea1fe: c0e500289c25 brasl %r14,00000003cc3fda48 00000003cbeea204: b9040043 lgr %r4,%r3 00000003cbeea208: b9040051 lgr %r5,%r1 00000003cbeea20c: b9040032 lgr %r3,%r2 Call Trace: [<00000003cbeea1f8>] __list_del_entry_valid+0x98/0x140 ([<00000003cbeea1f4>] __list_del_entry_valid+0x94/0x140) [<000003ff7ff502fe>] zfcp_fsf_req_dismiss_all+0xde/0x150 [zfcp] [<000003ff7ff49cd0>] zfcp_erp_strategy_do_action+0x160/0x280 [zfcp] ---truncated--- CVE-2022-49789 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 important In the Linux kernel, the following vulnerability has been resolved: net: ena: Fix error handling in ena_init() The ena_init() won't destroy workqueue created by create_singlethread_workqueue() when pci_register_driver() failed. Call destroy_workqueue() when pci_register_driver() failed to prevent the resource leak. CVE-2022-49813 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: mISDN: fix possible memory leak in mISDN_dsp_element_register() Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array"), the name of device is allocated dynamically, use put_device() to give up the reference, so that the name can be freed in kobject_cleanup() when the refcount is 0. The 'entry' is going to be freed in mISDN_dsp_dev_release(), so the kfree() is removed. list_del() is called in mISDN_dsp_dev_release(), so it need be initialized. CVE-2022-49821 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: cifs: Fix connections leak when tlink setup failed If the tlink setup failed, lost to put the connections, then the module refcnt leak since the cifsd kthread not exit. Also leak the fscache info, and for next mount with fsc, it will print the follow errors: CIFS: Cache volume key already in use (cifs,127.0.0.1:445,TEST) Let's check the result of tlink setup, and do some cleanup. CVE-2022-49822 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ata: libata-transport: fix double ata_host_put() in ata_tport_add() In the error path in ata_tport_add(), when calling put_device(), ata_tport_release() is called, it will put the refcount of 'ap->host'. And then ata_host_put() is called again, the refcount is decreased to 0, ata_host_release() is called, all ports are freed and set to null. When unbinding the device after failure, ata_host_stop() is called to release the resources, it leads a null-ptr-deref(), because all the ports all freed and null. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 CPU: 7 PID: 18671 Comm: modprobe Kdump: loaded Tainted: G E 6.1.0-rc3+ #8 pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ata_host_stop+0x3c/0x84 [libata] lr : release_nodes+0x64/0xd0 Call trace: ata_host_stop+0x3c/0x84 [libata] release_nodes+0x64/0xd0 devres_release_all+0xbc/0x1b0 device_unbind_cleanup+0x20/0x70 really_probe+0x158/0x320 __driver_probe_device+0x84/0x120 driver_probe_device+0x44/0x120 __driver_attach+0xb4/0x220 bus_for_each_dev+0x78/0xdc driver_attach+0x2c/0x40 bus_add_driver+0x184/0x240 driver_register+0x80/0x13c __pci_register_driver+0x4c/0x60 ahci_pci_driver_init+0x30/0x1000 [ahci] Fix this by removing redundant ata_host_put() in the error path. CVE-2022-49826 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/scheduler: fix fence ref counting We leaked dependency fences when processes were beeing killed. Additional to that grab a reference to the last scheduled fence. CVE-2022-49829 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: pinctrl: devicetree: fix null pointer dereferencing in pinctrl_dt_to_map Here is the BUG report by KASAN about null pointer dereference: BUG: KASAN: null-ptr-deref in strcmp+0x2e/0x50 Read of size 1 at addr 0000000000000000 by task python3/2640 Call Trace: strcmp __of_find_property of_find_property pinctrl_dt_to_map kasprintf() would return NULL pointer when kmalloc() fail to allocate. So directly return ENOMEM, if kasprintf() return NULL pointer. CVE-2022-49832 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: fix potential memleak in 'add_widget_node' As 'kobject_add' may allocated memory for 'kobject->name' when return error. And in this function, if call 'kobject_add' failed didn't free kobject. So call 'kobject_put' to recycling resources. CVE-2022-49835 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: bpf, test_run: Fix alignment problem in bpf_prog_test_run_skb() We got a syzkaller problem because of aarch64 alignment fault if KFENCE enabled. When the size from user bpf program is an odd number, like 399, 407, etc, it will cause the struct skb_shared_info's unaligned access. As seen below: BUG: KFENCE: use-after-free read in __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032 Use-after-free read at 0xffff6254fffac077 (in kfence-#213): __lse_atomic_add arch/arm64/include/asm/atomic_lse.h:26 [inline] arch_atomic_add arch/arm64/include/asm/atomic.h:28 [inline] arch_atomic_inc include/linux/atomic-arch-fallback.h:270 [inline] atomic_inc include/asm-generic/atomic-instrumented.h:241 [inline] __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032 skb_clone+0xf4/0x214 net/core/skbuff.c:1481 ____bpf_clone_redirect net/core/filter.c:2433 [inline] bpf_clone_redirect+0x78/0x1c0 net/core/filter.c:2420 bpf_prog_d3839dd9068ceb51+0x80/0x330 bpf_dispatcher_nop_func include/linux/bpf.h:728 [inline] bpf_test_run+0x3c0/0x6c0 net/bpf/test_run.c:53 bpf_prog_test_run_skb+0x638/0xa7c net/bpf/test_run.c:594 bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline] __do_sys_bpf kernel/bpf/syscall.c:4441 [inline] __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381 kfence-#213: 0xffff6254fffac000-0xffff6254fffac196, size=407, cache=kmalloc-512 allocated by task 15074 on cpu 0 at 1342.585390s: kmalloc include/linux/slab.h:568 [inline] kzalloc include/linux/slab.h:675 [inline] bpf_test_init.isra.0+0xac/0x290 net/bpf/test_run.c:191 bpf_prog_test_run_skb+0x11c/0xa7c net/bpf/test_run.c:512 bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline] __do_sys_bpf kernel/bpf/syscall.c:4441 [inline] __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381 __arm64_sys_bpf+0x50/0x60 kernel/bpf/syscall.c:4381 To fix the problem, we adjust @size so that (@size + @hearoom) is a multiple of SMP_CACHE_BYTES. So we make sure the struct skb_shared_info is aligned to a cache line. CVE-2022-49840 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ASoC: core: Fix use-after-free in snd_soc_exit() KASAN reports a use-after-free: BUG: KASAN: use-after-free in device_del+0xb5b/0xc60 Read of size 8 at addr ffff888008655050 by task rmmod/387 CPU: 2 PID: 387 Comm: rmmod Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <TASK> dump_stack_lvl+0x79/0x9a print_report+0x17f/0x47b kasan_report+0xbb/0xf0 device_del+0xb5b/0xc60 platform_device_del.part.0+0x24/0x200 platform_device_unregister+0x2e/0x40 snd_soc_exit+0xa/0x22 [snd_soc_core] __do_sys_delete_module.constprop.0+0x34f/0x5b0 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd ... </TASK> It's bacause in snd_soc_init(), snd_soc_util_init() is possble to fail, but its ret is ignored, which makes soc_dummy_dev unregistered twice. snd_soc_init() snd_soc_util_init() platform_device_register_simple(soc_dummy_dev) platform_driver_register() # fail platform_device_unregister(soc_dummy_dev) platform_driver_register() # success ... snd_soc_exit() snd_soc_util_exit() # soc_dummy_dev will be unregistered for second time To fix it, handle error and stop snd_soc_init() when util_init() fail. Also clean debugfs when util_init() or driver_register() fail. CVE-2022-49842 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: udf: Fix a slab-out-of-bounds write bug in udf_find_entry() Syzbot reported a slab-out-of-bounds Write bug: loop0: detected capacity change from 0 to 2048 ================================================================== BUG: KASAN: slab-out-of-bounds in udf_find_entry+0x8a5/0x14f0 fs/udf/namei.c:253 Write of size 105 at addr ffff8880123ff896 by task syz-executor323/3610 CPU: 0 PID: 3610 Comm: syz-executor323 Not tainted 6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022 Call Trace: <TASK> __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+0xcd/0x100 mm/kasan/report.c:495 kasan_check_range+0x2a7/0x2e0 mm/kasan/generic.c:189 memcpy+0x3c/0x60 mm/kasan/shadow.c:66 udf_find_entry+0x8a5/0x14f0 fs/udf/namei.c:253 udf_lookup+0xef/0x340 fs/udf/namei.c:309 lookup_open fs/namei.c:3391 [inline] open_last_lookups fs/namei.c:3481 [inline] path_openat+0x10e6/0x2df0 fs/namei.c:3710 do_filp_open+0x264/0x4f0 fs/namei.c:3740 do_sys_openat2+0x124/0x4e0 fs/open.c:1310 do_sys_open fs/open.c:1326 [inline] __do_sys_creat fs/open.c:1402 [inline] __se_sys_creat fs/open.c:1396 [inline] __x64_sys_creat+0x11f/0x160 fs/open.c:1396 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 RIP: 0033:0x7ffab0d164d9 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 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffe1a7e6bb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000055 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffab0d164d9 RDX: 00007ffab0d164d9 RSI: 0000000000000000 RDI: 0000000020000180 RBP: 00007ffab0cd5a10 R08: 0000000000000000 R09: 0000000000000000 R10: 00005555573552c0 R11: 0000000000000246 R12: 00007ffab0cd5aa0 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> Allocated by task 3610: kasan_save_stack mm/kasan/common.c:45 [inline] kasan_set_track+0x3d/0x60 mm/kasan/common.c:52 ____kasan_kmalloc mm/kasan/common.c:371 [inline] __kasan_kmalloc+0x97/0xb0 mm/kasan/common.c:380 kmalloc include/linux/slab.h:576 [inline] udf_find_entry+0x7b6/0x14f0 fs/udf/namei.c:243 udf_lookup+0xef/0x340 fs/udf/namei.c:309 lookup_open fs/namei.c:3391 [inline] open_last_lookups fs/namei.c:3481 [inline] path_openat+0x10e6/0x2df0 fs/namei.c:3710 do_filp_open+0x264/0x4f0 fs/namei.c:3740 do_sys_openat2+0x124/0x4e0 fs/open.c:1310 do_sys_open fs/open.c:1326 [inline] __do_sys_creat fs/open.c:1402 [inline] __se_sys_creat fs/open.c:1396 [inline] __x64_sys_creat+0x11f/0x160 fs/open.c:1396 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 The buggy address belongs to the object at ffff8880123ff800 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 150 bytes inside of 256-byte region [ffff8880123ff800, ffff8880123ff900) The buggy address belongs to the physical page: page:ffffea000048ff80 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x123fe head:ffffea000048ff80 order:1 compound_mapcount:0 compound_pincount:0 flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000010200 ffffea00004b8500 dead000000000003 ffff888012041b40 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x0(), pid 1, tgid 1 (swapper/0), ts 1841222404, free_ts 0 create_dummy_stack mm/page_owner.c: ---truncated--- CVE-2022-49846 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: macvlan: fix memory leaks of macvlan_common_newlink kmemleak reports memory leaks in macvlan_common_newlink, as follows: ip link add link eth0 name .. type macvlan mode source macaddr add <MAC-ADDR> kmemleak reports: unreferenced object 0xffff8880109bb140 (size 64): comm "ip", pid 284, jiffies 4294986150 (age 430.108s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 b8 aa 5a 12 80 88 ff ff ..........Z..... 80 1b fa 0d 80 88 ff ff 1e ff ac af c7 c1 6b 6b ..............kk backtrace: [<ffffffff813e06a7>] kmem_cache_alloc_trace+0x1c7/0x300 [<ffffffff81b66025>] macvlan_hash_add_source+0x45/0xc0 [<ffffffff81b66a67>] macvlan_changelink_sources+0xd7/0x170 [<ffffffff81b6775c>] macvlan_common_newlink+0x38c/0x5a0 [<ffffffff81b6797e>] macvlan_newlink+0xe/0x20 [<ffffffff81d97f8f>] __rtnl_newlink+0x7af/0xa50 [<ffffffff81d98278>] rtnl_newlink+0x48/0x70 ... In the scenario where the macvlan mode is configured as 'source', macvlan_changelink_sources() will be execured to reconfigure list of remote source mac addresses, at the same time, if register_netdevice() return an error, the resource generated by macvlan_changelink_sources() is not cleaned up. Using this patch, in the case of an error, it will execute macvlan_flush_sources() to ensure that the resource is cleaned up. CVE-2022-49853 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: dmaengine: mv_xor_v2: Fix a resource leak in mv_xor_v2_remove() A clk_prepare_enable() call in the probe is not balanced by a corresponding clk_disable_unprepare() in the remove function. Add the missing call. CVE-2022-49861 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: tipc: fix the msg->req tlv len check in tipc_nl_compat_name_table_dump_header This is a follow-up for commit 974cb0e3e7c9 ("tipc: fix uninit-value in tipc_nl_compat_name_table_dump") where it should have type casted sizeof(..) to int to work when TLV_GET_DATA_LEN() returns a negative value. syzbot reported a call trace because of it: BUG: KMSAN: uninit-value in ... tipc_nl_compat_name_table_dump+0x841/0xea0 net/tipc/netlink_compat.c:934 __tipc_nl_compat_dumpit+0xab2/0x1320 net/tipc/netlink_compat.c:238 tipc_nl_compat_dumpit+0x991/0xb50 net/tipc/netlink_compat.c:321 tipc_nl_compat_recv+0xb6e/0x1640 net/tipc/netlink_compat.c:1324 genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline] genl_family_rcv_msg net/netlink/genetlink.c:775 [inline] genl_rcv_msg+0x103f/0x1260 net/netlink/genetlink.c:792 netlink_rcv_skb+0x3a5/0x6c0 net/netlink/af_netlink.c:2501 genl_rcv+0x3c/0x50 net/netlink/genetlink.c:803 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0xf3b/0x1270 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x1288/0x1440 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] CVE-2022-49862 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ipv6: addrlabel: fix infoleak when sending struct ifaddrlblmsg to network When copying a `struct ifaddrlblmsg` to the network, __ifal_reserved remained uninitialized, resulting in a 1-byte infoleak: BUG: KMSAN: kernel-network-infoleak in __netdev_start_xmit ./include/linux/netdevice.h:4841 __netdev_start_xmit ./include/linux/netdevice.h:4841 netdev_start_xmit ./include/linux/netdevice.h:4857 xmit_one net/core/dev.c:3590 dev_hard_start_xmit+0x1dc/0x800 net/core/dev.c:3606 __dev_queue_xmit+0x17e8/0x4350 net/core/dev.c:4256 dev_queue_xmit ./include/linux/netdevice.h:3009 __netlink_deliver_tap_skb net/netlink/af_netlink.c:307 __netlink_deliver_tap+0x728/0xad0 net/netlink/af_netlink.c:325 netlink_deliver_tap net/netlink/af_netlink.c:338 __netlink_sendskb net/netlink/af_netlink.c:1263 netlink_sendskb+0x1d9/0x200 net/netlink/af_netlink.c:1272 netlink_unicast+0x56d/0xf50 net/netlink/af_netlink.c:1360 nlmsg_unicast ./include/net/netlink.h:1061 rtnl_unicast+0x5a/0x80 net/core/rtnetlink.c:758 ip6addrlbl_get+0xfad/0x10f0 net/ipv6/addrlabel.c:628 rtnetlink_rcv_msg+0xb33/0x1570 net/core/rtnetlink.c:6082 ... Uninit was created at: slab_post_alloc_hook+0x118/0xb00 mm/slab.h:742 slab_alloc_node mm/slub.c:3398 __kmem_cache_alloc_node+0x4f2/0x930 mm/slub.c:3437 __do_kmalloc_node mm/slab_common.c:954 __kmalloc_node_track_caller+0x117/0x3d0 mm/slab_common.c:975 kmalloc_reserve net/core/skbuff.c:437 __alloc_skb+0x27a/0xab0 net/core/skbuff.c:509 alloc_skb ./include/linux/skbuff.h:1267 nlmsg_new ./include/net/netlink.h:964 ip6addrlbl_get+0x490/0x10f0 net/ipv6/addrlabel.c:608 rtnetlink_rcv_msg+0xb33/0x1570 net/core/rtnetlink.c:6082 netlink_rcv_skb+0x299/0x550 net/netlink/af_netlink.c:2540 rtnetlink_rcv+0x26/0x30 net/core/rtnetlink.c:6109 netlink_unicast_kernel net/netlink/af_netlink.c:1319 netlink_unicast+0x9ab/0xf50 net/netlink/af_netlink.c:1345 netlink_sendmsg+0xebc/0x10f0 net/netlink/af_netlink.c:1921 ... This patch ensures that the reserved field is always initialized. CVE-2022-49865 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: tun: Fix memory leaks of napi_get_frags kmemleak reports after running test_progs: unreferenced object 0xffff8881b1672dc0 (size 232): comm "test_progs", pid 394388, jiffies 4354712116 (age 841.975s) hex dump (first 32 bytes): e0 84 d7 a8 81 88 ff ff 80 2c 67 b1 81 88 ff ff .........,g..... 00 40 c5 9b 81 88 ff ff 00 00 00 00 00 00 00 00 .@.............. backtrace: [<00000000c8f01748>] napi_skb_cache_get+0xd4/0x150 [<0000000041c7fc09>] __napi_build_skb+0x15/0x50 [<00000000431c7079>] __napi_alloc_skb+0x26e/0x540 [<000000003ecfa30e>] napi_get_frags+0x59/0x140 [<0000000099b2199e>] tun_get_user+0x183d/0x3bb0 [tun] [<000000008a5adef0>] tun_chr_write_iter+0xc0/0x1b1 [tun] [<0000000049993ff4>] do_iter_readv_writev+0x19f/0x320 [<000000008f338ea2>] do_iter_write+0x135/0x630 [<000000008a3377a4>] vfs_writev+0x12e/0x440 [<00000000a6b5639a>] do_writev+0x104/0x280 [<00000000ccf065d8>] do_syscall_64+0x3b/0x90 [<00000000d776e329>] entry_SYSCALL_64_after_hwframe+0x63/0xcd The issue occurs in the following scenarios: tun_get_user() napi_gro_frags() napi_frags_finish() case GRO_NORMAL: gro_normal_one() list_add_tail(&skb->list, &napi->rx_list); <-- While napi->rx_count < READ_ONCE(gro_normal_batch), <-- gro_normal_list() is not called, napi->rx_list is not empty <-- not ask to complete the gro work, will cause memory leaks in <-- following tun_napi_del() ... tun_napi_del() netif_napi_del() __netif_napi_del() <-- &napi->rx_list is not empty, which caused memory leaks To fix, add napi_complete() after napi_gro_frags(). CVE-2022-49871 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: gso: fix panic on frag_list with mixed head alloc types Since commit 3dcbdb134f32 ("net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list"), it is allowed to change gso_size of a GRO packet. However, that commit assumes that "checking the first list_skb member suffices; i.e if either of the list_skb members have non head_frag head, then the first one has too". It turns out this assumption does not hold. We've seen BUG_ON being hit in skb_segment when skbs on the frag_list had differing head_frag with the vmxnet3 driver. This happens because __netdev_alloc_skb and __napi_alloc_skb can return a skb that is page backed or kmalloced depending on the requested size. As the result, the last small skb in the GRO packet can be kmalloced. There are three different locations where this can be fixed: (1) We could check head_frag in GRO and not allow GROing skbs with different head_frag. However, that would lead to performance regression on normal forward paths with unmodified gso_size, where !head_frag in the last packet is not a problem. (2) Set a flag in bpf_skb_net_grow and bpf_skb_net_shrink indicating that NETIF_F_SG is undesirable. That would need to eat a bit in sk_buff. Furthermore, that flag can be unset when all skbs on the frag_list are page backed. To retain good performance, bpf_skb_net_grow/shrink would have to walk the frag_list. (3) Walk the frag_list in skb_segment when determining whether NETIF_F_SG should be cleared. This of course slows things down. This patch implements (3). To limit the performance impact in skb_segment, the list is walked only for skbs with SKB_GSO_DODGY set that have gso_size changed. Normal paths thus will not hit it. We could check only the last skb but since we need to walk the whole list anyway, let's stay on the safe side. CVE-2022-49872 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: HID: hyperv: fix possible memory leak in mousevsc_probe() If hid_add_device() returns error, it should call hid_destroy_device() to free hid_dev which is allocated in hid_allocate_device(). CVE-2022-49874 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ext4: fix warning in 'ext4_da_release_space' Syzkaller report issue as follows: EXT4-fs (loop0): Free/Dirty block details EXT4-fs (loop0): free_blocks=0 EXT4-fs (loop0): dirty_blocks=0 EXT4-fs (loop0): Block reservation details EXT4-fs (loop0): i_reserved_data_blocks=0 EXT4-fs warning (device loop0): ext4_da_release_space:1527: ext4_da_release_space: ino 18, to_free 1 with only 0 reserved data blocks ------------[ cut here ]------------ WARNING: CPU: 0 PID: 92 at fs/ext4/inode.c:1528 ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1524 Modules linked in: CPU: 0 PID: 92 Comm: kworker/u4:4 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Workqueue: writeback wb_workfn (flush-7:0) RIP: 0010:ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1528 RSP: 0018:ffffc900015f6c90 EFLAGS: 00010296 RAX: 42215896cd52ea00 RBX: 0000000000000000 RCX: 42215896cd52ea00 RDX: 0000000000000000 RSI: 0000000080000001 RDI: 0000000000000000 RBP: 1ffff1100e907d96 R08: ffffffff816aa79d R09: fffff520002bece5 R10: fffff520002bece5 R11: 1ffff920002bece4 R12: ffff888021fd2000 R13: ffff88807483ecb0 R14: 0000000000000001 R15: ffff88807483e740 FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005555569ba628 CR3: 000000000c88e000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ext4_es_remove_extent+0x1ab/0x260 fs/ext4/extents_status.c:1461 mpage_release_unused_pages+0x24d/0xef0 fs/ext4/inode.c:1589 ext4_writepages+0x12eb/0x3be0 fs/ext4/inode.c:2852 do_writepages+0x3c3/0x680 mm/page-writeback.c:2469 __writeback_single_inode+0xd1/0x670 fs/fs-writeback.c:1587 writeback_sb_inodes+0xb3b/0x18f0 fs/fs-writeback.c:1870 wb_writeback+0x41f/0x7b0 fs/fs-writeback.c:2044 wb_do_writeback fs/fs-writeback.c:2187 [inline] wb_workfn+0x3cb/0xef0 fs/fs-writeback.c:2227 process_one_work+0x877/0xdb0 kernel/workqueue.c:2289 worker_thread+0xb14/0x1330 kernel/workqueue.c:2436 kthread+0x266/0x300 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK> Above issue may happens as follows: ext4_da_write_begin ext4_create_inline_data ext4_clear_inode_flag(inode, EXT4_INODE_EXTENTS); ext4_set_inode_flag(inode, EXT4_INODE_INLINE_DATA); __ext4_ioctl ext4_ext_migrate -> will lead to eh->eh_entries not zero, and set extent flag ext4_da_write_begin ext4_da_convert_inline_data_to_extent ext4_da_write_inline_data_begin ext4_da_map_blocks ext4_insert_delayed_block if (!ext4_es_scan_clu(inode, &ext4_es_is_delonly, lblk)) if (!ext4_es_scan_clu(inode, &ext4_es_is_mapped, lblk)) ext4_clu_mapped(inode, EXT4_B2C(sbi, lblk)); -> will return 1 allocated = true; ext4_es_insert_delayed_block(inode, lblk, allocated); ext4_writepages mpage_map_and_submit_extent(handle, &mpd, &give_up_on_write); -> return -ENOSPC mpage_release_unused_pages(&mpd, give_up_on_write); -> give_up_on_write == 1 ext4_es_remove_extent ext4_da_release_space(inode, reserved); if (unlikely(to_free > ei->i_reserved_data_blocks)) -> to_free == 1 but ei->i_reserved_data_blocks == 0 -> then trigger warning as above To solve above issue, forbid inode do migrate which has inline data. CVE-2022-49880 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Check for NULL cpu_buffer in ring_buffer_wake_waiters() On some machines the number of listed CPUs may be bigger than the actual CPUs that exist. The tracing subsystem allocates a per_cpu directory with access to the per CPU ring buffer via a cpuX file. But to save space, the ring buffer will only allocate buffers for online CPUs, even though the CPU array will be as big as the nr_cpu_ids. With the addition of waking waiters on the ring buffer when closing the file, the ring_buffer_wake_waiters() now needs to make sure that the buffer is allocated (with the irq_work allocated with it) before trying to wake waiters, as it will cause a NULL pointer dereference. While debugging this, I added a NULL check for the buffer itself (which is OK to do), and also NULL pointer checks against buffer->buffers (which is not fine, and will WARN) as well as making sure the CPU number passed in is within the nr_cpu_ids (which is also not fine if it isn't). Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1204705 CVE-2022-49889 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix use-after-free for dynamic ftrace_ops KASAN reported a use-after-free with ftrace ops [1]. It was found from vmcore that perf had registered two ops with the same content successively, both dynamic. After unregistering the second ops, a use-after-free occurred. In ftrace_shutdown(), when the second ops is unregistered, the FTRACE_UPDATE_CALLS command is not set because there is another enabled ops with the same content. Also, both ops are dynamic and the ftrace callback function is ftrace_ops_list_func, so the FTRACE_UPDATE_TRACE_FUNC command will not be set. Eventually the value of 'command' will be 0 and ftrace_shutdown() will skip the rcu synchronization. However, ftrace may be activated. When the ops is released, another CPU may be accessing the ops. Add the missing synchronization to fix this problem. [1] BUG: KASAN: use-after-free in __ftrace_ops_list_func kernel/trace/ftrace.c:7020 [inline] BUG: KASAN: use-after-free in ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049 Read of size 8 at addr ffff56551965bbc8 by task syz-executor.2/14468 CPU: 1 PID: 14468 Comm: syz-executor.2 Not tainted 5.10.0 #7 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0x0/0x40c arch/arm64/kernel/stacktrace.c:132 show_stack+0x30/0x40 arch/arm64/kernel/stacktrace.c:196 __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1b4/0x248 lib/dump_stack.c:118 print_address_description.constprop.0+0x28/0x48c mm/kasan/report.c:387 __kasan_report mm/kasan/report.c:547 [inline] kasan_report+0x118/0x210 mm/kasan/report.c:564 check_memory_region_inline mm/kasan/generic.c:187 [inline] __asan_load8+0x98/0xc0 mm/kasan/generic.c:253 __ftrace_ops_list_func kernel/trace/ftrace.c:7020 [inline] ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049 ftrace_graph_call+0x0/0x4 __might_sleep+0x8/0x100 include/linux/perf_event.h:1170 __might_fault mm/memory.c:5183 [inline] __might_fault+0x58/0x70 mm/memory.c:5171 do_strncpy_from_user lib/strncpy_from_user.c:41 [inline] strncpy_from_user+0x1f4/0x4b0 lib/strncpy_from_user.c:139 getname_flags+0xb0/0x31c fs/namei.c:149 getname+0x2c/0x40 fs/namei.c:209 [...] Allocated by task 14445: kasan_save_stack+0x24/0x50 mm/kasan/common.c:48 kasan_set_track mm/kasan/common.c:56 [inline] __kasan_kmalloc mm/kasan/common.c:479 [inline] __kasan_kmalloc.constprop.0+0x110/0x13c mm/kasan/common.c:449 kasan_kmalloc+0xc/0x14 mm/kasan/common.c:493 kmem_cache_alloc_trace+0x440/0x924 mm/slub.c:2950 kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:675 [inline] perf_event_alloc.part.0+0xb4/0x1350 kernel/events/core.c:11230 perf_event_alloc kernel/events/core.c:11733 [inline] __do_sys_perf_event_open kernel/events/core.c:11831 [inline] __se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723 __arm64_sys_perf_event_open+0x6c/0x80 kernel/events/core.c:11723 [...] Freed by task 14445: kasan_save_stack+0x24/0x50 mm/kasan/common.c:48 kasan_set_track+0x24/0x34 mm/kasan/common.c:56 kasan_set_free_info+0x20/0x40 mm/kasan/generic.c:358 __kasan_slab_free.part.0+0x11c/0x1b0 mm/kasan/common.c:437 __kasan_slab_free mm/kasan/common.c:445 [inline] kasan_slab_free+0x2c/0x40 mm/kasan/common.c:446 slab_free_hook mm/slub.c:1569 [inline] slab_free_freelist_hook mm/slub.c:1608 [inline] slab_free mm/slub.c:3179 [inline] kfree+0x12c/0xc10 mm/slub.c:4176 perf_event_alloc.part.0+0xa0c/0x1350 kernel/events/core.c:11434 perf_event_alloc kernel/events/core.c:11733 [inline] __do_sys_perf_event_open kernel/events/core.c:11831 [inline] __se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723 [...] CVE-2022-49892 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: btrfs: fix tree mod log mishandling of reallocated nodes We have been seeing the following panic in production kernel BUG at fs/btrfs/tree-mod-log.c:677! invalid opcode: 0000 [#1] SMP RIP: 0010:tree_mod_log_rewind+0x1b4/0x200 RSP: 0000:ffffc9002c02f890 EFLAGS: 00010293 RAX: 0000000000000003 RBX: ffff8882b448c700 RCX: 0000000000000000 RDX: 0000000000008000 RSI: 00000000000000a7 RDI: ffff88877d831c00 RBP: 0000000000000002 R08: 000000000000009f R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000100c40 R12: 0000000000000001 R13: ffff8886c26d6a00 R14: ffff88829f5424f8 R15: ffff88877d831a00 FS: 00007fee1d80c780(0000) GS:ffff8890400c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fee1963a020 CR3: 0000000434f33002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: btrfs_get_old_root+0x12b/0x420 btrfs_search_old_slot+0x64/0x2f0 ? tree_mod_log_oldest_root+0x3d/0xf0 resolve_indirect_ref+0xfd/0x660 ? ulist_alloc+0x31/0x60 ? kmem_cache_alloc_trace+0x114/0x2c0 find_parent_nodes+0x97a/0x17e0 ? ulist_alloc+0x30/0x60 btrfs_find_all_roots_safe+0x97/0x150 iterate_extent_inodes+0x154/0x370 ? btrfs_search_path_in_tree+0x240/0x240 iterate_inodes_from_logical+0x98/0xd0 ? btrfs_search_path_in_tree+0x240/0x240 btrfs_ioctl_logical_to_ino+0xd9/0x180 btrfs_ioctl+0xe2/0x2ec0 ? __mod_memcg_lruvec_state+0x3d/0x280 ? do_sys_openat2+0x6d/0x140 ? kretprobe_dispatcher+0x47/0x70 ? kretprobe_rethook_handler+0x38/0x50 ? rethook_trampoline_handler+0x82/0x140 ? arch_rethook_trampoline_callback+0x3b/0x50 ? kmem_cache_free+0xfb/0x270 ? do_sys_openat2+0xd5/0x140 __x64_sys_ioctl+0x71/0xb0 do_syscall_64+0x2d/0x40 Which is this code in tree_mod_log_rewind() switch (tm->op) { case BTRFS_MOD_LOG_KEY_REMOVE_WHILE_FREEING: BUG_ON(tm->slot < n); This occurs because we replay the nodes in order that they happened, and when we do a REPLACE we will log a REMOVE_WHILE_FREEING for every slot, starting at 0. 'n' here is the number of items in this block, which in this case was 1, but we had 2 REMOVE_WHILE_FREEING operations. The actual root cause of this was that we were replaying operations for a block that shouldn't have been replayed. Consider the following sequence of events 1. We have an already modified root, and we do a btrfs_get_tree_mod_seq(). 2. We begin removing items from this root, triggering KEY_REPLACE for it's child slots. 3. We remove one of the 2 children this root node points to, thus triggering the root node promotion of the remaining child, and freeing this node. 4. We modify a new root, and re-allocate the above node to the root node of this other root. The tree mod log looks something like this logical 0 op KEY_REPLACE (slot 1) seq 2 logical 0 op KEY_REMOVE (slot 1) seq 3 logical 0 op KEY_REMOVE_WHILE_FREEING (slot 0) seq 4 logical 4096 op LOG_ROOT_REPLACE (old logical 0) seq 5 logical 8192 op KEY_REMOVE_WHILE_FREEING (slot 1) seq 6 logical 8192 op KEY_REMOVE_WHILE_FREEING (slot 0) seq 7 logical 0 op LOG_ROOT_REPLACE (old logical 8192) seq 8 >From here the bug is triggered by the following steps 1. Call btrfs_get_old_root() on the new_root. 2. We call tree_mod_log_oldest_root(btrfs_root_node(new_root)), which is currently logical 0. 3. tree_mod_log_oldest_root() calls tree_mod_log_search_oldest(), which gives us the KEY_REPLACE seq 2, and since that's not a LOG_ROOT_REPLACE we incorrectly believe that we don't have an old root, because we expect that the most recent change should be a LOG_ROOT_REPLACE. 4. Back in tree_mod_log_oldest_root() we don't have a LOG_ROOT_REPLACE, so we don't set old_root, we simply use our e ---truncated--- CVE-2022-49898 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ibmvnic: Free rwi on reset success Free the rwi structure in the event that the last rwi in the list processed successfully. The logic in commit 4f408e1fa6e1 ("ibmvnic: retry reset if there are no other resets") introduces an issue that results in a 32 byte memory leak whenever the last rwi in the list gets processed. CVE-2022-49906 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: mdio: fix undefined behavior in bit shift for __mdiobus_register Shifting signed 32-bit value by 31 bits is undefined, so changing significant bit to unsigned. The UBSAN warning calltrace like below: UBSAN: shift-out-of-bounds in drivers/net/phy/mdio_bus.c:586:27 left shift of 1 by 31 places cannot be represented in type 'int' Call Trace: <TASK> dump_stack_lvl+0x7d/0xa5 dump_stack+0x15/0x1b ubsan_epilogue+0xe/0x4e __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c __mdiobus_register+0x49d/0x4e0 fixed_mdio_bus_init+0xd8/0x12d do_one_initcall+0x76/0x430 kernel_init_freeable+0x3b3/0x422 kernel_init+0x24/0x1e0 ret_from_fork+0x1f/0x30 </TASK> CVE-2022-49907 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: btrfs: fix inode list leak during backref walking at find_parent_nodes() During backref walking, at find_parent_nodes(), if we are dealing with a data extent and we get an error while resolving the indirect backrefs, at resolve_indirect_refs(), or in the while loop that iterates over the refs in the direct refs rbtree, we end up leaking the inode lists attached to the direct refs we have in the direct refs rbtree that were not yet added to the refs ulist passed as argument to find_parent_nodes(). Since they were not yet added to the refs ulist and prelim_release() does not free the lists, on error the caller can only free the lists attached to the refs that were added to the refs ulist, all the remaining refs get their inode lists never freed, therefore leaking their memory. Fix this by having prelim_release() always free any attached inode list to each ref found in the rbtree, and have find_parent_nodes() set the ref's inode list to NULL once it transfers ownership of the inode list to a ref added to the refs ulist passed to find_parent_nodes(). CVE-2022-49913 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: btrfs: fix inode list leak during backref walking at resolve_indirect_refs() During backref walking, at resolve_indirect_refs(), if we get an error we jump to the 'out' label and call ulist_free() on the 'parents' ulist, which frees all the elements in the ulist - however that does not free any inode lists that may be attached to elements, through the 'aux' field of a ulist node, so we end up leaking lists if we have any attached to the unodes. Fix this by calling free_leaf_list() instead of ulist_free() when we exit from resolve_indirect_refs(). The static function free_leaf_list() is moved up for this to be possible and it's slightly simplified by removing unnecessary code. CVE-2022-49914 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: mISDN: fix possible memory leak in mISDN_register_device() Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array"), the name of device is allocated dynamically, add put_device() to give up the reference, so that the name can be freed in kobject_cleanup() when the refcount is 0. Set device class before put_device() to avoid null release() function WARN message in device_release(). CVE-2022-49915 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: nfc: nfcmrvl: Fix potential memory leak in nfcmrvl_i2c_nci_send() nfcmrvl_i2c_nci_send() will be called by nfcmrvl_nci_send(), and skb should be freed in nfcmrvl_i2c_nci_send(). However, nfcmrvl_nci_send() will only free skb when i2c_master_send() return >=0, which means skb will memleak when i2c_master_send() failed. Free skb no matter whether i2c_master_send() succeeds. CVE-2022-49922 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: nfc: nxp-nci: Fix potential memory leak in nxp_nci_send() nxp_nci_send() will call nxp_nci_i2c_write(), and only free skb when nxp_nci_i2c_write() failed. However, even if the nxp_nci_i2c_write() run succeeds, the skb will not be freed in nxp_nci_i2c_write(). As the result, the skb will memleak. nxp_nci_send() should also free the skb when nxp_nci_i2c_write() succeeds. CVE-2022-49923 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: nfc: fdp: Fix potential memory leak in fdp_nci_send() fdp_nci_send() will call fdp_nci_i2c_write that will not free skb in the function. As a result, when fdp_nci_i2c_write() finished, the skb will memleak. fdp_nci_send() should free skb after fdp_nci_i2c_write() finished. CVE-2022-49924 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix null-ptr-deref in ib_core_cleanup() KASAN reported a null-ptr-deref error: KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] CPU: 1 PID: 379 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:destroy_workqueue+0x2f/0x740 RSP: 0018:ffff888016137df8 EFLAGS: 00000202 ... Call Trace: ib_core_cleanup+0xa/0xa1 [ib_core] __do_sys_delete_module.constprop.0+0x34f/0x5b0 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fa1a0d221b7 ... It is because the fail of roce_gid_mgmt_init() is ignored: ib_core_init() roce_gid_mgmt_init() gid_cache_wq = alloc_ordered_workqueue # fail ... ib_core_cleanup() roce_gid_mgmt_cleanup() destroy_workqueue(gid_cache_wq) # destroy an unallocated wq Fix this by catching the fail of roce_gid_mgmt_init() in ib_core_init(). CVE-2022-49925 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: nfs4: Fix kmemleak when allocate slot failed If one of the slot allocate failed, should cleanup all the other allocated slots, otherwise, the allocated slots will leak: unreferenced object 0xffff8881115aa100 (size 64): comm ""mount.nfs"", pid 679, jiffies 4294744957 (age 115.037s) hex dump (first 32 bytes): 00 cc 19 73 81 88 ff ff 00 a0 5a 11 81 88 ff ff ...s......Z..... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000007a4c434a>] nfs4_find_or_create_slot+0x8e/0x130 [<000000005472a39c>] nfs4_realloc_slot_table+0x23f/0x270 [<00000000cd8ca0eb>] nfs40_init_client+0x4a/0x90 [<00000000128486db>] nfs4_init_client+0xce/0x270 [<000000008d2cacad>] nfs4_set_client+0x1a2/0x2b0 [<000000000e593b52>] nfs4_create_server+0x300/0x5f0 [<00000000e4425dd2>] nfs4_try_get_tree+0x65/0x110 [<00000000d3a6176f>] vfs_get_tree+0x41/0xf0 [<0000000016b5ad4c>] path_mount+0x9b3/0xdd0 [<00000000494cae71>] __x64_sys_mount+0x190/0x1d0 [<000000005d56bdec>] do_syscall_64+0x35/0x80 [<00000000687c9ae4>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 CVE-2022-49927 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Correctly move list in sc_disable() Commit 13bac861952a ("IB/hfi1: Fix abba locking issue with sc_disable()") incorrectly tries to move a list from one list head to another. The result is a kernel crash. The crash is triggered when a link goes down and there are waiters for a send to complete. The following signature is seen: BUG: kernel NULL pointer dereference, address: 0000000000000030 [...] Call Trace: sc_disable+0x1ba/0x240 [hfi1] pio_freeze+0x3d/0x60 [hfi1] handle_freeze+0x27/0x1b0 [hfi1] process_one_work+0x1b0/0x380 ? process_one_work+0x380/0x380 worker_thread+0x30/0x360 ? process_one_work+0x380/0x380 kthread+0xd7/0x100 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 The fix is to use the correct call to move the list. CVE-2022-49931 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate A memory leak flaw was found in the Linux kernel's Stream Control Transmission Protocol. This issue may occur when a user starts a malicious networking service and someone connects to this service. This could allow a local user to starve resources, causing a denial of service. CVE-2023-1074 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate A use-after-free flaw was found in btsdio_remove in drivers\bluetooth\btsdio.c in the Linux Kernel. In this flaw, a call to btsdio_remove with an unfinished job, may cause a race problem leading to a UAF on hdev devices. CVE-2023-1989 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 important A use-after-free flaw was found in ndlc_remove in drivers/nfc/st-nci/ndlc.c in the Linux Kernel. This flaw could allow an attacker to crash the system due to a race problem. CVE-2023-1990 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 important A use-after-free vulnerability was found in iscsi_sw_tcp_session_create in drivers/scsi/iscsi_tcp.c in SCSI sub-component in the Linux Kernel. In this flaw an attacker could leak kernel internal information. CVE-2023-2162 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 important A use-after-free flaw was found in vcs_read in drivers/tty/vt/vc_screen.c in vc_screen in the Linux Kernel. This issue may allow an attacker with local user access to cause a system crash or leak internal kernel information. CVE-2023-3567 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 important libexpat through 2.5.0 allows a denial of service (resource consumption) because many full reparsings are required in the case of a large token for which multiple buffer fills are needed. CVE-2023-52425 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:expat-2.7.1-21.43.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libexpat1-2.7.1-21.43.1 moderate In the Linux kernel, the following vulnerability has been resolved: thermal: core: prevent potential string overflow The dev->id value comes from ida_alloc() so it's a number between zero and INT_MAX. If it's too high then these sprintf()s will overflow. CVE-2023-52868 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: Squashfs: fix handling and sanity checking of xattr_ids count A Sysbot [1] corrupted filesystem exposes two flaws in the handling and sanity checking of the xattr_ids count in the filesystem. Both of these flaws cause computation overflow due to incorrect typing. In the corrupted filesystem the xattr_ids value is 4294967071, which stored in a signed variable becomes the negative number -225. Flaw 1 (64-bit systems only): The signed integer xattr_ids variable causes sign extension. This causes variable overflow in the SQUASHFS_XATTR_*(A) macros. The variable is first multiplied by sizeof(struct squashfs_xattr_id) where the type of the sizeof operator is "unsigned long". On a 64-bit system this is 64-bits in size, and causes the negative number to be sign extended and widened to 64-bits and then become unsigned. This produces the very large number 18446744073709548016 or 2^64 - 3600. This number when rounded up by SQUASHFS_METADATA_SIZE - 1 (8191 bytes) and divided by SQUASHFS_METADATA_SIZE overflows and produces a length of 0 (stored in len). Flaw 2 (32-bit systems only): On a 32-bit system the integer variable is not widened by the unsigned long type of the sizeof operator (32-bits), and the signedness of the variable has no effect due it always being treated as unsigned. The above corrupted xattr_ids value of 4294967071, when multiplied overflows and produces the number 4294963696 or 2^32 - 3400. This number when rounded up by SQUASHFS_METADATA_SIZE - 1 (8191 bytes) and divided by SQUASHFS_METADATA_SIZE overflows again and produces a length of 0. The effect of the 0 length computation: In conjunction with the corrupted xattr_ids field, the filesystem also has a corrupted xattr_table_start value, where it matches the end of filesystem value of 850. This causes the following sanity check code to fail because the incorrectly computed len of 0 matches the incorrect size of the table reported by the superblock (0 bytes). len = SQUASHFS_XATTR_BLOCK_BYTES(*xattr_ids); indexes = SQUASHFS_XATTR_BLOCKS(*xattr_ids); /* * The computed size of the index table (len bytes) should exactly * match the table start and end points */ start = table_start + sizeof(*id_table); end = msblk->bytes_used; if (len != (end - start)) return ERR_PTR(-EINVAL); Changing the xattr_ids variable to be "usigned int" fixes the flaw on a 64-bit system. This relies on the fact the computation is widened by the unsigned long type of the sizeof operator. Casting the variable to u64 in the above macro fixes this flaw on a 32-bit system. It also means 64-bit systems do not implicitly rely on the type of the sizeof operator to widen the computation. [1] https://lore.kernel.org/lkml/000000000000cd44f005f1a0f17f@google.com/ CVE-2023-52933 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: mm/khugepaged: fix ->anon_vma race If an ->anon_vma is attached to the VMA, collapse_and_free_pmd() requires it to be locked. Page table traversal is allowed under any one of the mmap lock, the anon_vma lock (if the VMA is associated with an anon_vma), and the mapping lock (if the VMA is associated with a mapping); and so to be able to remove page tables, we must hold all three of them. retract_page_tables() bails out if an ->anon_vma is attached, but does this check before holding the mmap lock (as the comment above the check explains). If we racily merged an existing ->anon_vma (shared with a child process) from a neighboring VMA, subsequent rmap traversals on pages belonging to the child will be able to see the page tables that we are concurrently removing while assuming that nothing else can access them. Repeat the ->anon_vma check once we hold the mmap lock to ensure that there really is no concurrent page table access. Hitting this bug causes a lockdep warning in collapse_and_free_pmd(), in the line "lockdep_assert_held_write(&vma->anon_vma->root->rwsem)". It can also lead to use-after-free access. CVE-2023-52935 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: iscsi_tcp: Fix UAF during logout when accessing the shost ipaddress Bug report and analysis from Ding Hui. During iSCSI session logout, if another task accesses the shost ipaddress attr, we can get a KASAN UAF report like this: [ 276.942144] BUG: KASAN: use-after-free in _raw_spin_lock_bh+0x78/0xe0 [ 276.942535] Write of size 4 at addr ffff8881053b45b8 by task cat/4088 [ 276.943511] CPU: 2 PID: 4088 Comm: cat Tainted: G E 6.1.0-rc8+ #3 [ 276.943997] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 [ 276.944470] Call Trace: [ 276.944943] <TASK> [ 276.945397] dump_stack_lvl+0x34/0x48 [ 276.945887] print_address_description.constprop.0+0x86/0x1e7 [ 276.946421] print_report+0x36/0x4f [ 276.947358] kasan_report+0xad/0x130 [ 276.948234] kasan_check_range+0x35/0x1c0 [ 276.948674] _raw_spin_lock_bh+0x78/0xe0 [ 276.949989] iscsi_sw_tcp_host_get_param+0xad/0x2e0 [iscsi_tcp] [ 276.951765] show_host_param_ISCSI_HOST_PARAM_IPADDRESS+0xe9/0x130 [scsi_transport_iscsi] [ 276.952185] dev_attr_show+0x3f/0x80 [ 276.953005] sysfs_kf_seq_show+0x1fb/0x3e0 [ 276.953401] seq_read_iter+0x402/0x1020 [ 276.954260] vfs_read+0x532/0x7b0 [ 276.955113] ksys_read+0xed/0x1c0 [ 276.955952] do_syscall_64+0x38/0x90 [ 276.956347] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 276.956769] RIP: 0033:0x7f5d3a679222 [ 276.957161] Code: c0 e9 b2 fe ff ff 50 48 8d 3d 32 c0 0b 00 e8 a5 fe 01 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 48 89 54 24 [ 276.958009] RSP: 002b:00007ffc864d16a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [ 276.958431] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5d3a679222 [ 276.958857] RDX: 0000000000020000 RSI: 00007f5d3a4fe000 RDI: 0000000000000003 [ 276.959281] RBP: 00007f5d3a4fe000 R08: 00000000ffffffff R09: 0000000000000000 [ 276.959682] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000020000 [ 276.960126] R13: 0000000000000003 R14: 0000000000000000 R15: 0000557a26dada58 [ 276.960536] </TASK> [ 276.961357] Allocated by task 2209: [ 276.961756] kasan_save_stack+0x1e/0x40 [ 276.962170] kasan_set_track+0x21/0x30 [ 276.962557] __kasan_kmalloc+0x7e/0x90 [ 276.962923] __kmalloc+0x5b/0x140 [ 276.963308] iscsi_alloc_session+0x28/0x840 [scsi_transport_iscsi] [ 276.963712] iscsi_session_setup+0xda/0xba0 [libiscsi] [ 276.964078] iscsi_sw_tcp_session_create+0x1fd/0x330 [iscsi_tcp] [ 276.964431] iscsi_if_create_session.isra.0+0x50/0x260 [scsi_transport_iscsi] [ 276.964793] iscsi_if_recv_msg+0xc5a/0x2660 [scsi_transport_iscsi] [ 276.965153] iscsi_if_rx+0x198/0x4b0 [scsi_transport_iscsi] [ 276.965546] netlink_unicast+0x4d5/0x7b0 [ 276.965905] netlink_sendmsg+0x78d/0xc30 [ 276.966236] sock_sendmsg+0xe5/0x120 [ 276.966576] ____sys_sendmsg+0x5fe/0x860 [ 276.966923] ___sys_sendmsg+0xe0/0x170 [ 276.967300] __sys_sendmsg+0xc8/0x170 [ 276.967666] do_syscall_64+0x38/0x90 [ 276.968028] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 276.968773] Freed by task 2209: [ 276.969111] kasan_save_stack+0x1e/0x40 [ 276.969449] kasan_set_track+0x21/0x30 [ 276.969789] kasan_save_free_info+0x2a/0x50 [ 276.970146] __kasan_slab_free+0x106/0x190 [ 276.970470] __kmem_cache_free+0x133/0x270 [ 276.970816] device_release+0x98/0x210 [ 276.971145] kobject_cleanup+0x101/0x360 [ 276.971462] iscsi_session_teardown+0x3fb/0x530 [libiscsi] [ 276.971775] iscsi_sw_tcp_session_destroy+0xd8/0x130 [iscsi_tcp] [ 276.972143] iscsi_if_recv_msg+0x1bf1/0x2660 [scsi_transport_iscsi] [ 276.972485] iscsi_if_rx+0x198/0x4b0 [scsi_transport_iscsi] [ 276.972808] netlink_unicast+0x4d5/0x7b0 [ 276.973201] netlink_sendmsg+0x78d/0xc30 [ 276.973544] sock_sendmsg+0xe5/0x120 [ 276.973864] ____sys_sendmsg+0x5fe/0x860 [ 276.974248] ___sys_ ---truncated--- CVE-2023-52975 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. CVE-2023-52979 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ALSA: hda/via: Avoid potential array out-of-bound in add_secret_dac_path() snd_hda_get_connections() can return a negative error code. It may lead to accessing 'conn' array at a negative index. Found by Linux Verification Center (linuxtesting.org) with SVACE. CVE-2023-52988 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: firewire: fix memory leak for payload of request subaction to IEC 61883-1 FCP region This patch is fix for Linux kernel v2.6.33 or later. For request subaction to IEC 61883-1 FCP region, Linux FireWire subsystem have had an issue of use-after-free. The subsystem allows multiple user space listeners to the region, while data of the payload was likely released before the listeners execute read(2) to access to it for copying to user space. The issue was fixed by a commit 281e20323ab7 ("firewire: core: fix use-after-free regression in FCP handler"). The object of payload is duplicated in kernel space for each listener. When the listener executes ioctl(2) with FW_CDEV_IOC_SEND_RESPONSE request, the object is going to be released. However, it causes memory leak since the commit relies on call of release_request() in drivers/firewire/core-cdev.c. Against the expectation, the function is never called due to the design of release_client_resource(). The function delegates release task to caller when called with non-NULL fourth argument. The implementation of ioctl_send_response() is the case. It should release the object explicitly. This commit fixes the bug. CVE-2023-52989 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: x86/i8259: Mark legacy PIC interrupts with IRQ_LEVEL Baoquan reported that after triggering a crash the subsequent crash-kernel fails to boot about half of the time. It triggers a NULL pointer dereference in the periodic tick code. This happens because the legacy timer interrupt (IRQ0) is resent in software which happens in soft interrupt (tasklet) context. In this context get_irq_regs() returns NULL which leads to the NULL pointer dereference. The reason for the resend is a spurious APIC interrupt on the IRQ0 vector which is captured and leads to a resend when the legacy timer interrupt is enabled. This is wrong because the legacy PIC interrupts are level triggered and therefore should never be resent in software, but nothing ever sets the IRQ_LEVEL flag on those interrupts, so the core code does not know about their trigger type. Ensure that IRQ_LEVEL is set when the legacy PCI interrupts are set up. CVE-2023-52993 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ipv4: prevent potential spectre v1 gadget in ip_metrics_convert() if (!type) continue; if (type > RTAX_MAX) return -EINVAL; ... metrics[type - 1] = val; @type being used as an array index, we need to prevent cpu speculation or risk leaking kernel memory content. CVE-2023-52997 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: cifs: Fix oops due to uncleared server->smbd_conn in reconnect In smbd_destroy(), clear the server->smbd_conn pointer after freeing the smbd_connection struct that it points to so that reconnection doesn't get confused. CVE-2023-53006 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: tracing: Make sure trace_printk() can output as soon as it can be used Currently trace_printk() can be used as soon as early_trace_init() is called from start_kernel(). But if a crash happens, and "ftrace_dump_on_oops" is set on the kernel command line, all you get will be: [ 0.456075] <idle>-0 0dN.2. 347519us : Unknown type 6 [ 0.456075] <idle>-0 0dN.2. 353141us : Unknown type 6 [ 0.456075] <idle>-0 0dN.2. 358684us : Unknown type 6 This is because the trace_printk() event (type 6) hasn't been registered yet. That gets done via an early_initcall(), which may be early, but not early enough. Instead of registering the trace_printk() event (and other ftrace events, which are not trace events) via an early_initcall(), have them registered at the same time that trace_printk() can be used. This way, if there is a crash before early_initcall(), then the trace_printk()s will actually be useful. CVE-2023-53007 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: cifs: fix potential memory leaks in session setup Make sure to free cifs_ses::auth_key.response before allocating it as we might end up leaking memory in reconnect or mounting. CVE-2023-53008 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: bnxt: Do not read past the end of test names Test names were being concatenated based on a offset beyond the end of the first name, which tripped the buffer overflow detection logic: detected buffer overflow in strnlen [...] Call Trace: bnxt_ethtool_init.cold+0x18/0x18 Refactor struct hwrm_selftest_qlist_output to use an actual array, and adjust the concatenation to use snprintf() rather than a series of strncat() calls. CVE-2023-53010 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: HID: betop: check shape of output reports betopff_init() only checks the total sum of the report counts for each report field to be at least 4, but hid_betopff_play() expects 4 report fields. A device advertising an output report with one field and 4 report counts would pass the check but crash the kernel with a NULL pointer dereference in hid_betopff_play(). CVE-2023-53015 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: mdio: validate parameter addr in mdiobus_get_phy() The caller may pass any value as addr, what may result in an out-of-bounds access to array mdio_map. One existing case is stmmac_init_phy() that may pass -1 as addr. Therefore validate addr before using it. CVE-2023-53019 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: nfc: Fix use-after-free in local_cleanup() Fix a use-after-free that occurs in kfree_skb() called from local_cleanup(). This could happen when killing nfc daemon (e.g. neard) after detaching an nfc device. When detaching an nfc device, local_cleanup() called from nfc_llcp_unregister_device() frees local->rx_pending and decreases local->ref by kref_put() in nfc_llcp_local_put(). In the terminating process, nfc daemon releases all sockets and it leads to decreasing local->ref. After the last release of local->ref, local_cleanup() called from local_release() frees local->rx_pending again, which leads to the bug. Setting local->rx_pending to NULL in local_cleanup() could prevent use-after-free when local_cleanup() is called twice. Found by a modified version of syzkaller. BUG: KASAN: use-after-free in kfree_skb() Call Trace: dump_stack_lvl (lib/dump_stack.c:106) print_address_description.constprop.0.cold (mm/kasan/report.c:306) kasan_check_range (mm/kasan/generic.c:189) kfree_skb (net/core/skbuff.c:955) local_cleanup (net/nfc/llcp_core.c:159) nfc_llcp_local_put.part.0 (net/nfc/llcp_core.c:172) nfc_llcp_local_put (net/nfc/llcp_core.c:181) llcp_sock_destruct (net/nfc/llcp_sock.c:959) __sk_destruct (net/core/sock.c:2133) sk_destruct (net/core/sock.c:2181) __sk_free (net/core/sock.c:2192) sk_free (net/core/sock.c:2203) llcp_sock_release (net/nfc/llcp_sock.c:646) __sock_release (net/socket.c:650) sock_close (net/socket.c:1365) __fput (fs/file_table.c:306) task_work_run (kernel/task_work.c:179) ptrace_notify (kernel/signal.c:2354) syscall_exit_to_user_mode_prepare (kernel/entry/common.c:278) syscall_exit_to_user_mode (kernel/entry/common.c:296) do_syscall_64 (arch/x86/entry/common.c:86) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:106) Allocated by task 4719: kasan_save_stack (mm/kasan/common.c:45) __kasan_slab_alloc (mm/kasan/common.c:325) slab_post_alloc_hook (mm/slab.h:766) kmem_cache_alloc_node (mm/slub.c:3497) __alloc_skb (net/core/skbuff.c:552) pn533_recv_response (drivers/nfc/pn533/usb.c:65) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1671) usb_giveback_urb_bh (drivers/usb/core/hcd.c:1704) tasklet_action_common.isra.0 (kernel/softirq.c:797) __do_softirq (kernel/softirq.c:571) Freed by task 1901: kasan_save_stack (mm/kasan/common.c:45) kasan_set_track (mm/kasan/common.c:52) kasan_save_free_info (mm/kasan/genericdd.c:518) __kasan_slab_free (mm/kasan/common.c:236) kmem_cache_free (mm/slub.c:3809) kfree_skbmem (net/core/skbuff.c:874) kfree_skb (net/core/skbuff.c:931) local_cleanup (net/nfc/llcp_core.c:159) nfc_llcp_unregister_device (net/nfc/llcp_core.c:1617) nfc_unregister_device (net/nfc/core.c:1179) pn53x_unregister_nfc (drivers/nfc/pn533/pn533.c:2846) pn533_usb_disconnect (drivers/nfc/pn533/usb.c:579) usb_unbind_interface (drivers/usb/core/driver.c:458) device_release_driver_internal (drivers/base/dd.c:1279) bus_remove_device (drivers/base/bus.c:529) device_del (drivers/base/core.c:3665) usb_disable_device (drivers/usb/core/message.c:1420) usb_disconnect (drivers/usb/core.c:2261) hub_event (drivers/usb/core/hub.c:5833) process_one_work (arch/x86/include/asm/jump_label.h:27 include/linux/jump_label.h:212 include/trace/events/workqueue.h:108 kernel/workqueue.c:2281) worker_thread (include/linux/list.h:282 kernel/workqueue.c:2423) kthread (kernel/kthread.c:319) ret_from_fork (arch/x86/entry/entry_64.S:301) CVE-2023-53023 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: bpf: Fix pointer-leak due to insufficient speculative store bypass mitigation To mitigate Spectre v4, 2039f26f3aca ("bpf: Fix leakage due to insufficient speculative store bypass mitigation") inserts lfence instructions after 1) initializing a stack slot and 2) spilling a pointer to the stack. However, this does not cover cases where a stack slot is first initialized with a pointer (subject to sanitization) but then overwritten with a scalar (not subject to sanitization because the slot was already initialized). In this case, the second write may be subject to speculative store bypass (SSB) creating a speculative pointer-as-scalar type confusion. This allows the program to subsequently leak the numerical pointer value using, for example, a branch-based cache side channel. To fix this, also sanitize scalars if they write a stack slot that previously contained a pointer. Assuming that pointer-spills are only generated by LLVM on register-pressure, the performance impact on most real-world BPF programs should be small. The following unprivileged BPF bytecode drafts a minimal exploit and the mitigation: [...] // r6 = 0 or 1 (skalar, unknown user input) // r7 = accessible ptr for side channel // r10 = frame pointer (fp), to be leaked // r9 = r10 # fp alias to encourage ssb *(u64 *)(r9 - 8) = r10 // fp[-8] = ptr, to be leaked // lfence added here because of pointer spill to stack. // // Ommitted: Dummy bpf_ringbuf_output() here to train alias predictor // for no r9-r10 dependency. // *(u64 *)(r10 - 8) = r6 // fp[-8] = scalar, overwrites ptr // 2039f26f3aca: no lfence added because stack slot was not STACK_INVALID, // store may be subject to SSB // // fix: also add an lfence when the slot contained a ptr // r8 = *(u64 *)(r9 - 8) // r8 = architecturally a scalar, speculatively a ptr // // leak ptr using branch-based cache side channel: r8 &= 1 // choose bit to leak if r8 == 0 goto SLOW // no mispredict // architecturally dead code if input r6 is 0, // only executes speculatively iff ptr bit is 1 r8 = *(u64 *)(r7 + 0) # encode bit in cache (0: slow, 1: fast) SLOW: [...] After running this, the program can time the access to *(r7 + 0) to determine whether the chosen pointer bit was 0 or 1. Repeat this 64 times to recover the whole address on amd64. In summary, sanitization can only be skipped if one scalar is overwritten with another scalar. Scalar-confusion due to speculative store bypass can not lead to invalid accesses because the pointer bounds deducted during verification are enforced using branchless logic. See 979d63d50c0c ("bpf: prevent out of bounds speculation on pointer arithmetic") for details. Do not make the mitigation depend on !env->allow_{uninit_stack,ptr_leaks} because speculative leaks are likely unexpected if these were enabled. For example, leaking the address to a protected log file may be acceptable while disabling the mitigation might unintentionally leak the address into the cached-state of a map that is accessible to unprivileged processes. CVE-2023-53024 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: powerpc/imc-pmu: Fix use of mutex in IRQs disabled section Current imc-pmu code triggers a WARNING with CONFIG_DEBUG_ATOMIC_SLEEP and CONFIG_PROVE_LOCKING enabled, while running a thread_imc event. Command to trigger the warning: # perf stat -e thread_imc/CPM_CS_FROM_L4_MEM_X_DPTEG/ sleep 5 Performance counter stats for 'sleep 5': 0 thread_imc/CPM_CS_FROM_L4_MEM_X_DPTEG/ 5.002117947 seconds time elapsed 0.000131000 seconds user 0.001063000 seconds sys Below is snippet of the warning in dmesg: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 2869, name: perf-exec preempt_count: 2, expected: 0 4 locks held by perf-exec/2869: #0: c00000004325c540 (&sig->cred_guard_mutex){+.+.}-{3:3}, at: bprm_execve+0x64/0xa90 #1: c00000004325c5d8 (&sig->exec_update_lock){++++}-{3:3}, at: begin_new_exec+0x460/0xef0 #2: c0000003fa99d4e0 (&cpuctx_lock){-...}-{2:2}, at: perf_event_exec+0x290/0x510 #3: c000000017ab8418 (&ctx->lock){....}-{2:2}, at: perf_event_exec+0x29c/0x510 irq event stamp: 4806 hardirqs last enabled at (4805): [<c000000000f65b94>] _raw_spin_unlock_irqrestore+0x94/0xd0 hardirqs last disabled at (4806): [<c0000000003fae44>] perf_event_exec+0x394/0x510 softirqs last enabled at (0): [<c00000000013c404>] copy_process+0xc34/0x1ff0 softirqs last disabled at (0): [<0000000000000000>] 0x0 CPU: 36 PID: 2869 Comm: perf-exec Not tainted 6.2.0-rc2-00011-g1247637727f2 #61 Hardware name: 8375-42A POWER9 0x4e1202 opal:v7.0-16-g9b85f7d961 PowerNV Call Trace: dump_stack_lvl+0x98/0xe0 (unreliable) __might_resched+0x2f8/0x310 __mutex_lock+0x6c/0x13f0 thread_imc_event_add+0xf4/0x1b0 event_sched_in+0xe0/0x210 merge_sched_in+0x1f0/0x600 visit_groups_merge.isra.92.constprop.166+0x2bc/0x6c0 ctx_flexible_sched_in+0xcc/0x140 ctx_sched_in+0x20c/0x2a0 ctx_resched+0x104/0x1c0 perf_event_exec+0x340/0x510 begin_new_exec+0x730/0xef0 load_elf_binary+0x3f8/0x1e10 ... do not call blocking ops when !TASK_RUNNING; state=2001 set at [<00000000fd63e7cf>] do_nanosleep+0x60/0x1a0 WARNING: CPU: 36 PID: 2869 at kernel/sched/core.c:9912 __might_sleep+0x9c/0xb0 CPU: 36 PID: 2869 Comm: sleep Tainted: G W 6.2.0-rc2-00011-g1247637727f2 #61 Hardware name: 8375-42A POWER9 0x4e1202 opal:v7.0-16-g9b85f7d961 PowerNV NIP: c000000000194a1c LR: c000000000194a18 CTR: c000000000a78670 REGS: c00000004d2134e0 TRAP: 0700 Tainted: G W (6.2.0-rc2-00011-g1247637727f2) MSR: 9000000000021033 <SF,HV,ME,IR,DR,RI,LE> CR: 48002824 XER: 00000000 CFAR: c00000000013fb64 IRQMASK: 1 The above warning triggered because the current imc-pmu code uses mutex lock in interrupt disabled sections. The function mutex_lock() internally calls __might_resched(), which will check if IRQs are disabled and in case IRQs are disabled, it will trigger the warning. Fix the issue by changing the mutex lock to spinlock. [mpe: Fix comments, trim oops in change log, add reported-by tags] CVE-2023-53031 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: Fix overflow before widen in the bitmap_ip_create() function. When first_ip is 0, last_ip is 0xFFFFFFFF, and netmask is 31, the value of an arithmetic expression 2 << (netmask - mask_bits - 1) is subject to overflow due to a failure casting operands to a larger data type before performing the arithmetic. Note that it's harmless since the value will be checked at the next step. Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with SVACE. CVE-2023-53032 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: HID: intel-ish-hid: ipc: Fix potential use-after-free in work function When a reset notify IPC message is received, the ISR schedules a work function and passes the ISHTP device to it via a global pointer ishtp_dev. If ish_probe() fails, the devm-managed device resources including ishtp_dev are freed, but the work is not cancelled, causing a use-after-free when the work function tries to access ishtp_dev. Use devm_work_autocancel() instead, so that the work is automatically cancelled if probe fails. CVE-2023-53039 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Perform lockless command completion in abort path While adding and removing the controller, the following call trace was observed: WARNING: CPU: 3 PID: 623596 at kernel/dma/mapping.c:532 dma_free_attrs+0x33/0x50 CPU: 3 PID: 623596 Comm: sh Kdump: loaded Not tainted 5.14.0-96.el9.x86_64 #1 RIP: 0010:dma_free_attrs+0x33/0x50 Call Trace: qla2x00_async_sns_sp_done+0x107/0x1b0 [qla2xxx] qla2x00_abort_srb+0x8e/0x250 [qla2xxx] ? ql_dbg+0x70/0x100 [qla2xxx] __qla2x00_abort_all_cmds+0x108/0x190 [qla2xxx] qla2x00_abort_all_cmds+0x24/0x70 [qla2xxx] qla2x00_abort_isp_cleanup+0x305/0x3e0 [qla2xxx] qla2x00_remove_one+0x364/0x400 [qla2xxx] pci_device_remove+0x36/0xa0 __device_release_driver+0x17a/0x230 device_release_driver+0x24/0x30 pci_stop_bus_device+0x68/0x90 pci_stop_and_remove_bus_device_locked+0x16/0x30 remove_store+0x75/0x90 kernfs_fop_write_iter+0x11c/0x1b0 new_sync_write+0x11f/0x1b0 vfs_write+0x1eb/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x5c/0x80 ? do_user_addr_fault+0x1d8/0x680 ? do_syscall_64+0x69/0x80 ? exc_page_fault+0x62/0x140 ? asm_exc_page_fault+0x8/0x30 entry_SYSCALL_64_after_hwframe+0x44/0xae The command was completed in the abort path during driver unload with a lock held, causing the warning in abort path. Hence complete the command without any lock held. CVE-2023-53041 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: dm stats: check for and propagate alloc_percpu failure Check alloc_precpu()'s return value and return an error from dm_stats_init() if it fails. Update alloc_dev() to fail if dm_stats_init() does. Otherwise, a NULL pointer dereference will occur in dm_stats_cleanup() even if dm-stats isn't being actively used. CVE-2023-53044 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: usb: gadget: u_audio: don't let userspace block driver unbind In the unbind callback for f_uac1 and f_uac2, a call to snd_card_free() via g_audio_cleanup() will disconnect the card and then wait for all resources to be released, which happens when the refcount falls to zero. Since userspace can keep the refcount incremented by not closing the relevant file descriptor, the call to unbind may block indefinitely. This can cause a deadlock during reboot, as evidenced by the following blocked task observed on my machine: task:reboot state:D stack:0 pid:2827 ppid:569 flags:0x0000000c Call trace: __switch_to+0xc8/0x140 __schedule+0x2f0/0x7c0 schedule+0x60/0xd0 schedule_timeout+0x180/0x1d4 wait_for_completion+0x78/0x180 snd_card_free+0x90/0xa0 g_audio_cleanup+0x2c/0x64 afunc_unbind+0x28/0x60 ... kernel_restart+0x4c/0xac __do_sys_reboot+0xcc/0x1ec __arm64_sys_reboot+0x28/0x30 invoke_syscall+0x4c/0x110 ... The issue can also be observed by opening the card with arecord and then stopping the process through the shell before unbinding: # arecord -D hw:UAC2Gadget -f S32_LE -c 2 -r 48000 /dev/null Recording WAVE '/dev/null' : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo ^Z[1]+ Stopped arecord -D hw:UAC2Gadget -f S32_LE -c 2 -r 48000 /dev/null # echo gadget.0 > /sys/bus/gadget/drivers/configfs-gadget/unbind (observe that the unbind command never finishes) Fix the problem by using snd_card_free_when_closed() instead, which will still disconnect the card as desired, but defer the task of freeing the resources to the core once userspace closes its file descriptor. CVE-2023-53045 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: dm crypt: add cond_resched() to dmcrypt_write() The loop in dmcrypt_write may be running for unbounded amount of time, thus we need cond_resched() in it. This commit fixes the following warning: [ 3391.153255][ C12] watchdog: BUG: soft lockup - CPU#12 stuck for 23s! [dmcrypt_write/2:2897] ... [ 3391.387210][ C12] Call trace: [ 3391.390338][ C12] blk_attempt_bio_merge.part.6+0x38/0x158 [ 3391.395970][ C12] blk_attempt_plug_merge+0xc0/0x1b0 [ 3391.401085][ C12] blk_mq_submit_bio+0x398/0x550 [ 3391.405856][ C12] submit_bio_noacct+0x308/0x380 [ 3391.410630][ C12] dmcrypt_write+0x1e4/0x208 [dm_crypt] [ 3391.416005][ C12] kthread+0x130/0x138 [ 3391.419911][ C12] ret_from_fork+0x10/0x18 CVE-2023-53051 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Synchronize the IOCB count to be in order A system hang was observed with the following call trace: BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 15 PID: 86747 Comm: nvme Kdump: loaded Not tainted 6.2.0+ #1 Hardware name: Dell Inc. PowerEdge R6515/04F3CJ, BIOS 2.7.3 03/31/2022 RIP: 0010:__wake_up_common+0x55/0x190 Code: 41 f6 01 04 0f 85 b2 00 00 00 48 8b 43 08 4c 8d 40 e8 48 8d 43 08 48 89 04 24 48 89 c6\ 49 8d 40 18 48 39 c6 0f 84 e9 00 00 00 <49> 8b 40 18 89 6c 24 14 31 ed 4c 8d 60 e8 41 8b 18 f6 c3 04 75 5d RSP: 0018:ffffb05a82afbba0 EFLAGS: 00010082 RAX: 0000000000000000 RBX: ffff8f9b83a00018 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffff8f9b83a00020 RDI: ffff8f9b83a00018 RBP: 0000000000000001 R08: ffffffffffffffe8 R09: ffffb05a82afbbf8 R10: 70735f7472617473 R11: 5f30307832616c71 R12: 0000000000000001 R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f815cf4c740(0000) GS:ffff8f9eeed80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010633a000 CR4: 0000000000350ee0 Call Trace: <TASK> __wake_up_common_lock+0x83/0xd0 qla_nvme_ls_req+0x21b/0x2b0 [qla2xxx] __nvme_fc_send_ls_req+0x1b5/0x350 [nvme_fc] nvme_fc_xmt_disconnect_assoc+0xca/0x110 [nvme_fc] nvme_fc_delete_association+0x1bf/0x220 [nvme_fc] ? nvme_remove_namespaces+0x9f/0x140 [nvme_core] nvme_do_delete_ctrl+0x5b/0xa0 [nvme_core] nvme_sysfs_delete+0x5f/0x70 [nvme_core] kernfs_fop_write_iter+0x12b/0x1c0 vfs_write+0x2a3/0x3b0 ksys_write+0x5f/0xe0 do_syscall_64+0x5c/0x90 ? syscall_exit_work+0x103/0x130 ? syscall_exit_to_user_mode+0x12/0x30 ? do_syscall_64+0x69/0x90 ? exit_to_user_mode_loop+0xd0/0x130 ? exit_to_user_mode_prepare+0xec/0x100 ? syscall_exit_to_user_mode+0x12/0x30 ? do_syscall_64+0x69/0x90 ? syscall_exit_to_user_mode+0x12/0x30 ? do_syscall_64+0x69/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7f815cd3eb97 The IOCB counts are out of order and that would block any commands from going out and subsequently hang the system. Synchronize the IOCB count to be in correct order. CVE-2023-53056 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: igb: revert rtnl_lock() that causes deadlock The commit 6faee3d4ee8b ("igb: Add lock to avoid data race") adds rtnl_lock to eliminate a false data race shown below (FREE from device detaching) | (USE from netdev core) igb_remove | igb_ndo_get_vf_config igb_disable_sriov | vf >= adapter->vfs_allocated_count? kfree(adapter->vf_data) | adapter->vfs_allocated_count = 0 | | memcpy(... adapter->vf_data[vf] The above race will never happen and the extra rtnl_lock causes deadlock below [ 141.420169] <TASK> [ 141.420672] __schedule+0x2dd/0x840 [ 141.421427] schedule+0x50/0xc0 [ 141.422041] schedule_preempt_disabled+0x11/0x20 [ 141.422678] __mutex_lock.isra.13+0x431/0x6b0 [ 141.423324] unregister_netdev+0xe/0x20 [ 141.423578] igbvf_remove+0x45/0xe0 [igbvf] [ 141.423791] pci_device_remove+0x36/0xb0 [ 141.423990] device_release_driver_internal+0xc1/0x160 [ 141.424270] pci_stop_bus_device+0x6d/0x90 [ 141.424507] pci_stop_and_remove_bus_device+0xe/0x20 [ 141.424789] pci_iov_remove_virtfn+0xba/0x120 [ 141.425452] sriov_disable+0x2f/0xf0 [ 141.425679] igb_disable_sriov+0x4e/0x100 [igb] [ 141.426353] igb_remove+0xa0/0x130 [igb] [ 141.426599] pci_device_remove+0x36/0xb0 [ 141.426796] device_release_driver_internal+0xc1/0x160 [ 141.427060] driver_detach+0x44/0x90 [ 141.427253] bus_remove_driver+0x55/0xe0 [ 141.427477] pci_unregister_driver+0x2a/0xa0 [ 141.428296] __x64_sys_delete_module+0x141/0x2b0 [ 141.429126] ? mntput_no_expire+0x4a/0x240 [ 141.429363] ? syscall_trace_enter.isra.19+0x126/0x1a0 [ 141.429653] do_syscall_64+0x5b/0x80 [ 141.429847] ? exit_to_user_mode_prepare+0x14d/0x1c0 [ 141.430109] ? syscall_exit_to_user_mode+0x12/0x30 [ 141.430849] ? do_syscall_64+0x67/0x80 [ 141.431083] ? syscall_exit_to_user_mode_prepare+0x183/0x1b0 [ 141.431770] ? syscall_exit_to_user_mode+0x12/0x30 [ 141.432482] ? do_syscall_64+0x67/0x80 [ 141.432714] ? exc_page_fault+0x64/0x140 [ 141.432911] entry_SYSCALL_64_after_hwframe+0x72/0xdc Since the igb_disable_sriov() will call pci_disable_sriov() before releasing any resources, the netdev core will synchronize the cleanup to avoid any races. This patch removes the useless rtnl_(un)lock to guarantee correctness. CVE-2023-53060 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: usb: smsc95xx: Limit packet length to skb->len Packet length retrieved from descriptor may be larger than the actual socket buffer length. In such case the cloned skb passed up the network stack will leak kernel memory contents. CVE-2023-53062 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: qed/qed_sriov: guard against NULL derefs from qed_iov_get_vf_info We have to make sure that the info returned by the helper is valid before using it. Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. CVE-2023-53066 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: usb: lan78xx: Limit packet length to skb->len Packet length retrieved from descriptor may be larger than the actual socket buffer length. In such case the cloned skb passed up the network stack will leak kernel memory contents. Additionally prevent integer underflow when size is less than ETH_FCS_LEN. CVE-2023-53068 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix invalid address access in lookup_rec() when index is 0 KASAN reported follow problem: BUG: KASAN: use-after-free in lookup_rec Read of size 8 at addr ffff000199270ff0 by task modprobe CPU: 2 Comm: modprobe Call trace: kasan_report __asan_load8 lookup_rec ftrace_location arch_check_ftrace_location check_kprobe_address_safe register_kprobe When checking pg->records[pg->index - 1].ip in lookup_rec(), it can get a pg which is newly added to ftrace_pages_start in ftrace_process_locs(). Before the first pg->index++, index is 0 and accessing pg->records[-1].ip will cause this problem. Don't check the ip when pg->index is 0. CVE-2023-53075 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: scsi_dh_alua: Fix memleak for 'qdata' in alua_activate() If alua_rtpg_queue() failed from alua_activate(), then 'qdata' is not freed, which will cause following memleak: unreferenced object 0xffff88810b2c6980 (size 32): comm "kworker/u16:2", pid 635322, jiffies 4355801099 (age 1216426.076s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 40 39 24 c1 ff ff ff ff 00 f8 ea 0a 81 88 ff ff @9$............. backtrace: [<0000000098f3a26d>] alua_activate+0xb0/0x320 [<000000003b529641>] scsi_dh_activate+0xb2/0x140 [<000000007b296db3>] activate_path_work+0xc6/0xe0 [dm_multipath] [<000000007adc9ace>] process_one_work+0x3c5/0x730 [<00000000c457a985>] worker_thread+0x93/0x650 [<00000000cb80e628>] kthread+0x1ba/0x210 [<00000000a1e61077>] ret_from_fork+0x22/0x30 Fix the problem by freeing 'qdata' in error path. CVE-2023-53078 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix steering rules cleanup vport's mc, uc and multicast rules are not deleted in teardown path when EEH happens. Since the vport's promisc settings(uc, mc and all) in firmware are reset after EEH, mlx5 driver will try to delete the above rules in the initialization path. This cause kernel crash because these software rules are no longer valid. Fix by nullifying these rules right after delete to avoid accessing any dangling pointers. Call Trace: __list_del_entry_valid+0xcc/0x100 (unreliable) tree_put_node+0xf4/0x1b0 [mlx5_core] tree_remove_node+0x30/0x70 [mlx5_core] mlx5_del_flow_rules+0x14c/0x1f0 [mlx5_core] esw_apply_vport_rx_mode+0x10c/0x200 [mlx5_core] esw_update_vport_rx_mode+0xb4/0x180 [mlx5_core] esw_vport_change_handle_locked+0x1ec/0x230 [mlx5_core] esw_enable_vport+0x130/0x260 [mlx5_core] mlx5_eswitch_enable_sriov+0x2a0/0x2f0 [mlx5_core] mlx5_device_enable_sriov+0x74/0x440 [mlx5_core] mlx5_load_one+0x114c/0x1550 [mlx5_core] mlx5_pci_resume+0x68/0xf0 [mlx5_core] eeh_report_resume+0x1a4/0x230 eeh_pe_dev_traverse+0x98/0x170 eeh_handle_normal_event+0x3e4/0x640 eeh_handle_event+0x4c/0x370 eeh_event_handler+0x14c/0x210 kthread+0x168/0x1b0 ret_from_kernel_thread+0x5c/0x84 CVE-2023-53079 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: xsk: Add missing overflow check in xdp_umem_reg The number of chunks can overflow u32. Make sure to return -EINVAL on overflow. Also remove a redundant u32 cast assigning umem->npgs. CVE-2023-53080 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: tty: serial: fsl_lpuart: fix race on RX DMA shutdown From time to time DMA completion can come in the middle of DMA shutdown: <process ctx>: <IRQ>: lpuart32_shutdown() lpuart_dma_shutdown() del_timer_sync() lpuart_dma_rx_complete() lpuart_copy_rx_to_tty() mod_timer() lpuart_dma_rx_free() When the timer fires a bit later, sport->dma_rx_desc is NULL: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 pc : lpuart_copy_rx_to_tty+0xcc/0x5bc lr : lpuart_timer_func+0x1c/0x2c Call trace: lpuart_copy_rx_to_tty lpuart_timer_func call_timer_fn __run_timers.part.0 run_timer_softirq __do_softirq __irq_exit_rcu irq_exit handle_domain_irq gic_handle_irq call_on_irq_stack do_interrupt_handler ... To fix this fold del_timer_sync() into lpuart_dma_rx_free() after dmaengine_terminate_sync() to make sure timer will not be re-started in lpuart_copy_rx_to_tty() <= lpuart_dma_rx_complete(). CVE-2023-53094 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ext4: fix WARNING in ext4_update_inline_data Syzbot found the following issue: EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 without journal. Quota mode: none. fscrypt: AES-256-CTS-CBC using implementation "cts-cbc-aes-aesni" fscrypt: AES-256-XTS using implementation "xts-aes-aesni" ------------[ cut here ]------------ WARNING: CPU: 0 PID: 5071 at mm/page_alloc.c:5525 __alloc_pages+0x30a/0x560 mm/page_alloc.c:5525 Modules linked in: CPU: 1 PID: 5071 Comm: syz-executor263 Not tainted 6.2.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 RIP: 0010:__alloc_pages+0x30a/0x560 mm/page_alloc.c:5525 RSP: 0018:ffffc90003c2f1c0 EFLAGS: 00010246 RAX: ffffc90003c2f220 RBX: 0000000000000014 RCX: 0000000000000000 RDX: 0000000000000028 RSI: 0000000000000000 RDI: ffffc90003c2f248 RBP: ffffc90003c2f2d8 R08: dffffc0000000000 R09: ffffc90003c2f220 R10: fffff52000785e49 R11: 1ffff92000785e44 R12: 0000000000040d40 R13: 1ffff92000785e40 R14: dffffc0000000000 R15: 1ffff92000785e3c FS: 0000555556c0d300(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f95d5e04138 CR3: 00000000793aa000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __alloc_pages_node include/linux/gfp.h:237 [inline] alloc_pages_node include/linux/gfp.h:260 [inline] __kmalloc_large_node+0x95/0x1e0 mm/slab_common.c:1113 __do_kmalloc_node mm/slab_common.c:956 [inline] __kmalloc+0xfe/0x190 mm/slab_common.c:981 kmalloc include/linux/slab.h:584 [inline] kzalloc include/linux/slab.h:720 [inline] ext4_update_inline_data+0x236/0x6b0 fs/ext4/inline.c:346 ext4_update_inline_dir fs/ext4/inline.c:1115 [inline] ext4_try_add_inline_entry+0x328/0x990 fs/ext4/inline.c:1307 ext4_add_entry+0x5a4/0xeb0 fs/ext4/namei.c:2385 ext4_add_nondir+0x96/0x260 fs/ext4/namei.c:2772 ext4_create+0x36c/0x560 fs/ext4/namei.c:2817 lookup_open fs/namei.c:3413 [inline] open_last_lookups fs/namei.c:3481 [inline] path_openat+0x12ac/0x2dd0 fs/namei.c:3711 do_filp_open+0x264/0x4f0 fs/namei.c:3741 do_sys_openat2+0x124/0x4e0 fs/open.c:1310 do_sys_open fs/open.c:1326 [inline] __do_sys_openat fs/open.c:1342 [inline] __se_sys_openat fs/open.c:1337 [inline] __x64_sys_openat+0x243/0x290 fs/open.c:1337 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 Above issue happens as follows: ext4_iget ext4_find_inline_data_nolock ->i_inline_off=164 i_inline_size=60 ext4_try_add_inline_entry __ext4_mark_inode_dirty ext4_expand_extra_isize_ea ->i_extra_isize=32 s_want_extra_isize=44 ext4_xattr_shift_entries ->after shift i_inline_off is incorrect, actually is change to 176 ext4_try_add_inline_entry ext4_update_inline_dir get_max_inline_xattr_value_size if (EXT4_I(inode)->i_inline_off) entry = (struct ext4_xattr_entry *)((void *)raw_inode + EXT4_I(inode)->i_inline_off); free += EXT4_XATTR_SIZE(le32_to_cpu(entry->e_value_size)); ->As entry is incorrect, then 'free' may be negative ext4_update_inline_data value = kzalloc(len, GFP_NOFS); -> len is unsigned int, maybe very large, then trigger warning when 'kzalloc()' To resolve the above issue we need to update 'i_inline_off' after 'ext4_xattr_shift_entries()'. We do not need to set EXT4_STATE_MAY_INLINE_DATA flag here, since ext4_mark_inode_dirty() already sets this flag if needed. Setting EXT4_STATE_MAY_INLINE_DATA when it is needed may trigger a BUG_ON in ext4_writepages(). CVE-2023-53100 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ext4: zero i_disksize when initializing the bootloader inode If the boot loader inode has never been used before, the EXT4_IOC_SWAP_BOOT inode will initialize it, including setting the i_size to 0. However, if the "never before used" boot loader has a non-zero i_size, then i_disksize will be non-zero, and the inconsistency between i_size and i_disksize can trigger a kernel warning: WARNING: CPU: 0 PID: 2580 at fs/ext4/file.c:319 CPU: 0 PID: 2580 Comm: bb Not tainted 6.3.0-rc1-00004-g703695902cfa RIP: 0010:ext4_file_write_iter+0xbc7/0xd10 Call Trace: vfs_write+0x3b1/0x5c0 ksys_write+0x77/0x160 __x64_sys_write+0x22/0x30 do_syscall_64+0x39/0x80 Reproducer: 1. create corrupted image and mount it: mke2fs -t ext4 /tmp/foo.img 200 debugfs -wR "sif <5> size 25700" /tmp/foo.img mount -t ext4 /tmp/foo.img /mnt cd /mnt echo 123 > file 2. Run the reproducer program: posix_memalign(&buf, 1024, 1024) fd = open("file", O_RDWR | O_DIRECT); ioctl(fd, EXT4_IOC_SWAP_BOOT); write(fd, buf, 1024); Fix this by setting i_disksize as well as i_size to zero when initiaizing the boot loader inode. CVE-2023-53101 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: bonding: restore bond's IFF_SLAVE flag if a non-eth dev enslave fails syzbot reported a warning[1] where the bond device itself is a slave and we try to enslave a non-ethernet device as the first slave which fails but then in the error path when ether_setup() restores the bond device it also clears all flags. In my previous fix[2] I restored the IFF_MASTER flag, but I didn't consider the case that the bond device itself might also be a slave with IFF_SLAVE set, so we need to restore that flag as well. Use the bond_ether_setup helper which does the right thing and restores the bond's flags properly. Steps to reproduce using a nlmon dev: $ ip l add nlmon0 type nlmon $ ip l add bond1 type bond $ ip l add bond2 type bond $ ip l set bond1 master bond2 $ ip l set dev nlmon0 master bond1 $ ip -d l sh dev bond1 22: bond1: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noqueue master bond2 state DOWN mode DEFAULT group default qlen 1000 (now bond1's IFF_SLAVE flag is gone and we'll hit a warning[3] if we try to delete it) [1] https://syzkaller.appspot.com/bug?id=391c7b1f6522182899efba27d891f1743e8eb3ef [2] commit 7d5cd2ce5292 ("bonding: correctly handle bonding type change on enslave failure") [3] example warning: [ 27.008664] bond1: (slave nlmon0): The slave device specified does not support setting the MAC address [ 27.008692] bond1: (slave nlmon0): Error -95 calling set_mac_address [ 32.464639] bond1 (unregistering): Released all slaves [ 32.464685] ------------[ cut here ]------------ [ 32.464686] WARNING: CPU: 1 PID: 2004 at net/core/dev.c:10829 unregister_netdevice_many+0x72a/0x780 [ 32.464694] Modules linked in: br_netfilter bridge bonding virtio_net [ 32.464699] CPU: 1 PID: 2004 Comm: ip Kdump: loaded Not tainted 5.18.0-rc3+ #47 [ 32.464703] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.1-2.fc37 04/01/2014 [ 32.464704] RIP: 0010:unregister_netdevice_many+0x72a/0x780 [ 32.464707] Code: 99 fd ff ff ba 90 1a 00 00 48 c7 c6 f4 02 66 96 48 c7 c7 20 4d 35 96 c6 05 fa c7 2b 02 01 e8 be 6f 4a 00 0f 0b e9 73 fd ff ff <0f> 0b e9 5f fd ff ff 80 3d e3 c7 2b 02 00 0f 85 3b fd ff ff ba 59 [ 32.464710] RSP: 0018:ffffa006422d7820 EFLAGS: 00010206 [ 32.464712] RAX: ffff8f6e077140a0 RBX: ffffa006422d7888 RCX: 0000000000000000 [ 32.464714] RDX: ffff8f6e12edbe58 RSI: 0000000000000296 RDI: ffffffff96d4a520 [ 32.464716] RBP: ffff8f6e07714000 R08: ffffffff96d63600 R09: ffffa006422d7728 [ 32.464717] R10: 0000000000000ec0 R11: ffffffff9698c988 R12: ffff8f6e12edb140 [ 32.464719] R13: dead000000000122 R14: dead000000000100 R15: ffff8f6e12edb140 [ 32.464723] FS: 00007f297c2f1740(0000) GS:ffff8f6e5d900000(0000) knlGS:0000000000000000 [ 32.464725] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 32.464726] CR2: 00007f297bf1c800 CR3: 00000000115e8000 CR4: 0000000000350ee0 [ 32.464730] Call Trace: [ 32.464763] <TASK> [ 32.464767] rtnl_dellink+0x13e/0x380 [ 32.464776] ? cred_has_capability.isra.0+0x68/0x100 [ 32.464780] ? __rtnl_unlock+0x33/0x60 [ 32.464783] ? bpf_lsm_capset+0x10/0x10 [ 32.464786] ? security_capable+0x36/0x50 [ 32.464790] rtnetlink_rcv_msg+0x14e/0x3b0 [ 32.464792] ? _copy_to_iter+0xb1/0x790 [ 32.464796] ? post_alloc_hook+0xa0/0x160 [ 32.464799] ? rtnl_calcit.isra.0+0x110/0x110 [ 32.464802] netlink_rcv_skb+0x50/0xf0 [ 32.464806] netlink_unicast+0x216/0x340 [ 32.464809] netlink_sendmsg+0x23f/0x480 [ 32.464812] sock_sendmsg+0x5e/0x60 [ 32.464815] ____sys_sendmsg+0x22c/0x270 [ 32.464818] ? import_iovec+0x17/0x20 [ 32.464821] ? sendmsg_copy_msghdr+0x59/0x90 [ 32.464823] ? do_set_pte+0xa0/0xe0 [ 32.464828] ___sys_sendmsg+0x81/0xc0 [ 32.464832] ? mod_objcg_state+0xc6/0x300 [ 32.464835] ? refill_obj_stock+0xa9/0x160 [ 32.464838] ? memcg_slab_free_hook+0x1a5/0x1f0 [ 32.464842] __sys_sendm ---truncated--- CVE-2023-53103 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net/iucv: Fix size of interrupt data iucv_irq_data needs to be 4 bytes larger. These bytes are not used by the iucv module, but written by the z/VM hypervisor in case a CPU is deconfigured. Reported as: BUG dma-kmalloc-64 (Not tainted): kmalloc Redzone overwritten ----------------------------------------------------------------------------- 0x0000000000400564-0x0000000000400567 @offset=1380. First byte 0x80 instead of 0xcc Allocated in iucv_cpu_prepare+0x44/0xd0 age=167839 cpu=2 pid=1 __kmem_cache_alloc_node+0x166/0x450 kmalloc_node_trace+0x3a/0x70 iucv_cpu_prepare+0x44/0xd0 cpuhp_invoke_callback+0x156/0x2f0 cpuhp_issue_call+0xf0/0x298 __cpuhp_setup_state_cpuslocked+0x136/0x338 __cpuhp_setup_state+0xf4/0x288 iucv_init+0xf4/0x280 do_one_initcall+0x78/0x390 do_initcalls+0x11a/0x140 kernel_init_freeable+0x25e/0x2a0 kernel_init+0x2e/0x170 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 Freed in iucv_init+0x92/0x280 age=167839 cpu=2 pid=1 __kmem_cache_free+0x308/0x358 iucv_init+0x92/0x280 do_one_initcall+0x78/0x390 do_initcalls+0x11a/0x140 kernel_init_freeable+0x25e/0x2a0 kernel_init+0x2e/0x170 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 Slab 0x0000037200010000 objects=32 used=30 fp=0x0000000000400640 flags=0x1ffff00000010200(slab|head|node=0|zone=0| Object 0x0000000000400540 @offset=1344 fp=0x0000000000000000 Redzone 0000000000400500: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ Redzone 0000000000400510: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ Redzone 0000000000400520: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ Redzone 0000000000400530: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ Object 0000000000400540: 00 01 00 03 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object 0000000000400550: f3 86 81 f2 f4 82 f8 82 f0 f0 f0 f0 f0 f0 f0 f2 ................ Object 0000000000400560: 00 00 00 00 80 00 00 00 cc cc cc cc cc cc cc cc ................ Object 0000000000400570: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ Redzone 0000000000400580: cc cc cc cc cc cc cc cc ........ Padding 00000000004005d4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ Padding 00000000004005e4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ Padding 00000000004005f4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZ CPU: 6 PID: 121030 Comm: 116-pai-crypto. Not tainted 6.3.0-20230221.rc0.git4.99b8246b2d71.300.fc37.s390x+debug #1 Hardware name: IBM 3931 A01 704 (z/VM 7.3.0) Call Trace: [<000000032aa034ec>] dump_stack_lvl+0xac/0x100 [<0000000329f5a6cc>] check_bytes_and_report+0x104/0x140 [<0000000329f5aa78>] check_object+0x370/0x3c0 [<0000000329f5ede6>] free_debug_processing+0x15e/0x348 [<0000000329f5f06a>] free_to_partial_list+0x9a/0x2f0 [<0000000329f5f4a4>] __slab_free+0x1e4/0x3a8 [<0000000329f61768>] __kmem_cache_free+0x308/0x358 [<000000032a91465c>] iucv_cpu_dead+0x6c/0x88 [<0000000329c2fc66>] cpuhp_invoke_callback+0x156/0x2f0 [<000000032aa062da>] _cpu_down.constprop.0+0x22a/0x5e0 [<0000000329c3243e>] cpu_device_down+0x4e/0x78 [<000000032a61dee0>] device_offline+0xc8/0x118 [<000000032a61e048>] online_store+0x60/0xe0 [<000000032a08b6b0>] kernfs_fop_write_iter+0x150/0x1e8 [<0000000329fab65c>] vfs_write+0x174/0x360 [<0000000329fab9fc>] ksys_write+0x74/0x100 [<000000032aa03a5a>] __do_syscall+0x1da/0x208 [<000000032aa177b2>] system_call+0x82/0xb0 INFO: lockdep is turned off. FIX dma-kmalloc-64: Restoring kmalloc Redzone 0x0000000000400564-0x0000000000400567=0xcc FIX dma-kmalloc-64: Object at 0x0000000000400540 not freed CVE-2023-53108 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: i40e: Fix kernel crash during reboot when adapter is in recovery mode If the driver detects during probe that firmware is in recovery mode then i40e_init_recovery_mode() is called and the rest of probe function is skipped including pci_set_drvdata(). Subsequent i40e_shutdown() called during shutdown/reboot dereferences NULL pointer as pci_get_drvdata() returns NULL. To fix call pci_set_drvdata() also during entering to recovery mode. Reproducer: 1) Lets have i40e NIC with firmware in recovery mode 2) Run reboot Result: [ 139.084698] i40e: Intel(R) Ethernet Connection XL710 Network Driver [ 139.090959] i40e: Copyright (c) 2013 - 2019 Intel Corporation. [ 139.108438] i40e 0000:02:00.0: Firmware recovery mode detected. Limiting functionality. [ 139.116439] i40e 0000:02:00.0: Refer to the Intel(R) Ethernet Adapters and Devices User Guide for details on firmware recovery mode. [ 139.129499] i40e 0000:02:00.0: fw 8.3.64775 api 1.13 nvm 8.30 0x8000b78d 1.3106.0 [8086:1583] [15d9:084a] [ 139.215932] i40e 0000:02:00.0 enp2s0f0: renamed from eth0 [ 139.223292] i40e 0000:02:00.1: Firmware recovery mode detected. Limiting functionality. [ 139.231292] i40e 0000:02:00.1: Refer to the Intel(R) Ethernet Adapters and Devices User Guide for details on firmware recovery mode. [ 139.244406] i40e 0000:02:00.1: fw 8.3.64775 api 1.13 nvm 8.30 0x8000b78d 1.3106.0 [8086:1583] [15d9:084a] [ 139.329209] i40e 0000:02:00.1 enp2s0f1: renamed from eth0 ... [ 156.311376] BUG: kernel NULL pointer dereference, address: 00000000000006c2 [ 156.318330] #PF: supervisor write access in kernel mode [ 156.323546] #PF: error_code(0x0002) - not-present page [ 156.328679] PGD 0 P4D 0 [ 156.331210] Oops: 0002 [#1] PREEMPT SMP NOPTI [ 156.335567] CPU: 26 PID: 15119 Comm: reboot Tainted: G E 6.2.0+ #1 [ 156.343126] Hardware name: Abacus electric, s.r.o. - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.4 04/13/2022 [ 156.353369] RIP: 0010:i40e_shutdown+0x15/0x130 [i40e] [ 156.358430] Code: c1 fc ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 55 48 89 fd 53 48 8b 9f 48 01 00 00 <f0> 80 8b c2 06 00 00 04 f0 80 8b c0 06 00 00 08 48 8d bb 08 08 00 [ 156.377168] RSP: 0018:ffffb223c8447d90 EFLAGS: 00010282 [ 156.382384] RAX: ffffffffc073ee70 RBX: 0000000000000000 RCX: 0000000000000001 [ 156.389510] RDX: 0000000080000001 RSI: 0000000000000246 RDI: ffff95db49988000 [ 156.396634] RBP: ffff95db49988000 R08: ffffffffffffffff R09: ffffffff8bd17d40 [ 156.403759] R10: 0000000000000001 R11: ffffffff8a5e3d28 R12: ffff95db49988000 [ 156.410882] R13: ffffffff89a6fe17 R14: ffff95db49988150 R15: 0000000000000000 [ 156.418007] FS: 00007fe7c0cc3980(0000) GS:ffff95ea8ee80000(0000) knlGS:0000000000000000 [ 156.426083] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 156.431819] CR2: 00000000000006c2 CR3: 00000003092fc005 CR4: 0000000000770ee0 [ 156.438944] PKRU: 55555554 [ 156.441647] Call Trace: [ 156.444096] <TASK> [ 156.446199] pci_device_shutdown+0x38/0x60 [ 156.450297] device_shutdown+0x163/0x210 [ 156.454215] kernel_restart+0x12/0x70 [ 156.457872] __do_sys_reboot+0x1ab/0x230 [ 156.461789] ? vfs_writev+0xa6/0x1a0 [ 156.465362] ? __pfx_file_free_rcu+0x10/0x10 [ 156.469635] ? __call_rcu_common.constprop.85+0x109/0x5a0 [ 156.475034] do_syscall_64+0x3e/0x90 [ 156.478611] entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 156.483658] RIP: 0033:0x7fe7bff37ab7 CVE-2023-53114 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: tcp: tcp_make_synack() can be called from process context tcp_rtx_synack() now could be called in process context as explained in 0a375c822497 ("tcp: tcp_rtx_synack() can be called from process context"). tcp_rtx_synack() might call tcp_make_synack(), which will touch per-CPU variables with preemption enabled. This causes the following BUG: BUG: using __this_cpu_add() in preemptible [00000000] code: ThriftIO1/5464 caller is tcp_make_synack+0x841/0xac0 Call Trace: <TASK> dump_stack_lvl+0x10d/0x1a0 check_preemption_disabled+0x104/0x110 tcp_make_synack+0x841/0xac0 tcp_v6_send_synack+0x5c/0x450 tcp_rtx_synack+0xeb/0x1f0 inet_rtx_syn_ack+0x34/0x60 tcp_check_req+0x3af/0x9e0 tcp_rcv_state_process+0x59b/0x2030 tcp_v6_do_rcv+0x5f5/0x700 release_sock+0x3a/0xf0 tcp_sendmsg+0x33/0x40 ____sys_sendmsg+0x2f2/0x490 __sys_sendmsg+0x184/0x230 do_syscall_64+0x3d/0x90 Avoid calling __TCP_INC_STATS() with will touch per-cpu variables. Use TCP_INC_STATS() which is safe to be called from context switch. CVE-2023-53121 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Fix NULL pointer access in mpt3sas_transport_port_add() Port is allocated by sas_port_alloc_num() and rphy is allocated by either sas_end_device_alloc() or sas_expander_alloc(), all of which may return NULL. So we need to check the rphy to avoid possible NULL pointer access. If sas_rphy_add() returned with failure, rphy is set to NULL. We would access the rphy in the following lines which would also result NULL pointer access. CVE-2023-53124 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: usb: smsc75xx: Limit packet length to skb->len Packet length retrieved from skb data may be larger than the actual socket buffer length (up to 9026 bytes). In such case the cloned skb passed up the network stack will leak kernel memory contents. CVE-2023-53125 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Fix a server shutdown leak Fix a race where kthread_stop() may prevent the threadfn from ever getting called. If that happens the svc_rqst will not be cleaned up. CVE-2023-53131 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: nfc: fdp: add null check of devm_kmalloc_array in fdp_nci_i2c_read_device_properties devm_kmalloc_array may fails, *fw_vsc_cfg might be null and cause out-of-bounds write in device_property_read_u8_array later. CVE-2023-53139 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: core: Remove the /proc/scsi/${proc_name} directory earlier Remove the /proc/scsi/${proc_name} directory earlier to fix a race condition between unloading and reloading kernel modules. This fixes a bug introduced in 2009 by commit 77c019768f06 ("[SCSI] fix /proc memory leak in the SCSI core"). Fix the following kernel warning: proc_dir_entry 'scsi/scsi_debug' already registered WARNING: CPU: 19 PID: 27986 at fs/proc/generic.c:376 proc_register+0x27d/0x2e0 Call Trace: proc_mkdir+0xb5/0xe0 scsi_proc_hostdir_add+0xb5/0x170 scsi_host_alloc+0x683/0x6c0 sdebug_driver_probe+0x6b/0x2d0 [scsi_debug] really_probe+0x159/0x540 __driver_probe_device+0xdc/0x230 driver_probe_device+0x4f/0x120 __device_attach_driver+0xef/0x180 bus_for_each_drv+0xe5/0x130 __device_attach+0x127/0x290 device_initial_probe+0x17/0x20 bus_probe_device+0x110/0x130 device_add+0x673/0xc80 device_register+0x1e/0x30 sdebug_add_host_helper+0x1a7/0x3b0 [scsi_debug] scsi_debug_init+0x64f/0x1000 [scsi_debug] do_one_initcall+0xd7/0x470 do_init_module+0xe7/0x330 load_module+0x122a/0x12c0 __do_sys_finit_module+0x124/0x1a0 __x64_sys_finit_module+0x46/0x50 do_syscall_64+0x38/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 CVE-2023-53140 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ila: do not generate empty messages in ila_xlat_nl_cmd_get_mapping() ila_xlat_nl_cmd_get_mapping() generates an empty skb, triggerring a recent sanity check [1]. Instead, return an error code, so that user space can get it. [1] skb_assert_len WARNING: CPU: 0 PID: 5923 at include/linux/skbuff.h:2527 skb_assert_len include/linux/skbuff.h:2527 [inline] WARNING: CPU: 0 PID: 5923 at include/linux/skbuff.h:2527 __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156 Modules linked in: CPU: 0 PID: 5923 Comm: syz-executor269 Not tainted 6.2.0-syzkaller-18300-g2ebd1fbb946d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/21/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_assert_len include/linux/skbuff.h:2527 [inline] pc : __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156 lr : skb_assert_len include/linux/skbuff.h:2527 [inline] lr : __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156 sp : ffff80001e0d6c40 x29: ffff80001e0d6e60 x28: dfff800000000000 x27: ffff0000c86328c0 x26: dfff800000000000 x25: ffff0000c8632990 x24: ffff0000c8632a00 x23: 0000000000000000 x22: 1fffe000190c6542 x21: ffff0000c8632a10 x20: ffff0000c8632a00 x19: ffff80001856e000 x18: ffff80001e0d5fc0 x17: 0000000000000000 x16: ffff80001235d16c x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000001 x12: 0000000000000001 x11: ff80800008353a30 x10: 0000000000000000 x9 : 21567eaf25bfb600 x8 : 21567eaf25bfb600 x7 : 0000000000000001 x6 : 0000000000000001 x5 : ffff80001e0d6558 x4 : ffff800015c74760 x3 : ffff800008596744 x2 : 0000000000000001 x1 : 0000000100000000 x0 : 000000000000000e Call trace: skb_assert_len include/linux/skbuff.h:2527 [inline] __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156 dev_queue_xmit include/linux/netdevice.h:3033 [inline] __netlink_deliver_tap_skb net/netlink/af_netlink.c:307 [inline] __netlink_deliver_tap+0x45c/0x6f8 net/netlink/af_netlink.c:325 netlink_deliver_tap+0xf4/0x174 net/netlink/af_netlink.c:338 __netlink_sendskb net/netlink/af_netlink.c:1283 [inline] netlink_sendskb+0x6c/0x154 net/netlink/af_netlink.c:1292 netlink_unicast+0x334/0x8d4 net/netlink/af_netlink.c:1380 nlmsg_unicast include/net/netlink.h:1099 [inline] genlmsg_unicast include/net/genetlink.h:433 [inline] genlmsg_reply include/net/genetlink.h:443 [inline] ila_xlat_nl_cmd_get_mapping+0x620/0x7d0 net/ipv6/ila/ila_xlat.c:493 genl_family_rcv_msg_doit net/netlink/genetlink.c:968 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1048 [inline] genl_rcv_msg+0x938/0xc1c net/netlink/genetlink.c:1065 netlink_rcv_skb+0x214/0x3c4 net/netlink/af_netlink.c:2574 genl_rcv+0x38/0x50 net/netlink/genetlink.c:1076 netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline] netlink_unicast+0x660/0x8d4 net/netlink/af_netlink.c:1365 netlink_sendmsg+0x800/0xae0 net/netlink/af_netlink.c:1942 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] ____sys_sendmsg+0x558/0x844 net/socket.c:2479 ___sys_sendmsg net/socket.c:2533 [inline] __sys_sendmsg+0x26c/0x33c net/socket.c:2562 __do_sys_sendmsg net/socket.c:2571 [inline] __se_sys_sendmsg net/socket.c:2569 [inline] __arm64_sys_sendmsg+0x80/0x94 net/socket.c:2569 __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline] invoke_syscall+0x98/0x2c0 arch/arm64/kernel/syscall.c:52 el0_svc_common+0x138/0x258 arch/arm64/kernel/syscall.c:142 do_el0_svc+0x64/0x198 arch/arm64/kernel/syscall.c:193 el0_svc+0x58/0x168 arch/arm64/kernel/entry-common.c:637 el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:655 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591 irq event stamp: 136484 hardirqs last enabled at (136483): [<ffff800008350244>] __up_console_sem+0x60/0xb4 kernel/printk/printk.c:345 hardirqs last disabled at (136484): [<ffff800012358d60>] el1_dbg+0x24/0x80 arch/arm64/kernel/entry-common.c:405 softirqs last enabled at (136418): [<ffff800008020ea8>] softirq_ha ---truncated--- CVE-2023-53141 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate 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. CVE-2024-10041 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libapparmor1-2.8.2-56.26.1 moderate Applications that use Wget to access a remote resource using shorthand URLs and pass arbitrary user credentials in the URL are vulnerable. In these cases attackers can enter crafted credentials which will cause Wget to access an arbitrary host. CVE-2024-10524 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:wget-1.14-21.25.1 moderate A flaw was found in rsync. When using the `--safe-links` option, the rsync client fails to properly verify if a symbolic link destination sent from the server contains another symbolic link within it. This results in a path traversal vulnerability, which may lead to arbitrary file write outside the desired directory. CVE-2024-12088 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:rsync-3.1.3-3.28.1 moderate In the Linux kernel, the following vulnerability has been resolved: net/sched: act_mirred: use the backlog for mirred ingress The test Davide added in commit ca22da2fbd69 ("act_mirred: use the backlog for nested calls to mirred ingress") hangs our testing VMs every 10 or so runs, with the familiar tcp_v4_rcv -> tcp_v4_rcv deadlock reported by lockdep. The problem as previously described by Davide (see Link) is that if we reverse flow of traffic with the redirect (egress -> ingress) we may reach the same socket which generated the packet. And we may still be holding its socket lock. The common solution to such deadlocks is to put the packet in the Rx backlog, rather than run the Rx path inline. Do that for all egress -> ingress reversals, not just once we started to nest mirred calls. In the past there was a concern that the backlog indirection will lead to loss of error reporting / less accurate stats. But the current workaround does not seem to address the issue. CVE-2024-26740 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: ip_tunnel: prevent perpetual headroom growth syzkaller triggered following kasan splat: BUG: KASAN: use-after-free in __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191 [..] kasan_report+0xda/0x110 mm/kasan/report.c:588 __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline] ___skb_get_hash net/core/flow_dissector.c:1791 [inline] __skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856 skb_get_hash include/linux/skbuff.h:1556 [inline] ip_tunnel_xmit+0x1855/0x33c0 net/ipv4/ip_tunnel.c:748 ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592 ... ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323 .. iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831 ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 ... The splat occurs because skb->data points past skb->head allocated area. This is because neigh layer does: __skb_pull(skb, skb_network_offset(skb)); ... but skb_network_offset() returns a negative offset and __skb_pull() arg is unsigned. IOW, we skb->data gets "adjusted" by a huge value. The negative value is returned because skb->head and skb->data distance is more than 64k and skb->network_header (u16) has wrapped around. The bug is in the ip_tunnel infrastructure, which can cause dev->needed_headroom to increment ad infinitum. The syzkaller reproducer consists of packets getting routed via a gre tunnel, and route of gre encapsulated packets pointing at another (ipip) tunnel. The ipip encapsulation finds gre0 as next output device. This results in the following pattern: 1). First packet is to be sent out via gre0. Route lookup found an output device, ipip0. 2). ip_tunnel_xmit for gre0 bumps gre0->needed_headroom based on the future output device, rt.dev->needed_headroom (ipip0). 3). ip output / start_xmit moves skb on to ipip0. which runs the same code path again (xmit recursion). 4). Routing step for the post-gre0-encap packet finds gre0 as output device to use for ipip0 encapsulated packet. tunl0->needed_headroom is then incremented based on the (already bumped) gre0 device headroom. This repeats for every future packet: gre0->needed_headroom gets inflated because previous packets' ipip0 step incremented rt->dev (gre0) headroom, and ipip0 incremented because gre0 needed_headroom was increased. For each subsequent packet, gre/ipip0->needed_headroom grows until post-expand-head reallocations result in a skb->head/data distance of more than 64k. Once that happens, skb->network_header (u16) wraps around when pskb_expand_head tries to make sure that skb_network_offset() is unchanged after the headroom expansion/reallocation. After this skb_network_offset(skb) returns a different (and negative) result post headroom expansion. The next trip to neigh layer (or anything else that would __skb_pull the network header) makes skb->data point to a memory location outside skb->head area. v2: Cap the needed_headroom update to an arbitarily chosen upperlimit to prevent perpetual increase instead of dropping the headroom increment completely. CVE-2024-26804 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net/sched: Fix mirred deadlock on device recursion When the mirred action is used on a classful egress qdisc and a packet is mirrored or redirected to self we hit a qdisc lock deadlock. See trace below. [..... other info removed for brevity....] [ 82.890906] [ 82.890906] ============================================ [ 82.890906] WARNING: possible recursive locking detected [ 82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G W [ 82.890906] -------------------------------------------- [ 82.890906] ping/418 is trying to acquire lock: [ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at: __dev_queue_xmit+0x1778/0x3550 [ 82.890906] [ 82.890906] but task is already holding lock: [ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at: __dev_queue_xmit+0x1778/0x3550 [ 82.890906] [ 82.890906] other info that might help us debug this: [ 82.890906] Possible unsafe locking scenario: [ 82.890906] [ 82.890906] CPU0 [ 82.890906] ---- [ 82.890906] lock(&sch->q.lock); [ 82.890906] lock(&sch->q.lock); [ 82.890906] [ 82.890906] *** DEADLOCK *** [ 82.890906] [..... other info removed for brevity....] Example setup (eth0->eth0) to recreate tc qdisc add dev eth0 root handle 1: htb default 30 tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth0 Another example(eth0->eth1->eth0) to recreate tc qdisc add dev eth0 root handle 1: htb default 30 tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth1 tc qdisc add dev eth1 root handle 1: htb default 30 tc filter add dev eth1 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth0 We fix this by adding an owner field (CPU id) to struct Qdisc set after root qdisc is entered. When the softirq enters it a second time, if the qdisc owner is the same CPU, the packet is dropped to break the loop. CVE-2024-27010 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: tcp: properly terminate timers for kernel sockets We had various syzbot reports about tcp timers firing after the corresponding netns has been dismantled. Fortunately Josef Bacik could trigger the issue more often, and could test a patch I wrote two years ago. When TCP sockets are closed, we call inet_csk_clear_xmit_timers() to 'stop' the timers. inet_csk_clear_xmit_timers() can be called from any context, including when socket lock is held. This is the reason it uses sk_stop_timer(), aka del_timer(). This means that ongoing timers might finish much later. For user sockets, this is fine because each running timer holds a reference on the socket, and the user socket holds a reference on the netns. For kernel sockets, we risk that the netns is freed before timer can complete, because kernel sockets do not hold reference on the netns. This patch adds inet_csk_clear_xmit_timers_sync() function that using sk_stop_timer_sync() to make sure all timers are terminated before the kernel socket is released. Modules using kernel sockets close them in their netns exit() handler. Also add sock_not_owned_by_me() helper to get LOCKDEP support : inet_csk_clear_xmit_timers_sync() must not be called while socket lock is held. It is very possible we can revert in the future commit 3a58f13a881e ("net: rds: acquire refcount on TCP sockets") which attempted to solve the issue in rds only. (net/smc/af_smc.c and net/mptcp/subflow.c have similar code) We probably can remove the check_net() tests from tcp_out_of_resources() and __tcp_close() in the future. CVE-2024-35910 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init() l2cap_le_flowctl_init() can cause both div-by-zero and an integer overflow since hdev->le_mtu may not fall in the valid range. Move MTU from hci_dev to hci_conn to validate MTU and stop the connection process earlier if MTU is invalid. Also, add a missing validation in read_buffer_size() and make it return an error value if the validation fails. Now hci_conn_add() returns ERR_PTR() as it can fail due to the both a kzalloc failure and invalid MTU value. divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G W 6.9.0-rc5+ #20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci0 hci_rx_work RIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547 Code: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c 89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 <66> f7 f3 89 c3 ff c3 4d 8d b7 88 00 00 00 4c 89 f0 48 c1 e8 03 42 RSP: 0018:ffff88810bc0f858 EFLAGS: 00010246 RAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66f RBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaa R10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084 R13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000 FS: 0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <TASK> l2cap_le_connect_req net/bluetooth/l2cap_core.c:4902 [inline] l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [inline] l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [inline] l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c:6809 l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506 hci_acldata_packet net/bluetooth/hci_core.c:3939 [inline] hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335 worker_thread+0x926/0xe70 kernel/workqueue.c:3416 kthread+0x2e3/0x380 kernel/kthread.c:388 ret_from_fork+0x5c/0x90 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- CVE-2024-36968 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: qedf: Ensure the copied buf is NUL terminated Currently, we allocate a count-sized kernel buffer and copy count from userspace to that buffer. Later, we use kstrtouint on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using kstrtouint. Fix this issue by using memdup_user_nul instead of memdup_user. CVE-2024-38559 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: netpoll: Fix race condition in netpoll_owner_active KCSAN detected a race condition in netpoll: BUG: KCSAN: data-race in net_rx_action / netpoll_send_skb write (marked) to 0xffff8881164168b0 of 4 bytes by interrupt on cpu 10: net_rx_action (./include/linux/netpoll.h:90 net/core/dev.c:6712 net/core/dev.c:6822) <snip> read to 0xffff8881164168b0 of 4 bytes by task 1 on cpu 2: netpoll_send_skb (net/core/netpoll.c:319 net/core/netpoll.c:345 net/core/netpoll.c:393) netpoll_send_udp (net/core/netpoll.c:?) <snip> value changed: 0x0000000a -> 0xffffffff This happens because netpoll_owner_active() needs to check if the current CPU is the owner of the lock, touching napi->poll_owner non atomically. The ->poll_owner field contains the current CPU holding the lock. Use an atomic read to check if the poll owner is the current CPU. CVE-2024-41005 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate Vim is an open source command line text editor. double-free in dialog_changed() in Vim < v9.1.0648. When abandoning a buffer, Vim may ask the user what to do with the modified buffer. If the user wants the changed buffer to be saved, Vim may create a new Untitled file, if the buffer did not have a name yet. However, when setting the buffer name to Unnamed, Vim will falsely free a pointer twice, leading to a double-free and possibly later to a heap-use-after-free, which can lead to a crash. The issue has been fixed as of Vim patch v9.1.0648. CVE-2024-41965 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:vim-9.1.1406-17.48.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:vim-data-common-9.1.1406-17.48.1 low In the Linux kernel, the following vulnerability has been resolved: memcg_write_event_control(): fix a user-triggerable oops we are *not* guaranteed that anything past the terminating NUL is mapped (let alone initialized with anything sane). CVE-2024-45021 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate 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. CVE-2024-45339 important An issue was discovered in libexpat before 2.6.3. xmlparse.c does not reject a negative length for XML_ParseBuffer. CVE-2024-45490 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:expat-2.7.1-21.43.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libexpat1-2.7.1-21.43.1 moderate An issue was discovered in libexpat before 2.6.3. dtdCopy in xmlparse.c can have an integer overflow for nDefaultAtts on 32-bit platforms (where UINT_MAX equals SIZE_MAX). CVE-2024-45491 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:expat-2.7.1-21.43.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libexpat1-2.7.1-21.43.1 moderate An issue was discovered in libexpat before 2.6.3. nextScaffoldPart in xmlparse.c can have an integer overflow for m_groupSize on 32-bit platforms (where UINT_MAX equals SIZE_MAX). CVE-2024-45492 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:expat-2.7.1-21.43.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libexpat1-2.7.1-21.43.1 moderate In the Linux kernel, the following vulnerability has been resolved: btrfs: don't BUG_ON() when 0 reference count at btrfs_lookup_extent_info() Instead of doing a BUG_ON() handle the error by returning -EUCLEAN, aborting the transaction and logging an error message. CVE-2024-46751 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: btrfs: replace BUG_ON() with error handling at update_ref_for_cow() Instead of a BUG_ON() just return an error, log an error message and abort the transaction in case we find an extent buffer belonging to the relocation tree that doesn't have the full backref flag set. This is unexpected and should never happen (save for bugs or a potential bad memory). CVE-2024-46752 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: fou: Fix null-ptr-deref in GRO. We observed a null-ptr-deref in fou_gro_receive() while shutting down a host. [0] The NULL pointer is sk->sk_user_data, and the offset 8 is of protocol in struct fou. When fou_release() is called due to netns dismantle or explicit tunnel teardown, udp_tunnel_sock_release() sets NULL to sk->sk_user_data. Then, the tunnel socket is destroyed after a single RCU grace period. So, in-flight udp4_gro_receive() could find the socket and execute the FOU GRO handler, where sk->sk_user_data could be NULL. Let's use rcu_dereference_sk_user_data() in fou_from_sock() and add NULL checks in FOU GRO handlers. [0]: BUG: kernel NULL pointer dereference, address: 0000000000000008 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present page PGD 80000001032f4067 P4D 80000001032f4067 PUD 103240067 PMD 0 SMP PTI CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.216-204.855.amzn2.x86_64 #1 Hardware name: Amazon EC2 c5.large/, BIOS 1.0 10/16/2017 RIP: 0010:fou_gro_receive (net/ipv4/fou.c:233) [fou] Code: 41 5f c3 cc cc cc cc e8 e7 2e 69 f4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 49 89 f8 41 54 48 89 f7 48 89 d6 49 8b 80 88 02 00 00 <0f> b6 48 08 0f b7 42 4a 66 25 fd fd 80 cc 02 66 89 42 4a 0f b6 42 RSP: 0018:ffffa330c0003d08 EFLAGS: 00010297 RAX: 0000000000000000 RBX: ffff93d9e3a6b900 RCX: 0000000000000010 RDX: ffff93d9e3a6b900 RSI: ffff93d9e3a6b900 RDI: ffff93dac2e24d08 RBP: ffff93d9e3a6b900 R08: ffff93dacbce6400 R09: 0000000000000002 R10: 0000000000000000 R11: ffffffffb5f369b0 R12: ffff93dacbce6400 R13: ffff93dac2e24d08 R14: 0000000000000000 R15: ffffffffb4edd1c0 FS: 0000000000000000(0000) GS:ffff93daee800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000102140001 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259) ? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420) ? no_context (arch/x86/mm/fault.c:752) ? exc_page_fault (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 arch/x86/mm/fault.c:1435 arch/x86/mm/fault.c:1483) ? asm_exc_page_fault (arch/x86/include/asm/idtentry.h:571) ? fou_gro_receive (net/ipv4/fou.c:233) [fou] udp_gro_receive (include/linux/netdevice.h:2552 net/ipv4/udp_offload.c:559) udp4_gro_receive (net/ipv4/udp_offload.c:604) inet_gro_receive (net/ipv4/af_inet.c:1549 (discriminator 7)) dev_gro_receive (net/core/dev.c:6035 (discriminator 4)) napi_gro_receive (net/core/dev.c:6170) ena_clean_rx_irq (drivers/amazon/net/ena/ena_netdev.c:1558) [ena] ena_io_poll (drivers/amazon/net/ena/ena_netdev.c:1742) [ena] napi_poll (net/core/dev.c:6847) net_rx_action (net/core/dev.c:6917) __do_softirq (arch/x86/include/asm/jump_label.h:25 include/linux/jump_label.h:200 include/trace/events/irq.h:142 kernel/softirq.c:299) asm_call_irq_on_stack (arch/x86/entry/entry_64.S:809) </IRQ> do_softirq_own_stack (arch/x86/include/asm/irq_stack.h:27 arch/x86/include/asm/irq_stack.h:77 arch/x86/kernel/irq_64.c:77) irq_exit_rcu (kernel/softirq.c:393 kernel/softirq.c:423 kernel/softirq.c:435) common_interrupt (arch/x86/kernel/irq.c:239) asm_common_interrupt (arch/x86/include/asm/idtentry.h:626) RIP: 0010:acpi_idle_do_entry (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 drivers/acpi/processor_idle.c:114 drivers/acpi/processor_idle.c:575) Code: 8b 15 d1 3c c4 02 ed c3 cc cc cc cc 65 48 8b 04 25 40 ef 01 00 48 8b 00 a8 08 75 eb 0f 1f 44 00 00 0f 00 2d d5 09 55 00 fb f4 <fa> c3 cc cc cc cc e9 be fc ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 RSP: 0018:ffffffffb5603e58 EFLAGS: 00000246 RAX: 0000000000004000 RBX: ffff93dac0929c00 RCX: ffff93daee833900 RDX: ffff93daee800000 RSI: ffff93d ---truncated--- CVE-2024-46763 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate Requests is a HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session. CVE-2024-47081 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:python-requests-2.24.0-8.23.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:python3-requests-2.24.0-8.20.1 moderate In the Linux kernel, the following vulnerability has been resolved: icmp: change the order of rate limits ICMP messages are ratelimited : After the blamed commits, the two rate limiters are applied in this order: 1) host wide ratelimit (icmp_global_allow()) 2) Per destination ratelimit (inetpeer based) In order to avoid side-channels attacks, we need to apply the per destination check first. This patch makes the following change : 1) icmp_global_allow() checks if the host wide limit is reached. But credits are not yet consumed. This is deferred to 3) 2) The per destination limit is checked/updated. This might add a new node in inetpeer tree. 3) icmp_global_consume() consumes tokens if prior operations succeeded. This means that host wide ratelimit is still effective in keeping inetpeer tree small even under DDOS. As a bonus, I removed icmp_global.lock as the fast path can use a lock-free operation. CVE-2024-47678 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net/smc: check iparea_offset and ipv6_prefixes_cnt when receiving proposal msg When receiving proposal msg in server, the field iparea_offset and the field ipv6_prefixes_cnt in proposal msg are from the remote client and can not be fully trusted. Especially the field iparea_offset, once exceed the max value, there has the chance to access wrong address, and crash may happen. This patch checks iparea_offset and ipv6_prefixes_cnt before using them. CVE-2024-49571 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ACPI: PAD: fix crash in exit_round_robin() The kernel occasionally crashes in cpumask_clear_cpu(), which is called within exit_round_robin(), because when executing clear_bit(nr, addr) with nr set to 0xffffffff, the address calculation may cause misalignment within the memory, leading to access to an invalid memory address. ---------- BUG: unable to handle kernel paging request at ffffffffe0740618 ... CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G OE X --------- - - 4.18.0-425.19.2.el8_7.x86_64 #1 ... RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad] Code: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 <f0> 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31 RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202 RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8 R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000000e R13: 0000000000000000 R14: ffffffffffffffff R15: 000000000000000e FS: 0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? acpi_pad_add+0x120/0x120 [acpi_pad] kthread+0x10b/0x130 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x1f/0x40 ... CR2: ffffffffe0740618 crash> dis -lr ffffffffc0726923 ... /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 114 0xffffffffc0726918 <power_saving_thread+776>: mov %r12d,%r12d /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 325 0xffffffffc072691b <power_saving_thread+779>: mov -0x3f8d7de0(,%r12,4),%eax /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 80 0xffffffffc0726923 <power_saving_thread+787>: lock btr %rax,0x19cf4(%rip) # 0xffffffffc0740620 <pad_busy_cpus_bits> crash> px tsk_in_cpu[14] $66 = 0xffffffff crash> px 0xffffffffc072692c+0x19cf4 $99 = 0xffffffffc0740620 crash> sym 0xffffffffc0740620 ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad] crash> px pad_busy_cpus_bits[0] $42 = 0xfffc0 ---------- To fix this, ensure that tsk_in_cpu[tsk_index] != -1 before calling cpumask_clear_cpu() in exit_round_robin(), just as it is done in round_robin_cpu(). [ rjw: Subject edit, avoid updates to the same value ] CVE-2024-49935 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: l2tp: prevent possible tunnel refcount underflow When a session is created, it sets a backpointer to its tunnel. When the session refcount drops to 0, l2tp_session_free drops the tunnel refcount if session->tunnel is non-NULL. However, session->tunnel is set in l2tp_session_create, before the tunnel refcount is incremented by l2tp_session_register, which leaves a small window where session->tunnel is non-NULL when the tunnel refcount hasn't been bumped. Moving the assignment to l2tp_session_register is trivial but l2tp_session_create calls l2tp_session_set_header_len which uses session->tunnel to get the tunnel's encap. Add an encap arg to l2tp_session_set_header_len to avoid using session->tunnel. If l2tpv3 sessions have colliding IDs, it is possible for l2tp_v3_session_get to race with l2tp_session_register and fetch a session which doesn't yet have session->tunnel set. Add a check for this case. CVE-2024-49940 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: block: fix integer overflow in BLKSECDISCARD I independently rediscovered commit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155 block: fix overflow in blk_ioctl_discard() but for secure erase. Same problem: uint64_t r[2] = {512, 18446744073709551104ULL}; ioctl(fd, BLKSECDISCARD, r); will enter near infinite loop inside blkdev_issue_secure_erase(): a.out: attempt to access beyond end of device loop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048 bio_check_eod: 3286214 callbacks suppressed CVE-2024-49994 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: netfilter: xtables: avoid NFPROTO_UNSPEC where needed syzbot managed to call xt_cluster match via ebtables: WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780 [..] ebt_do_table+0x174b/0x2a40 Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packet processing. As this is only useful to restrict locally terminating TCP/UDP traffic, register this for ipv4 and ipv6 family only. Pablo points out that this is a general issue, direct users of the set/getsockopt interface can call into targets/matches that were only intended for use with ip(6)tables. Check all UNSPEC matches and targets for similar issues: - matches and targets are fine except if they assume skb_network_header() is valid -- this is only true when called from inet layer: ip(6) stack pulls the ip/ipv6 header into linear data area. - targets that return XT_CONTINUE or other xtables verdicts must be restricted too, they are incompatbile with the ebtables traverser, e.g. EBT_CONTINUE is a completely different value than XT_CONTINUE. Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, as they are provided for use by ip(6)tables. The MARK target is also used by arptables, so register for NFPROTO_ARP too. While at it, bail out if connbytes fails to enable the corresponding conntrack family. This change passes the selftests in iptables.git. CVE-2024-50038 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: nfsd: fix race between laundromat and free_stateid There is a race between laundromat handling of revoked delegations and a client sending free_stateid operation. Laundromat thread finds that delegation has expired and needs to be revoked so it marks the delegation stid revoked and it puts it on a reaper list but then it unlock the state lock and the actual delegation revocation happens without the lock. Once the stid is marked revoked a racing free_stateid processing thread does the following (1) it calls list_del_init() which removes it from the reaper list and (2) frees the delegation stid structure. The laundromat thread ends up not calling the revoke_delegation() function for this particular delegation but that means it will no release the lock lease that exists on the file. Now, a new open for this file comes in and ends up finding that lease list isn't empty and calls nfsd_breaker_owns_lease() which ends up trying to derefence a freed delegation stateid. Leading to the followint use-after-free KASAN warning: kernel: ================================================================== kernel: BUG: KASAN: slab-use-after-free in nfsd_breaker_owns_lease+0x140/0x160 [nfsd] kernel: Read of size 8 at addr ffff0000e73cd0c8 by task nfsd/6205 kernel: kernel: CPU: 2 UID: 0 PID: 6205 Comm: nfsd Kdump: loaded Not tainted 6.11.0-rc7+ #9 kernel: Hardware name: Apple Inc. Apple Virtualization Generic Platform, BIOS 2069.0.0.0.0 08/03/2024 kernel: Call trace: kernel: dump_backtrace+0x98/0x120 kernel: show_stack+0x1c/0x30 kernel: dump_stack_lvl+0x80/0xe8 kernel: print_address_description.constprop.0+0x84/0x390 kernel: print_report+0xa4/0x268 kernel: kasan_report+0xb4/0xf8 kernel: __asan_report_load8_noabort+0x1c/0x28 kernel: nfsd_breaker_owns_lease+0x140/0x160 [nfsd] kernel: nfsd_file_do_acquire+0xb3c/0x11d0 [nfsd] kernel: nfsd_file_acquire_opened+0x84/0x110 [nfsd] kernel: nfs4_get_vfs_file+0x634/0x958 [nfsd] kernel: nfsd4_process_open2+0xa40/0x1a40 [nfsd] kernel: nfsd4_open+0xa08/0xe80 [nfsd] kernel: nfsd4_proc_compound+0xb8c/0x2130 [nfsd] kernel: nfsd_dispatch+0x22c/0x718 [nfsd] kernel: svc_process_common+0x8e8/0x1960 [sunrpc] kernel: svc_process+0x3d4/0x7e0 [sunrpc] kernel: svc_handle_xprt+0x828/0xe10 [sunrpc] kernel: svc_recv+0x2cc/0x6a8 [sunrpc] kernel: nfsd+0x270/0x400 [nfsd] kernel: kthread+0x288/0x310 kernel: ret_from_fork+0x10/0x20 This patch proposes a fixed that's based on adding 2 new additional stid's sc_status values that help coordinate between the laundromat and other operations (nfsd4_free_stateid() and nfsd4_delegreturn()). First to make sure, that once the stid is marked revoked, it is not removed by the nfsd4_free_stateid(), the laundromat take a reference on the stateid. Then, coordinating whether the stid has been put on the cl_revoked list or we are processing FREE_STATEID and need to make sure to remove it from the list, each check that state and act accordingly. If laundromat has added to the cl_revoke list before the arrival of FREE_STATEID, then nfsd4_free_stateid() knows to remove it from the list. If nfsd4_free_stateid() finds that operations arrived before laundromat has placed it on cl_revoke list, it marks the state freed and then laundromat will no longer add it to the list. Also, for nfsd4_delegreturn() when looking for the specified stid, we need to access stid that are marked removed or freeable, it means the laundromat has started processing it but hasn't finished and this delegreturn needs to return nfserr_deleg_revoked and not nfserr_bad_stateid. The latter will not trigger a FREE_STATEID and the lack of it will leave this stid on the cl_revoked list indefinitely. CVE-2024-50106 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: usb: musb: sunxi: Fix accessing an released usb phy Commit 6ed05c68cbca ("usb: musb: sunxi: Explicitly release USB PHY on exit") will cause that usb phy @glue->xceiv is accessed after released. 1) register platform driver @sunxi_musb_driver // get the usb phy @glue->xceiv sunxi_musb_probe() -> devm_usb_get_phy(). 2) register and unregister platform driver @musb_driver musb_probe() -> sunxi_musb_init() use the phy here //the phy is released here musb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy() 3) register @musb_driver again musb_probe() -> sunxi_musb_init() use the phy here but the phy has been released at 2). ... Fixed by reverting the commit, namely, removing devm_usb_put_phy() from sunxi_musb_exit(). CVE-2024-50269 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: filemap: Fix bounds checking in filemap_read() If the caller supplies an iocb->ki_pos value that is close to the filesystem upper limit, and an iterator with a count that causes us to overflow that limit, then filemap_read() enters an infinite loop. This behaviour was discovered when testing xfstests generic/525 with the "localio" optimisation for loopback NFS mounts. CVE-2024-50272 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: cx24116: prevent overflows on SNR calculus as reported by Coverity, if reading SNR registers fail, a negative number will be returned, causing an underflow when reading SNR registers. Prevent that. CVE-2024-50290 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 important An issue was discovered in libexpat before 2.6.4. There is a crash within the XML_ResumeParser function because XML_StopParser can stop/suspend an unstarted parser. CVE-2024-50602 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:expat-2.7.1-21.43.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libexpat1-2.7.1-21.43.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/msm/gem: prevent integer overflow in msm_ioctl_gem_submit() The "submit->cmd[i].size" and "submit->cmd[i].offset" variables are u32 values that come from the user via the submit_lookup_cmds() function. This addition could lead to an integer wrapping bug so use size_add() to prevent that. Patchwork: https://patchwork.freedesktop.org/patch/624696/ CVE-2024-52559 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: dvbdev: prevent the risk of out of memory access The dvbdev contains a static variable used to store dvb minors. The behavior of it depends if CONFIG_DVB_DYNAMIC_MINORS is set or not. When not set, dvb_register_device() won't check for boundaries, as it will rely that a previous call to dvb_register_adapter() would already be enforcing it. On a similar way, dvb_device_open() uses the assumption that the register functions already did the needed checks. This can be fragile if some device ends using different calls. This also generate warnings on static check analysers like Coverity. So, add explicit guards to prevent potential risk of OOM issues. CVE-2024-53063 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 important In the Linux kernel, the following vulnerability has been resolved: net: fix data-races around sk->sk_forward_alloc Syzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inet_sock_destruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? __warn+0x88/0x130 ? inet_sock_destruct+0x1c5/0x1e0 ? report_bug+0x18e/0x1a0 ? handle_bug+0x53/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x1c5/0x1e0 __sk_destruct+0x2a/0x200 rcu_do_batch+0x1aa/0x530 ? rcu_do_batch+0x13b/0x530 rcu_core+0x159/0x2f0 handle_softirqs+0xd3/0x2b0 ? __pfx_smpboot_thread_fn+0x10/0x10 run_ksoftirqd+0x25/0x30 smpboot_thread_fn+0xdd/0x1d0 kthread+0xd3/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> ---[ end trace 0000000000000000 ]--- Its possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add() concurrently when sk->sk_state == TCP_LISTEN with sk->sk_lock unlocked, which triggers a data-race around sk->sk_forward_alloc: tcp_v6_rcv tcp_v6_do_rcv skb_clone_and_charge_r sk_rmem_schedule __sk_mem_schedule sk_forward_alloc_add() skb_set_owner_r sk_mem_charge sk_forward_alloc_add() __kfree_skb skb_release_all skb_release_head_state sock_rfree sk_mem_uncharge sk_forward_alloc_add() sk_mem_reclaim // set local var reclaimable __sk_mem_reclaim sk_forward_alloc_add() In this syzkaller testcase, two threads call tcp_v6_do_rcv() with skb->truesize=768, the sk_forward_alloc changes like this: (cpu 1) | (cpu 2) | sk_forward_alloc ... | ... | 0 __sk_mem_schedule() | | +4096 = 4096 | __sk_mem_schedule() | +4096 = 8192 sk_mem_charge() | | -768 = 7424 | sk_mem_charge() | -768 = 6656 ... | ... | sk_mem_uncharge() | | +768 = 7424 reclaimable=7424 | | | sk_mem_uncharge() | +768 = 8192 | reclaimable=8192 | __sk_mem_reclaim() | | -4096 = 4096 | __sk_mem_reclaim() | -8192 = -4096 != 0 The skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() when sk->sk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock(). Fix the same issue in dccp_v6_do_rcv(). CVE-2024-53124 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: netlink: terminate outstanding dump on socket close Netlink supports iterative dumping of data. It provides the families the following ops: - start - (optional) kicks off the dumping process - dump - actual dump helper, keeps getting called until it returns 0 - done - (optional) pairs with .start, can be used for cleanup The whole process is asynchronous and the repeated calls to .dump don't actually happen in a tight loop, but rather are triggered in response to recvmsg() on the socket. This gives the user full control over the dump, but also means that the user can close the socket without getting to the end of the dump. To make sure .start is always paired with .done we check if there is an ongoing dump before freeing the socket, and if so call .done. The complication is that sockets can get freed from BH and .done is allowed to sleep. So we use a workqueue to defer the call, when needed. Unfortunately this does not work correctly. What we defer is not the cleanup but rather releasing a reference on the socket. We have no guarantee that we own the last reference, if someone else holds the socket they may release it in BH and we're back to square one. The whole dance, however, appears to be unnecessary. Only the user can interact with dumps, so we can clean up when socket is closed. And close always happens in process context. Some async code may still access the socket after close, queue notification skbs to it etc. but no dumps can start, end or otherwise make progress. Delete the workqueue and flush the dump state directly from the release handler. Note that further cleanup is possible in -next, for instance we now always call .done before releasing the main module reference, so dump doesn't have to take a reference of its own. CVE-2024-53140 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: sunrpc: fix one UAF issue caused by sunrpc kernel tcp socket BUG: KASAN: slab-use-after-free in tcp_write_timer_handler+0x156/0x3e0 Read of size 1 at addr ffff888111f322cd by task swapper/0/0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc4-dirty #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 Call Trace: <IRQ> dump_stack_lvl+0x68/0xa0 print_address_description.constprop.0+0x2c/0x3d0 print_report+0xb4/0x270 kasan_report+0xbd/0xf0 tcp_write_timer_handler+0x156/0x3e0 tcp_write_timer+0x66/0x170 call_timer_fn+0xfb/0x1d0 __run_timers+0x3f8/0x480 run_timer_softirq+0x9b/0x100 handle_softirqs+0x153/0x390 __irq_exit_rcu+0x103/0x120 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x76/0x90 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1a/0x20 RIP: 0010:default_idle+0xf/0x20 Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 <fa> c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242 RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff9f00590f RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed102360835d R10: ffff88811b041aeb R11: 0000000000000001 R12: 0000000000000000 R13: ffffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0 default_idle_call+0x6b/0xa0 cpuidle_idle_call+0x1af/0x1f0 do_idle+0xbc/0x130 cpu_startup_entry+0x33/0x40 rest_init+0x11f/0x210 start_kernel+0x39a/0x420 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0x97/0xa0 common_startup_64+0x13e/0x141 </TASK> Allocated by task 595: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x87/0x90 kmem_cache_alloc_noprof+0x12b/0x3f0 copy_net_ns+0x94/0x380 create_new_namespaces+0x24c/0x500 unshare_nsproxy_namespaces+0x75/0xf0 ksys_unshare+0x24e/0x4f0 __x64_sys_unshare+0x1f/0x30 do_syscall_64+0x70/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 100: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x54/0x70 kmem_cache_free+0x156/0x5d0 cleanup_net+0x5d3/0x670 process_one_work+0x776/0xa90 worker_thread+0x2e2/0x560 kthread+0x1a8/0x1f0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30 Reproduction script: mkdir -p /mnt/nfsshare mkdir -p /mnt/nfs/netns_1 mkfs.ext4 /dev/sdb mount /dev/sdb /mnt/nfsshare systemctl restart nfs-server chmod 777 /mnt/nfsshare exportfs -i -o rw,no_root_squash *:/mnt/nfsshare ip netns add netns_1 ip link add name veth_1_peer type veth peer veth_1 ifconfig veth_1_peer 11.11.0.254 up ip link set veth_1 netns netns_1 ip netns exec netns_1 ifconfig veth_1 11.11.0.1 ip netns exec netns_1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp \ --tcp-flags FIN FIN -j DROP (note: In my environment, a DESTROY_CLIENTID operation is always sent immediately, breaking the nfs tcp connection.) ip netns exec netns_1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 \ 11.11.0.254:/mnt/nfsshare /mnt/nfs/netns_1 ip netns del netns_1 The reason here is that the tcp socket in netns_1 (nfs side) has been shutdown and closed (done in xs_destroy), but the FIN message (with ack) is discarded, and the nfsd side keeps sending retransmission messages. As a result, when the tcp sock in netns_1 processes the received message, it sends the message (FIN message) in the sending queue, and the tcp timer is re-established. When the network namespace is deleted, the net structure accessed by tcp's timer handler function causes problems. To fix this problem, let's hold netns refcnt for the tcp kernel socket as done in other modules. This is an ugly hack which can easily be backported to earlier kernels. A proper fix which cleans up the interfaces will follow, but may not be so easy to backport. CVE-2024-53168 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 important In the Linux kernel, the following vulnerability has been resolved: ipvs: fix UB due to uninitialized stack access in ip_vs_protocol_init() Under certain kernel configurations when building with Clang/LLVM, the compiler does not generate a return or jump as the terminator instruction for ip_vs_protocol_init(), triggering the following objtool warning during build time: vmlinux.o: warning: objtool: ip_vs_protocol_init() falls through to next function __initstub__kmod_ip_vs_rr__935_123_ip_vs_rr_init6() At runtime, this either causes an oops when trying to load the ipvs module or a boot-time panic if ipvs is built-in. This same issue has been reported by the Intel kernel test robot previously. Digging deeper into both LLVM and the kernel code reveals this to be a undefined behavior problem. ip_vs_protocol_init() uses a on-stack buffer of 64 chars to store the registered protocol names and leaves it uninitialized after definition. The function calls strnlen() when concatenating protocol names into the buffer. With CONFIG_FORTIFY_SOURCE strnlen() performs an extra step to check whether the last byte of the input char buffer is a null character (commit 3009f891bb9f ("fortify: Allow strlen() and strnlen() to pass compile-time known lengths")). This, together with possibly other configurations, cause the following IR to be generated: define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #5 section ".init.text" align 16 !kcfi_type !29 { %1 = alloca [64 x i8], align 16 ... 14: ; preds = %11 %15 = getelementptr inbounds i8, ptr %1, i64 63 %16 = load i8, ptr %15, align 1 %17 = tail call i1 @llvm.is.constant.i8(i8 %16) %18 = icmp eq i8 %16, 0 %19 = select i1 %17, i1 %18, i1 false br i1 %19, label %20, label %23 20: ; preds = %14 %21 = call i64 @strlen(ptr noundef nonnull dereferenceable(1) %1) #23 ... 23: ; preds = %14, %11, %20 %24 = call i64 @strnlen(ptr noundef nonnull dereferenceable(1) %1, i64 noundef 64) #24 ... } The above code calculates the address of the last char in the buffer (value %15) and then loads from it (value %16). Because the buffer is never initialized, the LLVM GVN pass marks value %16 as undefined: %13 = getelementptr inbounds i8, ptr %1, i64 63 br i1 undef, label %14, label %17 This gives later passes (SCCP, in particular) more DCE opportunities by propagating the undef value further, and eventually removes everything after the load on the uninitialized stack location: define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #0 section ".init.text" align 16 !kcfi_type !11 { %1 = alloca [64 x i8], align 16 ... 12: ; preds = %11 %13 = getelementptr inbounds i8, ptr %1, i64 63 unreachable } In this way, the generated native code will just fall through to the next function, as LLVM does not generate any code for the unreachable IR instruction and leaves the function without a terminator. Zero the on-stack buffer to avoid this possible UB. CVE-2024-53680 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: netfilter: IDLETIMER: Fix for possible ABBA deadlock Deletion of the last rule referencing a given idletimer may happen at the same time as a read of its file in sysfs: | ====================================================== | WARNING: possible circular locking dependency detected | 6.12.0-rc7-01692-g5e9a28f41134-dirty #594 Not tainted | ------------------------------------------------------ | iptables/3303 is trying to acquire lock: | ffff8881057e04b8 (kn->active#48){++++}-{0:0}, at: __kernfs_remove+0x20 | | but task is already holding lock: | ffffffffa0249068 (list_mutex){+.+.}-{3:3}, at: idletimer_tg_destroy_v] | | which lock already depends on the new lock. A simple reproducer is: | #!/bin/bash | | while true; do | iptables -A INPUT -i foo -j IDLETIMER --timeout 10 --label "testme" | iptables -D INPUT -i foo -j IDLETIMER --timeout 10 --label "testme" | done & | while true; do | cat /sys/class/xt_idletimer/timers/testme >/dev/null | done Avoid this by freeing list_mutex right after deleting the element from the list, then continuing with the teardown. CVE-2024-54683 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate xsltGetInheritedNsList in libxslt before 1.1.43 has a use-after-free issue related to exclusion of result prefixes. CVE-2024-55549 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libxslt-tools-1.1.28-17.18.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libxslt1-1.1.28-17.18.1 important In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: Fix not checking skb length on hci_acldata_packet This fixes not checking if skb really contains an ACL header otherwise the code may attempt to access some uninitilized/invalid memory past the valid skb->data. CVE-2024-56590 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: tcp_bpf: Fix the sk_mem_uncharge logic in tcp_bpf_sendmsg The current sk memory accounting logic in __SK_REDIRECT is pre-uncharging tosend bytes, which is either msg->sg.size or a smaller value apply_bytes. Potential problems with this strategy are as follows: - If the actual sent bytes are smaller than tosend, we need to charge some bytes back, as in line 487, which is okay but seems not clean. - When tosend is set to apply_bytes, as in line 417, and (ret < 0), we may miss uncharging (msg->sg.size - apply_bytes) bytes. [...] 415 tosend = msg->sg.size; 416 if (psock->apply_bytes && psock->apply_bytes < tosend) 417 tosend = psock->apply_bytes; [...] 443 sk_msg_return(sk, msg, tosend); 444 release_sock(sk); 446 origsize = msg->sg.size; 447 ret = tcp_bpf_sendmsg_redir(sk_redir, redir_ingress, 448 msg, tosend, flags); 449 sent = origsize - msg->sg.size; [...] 454 lock_sock(sk); 455 if (unlikely(ret < 0)) { 456 int free = sk_msg_free_nocharge(sk, msg); 458 if (!cork) 459 *copied -= free; 460 } [...] 487 if (eval == __SK_REDIRECT) 488 sk_mem_charge(sk, tosend - sent); [...] When running the selftest test_txmsg_redir_wait_sndmem with txmsg_apply, the following warning will be reported: ------------[ cut here ]------------ WARNING: CPU: 6 PID: 57 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x190/0x1a0 Modules linked in: CPU: 6 UID: 0 PID: 57 Comm: kworker/6:0 Not tainted 6.12.0-rc1.bm.1-amd64+ #43 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Workqueue: events sk_psock_destroy RIP: 0010:inet_sock_destruct+0x190/0x1a0 RSP: 0018:ffffad0a8021fe08 EFLAGS: 00010206 RAX: 0000000000000011 RBX: ffff9aab4475b900 RCX: ffff9aab481a0800 RDX: 0000000000000303 RSI: 0000000000000011 RDI: ffff9aab4475b900 RBP: ffff9aab4475b990 R08: 0000000000000000 R09: ffff9aab40050ec0 R10: 0000000000000000 R11: ffff9aae6fdb1d01 R12: ffff9aab49c60400 R13: ffff9aab49c60598 R14: ffff9aab49c60598 R15: dead000000000100 FS: 0000000000000000(0000) GS:ffff9aae6fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffec7e47bd8 CR3: 00000001a1a1c004 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __warn+0x89/0x130 ? inet_sock_destruct+0x190/0x1a0 ? report_bug+0xfc/0x1e0 ? handle_bug+0x5c/0xa0 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x190/0x1a0 __sk_destruct+0x25/0x220 sk_psock_destroy+0x2b2/0x310 process_scheduled_works+0xa3/0x3e0 worker_thread+0x117/0x240 ? __pfx_worker_thread+0x10/0x10 kthread+0xcf/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> ---[ end trace 0000000000000000 ]--- In __SK_REDIRECT, a more concise way is delaying the uncharging after sent bytes are finalized, and uncharge this value. When (ret < 0), we shall invoke sk_msg_free. Same thing happens in case __SK_DROP, when tosend is set to apply_bytes, we may miss uncharging (msg->sg.size - apply_bytes) bytes. The same warning will be reported in selftest. [...] 468 case __SK_DROP: 469 default: 470 sk_msg_free_partial(sk, msg, tosend); 471 sk_msg_apply_bytes(psock, tosend); 472 *copied -= (tosend + delta); 473 return -EACCES; [...] So instead of sk_msg_free_partial we can do sk_msg_free here. CVE-2024-56633 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net/smc: fix LGR and link use-after-free issue We encountered a LGR/link use-after-free issue, which manifested as the LGR/link refcnt reaching 0 early and entering the clear process, making resource access unsafe. refcount_t: addition on 0; use-after-free. WARNING: CPU: 14 PID: 107447 at lib/refcount.c:25 refcount_warn_saturate+0x9c/0x140 Workqueue: events smc_lgr_terminate_work [smc] Call trace: refcount_warn_saturate+0x9c/0x140 __smc_lgr_terminate.part.45+0x2a8/0x370 [smc] smc_lgr_terminate_work+0x28/0x30 [smc] process_one_work+0x1b8/0x420 worker_thread+0x158/0x510 kthread+0x114/0x118 or refcount_t: underflow; use-after-free. WARNING: CPU: 6 PID: 93140 at lib/refcount.c:28 refcount_warn_saturate+0xf0/0x140 Workqueue: smc_hs_wq smc_listen_work [smc] Call trace: refcount_warn_saturate+0xf0/0x140 smcr_link_put+0x1cc/0x1d8 [smc] smc_conn_free+0x110/0x1b0 [smc] smc_conn_abort+0x50/0x60 [smc] smc_listen_find_device+0x75c/0x790 [smc] smc_listen_work+0x368/0x8a0 [smc] process_one_work+0x1b8/0x420 worker_thread+0x158/0x510 kthread+0x114/0x118 It is caused by repeated release of LGR/link refcnt. One suspect is that smc_conn_free() is called repeatedly because some smc_conn_free() from server listening path are not protected by sock lock. e.g. Calls under socklock | smc_listen_work ------------------------------------------------------- lock_sock(sk) | smc_conn_abort smc_conn_free | \- smc_conn_free \- smcr_link_put | \- smcr_link_put (duplicated) release_sock(sk) So here add sock lock protection in smc_listen_work() path, making it exclusive with other connection operations. CVE-2024-56640 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net/smc: initialize close_work early to avoid warning We encountered a warning that close_work was canceled before initialization. WARNING: CPU: 7 PID: 111103 at kernel/workqueue.c:3047 __flush_work+0x19e/0x1b0 Workqueue: events smc_lgr_terminate_work [smc] RIP: 0010:__flush_work+0x19e/0x1b0 Call Trace: ? __wake_up_common+0x7a/0x190 ? work_busy+0x80/0x80 __cancel_work_timer+0xe3/0x160 smc_close_cancel_work+0x1a/0x70 [smc] smc_close_active_abort+0x207/0x360 [smc] __smc_lgr_terminate.part.38+0xc8/0x180 [smc] process_one_work+0x19e/0x340 worker_thread+0x30/0x370 ? process_one_work+0x340/0x340 kthread+0x117/0x130 ? __kthread_cancel_work+0x50/0x50 ret_from_fork+0x22/0x30 This is because when smc_close_cancel_work is triggered, e.g. the RDMA driver is rmmod and the LGR is terminated, the conn->close_work is flushed before initialization, resulting in WARN_ON(!work->func). __smc_lgr_terminate | smc_connect_{rdma|ism} ------------------------------------------------------------- | smc_conn_create | \- smc_lgr_register_conn for conn in lgr->conns_all | \- smc_conn_kill | \- smc_close_active_abort | \- smc_close_cancel_work | \- cancel_work_sync | \- __flush_work | (close_work) | | smc_close_init | \- INIT_WORK(&close_work) So fix this by initializing close_work before establishing the connection. CVE-2024-56641 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net/sched: netem: account for backlog updates from child qdisc In general, 'qlen' of any classful qdisc should keep track of the number of packets that the qdisc itself and all of its children holds. In case of netem, 'qlen' only accounts for the packets in its internal tfifo. When netem is used with a child qdisc, the child qdisc can use 'qdisc_tree_reduce_backlog' to inform its parent, netem, about created or dropped SKBs. This function updates 'qlen' and the backlog statistics of netem, but netem does not account for changes made by a child qdisc. 'qlen' then indicates the wrong number of packets in the tfifo. If a child qdisc creates new SKBs during enqueue and informs its parent about this, netem's 'qlen' value is increased. When netem dequeues the newly created SKBs from the child, the 'qlen' in netem is not updated. If 'qlen' reaches the configured sch->limit, the enqueue function stops working, even though the tfifo is not full. Reproduce the bug: Ensure that the sender machine has GSO enabled. Configure netem as root qdisc and tbf as its child on the outgoing interface of the machine as follows: $ tc qdisc add dev <oif> root handle 1: netem delay 100ms limit 100 $ tc qdisc add dev <oif> parent 1:0 tbf rate 50Mbit burst 1542 latency 50ms Send bulk TCP traffic out via this interface, e.g., by running an iPerf3 client on the machine. Check the qdisc statistics: $ tc -s qdisc show dev <oif> Statistics after 10s of iPerf3 TCP test before the fix (note that netem's backlog > limit, netem stopped accepting packets): qdisc netem 1: root refcnt 2 limit 1000 delay 100ms Sent 2767766 bytes 1848 pkt (dropped 652, overlimits 0 requeues 0) backlog 4294528236b 1155p requeues 0 qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms Sent 2767766 bytes 1848 pkt (dropped 327, overlimits 7601 requeues 0) backlog 0b 0p requeues 0 Statistics after the fix: qdisc netem 1: root refcnt 2 limit 1000 delay 100ms Sent 37766372 bytes 24974 pkt (dropped 9, overlimits 0 requeues 0) backlog 0b 0p requeues 0 qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms Sent 37766372 bytes 24974 pkt (dropped 327, overlimits 96017 requeues 0) backlog 0b 0p requeues 0 tbf segments the GSO SKBs (tbf_segment) and updates the netem's 'qlen'. The interface fully stops transferring packets and "locks". In this case, the child qdisc and tfifo are empty, but 'qlen' indicates the tfifo is at its limit and no more packets are accepted. This patch adds a counter for the entries in the tfifo. Netem's 'qlen' is only decreased when a packet is returned by its dequeue function, and not during enqueuing into the child qdisc. External updates to 'qlen' are thus accounted for and only the behavior of the backlog statistics changes. As in other qdiscs, 'qlen' then keeps track of how many packets are held in netem and all of its children. As before, sch->limit remains as the maximum number of packets in the tfifo. The same applies to netem's backlog statistics. CVE-2024-56770 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: nfsd: fix nfs4_openowner leak when concurrent nfsd4_open occur The action force umount(umount -f) will attempt to kill all rpc_task even umount operation may ultimately fail if some files remain open. Consequently, if an action attempts to open a file, it can potentially send two rpc_task to nfs server. NFS CLIENT thread1 thread2 open("file") ... nfs4_do_open _nfs4_do_open _nfs4_open_and_get_state _nfs4_proc_open nfs4_run_open_task /* rpc_task1 */ rpc_run_task rpc_wait_for_completion_task umount -f nfs_umount_begin rpc_killall_tasks rpc_signal_task rpc_task1 been wakeup and return -512 _nfs4_do_open // while loop ... nfs4_run_open_task /* rpc_task2 */ rpc_run_task rpc_wait_for_completion_task While processing an open request, nfsd will first attempt to find or allocate an nfs4_openowner. If it finds an nfs4_openowner that is not marked as NFS4_OO_CONFIRMED, this nfs4_openowner will released. Since two rpc_task can attempt to open the same file simultaneously from the client to server, and because two instances of nfsd can run concurrently, this situation can lead to lots of memory leak. Additionally, when we echo 0 to /proc/fs/nfsd/threads, warning will be triggered. NFS SERVER nfsd1 nfsd2 echo 0 > /proc/fs/nfsd/threads nfsd4_open nfsd4_process_open1 find_or_alloc_open_stateowner // alloc oo1, stateid1 nfsd4_open nfsd4_process_open1 find_or_alloc_open_stateowner // find oo1, without NFS4_OO_CONFIRMED release_openowner unhash_openowner_locked list_del_init(&oo->oo_perclient) // cannot find this oo // from client, LEAK!!! alloc_stateowner // alloc oo2 nfsd4_process_open2 init_open_stateid // associate oo1 // with stateid1, stateid1 LEAK!!! nfs4_get_vfs_file // alloc nfsd_file1 and nfsd_file_mark1 // all LEAK!!! nfsd4_process_open2 ... write_threads ... nfsd_destroy_serv nfsd_shutdown_net nfs4_state_shutdown_net nfs4_state_destroy_net destroy_client __destroy_client // won't find oo1!!! nfsd_shutdown_generic nfsd_file_cache_shutdown kmem_cache_destroy for nfsd_file_slab and nfsd_file_mark_slab // bark since nfsd_file1 // and nfsd_file_mark1 // still alive ======================================================================= BUG nfsd_file (Not tainted): Objects remaining in nfsd_file on __kmem_cache_shutdown() ----------------------------------------------------------------------- Slab 0xffd4000004438a80 objects=34 used=1 fp=0xff11000110e2ad28 flags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff) CPU: 4 UID: 0 PID: 757 Comm: sh Not tainted 6.12.0-rc6+ #19 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: <TASK> dum ---truncated--- CVE-2024-56779 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ila: serialize calls to nf_register_net_hooks() syzbot found a race in ila_add_mapping() [1] commit 031ae72825ce ("ila: call nf_unregister_net_hooks() sooner") attempted to fix a similar issue. Looking at the syzbot repro, we have concurrent ILA_CMD_ADD commands. Add a mutex to make sure at most one thread is calling nf_register_net_hooks(). [1] BUG: KASAN: slab-use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline] BUG: KASAN: slab-use-after-free in __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604 Read of size 4 at addr ffff888028f40008 by task dhcpcd/5501 CPU: 1 UID: 0 PID: 5501 Comm: dhcpcd Not tainted 6.13.0-rc4-syzkaller-00054-gd6ef8b40d075 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <IRQ> __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+0xc3/0x620 mm/kasan/report.c:489 kasan_report+0xd9/0x110 mm/kasan/report.c:602 rht_key_hashfn include/linux/rhashtable.h:159 [inline] __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604 rhashtable_lookup include/linux/rhashtable.h:646 [inline] rhashtable_lookup_fast include/linux/rhashtable.h:672 [inline] ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:127 [inline] ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline] ila_nf_input+0x1ee/0x620 net/ipv6/ila/ila_xlat.c:185 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xbb/0x200 net/netfilter/core.c:626 nf_hook.constprop.0+0x42e/0x750 include/linux/netfilter.h:269 NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0xa4/0x680 net/ipv6/ip6_input.c:309 __netif_receive_skb_one_core+0x12e/0x1e0 net/core/dev.c:5672 __netif_receive_skb+0x1d/0x160 net/core/dev.c:5785 process_backlog+0x443/0x15f0 net/core/dev.c:6117 __napi_poll.constprop.0+0xb7/0x550 net/core/dev.c:6883 napi_poll net/core/dev.c:6952 [inline] net_rx_action+0xa94/0x1010 net/core/dev.c:7074 handle_softirqs+0x213/0x8f0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [inline] invoke_softirq kernel/softirq.c:435 [inline] __irq_exit_rcu+0x109/0x170 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvec_apic_timer_interrupt+0xa4/0xc0 arch/x86/kernel/apic/apic.c:1049 CVE-2024-57900 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: fs: relax assertions on failure to encode file handles Encoding file handles is usually performed by a filesystem >encode_fh() method that may fail for various reasons. The legacy users of exportfs_encode_fh(), namely, nfsd and name_to_handle_at(2) syscall are ready to cope with the possibility of failure to encode a file handle. There are a few other users of exportfs_encode_{fh,fid}() that currently have a WARN_ON() assertion when ->encode_fh() fails. Relax those assertions because they are wrong. The second linked bug report states commit 16aac5ad1fa9 ("ovl: support encoding non-decodable file handles") in v6.6 as the regressing commit, but this is not accurate. The aforementioned commit only increases the chances of the assertion and allows triggering the assertion with the reproducer using overlayfs, inotify and drop_caches. Triggering this assertion was always possible with other filesystems and other reasons of ->encode_fh() failures and more particularly, it was also possible with the exact same reproducer using overlayfs that is mounted with options index=on,nfs_export=on also on kernels < v6.6. Therefore, I am not listing the aforementioned commit as a Fixes commit. Backport hint: this patch will have a trivial conflict applying to v6.6.y, and other trivial conflicts applying to stable kernels < v6.6. CVE-2024-57924 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: rdma/cxgb4: Prevent potential integer overflow on 32bit The "gl->tot_len" variable is controlled by the user. It comes from process_responses(). On 32bit systems, the "gl->tot_len + sizeof(struct cpl_pass_accept_req) + sizeof(struct rss_header)" addition could have an integer wrapping bug. Use size_add() to prevent this. CVE-2024-57973 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: pps: Fix a use-after-free On a board running ntpd and gpsd, I'm seeing a consistent use-after-free in sys_exit() from gpsd when rebooting: pps pps1: removed ------------[ cut here ]------------ kobject: '(null)' (00000000db4bec24): is not initialized, yet kobject_put() is being called. WARNING: CPU: 2 PID: 440 at lib/kobject.c:734 kobject_put+0x120/0x150 CPU: 2 UID: 299 PID: 440 Comm: gpsd Not tainted 6.11.0-rc6-00308-gb31c44928842 #1 Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : kobject_put+0x120/0x150 lr : kobject_put+0x120/0x150 sp : ffffffc0803d3ae0 x29: ffffffc0803d3ae0 x28: ffffff8042dc9738 x27: 0000000000000001 x26: 0000000000000000 x25: ffffff8042dc9040 x24: ffffff8042dc9440 x23: ffffff80402a4620 x22: ffffff8042ef4bd0 x21: ffffff80405cb600 x20: 000000000008001b x19: ffffff8040b3b6e0 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 696e6920746f6e20 x14: 7369203a29343263 x13: 205d303434542020 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: kobject_put+0x120/0x150 cdev_put+0x20/0x3c __fput+0x2c4/0x2d8 ____fput+0x1c/0x38 task_work_run+0x70/0xfc do_exit+0x2a0/0x924 do_group_exit+0x34/0x90 get_signal+0x7fc/0x8c0 do_signal+0x128/0x13b4 do_notify_resume+0xdc/0x160 el0_svc+0xd4/0xf8 el0t_64_sync_handler+0x140/0x14c el0t_64_sync+0x190/0x194 ---[ end trace 0000000000000000 ]--- ...followed by more symptoms of corruption, with similar stacks: refcount_t: underflow; use-after-free. kernel BUG at lib/list_debug.c:62! Kernel panic - not syncing: Oops - BUG: Fatal exception This happens because pps_device_destruct() frees the pps_device with the embedded cdev immediately after calling cdev_del(), but, as the comment above cdev_del() notes, fops for previously opened cdevs are still callable even after cdev_del() returns. I think this bug has always been there: I can't explain why it suddenly started happening every time I reboot this particular board. In commit d953e0e837e6 ("pps: Fix a use-after free bug when unregistering a source."), George Spelvin suggested removing the embedded cdev. That seems like the simplest way to fix this, so I've implemented his suggestion, using __register_chrdev() with pps_idr becoming the source of truth for which minor corresponds to which device. But now that pps_idr defines userspace visibility instead of cdev_add(), we need to be sure the pps->dev refcount can't reach zero while userspace can still find it again. So, the idr_remove() call moves to pps_unregister_cdev(), and pps_idr now holds a reference to pps->dev. pps_core: source serial1 got cdev (251:1) <...> pps pps1: removed pps_core: unregistering pps1 pps_core: deallocating pps1 CVE-2024-57979 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Fix double free in error path If the uvc_status_init() function fails to allocate the int_urb, it will free the dev->status pointer but doesn't reset the pointer to NULL. This results in the kfree() call in uvc_status_cleanup() trying to double-free the memory. Fix it by resetting the dev->status pointer to NULL after freeing it. Reviewed by: Ricardo Ribalda <ribalda@chromium.org> CVE-2024-57980 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Fix NULL pointer dereference on certain command aborts If a command is queued to the final usable TRB of a ring segment, the enqueue pointer is advanced to the subsequent link TRB and no further. If the command is later aborted, when the abort completion is handled the dequeue pointer is advanced to the first TRB of the next segment. If no further commands are queued, xhci_handle_stopped_cmd_ring() sees the ring pointers unequal and assumes that there is a pending command, so it calls xhci_mod_cmd_timer() which crashes if cur_cmd was NULL. Don't attempt timer setup if cur_cmd is NULL. The subsequent doorbell ring likely is unnecessary too, but it's harmless. Leave it alone. This is probably Bug 219532, but no confirmation has been received. The issue has been independently reproduced and confirmed fixed using a USB MCU programmed to NAK the Status stage of SET_ADDRESS forever. Everything continued working normally after several prevented crashes. CVE-2024-57981 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net_sched: sch_sfq: don't allow 1 packet limit The current implementation does not work correctly with a limit of 1. iproute2 actually checks for this and this patch adds the check in kernel as well. This fixes the following syzkaller reported crash: UBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:210:6 index 65535 is out of range for type 'struct sfq_head[128]' CPU: 0 PID: 2569 Comm: syz-executor101 Not tainted 5.10.0-smp-DEV #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x125/0x19f lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:148 [inline] __ubsan_handle_out_of_bounds+0xed/0x120 lib/ubsan.c:347 sfq_link net/sched/sch_sfq.c:210 [inline] sfq_dec+0x528/0x600 net/sched/sch_sfq.c:238 sfq_dequeue+0x39b/0x9d0 net/sched/sch_sfq.c:500 sfq_reset+0x13/0x50 net/sched/sch_sfq.c:525 qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026 tbf_reset+0x3d/0x100 net/sched/sch_tbf.c:319 qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026 dev_reset_queue+0x8c/0x140 net/sched/sch_generic.c:1296 netdev_for_each_tx_queue include/linux/netdevice.h:2350 [inline] dev_deactivate_many+0x6dc/0xc20 net/sched/sch_generic.c:1362 __dev_close_many+0x214/0x350 net/core/dev.c:1468 dev_close_many+0x207/0x510 net/core/dev.c:1506 unregister_netdevice_many+0x40f/0x16b0 net/core/dev.c:10738 unregister_netdevice_queue+0x2be/0x310 net/core/dev.c:10695 unregister_netdevice include/linux/netdevice.h:2893 [inline] __tun_detach+0x6b6/0x1600 drivers/net/tun.c:689 tun_detach drivers/net/tun.c:705 [inline] tun_chr_close+0x104/0x1b0 drivers/net/tun.c:3640 __fput+0x203/0x840 fs/file_table.c:280 task_work_run+0x129/0x1b0 kernel/task_work.c:185 exit_task_work include/linux/task_work.h:33 [inline] do_exit+0x5ce/0x2200 kernel/exit.c:931 do_group_exit+0x144/0x310 kernel/exit.c:1046 __do_sys_exit_group kernel/exit.c:1057 [inline] __se_sys_exit_group kernel/exit.c:1055 [inline] __x64_sys_exit_group+0x3b/0x40 kernel/exit.c:1055 do_syscall_64+0x6c/0xd0 entry_SYSCALL_64_after_hwframe+0x61/0xcb RIP: 0033:0x7fe5e7b52479 Code: Unable to access opcode bytes at RIP 0x7fe5e7b5244f. RSP: 002b:00007ffd3c800398 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe5e7b52479 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000 RBP: 00007fe5e7bcd2d0 R08: ffffffffffffffb8 R09: 0000000000000014 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe5e7bcd2d0 R13: 0000000000000000 R14: 00007fe5e7bcdd20 R15: 00007fe5e7b24270 The crash can be also be reproduced with the following (with a tc recompiled to allow for sfq limits of 1): tc qdisc add dev dummy0 handle 1: root tbf rate 1Kbit burst 100b lat 1s ../iproute2-6.9.0/tc/tc qdisc add dev dummy0 handle 2: parent 1:10 sfq limit 1 ifconfig dummy0 up ping -I dummy0 -f -c2 -W0.1 8.8.8.8 sleep 1 Scenario that triggers the crash: * the first packet is sent and queued in TBF and SFQ; qdisc qlen is 1 * TBF dequeues: it peeks from SFQ which moves the packet to the gso_skb list and keeps qdisc qlen set to 1. TBF is out of tokens so it schedules itself for later. * the second packet is sent and TBF tries to queues it to SFQ. qdisc qlen is now 2 and because the SFQ limit is 1 the packet is dropped by SFQ. At this point qlen is 1, and all of the SFQ slots are empty, however q->tail is not NULL. At this point, assuming no more packets are queued, when sch_dequeue runs again it will decrement the qlen for the current empty slot causing an underflow and the subsequent out of bounds access. CVE-2024-57996 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 important In the Linux kernel, the following vulnerability has been resolved: tpm: Change to kvalloc() in eventlog/acpi.c The following failure was reported on HPE ProLiant D320: [ 10.693310][ T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0) [ 10.848132][ T1] ------------[ cut here ]------------ [ 10.853559][ T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330 [ 10.862827][ T1] Modules linked in: [ 10.866671][ T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375 [ 10.882741][ T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024 [ 10.892170][ T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330 [ 10.898103][ T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1 [ 10.917750][ T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246 [ 10.923777][ T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000 [ 10.931727][ T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0 The above transcript shows that ACPI pointed a 16 MiB buffer for the log events because RSI maps to the 'order' parameter of __alloc_pages_noprof(). Address the bug by moving from devm_kmalloc() to devm_add_action() and kvmalloc() and devm_add_action(). CVE-2024-58005 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: handle NULL sock pointer in l2cap_sock_alloc A NULL sock pointer is passed into l2cap_sock_alloc() when it is called from l2cap_sock_new_connection_cb() and the error handling paths should also be aware of it. Seemingly a more elegant solution would be to swap bt_sock_alloc() and l2cap_chan_create() calls since they are not interdependent to that moment but then l2cap_chan_create() adds the soon to be deallocated and still dummy-initialized channel to the global list accessible by many L2CAP paths. The channel would be removed from the list in short period of time but be a bit more straight-forward here and just check for NULL instead of changing the order of function calls. Found by Linux Verification Center (linuxtesting.org) with SVACE static analysis tool. CVE-2024-58009 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: brcmsmac: add gain range check to wlc_phy_iqcal_gainparams_nphy() In 'wlc_phy_iqcal_gainparams_nphy()', add gain range check to WARN() instead of possible out-of-bounds 'tbl_iqcal_gainparams_nphy' access. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. CVE-2024-58014 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 important In the Linux kernel, the following vulnerability has been resolved: printk: Fix signed integer overflow when defining LOG_BUF_LEN_MAX Shifting 1 << 31 on a 32-bit int causes signed integer overflow, which leads to undefined behavior. To prevent this, cast 1 to u32 before performing the shift, ensuring well-defined behavior. This change explicitly avoids any potential overflow by ensuring that the shift occurs on an unsigned 32-bit integer. CVE-2024-58017 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_table The function atomctrl_get_smc_sclk_range_table() does not check the return value of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to retrieve SMU_Info table, it returns NULL which is later dereferenced. Found by Linux Verification Center (linuxtesting.org) with SVACE. In practice this should never happen as this code only gets called on polaris chips and the vbios data table will always be present on those chips. CVE-2024-58052 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: fix memory leaks and invalid access at probe error path Deinitialize at reverse order when probe fails. When init_sw_vars fails, rtl_deinit_core should not be called, specially now that it destroys the rtl_wq workqueue. And call rtl_pci_deinit and deinit_sw_vars, otherwise, memory will be leaked. Remove pci_set_drvdata call as it will already be cleaned up by the core driver code and could lead to memory leaks too. cf. commit 8d450935ae7f ("wireless: rtlwifi: remove unnecessary pci_set_drvdata()") and commit 3d86b93064c7 ("rtlwifi: Fix PCI probe error path orphaned memory"). CVE-2024-58063 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: team: prevent adding a device which is already a team device lower Prevent adding a device which is already a team device lower, e.g. adding veth0 if vlan1 was already added and veth0 is a lower of vlan1. This is not useful in practice and can lead to recursive locking: $ ip link add veth0 type veth peer name veth1 $ ip link set veth0 up $ ip link set veth1 up $ ip link add link veth0 name veth0.1 type vlan protocol 802.1Q id 1 $ ip link add team0 type team $ ip link set veth0.1 down $ ip link set veth0.1 master team0 team0: Port device veth0.1 added $ ip link set veth0 down $ ip link set veth0 master team0 ============================================ WARNING: possible recursive locking detected 6.13.0-rc2-virtme-00441-ga14a429069bb #46 Not tainted -------------------------------------------- ip/7684 is trying to acquire lock: ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) but task is already holding lock: ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_add_slave (drivers/net/team/team_core.c:1147 drivers/net/team/team_core.c:1977) other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(team->team_lock_key); lock(team->team_lock_key); *** DEADLOCK *** May be due to missing lock nesting notation 2 locks held by ip/7684: stack backtrace: CPU: 3 UID: 0 PID: 7684 Comm: ip Not tainted 6.13.0-rc2-virtme-00441-ga14a429069bb #46 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:122) print_deadlock_bug.cold (kernel/locking/lockdep.c:3040) __lock_acquire (kernel/locking/lockdep.c:3893 kernel/locking/lockdep.c:5226) ? netlink_broadcast_filtered (net/netlink/af_netlink.c:1548) lock_acquire.part.0 (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? trace_lock_acquire (./include/trace/events/lock.h:24 (discriminator 2)) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? lock_acquire (kernel/locking/lockdep.c:5822) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) __mutex_lock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:735) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? fib_sync_up (net/ipv4/fib_semantics.c:2167) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) notifier_call_chain (kernel/notifier.c:85) call_netdevice_notifiers_info (net/core/dev.c:1996) __dev_notify_flags (net/core/dev.c:8993) ? __dev_change_flags (net/core/dev.c:8975) dev_change_flags (net/core/dev.c:9027) vlan_device_event (net/8021q/vlan.c:85 net/8021q/vlan.c:470) ? br_device_event (net/bridge/br.c:143) notifier_call_chain (kernel/notifier.c:85) call_netdevice_notifiers_info (net/core/dev.c:1996) dev_open (net/core/dev.c:1519 net/core/dev.c:1505) team_add_slave (drivers/net/team/team_core.c:1219 drivers/net/team/team_core.c:1977) ? __pfx_team_add_slave (drivers/net/team/team_core.c:1972) do_set_master (net/core/rtnetlink.c:2917) do_setlink.isra.0 (net/core/rtnetlink.c:3117) CVE-2024-58071 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: remove unused check_buddy_priv Commit 2461c7d60f9f ("rtlwifi: Update header file") introduced a global list of private data structures. Later on, commit 26634c4b1868 ("rtlwifi Modify existing bits to match vendor version 2013.02.07") started adding the private data to that list at probe time and added a hook, check_buddy_priv to find the private data from a similar device. However, that function was never used. Besides, though there is a lock for that list, it is never used. And when the probe fails, the private data is never removed from the list. This would cause a second probe to access freed memory. Remove the unused hook, structures and members, which will prevent the potential race condition on the list and its corruption during a second probe when probe fails. CVE-2024-58072 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: KVM: Explicitly verify target vCPU is online in kvm_get_vcpu() Explicitly verify the target vCPU is fully online _prior_ to clamping the index in kvm_get_vcpu(). If the index is "bad", the nospec clamping will generate '0', i.e. KVM will return vCPU0 instead of NULL. In practice, the bug is unlikely to cause problems, as it will only come into play if userspace or the guest is buggy or misbehaving, e.g. KVM may send interrupts to vCPU0 instead of dropping them on the floor. However, returning vCPU0 when it shouldn't exist per online_vcpus is problematic now that KVM uses an xarray for the vCPUs array, as KVM needs to insert into the xarray before publishing the vCPU to userspace (see commit c5b077549136 ("KVM: Convert the kvm->vcpus array to a xarray")), i.e. before vCPU creation is guaranteed to succeed. As a result, incorrectly providing access to vCPU0 will trigger a use-after-free if vCPU0 is dereferenced and kvm_vm_ioctl_create_vcpu() bails out of vCPU creation due to an error and frees vCPU0. Commit afb2acb2e3a3 ("KVM: Fix vcpu_array[0] races") papered over that issue, but in doing so introduced an unsolvable teardown conundrum. Preventing accesses to vCPU0 before it's fully online will allow reverting commit afb2acb2e3a3, without re-introducing the vcpu_array[0] UAF race. CVE-2024-58083 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: PCI/ASPM: Fix link state exit during switch upstream function removal Before 456d8aa37d0f ("PCI/ASPM: Disable ASPM on MFD function removal to avoid use-after-free"), we would free the ASPM link only after the last function on the bus pertaining to the given link was removed. That was too late. If function 0 is removed before sibling function, link->downstream would point to free'd memory after. After above change, we freed the ASPM parent link state upon any function removal on the bus pertaining to a given link. That is too early. If the link is to a PCIe switch with MFD on the upstream port, then removing functions other than 0 first would free a link which still remains parent_link to the remaining downstream ports. The resulting GPFs are especially frequent during hot-unplug, because pciehp removes devices on the link bus in reverse order. On that switch, function 0 is the virtual P2P bridge to the internal bus. Free exactly when function 0 is removed -- before the parent link is obsolete, but after all subordinate links are gone. [kwilczynski: commit log] CVE-2024-58093 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate A stack overflow vulnerability exists in the libexpat library due to the way it handles recursive entity expansion in XML documents. When parsing an XML document with deeply nested entity references, libexpat can be forced to recurse indefinitely, exhausting the stack space and causing a crash. This issue could lead to denial of service (DoS) or, in some cases, exploitable memory corruption, depending on the environment and library usage. CVE-2024-8176 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:expat-2.7.1-21.43.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libexpat1-2.7.1-21.43.1 important In the Linux kernel, the following vulnerability has been resolved: rds: sysctl: rds_tcp_{rcv,snd}buf: avoid using current->nsproxy As mentioned in a previous commit of this series, using the 'net' structure via 'current' is not recommended for different reasons: - Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns. - current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2). The per-netns structure can be obtained from the table->data using container_of(), then the 'net' one can be retrieved from the listen socket (if available). CVE-2025-21635 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack: clamp maximum hashtable size to INT_MAX Use INT_MAX as maximum size for the conntrack hashtable. Otherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof() when resizing hashtable because __GFP_NOWARN is unset. See: 0708a0afe291 ("mm: Consider __GFP_NOWARN flag for oversized kvmalloc() calls") Note: hashtable resize is only possible from init_netns. CVE-2025-21648 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: pfifo_tail_enqueue: Drop new packet when sch->limit == 0 Expected behaviour: In case we reach scheduler's limit, pfifo_tail_enqueue() will drop a packet in scheduler's queue and decrease scheduler's qlen by one. Then, pfifo_tail_enqueue() enqueue new packet and increase scheduler's qlen by one. Finally, pfifo_tail_enqueue() return `NET_XMIT_CN` status code. Weird behaviour: In case we set `sch->limit == 0` and trigger pfifo_tail_enqueue() on a scheduler that has no packet, the 'drop a packet' step will do nothing. This means the scheduler's qlen still has value equal 0. Then, we continue to enqueue new packet and increase scheduler's qlen by one. In summary, we can leverage pfifo_tail_enqueue() to increase qlen by one and return `NET_XMIT_CN` status code. The problem is: Let's say we have two qdiscs: Qdisc_A and Qdisc_B. - Qdisc_A's type must have '->graft()' function to create parent/child relationship. Let's say Qdisc_A's type is `hfsc`. Enqueue packet to this qdisc will trigger `hfsc_enqueue`. - Qdisc_B's type is pfifo_head_drop. Enqueue packet to this qdisc will trigger `pfifo_tail_enqueue`. - Qdisc_B is configured to have `sch->limit == 0`. - Qdisc_A is configured to route the enqueued's packet to Qdisc_B. Enqueue packet through Qdisc_A will lead to: - hfsc_enqueue(Qdisc_A) -> pfifo_tail_enqueue(Qdisc_B) - Qdisc_B->q.qlen += 1 - pfifo_tail_enqueue() return `NET_XMIT_CN` - hfsc_enqueue() check for `NET_XMIT_SUCCESS` and see `NET_XMIT_CN` => hfsc_enqueue() don't increase qlen of Qdisc_A. The whole process lead to a situation where Qdisc_A->q.qlen == 0 and Qdisc_B->q.qlen == 1. Replace 'hfsc' with other type (for example: 'drr') still lead to the same problem. This violate the design where parent's qlen should equal to the sum of its childrens'qlen. Bug impact: This issue can be used for user->kernel privilege escalation when it is reachable. CVE-2025-21702 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 important In the Linux kernel, the following vulnerability has been resolved: netem: Update sch->q.qlen before qdisc_tree_reduce_backlog() qdisc_tree_reduce_backlog() notifies parent qdisc only if child qdisc becomes empty, therefore we need to reduce the backlog of the child qdisc before calling it. Otherwise it would miss the opportunity to call cops->qlen_notify(), in the case of DRR, it resulted in UAF since DRR uses ->qlen_notify() to maintain its active list. CVE-2025-21703 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 important In the Linux kernel, the following vulnerability has been resolved: usb: cdc-acm: Check control transfer buffer size before access If the first fragment is shorter than struct usb_cdc_notification, we can't calculate an expected_size. Log an error and discard the notification instead of reading lengths from memory outside the received data, which can lead to memory corruption when the expected_size decreases between fragments, causing `expected_size - acm->nb_index` to wrap. This issue has been present since the beginning of git history; however, it only leads to memory corruption since commit ea2583529cd1 ("cdc-acm: reassemble fragmented notifications"). A mitigating factor is that acm_ctrl_irq() can only execute after userspace has opened /dev/ttyACM*; but if ModemManager is running, ModemManager will do that automatically depending on the USB device's vendor/product IDs and its other interfaces. CVE-2025-21704 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: usb: rtl8150: enable basic endpoint checking Syzkaller reports [1] encountering a common issue of utilizing a wrong usb endpoint type during URB submitting stage. This, in turn, triggers a warning shown below. For now, enable simple endpoint checking (specifically, bulk and interrupt eps, testing control one is not essential) to mitigate the issue with a view to do other related cosmetic changes later, if they are necessary. [1] Syzkaller report: usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 1 PID: 2586 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 driv> Modules linked in: CPU: 1 UID: 0 PID: 2586 Comm: dhcpcd Not tainted 6.11.0-rc4-syzkaller-00069-gfc88bb11617> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503 Code: 84 3c 02 00 00 e8 05 e4 fc fc 4c 89 ef e8 fd 25 d7 fe 45 89 e0 89 e9 4c 89 f2 48 8> RSP: 0018:ffffc9000441f740 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff888112487a00 RCX: ffffffff811a99a9 RDX: ffff88810df6ba80 RSI: ffffffff811a99b6 RDI: 0000000000000001 RBP: 0000000000000003 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001 R13: ffff8881023bf0a8 R14: ffff888112452a20 R15: ffff888112487a7c FS: 00007fc04eea5740(0000) GS:ffff8881f6300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f0a1de9f870 CR3: 000000010dbd0000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> rtl8150_open+0x300/0xe30 drivers/net/usb/rtl8150.c:733 __dev_open+0x2d4/0x4e0 net/core/dev.c:1474 __dev_change_flags+0x561/0x720 net/core/dev.c:8838 dev_change_flags+0x8f/0x160 net/core/dev.c:8910 devinet_ioctl+0x127a/0x1f10 net/ipv4/devinet.c:1177 inet_ioctl+0x3aa/0x3f0 net/ipv4/af_inet.c:1003 sock_do_ioctl+0x116/0x280 net/socket.c:1222 sock_ioctl+0x22e/0x6c0 net/socket.c:1341 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+0x193/0x220 fs/ioctl.c:893 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:0x7fc04ef73d49 ... This change has not been tested on real hardware. CVE-2025-21708 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: NFC: nci: Add bounds checking in nci_hci_create_pipe() The "pipe" variable is a u8 which comes from the network. If it's more than 127, then it results in memory corruption in the caller, nci_hci_connect_gate(). CVE-2025-21735 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix NULL pointer dereference in brcmf_txfinalize() On removal of the device or unloading of the kernel module a potential NULL pointer dereference occurs. The following sequence deletes the interface: brcmf_detach() brcmf_remove_interface() brcmf_del_if() Inside the brcmf_del_if() function the drvr->if2bss[ifidx] is updated to BRCMF_BSSIDX_INVALID (-1) if the bsscfgidx matches. After brcmf_remove_interface() call the brcmf_proto_detach() function is called providing the following sequence: brcmf_detach() brcmf_proto_detach() brcmf_proto_msgbuf_detach() brcmf_flowring_detach() brcmf_msgbuf_delete_flowring() brcmf_msgbuf_remove_flowring() brcmf_flowring_delete() brcmf_get_ifp() brcmf_txfinalize() Since brcmf_get_ip() can and actually will return NULL in this case the call to brcmf_txfinalize() will result in a NULL pointer dereference inside brcmf_txfinalize() when trying to update ifp->ndev->stats.tx_errors. This will only happen if a flowring still has an skb. Although the NULL pointer dereference has only been seen when trying to update the tx statistic, all other uses of the ifp pointer have been guarded as well with an early return if ifp is NULL. CVE-2025-21744 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Check the return value of of_property_read_string_index() Somewhen between 6.10 and 6.11 the driver started to crash on my MacBookPro14,3. The property doesn't exist and 'tmp' remains uninitialized, so we pass a random pointer to devm_kstrdup(). The crash I am getting looks like this: BUG: unable to handle page fault for address: 00007f033c669379 PF: supervisor read access in kernel mode PF: error_code(0x0001) - permissions violation PGD 8000000101341067 P4D 8000000101341067 PUD 101340067 PMD 1013bb067 PTE 800000010aee9025 Oops: Oops: 0001 [#1] SMP PTI CPU: 4 UID: 0 PID: 827 Comm: (udev-worker) Not tainted 6.11.8-gentoo #1 Hardware name: Apple Inc. MacBookPro14,3/Mac-551B86E5744E2388, BIOS 529.140.2.0.0 06/23/2024 RIP: 0010:strlen+0x4/0x30 Code: f7 75 ec 31 c0 c3 cc cc cc cc 48 89 f8 c3 cc cc cc cc 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa <80> 3f 00 74 14 48 89 f8 48 83 c0 01 80 38 00 75 f7 48 29 f8 c3 cc RSP: 0018:ffffb4aac0683ad8 EFLAGS: 00010202 RAX: 00000000ffffffea RBX: 00007f033c669379 RCX: 0000000000000001 RDX: 0000000000000cc0 RSI: 00007f033c669379 RDI: 00007f033c669379 RBP: 00000000ffffffea R08: 0000000000000000 R09: 00000000c0ba916a R10: ffffffffffffffff R11: ffffffffb61ea260 R12: ffff91f7815b50c8 R13: 0000000000000cc0 R14: ffff91fafefffe30 R15: ffffb4aac0683b30 FS: 00007f033ccbe8c0(0000) GS:ffff91faeed00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f033c669379 CR3: 0000000107b1e004 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? __die+0x23/0x70 ? page_fault_oops+0x149/0x4c0 ? raw_spin_rq_lock_nested+0xe/0x20 ? sched_balance_newidle+0x22b/0x3c0 ? update_load_avg+0x78/0x770 ? exc_page_fault+0x6f/0x150 ? asm_exc_page_fault+0x26/0x30 ? __pfx_pci_conf1_write+0x10/0x10 ? strlen+0x4/0x30 devm_kstrdup+0x25/0x70 brcmf_of_probe+0x273/0x350 [brcmfmac] CVE-2025-21750 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: add RCU protection to mld_newpack() mld_newpack() can be called without RTNL or RCU being held. Note that we no longer can use sock_alloc_send_skb() because ipv6.igmp_sk uses GFP_KERNEL allocations which can sleep. Instead use alloc_skb() and charge the net->ipv6.igmp_sk socket under RCU protection. CVE-2025-21758 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: extend RCU protection in igmp6_send() igmp6_send() can be called without RTNL or RCU being held. Extend RCU protection so that we can safely fetch the net pointer and avoid a potential UAF. Note that we no longer can use sock_alloc_send_skb() because ipv6.igmp_sk uses GFP_KERNEL allocations which can sleep. Instead use alloc_skb() and charge the net->ipv6.igmp_sk socket under RCU protection. CVE-2025-21759 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ndisc: extend RCU protection in ndisc_send_skb() ndisc_send_skb() can be called without RTNL or RCU held. Acquire rcu_read_lock() earlier, so that we can use dev_net_rcu() and avoid a potential UAF. CVE-2025-21760 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: arp: use RCU protection in arp_xmit() arp_xmit() can be called without RTNL or RCU protection. Use RCU protection to avoid potential UAF. CVE-2025-21762 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: neighbour: use RCU protection in __neigh_notify() __neigh_notify() can be called without RTNL or RCU protection. Use RCU protection to avoid potential UAF. CVE-2025-21763 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ndisc: use RCU protection in ndisc_alloc_skb() ndisc_alloc_skb() can be called without RTNL or RCU being held. Add RCU protection to avoid possible UAF. CVE-2025-21764 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ipv6: use RCU protection in ip6_default_advmss() ip6_default_advmss() needs rcu protection to make sure the net structure it reads does not disappear. CVE-2025-21765 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ipv4: use RCU protection in __ip_rt_update_pmtu() __ip_rt_update_pmtu() must use RCU protection to make sure the net structure it reads does not disappear. CVE-2025-21766 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: ipv6: fix dst ref loops in rpl, seg6 and ioam6 lwtunnels Some lwtunnels have a dst cache for post-transformation dst. If the packet destination did not change we may end up recording a reference to the lwtunnel in its own cache, and the lwtunnel state will never be freed. Discovered by the ioam6.sh test, kmemleak was recently fixed to catch per-cpu memory leaks. I'm not sure if rpl and seg6 can actually hit this, but in principle I don't see why not. CVE-2025-21768 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: partitions: mac: fix handling of bogus partition table Fix several issues in partition probing: - The bailout for a bad partoffset must use put_dev_sector(), since the preceding read_part_sector() succeeded. - If the partition table claims a silly sector size like 0xfff bytes (which results in partition table entries straddling sector boundaries), bail out instead of accessing out-of-bounds memory. - We must not assume that the partition table contains proper NUL termination - use strnlen() and strncmp() instead of strlen() and strcmp(). CVE-2025-21772 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 important In the Linux kernel, the following vulnerability has been resolved: USB: hub: Ignore non-compliant devices with too many configs or interfaces Robert Morris created a test program which can cause usb_hub_to_struct_hub() to dereference a NULL or inappropriate pointer: Oops: general protection fault, probably for non-canonical address 0xcccccccccccccccc: 0000 [#1] SMP DEBUG_PAGEALLOC PTI CPU: 7 UID: 0 PID: 117 Comm: kworker/7:1 Not tainted 6.13.0-rc3-00017-gf44d154d6e3d #14 Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021 Workqueue: usb_hub_wq hub_event RIP: 0010:usb_hub_adjust_deviceremovable+0x78/0x110 ... Call Trace: <TASK> ? die_addr+0x31/0x80 ? exc_general_protection+0x1b4/0x3c0 ? asm_exc_general_protection+0x26/0x30 ? usb_hub_adjust_deviceremovable+0x78/0x110 hub_probe+0x7c7/0xab0 usb_probe_interface+0x14b/0x350 really_probe+0xd0/0x2d0 ? __pfx___device_attach_driver+0x10/0x10 __driver_probe_device+0x6e/0x110 driver_probe_device+0x1a/0x90 __device_attach_driver+0x7e/0xc0 bus_for_each_drv+0x7f/0xd0 __device_attach+0xaa/0x1a0 bus_probe_device+0x8b/0xa0 device_add+0x62e/0x810 usb_set_configuration+0x65d/0x990 usb_generic_driver_probe+0x4b/0x70 usb_probe_device+0x36/0xd0 The cause of this error is that the device has two interfaces, and the hub driver binds to interface 1 instead of interface 0, which is where usb_hub_to_struct_hub() looks. We can prevent the problem from occurring by refusing to accept hub devices that violate the USB spec by having more than one configuration or interface. CVE-2025-21776 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Reject Hyper-V's SEND_IPI hypercalls if local APIC isn't in-kernel Advertise support for Hyper-V's SEND_IPI and SEND_IPI_EX hypercalls if and only if the local API is emulated/virtualized by KVM, and explicitly reject said hypercalls if the local APIC is emulated in userspace, i.e. don't rely on userspace to opt-in to KVM_CAP_HYPERV_ENFORCE_CPUID. Rejecting SEND_IPI and SEND_IPI_EX fixes a NULL-pointer dereference if Hyper-V enlightenments are exposed to the guest without an in-kernel local APIC: dump_stack+0xbe/0xfd __kasan_report.cold+0x34/0x84 kasan_report+0x3a/0x50 __apic_accept_irq+0x3a/0x5c0 kvm_hv_send_ipi.isra.0+0x34e/0x820 kvm_hv_hypercall+0x8d9/0x9d0 kvm_emulate_hypercall+0x506/0x7e0 __vmx_handle_exit+0x283/0xb60 vmx_handle_exit+0x1d/0xd0 vcpu_enter_guest+0x16b0/0x24c0 vcpu_run+0xc0/0x550 kvm_arch_vcpu_ioctl_run+0x170/0x6d0 kvm_vcpu_ioctl+0x413/0xb20 __se_sys_ioctl+0x111/0x160 do_syscal1_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Note, checking the sending vCPU is sufficient, as the per-VM irqchip_mode can't be modified after vCPUs are created, i.e. if one vCPU has an in-kernel local APIC, then all vCPUs have an in-kernel local APIC. CVE-2025-21779 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: orangefs: fix a oob in orangefs_debug_write I got a syzbot report: slab-out-of-bounds Read in orangefs_debug_write... several people suggested fixes, I tested Al Viro's suggestion and made this patch. CVE-2025-21782 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array The loop that detects/populates cache information already has a bounds check on the array size but does not account for cache levels with separate data/instructions cache. Fix this by incrementing the index for any populated leaf (instead of any populated level). CVE-2025-21785 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 important In the Linux kernel, the following vulnerability has been resolved: team: better TEAM_OPTION_TYPE_STRING validation syzbot reported following splat [1] Make sure user-provided data contains one nul byte. [1] BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:633 [inline] BUG: KMSAN: uninit-value in string+0x3ec/0x5f0 lib/vsprintf.c:714 string_nocheck lib/vsprintf.c:633 [inline] string+0x3ec/0x5f0 lib/vsprintf.c:714 vsnprintf+0xa5d/0x1960 lib/vsprintf.c:2843 __request_module+0x252/0x9f0 kernel/module/kmod.c:149 team_mode_get drivers/net/team/team_core.c:480 [inline] team_change_mode drivers/net/team/team_core.c:607 [inline] team_mode_option_set+0x437/0x970 drivers/net/team/team_core.c:1401 team_option_set drivers/net/team/team_core.c:375 [inline] team_nl_options_set_doit+0x1339/0x1f90 drivers/net/team/team_core.c:2662 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x1214/0x12c0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2543 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0xf52/0x1260 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x10da/0x11e0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:733 ____sys_sendmsg+0x877/0xb60 net/socket.c:2573 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2627 __sys_sendmsg net/socket.c:2659 [inline] __do_sys_sendmsg net/socket.c:2664 [inline] __se_sys_sendmsg net/socket.c:2662 [inline] __x64_sys_sendmsg+0x212/0x3c0 net/socket.c:2662 x64_sys_call+0x2ed6/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f CVE-2025-21787 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: vrf: use RCU protection in l3mdev_l3_out() l3mdev_l3_out() can be called without RCU being held: raw_sendmsg() ip_push_pending_frames() ip_send_skb() ip_local_out() __ip_local_out() l3mdev_ip_out() Add rcu_read_lock() / rcu_read_unlock() pair to avoid a potential UAF. CVE-2025-21791 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 important In the Linux kernel, the following vulnerability has been resolved: nfsd: clear acl_access/acl_default after releasing them If getting acl_default fails, acl_access and acl_default will be released simultaneously. However, acl_access will still retain a pointer pointing to the released posix_acl, which will trigger a WARNING in nfs3svc_release_getacl like this: ------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 26 PID: 3199 at lib/refcount.c:28 refcount_warn_saturate+0xb5/0x170 Modules linked in: CPU: 26 UID: 0 PID: 3199 Comm: nfsd Not tainted 6.12.0-rc6-00079-g04ae226af01f-dirty #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:refcount_warn_saturate+0xb5/0x170 Code: cc cc 0f b6 1d b3 20 a5 03 80 fb 01 0f 87 65 48 d8 00 83 e3 01 75 e4 48 c7 c7 c0 3b 9b 85 c6 05 97 20 a5 03 01 e8 fb 3e 30 ff <0f> 0b eb cd 0f b6 1d 8a3 RSP: 0018:ffffc90008637cd8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83904fde RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88871ed36380 RBP: ffff888158beeb40 R08: 0000000000000001 R09: fffff520010c6f56 R10: ffffc90008637ab7 R11: 0000000000000001 R12: 0000000000000001 R13: ffff888140e77400 R14: ffff888140e77408 R15: ffffffff858b42c0 FS: 0000000000000000(0000) GS:ffff88871ed00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000562384d32158 CR3: 000000055cc6a000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? refcount_warn_saturate+0xb5/0x170 ? __warn+0xa5/0x140 ? refcount_warn_saturate+0xb5/0x170 ? report_bug+0x1b1/0x1e0 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x17/0x40 ? asm_exc_invalid_op+0x1a/0x20 ? tick_nohz_tick_stopped+0x1e/0x40 ? refcount_warn_saturate+0xb5/0x170 ? refcount_warn_saturate+0xb5/0x170 nfs3svc_release_getacl+0xc9/0xe0 svc_process_common+0x5db/0xb60 ? __pfx_svc_process_common+0x10/0x10 ? __rcu_read_unlock+0x69/0xa0 ? __pfx_nfsd_dispatch+0x10/0x10 ? svc_xprt_received+0xa1/0x120 ? xdr_init_decode+0x11d/0x190 svc_process+0x2a7/0x330 svc_handle_xprt+0x69d/0x940 svc_recv+0x180/0x2d0 nfsd+0x168/0x200 ? __pfx_nfsd+0x10/0x10 kthread+0x1a2/0x1e0 ? kthread+0xf4/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Kernel panic - not syncing: kernel: panic_on_warn set ... Clear acl_access/acl_default after posix_acl_release is called to prevent UAF from being triggered. CVE-2025-21796 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix oops when unload drivers paralleling When unload hclge driver, it tries to disable sriov first for each ae_dev node from hnae3_ae_dev_list. If user unloads hns3 driver at the time, because it removes all the ae_dev nodes, and it may cause oops. But we can't simply use hnae3_common_lock for this. Because in the process flow of pci_disable_sriov(), it will trigger the remove flow of VF, which will also take hnae3_common_lock. To fixes it, introduce a new mutex to protect the unload process. CVE-2025-21802 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: let net.core.dev_weight always be non-zero The following problem was encountered during stability test: (NULL net_device): NAPI poll function process_backlog+0x0/0x530 \ returned 1, exceeding its budget of 0. ------------[ cut here ]------------ list_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, \ next=ffff88905f746e40. WARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 \ __list_add_valid_or_report+0xf3/0x130 CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+ RIP: 0010:__list_add_valid_or_report+0xf3/0x130 Call Trace: ? __warn+0xcd/0x250 ? __list_add_valid_or_report+0xf3/0x130 enqueue_to_backlog+0x923/0x1070 netif_rx_internal+0x92/0x2b0 __netif_rx+0x15/0x170 loopback_xmit+0x2ef/0x450 dev_hard_start_xmit+0x103/0x490 __dev_queue_xmit+0xeac/0x1950 ip_finish_output2+0x6cc/0x1620 ip_output+0x161/0x270 ip_push_pending_frames+0x155/0x1a0 raw_sendmsg+0xe13/0x1550 __sys_sendto+0x3bf/0x4e0 __x64_sys_sendto+0xdc/0x1b0 do_syscall_64+0x5b/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The reproduction command is as follows: sysctl -w net.core.dev_weight=0 ping 127.0.0.1 This is because when the napi's weight is set to 0, process_backlog() may return 0 and clear the NAPI_STATE_SCHED bit of napi->state, causing this napi to be re-polled in net_rx_action() until __do_softirq() times out. Since the NAPI_STATE_SCHED bit has been cleared, napi_schedule_rps() can be retriggered in enqueue_to_backlog(), causing this issue. Making the napi's weight always non-zero solves this problem. Triggering this issue requires system-wide admin (setting is not namespaced). CVE-2025-21806 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ptp: Ensure info->enable callback is always set The ioctl and sysfs handlers unconditionally call the ->enable callback. Not all drivers implement that callback, leading to NULL dereferences. Example of affected drivers: ptp_s390.c, ptp_vclock.c and ptp_mock.c. Instead use a dummy callback if no better was specified by the driver. CVE-2025-21814 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: fbdev: omap: use threaded IRQ for LCD DMA When using touchscreen and framebuffer, Nokia 770 crashes easily with: BUG: scheduling while atomic: irq/144-ads7846/82/0x00010000 Modules linked in: usb_f_ecm g_ether usb_f_rndis u_ether libcomposite configfs omap_udc ohci_omap ohci_hcd CPU: 0 UID: 0 PID: 82 Comm: irq/144-ads7846 Not tainted 6.12.7-770 #2 Hardware name: Nokia 770 Call trace: unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x54/0x5c dump_stack_lvl from __schedule_bug+0x50/0x70 __schedule_bug from __schedule+0x4d4/0x5bc __schedule from schedule+0x34/0xa0 schedule from schedule_preempt_disabled+0xc/0x10 schedule_preempt_disabled from __mutex_lock.constprop.0+0x218/0x3b4 __mutex_lock.constprop.0 from clk_prepare_lock+0x38/0xe4 clk_prepare_lock from clk_set_rate+0x18/0x154 clk_set_rate from sossi_read_data+0x4c/0x168 sossi_read_data from hwa742_read_reg+0x5c/0x8c hwa742_read_reg from send_frame_handler+0xfc/0x300 send_frame_handler from process_pending_requests+0x74/0xd0 process_pending_requests from lcd_dma_irq_handler+0x50/0x74 lcd_dma_irq_handler from __handle_irq_event_percpu+0x44/0x130 __handle_irq_event_percpu from handle_irq_event+0x28/0x68 handle_irq_event from handle_level_irq+0x9c/0x170 handle_level_irq from generic_handle_domain_irq+0x2c/0x3c generic_handle_domain_irq from omap1_handle_irq+0x40/0x8c omap1_handle_irq from generic_handle_arch_irq+0x28/0x3c generic_handle_arch_irq from call_with_stack+0x1c/0x24 call_with_stack from __irq_svc+0x94/0xa8 Exception stack(0xc5255da0 to 0xc5255de8) 5da0: 00000001 c22fc620 00000000 00000000 c08384a8 c106fc00 00000000 c240c248 5dc0: c113a600 c3f6ec30 00000001 00000000 c22fc620 c5255df0 c22fc620 c0279a94 5de0: 60000013 ffffffff __irq_svc from clk_prepare_lock+0x4c/0xe4 clk_prepare_lock from clk_get_rate+0x10/0x74 clk_get_rate from uwire_setup_transfer+0x40/0x180 uwire_setup_transfer from spi_bitbang_transfer_one+0x2c/0x9c spi_bitbang_transfer_one from spi_transfer_one_message+0x2d0/0x664 spi_transfer_one_message from __spi_pump_transfer_message+0x29c/0x498 __spi_pump_transfer_message from __spi_sync+0x1f8/0x2e8 __spi_sync from spi_sync+0x24/0x40 spi_sync from ads7846_halfd_read_state+0x5c/0x1c0 ads7846_halfd_read_state from ads7846_irq+0x58/0x348 ads7846_irq from irq_thread_fn+0x1c/0x78 irq_thread_fn from irq_thread+0x120/0x228 irq_thread from kthread+0xc8/0xe8 kthread from ret_from_fork+0x14/0x28 As a quick fix, switch to a threaded IRQ which provides a stable system. CVE-2025-21821 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: PCI: Avoid putting some root ports into D3 on TUXEDO Sirius Gen1 commit 9d26d3a8f1b0 ("PCI: Put PCIe ports into D3 during suspend") sets the policy that all PCIe ports are allowed to use D3. When the system is suspended if the port is not power manageable by the platform and won't be used for wakeup via a PME this sets up the policy for these ports to go into D3hot. This policy generally makes sense from an OSPM perspective but it leads to problems with wakeup from suspend on the TUXEDO Sirius 16 Gen 1 with a specific old BIOS. This manifests as a system hang. On the affected Device + BIOS combination, add a quirk for the root port of the problematic controller to ensure that these root ports are not put into D3hot at suspend. This patch is based on https://lore.kernel.org/linux-pci/20230708214457.1229-2-mario.limonciello@amd.com but with the added condition both in the documentation and in the code to apply only to the TUXEDO Sirius 16 Gen 1 with a specific old BIOS and only the affected root ports. CVE-2025-21831 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: acct: perform last write from workqueue In [1] it was reported that the acct(2) system call can be used to trigger NULL deref in cases where it is set to write to a file that triggers an internal lookup. This can e.g., happen when pointing acc(2) to /sys/power/resume. At the point the where the write to this file happens the calling task has already exited and called exit_fs(). A lookup will thus trigger a NULL-deref when accessing current->fs. Reorganize the code so that the the final write happens from the workqueue but with the caller's credentials. This preserves the (strange) permission model and has almost no regression risk. This api should stop to exist though. CVE-2025-21846 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: nfp: bpf: Add check for nfp_app_ctrl_msg_alloc() Add check for the return value of nfp_app_ctrl_msg_alloc() in nfp_bpf_cmsg_alloc() to prevent null pointer dereference. CVE-2025-21848 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: geneve: Fix use-after-free in geneve_find_dev(). syzkaller reported a use-after-free in geneve_find_dev() [0] without repro. geneve_configure() links struct geneve_dev.next to net_generic(net, geneve_net_id)->geneve_list. The net here could differ from dev_net(dev) if IFLA_NET_NS_PID, IFLA_NET_NS_FD, or IFLA_TARGET_NETNSID is set. When dev_net(dev) is dismantled, geneve_exit_batch_rtnl() finally calls unregister_netdevice_queue() for each dev in the netns, and later the dev is freed. However, its geneve_dev.next is still linked to the backend UDP socket netns. Then, use-after-free will occur when another geneve dev is created in the netns. Let's call geneve_dellink() instead in geneve_destroy_tunnels(). [0]: BUG: KASAN: slab-use-after-free in geneve_find_dev drivers/net/geneve.c:1295 [inline] BUG: KASAN: slab-use-after-free in geneve_configure+0x234/0x858 drivers/net/geneve.c:1343 Read of size 2 at addr ffff000054d6ee24 by task syz.1.4029/13441 CPU: 1 UID: 0 PID: 13441 Comm: syz.1.4029 Not tainted 6.13.0-g0ad9617c78ac #24 dc35ca22c79fb82e8e7bc5c9c9adafea898b1e3d Hardware name: linux,dummy-virt (DT) Call trace: show_stack+0x38/0x50 arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xbc/0x108 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x16c/0x6f0 mm/kasan/report.c:489 kasan_report+0xc0/0x120 mm/kasan/report.c:602 __asan_report_load2_noabort+0x20/0x30 mm/kasan/report_generic.c:379 geneve_find_dev drivers/net/geneve.c:1295 [inline] geneve_configure+0x234/0x858 drivers/net/geneve.c:1343 geneve_newlink+0xb8/0x128 drivers/net/geneve.c:1634 rtnl_newlink_create+0x23c/0x868 net/core/rtnetlink.c:3795 __rtnl_newlink net/core/rtnetlink.c:3906 [inline] rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x618/0x838 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x5fc/0x8b0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:713 [inline] __sock_sendmsg net/socket.c:728 [inline] ____sys_sendmsg+0x410/0x6f8 net/socket.c:2568 ___sys_sendmsg+0x178/0x1d8 net/socket.c:2622 __sys_sendmsg net/socket.c:2654 [inline] __do_sys_sendmsg net/socket.c:2659 [inline] __se_sys_sendmsg net/socket.c:2657 [inline] __arm64_sys_sendmsg+0x12c/0x1c8 net/socket.c:2657 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x90/0x278 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x13c/0x250 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x54/0x70 arch/arm64/kernel/syscall.c:151 el0_svc+0x4c/0xa8 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x1a0 arch/arm64/kernel/entry.S:600 Allocated by task 13247: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x68 mm/kasan/common.c:68 kasan_save_alloc_info+0x44/0x58 mm/kasan/generic.c:568 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x84/0xa0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4298 [inline] __kmalloc_node_noprof+0x2a0/0x560 mm/slub.c:4304 __kvmalloc_node_noprof+0x9c/0x230 mm/util.c:645 alloc_netdev_mqs+0xb8/0x11a0 net/core/dev.c:11470 rtnl_create_link+0x2b8/0xb50 net/core/rtnetlink.c:3604 rtnl_newlink_create+0x19c/0x868 net/core/rtnetlink.c:3780 __rtnl_newlink net/core/rtnetlink.c:3906 [inline] rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938 netlink_unicast_kernel net/netlink/af_n ---truncated--- CVE-2025-21858 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: drop_monitor: fix incorrect initialization order Syzkaller reports the following bug: BUG: spinlock bad magic on CPU#1, syz-executor.0/7995 lock: 0xffff88805303f3e0, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0 CPU: 1 PID: 7995 Comm: syz-executor.0 Tainted: G E 5.10.209+ #1 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x119/0x179 lib/dump_stack.c:118 debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline] do_raw_spin_lock+0x1f6/0x270 kernel/locking/spinlock_debug.c:112 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:117 [inline] _raw_spin_lock_irqsave+0x50/0x70 kernel/locking/spinlock.c:159 reset_per_cpu_data+0xe6/0x240 [drop_monitor] net_dm_cmd_trace+0x43d/0x17a0 [drop_monitor] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739 genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800 netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2497 genl_rcv+0x29/0x40 net/netlink/genetlink.c:811 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x914/0xe00 net/netlink/af_netlink.c:1916 sock_sendmsg_nosec net/socket.c:651 [inline] __sock_sendmsg+0x157/0x190 net/socket.c:663 ____sys_sendmsg+0x712/0x870 net/socket.c:2378 ___sys_sendmsg+0xf8/0x170 net/socket.c:2432 __sys_sendmsg+0xea/0x1b0 net/socket.c:2461 do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x62/0xc7 RIP: 0033:0x7f3f9815aee9 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 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f3f972bf0c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f3f9826d050 RCX: 00007f3f9815aee9 RDX: 0000000020000000 RSI: 0000000020001300 RDI: 0000000000000007 RBP: 00007f3f981b63bd R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000006e R14: 00007f3f9826d050 R15: 00007ffe01ee6768 If drop_monitor is built as a kernel module, syzkaller may have time to send a netlink NET_DM_CMD_START message during the module loading. This will call the net_dm_monitor_start() function that uses a spinlock that has not yet been initialized. To fix this, let's place resource initialization above the registration of a generic netlink family. Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller. CVE-2025-21862 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: gtp: Suppress list corruption splat in gtp_net_exit_batch_rtnl(). Brad Spengler reported the list_del() corruption splat in gtp_net_exit_batch_rtnl(). [0] Commit eb28fd76c0a0 ("gtp: Destroy device along with udp socket's netns dismantle.") added the for_each_netdev() loop in gtp_net_exit_batch_rtnl() to destroy devices in each netns as done in geneve and ip tunnels. However, this could trigger ->dellink() twice for the same device during ->exit_batch_rtnl(). Say we have two netns A & B and gtp device B that resides in netns B but whose UDP socket is in netns A. 1. cleanup_net() processes netns A and then B. 2. gtp_net_exit_batch_rtnl() finds the device B while iterating netns A's gn->gtp_dev_list and calls ->dellink(). [ device B is not yet unlinked from netns B as unregister_netdevice_many() has not been called. ] 3. gtp_net_exit_batch_rtnl() finds the device B while iterating netns B's for_each_netdev() and calls ->dellink(). gtp_dellink() cleans up the device's hash table, unlinks the dev from gn->gtp_dev_list, and calls unregister_netdevice_queue(). Basically, calling gtp_dellink() multiple times is fine unless CONFIG_DEBUG_LIST is enabled. Let's remove for_each_netdev() in gtp_net_exit_batch_rtnl() and delegate the destruction to default_device_exit_batch() as done in bareudp. [0]: list_del corruption, ffff8880aaa62c00->next (autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc00/0x1000 [slab object]) is LIST_POISON1 (ffffffffffffff02) (prev is 0xffffffffffffff04) kernel BUG at lib/list_debug.c:58! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 1 UID: 0 PID: 1804 Comm: kworker/u8:7 Tainted: G T 6.12.13-grsec-full-20250211091339 #1 Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: netns cleanup_net RIP: 0010:[<ffffffff84947381>] __list_del_entry_valid_or_report+0x141/0x200 lib/list_debug.c:58 Code: c2 76 91 31 c0 e8 9f b1 f7 fc 0f 0b 4d 89 f0 48 c7 c1 02 ff ff ff 48 89 ea 48 89 ee 48 c7 c7 e0 c2 76 91 31 c0 e8 7f b1 f7 fc <0f> 0b 4d 89 e8 48 c7 c1 04 ff ff ff 48 89 ea 48 89 ee 48 c7 c7 60 RSP: 0018:fffffe8040b4fbd0 EFLAGS: 00010283 RAX: 00000000000000cc RBX: dffffc0000000000 RCX: ffffffff818c4054 RDX: ffffffff84947381 RSI: ffffffff818d1512 RDI: 0000000000000000 RBP: ffff8880aaa62c00 R08: 0000000000000001 R09: fffffbd008169f32 R10: fffffe8040b4f997 R11: 0000000000000001 R12: a1988d84f24943e4 R13: ffffffffffffff02 R14: ffffffffffffff04 R15: ffff8880aaa62c08 RBX: kasan shadow of 0x0 RCX: __wake_up_klogd.part.0+0x74/0xe0 kernel/printk/printk.c:4554 RDX: __list_del_entry_valid_or_report+0x141/0x200 lib/list_debug.c:58 RSI: vprintk+0x72/0x100 kernel/printk/printk_safe.c:71 RBP: autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc00/0x1000 [slab object] RSP: process kstack fffffe8040b4fbd0+0x7bd0/0x8000 [kworker/u8:7+netns 1804 ] R09: kasan shadow of process kstack fffffe8040b4f990+0x7990/0x8000 [kworker/u8:7+netns 1804 ] R10: process kstack fffffe8040b4f997+0x7997/0x8000 [kworker/u8:7+netns 1804 ] R15: autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc08/0x1000 [slab object] FS: 0000000000000000(0000) GS:ffff888116000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000748f5372c000 CR3: 0000000015408000 CR4: 00000000003406f0 shadow CR4: 00000000003406f0 Stack: 0000000000000000 ffffffff8a0c35e7 ffffffff8a0c3603 ffff8880aaa62c00 ffff8880aaa62c00 0000000000000004 ffff88811145311c 0000000000000005 0000000000000001 ffff8880aaa62000 fffffe8040b4fd40 ffffffff8a0c360d Call Trace: <TASK> [<ffffffff8a0c360d>] __list_del_entry_valid include/linux/list.h:131 [inline] fffffe8040b4fc28 [<ffffffff8a0c360d>] __list_del_entry include/linux/list.h:248 [inline] fffffe8040b4fc28 [<ffffffff8a0c360d>] list_del include/linux/list.h:262 [inl ---truncated--- CVE-2025-21865 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: tee: optee: Fix supplicant wait loop OP-TEE supplicant is a user-space daemon and it's possible for it be hung or crashed or killed in the middle of processing an OP-TEE RPC call. It becomes more complicated when there is incorrect shutdown ordering of the supplicant process vs the OP-TEE client application which can eventually lead to system hang-up waiting for the closure of the client application. Allow the client process waiting in kernel for supplicant response to be killed rather than indefinitely waiting in an unkillable state. Also, a normal uninterruptible wait should not have resulted in the hung-task watchdog getting triggered, but the endless loop would. This fixes issues observed during system reboot/shutdown when supplicant got hung for some reason or gets crashed/killed which lead to client getting hung in an unkillable state. It in turn lead to system being in hung up state requiring hard power off/on to recover. CVE-2025-21871 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: usbnet: gl620a: fix endpoint checking in genelink_bind() Syzbot reports [1] a warning in usb_submit_urb() triggered by inconsistencies between expected and actually present endpoints in gl620a driver. Since genelink_bind() does not properly verify whether specified eps are in fact provided by the device, in this case, an artificially manufactured one, one may get a mismatch. Fix the issue by resorting to a usbnet utility function usbnet_get_endpoints(), usually reserved for this very problem. Check for endpoints and return early before proceeding further if any are missing. [1] Syzbot report: usb 5-1: Manufacturer: syz usb 5-1: SerialNumber: syz usb 5-1: config 0 descriptor?? gl620a 5-1:0.23 usb0: register 'gl620a' at usb-dummy_hcd.0-1, ... ------------[ cut here ]------------ usb 5-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 2 PID: 1841 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503 Modules linked in: CPU: 2 UID: 0 PID: 1841 Comm: kworker/2:2 Not tainted 6.12.0-syzkaller-07834-g06afb0f36106 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: mld mld_ifc_work RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503 ... Call Trace: <TASK> usbnet_start_xmit+0x6be/0x2780 drivers/net/usb/usbnet.c:1467 __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] xmit_one net/core/dev.c:3590 [inline] dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3606 sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343 __dev_xmit_skb net/core/dev.c:3827 [inline] __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4400 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_resolve_output net/core/neighbour.c:1514 [inline] neigh_resolve_output+0x5bc/0x950 net/core/neighbour.c:1494 neigh_output include/net/neighbour.h:539 [inline] ip6_finish_output2+0xb1b/0x2070 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0x3f9/0x1360 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x1f8/0x540 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] mld_sendpack+0x9f0/0x11d0 net/ipv6/mcast.c:1819 mld_send_cr net/ipv6/mcast.c:2120 [inline] mld_ifc_work+0x740/0xca0 net/ipv6/mcast.c:2651 process_one_work+0x9c5/0x1ba0 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> CVE-2025-21877 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: uprobes: Reject the shared zeropage in uprobe_write_opcode() We triggered the following crash in syzkaller tests: BUG: Bad page state in process syz.7.38 pfn:1eff3 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1eff3 flags: 0x3fffff00004004(referenced|reserved|node=0|zone=1|lastcpupid=0x1fffff) raw: 003fffff00004004 ffffe6c6c07bfcc8 ffffe6c6c07bfcc8 0000000000000000 raw: 0000000000000000 0000000000000000 00000000fffffffe 0000000000000000 page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x32/0x50 bad_page+0x69/0xf0 free_unref_page_prepare+0x401/0x500 free_unref_page+0x6d/0x1b0 uprobe_write_opcode+0x460/0x8e0 install_breakpoint.part.0+0x51/0x80 register_for_each_vma+0x1d9/0x2b0 __uprobe_register+0x245/0x300 bpf_uprobe_multi_link_attach+0x29b/0x4f0 link_create+0x1e2/0x280 __sys_bpf+0x75f/0xac0 __x64_sys_bpf+0x1a/0x30 do_syscall_64+0x56/0x100 entry_SYSCALL_64_after_hwframe+0x78/0xe2 BUG: Bad rss-counter state mm:00000000452453e0 type:MM_FILEPAGES val:-1 The following syzkaller test case can be used to reproduce: r2 = creat(&(0x7f0000000000)='./file0\x00', 0x8) write$nbd(r2, &(0x7f0000000580)=ANY=[], 0x10) r4 = openat(0xffffffffffffff9c, &(0x7f0000000040)='./file0\x00', 0x42, 0x0) mmap$IORING_OFF_SQ_RING(&(0x7f0000ffd000/0x3000)=nil, 0x3000, 0x0, 0x12, r4, 0x0) r5 = userfaultfd(0x80801) ioctl$UFFDIO_API(r5, 0xc018aa3f, &(0x7f0000000040)={0xaa, 0x20}) r6 = userfaultfd(0x80801) ioctl$UFFDIO_API(r6, 0xc018aa3f, &(0x7f0000000140)) ioctl$UFFDIO_REGISTER(r6, 0xc020aa00, &(0x7f0000000100)={{&(0x7f0000ffc000/0x4000)=nil, 0x4000}, 0x2}) ioctl$UFFDIO_ZEROPAGE(r5, 0xc020aa04, &(0x7f0000000000)={{&(0x7f0000ffd000/0x1000)=nil, 0x1000}}) r7 = bpf$PROG_LOAD(0x5, &(0x7f0000000140)={0x2, 0x3, &(0x7f0000000200)=ANY=[@ANYBLOB="1800000000120000000000000000000095"], &(0x7f0000000000)='GPL\x00', 0x7, 0x0, 0x0, 0x0, 0x0, '\x00', 0x0, @fallback=0x30, 0xffffffffffffffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, @void, @value}, 0x94) bpf$BPF_LINK_CREATE_XDP(0x1c, &(0x7f0000000040)={r7, 0x0, 0x30, 0x1e, @val=@uprobe_multi={&(0x7f0000000080)='./file0\x00', &(0x7f0000000100)=[0x2], 0x0, 0x0, 0x1}}, 0x40) The cause is that zero pfn is set to the PTE without increasing the RSS count in mfill_atomic_pte_zeropage() and the refcount of zero folio does not increase accordingly. Then, the operation on the same pfn is performed in uprobe_write_opcode()->__replace_page() to unconditional decrease the RSS count and old_folio's refcount. Therefore, two bugs are introduced: 1. The RSS count is incorrect, when process exit, the check_mm() report error "Bad rss-count". 2. The reserved folio (zero folio) is freed when folio->refcount is zero, then free_pages_prepare->free_page_is_bad() report error "Bad page state". There is more, the following warning could also theoretically be triggered: __replace_page() -> ... -> folio_remove_rmap_pte() -> VM_WARN_ON_FOLIO(is_zero_folio(folio), folio) Considering that uprobe hit on the zero folio is a very rare case, just reject zero old folio immediately after get_user_page_vma_remote(). [ mingo: Cleaned up the changelog ] CVE-2025-21881 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ipvlan: ensure network headers are in skb linear part syzbot found that ipvlan_process_v6_outbound() was assuming the IPv6 network header isis present in skb->head [1] Add the needed pskb_network_may_pull() calls for both IPv4 and IPv6 handlers. [1] BUG: KMSAN: uninit-value in __ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47 __ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47 ipv6_addr_type include/net/ipv6.h:555 [inline] ip6_route_output_flags_noref net/ipv6/route.c:2616 [inline] ip6_route_output_flags+0x51/0x720 net/ipv6/route.c:2651 ip6_route_output include/net/ip6_route.h:93 [inline] ipvlan_route_v6_outbound+0x24e/0x520 drivers/net/ipvlan/ipvlan_core.c:476 ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:491 [inline] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:541 [inline] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:605 [inline] ipvlan_queue_xmit+0xd72/0x1780 drivers/net/ipvlan/ipvlan_core.c:671 ipvlan_start_xmit+0x5b/0x210 drivers/net/ipvlan/ipvlan_main.c:223 __netdev_start_xmit include/linux/netdevice.h:5150 [inline] netdev_start_xmit include/linux/netdevice.h:5159 [inline] xmit_one net/core/dev.c:3735 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3751 sch_direct_xmit+0x399/0xd40 net/sched/sch_generic.c:343 qdisc_restart net/sched/sch_generic.c:408 [inline] __qdisc_run+0x14da/0x35d0 net/sched/sch_generic.c:416 qdisc_run+0x141/0x4d0 include/net/pkt_sched.h:127 net_tx_action+0x78b/0x940 net/core/dev.c:5484 handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561 __do_softirq+0x14/0x1a kernel/softirq.c:595 do_softirq+0x9a/0x100 kernel/softirq.c:462 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4611 dev_queue_xmit include/linux/netdevice.h:3311 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3132 [inline] packet_sendmsg+0x93e0/0xa7e0 net/packet/af_packet.c:3164 sock_sendmsg_nosec net/socket.c:718 [inline] CVE-2025-21891 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: reject cooked mode if it is set along with other flags It is possible to set both MONITOR_FLAG_COOK_FRAMES and MONITOR_FLAG_ACTIVE flags simultaneously on the same monitor interface from the userspace. This causes a sub-interface to be created with no IEEE80211_SDATA_IN_DRIVER bit set because the monitor interface is in the cooked state and it takes precedence over all other states. When the interface is then being deleted the kernel calls WARN_ONCE() from check_sdata_in_driver() because of missing that bit. Fix this by rejecting MONITOR_FLAG_COOK_FRAMES if it is set along with other flags. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. CVE-2025-21909 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: regulatory: improve invalid hints checking Syzbot keeps reporting an issue [1] that occurs when erroneous symbols sent from userspace get through into user_alpha2[] via regulatory_hint_user() call. Such invalid regulatory hints should be rejected. While a sanity check from commit 47caf685a685 ("cfg80211: regulatory: reject invalid hints") looks to be enough to deter these very cases, there is a way to get around it due to 2 reasons. 1) The way isalpha() works, symbols other than latin lower and upper letters may be used to determine a country/domain. For instance, greek letters will also be considered upper/lower letters and for such characters isalpha() will return true as well. However, ISO-3166-1 alpha2 codes should only hold latin characters. 2) While processing a user regulatory request, between reg_process_hint_user() and regulatory_hint_user() there happens to be a call to queue_regulatory_request() which modifies letters in request->alpha2[] with toupper(). This works fine for latin symbols, less so for weird letter characters from the second part of _ctype[]. Syzbot triggers a warning in is_user_regdom_saved() by first sending over an unexpected non-latin letter that gets malformed by toupper() into a character that ends up failing isalpha() check. Prevent this by enhancing is_an_alpha2() to ensure that incoming symbols are latin letters and nothing else. [1] Syzbot report: ------------[ cut here ]------------ Unexpected user alpha2: A� WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 is_user_regdom_saved net/wireless/reg.c:440 [inline] WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 restore_alpha2 net/wireless/reg.c:3424 [inline] WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 restore_regulatory_settings+0x3c0/0x1e50 net/wireless/reg.c:3516 Modules linked in: CPU: 1 UID: 0 PID: 964 Comm: kworker/1:2 Not tainted 6.12.0-rc5-syzkaller-00044-gc1e939a21eb1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: events_power_efficient crda_timeout_work RIP: 0010:is_user_regdom_saved net/wireless/reg.c:440 [inline] RIP: 0010:restore_alpha2 net/wireless/reg.c:3424 [inline] RIP: 0010:restore_regulatory_settings+0x3c0/0x1e50 net/wireless/reg.c:3516 ... Call Trace: <TASK> crda_timeout_work+0x27/0x50 net/wireless/reg.c:542 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa65/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f2/0x390 kernel/kthread.c:389 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> CVE-2025-21910 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: usb: atm: cxacru: fix a flaw in existing endpoint checks Syzbot once again identified a flaw in usb endpoint checking, see [1]. This time the issue stems from a commit authored by me (2eabb655a968 ("usb: atm: cxacru: fix endpoint checking in cxacru_bind()")). While using usb_find_common_endpoints() may usually be enough to discard devices with wrong endpoints, in this case one needs more than just finding and identifying the sufficient number of endpoints of correct types - one needs to check the endpoint's address as well. Since cxacru_bind() fills URBs with CXACRU_EP_CMD address in mind, switch the endpoint verification approach to usb_check_XXX_endpoints() instead to fix incomplete ep testing. [1] Syzbot report: usb 5-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 0 PID: 1378 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503 ... RIP: 0010:usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503 ... Call Trace: <TASK> cxacru_cm+0x3c8/0xe50 drivers/usb/atm/cxacru.c:649 cxacru_card_status drivers/usb/atm/cxacru.c:760 [inline] cxacru_bind+0xcf9/0x1150 drivers/usb/atm/cxacru.c:1223 usbatm_usb_probe+0x314/0x1d30 drivers/usb/atm/usbatm.c:1058 cxacru_usb_probe+0x184/0x220 drivers/usb/atm/cxacru.c:1377 usb_probe_interface+0x641/0xbb0 drivers/usb/core/driver.c:396 really_probe+0x2b9/0xad0 drivers/base/dd.c:658 __driver_probe_device+0x1a2/0x390 drivers/base/dd.c:800 driver_probe_device+0x50/0x430 drivers/base/dd.c:830 ... CVE-2025-21916 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ppp: Fix KMSAN uninit-value warning with bpf Syzbot caught an "KMSAN: uninit-value" warning [1], which is caused by the ppp driver not initializing a 2-byte header when using socket filter. The following code can generate a PPP filter BPF program: ''' struct bpf_program fp; pcap_t *handle; handle = pcap_open_dead(DLT_PPP_PPPD, 65535); pcap_compile(handle, &fp, "ip and outbound", 0, 0); bpf_dump(&fp, 1); ''' Its output is: ''' (000) ldh [2] (001) jeq #0x21 jt 2 jf 5 (002) ldb [0] (003) jeq #0x1 jt 4 jf 5 (004) ret #65535 (005) ret #0 ''' Wen can find similar code at the following link: https://github.com/ppp-project/ppp/blob/master/pppd/options.c#L1680 The maintainer of this code repository is also the original maintainer of the ppp driver. As you can see the BPF program skips 2 bytes of data and then reads the 'Protocol' field to determine if it's an IP packet. Then it read the first byte of the first 2 bytes to determine the direction. The issue is that only the first byte indicating direction is initialized in current ppp driver code while the second byte is not initialized. For normal BPF programs generated by libpcap, uninitialized data won't be used, so it's not a problem. However, for carefully crafted BPF programs, such as those generated by syzkaller [2], which start reading from offset 0, the uninitialized data will be used and caught by KMSAN. [1] https://syzkaller.appspot.com/bug?extid=853242d9c9917165d791 [2] https://syzkaller.appspot.com/text?tag=ReproC&x=11994913980000 CVE-2025-21922 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: gso: fix ownership in __udp_gso_segment In __udp_gso_segment the skb destructor is removed before segmenting the skb but the socket reference is kept as-is. This is an issue if the original skb is later orphaned as we can hit the following bug: kernel BUG at ./include/linux/skbuff.h:3312! (skb_orphan) RIP: 0010:ip_rcv_core+0x8b2/0xca0 Call Trace: ip_rcv+0xab/0x6e0 __netif_receive_skb_one_core+0x168/0x1b0 process_backlog+0x384/0x1100 __napi_poll.constprop.0+0xa1/0x370 net_rx_action+0x925/0xe50 The above can happen following a sequence of events when using OpenVSwitch, when an OVS_ACTION_ATTR_USERSPACE action precedes an OVS_ACTION_ATTR_OUTPUT action: 1. OVS_ACTION_ATTR_USERSPACE is handled (in do_execute_actions): the skb goes through queue_gso_packets and then __udp_gso_segment, where its destructor is removed. 2. The segments' data are copied and sent to userspace. 3. OVS_ACTION_ATTR_OUTPUT is handled (in do_execute_actions) and the same original skb is sent to its path. 4. If it later hits skb_orphan, we hit the bug. Fix this by also removing the reference to the socket in __udp_gso_segment. CVE-2025-21926 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: fix potential memory corruption in nvme_tcp_recv_pdu() nvme_tcp_recv_pdu() doesn't check the validity of the header length. When header digests are enabled, a target might send a packet with an invalid header length (e.g. 255), causing nvme_tcp_verify_hdgst() to access memory outside the allocated area and cause memory corruptions by overwriting it with the calculated digest. Fix this by rejecting packets with an unexpected header length. CVE-2025-21927 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: hwpoison, memory_hotplug: lock folio before unmap hwpoisoned folio Commit b15c87263a69 ("hwpoison, memory_hotplug: allow hwpoisoned pages to be offlined) add page poison checks in do_migrate_range in order to make offline hwpoisoned page possible by introducing isolate_lru_page and try_to_unmap for hwpoisoned page. However folio lock must be held before calling try_to_unmap. Add it to fix this problem. Warning will be produced if folio is not locked during unmap: ------------[ cut here ]------------ kernel BUG at ./include/linux/swapops.h:400! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 4 UID: 0 PID: 411 Comm: bash Tainted: G W 6.13.0-rc1-00016-g3c434c7ee82a-dirty #41 Tainted: [W]=WARN Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : try_to_unmap_one+0xb08/0xd3c lr : try_to_unmap_one+0x3dc/0xd3c Call trace: try_to_unmap_one+0xb08/0xd3c (P) try_to_unmap_one+0x3dc/0xd3c (L) rmap_walk_anon+0xdc/0x1f8 rmap_walk+0x3c/0x58 try_to_unmap+0x88/0x90 unmap_poisoned_folio+0x30/0xa8 do_migrate_range+0x4a0/0x568 offline_pages+0x5a4/0x670 memory_block_action+0x17c/0x374 memory_subsys_offline+0x3c/0x78 device_offline+0xa4/0xd0 state_store+0x8c/0xf0 dev_attr_store+0x18/0x2c sysfs_kf_write+0x44/0x54 kernfs_fop_write_iter+0x118/0x1a8 vfs_write+0x3a8/0x4bc ksys_write+0x6c/0xf8 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x30/0xd0 el0t_64_sync_handler+0xc8/0xcc el0t_64_sync+0x198/0x19c Code: f9407be0 b5fff320 d4210000 17ffff97 (d4210000) ---[ end trace 0000000000000000 ]--- CVE-2025-21931 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: rapidio: fix an API misues when rio_add_net() fails rio_add_net() calls device_register() and fails when device_register() fails. Thus, put_device() should be used rather than kfree(). Add "mport->net = NULL;" to avoid a use after free issue. CVE-2025-21934 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: rapidio: add check for rio_add_net() in rio_scan_alloc_net() The return value of rio_add_net() should be checked. If it fails, put_device() should be called to free the memory and give up the reference initialized in rio_add_net(). CVE-2025-21935 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix null check for pipe_ctx->plane_state in resource_build_scaling_params Null pointer dereference issue could occur when pipe_ctx->plane_state is null. The fix adds a check to ensure 'pipe_ctx->plane_state' is not null before accessing. This prevents a null pointer dereference. Found by code review. (cherry picked from commit 63e6a77ccf239337baa9b1e7787cde9fa0462092) CVE-2025-21941 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: HID: appleir: Fix potential NULL dereference at raw event handle Syzkaller reports a NULL pointer dereference issue in input_event(). BUG: KASAN: null-ptr-deref in instrument_atomic_read include/linux/instrumented.h:68 [inline] BUG: KASAN: null-ptr-deref in _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] BUG: KASAN: null-ptr-deref in is_event_supported drivers/input/input.c:67 [inline] BUG: KASAN: null-ptr-deref in input_event+0x42/0xa0 drivers/input/input.c:395 Read of size 8 at addr 0000000000000028 by task syz-executor199/2949 CPU: 0 UID: 0 PID: 2949 Comm: syz-executor199 Not tainted 6.13.0-rc4-syzkaller-00076-gf097a36ef88d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 kasan_report+0xd9/0x110 mm/kasan/report.c:602 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189 instrument_atomic_read include/linux/instrumented.h:68 [inline] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] is_event_supported drivers/input/input.c:67 [inline] input_event+0x42/0xa0 drivers/input/input.c:395 input_report_key include/linux/input.h:439 [inline] key_down drivers/hid/hid-appleir.c:159 [inline] appleir_raw_event+0x3e5/0x5e0 drivers/hid/hid-appleir.c:232 __hid_input_report.constprop.0+0x312/0x440 drivers/hid/hid-core.c:2111 hid_ctrl+0x49f/0x550 drivers/hid/usbhid/hid-core.c:484 __usb_hcd_giveback_urb+0x389/0x6e0 drivers/usb/core/hcd.c:1650 usb_hcd_giveback_urb+0x396/0x450 drivers/usb/core/hcd.c:1734 dummy_timer+0x17f7/0x3960 drivers/usb/gadget/udc/dummy_hcd.c:1993 __run_hrtimer kernel/time/hrtimer.c:1739 [inline] __hrtimer_run_queues+0x20a/0xae0 kernel/time/hrtimer.c:1803 hrtimer_run_softirq+0x17d/0x350 kernel/time/hrtimer.c:1820 handle_softirqs+0x206/0x8d0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [inline] invoke_softirq kernel/softirq.c:435 [inline] __irq_exit_rcu+0xfa/0x160 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvec_apic_timer_interrupt+0x90/0xb0 arch/x86/kernel/apic/apic.c:1049 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702 __mod_timer+0x8f6/0xdc0 kernel/time/timer.c:1185 add_timer+0x62/0x90 kernel/time/timer.c:1295 schedule_timeout+0x11f/0x280 kernel/time/sleep_timeout.c:98 usbhid_wait_io+0x1c7/0x380 drivers/hid/usbhid/hid-core.c:645 usbhid_init_reports+0x19f/0x390 drivers/hid/usbhid/hid-core.c:784 hiddev_ioctl+0x1133/0x15b0 drivers/hid/usbhid/hiddev.c:794 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl fs/ioctl.c:892 [inline] __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892 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 </TASK> This happens due to the malformed report items sent by the emulated device which results in a report, that has no fields, being added to the report list. Due to this appleir_input_configured() is never called, hidinput_connect() fails which results in the HID_CLAIMED_INPUT flag is not being set. However, it does not make appleir_probe() fail and lets the event callback to be called without the associated input device. Thus, add a check for the HID_CLAIMED_INPUT flag and leave the event hook early if the driver didn't claim any input_dev for some reason. Moreover, some other hid drivers accessing input_dev in their event callbacks do have similar checks, too. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. CVE-2025-21948 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Assign normalized_pix_clk when color depth = 14 [WHY & HOW] A warning message "WARNING: CPU: 4 PID: 459 at ... /dc_resource.c:3397 calculate_phy_pix_clks+0xef/0x100 [amdgpu]" occurs because the display_color_depth == COLOR_DEPTH_141414 is not handled. This is observed in Radeon RX 6600 XT. It is fixed by assigning pix_clk * (14 * 3) / 24 - same as the rests. Also fixes the indentation in get_norm_pix_clk. (cherry picked from commit 274a87eb389f58eddcbc5659ab0b180b37e92775) CVE-2025-21956 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: qla1280: Fix kernel oops when debug level > 2 A null dereference or oops exception will eventually occur when qla1280.c driver is compiled with DEBUG_QLA1280 enabled and ql_debug_level > 2. I think its clear from the code that the intention here is sg_dma_len(s) not length of sg_next(s) when printing the debug info. CVE-2025-21957 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: cifs: Fix integer overflow while processing acdirmax mount option User-provided mount parameter acdirmax of type u32 is intended to have an upper limit, but before it is validated, the value is converted from seconds to jiffies which can lead to an integer overflow. Found by Linux Verification Center (linuxtesting.org) with SVACE. CVE-2025-21963 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: cifs: Fix integer overflow while processing acregmax mount option User-provided mount parameter acregmax of type u32 is intended to have an upper limit, but before it is validated, the value is converted from seconds to jiffies which can lead to an integer overflow. Found by Linux Verification Center (linuxtesting.org) with SVACE. CVE-2025-21964 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix slab-use-after-free Read in l2cap_send_cmd After the hci sync command releases l2cap_conn, the hci receive data work queue references the released l2cap_conn when sending to the upper layer. Add hci dev lock to the hci receive data work queue to synchronize the two. [1] BUG: KASAN: slab-use-after-free in l2cap_send_cmd+0x187/0x8d0 net/bluetooth/l2cap_core.c:954 Read of size 8 at addr ffff8880271a4000 by task kworker/u9:2/5837 CPU: 0 UID: 0 PID: 5837 Comm: kworker/u9:2 Not tainted 6.13.0-rc5-syzkaller-00163-gab75170520d4 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: hci1 hci_rx_work Call Trace: <TASK> __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 l2cap_build_cmd net/bluetooth/l2cap_core.c:2964 [inline] l2cap_send_cmd+0x187/0x8d0 net/bluetooth/l2cap_core.c:954 l2cap_sig_send_rej net/bluetooth/l2cap_core.c:5502 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5538 [inline] l2cap_recv_frame+0x221f/0x10db0 net/bluetooth/l2cap_core.c:6817 hci_acldata_packet net/bluetooth/hci_core.c:3797 [inline] hci_rx_work+0x508/0xdb0 net/bluetooth/hci_core.c:4040 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Allocated by task 5837: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4329 kmalloc_noprof include/linux/slab.h:901 [inline] kzalloc_noprof include/linux/slab.h:1037 [inline] l2cap_conn_add+0xa9/0x8e0 net/bluetooth/l2cap_core.c:6860 l2cap_connect_cfm+0x115/0x1090 net/bluetooth/l2cap_core.c:7239 hci_connect_cfm include/net/bluetooth/hci_core.h:2057 [inline] hci_remote_features_evt+0x68e/0xac0 net/bluetooth/hci_event.c:3726 hci_event_func net/bluetooth/hci_event.c:7473 [inline] hci_event_packet+0xac2/0x1540 net/bluetooth/hci_event.c:7525 hci_rx_work+0x3f3/0xdb0 net/bluetooth/hci_core.c:4035 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 54: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2353 [inline] slab_free mm/slub.c:4613 [inline] kfree+0x196/0x430 mm/slub.c:4761 l2cap_connect_cfm+0xcc/0x1090 net/bluetooth/l2cap_core.c:7235 hci_connect_cfm include/net/bluetooth/hci_core.h:2057 [inline] hci_conn_failed+0x287/0x400 net/bluetooth/hci_conn.c:1266 hci_abort_conn_sync+0x56c/0x11f0 net/bluetooth/hci_sync.c:5603 hci_cmd_sync_work+0x22b/0x400 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entr ---truncated--- CVE-2025-21969 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: fbdev: hyperv_fb: Allow graceful removal of framebuffer When a Hyper-V framebuffer device is unbind, hyperv_fb driver tries to release the framebuffer forcefully. If this framebuffer is in use it produce the following WARN and hence this framebuffer is never released. [ 44.111220] WARNING: CPU: 35 PID: 1882 at drivers/video/fbdev/core/fb_info.c:70 framebuffer_release+0x2c/0x40 < snip > [ 44.111289] Call Trace: [ 44.111290] <TASK> [ 44.111291] ? show_regs+0x6c/0x80 [ 44.111295] ? __warn+0x8d/0x150 [ 44.111298] ? framebuffer_release+0x2c/0x40 [ 44.111300] ? report_bug+0x182/0x1b0 [ 44.111303] ? handle_bug+0x6e/0xb0 [ 44.111306] ? exc_invalid_op+0x18/0x80 [ 44.111308] ? asm_exc_invalid_op+0x1b/0x20 [ 44.111311] ? framebuffer_release+0x2c/0x40 [ 44.111313] ? hvfb_remove+0x86/0xa0 [hyperv_fb] [ 44.111315] vmbus_remove+0x24/0x40 [hv_vmbus] [ 44.111323] device_remove+0x40/0x80 [ 44.111325] device_release_driver_internal+0x20b/0x270 [ 44.111327] ? bus_find_device+0xb3/0xf0 Fix this by moving the release of framebuffer and assosiated memory to fb_ops.fb_destroy function, so that framebuffer framework handles it gracefully. While we fix this, also replace manual registrations/unregistration of framebuffer with devm_register_framebuffer. CVE-2025-21976 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: iscsi_ibft: Fix UBSAN shift-out-of-bounds warning in ibft_attr_show_nic() When performing an iSCSI boot using IPv6, iscsistart still reads the /sys/firmware/ibft/ethernetX/subnet-mask entry. Since the IPv6 prefix length is 64, this causes the shift exponent to become negative, triggering a UBSAN warning. As the concept of a subnet mask does not apply to IPv6, the value is set to ~0 to suppress the warning message. CVE-2025-21993 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/radeon: fix uninitialized size issue in radeon_vce_cs_parse() On the off chance that command stream passed from userspace via ioctl() call to radeon_vce_cs_parse() is weirdly crafted and first command to execute is to encode (case 0x03000001), the function in question will attempt to call radeon_vce_cs_reloc() with size argument that has not been properly initialized. Specifically, 'size' will point to 'tmp' variable before the latter had a chance to be assigned any value. Play it safe and init 'tmp' with 0, thus ensuring that radeon_vce_cs_reloc() will catch an early error in cases like these. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE. (cherry picked from commit 2d52de55f9ee7aaee0e09ac443f77855989c6b68) CVE-2025-21996 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: atm: fix use after free in lec_send() The ->send() operation frees skb so save the length before calling ->send() to avoid a use after free. CVE-2025-22004 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 important In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix error code in chan_alloc_skb_cb() The chan_alloc_skb_cb() function is supposed to return error pointers on error. Returning NULL will lead to a NULL dereference. CVE-2025-22007 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: regulator: check that dummy regulator has been probed before using it Due to asynchronous driver probing there is a chance that the dummy regulator hasn't already been probed when first accessing it. CVE-2025-22008 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix soft lockup during bt pages loop Driver runs a for-loop when allocating bt pages and mapping them with buffer pages. When a large buffer (e.g. MR over 100GB) is being allocated, it may require a considerable loop count. This will lead to soft lockup: watchdog: BUG: soft lockup - CPU#27 stuck for 22s! ... Call trace: hem_list_alloc_mid_bt+0x124/0x394 [hns_roce_hw_v2] hns_roce_hem_list_request+0xf8/0x160 [hns_roce_hw_v2] hns_roce_mtr_create+0x2e4/0x360 [hns_roce_hw_v2] alloc_mr_pbl+0xd4/0x17c [hns_roce_hw_v2] hns_roce_reg_user_mr+0xf8/0x190 [hns_roce_hw_v2] ib_uverbs_reg_mr+0x118/0x290 watchdog: BUG: soft lockup - CPU#35 stuck for 23s! ... Call trace: hns_roce_hem_list_find_mtt+0x7c/0xb0 [hns_roce_hw_v2] mtr_map_bufs+0xc4/0x204 [hns_roce_hw_v2] hns_roce_mtr_create+0x31c/0x3c4 [hns_roce_hw_v2] alloc_mr_pbl+0xb0/0x160 [hns_roce_hw_v2] hns_roce_reg_user_mr+0x108/0x1c0 [hns_roce_hw_v2] ib_uverbs_reg_mr+0x120/0x2bc Add a cond_resched() to fix soft lockup during these loops. In order not to affect the allocation performance of normal-size buffer, set the loop count of a 100GB MR as the threshold to call cond_resched(). CVE-2025-22010 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: atm: Fix NULL pointer dereference When MPOA_cache_impos_rcvd() receives the msg, it can trigger Null Pointer Dereference Vulnerability if both entry and holding_time are NULL. Because there is only for the situation where entry is NULL and holding_time exists, it can be passed when both entry and holding_time are NULL. If these are NULL, the entry will be passd to eg_cache_put() as parameter and it is referenced by entry->use code in it. kasan log: [ 3.316691] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006:I [ 3.317568] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [ 3.318188] CPU: 3 UID: 0 PID: 79 Comm: ex Not tainted 6.14.0-rc2 #102 [ 3.318601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [ 3.319298] RIP: 0010:eg_cache_remove_entry+0xa5/0x470 [ 3.319677] Code: c1 f7 6e fd 48 c7 c7 00 7e 38 b2 e8 95 64 54 fd 48 c7 c7 40 7e 38 b2 48 89 ee e80 [ 3.321220] RSP: 0018:ffff88800583f8a8 EFLAGS: 00010006 [ 3.321596] RAX: 0000000000000006 RBX: ffff888005989000 RCX: ffffffffaecc2d8e [ 3.322112] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000030 [ 3.322643] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6558b88 [ 3.323181] R10: 0000000000000003 R11: 203a207972746e65 R12: 1ffff11000b07f15 [ 3.323707] R13: dffffc0000000000 R14: ffff888005989000 R15: ffff888005989068 [ 3.324185] FS: 000000001b6313c0(0000) GS:ffff88806d380000(0000) knlGS:0000000000000000 [ 3.325042] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3.325545] CR2: 00000000004b4b40 CR3: 000000000248e000 CR4: 00000000000006f0 [ 3.326430] Call Trace: [ 3.326725] <TASK> [ 3.326927] ? die_addr+0x3c/0xa0 [ 3.327330] ? exc_general_protection+0x161/0x2a0 [ 3.327662] ? asm_exc_general_protection+0x26/0x30 [ 3.328214] ? vprintk_emit+0x15e/0x420 [ 3.328543] ? eg_cache_remove_entry+0xa5/0x470 [ 3.328910] ? eg_cache_remove_entry+0x9a/0x470 [ 3.329294] ? __pfx_eg_cache_remove_entry+0x10/0x10 [ 3.329664] ? console_unlock+0x107/0x1d0 [ 3.329946] ? __pfx_console_unlock+0x10/0x10 [ 3.330283] ? do_syscall_64+0xa6/0x1a0 [ 3.330584] ? entry_SYSCALL_64_after_hwframe+0x47/0x7f [ 3.331090] ? __pfx_prb_read_valid+0x10/0x10 [ 3.331395] ? down_trylock+0x52/0x80 [ 3.331703] ? vprintk_emit+0x15e/0x420 [ 3.331986] ? __pfx_vprintk_emit+0x10/0x10 [ 3.332279] ? down_trylock+0x52/0x80 [ 3.332527] ? _printk+0xbf/0x100 [ 3.332762] ? __pfx__printk+0x10/0x10 [ 3.333007] ? _raw_write_lock_irq+0x81/0xe0 [ 3.333284] ? __pfx__raw_write_lock_irq+0x10/0x10 [ 3.333614] msg_from_mpoad+0x1185/0x2750 [ 3.333893] ? __build_skb_around+0x27b/0x3a0 [ 3.334183] ? __pfx_msg_from_mpoad+0x10/0x10 [ 3.334501] ? __alloc_skb+0x1c0/0x310 [ 3.334809] ? __pfx___alloc_skb+0x10/0x10 [ 3.335283] ? _raw_spin_lock+0xe0/0xe0 [ 3.335632] ? finish_wait+0x8d/0x1e0 [ 3.335975] vcc_sendmsg+0x684/0xba0 [ 3.336250] ? __pfx_vcc_sendmsg+0x10/0x10 [ 3.336587] ? __pfx_autoremove_wake_function+0x10/0x10 [ 3.337056] ? fdget+0x176/0x3e0 [ 3.337348] __sys_sendto+0x4a2/0x510 [ 3.337663] ? __pfx___sys_sendto+0x10/0x10 [ 3.337969] ? ioctl_has_perm.constprop.0.isra.0+0x284/0x400 [ 3.338364] ? sock_ioctl+0x1bb/0x5a0 [ 3.338653] ? __rseq_handle_notify_resume+0x825/0xd20 [ 3.339017] ? __pfx_sock_ioctl+0x10/0x10 [ 3.339316] ? __pfx___rseq_handle_notify_resume+0x10/0x10 [ 3.339727] ? selinux_file_ioctl+0xa4/0x260 [ 3.340166] __x64_sys_sendto+0xe0/0x1c0 [ 3.340526] ? syscall_exit_to_user_mode+0x123/0x140 [ 3.340898] do_syscall_64+0xa6/0x1a0 [ 3.341170] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 3.341533] RIP: 0033:0x44a380 [ 3.341757] Code: 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c00 [ ---truncated--- CVE-2025-22018 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: netfilter: socket: Lookup orig tuple for IPv6 SNAT nf_sk_lookup_slow_v4 does the conntrack lookup for IPv4 packets to restore the original 5-tuple in case of SNAT, to be able to find the right socket (if any). Then socket_match() can correctly check whether the socket was transparent. However, the IPv6 counterpart (nf_sk_lookup_slow_v6) lacks this conntrack lookup, making xt_socket fail to match on the socket when the packet was SNATed. Add the same logic to nf_sk_lookup_slow_v6. IPv6 SNAT is used in Kubernetes clusters for pod-to-world packets, as pods' addresses are in the fd00::/8 ULA subnet and need to be replaced with the node's external address. Cilium leverages Envoy to enforce L7 policies, and Envoy uses transparent sockets. Cilium inserts an iptables prerouting rule that matches on `-m socket --transparent` and redirects the packets to localhost, but it fails to match SNATed IPv6 packets due to that missing conntrack lookup. CVE-2025-22021 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 low In the Linux kernel, the following vulnerability has been resolved: nfsd: put dl_stid if fail to queue dl_recall Before calling nfsd4_run_cb to queue dl_recall to the callback_wq, we increment the reference count of dl_stid. We expect that after the corresponding work_struct is processed, the reference count of dl_stid will be decremented through the callback function nfsd4_cb_recall_release. However, if the call to nfsd4_run_cb fails, the incremented reference count of dl_stid will not be decremented correspondingly, leading to the following nfs4_stid leak: unreferenced object 0xffff88812067b578 (size 344): comm "nfsd", pid 2761, jiffies 4295044002 (age 5541.241s) hex dump (first 32 bytes): 01 00 00 00 6b 6b 6b 6b b8 02 c0 e2 81 88 ff ff ....kkkk........ 00 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 ad 4e ad de .kkkkkkk.....N.. backtrace: kmem_cache_alloc+0x4b9/0x700 nfsd4_process_open1+0x34/0x300 nfsd4_open+0x2d1/0x9d0 nfsd4_proc_compound+0x7a2/0xe30 nfsd_dispatch+0x241/0x3e0 svc_process_common+0x5d3/0xcc0 svc_process+0x2a3/0x320 nfsd+0x180/0x2e0 kthread+0x199/0x1d0 ret_from_fork+0x30/0x50 ret_from_fork_asm+0x1b/0x30 unreferenced object 0xffff8881499f4d28 (size 368): comm "nfsd", pid 2761, jiffies 4295044005 (age 5541.239s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 30 4d 9f 49 81 88 ff ff ........0M.I.... 30 4d 9f 49 81 88 ff ff 20 00 00 00 01 00 00 00 0M.I.... ....... backtrace: kmem_cache_alloc+0x4b9/0x700 nfs4_alloc_stid+0x29/0x210 alloc_init_deleg+0x92/0x2e0 nfs4_set_delegation+0x284/0xc00 nfs4_open_delegation+0x216/0x3f0 nfsd4_process_open2+0x2b3/0xee0 nfsd4_open+0x770/0x9d0 nfsd4_proc_compound+0x7a2/0xe30 nfsd_dispatch+0x241/0x3e0 svc_process_common+0x5d3/0xcc0 svc_process+0x2a3/0x320 nfsd+0x180/0x2e0 kthread+0x199/0x1d0 ret_from_fork+0x30/0x50 ret_from_fork_asm+0x1b/0x30 Fix it by checking the result of nfsd4_run_cb and call nfs4_put_stid if fail to queue dl_recall. CVE-2025-22025 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: streamzap: fix race between device disconnection and urb callback Syzkaller has reported a general protection fault at function ir_raw_event_store_with_filter(). This crash is caused by a NULL pointer dereference of dev->raw pointer, even though it is checked for NULL in the same function, which means there is a race condition. It occurs due to the incorrect order of actions in the streamzap_disconnect() function: rc_unregister_device() is called before usb_kill_urb(). The dev->raw pointer is freed and set to NULL in rc_unregister_device(), and only after that usb_kill_urb() waits for in-progress requests to finish. If rc_unregister_device() is called while streamzap_callback() handler is not finished, this can lead to accessing freed resources. Thus rc_unregister_device() should be called after usb_kill_urb(). Found by Linux Verification Center (linuxtesting.org) with Syzkaller. CVE-2025-22027 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. CVE-2025-22029 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 important In the Linux kernel, the following vulnerability has been resolved: usbnet:fix NPE during rx_complete Missing usbnet_going_away Check in Critical Path. The usb_submit_urb function lacks a usbnet_going_away validation, whereas __usbnet_queue_skb includes this check. This inconsistency creates a race condition where: A URB request may succeed, but the corresponding SKB data fails to be queued. Subsequent processes: (e.g., rx_complete -> defer_bh -> __skb_unlink(skb, list)) attempt to access skb->next, triggering a NULL pointer dereference (Kernel Panic). CVE-2025-22050 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: ibmveth: make veth_pool_store stop hanging v2: - Created a single error handling unlock and exit in veth_pool_store - Greatly expanded commit message with previous explanatory-only text Summary: Use rtnl_mutex to synchronize veth_pool_store with itself, ibmveth_close and ibmveth_open, preventing multiple calls in a row to napi_disable. Background: Two (or more) threads could call veth_pool_store through writing to /sys/devices/vio/30000002/pool*/*. You can do this easily with a little shell script. This causes a hang. I configured LOCKDEP, compiled ibmveth.c with DEBUG, and built a new kernel. I ran this test again and saw: Setting pool0/active to 0 Setting pool1/active to 1 [ 73.911067][ T4365] ibmveth 30000002 eth0: close starting Setting pool1/active to 1 Setting pool1/active to 0 [ 73.911367][ T4366] ibmveth 30000002 eth0: close starting [ 73.916056][ T4365] ibmveth 30000002 eth0: close complete [ 73.916064][ T4365] ibmveth 30000002 eth0: open starting [ 110.808564][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification. [ 230.808495][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification. [ 243.683786][ T123] INFO: task stress.sh:4365 blocked for more than 122 seconds. [ 243.683827][ T123] Not tainted 6.14.0-01103-g2df0c02dab82-dirty #8 [ 243.683833][ T123] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 243.683838][ T123] task:stress.sh state:D stack:28096 pid:4365 tgid:4365 ppid:4364 task_flags:0x400040 flags:0x00042000 [ 243.683852][ T123] Call Trace: [ 243.683857][ T123] [c00000000c38f690] [0000000000000001] 0x1 (unreliable) [ 243.683868][ T123] [c00000000c38f840] [c00000000001f908] __switch_to+0x318/0x4e0 [ 243.683878][ T123] [c00000000c38f8a0] [c000000001549a70] __schedule+0x500/0x12a0 [ 243.683888][ T123] [c00000000c38f9a0] [c00000000154a878] schedule+0x68/0x210 [ 243.683896][ T123] [c00000000c38f9d0] [c00000000154ac80] schedule_preempt_disabled+0x30/0x50 [ 243.683904][ T123] [c00000000c38fa00] [c00000000154dbb0] __mutex_lock+0x730/0x10f0 [ 243.683913][ T123] [c00000000c38fb10] [c000000001154d40] napi_enable+0x30/0x60 [ 243.683921][ T123] [c00000000c38fb40] [c000000000f4ae94] ibmveth_open+0x68/0x5dc [ 243.683928][ T123] [c00000000c38fbe0] [c000000000f4aa20] veth_pool_store+0x220/0x270 [ 243.683936][ T123] [c00000000c38fc70] [c000000000826278] sysfs_kf_write+0x68/0xb0 [ 243.683944][ T123] [c00000000c38fcb0] [c0000000008240b8] kernfs_fop_write_iter+0x198/0x2d0 [ 243.683951][ T123] [c00000000c38fd00] [c00000000071b9ac] vfs_write+0x34c/0x650 [ 243.683958][ T123] [c00000000c38fdc0] [c00000000071bea8] ksys_write+0x88/0x150 [ 243.683966][ T123] [c00000000c38fe10] [c0000000000317f4] system_call_exception+0x124/0x340 [ 243.683973][ T123] [c00000000c38fe50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec ... [ 243.684087][ T123] Showing all locks held in the system: [ 243.684095][ T123] 1 lock held by khungtaskd/123: [ 243.684099][ T123] #0: c00000000278e370 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x50/0x248 [ 243.684114][ T123] 4 locks held by stress.sh/4365: [ 243.684119][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150 [ 243.684132][ T123] #1: c000000041aea888 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x154/0x2d0 [ 243.684143][ T123] #2: c0000000366fb9a8 (kn->active#64){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x160/0x2d0 [ 243.684155][ T123] #3: c000000035ff4cb8 (&dev->lock){+.+.}-{3:3}, at: napi_enable+0x30/0x60 [ 243.684166][ T123] 5 locks held by stress.sh/4366: [ 243.684170][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150 [ 243. ---truncated--- CVE-2025-22053 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: fix geneve_opt length integer overflow struct geneve_opt uses 5 bit length for each single option, which means every vary size option should be smaller than 128 bytes. However, all current related Netlink policies cannot promise this length condition and the attacker can exploit a exact 128-byte size option to *fake* a zero length option and confuse the parsing logic, further achieve heap out-of-bounds read. One example crash log is like below: [ 3.905425] ================================================================== [ 3.905925] BUG: KASAN: slab-out-of-bounds in nla_put+0xa9/0xe0 [ 3.906255] Read of size 124 at addr ffff888005f291cc by task poc/177 [ 3.906646] [ 3.906775] CPU: 0 PID: 177 Comm: poc-oob-read Not tainted 6.1.132 #1 [ 3.907131] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 3.907784] Call Trace: [ 3.907925] <TASK> [ 3.908048] dump_stack_lvl+0x44/0x5c [ 3.908258] print_report+0x184/0x4be [ 3.909151] kasan_report+0xc5/0x100 [ 3.909539] kasan_check_range+0xf3/0x1a0 [ 3.909794] memcpy+0x1f/0x60 [ 3.909968] nla_put+0xa9/0xe0 [ 3.910147] tunnel_key_dump+0x945/0xba0 [ 3.911536] tcf_action_dump_1+0x1c1/0x340 [ 3.912436] tcf_action_dump+0x101/0x180 [ 3.912689] tcf_exts_dump+0x164/0x1e0 [ 3.912905] fw_dump+0x18b/0x2d0 [ 3.913483] tcf_fill_node+0x2ee/0x460 [ 3.914778] tfilter_notify+0xf4/0x180 [ 3.915208] tc_new_tfilter+0xd51/0x10d0 [ 3.918615] rtnetlink_rcv_msg+0x4a2/0x560 [ 3.919118] netlink_rcv_skb+0xcd/0x200 [ 3.919787] netlink_unicast+0x395/0x530 [ 3.921032] netlink_sendmsg+0x3d0/0x6d0 [ 3.921987] __sock_sendmsg+0x99/0xa0 [ 3.922220] __sys_sendto+0x1b7/0x240 [ 3.922682] __x64_sys_sendto+0x72/0x90 [ 3.922906] do_syscall_64+0x5e/0x90 [ 3.923814] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 3.924122] RIP: 0033:0x7e83eab84407 [ 3.924331] 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 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf [ 3.925330] RSP: 002b:00007ffff505e370 EFLAGS: 00000202 ORIG_RAX: 000000000000002c [ 3.925752] RAX: ffffffffffffffda RBX: 00007e83eaafa740 RCX: 00007e83eab84407 [ 3.926173] RDX: 00000000000001a8 RSI: 00007ffff505e3c0 RDI: 0000000000000003 [ 3.926587] RBP: 00007ffff505f460 R08: 00007e83eace1000 R09: 000000000000000c [ 3.926977] R10: 0000000000000000 R11: 0000000000000202 R12: 00007ffff505f3c0 [ 3.927367] R13: 00007ffff505f5c8 R14: 00007e83ead1b000 R15: 00005d4fbbe6dcb8 Fix these issues by enforing correct length condition in related policies. CVE-2025-22055 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 important In the Linux kernel, the following vulnerability has been resolved: udp: Fix memory accounting leak. Matt Dowling reported a weird UDP memory usage issue. Under normal operation, the UDP memory usage reported in /proc/net/sockstat remains close to zero. However, it occasionally spiked to 524,288 pages and never dropped. Moreover, the value doubled when the application was terminated. Finally, it caused intermittent packet drops. We can reproduce the issue with the script below [0]: 1. /proc/net/sockstat reports 0 pages # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 0 2. Run the script till the report reaches 524,288 # python3 test.py & sleep 5 # cat /proc/net/sockstat | grep UDP: UDP: inuse 3 mem 524288 <-- (INT_MAX + 1) >> PAGE_SHIFT 3. Kill the socket and confirm the number never drops # pkill python3 && sleep 5 # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 524288 4. (necessary since v6.0) Trigger proto_memory_pcpu_drain() # python3 test.py & sleep 1 && pkill python3 5. The number doubles # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 1048577 The application set INT_MAX to SO_RCVBUF, which triggered an integer overflow in udp_rmem_release(). When a socket is close()d, udp_destruct_common() purges its receive queue and sums up skb->truesize in the queue. This total is calculated and stored in a local unsigned integer variable. The total size is then passed to udp_rmem_release() to adjust memory accounting. However, because the function takes a signed integer argument, the total size can wrap around, causing an overflow. Then, the released amount is calculated as follows: 1) Add size to sk->sk_forward_alloc. 2) Round down sk->sk_forward_alloc to the nearest lower multiple of PAGE_SIZE and assign it to amount. 3) Subtract amount from sk->sk_forward_alloc. 4) Pass amount >> PAGE_SHIFT to __sk_mem_reduce_allocated(). When the issue occurred, the total in udp_destruct_common() was 2147484480 (INT_MAX + 833), which was cast to -2147482816 in udp_rmem_release(). At 1) sk->sk_forward_alloc is changed from 3264 to -2147479552, and 2) sets -2147479552 to amount. 3) reverts the wraparound, so we don't see a warning in inet_sock_destruct(). However, udp_memory_allocated ends up doubling at 4). Since commit 3cd3399dd7a8 ("net: implement per-cpu reserves for memory_allocated"), memory usage no longer doubles immediately after a socket is close()d because __sk_mem_reduce_allocated() caches the amount in udp_memory_per_cpu_fw_alloc. However, the next time a UDP socket receives a packet, the subtraction takes effect, causing UDP memory usage to double. This issue makes further memory allocation fail once the socket's sk->sk_rmem_alloc exceeds net.ipv4.udp_rmem_min, resulting in packet drops. To prevent this issue, let's use unsigned int for the calculation and call sk_forward_alloc_add() only once for the small delta. Note that first_packet_length() also potentially has the same problem. [0]: from socket import * SO_RCVBUFFORCE = 33 INT_MAX = (2 ** 31) - 1 s = socket(AF_INET, SOCK_DGRAM) s.bind(('', 0)) s.setsockopt(SOL_SOCKET, SO_RCVBUFFORCE, INT_MAX) c = socket(AF_INET, SOCK_DGRAM) c.connect(s.getsockname()) data = b'a' * 100 while True: c.send(data) CVE-2025-22058 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: Prevent parser TCAM memory corruption Protect the parser TCAM/SRAM memory, and the cached (shadow) SRAM information, from concurrent modifications. Both the TCAM and SRAM tables are indirectly accessed by configuring an index register that selects the row to read or write to. This means that operations must be atomic in order to, e.g., avoid spreading writes across multiple rows. Since the shadow SRAM array is used to find free rows in the hardware table, it must also be protected in order to avoid TOCTOU errors where multiple cores allocate the same row. This issue was detected in a situation where `mvpp2_set_rx_mode()` ran concurrently on two CPUs. In this particular case the MVPP2_PE_MAC_UC_PROMISCUOUS entry was corrupted, causing the classifier unit to drop all incoming unicast - indicated by the `rx_classifier_drops` counter. CVE-2025-22060 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: netlabel: Fix NULL pointer exception caused by CALIPSO on IPv4 sockets When calling netlbl_conn_setattr(), addr->sa_family is used to determine the function behavior. If sk is an IPv4 socket, but the connect function is called with an IPv6 address, the function calipso_sock_setattr() is triggered. Inside this function, the following code is executed: sk_fullsock(__sk) ? inet_sk(__sk)->pinet6 : NULL; Since sk is an IPv4 socket, pinet6 is NULL, leading to a null pointer dereference. This patch fixes the issue by checking if inet6_sk(sk) returns a NULL pointer before accessing pinet6. CVE-2025-22063 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix mlx5_poll_one() cur_qp update flow When cur_qp isn't NULL, in order to avoid fetching the QP from the radix tree again we check if the next cqe QP is identical to the one we already have. The bug however is that we are checking if the QP is identical by checking the QP number inside the CQE against the QP number inside the mlx5_ib_qp, but that's wrong since the QP number from the CQE is from FW so it should be matched against mlx5_core_qp which is our FW QP number. Otherwise we could use the wrong QP when handling a CQE which could cause the kernel trace below. This issue is mainly noticeable over QPs 0 & 1, since for now they are the only QPs in our driver whereas the QP number inside mlx5_ib_qp doesn't match the QP number inside mlx5_core_qp. BUG: kernel NULL pointer dereference, address: 0000000000000012 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP CPU: 0 UID: 0 PID: 7927 Comm: kworker/u62:1 Not tainted 6.14.0-rc3+ #189 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core] RIP: 0010:mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib] Code: 03 00 00 8d 58 ff 21 cb 66 39 d3 74 39 48 c7 c7 3c 89 6e a0 0f b7 db e8 b7 d2 b3 e0 49 8b 86 60 03 00 00 48 c7 c7 4a 89 6e a0 <0f> b7 5c 98 02 e8 9f d2 b3 e0 41 0f b7 86 78 03 00 00 83 e8 01 21 RSP: 0018:ffff88810511bd60 EFLAGS: 00010046 RAX: 0000000000000010 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff88885fa1b3c0 RDI: ffffffffa06e894a RBP: 00000000000000b0 R08: 0000000000000000 R09: ffff88810511bc10 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88810d593000 R13: ffff88810e579108 R14: ffff888105146000 R15: 00000000000000b0 FS: 0000000000000000(0000) GS:ffff88885fa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000012 CR3: 00000001077e6001 CR4: 0000000000370eb0 Call Trace: <TASK> ? __die+0x20/0x60 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x130 ? asm_exc_page_fault+0x22/0x30 ? mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib] __ib_process_cq+0x5a/0x150 [ib_core] ib_cq_poll_work+0x31/0x90 [ib_core] process_one_work+0x169/0x320 worker_thread+0x288/0x3a0 ? work_busy+0xb0/0xb0 kthread+0xd7/0x1f0 ? kthreads_online_cpu+0x130/0x130 ? kthreads_online_cpu+0x130/0x130 ret_from_fork+0x2d/0x50 ? kthreads_online_cpu+0x130/0x130 ret_from_fork_asm+0x11/0x20 </TASK> CVE-2025-22086 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ibmvnic: Use kernel helpers for hex dumps Previously, when the driver was printing hex dumps, the buffer was cast to an 8 byte long and printed using string formatters. If the buffer size was not a multiple of 8 then a read buffer overflow was possible. Therefore, create a new ibmvnic function that loops over a buffer and calls hex_dump_to_buffer instead. This patch address KASAN reports like the one below: ibmvnic 30000003 env3: Login Buffer: ibmvnic 30000003 env3: 01000000af000000 <...> ibmvnic 30000003 env3: 2e6d62692e736261 ibmvnic 30000003 env3: 65050003006d6f63 ================================================================== BUG: KASAN: slab-out-of-bounds in ibmvnic_login+0xacc/0xffc [ibmvnic] Read of size 8 at addr c0000001331a9aa8 by task ip/17681 <...> Allocated by task 17681: <...> ibmvnic_login+0x2f0/0xffc [ibmvnic] ibmvnic_open+0x148/0x308 [ibmvnic] __dev_open+0x1ac/0x304 <...> The buggy address is located 168 bytes inside of allocated 175-byte region [c0000001331a9a00, c0000001331a9aaf) <...> ================================================================= ibmvnic 30000003 env3: 000000000033766e CVE-2025-22104 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate FreeType 2.8.1 has a signed integer overflow in cf2_doFlex in cff/cf2intrp.c. CVE-2025-23022 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libfreetype6-2.6.3-7.24.1 moderate In the Linux kernel, the following vulnerability has been resolved: dlm: prevent NPD when writing a positive value to event_done do_uevent returns the value written to event_done. In case it is a positive value, new_lockspace would undo all the work, and lockspace would not be set. __dlm_new_lockspace, however, would treat that positive value as a success due to commit 8511a2728ab8 ("dlm: fix use count with multiple joins"). Down the line, device_create_lockspace would pass that NULL lockspace to dlm_find_lockspace_local, leading to a NULL pointer dereference. Treating such positive values as successes prevents the problem. Given this has been broken for so long, this is unlikely to break userspace expectations. CVE-2025-23131 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: thermal: int340x: Add NULL check for adev Not all devices have an ACPI companion fwnode, so adev might be NULL. This is similar to the commit cd2fd6eab480 ("platform/x86: int3472: Check for adev == NULL"). Add a check for adev not being set and return -ENODEV in that case to avoid a possible NULL pointer deref in int3402_thermal_probe(). Note, under the same directory, int3400_thermal_probe() has such a check. [ rjw: Subject edit, added Fixes: ] CVE-2025-23136 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ext4: fix off-by-one error in do_split Syzkaller detected a use-after-free issue in ext4_insert_dentry that was caused by out-of-bounds access due to incorrect splitting in do_split. BUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 Write of size 251 at addr ffff888074572f14 by task syz-executor335/5847 CPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 Call Trace: <TASK> __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 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106 ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154 make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455 ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796 ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431 vfs_symlink+0x137/0x2e0 fs/namei.c:4615 do_symlinkat+0x222/0x3a0 fs/namei.c:4641 __do_sys_symlink fs/namei.c:4662 [inline] __se_sys_symlink fs/namei.c:4660 [inline] __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660 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 </TASK> The following loop is located right above 'if' statement. for (i = count-1; i >= 0; i--) { /* is more than half of this entry in 2nd half of the block? */ if (size + map[i].size/2 > blocksize/2) break; size += map[i].size; move++; } 'i' in this case could go down to -1, in which case sum of active entries wouldn't exceed half the block size, but previous behaviour would also do split in half if sum would exceed at the very last block, which in case of having too many long name files in a single block could lead to out-of-bounds access and following use-after-free. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. CVE-2025-23150 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: PCI: vmd: Make vmd_dev::cfg_lock a raw_spinlock_t type The access to the PCI config space via pci_ops::read and pci_ops::write is a low-level hardware access. The functions can be accessed with disabled interrupts even on PREEMPT_RT. The pci_lock is a raw_spinlock_t for this purpose. A spinlock_t becomes a sleeping lock on PREEMPT_RT, so it cannot be acquired with disabled interrupts. The vmd_dev::cfg_lock is accessed in the same context as the pci_lock. Make vmd_dev::cfg_lock a raw_spinlock_t type so it can be used with interrupts disabled. This was reported as: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 Call Trace: rt_spin_lock+0x4e/0x130 vmd_pci_read+0x8d/0x100 [vmd] pci_user_read_config_byte+0x6f/0xe0 pci_read_config+0xfe/0x290 sysfs_kf_bin_read+0x68/0x90 [bigeasy: reword commit message] Tested-off-by: Luis Claudio R. Goncalves <lgoncalv@redhat.com> [kwilczynski: commit log] [bhelgaas: add back report info from https://lore.kernel.org/lkml/20241218115951.83062-1-ryotkkr98@gmail.com/] CVE-2025-23161 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate numbers.c in libxslt before 1.1.43 has a use-after-free because, in nested XPath evaluations, an XPath context node can be modified but never restored. This is related to xsltNumberFormatGetValue, xsltEvalXPathPredicate, xsltEvalXPathStringNs, and xsltComputeSortResultInternal. CVE-2025-24855 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libxslt-tools-1.1.28-17.18.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libxslt1-1.1.28-17.18.1 important A vulnerability has been found in Hercules Augeas 1.14.1 and classified as problematic. This vulnerability affects the function re_case_expand of the file src/fa.c. The manipulation of the argument re leads to null pointer dereference. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used. CVE-2025-2588 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:augeas-1.10.1-4.6.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:augeas-lenses-1.10.1-4.6.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libaugeas0-1.10.1-4.6.1 low In SQLite 3.44.0 through 3.49.0 before 3.49.1, the concat_ws() SQL function can cause memory to be written beyond the end of a malloc-allocated buffer. If the separator argument is attacker-controlled and has a large string (e.g., 2MB or more), an integer overflow occurs in calculating the size of the result buffer, and thus malloc may not allocate enough memory. CVE-2025-29087 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libsqlite3-0-3.49.1-9.33.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:sqlite3-3.49.1-9.33.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:sqlite3-tcl-3.49.1-9.33.1 moderate In SQLite 3.49.0 before 3.49.1, certain argument values to sqlite3_db_config (in the C-language API) can cause a denial of service (application crash). An sz*nBig multiplication is not cast to a 64-bit integer, and consequently some memory allocations may be incorrect. CVE-2025-29088 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libsqlite3-0-3.49.1-9.33.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:sqlite3-3.49.1-9.33.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:sqlite3-tcl-3.49.1-9.33.1 moderate Vim, a text editor, is vulnerable to potential data loss with zip.vim and special crafted zip files in versions prior to 9.1.1198. The impact is medium because a user must be made to view such an archive with Vim and then press 'x' on such a strange filename. The issue has been fixed as of Vim patch v9.1.1198. CVE-2025-29768 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:vim-9.1.1406-17.48.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:vim-data-common-9.1.1406-17.48.1 moderate In libxml2 before 2.13.8 and 2.14.x before 2.14.2, out-of-bounds memory access can occur in the Python API (Python bindings) because of an incorrect return value. This occurs in xmlPythonFileRead and xmlPythonFileReadRaw because of a difference between bytes and characters. CVE-2025-32414 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libxml2-2-2.9.4-46.84.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libxml2-tools-2.9.4-46.84.1 moderate In libxml2 before 2.13.8 and 2.14.x before 2.14.2, xmlSchemaIDCFillNodeTables in xmlschemas.c has a heap-based buffer under-read. To exploit this, a crafted XML document must be validated against an XML schema with certain identity constraints, or a crafted XML schema must be used. CVE-2025-32415 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libxml2-2-2.9.4-46.84.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libxml2-tools-2.9.4-46.84.1 low Sudo before 1.9.17p1, when used with a sudoers file that specifies a host that is neither the current host nor ALL, allows listed users to execute commands on unintended machines. CVE-2025-32462 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:sudo-1.8.27-4.54.1 important In the Linux kernel, the following vulnerability has been resolved: net: ppp: Add bound checking for skb data on ppp_sync_txmung Ensure we have enough data in linear buffer from skb before accessing initial bytes. This prevents potential out-of-bounds accesses when processing short packets. When ppp_sync_txmung receives an incoming package with an empty payload: (remote) gef>> p *(struct pppoe_hdr *) (skb->head + skb->network_header) $18 = { type = 0x1, ver = 0x1, code = 0x0, sid = 0x2, length = 0x0, tag = 0xffff8880371cdb96 } from the skb struct (trimmed) tail = 0x16, end = 0x140, head = 0xffff88803346f400 "4", data = 0xffff88803346f416 ":\377", truesize = 0x380, len = 0x0, data_len = 0x0, mac_len = 0xe, hdr_len = 0x0, it is not safe to access data[2]. [pabeni@redhat.com: fixed subj typo] CVE-2025-37749 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net_sched: sch_sfq: move the limit validation It is not sufficient to directly validate the limit on the data that the user passes as it can be updated based on how the other parameters are changed. Move the check at the end of the configuration update process to also catch scenarios where the limit is indirectly updated, for example with the following configurations: tc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 depth 1 tc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 divisor 1 This fixes the following syzkaller reported crash: ------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:203:6 index 65535 is out of range for type 'struct sfq_head[128]' CPU: 1 UID: 0 PID: 3037 Comm: syz.2.16 Not tainted 6.14.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x201/0x300 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_out_of_bounds+0xf5/0x120 lib/ubsan.c:429 sfq_link net/sched/sch_sfq.c:203 [inline] sfq_dec+0x53c/0x610 net/sched/sch_sfq.c:231 sfq_dequeue+0x34e/0x8c0 net/sched/sch_sfq.c:493 sfq_reset+0x17/0x60 net/sched/sch_sfq.c:518 qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035 tbf_reset+0x41/0x110 net/sched/sch_tbf.c:339 qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035 dev_reset_queue+0x100/0x1b0 net/sched/sch_generic.c:1311 netdev_for_each_tx_queue include/linux/netdevice.h:2590 [inline] dev_deactivate_many+0x7e5/0xe70 net/sched/sch_generic.c:1375 CVE-2025-37752 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 important In the Linux kernel, the following vulnerability has been resolved: isofs: Prevent the use of too small fid syzbot reported a slab-out-of-bounds Read in isofs_fh_to_parent. [1] The handle_bytes value passed in by the reproducing program is equal to 12. In handle_to_path(), only 12 bytes of memory are allocated for the structure file_handle->f_handle member, which causes an out-of-bounds access when accessing the member parent_block of the structure isofs_fid in isofs, because accessing parent_block requires at least 16 bytes of f_handle. Here, fh_len is used to indirectly confirm that the value of handle_bytes is greater than 3 before accessing parent_block. [1] BUG: KASAN: slab-out-of-bounds in isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183 Read of size 4 at addr ffff0000cc030d94 by task syz-executor215/6466 CPU: 1 UID: 0 PID: 6466 Comm: syz-executor215 Not tainted 6.14.0-rc7-syzkaller-ga2392f333575 #0 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 lib/dump_stack.c:94 [inline] dump_stack_lvl+0xe4/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0x198/0x550 mm/kasan/report.c:521 kasan_report+0xd8/0x138 mm/kasan/report.c:634 __asan_report_load4_noabort+0x20/0x2c mm/kasan/report_generic.c:380 isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183 exportfs_decode_fh_raw+0x2dc/0x608 fs/exportfs/expfs.c:523 do_handle_to_path+0xa0/0x198 fs/fhandle.c:257 handle_to_path fs/fhandle.c:385 [inline] do_handle_open+0x8cc/0xb8c fs/fhandle.c:403 __do_sys_open_by_handle_at fs/fhandle.c:443 [inline] __se_sys_open_by_handle_at fs/fhandle.c:434 [inline] __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 Allocated by task 6466: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_alloc_info+0x40/0x50 mm/kasan/generic.c:562 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xac/0xc4 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4294 [inline] __kmalloc_noprof+0x32c/0x54c mm/slub.c:4306 kmalloc_noprof include/linux/slab.h:905 [inline] handle_to_path fs/fhandle.c:357 [inline] do_handle_open+0x5a4/0xb8c fs/fhandle.c:403 __do_sys_open_by_handle_at fs/fhandle.c:443 [inline] __se_sys_open_by_handle_at fs/fhandle.c:434 [inline] __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 CVE-2025-37780 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. CVE-2025-37782 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: ext4: fix OOB read when checking dotdot dir Mounting a corrupted filesystem with directory which contains '.' dir entry with rec_len == block size results in out-of-bounds read (later on, when the corrupted directory is removed). ext4_empty_dir() assumes every ext4 directory contains at least '.' and '..' as directory entries in the first data block. It first loads the '.' dir entry, performs sanity checks by calling ext4_check_dir_entry() and then uses its rec_len member to compute the location of '..' dir entry (in ext4_next_entry). It assumes the '..' dir entry fits into the same data block. If the rec_len of '.' is precisely one block (4KB), it slips through the sanity checks (it is considered the last directory entry in the data block) and leaves "struct ext4_dir_entry_2 *de" point exactly past the memory slot allocated to the data block. The following call to ext4_check_dir_entry() on new value of de then dereferences this pointer which results in out-of-bounds mem access. Fix this by extending __ext4_check_dir_entry() to check for '.' dir entries that reach the end of data block. Make sure to ignore the phony dir entries for checksum (by checking name_len for non-zero). Note: This is reported by KASAN as use-after-free in case another structure was recently freed from the slot past the bound, but it is really an OOB read. This issue was found by syzkaller tool. Call Trace: [ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710 [ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375 [ 38.595158] [ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1 [ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 38.595304] Call Trace: [ 38.595308] <TASK> [ 38.595311] dump_stack_lvl+0xa7/0xd0 [ 38.595325] print_address_description.constprop.0+0x2c/0x3f0 [ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595349] print_report+0xaa/0x250 [ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595368] ? kasan_addr_to_slab+0x9/0x90 [ 38.595378] kasan_report+0xab/0xe0 [ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595400] __ext4_check_dir_entry+0x67e/0x710 [ 38.595410] ext4_empty_dir+0x465/0x990 [ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10 [ 38.595432] ext4_rmdir.part.0+0x29a/0xd10 [ 38.595441] ? __dquot_initialize+0x2a7/0xbf0 [ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10 [ 38.595464] ? __pfx___dquot_initialize+0x10/0x10 [ 38.595478] ? down_write+0xdb/0x140 [ 38.595487] ? __pfx_down_write+0x10/0x10 [ 38.595497] ext4_rmdir+0xee/0x140 [ 38.595506] vfs_rmdir+0x209/0x670 [ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190 [ 38.595529] do_rmdir+0x363/0x3c0 [ 38.595537] ? __pfx_do_rmdir+0x10/0x10 [ 38.595544] ? strncpy_from_user+0x1ff/0x2e0 [ 38.595561] __x64_sys_unlinkat+0xf0/0x130 [ 38.595570] do_syscall_64+0x5b/0x180 [ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e CVE-2025-37785 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix nested key length validation in the set() action It's not safe to access nla_len(ovs_key) if the data is smaller than the netlink header. Check that the attribute is OK first. CVE-2025-37789 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: Purge vif txq in ieee80211_do_stop() After ieee80211_do_stop() SKB from vif's txq could still be processed. Indeed another concurrent vif schedule_and_wake_txq call could cause those packets to be dequeued (see ieee80211_handle_wake_tx_queue()) without checking the sdata current state. Because vif.drv_priv is now cleared in this function, this could lead to driver crash. For example in ath12k, ahvif is store in vif.drv_priv. Thus if ath12k_mac_op_tx() is called after ieee80211_do_stop(), ahvif->ah can be NULL, leading the ath12k_warn(ahvif->ah,...) call in this function to trigger the NULL deref below. Unable to handle kernel paging request at virtual address dfffffc000000001 KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] batman_adv: bat0: Interface deactivated: brbh1337 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [dfffffc000000001] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP CPU: 1 UID: 0 PID: 978 Comm: lbd Not tainted 6.13.0-g633f875b8f1e #114 Hardware name: HW (DT) pstate: 10000005 (nzcV daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] lr : ath12k_mac_op_tx+0x174/0x29b8 [ath12k] sp : ffffffc086ace450 x29: ffffffc086ace450 x28: 0000000000000000 x27: 1ffffff810d59ca4 x26: ffffff801d05f7c0 x25: 0000000000000000 x24: 000000004000001e x23: ffffff8009ce4926 x22: ffffff801f9c0800 x21: ffffff801d05f7f0 x20: ffffff8034a19f40 x19: 0000000000000000 x18: ffffff801f9c0958 x17: ffffff800bc0a504 x16: dfffffc000000000 x15: ffffffc086ace4f8 x14: ffffff801d05f83c x13: 0000000000000000 x12: ffffffb003a0bf03 x11: 0000000000000000 x10: ffffffb003a0bf02 x9 : ffffff8034a19f40 x8 : ffffff801d05f818 x7 : 1ffffff0069433dc x6 : ffffff8034a19ee0 x5 : ffffff801d05f7f0 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000008 Call trace: ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] (P) ieee80211_handle_wake_tx_queue+0x16c/0x260 ieee80211_queue_skb+0xeec/0x1d20 ieee80211_tx+0x200/0x2c8 ieee80211_xmit+0x22c/0x338 __ieee80211_subif_start_xmit+0x7e8/0xc60 ieee80211_subif_start_xmit+0xc4/0xee0 __ieee80211_subif_start_xmit_8023.isra.0+0x854/0x17a0 ieee80211_subif_start_xmit_8023+0x124/0x488 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 br_dev_queue_push_xmit+0x120/0x4a8 __br_forward+0xe4/0x2b0 deliver_clone+0x5c/0xd0 br_flood+0x398/0x580 br_dev_xmit+0x454/0x9f8 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 ip6_finish_output2+0xc28/0x1b60 __ip6_finish_output+0x38c/0x638 ip6_output+0x1b4/0x338 ip6_local_out+0x7c/0xa8 ip6_send_skb+0x7c/0x1b0 ip6_push_pending_frames+0x94/0xd0 rawv6_sendmsg+0x1a98/0x2898 inet_sendmsg+0x94/0xe0 __sys_sendto+0x1e4/0x308 __arm64_sys_sendto+0xc4/0x140 do_el0_svc+0x110/0x280 el0_svc+0x20/0x60 el0t_64_sync_handler+0x104/0x138 el0t_64_sync+0x154/0x158 To avoid that, empty vif's txq at ieee80211_do_stop() so no packet could be dequeued after ieee80211_do_stop() (new packets cannot be queued because SDATA_STATE_RUNNING is cleared at this point). CVE-2025-37794 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: at76c50x: fix use after free access in at76_disconnect The memory pointed to by priv is freed at the end of at76_delete_device function (using ieee80211_free_hw). But the code then accesses the udev field of the freed object to put the USB device. This may also lead to a memory leak of the usb device. Fix this by using udev from interface. CVE-2025-37796 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net_sched: hfsc: Fix a UAF vulnerability in class handling This patch fixes a Use-After-Free vulnerability in the HFSC qdisc class handling. The issue occurs due to a time-of-check/time-of-use condition in hfsc_change_class() when working with certain child qdiscs like netem or codel. The vulnerability works as follows: 1. hfsc_change_class() checks if a class has packets (q.qlen != 0) 2. It then calls qdisc_peek_len(), which for certain qdiscs (e.g., codel, netem) might drop packets and empty the queue 3. The code continues assuming the queue is still non-empty, adding the class to vttree 4. This breaks HFSC scheduler assumptions that only non-empty classes are in vttree 5. Later, when the class is destroyed, this can lead to a Use-After-Free The fix adds a second queue length check after qdisc_peek_len() to verify the queue wasn't emptied. CVE-2025-37797 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 important In the Linux kernel, the following vulnerability has been resolved: codel: remove sch->q.qlen check before qdisc_tree_reduce_backlog() After making all ->qlen_notify() callbacks idempotent, now it is safe to remove the check of qlen!=0 from both fq_codel_dequeue() and codel_qdisc_dequeue(). CVE-2025-37798 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 important In the Linux kernel, the following vulnerability has been resolved: net_sched: hfsc: Fix a potential UAF in hfsc_dequeue() too Similarly to the previous patch, we need to safe guard hfsc_dequeue() too. But for this one, we don't have a reliable reproducer. CVE-2025-37823 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net/niu: Niu requires MSIX ENTRY_DATA fields touch before entry reads Fix niu_try_msix() to not cause a fatal trap on sparc systems. Set PCI_DEV_FLAGS_MSIX_TOUCH_ENTRY_DATA_FIRST on the struct pci_dev to work around a bug in the hardware or firmware. For each vector entry in the msix table, niu chips will cause a fatal trap if any registers in that entry are read before that entries' ENTRY_DATA register is written to. Testing indicates writes to other registers are not sufficient to prevent the fatal trap, however the value does not appear to matter. This only needs to happen once after power up, so simply rebooting into a kernel lacking this fix will NOT cause the trap. NON-RESUMABLE ERROR: Reporting on cpu 64 NON-RESUMABLE ERROR: TPC [0x00000000005f6900] <msix_prepare_msi_desc+0x90/0xa0> NON-RESUMABLE ERROR: RAW [4010000000000016:00000e37f93e32ff:0000000202000080:ffffffffffffffff NON-RESUMABLE ERROR: 0000000800000000:0000000000000000:0000000000000000:0000000000000000] NON-RESUMABLE ERROR: handle [0x4010000000000016] stick [0x00000e37f93e32ff] NON-RESUMABLE ERROR: type [precise nonresumable] NON-RESUMABLE ERROR: attrs [0x02000080] < ASI sp-faulted priv > NON-RESUMABLE ERROR: raddr [0xffffffffffffffff] NON-RESUMABLE ERROR: insn effective address [0x000000c50020000c] NON-RESUMABLE ERROR: size [0x8] NON-RESUMABLE ERROR: asi [0x00] CPU: 64 UID: 0 PID: 745 Comm: kworker/64:1 Not tainted 6.11.5 #63 Workqueue: events work_for_cpu_fn TSTATE: 0000000011001602 TPC: 00000000005f6900 TNPC: 00000000005f6904 Y: 00000000 Not tainted TPC: <msix_prepare_msi_desc+0x90/0xa0> g0: 00000000000002e9 g1: 000000000000000c g2: 000000c50020000c g3: 0000000000000100 g4: ffff8000470307c0 g5: ffff800fec5be000 g6: ffff800047a08000 g7: 0000000000000000 o0: ffff800014feb000 o1: ffff800047a0b620 o2: 0000000000000011 o3: ffff800047a0b620 o4: 0000000000000080 o5: 0000000000000011 sp: ffff800047a0ad51 ret_pc: 00000000005f7128 RPC: <__pci_enable_msix_range+0x3cc/0x460> l0: 000000000000000d l1: 000000000000c01f l2: ffff800014feb0a8 l3: 0000000000000020 l4: 000000000000c000 l5: 0000000000000001 l6: 0000000020000000 l7: ffff800047a0b734 i0: ffff800014feb000 i1: ffff800047a0b730 i2: 0000000000000001 i3: 000000000000000d i4: 0000000000000000 i5: 0000000000000000 i6: ffff800047a0ae81 i7: 00000000101888b0 I7: <niu_try_msix.constprop.0+0xc0/0x130 [niu]> Call Trace: [<00000000101888b0>] niu_try_msix.constprop.0+0xc0/0x130 [niu] [<000000001018f840>] niu_get_invariants+0x183c/0x207c [niu] [<00000000101902fc>] niu_pci_init_one+0x27c/0x2fc [niu] [<00000000005ef3e4>] local_pci_probe+0x28/0x74 [<0000000000469240>] work_for_cpu_fn+0x8/0x1c [<000000000046b008>] process_scheduled_works+0x144/0x210 [<000000000046b518>] worker_thread+0x13c/0x1c0 [<00000000004710e0>] kthread+0xb8/0xc8 [<00000000004060c8>] ret_from_fork+0x1c/0x2c [<0000000000000000>] 0x0 Kernel panic - not syncing: Non-resumable error. CVE-2025-37833 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: handle amdgpu_cgs_create_device() errors in amd_powerplay_create() Add error handling to propagate amdgpu_cgs_create_device() failures to the caller. When amdgpu_cgs_create_device() fails, release hwmgr and return -ENOMEM to prevent null pointer dereference. [v1]->[v2]: Change error code from -EINVAL to -ENOMEM. Free hwmgr. CVE-2025-37852 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: 9p/net: fix improper handling of bogus negative read/write replies In p9_client_write() and p9_client_read_once(), if the server incorrectly replies with success but a negative write/read count then we would consider written (negative) <= rsize (positive) because both variables were signed. Make variables unsigned to avoid this problem. The reproducer linked below now fails with the following error instead of a null pointer deref: 9pnet: bogus RWRITE count (4294967295 > 3) CVE-2025-37879 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: arm64: bpf: Add BHB mitigation to the epilogue for cBPF programs A malicious BPF program may manipulate the branch history to influence what the hardware speculates will happen next. On exit from a BPF program, emit the BHB mititgation sequence. This is only applied for 'classic' cBPF programs that are loaded by seccomp. CVE-2025-37948 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: xenbus: Use kref to track req lifetime Marek reported seeing a NULL pointer fault in the xenbus_thread callstack: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: e030:__wake_up_common+0x4c/0x180 Call Trace: <TASK> __wake_up_common_lock+0x82/0xd0 process_msg+0x18e/0x2f0 xenbus_thread+0x165/0x1c0 process_msg+0x18e is req->cb(req). req->cb is set to xs_wake_up(), a thin wrapper around wake_up(), or xenbus_dev_queue_reply(). It seems like it was xs_wake_up() in this case. It seems like req may have woken up the xs_wait_for_reply(), which kfree()ed the req. When xenbus_thread resumes, it faults on the zero-ed data. Linux Device Drivers 2nd edition states: "Normally, a wake_up call can cause an immediate reschedule to happen, meaning that other processes might run before wake_up returns." ... which would match the behaviour observed. Change to keeping two krefs on each request. One for the caller, and one for xenbus_thread. Each will kref_put() when finished, and the last will free it. This use of kref matches the description in Documentation/core-api/kref.rst CVE-2025-37949 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: arm64: bpf: Only mitigate cBPF programs loaded by unprivileged users Support for eBPF programs loaded by unprivileged users is typically disabled. This means only cBPF programs need to be mitigated for BHB. In addition, only mitigate cBPF programs that were loaded by an unprivileged user. Privileged users can also load the same program via eBPF, making the mitigation pointless. CVE-2025-37963 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 low In the Linux kernel, the following vulnerability has been resolved: net: phy: leds: fix memory leak A network restart test on a router led to an out-of-memory condition, which was traced to a memory leak in the PHY LED trigger code. The root cause is misuse of the devm API. The registration function (phy_led_triggers_register) is called from phy_attach_direct, not phy_probe, and the unregister function (phy_led_triggers_unregister) is called from phy_detach, not phy_remove. This means the register and unregister functions can be called multiple times for the same PHY device, but devm-allocated memory is not freed until the driver is unbound. This also prevents kmemleak from detecting the leak, as the devm API internally stores the allocated pointer. Fix this by replacing devm_kzalloc/devm_kcalloc with standard kzalloc/kcalloc, and add the corresponding kfree calls in the unregister path. CVE-2025-37989 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate In the Linux kernel, the following vulnerability has been resolved: net_sched: skbprio: Remove overly strict queue assertions In the current implementation, skbprio enqueue/dequeue contains an assertion that fails under certain conditions when SKBPRIO is used as a child qdisc under TBF with specific parameters. The failure occurs because TBF sometimes peeks at packets in the child qdisc without actually dequeuing them when tokens are unavailable. This peek operation creates a discrepancy between the parent and child qdisc queue length counters. When TBF later receives a high-priority packet, SKBPRIO's queue length may show a different value than what's reflected in its internal priority queue tracking, triggering the assertion. The fix removes this overly strict assertions in SKBPRIO, they are not necessary at all. CVE-2025-38637 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:cluster-md-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:dlm-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:gfs2-kmp-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:kernel-default-4.12.14-122.261.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:ocfs2-kmp-default-4.12.14-122.261.1 moderate Perl threads have a working directory race condition where file operations may target unintended paths. If a directory handle is open at thread creation, the process-wide current working directory is temporarily changed in order to clone that handle for the new thread, which is visible from any third (or more) thread already running. This may lead to unintended operations such as loading code or accessing files from unexpected locations, which a local attacker may be able to exploit. The bug was introduced in commit 11a11ecf4bea72b17d250cfb43c897be1341861e and released in Perl version 5.13.6 CVE-2025-40909 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:perl-5.18.2-12.29.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:perl-base-5.18.2-12.29.1 moderate A flaw was found in GLib, which is vulnerable to an integer overflow in the g_string_insert_unichar() function. When the position at which to insert the character is large, the position will overflow, leading to a buffer underwrite. CVE-2025-4373 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:glib2-tools-2.48.2-12.46.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libgio-2_0-0-2.48.2-12.46.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libglib-2_0-0-2.48.2-12.46.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libgmodule-2_0-0-2.48.2-12.46.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libgobject-2_0-0-2.48.2-12.46.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libgthread-2_0-0-2.48.2-12.46.1 moderate A vulnerability was found in systemd-coredump. This flaw allows an attacker to force a SUID process to crash and replace it with a non-SUID binary to access the original's privileged process coredump, allowing the attacker to read sensitive data, such as /etc/shadow content, loaded by the original process. A SUID binary or process has a special type of permission, which allows the process to run with the file owner's permissions, regardless of the user executing the binary. This allows the process to access more restricted data than unprivileged users or processes would be able to. An attacker can leverage this flaw by forcing a SUID process to crash and force the Linux kernel to recycle the process PID before systemd-coredump can analyze the /proc/pid/auxv file. If the attacker wins the race condition, they gain access to the original's SUID process coredump file. They can read sensitive content loaded into memory by the original binary, affecting data confidentiality. CVE-2025-4598 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libsystemd0-228-157.72.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libudev1-228-157.72.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:systemd-228-157.72.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:systemd-sysvinit-228-157.72.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:udev-228-157.72.1 moderate For a short time they PTY is set to mode 666, allowing any user on the system to connect to the screen session. CVE-2025-46802 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:screen-4.0.4-23.9.1 moderate ping in iputils before 20250602 allows a denial of service (application error or incorrect data collection) via a crafted ICMP Echo Reply packet, because of a signed 64-bit integer overflow in timestamp multiplication. CVE-2025-47268 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:iputils-s20161105-11.9.1 moderate setuptools is a package that allows users to download, build, install, upgrade, and uninstall Python packages. A path traversal vulnerability in `PackageIndex` is present in setuptools prior to version 78.1.1. An attacker would be allowed to write files to arbitrary locations on the filesystem with the permissions of the process running the Python code, which could escalate to remote code execution depending on the context. Version 78.1.1 fixes the issue. CVE-2025-47273 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:python-setuptools-40.6.2-4.27.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:python3-setuptools-40.6.2-4.27.1 important A stack buffer overflow was found in Internationl components for unicode (ICU ). While running the genrb binary, the 'subtag' struct overflowed at the SRBRoot::addTag function. This issue may lead to memory corruption and local arbitrary code execution. CVE-2025-5222 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libicu52_1-52.1-8.16.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:libicu52_1-data-52.1-8.16.1 important A Local Privilege Escalation (LPE) vulnerability has been discovered in pam-config within Linux Pluggable Authentication Modules (PAM). This flaw allows an unprivileged local attacker (for example, a user logged in via SSH) to obtain the elevated privileges normally reserved for a physically present, "allow_active" user. The highest risk is that the attacker can then perform all allow_active yes Polkit actions, which are typically restricted to console users, potentially gaining unauthorized control over system configurations, services, or other sensitive operations. CVE-2025-6018 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:pam-1.1.8-24.71.1 Public Cloud Image google/sles-12-sp5-sap-v20250709-x86-64:pam-config-0.89-5.8.1 important