<?xml version="1.0" encoding="UTF-8"?>
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1" xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.1">
  <DocumentTitle xml:lang="en">SUSE-IU-2025:16-1</DocumentTitle>
  <DocumentType>SUSE Image</DocumentType>
  <DocumentPublisher Type="Vendor">
    <ContactDetails>security@suse.de</ContactDetails>
    <IssuingAuthority>SUSE Security Team</IssuingAuthority>
  </DocumentPublisher>
  <DocumentTracking>
    <Identification>
      <ID>SUSE Image SUSE-IU-2025:16-1</ID>
    </Identification>
    <Status>Interim</Status>
    <Version>1</Version>
    <RevisionHistory>
      <Revision>
        <Number>1</Number>
        <Date>2025-09-24T18:42:28Z</Date>
        <Description>current</Description>
      </Revision>
    </RevisionHistory>
    <InitialReleaseDate>2025-01-07T01:00:00Z</InitialReleaseDate>
    <CurrentReleaseDate>2025-01-07T01:00:00Z</CurrentReleaseDate>
    <Generator>
      <Engine>cve-database/bin/generate-cvrf-publiccloud.pl</Engine>
      <Date>2021-02-18T01:00:00Z</Date>
    </Generator>
  </DocumentTracking>
  <DocumentNotes>
    <Note Title="Topic" Type="Summary" Ordinal="1" xml:lang="en">Image update for SUSE-IU-2025:16-1 / google/sles-12-sp5-byos-v20250107-x86-64</Note>
    <Note Title="Details" Type="General" Ordinal="2" xml:lang="en">This image update for google/sles-12-sp5-byos-v20250107-x86-64 contains the following changes:
Package ruby2.1 was updated:

- Add CVE-2024-47220.patch (CVE-2024-47220) Fix HTTP request  smuggling (boo#1230930)

Package expat was updated:

- security update- added patches
  fix CVE-2024-50602 [bsc#1232579], DoS via XML_ResumeParser
  + expat-CVE-2024-50602.patch

Package python36 was updated:

- Remove -IVendor/ from python-config boo#1231795- Fix CVE-2024-11168-validation-IPv6-addrs.patch
- PGO run of build freezes with parallel processing, switch to -j1

- Add CVE-2024-11168-validation-IPv6-addrs.patch
  fixing bsc#1233307 (CVE-2024-11168,
  gh#python/cpython#103848): Improper validation of IPv6 and
  IPvFuture addresses.

- Add CVE-2024-9287-venv_path_unquoted.patch to properly quote
  path names provided when creating a virtual environment
  (bsc#1232241, CVE-2024-9287)

- Drop .pyc files from docdir for reproducible builds
  (bsc#1230906).

Package google-osconfig-agent was updated:

- Update to version 20240926.03 (bsc#1231775, bsc#1231776)  * Revert &amp;quot;Bump go.opentelemetry.io/otel from 1.24.0 to 1.30.0 (#679)&amp;quot; (#684)
- from version 20240926.02
  * Bump go.opentelemetry.io/otel from 1.24.0 to 1.30.0 (#679)
  * another batch of depencies upgrade (#683)
- from version 20240926.01
  * aggregate dependabot changes to go.mod (#677)
  * Revert back Source package info delivery to control-plane (#673)
- from version 20240926.00
  * Update OWNERS (#676)
- from version 20240924.02
  * Upgrade grpc and it's dependencies to latest version (#672)
- from version 20240924.01
  * Implement keepalive config (#671)
- from version 20240924.00
  * Set new version of gRPC for test (#669)
- from version 20240920.00
  * Revert &amp;quot;bump version of the gRPC&amp;quot; (#667)
- from version 20240919.00
  * bump version of the gRPC (#666)
- from version 20240917.00
  * Merge pull request #665 from GoogleCloudPlatform/revert-664-update_grpc_dependency
  * Revert &amp;quot;Update grpc library and other dependencies. (#664)&amp;quot;
- from version 20240916.00
  * Update grpc library and other dependencies. (#664)
- from version 20240913.00
  * Move packagebuild presubmit to osconfig (#662)
- from version 20240912.00
  * Revert &amp;quot;update osconfig api to v1.13.0 &amp;amp; indirect dependency update&amp;quot; (#659)
- from version 20240822.00
  * Revert &amp;quot;Source package info delivery to control-plane (#639)&amp;quot; (#656)
- from version 20240821.00
  * Fix golang version format to fix builds. (#655)
- from version 20240814.01
  * Use gcsfuse pkg in guest-policies e2e in pkg
    update tests instead of old pkgs (#653)
  * Replace osconfig-agent-test pkg by gcsfuse in ospolicies
    tests and inventory-report tests (#652)
- from version 20240806.00
  * Disable Repository Resource test for SLES-12 (#650)

- Update to version 20240801.00
  * Fix Debian-12 failing test by using gcsfuse pkg
  * Fix fetching gpg key unit tests (#649)
- from version 20240729.00
  * Fix for old state file on Windows (#648)
- from version 20240723.00
  * Add debugging logs for repository resource config (#646)
- from version 20240718.00
  * Fix SLES-12 SP5 RPM package-resource e2e test (#645)
- from version 20240715.01
  * Fix OSPolicies e2e tests for SLES-15 SP5 by removing
    zypper update from VMs startup script (#644)
- from version 20240715.00
  * Fix GuestPolicies e2e tests for SLES-15 SP5 by removing
    zypper update from VMs startup script (#643)
- from version 20240709.01
  * Source package info delivery to control-plane (#639)
- from version 20240709.00
  * Enable gpgcheck flag for RPM e2e tests (#638)
- from version 20240708.00
  * Update osconfig api to v1.13.0
  * Indirect dependency update (#637)
- from version 20240705.01
  * Updating Windows &amp;amp; Linux Chrome packages
    to fix failing e2e tests (#636)
- from version 20240705.00
  * Merge pull request #635 from Gulio/patch-1
  * Update OWNERS
- from version 20240702.02
  * Remove RHEL-7 and CentOS-7 images from e2e tests (#634)

- Update to version 20240702.01
  * Use Debian-11 img in googet pkg build workflow (#632)
- from version 20240702.00
  * Pipeline testing 00 (#631)
- from version 20240701.00
  * update readme file (#628)
- from version 20240625.01
  * Updating yum install to support multi architecture based packages
  * Revert &amp;quot;Adding Architecture to the packages being installed/updated in yum repo&amp;quot;
- from version 20240625.00
  * Update old SLES images urls (#627)
- from version 20240620.00
  * Merge pull request #626 from GoogleCloudPlatform/yum-multiarch-fix
  * Adding Architecture to the packages being installed/updated in yum repo
- from version 20240618.01
  * Extract source_name(source_rpm) for rpm packages (#624)
- from version 20240618.00
  * update README.md file (#625)
- from version 20240615.00
  * Fix(dpkg) return onlt installed items as inventory (#623)
  * Extract source name and version for dpkg packages. (#622)

- Update to version 20240607.00
  * Update e2e tests to use VMM team's GCP project for pkgs testing version (#621)
- from version 20240606.00
  * Disable SUSE tests to run with testing agent repo (#619)
- from version 20240604.00
  * Fix the logic of pick region for Artifact Registry function (#618)
- from version 20240603.00
  * Disable centos-stream-8 tests as it reached EOL in May 31 (#617)
- from version 20240529.00
  * Merge pull request #610 from savijatv/patch-3
  * Update cis-level1-once-a-day-policy.yaml
- from version 20240528.00
  * Merge pull request #616 from MahmoudOuka/allow-windows-e2e-tests-to-\
    install-testing-version-of-agent-from-private-artifact-registry-repos
  * Allow Windows e2e tests to pull osconfig-agent pkg from testing (private)
    repos from Artifact registry
- from version 20240527.01
  * Merge pull request #615 from MahmoudOuka/fix-SUSE-e2e-tests
  * fix SUSE e2e tests
- from version 20240527.00
  * Merge pull request #614 from MahmoudOuka/allow-apt-and-yum-\
    e2e-tests-to-pull-osconfig-agent-pkg-from-testing-repos
  * fix golint comments
  * Allow Apt &amp;amp; Yum e2e tests to pull osconfig-agent pkg from testing repos
- from version 20240524.03
  * Merge pull request #611 from savijatv/patch-ospolicy-samples
  * Update to the CIS OS policy samples
- from version 20240524.00
  * Merge pull request #612 from MahmoudOuka/update-apt-e2e-tests-\
    to-pull-osconfig-agent-pkg-from-new-ar-repos
  * fix golint comment
  * Update Apt e2e tests to pull osconfig-agent pkg from new AR repos instead of rapture
- from version 20240523.02
  * bump golang.org/x/crypto version (#613)
- from version 20240523.00
  * update go-cmp dependency (#604)
- from version 20240522.00
  * rollback masive dependency update (#603)
  * Bump google.golang.org/api from 0.180.0 to 0.181.0 (#596)

- Update to version 20240517.00
  * Bump cloud.google.com/go/auth from 0.4.1 to 0.4.2 (#597)
- from version 20240516.01
  * Bump cloud.google.com/go/logging from 1.9.0 to 1.10.0 (#595)
  * Bump cloud.google.com/go/storage from 1.40.0 to 1.41.0 (#594)
- from version 20240516.00
  * Bump google.golang.org/grpc from 1.63.2 to 1.64.0 (#593)

- Update to version 20240513.02
  * E2e tests: allow passing spesific EL version
    number to InstallOSConfigEL func (#592)
- from version 20240513.01
  * Bump google.golang.org/api from 0.179.0 to 0.180.0 (#591)
- from version 20240513.00
  * E2e tests: Fix EL version detection logic in E2E tests (#590)
  * Bump google.golang.org/api from 0.178.0 to 0.179.0 (#589)
- from version 20240510.02
  * Bump cloud.google.com/go/auth from 0.4.0 to 0.4.1 (#588)
- from version 20240510.01
  * E2e tests: use family url format instead of specific
    version URL for head test images (#587)
- from version 20240510.00
  * Fix for lock location (#586)
- from version 20240509.03
  * Bump cloud.google.com/go from 0.112.2 to 0.113.0 (#584)
- from version 20240509.02
  * Remove dependabot not needed label (#576)
- from version 20240509.01
  * Write inventory to attributes only if enabled (#486)
- from version 20240509.00
  * E2e tests: install gnupg2 and run apt update in VMs startup-scripts (#583)
  * Add a temporary e2e test image for Ubuntu to test
    the latest osconfig-agent stable version (#582)
  * Bump google.golang.org/api from 0.177.0 to 0.178.0 (#578)
  * Bump github.com/googleapis/gax-go/v2 from 2.12.3 to 2.12.4 (#579)
  * Bump cloud.google.com/go/iam from 1.1.7 to 1.1.8 (#577)
  * Bump cloud.google.com/go/auth from 0.3.0 to 0.4.0 (#580)
  * Bump go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc (#581)
  * Bump golang.org/x/net from 0.24.0 to 0.25.0 (#575)
  * Bump cloud.google.com/go/osconfig from 1.12.6 to 1.12.7 (#573)
  * Bump go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp (#574)
  * Bump cloud.google.com/go/longrunning from 0.5.6 to 0.5.7 (#571)
- from version 20240508.08
  * Bump github.com/golang/glog from 1.2.0 to 1.2.1 (#572)
- from version 20240508.07
  * Bump golang.org/x/text from 0.14.0 to 0.15.0 (#565)
- from version 20240508.06
  * Bump golang.org/x/oauth2 from 0.19.0 to 0.20.0 (#566)
  * Bump golang.org/x/sys from 0.19.0 to 0.20.0 (#564)
- from version 20240508.05
  * Bump go.opentelemetry.io/otel/trace from 1.24.0 to 1.26.0 (#563)
- from version 20240508.04
  * Bump google.golang.org/protobuf from 1.34.0 to 1.34.1 (#567)
  * Using the default reviewer set for PR approvals (#570)
- from version 20240508.03
  * Adding advanced CodeQL settings to scan on PRs (#569)
- from version 20240508.02
  * Update Debian-12 package build workflow to use debian-cloud project (#568)
- from version 20240508.01
  * Dependabot dependency updates (#562)
- from version 20240508.00
  * Revert &amp;quot;Initial configuration of the dependabot
    for the direct and indirect dâ¦&amp;quot; (#561)
  * Initial configuration of the dependabot for the
    direct and indirect dependency scanning (#560)
- from version 20240507.00
  * Fix Debian-12 package build workflow typo (#559)
- from version 20240506.00
  * Use signed-by keyring approach for apt repos in Debian 12+ and Ubuntu 24+ (#558)
- from version 20240501.03
  * Logrus dependency update (#557)
- from version 20240501.02
  * Updating dependencies and respective checksums (#556)
- from version 20240501.01
  * Update go.mod (#554)
- from version 20240501.00
  * Bump golang.org/x/net from 0.17.0 to 0.23.0 (#542)
- from version 20240430.01
  * Remove SBOM generation logic from package build workflows (#553)
- from version 20240425.00
  * Fix e2e tests for exec-output size limit (#552)
- from version 20240424.00
  * Disabled some images which are either past EoL or broken (#549)
- from version 20240423.01
  * Copy packagebuild folder from guest-test-infra repo to osconfig repo (#545)
  * OS Config windows state file location changed (#544)
- from version 20240423.00
  * Removed debian-10 from e2e tests (#548)
- from version 20240422.00
  * Merge pull request #541 from GoogleCloudPlatform/michaljankowiak-patch-1
  * Update OWNERS
- from version 20240409.00
  * Bump output size limit to 500KB (#538)

Package wicked was updated:

- Update to version 0.6.77  - compat-suse: use iftype in sysctl handling (bsc#1230911, gh#openSUSE/wicked#1043)
  - Always generate the ipv4/ipv6 &amp;lt;enabled&amp;gt;true|false&amp;lt;/enabled&amp;gt; node
  - Inherit all, default and interface sysctl settings also for loopback,
    except for use_tempaddr and accept_dad.
  - Consider only interface specific accept_redirects sysctl settings.
  - Adopt ifsysctl(5) manual page with wicked specific behavior.
  - route: fix family and destination processing (bsc#1231060)
  - man: improve wicked-config(5) file description (gh#openSUSE/wicked#1039)
  - dhcp4: add ignore-rfc3927-1-6 wicked-config(5) option (jsc#PED-10855, gh#openSUSE/wicked#1038)
  - team: set arp link watcher interval default to 1s (gh#openSUSE/wicked#1037)
  - systemd: use `BindsTo=dbus.service` in favor of `Requisite=` (bsc#1229745)
  - compat-suse: fix use of deprecated `INTERFACETYPE=dummy` (boo#1229555)
  - arp: don't set target broadcast hardware address (gh#openSUSE/wicked#1036)
  - dbus: don't memcpy empty/NULL array value (gh#openSUSE/wicked#1035)
  - ethtool: fix leak and free pause data in ethtool_free (gh#openSUSE/wicked#1030)
- Removed patches included in the source archive:
  [- 0001-compat-suse-repair-dummy-interfaces-boo-1229555.patch]

Package vim was updated:

- Fix for bsc#1231373 / CVE-2024-47814.- Fix for bsc#1229238 / CVE-2024-43374.
- update to 9.1.0836
  * 9.1.0836: The vimtutor can be improved
  * 9.1.0835: :setglobal doesn't work properly for 'ffu' and 'tsrfu'
  * 9.1.0834: tests: 2html test fails
  * 9.1.0833: CI: recent ASAN changes do not work for indent tests
  * 9.1.0832: :set doesn't work for 'cot' and 'bkc' after :setlocal
  * runtime(doc): update help-toc description
  * runtime(2html): Make links use color scheme colors in TOhtml
  * 9.1.0831: 'findexpr' can't be used as lambad or Funcref
  * Filelist: include helptoc package
  * runtime(doc): include a TOC Vim9 plugin
  * Filelist: ignore .git-blame-ignore-revs
  * 9.1.0830: using wrong highlight group for spaces for popupmenu
  * runtime(typst): synchronize updates from the upstream typst.vim
  * git: ignore reformatting commit for git-blame (after v9.1.0829)
  * 9.1.0829: Vim source code uses a mix of tabs and spaces
  * 9.1.0828: string_T struct could be used more often
  * 9.1.0827: CI: tests can be improved
  * runtime(doc): remove stray sentence in pi_netrw.txt
  * 9.1.0826: filetype: sway files are not recognized
  * runtime(doc): Include netrw-gp in TOC
  * runtime(doc): mention 'iskeyword' at :h charclass()
  * runtime(doc): update help tags
  * 9.1.0825: compile error for non-diff builds
  * runtime(netrw): fix E874 when browsing remote directory which contains `~` character
  * runtime(doc): update coding style documentation
  * runtime(debversions): Add plucky (25.04) as Ubuntu release name
  * 9.1.0824: too many strlen() calls in register.c
  * 9.1.0823: filetype: Zephyr overlay files not recognized
  * runtime(doc): Clean up minor formatting issues for builtin functions
  * runtime(netrw): make :Launch/Open autoloadable
  * runtime(netrw): fix regression with x mapping on Cygwin
  * runtime(netrw): fix filetype detection for remote files
  * 9.1.0822: topline might be changed in diff mode unexpectedly
  * CI: huge linux builds should also run syntax &amp;amp; indent tests
  * 9.1.0821: 'findexpr' completion doesn't set v:fname to cmdline argument
  * 9.1.0820: tests: Mac OS tests are too flaky
  * runtime(awk): Highlight more awk comments in syntax script
  * runtime(netrw): add missing change for s:redir()
  * 9.1.0819: tests: using findexpr and imported func not tested
  * runtime(netrw): improve netrw's open-handling further
  * runtime(netrw): fix syntax error in netrwPlugin.vim
  * runtime(netrw): simplify gx file handling
  * 9.1.0818: some global functions are only used in single files
  * 9.1.0817: termdebug: cannot evaluate expr in a popup
  * runtime(defaults): Detect putty terminal and switch to dark background
  * 9.1.0816: tests: not clear what tests cause asan failures
  * runtime(doc): Remove some completed items from todo.txt
  * 9.1.0815: &amp;quot;above&amp;quot; virtual text causes wrong 'colorcolumn' position
  * runtime(syntax-tests): tiny vim fails because of line-continuation
  * 9.1.0814: mapset() may remove unrelated mapping
  * 9.1.0813: no error handling with setglobal and number types
  * 9.1.0812: Coverity warns about dereferencing NULL ptr
  * 9.1.0811: :find expansion does not consider 'findexpr'
  * 9.1.0810: cannot easily adjust the |:find| command
  * 9.1.0809: filetype: petalinux config files not recognized
  * 9.1.0808: Terminal scrollback doesn't shrink when decreasing 'termwinscroll'
  * 9.1.0807: tests: having 'nolist' in modelines isn't always desired
  * 9.1.0806: tests: no error check when setting global 'briopt'
  * 9.1.0805: tests: minor issues in gen_opt_test.vim
  * 9.1.0804: tests: no error check when setting global 'cc'
  * 9.1.0803: tests: no error check when setting global 'isk'
  * 9.1.0802: tests: no error check when setting global 'fdm' to empty value
  * 9.1.0801: tests: no error check when setting global 'termwinkey'
  * 9.1.0800: tests: no error check when setting global 'termwinsize'
  * runtime(doc): :ownsyntax also resets 'spelloptions'
  * 9.1.0799: tests: gettwinvar()/gettabwinvar() tests are not comprehensive
  * runtime(doc): Fix wrong Mac default options
  * 9.1.0798: too many strlen() calls in cmdhist.c
  * 9.1.0797: testing of options can be further improved
  * 9.1.0796: filetype: libtool files are not recognized
  * (typst): add folding to typst ftplugin
  * runtime(netrw): deprecate and remove netrwFileHandlers#Invoke()
  * 9.1.0795: filetype: Vivado memory info file are not recognized
  * 9.1.0794: tests: tests may fail on Windows environment
  * runtime(doc): improve the :colorscheme documentation
  * 9.1.0793: xxd: -e does add one extra space
  * 9.1.0792: tests: Test_set_values() is not comprehensive enough
  * runtime(swayconfig): add flag for bindsym/bindcode to syntax script
  * 9.1.0791: tests: errors in gen_opt_test.vim are not shown
  * runtime(compiler): check for compile_commands in build dirs for cppcheck
  * 9.1.0790: Amiga: AmigaOS4 build should use default runtime (newlib)
  * runtime(help): Update help syntax
  * runtime(help): fix end of sentence highlight in code examples
  * runtime(jinja): Support jinja syntax as secondary filetype
  * 9.1.0789: tests: ':resize + 5' has invalid space after '+'
  * 9.1.0788: &amp;lt;CSI&amp;gt;27;&amp;lt;mod&amp;gt;u is not decoded to literal Escape in kitty/foot
  * 9.1.0787: cursor position changed when using hidden terminal
  * 9.1.0786: tests: quickfix update test does not test location list
  * runtime(doc): add some docs for file-watcher programs
  * CI: uploading failed screendumps still fails on Cirrus CI
  * 9.1.0785: cannot preserve error position when setting quickfix list
  * 9.1.0784: there are several problems with python 3.13
  * 9.1.0783: 'spell' option setting has problems
  * 9.1.0782: tests: using wrong neomuttlog file name
  * runtime(doc): add preview flag to statusline example
  * 9.1.0781: tests: test_filetype fails
  * 9.1.0780: MS-Windows: incorrect Win32 error checking
  * 9.1.0779: filetype: neomuttlog files are not recognized
  * 9.1.0778: filetype: lf config files are not recognized
  * runtime(comment): fix commment toggle with mixed tabs &amp;amp; spaces
  * runtime(misc): Use consistent &amp;quot;Vim script&amp;quot; spelling
  * runtime(gleam): add ftplugin for gleam files
  * runtime(doc): link help-writing from write-local-help
  * 9.1.0777: filetype: Some upstream php files are not recognized
  * runtime(java): Define javaBlockStart and javaBlockOtherStart hl groups
  * runtime(doc): mention conversion rules for remote_expr()
  * runtime(tutor): Fix missing :s command in spanish translation section 4.4
  * 9.1.0776: test_strftime may fail because of missing TZ data
  * translation(am): Add Armenian language translation
  * 9.1.0775: tests: not enough tests for setting options
  * 9.1.0774: &amp;quot;shellcmdline&amp;quot; doesn't work with getcompletion()
  * 9.1.0773: filetype: some Apache files are not recognized
  * 9.1.0772: some missing changes from v9.1.0771
  * 9.1.0771: completion attribute hl_group is confusing
  * 9.1.0770: current command line completion is a bit limited
  * 9.1.0769: filetype: MLIR files are not recognized
  * 9.1.0768: MS-Windows: incorrect cursor position when restoring screen
  * runtime(nasm): Update nasm syntax script
  * 9.1.0767: A condition is always true in ex_getln.c
  * runtime(skill): Update syntax file to fix string escapes
  * runtime(help): highlight CTRL-&amp;lt;Key&amp;gt; correctly
  * runtime(doc): add missing usr_52 entry to toc
  * 9.1.0766: too many strlen() calls in ex_getln.c
  * runtime(doc): correct `vi` registers 1-9 documentation error
  * 9.1.0765: No test for patches 6.2.418 and 7.3.489
  * runtime(spec): set comments and commentstring options
  * NSIS: Include libgcc_s_sjlj-1.dll again
  * runtime(doc): clarify the effect of 'startofline' option
  * 9.1.0764: [security]: use-after-free when closing a buffer
  * runtime(vim): Update base-syntax file, improve class, enum and interface highlighting
  * 9.1.0763: tests: cannot run single syntax tests
  * 9.1.0762: 'cedit', 'termwinkey' and 'wildchar' may not be parsed correctly
  * 9.1.0761: :cd completion fails on Windows with backslash in path
  * 9.1.0760: tests: no error reported, if gen_opt_test.vim fails
  * 9.1.0759: screenpos() may return invalid position
  * runtime(misc): unset compiler in various ftplugins
  * runtime(doc): update formatting and syntax
  * runtime(compiler): add cppcheck linter compiler plugin
  * runtime(doc): Fix style in documents
  * runtime(doc): Fix to two-space convention in user manual
  * runtime(comment): consider &amp;amp;tabstop in lines after whitespace indent
  * 9.1.0758: it's possible to set an invalid key to 'wildcharm'
  * runtime(java): Manage circularity for every :syn-included syntax file
  * 9.1.0757: tests: messages files contains ANSI escape sequences
  * 9.1.0756: missing change from patch v9.1.0754
  * 9.1.0755: quickfix list does not handle hardlinks well
  * runtime(doc): 'filetype', 'syntax' and 'keymap' only allow alphanumeric + some characters
  * runtime(systemd): small fixes to &amp;amp;keywordprg in ftplugin
  * CI: macos-12 runner is being sunset, switch to 13
  * 9.1.0754: fixed order of items in insert-mode completion menu
  * runtime(comment): commenting might be off by one column
  * 9.1.0753: Wrong display when typing in diff mode with 'smoothscroll'
  * 9.1.0752: can set 'cedit' to an invalid value
  * runtime(doc): add `usr` tag to usr_toc.txt
  * 9.1.0751: Error callback for term_start() not used
  * 9.1.0750: there are some Win9x legacy references
  * runtime(java): Recognise the CommonMark form (///) of Javadoc comments
  * 9.1.0749: filetype: http files not recognized
  * runtime(comment): fix syntax error
  * CI: uploading failed screendump tests does not work Cirrus
  * 9.1.0748: :keep* commmands are sometimes misidentified as :k
  * runtime(indent): allow matching negative numbers for gnu indent config file
  * runtime(comment): add gC mapping to (un)comment rest of line
  * 9.1.0747: various typos in repo found
  * 9.1.0746: tests: Test_halfpage_longline() fails on large terminals
  * runtime(doc): reformat gnat example
  * runtime(doc): reformat ada_standard_types section
  * 9.1.0745: filetype: bun and deno history files not recognized
  * runtime(glvs): Correct the tag name of glvs-autoinstal
  * runtime(doc): include short form for :earlier/:later
  * runtime(doc): remove completed TODO
  * 9.1.0744: filetype: notmuch configs are not recognised
  * 9.1.0743: diff mode does not handle overlapping diffs correctly
  * runtime(glvs): fix a few issues
  * runtime(doc): Fix typo in :help :command-modifiers
  * 9.1.0742: getcmdprompt() implementation can be improved
  * runtime(docs): update `:set?` command behavior table
  * runtime(doc): update vim90 to vim91 in docs
  * runtime(doc): fix typo in :h dos-colors
  * 9.1.0741: No way to get prompt for input()/confirm()
  * runtime(doc): fix typo in version9.txt nrformat -&amp;gt; nrformats
  * runtime(rmd,rrst): 'fex' option not properly restored
  * runtime(netrw): remove extraneous closing bracket
  * 9.1.0740: incorrect internal diff with empty file
  * 9.1.0739: [security]: use-after-free in ex_getln.c
  * runtime(filetype): tests: Test_filetype_detection() fails
  * runtime(dist): do not output a message if executable is not found
  * 9.1.0738: filetype: rapid files are not recognized
  * runtime(modconf): remove erroneous :endif in ftplugin
  * runtime(lyrics): support multiple timestamps in syntax script
  * runtime(java): Optionally recognise _module_ import declarations
  * runtime(vim): Update base-syntax, improve folding function matches
  * CI: upload failed screendump tests also for Cirrus
  * 9.1.0737: tests: screendump tests may require a bit more time
  * runtime(misc): simplify keywordprg in various ftplugins
  * runtime(java): Optionally recognise all primitive constants in _switch-case_ labels
  * runtime(zsh,sh): set and unset compiler in ftplugin
  * runtime(netrw): using inefficient highlight pattern for 'mf'
  * 9.1.0736: Unicode tables are outdated
  * 9.1.0735: filetype: salt files are not recognized
  * 9.1.0734: filetype: jinja files are not recognized
  * runtime(zathurarc): add double-click-follow to syntax script
  * translation(ru): Updated messages translation
  * translation(it): updated xxd man page
  * translation(ru): updated xxd man page
  * 9.1.0733: keyword completion does not work with fuzzy
  * 9.1.0732: xxd: cannot use -b and -i together
  * runtime(java): Highlight javaConceptKind modifiers with StorageClass
  * runtime(doc): reword and reformat how to use defaults.vim
  * 9.1.0731: inconsistent case sensitive extension matching
  * runtime(vim): Update base-syntax, match Vim9 bool/null literal args to :if/:while/:return
  * runtime(netrw): delete confirmation not strict enough
  * 9.1.0730: Crash with cursor-screenline and narrow window
  * 9.1.0729: Wrong cursor-screenline when resizing window
  * 9.1.0728: [security]: heap-use-after-free in garbage collection with location list user data
  * runtime(doc): clarify the effect of the timeout for search()-functions
  * runtime(idlang): update syntax script
  * runtime(spec): Recognize epoch when making spec changelog in ftplugin
  * runtime(spec): add file triggers to syntax script
  * 9.1.0727: too many strlen() calls in option.c
  * runtime(make): add compiler/make.vim to reset compiler plugin settings
  * runtime(java): Recognise all available standard doclet tags
  * 9.1.0726: not using correct python3 API with dynamic linking
  * runtime(dosini): Update syntax script, spellcheck comments only
  * runtime(doc): Revert outdated comment in completeopt's fuzzy documentation
  * 9.1.0725: filetype: swiftinterface files are not recognized
  * runtime(pandoc): Update compiler plugin to use actual 'spelllang'
  * runtime(groff): Add compiler plugin for groff
  * 9.1.0724: if_python: link error with python 3.13 and stable ABI
  * 9.1.0723: if_python: dynamic linking fails with python3 &amp;gt;= 3.13
  * 9.1.0722: crash with large id in text_prop interface
  * 9.1.0721: tests: test_mksession does not consider XDG_CONFIG_HOME
  * runtime(glvs): update GetLatestVimScripts plugin
  * runtime(doc): Fix typo in :help :hide text
  * runtime(doc): buffers can be re-used
  * 9.1.0720: Wrong breakindentopt=list:-1 with multibyte or TABs
  * 9.1.0719: Resetting cell widths can make 'listchars' or 'fillchars' invalid
  * runtime(doc): Update version9.txt and mention $MYVIMDIR
- Update to 9.1.0718:
  * v9.1.0718: hard to know the users personal Vim Runtime Directory
  * v9.1.0717: Unnecessary nextcmd NULL checks in parse_command_modifiers()
    Maintainers: fix typo in author name
  * v9.1.0716: resetting setcellwidth( doesn't update the screen
    runtime(hcl,terraform): Add runtime files for HCL and Terraform
    runtime(tmux): Update syntax script
  * v9.1.0715: Not correctly parsing color names (after v9.1.0709)
  * v9.1.0714: GuiEnter_Turkish test may fail
  * v9.1.0713: Newline causes E749 in Ex mode
  * v9.1.0712: missing dependency of Test_gettext_makefile
  * v9.1.0711: test_xxd may file when using different xxd
  * v9.1.0710: popup window may hide part of Command line
    runtime(vim): Update syntax, improve user-command matching
  * v9.1.0709: GUIEnter event not found in Turkish locale
    runtime(sudoers): improve recognized Runas_Spec and Tag_Spec items
  * v9.1.0708: Recursive window update does not account for reset skipcol
    runtime(nu): include filetype plugin
  * v9.1.0707: invalid cursor position may cause a crash
  * v9.1.0706: test_gettext fails when using shadow dir
    CI: Install locales-all package
  * v9.1.0705: Sorting of fuzzy filename completion is not stable
    translation(pt): update Portuguese/Brazilian menu translation
    runtime(vim): Update base-syntax, match bracket mark ranges
    runtime(doc): Update :help :command-complete list
  * v9.1.0704: inserting with a count is inefficient
    runtime(doc): use mkdir -p to save a command
  * v9.1.0703: crash with 2byte encoding and glob2regpat()
    runtime(hollywood): update syn highlight for If-Then statements
    and For-In-Loops
  * v9.1.0702: Patch 9.1.0700 broke CI
  * v9.1.0701: crash with NFA regex engine when searching for
    composing chars
  * v9.1.0700: crash with 2byte encoding and glob2regpat()
  * v9.1.0699: &amp;quot;dvgo&amp;quot; is not always an inclusive motion
    runtime(java): Provide support for syntax preview features
  * v9.1.0698: &amp;quot;Untitled&amp;quot; file not removed when running Test_crash1_3
    alone
  * v9.1.0697: heap-buffer-overflow in ins_typebuf
  * v9.1.0696: installing runtime files fails when using SHADOWDIR
    runtime(doc): fix typo
  * v9.1.0695: test_crash leaves Untitled file around
    translation(br): Update Brazilian translation
    translation(pt): Update menu_pt_br
  * v9.1.0694: matchparen is slow on a long line
  * v9.1.0693: Configure doesn't show result when not using python3
    stable abi
  * v9.1.0692: Wrong patlen value in ex_substitute()
  * v9.1.0691: stable-abi may cause segfault on Python 3.11
    runtime(vim): Update base-syntax, match :loadkeymap after colon and bar
    runtime(mane): Improve &amp;lt;Plug&amp;gt;ManBS mapping
  * v9.1.0690: cannot set special highlight kind in popupmenu
    translation(pt): Revert and fix wrong Portuguese menu translation
    files
    translation(pt): revert Portuguese menu translation
    translation(br): Update Brazilian translations
    runtime(vim): Update base-syntax, improve :let-heredoc highlighting
  * v9.1.0689: buffer-overflow in do_search( with 'rightleft'
    runtime(vim): Improve heredoc handling for all embedded scripts
  * v9.1.0688: dereferences NULL pointer in check_type_is_value()
  * v9.1.0687: Makefile may not install desktop files
    runtime(man): Fix &amp;lt;Plug&amp;gt;ManBS
    runtime(java): Make the bundled &amp;amp;foldtext function optional
    runtime(netrw): Change line on `mx` if command output exists
    runtime(netrw): Fix `mf`-selected entry highlighting
    runtime(htmlangular): add html syntax highlighting
    translation(it): Fix filemode of Italian manpages
    runtime(doc): Update outdated man.vim plugin information
    runtime(zip): simplify condition to detect MS-Windows
  * v9.1.0686: zip-plugin has problems with special characters
    runtime(pandoc): escape quotes in &amp;amp;errorformat for pandoc
    translation(it): updated Italian manpage
  * v9.1.0685: too many strlen( calls in usercmd.c
    runtime(doc): fix grammar in :h :keeppatterns
    runtime(pandoc): refine pandoc compiler settings
  * v9.1.0684: completion is inserted on Enter with &amp;quot;noselect&amp;quot;
    translation(ru): update man pages
  * v9.1.0683: mode( returns wrong value with &amp;lt;Cmd&amp;gt; mapping
    runtime(doc): remove trailing whitespace in cmdline.txt
  * v9.1.0682: Segfault with uninitialized funcref
  * v9.1.0681: Analyzing failed screendumps is hard
    runtime(doc): more clarification for the :keeppatterns needed
  * v9.1.0680: VMS does not have defined uintptr_t
    runtime(doc): improve typedchar documentation for KeyInputPre autocmd
    runtime(dist): verify that executable is in $PATH
    translation(it): update Italian manpages
    runtime(doc): clarify the effect of :keeppatterns after * v9.1.0677
    runtime(doc): update Makefile and make it portable between GNU and BSD
  * v9.1.0679: Rename from w_closing to w_locked is incomplete
    runtime(colors): update colorschemes
    runtime(vim): Update base-syntax, improve :let-heredoc highlighting
    runtime(doc): Updating the examples in the xxd manpage
    translation(ru): Updated uganda.rux
    runtime(yaml): do not re-indent when commenting out lines
  * v9.1.0678: use-after-free in alist_add()
  * v9.1.0677 :keepp does not retain the substitute pattern
    translation(ja): Update Japanese translations to latest release
    runtime(netrw): Drop committed trace lines
    runtime(netrw): Error popup not always used
    runtime(netrw): ErrorMsg( may throw E121
    runtime(tutor): update Makefile and make it portable between GNU and BSD
    translation: improve the po/cleanup.vim script
    runtime(lang): update Makefile and make it portable between GNU and BSD
  * v9.1.0676: style issues with man pages
  * v9.1.0675: Patch v9.1.0674 causes problems
    runtime(dosbatch): Show %%i as an argument in syntax file
    runtime(dosbatch): Add syn-sync to syntax file
    runtime(sql, mysql): fix E169: Command too recursive with
    sql_type_default = &amp;quot;mysql&amp;quot;
  * v9.1.0674: compiling abstract method fails because of missing return
    runtime(javascript): fix a few issues with syntax higlighting
    runtime(mediawiki): fix typo in doc, test for b:did_ftplugin var
    runtime(termdebug): Fix wrong test for balloon feature
    runtime(doc): Remove mentioning of the voting feature
    runtime(doc): add help tags for json + markdown global variables
  * v9.1.0673: too recursive func calls when calling super-class method
    runtime(syntax-tests): Facilitate the viewing of rendered screendumps
    runtime(doc): fix a few style issues
  * v9.1.0672: marker folds may get corrupted on undo
  * v9.1.0671 Problem:  crash with WinNewPre autocommand
  * v9.1.0670: po file encoding fails on *BSD during make
    translation(it): Update Italian translation
    translation: Stop using msgconv
  * v9.1.0669: stable python ABI not used by default
    Update .gitignore and .hgignore files
  * v9.1.0668: build-error with python3.12 and stable ABI
    translations: Update generated po files
  * v9.1.0667: Some other options reset curswant unnecessarily when set
  * v9.1.0666: assert_equal( doesn't show multibyte string correctly
    runtime(doc): clarify directory of Vim's executable vs CWD
  * v9.1.0665 :for loop
    runtime(proto): Add indent script for protobuf filetype
  * v9.1.0664: console vim did not switch back to main screen on exit
    runtime(zip): zip plugin does not work with Vim 9.0
  * v9.1.0663: zip test still resets 'shellslash' option
    runtime(zip): use defer to restore old settings
    runtime(zip): add a generic Message function
    runtime(zip): increment base version of zip plugin
    runtime(zip): raise minimum Vim version to * v9.0
    runtime(zip): refactor save and restore of options
    runtime(zip): remove test for fnameescape
    runtime(zip): use :echomsg instead of :echo
    runtime(zip): clean up and remove comments
  * v9.1.0662: filecopy( may return wrong value when readlink( fails
  * v9.1.0661: the zip plugin is not tested.
    runtime(zip): Fix for FreeBSD's unzip command
    runtime(doc): capitalize correctly
  * v9.1.0660: Shift-Insert does work on old conhost
    translation(it): update Italian manpage
    runtime(lua): add/subtract a 'shiftwidth' after '('/')' in indentexpr
    runtime(zip): escape '[' on Unix as well
  * v9.1.0659: MSVC Makefile is a bit hard to read
    runtime(doc): fix typo in syntax.txt
    runtime(doc): -x is only available when compiled with crypt feature
  * v9.1.0658: Coverity warns about dereferencing NULL pointer.
    runtime(colors): update Todo highlight in habamax colorscheme
  * v9.1.0657: MSVC build time can be optimized
  * v9.1.0656: MSVC Makefile CPU handling can be improved
  * v9.1.0655: goaccess config file not recognized
    CI: update clang compiler to version 20
    runtime(netrw): honor `g:netrw_alt{o,v}` for `:{S,H,V}explore`
  * v9.1.0654: completion does not respect completeslash with fuzzy
  * v9.1.0653: Patch v9.1.0648 not completely right
  * v9.1.0652: too many strlen( calls in syntax.c
  * v9.1.0651 :append
  * v9.1.0650: Coverity warning in cstrncmp()
  * v9.1.0649: Wrong comment for &amp;quot;len&amp;quot; argument of call_simple_func()
  * v9.1.0648: [security] double-free in dialog_changed()
  * v9.1.0647: [security] use-after-free in tagstack_clear_entry
    runtime(doc): re-format tag example lines, mention ctags --list-kinds
  * v9.1.0646: imported function may not be found
    runtime(java): Document &amp;quot;g:java_space_errors&amp;quot; and &amp;quot;g:java_comment_strings&amp;quot;
    runtime(java): Cluster optional group definitions and their group links
    runtime(java): Tidy up the syntax file
    runtime(java): Tidy up the documentation for &amp;quot;ft-java-syntax&amp;quot;
    runtime(colors): update habamax scheme - tweak diff/search/todo colors
    runtime(nohlsearch): add missing loaded_hlsearch guard
    runtime(kivy): Updated maintainer info for syntax script
    Maintainers: Add maintainer for ondir ftplugin + syntax files
    runtime(netrw): removing trailing slash when copying files in same
    directory
  * v9.1.0645: wrong match when searching multi-byte char case-insensitive
    runtime(html): update syntax script to sync by 250 minlines by default
  * v9.1.0644: Unnecessary STRLEN( when applying mapping
    runtime(zip): Opening a remote zipfile don't work
    runtime(cuda): source c and cpp ftplugins
  * v9.1.0643: cursor may end up on invalid position
  * v9.1.0642: Check that mapping rhs starts with lhs fails if not
    simplified
  * v9.1.0641: OLE enabled in console version
    runtime(thrift): add ftplugin, indent and syntax scripts
  * v9.1.0640: Makefile can be improved
  * v9.1.0639: channel timeout may wrap around
  * v9.1.0638: E1510 may happen when formatting a message for smsg()
  * v9.1.0637: Style issues in MSVC Makefile
- Update apparmor.vim to latest version (from AppArmor 4.0.2)
  - add support for &amp;quot;all&amp;quot; and &amp;quot;userns&amp;quot; rules, and new profile flags
- Update to 9.1.0636:
  * 9.1.0636: filetype: ziggy files are not recognized
  * 9.1.0635: filetype: SuperHTML template files not recognized
  * 9.1.0634: Ctrl-P not working by default
  * 9.1.0633: Compilation warnings with `-Wunused-parameter`
  * 9.1.0632: MS-Windows: Compiler Warnings
  Add support for Files-Included in syntax script
  tweak documentation style a bit
  * 9.1.0631: wrong completion list displayed with non-existing dir + fuzzy completion
  * 9.1.0630: MS-Windows: build fails with VIMDLL and mzscheme
  * 9.1.0629: Rename of pum hl_group is incomplete
  * 9.1.0628: MinGW: coverage files are not cleaned up
  * 9.1.0627: MinGW: build-error when COVERAGE is enabled
  * 9.1.0626: Vim9: need more tests with null objects
  include initial filetype plugin
  * 9.1.0625: tests: test output all translated messages for all translations
  * 9.1.0624: ex command modifiers not found
  * 9.1.0623: Mingw: errors when trying to delete non-existing files
  * 9.1.0622: MS-Windows: mingw-build can be optimized
  * 9.1.0621: MS-Windows: startup code can be improved
  * 9.1.0620: Vim9: segfauls with null objects
  * 9.1.0619: tests: test_popup fails
  * 9.1.0618: cannot mark deprecated attributes in completion menu
  * 9.1.0617: Cursor moves beyond first line of folded end of buffer
  * 9.1.0616: filetype: Make syntax highlighting off for MS Makefiles
  * 9.1.0615: Unnecessary STRLEN() in make_percent_swname()
  Add single-line comment syntax
  Add syntax test for comments
  Update maintainer info
  * 9.1.0614: tests: screendump tests fail due to recent syntax changes
  * 9.1.0613: tests: termdebug test may fail and leave file around
  Update base-syntax, improve :set highlighting
  Optionally highlight the :: token for method references
  * 9.1.0612: filetype: deno.lock file not recognized
  Use delete() for deleting directory
  escape filename before trying to delete it
  * 9.1.0611: ambiguous mappings not correctly resolved with modifyOtherKeys
  correctly extract file from zip browser
  * 9.1.0610: filetype: OpenGL Shading Language files are not detected
  Fix endless recursion in netrw#Explore()
  * 9.1.0609: outdated comments in Makefile
  update syntax script
  Fix flow mapping key detection
  Remove orphaned YAML syntax dump files
  * 9.1.0608: Coverity warns about a few potential issues
  Update syntax script and remove syn sync
  * 9.1.0607: termdebug: uses inconsistent style
  * 9.1.0606: tests: generated files may cause failure in test_codestyle
  * 9.1.0605: internal error with fuzzy completion
  * 9.1.0604: popup_filter during Press Enter prompt seems to hang
  translation: Update Serbian messages translation
  * 9.1.0603: filetype: use correct extension for Dracula
  * 9.1.0602: filetype: Prolog detection can be improved
  fix more inconsistencies in assert function docs
  * 9.1.0601: Wrong cursor position with 'breakindent' when wide char doesn't fit
  Update base-syntax, improve :map highlighting
  * 9.1.0600: Unused function and unused error constants
  * 9.1.0599: Termdebug: still get E1023 when specifying arguments
  correct wrong comment options
  fix typo &amp;quot;a xterm&amp;quot; -&amp;gt; &amp;quot;an xterm&amp;quot;
  * 9.1.0598: fuzzy completion does not work with default completion
  * 9.1.0597: KeyInputPre cannot get the (unmapped typed) key
  * 9.1.0596: filetype: devscripts config files are not recognized
  gdb file/folder check is now performed only in CWD.
  quote filename arguments using double quotes
  update syntax to SDC-standard 2.1
  minor updates.
  Cleanup :match and :loadkeymap syntax test files
  Update base-syntax, match types in Vim9 variable declarations
  * 9.1.0595: make errors out with the po Makefile
  * 9.1.0594: Unnecessary redraw when setting 'winfixbuf'
  using wrong highlight for UTF-8
  include simple syntax plugin
  * 9.1.0593: filetype: Asymptote files are not recognized
  add recommended indent options to ftplugin
  add recommended indent options to ftplugin
  add recommended indent options to ftplugin
  * 9.1.0592: filetype: Mediawiki files are not recognized
  * 9.1.0591: filetype: *.wl files are not recognized
  * 9.1.0590: Vim9: crash when accessing getregionpos() return value
  'cpoptions': Include &amp;quot;z&amp;quot; in the documented default
  * 9.1.0589: vi: d{motion} and cw work differently than expected
  update included colorschemes
  grammar fixes in options.txt
- Add &amp;quot;Keywords&amp;quot; to gvim.desktop to make searching for gvim easier
- Removed patches, as they're no longer required (refreshing them
  deleted their contents):
  * vim-7.3-help_tags.patch
  * vim-7.4-highlight_fstab.patch
- Reorganise all applied patches in the spec file.
- Update to 9.1.0588:
  * 9.1.0588: The maze program no longer compiles on newer clang
    runtime(typst): Add typst runtime files
  * 9.1.0587: tests: Test_gui_lowlevel_keyevent is still flaky
  * 9.1.0586: ocaml runtime files are outdated
    runtime(termdebug): fix a few issues
  * 9.1.0585: tests: test_cpoptions leaves swapfiles around
  * 9.1.0584: Warning about redeclaring f_id() non-static
    runtime(doc): Add hint how to load termdebug from vimrc
    runtime(doc): document global insert behavior
  * 9.1.0583: filetype: *.pdf_tex files are not recognized
  * 9.1.0582: Printed line doesn't overwrite colon when pressing Enter in Ex mode
  * 9.1.0581: Various lines are indented inconsistently
  * 9.1.0580: :lmap mapping for keypad key not applied when typed in Select mode
  * 9.1.0579: Ex command is still executed after giving E1247
  * 9.1.0578: no tests for :Tohtml
  * 9.1.0577: Unnecessary checks for v:sizeoflong in test_put.vim
  * 9.1.0576: tests: still an issue with test_gettext_make
  * 9.1.0575: Wrong comments in alt_tabpage()
  * 9.1.0574: ex: wrong handling of commands after bar
    runtime(doc): add a note for netrw bug reports
  * 9.1.0573: ex: no implicit print for single addresses
    runtime(vim): make &amp;amp;indentexpr available from the outside
  * 9.1.0572: cannot specify tab page closing behaviour
    runtime(doc): remove obsolete Ex insert behavior
  * 9.1.0571: tests: Test_gui_lowlevel_keyevent is flaky
    runtime(logindefs): update syntax with new keywords
  * 9.1.0570: tests: test_gettext_make can be improved
    runtime(filetype): Fix Prolog file detection regex
  * 9.1.0569: fnamemodify() treats &amp;quot;..&amp;quot; and &amp;quot;../&amp;quot; differently
    runtime(mojo): include mojo ftplugin and indent script
  * 9.1.0568: Cannot expand paths from 'cdpath' setting
  * 9.1.0567: Cannot use relative paths as findfile() stop directories
  * 9.1.0566: Stop dir in findfile() doesn't work properly w/o trailing slash
  * 9.1.0565: Stop directory doesn't work properly in 'tags'
  * 9.1.0564: id() can be faster
  * 9.1.0563: Cannot process any Key event
  * 9.1.0562: tests: inconsistency in test_findfile.vim
    runtime(fstab): Add missing keywords to fstab syntax
  * 9.1.0561: netbeans: variable used un-initialized (Coverity)
  * 9.1.0560: bindtextdomain() does not indicate an error
  * 9.1.0559: translation of vim scripts can be improved
  * 9.1.0558: filetype: prolog detection can be improved
  * 9.1.0557: moving in the buffer list doesn't work as documented
    runtime(doc): fix inconsistencies in :h file-searching
  * 9.1.0556: :bwipe doesn't remove file from jumplist of other tabpages
    runtime(htmlangular): correct comment
  * 9.1.0555: filetype: angular ft detection is still problematic
  * 9.1.0554: :bw leaves jumplist and tagstack data around
  * 9.1.0553: filetype: *.mcmeta files are not recognized
  * 9.1.0552: No test for antlr4 filetype
  * 9.1.0551: filetype: htmlangular files are not properly detected
  * 9.1.0550: filetype: antlr4 files are not recognized
  * 9.1.0549: fuzzycollect regex based completion not working as expected
    runtime(doc): autocmd_add() accepts a list not a dict
  * 9.1.0548: it's not possible to get a unique id for some vars
    runtime(tmux): Update syntax script
  * 9.1.0547: No way to get the arity of a Vim function
  * 9.1.0546: vim-tiny fails on CTRL-X/CTRL-A
    runtime(hlsplaylist): include hlsplaylist ftplugin file
    runtime(doc): fix typo in :h ft-csv-syntax
    runtime(doc): Correct shell command to get $VIMRUNTIME into
    shell
  * 9.1.0545: MSVC conversion warning
  * 9.1.0544: filetype: ldapconf files are not recognized
    runtime(cmakecache): include cmakecache ftplugin file
    runtime(lex): include lex ftplugin file
    runtime(yacc): include yacc ftplugin file
    runtime(squirrel): include squirrel ftplugin file
    runtime(objcpp): include objcpp ftplugin file
    runtime(tf): include tf ftplugin file
    runtime(mysql): include mysql ftplugin file
    runtime(javacc): include javacc ftplugin file
    runtime(cabal): include cabal ftplugin file
    runtime(cuda): include CUDA ftplugin file
    runtime(editorconfig): include editorconfig ftplugin file
    runtime(kivy): update kivy syntax, include ftplugin
    runtime(syntax-tests): Stop generating redundant &amp;quot;*_* 99.dump&amp;quot;
    files
  * 9.1.0543: Behavior of CursorMovedC is strange
    runtime(vim): Update base-syntax, improve :match command
    highlighting
  * 9.1.0542: Vim9: confusing string() output for object functions
  * 9.1.0541: failing test with Vim configured without channel
  * 9.1.0540: Unused assignment in sign_define_cmd()
    runtime(doc): add page-scrolling keys to index.txt
    runtime(doc): add reference to xterm-focus-event from
    FocusGained/Lost
  * 9.1.0539: Not enough tests for what v9.1.0535 fixed
    runtime(doc): clarify how to re-init csv syntax file
  * 9.1.0538: not possible to assign priority when defining a sign
  * 9.1.0537: signed number detection for CTRL-X/A can be improved
  * 9.1.0536: filetype: zone files are not recognized
  * 9.1.0535: newline escape wrong in ex mode
    runtime(man): honor cmd modifiers before `g:ft_man_open_mode`
    runtime(man): use `nnoremap` to map to Ex commands
  * 9.1.0534: completion wrong with fuzzy when cycling back to original
    runtime(syntax-tests): Abort and report failed cursor progress
    runtime(syntax-tests): Introduce self tests for screen dumping
    runtime(syntax-tests): Clear and redraw the ruler line with
    the shell info
    runtime(syntax-tests): Allow for folded and wrapped lines in
    syntax test files
  * 9.1.0533: Vim9: need more tests for nested objects equality
    CI: Pre-v* 9.0.0110 versions generate bogus documentation tag entries
    runtime(doc): Remove wrong help tag CTRL-SHIFT-CR
  * 9.1.0532: filetype: Cedar files not recognized
    runtime(doc): document further keys that scroll page up/down
  * 9.1.0531: resource leak in mch_get_random()
    runtime(tutor): Fix wrong spanish translation
    runtime(netrw): fix remaining case of register clobber
  * 9.1.0530: xxd: MSVC warning about non-ASCII character
  * 9.1.0529: silent! causes following try/catch to not work
    runtime(rust): use shiftwidth() in indent script
  * 9.1.0528: spell completion message still wrong in translations
  * 9.1.0527: inconsistent parameter in Makefiles for Vim executable
  * 9.1.0526: Unwanted cursor movement with pagescroll at start of buffer
    runtime(doc): mention $XDG_CONFIG_HOME instead of $HOME/.config
  * 9.1.0525: Right release selects immediately when pum is truncated.
  * 9.1.0524: the recursive parameter in the *_equal functions can be removed
    runtime(termdebug): Add Deprecation warnings
  * 9.1.0523: Vim9: cannot downcast an object
  * 9.1.0522: Vim9: string(object) hangs for recursive references
  * 9.1.0521: if_py: _PyObject_CallFunction_SizeT is dropped in Python 3.13
  * 9.1.0520: Vim9: incorrect type checking for modifying lists
    runtime(manpager): avoid readonly prompt
  * 9.1.0519: MS-Windows: libvterm compilation can be optimized
  * 9.1.0518: initialize the random buffer can be improved
  * 9.1.0517: MS-Windows: too long lines in Make_mvc.mak
    runtime(terraform): Add filetype plugin for terraform
    runtime(dockerfile): enable spellchecking of comments in
    syntax script
    runtime(doc): rename variable for pandoc markdown support
    runtime(doc): In builtin overview use {buf} as param for
    appendbufline/setbufline
    runtime(doc): clarify, that register 1-* 9 will always be shifted
    runtime(netrw): save and restore register 0-* 9, a and unnamed
    runtime(termdebug): Refactored StartDebug_term and EndDebug
    functions
    runtime(java): Compose &amp;quot;g:java_highlight_signature&amp;quot; and
    &amp;quot;g:java_highlight_functions&amp;quot;
  * 9.1.0516: need more tests for nested dicts and list comparision
  * 9.1.0515: Vim9: segfault in object_equal()
  * 9.1.0514: Vim9: issue with comparing objects recursively
    runtime(termdebug): Change some variables to Enums
    runtime(vim): Update base-syntax, fix function tail comments
  * 9.1.0513: Vim9: segfault with object comparison
- Update to 9.1.0512:
  * Mode message for spell completion doesn't match allowed keys
  * CursorMovedC triggered wrongly with setcmdpos()
  * update runtime files
  * CI: test_gettext fails on MacOS14 + MSVC Win
  * not possible to translate Vim script messages
  * termdebug plugin can be further improved
  * add gomod filetype plugin
  * hard to detect cursor movement in the command line
  * Optionally highlight parameterised types
  * filetype: .envrc &amp;amp; .prettierignore not recognized
  * filetype: Faust files are not recognized
  * inner-tag textobject confused about &amp;quot;&amp;gt;&amp;quot; in attributes
  * cannot use fuzzy keyword completion
  * Remove the group exclusion list from @javaTop
  * wrong return type for execute() function
  * MS-Windows: too much legacy code
  * too complicated mapping restore in termdebug
  * simplify mapping
  * cannot switch buffer in a popup
  * MS-Windows: doesn't handle symlinks properly
  * getcmdcompltype() interferes with cmdline completion
  * termdebug can be further improved
  * update htmldjango detection
  * Improve Turkish documentation
  * include a simple csv filetype and syntax plugin
  * include the the simple nohlsearch package
  * matched text is highlighted case-sensitively
  * Matched text isn't highlighted in cmdline pum
  * Fix typos in several documents
  * clarify when text properties are cleared
  * improve the vim-shebang example
  * revert unintended formatting changes for termdebug
  * Add a config variable for commonly used compiler options
  * Wrong matched text highlighted in pum with 'rightleft'
  * bump length of character references in syntax script
  * properly check mapping variables using null_dict
  * fix KdlIndent and kdlComment in indent script
  * Test for patch 9.1.0489 doesn't fail without the fix
  * Fold multi-line comments with the syntax kind of &amp;amp;fdm
  * using wrong type for PlaceSign()
  * filetype: Vim-script files not detected by shebang line
  * revert unintended change to zip#Write()
  * add another tag for vim-shebang feature
  * Cmdline pum doesn't work properly with 'rightleft'
  * minor style problems with patch 9.1.0487
  * default completion may break with fuzzy
  * Wrong padding for pum &amp;quot;kind&amp;quot; with 'rightleft'
  * Update base-syntax, match shebang lines
  * MS-Windows: handle files with spaces properly
  * Restore HTML syntax file tests
  * completed item not update on fuzzy completion
  * filetype: Snakemake files are not recognized
  * make TermDebugSendCommand() a global function again
  * close all buffers in the same way
  * Matched text shouldn't be highlighted in &amp;quot;kind&amp;quot; and &amp;quot;menu&amp;quot;
  * fix wrong helptag for :defer
  * Update base-syntax, match :sleep arg
  * include Georgian keymap
  * Sorting of completeopt+=fuzzy is not stable
  * correctly test for windows in NetrwGlob()
  * glob() on windows fails with [] in directory name
  * rewrite mkdir() doc and simplify {flags} meaning
  * glob() not sufficiently tested
  * update return type for job_info()
  * termdebug plugin needs more love
  * correct return types for job_start() and job_status()
  * Update base-syntax, match :catch and :throw args
  * Include element values in non-marker annotations
  * Vim9: term_getjob() throws an exception on error
  * fuzzy string matching executed when not needed
  * fuzzy_match_str_with_pos() does unnecessary list operations
  * restore description of &amp;quot;$&amp;quot; in col() and virtcol()
  * deduplicate getpos(), line(), col(), virtcol()
  * Update g:vimsyn_comment_strings dump file tests
  * Use string interpolation instead of string concat
  * potential deref of NULL pointer in fuzzy_match_str_with_pos
  * block_editing errors out when using &amp;lt;enter&amp;gt;
  * Update base-syntax, configurable comment string highlighting
  * fix typos in syntax.txt
  * Cannot see matched text in popup menu
  * Update base-syntax, match multiline continued comments
  * clarify documentation for &amp;quot;v&amp;quot; position at line()
  * cmod_split modifier is always reset in term_start()
  * remove line-continuation characters
  * use shiftwidth() instead of &amp;amp;tabstop in indent script
  * Remove orphaned screen dump files
  * include syntax, indent and ftplugin files
  * CI: Test_ColonEight() fails on github runners
  * add missing Enabled field in syntax script
  * basic svelte ftplugin file
  * term_start() does not clear vertical modifier
  * fix mousemodel restoration by comparing against null_string
  * Added definitions of Vim scripts and plugins
  * Exclude lambda expressions from _when_ _switch-case_ label clauses
  * Fix saved_mousemodel check
  * Inconsistencies between functions for option flags
  * Crash when using autocmd_get() after removing event inside autocmd
  * Fix small style issues
  * add return type info for Vim function descriptions
  * Update Italian Vim manpage
  * disable the q mapping
  * Change 'cms' for C++ to '// %s'
  * fix type mismatch error
  * Fix wrong email address
  * convert termdebug plugin to Vim9 script
- Update to 9.1.0470:
  * tests Test_ColonEight_MultiByte() fails sporadically
  * Cannot have buffer-local value for 'completeopt'
  * GvimExt does not consult HKEY_CURRENT_USER
  * typos in some comments
  * runtime(vim): Update base-syntax, allow whitespace before
    :substitute pattern
  * Missing comments for fuzzy completion
  * runtime(man): update Vim manpage
  * runtime(comment): clarify the usage of 'commentstring' option
    value
  * runtime(doc): clarify how fuzzy 'completeopt' should work
  * runtime(netrw): prevent accidental data loss
  * missing filecopy() function
  * no whitespace padding in commentstring option in ftplugins
  * no fuzzy-matching support for insert-completion
  * eval5() and eval7 are too complex
  * too many strlen() calls in drawline.c
  * filetype lintstagedrc files are not recognized
  * Vim9 import autoload does not work with symlink
  * Coverity complains about division by zero
  * tests test_gui fails on Wayland
  * Left shift is incorrect with vartabstop and shiftwidth=0
  * runtime(doc): clarify 'shortmess' flag &amp;quot;S&amp;quot;
  * MS-Windows compiler warning for size_t to int conversion
  * runtime(doc): include some vim9 script examples in the help
  * minor issues in test_filetype with rasi test
  * filetype rasi files are not recognized
  * runtime(java): Improve the matching of lambda expressions
  * Configure checks for libelf unnecessarily
  * No test for escaping '&amp;lt;' with shellescape()
  * check.vim complains about overlong comment lines
  * translation(it): Update Italian translation
  * evalc. code too complex
  * MS-Windows Compiler warnings
- Update to 9.1.0448:
  * compiler warning in eval.c
  * remove remaining css code
  * Add ft_hare.txt to Reference Manual TOC
  * re-generate vim syntax from generator
  * fix syntax vim bug
  * completion may be wrong when deleting all chars
  * getregionpos() inconsistent for partly-selected multibyte char
  * fix highlighting nested and escaped quotes in string props
  * remove the indent plugin since it has too many issues
  * update Debian runtime files
  * Coverity warning after 9.1.0440
  * Not enough tests for getregion() with multibyte chars
  * Can't use blockwise selection with width for getregion()
  * update outdated syntax files
  * fix floating_modifier highlight
  * hare runtime files outdated
  * getregionpos() can't properly indicate positions beyond eol
  * function get_lval() is too long
  * Cannot filter the history
  * Wrong Ex command executed when :g uses '?' as delimiter
  * support floating_modifier none; revert broken highlighting
  * Motif requires non-const char pointer for XPM  data
  * Crash when using '?' as separator for :s
  * filetype: cygport files are not recognized
  * make errors trying to access autoload/zig
  * Wrong yanking with exclusive selection and ve=all
  * add missing help tags file
  * Ancient XPM preprocessor hack may cause build errors
  * include basic rescript ftplugin file
  * eval.c is too long
  * getregionpos() doesn't handle one char selection
  * check for gdb file/dir before using as buffer name
  * refactor zig ftplugin, remove auto format
  * Coverity complains about eval.c refactor
  * Tag guessing leaves wrong search history with very short names
  * some issues with termdebug mapping test
  * update matchit plugin to v1.20
  * too many strlen() calls in search.c
  * set commentstring option
  * update vb indent plugin as vim9script
  * filetype: purescript files are not recognized
  * filetype: slint files are not recognized
  * basic nim ftplugin file for comments
  * Add Arduino ftplugin and indent files
  * include basic typst ftplugin file
  * include basic prisma ftplugin file
  * include basic v ftplugin for comment support
  * getregionpos() wrong with blockwise mode and multibyte
  * function echo_string_core() is too long
  * hyprlang files are not recognized
  * add basic dart ftplugin file
  * basic ftplugin file for graphql
  * mention comment plugin at :h 'commentstring'
  * set commentstring for sql files in ftplugin
  * :browse oldfiles prompts even with single entry
  * eval.c not sufficiently tested
  * clarify why E195 is returned
  * clarify temporary file clean up
  * fix :NoMatchParen not working
  * Cannot move to previous/next rare word
  * add basic ftplugin file for sshdconfig
  * if_py: find_module has been removed in Python 3.12.0a7
  * some screen dump tests can be improved
  * Some functions are not tested
  * clarify instal instructions for comment package
  * Unable to leave long line with 'smoothscroll' and 'scrolloff'
  * fix typo in vim9script help file
  * Remove trailing spaces
  * clarify {special} argument for shellescape()
- update to 9.1.0413
  * smoothscroll may cause infinite loop
  * add missing entries for the keys CTRL-W g&amp;lt;Tab&amp;gt; and &amp;lt;C-Tab&amp;gt;
  * update vi_diff.txt: add default value for 'flash'
  * typo in regexp_bt.c in DEBUG code
  * allow indented commands
  * Fix wrong define regex in ftplugin
  * Filter out non-Latin-1 characters for syntax tests
  * prefer scp over pscp
  * fix typo in usr_52.txt
  * too long functions in eval.c
  * warning about uninitialized variable
  * too many strlen() calls in the regexp engine
  * E16 fix, async keyword support for define
  * Stuck with long line and half-page scrolling
  * Divide by zero with getmousepos() and 'smoothscroll'
  * update and remove  some invalid links
  * update translation of xxd manpage
  * Recursively delete directories by default with netrw delete command
  * Strive to remain compatible for at least Vim 7.0
  * tests: xxd buffer overflow fails on 32-bit
  * Stop handpicking syntax groups for @javaTop
  * [security] xxd: buffer-overflow with specific flags
  * Vim9: not able to import file from start dir
  * filetype: mdd files detected as zsh filetype
  * filetype: zsh module files are not recognized
  * Remove hardcoded private.ppk logic from netrw
  * Vim9: confusing error message for unknown type
  * block_editing errors out when using del
  * add new items to scripts section in syntax plugin
  * Vim9: imported vars are not properly type checked
  * Wrong display with 'smoothscroll' when changing quickfix list
  * filetype: jj files are not recognized
  * getregionpos() may leak memory on error
  * The CODEOWNERS File is not useful
  * Remove and cleanup Win9x legacy from netrw
  * add MsgArea to 'highlight' option description
  * Cannot get a list of positions describing a region
  * Fix digit separator in syntax script for octals and floats
  * Update link to Wikipedia Vi page
  * clear $MANPAGER in ftplugin before shelling out
  * Fix typos in help documents
  * 'viewdir' not respecting $XDG_CONFIG_HOME
  * tests: Vim9 debug tests may be flaky
  * correct getscriptinfo() example
  * Vim9: could improve testing
  * test_sound fails on macos-12
  * update Serbian menu
  * update Slovak menu
  * update Slovenian menu
  * update Portuguese menu
  * update Dutch menu
  * update Korean menu
  * update Icelandic menu
  * update Czech menu
  * update Afrikaans menu
  * update German menu
  * filetype: inko files are not recognized
  * filetype: templ files are not recognized
  * cursor() and getregion() don't handle v:maxcol well
  * Vim9: null value tests not sufficient
  * update Catalan menu
  * filetype: stylus files not recognized
  * update spanish menu localization
  * regenerate helptags
  * Vim9: crash with null_class and null_object
  * Add tags about lazyloading of menu
  * tests: vt420 terminfo entry may not be found
  * filetype: .out files recognized as tex files
  * filetype: Kbuild files are not recognized
  * cbuffer and similar commands don't accept a range
  * Improve the recognition of the &amp;quot;indent&amp;quot; method declarations
  * Fix a typo in usr_30.txt
  * remove undefined var s:save_cpoptions and add include setting
  * missing setlocal in indent plugin
  * Calculating line height for unnecessary amount of lines
  * improve syntax file performance
  * There are a few typos
  * Vim9: no comments allowed after class vars
  * CI: remove trailing white space in documentation
  * Formatting text wrong when 'breakindent' is set
  * Add oracular (24.10) as Ubuntu release name
  * Vim9: Trailing commands after class/enum keywords ignored
  * tests: 1-second delay after Test_BufEnter_botline()
  * update helptags for jq syntax
  * include syntax, ftplugin and compiler plugin
  * fix typo synconcealend -&amp;gt; synconcealed
  * include a simple comment toggling plugin
  * wrong botline in BufEnter
  * clarify syntax vs matching mechanism
  * fix undefined variable in indent plugin
  * ops.c code uses too many strlen() calls
  * Calling CLEAR_FIELD() on the same struct twice
  * Vim9: compile_def_function() still too long
  * Update Serbian messages
  * clarify the effect of setting the shell to powershell
  * Improve the recognition of the &amp;quot;style&amp;quot; method declarations
  * Vim9: problem when importing autoloaded scripts
  * compile_def_function is too long
  * filetype: ondir files are not recognized
  * Crash when typing many keys with D- modifier
  * tests: test_vim9_builtin is a bit slow
  * update documentation
  * change the download URL of &amp;quot;libsodium&amp;quot;
  * tests: test_winfixbuf is a bit slow
  * Add filetype, syntax and indent plugin for Astro
  * expanding rc config files does not work well
  * Vim9: vim9type.c is too complicated
  * Vim9: does not handle autoloaded variables well
  * minor spell fix in starting.txt
  * wrong drawing in GUI with setcellwidth()
  * Add include and suffixesadd
  * Page scrolling should place cursor at window boundaries
  * align command line table
  * minor fixes to starting.txt
  * fix comment definition in filetype plugin
  * filetype: flake.lock files are not recognized
  * runtime(uci): No support for uci file types
  * Support &amp;quot;g:ftplugin_java_source_path&amp;quot; with archived files
  * tests: Test_autoload_import_relative_compiled fails on Windows
  * Finding cmd modifiers and cmdline-specials is inefficient
  * No test that completing a partial mapping clears 'showcmd'
  * tests: test_vim9_dissamble may fail
  * Vim9: need static type for typealias
  * X11 does not ignore smooth scroll event
  * A few typos in test_xdg when testing gvimrc
  * Patch v9.1.0338 fixed sourcing a script with import
  * Problem: gvimrc not sourced from XDG_CONFIG_HOME
  * Cursor wrong after using setcellwidth() in terminal
  * 'showcmd' wrong for partial mapping with multibyte
  * tests: test_taglist fails when 'helplang' contains non-english
  * Problem: a few memory leaks are found
  * Problem: Error with matchaddpos() and empty list
  * tests: xdg test uses screen dumps
  * Vim9: import through symlinks not correctly handled
  * Missing entry for XDG vimrc file in :version
  * tests: typo in test_xdg
  * runtime(i3config/swayconfig): update syntax scripts
  * document pandoc compiler and enable configuring arguments
  * String interpolation fails for List type
  * No test for highlight behavior with 'ambiwidth'
  * tests: test_xdg fails on the appimage repo
  * tests: some assert_equal() calls have wrong order of args
  * make install does not install all files
  * runtime(doc): fix typos in starting.txt

- Remove patch to fix bsc#1220618:
  * vim-8.2.3607-revert-gtk3-code-removal.patch
- This patch introduced this bug that caused Vim to use significantly more CPU.

Package avahi was updated:

- Add avahi-CVE-2024-52616.patch:  Backporting 1dade81c from upstream: Properly randomize query id
  of DNS packets.
  (CVE-2024-52616, bsc#1233420)

Package cloud-regionsrv-client was updated:

- Update to 10.3.7 (bsc#1232770)  + Fix the product triplet for LTSS, it is always SLES-LTSS, not
    $BASEPRODUCT-LTSS

- Update to 10.3.6 (jsc#PCT-471, bsc#1230615)
  + Fix sudo setup
    ~ permissions cloudguestregistryauth
    ~ directory ownership /etc/sudoers.d
  + spec file
    ~ Remove traces of registry related entries on SLE 12
  + Forward port
    ~ fix-for-sles12-disable-registry.patch
    ~ fix-for-sles12-no-trans_update.patch
  + Deregister non free extensions at registercloudguest --clean
  + Fix registry cleanup at registercloudguest --clean, don't remove files
  + Prevent duplicate search entries in registry setup
- Update EC2 plugin to 1.0.5
  + Switch to using the region endpoint from IMDS to determine the region
    instead of deriving the data from the availability zone

- Update to 10.3.5
  + Update spec file to build in all code streams,
    SLE 12, SLE 15, ALP, and SLFO and have proper dependencies

Package yast2-network was updated:

- Honor the AutoYaST profile allowing to disable the IP check  (bsc#1216859).
- 3.4.12

Package python was updated:

- Add CVE-2024-11168-validation-IPv6-addrs.patch  fixing bsc#1233307 (CVE-2024-11168,
  gh#python/cpython#103848): Improper validation of IPv6 and
  IPvFuture addresses.
- Add ipaddress module from https://github.com/phihag/ipaddress
- Remove -IVendor/ from python-config boo#1231795

- Stop using %%defattr, it seems to be breaking proper executable
  attributes on /usr/bin/ scripts (bsc#1227378).

Package python-base was updated:

- Add CVE-2024-11168-validation-IPv6-addrs.patch  fixing bsc#1233307 (CVE-2024-11168,
  gh#python/cpython#103848): Improper validation of IPv6 and
  IPvFuture addresses.
- Add ipaddress module from https://github.com/phihag/ipaddress
- Remove -IVendor/ from python-config boo#1231795

- Stop using %%defattr, it seems to be breaking proper executable
  attributes on /usr/bin/ scripts (bsc#1227378).

Package curl was updated:

- Security fix: [bsc#1234068, CVE-2024-11053]  * curl could leak the password used for the first host to the
    followed-to host under certain circumstances.
  * netrc: address several netrc parser flaws
  * Add curl-CVE-2024-11053.patch

- Security fix: [bsc#1232528, CVE-2024-9681]
  * HSTS subdomain overwrites parent cache entry
  * Add curl-CVE-2024-9681.patch

Package glib2 was updated:

- Add glib2-CVE-2024-52533.patch: fix a single byte buffer overflow  (boo#1233282 CVE-2024-52533 glgo#GNOME/glib#3461).

Package python3 was updated:

- Remove -IVendor/ from python-config boo#1231795- Fix CVE-2024-11168-validation-IPv6-addrs.patch
- PGO run of build freezes with parallel processing, switch to -j1

- Add CVE-2024-11168-validation-IPv6-addrs.patch
  fixing bsc#1233307 (CVE-2024-11168,
  gh#python/cpython#103848): Improper validation of IPv6 and
  IPvFuture addresses.

- Add CVE-2024-9287-venv_path_unquoted.patch to properly quote
  path names provided when creating a virtual environment
  (bsc#1232241, CVE-2024-9287)

- Drop .pyc files from docdir for reproducible builds
  (bsc#1230906).

Package python3-base was updated:

- Remove -IVendor/ from python-config boo#1231795- Fix CVE-2024-11168-validation-IPv6-addrs.patch
- PGO run of build freezes with parallel processing, switch to -j1

- Add CVE-2024-11168-validation-IPv6-addrs.patch
  fixing bsc#1233307 (CVE-2024-11168,
  gh#python/cpython#103848): Improper validation of IPv6 and
  IPvFuture addresses.

- Add CVE-2024-9287-venv_path_unquoted.patch to properly quote
  path names provided when creating a virtual environment
  (bsc#1232241, CVE-2024-9287)

- Drop .pyc files from docdir for reproducible builds
  (bsc#1230906).

Package gcc13 was updated:

Package release-notes-sles was updated:

- 12.5.20241206 (tracked in bsc#933411)- Added note about openJDK 11 support status (bsc#1233970)

Package kernel-default was updated:

- x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client (bsc#1234072 CVE-2024-53114).- commit ace41bd

- Update
  patches.suse/initramfs-avoid-filename-buffer-overrun.patch
  (CVE-2024-53142 bsc#1232436).
- commit c12c103

- Bluetooth: af_bluetooth: Fix deadlock (CVE-2024-26886
  bsc#1223044).
- Bluetooth: Avoid potential use-after-free in hci_error_reset
  (CVE-2024-26801 bsc#1222413).
- commit 0002c48

- dm cache: fix potential out-of-bounds access on the first resume
  (bsc#1233467, CVE-2024-50278).
- dm cache: optimize dirty bit checking with find_next_bit when
  resizing (bsc#1233467, CVE-2024-50278).
- commit 0b89286

- Update References: field,
  patches.suse/dm-cache-fix-out-of-bounds-access-to-the-dirty-bitset-when-resizing.patch
  (bsc#1233467, bsc#1233468, CVE-2024-50278, CVE-2024-50279).
- commit 3ad9690

- dm cache: fix flushing uninitialized delayed_work on cache_ctr
  error (bsc#1233467, CVE-2024-50278).
- dm cache: correct the number of origin blocks to match the
  target length (bsc#1233467, CVE-2024-50278).
- commit 4bc71b8

- can: bcm: Clear bo-&amp;gt;bcm_proc_read after remove_proc_entry()
  (CVE-2024-46771 bsc#1230766).
- commit 491eb77

- ocfs2: uncache inode which has failed entering the group (bsc#1234087).
- commit 8d46222

- sch/netem: fix use after free in netem_dequeue (CVE-2024-46800
  bsc#1230827).
- can: bcm: Remove proc entry when dev is unregistered
  (CVE-2024-46771 bsc#1230766).
- commit 4db26bc

- media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED
  in uvc_parse_format (CVE-2024-53104 bsc#1234025).
- commit 5e374e6

- USB: serial: io_edgeport: fix use after free in debug printk (CVE-2024-50267 bsc#1233456)
- commit 5cba6cd

- usb: typec: altmode should keep reference to parent (CVE-2024-50150 bsc#1233051)
- commit 42ad9b3

- net: hns3: fix kernel crash when uninstalling driver (CVE-2024-50296 bsc#1233485)
- commit 184c4c0

- drm/vc4: Warn if some v3d code is run on BCM2711 (bsc#1233108)
  Only take struct vc4file.dev for bsc#1233108. Leave out the commit's
  tests and warnings.
- commit 7eeddbe

- net: relax socket state check at accept time (git-fixes).
- commit 4a31544

- tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets
  (CVE-2024-36905 bsc#1225742).
- commit 9ad4cc7

- drm/vc4: Stop the active perfmon before being destroyed (bsc#1233108 CVE-2024-50187)
- commit f0f44d8

- wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit (CVE-2024-49938 bsc#1232552)
- commit 4092e67

- netfilter: nf_tables: prevent nf_skb_duplicated corruption (CVE-2024-49952 bsc#1232157)
- commit 0b60580

- security/keys: fix slab-out-of-bounds in key_task_permission
  (CVE-2024-50301 bsc#1233490).
- commit 6e6d2aa

- media: cx24116: prevent overflows on SNR calculus
  (CVE-2024-50290 bsc#1233479).
- commit 12a43db

- dm cache: fix out-of-bounds access to the dirty bitset when
  resizing (CVE-2024-50279 bsc#1233468).
- commit a5eeed1

- nvme-pci: fix race condition between reset and
  nvme_dev_disable() (bsc#1232888 CVE-2024-50135).
- commit d800691

- scsi: lpfc: Ensure DA_ID handling completion before deleting
  an NPIV instance (bsc#1233130 CVE-2024-50183).
- commit 2341eee

- tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink()
  (CVE-2024-50154 bsc#1233070).
  Patch has been manually modified to apply.
- commit e2aba08

- nfs: Fix KMSAN warning in decode_getfattr_attrs()
  (CVE-2024-53066 bsc#1233560).
- commit b4e2ec3

- btrfs: fix a NULL pointer dereference when failed to start a
  new trasacntion (CVE-2024-49868 bsc#1232272).
- commit 28e08c8

- Reinstate some of &amp;quot;swiotlb: rework &amp;quot;fix info leak with
  DMA_FROM_DEVICE&amp;quot;&amp;quot; (CVE-2022-48853 bsc#1228015).
- commit ddba53c

- HID: core: zero-initialize the report buffer (CVE-2024-50302
  bsc#1233491).
- commit 6bc7fd8

- vsock/virtio: Initialization of the dangling pointer occurring
  in vsk-&amp;gt;trans (CVE-2024-50264 bsc#1233453).
- commit edf6fa0

- net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged
  SKB data (CVE-2024-53058 bsc#1233552).
- commit ebde361

- Bluetooth: SCO: Fix UAF on sco_sock_timeout (CVE-2024-50125
  bsc#1232928).
- Bluetooth: call sock_hold earlier in sco_conn_del
  (CVE-2024-50125 bsc#1232928).
- commit 4838e6d

- Update
  patches.suse/posix-clock-posix-clock-Fix-unbalanced-locking-in-pc.patch
  (CVE-2024-50195 bsc#1233103 CVE-2024-50210 bsc#1233097).
- commit 4b1cf97

- mm: revert &amp;quot;mm: shmem: fix data-race in shmem_getattr()&amp;quot;
  (CVE-2024-50228, bsc#1233204, git fixes (mm/shmem)).
- commit 84efe19

- posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime() (CVE-2024-50195 bsc#1233103)
- commit dede472

- media: av7110: fix a spectre vulnerability (CVE-2024-50289
  bsc#1233478).
- commit 43a6f6e

- efi/memattr: Ignore table if the size is clearly bogus
  (CVE-2024-49858 bsc#1232251 bsc#1231465).
- commit 3272541

- i40e: fix race condition by adding filter's intermediate sync
  state (CVE-2024-53088 bsc#1233580).
- i40e: fix i40e_count_filters() to count only active/new filters
  (CVE-2024-53088 bsc#1233580).
- commit c0c4369

- ocfs2: remove entry once instead of null-ptr-dereference in
  ocfs2_xa_remove() (bsc#1233454 CVE-2024-50265).
- commit 3e0d522

- net: hns3: fix a deadlock problem when config TC during
  resetting (CVE-2024-44995 bsc#1230231).
- commit 398b1db

- media: dvbdev: prevent the risk of out of memory access
  (CVE-2024-53063 bsc#1233557).
- commit 62f1f9b

- tpm: Lock TPM chip in tpm_pm_suspend() first (bsc#1082555
  git-fixes CVE-2024-53085 bsc#1233577).
- commit 70d272c

- media: s5p-jpeg: prevent buffer overflows (CVE-2024-53061
  bsc#1233555).
- commit 506c426

- Update
  patches.suse/tipc-fix-a-possible-memleak-in-tipc_buf_append.patch
  (bsc#1221977 CVE-2021-47162 bsc#1225764 CVE-2024-36954
  CVE-2024-36886 bsc#1225730).
- commit 6b7c8a5

- net: netem: use a list in addition to rbtree
  (git-fixes CVE-2024-45016 bsc#1230429).
- commit 2b0774f

- swiotlb: fix info leak with DMA_FROM_DEVICE (CVE-2022-48853
  bsc#1228015).
- commit 56fe90d

- crypto: ecdh - explicitly zeroize private_key (CVE-2024-42098
  bsc#1228779).
- commit ef82dbf

- crypto: aead,cipher - zeroize key buffer after use
  (CVE-2024-42229 bsc#1228708).
- commit 1b83698

- btrfs: reinitialize delayed ref list after deleting it from
  the list (bsc#1233462 CVE-2024-50273).
- commit 0901f0b

- Refresh
  patches.suse/net-prevent-mss-overflow-in-skb_segment.patch.
  Fix the following warning:
  net/core/skbuff.c: In function 'skb_segment':
  include/linux/kernel.h:795:16: warning: comparison of distinct pointer types lacks a cast [enabled by default]
  include/linux/kernel.h:798:2: note: in expansion of macro '__min'
  net/core/skbuff.c:3302:18: note: in expansion of macro 'min'
  This is how the warning got silenced in upstream stable kernel
  v4.19.321.
- commit 68ad1ea

- Refresh
  patches.suse/scsi-lpfc-Validate-hdwq-pointers-before-dereferencin.patch.
  Adjust the backport to match the old size of struct members. This
  fixes the following warning:
  ../drivers/scsi/lpfc/lpfc_sli.c: In function 'lpfc_sli_flush_io_rings':
  ../drivers/scsi/lpfc/lpfc_sli.c:4436:5: warning: format '%lx' expects argument of type 'long unsigned int', but argument 5 has type 'int' [-Wformat=]
  ../drivers/scsi/lpfc/lpfc_sli.c:4436:5: warning: format '%lx' expects argument of type 'long unsigned int', but argument 6 has type 'uint32_t' [-Wformat=]
- commit dff4c6e

- kernel-binary: Enable livepatch package only when livepatch is enabled
  Otherwise the filelist may be empty failing the build (bsc#1218644).
- commit f730eec

- Update config files (bsc#1218644).
  LIVEPATCH_IPA_CLONES=n =&amp;gt; LIVEPATCH=n
- commit b1b7b65

- posix-clock: Fix missing timespec64 check in pc_clock_settime() (CVE-2024-50195 bsc#1233103)
- commit 41e678c

- net: systemport: fix potential memory leak in bcm_sysport_xmit() (CVE-2024-50171 bsc#1233057)
- commit a8cf9c8

- Bluetooth: bnep: fix wild-memory-access in proto_unregister (CVE-2024-50148 bsc#1233063)
- commit cb3dc55

- tty: n_gsm: Fix use-after-free in gsm_cleanup_mux (CVE-2024-50073 bsc#1232520)
- commit 68babec

- Update
  patches.suse/arm64-probes-Fix-uprobes-for-big-endian-kernels.patch
  (git-fixes CVE-2024-50194 bsc#1233111).
- Update
  patches.suse/arm64-probes-Remove-broken-LDR-literal-uprobe-support.patch
  (git-fixes CVE-2024-50099 bsc#1232887).
- Update
  patches.suse/ceph-remove-the-incorrect-Fw-reference-check-when-dir.patch
  (bsc#1231184 CVE-2024-50179 bsc#1233123).
- commit c9a203b

- ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow
  (bsc#1233191 CVE-2024-50218).
- commit cc4dbc4

- Update tags in
  patches.suse/ext4-fix-slab-use-after-free-in-ext4_split_extent_at.patch
  (bsc#1232201 CVE-2024-49884 bsc#1232198).
- commit dcc8f26

- Fix compiler warnings introduced in
  patches.suse/udf-Avoid-excessive-partition-lengths.patch.
- commit fc54634

- mm: shmem: fix data-race in shmem_getattr() (CVE-2024-50228,
  bsc#1233204, git fixes (mm/shmem)).
- commit e71d93b

- driver core: bus: Fix double free in driver API bus_register()
  (bsc#1232329 CVE-2024-50055).
- commit 0448963

- KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory
  (CVE-2024-50115 bsc#1232919).
- commit 0050d80

- drm/amd: Guard against bad data for ATIF ACPI method (bsc#1232897 CVE-2024-50117)
- commit 97c9929

- wifi: mac80211: do not pass a stopped vif to the driver in
  .get_txpower (CVE-2024-50237 bsc#1233216).
- commit 6d8f0b7

- wifi: ath10k: Fix memory leak in management tx (CVE-2024-50236
  bsc#1233212).
- commit 0b6cbda

- wifi: iwlegacy: Clear stale interrupts before resuming device
  (CVE-2024-50234 bsc#1233211).
- commit 01cb9ce

- drm/amd/display: Check null pointers before used (bsc#1232371 CVE-2024-49921)
- commit e8deeae

- net/ncsi: Disable the ncsi work before freeing the associated
  structure (CVE-2024-49945 bsc#1232165).
- commit a88491e

- Update tags
  patches.suse/mm-Avoid-overflows-in-dirty-throttling-logic.patch
  (bsc#1222364 CVE-2024-42131 bsc#1228650).
- commit 3f14d21

- RDMA/mad: Improve handling of timed out WRs of mad agent (bsc#1232873 CVE-2024-50095)
- commit 2d90f41

- IB/mad: Issue complete whenever decrements agent refcount (bsc#1232873 CVE-2024-50095)
- commit 27da1c4

- be2net: fix potential memory leak in be_xmit() (CVE-2024-50167
  bsc#1233049).
- commit 4f25cff

- cpufreq: brcmstb-avs-cpufreq: ISO C90 forbids mixed declarations
  (CVE-2024-27051 bsc#1223769).
- commit 6437a99

- driver core: Fix error return code in really_probe()
  (bsc#1232224 CVE-2024-49925).
- commit 7264309

- parport: Proper fix for array out-of-bounds access (CVE-2024-50074 bsc#1232507)
- commit ee8e094

- cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get's
  return value (CVE-2024-27051 bsc#1223769).
- commit e56562b

- vfs: fix race between evice_inodes() and find_inode()&amp;amp;iput()
  (bsc#1231930 CVE-2024-47679).
- commit ebf12b1

- ext4: avoid OOB when system.data xattr changes underneath the
  filesystem (bsc#1231920 CVE-2024-47701).
- commit 06b6d21

- ext4: explicitly exit when ext4_find_inline_entry returns an
  error (bsc#1231920 CVE-2024-47701).
- commit 76db0bc

- ext4: return error on ext4_find_inline_entry (bsc#1231920
  CVE-2024-47701).
- commit 3ce9700

- ext4: ext4_search_dir should return a proper error (bsc#1231920
  CVE-2024-47701).
- commit 35d9543

- wifi: cfg80211: check A-MSDU format more carefully (stable-fixes
  CVE-2024-35937 bsc#1224526).
- blacklist.conf: remove the entry that we're just adding
- commit efe6631

- driver core: kABI workaround for dev_groups in device_driver
  (bsc#1232224 CVE-2024-49925).
- commit 993ec78

- initramfs: avoid filename buffer overrun (bsc#1232436).
- commit 7ae8606

- driver core: add dev_groups to all drivers (bsc#1232224
  CVE-2024-49925).
- commit d16dce7

- fbdev: efifb: Register sysfs groups through driver core
  (bsc#1232224 CVE-2024-49925).
- commit bff3087

- NFC: nci: Bounds check struct nfc_target arrays (bsc#1232304 CVE-2022-48967)
- commit 5a26fef

- net: hisilicon: Fix potential use-after-free in hix5hd2_rx() (bsc#1231979 CVE-2022-48960)
- commit e5b93cf

- kabi/severities: ignore amdgpu symbols
  amdkfd symbols are exported but they are supposed to be used only
  by amdgpu, so they are local symbols that can be ignored.
- commit 381c434

- ipv6: avoid use-after-free in ip6_fragment() (CVE-2022-48956
  bsc#1231893).
- commit fea62f0

- scsi: lpfc: Validate hdwq pointers before dereferencing in
  reset/errata paths (bsc#1232218 CVE-2024-49891).
- commit b5db475

- SLE12-SP5 turned LTSS (Extended Security) - maintainership goes to L3
- commit 6e14d1d

- Bluetooth: RFCOMM: FIX possible deadlock in
  rfcomm_sk_state_change (CVE-2024-50044 bsc#1231904).
- commit e681821

- tipc: guard against string buffer overrun (CVE-2024-49995
  bsc#1232432).
- commit ba288b6

- net/xen-netback: prevent UAF in xenvif_flush_hash()
  (CVE-2024-49936 bsc#1232424).
- commit 2fa13cf

- drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer
  (CVE-2024-49991 bsc#1232282).
- commit ce009ae

- Remove duplicate CVE references
  Update patches.suse/nvme-fix-a-possible-use-after-free-in-controller-res.patch
  Update patches.suse/nvme-rdma-fix-possible-use-after-free-in-transport-e.patch
  Update patches.suse/nvme-tcp-fix-possible-use-after-free-in-transport-er.patch
- commit 2663e32

- mm: split critical region in remap_file_pages() and invoke
  LSMs in between (CVE-2024-47745 bsc#1232135 git-fix).
- commit 661d796

- nfs: fix memory leak in error path of nfs4_do_reclaim
  (git-fixes).
- nfsd: fix delegation_blocked() to block correctly for at least
  30 seconds (git-fixes).
- commit 05c4d99

- Update
  patches.suse/IB-core-Implement-a-limit-on-UMAD-receive-List.patch
  (bsc#1228743 CVE-2024-42145 bsc#1223384).
- Update
  patches.suse/RDMA-cxgb4-Added-NULL-check-for-lookup_atid.patch
  (git-fixes CVE-2024-47749 bsc#1232180).
- Update
  patches.suse/RDMA-iwcm-Fix-WARNING-at_kernel-workqueue.c-check_fl.patch
  (git-fixes CVE-2024-47696 bsc#1231864).
- Update
  patches.suse/aoe-fix-the-potential-use-after-free-problem-in-more.patch
  (bsc#1218562 CVE-2023-6270 CVE-2024-49982 bsc#1232097).
- Update patches.suse/media-edia-dvbdev-fix-a-use-after-free.patch
  (CVE-2024-27043 bsc#1223824 bsc#1218562).
- Update
  patches.suse/ocfs2-fix-null-ptr-deref-when-journal-load-failed.patch
  (git-fixes CVE-2024-49957 bsc#1232152).
- Update
  patches.suse/ocfs2-fix-possible-null-ptr-deref-in-ocfs2_set_buffer_uptodate.patch
  (git-fixes CVE-2024-49877 bsc#1232339).
- Update
  patches.suse/ocfs2-remove-unreasonable-unlock-in-ocfs2_read_blocks.patch
  (git-fixes CVE-2024-49965 bsc#1232142).
- commit d1259c0

- Update
  patches.suse/nfc-nci-fix-possible-NULL-pointer-dereference-in-sen.patch
  (bsc#1219125 CVE-2023-46343 CVE-2023-52919 bsc#1231988).
- Update
  patches.suse/tcp-do-not-accept-ACK-of-bytes-we-never-sent.patch
  (CVE-2023-52881 bsc#1225611 bsc#1223384).
- commit 9477732

- Update
  patches.suse/char-tpm-Protect-tpm_pm_suspend-with-locks.patch
  (bsc#1082555 CVE-2022-48997 bsc#1232035).
- Update
  patches.suse/igb-Initialize-mailbox-message-for-VF-reset.patch
  (git-fixes CVE-2022-48949 bsc#1231897).
- Update
  patches.suse/net-mana-Fix-race-on-per-CQ-variable-napi-work_done.patch
  (bsc#1229154 CVE-2022-48985 bsc#1231958).
- Update
  patches.suse/nvme-fix-a-possible-use-after-free-in-controller-res.patch
  (bsc#1227941 (CVE-2022-48790) CVE-2022-48790).
- Update
  patches.suse/nvme-rdma-fix-possible-use-after-free-in-transport-e.patch
  (bsc#1227952 (CVE-2022-48788) CVE-2022-48788).
- Update
  patches.suse/nvme-tcp-fix-possible-use-after-free-in-transport-er.patch
  (bsc#1228000 (CVE-2022-48789) CVE-2022-48789).
- Update
  patches.suse/udf-Fix-preallocation-discarding-at-indirect-extent-.patch
  (bsc#1213034 CVE-2022-48946 bsc#1231888).
- Update
  patches.suse/xen-netfront-Fix-NULL-sring-after-live-migration.patch
  (git-fixes CVE-2022-48969 bsc#1232026).
- commit c8e7e6a

- Update patches.suse/phy-mdio-fix-memory-leak.patch (git-fixes
  bsc#1225336 CVE-2021-47416 bsc#1225189).
- commit 9036983

- smb: client: fix UAF in async decryption (bsc#1232418,
  CVE-2024-50047).
- commit f679375

- drm/amd/display: Fix index out of bounds in degamma hardware format translation (CVE-2024-49894 bsc#1232354)
- commit b558147

- drm/msm/adreno: Assign msm_gpu-&amp;gt;pdev earlier to avoid nullptrs (CVE-2024-49901 bsc#1232305)
- commit 9c2561f

- ext4: fix i_data_sem unlock order in ext4_ind_migrate() (CVE-2024-50006 bsc#1232442)
- commit 8639f10

- ALSA: asihpi: Fix potential OOB array access (CVE-2024-50007 bsc#1232394)
- commit 013518a

- jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error (CVE-2024-49959 bsc#1232149)
- commit 284567a

- ACPI: sysfs: validate return type of _STR method (bsc#1231861
  CVE-2024-49860).
- commit aede924

- mm/khugepaged: invoke MMU notifiers in shmem/file collapse paths
  (CVE-2022-48991 bsc#1232070).
- commit bc2150c

- mm/khugepaged: fix GUP-fast interaction by sending IPI
  (CVE-2022-48991 bsc#1232070 prerequisity).
- commit 1df90ba

- khugepaged: retract_page_tables() remember to test exit
  (CVE-2022-48991 bsc#1232070 prerequisity).
- commit f4a1619

- ext4: update orig_path in ext4_find_extent() (CVE-2024-49881 bsc#1232201)
- commit b5dc210

- ext4: fix slab-use-after-free in ext4_split_extent_at() (bsc#1232201)
- commit 693aa17

- btrfs: don't BUG_ON on ENOMEM from btrfs_lookup_extent_info()
  in walk_down_proc() (CVE-2024-46841 bsc#1231094).
- commit 6d306f6

- ext4: aovid use-after-free in ext4_ext_insert_extent() (CVE-2024-49883 bsc#1232199)
- commit ec16b20

- wifi: iwlwifi: mvm: avoid NULL pointer dereference (CVE-2024-49929 bsc#1232253)
- commit 84425bf

- net: fix a memleak when uncloning an skb dst and its metadata
  (CVE-2022-48809 bsc#1227947).
- commit 2bf5e2a

- tpm: Clean up TPM space after command failure (CVE-2024-49851
  bsc#1232134).
- commit 7bbb5a1

- serial: protect uart_port_dtr_rts() in uart_shutdown() too
  (CVE-2024-50058 bsc#1232285).
- commit 41b7884

- ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package() (CVE-2024-49962 bsc#1232314)
- commit 4df8d00

- drm/amd/display: Check stream before comparing them (CVE-2024-49896 bsc#1232221)
- commit b1fe975

- drm/amd/pm: ensure the fw_info is not null before using it (CVE-2024-49890 bsc#1232217)
- commit c3be196

- ASoC: ops: Correct bounds check for second channel on SX controls (CVE-2022-48951 bsc#1231929)
- commit bf654bc

- firmware_loader: Block path traversal (CVE-2024-47742 bsc#1232126)
- commit 7af5448

- ASoC: soc-pcm: Add NULL check in BE reparenting (CVE-2022-48992 bsc#1232071)
- commit 70e6117

- media: pci: cx23885: check cx23885_vdev_init() return (CVE-2023-52918 bsc#1232047)
- commit 713adf4

- ASoC: ops: Check bounds for second channel in snd_soc_put_volsw_sx() (CVE-2022-48951 bsc#1231929)
- commit 26bb290

- btrfs: clean up our handling of refs == 0 in snapshot delete (CVE-2024-46840 bsc#1231105)
- commit 61febb6

- drm/amd/display: Check null pointers before multiple uses (bsc#1232313 CVE-2024-49920)
- commit 2448039

- iommu/vt-d: Fix PCI device refcount leak in  has_external_pci()
  (bsc#1232123 CVE-2022-49000).
- commit 02b654b

- net: mvneta: Fix an out of bounds check (CVE-2022-48966
  bsc#1232191).
- commit 0317c39

- iommu/vt-d: Fix PCI device refcount leak in
  dmar_dev_scope_init() (bsc#1232133 CVE-2022-49002).
- commit 5c0b5c2

- net: hisilicon: Fix potential use-after-free in hisi_femac_rx()
  (CVE-2022-48962 bsc#1232286).
- commit fc49b9f

- ppp: fix ppp_async_encode() illegal access (CVE-2024-50035
  bsc#1232392).
- net: avoid potential underflow in qdisc_pkt_len_init() with UFO
  (CVE-2024-49949 bsc#1232160).
- net: mvneta: Prevent out of bounds read in mvneta_config_rss()
  (CVE-2022-48966 bsc#1232191).
- net/9p: Fix a potential socket leak in p9_socket_open
  (CVE-2022-49020 bsc#1232175).
- commit 2c23eba

- hwmon: (coretemp) fix pci device refcount leak in nv1a_ram_new()
  (bsc#1232006 CVE-2022-49011).
- hwmon: (coretemp) Check for null before removing sysfs attrs
  (bsc#1232172 CVE-2022-49010).
- hwmon: (ibmpex) Fix possible UAF when ibmpex_register_bmc()
  fails (bsc#1231995 CVE-2022-49029).
- commit 71880ba

- Update
  patches.suse/0001-x86-kaslr-Expose-and-use-the-end-of-the-physical-mem.patch
  (bsc#1230405, bsc#1232236).
- commit a8a279f

- mm: call the security_mmap_file() LSM hook in remap_file_pages()
  (CVE-2024-47745 bsc#1232135).
- commit ed0f269

- Bluetooth: L2CAP: Fix uaf in l2cap_connect (CVE-2024-49950
  bsc#1232159).
- commit 30ab1b9

- arm64: probes: Fix uprobes for big-endian kernels (git-fixes)
- commit 3e6f9a6

- arm64: probes: Fix simulate_ldr*_literal() (git-fixes)
- commit a1137d7

- arm64: probes: Remove broken LDR (literal) uprobe support (git-fixes)
- commit e35a346

- arm64: esr: Define ESR_ELx_EC_* constants as UL (git-fixes)
- commit 03723c2

- ext4: fix double brelse() the buffer of the extents path
  (bsc#1232200 CVE-2024-49882).
- ext4: no need to continue when the number of entries is 1
  (bsc#1232140 CVE-2024-49967).
- commit fc369f8

- ethernet: aeroflex: fix potential skb leak in greth_init_rings()
  (CVE-2022-48958 bsc#1231889).
- e100: Fix possible use after free in e100_xmit_prepare
  (CVE-2022-49026 bsc#1231997).
- iavf: Fix error handling in iavf_init_module() (CVE-2022-49027
  bsc#1232007).
- ixgbevf: Fix resource leak in ixgbevf_init_module()
  (CVE-2022-49028 bsc#1231996).
- net: phy: fix null-ptr-deref while probe() failed
  (CVE-2022-49021 bsc#1231939).
- commit ed7ba02

- net: usb: usbnet: fix name regression (get-fixes).
- commit 505fee4

- drm/amd/display: Check gpio_id before used as array index (CVE-2024-46818 bsc#1231203).
- commit 38ee0dd

- drbd: Fix atomicity violation in drbd_uuid_set_bm() (git-fixes).
- drbd: Add NULL check for net_conf to prevent dereference in
  state validation (git-fixes).
- commit 8ea7f3b

- gpio: amd8111: Fix PCI device reference count leak (CVE-2022-48973 bsc#1232039)
- commit cbd0482

- Bluetooth: Fix not cleanup led when bt_init fails (CVE-2022-48971 bsc#1232037)
- commit ce6c97c

- cifs: Fix buffer overflow when parsing NFS reparse points
  (bsc#1232089, CVE-2024-49996).
- commit 009c8ed

- netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() (CVE-2024-47685 bsc#1231998)
- commit 6b03439

- net: Fix an unsafe loop on the list (CVE-2024-50024 bsc#1231954)
- commit b3d8cae

- ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev() (CVE-2024-47707 bsc#1231935)
- commit 4b59ef3

- mac802154: fix missing INIT_LIST_HEAD in ieee802154_if_add() (CVE-2022-48972 bsc#1232025)
- commit 0168947

- HID: core: fix shift-out-of-bounds in hid_report_raw_event (CVE-2022-48978 bsc#1232038)
- commit 7a79be0

- netfilter: br_netfilter: fix panic with metadata_dst skb (CVE-2024-50045 bsc#1231903)
- commit 2c7a2ef

- block, bfq: fix possible UAF for bfqq-&amp;gt;bic with merge chain (CVE-2024-47706 bsc#1231942)
- commit c8fc3bd

- tcp: check skb is non-NULL in tcp_rto_delta_us() (CVE-2024-47684 bsc#1231987)
- commit 3560609

- net: hsr: Fix potential use-after-free (CVE-2022-49015 bsc#1231938)
- commit 6ebc760

- ocfs2: cancel dqi_sync_work before freeing oinfo (bsc#1232141
  CVE-2024-49966).
- commit b3c314a

- RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled (bsc#1232111 CVE-2024-47735)
- commit 78adc47

- ocfs2: reserve space for inline xattr before attaching reflink
  tree (bsc#1232151 CVE-2024-49958).
- commit 75ba1c4

- wifi: mac80211: use two-phase skb reclamation in
  ieee80211_do_stop() (CVE-2024-47713 bsc#1232016).
- commit 6ae0d21

- nfsd: call cache_put if xdr_reserve_space returns NULL
  (bsc#1232056 CVE-2024-47737).
- commit 629ef18

- Update
  patches.suse/memcg-Fix-possible-use-after-free-in-memcg_write_event_control.patch
  (bsc#1206344, CVE-2022-48988, bsc#1232069).
- commit 3727547

- slip: make slhc_remember() more robust against malicious packets
  (CVE-2024-50033 bsc#1231914).
- net: tun: Fix use-after-free in tun_detach() (CVE-2022-49014
  bsc#1231890).
- commit c68baf4

- md/raid5: fix deadlock that raid5d() wait for itself to clear
  MD_SB_CHANGE_PENDING (bsc#1227437, CVE-2024-39476).
- Delete the following patch, it is replaced by the above one,
  patches.suse/Revert-md-raid5-Wait-for-MD_SB_CHANGE_PENDING-in-rai.patch.
- commit e9834f3

- net/ipv6: prevent use after free in ip6_route_mpath_notify
  (CVE-2024-26852 bsc#1223057 bsc#1230784).
- Update
  patches.suse/net-ipv6-avoid-possible-UAF-in-ip6_route_mpath_notif.patch
  (CVE-2024-26852 bsc#1223057 bsc#1230784).
- commit 7d060a6

- drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds
  write  error (bsc#1231858 CVE-2024-47697).
- drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds
  write  error (bsc#1231859 CVE-2024-47698).
- commit d62c304

- ethtool: fail closed if we can't get max channel used in
  indirection tables (CVE-2024-46834 bsc#1231096).
- commit bddfacf

- gpio: prevent potential speculation leaks in
  gpio_device_get_desc() (stable-fixes CVE-2024-44931
  bsc#1229837).
- commit 664410d

- gpio: pca953x: fix pca953x_irq_bus_sync_unlock race
  (stable-fixes CVE-2024-42253 bsc#1229005).
- commit 966ef70

- mm: avoid leaving partial pfn mappings around in error case
  (CVE-2024-47674 bsc#1231673).
- commit b85f7d9

- udf: Avoid excessive partition lengths (bsc#1230773
  CVE-2024-46777).
- fsnotify: clear PARENT_WATCHED flags lazily (bsc#1231439
  CVE-2024-47660).
- commit 1cf833b

- netem: fix return value if duplicate enqueue fails
  (CVE-2024-45016 bsc#1230429).
- net: netem: fix use after free and double free with packet
  corruption (git-fixes CVE-2024-45016 bsc#1230429).
- net: netem: correct the parent's backlog when corrupted packet
  was dropped (git-fixes CVE-2024-45016 bsc#1230429).
- net: netem: fix error path for corrupted GSO frames (git-fixes
  CVE-2024-45016 bsc#1230429).
- net: netem: fix backlog accounting for corrupted GSO frames
  (git-fixes CVE-2024-45016 bsc#1230429).
- commit 8535e0c

- perf/x86/intel: Limit the period on Haswell (bsc#1231072,
  CVE-2024-46848).
- commit ddcb55d

- Update
  patches.suse/ocfs2-add-bounds-checking-to-ocfs2_xattr_find_entry.patch
  (bsc#1228410 CVE-2024-41016 CVE-2024-47670 bsc#1231537).
- commit 3c9794f

- wifi: iwlwifi: mvm: pause TCM when the firmware is stopped
  (CVE-2024-47673 bsc#1231539).
- commit ec71cef

- wifi: iwlwifi: mvm: don't wait for tx queues if firmware is dead
  (CVE-2024-47672 bsc#1231540).
- commit bf00ca5

- sched/smt: Fix unbalance sched_smt_present dec/inc
  (CVE-2024-44958 bsc#1230179).
- commit d76ce7a

- add bug reference for a mana change (bsc#1229769).
- commit 365e607

- nfc: fix segfault in nfc_genl_dump_devices_done (CVE-2021-47612 bsc#1226585)
- commit 04d816c

- aoe: fix the potential use-after-free problem in more places
  (bsc#1218562 CVE-2023-6270).
- commit 9a97d1d

- xhci: Fix null pointer dereference when host dies
  (CVE-2023-52898 bsc#1229568).
- commit 8083a37

- bpf: Fix pointer-leak due to insufficient speculative store
  bypass mitigation (bsc#1231375).
- commit 8169915

- wifi: mwifiex: Do not return unused priv in
  mwifiex_get_priv_by_id() (bsc#1230802 CVE-2024-46755).
- commit 3faac0d

- Delete some more obsolete scripts
- commit c036565

- drm/amd/display: Stop amdgpu_dm initialize when link nums greater than max_links (CVE-2024-46816 bsc#1231197).
- commit fce3225

- drm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_number (bsc#1230725 CVE-2024-46724)
- commit a6d26f5

- drm/amd/display: Check link_index before accessing dc-&amp;gt;links (CVE-2024-46813 bsc#1231191).
- commit 6cd35ce

- rpm/release-projects: Add SLFO projects (bsc#1231293).
- commit 9f2c584

- Update kabi files from rpm-4.12.14-122.228
  Some nvme symbols are listed as exported from vmlinux while the driver
  is modular. This is because the symvers files were not updated after
  making the driver modular.
- commit 00d2c7f

- ELF: fix kernel.randomize_va_space double read (CVE-2024-46826 bsc#1231115)
  Dropped const and split declaration and assignment to avoid warning of
  mixing declarations and statements.
- commit 8b66569

- drm/amd/display: added NULL check at start of dc_validate_stream (CVE-2024-46802 bsc#1231111)
- commit a598fc3

Package google-guest-configs was updated:

- Update to version 20241121.00 (bsc#1233625, bsc#1233626)  * Temporarily revert google_set_multiqueue changes for release (#92)
- from version 20241115.00
  * Remove IDPF devices from renaming rules (#91)
- from version 20241112.00
  * Revert &amp;quot;Revert 3 commits:&amp;quot; (#89)
- from version 20241108.00
  * Revert 3 commits: (#87)
- from version 20241107.00
  * gce-nic-naming: Exit 1 so that udev ignores the rule on error (#86)
- from version 20241106.00
  * Remove Apt IPv4 only config for Debian and Ubuntu (#85)
- from version 20241031.00
  * Add GCE intent based NIC naming tools (#84)
- from version 20241025.00
  * Update google_set_multiqueue to skip set_irq
    if NIC is not a gvnic device (#83)
- Add new binary gce-nic-naming to %{_bindir} in %files section

- Update to version 20241021.00 (bsc#1231775, bsc#1231776)
  * Add GCE-specific config for systemd-resolved (#82)
- from version 20241015.00
  * Update google_set_multiqueue to enable on A3Ultra family (#79)
- from version 20241013.00
  * Update OWNERS (#81)
- from version 20241010.00
  * Depend on jq in enterprise linux (#80)
- from version 20241008.00
  * Always use IP from primary NIC in the
    networkd-dispatcher routable hook (#78)

- Update to version 20240925.00
  * Call google_set_hostname on openSUSE and when the agent
    is configured to manage hostname and FQDN, let it (#75)
- from version 20240924.00
  * Include systemd-networkd hook in Ubuntu packaging (#77)
- from version 20240905.00
  * Update packaging as of Ubuntu devel packaging (#65)
- from version 20240830.00
  * Fix the name for A3 Edge VMs (#76)

- Update to version 20240725.00
  * Fix: hostnamectl command (#74)

- Update to version 20240607.00
  * Update is_a3_platform to include A3-edge shape (#73)

- Update to version 20240514.00
  * Add systemd-networkd hostname hook (#71)
- from version 20240501.00
  * Add hostname hook for NetworkManager without
    dhclient compat script (#70)

Package google-guest-agent was updated:

- Update to version 20241011.01 (bsc#1231775, bsc#1231776)  * SUSE no overwrite bug fix, Ubuntu 18.04 exception (#451)
- from version 20241011.00
  * Skip MDS setup by default for this release (#450)
- from version 20241010.01
  * Revert &amp;quot;network/netplan: Adjust link-local accordingly (#443)&amp;quot; (#448)
  * Set enable regardless of previous check failed or not (#447)
- from version 20241009.03
  * Avoid unnecessary reloads, check before overwriting configs (#446)
- from version 20241009.02
  * network/netplan: Do generate instead of apply (#445)
- from version 20241009.01
  * Skip SetupInterfaces if configs are already applied (#444)
  * network/netplan: Adjust link-local accordingly (#443)
  * Repeated logging could be mistaken for a recurring issue,
    log mds mtls endpoint error only once (#439)
  * Retry MDS PUT operation, reload netplan/networkctl
    only if configs are changed (#438)
  * Log interface state after setting up network (#437)
  * network: Debian 12 rollback only if default netplan is ok (#436)
- from version 20240930.01
  * Change mtls mds defaults, update log message to assure error is harmless (#434)
- from version 20240930.00
  * network: Restore Debian 12 netplan configuration. (#433)
  * network: Remove primary NIC left over configs. (#432)
  * Update VLAN interfaces format to match with MDS (#431)
  * Fix panics in agent when setting up VLAN with netplan (#430)
  * Add VLAN NIC support for NetworkManager (#429)
  * Fix debian12 netplan config issue, use ptr receiver (#428)
  * Update README to reflect new network manager changes (#427)
  * Introduce a configuration toggle for enabling/disabling cloud logging (#413)
  * Adapt and update config key to be consistent with MDS (#426)
  * Allow users to enable/disable the mds mtls via metadata key (#423)
  * Make primary nic management config consistent across all network managers (#422)
  * Document disabling account manager on AD (#421)
  * Update README with MDS MTLS docs (#418)
  * Avoid writing configuration files when they already exist on wicked and (#410)
  * Update golang.org/x/net dependencies to catch up on CVEs (#412)
  * Get rid of deperecated dependencies in snapshot service generate code (#411)
  * Fix where agent panics on nil event (#409)
  * Configure primary nic if only set in cfg file (#408)
  * Update NIC management strategy (#402)
  * Only release dhclient leases for an interface if the
    respective dhclient is still running (#407)
  * Disable OS Login without pruning off any extra suffix. (#400)
  * Skip root cert rotation if installed once (#405)
  * Add ipv6 support to guest agent (#404)
  * Update Accounts documentation (#403)
  * Update google-startup-scripts.service to enable logging (#399)
  * Network subsystem remove os rules (#396)
  * oslogin: Don't remove sshca watcher when oslogin is disabled (#398)
  * Update dependencies to catch up on CVE fixes (#397)
  * Network manager netplan implementation (#386)
  * Update dependencies to catch up on CVE fixes (#391)
  * Log current available routes on error (#388)
  * Fix command monitor bugs (#389)
  * windows account: Ignore &amp;quot;user already belogs to group&amp;quot; error (#387)
  * Add more error logging in snapshot handling requests, use common retry util (#384)
  * All non-200 status code from MDS should raise error (#383)
  * Change metadata key to enable-oslogin-certificates (#382)
  * Update dhclient pid/lease file directory to abide apparmor rules (#381)
  * Add COS homedir-gid patch to upstream. (#365)
  * Add require-oslogin-certificates logic to disable keys (#368)
  * systemd-networkd: Support Debian 12's version (#372)
  * Minor update typo in comment (#380)
  * NetworkManager: Only set secondary interfaces as up (#378)
  * address manager: Make sure we check for oldMetadata (#375)
  * network: Early setup network (#374)
  * NetworkManager: Fix ipv6 and ipv4 mode attribute (#373)
  * Network Manager: Make sure we clean up ifcfg files (#371)
  * metadata script runner: Fix script download (#370)
  * oslogin: Avoid adding extra empty line at the end of /etc/security/group.conf (#369)
  * Dynamic vlan (#361)
  * Check for nil response (#366)
  * Create NetworkManager implementation (#362)
  * Skip interface manager on Windows (#363)
  * network: Remove ignore setup (#360)
  * Create wicked network service implementation and its respective unit (#356)
  * Update metadata script runner, add tests (#357)
  * Refactor guest-agent to use common retry util (#355)
  * Flush logs before exiting #358 (#359)
  * Create systemd-networkd unit tests. (#354)
  * Update network manager unit tests (#351)
  * Implement retry util (#350)
  * Refactor utils package to not dump everything unrelated into one file (#352)
  * Set version on metadata script runner (#353)
  * Implement cleanup of deprecated configuration directives (#348)
  * Ignore DHCP offered routes only for secondary nics (#347)
  * Deprecate DHClient in favor of systemd-networkd (#342)
  * Generate windows and linux licenses (#346)
  * Remove quintonamore from OWNERS (#345)
  * Delete integration tests (#343)

- Update to version 20240816.00
  * Add configuration toggle to enable/disable use
    of OS native certificate stores (#419)
  * Fix dependencies in stable branch #412 (#415)
  * Update dep: golang.org/x/crypto to v0.17.0
  * Update dep: google.golang.org/protobuf to 1.33.0
  * Update dep: golang.org/x/net to 0.17.0
  * Update dep: google.golang.org/grpc to v1.57.1
- from version 20240813.00
  * Update README with MDS MTLS docs (#418)
- from version 20240808.01
  * Avoid writing configuration files when they already
    exist on wicked and NetworkManager (#410)
- from version 20240808.00
  * Update golang.org/x/net dependencies
    to catch up on CVEs (#412)
- from version 20240805.00
  * Get rid of deperecated dependencies in
    snapshot service generate code (#411)
- Drop dont_overwrite_ifcfg.patch, fixed upstream

- Update to version 20240802.00
  * Fix where agent panics on nil event (#409)
- from version 20240801.00
  * Configure primary nic if only set in cfg file (#408)
  * Update NIC management strategy (#402)
  * Only release dhclient leases for an interface if the respective dhclient is still running (#407)
  * Disable OS Login without pruning off any extra suffix. (#400)
  * Skip root cert rotation if installed once (#405)
  * Add ipv6 support to guest agent (#404)
  * Update Accounts documentation (#403)
  * Update google-startup-scripts.service to enable logging (#399)
  * Network subsystem remove os rules (#396)
  * oslogin: don't remove sshca watcher when oslogin is disabled (#398)
  * Update dependencies to catch up on CVE fixes (#397)
  * Network manager netplan implementation (#386)
  * Update dependencies to catch up on CVE fixes (#391)
  * Log current available routes on error (#388)
  * Fix command monitor bugs (#389)
  * Windows account: ignore &amp;quot;user already belogs to group&amp;quot; error (#387)
  * Add more error logging in snapshot handling requests, use common retry util (#384)
  * All non-200 status code from MDS should raise error (#383)
  * Change metadata key to enable-oslogin-certificates (#382)
  * Update dhclient pid/lease file directory to abide apparmor rules (#381)
  * Add COS homedir-gid patch to upstream. (#365)
  * Add require-oslogin-certificates logic to disable keys (#368)
  * systemd-networkd: support debian 12's version (#372)
  * Minor update typo in comment (#380)
  * NetworkManager: only set secondary interfaces as up (#378)
  * address manager: make sure we check for oldMetadata (#375)
  * network: early setup network (#374)
  * NetworkManager: fix ipv6 and ipv4 mode attribute (#373)
  * Network Manager: make sure we clean up ifcfg files (#371)
  * metadata script runner: fix script download (#370)
  * oslogin: avoid adding extra empty line at the end of /etc/security/group.conf (#369)
  * Dynamic vlan (#361)
  * Check for nil response (#366)
  * Create NetworkManager implementation (#362)
  * Skip interface manager on Windows (#363)
  * network: remove ignore setup (#360)
  * Create wicked network service implementation and its respective unit (#356)
  * Update metadata script runner, add tests (#357)
  * Refactor guest-agent to use common retry util (#355)
  * Flush logs before exiting #358 (#359)
  * Create systemd-networkd unit tests. (#354)
  * Update network manager unit tests (#351)
  * Implement retry util (#350)
  * Refactor utils package to not dump everything unrelated into one file (#352)
  * Set version on metadata script runner (#353)
  * Implement cleanup of deprecated configuration directives (#348)
  * Ignore DHCP offered routes only for secondary nics (#347)
  * Deprecate DHClient in favor of systemd-networkd (#342)
  * Generate windows and linux licenses (#346)
  * Remove quintonamore from OWNERS (#345)
  * Delete integration tests (#343)
- from version 20240716.00
  * Update dep: golang.org/x/crypto to v0.17.0
  * Update dep: google.golang.org/protobuf to 1.33.0
  * Update dep: golang.org/x/net to 0.17.0
  * Update dep: google.golang.org/grpc to v1.57.1

- Update to version 20240701.00
  * Update google-startup-scripts.service to enable logging (#399)

- Update to version 20240611.01
  * Network subsystem remove os rules (#396)
  * oslogin: don't remove sshca watcher when oslogin is disabled (#398)
  * update dependencies to catch up on CVE fixes (#397)
  * Network manager netplan implementation (#386)
  * update dependencies to catch up on CVE fixes (#391)
  * Log current available routes on error (#388)
  * Fix command monitor bugs (#389)
  * windows account: ignore &amp;quot;user already belogs to group&amp;quot; error (#387)
  * Add more error logging in snapshot handling requests, use common retry util (#384)
  * All non-200 status code from MDS should raise error (#383)
  * change metadata key to enable-oslogin-certificates (#382)
  * Update dhclient pid/lease file directory to abide apparmor rules (#381)
  * Add COS homedir-gid patch to upstream. (#365)
  * Add require-oslogin-certificates logic to disable keys (#368)
  * systemd-networkd: support debian 12's version (#372)
  * Minor update typo in comment (#380)
  * NetworkManager: only set secondary interfaces as up (#378)
  * address manager: make sure we check for oldMetadata (#375)
  * network: early setup network (#374)
  * NetworkManager: fix ipv6 and ipv4 mode attribute (#373)
  * Network Manager: make sure we clean up ifcfg files (#371)
  * metadata script runner: fix script download (#370)
  * oslogin: avoid adding extra empty line at the end of /etc/security/group.conf (#369)
  * Dynamic vlan (#361)
  * Check for nil response (#366)
  * Create NetworkManager implementation (#362)
  * Skip interface manager on Windows (#363)
  * network: remove ignore setup (#360)
  * Create wicked network service implementation and its respective unit (#356)
  * Update metadata script runner, add tests (#357)
  * Refactor guest-agent to use common retry util (#355)
  * Flush logs before exiting #358 (#359)
  * Create systemd-networkd unit tests. (#354)
  * Update network manager unit tests (#351)
  * Implement retry util (#350)
  * Refactor utils package to not dump everything unrelated into one file (#352)
  * Set version on metadata script runner (#353)
  * Implement cleanup of deprecated configuration directives (#348)
  * ignore DHCP offered routes only for secondary nics (#347)
  * Deprecate DHClient in favor of systemd-networkd (#342)
  * Generate windows and linux licenses (#346)
  * Remove quintonamore from OWNERS (#345)
  * Delete integration tests (#343)
- from version 20240528.00
  * update dep: golang.org/x/crypto to v0.17.0
  * update dep: google.golang.org/protobuf to 1.33.0
  * update dep: golang.org/x/net to 0.17.0
  * update dep: google.golang.org/grpc to v1.57.1

Package iputils was updated:

- Bring back ifenslave binary bcs#1234224  * Add iputils-ifenslave.diff
  * Rebase iputils-disable-rarpd-rdisc.patch

Package libzypp was updated:

- Url: queryparams without value should not have a trailing &amp;quot;=&amp;quot;.- version 16.22.15 (0)

- Url query part: `=` is a safe char in value (bsc#1234304)
  Some CDN auth token implementations require a `=` within the
  query parameters value not to be %-encoded.
- version 16.22.14 (0)

Package suseconnect-ng was updated:

- Update version to 1.13:  - Integrating uptime-tracker
  - Honor auto-import-gpg-keys flag on migration (bsc#1231328)
  - Only send labels if targetting SCC
  - Skip the docker auth generation on RMT (bsc#1231185)
  - Add --set-labels to register command to set labels at registration time on SCC
  - Add a new function to display suse-uptime-tracker version
  - Integrate with uptime-tracker ( https://github.com/SUSE/uptime-tracker/ )
  - Add a command to show the info being gathered

Package sudo was updated:

- Fix a regression in -P handling cased by fix for CVE-2021-3156  Fix provided by Brahmajit Das [bsc#1234371]
  * sudo-CVE-2021-3156.patch updated

</Note>
    <Note Title="Terms of Use" Type="Legal Disclaimer" Ordinal="3" xml:lang="en">The CVRF data is provided by SUSE under the Creative Commons License 4.0 with Attribution (CC-BY-4.0).</Note>
  </DocumentNotes>
  <DocumentReferences>
    <Reference Type="Self">
      <URL>https://publiccloudimagechangeinfo.suse.com/google/sles-12-sp5-byos-v20250107-x86-64/</URL>
      <Description>Public Cloud Image Info</Description>
    </Reference>
    <Reference Type="Self">
      <URL>https://www.suse.com/support/security/rating/</URL>
      <Description>SUSE Security Ratings</Description>
    </Reference>
  </DocumentReferences>
  <ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
    <Branch Type="Product Family" Name="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <Branch Type="Product Name" Name="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
        <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
      </Branch>
    </Branch>
    <Branch Type="Product Version" Name="cloud-regionsrv-client-10.3.7-52.117.1">
      <FullProductName ProductID="cloud-regionsrv-client-10.3.7-52.117.1">cloud-regionsrv-client-10.3.7-52.117.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cloud-regionsrv-client-plugin-gce-1.0.0-52.117.1">
      <FullProductName ProductID="cloud-regionsrv-client-plugin-gce-1.0.0-52.117.1">cloud-regionsrv-client-plugin-gce-1.0.0-52.117.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="curl-8.0.1-11.101.1">
      <FullProductName ProductID="curl-8.0.1-11.101.1">curl-8.0.1-11.101.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="expat-2.1.0-21.40.1">
      <FullProductName ProductID="expat-2.1.0-21.40.1">expat-2.1.0-21.40.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glib2-tools-2.48.2-12.43.1">
      <FullProductName ProductID="glib2-tools-2.48.2-12.43.1">glib2-tools-2.48.2-12.43.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="google-guest-agent-20241011.01-1.41.3">
      <FullProductName ProductID="google-guest-agent-20241011.01-1.41.3">google-guest-agent-20241011.01-1.41.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="google-guest-configs-20241121.00-1.35.1">
      <FullProductName ProductID="google-guest-configs-20241121.00-1.35.1">google-guest-configs-20241121.00-1.35.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="google-osconfig-agent-20240926.03-1.29.3">
      <FullProductName ProductID="google-osconfig-agent-20240926.03-1.29.3">google-osconfig-agent-20240926.03-1.29.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="iputils-s20161105-11.6.2">
      <FullProductName ProductID="iputils-s20161105-11.6.2">iputils-s20161105-11.6.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="kernel-default-4.12.14-122.237.1">
      <FullProductName ProductID="kernel-default-4.12.14-122.237.1">kernel-default-4.12.14-122.237.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libavahi-client3-0.6.32-32.30.1">
      <FullProductName ProductID="libavahi-client3-0.6.32-32.30.1">libavahi-client3-0.6.32-32.30.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libavahi-common3-0.6.32-32.30.1">
      <FullProductName ProductID="libavahi-common3-0.6.32-32.30.1">libavahi-common3-0.6.32-32.30.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libcurl4-8.0.1-11.101.1">
      <FullProductName ProductID="libcurl4-8.0.1-11.101.1">libcurl4-8.0.1-11.101.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libexpat1-2.1.0-21.40.1">
      <FullProductName ProductID="libexpat1-2.1.0-21.40.1">libexpat1-2.1.0-21.40.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgcc_s1-13.3.0+git8781-1.16.1">
      <FullProductName ProductID="libgcc_s1-13.3.0+git8781-1.16.1">libgcc_s1-13.3.0+git8781-1.16.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgio-2_0-0-2.48.2-12.43.1">
      <FullProductName ProductID="libgio-2_0-0-2.48.2-12.43.1">libgio-2_0-0-2.48.2-12.43.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libglib-2_0-0-2.48.2-12.43.1">
      <FullProductName ProductID="libglib-2_0-0-2.48.2-12.43.1">libglib-2_0-0-2.48.2-12.43.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgmodule-2_0-0-2.48.2-12.43.1">
      <FullProductName ProductID="libgmodule-2_0-0-2.48.2-12.43.1">libgmodule-2_0-0-2.48.2-12.43.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgobject-2_0-0-2.48.2-12.43.1">
      <FullProductName ProductID="libgobject-2_0-0-2.48.2-12.43.1">libgobject-2_0-0-2.48.2-12.43.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libpython2_7-1_0-2.7.18-33.38.1">
      <FullProductName ProductID="libpython2_7-1_0-2.7.18-33.38.1">libpython2_7-1_0-2.7.18-33.38.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libpython3_4m1_0-3.4.10-25.145.1">
      <FullProductName ProductID="libpython3_4m1_0-3.4.10-25.145.1">libpython3_4m1_0-3.4.10-25.145.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libpython3_6m1_0-3.6.15-73.1">
      <FullProductName ProductID="libpython3_6m1_0-3.6.15-73.1">libpython3_6m1_0-3.6.15-73.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libruby2_1-2_1-2.1.9-19.9.1">
      <FullProductName ProductID="libruby2_1-2_1-2.1.9-19.9.1">libruby2_1-2_1-2.1.9-19.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libstdc++6-13.3.0+git8781-1.16.1">
      <FullProductName ProductID="libstdc++6-13.3.0+git8781-1.16.1">libstdc++6-13.3.0+git8781-1.16.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsuseconnect-1.13.0-3.28.1">
      <FullProductName ProductID="libsuseconnect-1.13.0-3.28.1">libsuseconnect-1.13.0-3.28.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libzypp-16.22.15-72.1">
      <FullProductName ProductID="libzypp-16.22.15-72.1">libzypp-16.22.15-72.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python-2.7.18-33.38.1">
      <FullProductName ProductID="python-2.7.18-33.38.1">python-2.7.18-33.38.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python-base-2.7.18-33.38.1">
      <FullProductName ProductID="python-base-2.7.18-33.38.1">python-base-2.7.18-33.38.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python-xml-2.7.18-33.38.1">
      <FullProductName ProductID="python-xml-2.7.18-33.38.1">python-xml-2.7.18-33.38.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-3.4.10-25.145.1">
      <FullProductName ProductID="python3-3.4.10-25.145.1">python3-3.4.10-25.145.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-base-3.4.10-25.145.1">
      <FullProductName ProductID="python3-base-3.4.10-25.145.1">python3-base-3.4.10-25.145.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python36-base-3.6.15-73.1">
      <FullProductName ProductID="python36-base-3.6.15-73.1">python36-base-3.6.15-73.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="release-notes-sles-12.5.20241206-3.43.3">
      <FullProductName ProductID="release-notes-sles-12.5.20241206-3.43.3">release-notes-sles-12.5.20241206-3.43.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ruby2.1-2.1.9-19.9.1">
      <FullProductName ProductID="ruby2.1-2.1.9-19.9.1">ruby2.1-2.1.9-19.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ruby2.1-stdlib-2.1.9-19.9.1">
      <FullProductName ProductID="ruby2.1-stdlib-2.1.9-19.9.1">ruby2.1-stdlib-2.1.9-19.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="sudo-1.8.27-4.51.1">
      <FullProductName ProductID="sudo-1.8.27-4.51.1">sudo-1.8.27-4.51.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="suseconnect-ng-1.13.0-3.28.1">
      <FullProductName ProductID="suseconnect-ng-1.13.0-3.28.1">suseconnect-ng-1.13.0-3.28.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="suseconnect-ruby-bindings-1.13.0-3.28.1">
      <FullProductName ProductID="suseconnect-ruby-bindings-1.13.0-3.28.1">suseconnect-ruby-bindings-1.13.0-3.28.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="vim-9.1.0836-17.38.1">
      <FullProductName ProductID="vim-9.1.0836-17.38.1">vim-9.1.0836-17.38.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="vim-data-common-9.1.0836-17.38.1">
      <FullProductName ProductID="vim-data-common-9.1.0836-17.38.1">vim-data-common-9.1.0836-17.38.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="wicked-0.6.77-3.53.1">
      <FullProductName ProductID="wicked-0.6.77-3.53.1">wicked-0.6.77-3.53.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="wicked-service-0.6.77-3.53.1">
      <FullProductName ProductID="wicked-service-0.6.77-3.53.1">wicked-service-0.6.77-3.53.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="yast2-network-3.4.12-3.6.4">
      <FullProductName ProductID="yast2-network-3.4.12-3.6.4">yast2-network-3.4.12-3.6.4</FullProductName>
    </Branch>
    <Relationship ProductReference="cloud-regionsrv-client-10.3.7-52.117.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:cloud-regionsrv-client-10.3.7-52.117.1">cloud-regionsrv-client-10.3.7-52.117.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cloud-regionsrv-client-plugin-gce-1.0.0-52.117.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:cloud-regionsrv-client-plugin-gce-1.0.0-52.117.1">cloud-regionsrv-client-plugin-gce-1.0.0-52.117.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="curl-8.0.1-11.101.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:curl-8.0.1-11.101.1">curl-8.0.1-11.101.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="expat-2.1.0-21.40.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:expat-2.1.0-21.40.1">expat-2.1.0-21.40.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glib2-tools-2.48.2-12.43.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:glib2-tools-2.48.2-12.43.1">glib2-tools-2.48.2-12.43.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="google-guest-agent-20241011.01-1.41.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:google-guest-agent-20241011.01-1.41.3">google-guest-agent-20241011.01-1.41.3 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="google-guest-configs-20241121.00-1.35.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:google-guest-configs-20241121.00-1.35.1">google-guest-configs-20241121.00-1.35.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="google-osconfig-agent-20240926.03-1.29.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:google-osconfig-agent-20240926.03-1.29.3">google-osconfig-agent-20240926.03-1.29.3 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="iputils-s20161105-11.6.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:iputils-s20161105-11.6.2">iputils-s20161105-11.6.2 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="kernel-default-4.12.14-122.237.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1">kernel-default-4.12.14-122.237.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libavahi-client3-0.6.32-32.30.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:libavahi-client3-0.6.32-32.30.1">libavahi-client3-0.6.32-32.30.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libavahi-common3-0.6.32-32.30.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:libavahi-common3-0.6.32-32.30.1">libavahi-common3-0.6.32-32.30.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libcurl4-8.0.1-11.101.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:libcurl4-8.0.1-11.101.1">libcurl4-8.0.1-11.101.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libexpat1-2.1.0-21.40.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:libexpat1-2.1.0-21.40.1">libexpat1-2.1.0-21.40.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgcc_s1-13.3.0+git8781-1.16.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:libgcc_s1-13.3.0+git8781-1.16.1">libgcc_s1-13.3.0+git8781-1.16.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgio-2_0-0-2.48.2-12.43.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:libgio-2_0-0-2.48.2-12.43.1">libgio-2_0-0-2.48.2-12.43.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libglib-2_0-0-2.48.2-12.43.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:libglib-2_0-0-2.48.2-12.43.1">libglib-2_0-0-2.48.2-12.43.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgmodule-2_0-0-2.48.2-12.43.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:libgmodule-2_0-0-2.48.2-12.43.1">libgmodule-2_0-0-2.48.2-12.43.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgobject-2_0-0-2.48.2-12.43.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:libgobject-2_0-0-2.48.2-12.43.1">libgobject-2_0-0-2.48.2-12.43.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libpython2_7-1_0-2.7.18-33.38.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:libpython2_7-1_0-2.7.18-33.38.1">libpython2_7-1_0-2.7.18-33.38.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libpython3_4m1_0-3.4.10-25.145.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:libpython3_4m1_0-3.4.10-25.145.1">libpython3_4m1_0-3.4.10-25.145.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libpython3_6m1_0-3.6.15-73.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:libpython3_6m1_0-3.6.15-73.1">libpython3_6m1_0-3.6.15-73.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libruby2_1-2_1-2.1.9-19.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:libruby2_1-2_1-2.1.9-19.9.1">libruby2_1-2_1-2.1.9-19.9.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libstdc++6-13.3.0+git8781-1.16.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:libstdc++6-13.3.0+git8781-1.16.1">libstdc++6-13.3.0+git8781-1.16.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsuseconnect-1.13.0-3.28.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:libsuseconnect-1.13.0-3.28.1">libsuseconnect-1.13.0-3.28.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libzypp-16.22.15-72.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:libzypp-16.22.15-72.1">libzypp-16.22.15-72.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python-2.7.18-33.38.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:python-2.7.18-33.38.1">python-2.7.18-33.38.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python-base-2.7.18-33.38.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:python-base-2.7.18-33.38.1">python-base-2.7.18-33.38.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python-xml-2.7.18-33.38.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:python-xml-2.7.18-33.38.1">python-xml-2.7.18-33.38.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-3.4.10-25.145.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:python3-3.4.10-25.145.1">python3-3.4.10-25.145.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-base-3.4.10-25.145.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:python3-base-3.4.10-25.145.1">python3-base-3.4.10-25.145.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python36-base-3.6.15-73.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:python36-base-3.6.15-73.1">python36-base-3.6.15-73.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="release-notes-sles-12.5.20241206-3.43.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:release-notes-sles-12.5.20241206-3.43.3">release-notes-sles-12.5.20241206-3.43.3 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ruby2.1-2.1.9-19.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:ruby2.1-2.1.9-19.9.1">ruby2.1-2.1.9-19.9.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ruby2.1-stdlib-2.1.9-19.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:ruby2.1-stdlib-2.1.9-19.9.1">ruby2.1-stdlib-2.1.9-19.9.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="sudo-1.8.27-4.51.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:sudo-1.8.27-4.51.1">sudo-1.8.27-4.51.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="suseconnect-ng-1.13.0-3.28.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:suseconnect-ng-1.13.0-3.28.1">suseconnect-ng-1.13.0-3.28.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="suseconnect-ruby-bindings-1.13.0-3.28.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:suseconnect-ruby-bindings-1.13.0-3.28.1">suseconnect-ruby-bindings-1.13.0-3.28.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="vim-9.1.0836-17.38.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:vim-9.1.0836-17.38.1">vim-9.1.0836-17.38.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="vim-data-common-9.1.0836-17.38.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:vim-data-common-9.1.0836-17.38.1">vim-data-common-9.1.0836-17.38.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="wicked-0.6.77-3.53.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:wicked-0.6.77-3.53.1">wicked-0.6.77-3.53.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="wicked-service-0.6.77-3.53.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:wicked-service-0.6.77-3.53.1">wicked-service-0.6.77-3.53.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="yast2-network-3.4.12-3.6.4" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:yast2-network-3.4.12-3.6.4">yast2-network-3.4.12-3.6.4 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64</FullProductName>
    </Relationship>
  </ProductTree>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Sudo before 1.9.5p2 contains an off-by-one error that can result in a heap-based buffer overflow, which allows privilege escalation to root via "sudoedit -s" and a command-line argument that ends with a single backslash character.</Note>
    </Notes>
    <CVE>CVE-2021-3156</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:sudo-1.8.27-4.51.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>7.2</BaseScore>
        <Vector>AV:L/AC:L/Au:N/C:C/I:C/A:C</Vector>
      </ScoreSet>
    </CVSSScoreSets>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tipc: skb_linearize the head skb when reassembling msgs

It's not a good idea to append the frag skb to a skb's frag_list if
the frag_list already has skbs from elsewhere, such as this skb was
created by pskb_copy() where the frag_list was cloned (all the skbs
in it were skb_get'ed) and shared by multiple skbs.

However, the new appended frag skb should have been only seen by the
current skb. Otherwise, it will cause use after free crashes as this
appended frag skb are seen by multiple skbs but it only got skb_get
called once.

The same thing happens with a skb updated by pskb_may_pull() with a
skb_cloned skb. Li Shuang has reported quite a few crashes caused
by this when doing testing over macvlan devices:

  [] kernel BUG at net/core/skbuff.c:1970!
  [] Call Trace:
  []  skb_clone+0x4d/0xb0
  []  macvlan_broadcast+0xd8/0x160 [macvlan]
  []  macvlan_process_broadcast+0x148/0x150 [macvlan]
  []  process_one_work+0x1a7/0x360
  []  worker_thread+0x30/0x390

  [] kernel BUG at mm/usercopy.c:102!
  [] Call Trace:
  []  __check_heap_object+0xd3/0x100
  []  __check_object_size+0xff/0x16b
  []  simple_copy_to_iter+0x1c/0x30
  []  __skb_datagram_iter+0x7d/0x310
  []  __skb_datagram_iter+0x2a5/0x310
  []  skb_copy_datagram_iter+0x3b/0x90
  []  tipc_recvmsg+0x14a/0x3a0 [tipc]
  []  ____sys_recvmsg+0x91/0x150
  []  ___sys_recvmsg+0x7b/0xc0

  [] kernel BUG at mm/slub.c:305!
  [] Call Trace:
  []  &lt;IRQ&gt;
  []  kmem_cache_free+0x3ff/0x400
  []  __netif_receive_skb_core+0x12c/0xc40
  []  ? kmem_cache_alloc+0x12e/0x270
  []  netif_receive_skb_internal+0x3d/0xb0
  []  ? get_rx_page_info+0x8e/0xa0 [be2net]
  []  be_poll+0x6ef/0xd00 [be2net]
  []  ? irq_exit+0x4f/0x100
  []  net_rx_action+0x149/0x3b0

  ...

This patch is to fix it by linearizing the head skb if it has frag_list
set in tipc_buf_append(). Note that we choose to do this before calling
skb_unshare(), as __skb_linearize() will avoid skb_copy(). Also, we can
not just drop the frag_list either as the early time.</Note>
    </Notes>
    <CVE>CVE-2021-47162</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

phy: mdio: fix memory leak

Syzbot reported memory leak in MDIO bus interface, the problem was in
wrong state logic.

MDIOBUS_ALLOCATED indicates 2 states:
	1. Bus is only allocated
	2. Bus allocated and __mdiobus_register() fails, but
	   device_register() was called

In case of device_register() has been called we should call put_device()
to correctly free the memory allocated for this device, but mdiobus_free()
calls just kfree(dev) in case of MDIOBUS_ALLOCATED state

To avoid this behaviour we need to set bus-&gt;state to MDIOBUS_UNREGISTERED
_before_ calling device_register(), because put_device() should be
called even in case of device_register() failure.</Note>
    </Notes>
    <CVE>CVE-2021-47416</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nfc: fix segfault in nfc_genl_dump_devices_done

When kmalloc in nfc_genl_dump_devices() fails then
nfc_genl_dump_devices_done() segfaults as below

KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 0 PID: 25 Comm: kworker/0:1 Not tainted 5.16.0-rc4-01180-g2a987e65025e-dirty #5
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-6.fc35 04/01/2014
Workqueue: events netlink_sock_destruct_work
RIP: 0010:klist_iter_exit+0x26/0x80
Call Trace:
&lt;TASK&gt;
class_dev_iter_exit+0x15/0x20
nfc_genl_dump_devices_done+0x3b/0x50
genl_lock_done+0x84/0xd0
netlink_sock_destruct+0x8f/0x270
__sk_destruct+0x64/0x3b0
sk_destruct+0xa8/0xd0
__sk_free+0x2e8/0x3d0
sk_free+0x51/0x90
netlink_sock_destruct_work+0x1c/0x20
process_one_work+0x411/0x710
worker_thread+0x6fd/0xa80</Note>
    </Notes>
    <CVE>CVE-2021-47612</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nvme-rdma: fix possible use-after-free in transport error_recovery work

While nvme_rdma_submit_async_event_work is checking the ctrl and queue
state before preparing the AER command and scheduling io_work, in order
to fully prevent a race where this check is not reliable the error
recovery work must flush async_event_work before continuing to destroy
the admin queue after setting the ctrl state to RESETTING such that
there is no race .submit_async_event and the error recovery handler
itself changing the ctrl state.</Note>
    </Notes>
    <CVE>CVE-2022-48788</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nvme-tcp: fix possible use-after-free in transport error_recovery work

While nvme_tcp_submit_async_event_work is checking the ctrl and queue
state before preparing the AER command and scheduling io_work, in order
to fully prevent a race where this check is not reliable the error
recovery work must flush async_event_work before continuing to destroy
the admin queue after setting the ctrl state to RESETTING such that
there is no race .submit_async_event and the error recovery handler
itself changing the ctrl state.</Note>
    </Notes>
    <CVE>CVE-2022-48789</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nvme: fix a possible use-after-free in controller reset during load

Unlike .queue_rq, in .submit_async_event drivers may not check the ctrl
readiness for AER submission. This may lead to a use-after-free
condition that was observed with nvme-tcp.

The race condition may happen in the following scenario:
1. driver executes its reset_ctrl_work
2. -&gt; nvme_stop_ctrl - flushes ctrl async_event_work
3. ctrl sends AEN which is received by the host, which in turn
   schedules AEN handling
4. teardown admin queue (which releases the queue socket)
5. AEN processed, submits another AER, calling the driver to submit
6. driver attempts to send the cmd
==&gt; use-after-free

In order to fix that, add ctrl state check to validate the ctrl
is actually able to accept the AER submission.

This addresses the above race in controller resets because the driver
during teardown should:
1. change ctrl state to RESETTING
2. flush async_event_work (as well as other async work elements)

So after 1,2, any other AER command will find the
ctrl state to be RESETTING and bail out without submitting the AER.</Note>
    </Notes>
    <CVE>CVE-2022-48790</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: fix a memleak when uncloning an skb dst and its metadata

When uncloning an skb dst and its associated metadata, a new
dst+metadata is allocated and later replaces the old one in the skb.
This is helpful to have a non-shared dst+metadata attached to a specific
skb.

The issue is the uncloned dst+metadata is initialized with a refcount of
1, which is increased to 2 before attaching it to the skb. When
tun_dst_unclone returns, the dst+metadata is only referenced from a
single place (the skb) while its refcount is 2. Its refcount will never
drop to 0 (when the skb is consumed), leading to a memory leak.

Fix this by removing the call to dst_hold in tun_dst_unclone, as the
dst+metadata refcount is already 1.</Note>
    </Notes>
    <CVE>CVE-2022-48809</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

swiotlb: fix info leak with DMA_FROM_DEVICE

The problem I'm addressing was discovered by the LTP test covering
cve-2018-1000204.

A short description of what happens follows:
1) The test case issues a command code 00 (TEST UNIT READY) via the SG_IO
   interface with: dxfer_len == 524288, dxdfer_dir == SG_DXFER_FROM_DEV
   and a corresponding dxferp. The peculiar thing about this is that TUR
   is not reading from the device.
2) In sg_start_req() the invocation of blk_rq_map_user() effectively
   bounces the user-space buffer. As if the device was to transfer into
   it. Since commit a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in
   sg_build_indirect()") we make sure this first bounce buffer is
   allocated with GFP_ZERO.
3) For the rest of the story we keep ignoring that we have a TUR, so the
   device won't touch the buffer we prepare as if the we had a
   DMA_FROM_DEVICE type of situation. My setup uses a virtio-scsi device
   and the  buffer allocated by SG is mapped by the function
   virtqueue_add_split() which uses DMA_FROM_DEVICE for the "in" sgs (here
   scatter-gather and not scsi generics). This mapping involves bouncing
   via the swiotlb (we need swiotlb to do virtio in protected guest like
   s390 Secure Execution, or AMD SEV).
4) When the SCSI TUR is done, we first copy back the content of the second
   (that is swiotlb) bounce buffer (which most likely contains some
   previous IO data), to the first bounce buffer, which contains all
   zeros.  Then we copy back the content of the first bounce buffer to
   the user-space buffer.
5) The test case detects that the buffer, which it zero-initialized,
  ain't all zeros and fails.

One can argue that this is an swiotlb problem, because without swiotlb
we leak all zeros, and the swiotlb should be transparent in a sense that
it does not affect the outcome (if all other participants are well
behaved).

Copying the content of the original buffer into the swiotlb buffer is
the only way I can think of to make swiotlb transparent in such
scenarios. So let's do just that if in doubt, but allow the driver
to tell us that the whole mapped buffer is going to be overwritten,
in which case we can preserve the old behavior and avoid the performance
impact of the extra bounce.</Note>
    </Notes>
    <CVE>CVE-2022-48853</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

udf: Fix preallocation discarding at indirect extent boundary

When preallocation extent is the first one in the extent block, the
code would corrupt extent tree header instead. Fix the problem and use
udf_delete_aext() for deleting extent to avoid some code duplication.</Note>
    </Notes>
    <CVE>CVE-2022-48946</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

igb: Initialize mailbox message for VF reset

When a MAC address is not assigned to the VF, that portion of the message
sent to the VF is not set. The memory, however, is allocated from the
stack meaning that information may be leaked to the VM. Initialize the
message buffer to 0 so that no information is passed to the VM in this
case.</Note>
    </Notes>
    <CVE>CVE-2022-48949</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ASoC: ops: Check bounds for second channel in snd_soc_put_volsw_sx()

The bounds checks in snd_soc_put_volsw_sx() are only being applied to the
first channel, meaning it is possible to write out of bounds values to the
second channel in stereo controls. Add appropriate checks.</Note>
    </Notes>
    <CVE>CVE-2022-48951</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ipv6: avoid use-after-free in ip6_fragment()

Blamed commit claimed rcu_read_lock() was held by ip6_fragment() callers.

It seems to not be always true, at least for UDP stack.

syzbot reported:

BUG: KASAN: use-after-free in ip6_dst_idev include/net/ip6_fib.h:245 [inline]
BUG: KASAN: use-after-free in ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951
Read of size 8 at addr ffff88801d403e80 by task syz-executor.3/7618

CPU: 1 PID: 7618 Comm: syz-executor.3 Not tainted 6.1.0-rc6-syzkaller-00012-g4312098baf37 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106
 print_address_description mm/kasan/report.c:284 [inline]
 print_report+0x15e/0x45d mm/kasan/report.c:395
 kasan_report+0xbf/0x1f0 mm/kasan/report.c:495
 ip6_dst_idev include/net/ip6_fib.h:245 [inline]
 ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951
 __ip6_finish_output net/ipv6/ip6_output.c:193 [inline]
 ip6_finish_output+0x9a3/0x1170 net/ipv6/ip6_output.c:206
 NF_HOOK_COND include/linux/netfilter.h:291 [inline]
 ip6_output+0x1f1/0x540 net/ipv6/ip6_output.c:227
 dst_output include/net/dst.h:445 [inline]
 ip6_local_out+0xb3/0x1a0 net/ipv6/output_core.c:161
 ip6_send_skb+0xbb/0x340 net/ipv6/ip6_output.c:1966
 udp_v6_send_skb+0x82a/0x18a0 net/ipv6/udp.c:1286
 udp_v6_push_pending_frames+0x140/0x200 net/ipv6/udp.c:1313
 udpv6_sendmsg+0x18da/0x2c80 net/ipv6/udp.c:1606
 inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665
 sock_sendmsg_nosec net/socket.c:714 [inline]
 sock_sendmsg+0xd3/0x120 net/socket.c:734
 sock_write_iter+0x295/0x3d0 net/socket.c:1108
 call_write_iter include/linux/fs.h:2191 [inline]
 new_sync_write fs/read_write.c:491 [inline]
 vfs_write+0x9ed/0xdd0 fs/read_write.c:584
 ksys_write+0x1ec/0x250 fs/read_write.c:637
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7fde3588c0d9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fde365b6168 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007fde359ac050 RCX: 00007fde3588c0d9
RDX: 000000000000ffdc RSI: 00000000200000c0 RDI: 000000000000000a
RBP: 00007fde358e7ae9 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fde35acfb1f R14: 00007fde365b6300 R15: 0000000000022000
 &lt;/TASK&gt;

Allocated by task 7618:
 kasan_save_stack+0x22/0x40 mm/kasan/common.c:45
 kasan_set_track+0x25/0x30 mm/kasan/common.c:52
 __kasan_slab_alloc+0x82/0x90 mm/kasan/common.c:325
 kasan_slab_alloc include/linux/kasan.h:201 [inline]
 slab_post_alloc_hook mm/slab.h:737 [inline]
 slab_alloc_node mm/slub.c:3398 [inline]
 slab_alloc mm/slub.c:3406 [inline]
 __kmem_cache_alloc_lru mm/slub.c:3413 [inline]
 kmem_cache_alloc+0x2b4/0x3d0 mm/slub.c:3422
 dst_alloc+0x14a/0x1f0 net/core/dst.c:92
 ip6_dst_alloc+0x32/0xa0 net/ipv6/route.c:344
 ip6_rt_pcpu_alloc net/ipv6/route.c:1369 [inline]
 rt6_make_pcpu_route net/ipv6/route.c:1417 [inline]
 ip6_pol_route+0x901/0x1190 net/ipv6/route.c:2254
 pol_lookup_func include/net/ip6_fib.h:582 [inline]
 fib6_rule_lookup+0x52e/0x6f0 net/ipv6/fib6_rules.c:121
 ip6_route_output_flags_noref+0x2e6/0x380 net/ipv6/route.c:2625
 ip6_route_output_flags+0x76/0x320 net/ipv6/route.c:2638
 ip6_route_output include/net/ip6_route.h:98 [inline]
 ip6_dst_lookup_tail+0x5ab/0x1620 net/ipv6/ip6_output.c:1092
 ip6_dst_lookup_flow+0x90/0x1d0 net/ipv6/ip6_output.c:1222
 ip6_sk_dst_lookup_flow+0x553/0x980 net/ipv6/ip6_output.c:1260
 udpv6_sendmsg+0x151d/0x2c80 net/ipv6/udp.c:1554
 inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665
 sock_sendmsg_nosec n
---truncated---</Note>
    </Notes>
    <CVE>CVE-2022-48956</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ethernet: aeroflex: fix potential skb leak in greth_init_rings()

The greth_init_rings() function won't free the newly allocated skb when
dma_mapping_error() returns error, so add dev_kfree_skb() to fix it.

Compile tested only.</Note>
    </Notes>
    <CVE>CVE-2022-48958</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: hisilicon: Fix potential use-after-free in hix5hd2_rx()

The skb is delivered to napi_gro_receive() which may free it, after
calling this, dereferencing skb may trigger use-after-free.</Note>
    </Notes>
    <CVE>CVE-2022-48960</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: hisilicon: Fix potential use-after-free in hisi_femac_rx()

The skb is delivered to napi_gro_receive() which may free it, after
calling this, dereferencing skb may trigger use-after-free.</Note>
    </Notes>
    <CVE>CVE-2022-48962</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: mvneta: Prevent out of bounds read in mvneta_config_rss()

The pp-&gt;indir[0] value comes from the user.  It is passed to:

	if (cpu_online(pp-&gt;rxq_def))

inside the mvneta_percpu_elect() function.  It needs bounds checkeding
to ensure that it is not beyond the end of the cpu bitmap.</Note>
    </Notes>
    <CVE>CVE-2022-48966</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

NFC: nci: Bounds check struct nfc_target arrays

While running under CONFIG_FORTIFY_SOURCE=y, syzkaller reported:

  memcpy: detected field-spanning write (size 129) of single field "target-&gt;sensf_res" at net/nfc/nci/ntf.c:260 (size 18)

This appears to be a legitimate lack of bounds checking in
nci_add_new_protocol(). Add the missing checks.</Note>
    </Notes>
    <CVE>CVE-2022-48967</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

xen-netfront: Fix NULL sring after live migration

A NAPI is setup for each network sring to poll data to kernel
The sring with source host is destroyed before live migration and
new sring with target host is setup after live migration.
The NAPI for the old sring is not deleted until setup new sring
with target host after migration. With busy_poll/busy_read enabled,
the NAPI can be polled before got deleted when resume VM.

BUG: unable to handle kernel NULL pointer dereference at
0000000000000008
IP: xennet_poll+0xae/0xd20
PGD 0 P4D 0
Oops: 0000 [#1] SMP PTI
Call Trace:
 finish_task_switch+0x71/0x230
 timerqueue_del+0x1d/0x40
 hrtimer_try_to_cancel+0xb5/0x110
 xennet_alloc_rx_buffers+0x2a0/0x2a0
 napi_busy_loop+0xdb/0x270
 sock_poll+0x87/0x90
 do_sys_poll+0x26f/0x580
 tracing_map_insert+0x1d4/0x2f0
 event_hist_trigger+0x14a/0x260

 finish_task_switch+0x71/0x230
 __schedule+0x256/0x890
 recalc_sigpending+0x1b/0x50
 xen_sched_clock+0x15/0x20
 __rb_reserve_next+0x12d/0x140
 ring_buffer_lock_reserve+0x123/0x3d0
 event_triggers_call+0x87/0xb0
 trace_event_buffer_commit+0x1c4/0x210
 xen_clocksource_get_cycles+0x15/0x20
 ktime_get_ts64+0x51/0xf0
 SyS_ppoll+0x160/0x1a0
 SyS_ppoll+0x160/0x1a0
 do_syscall_64+0x73/0x130
 entry_SYSCALL_64_after_hwframe+0x41/0xa6
...
RIP: xennet_poll+0xae/0xd20 RSP: ffffb4f041933900
CR2: 0000000000000008
---[ end trace f8601785b354351c ]---

xen frontend should remove the NAPIs for the old srings before live
migration as the bond srings are destroyed

There is a tiny window between the srings are set to NULL and
the NAPIs are disabled, It is safe as the NAPI threads are still
frozen at that time</Note>
    </Notes>
    <CVE>CVE-2022-48969</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: Fix not cleanup led when bt_init fails

bt_init() calls bt_leds_init() to register led, but if it fails later,
bt_leds_cleanup() is not called to unregister it.

This can cause panic if the argument "bluetooth-power" in text is freed
and then another led_trigger_register() tries to access it:

BUG: unable to handle page fault for address: ffffffffc06d3bc0
RIP: 0010:strcmp+0xc/0x30
  Call Trace:
    &lt;TASK&gt;
    led_trigger_register+0x10d/0x4f0
    led_trigger_register_simple+0x7d/0x100
    bt_init+0x39/0xf7 [bluetooth]
    do_one_initcall+0xd0/0x4e0</Note>
    </Notes>
    <CVE>CVE-2022-48971</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mac802154: fix missing INIT_LIST_HEAD in ieee802154_if_add()

Kernel fault injection test reports null-ptr-deref as follows:

BUG: kernel NULL pointer dereference, address: 0000000000000008
RIP: 0010:cfg802154_netdev_notifier_call+0x120/0x310 include/linux/list.h:114
Call Trace:
 &lt;TASK&gt;
 raw_notifier_call_chain+0x6d/0xa0 kernel/notifier.c:87
 call_netdevice_notifiers_info+0x6e/0xc0 net/core/dev.c:1944
 unregister_netdevice_many_notify+0x60d/0xcb0 net/core/dev.c:1982
 unregister_netdevice_queue+0x154/0x1a0 net/core/dev.c:10879
 register_netdevice+0x9a8/0xb90 net/core/dev.c:10083
 ieee802154_if_add+0x6ed/0x7e0 net/mac802154/iface.c:659
 ieee802154_register_hw+0x29c/0x330 net/mac802154/main.c:229
 mcr20a_probe+0xaaa/0xcb1 drivers/net/ieee802154/mcr20a.c:1316

ieee802154_if_add() allocates wpan_dev as netdev's private data, but not
init the list in struct wpan_dev. cfg802154_netdev_notifier_call() manage
the list when device register/unregister, and may lead to null-ptr-deref.

Use INIT_LIST_HEAD() on it to initialize it correctly.</Note>
    </Notes>
    <CVE>CVE-2022-48972</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

gpio: amd8111: Fix PCI device reference count leak

for_each_pci_dev() is implemented by pci_get_device(). The comment of
pci_get_device() says that it will increase the reference count for the
returned pci_dev and also decrease the reference count for the input
pci_dev @from if it is not NULL.

If we break for_each_pci_dev() loop with pdev not NULL, we need to call
pci_dev_put() to decrease the reference count. Add the missing
pci_dev_put() after the 'out' label. Since pci_dev_put() can handle NULL
input parameter, there is no problem for the 'Device not found' branch.
For the normal path, add pci_dev_put() in amd_gpio_exit().</Note>
    </Notes>
    <CVE>CVE-2022-48973</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

HID: core: fix shift-out-of-bounds in hid_report_raw_event

Syzbot reported shift-out-of-bounds in hid_report_raw_event.

microsoft 0003:045E:07DA.0001: hid_field_extract() called with n (128) &gt;
32! (swapper/0)
======================================================================
UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:1323:20
shift exponent 127 is too large for 32-bit type 'int'
CPU: 0 PID: 0 Comm: swapper/0 Not tainted
6.1.0-rc4-syzkaller-00159-g4bbf3422df78 #0
Hardware name: Google Compute Engine/Google Compute Engine, BIOS
Google 10/26/2022
Call Trace:
 &lt;IRQ&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106
 ubsan_epilogue lib/ubsan.c:151 [inline]
 __ubsan_handle_shift_out_of_bounds+0x3a6/0x420 lib/ubsan.c:322
 snto32 drivers/hid/hid-core.c:1323 [inline]
 hid_input_fetch_field drivers/hid/hid-core.c:1572 [inline]
 hid_process_report drivers/hid/hid-core.c:1665 [inline]
 hid_report_raw_event+0xd56/0x18b0 drivers/hid/hid-core.c:1998
 hid_input_report+0x408/0x4f0 drivers/hid/hid-core.c:2066
 hid_irq_in+0x459/0x690 drivers/hid/usbhid/hid-core.c:284
 __usb_hcd_giveback_urb+0x369/0x530 drivers/usb/core/hcd.c:1671
 dummy_timer+0x86b/0x3110 drivers/usb/gadget/udc/dummy_hcd.c:1988
 call_timer_fn+0xf5/0x210 kernel/time/timer.c:1474
 expire_timers kernel/time/timer.c:1519 [inline]
 __run_timers+0x76a/0x980 kernel/time/timer.c:1790
 run_timer_softirq+0x63/0xf0 kernel/time/timer.c:1803
 __do_softirq+0x277/0x75b kernel/softirq.c:571
 __irq_exit_rcu+0xec/0x170 kernel/softirq.c:650
 irq_exit_rcu+0x5/0x20 kernel/softirq.c:662
 sysvec_apic_timer_interrupt+0x91/0xb0 arch/x86/kernel/apic/apic.c:1107
======================================================================

If the size of the integer (unsigned n) is bigger than 32 in snto32(),
shift exponent will be too large for 32-bit type 'int', resulting in a
shift-out-of-bounds bug.
Fix this by adding a check on the size of the integer (unsigned n) in
snto32(). To add support for n greater than 32 bits, set n to 32, if n
is greater than 32.</Note>
    </Notes>
    <CVE>CVE-2022-48978</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: mana: Fix race on per-CQ variable napi work_done

After calling napi_complete_done(), the NAPIF_STATE_SCHED bit may be
cleared, and another CPU can start napi thread and access per-CQ variable,
cq-&gt;work_done. If the other thread (for example, from busy_poll) sets
it to a value &gt;= budget, this thread will continue to run when it should
stop, and cause memory corruption and panic.

To fix this issue, save the per-CQ work_done variable in a local variable
before napi_complete_done(), so it won't be corrupted by a possible
concurrent thread after napi_complete_done().

Also, add a flag bit to advertise to the NIC firmware: the NAPI work_done
variable race is fixed, so the driver is able to reliably support features
like busy_poll.</Note>
    </Notes>
    <CVE>CVE-2022-48985</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

memcg: fix possible use-after-free in memcg_write_event_control()

memcg_write_event_control() accesses the dentry-&gt;d_name of the specified
control fd to route the write call.  As a cgroup interface file can't be
renamed, it's safe to access d_name as long as the specified file is a
regular cgroup file.  Also, as these cgroup interface files can't be
removed before the directory, it's safe to access the parent too.

Prior to 347c4a874710 ("memcg: remove cgroup_event-&gt;cft"), there was a
call to __file_cft() which verified that the specified file is a regular
cgroupfs file before further accesses.  The cftype pointer returned from
__file_cft() was no longer necessary and the commit inadvertently dropped
the file type check with it allowing any file to slip through.  With the
invarients broken, the d_name and parent accesses can now race against
renames and removals of arbitrary files and cause use-after-free's.

Fix the bug by resurrecting the file type check in __file_cft().  Now that
cgroupfs is implemented through kernfs, checking the file operations needs
to go through a layer of indirection.  Instead, let's check the superblock
and dentry type.</Note>
    </Notes>
    <CVE>CVE-2022-48988</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mm/khugepaged: invoke MMU notifiers in shmem/file collapse paths

Any codepath that zaps page table entries must invoke MMU notifiers to
ensure that secondary MMUs (like KVM) don't keep accessing pages which
aren't mapped anymore.  Secondary MMUs don't hold their own references to
pages that are mirrored over, so failing to notify them can lead to page
use-after-free.

I'm marking this as addressing an issue introduced in commit f3f0e1d2150b
("khugepaged: add support of collapse for tmpfs/shmem pages"), but most of
the security impact of this only came in commit 27e1f8273113 ("khugepaged:
enable collapse pmd for pte-mapped THP"), which actually omitted flushes
for the removal of present PTEs, not just for the removal of empty page
tables.</Note>
    </Notes>
    <CVE>CVE-2022-48991</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ASoC: soc-pcm: Add NULL check in BE reparenting

Add NULL check in dpcm_be_reparent API, to handle
kernel NULL pointer dereference error.
The issue occurred in fuzzing test.</Note>
    </Notes>
    <CVE>CVE-2022-48992</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

char: tpm: Protect tpm_pm_suspend with locks

Currently tpm transactions are executed unconditionally in
tpm_pm_suspend() function, which may lead to races with other tpm
accessors in the system.

Specifically, the hw_random tpm driver makes use of tpm_get_random(),
and this function is called in a loop from a kthread, which means it's
not frozen alongside userspace, and so can race with the work done
during system suspend:

  tpm tpm0: tpm_transmit: tpm_recv: error -52
  tpm tpm0: invalid TPM_STS.x 0xff, dumping stack for forensics
  CPU: 0 PID: 1 Comm: init Not tainted 6.1.0-rc5+ #135
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014
  Call Trace:
   tpm_tis_status.cold+0x19/0x20
   tpm_transmit+0x13b/0x390
   tpm_transmit_cmd+0x20/0x80
   tpm1_pm_suspend+0xa6/0x110
   tpm_pm_suspend+0x53/0x80
   __pnp_bus_suspend+0x35/0xe0
   __device_suspend+0x10f/0x350

Fix this by calling tpm_try_get_ops(), which itself is a wrapper around
tpm_chip_start(), but takes the appropriate mutex.

[Jason: reworked commit message, added metadata]</Note>
    </Notes>
    <CVE>CVE-2022-48997</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iommu/vt-d: Fix PCI device refcount leak in has_external_pci()

for_each_pci_dev() is implemented by pci_get_device(). The comment of
pci_get_device() says that it will increase the reference count for the
returned pci_dev and also decrease the reference count for the input
pci_dev @from if it is not NULL.

If we break for_each_pci_dev() loop with pdev not NULL, we need to call
pci_dev_put() to decrease the reference count. Add the missing
pci_dev_put() before 'return true' to avoid reference count leak.</Note>
    </Notes>
    <CVE>CVE-2022-49000</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iommu/vt-d: Fix PCI device refcount leak in dmar_dev_scope_init()

for_each_pci_dev() is implemented by pci_get_device(). The comment of
pci_get_device() says that it will increase the reference count for the
returned pci_dev and also decrease the reference count for the input
pci_dev @from if it is not NULL.

If we break for_each_pci_dev() loop with pdev not NULL, we need to call
pci_dev_put() to decrease the reference count. Add the missing
pci_dev_put() for the error path to avoid reference count leak.</Note>
    </Notes>
    <CVE>CVE-2022-49002</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hwmon: (coretemp) Check for null before removing sysfs attrs

If coretemp_add_core() gets an error then pdata-&gt;core_data[indx]
is already NULL and has been kfreed. Don't pass that to
sysfs_remove_group() as that will crash in sysfs_remove_group().

[Shortened for readability]
[91854.020159] sysfs: cannot create duplicate filename '/devices/platform/coretemp.0/hwmon/hwmon2/temp20_label'
&lt;cpu offline&gt;
[91855.126115] BUG: kernel NULL pointer dereference, address: 0000000000000188
[91855.165103] #PF: supervisor read access in kernel mode
[91855.194506] #PF: error_code(0x0000) - not-present page
[91855.224445] PGD 0 P4D 0
[91855.238508] Oops: 0000 [#1] PREEMPT SMP PTI
...
[91855.342716] RIP: 0010:sysfs_remove_group+0xc/0x80
...
[91855.796571] Call Trace:
[91855.810524]  coretemp_cpu_offline+0x12b/0x1dd [coretemp]
[91855.841738]  ? coretemp_cpu_online+0x180/0x180 [coretemp]
[91855.871107]  cpuhp_invoke_callback+0x105/0x4b0
[91855.893432]  cpuhp_thread_fun+0x8e/0x150
...

Fix this by checking for NULL first.</Note>
    </Notes>
    <CVE>CVE-2022-49010</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hwmon: (coretemp) fix pci device refcount leak in nv1a_ram_new()

As comment of pci_get_domain_bus_and_slot() says, it returns
a pci device with refcount increment, when finish using it,
the caller must decrement the reference count by calling
pci_dev_put(). So call it after using to avoid refcount leak.</Note>
    </Notes>
    <CVE>CVE-2022-49011</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: tun: Fix use-after-free in tun_detach()

syzbot reported use-after-free in tun_detach() [1].  This causes call
trace like below:

==================================================================
BUG: KASAN: use-after-free in notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75
Read of size 8 at addr ffff88807324e2a8 by task syz-executor.0/3673

CPU: 0 PID: 3673 Comm: syz-executor.0 Not tainted 6.1.0-rc5-syzkaller-00044-gcc675d22e422 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106
 print_address_description mm/kasan/report.c:284 [inline]
 print_report+0x15e/0x461 mm/kasan/report.c:395
 kasan_report+0xbf/0x1f0 mm/kasan/report.c:495
 notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75
 call_netdevice_notifiers_info+0x86/0x130 net/core/dev.c:1942
 call_netdevice_notifiers_extack net/core/dev.c:1983 [inline]
 call_netdevice_notifiers net/core/dev.c:1997 [inline]
 netdev_wait_allrefs_any net/core/dev.c:10237 [inline]
 netdev_run_todo+0xbc6/0x1100 net/core/dev.c:10351
 tun_detach drivers/net/tun.c:704 [inline]
 tun_chr_close+0xe4/0x190 drivers/net/tun.c:3467
 __fput+0x27c/0xa90 fs/file_table.c:320
 task_work_run+0x16f/0x270 kernel/task_work.c:179
 exit_task_work include/linux/task_work.h:38 [inline]
 do_exit+0xb3d/0x2a30 kernel/exit.c:820
 do_group_exit+0xd4/0x2a0 kernel/exit.c:950
 get_signal+0x21b1/0x2440 kernel/signal.c:2858
 arch_do_signal_or_restart+0x86/0x2300 arch/x86/kernel/signal.c:869
 exit_to_user_mode_loop kernel/entry/common.c:168 [inline]
 exit_to_user_mode_prepare+0x15f/0x250 kernel/entry/common.c:203
 __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]
 syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:296
 do_syscall_64+0x46/0xb0 arch/x86/entry/common.c:86
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

The cause of the issue is that sock_put() from __tun_detach() drops
last reference count for struct net, and then notifier_call_chain()
from netdev_state_change() accesses that struct net.

This patch fixes the issue by calling sock_put() from tun_detach()
after all necessary accesses for the struct net has done.</Note>
    </Notes>
    <CVE>CVE-2022-49014</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: hsr: Fix potential use-after-free

The skb is delivered to netif_rx() which may free it, after calling this,
dereferencing skb may trigger use-after-free.</Note>
    </Notes>
    <CVE>CVE-2022-49015</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/9p: Fix a potential socket leak in p9_socket_open

Both p9_fd_create_tcp() and p9_fd_create_unix() will call
p9_socket_open(). If the creation of p9_trans_fd fails,
p9_fd_create_tcp() and p9_fd_create_unix() will return an
error directly instead of releasing the cscoket, which will
result in a socket leak.

This patch adds sock_release() to fix the leak issue.</Note>
    </Notes>
    <CVE>CVE-2022-49020</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: phy: fix null-ptr-deref while probe() failed

I got a null-ptr-deref report as following when doing fault injection test:

BUG: kernel NULL pointer dereference, address: 0000000000000058
Oops: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 1 PID: 253 Comm: 507-spi-dm9051 Tainted: G    B            N 6.1.0-rc3+
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:klist_put+0x2d/0xd0
Call Trace:
 &lt;TASK&gt;
 klist_remove+0xf1/0x1c0
 device_release_driver_internal+0x23e/0x2d0
 bus_remove_device+0x1bd/0x240
 device_del+0x357/0x770
 phy_device_remove+0x11/0x30
 mdiobus_unregister+0xa5/0x140
 release_nodes+0x6a/0xa0
 devres_release_all+0xf8/0x150
 device_unbind_cleanup+0x19/0xd0

//probe path:
phy_device_register()
  device_add()

phy_connect
  phy_attach_direct() //set device driver
    probe() //it's failed, driver is not bound
    device_bind_driver() // probe failed, it's not called

//remove path:
phy_device_remove()
  device_del()
    device_release_driver_internal()
      __device_release_driver() //dev-&gt;drv is not NULL
        klist_remove() &lt;- knode_driver is not added yet, cause null-ptr-deref

In phy_attach_direct(), after setting the 'dev-&gt;driver', probe() fails,
device_bind_driver() is not called, so the knode_driver-&gt;n_klist is not
set, then it causes null-ptr-deref in __device_release_driver() while
deleting device. Fix this by setting dev-&gt;driver to NULL in the error
path in phy_attach_direct().</Note>
    </Notes>
    <CVE>CVE-2022-49021</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

e100: Fix possible use after free in e100_xmit_prepare

In e100_xmit_prepare(), if we can't map the skb, then return -ENOMEM, so
e100_xmit_frame() will return NETDEV_TX_BUSY and the upper layer will
resend the skb. But the skb is already freed, which will cause UAF bug
when the upper layer resends the skb.

Remove the harmful free.</Note>
    </Notes>
    <CVE>CVE-2022-49026</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iavf: Fix error handling in iavf_init_module()

The iavf_init_module() won't destroy workqueue when pci_register_driver()
failed. Call destroy_workqueue() when pci_register_driver() failed to
prevent the resource leak.

Similar to the handling of u132_hcd_init in commit f276e002793c
("usb: u132-hcd: fix resource leak")</Note>
    </Notes>
    <CVE>CVE-2022-49027</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ixgbevf: Fix resource leak in ixgbevf_init_module()

ixgbevf_init_module() won't destroy the workqueue created by
create_singlethread_workqueue() when pci_register_driver() failed. Add
destroy_workqueue() in fail path to prevent the resource leak.

Similar to the handling of u132_hcd_init in commit f276e002793c
("usb: u132-hcd: fix resource leak")</Note>
    </Notes>
    <CVE>CVE-2022-49028</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hwmon: (ibmpex) Fix possible UAF when ibmpex_register_bmc() fails

Smatch report warning as follows:

drivers/hwmon/ibmpex.c:509 ibmpex_register_bmc() warn:
  '&amp;data-&gt;list' not removed from list

If ibmpex_find_sensors() fails in ibmpex_register_bmc(), data will
be freed, but data-&gt;list will not be removed from driver_data.bmc_data,
then list traversal may cause UAF.

Fix by removeing it from driver_data.bmc_data before free().</Note>
    </Notes>
    <CVE>CVE-2022-49029</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel before 6.5.9, there is a NULL pointer dereference in send_acknowledge in net/nfc/nci/spi.c.</Note>
    </Notes>
    <CVE>CVE-2023-46343</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tcp: do not accept ACK of bytes we never sent

This patch is based on a detailed report and ideas from Yepeng Pan
and Christian Rossow.

ACK seq validation is currently following RFC 5961 5.2 guidelines:

   The ACK value is considered acceptable only if
   it is in the range of ((SND.UNA - MAX.SND.WND) &lt;= SEG.ACK &lt;=
   SND.NXT).  All incoming segments whose ACK value doesn't satisfy the
   above condition MUST be discarded and an ACK sent back.  It needs to
   be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is a
   duplicate (SEG.ACK &lt; SND.UNA), it can be ignored.  If the ACK
   acknowledges something not yet sent (SEG.ACK &gt; SND.NXT) then send an
   ACK, drop the segment, and return".  The "ignored" above implies that
   the processing of the incoming data segment continues, which means
   the ACK value is treated as acceptable.  This mitigation makes the
   ACK check more stringent since any ACK &lt; SND.UNA wouldn't be
   accepted, instead only ACKs that are in the range ((SND.UNA -
   MAX.SND.WND) &lt;= SEG.ACK &lt;= SND.NXT) get through.

This can be refined for new (and possibly spoofed) flows,
by not accepting ACK for bytes that were never sent.

This greatly improves TCP security at a little cost.

I added a Fixes: tag to make sure this patch will reach stable trees,
even if the 'blamed' patch was adhering to the RFC.

tp-&gt;bytes_acked was added in linux-4.2

Following packetdrill test (courtesy of Yepeng Pan) shows
the issue at hand:

0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0 bind(3, ..., ...) = 0
+0 listen(3, 1024) = 0

// ---------------- Handshake ------------------- //

// when window scale is set to 14 the window size can be extended to
// 65535 * (2^14) = 1073725440. Linux would accept an ACK packet
// with ack number in (Server_ISN+1-1073725440. Server_ISN+1)
// ,though this ack number acknowledges some data never
// sent by the server.

+0 &lt; S 0:0(0) win 65535 &lt;mss 1400,nop,wscale 14&gt;
+0 &gt; S. 0:0(0) ack 1 &lt;...&gt;
+0 &lt; . 1:1(0) ack 1 win 65535
+0 accept(3, ..., ...) = 4

// For the established connection, we send an ACK packet,
// the ack packet uses ack number 1 - 1073725300 + 2^32,
// where 2^32 is used to wrap around.
// Note: we used 1073725300 instead of 1073725440 to avoid possible
// edge cases.
// 1 - 1073725300 + 2^32 = 3221241997

// Oops, old kernels happily accept this packet.
+0 &lt; . 1:1001(1000) ack 3221241997 win 65535

// After the kernel fix the following will be replaced by a challenge ACK,
// and prior malicious frame would be dropped.
+0 &gt; . 1:1(0) ack 1001</Note>
    </Notes>
    <CVE>CVE-2023-52881</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

xhci: Fix null pointer dereference when host dies

Make sure xhci_free_dev() and xhci_kill_endpoint_urbs() do not race
and cause null pointer dereference when host suddenly dies.

Usb core may call xhci_free_dev() which frees the xhci-&gt;devs[slot_id]
virt device at the same time that xhci_kill_endpoint_urbs() tries to
loop through all the device's endpoints, checking if there are any
cancelled urbs left to give back.

hold the xhci spinlock while freeing the virt device</Note>
    </Notes>
    <CVE>CVE-2023-52898</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: pci: cx23885: check cx23885_vdev_init() return

cx23885_vdev_init() can return a NULL pointer, but that pointer
is used in the next line without a check.

Add a NULL pointer check and go to the error unwind if it is NULL.</Note>
    </Notes>
    <CVE>CVE-2023-52918</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in the ATA over Ethernet (AoE) driver in the Linux kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on `struct net_device`, and a use-after-free can be triggered by racing between the free on the struct and the access through the `skbtxq` global queue. This could lead to a denial of service condition or potential code execution.</Note>
    </Notes>
    <CVE>CVE-2023-6270</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">When asked to both use a `.netrc` file for credentials and to follow HTTP
redirects, curl could leak the password used for the first host to the
followed-to host under certain circumstances.

This flaw only manifests itself if the netrc file has an entry that matches
the redirect target hostname but the entry either omits just the password or
omits both login and password.</Note>
    </Notes>
    <CVE>CVE-2024-11053</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:curl-8.0.1-11.101.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:libcurl4-8.0.1-11.101.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">The urllib.parse.urlsplit() and urlparse() functions improperly validated bracketed hosts (`[]`), allowing hosts that weren't IPv6 or IPvFuture. This behavior was not conformant to RFC 3986 and potentially enabled SSRF if a URL is processed by more than one URL parser.</Note>
    </Notes>
    <CVE>CVE-2024-11168</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:libpython2_7-1_0-2.7.18-33.38.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:libpython3_4m1_0-3.4.10-25.145.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:python-2.7.18-33.38.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:python-base-2.7.18-33.38.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:python-xml-2.7.18-33.38.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:python3-3.4.10-25.145.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:python3-base-3.4.10-25.145.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: Avoid potential use-after-free in hci_error_reset

While handling the HCI_EV_HARDWARE_ERROR event, if the underlying
BT controller is not responding, the GPIO reset mechanism would
free the hci_dev and lead to a use-after-free in hci_error_reset.

Here's the call trace observed on a ChromeOS device with Intel AX201:
   queue_work_on+0x3e/0x6c
   __hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth &lt;HASH:3b4a6&gt;]
   ? init_wait_entry+0x31/0x31
   __hci_cmd_sync+0x16/0x20 [bluetooth &lt;HASH:3b4a 6&gt;]
   hci_error_reset+0x4f/0xa4 [bluetooth &lt;HASH:3b4a 6&gt;]
   process_one_work+0x1d8/0x33f
   worker_thread+0x21b/0x373
   kthread+0x13a/0x152
   ? pr_cont_work+0x54/0x54
   ? kthread_blkcg+0x31/0x31
    ret_from_fork+0x1f/0x30

This patch holds the reference count on the hci_dev while processing
a HCI_EV_HARDWARE_ERROR event to avoid potential crash.</Note>
    </Notes>
    <CVE>CVE-2024-26801</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/ipv6: avoid possible UAF in ip6_route_mpath_notify()

syzbot found another use-after-free in ip6_route_mpath_notify() [1]

Commit f7225172f25a ("net/ipv6: prevent use after free in
ip6_route_mpath_notify") was not able to fix the root cause.

We need to defer the fib6_info_release() calls after
ip6_route_mpath_notify(), in the cleanup phase.

[1]
BUG: KASAN: slab-use-after-free in rt6_fill_node+0x1460/0x1ac0
Read of size 4 at addr ffff88809a07fc64 by task syz-executor.2/23037

CPU: 0 PID: 23037 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-01035-gea7f3cfaa588 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
Call Trace:
 &lt;TASK&gt;
  __dump_stack lib/dump_stack.c:88 [inline]
  dump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106
  print_address_description mm/kasan/report.c:377 [inline]
  print_report+0x167/0x540 mm/kasan/report.c:488
  kasan_report+0x142/0x180 mm/kasan/report.c:601
 rt6_fill_node+0x1460/0x1ac0
  inet6_rt_notify+0x13b/0x290 net/ipv6/route.c:6184
  ip6_route_mpath_notify net/ipv6/route.c:5198 [inline]
  ip6_route_multipath_add net/ipv6/route.c:5404 [inline]
  inet6_rtm_newroute+0x1d0f/0x2300 net/ipv6/route.c:5517
  rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597
  netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543
  netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
  netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367
  netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908
  sock_sendmsg_nosec net/socket.c:730 [inline]
  __sock_sendmsg+0x221/0x270 net/socket.c:745
  ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584
  ___sys_sendmsg net/socket.c:2638 [inline]
  __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667
 do_syscall_64+0xf9/0x240
 entry_SYSCALL_64_after_hwframe+0x6f/0x77
RIP: 0033:0x7f73dd87dda9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f73de6550c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007f73dd9ac050 RCX: 00007f73dd87dda9
RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000005
RBP: 00007f73dd8ca47a R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000006e R14: 00007f73dd9ac050 R15: 00007ffdbdeb7858
 &lt;/TASK&gt;

Allocated by task 23037:
  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:372 [inline]
  __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:389
  kasan_kmalloc include/linux/kasan.h:211 [inline]
  __do_kmalloc_node mm/slub.c:3981 [inline]
  __kmalloc+0x22e/0x490 mm/slub.c:3994
  kmalloc include/linux/slab.h:594 [inline]
  kzalloc include/linux/slab.h:711 [inline]
  fib6_info_alloc+0x2e/0xf0 net/ipv6/ip6_fib.c:155
  ip6_route_info_create+0x445/0x12b0 net/ipv6/route.c:3758
  ip6_route_multipath_add net/ipv6/route.c:5298 [inline]
  inet6_rtm_newroute+0x744/0x2300 net/ipv6/route.c:5517
  rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597
  netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543
  netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
  netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367
  netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908
  sock_sendmsg_nosec net/socket.c:730 [inline]
  __sock_sendmsg+0x221/0x270 net/socket.c:745
  ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584
  ___sys_sendmsg net/socket.c:2638 [inline]
  __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667
 do_syscall_64+0xf9/0x240
 entry_SYSCALL_64_after_hwframe+0x6f/0x77

Freed by task 16:
  kasan_save_stack mm/kasan/common.c:47 [inline]
  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
  kasan_save_free_info+0x4e/0x60 mm/kasan/generic.c:640
  poison_slab_object+0xa6/0xe0 m
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-26852</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: af_bluetooth: Fix deadlock

Attemting to do sock_lock on .recvmsg may cause a deadlock as shown
bellow, so instead of using sock_sock this uses sk_receive_queue.lock
on bt_sock_ioctl to avoid the UAF:

INFO: task kworker/u9:1:121 blocked for more than 30 seconds.
      Not tainted 6.7.6-lemon #183
Workqueue: hci0 hci_rx_work
Call Trace:
 &lt;TASK&gt;
 __schedule+0x37d/0xa00
 schedule+0x32/0xe0
 __lock_sock+0x68/0xa0
 ? __pfx_autoremove_wake_function+0x10/0x10
 lock_sock_nested+0x43/0x50
 l2cap_sock_recv_cb+0x21/0xa0
 l2cap_recv_frame+0x55b/0x30a0
 ? psi_task_switch+0xeb/0x270
 ? finish_task_switch.isra.0+0x93/0x2a0
 hci_rx_work+0x33a/0x3f0
 process_one_work+0x13a/0x2f0
 worker_thread+0x2f0/0x410
 ? __pfx_worker_thread+0x10/0x10
 kthread+0xe0/0x110
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x2c/0x50
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1b/0x30
 &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2024-26886</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: edia: dvbdev: fix a use-after-free

In dvb_register_device, *pdvbdev is set equal to dvbdev, which is freed
in several error-handling paths. However, *pdvbdev is not set to NULL
after dvbdev's deallocation, causing use-after-frees in many places,
for example, in the following call chain:

budget_register
  |-&gt; dvb_dmxdev_init
        |-&gt; dvb_register_device
  |-&gt; dvb_dmxdev_release
        |-&gt; dvb_unregister_device
              |-&gt; dvb_remove_device
                    |-&gt; dvb_device_put
                          |-&gt; kref_put

When calling dvb_unregister_device, dmxdev-&gt;dvbdev (i.e. *pdvbdev in
dvb_register_device) could point to memory that had been freed in
dvb_register_device. Thereafter, this pointer is transferred to
kref_put and triggering a use-after-free.</Note>
    </Notes>
    <CVE>CVE-2024-27043</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get's return value

cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it
and return 0 in case of error.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2024-27051</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: cfg80211: check A-MSDU format more carefully

If it looks like there's another subframe in the A-MSDU
but the header isn't fully there, we can end up reading
data out of bounds, only to discard later. Make this a
bit more careful and check if the subframe header can
even be present.</Note>
    </Notes>
    <CVE>CVE-2024-35937</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tipc: fix UAF in error path

Sam Page (sam4k) working with Trend Micro Zero Day Initiative reported
a UAF in the tipc_buf_append() error path:

BUG: KASAN: slab-use-after-free in kfree_skb_list_reason+0x47e/0x4c0
linux/net/core/skbuff.c:1183
Read of size 8 at addr ffff88804d2a7c80 by task poc/8034

CPU: 1 PID: 8034 Comm: poc Not tainted 6.8.2 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.16.0-debian-1.16.0-5 04/01/2014
Call Trace:
 &lt;IRQ&gt;
 __dump_stack linux/lib/dump_stack.c:88
 dump_stack_lvl+0xd9/0x1b0 linux/lib/dump_stack.c:106
 print_address_description linux/mm/kasan/report.c:377
 print_report+0xc4/0x620 linux/mm/kasan/report.c:488
 kasan_report+0xda/0x110 linux/mm/kasan/report.c:601
 kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183
 skb_release_data+0x5af/0x880 linux/net/core/skbuff.c:1026
 skb_release_all linux/net/core/skbuff.c:1094
 __kfree_skb linux/net/core/skbuff.c:1108
 kfree_skb_reason+0x12d/0x210 linux/net/core/skbuff.c:1144
 kfree_skb linux/./include/linux/skbuff.h:1244
 tipc_buf_append+0x425/0xb50 linux/net/tipc/msg.c:186
 tipc_link_input+0x224/0x7c0 linux/net/tipc/link.c:1324
 tipc_link_rcv+0x76e/0x2d70 linux/net/tipc/link.c:1824
 tipc_rcv+0x45f/0x10f0 linux/net/tipc/node.c:2159
 tipc_udp_recv+0x73b/0x8f0 linux/net/tipc/udp_media.c:390
 udp_queue_rcv_one_skb+0xad2/0x1850 linux/net/ipv4/udp.c:2108
 udp_queue_rcv_skb+0x131/0xb00 linux/net/ipv4/udp.c:2186
 udp_unicast_rcv_skb+0x165/0x3b0 linux/net/ipv4/udp.c:2346
 __udp4_lib_rcv+0x2594/0x3400 linux/net/ipv4/udp.c:2422
 ip_protocol_deliver_rcu+0x30c/0x4e0 linux/net/ipv4/ip_input.c:205
 ip_local_deliver_finish+0x2e4/0x520 linux/net/ipv4/ip_input.c:233
 NF_HOOK linux/./include/linux/netfilter.h:314
 NF_HOOK linux/./include/linux/netfilter.h:308
 ip_local_deliver+0x18e/0x1f0 linux/net/ipv4/ip_input.c:254
 dst_input linux/./include/net/dst.h:461
 ip_rcv_finish linux/net/ipv4/ip_input.c:449
 NF_HOOK linux/./include/linux/netfilter.h:314
 NF_HOOK linux/./include/linux/netfilter.h:308
 ip_rcv+0x2c5/0x5d0 linux/net/ipv4/ip_input.c:569
 __netif_receive_skb_one_core+0x199/0x1e0 linux/net/core/dev.c:5534
 __netif_receive_skb+0x1f/0x1c0 linux/net/core/dev.c:5648
 process_backlog+0x101/0x6b0 linux/net/core/dev.c:5976
 __napi_poll.constprop.0+0xba/0x550 linux/net/core/dev.c:6576
 napi_poll linux/net/core/dev.c:6645
 net_rx_action+0x95a/0xe90 linux/net/core/dev.c:6781
 __do_softirq+0x21f/0x8e7 linux/kernel/softirq.c:553
 do_softirq linux/kernel/softirq.c:454
 do_softirq+0xb2/0xf0 linux/kernel/softirq.c:441
 &lt;/IRQ&gt;
 &lt;TASK&gt;
 __local_bh_enable_ip+0x100/0x120 linux/kernel/softirq.c:381
 local_bh_enable linux/./include/linux/bottom_half.h:33
 rcu_read_unlock_bh linux/./include/linux/rcupdate.h:851
 __dev_queue_xmit+0x871/0x3ee0 linux/net/core/dev.c:4378
 dev_queue_xmit linux/./include/linux/netdevice.h:3169
 neigh_hh_output linux/./include/net/neighbour.h:526
 neigh_output linux/./include/net/neighbour.h:540
 ip_finish_output2+0x169f/0x2550 linux/net/ipv4/ip_output.c:235
 __ip_finish_output linux/net/ipv4/ip_output.c:313
 __ip_finish_output+0x49e/0x950 linux/net/ipv4/ip_output.c:295
 ip_finish_output+0x31/0x310 linux/net/ipv4/ip_output.c:323
 NF_HOOK_COND linux/./include/linux/netfilter.h:303
 ip_output+0x13b/0x2a0 linux/net/ipv4/ip_output.c:433
 dst_output linux/./include/net/dst.h:451
 ip_local_out linux/net/ipv4/ip_output.c:129
 ip_send_skb+0x3e5/0x560 linux/net/ipv4/ip_output.c:1492
 udp_send_skb+0x73f/0x1530 linux/net/ipv4/udp.c:963
 udp_sendmsg+0x1a36/0x2b40 linux/net/ipv4/udp.c:1250
 inet_sendmsg+0x105/0x140 linux/net/ipv4/af_inet.c:850
 sock_sendmsg_nosec linux/net/socket.c:730
 __sock_sendmsg linux/net/socket.c:745
 __sys_sendto+0x42c/0x4e0 linux/net/socket.c:2191
 __do_sys_sendto linux/net/socket.c:2203
 __se_sys_sendto linux/net/socket.c:2199
 __x64_sys_sendto+0xe0/0x1c0 linux/net/socket.c:2199
 do_syscall_x64 linux/arch/x86/entry/common.c:52
 do_syscall_
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-36886</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets

TCP_SYN_RECV state is really special, it is only used by
cross-syn connections, mostly used by fuzzers.

In the following crash [1], syzbot managed to trigger a divide
by zero in tcp_rcv_space_adjust()

A socket makes the following state transitions,
without ever calling tcp_init_transfer(),
meaning tcp_init_buffer_space() is also not called.

         TCP_CLOSE
connect()
         TCP_SYN_SENT
         TCP_SYN_RECV
shutdown() -&gt; tcp_shutdown(sk, SEND_SHUTDOWN)
         TCP_FIN_WAIT1

To fix this issue, change tcp_shutdown() to not
perform a TCP_SYN_RECV -&gt; TCP_FIN_WAIT1 transition,
which makes no sense anyway.

When tcp_rcv_state_process() later changes socket state
from TCP_SYN_RECV to TCP_ESTABLISH, then look at
sk-&gt;sk_shutdown to finally enter TCP_FIN_WAIT1 state,
and send a FIN packet from a sane socket state.

This means tcp_send_fin() can now be called from BH
context, and must use GFP_ATOMIC allocations.

[1]
divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI
CPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
 RIP: 0010:tcp_rcv_space_adjust+0x2df/0x890 net/ipv4/tcp_input.c:767
Code: e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29 c8 48 0f af c3 31 d2 &lt;48&gt; f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48
RSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246
RAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7
R10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30
R13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2da
FS:  00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0
Call Trace:
 &lt;TASK&gt;
  tcp_recvmsg_locked+0x106d/0x25a0 net/ipv4/tcp.c:2513
  tcp_recvmsg+0x25d/0x920 net/ipv4/tcp.c:2578
  inet6_recvmsg+0x16a/0x730 net/ipv6/af_inet6.c:680
  sock_recvmsg_nosec net/socket.c:1046 [inline]
  sock_recvmsg+0x109/0x280 net/socket.c:1068
  ____sys_recvmsg+0x1db/0x470 net/socket.c:2803
  ___sys_recvmsg net/socket.c:2845 [inline]
  do_recvmmsg+0x474/0xae0 net/socket.c:2939
  __sys_recvmmsg net/socket.c:3018 [inline]
  __do_sys_recvmmsg net/socket.c:3041 [inline]
  __se_sys_recvmmsg net/socket.c:3034 [inline]
  __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7faeb6363db9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffcc1997168 EFLAGS: 00000246 ORIG_RAX: 000000000000012b
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9
RDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005
RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001c
R10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001</Note>
    </Notes>
    <CVE>CVE-2024-36905</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING

Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with
small possibility, the root cause is exactly the same as commit
bed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"")

However, Dan reported another hang after that, and junxiao investigated
the problem and found out that this is caused by plugged bio can't issue
from raid5d().

Current implementation in raid5d() has a weird dependence:

1) md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear
   MD_SB_CHANGE_PENDING;
2) raid5d() handles IO in a deadloop, until all IO are issued;
3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;

This behaviour is introduce before v2.6, and for consequence, if other
context hold 'reconfig_mutex', and md_check_recovery() can't update
super_block, then raid5d() will waste one cpu 100% by the deadloop, until
'reconfig_mutex' is released.

Refer to the implementation from raid1 and raid10, fix this problem by
skipping issue IO if MD_SB_CHANGE_PENDING is still set after
md_check_recovery(), daemon thread will be woken up when 'reconfig_mutex'
is released. Meanwhile, the hang problem will be fixed as well.</Note>
    </Notes>
    <CVE>CVE-2024-39476</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ocfs2: strict bound check before memcmp in ocfs2_xattr_find_entry()

xattr in ocfs2 maybe 'non-indexed', which saved with additional space
requested.  It's better to check if the memory is out of bound before
memcmp, although this possibility mainly comes from crafted poisonous
images.</Note>
    </Notes>
    <CVE>CVE-2024-41016</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

crypto: ecdh - explicitly zeroize private_key

private_key is overwritten with the key parameter passed in by the
caller (if present), or alternatively a newly generated private key.
However, it is possible that the caller provides a key (or the newly
generated key) which is shorter than the previous key. In that
scenario, some key material from the previous key would not be
overwritten. The easiest solution is to explicitly zeroize the entire
private_key array first.

Note that this patch slightly changes the behavior of this function:
previously, if the ecc_gen_privkey failed, the old private_key would
remain. Now, the private_key is always zeroized. This behavior is
consistent with the case where params.key is set and ecc_is_key_valid
fails.</Note>
    </Notes>
    <CVE>CVE-2024-42098</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mm: avoid overflows in dirty throttling logic

The dirty throttling logic is interspersed with assumptions that dirty
limits in PAGE_SIZE units fit into 32-bit (so that various multiplications
fit into 64-bits).  If limits end up being larger, we will hit overflows,
possible divisions by 0 etc.  Fix these problems by never allowing so
large dirty limits as they have dubious practical value anyway.  For
dirty_bytes / dirty_background_bytes interfaces we can just refuse to set
so large limits.  For dirty_ratio / dirty_background_ratio it isn't so
simple as the dirty limit is computed from the amount of available memory
which can change due to memory hotplug etc.  So when converting dirty
limits from ratios to numbers of pages, we just don't allow the result to
exceed UINT_MAX.

This is root-only triggerable problem which occurs when the operator
sets dirty limits to &gt;16 TB.</Note>
    </Notes>
    <CVE>CVE-2024-42131</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

IB/core: Implement a limit on UMAD receive List

The existing behavior of ib_umad, which maintains received MAD
packets in an unbounded list, poses a risk of uncontrolled growth.
As user-space applications extract packets from this list, the rate
of extraction may not match the rate of incoming packets, leading
to potential list overflow.

To address this, we introduce a limit to the size of the list. After
considering typical scenarios, such as OpenSM processing, which can
handle approximately 100k packets per second, and the 1-second retry
timeout for most packets, we set the list size limit to 200k. Packets
received beyond this limit are dropped, assuming they are likely timed
out by the time they are handled by user-space.

Notably, packets queued on the receive list due to reasons like
timed-out sends are preserved even when the list is full.</Note>
    </Notes>
    <CVE>CVE-2024-42145</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

crypto: aead,cipher - zeroize key buffer after use

I.G 9.7.B for FIPS 140-3 specifies that variables temporarily holding
cryptographic information should be zeroized once they are no longer
needed. Accomplish this by using kfree_sensitive for buffers that
previously held the private key.</Note>
    </Notes>
    <CVE>CVE-2024-42229</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

gpio: pca953x: fix pca953x_irq_bus_sync_unlock race

Ensure that `i2c_lock' is held when setting interrupt latch and mask in
pca953x_irq_bus_sync_unlock() in order to avoid races.

The other (non-probe) call site pca953x_gpio_set_multiple() ensures the
lock is held before calling pca953x_write_regs().

The problem occurred when a request raced against irq_bus_sync_unlock()
approximately once per thousand reboots on an i.MX8MP based system.

 * Normal case

   0-0022: write register AI|3a {03,02,00,00,01} Input latch P0
   0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0
   0-0022: write register AI|08 {ff,00,00,00,00} Output P3
   0-0022: write register AI|12 {fc,00,00,00,00} Config P3

 * Race case

   0-0022: write register AI|08 {ff,00,00,00,00} Output P3
   0-0022: write register AI|08 {03,02,00,00,01} *** Wrong register ***
   0-0022: write register AI|12 {fc,00,00,00,00} Config P3
   0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0</Note>
    </Notes>
    <CVE>CVE-2024-42253</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">The UNIX editor Vim prior to version 9.1.0678 has a use-after-free error in argument list handling. When adding a new file to the argument list, this triggers `Buf*` autocommands. If in such an autocommand the buffer that was just opened is closed (including the window where it is shown), this causes the window structure to be freed which contains a reference to the argument list that we are actually modifying. Once the autocommands are completed, the references to the window and argument list are no longer valid and as such cause an use-after-free. Impact is low since the user must either intentionally add some unusual autocommands that wipe a buffer during creation (either manually or by sourcing a malicious plugin), but it will crash Vim. The issue has been fixed as of Vim patch v9.1.0678.</Note>
    </Notes>
    <CVE>CVE-2024-43374</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:vim-9.1.0836-17.38.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:vim-data-common-9.1.0836-17.38.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

gpio: prevent potential speculation leaks in gpio_device_get_desc()

Userspace may trigger a speculative read of an address outside the gpio
descriptor array.
Users can do that by calling gpio_ioctl() with an offset out of range.
Offset is copied from user and then used as an array index to get
the gpio descriptor without sanitization in gpio_device_get_desc().

This change ensures that the offset is sanitized by using
array_index_nospec() to mitigate any possibility of speculative
information leaks.

This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.</Note>
    </Notes>
    <CVE>CVE-2024-44931</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sched/smt: Fix unbalance sched_smt_present dec/inc

I got the following warn report while doing stress test:

jump label: negative count!
WARNING: CPU: 3 PID: 38 at kernel/jump_label.c:263 static_key_slow_try_dec+0x9d/0xb0
Call Trace:
 &lt;TASK&gt;
 __static_key_slow_dec_cpuslocked+0x16/0x70
 sched_cpu_deactivate+0x26e/0x2a0
 cpuhp_invoke_callback+0x3ad/0x10d0
 cpuhp_thread_fun+0x3f5/0x680
 smpboot_thread_fn+0x56d/0x8d0
 kthread+0x309/0x400
 ret_from_fork+0x41/0x70
 ret_from_fork_asm+0x1b/0x30
 &lt;/TASK&gt;

Because when cpuset_cpu_inactive() fails in sched_cpu_deactivate(),
the cpu offline failed, but sched_smt_present is decremented before
calling sched_cpu_deactivate(), it leads to unbalanced dec/inc, so
fix it by incrementing sched_smt_present in the error path.</Note>
    </Notes>
    <CVE>CVE-2024-44958</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: hns3: fix a deadlock problem when config TC during resetting

When config TC during the reset process, may cause a deadlock, the flow is
as below:
                             pf reset start
                                 |
                                 v
                              ......
setup tc                         |
    |                            v
    v                      DOWN: napi_disable()
napi_disable()(skip)             |
    |                            |
    v                            v
  ......                      ......
    |                            |
    v                            |
napi_enable()                    |
                                 v
                           UINIT: netif_napi_del()
                                 |
                                 v
                              ......
                                 |
                                 v
                           INIT: netif_napi_add()
                                 |
                                 v
                              ......                 global reset start
                                 |                      |
                                 v                      v
                           UP: napi_enable()(skip)    ......
                                 |                      |
                                 v                      v
                              ......                 napi_disable()

In reset process, the driver will DOWN the port and then UINIT, in this
case, the setup tc process will UP the port before UINIT, so cause the
problem. Adds a DOWN process in UINIT to fix it.</Note>
    </Notes>
    <CVE>CVE-2024-44995</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netem: fix return value if duplicate enqueue fails

There is a bug in netem_enqueue() introduced by
commit 5845f706388a ("net: netem: fix skb length BUG_ON in __skb_to_sgvec")
that can lead to a use-after-free.

This commit made netem_enqueue() always return NET_XMIT_SUCCESS
when a packet is duplicated, which can cause the parent qdisc's q.qlen
to be mistakenly incremented. When this happens qlen_notify() may be
skipped on the parent during destruction, leaving a dangling pointer
for some classful qdiscs like DRR.

There are two ways for the bug happen:

- If the duplicated packet is dropped by rootq-&gt;enqueue() and then
  the original packet is also dropped.
- If rootq-&gt;enqueue() sends the duplicated packet to a different qdisc
  and the original packet is dropped.

In both cases NET_XMIT_SUCCESS is returned even though no packets
are enqueued at the netem qdisc.

The fix is to defer the enqueue of the duplicate packet until after
the original packet has been guaranteed to return NET_XMIT_SUCCESS.</Note>
    </Notes>
    <CVE>CVE-2024-45016</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_number

Check the fb_channel_number range to avoid the array out-of-bounds
read error</Note>
    </Notes>
    <CVE>CVE-2024-46724</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: mwifiex: Do not return unused priv in mwifiex_get_priv_by_id()

mwifiex_get_priv_by_id() returns the priv pointer corresponding to
the bss_num and bss_type, but without checking if the priv is actually
currently in use.
Unused priv pointers do not have a wiphy attached to them which can
lead to NULL pointer dereferences further down the callstack.  Fix
this by returning only used priv pointers which have priv-&gt;bss_mode
set to something else than NL80211_IFTYPE_UNSPECIFIED.

Said NULL pointer dereference happened when an Accesspoint was started
with wpa_supplicant -i mlan0 with this config:

network={
        ssid="somessid"
        mode=2
        frequency=2412
        key_mgmt=WPA-PSK WPA-PSK-SHA256
        proto=RSN
        group=CCMP
        pairwise=CCMP
        psk="12345678"
}

When waiting for the AP to be established, interrupting wpa_supplicant
with &lt;ctrl-c&gt; and starting it again this happens:

| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000140
| Mem abort info:
|   ESR = 0x0000000096000004
|   EC = 0x25: DABT (current EL), IL = 32 bits
|   SET = 0, FnV = 0
|   EA = 0, S1PTW = 0
|   FSC = 0x04: level 0 translation fault
| Data abort info:
|   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
|   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
|   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
| user pgtable: 4k pages, 48-bit VAs, pgdp=0000000046d96000
| [0000000000000140] pgd=0000000000000000, p4d=0000000000000000
| Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
| Modules linked in: caam_jr caamhash_desc spidev caamalg_desc crypto_engine authenc libdes mwifiex_sdio
+mwifiex crct10dif_ce cdc_acm onboard_usb_hub fsl_imx8_ddr_perf imx8m_ddrc rtc_ds1307 lm75 rtc_snvs
+imx_sdma caam imx8mm_thermal spi_imx error imx_cpufreq_dt fuse ip_tables x_tables ipv6
| CPU: 0 PID: 8 Comm: kworker/0:1 Not tainted 6.9.0-00007-g937242013fce-dirty #18
| Hardware name: somemachine (DT)
| Workqueue: events sdio_irq_work
| pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
| pc : mwifiex_get_cfp+0xd8/0x15c [mwifiex]
| lr : mwifiex_get_cfp+0x34/0x15c [mwifiex]
| sp : ffff8000818b3a70
| x29: ffff8000818b3a70 x28: ffff000006bfd8a5 x27: 0000000000000004
| x26: 000000000000002c x25: 0000000000001511 x24: 0000000002e86bc9
| x23: ffff000006bfd996 x22: 0000000000000004 x21: ffff000007bec000
| x20: 000000000000002c x19: 0000000000000000 x18: 0000000000000000
| x17: 000000040044ffff x16: 00500072b5503510 x15: ccc283740681e517
| x14: 0201000101006d15 x13: 0000000002e8ff43 x12: 002c01000000ffb1
| x11: 0100000000000000 x10: 02e8ff43002c0100 x9 : 0000ffb100100157
| x8 : ffff000003d20000 x7 : 00000000000002f1 x6 : 00000000ffffe124
| x5 : 0000000000000001 x4 : 0000000000000003 x3 : 0000000000000000
| x2 : 0000000000000000 x1 : 0001000000011001 x0 : 0000000000000000
| Call trace:
|  mwifiex_get_cfp+0xd8/0x15c [mwifiex]
|  mwifiex_parse_single_response_buf+0x1d0/0x504 [mwifiex]
|  mwifiex_handle_event_ext_scan_report+0x19c/0x2f8 [mwifiex]
|  mwifiex_process_sta_event+0x298/0xf0c [mwifiex]
|  mwifiex_process_event+0x110/0x238 [mwifiex]
|  mwifiex_main_process+0x428/0xa44 [mwifiex]
|  mwifiex_sdio_interrupt+0x64/0x12c [mwifiex_sdio]
|  process_sdio_pending_irqs+0x64/0x1b8
|  sdio_irq_work+0x4c/0x7c
|  process_one_work+0x148/0x2a0
|  worker_thread+0x2fc/0x40c
|  kthread+0x110/0x114
|  ret_from_fork+0x10/0x20
| Code: a94153f3 a8c37bfd d50323bf d65f03c0 (f940a000)
| ---[ end trace 0000000000000000 ]---</Note>
    </Notes>
    <CVE>CVE-2024-46755</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

can: bcm: Remove proc entry when dev is unregistered.

syzkaller reported a warning in bcm_connect() below. [0]

The repro calls connect() to vxcan1, removes vxcan1, and calls
connect() with ifindex == 0.

Calling connect() for a BCM socket allocates a proc entry.
Then, bcm_sk(sk)-&gt;bound is set to 1 to prevent further connect().

However, removing the bound device resets bcm_sk(sk)-&gt;bound to 0
in bcm_notify().

The 2nd connect() tries to allocate a proc entry with the same
name and sets NULL to bcm_sk(sk)-&gt;bcm_proc_read, leaking the
original proc entry.

Since the proc entry is available only for connect()ed sockets,
let's clean up the entry when the bound netdev is unregistered.

[0]:
proc_dir_entry 'can-bcm/2456' already registered
WARNING: CPU: 1 PID: 394 at fs/proc/generic.c:376 proc_register+0x645/0x8f0 fs/proc/generic.c:375
Modules linked in:
CPU: 1 PID: 394 Comm: syz-executor403 Not tainted 6.10.0-rc7-g852e42cc2dd4
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
RIP: 0010:proc_register+0x645/0x8f0 fs/proc/generic.c:375
Code: 00 00 00 00 00 48 85 ed 0f 85 97 02 00 00 4d 85 f6 0f 85 9f 02 00 00 48 c7 c7 9b cb cf 87 48 89 de 4c 89 fa e8 1c 6f eb fe 90 &lt;0f&gt; 0b 90 90 48 c7 c7 98 37 99 89 e8 cb 7e 22 05 bb 00 00 00 10 48
RSP: 0018:ffa0000000cd7c30 EFLAGS: 00010246
RAX: 9e129be1950f0200 RBX: ff1100011b51582c RCX: ff1100011857cd80
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002
RBP: 0000000000000000 R08: ffd400000000000f R09: ff1100013e78cac0
R10: ffac800000cd7980 R11: ff1100013e12b1f0 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: ff1100011a99a2ec
FS:  00007fbd7086f740(0000) GS:ff1100013fd00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000200071c0 CR3: 0000000118556004 CR4: 0000000000771ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 proc_create_net_single+0x144/0x210 fs/proc/proc_net.c:220
 bcm_connect+0x472/0x840 net/can/bcm.c:1673
 __sys_connect_file net/socket.c:2049 [inline]
 __sys_connect+0x5d2/0x690 net/socket.c:2066
 __do_sys_connect net/socket.c:2076 [inline]
 __se_sys_connect net/socket.c:2073 [inline]
 __x64_sys_connect+0x8f/0x100 net/socket.c:2073
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xd9/0x1c0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x4b/0x53
RIP: 0033:0x7fbd708b0e5d
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48
RSP: 002b:00007fff8cd33f08 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fbd708b0e5d
RDX: 0000000000000010 RSI: 0000000020000040 RDI: 0000000000000003
RBP: 0000000000000000 R08: 0000000000000040 R09: 0000000000000040
R10: 0000000000000040 R11: 0000000000000246 R12: 00007fff8cd34098
R13: 0000000000401280 R14: 0000000000406de8 R15: 00007fbd70ab9000
 &lt;/TASK&gt;
remove_proc_entry: removing non-empty directory 'net/can-bcm', leaking at least '2456'</Note>
    </Notes>
    <CVE>CVE-2024-46771</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

udf: Avoid excessive partition lengths

Avoid mounting filesystems where the partition would overflow the
32-bits used for block number. Also refuse to mount filesystems where
the partition length is so large we cannot safely index bits in a
block bitmap.</Note>
    </Notes>
    <CVE>CVE-2024-46777</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sch/netem: fix use after free in netem_dequeue

If netem_dequeue() enqueues packet to inner qdisc and that qdisc
returns __NET_XMIT_STOLEN. The packet is dropped but
qdisc_tree_reduce_backlog() is not called to update the parent's
q.qlen, leading to the similar use-after-free as Commit
e04991a48dbaf382 ("netem: fix return value if duplicate enqueue
fails")

Commands to trigger KASAN UaF:

ip link add type dummy
ip link set lo up
ip link set dummy0 up
tc qdisc add dev lo parent root handle 1: drr
tc filter add dev lo parent 1: basic classid 1:1
tc class add dev lo classid 1:1 drr
tc qdisc add dev lo parent 1:1 handle 2: netem
tc qdisc add dev lo parent 2: handle 3: drr
tc filter add dev lo parent 3: basic classid 3:1 action mirred egress
redirect dev dummy0
tc class add dev lo classid 3:1 drr
ping -c1 -W0.01 localhost # Trigger bug
tc class del dev lo classid 1:1
tc class add dev lo classid 1:1 drr
ping -c1 -W0.01 localhost # UaF</Note>
    </Notes>
    <CVE>CVE-2024-46800</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: added NULL check at start of dc_validate_stream

[Why]
prevent invalid memory access

[How]
check if dc and stream are NULL</Note>
    </Notes>
    <CVE>CVE-2024-46802</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check link_index before accessing dc-&gt;links[]

[WHY &amp; HOW]
dc-&gt;links[] has max size of MAX_LINKS and NULL is return when trying to
access with out-of-bound index.

This fixes 3 OVERRUN and 1 RESOURCE_LEAK issues reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-46813</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Stop amdgpu_dm initialize when link nums greater than max_links

[Why]
Coverity report OVERRUN warning. There are
only max_links elements within dc-&gt;links. link
count could up to AMDGPU_DM_MAX_DISPLAY_INDEX 31.

[How]
Make sure link count less than max_links.</Note>
    </Notes>
    <CVE>CVE-2024-46816</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check gpio_id before used as array index

[WHY &amp; HOW]
GPIO_ID_UNKNOWN (-1) is not a valid value for array index and therefore
should be checked in advance.

This fixes 5 OVERRUN issues reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-46818</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ELF: fix kernel.randomize_va_space double read

ELF loader uses "randomize_va_space" twice. It is sysctl and can change
at any moment, so 2 loads could see 2 different values in theory with
unpredictable consequences.

Issue exactly one load for consistent value across one exec.</Note>
    </Notes>
    <CVE>CVE-2024-46826</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ethtool: fail closed if we can't get max channel used in indirection tables

Commit 0d1b7d6c9274 ("bnxt: fix crashes when reducing ring count with
active RSS contexts") proves that allowing indirection table to contain
channels with out of bounds IDs may lead to crashes. Currently the
max channel check in the core gets skipped if driver can't fetch
the indirection table or when we can't allocate memory.

Both of those conditions should be extremely rare but if they do
happen we should try to be safe and fail the channel change.</Note>
    </Notes>
    <CVE>CVE-2024-46834</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

btrfs: clean up our handling of refs == 0 in snapshot delete

In reada we BUG_ON(refs == 0), which could be unkind since we aren't
holding a lock on the extent leaf and thus could get a transient
incorrect answer.  In walk_down_proc we also BUG_ON(refs == 0), which
could happen if we have extent tree corruption.  Change that to return
-EUCLEAN.  In do_walk_down() we catch this case and handle it correctly,
however we return -EIO, which -EUCLEAN is a more appropriate error code.
Finally in walk_up_proc we have the same BUG_ON(refs == 0), so convert
that to proper error handling.  Also adjust the error message so we can
actually do something with the information.</Note>
    </Notes>
    <CVE>CVE-2024-46840</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

btrfs: don't BUG_ON on ENOMEM from btrfs_lookup_extent_info() in walk_down_proc()

We handle errors here properly, ENOMEM isn't fatal, return the error.</Note>
    </Notes>
    <CVE>CVE-2024-46841</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

perf/x86/intel: Limit the period on Haswell

Running the ltp test cve-2015-3290 concurrently reports the following
warnings.

perfevents: irq loop stuck!
  WARNING: CPU: 31 PID: 32438 at arch/x86/events/intel/core.c:3174
  intel_pmu_handle_irq+0x285/0x370
  Call Trace:
   &lt;NMI&gt;
   ? __warn+0xa4/0x220
   ? intel_pmu_handle_irq+0x285/0x370
   ? __report_bug+0x123/0x130
   ? intel_pmu_handle_irq+0x285/0x370
   ? __report_bug+0x123/0x130
   ? intel_pmu_handle_irq+0x285/0x370
   ? report_bug+0x3e/0xa0
   ? handle_bug+0x3c/0x70
   ? exc_invalid_op+0x18/0x50
   ? asm_exc_invalid_op+0x1a/0x20
   ? irq_work_claim+0x1e/0x40
   ? intel_pmu_handle_irq+0x285/0x370
   perf_event_nmi_handler+0x3d/0x60
   nmi_handle+0x104/0x330

Thanks to Thomas Gleixner's analysis, the issue is caused by the low
initial period (1) of the frequency estimation algorithm, which triggers
the defects of the HW, specifically erratum HSW11 and HSW143. (For the
details, please refer https://lore.kernel.org/lkml/87plq9l5d2.ffs@tglx/)

The HSW11 requires a period larger than 100 for the INST_RETIRED.ALL
event, but the initial period in the freq mode is 1. The erratum is the
same as the BDM11, which has been supported in the kernel. A minimum
period of 128 is enforced as well on HSW.

HSW143 is regarding that the fixed counter 1 may overcount 32 with the
Hyper-Threading is enabled. However, based on the test, the hardware
has more issues than it tells. Besides the fixed counter 1, the message
'interrupt took too long' can be observed on any counter which was armed
with a period &lt; 32 and two events expired in the same NMI. A minimum
period of 32 is enforced for the rest of the events.
The recommended workaround code of the HSW143 is not implemented.
Because it only addresses the issue for the fixed counter. It brings
extra overhead through extra MSR writing. No related overcounting issue
has been reported so far.</Note>
    </Notes>
    <CVE>CVE-2024-46848</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">An issue was discovered in the WEBrick toolkit through 1.8.1 for Ruby. It allows HTTP request smuggling by providing both a Content-Length header and a Transfer-Encoding header, e.g., "GET /admin HTTP/1.1\r\n" inside of a "POST /user HTTP/1.1\r\n" request. NOTE: the supplier's position is "Webrick should not be used in production."</Note>
    </Notes>
    <CVE>CVE-2024-47220</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:libruby2_1-2_1-2.1.9-19.9.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:ruby2.1-2.1.9-19.9.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:ruby2.1-stdlib-2.1.9-19.9.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

fsnotify: clear PARENT_WATCHED flags lazily

In some setups directories can have many (usually negative) dentries.
Hence __fsnotify_update_child_dentry_flags() function can take a
significant amount of time. Since the bulk of this function happens
under inode-&gt;i_lock this causes a significant contention on the lock
when we remove the watch from the directory as the
__fsnotify_update_child_dentry_flags() call from fsnotify_recalc_mask()
races with __fsnotify_update_child_dentry_flags() calls from
__fsnotify_parent() happening on children. This can lead upto softlockup
reports reported by users.

Fix the problem by calling fsnotify_update_children_dentry_flags() to
set PARENT_WATCHED flags only when parent starts watching children.

When parent stops watching children, clear false positive PARENT_WATCHED
flags lazily in __fsnotify_parent() for each accessed child.</Note>
    </Notes>
    <CVE>CVE-2024-47660</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: don't wait for tx queues if firmware is dead

There is a WARNING in iwl_trans_wait_tx_queues_empty() (that was
recently converted from just a message), that can be hit if we
wait for TX queues to become empty after firmware died. Clearly,
we can't expect anything from the firmware after it's declared dead.

Don't call iwl_trans_wait_tx_queues_empty() in this case. While it could
be a good idea to stop the flow earlier, the flush functions do some
maintenance work that is not related to the firmware, so keep that part
of the code running even when the firmware is not running.

[edit commit message]</Note>
    </Notes>
    <CVE>CVE-2024-47672</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: pause TCM when the firmware is stopped

Not doing so will make us send a host command to the transport while the
firmware is not alive, which will trigger a WARNING.

bad state = 0
WARNING: CPU: 2 PID: 17434 at drivers/net/wireless/intel/iwlwifi/iwl-trans.c:115 iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]
RIP: 0010:iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]
Call Trace:
 &lt;TASK&gt;
 iwl_mvm_send_cmd+0x40/0xc0 [iwlmvm]
 iwl_mvm_config_scan+0x198/0x260 [iwlmvm]
 iwl_mvm_recalc_tcm+0x730/0x11d0 [iwlmvm]
 iwl_mvm_tcm_work+0x1d/0x30 [iwlmvm]
 process_one_work+0x29e/0x640
 worker_thread+0x2df/0x690
 ? rescuer_thread+0x540/0x540
 kthread+0x192/0x1e0
 ? set_kthread_struct+0x90/0x90
 ret_from_fork+0x22/0x30</Note>
    </Notes>
    <CVE>CVE-2024-47673</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mm: avoid leaving partial pfn mappings around in error case

As Jann points out, PFN mappings are special, because unlike normal
memory mappings, there is no lifetime information associated with the
mapping - it is just a raw mapping of PFNs with no reference counting of
a 'struct page'.

That's all very much intentional, but it does mean that it's easy to
mess up the cleanup in case of errors.  Yes, a failed mmap() will always
eventually clean up any partial mappings, but without any explicit
lifetime in the page table mapping itself, it's very easy to do the
error handling in the wrong order.

In particular, it's easy to mistakenly free the physical backing store
before the page tables are actually cleaned up and (temporarily) have
stale dangling PTE entries.

To make this situation less error-prone, just make sure that any partial
pfn mapping is torn down early, before any other error handling.</Note>
    </Notes>
    <CVE>CVE-2024-47674</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vfs: fix race between evice_inodes() and find_inode()&amp;iput()

Hi, all

Recently I noticed a bug[1] in btrfs, after digged it into
and I believe it'a race in vfs.

Let's assume there's a inode (ie ino 261) with i_count 1 is
called by iput(), and there's a concurrent thread calling
generic_shutdown_super().

cpu0:                              cpu1:
iput() // i_count is 1
  -&gt;spin_lock(inode)
  -&gt;dec i_count to 0
  -&gt;iput_final()                    generic_shutdown_super()
    -&gt;__inode_add_lru()               -&gt;evict_inodes()
      // cause some reason[2]           -&gt;if (atomic_read(inode-&gt;i_count)) continue;
      // return before                  // inode 261 passed the above check
      // list_lru_add_obj()             // and then schedule out
   -&gt;spin_unlock()
// note here: the inode 261
// was still at sb list and hash list,
// and I_FREEING|I_WILL_FREE was not been set

btrfs_iget()
  // after some function calls
  -&gt;find_inode()
    // found the above inode 261
    -&gt;spin_lock(inode)
   // check I_FREEING|I_WILL_FREE
   // and passed
      -&gt;__iget()
    -&gt;spin_unlock(inode)                // schedule back
                                        -&gt;spin_lock(inode)
                                        // check (I_NEW|I_FREEING|I_WILL_FREE) flags,
                                        // passed and set I_FREEING
iput()                                  -&gt;spin_unlock(inode)
  -&gt;spin_lock(inode)			  -&gt;evict()
  // dec i_count to 0
  -&gt;iput_final()
    -&gt;spin_unlock()
    -&gt;evict()

Now, we have two threads simultaneously evicting
the same inode, which may trigger the BUG(inode-&gt;i_state &amp; I_CLEAR)
statement both within clear_inode() and iput().

To fix the bug, recheck the inode-&gt;i_count after holding i_lock.
Because in the most scenarios, the first check is valid, and
the overhead of spin_lock() can be reduced.

If there is any misunderstanding, please let me know, thanks.

[1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/
[2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable()
return false when I reproduced the bug.</Note>
    </Notes>
    <CVE>CVE-2024-47679</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tcp: check skb is non-NULL in tcp_rto_delta_us()

We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic
kernel that are running ceph and recently hit a null ptr dereference in
tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also
saw it getting hit from the RACK case as well. Here are examples of the oops
messages we saw in each of those cases:

Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020
Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode
Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page
Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0
Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI
Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu
Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023
Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160
Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 &lt;48&gt; 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3
Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246
Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000
Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60
Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8
Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900
Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30
Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000
Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0
Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554
Jul 26 15:05:02 rx [11061395.916786] Call Trace:
Jul 26 15:05:02 rx [11061395.919488]
Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f
Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9
Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380
Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0
Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50
Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0
Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20
Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450
Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140
Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90
Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0
Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40
Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160
Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160
Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220
Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240
Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0
Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240
Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130
Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280
Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10
Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30
Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-47684</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put()

syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending
garbage on the four reserved tcp bits (th-&gt;res1)

Use skb_put_zero() to clear the whole TCP header,
as done in nf_reject_ip_tcphdr_put()

BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255
  nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255
  nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344
  nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48
  expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]
  nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288
  nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161
  nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
  nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626
  nf_hook include/linux/netfilter.h:269 [inline]
  NF_HOOK include/linux/netfilter.h:312 [inline]
  ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310
  __netif_receive_skb_one_core net/core/dev.c:5661 [inline]
  __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775
  process_backlog+0x4ad/0xa50 net/core/dev.c:6108
  __napi_poll+0xe7/0x980 net/core/dev.c:6772
  napi_poll net/core/dev.c:6841 [inline]
  net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963
  handle_softirqs+0x1ce/0x800 kernel/softirq.c:554
  __do_softirq+0x14/0x1a kernel/softirq.c:588
  do_softirq+0x9a/0x100 kernel/softirq.c:455
  __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382
  local_bh_enable include/linux/bottom_half.h:33 [inline]
  rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline]
  __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450
  dev_queue_xmit include/linux/netdevice.h:3105 [inline]
  neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565
  neigh_output include/net/neighbour.h:542 [inline]
  ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141
  __ip6_finish_output net/ipv6/ip6_output.c:215 [inline]
  ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226
  NF_HOOK_COND include/linux/netfilter.h:303 [inline]
  ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247
  dst_output include/net/dst.h:450 [inline]
  NF_HOOK include/linux/netfilter.h:314 [inline]
  ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366
  inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135
  __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466
  tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline]
  tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143
  tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333
  __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679
  inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750
  __sys_connect_file net/socket.c:2061 [inline]
  __sys_connect+0x606/0x690 net/socket.c:2078
  __do_sys_connect net/socket.c:2088 [inline]
  __se_sys_connect net/socket.c:2085 [inline]
  __x64_sys_connect+0x91/0xe0 net/socket.c:2085
  x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43
  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

Uninit was stored to memory at:
  nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249
  nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344
  nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48
  expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]
  nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288
  nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161
  nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
  nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626
  nf_hook include/linux/netfilter.h:269 [inline]
  NF_HOOK include/linux/netfilter.h:312 [inline]
  ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310
  __netif_receive_skb_one_core
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-47685</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency

In the commit aee2424246f9 ("RDMA/iwcm: Fix a use-after-free related to
destroying CM IDs"), the function flush_workqueue is invoked to flush the
work queue iwcm_wq.

But at that time, the work queue iwcm_wq was created via the function
alloc_ordered_workqueue without the flag WQ_MEM_RECLAIM.

Because the current process is trying to flush the whole iwcm_wq, if
iwcm_wq doesn't have the flag WQ_MEM_RECLAIM, verify that the current
process is not reclaiming memory or running on a workqueue which doesn't
have the flag WQ_MEM_RECLAIM as that can break forward-progress guarantee
leading to a deadlock.

The call trace is as below:

[  125.350876][ T1430] Call Trace:
[  125.356281][ T1430]  &lt;TASK&gt;
[ 125.361285][ T1430] ? __warn (kernel/panic.c:693)
[ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))
[ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219)
[ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239)
[ 125.388987][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1))
[ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621)
[ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))
[ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))
[ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970)
[ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151)
[ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm
[ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910)
[ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162)
[ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161)
[ 125.482537][ T1430] _destroy_id (drivers/infiniband/core/cma.c:2044) rdma_cm
[ 125.495072][ T1430] nvme_rdma_free_queue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvme_rdma
[ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (drivers/nvme/host/rdma.c:2180) nvme_rdma
[ 125.505831][ T1430] process_one_work (kernel/workqueue.c:3231)
[ 125.515122][ T1430] worker_thread (kernel/workqueue.c:3306 kernel/workqueue.c:3393)
[ 125.515127][ T1430] ? __pfx_worker_thread (kernel/workqueue.c:3339)
[ 125.531837][ T1430] kthread (kernel/kthread.c:389)
[ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342)
[ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147)
[ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342)
[ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257)
[  125.566487][ T1430]  &lt;/TASK&gt;
[  125.566488][ T1430] ---[ end trace 0000000000000000 ]---</Note>
    </Notes>
    <CVE>CVE-2024-47696</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error

Ensure index in rtl2830_pid_filter does not exceed 31 to prevent
out-of-bounds access.

dev-&gt;filters is a 32-bit value, so set_bit and clear_bit functions should
only operate on indices from 0 to 31. If index is 32, it will attempt to
access a non-existent 33rd bit, leading to out-of-bounds access.
Change the boundary check from index &gt; 32 to index &gt;= 32 to resolve this
issue.</Note>
    </Notes>
    <CVE>CVE-2024-47697</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error

Ensure index in rtl2832_pid_filter does not exceed 31 to prevent
out-of-bounds access.

dev-&gt;filters is a 32-bit value, so set_bit and clear_bit functions should
only operate on indices from 0 to 31. If index is 32, it will attempt to
access a non-existent 33rd bit, leading to out-of-bounds access.
Change the boundary check from index &gt; 32 to index &gt;= 32 to resolve this
issue.

[hverkuil: added fixes tag, rtl2830_pid_filter -&gt; rtl2832_pid_filter in logmsg]</Note>
    </Notes>
    <CVE>CVE-2024-47698</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ext4: avoid OOB when system.data xattr changes underneath the filesystem

When looking up for an entry in an inlined directory, if e_value_offs is
changed underneath the filesystem by some change in the block device, it
will lead to an out-of-bounds access that KASAN detects as an UAF.

EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none.
loop0: detected capacity change from 2048 to 2047
==================================================================
BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500
Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103

CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:93 [inline]
 dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119
 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
 ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500
 ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697
 __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573
 ext4_lookup_entry fs/ext4/namei.c:1727 [inline]
 ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795
 lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633
 filename_create+0x297/0x540 fs/namei.c:3980
 do_symlinkat+0xf9/0x3a0 fs/namei.c:4587
 __do_sys_symlinkat fs/namei.c:4610 [inline]
 __se_sys_symlinkat fs/namei.c:4607 [inline]
 __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607
 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
RIP: 0033:0x7f3e73ced469
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a
RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469
RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0
RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290
R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c
R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0
 &lt;/TASK&gt;

Calling ext4_xattr_ibody_find right after reading the inode with
ext4_get_inode_loc will lead to a check of the validity of the xattrs,
avoiding this problem.</Note>
    </Notes>
    <CVE>CVE-2024-47701</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

block, bfq: fix possible UAF for bfqq-&gt;bic with merge chain

1) initial state, three tasks:

		Process 1       Process 2	Process 3
		 (BIC1)          (BIC2)		 (BIC3)
		  |  ^            |  ^		  |  ^
		  |  |            |  |		  |  |
		  V  |            V  |		  V  |
		  bfqq1           bfqq2		  bfqq3
process ref:	   1		    1		    1

2) bfqq1 merged to bfqq2:

		Process 1       Process 2	Process 3
		 (BIC1)          (BIC2)		 (BIC3)
		  |               |		  |  ^
		  \--------------\|		  |  |
		                  V		  V  |
		  bfqq1---------&gt;bfqq2		  bfqq3
process ref:	   0		    2		    1

3) bfqq2 merged to bfqq3:

		Process 1       Process 2	Process 3
		 (BIC1)          (BIC2)		 (BIC3)
	 here -&gt; ^                |		  |
		  \--------------\ \-------------\|
		                  V		  V
		  bfqq1---------&gt;bfqq2----------&gt;bfqq3
process ref:	   0		    1		    3

In this case, IO from Process 1 will get bfqq2 from BIC1 first, and then
get bfqq3 through merge chain, and finially handle IO by bfqq3.
Howerver, current code will think bfqq2 is owned by BIC1, like initial
state, and set bfqq2-&gt;bic to BIC1.

bfq_insert_request
-&gt; by Process 1
 bfqq = bfq_init_rq(rq)
  bfqq = bfq_get_bfqq_handle_split
   bfqq = bic_to_bfqq
   -&gt; get bfqq2 from BIC1
 bfqq-&gt;ref++
 rq-&gt;elv.priv[0] = bic
 rq-&gt;elv.priv[1] = bfqq
 if (bfqq_process_refs(bfqq) == 1)
  bfqq-&gt;bic = bic
  -&gt; record BIC1 to bfqq2

  __bfq_insert_request
   new_bfqq = bfq_setup_cooperator
   -&gt; get bfqq3 from bfqq2-&gt;new_bfqq
   bfqq_request_freed(bfqq)
   new_bfqq-&gt;ref++
   rq-&gt;elv.priv[1] = new_bfqq
   -&gt; handle IO by bfqq3

Fix the problem by checking bfqq is from merge chain fist. And this
might fix a following problem reported by our syzkaller(unreproducible):

==================================================================
BUG: KASAN: slab-use-after-free in bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline]
BUG: KASAN: slab-use-after-free in bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline]
BUG: KASAN: slab-use-after-free in bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889
Write of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595

CPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G             L     6.6.0-07439-gba2303cacfda #6
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
Workqueue: kblockd blk_mq_requeue_work
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106
 print_address_description mm/kasan/report.c:364 [inline]
 print_report+0x10d/0x610 mm/kasan/report.c:475
 kasan_report+0x8e/0xc0 mm/kasan/report.c:588
 bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline]
 bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline]
 bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889
 bfq_get_bfqq_handle_split+0x169/0x5d0 block/bfq-iosched.c:6757
 bfq_init_rq block/bfq-iosched.c:6876 [inline]
 bfq_insert_request block/bfq-iosched.c:6254 [inline]
 bfq_insert_requests+0x1112/0x5cf0 block/bfq-iosched.c:6304
 blk_mq_insert_request+0x290/0x8d0 block/blk-mq.c:2593
 blk_mq_requeue_work+0x6bc/0xa70 block/blk-mq.c:1502
 process_one_work kernel/workqueue.c:2627 [inline]
 process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700
 worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781
 kthread+0x33c/0x440 kernel/kthread.c:388
 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305
 &lt;/TASK&gt;

Allocated by task 20776:
 kasan_save_stack+0x20/0x40 mm/kasan/common.c:45
 kasan_set_track+0x25/0x30 mm/kasan/common.c:52
 __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328
 kasan_slab_alloc include/linux/kasan.h:188 [inline]
 slab_post_alloc_hook mm/slab.h:763 [inline]
 slab_alloc_node mm/slub.c:3458 [inline]
 kmem_cache_alloc_node+0x1a4/0x6f0 mm/slub.c:3503
 ioc_create_icq block/blk-ioc.c:370 [inline]
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-47706</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev()

Blamed commit accidentally removed a check for rt-&gt;rt6i_idev being NULL,
as spotted by syzbot:

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
 RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline]
 RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914
Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df &lt;80&gt; 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06
RSP: 0018:ffffc900047374e0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000
RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0
RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8c
R10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18
R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930
FS:  0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
  addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856
 addrconf_notify+0x3cb/0x1020
  notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93
  call_netdevice_notifiers_extack net/core/dev.c:2032 [inline]
  call_netdevice_notifiers net/core/dev.c:2046 [inline]
  unregister_netdevice_many_notify+0xd81/0x1c40 net/core/dev.c:11352
  unregister_netdevice_many net/core/dev.c:11414 [inline]
  unregister_netdevice_queue+0x303/0x370 net/core/dev.c:11289
  unregister_netdevice include/linux/netdevice.h:3129 [inline]
  __tun_detach+0x6b9/0x1600 drivers/net/tun.c:685
  tun_detach drivers/net/tun.c:701 [inline]
  tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510
  __fput+0x24a/0x8a0 fs/file_table.c:422
  task_work_run+0x24f/0x310 kernel/task_work.c:228
  exit_task_work include/linux/task_work.h:40 [inline]
  do_exit+0xa2f/0x27f0 kernel/exit.c:882
  do_group_exit+0x207/0x2c0 kernel/exit.c:1031
  __do_sys_exit_group kernel/exit.c:1042 [inline]
  __se_sys_exit_group kernel/exit.c:1040 [inline]
  __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040
  x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f1acc77def9
Code: Unable to access opcode bytes at 0x7f1acc77decf.
RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043
RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0
 &lt;/TASK&gt;
Modules linked in:
---[ end trace 0000000000000000 ]---
 RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline]
 RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914
Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df &lt;80&gt; 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06
RSP: 0018:ffffc900047374e0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000
RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0
R
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-47707</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop()

Since '__dev_queue_xmit()' should be called with interrupts enabled,
the following backtrace:

ieee80211_do_stop()
 ...
 spin_lock_irqsave(&amp;local-&gt;queue_stop_reason_lock, flags)
 ...
 ieee80211_free_txskb()
  ieee80211_report_used_skb()
   ieee80211_report_ack_skb()
    cfg80211_mgmt_tx_status_ext()
     nl80211_frame_tx_status()
      genlmsg_multicast_netns()
       genlmsg_multicast_netns_filtered()
        nlmsg_multicast_filtered()
	 netlink_broadcast_filtered()
	  do_one_broadcast()
	   netlink_broadcast_deliver()
	    __netlink_sendskb()
	     netlink_deliver_tap()
	      __netlink_deliver_tap_skb()
	       dev_queue_xmit()
	        __dev_queue_xmit() ; with IRQS disabled
 ...
 spin_unlock_irqrestore(&amp;local-&gt;queue_stop_reason_lock, flags)

issues the warning (as reported by syzbot reproducer):

WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120

Fix this by implementing a two-phase skb reclamation in
'ieee80211_do_stop()', where actual work is performed
outside of a section with interrupts disabled.</Note>
    </Notes>
    <CVE>CVE-2024-47713</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled

Fix missuse of spin_lock_irq()/spin_unlock_irq() when
spin_lock_irqsave()/spin_lock_irqrestore() was hold.

This was discovered through the lock debugging, and the corresponding
log is as follows:

raw_local_irq_restore() called with IRQs enabled
WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40
...
Call trace:
 warn_bogus_irq_restore+0x30/0x40
 _raw_spin_unlock_irqrestore+0x84/0xc8
 add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2]
 hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2]
 hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2]
 create_qp+0x138/0x258
 ib_create_qp_kernel+0x50/0xe8
 create_mad_qp+0xa8/0x128
 ib_mad_port_open+0x218/0x448
 ib_mad_init_device+0x70/0x1f8
 add_client_context+0xfc/0x220
 enable_device_and_get+0xd0/0x140
 ib_register_device.part.0+0xf4/0x1c8
 ib_register_device+0x34/0x50
 hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2]
 hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2]
 __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2]
 hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2]</Note>
    </Notes>
    <CVE>CVE-2024-47735</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nfsd: call cache_put if xdr_reserve_space returns NULL

If not enough buffer space available, but idmap_lookup has triggered
lookup_fn which calls cache_get and returns successfully. Then we
missed to call cache_put here which pairs with cache_get.

Reviwed-by: Jeff Layton &lt;jlayton@kernel.org&gt;</Note>
    </Notes>
    <CVE>CVE-2024-47737</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

firmware_loader: Block path traversal

Most firmware names are hardcoded strings, or are constructed from fairly
constrained format strings where the dynamic parts are just some hex
numbers or such.

However, there are a couple codepaths in the kernel where firmware file
names contain string components that are passed through from a device or
semi-privileged userspace; the ones I could find (not counting interfaces
that require root privileges) are:

 - lpfc_sli4_request_firmware_update() seems to construct the firmware
   filename from "ModelName", a string that was previously parsed out of
   some descriptor ("Vital Product Data") in lpfc_fill_vpd()
 - nfp_net_fw_find() seems to construct a firmware filename from a model
   name coming from nfp_hwinfo_lookup(pf-&gt;hwinfo, "nffw.partno"), which I
   think parses some descriptor that was read from the device.
   (But this case likely isn't exploitable because the format string looks
   like "netronome/nic_%s", and there shouldn't be any *folders* starting
   with "netronome/nic_". The previous case was different because there,
   the "%s" is *at the start* of the format string.)
 - module_flash_fw_schedule() is reachable from the
   ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as
   GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is
   enough to pass the privilege check), and takes a userspace-provided
   firmware name.
   (But I think to reach this case, you need to have CAP_NET_ADMIN over a
   network namespace that a special kind of ethernet device is mapped into,
   so I think this is not a viable attack path in practice.)

Fix it by rejecting any firmware names containing ".." path components.

For what it's worth, I went looking and haven't found any USB device
drivers that use the firmware loader dangerously.</Note>
    </Notes>
    <CVE>CVE-2024-47742</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mm: call the security_mmap_file() LSM hook in remap_file_pages()

The remap_file_pages syscall handler calls do_mmap() directly, which
doesn't contain the LSM security check. And if the process has called
personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for
RW pages, this will actually result in remapping the pages to RWX,
bypassing a W^X policy enforced by SELinux.

So we should check prot by security_mmap_file LSM hook in the
remap_file_pages syscall handler before do_mmap() is called. Otherwise, it
potentially permits an attacker to bypass a W^X policy enforced by
SELinux.

The bypass is similar to CVE-2016-10044, which bypass the same thing via
AIO and can be found in [1].

The PoC:

$ cat &gt; test.c

int main(void) {
	size_t pagesz = sysconf(_SC_PAGE_SIZE);
	int mfd = syscall(SYS_memfd_create, "test", 0);
	const char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE,
		MAP_SHARED, mfd, 0);
	unsigned int old = syscall(SYS_personality, 0xffffffff);
	syscall(SYS_personality, READ_IMPLIES_EXEC | old);
	syscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0);
	syscall(SYS_personality, old);
	// show the RWX page exists even if W^X policy is enforced
	int fd = open("/proc/self/maps", O_RDONLY);
	unsigned char buf2[1024];
	while (1) {
		int ret = read(fd, buf2, 1024);
		if (ret &lt;= 0) break;
		write(1, buf2, ret);
	}
	close(fd);
}

$ gcc test.c -o test
$ ./test | grep rwx
7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted)

[PM: subject line tweaks]</Note>
    </Notes>
    <CVE>CVE-2024-47745</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/cxgb4: Added NULL check for lookup_atid

The lookup_atid() function can return NULL if the ATID is
invalid or does not exist in the identifier table, which
could lead to dereferencing a null pointer without a
check in the `act_establish()` and `act_open_rpl()` functions.
Add a NULL check to prevent null pointer dereferencing.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2024-47749</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Vim is an open source, command line text editor. A use-after-free was found in Vim &lt; 9.1.0764. When closing a buffer (visible in a window) a BufWinLeave auto command can cause an use-after-free if this auto command happens to re-open the same buffer in a new split window. Impact is low since the user must have intentionally set up such a strange auto command and run some buffer unload commands. However this may lead to a crash. This issue has been addressed in version 9.1.0764 and all users are advised to upgrade. There are no known workarounds for this vulnerability.</Note>
    </Notes>
    <CVE>CVE-2024-47814</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:vim-9.1.0836-17.38.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:vim-data-common-9.1.0836-17.38.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tpm: Clean up TPM space after command failure

tpm_dev_transmit prepares the TPM space before attempting command
transmission. However if the command fails no rollback of this
preparation is done. This can result in transient handles being leaked
if the device is subsequently closed with no further commands performed.

Fix this by flushing the space in the event of command transmission
failure.</Note>
    </Notes>
    <CVE>CVE-2024-49851</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption

The TPM event log table is a Linux specific construct, where the data
produced by the GetEventLog() boot service is cached in memory, and
passed on to the OS using an EFI configuration table.

The use of EFI_LOADER_DATA here results in the region being left
unreserved in the E820 memory map constructed by the EFI stub, and this
is the memory description that is passed on to the incoming kernel by
kexec, which is therefore unaware that the region should be reserved.

Even though the utility of the TPM2 event log after a kexec is
questionable, any corruption might send the parsing code off into the
weeds and crash the kernel. So let's use EFI_ACPI_RECLAIM_MEMORY
instead, which is always treated as reserved by the E820 conversion
logic.</Note>
    </Notes>
    <CVE>CVE-2024-49858</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ACPI: sysfs: validate return type of _STR method

Only buffer objects are valid return values of _STR.

If something else is returned description_show() will access invalid
memory.</Note>
    </Notes>
    <CVE>CVE-2024-49860</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix a NULL pointer dereference when failed to start a new trasacntion

[BUG]
Syzbot reported a NULL pointer dereference with the following crash:

  FAULT_INJECTION: forcing a failure.
   start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676
   prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642
   relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678
  ...
  BTRFS info (device loop0): balance: ended with status: -12
  Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI
  KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667]
  RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926
  Call Trace:
   &lt;TASK&gt;
   commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496
   btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430
   del_balance_item fs/btrfs/volumes.c:3678 [inline]
   reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742
   btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574
   btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673
   vfs_ioctl fs/ioctl.c:51 [inline]
   __do_sys_ioctl fs/ioctl.c:907 [inline]
   __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893
   do_syscall_x64 arch/x86/entry/common.c:52 [inline]
   do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
   entry_SYSCALL_64_after_hwframe+0x77/0x7f

[CAUSE]
The allocation failure happens at the start_transaction() inside
prepare_to_relocate(), and during the error handling we call
unset_reloc_control(), which makes fs_info-&gt;balance_ctl to be NULL.

Then we continue the error path cleanup in btrfs_balance() by calling
reset_balance_state() which will call del_balance_item() to fully delete
the balance item in the root tree.

However during the small window between set_reloc_contrl() and
unset_reloc_control(), we can have a subvolume tree update and created a
reloc_root for that subvolume.

Then we go into the final btrfs_commit_transaction() of
del_balance_item(), and into btrfs_update_reloc_root() inside
commit_fs_roots().

That function checks if fs_info-&gt;reloc_ctl is in the merge_reloc_tree
stage, but since fs_info-&gt;reloc_ctl is NULL, it results a NULL pointer
dereference.

[FIX]
Just add extra check on fs_info-&gt;reloc_ctl inside
btrfs_update_reloc_root(), before checking
fs_info-&gt;reloc_ctl-&gt;merge_reloc_tree.

That DEAD_RELOC_TREE handling is to prevent further modification to the
reloc tree during merge stage, but since there is no reloc_ctl at all,
we do not need to bother that.</Note>
    </Notes>
    <CVE>CVE-2024-49868</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate

When doing cleanup, if flags without OCFS2_BH_READAHEAD, it may trigger
NULL pointer dereference in the following ocfs2_set_buffer_uptodate() if
bh is NULL.</Note>
    </Notes>
    <CVE>CVE-2024-49877</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ext4: update orig_path in ext4_find_extent()

In ext4_find_extent(), if the path is not big enough, we free it and set
*orig_path to NULL. But after reallocating and successfully initializing
the path, we don't update *orig_path, in which case the caller gets a
valid path but a NULL ppath, and this may cause a NULL pointer dereference
or a path memory leak. For example:

ext4_split_extent
  path = *ppath = 2000
  ext4_find_extent
    if (depth &gt; path[0].p_maxdepth)
      kfree(path = 2000);
      *orig_path = path = NULL;
      path = kcalloc() = 3000
  ext4_split_extent_at(*ppath = NULL)
    path = *ppath;
    ex = path[depth].p_ext;
    // NULL pointer dereference!

==================================================================
BUG: kernel NULL pointer dereference, address: 0000000000000010
CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847
RIP: 0010:ext4_split_extent_at+0x6d/0x560
Call Trace:
 &lt;TASK&gt;
 ext4_split_extent.isra.0+0xcb/0x1b0
 ext4_ext_convert_to_initialized+0x168/0x6c0
 ext4_ext_handle_unwritten_extents+0x325/0x4d0
 ext4_ext_map_blocks+0x520/0xdb0
 ext4_map_blocks+0x2b0/0x690
 ext4_iomap_begin+0x20e/0x2c0
[...]
==================================================================

Therefore, *orig_path is updated when the extent lookup succeeds, so that
the caller can safely use path or *ppath.</Note>
    </Notes>
    <CVE>CVE-2024-49881</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ext4: fix double brelse() the buffer of the extents path

In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been
released, otherwise it may be released twice. An example of what triggers
this is as follows:

  split2    map    split1
|--------|-------|--------|

ext4_ext_map_blocks
 ext4_ext_handle_unwritten_extents
  ext4_split_convert_extents
   // path-&gt;p_depth == 0
   ext4_split_extent
     // 1. do split1
     ext4_split_extent_at
       |ext4_ext_insert_extent
       |  ext4_ext_create_new_leaf
       |    ext4_ext_grow_indepth
       |      le16_add_cpu(&amp;neh-&gt;eh_depth, 1)
       |    ext4_find_extent
       |      // return -ENOMEM
       |// get error and try zeroout
       |path = ext4_find_extent
       |  path-&gt;p_depth = 1
       |ext4_ext_try_to_merge
       |  ext4_ext_try_to_merge_up
       |    path-&gt;p_depth = 0
       |    brelse(path[1].p_bh)  ---&gt; not set to NULL here
       |// zeroout success
     // 2. update path
     ext4_find_extent
     // 3. do split2
     ext4_split_extent_at
       ext4_ext_insert_extent
         ext4_ext_create_new_leaf
           ext4_ext_grow_indepth
             le16_add_cpu(&amp;neh-&gt;eh_depth, 1)
           ext4_find_extent
             path[0].p_bh = NULL;
             path-&gt;p_depth = 1
             read_extent_tree_block  ---&gt; return err
             // path[1].p_bh is still the old value
             ext4_free_ext_path
               ext4_ext_drop_refs
                 // path-&gt;p_depth == 1
                 brelse(path[1].p_bh)  ---&gt; brelse a buffer twice

Finally got the following WARRNING when removing the buffer from lru:

============================================
VFS: brelse: Trying to free free buffer
WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90
CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716
RIP: 0010:__brelse+0x58/0x90
Call Trace:
 &lt;TASK&gt;
 __find_get_block+0x6e7/0x810
 bdev_getblk+0x2b/0x480
 __ext4_get_inode_loc+0x48a/0x1240
 ext4_get_inode_loc+0xb2/0x150
 ext4_reserve_inode_write+0xb7/0x230
 __ext4_mark_inode_dirty+0x144/0x6a0
 ext4_ext_insert_extent+0x9c8/0x3230
 ext4_ext_map_blocks+0xf45/0x2dc0
 ext4_map_blocks+0x724/0x1700
 ext4_do_writepages+0x12d6/0x2a70
[...]
============================================</Note>
    </Notes>
    <CVE>CVE-2024-49882</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ext4: aovid use-after-free in ext4_ext_insert_extent()

As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path is
reallocated in ext4_ext_create_new_leaf(), we'll use the stale path and
cause UAF. Below is a sample trace with dummy values:

ext4_ext_insert_extent
  path = *ppath = 2000
  ext4_ext_create_new_leaf(ppath)
    ext4_find_extent(ppath)
      path = *ppath = 2000
      if (depth &gt; path[0].p_maxdepth)
            kfree(path = 2000);
            *ppath = path = NULL;
      path = kcalloc() = 3000
      *ppath = 3000;
      return path;
  /* here path is still 2000, UAF! */
  eh = path[depth].p_hdr

==================================================================
BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330
Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179
CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866
Call Trace:
 &lt;TASK&gt;
 ext4_ext_insert_extent+0x26d4/0x3330
 ext4_ext_map_blocks+0xe22/0x2d40
 ext4_map_blocks+0x71e/0x1700
 ext4_do_writepages+0x1290/0x2800
[...]

Allocated by task 179:
 ext4_find_extent+0x81c/0x1f70
 ext4_ext_map_blocks+0x146/0x2d40
 ext4_map_blocks+0x71e/0x1700
 ext4_do_writepages+0x1290/0x2800
 ext4_writepages+0x26d/0x4e0
 do_writepages+0x175/0x700
[...]

Freed by task 179:
 kfree+0xcb/0x240
 ext4_find_extent+0x7c0/0x1f70
 ext4_ext_insert_extent+0xa26/0x3330
 ext4_ext_map_blocks+0xe22/0x2d40
 ext4_map_blocks+0x71e/0x1700
 ext4_do_writepages+0x1290/0x2800
 ext4_writepages+0x26d/0x4e0
 do_writepages+0x175/0x700
[...]
==================================================================

So use *ppath to update the path to avoid the above problem.</Note>
    </Notes>
    <CVE>CVE-2024-49883</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ext4: fix slab-use-after-free in ext4_split_extent_at()

We hit the following use-after-free:

==================================================================
BUG: KASAN: slab-use-after-free in ext4_split_extent_at+0xba8/0xcc0
Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40
CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724
Call Trace:
 &lt;TASK&gt;
 kasan_report+0x93/0xc0
 ext4_split_extent_at+0xba8/0xcc0
 ext4_split_extent.isra.0+0x18f/0x500
 ext4_split_convert_extents+0x275/0x750
 ext4_ext_handle_unwritten_extents+0x73e/0x1580
 ext4_ext_map_blocks+0xe20/0x2dc0
 ext4_map_blocks+0x724/0x1700
 ext4_do_writepages+0x12d6/0x2a70
[...]

Allocated by task 40:
 __kmalloc_noprof+0x1ac/0x480
 ext4_find_extent+0xf3b/0x1e70
 ext4_ext_map_blocks+0x188/0x2dc0
 ext4_map_blocks+0x724/0x1700
 ext4_do_writepages+0x12d6/0x2a70
[...]

Freed by task 40:
 kfree+0xf1/0x2b0
 ext4_find_extent+0xa71/0x1e70
 ext4_ext_insert_extent+0xa22/0x3260
 ext4_split_extent_at+0x3ef/0xcc0
 ext4_split_extent.isra.0+0x18f/0x500
 ext4_split_convert_extents+0x275/0x750
 ext4_ext_handle_unwritten_extents+0x73e/0x1580
 ext4_ext_map_blocks+0xe20/0x2dc0
 ext4_map_blocks+0x724/0x1700
 ext4_do_writepages+0x12d6/0x2a70
[...]
==================================================================

The flow of issue triggering is as follows:

ext4_split_extent_at
  path = *ppath
  ext4_ext_insert_extent(ppath)
    ext4_ext_create_new_leaf(ppath)
      ext4_find_extent(orig_path)
        path = *orig_path
        read_extent_tree_block
          // return -ENOMEM or -EIO
        ext4_free_ext_path(path)
          kfree(path)
        *orig_path = NULL
  a. If err is -ENOMEM:
  ext4_ext_dirty(path + path-&gt;p_depth)
  // path use-after-free !!!
  b. If err is -EIO and we have EXT_DEBUG defined:
  ext4_ext_show_leaf(path)
    eh = path[depth].p_hdr
    // path also use-after-free !!!

So when trying to zeroout or fix the extent length, call ext4_find_extent()
to update the path.

In addition we use *ppath directly as an ext4_ext_show_leaf() input to
avoid possible use-after-free when EXT_DEBUG is defined, and to avoid
unnecessary path updates.</Note>
    </Notes>
    <CVE>CVE-2024-49884</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/pm: ensure the fw_info is not null before using it

This resolves the dereference null return value warning
reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-49890</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata paths

When the HBA is undergoing a reset or is handling an errata event, NULL ptr
dereference crashes may occur in routines such as
lpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), or
lpfc_abort_handler().

Add NULL ptr checks before dereferencing hdwq pointers that may have been
freed due to operations colliding with a reset or errata event handler.</Note>
    </Notes>
    <CVE>CVE-2024-49891</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix index out of bounds in degamma hardware format translation

Fixes index out of bounds issue in
`cm_helper_translate_curve_to_degamma_hw_format` function. The issue
could occur when the index 'i' exceeds the number of transfer function
points (TRANSFER_FUNC_POINTS).

The fix adds a check to ensure 'i' is within bounds before accessing the
transfer function points. If 'i' is out of bounds the function returns
false to indicate an error.

Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf-&gt;tf_pts.red' 1025 &lt;= s32max
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf-&gt;tf_pts.green' 1025 &lt;= s32max
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf-&gt;tf_pts.blue' 1025 &lt;= s32max</Note>
    </Notes>
    <CVE>CVE-2024-49894</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check stream before comparing them

[WHAT &amp; HOW]
amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It is
necessary to check for null before dereferencing them.

This fixes 1 FORWARD_NULL issue reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-49896</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/msm/adreno: Assign msm_gpu-&gt;pdev earlier to avoid nullptrs

There are some cases, such as the one uncovered by Commit 46d4efcccc68
("drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails")
where

msm_gpu_cleanup() : platform_set_drvdata(gpu-&gt;pdev, NULL);

is called on gpu-&gt;pdev == NULL, as the GPU device has not been fully
initialized yet.

Turns out that there's more than just the aforementioned path that
causes this to happen (e.g. the case when there's speedbin data in the
catalog, but opp-supported-hw is missing in DT).

Assigning msm_gpu-&gt;pdev earlier seems like the least painful solution
to this, therefore do so.

Patchwork: https://patchwork.freedesktop.org/patch/602742/</Note>
    </Notes>
    <CVE>CVE-2024-49901</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check null pointers before multiple uses

[WHAT &amp; HOW]
Poniters, such as stream_enc and dc-&gt;bw_vbios, are null checked previously
in the same function, so Coverity warns "implies that stream_enc and
dc-&gt;bw_vbios might be null". They are used multiple times in the
subsequent code and need to be checked.

This fixes 10 FORWARD_NULL issues reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-49920</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check null pointers before used

[WHAT &amp; HOW]
Poniters, such as dc-&gt;clk_mgr, are null checked previously in the same
function, so Coverity warns "implies that "dc-&gt;clk_mgr" might be null".
As a result, these pointers need to be checked when used again.

This fixes 10 FORWARD_NULL issues reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-49921</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

fbdev: efifb: Register sysfs groups through driver core

The driver core can register and cleanup sysfs groups already.
Make use of that functionality to simplify the error handling and
cleanup.

Also avoid a UAF race during unregistering where the sysctl attributes
were usable after the info struct was freed.</Note>
    </Notes>
    <CVE>CVE-2024-49925</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: avoid NULL pointer dereference

iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta
pointer is not NULL.
It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is
dereferencing the ieee80211_sta pointer.
If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL
pointer.
Fix this by checking the sta pointer before retrieving the mvmsta
from it. If sta is not NULL, then mvmsta isn't either.</Note>
    </Notes>
    <CVE>CVE-2024-49929</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/xen-netback: prevent UAF in xenvif_flush_hash()

During the list_for_each_entry_rcu iteration call of xenvif_flush_hash,
kfree_rcu does not exist inside the rcu read critical section, so if
kfree_rcu is called when the rcu grace period ends during the iteration,
UAF occurs when accessing head-&gt;next after the entry becomes free.

Therefore, to solve this, you need to change it to list_for_each_entry_safe.</Note>
    </Notes>
    <CVE>CVE-2024-49936</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit

Syzbot points out that skb_trim() has a sanity check on the existing length of
the skb, which can be uninitialised in some error paths. The intent here is
clearly just to reset the length to zero before resubmitting, so switch to
calling __skb_set_length(skb, 0) directly. In addition, __skb_set_length()
already contains a call to skb_reset_tail_pointer(), so remove the redundant
call.

The syzbot report came from ath9k_hif_usb_reg_in_cb(), but there's a similar
usage of skb_trim() in ath9k_hif_usb_rx_cb(), change both while we're at it.</Note>
    </Notes>
    <CVE>CVE-2024-49938</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/ncsi: Disable the ncsi work before freeing the associated structure

The work function can run after the ncsi device is freed, resulting
in use-after-free bugs or kernel panic.</Note>
    </Notes>
    <CVE>CVE-2024-49945</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: avoid potential underflow in qdisc_pkt_len_init() with UFO

After commit 7c6d2ecbda83 ("net: be more gentle about silly gso
requests coming from user") virtio_net_hdr_to_skb() had sanity check
to detect malicious attempts from user space to cook a bad GSO packet.

Then commit cf9acc90c80ec ("net: virtio_net_hdr_to_skb: count
transport header in UFO") while fixing one issue, allowed user space
to cook a GSO packet with the following characteristic :

IPv4 SKB_GSO_UDP, gso_size=3, skb-&gt;len = 28.

When this packet arrives in qdisc_pkt_len_init(), we end up
with hdr_len = 28 (IPv4 header + UDP header), matching skb-&gt;len

Then the following sets gso_segs to 0 :

gso_segs = DIV_ROUND_UP(skb-&gt;len - hdr_len,
                        shinfo-&gt;gso_size);

Then later we set qdisc_skb_cb(skb)-&gt;pkt_len to back to zero :/

qdisc_skb_cb(skb)-&gt;pkt_len += (gso_segs - 1) * hdr_len;

This leads to the following crash in fq_codel [1]

qdisc_pkt_len_init() is best effort, we only want an estimation
of the bytes sent on the wire, not crashing the kernel.

This patch is fixing this particular issue, a following one
adds more sanity checks for another potential bug.

[1]
[   70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000
[   70.724561] #PF: supervisor read access in kernel mode
[   70.724561] #PF: error_code(0x0000) - not-present page
[   70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0
[   70.724561] Oops: Oops: 0000 [#1] SMP NOPTI
[   70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991
[   70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[   70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel
[ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 &lt;49&gt; 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49
All code
========
   0:	24 08                	and    $0x8,%al
   2:	49 c1 e1 06          	shl    $0x6,%r9
   6:	44 89 7c 24 18       	mov    %r15d,0x18(%rsp)
   b:	45 31 ed             	xor    %r13d,%r13d
   e:	45 31 c0             	xor    %r8d,%r8d
  11:	31 ff                	xor    %edi,%edi
  13:	89 44 24 14          	mov    %eax,0x14(%rsp)
  17:	4c 03 8b 90 01 00 00 	add    0x190(%rbx),%r9
  1e:	eb 04                	jmp    0x24
  20:	39 ca                	cmp    %ecx,%edx
  22:	73 37                	jae    0x5b
  24:	4d 8b 39             	mov    (%r9),%r15
  27:	83 c7 01             	add    $0x1,%edi
  2a:*	49 8b 17             	mov    (%r15),%rdx		&lt;-- trapping instruction
  2d:	49 89 11             	mov    %rdx,(%r9)
  30:	41 8b 57 28          	mov    0x28(%r15),%edx
  34:	45 8b 5f 34          	mov    0x34(%r15),%r11d
  38:	49 c7 07 00 00 00 00 	movq   $0x0,(%r15)
  3f:	49                   	rex.WB

Code starting with the faulting instruction
===========================================
   0:	49 8b 17             	mov    (%r15),%rdx
   3:	49 89 11             	mov    %rdx,(%r9)
   6:	41 8b 57 28          	mov    0x28(%r15),%edx
   a:	45 8b 5f 34          	mov    0x34(%r15),%r11d
   e:	49 c7 07 00 00 00 00 	movq   $0x0,(%r15)
  15:	49                   	rex.WB
[   70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202
[   70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000
[   70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001
[   70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000
[   70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58
[   70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000
[   70.724561] FS:  000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000
[   70.724561] CS:  0010 DS: 0000 ES: 0000 C
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-49949</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: L2CAP: Fix uaf in l2cap_connect

[Syzbot reported]
BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949
Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54

CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
Workqueue: hci2 hci_rx_work
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:93 [inline]
 dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119
 print_address_description mm/kasan/report.c:377 [inline]
 print_report+0xc3/0x620 mm/kasan/report.c:488
 kasan_report+0xd9/0x110 mm/kasan/report.c:601
 l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949
 l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline]
 l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline]
 l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline]
 l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825
 l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514
 hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline]
 hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028
 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231
 process_scheduled_works kernel/workqueue.c:3312 [inline]
 worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389
 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
...

Freed by task 5245:
 kasan_save_stack+0x33/0x60 mm/kasan/common.c:47
 kasan_save_track+0x14/0x30 mm/kasan/common.c:68
 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:579
 poison_slab_object+0xf7/0x160 mm/kasan/common.c:240
 __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256
 kasan_slab_free include/linux/kasan.h:184 [inline]
 slab_free_hook mm/slub.c:2256 [inline]
 slab_free mm/slub.c:4477 [inline]
 kfree+0x12a/0x3b0 mm/slub.c:4598
 l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline]
 kref_put include/linux/kref.h:65 [inline]
 l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline]
 l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802
 l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241
 hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline]
 hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265
 hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583
 abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917
 hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328
 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231
 process_scheduled_works kernel/workqueue.c:3312 [inline]
 worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389
 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</Note>
    </Notes>
    <CVE>CVE-2024-49950</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_tables: prevent nf_skb_duplicated corruption

syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write
per-cpu variable nf_skb_duplicated in an unsafe way [1].

Disabling preemption as hinted by the splat is not enough,
we have to disable soft interrupts as well.

[1]
BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316
 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87
CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
Call Trace:
 &lt;TASK&gt;
  __dump_stack lib/dump_stack.c:93 [inline]
  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119
  check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49
  nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87
  nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30
  expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]
  nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288
  nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23
  nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
  nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626
  nf_hook+0x2c4/0x450 include/linux/netfilter.h:269
  NF_HOOK_COND include/linux/netfilter.h:302 [inline]
  ip_output+0x185/0x230 net/ipv4/ip_output.c:433
  ip_local_out net/ipv4/ip_output.c:129 [inline]
  ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495
  udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981
  udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269
  sock_sendmsg_nosec net/socket.c:730 [inline]
  __sock_sendmsg+0x1a6/0x270 net/socket.c:745
  ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597
  ___sys_sendmsg net/socket.c:2651 [inline]
  __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737
  __do_sys_sendmmsg net/socket.c:2766 [inline]
  __se_sys_sendmmsg net/socket.c:2763 [inline]
  __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763
  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
RIP: 0033:0x7f4ce4f7def9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133
RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9
RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006
RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68
 &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2024-49952</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ocfs2: fix null-ptr-deref when journal load failed.

During the mounting process, if journal_reset() fails because of too short
journal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer. 
Subsequently, ocfs2_journal_shutdown() calls
jbd2_journal_flush()-&gt;jbd2_cleanup_journal_tail()-&gt;
__jbd2_update_log_tail()-&gt;jbd2_journal_update_sb_log_tail()
-&gt;lock_buffer(journal-&gt;j_sb_buffer), resulting in a null-pointer
dereference error.

To resolve this issue, we should check the JBD2_LOADED flag to ensure the
journal was properly loaded.  Additionally, use journal instead of
osb-&gt;journal directly to simplify the code.</Note>
    </Notes>
    <CVE>CVE-2024-49957</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ocfs2: reserve space for inline xattr before attaching reflink tree

One of our customers reported a crash and a corrupted ocfs2 filesystem. 
The crash was due to the detection of corruption.  Upon troubleshooting,
the fsck -fn output showed the below corruption

[EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record,
but fsck believes the largest valid value is 227.  Clamp the next record value? n

The stat output from the debugfs.ocfs2 showed the following corruption
where the "Next Free Rec:" had overshot the "Count:" in the root metadata
block.

        Inode: 33080590   Mode: 0640   Generation: 2619713622 (0x9c25a856)
        FS Generation: 904309833 (0x35e6ac49)
        CRC32: 00000000   ECC: 0000
        Type: Regular   Attr: 0x0   Flags: Valid
        Dynamic Features: (0x16) HasXattr InlineXattr Refcounted
        Extended Attributes Block: 0  Extended Attributes Inline Size: 256
        User: 0 (root)   Group: 0 (root)   Size: 281320357888
        Links: 1   Clusters: 141738
        ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024
        atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024
        mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024
        dtime: 0x0 -- Wed Dec 31 17:00:00 1969
        Refcount Block: 2777346
        Last Extblk: 2886943   Orphan Slot: 0
        Sub Alloc Slot: 0   Sub Alloc Bit: 14
        Tree Depth: 1   Count: 227   Next Free Rec: 230
        ## Offset        Clusters       Block#
        0  0             2310           2776351
        1  2310          2139           2777375
        2  4449          1221           2778399
        3  5670          731            2779423
        4  6401          566            2780447
        .......          ....           .......
        .......          ....           .......

The issue was in the reflink workfow while reserving space for inline
xattr.  The problematic function is ocfs2_reflink_xattr_inline().  By the
time this function is called the reflink tree is already recreated at the
destination inode from the source inode.  At this point, this function
reserves space for inline xattrs at the destination inode without even
checking if there is space at the root metadata block.  It simply reduces
the l_count from 243 to 227 thereby making space of 256 bytes for inline
xattr whereas the inode already has extents beyond this index (in this
case up to 230), thereby causing corruption.

The fix for this is to reserve space for inline metadata at the destination
inode before the reflink tree gets recreated. The customer has verified the
fix.</Note>
    </Notes>
    <CVE>CVE-2024-49958</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error

In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail()
to recover some journal space. But if an error occurs while executing
jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free
space right away, we try other branches, and if j_committing_transaction
is NULL (i.e., the tid is 0), we will get the following complain:

============================================
JBD2: I/O error when updating journal superblock for sdd-8.
__jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available
__jbd2_log_wait_for_space: no way to get more journal space in sdd-8
------------[ cut here ]------------
WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0
Modules linked in:
CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1
RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0
Call Trace:
 &lt;TASK&gt;
 add_transaction_credits+0x5d1/0x5e0
 start_this_handle+0x1ef/0x6a0
 jbd2__journal_start+0x18b/0x340
 ext4_dirty_inode+0x5d/0xb0
 __mark_inode_dirty+0xe4/0x5d0
 generic_update_time+0x60/0x70
[...]
============================================

So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to
clean up at the moment, continue to try to reclaim free space in other ways.

Note that this fix relies on commit 6f6a6fda2945 ("jbd2: fix ocfs2 corrupt
when updating journal superblock fails") to make jbd2_cleanup_journal_tail
return the correct error code.</Note>
    </Notes>
    <CVE>CVE-2024-49959</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package()

ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0

ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will cause
NULL pointer dereference later.

[ rjw: Subject and changelog edits ]</Note>
    </Notes>
    <CVE>CVE-2024-49962</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ocfs2: remove unreasonable unlock in ocfs2_read_blocks

Patch series "Misc fixes for ocfs2_read_blocks", v5.

This series contains 2 fixes for ocfs2_read_blocks().  The first patch fix
the issue reported by syzbot, which detects bad unlock balance in
ocfs2_read_blocks().  The second patch fixes an issue reported by Heming
Zhao when reviewing above fix.


This patch (of 2):

There was a lock release before exiting, so remove the unreasonable unlock.</Note>
    </Notes>
    <CVE>CVE-2024-49965</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ocfs2: cancel dqi_sync_work before freeing oinfo

ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the
end, if error occurs after successfully reading global quota, it will
trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled:

ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c

This reports that there is an active delayed work when freeing oinfo in
error handling, so cancel dqi_sync_work first.  BTW, return status instead
of -1 when .read_file_info fails.</Note>
    </Notes>
    <CVE>CVE-2024-49966</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
    </Notes>
    <CVE>CVE-2024-49967</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer

Pass pointer reference to amdgpu_bo_unref to clear the correct pointer,
otherwise amdgpu_bo_unref clear the local variable, the original pointer
not set to NULL, this could cause use-after-free bug.</Note>
    </Notes>
    <CVE>CVE-2024-49991</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
    </Notes>
    <CVE>CVE-2024-49995</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

cifs: Fix buffer overflow when parsing NFS reparse points

ReparseDataLength is sum of the InodeType size and DataBuffer size.
So to get DataBuffer size it is needed to subtract InodeType's size from
ReparseDataLength.

Function cifs_strndup_from_utf16() is currentlly accessing buf-&gt;DataBuffer
at position after the end of the buffer because it does not subtract
InodeType size from the length. Fix this problem and correctly subtract
variable len.

Member InodeType is present only when reparse buffer is large enough. Check
for ReparseDataLength before accessing InodeType to prevent another invalid
memory access.

Major and minor rdev values are present also only when reparse buffer is
large enough. Check for reparse buffer size before calling reparse_mkdev().</Note>
    </Notes>
    <CVE>CVE-2024-49996</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ext4: fix i_data_sem unlock order in ext4_ind_migrate()

Fuzzing reports a possible deadlock in jbd2_log_wait_commit.

This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require
synchronous updates because the file descriptor is opened with O_SYNC.
This can lead to the jbd2_journal_stop() function calling
jbd2_might_wait_for_commit(), potentially causing a deadlock if the
EXT4_IOC_MIGRATE call races with a write(2) system call.

This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this
case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the
jbd2_journal_stop function while i_data_sem is locked. This triggers
lockdep because the jbd2_journal_start function might also lock the same
jbd2_handle simultaneously.

Found by Linux Verification Center (linuxtesting.org) with syzkaller.

Rule: add</Note>
    </Notes>
    <CVE>CVE-2024-50006</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ALSA: asihpi: Fix potential OOB array access

ASIHPI driver stores some values in the static array upon a response
from the driver, and its index depends on the firmware.  We shouldn't
trust it blindly.

This patch adds a sanity check of the array index to fit in the array
size.</Note>
    </Notes>
    <CVE>CVE-2024-50007</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: Fix an unsafe loop on the list

The kernel may crash when deleting a genetlink family if there are still
listeners for that family:

Oops: Kernel access of bad area, sig: 11 [#1]
  ...
  NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0
  LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0
  Call Trace:
__netlink_clear_multicast_users+0x74/0xc0
genl_unregister_family+0xd4/0x2d0

Change the unsafe loop on the list to a safe one, because inside the
loop there is an element removal from this list.</Note>
    </Notes>
    <CVE>CVE-2024-50024</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

slip: make slhc_remember() more robust against malicious packets

syzbot found that slhc_remember() was missing checks against
malicious packets [1].

slhc_remember() only checked the size of the packet was at least 20,
which is not good enough.

We need to make sure the packet includes the IPv4 and TCP header
that are supposed to be carried.

Add iph and th pointers to make the code more readable.

[1]

BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666
  slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666
  ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455
  ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline]
  ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212
  ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327
  pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379
  sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113
  __release_sock+0x1da/0x330 net/core/sock.c:3072
  release_sock+0x6b/0x250 net/core/sock.c:3626
  pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903
  sock_sendmsg_nosec net/socket.c:729 [inline]
  __sock_sendmsg+0x30f/0x380 net/socket.c:744
  ____sys_sendmsg+0x903/0xb60 net/socket.c:2602
  ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656
  __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742
  __do_sys_sendmmsg net/socket.c:2771 [inline]
  __se_sys_sendmmsg net/socket.c:2768 [inline]
  __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768
  x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308
  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

Uninit was created at:
  slab_post_alloc_hook mm/slub.c:4091 [inline]
  slab_alloc_node mm/slub.c:4134 [inline]
  kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186
  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587
  __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678
  alloc_skb include/linux/skbuff.h:1322 [inline]
  sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732
  pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867
  sock_sendmsg_nosec net/socket.c:729 [inline]
  __sock_sendmsg+0x30f/0x380 net/socket.c:744
  ____sys_sendmsg+0x903/0xb60 net/socket.c:2602
  ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656
  __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742
  __do_sys_sendmmsg net/socket.c:2771 [inline]
  __se_sys_sendmmsg net/socket.c:2768 [inline]
  __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768
  x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308
  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

CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024</Note>
    </Notes>
    <CVE>CVE-2024-50033</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ppp: fix ppp_async_encode() illegal access

syzbot reported an issue in ppp_async_encode() [1]

In this case, pppoe_sendmsg() is called with a zero size.
Then ppp_async_encode() is called with an empty skb.

BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline]
 BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675
  ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline]
  ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675
  ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634
  ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline]
  ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304
  pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379
  sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113
  __release_sock+0x1da/0x330 net/core/sock.c:3072
  release_sock+0x6b/0x250 net/core/sock.c:3626
  pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903
  sock_sendmsg_nosec net/socket.c:729 [inline]
  __sock_sendmsg+0x30f/0x380 net/socket.c:744
  ____sys_sendmsg+0x903/0xb60 net/socket.c:2602
  ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656
  __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742
  __do_sys_sendmmsg net/socket.c:2771 [inline]
  __se_sys_sendmmsg net/socket.c:2768 [inline]
  __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768
  x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308
  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

Uninit was created at:
  slab_post_alloc_hook mm/slub.c:4092 [inline]
  slab_alloc_node mm/slub.c:4135 [inline]
  kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187
  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587
  __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678
  alloc_skb include/linux/skbuff.h:1322 [inline]
  sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732
  pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867
  sock_sendmsg_nosec net/socket.c:729 [inline]
  __sock_sendmsg+0x30f/0x380 net/socket.c:744
  ____sys_sendmsg+0x903/0xb60 net/socket.c:2602
  ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656
  __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742
  __do_sys_sendmmsg net/socket.c:2771 [inline]
  __se_sys_sendmmsg net/socket.c:2768 [inline]
  __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768
  x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308
  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

CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024</Note>
    </Notes>
    <CVE>CVE-2024-50035</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change

rfcomm_sk_state_change attempts to use sock_lock so it must never be
called with it locked but rfcomm_sock_ioctl always attempt to lock it
causing the following trace:

======================================================
WARNING: possible circular locking dependency detected
6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted
------------------------------------------------------
syz-executor386/5093 is trying to acquire lock:
ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline]
ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73

but task is already holding lock:
ffff88807badfd28 (&amp;d-&gt;lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491</Note>
    </Notes>
    <CVE>CVE-2024-50044</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfilter: br_netfilter: fix panic with metadata_dst skb

Fix a kernel panic in the br_netfilter module when sending untagged
traffic via a VxLAN device.
This happens during the check for fragmentation in br_nf_dev_queue_xmit.

It is dependent on:
1) the br_netfilter module being loaded;
2) net.bridge.bridge-nf-call-iptables set to 1;
3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port;
4) untagged frames with size higher than the VxLAN MTU forwarded/flooded

When forwarding the untagged packet to the VxLAN bridge port, before
the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and
changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type
of dst, i.e., skb_valid_dst(skb) is false, and metadata-&gt;dst.dev is NULL.

Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there's a check
for frames that needs to be fragmented: frames with higher MTU than the
VxLAN device end up calling br_nf_ip_fragment, which in turns call
ip_skb_dst_mtu.

The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst
with valid dst-&gt;dev, thus the crash.

This case was never supported in the first place, so drop the packet
instead.

PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data.
[  176.291791] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000110
[  176.292101] Mem abort info:
[  176.292184]   ESR = 0x0000000096000004
[  176.292322]   EC = 0x25: DABT (current EL), IL = 32 bits
[  176.292530]   SET = 0, FnV = 0
[  176.292709]   EA = 0, S1PTW = 0
[  176.292862]   FSC = 0x04: level 0 translation fault
[  176.293013] Data abort info:
[  176.293104]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[  176.293488]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[  176.293787]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[  176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000
[  176.294166] [0000000000000110] pgd=0000000000000000,
p4d=0000000000000000
[  176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
[  176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth
br_netfilter bridge stp llc ipv6 crct10dif_ce
[  176.295923] CPU: 0 PID: 188 Comm: ping Not tainted
6.8.0-rc3-g5b3fbd61b9d1 #2
[  176.296314] Hardware name: linux,dummy-virt (DT)
[  176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS
BTYPE=--)
[  176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter]
[  176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter]
[  176.297636] sp : ffff800080003630
[  176.297743] x29: ffff800080003630 x28: 0000000000000008 x27:
ffff6828c49ad9f8
[  176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24:
00000000000003e8
[  176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21:
ffff6828c3b16d28
[  176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18:
0000000000000014
[  176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15:
0000000095744632
[  176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12:
ffffb7e137926a70
[  176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 :
0000000000000000
[  176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 :
f20e0100bebafeca
[  176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 :
0000000000000000
[  176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 :
ffff6828c7f918f0
[  176.300889] Call trace:
[  176.301123]  br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter]
[  176.301411]  br_nf_post_routing+0x2a8/0x3e4 [br_netfilter]
[  176.301703]  nf_hook_slow+0x48/0x124
[  176.302060]  br_forward_finish+0xc8/0xe8 [bridge]
[  176.302371]  br_nf_hook_thresh+0x124/0x134 [br_netfilter]
[  176.302605]  br_nf_forward_finish+0x118/0x22c [br_netfilter]
[  176.302824]  br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter]
[  176.303136]  br_nf_forward+0x2b8/0x4e0 [br_netfilter]
[  176.303359]  nf_hook_slow+0x48/0x124
[  176.303
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-50045</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

smb: client: fix UAF in async decryption

Doing an async decryption (large read) crashes with a
slab-use-after-free way down in the crypto API.

Reproducer:
    # mount.cifs -o ...,seal,esize=1 //srv/share /mnt
    # dd if=/mnt/largefile of=/dev/null
    ...
    [  194.196391] ==================================================================
    [  194.196844] BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xc1/0x110
    [  194.197269] Read of size 8 at addr ffff888112bd0448 by task kworker/u77:2/899
    [  194.197707]
    [  194.197818] CPU: 12 UID: 0 PID: 899 Comm: kworker/u77:2 Not tainted 6.11.0-lku-00028-gfca3ca14a17a-dirty #43
    [  194.198400] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014
    [  194.199046] Workqueue: smb3decryptd smb2_decrypt_offload [cifs]
    [  194.200032] Call Trace:
    [  194.200191]  &lt;TASK&gt;
    [  194.200327]  dump_stack_lvl+0x4e/0x70
    [  194.200558]  ? gf128mul_4k_lle+0xc1/0x110
    [  194.200809]  print_report+0x174/0x505
    [  194.201040]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10
    [  194.201352]  ? srso_return_thunk+0x5/0x5f
    [  194.201604]  ? __virt_addr_valid+0xdf/0x1c0
    [  194.201868]  ? gf128mul_4k_lle+0xc1/0x110
    [  194.202128]  kasan_report+0xc8/0x150
    [  194.202361]  ? gf128mul_4k_lle+0xc1/0x110
    [  194.202616]  gf128mul_4k_lle+0xc1/0x110
    [  194.202863]  ghash_update+0x184/0x210
    [  194.203103]  shash_ahash_update+0x184/0x2a0
    [  194.203377]  ? __pfx_shash_ahash_update+0x10/0x10
    [  194.203651]  ? srso_return_thunk+0x5/0x5f
    [  194.203877]  ? crypto_gcm_init_common+0x1ba/0x340
    [  194.204142]  gcm_hash_assoc_remain_continue+0x10a/0x140
    [  194.204434]  crypt_message+0xec1/0x10a0 [cifs]
    [  194.206489]  ? __pfx_crypt_message+0x10/0x10 [cifs]
    [  194.208507]  ? srso_return_thunk+0x5/0x5f
    [  194.209205]  ? srso_return_thunk+0x5/0x5f
    [  194.209925]  ? srso_return_thunk+0x5/0x5f
    [  194.210443]  ? srso_return_thunk+0x5/0x5f
    [  194.211037]  decrypt_raw_data+0x15f/0x250 [cifs]
    [  194.212906]  ? __pfx_decrypt_raw_data+0x10/0x10 [cifs]
    [  194.214670]  ? srso_return_thunk+0x5/0x5f
    [  194.215193]  smb2_decrypt_offload+0x12a/0x6c0 [cifs]

This is because TFM is being used in parallel.

Fix this by allocating a new AEAD TFM for async decryption, but keep
the existing one for synchronous READ cases (similar to what is done
in smb3_calc_signature()).

Also remove the calls to aead_request_set_callback() and
crypto_wait_req() since it's always going to be a synchronous operation.</Note>
    </Notes>
    <CVE>CVE-2024-50047</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

driver core: bus: Fix double free in driver API bus_register()

For bus_register(), any error which happens after kset_register() will
cause that @priv are freed twice, fixed by setting @priv with NULL after
the first free.</Note>
    </Notes>
    <CVE>CVE-2024-50055</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

serial: protect uart_port_dtr_rts() in uart_shutdown() too

Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part
3) added few uport == NULL checks. It added one to uart_shutdown(), so
the commit assumes, uport can be NULL in there. But right after that
protection, there is an unprotected "uart_port_dtr_rts(uport, false);"
call. That is invoked only if HUPCL is set, so I assume that is the
reason why we do not see lots of these reports.

Or it cannot be NULL at this point at all for some reason :P.

Until the above is investigated, stay on the safe side and move this
dereference to the if too.

I got this inconsistency from Coverity under CID 1585130. Thanks.</Note>
    </Notes>
    <CVE>CVE-2024-50058</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tty: n_gsm: Fix use-after-free in gsm_cleanup_mux

BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0
drivers/tty/n_gsm.c:3160 [n_gsm]
Read of size 8 at addr ffff88815fe99c00 by task poc/3379
CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56
Hardware name: VMware, Inc. VMware Virtual Platform/440BX
Desktop Reference Platform, BIOS 6.00 11/12/2020
Call Trace:
 &lt;TASK&gt;
 gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm]
 __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm]
 __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389
 update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500
 __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846
 __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161
 gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm]
 _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107
 __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm]
 ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195
 ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79
 __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338
 __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805
 tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818

Allocated by task 65:
 gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm]
 gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm]
 gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm]
 gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm]
 tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391
 tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39
 flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445
 process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229
 worker_thread+0x3dc/0x950 kernel/workqueue.c:3391
 kthread+0x2a3/0x370 kernel/kthread.c:389
 ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257

Freed by task 3367:
 kfree+0x126/0x420 mm/slub.c:4580
 gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm]
 gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm]
 tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818

[Analysis]
gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux
can be freed by multi threads through ioctl,which leads
to the occurrence of uaf. Protect it by gsm tx lock.</Note>
    </Notes>
    <CVE>CVE-2024-50073</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

parport: Proper fix for array out-of-bounds access

The recent fix for array out-of-bounds accesses replaced sprintf()
calls blindly with snprintf().  However, since snprintf() returns the
would-be-printed size, not the actually output size, the length
calculation can still go over the given limit.

Use scnprintf() instead of snprintf(), which returns the actually
output letters, for addressing the potential out-of-bounds access
properly.</Note>
    </Notes>
    <CVE>CVE-2024-50074</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/mad: Improve handling of timed out WRs of mad agent

Current timeout handler of mad agent acquires/releases mad_agent_priv
lock for every timed out WRs. This causes heavy locking contention
when higher no. of WRs are to be handled inside timeout handler.

This leads to softlockup with below trace in some use cases where
rdma-cm path is used to establish connection between peer nodes

Trace:
-----
 BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767]
 CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE
     -------  ---  5.14.0-427.13.1.el9_4.x86_64 #1
 Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019
 Workqueue: ib_mad1 timeout_sends [ib_core]
 RIP: 0010:__do_softirq+0x78/0x2ac
 RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246
 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f
 RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b
 RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000
 R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000
 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040
 FS:  0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
 PKRU: 55555554
 Call Trace:
  &lt;IRQ&gt;
  ? show_trace_log_lvl+0x1c4/0x2df
  ? show_trace_log_lvl+0x1c4/0x2df
  ? __irq_exit_rcu+0xa1/0xc0
  ? watchdog_timer_fn+0x1b2/0x210
  ? __pfx_watchdog_timer_fn+0x10/0x10
  ? __hrtimer_run_queues+0x127/0x2c0
  ? hrtimer_interrupt+0xfc/0x210
  ? __sysvec_apic_timer_interrupt+0x5c/0x110
  ? sysvec_apic_timer_interrupt+0x37/0x90
  ? asm_sysvec_apic_timer_interrupt+0x16/0x20
  ? __do_softirq+0x78/0x2ac
  ? __do_softirq+0x60/0x2ac
  __irq_exit_rcu+0xa1/0xc0
  sysvec_call_function_single+0x72/0x90
  &lt;/IRQ&gt;
  &lt;TASK&gt;
  asm_sysvec_call_function_single+0x16/0x20
 RIP: 0010:_raw_spin_unlock_irq+0x14/0x30
 RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247
 RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800
 RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c
 RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000
 R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538
 R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c
  cm_process_send_error+0x122/0x1d0 [ib_cm]
  timeout_sends+0x1dd/0x270 [ib_core]
  process_one_work+0x1e2/0x3b0
  ? __pfx_worker_thread+0x10/0x10
  worker_thread+0x50/0x3a0
  ? __pfx_worker_thread+0x10/0x10
  kthread+0xdd/0x100
  ? __pfx_kthread+0x10/0x10
  ret_from_fork+0x29/0x50
  &lt;/TASK&gt;

Simplified timeout handler by creating local list of timed out WRs
and invoke send handler post creating the list. The new method acquires/
releases lock once to fetch the list and hence helps to reduce locking
contetiong when processing higher no. of WRs</Note>
    </Notes>
    <CVE>CVE-2024-50095</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

arm64: probes: Remove broken LDR (literal) uprobe support

The simulate_ldr_literal() and simulate_ldrsw_literal() functions are
unsafe to use for uprobes. Both functions were originally written for
use with kprobes, and access memory with plain C accesses. When uprobes
was added, these were reused unmodified even though they cannot safely
access user memory.

There are three key problems:

1) The plain C accesses do not have corresponding extable entries, and
   thus if they encounter a fault the kernel will treat these as
   unintentional accesses to user memory, resulting in a BUG() which
   will kill the kernel thread, and likely lead to further issues (e.g.
   lockup or panic()).

2) The plain C accesses are subject to HW PAN and SW PAN, and so when
   either is in use, any attempt to simulate an access to user memory
   will fault. Thus neither simulate_ldr_literal() nor
   simulate_ldrsw_literal() can do anything useful when simulating a
   user instruction on any system with HW PAN or SW PAN.

3) The plain C accesses are privileged, as they run in kernel context,
   and in practice can access a small range of kernel virtual addresses.
   The instructions they simulate have a range of +/-1MiB, and since the
   simulated instructions must itself be a user instructions in the
   TTBR0 address range, these can address the final 1MiB of the TTBR1
   acddress range by wrapping downwards from an address in the first
   1MiB of the TTBR0 address range.

   In contemporary kernels the last 8MiB of TTBR1 address range is
   reserved, and accesses to this will always fault, meaning this is no
   worse than (1).

   Historically, it was theoretically possible for the linear map or
   vmemmap to spill into the final 8MiB of the TTBR1 address range, but
   in practice this is extremely unlikely to occur as this would
   require either:

   * Having enough physical memory to fill the entire linear map all the
     way to the final 1MiB of the TTBR1 address range.

   * Getting unlucky with KASLR randomization of the linear map such
     that the populated region happens to overlap with the last 1MiB of
     the TTBR address range.

   ... and in either case if we were to spill into the final page there
   would be larger problems as the final page would alias with error
   pointers.

Practically speaking, (1) and (2) are the big issues. Given there have
been no reports of problems since the broken code was introduced, it
appears that no-one is relying on probing these instructions with
uprobes.

Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW
(literal), limiting the use of simulate_ldr_literal() and
simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR
(literal) and LDRSW (literal) will be rejected as
arm_probe_decode_insn() will return INSN_REJECTED. In future we can
consider introducing working uprobes support for these instructions, but
this will require more significant work.</Note>
    </Notes>
    <CVE>CVE-2024-50099</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory

Ignore nCR3[4:0] when loading PDPTEs from memory for nested SVM, as bits
4:0 of CR3 are ignored when PAE paging is used, and thus VMRUN doesn't
enforce 32-byte alignment of nCR3.

In the absolute worst case scenario, failure to ignore bits 4:0 can result
in an out-of-bounds read, e.g. if the target page is at the end of a
memslot, and the VMM isn't using guard pages.

Per the APM:

  The CR3 register points to the base address of the page-directory-pointer
  table. The page-directory-pointer table is aligned on a 32-byte boundary,
  with the low 5 address bits 4:0 assumed to be 0.

And the SDM's much more explicit:

  4:0    Ignored

Note, KVM gets this right when loading PDPTRs, it's only the nSVM flow
that is broken.</Note>
    </Notes>
    <CVE>CVE-2024-50115</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd: Guard against bad data for ATIF ACPI method

If a BIOS provides bad data in response to an ATIF method call
this causes a NULL pointer dereference in the caller.

```
? show_regs (arch/x86/kernel/dumpstack.c:478 (discriminator 1))
? __die (arch/x86/kernel/dumpstack.c:423 arch/x86/kernel/dumpstack.c:434)
? page_fault_oops (arch/x86/mm/fault.c:544 (discriminator 2) arch/x86/mm/fault.c:705 (discriminator 2))
? do_user_addr_fault (arch/x86/mm/fault.c:440 (discriminator 1) arch/x86/mm/fault.c:1232 (discriminator 1))
? acpi_ut_update_object_reference (drivers/acpi/acpica/utdelete.c:642)
? exc_page_fault (arch/x86/mm/fault.c:1542)
? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623)
? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:387 (discriminator 2)) amdgpu
? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:386 (discriminator 1)) amdgpu
```

It has been encountered on at least one system, so guard for it.

(cherry picked from commit c9b7c809b89f24e9372a4e7f02d64c950b07fdee)</Note>
    </Notes>
    <CVE>CVE-2024-50117</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: SCO: Fix UAF on sco_sock_timeout

conn-&gt;sk maybe have been unlinked/freed while waiting for sco_conn_lock
so this checks if the conn-&gt;sk is still valid by checking if it part of
sco_sk_list.</Note>
    </Notes>
    <CVE>CVE-2024-50125</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nvme-pci: fix race condition between reset and nvme_dev_disable()

nvme_dev_disable() modifies the dev-&gt;online_queues field, therefore
nvme_pci_update_nr_queues() should avoid racing against it, otherwise
we could end up passing invalid values to blk_mq_update_nr_hw_queues().

 WARNING: CPU: 39 PID: 61303 at drivers/pci/msi/api.c:347
          pci_irq_get_affinity+0x187/0x210
 Workqueue: nvme-reset-wq nvme_reset_work [nvme]
 RIP: 0010:pci_irq_get_affinity+0x187/0x210
 Call Trace:
  &lt;TASK&gt;
  ? blk_mq_pci_map_queues+0x87/0x3c0
  ? pci_irq_get_affinity+0x187/0x210
  blk_mq_pci_map_queues+0x87/0x3c0
  nvme_pci_map_queues+0x189/0x460 [nvme]
  blk_mq_update_nr_hw_queues+0x2a/0x40
  nvme_reset_work+0x1be/0x2a0 [nvme]

Fix the bug by locking the shutdown_lock mutex before using
dev-&gt;online_queues. Give up if nvme_dev_disable() is running or if
it has been executed already.</Note>
    </Notes>
    <CVE>CVE-2024-50135</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: bnep: fix wild-memory-access in proto_unregister

There's issue as follows:
  KASAN: maybe wild-memory-access in range [0xdead...108-0xdead...10f]
  CPU: 3 UID: 0 PID: 2805 Comm: rmmod Tainted: G        W
  RIP: 0010:proto_unregister+0xee/0x400
  Call Trace:
   &lt;TASK&gt;
   __do_sys_delete_module+0x318/0x580
   do_syscall_64+0xc1/0x1d0
   entry_SYSCALL_64_after_hwframe+0x77/0x7f

As bnep_init() ignore bnep_sock_init()'s return value, and bnep_sock_init()
will cleanup all resource. Then when remove bnep module will call
bnep_sock_cleanup() to cleanup sock's resource.
To solve above issue just return bnep_sock_init()'s return value in
bnep_exit().</Note>
    </Notes>
    <CVE>CVE-2024-50148</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: typec: altmode should keep reference to parent

The altmode device release refers to its parent device, but without keeping
a reference to it.

When registering the altmode, get a reference to the parent and put it in
the release function.

Before this fix, when using CONFIG_DEBUG_KOBJECT_RELEASE, we see issues
like this:

[   43.572860] kobject: 'port0.0' (ffff8880057ba008): kobject_release, parent 0000000000000000 (delayed 3000)
[   43.573532] kobject: 'port0.1' (ffff8880057bd008): kobject_release, parent 0000000000000000 (delayed 1000)
[   43.574407] kobject: 'port0' (ffff8880057b9008): kobject_release, parent 0000000000000000 (delayed 3000)
[   43.575059] kobject: 'port1.0' (ffff8880057ca008): kobject_release, parent 0000000000000000 (delayed 4000)
[   43.575908] kobject: 'port1.1' (ffff8880057c9008): kobject_release, parent 0000000000000000 (delayed 4000)
[   43.576908] kobject: 'typec' (ffff8880062dbc00): kobject_release, parent 0000000000000000 (delayed 4000)
[   43.577769] kobject: 'port1' (ffff8880057bf008): kobject_release, parent 0000000000000000 (delayed 3000)
[   46.612867] ==================================================================
[   46.613402] BUG: KASAN: slab-use-after-free in typec_altmode_release+0x38/0x129
[   46.614003] Read of size 8 at addr ffff8880057b9118 by task kworker/2:1/48
[   46.614538]
[   46.614668] CPU: 2 UID: 0 PID: 48 Comm: kworker/2:1 Not tainted 6.12.0-rc1-00138-gedbae730ad31 #535
[   46.615391] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
[   46.616042] Workqueue: events kobject_delayed_cleanup
[   46.616446] Call Trace:
[   46.616648]  &lt;TASK&gt;
[   46.616820]  dump_stack_lvl+0x5b/0x7c
[   46.617112]  ? typec_altmode_release+0x38/0x129
[   46.617470]  print_report+0x14c/0x49e
[   46.617769]  ? rcu_read_unlock_sched+0x56/0x69
[   46.618117]  ? __virt_addr_valid+0x19a/0x1ab
[   46.618456]  ? kmem_cache_debug_flags+0xc/0x1d
[   46.618807]  ? typec_altmode_release+0x38/0x129
[   46.619161]  kasan_report+0x8d/0xb4
[   46.619447]  ? typec_altmode_release+0x38/0x129
[   46.619809]  ? process_scheduled_works+0x3cb/0x85f
[   46.620185]  typec_altmode_release+0x38/0x129
[   46.620537]  ? process_scheduled_works+0x3cb/0x85f
[   46.620907]  device_release+0xaf/0xf2
[   46.621206]  kobject_delayed_cleanup+0x13b/0x17a
[   46.621584]  process_scheduled_works+0x4f6/0x85f
[   46.621955]  ? __pfx_process_scheduled_works+0x10/0x10
[   46.622353]  ? hlock_class+0x31/0x9a
[   46.622647]  ? lock_acquired+0x361/0x3c3
[   46.622956]  ? move_linked_works+0x46/0x7d
[   46.623277]  worker_thread+0x1ce/0x291
[   46.623582]  ? __kthread_parkme+0xc8/0xdf
[   46.623900]  ? __pfx_worker_thread+0x10/0x10
[   46.624236]  kthread+0x17e/0x190
[   46.624501]  ? kthread+0xfb/0x190
[   46.624756]  ? __pfx_kthread+0x10/0x10
[   46.625015]  ret_from_fork+0x20/0x40
[   46.625268]  ? __pfx_kthread+0x10/0x10
[   46.625532]  ret_from_fork_asm+0x1a/0x30
[   46.625805]  &lt;/TASK&gt;
[   46.625953]
[   46.626056] Allocated by task 678:
[   46.626287]  kasan_save_stack+0x24/0x44
[   46.626555]  kasan_save_track+0x14/0x2d
[   46.626811]  __kasan_kmalloc+0x3f/0x4d
[   46.627049]  __kmalloc_noprof+0x1bf/0x1f0
[   46.627362]  typec_register_port+0x23/0x491
[   46.627698]  cros_typec_probe+0x634/0xbb6
[   46.628026]  platform_probe+0x47/0x8c
[   46.628311]  really_probe+0x20a/0x47d
[   46.628605]  device_driver_attach+0x39/0x72
[   46.628940]  bind_store+0x87/0xd7
[   46.629213]  kernfs_fop_write_iter+0x1aa/0x218
[   46.629574]  vfs_write+0x1d6/0x29b
[   46.629856]  ksys_write+0xcd/0x13b
[   46.630128]  do_syscall_64+0xd4/0x139
[   46.630420]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[   46.630820]
[   46.630946] Freed by task 48:
[   46.631182]  kasan_save_stack+0x24/0x44
[   46.631493]  kasan_save_track+0x14/0x2d
[   46.631799]  kasan_save_free_info+0x3f/0x4d
[   46.632144]  __kasan_slab_free+0x37/0x45
[   46.632474]
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-50150</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().

Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler().

  """
  We are seeing a use-after-free from a bpf prog attached to
  trace_tcp_retransmit_synack. The program passes the req-&gt;sk to the
  bpf_sk_storage_get_tracing kernel helper which does check for null
  before using it.
  """

The commit 83fccfc3940c ("inet: fix potential deadlock in
reqsk_queue_unlink()") added timer_pending() in reqsk_queue_unlink() not
to call del_timer_sync() from reqsk_timer_handler(), but it introduced a
small race window.

Before the timer is called, expire_timers() calls detach_timer(timer, true)
to clear timer-&gt;entry.pprev and marks it as not pending.

If reqsk_queue_unlink() checks timer_pending() just after expire_timers()
calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will
continue running and send multiple SYN+ACKs until it expires.

The reported UAF could happen if req-&gt;sk is close()d earlier than the timer
expiration, which is 63s by default.

The scenario would be

  1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(),
     but del_timer_sync() is missed

  2. reqsk timer is executed and scheduled again

  3. req-&gt;sk is accept()ed and reqsk_put() decrements rsk_refcnt, but
     reqsk timer still has another one, and inet_csk_accept() does not
     clear req-&gt;sk for non-TFO sockets

  4. sk is close()d

  5. reqsk timer is executed again, and BPF touches req-&gt;sk

Let's not use timer_pending() by passing the caller context to
__inet_csk_reqsk_queue_drop().

Note that reqsk timer is pinned, so the issue does not happen in most
use cases. [1]

[0]
BUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0

Use-after-free read at 0x00000000a891fb3a (in kfence-#1):
bpf_sk_storage_get_tracing+0x2e/0x1b0
bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1dda
bpf_trace_run2+0x4c/0xc0
tcp_rtx_synack+0xf9/0x100
reqsk_timer_handler+0xda/0x3d0
run_timer_softirq+0x292/0x8a0
irq_exit_rcu+0xf5/0x320
sysvec_apic_timer_interrupt+0x6d/0x80
asm_sysvec_apic_timer_interrupt+0x16/0x20
intel_idle_irq+0x5a/0xa0
cpuidle_enter_state+0x94/0x273
cpu_startup_entry+0x15e/0x260
start_secondary+0x8a/0x90
secondary_startup_64_no_verify+0xfa/0xfb

kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6

allocated by task 0 on cpu 9 at 260507.901592s:
sk_prot_alloc+0x35/0x140
sk_clone_lock+0x1f/0x3f0
inet_csk_clone_lock+0x15/0x160
tcp_create_openreq_child+0x1f/0x410
tcp_v6_syn_recv_sock+0x1da/0x700
tcp_check_req+0x1fb/0x510
tcp_v6_rcv+0x98b/0x1420
ipv6_list_rcv+0x2258/0x26e0
napi_complete_done+0x5b1/0x2990
mlx5e_napi_poll+0x2ae/0x8d0
net_rx_action+0x13e/0x590
irq_exit_rcu+0xf5/0x320
common_interrupt+0x80/0x90
asm_common_interrupt+0x22/0x40
cpuidle_enter_state+0xfb/0x273
cpu_startup_entry+0x15e/0x260
start_secondary+0x8a/0x90
secondary_startup_64_no_verify+0xfa/0xfb

freed by task 0 on cpu 9 at 260507.927527s:
rcu_core_si+0x4ff/0xf10
irq_exit_rcu+0xf5/0x320
sysvec_apic_timer_interrupt+0x6d/0x80
asm_sysvec_apic_timer_interrupt+0x16/0x20
cpuidle_enter_state+0xfb/0x273
cpu_startup_entry+0x15e/0x260
start_secondary+0x8a/0x90
secondary_startup_64_no_verify+0xfa/0xfb</Note>
    </Notes>
    <CVE>CVE-2024-50154</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

be2net: fix potential memory leak in be_xmit()

The be_xmit() returns NETDEV_TX_OK without freeing skb
in case of be_xmit_enqueue() fails, add dev_kfree_skb_any() to fix it.</Note>
    </Notes>
    <CVE>CVE-2024-50167</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: systemport: fix potential memory leak in bcm_sysport_xmit()

The bcm_sysport_xmit() returns NETDEV_TX_OK without freeing skb
in case of dma_map_single() fails, add dev_kfree_skb() to fix it.</Note>
    </Notes>
    <CVE>CVE-2024-50171</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ceph: remove the incorrect Fw reference check when dirtying pages

When doing the direct-io reads it will also try to mark pages dirty,
but for the read path it won't hold the Fw caps and there is case
will it get the Fw reference.</Note>
    </Notes>
    <CVE>CVE-2024-50179</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instance

Deleting an NPIV instance requires all fabric ndlps to be released before
an NPIV's resources can be torn down.  Failure to release fabric ndlps
beforehand opens kref imbalance race conditions.  Fix by forcing the DA_ID
to complete synchronously with usage of wait_queue.</Note>
    </Notes>
    <CVE>CVE-2024-50183</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/vc4: Stop the active perfmon before being destroyed

Upon closing the file descriptor, the active performance monitor is not
stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`,
the active performance monitor's pointer (`vc4-&gt;active_perfmon`) is still
retained.

If we open a new file descriptor and submit a few jobs with performance
monitors, the driver will attempt to stop the active performance monitor
using the stale pointer in `vc4-&gt;active_perfmon`. However, this pointer
is no longer valid because the previous process has already terminated,
and all performance monitors associated with it have been destroyed and
freed.

To fix this, when the active performance monitor belongs to a given
process, explicitly stop it before destroying and freeing it.</Note>
    </Notes>
    <CVE>CVE-2024-50187</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

arm64: probes: Fix uprobes for big-endian kernels

The arm64 uprobes code is broken for big-endian kernels as it doesn't
convert the in-memory instruction encoding (which is always
little-endian) into the kernel's native endianness before analyzing and
simulating instructions. This may result in a few distinct problems:

* The kernel may may erroneously reject probing an instruction which can
  safely be probed.

* The kernel may erroneously erroneously permit stepping an
  instruction out-of-line when that instruction cannot be stepped
  out-of-line safely.

* The kernel may erroneously simulate instruction incorrectly dur to
  interpretting the byte-swapped encoding.

The endianness mismatch isn't caught by the compiler or sparse because:

* The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so
  the compiler and sparse have no idea these contain a little-endian
  32-bit value. The core uprobes code populates these with a memcpy()
  which similarly does not handle endianness.

* While the uprobe_opcode_t type is an alias for __le32, both
  arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[]
  to the similarly-named probe_opcode_t, which is an alias for u32.
  Hence there is no endianness conversion warning.

Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and
adding the appropriate __le32_to_cpu() conversions prior to consuming
the instruction encoding. The core uprobes copies these fields as opaque
ranges of bytes, and so is unaffected by this change.

At the same time, remove MAX_UINSN_BYTES and consistently use
AARCH64_INSN_SIZE for clarity.

Tested with the following:

| #include &lt;stdio.h&gt;
| #include &lt;stdbool.h&gt;
|
| #define noinline __attribute__((noinline))
|
| static noinline void *adrp_self(void)
| {
|         void *addr;
|
|         asm volatile(
|         "       adrp    %x0, adrp_self\n"
|         "       add     %x0, %x0, :lo12:adrp_self\n"
|         : "=r" (addr));
| }
|
|
| int main(int argc, char *argv)
| {
|         void *ptr = adrp_self();
|         bool equal = (ptr == adrp_self);
|
|         printf("adrp_self   =&gt; %p\n"
|                "adrp_self() =&gt; %p\n"
|                "%s\n",
|                adrp_self, ptr, equal ? "EQUAL" : "NOT EQUAL");
|
|         return 0;
| }

.... where the adrp_self() function was compiled to:

| 00000000004007e0 &lt;adrp_self&gt;:
|   4007e0:       90000000        adrp    x0, 400000 &lt;__ehdr_start&gt;
|   4007e4:       911f8000        add     x0, x0, #0x7e0
|   4007e8:       d65f03c0        ret

Before this patch, the ADRP is not recognized, and is assumed to be
steppable, resulting in corruption of the result:

| # ./adrp-self
| adrp_self   =&gt; 0x4007e0
| adrp_self() =&gt; 0x4007e0
| EQUAL
| # echo 'p /root/adrp-self:0x007e0' &gt; /sys/kernel/tracing/uprobe_events
| # echo 1 &gt; /sys/kernel/tracing/events/uprobes/enable
| # ./adrp-self
| adrp_self   =&gt; 0x4007e0
| adrp_self() =&gt; 0xffffffffff7e0
| NOT EQUAL

After this patch, the ADRP is correctly recognized and simulated:

| # ./adrp-self
| adrp_self   =&gt; 0x4007e0
| adrp_self() =&gt; 0x4007e0
| EQUAL
| #
| # echo 'p /root/adrp-self:0x007e0' &gt; /sys/kernel/tracing/uprobe_events
| # echo 1 &gt; /sys/kernel/tracing/events/uprobes/enable
| # ./adrp-self
| adrp_self   =&gt; 0x4007e0
| adrp_self() =&gt; 0x4007e0
| EQUAL</Note>
    </Notes>
    <CVE>CVE-2024-50194</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

posix-clock: Fix missing timespec64 check in pc_clock_settime()

As Andrew pointed out, it will make sense that the PTP core
checked timespec64 struct's tv_sec and tv_nsec range before calling
ptp-&gt;info-&gt;settime64().

As the man manual of clock_settime() said, if tp.tv_sec is negative or
tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL,
which include dynamic clocks which handles PTP clock, and the condition is
consistent with timespec64_valid(). As Thomas suggested, timespec64_valid()
only check the timespec is valid, but not ensure that the time is
in a valid range, so check it ahead using timespec64_valid_strict()
in pc_clock_settime() and return -EINVAL if not valid.

There are some drivers that use tp-&gt;tv_sec and tp-&gt;tv_nsec directly to
write registers without validity checks and assume that the higher layer
has checked it, which is dangerous and will benefit from this, such as
hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(),
and some drivers can remove the checks of itself.</Note>
    </Notes>
    <CVE>CVE-2024-50195</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow

Syzbot reported a kernel BUG in ocfs2_truncate_inline.  There are two
reasons for this: first, the parameter value passed is greater than
ocfs2_max_inline_data_with_xattr, second, the start and end parameters of
ocfs2_truncate_inline are "unsigned int".

So, we need to add a sanity check for byte_start and byte_len right before
ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater
than ocfs2_max_inline_data_with_xattr return -EINVAL.</Note>
    </Notes>
    <CVE>CVE-2024-50218</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
    </Notes>
    <CVE>CVE-2024-50228</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlegacy: Clear stale interrupts before resuming device

iwl4965 fails upon resume from hibernation on my laptop. The reason
seems to be a stale interrupt which isn't being cleared out before
interrupts are enabled. We end up with a race beween the resume
trying to bring things back up, and the restart work (queued form
the interrupt handler) trying to bring things down. Eventually
the whole thing blows up.

Fix the problem by clearing out any stale interrupts before
interrupts get enabled during resume.

Here's a debug log of the indicent:
[   12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000
[   12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000
[   12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio.
[   12.042653] iwl4965 0000:10:00.0: On demand firmware reload
[   12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282
[   12.052207] ieee80211 phy0: il4965_mac_start enter
[   12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff
[   12.052244] ieee80211 phy0: il4965_set_hw_ready hardware  ready
[   12.052324] ieee80211 phy0: il_apm_init Init card's basic functions
[   12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S
[   12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm
[   12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm
[   12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK
[   12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations
[   12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up
[   12.058737] ieee80211 phy0: il4965_mac_start Start UP work done.
[   12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down
[   12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout
[   12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort
[   12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver
[   12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared
[   12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state
[   12.058827] ieee80211 phy0: _il_apm_stop_master stop master
[   12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear.
[   12.058869] ieee80211 phy0: Hardware restart was requested
[   16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms.
[   16.132303] ------------[ cut here ]------------
[   16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue.
[   16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211]
[   16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev
[   16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143
[   16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010
[   16.132463] Workqueue: async async_run_entry_fn
[   16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211]
[   16.132501] Code: da 02 00 0
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-50234</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: ath10k: Fix memory leak in management tx

In the current logic, memory is allocated for storing the MSDU context
during management packet TX but this memory is not being freed during
management TX completion. Similar leaks are seen in the management TX
cleanup logic.

Kmemleak reports this problem as below,

unreferenced object 0xffffff80b64ed250 (size 16):
  comm "kworker/u16:7", pid 148, jiffies 4294687130 (age 714.199s)
  hex dump (first 16 bytes):
    00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00  .+.......t......
  backtrace:
    [&lt;ffffffe6e7b245dc&gt;] __kmem_cache_alloc_node+0x1e4/0x2d8
    [&lt;ffffffe6e7adde88&gt;] kmalloc_trace+0x48/0x110
    [&lt;ffffffe6bbd765fc&gt;] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core]
    [&lt;ffffffe6bbd3eed4&gt;] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core]
    [&lt;ffffffe6e78d5974&gt;] process_scheduled_works+0x1ac/0x400
    [&lt;ffffffe6e78d60b8&gt;] worker_thread+0x208/0x328
    [&lt;ffffffe6e78dc890&gt;] kthread+0x100/0x1c0
    [&lt;ffffffe6e78166c0&gt;] ret_from_fork+0x10/0x20

Free the memory during completion and cleanup to fix the leak.

Protect the mgmt_pending_tx idr_remove() operation in
ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar-&gt;data_lock similar to
other instances.

Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1</Note>
    </Notes>
    <CVE>CVE-2024-50236</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower

Avoid potentially crashing in the driver because of uninitialized private data</Note>
    </Notes>
    <CVE>CVE-2024-50237</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vsock/virtio: Initialization of the dangling pointer occurring in vsk-&gt;trans

During loopback communication, a dangling pointer can be created in
vsk-&gt;trans, potentially leading to a Use-After-Free condition.  This
issue is resolved by initializing vsk-&gt;trans to NULL.</Note>
    </Notes>
    <CVE>CVE-2024-50264</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove()

Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove():

[   57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12
[   57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper.  Leaking 1 clusters and removing the entry
[   57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004
[...]
[   57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0
[...]
[   57.331328] Call Trace:
[   57.331477]  &lt;TASK&gt;
[...]
[   57.333511]  ? do_user_addr_fault+0x3e5/0x740
[   57.333778]  ? exc_page_fault+0x70/0x170
[   57.334016]  ? asm_exc_page_fault+0x2b/0x30
[   57.334263]  ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10
[   57.334596]  ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0
[   57.334913]  ocfs2_xa_remove_entry+0x23/0xc0
[   57.335164]  ocfs2_xa_set+0x704/0xcf0
[   57.335381]  ? _raw_spin_unlock+0x1a/0x40
[   57.335620]  ? ocfs2_inode_cache_unlock+0x16/0x20
[   57.335915]  ? trace_preempt_on+0x1e/0x70
[   57.336153]  ? start_this_handle+0x16c/0x500
[   57.336410]  ? preempt_count_sub+0x50/0x80
[   57.336656]  ? _raw_read_unlock+0x20/0x40
[   57.336906]  ? start_this_handle+0x16c/0x500
[   57.337162]  ocfs2_xattr_block_set+0xa6/0x1e0
[   57.337424]  __ocfs2_xattr_set_handle+0x1fd/0x5d0
[   57.337706]  ? ocfs2_start_trans+0x13d/0x290
[   57.337971]  ocfs2_xattr_set+0xb13/0xfb0
[   57.338207]  ? dput+0x46/0x1c0
[   57.338393]  ocfs2_xattr_trusted_set+0x28/0x30
[   57.338665]  ? ocfs2_xattr_trusted_set+0x28/0x30
[   57.338948]  __vfs_removexattr+0x92/0xc0
[   57.339182]  __vfs_removexattr_locked+0xd5/0x190
[   57.339456]  ? preempt_count_sub+0x50/0x80
[   57.339705]  vfs_removexattr+0x5f/0x100
[...]

Reproducer uses faultinject facility to fail ocfs2_xa_remove() -&gt;
ocfs2_xa_value_truncate() with -ENOMEM.

In this case the comment mentions that we can return 0 if
ocfs2_xa_cleanup_value_truncate() is going to wipe the entry
anyway. But the following 'rc' check is wrong and execution flow do
'ocfs2_xa_remove_entry(loc);' twice:
* 1st: in ocfs2_xa_cleanup_value_truncate();
* 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'.

Fix this by skipping the 2nd removal of the same entry and making
syzkaller repro happy.</Note>
    </Notes>
    <CVE>CVE-2024-50265</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

USB: serial: io_edgeport: fix use after free in debug printk

The "dev_dbg(&amp;urb-&gt;dev-&gt;dev, ..." which happens after usb_free_urb(urb)
is a use after free of the "urb" pointer.  Store the "dev" pointer at the
start of the function to avoid this issue.</Note>
    </Notes>
    <CVE>CVE-2024-50267</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

btrfs: reinitialize delayed ref list after deleting it from the list

At insert_delayed_ref() if we need to update the action of an existing
ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head's
ref_add_list using list_del(), which leaves the ref's add_list member
not reinitialized, as list_del() sets the next and prev members of the
list to LIST_POISON1 and LIST_POISON2, respectively.

If later we end up calling drop_delayed_ref() against the ref, which can
happen during merging or when destroying delayed refs due to a transaction
abort, we can trigger a crash since at drop_delayed_ref() we call
list_empty() against the ref's add_list, which returns false since
the list was not reinitialized after the list_del() and as a consequence
we call list_del() again at drop_delayed_ref(). This results in an
invalid list access since the next and prev members are set to poison
pointers, resulting in a splat if CONFIG_LIST_HARDENED and
CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences
otherwise.

So fix this by deleting from the list with list_del_init() instead.</Note>
    </Notes>
    <CVE>CVE-2024-50273</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

dm cache: fix potential out-of-bounds access on the first resume

Out-of-bounds access occurs if the fast device is expanded unexpectedly
before the first-time resume of the cache table. This happens because
expanding the fast device requires reloading the cache table for
cache_create to allocate new in-core data structures that fit the new
size, and the check in cache_preresume is not performed during the
first resume, leading to the issue.

Reproduce steps:

1. prepare component devices:

dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"
dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"
dmsetup create corig --table "0 524288 linear /dev/sdc 262144"
dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct

2. load a cache table of 512 cache blocks, and deliberately expand the
   fast device before resuming the cache, making the in-core data
   structures inadequate.

dmsetup create cache --notable
dmsetup reload cache --table "0 524288 cache /dev/mapper/cmeta \
/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"
dmsetup reload cdata --table "0 131072 linear /dev/sdc 8192"
dmsetup resume cdata
dmsetup resume cache

3. suspend the cache to write out the in-core dirty bitset and hint
   array, leading to out-of-bounds access to the dirty bitset at offset
   0x40:

dmsetup suspend cache

KASAN reports:

  BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80
  Read of size 8 at addr ffffc90000085040 by task dmsetup/90

  (...snip...)
  The buggy address belongs to the virtual mapping at
   [ffffc90000085000, ffffc90000087000) created by:
   cache_ctr+0x176a/0x35f0

  (...snip...)
  Memory state around the buggy address:
   ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
   ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
  &gt;ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8
                                             ^
   ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
   ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8

Fix by checking the size change on the first resume.</Note>
    </Notes>
    <CVE>CVE-2024-50278</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

dm cache: fix out-of-bounds access to the dirty bitset when resizing

dm-cache checks the dirty bits of the cache blocks to be dropped when
shrinking the fast device, but an index bug in bitset iteration causes
out-of-bounds access.

Reproduce steps:

1. create a cache device of 1024 cache blocks (128 bytes dirty bitset)

dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"
dmsetup create cdata --table "0 131072 linear /dev/sdc 8192"
dmsetup create corig --table "0 524288 linear /dev/sdc 262144"
dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct
dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \
/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"

2. shrink the fast device to 512 cache blocks, triggering out-of-bounds
   access to the dirty bitset (offset 0x80)

dmsetup suspend cache
dmsetup reload cdata --table "0 65536 linear /dev/sdc 8192"
dmsetup resume cdata
dmsetup resume cache

KASAN reports:

  BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0
  Read of size 8 at addr ffffc900000f3080 by task dmsetup/131

  (...snip...)
  The buggy address belongs to the virtual mapping at
   [ffffc900000f3000, ffffc900000f5000) created by:
   cache_ctr+0x176a/0x35f0

  (...snip...)
  Memory state around the buggy address:
   ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
   ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  &gt;ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
                     ^
   ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
   ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8

Fix by making the index post-incremented.</Note>
    </Notes>
    <CVE>CVE-2024-50279</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: av7110: fix a spectre vulnerability

As warned by smatch:
	drivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue 'av7110-&gt;ci_slot' [w] (local cap)

There is a spectre-related vulnerability at the code. Fix it.</Note>
    </Notes>
    <CVE>CVE-2024-50289</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: 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.</Note>
    </Notes>
    <CVE>CVE-2024-50290</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: hns3: fix kernel crash when uninstalling driver

When the driver is uninstalled and the VF is disabled concurrently, a
kernel crash occurs. The reason is that the two actions call function
pci_disable_sriov(). The num_VFs is checked to determine whether to
release the corresponding resources. During the second calling, num_VFs
is not 0 and the resource release function is called. However, the
corresponding resource has been released during the first invoking.
Therefore, the problem occurs:

[15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020
...
[15278.131557][T50670] Call trace:
[15278.134686][T50670]  klist_put+0x28/0x12c
[15278.138682][T50670]  klist_del+0x14/0x20
[15278.142592][T50670]  device_del+0xbc/0x3c0
[15278.146676][T50670]  pci_remove_bus_device+0x84/0x120
[15278.151714][T50670]  pci_stop_and_remove_bus_device+0x6c/0x80
[15278.157447][T50670]  pci_iov_remove_virtfn+0xb4/0x12c
[15278.162485][T50670]  sriov_disable+0x50/0x11c
[15278.166829][T50670]  pci_disable_sriov+0x24/0x30
[15278.171433][T50670]  hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3]
[15278.178039][T50670]  hclge_exit+0x28/0xd0 [hclge]
[15278.182730][T50670]  __se_sys_delete_module.isra.0+0x164/0x230
[15278.188550][T50670]  __arm64_sys_delete_module+0x1c/0x30
[15278.193848][T50670]  invoke_syscall+0x50/0x11c
[15278.198278][T50670]  el0_svc_common.constprop.0+0x158/0x164
[15278.203837][T50670]  do_el0_svc+0x34/0xcc
[15278.207834][T50670]  el0_svc+0x20/0x30

For details, see the following figure.

     rmmod hclge              disable VFs
----------------------------------------------------
hclge_exit()            sriov_numvfs_store()
  ...                     device_lock()
  pci_disable_sriov()     hns3_pci_sriov_configure()
                            pci_disable_sriov()
                              sriov_disable()
    sriov_disable()             if !num_VFs :
      if !num_VFs :               return;
        return;                 sriov_del_vfs()
      sriov_del_vfs()             ...
        ...                       klist_put()
        klist_put()               ...
        ...                     num_VFs = 0;
      num_VFs = 0;        device_unlock();

In this patch, when driver is removing, we get the device_lock()
to protect num_VFs, just like sriov_numvfs_store().</Note>
    </Notes>
    <CVE>CVE-2024-50296</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

security/keys: fix slab-out-of-bounds in key_task_permission

KASAN reports an out of bounds read:
BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36
BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline]
BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410
security/keys/permission.c:54
Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362

CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15
Call Trace:
 __dump_stack lib/dump_stack.c:82 [inline]
 dump_stack+0x107/0x167 lib/dump_stack.c:123
 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400
 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560
 kasan_report+0x3a/0x50 mm/kasan/report.c:585
 __kuid_val include/linux/uidgid.h:36 [inline]
 uid_eq include/linux/uidgid.h:63 [inline]
 key_task_permission+0x394/0x410 security/keys/permission.c:54
 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793

This issue was also reported by syzbot.

It can be reproduced by following these steps(more details [1]):
1. Obtain more than 32 inputs that have similar hashes, which ends with the
   pattern '0xxxxxxxe6'.
2. Reboot and add the keys obtained in step 1.

The reproducer demonstrates how this issue happened:
1. In the search_nested_keyrings function, when it iterates through the
   slots in a node(below tag ascend_to_node), if the slot pointer is meta
   and node-&gt;back_pointer != NULL(it means a root), it will proceed to
   descend_to_node. However, there is an exception. If node is the root,
   and one of the slots points to a shortcut, it will be treated as a
   keyring.
2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function.
   However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as
   ASSOC_ARRAY_PTR_SUBTYPE_MASK.
3. When 32 keys with the similar hashes are added to the tree, the ROOT
   has keys with hashes that are not similar (e.g. slot 0) and it splits
   NODE A without using a shortcut. When NODE A is filled with keys that
   all hashes are xxe6, the keys are similar, NODE A will split with a
   shortcut. Finally, it forms the tree as shown below, where slot 6 points
   to a shortcut.

                      NODE A
              +------&gt;+---+
      ROOT    |       | 0 | xxe6
      +---+   |       +---+
 xxxx | 0 | shortcut  :   : xxe6
      +---+   |       +---+
 xxe6 :   :   |       |   | xxe6
      +---+   |       +---+
      | 6 |---+       :   : xxe6
      +---+           +---+
 xxe6 :   :           | f | xxe6
      +---+           +---+
 xxe6 | f |
      +---+

4. As mentioned above, If a slot(slot 6) of the root points to a shortcut,
   it may be mistakenly transferred to a key*, leading to a read
   out-of-bounds read.

To fix this issue, one should jump to descend_to_node if the ptr is a
shortcut, regardless of whether the node is root or not.

[1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/

[jarkko: tweaked the commit message a bit to have an appropriate closes
 tag.]</Note>
    </Notes>
    <CVE>CVE-2024-50301</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

HID: core: zero-initialize the report buffer

Since the report buffer is used by all kinds of drivers in various ways, let's
zero-initialize it during allocation to make sure that it can't be ever used
to leak kernel memory via specially-crafted report.</Note>
    </Notes>
    <CVE>CVE-2024-50302</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">An 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.</Note>
    </Notes>
    <CVE>CVE-2024-50602</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:expat-2.1.0-21.40.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:libexpat1-2.1.0-21.40.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">gio/gsocks4aproxy.c in GNOME GLib before 2.82.1 has an off-by-one error and resultant buffer overflow because SOCKS4_CONN_MSG_LEN is not sufficient for a trailing '\0' character.</Note>
    </Notes>
    <CVE>CVE-2024-52533</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:glib2-tools-2.48.2-12.43.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:libgio-2_0-0-2.48.2-12.43.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:libglib-2_0-0-2.48.2-12.43.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:libgmodule-2_0-0-2.48.2-12.43.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:libgobject-2_0-0-2.48.2-12.43.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in the Avahi-daemon, where it initializes DNS transaction IDs randomly only once at startup, incrementing them sequentially after that. This predictable behavior facilitates DNS spoofing attacks, allowing attackers to guess transaction IDs.</Note>
    </Notes>
    <CVE>CVE-2024-52616</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:libavahi-client3-0.6.32-32.30.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:libavahi-common3-0.6.32-32.30.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data

In case the non-paged data of a SKB carries protocol header and protocol
payload to be transmitted on a certain platform that the DMA AXI address
width is configured to 40-bit/48-bit, or the size of the non-paged data
is bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXI
address width is configured to 32-bit, then this SKB requires at least
two DMA transmit descriptors to serve it.

For example, three descriptors are allocated to split one DMA buffer
mapped from one piece of non-paged data:
    dma_desc[N + 0],
    dma_desc[N + 1],
    dma_desc[N + 2].
Then three elements of tx_q-&gt;tx_skbuff_dma[] will be allocated to hold
extra information to be reused in stmmac_tx_clean():
    tx_q-&gt;tx_skbuff_dma[N + 0],
    tx_q-&gt;tx_skbuff_dma[N + 1],
    tx_q-&gt;tx_skbuff_dma[N + 2].
Now we focus on tx_q-&gt;tx_skbuff_dma[entry].buf, which is the DMA buffer
address returned by DMA mapping call. stmmac_tx_clean() will try to
unmap the DMA buffer _ONLY_IF_ tx_q-&gt;tx_skbuff_dma[entry].buf
is a valid buffer address.

The expected behavior that saves DMA buffer address of this non-paged
data to tx_q-&gt;tx_skbuff_dma[entry].buf is:
    tx_q-&gt;tx_skbuff_dma[N + 0].buf = NULL;
    tx_q-&gt;tx_skbuff_dma[N + 1].buf = NULL;
    tx_q-&gt;tx_skbuff_dma[N + 2].buf = dma_map_single();
Unfortunately, the current code misbehaves like this:
    tx_q-&gt;tx_skbuff_dma[N + 0].buf = dma_map_single();
    tx_q-&gt;tx_skbuff_dma[N + 1].buf = NULL;
    tx_q-&gt;tx_skbuff_dma[N + 2].buf = NULL;

On the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by the
DMA engine, tx_q-&gt;tx_skbuff_dma[N + 0].buf is a valid buffer address
obviously, then the DMA buffer will be unmapped immediately.
There may be a rare case that the DMA engine does not finish the
pending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will go
horribly wrong, DMA is going to access a unmapped/unreferenced memory
region, corrupted data will be transmited or iommu fault will be
triggered :(

In contrast, the for-loop that maps SKB fragments behaves perfectly
as expected, and that is how the driver should do for both non-paged
data and paged frags actually.

This patch corrects DMA map/unmap sequences by fixing the array index
for tx_q-&gt;tx_skbuff_dma[entry].buf when assigning DMA buffer address.

Tested and verified on DWXGMAC CORE 3.20a</Note>
    </Notes>
    <CVE>CVE-2024-53058</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: s5p-jpeg: prevent buffer overflows

The current logic allows word to be less than 2. If this happens,
there will be buffer overflows, as reported by smatch. Add extra
checks to prevent it.

While here, remove an unused word = 0 assignment.</Note>
    </Notes>
    <CVE>CVE-2024-53061</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: 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.</Note>
    </Notes>
    <CVE>CVE-2024-53063</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nfs: Fix KMSAN warning in decode_getfattr_attrs()

Fix the following KMSAN warning:

CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G    B
Tainted: [B]=BAD_PAGE
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)
=====================================================
=====================================================
BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90
 decode_getfattr_attrs+0x2d6d/0x2f90
 decode_getfattr_generic+0x806/0xb00
 nfs4_xdr_dec_getattr+0x1de/0x240
 rpcauth_unwrap_resp_decode+0xab/0x100
 rpcauth_unwrap_resp+0x95/0xc0
 call_decode+0x4ff/0xb50
 __rpc_execute+0x57b/0x19d0
 rpc_execute+0x368/0x5e0
 rpc_run_task+0xcfe/0xee0
 nfs4_proc_getattr+0x5b5/0x990
 __nfs_revalidate_inode+0x477/0xd00
 nfs_access_get_cached+0x1021/0x1cc0
 nfs_do_access+0x9f/0xae0
 nfs_permission+0x1e4/0x8c0
 inode_permission+0x356/0x6c0
 link_path_walk+0x958/0x1330
 path_lookupat+0xce/0x6b0
 filename_lookup+0x23e/0x770
 vfs_statx+0xe7/0x970
 vfs_fstatat+0x1f2/0x2c0
 __se_sys_newfstatat+0x67/0x880
 __x64_sys_newfstatat+0xbd/0x120
 x64_sys_call+0x1826/0x3cf0
 do_syscall_64+0xd0/0x1b0
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

The KMSAN warning is triggered in decode_getfattr_attrs(), when calling
decode_attr_mdsthreshold(). It appears that fattr-&gt;mdsthreshold is not
initialized.

Fix the issue by initializing fattr-&gt;mdsthreshold to NULL in
nfs_fattr_init().</Note>
    </Notes>
    <CVE>CVE-2024-53066</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tpm: Lock TPM chip in tpm_pm_suspend() first

Setting TPM_CHIP_FLAG_SUSPENDED in the end of tpm_pm_suspend() can be racy
according, as this leaves window for tpm_hwrng_read() to be called while
the operation is in progress. The recent bug report gives also evidence of
this behaviour.

Aadress this by locking the TPM chip before checking any chip-&gt;flags both
in tpm_pm_suspend() and tpm_hwrng_read(). Move TPM_CHIP_FLAG_SUSPENDED
check inside tpm_get_random() so that it will be always checked only when
the lock is reserved.</Note>
    </Notes>
    <CVE>CVE-2024-53085</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

i40e: fix race condition by adding filter's intermediate sync state

Fix a race condition in the i40e driver that leads to MAC/VLAN filters
becoming corrupted and leaking. Address the issue that occurs under
heavy load when multiple threads are concurrently modifying MAC/VLAN
filters by setting mac and port VLAN.

1. Thread T0 allocates a filter in i40e_add_filter() within
        i40e_ndo_set_vf_port_vlan().
2. Thread T1 concurrently frees the filter in __i40e_del_filter() within
        i40e_ndo_set_vf_mac().
3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which
        refers to the already freed filter memory, causing corruption.

Reproduction steps:
1. Spawn multiple VFs.
2. Apply a concurrent heavy load by running parallel operations to change
        MAC addresses on the VFs and change port VLANs on the host.
3. Observe errors in dmesg:
"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX,
	please set promiscuous on manually for VF XX".

Exact code for stable reproduction Intel can't open-source now.

The fix involves implementing a new intermediate filter state,
I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list.
These filters cannot be deleted from the hash list directly but
must be removed using the full process.</Note>
    </Notes>
    <CVE>CVE-2024-53088</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format

This can lead to out of bounds writes since frames of this type were not
taken into account when calculating the size of the frames buffer in
uvc_parse_streaming.</Note>
    </Notes>
    <CVE>CVE-2024-53104</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client

A number of Zen4 client SoCs advertise the ability to use virtualized
VMLOAD/VMSAVE, but using these instructions is reported to be a cause
of a random host reboot.

These instructions aren't intended to be advertised on Zen4 client
so clear the capability.</Note>
    </Notes>
    <CVE>CVE-2024-53114</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

initramfs: avoid filename buffer overrun

The initramfs filename field is defined in
Documentation/driver-api/early-userspace/buffer-format.rst as:

 37 cpio_file := ALGN(4) + cpio_header + filename + "\0" + ALGN(4) + data
...
 55 ============= ================== =========================
 56 Field name    Field size         Meaning
 57 ============= ================== =========================
...
 70 c_namesize    8 bytes            Length of filename, including final \0

When extracting an initramfs cpio archive, the kernel's do_name() path
handler assumes a zero-terminated path at @collected, passing it
directly to filp_open() / init_mkdir() / init_mknod().

If a specially crafted cpio entry carries a non-zero-terminated filename
and is followed by uninitialized memory, then a file may be created with
trailing characters that represent the uninitialized memory. The ability
to create an initramfs entry would imply already having full control of
the system, so the buffer overrun shouldn't be considered a security
vulnerability.

Append the output of the following bash script to an existing initramfs
and observe any created /initramfs_test_fname_overrunAA* path. E.g.
  ./reproducer.sh | gzip &gt;&gt; /myinitramfs

It's easiest to observe non-zero uninitialized memory when the output is
gzipped, as it'll overflow the heap allocated @out_buf in __gunzip(),
rather than the initrd_start+initrd_size block.

---- reproducer.sh ----
nilchar="A"	# change to "\0" to properly zero terminate / pad
magic="070701"
ino=1
mode=$(( 0100777 ))
uid=0
gid=0
nlink=1
mtime=1
filesize=0
devmajor=0
devminor=1
rdevmajor=0
rdevminor=0
csum=0
fname="initramfs_test_fname_overrun"
namelen=$(( ${#fname} + 1 ))	# plus one to account for terminator

printf "%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s" \
	$magic $ino $mode $uid $gid $nlink $mtime $filesize \
	$devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fname

termpadlen=$(( 1 + ((4 - ((110 + $namelen) &amp; 3)) % 4) ))
printf "%.s${nilchar}" $(seq 1 $termpadlen)
---- reproducer.sh ----

Symlink filename fields handled in do_symlink() won't overrun past the
data segment, due to the explicit zero-termination of the symlink
target.

Fix filename buffer overrun by aborting the initramfs FSM if any cpio
entry doesn't carry a zero-terminator at the expected (name_len - 1)
offset.</Note>
    </Notes>
    <CVE>CVE-2024-53142</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability has been found in the CPython `venv` module and CLI where path names provided when creating a virtual environment were not quoted properly, allowing the creator to inject commands into virtual environment "activation" scripts (ie "source venv/bin/activate"). This means that attacker-controlled virtual environments are able to run commands when the virtual environment is activated. Virtual environments which are not created by an attacker or which aren't activated before being used (ie "./venv/bin/python") are not affected.</Note>
    </Notes>
    <CVE>CVE-2024-9287</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:libpython3_4m1_0-3.4.10-25.145.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:python3-3.4.10-25.145.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:python3-base-3.4.10-25.145.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">When curl is asked to use HSTS, the expiry time for a subdomain might
overwrite a parent domain's cache entry, making it end sooner or later than
otherwise intended.

This affects curl using applications that enable HSTS and use URLs with the
insecure `HTTP://` scheme and perform transfers with hosts like
`x.example.com` as well as `example.com` where the first host is a subdomain
of the second host.

(The HSTS cache either needs to have been populated manually or there needs to
have been previous HTTPS accesses done as the cache needs to have entries for
the domains involved to trigger this problem.)

When `x.example.com` responds with `Strict-Transport-Security:` headers, this
bug can make the subdomain's expiry timeout *bleed over* and get set for the
parent domain `example.com` in curl's HSTS cache.

The result of a triggered bug is that HTTP accesses to `example.com` get
converted to HTTPS for a different period of time than what was asked for by
the origin server. If `example.com` for example stops supporting HTTPS at its
expiry time, curl might then fail to access `http://example.com` until the
(wrongly set) timeout expires. This bug can also expire the parent's entry
*earlier*, thus making curl inadvertently switch back to insecure HTTP earlier
than otherwise intended.</Note>
    </Notes>
    <CVE>CVE-2024-9681</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:curl-8.0.1-11.101.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20250107-x86-64:libcurl4-8.0.1-11.101.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
</cvrfdoc>
