SUSE-IU-2025:809-1 SUSE Image security@suse.de SUSE Security Team SUSE Image SUSE-IU-2025:809-1 Interim 1 1 2025-12-27T13:46:53Z current 2025-03-26T01:00:00Z 2025-03-26T01:00:00Z cve-database/bin/generate-cvrf-publiccloud.pl 2021-02-18T01:00:00Z Image update for SUSE-IU-2025:809-1 / google/sles-12-sp5-byos-v20250326-x86-64 This image update for google/sles-12-sp5-byos-v20250326-x86-64 contains the following changes: Package release-notes-sles was updated: - 12.5.20250211 (tracked in bsc#933411)- Improveed wording (bsc#1233970) - Fixed lifecycle information with proper version - 12.5.20250129 (tracked in bsc#933411) - Fixed lifecycle information (bsc#1236534) Package python-instance-billing-flavor-check was updated: - Update to version 1.0.0 (jsc#PCT-531) + API incompatibility: The check_payg_byos function no longer exits, it now returns a tuple of (flavor, exit_code). This makes the function reusable. + Update the build setup to work with the system interpreter of upcoming SLE releases. SLE 12 stays with the Python 3.4 interpreter and SLE 15 with the Python 3.6 interpreter. - Version 0.1.2 (bsc#1234444) + Improve detection of IPv4 and IPv6 network setup and use appropriate IP version for access the update servers + Improve reliability of flavor detection. Try an update server multiple times to get an answer, if we hit timeouts return the value flavor value from a cache file. - Version 0.1.1 (bsc#1235991, bsc#1235992) + Add time stamp to log - From version 0.1.0 + Doc improvements clarifying exit staus codes Package libX11 was updated: - U_CVE-2025-26597-0001-xkb-Fix-buffer-overflow-in-XkbChangeTypesOfKey.patch * Buffer overflow in XkbChangeTypesOfKey() (CVE-2025-26597, bsc#1237431) Package krb5 was updated: - Prevent overflow when calculating ulog block size. An authenticated attacker can cause kadmind to write beyond the end of the mapped region for the iprop log file, likely causing a process crash; (CVE-2025-24528); (bsc#1236619). - Add patch 0017-Prevent-overflow-when-calculating-ulog-block-size.patch Package libtasn1 was updated: - Security fix: [bsc#1236878, CVE-2024-12133] * Potential DoS in handling of numerous SEQUENCE OF or SET OF elements * Add libtasn1-CVE-2024-12133.patch Package google-osconfig-agent was updated: - Add patch to fix unexpected memory consumption during token parsing in golang.org/x/oauth2 (bsc#1239197, CVE-2025-22868) * CVE-2025-22868.patch - Add patch to fix vulnerability when creating log files * CVE-2024-45339.patch (bsc#1236560, CVE-2024-45339) - Update to version 20250115.01 (bsc#1236406, bsc#1236407) * Bump cloud.google.com/go/osconfig from 1.14.2 to 1.14.3 (#772) - from version 20250115.00 * Bump cloud.google.com/go/auth from 0.10.2 to 0.14.0 (#767) * Bump go.opentelemetry.io/otel from 1.32.0 to 1.33.0 (#771) * Bump google.golang.org/protobuf from 1.35.1 to 1.36.2 (#763) - from version 20250114.00 * Bump golang.org/x/time from 0.8.0 to 0.9.0 (#770) - from version 20250113.01 * Bump cloud.google.com/go/auth/oauth2adapt from 0.2.5 to 0.2.7 (#766) - from version 20250113.00 * Bump golang.org/x/net from 0.31.0 to 0.34.0 (#769) - from version 20250110.00 * Bump golang.org/x/crypto from 0.29.0 to 0.31.0 in the go_modules group (#760) * Bump cloud.google.com/go/longrunning from 0.6.2 to 0.6.3 (#744) - from version 20241218.00 * Scanners fixes (#720) * Bump cloud.google.com/go/storage from 1.46.0 to 1.47.0 (#736) * Bump go.opentelemetry.io/contrib/detectors/gcp from 1.29.0 to 1.32.0 (#730) * Bump go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp (#738) * Bump golang.org/x/net from 0.30.0 to 0.31.0 (#731) - from version 20241118.01 * Bump github.com/googleapis/gax-go/v2 from 2.13.0 to 2.14.0 (#737) - from version 20241118.00 * move example to appropriate directory (#740) - from version 20241115.00 * Replace sles-15-sp3-sap old deprecated image in e2e tests (#739) * Bump golang.org/x/time from 0.7.0 to 0.8.0 (#734) - from version 20241114.03 * Bump github.com/GoogleCloudPlatform/opentelemetry-operations-go/detectors/gcp (#735) - from version 20241114.02 * Bump go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc (#729) - from version 20241114.01 * Remove SLES-15-SP2-SAP from e2e tests and add the new SLES-15-SP6 (#733) * Bump golang.org/x/crypto from 0.28.0 to 0.29.0 (#728) * Bump go.opentelemetry.io/otel/sdk/metric from 1.30.0 to 1.32.0 (#727) - from version 20241114.00 * Add example to run exec script from the gcs bucket (#732) * Bump cel.dev/expr from 0.16.1 to 0.18.0 (#723) - from version 20241112.00 * Bump golang.org/x/oauth2 from 0.23.0 to 0.24.0 (#722) * Bump github.com/GoogleCloudPlatform/opentelemetry-operations-go/exporter/metric (#721) * Bump google.golang.org/grpc from 1.67.1 to 1.68.0 (#725) * Bump github.com/golang/glog from 1.2.2 to 1.2.3 (#715) * Bump google.golang.org/api from 0.203.0 to 0.205.0 (#716) - from version 20241107.01 * Bump github.com/envoyproxy/go-control-plane from 0.13.0 to 0.13.1 (#717) * Bump github.com/GoogleCloudPlatform/opentelemetry-operations-go/internal/resourcemapping (#718) * Bump cloud.google.com/go/auth from 0.10.0 to 0.10.1 (#719) - from version 20241107.00 * Bump cloud.google.com/go/logging from 1.11.0 to 1.12.0 (#709) * Bump cloud.google.com/go/iam from 1.2.1 to 1.2.2 (#710) * Bump cloud.google.com/go/storage from 1.43.0 to 1.46.0 (#713) * Bump cloud.google.com/go/osconfig from 1.14.1 to 1.14.2 (#708) * Bump cloud.google.com/go/auth/oauth2adapt from 0.2.4 to 0.2.5 (#712) - from version 20241106.00 * Update OWNERS (#714) - from version 20241029.01 * remove toolchain override (#706) * Bump go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp (#701) - from version 20241029.00 * Bump go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc (#702) - from version 20241028.00 * Bump cloud.google.com/go/longrunning from 0.6.0 to 0.6.2 (#705) - from version 20241017.00 * Add a new CloudBuild trigger config-file for auto updating the presubmit test container image on every new commit (#704) - from version 20241004.00 * Add new packagebuild presubmit that will use cloud-build (#694) - from version 20240927.00 * Third batch of dependencies upgrade (#690) - Bump the golang compiler version to 1.22.4 (bsc#1225974, CVE-2024-24790) Package grub2 was updated: - Fix zfs.mo not found message when booting on legacy BIOS (bsc#1237865) * 0001-autofs-Ignore-zfs-not-found.patch - Security fixes for 2024 * 0001-misc-Implement-grub_strlcpy.patch - Fix CVE-2024-45781 (bsc#1233617) * 0002-fs-ufs-Fix-a-heap-OOB-write.patch - Fix CVE-2024-56737 (bsc#1234958) - Fix CVE-2024-45782 (bsc#1233615) * 0003-fs-hfs-Fix-stack-OOB-write-with-grub_strcpy.patch - Fix CVE-2024-45780 (bsc#1233614) * 0004-fs-tar-Integer-overflow-leads-to-heap-OOB-write.patch - Fix CVE-2024-45783 (bsc#1233616) * 0005-fs-hfsplus-Set-a-grub_errno-if-mount-fails.patch * 0006-kern-file-Ensure-file-data-is-set.patch * 0007-kern-file-Implement-filesystem-reference-counting.patch - Fix CVE-2025-0624 (bsc#1236316) * 0008-net-Fix-OOB-write-in-grub_net_search_config_file.patch - Fix CVE-2024-45774 (bsc#1233609) * 0009-video-readers-jpeg-Do-not-permit-duplicate-SOF0-mark.patch - Fix CVE-2024-45775 (bsc#1233610) * 0010-commands-extcmd-Missing-check-for-failed-allocation.patch - Fix CVE-2025-0622 (bsc#1236317) * 0011-commands-pgp-Unregister-the-check_signatures-hooks-o.patch - Fix CVE-2025-0622 (bsc#1236317) * 0012-normal-Remove-variables-hooks-on-module-unload.patch - Fix CVE-2025-0622 (bsc#1236317) * 0013-gettext-Remove-variables-hooks-on-module-unload.patch - Fix CVE-2024-45776 (bsc#1233612) * 0014-gettext-Integer-overflow-leads-to-heap-OOB-write-or-.patch - Fix CVE-2024-45777 (bsc#1233613) * 0015-gettext-Integer-overflow-leads-to-heap-OOB-write.patch - Fix CVE-2025-0690 (bsc#1237012) * 0016-commands-read-Fix-an-integer-overflow-when-supplying.patch - Fix CVE-2025-1118 (bsc#1237013) * 0017-commands-minicmd-Block-the-dump-command-in-lockdown-.patch - Fix CVE-2024-45778 (bsc#1233606) - Fix CVE-2024-45779 (bsc#1233608) * 0018-fs-bfs-Disable-under-lockdown.patch - Fix CVE-2025-0677 (bsc#1237002) - Fix CVE-2025-0684 (bsc#1237008) - Fix CVE-2025-0685 (bsc#1237009) - Fix CVE-2025-0686 (bsc#1237010) - Fix CVE-2025-0689 (bsc#1237011) * 0019-fs-Disable-many-filesystems-under-lockdown.patch - Fix CVE-2025-1125 (bsc#1237014) - Fix CVE-2025-0678 (bsc#1237006) * 0020-fs-Prevent-overflows-when-allocating-memory-for-arra.patch - Bump upstream SBAT generation to 5 Package vim was updated: - 9.1.1101 is a fix for: bsc#1229685 (CVE-2024-43790) bsc#1229822 (CVE-2024-43802) bsc#1230078 (CVE-2024-45306) bsc#1235695 (CVE-2025-22134) bsc#1236151 (CVE-2025-24014) bsc#1237137 (CVE-2025-1215) - Remove obsoleted patch: * vim-7.3-mktemp_tutor.patch - update to 9.1.1101 * insexpand.c hard to read * tests: Test_log_nonexistent only works on Linux * Update base-syntax, improve variable matching * Vim9: import with extends may crash * leaking memory with completing multi lines * --log with non-existent path causes a crash * if_perl: Perl 5.38 adds new symbols causing link failure * tests: matchparen plugin test wrongly named * Vim9: problem finding implemented method in type hierarchy * runtime(qf): Update syntax file, match second delimiter * tests: output of test ...win32_ctrl_z depends on python version * tests: fix expected return code for python 3.13 on Windows * tests: timeout might be a bit too small * tests: test_terminwscroll_topline2 unreliable * tests: No check when tests are run under Github actions * tests: plugin tests are named inconsistently * Vim9: import with extends may crash * completion doesn't work with multi lines * filetype: cmmt files are not recognized * Unable to persistently ignore events in a window and its buffers * improve syntax highlighting * setreg() doesn't correctly handle mbyte chars in blockwise mode * unexpected DCS responses may cause out of bounds reads * has('bsd') is true for GNU/Hurd * filetype: Mill files are not recognized * GUI late startup leads to uninitialized scrollbars * Add support for lz4 to tar &amp; gzip plugin * Terminal ansi colors off by one after tgc reset * included syntax items do not understand contains=TOP * vim_strnchr() is strange and unnecessary * Vim9: len variable not used in compile_load() * runtime(vim): Update base-syntax, match :debuggreedy count prefix * Strange error when heredoc marker starts with &quot;trim&quot; * tests: test_compiler fails on Windows without Maven * 'diffopt' &quot;linematch&quot; cannot be used with {n} less than 10 * args missing after failing to redefine a function * Cannot control cursor positioning of getchar() * preinsert text completions not deleted with &lt;C-W&gt;/&lt;C-U&gt; * getchar() can't distinguish between C-I and Tab * tests: Test_termwinscroll_topline2 fails on MacOS * heap-use-after-free and stack-use-after-scope with :14verbose * no digraph for &quot;Approaches the limit&quot; * not possible to use plural forms with gettext() * too many strlen() calls in userfunc.c * terminal: E315 when dragging the terminal with the mouse * runtime(openPlugin): fix unclosed parenthesis in GetWordUnderCursor() * runtime(doc): Tweak documentation style a bit * tests: test_glvs fails when unarchiver not available * Vim always enables 'termguicolors' in a terminal * completion: input text deleted with preinsert when adding leader * translation(sr): Missing Serbian translation for the tutor * Superfluous cleanup steps in test_ins_complete.vim * runtime(netrw): correct wrong version check * Vim doesn't highlight to be inserted text when completing * runtime(netrw): upstream snapshot of v176 * runtime(dist/vim9): fix regressions in dist#vim9#Open * runtime(hyprlang): fix string recognition * make install fails because of a missing dependency * runtime(asm): add byte directives to syntax script * Vim doesn't work well with TERM=xterm-direct * runtime(filetype): commit 99181205c5f8284a3 breaks V lang detection * runtime: decouple Open and Launch commands and gx mapping from netrw * &quot;nosort&quot; enables fuzzy filtering even if &quot;fuzzy&quot; isn't in 'completeopt' * runtime(just): fix typo in syntax file * runtime(filetype): Improve Verilog detection by checking for modules definition * tests: off-by-one error in CheckCWD in test_debugger.vim * tests: no support for env variables when running Vim in terminal * too many strlen() calls in os_unix.c * insert-completed items are always sorted * crash after scrolling and pasting in silent Ex mode * Makefiles uses non-portable syntax * fuzzymatching doesn't prefer matching camelcase * filetype: N-Tripels and TriG files are not recognized * Vim9: Patch 9.1.1014 causes regressions * translation(sr): Update Serbian messages translation - updade to 9.1.1043 * [security]: segfault in win_line() * update helptags * filetype: just files are not recognized * Update base-syntax, match ternary and falsy operators * Vim9: out-of-bound access when echoing an enum * Vim9: imported type cannot be used as func return type * runtime(kconfig): updated ftplugin and syntax script * runtime(doc): rename last t_BG reference to t_RB * Vim9: comments are outdated * tests: test_channel.py fails with IPv6 * runtime(vim): Update base-syntax, fix is/isnot operator matching * Vim9: confusing error when using abstract method via super * make install fails when using shadowdir * Vim9: memory leak with blob2str() * runtime(tex): add texEmphStyle to texMatchGroup in syntax script * runtime(netrw): upstream snapshot of v175 * Vim9: compiling abstract method fails without return * runtime(c): add new constexpr keyword to syntax file (C23) * tests: shaderslang was removed from test_filetype erroneously * link error when FEAT_SPELL not defined * Coverity complains about insecure data handling * runtime(sh): update syntax script * runtime(c): Add missing syntax test files * filetype: setting bash filetype is backwards incompatible * runtime(c): Update syntax and ftplugin files * the installer can be improved * too many strlen() calls in screen.c * no sanitize check when running linematch * filetype: swc configuration files are not recognized * runtime(netrw): change netrw maintainer * wrong return type of blob2str() * blob2str/str2blob() do not support list of strings * runtime(doc): fix typo in usr_02.txt * Coverity complains about dereferencing NULL pointer * linematch option value not completed * string might be used without a trailing NUL * no way to get current selected item in a async context * filetype: fd ignore files are not recognized * v9.1.0743 causes regression with diff mode * runtime(doc): fix base64 encode/decode examples * Vim9: Patch 9.1.1013 causes a few problems * Not possible to convert string2blob and blob2string * Coverity complains about dereferencing NULL value * Vim9: variable not found in transitive import * runtime(colors): Update colorschemes, include new unokai colorscheme * Vim9: Regression caused by patch v9.1.0646 * runtime(lyrics): support milliseconds in syntax script * runtime(vim): Split Vim legacy and Vim9 script indent tests * Vim9: class interface inheritance not correctly working * popupmenu internal error with some abbr in completion item * filetype: VisualCode setting file not recognized * diff feature can be improved * tests: test for patch 9.1.1006 doesn't fail without the patch * filetype: various ignore are not recognized * tests: Load screendump files with &quot;git vimdumps&quot; * PmenuMatch completion highlight can be combined * completion text is highlighted even with no pattern found * tests: a few termdebug tests are flaky * [security]: heap-buffer-overflow with visual mode * runtime(doc): add package-&lt;name&gt; helptags for included packages * Vim9: unknown func error with interface declaring func var * runtime(filetype): don't detect string interpolation as angular * ComplMatchIns highlight hard to read on light background * runtime(vim): Update base-syntax, highlight literal string quote escape * runtime(editorconfig): set omnifunc to syntaxcomplete func * tests: ruby tests fail with Ruby 3.4 * Vim9: leaking finished exception * runtime(tiasm): use correct syntax name tiasm in syntax script * filetype: TI assembly files are not recognized * too many strlen() calls in drawscreen.c * runtime(xf86conf): add section name OutputClass to syntax script * ComplMatchIns may highlight wrong text * runtime(vim): Update base-syntax, improve ex-bang matching * runtime(doc): clarify buffer deletion on popup_close() * filetype: shaderslang files are not detected * Vim9: not able to use comment after opening curly brace - update to 9.1.0993 * 9.1.0993: New 'cmdheight' behavior may be surprising * runtime(sh): fix typo in Last Change header * 9.1.0992: Vim9: double-free after v9.1.0988 * 9.1.0991: v:stacktrace has wrong type in Vim9 script * runtime(sh): add PS0 to bashSpecialVariables in syntax script * runtime(vim): Remove trailing comma from match_words * runtime(zsh): sync syntax script with upstream repo * runtime(doc): Capitalise the mnemonic &quot;Zero&quot; for the 'z' flag of search() * 9.1.0990: Inconsistent behavior when changing cmdheight * 9.1.0989: Vim9: Whitespace after the final enum value causes a syntax error * runtime(java): Quietly opt out for unsupported markdown.vim versions * runtime(vim): fix failing vim syntax test * 9.1.0988: Vim9: no error when using uninitialized var in new() * runtime(doc): update index.txt * 9.1.0987: filetype: cake files are not recognized * 9.1.0986: filetype: 'jj' filetype is a bit imprecise * runtime(jj): Support diffs in jj syntax * runtime(vim): Update matchit pattern, no Vim9 short names * 9.1.0985: Vim9: some ex commands can be shortened * 9.1.0984: exception handling can be improved * runtime(doc): update doc for :horizontal * runtime(doc): update index.txt, windows.txt and version9.txt * runtime(doc): Tweak documentation about base64 function * runtime(chordpro): update syntax script * 9.1.0983: not able to get the displayed items in complete_info() * runtime(doc): use standard SGR format at :h xterm-true-color * 9.1.0982: TI linker files are not recognized * runtime(vim): update vim generator syntax script * 9.1.0981: tests: typo in test_filetype.vim * 9.1.0980: no support for base64 en-/decoding functions in Vim Script * syntax(sh): Improve the recognition of bracket expressions * runtime(doc): mention how NUL bytes are handled * 9.1.0979: VMS: type warning with $XDG_VIMRC_FILE * 9.1.0978: GUI tests sometimes fail when setting 'scroll' options * 9.1.0977: filetype: msbuild filetypes are not recognized * 9.1.0976: Vim9: missing return statement with throw * 9.1.0975: Vim9: interpolated string expr not working in object methods * 9.1.0974: typo in change of commit v9.1.0873 * 9.1.0973: too many strlen() calls in fileio.c * runtime(sh): set shellcheck as the compiler for supported shells * runtime(doc): Fix enum example syntax * 9.1.0972: filetype: TI linker map files are not recognized * runtime(vim): Improve syntax script generator for Vim Script * 9.1.0971: filetype: SLNX files are not recognized * 9.1.0970: VMS: build errors on VMS architecture * runtime(doc): Fix documentation typos * runtime(doc): update for new keyprotocol option value (after v9.1.0969) * 9.1.0969: ghostty not using kitty protocol by default * 9.1.0968: tests: GetFileNameChecks() isn't fully sorted by filetype name * runtime(doc): update version9.txt for bash filetype * runtime(netrw): update last change header for #16265 * runtime(doc): fix doc error in :r behaviour * 9.1.0967: SpotBugs compiler setup can be further improved * 9.1.0966: Vim9: :enum command can be shortened * runtime(compiler): include a basic bash syntax checker compiler * 9.1.0965: filetype: sh filetype set when detecting the use of bash * runtime(doc): clarify ARCH value for 32-bit in INSTALLpc.txt * 9.1.0963: fuzzy-matching does not prefer full match * 9.1.0962: filetype: bun.lock file is not recognized * runtime(vim): update indentation plugin for Vim script * runtime(doc): tweak documentation style in helphelp.txt * runtime(vim): Update base-syntax, allow parens in default arguments * runtime(doc): mention auto-format using clang-format for sound.c/sign.c * runtime(help): fix typo s/additional/arbitrary/ * runtime(help): Add better support for language annotation highlighting * 9.1.0961: filetype: TI gel files are not recognized * 9.1.0960: filetype: hy history files are not recognized * translation(fi): Fix typoes in Finish menu translation * 9.1.0959: Coverity complains about type conversion * runtime(vim): Use supported syntax in indent tests * 9.1.0958: filetype: supertux2 config files detected as lisp * 9.1.0956: completion may crash, completion highlight wrong with preview window * 9.1.0955: Vim9: vim9compile.c can be further improved * runtime(doc): move help tag E1182 * runtime(graphql): contribute vim-graphql to Vim core * 9.1.0954: popupmenu.c can be improved * 9.1.0953: filetype: APKBUILD files not correctly detected * 9.1.0952: Vim9: missing type checking for any type assignment * 9.1.0951: filetype: jshell files are not recognized * runtime(dockerfile): do not set commentstring in syntax script * 9.1.0950: filetype: fennelrc files are not recognized * runtime(netrw): do not double escape Vim special characters * git: ignore reformatting change of netrw plugin * runtime(netrw): more reformating #16248 * runtime(doc): Add a note about handling symbolic links in starting.txt * 9.1.0949: popups inconsistently shifted to the left * git: ignore reformatting change of netrw plugin * runtime(netrw): change indent size from 1 to 2 * 9.1.0948: Missing cmdline completion for :pbuffer * runtime(tutor): Reformat tutor1 * 9.1.0947: short-description * 9.1.0946: cross-compiling fails on osx-arm64 * 9.1.0945: ComplMatchIns highlight doesn't end after inserted text * translation(sv): re-include the change from #16240 * 9.1.0944: tests: test_registers fails when not run under X11 * 9.1.0943: Vim9: vim9compile.c can be further improved * runtime(doc): Update README and mention make check to verify * translation(sv): partly revert commit 98874dca6d0b60ccd6fc3a140b3ec * runtime(vim): update base-syntax after v9.1.0936 * 9.1.0942: a few typos were found * 9.1.0941: ComplMatchIns doesn't work after multibyte chars * runtime(doc): Fix style in fold.txt * translation(sv): Fix typo in Swedish translation * 9.1.0940: Wrong cursor shape with &quot;gq&quot; and 'indentexpr' executes :normal * runtime(doc): fix some small errors * 9.1.0939: make installtutor fails * 9.1.0938: exclusive selection not respected when re-selecting block mode * 9.1.0937: test_undolist() is flaky * 9.1.0936: cannot highlight completed text * 9.1.0935: SpotBugs compiler can be improved * 9.1.0934: hard to view an existing buffer in the preview window * runtime(doc): document how to minimize fold computation costs * 9.1.0933: Vim9: vim9compile.c can be further improved * 9.1.0932: new Italian tutor not installed * runtime(doc): fix a few minor errors from the last doc updates * translation(it): add Italian translation for the interactive tutor * runtime(doc): update the change.txt help file * runtime(help): Add Vim lang annotation support for codeblocks * 9.1.0931: ml_get error in terminal buffer * 9.1.0930: tests: test_terminal2 may hang in GUI mode * 9.1.0929: filetype: lalrpop files are not recognized * 9.1.0928: tests: test_popupwin fails because the filter command fails * editorconfig: set trim_trailing_whitespace = false for src/testdir/test*.vim * 9.1.0927: style issues in insexpand.c * 9.1.0926: filetype: Pixi lock files are not recognized * runtime(doc): Add a reference to |++opt| and |+cmd| at `:h :pedit` * runtime(doc): add a note about inclusive motions and exclusive selection * 9.1.0925: Vim9: expression compiled when not necessary * 9.1.0924: patch 9.1.0923 causes issues * 9.1.0923: too many strlen() calls in filepath.c * 9.1.0923: wrong MIN macro in popupmenu.c * 9.1.0921: popupmenu logic is a bit convoluted * 9.1.0920: Vim9: compile_assignment() too long * 9.1.0919: filetype: some assembler files are not recognized * runtime(netrw): do not pollute search history with symlinks * 9.1.0918: tiny Vim crashes with fuzzy buffer completion * 9.1.0917: various vartabstop and shiftround bugs when shifting lines * runtime(typst): add definition lists to formatlistpat, update maintainer * 9.1.0916: messages.c is exceeding 80 columns * runtime(proto): include filetype plugin for protobuf * 9.1.0915: GVim: default font size a bit too small * 9.1.0914: Vim9: compile_assignment() is too long * 9.1.0913: no error check for neg values for 'messagesopt' * runtime(netrw): only check first arg of netrw_browsex_viewer for being executable * 9.1.0912: xxd: integer overflow with sparse files and -autoskip * 9.1.0911: Variable name for 'messagesopt' doesn't match short name * 9.1.0910: 'messagesopt' does not check max wait time * runtime(doc): update wrong Vietnamese localization tag * 9.1.0909: Vim9: crash when calling instance method - update to 9.1.0908 * refresh vim-7.3-mktemp_tutor.patch * 9.1.0908: not possible to configure :messages * 9.1.0907: printoptions:portrait does not change postscript Orientation * runtime(doc): Add vietnamese.txt to helps main TOC * 9.1.0906: filetype: Nvidia PTX files are not recognized * runtime(doc): updated version9.txt with changes from v9.1.0905 * 9.1.0905: Missing information in CompleteDone event * 9.1.0904: Vim9: copy-paste error in class_defining_member() * 9.1.0903: potential overflow in spell_soundfold_wsal() * runtime(netrw): do not detach when launching external programs in gvim * runtime(doc): make tag alignment more consistent in filetype.txt * runtime(doc): fix wrong syntax and style of vietnamese.txt * translation(it): update Italian manpage for vimtutor * runtime(lua): add optional lua function folding * Filelist: include translations for Chapter 2 tutor * translation(vi): Update Vietnamese translation * runtime(doc): include vietnamese.txt * runtime(tutor): fix another typo in tutor2 * runtime(doc): fix typo in vimtutor manpage * translation(it): update Italian manpage for vimtutor * translation(it): include Italian version of tutor chapter 2 * runtime(tutor): regenerated some translated tutor1 files * runtime(tutor): fix typo in Chapter 2 * 9.1.0902: filetype: Conda configuration files are not recognized * runtime(doc): Tweak documentation style a bit * runtime(tutor): update the tutor files and re-number the chapters * runtime(tutor): Update the makefiles for tutor1 and tutor2 files * 9.1.0901: MS-Windows: vimtutor batch script can be improved * runtime(doc): remove buffer-local completeopt todo item * 9.1.0900: Vim9: digraph_getlist() does not accept bool arg * runtime(typst): provide a formatlistpat in ftplugin * runtime(doc): Update documentation for &quot;noselect&quot; in 'completeopt' * 9.1.0899: default for 'backspace' can be set in C code * runtime(helptoc): reload cached g:helptoc.shell_prompt when starting toc * translation(ru): Updated messages translation * 9.1.0898: runtime(compiler): pytest compiler not included * 9.1.0897: filetype: pyrex files are not detected * runtime(compiler): update eslint compiler * 9.1.0896: completion list wrong after v9.1.0891 * runtime(doc): document changed default value for 'history' * 9.1.0895: default history value is too small * 9.1.0894: No test for what the spotbug compiler parses * 9.1.0893: No test that undofile format does not regress * translation(de): update German manpages * runtime(compiler): include spotbugs Java linter * 9.1.0892: the max value of 'tabheight' is limited by other tabpages * runtime(po): remove poDiffOld/New, add po-format flags to syntax file * 9.1.0891: building the completion list array is inefficient * patch 9.1.0890: %! item not allowed for 'rulerformat' * runtime(gzip): load undofile if there exists one * 9.1.0889: Possible unnecessary redraw after adding/deleting lines * 9.1.0888: leftcol property not available in getwininfo() * 9.1.0887: Wrong expression in sign.c * 9.1.0886: filetype: debian control file not detected * runtime(c3): include c3 filetype plugin * 9.1.0885: style of sign.c can be improved * 9.1.0884: gcc warns about uninitialized variable * runtime(apache): Update syntax directives for apache server 2.4.62 * translation(ru): updated vimtutor translation, update MAINTAINERS file * 9.1.0883: message history cleanup is missing some tests * runtime(doc): Expand docs on :! vs. :term * runtime(netrw): Fixing powershell execution issues on Windows * 9.1.0882: too many strlen() calls in insexpand.c * 9.1.0881: GUI: message dialog may not get focus * runtime(netrw): update netrw's decompress logic * runtime(apache): Update syntax keyword definition * runtime(misc): add Italian LICENSE and (top-level) README file * 9.1.0880: filetype: C3 files are not recognized * runtime(doc): add helptag for :HelpToc command * 9.1.0879: source is not consistently formatted * Add clang-format config file * runtime(compiler): fix escaping of arguments passed to :CompilerSet * 9.1.0878: termdebug: cannot enable DEBUG mode * 9.1.0877: tests: missing test for termdebug + decimal signs * 9.1.0876: filetype: openCL files are not recognized * 9.1.0875: filetype: hyprlang detection can be improved * 9.1.0874: filetype: karel files are not detected * 9.1.0873: filetype: Vivado files are not recognized * 9.1.0872: No test for W23 message * 9.1.0871: getcellpixels() can be further improved * 9.1.0870: too many strlen() calls in eval.c * 9.1.0869: Problem: curswant not set on gm in folded line * 9.1.0868: the warning about missing clipboard can be improved * runtime(doc): Makefile does not clean up all temporary files * 9.1.0867: ins_compl_add() has too many args * editorconfig: don't trim trailing whitespaces in runtime/doc * translation(am): Remove duplicate keys in desktop files * runtime(doc): update helptags * runtime(filetype): remove duplicated *.org file pattern * runtime(cfg): only consider leading // as starting a comment * 9.1.0866: filetype: LLVM IR files are not recognized * 9.1.0865: filetype: org files are not recognized * 9.1.0864: message history is fixed to 200 * 9.1.0863: getcellpixels() can be further improved * runtime(sh): better function support for bash/zsh in indent script * runtime(netrw): small fixes to netrw#BrowseX * 9.1.0862: 'wildmenu' not enabled by default in nocp mode * runtime(doc): update how to report issues for mac Vim * runtime(doc): mention option-backslash at :h CompilerSet * runtime(compiler): include a Java Maven compiler plugin * runtime(racket): update Racket runtime files * runtime(doc): improve indentation in examples for netrw-handler * runtime(doc): improve examples for netrw-handler functions * runtime(idris2): include filetype,indent+syntax plugins for (L)Idris2 + ipkg * runtime(doc): clarify the use of filters and external commands * 9.1.0861: Vim9: no runtime check for object member access of any var * runtime(compiler): update pylint linter * 9.1.0860: tests: mouse_shape tests use hard code sleep value * 9.1.0859: several problems with the GLVS plugin * 9.1.0858: Coverity complains about dead code * runtime(tar): Update tar.vim to support permissions * 9.1.0857: xxd: --- is incorrectly recognized as end-of-options * 9.1.0851: too many strlen() calls in getchar.c * 9.1.0850: Vim9: cannot access nested object inside objects * runtime(tex): extra Number highlighting causes issues * runtime(vim): Fix indent after :silent! function * 9.1.0849: there are a few typos in the source * runtime(netrw): directory symlink not resolved in tree view * runtime(doc): add a table of supported Operating Systems * runtime(tex): update Last Change header in syntax script * runtime(doc): fix typo in g:termdebug_config * runtime(vim): Update base-syntax, improve :normal highlighting * runtime(tex): add Number highlighting to syntax file * runtime(doc): Tweak documentation style a bit * 9.1.0848: if_lua: v:false/v:true are not evaluated to boolean * runtime(dune): use :setl instead of :set in ftplugin * runtime(termdebug): allow to use decimal signs * translation(it): Updated Italian vimtutor * runtime(compiler): improve cppcheck * git: git-blame-ignore-revs shown as an error on Github * 9.1.0847: tests: test_popupwin fails because of updated help file * 9.1.0846: debug symbols for xxd are not cleaned in Makefile * runtime(structurizr): Update structurizr syntax * runtime(8th): updated 8th syntax * runtime(doc): Add pi_tutor.txt to help TOC * runtime(compiler): add mypy and ruff compiler; update pylint linter * runtime(netrw): fix several bugs in netrw tree listing * runtime(netrw): prevent polluting the search history * 9.1.0845: vimtutor shell script can be improved * 9.1.0844: if_python: no way to pass local vars to python * 9.1.0843: too many strlen() calls in undo.c * runtime(doc): update default value for fillchars option * runtime(compiler): fix typo in cppcheck compiler plugin * runtime(doc): simplify vimtutor manpage a bit more * runtime(matchparen): Add matchparen_disable_cursor_hl config option * 9.1.0842: not checking for the sync() systemcall * 9.1.0841: tests: still preferring python2 over python3 * 9.1.0840: filetype: idris2 files are not recognized * 9.1.0839: filetype: leo files are not recognized * runtime(cook): include cook filetype plugin * runtime(debversions): Update Debian versions * patch 9.1.0838: vimtutor is bash-specific * runtime(doc): add help specific modeline to pi_tutor.txt * Filelist: vimtutor chapter 2 is missing in Filelist * 9.1.0837: cross-compiling has some issues * runtime(vimtutor): Add a second chapter Package procps was updated: - Add patch CVE-2023-4016-part2.patch * Fix the ps command segfaults when pid argument has a leading space (bsc#1236842) Package freetype2 was updated: - Added patch: * CVE-2025-27363.patch + fixes bsc#1239465, CVE-2025-27363: out-of-bounds write when attempting to parse font subglyph structures related to TrueType GX and variable font files Package python3 was updated: - Add CVE-2025-0938-sq-brackets-domain-names.patch which disallows square brackets ([ and ]) in domain names for parsed URLs (bsc#1236705, CVE-2025-0938, gh#python/cpython#105704) Package nfsidmap was updated: - nss: use strrchr() instead of strchr() to get the last occurrence of &quot;@&quot; (bsc#1236077) - add 0003-nss-use-strrchr-instead-of-strchr-to-get-the-last-oc.patch Package python36 was updated: - Add CVE-2025-0938-sq-brackets-domain-names.patch which disallows square brackets ([ and ]) in domain names for parsed URLs (bsc#1236705, CVE-2025-0938, gh#python/cpython#105704) Package google-guest-oslogin was updated: - Rework SELinux support (bsc#1232553) * Add pkgconfig(systemd) to BuildRequires for SELinux builds * Add policycoreutils to BuildRequires * Build and install SELinux module on older distributions as well to allow users to use the module with their own SELinux policies * Make checkpolicy build dependency unconditional * Move oslogin.pp SELinux module into %{selinuxtype} subdirectory * Own %{_datadir}/selinux{,/packages} on older distributions * Split SELinux support into separate -selinux package * Use SELinux RPM macros to install and uninstall SELinux module * Use RPM conditional builds to enable SELinux on newer distributions - Build and install SELinux module (bsc#1232553) Package python3-base was updated: - Add CVE-2025-0938-sq-brackets-domain-names.patch which disallows square brackets ([ and ]) in domain names for parsed URLs (bsc#1236705, CVE-2025-0938, gh#python/cpython#105704) Package python-base was updated: - Update CVE-2024-11168-validation-IPv6-addrs.patch according modifications by the Debian developers (Sylvain Beucler &lt;beuc@debian.org&gt;, gh#python/cpython#103848#issuecomment-2708135083). - Modify CVE-2025-0938-sq-brackets-domain-names.patch: we don't use bracketed_host variable any more (correction of the fix for bsc#1236705, discovered during analysis for bsc#1223694). - Add CVE-2025-0938-sq-brackets-domain-names.patch which disallows square brackets ([ and ]) in domain names for parsed URLs (bsc#1236705, CVE-2025-0938, gh#python/cpython#105704) Package glibc was updated: - assert-message-allocation.patch: Fix underallocation of abort_msg_s struct (CVE-2025-0395, bsc#1236282, BZ #32582)) - s390x-wcsncmp.patch: s390x: Fix segfault in wcsncmp (bsc#1228044, BZ [#31934]) Package cloud-regionsrv-client was updated: - Update to 10.3.11 (bsc#1234050) + Send registration code for the extensions, not only base product - Update to 10.3.8 (bsc#1233333) + Fix the package requirements for cloud-regionsrv-client + Follow changes to suseconnect error reporting from stdout to stderr Package mozilla-nss was updated: - Updated nss-fips-approved-crypto-non-ec.patch to not pass in bad targetKeyLength parameters when checking for FIPS approval after keygen. This was causing false rejections. - Updated nss-fips-approved-crypto-non-ec.patch to approve RSA signature verification mechanisms with PKCS padding and legacy moduli (bsc#1222834). Package openssh was updated: - Backported patch to fix a MitM attack against OpenSSH's VerifyHostKeyDNS-enabled client (bsc#1237040, CVE-2025-26465): * fix-CVE-2025-26465.patch - write active/enabled switch over files only if not yet present (bsc#1220110) - Add patch backported from upstream to add a s390 specific ioctl for ecc hardware support (bsc#1225637): * openssh-7.2p2-allow-s390-specific-ioctl-for-ecc-hardware-support.patch Package bind was updated: - Limit additional section processing for large RDATA sets. When answering queries, don’t add data to the additional section if the answer has more than 13 names in the RDATA. This limits the number of lookups into the database(s) during a single client query, reducing the query-processing load. (CVE-2024-11187) [bsc#1236596, bind-9.11-CVE-2024-11187.patch] Package rsync was updated: - Fix bsc#1237187 - rsync daemon mode after protocol bump * Add greeting line with available digests * Add rsync-fix-daemon-proto-32.patch - Bump protocl version to 32 - make it easier to show server is patched. * Add rsync-protocol-version-32.patch - Fix FLAG_GOT_DIR_FLIST collission with FLAG_HLINKED * Added rsync-fix-FLAG_GOT_DIR_FLIST.patch - Security update,CVE-2024-12747, bsc#1235475 race condition in handling symbolic links * Added rsync-CVE-2024-12747.patch - Security update, fix multiple vulnerabilities: * CVE-2024-12085, bsc#1234101 - Info Leak via uninitialized Stack contents defeats ASLR * CVE-2024-12086, bsc#1234102 - Server leaks arbitrary client files * CVE-2024-12087, bsc#1234103 - Server can make client write files outside of destination directory using symbolic links * CVE-2024-12088, bsc#1234104 - --safe-links Bypass * Added rsync-CVE-2024-12085.patch * Added rsync-CVE-2024-12086_01.patch * Added rsync-CVE-2024-12086_02.patch * Added rsync-CVE-2024-12086_03.patch * Added rsync-CVE-2024-12086_04.patch * Added rsync-CVE-2024-12087_01.patch * Added rsync-CVE-2024-12087_02.patch * Added rsync-CVE-2024-12088.patch * Added rsync-fix-compilation-do_malloc_fixes.patch Package gnutls was updated: - Security fix [bsc#1236974, CVE-2024-12243] * gnutls: inefficient DER Decoding in libtasn1 could lead to remote DoS * Add gnutls-x509-optimize-alt-name-access.patch * Add gnutls-CVE-2024-12243.patch Package google-guest-configs was updated: - Add ggc-no-dup-metasrv-entry.patch + Follow up to (bsc#1234289, bsc#1234293). Avoid duplicate entries for the metadata server in /etc/hosts - Update to version 20241205.00 (bsc#1234254, bsc#1234255) * Update google_set_multiqueue to configure vCPU ranges based on VM platform (#90) - from version 20241204.00 * Restore google_set_multiqueue changes for A3Ultra (#93) * Depend on networkd-dispatcher in Ubuntu (#94) - Include components to set hostname and /etc/hosts entries (bsc#1234289, bsc#1234293) * Add sysconfig and sysconfig-network to BuildRequires * Install google_set_hostname into %{_bindir} * Install google_up.sh into %{_sysconfdir}/sysconfig/network/scripts/ * Add code to add and remove POST_UP_SCRIPT=&quot;compat:suse:google_up.sh&quot; to /etc/sysconfig/network/ifcfg-eth0 in %post and %postun sections Package timezone was updated: - Update to 2025a: * Paraguay adopts permanent -03 starting spring 2024 * Improve pre-1991 data for the Philippines * Etc/Unknown is now reserved - Update to 2024b: * Improve historical data for Mexico, Mongolia, and Portugal. * System V names are now obsolescent. * The main data form now uses %z. * The code now conforms to RFC 8536 for early timestamps. * Support POSIX.1-2024, which removes asctime_r and ctime_r. * Assume POSIX.2-1992 or later for shell scripts. * SUPPORT_C89 now defaults to 1. - Add revert-philippines-historical-data.patch, revert-systemv-deprecation.patch * Fixes testsuite failures for other packages Package openssl-1_1 was updated: - Security fix: [bsc#1236136, CVE-2024-13176] * timing side-channel in the ECDSA signature computation * Add openssl-CVE-2024-13176.patch Package kernel-default was updated: - mailbox: bcm2835: Fix timeout during suspend mode (CVE-2024-49963 bsc#1232147). - commit 75bdf4b - x86/mce: Work around an erratum on fast string copy instructions (bsc#1238148 CVE-2022-49124). - commit b1aab7b - drm/msm/mdp5: Fix global state lock backoff (bsc#1238275) - commit d68fed1 - sfc: fix use after free when disabling sriov (CVE-2022-49626 bsc#1238270). - net: hns3: add vlan list lock to protect vlan list (CVE-2022-49182 bsc#1238260). - ibmvnic: fix race between xmit and reset (CVE-2022-49201 bsc#1238256). - mlxsw: spectrum: Guard against invalid local ports (CVE-2022-49134 bsc#1237982). - net: hns3: remove useless mutex vport_cfg_mutex in the struct hclge_dev (CVE-2022-49182 bsc#1238260). - commit 41d3a51 - drm/msm/mdp5: Return error code in mdp5_pipe_release when deadlock is (bsc#1238275 CVE-2022-49490) - commit af254cd - drm/amd/display: Fix memory leak (bsc#1238006 CVE-2022-49135) - commit 74a7dda - memstick/mspro_block: fix handling of read-only devices (CVE-2022-49178 bsc#1238107). - commit f4ff479 - bpf, sockmap: Fix repeated calls to sock_put() when msg has more_data (bsc#1235485 CVE-2024-56633). - commit 8b17f20 - tracing: Free buffers when a used dynamic event is removed (bsc#1232163 CVE-2022-49006). - blacklist.conf: Remove the commit from the list. - commit dc40c84 - tracing: Only have rmmod clear buffers that its events were active in (bsc#1232163). - kABI: Preserve TRACE_EVENT_FL values (bsc#1232163). - kABI: Add clear_trace to trace_array (bsc#1232163). - commit 314b5be - uprobes: fix kernel info leak via &quot;[uprobes]&quot; vma (bsc#1232104 CVE-2024-49975). - commit c0c10d0 - btrfs: fix use-after-free when attempting to join an aborted transaction (CVE-2025-21753 bsc#1237875) - commit 6c90c9e - mm/mempolicy: fix mpol_new leak in shared_policy_replace (CVE-2022-49080 bsc#1238033). - commit 067e764 - IB/rdmavt: add lock to call to rvt_error_qp to prevent a race condition (git-fixes CVE-2022-49089 bsc#1238041) - commit 6e0de51 - RDMA/hfi1: Fix use-after-free bug for mm struct (git-fixes CVE-2022-49076 bsc#1237738) - commit 6e82988 - nfsd: restore callback functionality for NFSv4.0 (CVE-2024-53217 bsc#1234999) - commit 805ad92 - netfilter: nf_tables: don't skip expired elements during walk (CVE-2023-52924 bsc#1236821). - commit 0526ace - can: gs_usb: gs_usb_open/close(): fix memory leak (CVE-2022-49661 bsc#1237788). - can: mcba_usb: properly check endpoint type (CVE-2022-49151 bsc#1237778). - commit 9830891 - media: stk1160: If start stream fails, return buffers with VB2_BUF_STATE_QUEUED (CVE-2022-49247 bsc#1237783). - commit a93f4c4 - media: staging: media: zoran: move videodev alloc (CVE-2021-47644 bsc#1237766). - commit c96d641 - ubi: Fix race condition between ctrl_cdev_ioctl and ubi_cdev_ioctl (CVE-2021-47634 bsc#1237758). - commit d5a9e9b - USB: serial: quatech2: fix null-ptr-deref in qt2_process_read_urb() (CVE-2025-21689 bsc#1237017). - commit 10a8b05 - hid: cp2112: Fix duplicate workqueue initialization (CVE-2023-52853 bsc#1224988). - commit 0767a8e - Update References for CVE-2023-52572 and bsc#bsc#1220946 Patch: patches.suse/cifs-Fix-UAF-in-cifs_demultiplex_thread-.patch - commit 8c83bd1 - net: Fix icmp host relookup triggering ip_rt_bug (CVE-2024-56647 bsc#1235435). - commit 5e3ecca - net: sched: Disallow replacing of child qdisc from one parent to another (CVE-2025-21700 bsc#1237159). - commit 634dd23 - sctp: sysctl: cookie_hmac_alg: avoid using current-&gt;nsproxy (CVE-2025-21640 bsc#1236123) - commit fcc1d3a - sctp: sysctl: rto_min/max: avoid using current-&gt;nsproxy (CVE-2025-21639 bsc#1236122) - commit cef2fdd - sctp: sysctl: auth_enable: avoid using current-&gt;nsproxy (CVE-2025-21638 bsc#1236115) - commit cb20958 - rtc: cmos: fix build on non-ACPI platforms (CVE-2022-48953 bsc#1231941). - commit aeaadef - scsi: storvsc: Ratelimit warning logs to prevent VM denial of service (bsc#1237025 CVE-2025-21690). - scsi: storvsc: Handle SRB status value 0x30 (git-fixes). - scsi: storvsc: Fix handling of srb_status and capacity change events (git-fixes). - scsi: storvsc: Use scsi_cmd_to_rq() instead of scsi_cmnd.request (git-fixes). - scsi: storvsc: Log TEST_UNIT_READY errors as warnings (git-fixes). - scsi: storvsc: Correctly handle multiple flags in srb_status (git-fixes). - scsi: storvsc: Update error logging (git-fixes). - scsi: storvsc: Miscellaneous code cleanups (git-fixes). - scsi: storvsc: Return DID_ERROR for invalid commands (git-fixes). - scsi: storvsc: Add validation for untrusted Hyper-V values (git-fixes). - scsi: storvsc: Fix spelling mistake (git-fixes). - commit 1ce0fca - rtc: cmos: Fix wake alarm breakage (CVE-2022-48953 bsc#1231941). - rtc: cmos: Fix event handler registration ordering issue (CVE-2022-48953 bsc#1231941). - commit 18a134d - gpiolib: fix memory leak in gpiochip_setup_dev() (CVE-2022-48975 bsc#1231885). - commit 8811266 - uprobe: avoid out-of-bounds memory access of fetching args (git-fixes CVE-2024-50067 bsc#1232416). - commit 113452d - Refresh patches.suse/cifs-Fix-UAF-in-cifs_demultiplex_thread-.patch. - Refresh patches.suse/netfilter-nf_conntrack_irc-Tighten-matching-on-DCC-m.patch. - powerpc/64/kdump: Limit kdump base to 512MB (bsc#1203410 ltc#199904). Add upstream commit ID and move to the sorted section. - commit 8635ca2 - Delete patches.suse/net-tipc-validate-domain-record-count-on-input.patch. Obsoleted by upstream commit 9aa422ad326634b76309e8ff342c246800621216 which we already have. - commit 0f3afb5 - Refresh patches.suse/SUNRPC-auth-async-tasks-mustn-t-block-waiting-for-me.patch. - Refresh patches.suse/SUNRPC-improve-swap-handling-scheduling-and-PF_MEMAL.patch. - Refresh patches.suse/SUNRPC-xprt-async-tasks-mustn-t-block-waiting-for-me.patch. Add upstream commit ID to 3 sunrpc patches and move them to the sorted section. - commit 95d9bb0 - Refresh patches.suse/crypto_ccp-fix_resource_leaks_in_ccp_run_aes_gcm_cmd.patch. - Refresh patches.suse/mm-pmem-avoid-inserting-hugepage-pte-entry-with-fsdax-if-hugepage-support-is-disabled.patch. - Refresh patches.suse/proc-Avoid-mixing-integer-types-in-mem_rw.patch. Move these 3 patches to the sorted section with proper upstream references. - commit b21e43e - net: mana: Add get_link and get_link_ksettings in ethtool (bsc#1236761). - net: netvsc: Update default VMBus channels (bsc#1236757). - commit cf42fac - Refresh patches.suse/eth-bnxt-always-recalculate-features-after-XDP-clear.patch. Fix warning introduced by commit 26357a58074c (&quot;eth: bnxt: always recalculate features after XDP clearing, fix null-deref (CVE-2025-21682 bsc#1236703).&quot;) - commit cb8e39a - Update patches.suse/ALSA-6fire-Release-resources-at-card-release.patch (CVE-2024-53239 bsc#1235054 bsc#1234853). - Update patches.suse/Bluetooth-L2CAP-Fix-uaf-in-l2cap_connect.patch (CVE-2024-49950 bsc#1232159 bsc#1225742). - Update patches.suse/Bluetooth-L2CAP-do-not-leave-dangling-sk-pointer-on-.patch (CVE-2024-56605 bsc#1235061 bsc#1234853). - Update patches.suse/KVM-nSVM-Ignore-nCR3-4-0-when-loading-PDPTEs-from-me.patch (CVE-2024-50115 bsc#1232919 bsc#1225742). - Update patches.suse/NFSv4.0-Fix-a-use-after-free-problem-in-the-asynchronous-open.patch (CVE-2024-53173 bsc#1234891 bsc#1234853). - Update patches.suse/btrfs-wait-for-fixup-workers-before-stopping-cleaner.patch (bsc#1235965 CVE-2024-57896 CVE-2024-49867 bsc#1232262). - Update patches.suse/ext4-avoid-OOB-when-system.data-xattr-changes-undern.patch (bsc#1231920 CVE-2024-47701 bsc#1225742). - Update patches.suse/ext4-fix-slab-use-after-free-in-ext4_split_extent_at.patch (bsc#1232201 CVE-2024-49884 bsc#1232198 bsc#1225742). - Update patches.suse/hfsplus-don-t-query-the-device-logical-block-size-multiple-times.patch (bsc#1235073 CVE-2024-56548 bsc#1234853). - Update patches.suse/tty-n_gsm-Fix-use-after-free-in-gsm_cleanup_mux.patch (CVE-2024-50073 bsc#1232520 bsc#1225742). - Update patches.suse/vfio-pci-Lock-external-INTx-masking-ops.patch (bsc#1222803 CVE-2024-26810). - Update patches.suse/wifi-mwifiex-Fix-memcpy-field-spanning-write-warning-in-mwifiex_config_scan.patch (CVE-2024-56539 bsc#1234963 bsc#1234853). - commit f832b51 - Update patches.suse/btrfs-fix-hang-during-unmount-when-stopping-a-space-.patch (bsc#1235965 CVE-2024-57896 CVE-2022-48664 bsc#1223524). - commit 1e97612 - smb: client: fix double free of TCP_Server_Info::hostname (CVE-2025-21673 bsc#1236689). - commit a8e944b - kABI fix for net: defer final 'struct net' free in netns dismantle (CVE-2024-56658 bsc#1235441). Upstream commit 0f6ede9fbc74 (&quot;net: defer final 'struct net' free in netns dismantle&quot;) introduced a new struct element `defer_free_list` into `struct net`. In order to preserve the kABI, move the newly added element into a hole. ``` struct netns_unix unx; /* 536 16 */ /* XXX 24 bytes hole, try to pack */ /* --- cacheline 9 boundary (576 bytes) --- */ struct netns_ipv4 ipv4 __attribute__((__aligned__(64))); /* 576 1088 */ ``` - commit 3fe112a - net: defer final 'struct net' free in netns dismantle (CVE-2024-56658 bsc#1235441). - commit a3ad07d - net: bridge: fix vlan tunnel dst refcnt when egressing (CVE-2021-47222 bsc#1224857) - commit c5ffad3 - net: bridge: fix vlan tunnel dst null pointer dereference (CVE-2021-47223 bsc#1224856) - commit 183304e - xfrm: validate new SA's prefixlen using SA family when sel.family is unset (CVE-2024-50142 bsc#1233028) - commit 44b0b49 - tcp_bpf: Fix the sk_mem_uncharge logic in tcp_bpf_sendmsg (bsc#1235485 CVE-2024-56633). - bpf, sockmap: Fix the sk-&gt;sk_forward_alloc warning of sk_stream_kill_queues (bsc#1235485 CVE-2024-56633). - bpf, sockmap: Fix more uncharged while msg has more_data (bsc#1235485 CVE-2024-56633). - tcp_bpf: Fix one concurrency problem in the tcp_bpf_send_verdict function (bsc#1235485 CVE-2024-56633). - commit 312086f - RDMA/hns: Fix cpu stuck caused by printings during reset (CVE-2024-56722 bsc#1235570) - commit 8d94b2e - vfio/pci: Lock external INTx masking ops (bsc#1222803). - Refresh patches.suse/vfio-pci-Create-persistent-INTx-handler.patch. - commit 0681ef7 - gtp: Destroy device along with udp socket's netns dismantle (CVE-2025-21678 bsc#1236698). - gtp: Use for_each_netdev_rcu() in gtp_genl_dump_pdp() (CVE-2025-21678 bsc#1236698). - eth: bnxt: always recalculate features after XDP clearing, fix null-deref (CVE-2025-21682 bsc#1236703). - commit e803c29 - ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find() (CVE-2024-50304 bsc#1233522). - commit 225c809 - netfilter: nft_payload: sanitize offset and length before calling skb_checksum() (CVE-2024-50251 bsc#1233248). - commit eece26a - net: inet6: do not leave a dangling sk pointer in inet6_create() (CVE-2024-56600 bsc#1235217). - commit a01a9a3 - btrfs: don't abort filesystem when attempting to snapshot deleted subvolume (bsc#1222072 CVE-2024-26644). - commit 41ce9ae - scsi: qla2xxx: Fix use after free on unload (CVE-2024-56623 bsc#1235466). - scsi: qedi: Fix a possible memory leak in qedi_alloc_and_init_sb() (CVE-2024-56747 bsc#1234934). - scsi: bfa: Fix use-after-free in bfad_im_module_exit() (CVE-2024-53227 bsc#1235011). - commit 64d880b - RDMA/uverbs: Prevent integer overflow issue (bsc#1235919 CVE-2024-57890) - commit 38203c5 - overflow: Implement size_t saturating arithmetic helpers (bsc#1235919 CVE-2024-57890) - commit 90eb057 - overflow: Add __must_check attribute to check_*() helpers (bsc#1235919 CVE-2024-57890) Refresh patches.suse/0010-overflow-Correct-check_shl_overflow-comment.patch - commit 5140cb6 - overflow.h: Add flex_array_size() helper (bsc#1235919 CVE-2024-57890) - commit 22d16f6 - overflow.h: Add comment documenting __ab_c_size() (bsc#1235919 CVE-2024-57890) - commit b5a4098 - netfilter: x_tables: fix LED ID check in led_tg_check() (CVE-2024-56650 bsc#1235430). - commit 8b9e311 - ALSA: usb-audio: Fix a DMA to stack memory bug (git-fixes). - ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox devices (git-fixes CVE-2024-53197 bsc#1235464). - commit dc81ff3 - NFSD: Prevent NULL dereference in nfsd4_process_cb_update() (CVE-2024-53217 bsc#1234999) - commit 8a6f9b4 - wifi: mac80211: fix mbss changed flags corruption on 32 bit systems (CVE-2024-57899 bsc#1235924) - commit 600d381 - drm/modes: Avoid divide by zero harder in drm_mode_vrefresh() (CVE-2024-56369 bsc#1235750) - commit b3145a1 - drm/modes: Switch to 64bit maths to avoid integer overflow (bsc#1235750) - commit e4d2dd7 - igb: Fix potential invalid memory access in igb_init_module() (CVE-2024-52332 bsc#1235700) - commit 23608e0 - rtc: check if __rtc_read_time was successful in rtc_timer_do_work() (CVE-2024-56739 bsc#1235611) - commit 26c24f2 - crypto: bcm - add error check in the ahash_hmac_init function (CVE-2024-56681 bsc#1235557) - commit f132d27 - sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport (CVE-2024-56688 bsc#1235538) - commit a4e5ee6 - acpi: nfit: vmalloc-out-of-bounds Read in acpi_nfit_ctl (CVE-2024-56662 bsc#1235533) - commit c4dc3c5 - media: wl128x: Fix atomicity violation in fmc_send_cmd() (CVE-2024-56700 bsc#1235500) - commit d0190f0 - drm/amdgpu: set the right AMDGPU sg segment limitation (CVE-2024-56594 bsc#1235413) - commit b32a039 - wifi: brcmfmac: Fix oops due to NULL pointer dereference in brcmf_sdiod_sglist_rw() (CVE-2024-56593 bsc#1235252) - commit 84dd400 - media: dvb-frontends: dib3000mb: fix uninit-value in dib3000_write_reg (CVE-2024-56769 bsc#1235155) - commit d6854a8 - ALSA: us122l: Use snd_card_free_when_closed() at disconnection (CVE-2024-56532 bsc#1235059) - commit c7d5d7e - ALSA: usx2y: Use snd_card_free_when_closed() at disconnection (CVE-2024-56533 bsc#1235053) - commit 7a2524a - media: ts2020: fix null-ptr-deref in ts2020_probe() (CVE-2024-56574 bsc#1235040) - commit 994f123 - Move patches.suse/floppy-reintroduce-O_NDELAY-fix.patch to the sorted section with proper upstream references. Document the reason why the upstream revert should not be applied to our kernel. - commit c686e79 - dm thin: make get_first_thin use rcu-safe list first function (CVE-2025-21664 bsc#1236262) - commit a5449a2 - selinux: ignore unknown extended permissions (CVE-2024-57931 bsc#1236192) - commit 026448e - net_sched: cls_flow: validate TCA_FLOW_RSHIFT attribute (CVE-2025-21653 bsc#1236161) - commit 987a924 - net/sctp: Prevent autoclose integer overflow in sctp_association_init() (CVE-2024-57938 bsc#1236182) - commit 3f47e6a - mm: vmscan: account for free pages to prevent infinite Loop in throttle_direct_reclaim() (CVE-2024-57884 bsc#1235948) - commit 7ce422e - Drivers: hv: util: Avoid accessing a ringbuffer not initialized yet (bsc#1235747 CVE-2024-55916). - commit bfb225e - gve: guard XDP xmit NDO on existence of xdp queues (CVE-2024-57932 bsc#1236190). - commit 9d9586a - Update patches.suse/tipc-fix-NULL-deref-in-cleanup_bearer.patch (bsc#1235433 CVE-2024-56661 bsc#1234931). - commit f670a26 - net: inet: do not leave a dangling sk pointer in inet_create() (CVE-2024-56601 bsc#1235230). - commit 2328dc9 - net: add more sanity checks to qdisc_pkt_len_init() (CVE-2024-49948 bsc#1232161). - commit 39d78f4 - net: restrict SO_REUSEPORT to inet sockets (bsc#1235967 CVE-2024-57903) - commit eaf865b - net: do not delay dst_entries_add() in dst_release() (CVE-2024-50036 bsc#1231912). - commit 4ae059f - tracing: Prevent bad count for tracing_cpumask_write (CVE-2024-56763 bsc#1235638) - commit 224036d - dccp: Fix memory leak in dccp_feat_change_recv (CVE-2024-56643 bsc#1235132) - commit f89cb51 - net/smc: initialize close_work early to avoid warning (CVE-2024-56641 bsc#1235526) - commit 3572c76 - btrfs: fix use-after-free when COWing tree bock and tracing is enabled (bsc#1235645 CVE-2024-56759). - btrfs: flush delalloc workers queue before stopping cleaner kthread during unmount (bsc#1235965 CVE-2024-57896). - btrfs: wait for fixup workers before stopping cleaner kthread during umount (bsc#1235965 CVE-2024-57896). - btrfs: fix hang during unmount when stopping a space reclaim worker (bsc#1235965 CVE-2024-57896). - Btrfs: fix crash during unmount due to race with delayed inode workers (bsc#1235965 CVE-2024-57896). - commit 176ee37 - drm/amd/display: Add check for granularity in dml ceil/floor helpers (CVE-2024-57922 bsc#1236080 with CVSS 5.5). - commit 447f836 - netfilter: ipset: Hold module reference while requesting a module (CVE-2024-56637 bsc#1235523) - commit 88e28cd - dm array: fix releasing a faulty array block twice in dm_array_cursor_end (bsc#1236096, CVE-2024-57929). - commit 1959a0b - Update patches.suse/af_packet-avoid-erroring-out-after-sock_init_data-in.patch (CVE-2024-56606 bsc#1235417). Fix the bug number. - commit f121592 - drm: adv7511: Fix use-after-free in adv7533_attach_dsi() (CVE-2024-57887 bsc#1235952). - commit 5c4ee3f - ocfs2: fix slab-use-after-free due to dangling pointer dqi_priv (bsc#1235964 CVE-2024-57892). - ocfs2: correct return value of ocfs2_local_free_info() (bsc#1235964 CVE-2024-57892). - commit b9a152d - xen: Fix the issue of resource not being properly released in xenbus_dev_probe() (CVE-2024-53198 bsc#1234923). - commit ca6183e - workqueue: skip lockdep wq dependency in cancel_work_sync() (bsc#1235918). - commit 1b19fa3 - workqueue: Do not warn when cancelling WQ_MEM_RECLAIM work from !WQ_MEM_RECLAIM worker (bsc#1235416 bsc#1235918 CVE-2024-57888). - commit b01b194 - ftrace: Fix regression with module command in stack_trace_filter (CVE-2024-56569 bsc#1235031). - commit e7b7c58 - ALSA: seq: oss: Fix races at processing SysEx messages (CVE-2024-57893 bsc#1235920). - commit 7be38f2 - bpf: fix OOB devmap writes when deleting elements (CVE-2024-56615 bsc#1235426) - commit a05e14b - cifs: fix calc signature on big endian systems (bsc#1235888, bsc#1234921). - commit 38ecaae - ocfs2: fix uninitialized value in ocfs2_file_read_iter() (CVE-2024-53155 bsc#1234855) - commit 1c5aa20 - dlm: fix possible lkb_resource null dereference (CVE-2024-47809 bsc#1235714) - commit 96406ba - ocfs2: free inode when ocfs2_get_init_inode() fails (CVE-2024-56630 bsc#1235479) - commit 3c3dfcf - bcache: revert replacing IS_ERR_OR_NULL with IS_ERR again (CVE-2024-48881 bsc#1235727) - commit 027cde8 - netfilter: nf_tables: use timestamp to check for set element timeout (CVE-2024-27397 bsc#1224095). - commit f2d74b7 - net/smc: check return value of sock_recvmsg when draining clc data (CVE-2024-57791 bsc#1235759). - commit 7c27e5f - scsi: qedf: Fix a possible memory leak in qedf_alloc_and_init_sb() (CVE-2024-56748 bsc#1235627) - commit ce7ef63 - smb: client: fix parsing of SMB3.1.1 POSIX create context (git-fixes). - commit bc79049 - s390/cpum_sf: Handle CPU hotplug remove during sampling (CVE-2024-57849 bsc#1235814). - commit 0001c5b - pinmux: Use sequential access to access desc-&gt;pinmux data (CVE-2024-47141 bsc#1235708). - commit 5d7a944 - mm/swapfile: skip HugeTLB pages for unuse_vma (CVE-2024-50199 bsc#1233112). - commit 46f452a - drm/dp_mst: Fix MST sideband message body length check (bsc#1235427 CVE-2024-56616) - commit a9fa1ed - bpf, sockmap: Fix race between element replace and close() (CVE-2024-56664 bsc#1235249). - commit 58b2a56 - tipc: fix NULL deref in cleanup_bearer() (bsc#1235433). - commit 45bfce4 - scsi: sg: Fix slab-use-after-free read in sg_release() (CVE-2024-56631 bsc#1235480). - commit 7bf64a1 - Fix CVE reference for patches.suse/af_packet-avoid-erroring-out-after-sock_init_data-in.patch (CVE-2024-56606) - commit 0d64068 - 9p/xen: fix release of IRQ (CVE-2024-56704 bsc#1235584). - commit f5768af - mfd: intel_soc_pmic_bxtwc: Use IRQ domain for TMU device (CVE-2024-56724 bsc#1235577). - commit fe1aa03 - irqchip/gic-v3-its: Prevent double free on error (bsc#1224697 CVE-2024-35847). - commit 014f7f5 - smb: client: fix use-after-free of signing key (bsc#1234921, CVE-2024-53179). - commit c267f82 - af_packet: avoid erroring out after sock_init_data() in packet_create() (CVE-2024-5660 bsc#123541) - commit 0fe28c5 - KVM: Always flush async #PF workqueue when vCPU is being destroyed (CVE-2024-26976 bsc#1223635). - commit 55809b2 - netfilter: nft_set_rbtree: .deactivate fails if element has expired (CVE-2024-27397 bsc#1224095). - netfilter: nft_set_rbtree: check for inactive element after flag mismatch (CVE-2024-27397 bsc#1224095). - commit 40ba8ec - smb: client: fix NULL ptr deref in crypto_aead_setkey() (CVE-2024-53185 bsc#1234901) - commit 5cf5c90 - ovl: Filter invalid inodes with missing lookup function (bsc#1235035 CVE-2024-56570). - commit 6e7923c - net: af_can: do not leave a dangling sk pointer in can_create() (CVE-2024-56603 bsc#1235415) - commit c85c522 - ubi: fastmap: Fix duplicate slab cache names while attaching (CVE-2024-53172 bsc#1234898) - commit 9366af4 - NFSv4.0: Fix a use-after-free problem in the asynchronous open() (CVE-2024-53173 bsc#1234891). - commit a7e3c22 - tipc: Fix use-after-free of kernel socket in cleanup_bearer() (CVE-2024-56642 bsc#1235433). - commit 3768de6 - sctp: properly validate chunk size in sctp_sf_ootb() (CVE-2024-50299 bsc#1233488) - commit 537e6f9 - drm/amdgpu: fix usage slab after free (CVE-2024-56551 bsc#1235075). - commit d5ec598 - Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2cap_sock_create() (CVE-2024-56605 bsc#1235061). - commit 6ac1393 - net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT (CVE-2024-53057 bsc#1233551). - commit 707ad78 - media: s5p_cec: limit msg.len to CEC_MAX_MSG_SIZE (CVE-2022-49035 bsc#1215304). - commit e681ca0 - Revert &quot;fbdev: efifb: Register sysfs groups through driver core&quot; This reverts commit bff30872a052aab87ee7774e2be9b01e1cc917a9. (bsc#1232224 CVE-2024-49925) As Michal Koutný's comment#70 in bsc#1232224, the reason is that kABI fixup in patches.kabi/driver-core-kABI-workaround-for-dev_groups-in-device.patch is not restoring original KABI since the (extended) struct device_driver is embedded in other structs, like platform_driver. And I agree with Michal's comments, CVE-2024-49925 vulnerability is not easy to be used by attacker who does not have root permission. So let's revert the following backported/kabi patches and set CVE-2024-49925 to WONFIX on SLE12-SP5: 72643096ed46b327a37e55db8130cbdc5dadc513 driver core: Fix error return code in really_probe() (bsc#1232224 CVE-2024-49925). 993ec78562135da497117ab08d14b980c9f783ac driver core: kABI workaround for dev_groups in device_driver (bsc#1232224 CVE-2024-49925). d16dce7a3af05c2034c4ba6cea77c5fdc32124cd driver core: add dev_groups to all drivers (bsc#1232224 CVE-2024-49925). bff30872a052aab87ee7774e2be9b01e1cc917a9 fbdev: efifb: Register sysfs groups through driver core (bsc#1232224 CVE-2024-49925). - commit 70f2ffa - Revert &quot;driver core: add dev_groups to all drivers (bsc#1232224&quot; This reverts commit d16dce7a3af05c2034c4ba6cea77c5fdc32124cd. (bsc#1232224 CVE-2024-49925) As Michal Koutný's comment#70 in bsc#1232224, the reason is that kABI fixup in patches.kabi/driver-core-kABI-workaround-for-dev_groups-in-device.patch is not restoring original KABI since the (extended) struct device_driver is embedded in other structs, like platform_driver. And I agree with Michal's comments, CVE-2024-49925 vulnerability is not easy to be used by attacker who does not have root permission. So let's revert the following backported/kabi patches and set CVE-2024-49925 to WONFIX on SLE12-SP5: 72643096ed46b327a37e55db8130cbdc5dadc513 driver core: Fix error return code in really_probe() (bsc#1232224 CVE-2024-49925). 993ec78562135da497117ab08d14b980c9f783ac driver core: kABI workaround for dev_groups in device_driver (bsc#1232224 CVE-2024-49925). d16dce7a3af05c2034c4ba6cea77c5fdc32124cd driver core: add dev_groups to all drivers (bsc#1232224 CVE-2024-49925). bff30872a052aab87ee7774e2be9b01e1cc917a9 fbdev: efifb: Register sysfs groups through driver core (bsc#1232224 CVE-2024-49925). - commit 4b057cb - Revert &quot;driver core: kABI workaround for dev_groups in device_driver&quot; This reverts commit 993ec78562135da497117ab08d14b980c9f783ac. (bsc#1232224 CVE-2024-49925) As Michal Koutný's comment#70 in bsc#1232224, the reason is that kABI fixup in patches.kabi/driver-core-kABI-workaround-for-dev_groups-in-device.patch is not restoring original KABI since the (extended) struct device_driver is embedded in other structs, like platform_driver. And I agree with Michal's comments, CVE-2024-49925 vulnerability is not easy to be used by attacker who does not have root permission. So let's revert the following backported/kabi patches and set CVE-2024-49925 to WONFIX on SLE12-SP5: 72643096ed46b327a37e55db8130cbdc5dadc513 driver core: Fix error return code in really_probe() (bsc#1232224 CVE-2024-49925). 993ec78562135da497117ab08d14b980c9f783ac driver core: kABI workaround for dev_groups in device_driver (bsc#1232224 CVE-2024-49925). d16dce7a3af05c2034c4ba6cea77c5fdc32124cd driver core: add dev_groups to all drivers (bsc#1232224 CVE-2024-49925). bff30872a052aab87ee7774e2be9b01e1cc917a9 fbdev: efifb: Register sysfs groups through driver core (bsc#1232224 CVE-2024-49925). - commit eade7d6 - Revert &quot;driver core: Fix error return code in really_probe()&quot; This reverts commit 72643096ed46b327a37e55db8130cbdc5dadc513. (bsc#1232224 CVE-2024-49925) As Michal Koutný's comment#70 in bsc#1232224, the reason is that kABI fixup in patches.kabi/driver-core-kABI-workaround-for-dev_groups-in-device.patch is not restoring original KABI since the (extended) struct device_driver is embedded in other structs, like platform_driver. And I agree with Michal's comments, CVE-2024-49925 vulnerability is not easy to be used by attacker who does not have root permission. So let's revert the following backported/kabi patches and set CVE-2024-49925 to WONFIX on SLE12-SP5: 72643096ed46b327a37e55db8130cbdc5dadc513 driver core: Fix error return code in really_probe() (bsc#1232224 CVE-2024-49925). 993ec78562135da497117ab08d14b980c9f783ac driver core: kABI workaround for dev_groups in device_driver (bsc#1232224 CVE-2024-49925). d16dce7a3af05c2034c4ba6cea77c5fdc32124cd driver core: add dev_groups to all drivers (bsc#1232224 CVE-2024-49925). bff30872a052aab87ee7774e2be9b01e1cc917a9 fbdev: efifb: Register sysfs groups through driver core (bsc#1232224 CVE-2024-49925). - commit 409618d - nvme-pci: fix freeing of the HMB descriptor table (bsc#1234921 CVE-2024-56756). - commit a639847 - wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_config_scan() (CVE-2024-56539 bsc#1234963). - commit 07aa3cb - vfio/pci: Properly hide first-in-list PCIe extended capability (bsc#1235004 CVE-2024-53214). - commit 1b7890f - wifi: ath10k: avoid NULL pointer error during sdio remove (CVE-2024-56599 bsc#1235138). - commit 827f8ee - leds: class: Protect brightness_show() with led_cdev-&gt;led_access mutex (CVE-2024-56587 bsc#1235125). - commit 654afb9 - net: marvell: mvpp2: phylink requires the link interrupt (bsc#1117016). - Delete patches.suse/net-mvpp2-fix-condition-for-setting-up-link-interrup.patch. Replace downsteram patch with upstream one - commit 5355aa8 - Bluetooth: RFCOMM: avoid leaving dangling sk pointer in rfcomm_sock_alloc() (bsc#1235056 CVE-2024-56604). - commit 9674234 - Bluetooth: Consolidate code around sk_alloc into a helper function (bsc#1235056 CVE-2024-56604). Refresh patches.suse/Bluetooth-SCO-Fix-UAF-on-sco_sock_timeout.patch. - commit d4282e9 - Bluetooth: hci_sock: purge socket queues in the destruct() callback (bsc#1235056 CVE-2024-56604). - commit a8a4e81 - hfsplus: don't query the device logical block size multiple times (bsc#1235073 CVE-2024-56548). - commit ff0cbed - wifi: ath9k: add range check for conn_rsp_epid in htc_connect_service() (CVE-2024-53156 bsc#1234846). - commit 22125f2 - ALSA: 6fire: Release resources at card release (CVE-2024-53239 bsc#1235054). - ALSA: caiaq: Use snd_card_free_when_closed() at disconnection (CVE-2024-56531 bsc#1235057). - commit d3f225e - NFSD: Prevent a potential integer overflow (CVE-2024-53146 bsc#1234853). - commit c43d88d - Refresh patches.suse/char-virtio-Select-VIRTIO-from-VIRTIO_CONSOLE.patch. - Refresh patches.suse/net-packet-fix-overflow-in-tpacket_rcv.patch. Add upstream references and move to sorted section. - commit 62678cc - SUNRPC: 'Directory with parent 'rpc_clnt' already present!' (bsc#1168202 bsc#1188924). - commit 511e0dd - SUNRPC: fix use-after-free in rpc_free_client_work() (bsc#1168202 bsc#1188924). - Refresh patches.suse/SUNRPC-Fix-RPC-client-cleaned-up-the-freed-pipefs-de.patch. - Refresh patches.suse/SUNRPC-defer-slow-parts-of-rpc_free_client-to-a-work.patch. Add upstream reference and move to sorted section. Split a fix-up to a separate patch so that it also gets its upstream reference. This aligns with how things were done in other maintained kernel branches. - commit f5a7a6e - netfilter: ipset: add missing range check in bitmap_ip_uadt (CVE-2024-53141 bsc#1234381) - commit 5b1c6de - RDMA/mlx5: Cancel pkey work before destroying device resources (bsc#1235009 CVE-2024-53224) - commit 9ac5166 - Update patches.suse/Bluetooth-hci_event-Align-BR-EDR-JUST_WORKS-paring-w.patch (git-fixes bsc#1230697 CVE-2024-8805 CVE-2024-53144 bsc#1234690). - Update patches.suse/can-bcm-Clear-bo-bcm_proc_read-after-remove_proc_ent.patch (CVE-2024-46771 bsc#1230766 CVE-2024-47709 bsc#1232048). - Update patches.suse/mm-revert-mm-shmem-fix-data-race-in-shmem_getattr.patch (CVE-2024-50228 bsc#1233204 git fixes (mm/shmem) CVE-2024-53136 bsc#1234161). - Update patches.suse/net-relax-socket-state-check-at-accept-time.patch (git-fixes CVE-2024-36484 bsc#1226872). - Update patches.suse/ocfs2-uncache-inode-which-has-failed-entering-the-group.patch (bsc#1234087 CVE-2024-53112). - commit 357ae3f - Refresh patches.suse/Deprecate-NR_UNSTABLE_NFS-use-NR_WRITEBACK.patch. - Refresh patches.suse/MM-replace-PF_LESS_THROTTLE-with-PF_LOCAL_THROTTLE.patch. - Refresh patches.suse/mm-Avoid-overflows-in-dirty-throttling-logic.patch. Add upstream reference to 2 patches, move them to the sorted section and refresh another patch to solve context conflicts. - commit 91ba058 - firmware: arm_scpi: Check the DVFS OPP count returned by the firmware (CVE-2024-53157 bsc#1234827). - commit 77c498b - s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct() (CVE-2024-53210 bsc#1234971). - commit e1704a7 - ALSA: usb-audio: Fix out of bounds reads when finding clock sources (CVE-2024-53150 bsc#1234834). - commit 809edc6 - smb: client: fix OOBs when building SMB2_IOCTL request (CVE-2024-50151 bsc#1233055). - commit 5303c51 - xen/netfront: fix crash when removing device (XSA-465 CVE-2024-53240 bsc#1234281). - commit 6a0455d - btrfs: qgroup: fix sleep from invalid context bug in btrfs_qgroup_inherit() (CVE-2022-49033 bsc#1232045). - commit 1c36522 - Bluetooth: hci_event: Align BR/EDR JUST_WORKS paring with LE (git-fixes, bsc#1230697, CVE-2024-8805). - commit af6048b - scsi: pm80xx: Set phy-&gt;enable_completion only when we wait for it (CVE-2024-47666 bsc#1231453). - commit 3fe50d4 - xfs: don't walk off the end of a directory data block (bsc#1228405 CVE-2024-41013). - commit 7e72128 - bpf: Fix out-of-bounds write in trie_get_next_key() (CVE-2024-50262 bsc#1233239) - commit deb09e1 - can: bcm: Fix UAF in bcm_proc_show() (CVE-2023-52922 bsc#1233977) - commit a84b421 - media: v4l2-tpg: prevent the risk of a division by zero (CVE-2024-50287 bsc#1233476) - commit f6101ec - fs: Fix uninitialized value issue in from_kuid and from_kgid (CVE-2024-53101 bsc#1233769) - commit a397183 - udf: refactor inode_bmap() to handle error (bsc#1234242 bsc#1233096 CVE-2024-50211). - commit 20d3a39 - udf: refactor udf_next_aext() to handle error (bsc#1234241). - commit f098aa9 - udf: refactor udf_current_aext() to handle error (bsc#1234240). - commit b64184f - udf: fix uninit-value use in udf_get_fileshortad (bsc#1234243 bsc#1233038 CVE-2024-50143). - commit 67400f8 - udf: Handle error when adding extent to a file (bsc#1234437). - commit f03c52b - kabi/severities: ignore intermodule symbols between fsl_fman and fsl_dpaa_eth - commit eb515fb - fsl/fman: Fix refcount handling of fman-related devices (CVE-2024-50166 bsc#1233050). - fsl/fman: Save device references taken in mac_probe() (CVE-2024-50166 bsc#1233050). - net: fman: Unregister ethernet device on removal (CVE-2024-50166 bsc#1233050). - commit f22236a - rtnetlink: make sure to refresh master_dev/m_ops in __rtnl_newlink() (CVE-2022-48742 bsc#1226694). - commit 8931ec3 - Update References: field, and keep KABI consistency of bioset_exit(), patches.suse/dm-cache-fix-flushing-uninitialized-delayed_work-on--1354.patch (bsc#1233467, CVE-2024-50278, bsc#1233469, CVE-2024-50280). - commit 4bed2c0 - netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6() (CVE-2024-50256 bsc#1233200). - commit c62ba75 Package libxml2 was updated: - security update- modified patches % fix-perl.diff (p1) - added patches fix CVE-2024-56171 [bsc#1237363], use-after-free in xmlSchemaIDCFillNodeTables and xmlSchemaBubbleIDCNodeTables in xmlschemas.c + libxml2-CVE-2024-56171.patch fix CVE-2025-24928 [bsc#1237370], stack-based buffer overflow in xmlSnprintfElements in valid.c + libxml2-CVE-2025-24928.patch fix CVE-2025-27113 [bsc#1237418], NULL Pointer Dereference in libxml2 xmlPatMatch + libxml2-CVE-2025-27113.patch - security update - added patches fix CVE-2022-49043 [bsc#1236460], use-after-free in xmlXIncludeAddNode + libxml2-CVE-2022-49043.patch Package python was updated: - Update CVE-2024-11168-validation-IPv6-addrs.patch according modifications by the Debian developers (Sylvain Beucler &lt;beuc@debian.org&gt;, gh#python/cpython#103848#issuecomment-2708135083). - Modify CVE-2025-0938-sq-brackets-domain-names.patch: we don't use bracketed_host variable any more (correction of the fix for bsc#1236705, discovered during analysis for bsc#1223694). - Add CVE-2025-0938-sq-brackets-domain-names.patch which disallows square brackets ([ and ]) in domain names for parsed URLs (bsc#1236705, CVE-2025-0938, gh#python/cpython#105704) Package wget was updated: - If wget for an http URL is redirected to a different site (hostname parts of URLs differ), then any &quot;Authenticate&quot; and &quot;Cookie&quot; header entries are discarded. [bsc#1185551, wget-do-not-propagate-credentials.patch, bsc#1230795, CVE-2021-31879] Package curl was updated: - Security fix: [bsc#1236590, CVE-2025-0725] * content_encoding: drop support for zlib before 1.2.0.4 * content_encoding: put the decomp buffers into the writer structs * Add curl-CVE-2025-0725.patch - Security fix: [bsc#1236588, CVE-2025-0167] * netrc: 'default' with no credentials is not a match * Add curl-CVE-2025-0167.patch Package google-guest-agent was updated: - Add patch to fix unexpected memory consumption during token parsing in golang.org/x/oauth2 (bsc#1239197, CVE-2025-22868) * CVE-2025-22868.patch - Update to version 20250116.00: (bsc#1236403) * networkd(vlan): remove the interface in addition to config (#468) * Implement support for vlan dynamic removal, update dhclient to remove only if configured (#465) * Update logging library (#479) * Remove Pat from owners file. (#478) - Update to version 20241209.01: (bsc#1235664) * readme: add notes about plugin manager (#476) * Update metadata script runner to honor cloud logging config flag (#475) * Fixing fallback from systemd-networkd to dhclient (#471) * network: fix nmcli check pattern (#472) * Update readme with guest agent manager (#469) * Add missing packaging spec (#466) * Bring back side-by-side packaging (#464) * Avoid changing permissions of directory if parent is / (#463) * network: force NetworkManager to connect to primary nic (#461) * Revert plugin manager packaging (#460) * Add GOPATH to PATH in debian build (#459) * Add plugin manager to debian build (#457) * rpm packaging: fix plugin manager assumptions (#458) * packaging: add plugin manager to rhel packaging (#454) The CVRF data is provided by SUSE under the Creative Commons License 4.0 with Attribution (CC-BY-4.0). https://publiccloudimagechangeinfo.suse.com/google/sles-12-sp5-byos-v20250326-x86-64/ Public Cloud Image Info https://www.suse.com/support/security/rating/ SUSE Security Ratings Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 bind-utils-9.11.22-3.60.2 cloud-regionsrv-client-10.3.11-52.122.1 cloud-regionsrv-client-plugin-gce-1.0.0-52.122.1 curl-8.0.1-11.105.1 glibc-2.22-114.40.1 glibc-i18ndata-2.22-114.40.1 glibc-locale-2.22-114.40.1 google-guest-agent-20250116.00-1.47.2 google-guest-configs-20241205.00-1.38.1 google-guest-oslogin-20240311.00-1.37.1 google-osconfig-agent-20250115.01-1.38.1 grub2-2.02-184.2 grub2-i386-pc-2.02-184.2 grub2-x86_64-efi-2.02-184.2 kernel-default-4.12.14-122.250.1 krb5-1.16.3-46.18.1 krb5-client-1.16.3-46.18.1 libX11-6-1.6.2-12.36.1 libX11-data-1.6.2-12.36.1 libbind9-161-9.11.22-3.60.2 libcurl4-8.0.1-11.105.1 libdns1110-9.11.22-3.60.2 libfreetype6-2.6.3-7.21.1 libgnutls30-3.4.17-8.17.1 libirs161-9.11.22-3.60.2 libisc1107-9.11.22-3.60.2 libisccc161-9.11.22-3.60.2 libisccfg163-9.11.22-3.60.2 liblwres161-9.11.22-3.60.2 libopenssl1_1-1.1.1d-2.116.1 libprocps3-3.3.9-11.33.1 libpython2_7-1_0-2.7.18-33.47.1 libpython3_4m1_0-3.4.10-25.148.1 libpython3_6m1_0-3.6.15-76.1 libtasn1-4.9-3.16.1 libtasn1-6-4.9-3.16.1 libxml2-2-2.9.4-46.81.1 mozilla-nss-certs-3.101.2-58.127.1 nfsidmap-0.25-7.6.1 nscd-2.22-114.40.1 openssh-7.2p2-81.26.1 procps-3.3.9-11.33.1 python-2.7.18-33.47.1 python-base-2.7.18-33.47.1 python-bind-9.11.22-3.60.2 python-instance-billing-flavor-check-1.0.0-1.20.1 python-xml-2.7.18-33.47.1 python3-3.4.10-25.148.1 python3-base-3.4.10-25.148.1 python36-base-3.6.15-76.1 release-notes-sles-12.5.20250211-3.52.4 rsync-3.1.3-3.25.2 timezone-2025a-74.82.1 vim-9.1.1101-17.41.1 vim-data-common-9.1.1101-17.41.1 wget-1.14-21.22.1 bind-utils-9.11.22-3.60.2 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 cloud-regionsrv-client-10.3.11-52.122.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 cloud-regionsrv-client-plugin-gce-1.0.0-52.122.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 curl-8.0.1-11.105.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 glibc-2.22-114.40.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 glibc-i18ndata-2.22-114.40.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 glibc-locale-2.22-114.40.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 google-guest-agent-20250116.00-1.47.2 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 google-guest-configs-20241205.00-1.38.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 google-guest-oslogin-20240311.00-1.37.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 google-osconfig-agent-20250115.01-1.38.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 grub2-2.02-184.2 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 grub2-i386-pc-2.02-184.2 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 grub2-x86_64-efi-2.02-184.2 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 kernel-default-4.12.14-122.250.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 krb5-1.16.3-46.18.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 krb5-client-1.16.3-46.18.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 libX11-6-1.6.2-12.36.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 libX11-data-1.6.2-12.36.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 libbind9-161-9.11.22-3.60.2 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 libcurl4-8.0.1-11.105.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 libdns1110-9.11.22-3.60.2 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 libfreetype6-2.6.3-7.21.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 libgnutls30-3.4.17-8.17.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 libirs161-9.11.22-3.60.2 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 libisc1107-9.11.22-3.60.2 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 libisccc161-9.11.22-3.60.2 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 libisccfg163-9.11.22-3.60.2 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 liblwres161-9.11.22-3.60.2 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 libopenssl1_1-1.1.1d-2.116.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 libprocps3-3.3.9-11.33.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 libpython2_7-1_0-2.7.18-33.47.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 libpython3_4m1_0-3.4.10-25.148.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 libpython3_6m1_0-3.6.15-76.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 libtasn1-4.9-3.16.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 libtasn1-6-4.9-3.16.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 libxml2-2-2.9.4-46.81.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 mozilla-nss-certs-3.101.2-58.127.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 nfsidmap-0.25-7.6.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 nscd-2.22-114.40.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 openssh-7.2p2-81.26.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 procps-3.3.9-11.33.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 python-2.7.18-33.47.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 python-base-2.7.18-33.47.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 python-bind-9.11.22-3.60.2 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 python-instance-billing-flavor-check-1.0.0-1.20.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 python-xml-2.7.18-33.47.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 python3-3.4.10-25.148.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 python3-base-3.4.10-25.148.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 python36-base-3.6.15-76.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 release-notes-sles-12.5.20250211-3.52.4 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 rsync-3.1.3-3.25.2 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 timezone-2025a-74.82.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 vim-9.1.1101-17.41.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 vim-data-common-9.1.1101-17.41.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 wget-1.14-21.22.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64 GNU Wget through 1.21.1 does not omit the Authorization header upon a redirect to a different origin, a related issue to CVE-2018-1000007. CVE-2021-31879 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:wget-1.14-21.22.1 moderate 5.8 AV:N/AC:M/Au:N/C:P/I:P/A:N In the Linux kernel, the following vulnerability has been resolved: net: bridge: fix vlan tunnel dst refcnt when egressing The egress tunnel code uses dst_clone() and directly sets the result which is wrong because the entry might have 0 refcnt or be already deleted, causing number of problems. It also triggers the WARN_ON() in dst_hold()[1] when a refcnt couldn't be taken. Fix it by using dst_hold_safe() and checking if a reference was actually taken before setting the dst. [1] dmesg WARN_ON log and following refcnt errors WARNING: CPU: 5 PID: 38 at include/net/dst.h:230 br_handle_egress_vlan_tunnel+0x10b/0x134 [bridge] Modules linked in: 8021q garp mrp bridge stp llc bonding ipv6 virtio_net CPU: 5 PID: 38 Comm: ksoftirqd/5 Kdump: loaded Tainted: G W 5.13.0-rc3+ #360 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014 RIP: 0010:br_handle_egress_vlan_tunnel+0x10b/0x134 [bridge] Code: e8 85 bc 01 e1 45 84 f6 74 90 45 31 f6 85 db 48 c7 c7 a0 02 19 a0 41 0f 94 c6 31 c9 31 d2 44 89 f6 e8 64 bc 01 e1 85 db 75 02 <0f> 0b 31 c9 31 d2 44 89 f6 48 c7 c7 70 02 19 a0 e8 4b bc 01 e1 49 RSP: 0018:ffff8881003d39e8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffffa01902a0 RBP: ffff8881040c6700 R08: 0000000000000000 R09: 0000000000000001 R10: 2ce93d0054fe0d00 R11: 54fe0d00000e0000 R12: ffff888109515000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000401 FS: 0000000000000000(0000) GS:ffff88822bf40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f42ba70f030 CR3: 0000000109926000 CR4: 00000000000006e0 Call Trace: br_handle_vlan+0xbc/0xca [bridge] __br_forward+0x23/0x164 [bridge] deliver_clone+0x41/0x48 [bridge] br_handle_frame_finish+0x36f/0x3aa [bridge] ? skb_dst+0x2e/0x38 [bridge] ? br_handle_ingress_vlan_tunnel+0x3e/0x1c8 [bridge] ? br_handle_frame_finish+0x3aa/0x3aa [bridge] br_handle_frame+0x2c3/0x377 [bridge] ? __skb_pull+0x33/0x51 ? vlan_do_receive+0x4f/0x36a ? br_handle_frame_finish+0x3aa/0x3aa [bridge] __netif_receive_skb_core+0x539/0x7c6 ? __list_del_entry_valid+0x16e/0x1c2 __netif_receive_skb_list_core+0x6d/0xd6 netif_receive_skb_list_internal+0x1d9/0x1fa gro_normal_list+0x22/0x3e dev_gro_receive+0x55b/0x600 ? detach_buf_split+0x58/0x140 napi_gro_receive+0x94/0x12e virtnet_poll+0x15d/0x315 [virtio_net] __napi_poll+0x2c/0x1c9 net_rx_action+0xe6/0x1fb __do_softirq+0x115/0x2d8 run_ksoftirqd+0x18/0x20 smpboot_thread_fn+0x183/0x19c ? smpboot_unregister_percpu_thread+0x66/0x66 kthread+0x10a/0x10f ? kthread_mod_delayed_work+0xb6/0xb6 ret_from_fork+0x22/0x30 ---[ end trace 49f61b07f775fd2b ]--- dst_release: dst:00000000c02d677a refcnt:-1 dst_release underflow CVE-2021-47222 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: bridge: fix vlan tunnel dst null pointer dereference This patch fixes a tunnel_dst null pointer dereference due to lockless access in the tunnel egress path. When deleting a vlan tunnel the tunnel_dst pointer is set to NULL without waiting a grace period (i.e. while it's still usable) and packets egressing are dereferencing it without checking. Use READ/WRITE_ONCE to annotate the lockless use of tunnel_id, use RCU for accessing tunnel_dst and make sure it is read only once and checked in the egress path. The dst is already properly RCU protected so we don't need to do anything fancy than to make sure tunnel_id and tunnel_dst are read only once and checked in the egress path. CVE-2021-47223 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: ubi: Fix race condition between ctrl_cdev_ioctl and ubi_cdev_ioctl Hulk Robot reported a KASAN report about use-after-free: ================================================================== BUG: KASAN: use-after-free in __list_del_entry_valid+0x13d/0x160 Read of size 8 at addr ffff888035e37d98 by task ubiattach/1385 [...] Call Trace: klist_dec_and_del+0xa7/0x4a0 klist_put+0xc7/0x1a0 device_del+0x4d4/0xed0 cdev_device_del+0x1a/0x80 ubi_attach_mtd_dev+0x2951/0x34b0 [ubi] ctrl_cdev_ioctl+0x286/0x2f0 [ubi] Allocated by task 1414: device_add+0x60a/0x18b0 cdev_device_add+0x103/0x170 ubi_create_volume+0x1118/0x1a10 [ubi] ubi_cdev_ioctl+0xb7f/0x1ba0 [ubi] Freed by task 1385: cdev_device_del+0x1a/0x80 ubi_remove_volume+0x438/0x6c0 [ubi] ubi_cdev_ioctl+0xbf4/0x1ba0 [ubi] [...] ================================================================== The lock held by ctrl_cdev_ioctl is ubi_devices_mutex, but the lock held by ubi_cdev_ioctl is ubi->device_mutex. Therefore, the two locks can be concurrent. ctrl_cdev_ioctl contains two operations: ubi_attach and ubi_detach. ubi_detach is bug-free because it uses reference counting to prevent concurrency. However, uif_init and uif_close in ubi_attach may race with ubi_cdev_ioctl. uif_init will race with ubi_cdev_ioctl as in the following stack. cpu1 cpu2 cpu3 _______________________|________________________|______________________ ctrl_cdev_ioctl ubi_attach_mtd_dev uif_init ubi_cdev_ioctl ubi_create_volume cdev_device_add ubi_add_volume // sysfs exist kill_volumes ubi_cdev_ioctl ubi_remove_volume cdev_device_del // first free ubi_free_volume cdev_del // double free cdev_device_del And uif_close will race with ubi_cdev_ioctl as in the following stack. cpu1 cpu2 cpu3 _______________________|________________________|______________________ ctrl_cdev_ioctl ubi_attach_mtd_dev uif_init ubi_cdev_ioctl ubi_create_volume cdev_device_add ubi_debugfs_init_dev //error goto out_uif; uif_close kill_volumes ubi_cdev_ioctl ubi_remove_volume cdev_device_del // first free ubi_free_volume // double free The cause of this problem is that commit 714fb87e8bc0 make device "available" before it becomes accessible via sysfs. Therefore, we roll back the modification. We will fix the race condition between ubi device creation and udev by removing ubi_get_device in vol_attribute_show and dev_attribute_show.This avoids accessing uninitialized ubi_devices[ubi_num]. ubi_get_device is used to prevent devices from being deleted during sysfs execution. However, now kernfs ensures that devices will not be deleted before all reference counting are released. The key process is shown in the following stack. device_del device_remove_attrs device_remove_groups sysfs_remove_groups sysfs_remove_group remove_files kernfs_remove_by_name kernfs_remove_by_name_ns __kernfs_remove kernfs_drain CVE-2021-47634 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: staging: media: zoran: move videodev alloc Move some code out of zr36057_init() and create new functions for handling zr->video_dev. This permit to ease code reading and fix a zr->video_dev memory leak. CVE-2021-47644 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: rtnetlink: make sure to refresh master_dev/m_ops in __rtnl_newlink() While looking at one unrelated syzbot bug, I found the replay logic in __rtnl_newlink() to potentially trigger use-after-free. It is better to clear master_dev and m_ops inside the loop, in case we have to replay it. CVE-2022-48742 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: rtc: cmos: Fix event handler registration ordering issue Because acpi_install_fixed_event_handler() enables the event automatically on success, it is incorrect to call it before the handler routine passed to it is ready to handle events. Unfortunately, the rtc-cmos driver does exactly the incorrect thing by calling cmos_wake_setup(), which passes rtc_handler() to acpi_install_fixed_event_handler(), before cmos_do_probe(), because rtc_handler() uses dev_get_drvdata() to get to the cmos object pointer and the driver data pointer is only populated in cmos_do_probe(). This leads to a NULL pointer dereference in rtc_handler() on boot if the RTC fixed event happens to be active at the init time. To address this issue, change the initialization ordering of the driver so that cmos_wake_setup() is always called after a successful cmos_do_probe() call. While at it, change cmos_pnp_probe() to call cmos_do_probe() after the initial if () statement used for computing the IRQ argument to be passed to cmos_do_probe() which is cleaner than calling it in each branch of that if () (local variable "irq" can be of type int, because it is passed to that function as an argument of type int). Note that commit 6492fed7d8c9 ("rtc: rtc-cmos: Do not check ACPI_FADT_LOW_POWER_S0") caused this issue to affect a larger number of systems, because previously it only affected systems with ACPI_FADT_LOW_POWER_S0 set, but it is present regardless of that commit. CVE-2022-48953 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: gpiolib: fix memory leak in gpiochip_setup_dev() Here is a backtrace report about memory leak detected in gpiochip_setup_dev(): unreferenced object 0xffff88810b406400 (size 512): comm "python3", pid 1682, jiffies 4295346908 (age 24.090s) backtrace: kmalloc_trace device_add device_private_init at drivers/base/core.c:3361 (inlined by) device_add at drivers/base/core.c:3411 cdev_device_add gpiolib_cdev_register gpiochip_setup_dev gpiochip_add_data_with_key gcdev_register() & gcdev_unregister() would call device_add() & device_del() (no matter CONFIG_GPIO_CDEV is enabled or not) to register/unregister device. However, if device_add() succeeds, some resource (like struct device_private allocated by device_private_init()) is not released by device_del(). Therefore, after device_add() succeeds by gcdev_register(), it needs to call put_device() to release resource in the error handle path. Here we move forward the register of release function, and let it release every piece of resource by put_device() instead of kfree(). While at it, fix another subtle issue, i.e. when gc->ngpio is equal to 0, we still call kcalloc() and, in case of further error, kfree() on the ZERO_PTR pointer, which is not NULL. It's not a bug per se, but rather waste of the resources and potentially wrong expectation about contents of the gdev->descs variable. CVE-2022-48975 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: tracing: Free buffers when a used dynamic event is removed After 65536 dynamic events have been added and removed, the "type" field of the event then uses the first type number that is available (not currently used by other events). A type number is the identifier of the binary blobs in the tracing ring buffer (known as events) to map them to logic that can parse the binary blob. The issue is that if a dynamic event (like a kprobe event) is traced and is in the ring buffer, and then that event is removed (because it is dynamic, which means it can be created and destroyed), if another dynamic event is created that has the same number that new event's logic on parsing the binary blob will be used. To show how this can be an issue, the following can crash the kernel: # cd /sys/kernel/tracing # for i in `seq 65536`; do echo 'p:kprobes/foo do_sys_openat2 $arg1:u32' > kprobe_events # done For every iteration of the above, the writing to the kprobe_events will remove the old event and create a new one (with the same format) and increase the type number to the next available on until the type number reaches over 65535 which is the max number for the 16 bit type. After it reaches that number, the logic to allocate a new number simply looks for the next available number. When an dynamic event is removed, that number is then available to be reused by the next dynamic event created. That is, once the above reaches the max number, the number assigned to the event in that loop will remain the same. Now that means deleting one dynamic event and created another will reuse the previous events type number. This is where bad things can happen. After the above loop finishes, the kprobes/foo event which reads the do_sys_openat2 function call's first parameter as an integer. # echo 1 > kprobes/foo/enable # cat /etc/passwd > /dev/null # cat trace cat-2211 [005] .... 2007.849603: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849620: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849838: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849880: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 # echo 0 > kprobes/foo/enable Now if we delete the kprobe and create a new one that reads a string: # echo 'p:kprobes/foo do_sys_openat2 +0($arg2):string' > kprobe_events And now we can the trace: # cat trace sendmail-1942 [002] ..... 530.136320: foo: (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.930817: foo: (do_sys_openat2+0x0/0x240) arg1="������������������������������������������������������������������������������������������������" cat-2046 [004] ..... 530.930961: foo: (do_sys_openat2+0x0/0x240) arg1="������������������������������������������������������������������������������������������������" cat-2046 [004] ..... 530.934278: foo: (do_sys_openat2+0x0/0x240) arg1="������������������������������������������������������������������������������������������������" cat-2046 [004] ..... 530.934563: foo: (do_sys_openat2+0x0/0x240) arg1="��������������������������������������� ---truncated--- CVE-2022-49006 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: btrfs: qgroup: fix sleep from invalid context bug in btrfs_qgroup_inherit() Syzkaller reported BUG as follows: BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274 Call Trace: <TASK> dump_stack_lvl+0xcd/0x134 __might_resched.cold+0x222/0x26b kmem_cache_alloc+0x2e7/0x3c0 update_qgroup_limit_item+0xe1/0x390 btrfs_qgroup_inherit+0x147b/0x1ee0 create_subvol+0x4eb/0x1710 btrfs_mksubvol+0xfe5/0x13f0 __btrfs_ioctl_snap_create+0x2b0/0x430 btrfs_ioctl_snap_create_v2+0x25a/0x520 btrfs_ioctl+0x2a1c/0x5ce0 __x64_sys_ioctl+0x193/0x200 do_syscall_64+0x35/0x80 Fix this by calling qgroup_dirty() on @dstqgroup, and update limit item in btrfs_run_qgroups() later outside of the spinlock context. CVE-2022-49033 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: s5p_cec: limit msg.len to CEC_MAX_MSG_SIZE I expect that the hardware will have limited this to 16, but just in case it hasn't, check for this corner case. CVE-2022-49035 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 important xmlXIncludeAddNode in xinclude.c in libxml2 before 2.11.0 has a use-after-free. CVE-2022-49043 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:libxml2-2-2.9.4-46.81.1 important In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Fix use-after-free bug for mm struct Under certain conditions, such as MPI_Abort, the hfi1 cleanup code may represent the last reference held on the task mm. hfi1_mmu_rb_unregister() then drops the last reference and the mm is freed before the final use in hfi1_release_user_pages(). A new task may allocate the mm structure while it is still being used, resulting in problems. One manifestation is corruption of the mmap_sem counter leading to a hang in down_write(). Another is corruption of an mm struct that is in use by another task. CVE-2022-49076 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: mm/mempolicy: fix mpol_new leak in shared_policy_replace If mpol_new is allocated but not used in restart loop, mpol_new will be freed via mpol_put before returning to the caller. But refcnt is not initialized yet, so mpol_put could not do the right things and might leak the unused mpol_new. This would happen if mempolicy was updated on the shared shmem file while the sp->lock has been dropped during the memory allocation. This issue could be triggered easily with the below code snippet if there are many processes doing the below work at the same time: shmid = shmget((key_t)5566, 1024 * PAGE_SIZE, 0666|IPC_CREAT); shm = shmat(shmid, 0, 0); loop many times { mbind(shm, 1024 * PAGE_SIZE, MPOL_LOCAL, mask, maxnode, 0); mbind(shm + 128 * PAGE_SIZE, 128 * PAGE_SIZE, MPOL_DEFAULT, mask, maxnode, 0); } CVE-2022-49080 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 important In the Linux kernel, the following vulnerability has been resolved: IB/rdmavt: add lock to call to rvt_error_qp to prevent a race condition The documentation of the function rvt_error_qp says both r_lock and s_lock need to be held when calling that function. It also asserts using lockdep that both of those locks are held. However, the commit I referenced in Fixes accidentally makes the call to rvt_error_qp in rvt_ruc_loopback no longer covered by r_lock. This results in the lockdep assertion failing and also possibly in a race condition. CVE-2022-49089 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: x86/mce: Work around an erratum on fast string copy instructions A rare kernel panic scenario can happen when the following conditions are met due to an erratum on fast string copy instructions: 1) An uncorrected error. 2) That error must be in first cache line of a page. 3) Kernel must execute page_copy from the page immediately before that page. The fast string copy instructions ("REP; MOVS*") could consume an uncorrectable memory error in the cache line _right after_ the desired region to copy and raise an MCE. Bit 0 of MSR_IA32_MISC_ENABLE can be cleared to disable fast string copy and will avoid such spurious machine checks. However, that is less preferable due to the permanent performance impact. Considering memory poison is rare, it's desirable to keep fast string copy enabled until an MCE is seen. Intel has confirmed the following: 1. The CPU erratum of fast string copy only applies to Skylake, Cascade Lake and Cooper Lake generations. Directly return from the MCE handler: 2. Will result in complete execution of the "REP; MOVS*" with no data loss or corruption. 3. Will not result in another MCE firing on the next poisoned cache line due to "REP; MOVS*". 4. Will resume execution from a correct point in code. 5. Will result in the same instruction that triggered the MCE firing a second MCE immediately for any other software recoverable data fetch errors. 6. Is not safe without disabling the fast string copy, as the next fast string copy of the same buffer on the same CPU would result in a PANIC MCE. This should mitigate the erratum completely with the only caveat that the fast string copy is disabled on the affected hyper thread thus performance degradation. This is still better than the OS crashing on MCEs raised on an irrelevant process due to "REP; MOVS*' accesses in a kernel context, e.g., copy_page. Injected errors on 1st cache line of 8 anonymous pages of process 'proc1' and observed MCE consumption from 'proc2' with no panic (directly returned). Without the fix, the host panicked within a few minutes on a random 'proc2' process due to kernel access from copy_page. [ bp: Fix comment style + touch ups, zap an unlikely(), improve the quirk function's readability. ] CVE-2022-49124 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum: Guard against invalid local ports When processing events generated by the device's firmware, the driver protects itself from events reported for non-existent local ports, but not for the CPU port (local port 0), which exists, but does not have all the fields as any local port. This can result in a NULL pointer dereference when trying access 'struct mlxsw_sp_port' fields which are not initialized for CPU port. Commit 63b08b1f6834 ("mlxsw: spectrum: Protect driver from buggy firmware") already handled such issue by bailing early when processing a PUDE event reported for the CPU port. Generalize the approach by moving the check to a common function and making use of it in all relevant places. CVE-2022-49134 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix memory leak [why] Resource release is needed on the error handling path to prevent memory leak. [how] Fix this by adding kfree on the error handling path. CVE-2022-49135 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: can: mcba_usb: properly check endpoint type Syzbot reported warning in usb_submit_urb() which is caused by wrong endpoint type. We should check that in endpoint is actually present to prevent this warning. Found pipes are now saved to struct mcba_priv and code uses them directly instead of making pipes in place. Fail log: | usb 5-1: BOGUS urb xfer, pipe 3 != type 1 | WARNING: CPU: 1 PID: 49 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 | Modules linked in: | CPU: 1 PID: 49 Comm: kworker/1:2 Not tainted 5.17.0-rc6-syzkaller-00184-g38f80f42147f #0 | Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 | Workqueue: usb_hub_wq hub_event | RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 | ... | Call Trace: | <TASK> | mcba_usb_start drivers/net/can/usb/mcba_usb.c:662 [inline] | mcba_usb_probe+0x8a3/0xc50 drivers/net/can/usb/mcba_usb.c:858 | usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396 | call_driver_probe drivers/base/dd.c:517 [inline] CVE-2022-49151 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: memstick/mspro_block: fix handling of read-only devices Use set_disk_ro to propagate the read-only state to the block layer instead of checking for it in ->open and leaking a reference in case of a read-only device. CVE-2022-49178 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: hns3: add vlan list lock to protect vlan list When adding port base VLAN, vf VLAN need to remove from HW and modify the vlan state in vf VLAN list as false. If the periodicity task is freeing the same node, it may cause "use after free" error. This patch adds a vlan list lock to protect the vlan list. CVE-2022-49182 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: ibmvnic: fix race between xmit and reset There is a race between reset and the transmit paths that can lead to ibmvnic_xmit() accessing an scrq after it has been freed in the reset path. It can result in a crash like: Kernel attempted to read user page (0) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000000 Faulting instruction address: 0xc0080000016189f8 Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c0080000016189f8] ibmvnic_xmit+0x60/0xb60 [ibmvnic] LR [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280 Call Trace: [c008000001618f08] ibmvnic_xmit+0x570/0xb60 [ibmvnic] (unreliable) [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280 [c000000000c9cfcc] sch_direct_xmit+0xec/0x330 [c000000000bfe640] __dev_xmit_skb+0x3a0/0x9d0 [c000000000c00ad4] __dev_queue_xmit+0x394/0x730 [c008000002db813c] __bond_start_xmit+0x254/0x450 [bonding] [c008000002db8378] bond_start_xmit+0x40/0xc0 [bonding] [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280 [c000000000c00ca4] __dev_queue_xmit+0x564/0x730 [c000000000cf97e0] neigh_hh_output+0xd0/0x180 [c000000000cfa69c] ip_finish_output2+0x31c/0x5c0 [c000000000cfd244] __ip_queue_xmit+0x194/0x4f0 [c000000000d2a3c4] __tcp_transmit_skb+0x434/0x9b0 [c000000000d2d1e0] __tcp_retransmit_skb+0x1d0/0x6a0 [c000000000d2d984] tcp_retransmit_skb+0x34/0x130 [c000000000d310e8] tcp_retransmit_timer+0x388/0x6d0 [c000000000d315ec] tcp_write_timer_handler+0x1bc/0x330 [c000000000d317bc] tcp_write_timer+0x5c/0x200 [c000000000243270] call_timer_fn+0x50/0x1c0 [c000000000243704] __run_timers.part.0+0x324/0x460 [c000000000243894] run_timer_softirq+0x54/0xa0 [c000000000ea713c] __do_softirq+0x15c/0x3e0 [c000000000166258] __irq_exit_rcu+0x158/0x190 [c000000000166420] irq_exit+0x20/0x40 [c00000000002853c] timer_interrupt+0x14c/0x2b0 [c000000000009a00] decrementer_common_virt+0x210/0x220 --- interrupt: 900 at plpar_hcall_norets_notrace+0x18/0x2c The immediate cause of the crash is the access of tx_scrq in the following snippet during a reset, where the tx_scrq can be either NULL or an address that will soon be invalid: ibmvnic_xmit() { ... tx_scrq = adapter->tx_scrq[queue_num]; txq = netdev_get_tx_queue(netdev, queue_num); ind_bufp = &tx_scrq->ind_buf; if (test_bit(0, &adapter->resetting)) { ... } But beyond that, the call to ibmvnic_xmit() itself is not safe during a reset and the reset path attempts to avoid this by stopping the queue in ibmvnic_cleanup(). However just after the queue was stopped, an in-flight ibmvnic_complete_tx() could have restarted the queue even as the reset is progressing. Since the queue was restarted we could get a call to ibmvnic_xmit() which can then access the bad tx_scrq (or other fields). We cannot however simply have ibmvnic_complete_tx() check the ->resetting bit and skip starting the queue. This can race at the "back-end" of a good reset which just restarted the queue but has not cleared the ->resetting bit yet. If we skip restarting the queue due to ->resetting being true, the queue would remain stopped indefinitely potentially leading to transmit timeouts. IOW ->resetting is too broad for this purpose. Instead use a new flag that indicates whether or not the queues are active. Only the open/ reset paths control when the queues are active. ibmvnic_complete_tx() and others wake up the queue only if the queue is marked active. So we will have: A. reset/open thread in ibmvnic_cleanup() and __ibmvnic_open() ->resetting = true ->tx_queues_active = false disable tx queues ... ->tx_queues_active = true start tx queues B. Tx interrupt in ibmvnic_complete_tx(): if (->tx_queues_active) netif_wake_subqueue(); To ensure that ->tx_queues_active and state of the queues are consistent, we need a lock which: - must also be taken in the interrupt path (ibmvnic_complete_tx()) - shared across the multiple ---truncated--- CVE-2022-49201 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: stk1160: If start stream fails, return buffers with VB2_BUF_STATE_QUEUED If the callback 'start_streaming' fails, then all queued buffers in the driver should be returned with state 'VB2_BUF_STATE_QUEUED'. Currently, they are returned with 'VB2_BUF_STATE_ERROR' which is wrong. Fix this. This also fixes the warning: [ 65.583633] WARNING: CPU: 5 PID: 593 at drivers/media/common/videobuf2/videobuf2-core.c:1612 vb2_start_streaming+0xd4/0x160 [videobuf2_common] [ 65.585027] Modules linked in: snd_usb_audio snd_hwdep snd_usbmidi_lib snd_rawmidi snd_soc_hdmi_codec dw_hdmi_i2s_audio saa7115 stk1160 videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc crct10dif_ce panfrost snd_soc_simple_card snd_soc_audio_graph_card snd_soc_spdif_tx snd_soc_simple_card_utils gpu_sched phy_rockchip_pcie snd_soc_rockchip_i2s rockchipdrm analogix_dp dw_mipi_dsi dw_hdmi cec drm_kms_helper drm rtc_rk808 rockchip_saradc industrialio_triggered_buffer kfifo_buf rockchip_thermal pcie_rockchip_host ip_tables x_tables ipv6 [ 65.589383] CPU: 5 PID: 593 Comm: v4l2src0:src Tainted: G W 5.16.0-rc4-62408-g32447129cb30-dirty #14 [ 65.590293] Hardware name: Radxa ROCK Pi 4B (DT) [ 65.590696] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 65.591304] pc : vb2_start_streaming+0xd4/0x160 [videobuf2_common] [ 65.591850] lr : vb2_start_streaming+0x6c/0x160 [videobuf2_common] [ 65.592395] sp : ffff800012bc3ad0 [ 65.592685] x29: ffff800012bc3ad0 x28: 0000000000000000 x27: ffff800012bc3cd8 [ 65.593312] x26: 0000000000000000 x25: ffff00000d8a7800 x24: 0000000040045612 [ 65.593938] x23: ffff800011323000 x22: ffff800012bc3cd8 x21: ffff00000908a8b0 [ 65.594562] x20: ffff00000908a8c8 x19: 00000000fffffff4 x18: ffffffffffffffff [ 65.595188] x17: 000000040044ffff x16: 00400034b5503510 x15: ffff800011323f78 [ 65.595813] x14: ffff000013163886 x13: ffff000013163885 x12: 00000000000002ce [ 65.596439] x11: 0000000000000028 x10: 0000000000000001 x9 : 0000000000000228 [ 65.597064] x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff726c5e78 [ 65.597690] x5 : ffff800012bc3990 x4 : 0000000000000000 x3 : ffff000009a34880 [ 65.598315] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000007cd99f0 [ 65.598940] Call trace: [ 65.599155] vb2_start_streaming+0xd4/0x160 [videobuf2_common] [ 65.599672] vb2_core_streamon+0x17c/0x1a8 [videobuf2_common] [ 65.600179] vb2_streamon+0x54/0x88 [videobuf2_v4l2] [ 65.600619] vb2_ioctl_streamon+0x54/0x60 [videobuf2_v4l2] [ 65.601103] v4l_streamon+0x3c/0x50 [videodev] [ 65.601521] __video_do_ioctl+0x1a4/0x428 [videodev] [ 65.601977] video_usercopy+0x320/0x828 [videodev] [ 65.602419] video_ioctl2+0x3c/0x58 [videodev] [ 65.602830] v4l2_ioctl+0x60/0x90 [videodev] [ 65.603227] __arm64_sys_ioctl+0xa8/0xe0 [ 65.603576] invoke_syscall+0x54/0x118 [ 65.603911] el0_svc_common.constprop.3+0x84/0x100 [ 65.604332] do_el0_svc+0x34/0xa0 [ 65.604625] el0_svc+0x1c/0x50 [ 65.604897] el0t_64_sync_handler+0x88/0xb0 [ 65.605264] el0t_64_sync+0x16c/0x170 [ 65.605587] ---[ end trace 578e0ba07742170d ]--- CVE-2022-49247 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/msm/mdp5: Return error code in mdp5_pipe_release when deadlock is detected mdp5_get_global_state runs the risk of hitting a -EDEADLK when acquiring the modeset lock, but currently mdp5_pipe_release doesn't check for if an error is returned. Because of this, there is a possibility of mdp5_pipe_release hitting a NULL dereference error. To avoid this, let's have mdp5_pipe_release check if mdp5_get_global_state returns an error and propogate that error. Changes since v1: - Separated declaration and initialization of *new_state to avoid compiler warning - Fixed some spelling mistakes in commit message Changes since v2: - Return 0 in case where hwpipe is NULL as this is considered normal behavior - Added 2nd patch in series to fix a similar NULL dereference issue in mdp5_mixer_release Patchwork: https://patchwork.freedesktop.org/patch/485179/ CVE-2022-49490 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: sfc: fix use after free when disabling sriov Use after free is detected by kfence when disabling sriov. What was read after being freed was vf->pci_dev: it was freed from pci_disable_sriov and later read in efx_ef10_sriov_free_vf_vports, called from efx_ef10_sriov_free_vf_vswitching. Set the pointer to NULL at release time to not trying to read it later. Reproducer and dmesg log (note that kfence doesn't detect it every time): $ echo 1 > /sys/class/net/enp65s0f0np0/device/sriov_numvfs $ echo 0 > /sys/class/net/enp65s0f0np0/device/sriov_numvfs BUG: KFENCE: use-after-free read in efx_ef10_sriov_free_vf_vswitching+0x82/0x170 [sfc] Use-after-free read at 0x00000000ff3c1ba5 (in kfence-#224): efx_ef10_sriov_free_vf_vswitching+0x82/0x170 [sfc] efx_ef10_pci_sriov_disable+0x38/0x70 [sfc] efx_pci_sriov_configure+0x24/0x40 [sfc] sriov_numvfs_store+0xfe/0x140 kernfs_fop_write_iter+0x11c/0x1b0 new_sync_write+0x11f/0x1b0 vfs_write+0x1eb/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x5c/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae kfence-#224: 0x00000000edb8ef95-0x00000000671f5ce1, size=2792, cache=kmalloc-4k allocated by task 6771 on cpu 10 at 3137.860196s: pci_alloc_dev+0x21/0x60 pci_iov_add_virtfn+0x2a2/0x320 sriov_enable+0x212/0x3e0 efx_ef10_sriov_configure+0x67/0x80 [sfc] efx_pci_sriov_configure+0x24/0x40 [sfc] sriov_numvfs_store+0xba/0x140 kernfs_fop_write_iter+0x11c/0x1b0 new_sync_write+0x11f/0x1b0 vfs_write+0x1eb/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x5c/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae freed by task 6771 on cpu 12 at 3170.991309s: device_release+0x34/0x90 kobject_cleanup+0x3a/0x130 pci_iov_remove_virtfn+0xd9/0x120 sriov_disable+0x30/0xe0 efx_ef10_pci_sriov_disable+0x57/0x70 [sfc] efx_pci_sriov_configure+0x24/0x40 [sfc] sriov_numvfs_store+0xfe/0x140 kernfs_fop_write_iter+0x11c/0x1b0 new_sync_write+0x11f/0x1b0 vfs_write+0x1eb/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x5c/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae CVE-2022-49626 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_open/close(): fix memory leak The gs_usb driver appears to suffer from a malady common to many USB CAN adapter drivers in that it performs usb_alloc_coherent() to allocate a number of USB request blocks (URBs) for RX, and then later relies on usb_kill_anchored_urbs() to free them, but this doesn't actually free them. As a result, this may be leaking DMA memory that's been used by the driver. This commit is an adaptation of the techniques found in the esd_usb2 driver where a similar design pattern led to a memory leak. It explicitly frees the RX URBs and their DMA memory via a call to usb_free_coherent(). Since the RX URBs were allocated in the gs_can_open(), we remove them in gs_can_close() rather than in the disconnect function as was done in esd_usb2. For more information, see the 928150fad41b ("can: esd_usb2: fix memory leak"). CVE-2022-49661 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate Under some circumstances, this weakness allows a user who has access to run the "ps" utility on a machine, the ability to write almost unlimited amounts of unfiltered data into the process heap. CVE-2023-4016 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:libprocps3-3.3.9-11.33.1 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:procps-3.3.9-11.33.1 low In the Linux kernel, the following vulnerability has been resolved: cifs: Fix UAF in cifs_demultiplex_thread() There is a UAF when xfstests on cifs: BUG: KASAN: use-after-free in smb2_is_network_name_deleted+0x27/0x160 Read of size 4 at addr ffff88810103fc08 by task cifsd/923 CPU: 1 PID: 923 Comm: cifsd Not tainted 6.1.0-rc4+ #45 ... Call Trace: <TASK> dump_stack_lvl+0x34/0x44 print_report+0x171/0x472 kasan_report+0xad/0x130 kasan_check_range+0x145/0x1a0 smb2_is_network_name_deleted+0x27/0x160 cifs_demultiplex_thread.cold+0x172/0x5a4 kthread+0x165/0x1a0 ret_from_fork+0x1f/0x30 </TASK> Allocated by task 923: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 __kasan_slab_alloc+0x54/0x60 kmem_cache_alloc+0x147/0x320 mempool_alloc+0xe1/0x260 cifs_small_buf_get+0x24/0x60 allocate_buffers+0xa1/0x1c0 cifs_demultiplex_thread+0x199/0x10d0 kthread+0x165/0x1a0 ret_from_fork+0x1f/0x30 Freed by task 921: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x2a/0x40 ____kasan_slab_free+0x143/0x1b0 kmem_cache_free+0xe3/0x4d0 cifs_small_buf_release+0x29/0x90 SMB2_negotiate+0x8b7/0x1c60 smb2_negotiate+0x51/0x70 cifs_negotiate_protocol+0xf0/0x160 cifs_get_smb_ses+0x5fa/0x13c0 mount_get_conns+0x7a/0x750 cifs_mount+0x103/0xd00 cifs_smb3_do_mount+0x1dd/0xcb0 smb3_get_tree+0x1d5/0x300 vfs_get_tree+0x41/0xf0 path_mount+0x9b3/0xdd0 __x64_sys_mount+0x190/0x1d0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 The UAF is because: mount(pid: 921) | cifsd(pid: 923) -------------------------------|------------------------------- | cifs_demultiplex_thread SMB2_negotiate | cifs_send_recv | compound_send_recv | smb_send_rqst | wait_for_response | wait_event_state [1] | | standard_receive3 | cifs_handle_standard | handle_mid | mid->resp_buf = buf; [2] | dequeue_mid [3] KILL the process [4] | resp_iov[i].iov_base = buf | free_rsp_buf [5] | | is_network_name_deleted [6] | callback 1. After send request to server, wait the response until mid->mid_state != SUBMITTED; 2. Receive response from server, and set it to mid; 3. Set the mid state to RECEIVED; 4. Kill the process, the mid state already RECEIVED, get 0; 5. Handle and release the negotiate response; 6. UAF. It can be easily reproduce with add some delay in [3] - [6]. Only sync call has the problem since async call's callback is executed in cifsd process. Add an extra state to mark the mid state to READY before wakeup the waitter, then it can get the resp safely. CVE-2023-52572 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: hid: cp2112: Fix duplicate workqueue initialization Previously the cp2112 driver called INIT_DELAYED_WORK within cp2112_gpio_irq_startup, resulting in duplicate initilizations of the workqueue on subsequent IRQ startups following an initial request. This resulted in a warning in set_work_data in workqueue.c, as well as a rare NULL dereference within process_one_work in workqueue.c. Initialize the workqueue within _probe instead. CVE-2023-52853 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: can: bcm: Fix UAF in bcm_proc_show() BUG: KASAN: slab-use-after-free in bcm_proc_show+0x969/0xa80 Read of size 8 at addr ffff888155846230 by task cat/7862 CPU: 1 PID: 7862 Comm: cat Not tainted 6.5.0-rc1-00153-gc8746099c197 #230 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0xd5/0x150 print_report+0xc1/0x5e0 kasan_report+0xba/0xf0 bcm_proc_show+0x969/0xa80 seq_read_iter+0x4f6/0x1260 seq_read+0x165/0x210 proc_reg_read+0x227/0x300 vfs_read+0x1d5/0x8d0 ksys_read+0x11e/0x240 do_syscall_64+0x35/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd Allocated by task 7846: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 __kasan_kmalloc+0x9e/0xa0 bcm_sendmsg+0x264b/0x44e0 sock_sendmsg+0xda/0x180 ____sys_sendmsg+0x735/0x920 ___sys_sendmsg+0x11d/0x1b0 __sys_sendmsg+0xfa/0x1d0 do_syscall_64+0x35/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd Freed by task 7846: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x27/0x40 ____kasan_slab_free+0x161/0x1c0 slab_free_freelist_hook+0x119/0x220 __kmem_cache_free+0xb4/0x2e0 rcu_core+0x809/0x1bd0 bcm_op is freed before procfs entry be removed in bcm_release(), this lead to bcm_proc_show() may read the freed bcm_op. CVE-2023-52922 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: don't skip expired elements during walk There is an asymmetry between commit/abort and preparation phase if the following conditions are met: 1. set is a verdict map ("1.2.3.4 : jump foo") 2. timeouts are enabled In this case, following sequence is problematic: 1. element E in set S refers to chain C 2. userspace requests removal of set S 3. kernel does a set walk to decrement chain->use count for all elements from preparation phase 4. kernel does another set walk to remove elements from the commit phase (or another walk to do a chain->use increment for all elements from abort phase) If E has already expired in 1), it will be ignored during list walk, so its use count won't have been changed. Then, when set is culled, ->destroy callback will zap the element via nf_tables_set_elem_destroy(), but this function is only safe for elements that have been deactivated earlier from the preparation phase: lack of earlier deactivate removes the element but leaks the chain use count, which results in a WARN splat when the chain gets removed later, plus a leak of the nft_chain structure. Update pipapo_get() not to skip expired elements, otherwise flush command reports bogus ENOENT errors. CVE-2023-52924 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 important 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. CVE-2024-11168 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:libpython2_7-1_0-2.7.18-33.47.1 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:python-2.7.18-33.47.1 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:python-base-2.7.18-33.47.1 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:python-xml-2.7.18-33.47.1 low It is possible to construct a zone such that some queries to it will generate responses containing numerous records in the Additional section. An attacker sending many such queries can cause either the authoritative server itself or an independent resolver to use disproportionate resources processing the queries. Zones will usually need to have been deliberately crafted to attack this exposure. This issue affects BIND 9 versions 9.11.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.32, 9.20.0 through 9.20.4, 9.21.0 through 9.21.3, 9.11.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.32-S1. CVE-2024-11187 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:bind-utils-9.11.22-3.60.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:libbind9-161-9.11.22-3.60.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:libdns1110-9.11.22-3.60.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:libirs161-9.11.22-3.60.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:libisc1107-9.11.22-3.60.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:libisccc161-9.11.22-3.60.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:libisccfg163-9.11.22-3.60.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:liblwres161-9.11.22-3.60.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:python-bind-9.11.22-3.60.2 important A flaw was found in rsync which could be triggered when rsync compares file checksums. This flaw allows an attacker to manipulate the checksum length (s2length) to cause a comparison between a checksum and uninitialized memory and leak one byte of uninitialized stack data at a time. CVE-2024-12085 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:rsync-3.1.3-3.25.2 moderate A flaw was found in rsync. It could allow a server to enumerate the contents of an arbitrary file from the client's machine. This issue occurs when files are being copied from a client to a server. During this process, the rsync server will send checksums of local data to the client to compare with in order to determine what data needs to be sent to the server. By sending specially constructed checksum values for arbitrary files, an attacker may be able to reconstruct the data of those files byte-by-byte based on the responses from the client. CVE-2024-12086 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:rsync-3.1.3-3.25.2 moderate A path traversal vulnerability exists in rsync. It stems from behavior enabled by the `--inc-recursive` option, a default-enabled option for many client options and can be enabled by the server even if not explicitly enabled by the client. When using the `--inc-recursive` option, a lack of proper symlink verification coupled with deduplication checks occurring on a per-file-list basis could allow a server to write files outside of the client's intended destination directory. A malicious server could write malicious files to arbitrary locations named after valid directories/paths on the client. CVE-2024-12087 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:rsync-3.1.3-3.25.2 important A flaw was found in rsync. When using the `--safe-links` option, the rsync client fails to properly verify if a symbolic link destination sent from the server contains another symbolic link within it. This results in a path traversal vulnerability, which may lead to arbitrary file write outside the desired directory. CVE-2024-12088 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:rsync-3.1.3-3.25.2 moderate A flaw in libtasn1 causes inefficient handling of specific certificate data. When processing a large number of elements in a certificate, libtasn1 takes much longer than expected, which can slow down or even crash the system. This flaw allows an attacker to send a specially crafted certificate, causing a denial of service attack. CVE-2024-12133 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:libtasn1-4.9-3.16.1 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:libtasn1-6-4.9-3.16.1 important A flaw was found in GnuTLS, which relies on libtasn1 for ASN.1 data processing. Due to an inefficient algorithm in libtasn1, decoding certain DER-encoded certificate data can take excessive time, leading to increased resource consumption. This flaw allows a remote attacker to send a specially crafted certificate, causing GnuTLS to become unresponsive or slow, resulting in a denial-of-service condition. CVE-2024-12243 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:libgnutls30-3.4.17-8.17.1 moderate A flaw was found in rsync. This vulnerability arises from a race condition during rsync's handling of symbolic links. Rsync's default behavior when encountering symbolic links is to skip them. If an attacker replaced a regular file with a symbolic link at the right time, it was possible to bypass the default behavior and traverse symbolic links. Depending on the privileges of the rsync process, an attacker could leak sensitive information, potentially leading to privilege escalation. CVE-2024-12747 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:rsync-3.1.3-3.25.2 moderate Issue summary: A timing side-channel which could potentially allow recovering the private key exists in the ECDSA signature computation. Impact summary: A timing side-channel in ECDSA signature computations could allow recovering the private key by an attacker. However, measuring the timing would require either local access to the signing application or a very fast network connection with low latency. There is a timing signal of around 300 nanoseconds when the top word of the inverted ECDSA nonce value is zero. This can happen with significant probability only for some of the supported elliptic curves. In particular the NIST P-521 curve is affected. To be able to measure this leak, the attacker process must either be located in the same physical computer or must have a very fast network connection with low latency. For that reason the severity of this vulnerability is Low. The FIPS modules in 3.4, 3.3, 3.2, 3.1 and 3.0 are affected by this issue. CVE-2024-13176 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:libopenssl1_1-1.1.1d-2.116.1 moderate The various Is methods (IsPrivate, IsLoopback, etc) did not work as expected for IPv4-mapped IPv6 addresses, returning false for addresses which would return true in their traditional IPv4 forms. CVE-2024-24790 moderate In the Linux kernel, the following vulnerability has been resolved: btrfs: don't abort filesystem when attempting to snapshot deleted subvolume If the source file descriptor to the snapshot ioctl refers to a deleted subvolume, we get the following abort: BTRFS: Transaction aborted (error -2) WARNING: CPU: 0 PID: 833 at fs/btrfs/transaction.c:1875 create_pending_snapshot+0x1040/0x1190 [btrfs] Modules linked in: pata_acpi btrfs ata_piix libata scsi_mod virtio_net blake2b_generic xor net_failover virtio_rng failover scsi_common rng_core raid6_pq libcrc32c CPU: 0 PID: 833 Comm: t_snapshot_dele Not tainted 6.7.0-rc6 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014 RIP: 0010:create_pending_snapshot+0x1040/0x1190 [btrfs] RSP: 0018:ffffa09c01337af8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff9982053e7c78 RCX: 0000000000000027 RDX: ffff99827dc20848 RSI: 0000000000000001 RDI: ffff99827dc20840 RBP: ffffa09c01337c00 R08: 0000000000000000 R09: ffffa09c01337998 R10: 0000000000000003 R11: ffffffffb96da248 R12: fffffffffffffffe R13: ffff99820535bb28 R14: ffff99820b7bd000 R15: ffff99820381ea80 FS: 00007fe20aadabc0(0000) GS:ffff99827dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000559a120b502f CR3: 00000000055b6000 CR4: 00000000000006f0 Call Trace: <TASK> ? create_pending_snapshot+0x1040/0x1190 [btrfs] ? __warn+0x81/0x130 ? create_pending_snapshot+0x1040/0x1190 [btrfs] ? report_bug+0x171/0x1a0 ? handle_bug+0x3a/0x70 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? create_pending_snapshot+0x1040/0x1190 [btrfs] ? create_pending_snapshot+0x1040/0x1190 [btrfs] create_pending_snapshots+0x92/0xc0 [btrfs] btrfs_commit_transaction+0x66b/0xf40 [btrfs] btrfs_mksubvol+0x301/0x4d0 [btrfs] btrfs_mksnapshot+0x80/0xb0 [btrfs] __btrfs_ioctl_snap_create+0x1c2/0x1d0 [btrfs] btrfs_ioctl_snap_create_v2+0xc4/0x150 [btrfs] btrfs_ioctl+0x8a6/0x2650 [btrfs] ? kmem_cache_free+0x22/0x340 ? do_sys_openat2+0x97/0xe0 __x64_sys_ioctl+0x97/0xd0 do_syscall_64+0x46/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 RIP: 0033:0x7fe20abe83af RSP: 002b:00007ffe6eff1360 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fe20abe83af RDX: 00007ffe6eff23c0 RSI: 0000000050009417 RDI: 0000000000000003 RBP: 0000000000000003 R08: 0000000000000000 R09: 00007fe20ad16cd0 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffe6eff13c0 R14: 00007fe20ad45000 R15: 0000559a120b6d58 </TASK> ---[ end trace 0000000000000000 ]--- BTRFS: error (device vdc: state A) in create_pending_snapshot:1875: errno=-2 No such entry BTRFS info (device vdc: state EA): forced readonly BTRFS warning (device vdc: state EA): Skipping commit of aborted transaction. BTRFS: error (device vdc: state EA) in cleanup_transaction:2055: errno=-2 No such entry This happens because create_pending_snapshot() initializes the new root item as a copy of the source root item. This includes the refs field, which is 0 for a deleted subvolume. The call to btrfs_insert_root() therefore inserts a root with refs == 0. btrfs_get_new_fs_root() then finds the root and returns -ENOENT if refs == 0, which causes create_pending_snapshot() to abort. Fix it by checking the source root's refs before attempting the snapshot, but after locking subvol_sem to avoid racing with deletion. CVE-2024-26644 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Lock external INTx masking ops Mask operations through config space changes to DisINTx may race INTx configuration changes via ioctl. Create wrappers that add locking for paths outside of the core interrupt code. In particular, irq_type is updated holding igate, therefore testing is_intx() requires holding igate. For example clearing DisINTx from config space can otherwise race changes of the interrupt configuration. This aligns interfaces which may trigger the INTx eventfd into two camps, one side serialized by igate and the other only enabled while INTx is configured. A subsequent patch introduces synchronization for the latter flows. CVE-2024-26810 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: KVM: Always flush async #PF workqueue when vCPU is being destroyed Always flush the per-vCPU async #PF workqueue when a vCPU is clearing its completion queue, e.g. when a VM and all its vCPUs is being destroyed. KVM must ensure that none of its workqueue callbacks is running when the last reference to the KVM _module_ is put. Gifting a reference to the associated VM prevents the workqueue callback from dereferencing freed vCPU/VM memory, but does not prevent the KVM module from being unloaded before the callback completes. Drop the misguided VM refcount gifting, as calling kvm_put_kvm() from async_pf_execute() if kvm_put_kvm() flushes the async #PF workqueue will result in deadlock. async_pf_execute() can't return until kvm_put_kvm() finishes, and kvm_put_kvm() can't return until async_pf_execute() finishes: WARNING: CPU: 8 PID: 251 at virt/kvm/kvm_main.c:1435 kvm_put_kvm+0x2d/0x320 [kvm] Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel kvm irqbypass CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Workqueue: events async_pf_execute [kvm] RIP: 0010:kvm_put_kvm+0x2d/0x320 [kvm] Call Trace: <TASK> async_pf_execute+0x198/0x260 [kvm] process_one_work+0x145/0x2d0 worker_thread+0x27e/0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 </TASK> ---[ end trace 0000000000000000 ]--- INFO: task kworker/8:1:251 blocked for more than 120 seconds. Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/8:1 state:D stack:0 pid:251 ppid:2 flags:0x00004000 Workqueue: events async_pf_execute [kvm] Call Trace: <TASK> __schedule+0x33f/0xa40 schedule+0x53/0xc0 schedule_timeout+0x12a/0x140 __wait_for_common+0x8d/0x1d0 __flush_work.isra.0+0x19f/0x2c0 kvm_clear_async_pf_completion_queue+0x129/0x190 [kvm] kvm_arch_destroy_vm+0x78/0x1b0 [kvm] kvm_put_kvm+0x1c1/0x320 [kvm] async_pf_execute+0x198/0x260 [kvm] process_one_work+0x145/0x2d0 worker_thread+0x27e/0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 </TASK> If kvm_clear_async_pf_completion_queue() actually flushes the workqueue, then there's no need to gift async_pf_execute() a reference because all invocations of async_pf_execute() will be forced to complete before the vCPU and its VM are destroyed/freed. And that in turn fixes the module unloading bug as __fput() won't do module_put() on the last vCPU reference until the vCPU has been freed, e.g. if closing the vCPU file also puts the last reference to the KVM module. Note that kvm_check_async_pf_completion() may also take the work item off the completion queue and so also needs to flush the work queue, as the work will not be seen by kvm_clear_async_pf_completion_queue(). Waiting on the workqueue could theoretically delay a vCPU due to waiting for the work to complete, but that's a very, very small chance, and likely a very small delay. kvm_arch_async_page_present_queued() unconditionally makes a new request, i.e. will effectively delay entering the guest, so the remaining work is really just: trace_kvm_async_pf_completed(addr, cr2_or_gpa); __kvm_vcpu_wake_up(vcpu); mmput(mm); and mmput() can't drop the last reference to the page tables if the vCPU is still alive, i.e. the vCPU won't get stuck tearing down page tables. Add a helper to do the flushing, specifically to deal with "wakeup all" work items, as they aren't actually work items, i.e. are never placed in a workqueue. Trying to flush a bogus workqueue entry rightly makes __flush_work() complain (kudos to whoever added that sanity check). Note, commit 5f6de5cbebee ("KVM: Prevent module exit until al ---truncated--- CVE-2024-26976 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: use timestamp to check for set element timeout Add a timestamp field at the beginning of the transaction, store it in the nftables per-netns area. Update set backend .insert, .deactivate and sync gc path to use the timestamp, this avoids that an element expires while control plane transaction is still unfinished. .lookup and .update, which are used from packet path, still use the current time to check if the element has expired. And .get path and dump also since this runs lockless under rcu read size lock. Then, there is async gc which also needs to check the current time since it runs asynchronously from a workqueue. CVE-2024-27397 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3-its: Prevent double free on error The error handling path in its_vpe_irq_domain_alloc() causes a double free when its_vpe_init() fails after successfully allocating at least one interrupt. This happens because its_vpe_irq_domain_free() frees the interrupts along with the area bitmap and the vprop_page and its_vpe_irq_domain_alloc() subsequently frees the area bitmap and the vprop_page again. Fix this by unconditionally invoking its_vpe_irq_domain_free() which handles all cases correctly and by removing the bitmap/vprop_page freeing from its_vpe_irq_domain_alloc(). [ tglx: Massaged change log ] CVE-2024-35847 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: relax socket state check at accept time. Christoph reported the following splat: WARNING: CPU: 1 PID: 772 at net/ipv4/af_inet.c:761 __inet_accept+0x1f4/0x4a0 Modules linked in: CPU: 1 PID: 772 Comm: syz-executor510 Not tainted 6.9.0-rc7-g7da7119fe22b #56 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 RIP: 0010:__inet_accept+0x1f4/0x4a0 net/ipv4/af_inet.c:759 Code: 04 38 84 c0 0f 85 87 00 00 00 41 c7 04 24 03 00 00 00 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ec b7 da fd <0f> 0b e9 7f fe ff ff e8 e0 b7 da fd 0f 0b e9 fe fe ff ff 89 d9 80 RSP: 0018:ffffc90000c2fc58 EFLAGS: 00010293 RAX: ffffffff836bdd14 RBX: 0000000000000000 RCX: ffff888104668000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: dffffc0000000000 R08: ffffffff836bdb89 R09: fffff52000185f64 R10: dffffc0000000000 R11: fffff52000185f64 R12: dffffc0000000000 R13: 1ffff92000185f98 R14: ffff88810754d880 R15: ffff8881007b7800 FS: 000000001c772880(0000) GS:ffff88811b280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb9fcf2e178 CR3: 00000001045d2002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> inet_accept+0x138/0x1d0 net/ipv4/af_inet.c:786 do_accept+0x435/0x620 net/socket.c:1929 __sys_accept4_file net/socket.c:1969 [inline] __sys_accept4+0x9b/0x110 net/socket.c:1999 __do_sys_accept net/socket.c:2016 [inline] __se_sys_accept net/socket.c:2013 [inline] __x64_sys_accept+0x7d/0x90 net/socket.c:2013 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x58/0x100 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x4315f9 Code: fd ff 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 ab b4 fd ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007ffdb26d9c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002b RAX: ffffffffffffffda RBX: 0000000000400300 RCX: 00000000004315f9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000004 RBP: 00000000006e1018 R08: 0000000000400300 R09: 0000000000400300 R10: 0000000000400300 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000040cdf0 R14: 000000000040ce80 R15: 0000000000000055 </TASK> The reproducer invokes shutdown() before entering the listener status. After commit 94062790aedb ("tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets"), the above causes the child to reach the accept syscall in FIN_WAIT1 status. Eric noted we can relax the existing assertion in __inet_accept() CVE-2024-36484 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: xfs: don't walk off the end of a directory data block This adds sanity checks for xfs_dir2_data_unused and xfs_dir2_data_entry to make sure don't stray beyond valid memory region. Before patching, the loop simply checks that the start offset of the dup and dep is within the range. So in a crafted image, if last entry is xfs_dir2_data_unused, we can change dup->length to dup->length-1 and leave 1 byte of space. In the next traversal, this space will be considered as dup or dep. We may encounter an out of bound read when accessing the fixed members. In the patch, we make sure that the remaining bytes large enough to hold an unused entry before accessing xfs_dir2_data_unused and xfs_dir2_data_unused is XFS_DIR2_DATA_ALIGN byte aligned. We also make sure that the remaining bytes large enough to hold a dirent with a single-byte name before accessing xfs_dir2_data_entry. CVE-2024-41013 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate Vim is an open source command line text editor. When performing a search and displaying the search-count message is disabled (:set shm+=S), the search pattern is displayed at the bottom of the screen in a buffer (msgbuf). When right-left mode (:set rl) is enabled, the search pattern is reversed. This happens by allocating a new buffer. If the search pattern contains some ASCII NUL characters, the buffer allocated will be smaller than the original allocated buffer (because for allocating the reversed buffer, the strlen() function is called, which only counts until it notices an ASCII NUL byte ) and thus the original length indicator is wrong. This causes an overflow when accessing characters inside the msgbuf by the previously (now wrong) length of the msgbuf. The issue has been fixed as of Vim patch v9.1.0689. CVE-2024-43790 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:vim-9.1.1101-17.41.1 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:vim-data-common-9.1.1101-17.41.1 moderate Vim is an improved version of the unix vi text editor. When flushing the typeahead buffer, Vim moves the current position in the typeahead buffer but does not check whether there is enough space left in the buffer to handle the next characters. So this may lead to the tb_off position within the typebuf variable to point outside of the valid buffer size, which can then later lead to a heap-buffer overflow in e.g. ins_typebuf(). Therefore, when flushing the typeahead buffer, check if there is enough space left before advancing the off position. If not, fall back to flush current typebuf contents. It's not quite clear yet, what can lead to this situation. It seems to happen when error messages occur (which will cause Vim to flush the typeahead buffer) in comnination with several long mappgins and so it may eventually move the off position out of a valid buffer size. Impact is low since it is not easily reproducible and requires to have several mappings active and run into some error condition. But when this happens, this will cause a crash. The issue has been fixed as of Vim patch v9.1.0697. Users are advised to upgrade. There are no known workarounds for this issue. CVE-2024-43802 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:vim-9.1.1101-17.41.1 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:vim-data-common-9.1.1101-17.41.1 moderate Vim is an open source, command line text editor. Patch v9.1.0038 optimized how the cursor position is calculated and removed a loop, that verified that the cursor position always points inside a line and does not become invalid by pointing beyond the end of a line. Back then we assumed this loop is unnecessary. However, this change made it possible that the cursor position stays invalid and points beyond the end of a line, which would eventually cause a heap-buffer-overflow when trying to access the line pointer at the specified cursor position. It's not quite clear yet, what can lead to this situation that the cursor points to an invalid position. That's why patch v9.1.0707 does not include a test case. The only observed impact has been a program crash. This issue has been addressed in with the patch v9.1.0707. All users are advised to upgrade. CVE-2024-45306 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:vim-9.1.1101-17.41.1 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:vim-data-common-9.1.1101-17.41.1 moderate When logs are written to a widely-writable directory (the default), an unprivileged attacker may predict a privileged process's log file path and pre-create a symbolic link to a sensitive file in its place. When that privileged process runs, it will follow the planted symlink and overwrite that sensitive file. To fix that, glog now causes the program to exit (with status code 2) when it finds that the configured log file already exists. CVE-2024-45339 important A flaw was found in grub2. A specially crafted JPEG file can cause the JPEG parser of grub2 to incorrectly check the bounds of its internal buffers, resulting in an out-of-bounds write. The possibility of overwriting sensitive information to bypass secure boot protections is not discarded. CVE-2024-45774 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-i386-pc-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-x86_64-efi-2.02-184.2 moderate A flaw was found in grub2 where the grub_extcmd_dispatcher() function calls grub_arg_list_alloc() to allocate memory for the grub's argument list. However, it fails to check in case the memory allocation fails. Once the allocation fails, a NULL point will be processed by the parse_option() function, leading grub to crash or, in some rare scenarios, corrupt the IVT data. CVE-2024-45775 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-i386-pc-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-x86_64-efi-2.02-184.2 moderate When reading the language .mo file in grub_mofile_open(), grub2 fails to verify an integer overflow when allocating its internal buffer. A crafted .mo file may lead the buffer size calculation to overflow, leading to out-of-bound reads and writes. This flaw allows an attacker to leak sensitive data or overwrite critical data, possibly circumventing secure boot protections. CVE-2024-45776 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-i386-pc-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-x86_64-efi-2.02-184.2 moderate A flaw was found in grub2. The calculation of the translation buffer when reading a language .mo file in grub_gettext_getstr_from_position() may overflow, leading to a Out-of-bound write. This issue can be leveraged by an attacker to overwrite grub2's sensitive heap data, eventually leading to the circumvention of secure boot protections. CVE-2024-45777 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-i386-pc-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-x86_64-efi-2.02-184.2 moderate A stack overflow flaw was found when reading a BFS file system. A crafted BFS filesystem may lead to an uncontrolled loop, causing grub2 to crash. CVE-2024-45778 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-i386-pc-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-x86_64-efi-2.02-184.2 moderate An integer overflow flaw was found in the BFS file system driver in grub2. When reading a file with an indirect extent map, grub2 fails to validate the number of extent entries to be read. A crafted or corrupted BFS filesystem may cause an integer overflow during the file reading, leading to a heap of bounds read. As a consequence, sensitive data may be leaked, or grub2 will crash. CVE-2024-45779 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-i386-pc-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-x86_64-efi-2.02-184.2 moderate A flaw was found in grub2. When reading tar files, grub2 allocates an internal buffer for the file name. However, it fails to properly verify the allocation against possible integer overflows. It's possible to cause the allocation length to overflow with a crafted tar file, leading to a heap out-of-bounds write. This flaw eventually allows an attacker to circumvent secure boot protections. CVE-2024-45780 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-i386-pc-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-x86_64-efi-2.02-184.2 moderate A flaw was found in grub2. When reading a symbolic link's name from a UFS filesystem, grub2 fails to validate the string length taken as an input. The lack of validation may lead to a heap out-of-bounds write, causing data integrity issues and eventually allowing an attacker to circumvent secure boot protections. CVE-2024-45781 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-i386-pc-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-x86_64-efi-2.02-184.2 moderate A flaw was found in the HFS filesystem. When reading an HFS volume's name at grub_fs_mount(), the HFS filesystem driver performs a strcpy() using the user-provided volume name as input without properly validating the volume name's length. This issue may read to a heap-based out-of-bounds writer, impacting grub's sensitive data integrity and eventually leading to a secure boot protection bypass. CVE-2024-45782 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-i386-pc-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-x86_64-efi-2.02-184.2 moderate A flaw was found in grub2. When failing to mount an HFS+ grub, the hfsplus filesystem driver doesn't properly set an ERRNO value. This issue may lead to a NULL pointer access. CVE-2024-45783 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-i386-pc-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-x86_64-efi-2.02-184.2 moderate 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)->bound is set to 1 to prevent further connect(). However, removing the bound device resets bcm_sk(sk)->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)->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 <0f> 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: <TASK> 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 <48> 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 </TASK> remove_proc_entry: removing non-empty directory 'net/can-bcm', leaking at least '2456' CVE-2024-46771 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: pinmux: Use sequential access to access desc->pinmux data When two client of the same gpio call pinctrl_select_state() for the same functionality, we are seeing NULL pointer issue while accessing desc->mux_owner. Let's say two processes A, B executing in pin_request() for the same pin and process A updates the desc->mux_usecount but not yet updated the desc->mux_owner while process B see the desc->mux_usecount which got updated by A path and further executes strcmp and while accessing desc->mux_owner it crashes with NULL pointer. Serialize the access to mux related setting with a mutex lock. cpu0 (process A) cpu1(process B) pinctrl_select_state() { pinctrl_select_state() { pin_request() { pin_request() { ... .... } else { desc->mux_usecount++; desc->mux_usecount && strcmp(desc->mux_owner, owner)) { if (desc->mux_usecount > 1) return 0; desc->mux_owner = owner; } } CVE-2024-47141 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: pm80xx: Set phy->enable_completion only when we wait for it pm8001_phy_control() populates the enable_completion pointer with a stack address, sends a PHY_LINK_RESET / PHY_HARD_RESET, waits 300 ms, and returns. The problem arises when a phy control response comes late. After 300 ms the pm8001_phy_control() function returns and the passed enable_completion stack address is no longer valid. Late phy control response invokes complete() on a dangling enable_completion pointer which leads to a kernel crash. CVE-2024-47666 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate 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: <TASK> __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 <48> 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 </TASK> 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. CVE-2024-47701 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: dlm: fix possible lkb_resource null dereference This patch fixes a possible null pointer dereference when this function is called from request_lock() as lkb->lkb_resource is not assigned yet, only after validate_lock_args() by calling attach_lkb(). Another issue is that a resource name could be a non printable bytearray and we cannot assume to be ASCII coded. The log functionality is probably never being hit when DLM is used in normal way and no debug logging is enabled. The null pointer dereference can only occur on a new created lkb that does not have the resource assigned yet, it probably never hits the null pointer dereference but we should be sure that other changes might not change this behaviour and we actually can hit the mentioned null pointer dereference. In this patch we just drop the printout of the resource name, the lkb id is enough to make a possible connection to a resource name if this exists. CVE-2024-47809 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: bcache: revert replacing IS_ERR_OR_NULL with IS_ERR again Commit 028ddcac477b ("bcache: Remove unnecessary NULL point check in node allocations") leads a NULL pointer deference in cache_set_flush(). 1721 if (!IS_ERR_OR_NULL(c->root)) 1722 list_add(&c->root->list, &c->btree_cache); >From the above code in cache_set_flush(), if previous registration code fails before allocating c->root, it is possible c->root is NULL as what it is initialized. __bch_btree_node_alloc() never returns NULL but c->root is possible to be NULL at above line 1721. This patch replaces IS_ERR() by IS_ERR_OR_NULL() to fix this. CVE-2024-48881 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate 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: <TASK> 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->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. CVE-2024-49884 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate 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. CVE-2024-49925 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: add more sanity checks to qdisc_pkt_len_init() One path takes care of SKB_GSO_DODGY, assuming skb->len is bigger than hdr_len. virtio_net_hdr_to_skb() does not fully dissect TCP headers, it only make sure it is at least 20 bytes. It is possible for an user to provide a malicious 'GSO' packet, total length of 80 bytes. - 20 bytes of IPv4 header - 60 bytes TCP header - a small gso_size like 8 virtio_net_hdr_to_skb() would declare this packet as a normal GSO packet, because it would see 40 bytes of payload, bigger than gso_size. We need to make detect this case to not underflow qdisc_skb_cb(skb)->pkt_len. CVE-2024-49948 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate 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: <TASK> __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 CVE-2024-49950 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: mailbox: bcm2835: Fix timeout during suspend mode During noirq suspend phase the Raspberry Pi power driver suffer of firmware property timeouts. The reason is that the IRQ of the underlying BCM2835 mailbox is disabled and rpi_firmware_property_list() will always run into a timeout [1]. Since the VideoCore side isn't consider as a wakeup source, set the IRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabled during suspend-resume cycle. [1] PM: late suspend of devices complete after 1.754 msecs WARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x204/0x22c Firmware transaction 0x00028001 timeout Modules linked in: CPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17 Hardware name: BCM2835 Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x44 dump_stack_lvl from __warn+0x88/0xec __warn from warn_slowpath_fmt+0x7c/0xb0 warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22c rpi_firmware_property_list from rpi_firmware_property+0x68/0x8c rpi_firmware_property from rpi_firmware_set_power+0x54/0xc0 rpi_firmware_set_power from _genpd_power_off+0xe4/0x148 _genpd_power_off from genpd_sync_power_off+0x7c/0x11c genpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0 genpd_finish_suspend from dpm_run_callback+0x78/0xd0 dpm_run_callback from device_suspend_noirq+0xc0/0x238 device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168 dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5ac suspend_devices_and_enter from pm_suspend+0x254/0x2e4 pm_suspend from state_store+0xa8/0xd4 state_store from kernfs_fop_write_iter+0x154/0x1a0 kernfs_fop_write_iter from vfs_write+0x12c/0x184 vfs_write from ksys_write+0x78/0xc0 ksys_write from ret_fast_syscall+0x0/0x54 Exception stack(0xcc93dfa8 to 0xcc93dff0) [...] PM: noirq suspend of devices complete after 3095.584 msecs CVE-2024-49963 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: uprobes: fix kernel info leak via "[uprobes]" vma xol_add_vma() maps the uninitialized page allocated by __create_xol_area() into userspace. On some architectures (x86) this memory is readable even without VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ, although this doesn't really matter, debugger can read this memory anyway. CVE-2024-49975 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: do not delay dst_entries_add() in dst_release() dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy() Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy() dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels. CVE-2024-50036 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: uprobe: avoid out-of-bounds memory access of fetching args Uprobe needs to fetch args into a percpu buffer, and then copy to ring buffer to avoid non-atomic context problem. Sometimes user-space strings, arrays can be very large, but the size of percpu buffer is only page size. And store_trace_args() won't check whether these data exceeds a single page or not, caused out-of-bounds memory access. It could be reproduced by following steps: 1. build kernel with CONFIG_KASAN enabled 2. save follow program as test.c ``` \#include <stdio.h> \#include <stdlib.h> \#include <string.h> // If string length large than MAX_STRING_SIZE, the fetch_store_strlen() // will return 0, cause __get_data_size() return shorter size, and // store_trace_args() will not trigger out-of-bounds access. // So make string length less than 4096. \#define STRLEN 4093 void generate_string(char *str, int n) { int i; for (i = 0; i < n; ++i) { char c = i % 26 + 'a'; str[i] = c; } str[n-1] = '\0'; } void print_string(char *str) { printf("%s\n", str); } int main() { char tmp[STRLEN]; generate_string(tmp, STRLEN); print_string(tmp); return 0; } ``` 3. compile program `gcc -o test test.c` 4. get the offset of `print_string()` ``` objdump -t test | grep -w print_string 0000000000401199 g F .text 000000000000001b print_string ``` 5. configure uprobe with offset 0x1199 ``` off=0x1199 cd /sys/kernel/debug/tracing/ echo "p /root/test:${off} arg1=+0(%di):ustring arg2=\$comm arg3=+0(%di):ustring" > uprobe_events echo 1 > events/uprobes/enable echo 1 > tracing_on ``` 6. run `test`, and kasan will report error. ================================================================== BUG: KASAN: use-after-free in strncpy_from_user+0x1d6/0x1f0 Write of size 8 at addr ffff88812311c004 by task test/499CPU: 0 UID: 0 PID: 499 Comm: test Not tainted 6.12.0-rc3+ #18 Hardware name: Red Hat KVM, BIOS 1.16.0-4.al8 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x55/0x70 print_address_description.constprop.0+0x27/0x310 kasan_report+0x10f/0x120 ? strncpy_from_user+0x1d6/0x1f0 strncpy_from_user+0x1d6/0x1f0 ? rmqueue.constprop.0+0x70d/0x2ad0 process_fetch_insn+0xb26/0x1470 ? __pfx_process_fetch_insn+0x10/0x10 ? _raw_spin_lock+0x85/0xe0 ? __pfx__raw_spin_lock+0x10/0x10 ? __pte_offset_map+0x1f/0x2d0 ? unwind_next_frame+0xc5f/0x1f80 ? arch_stack_walk+0x68/0xf0 ? is_bpf_text_address+0x23/0x30 ? kernel_text_address.part.0+0xbb/0xd0 ? __kernel_text_address+0x66/0xb0 ? unwind_get_return_address+0x5e/0xa0 ? __pfx_stack_trace_consume_entry+0x10/0x10 ? arch_stack_walk+0xa2/0xf0 ? _raw_spin_lock_irqsave+0x8b/0xf0 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? depot_alloc_stack+0x4c/0x1f0 ? _raw_spin_unlock_irqrestore+0xe/0x30 ? stack_depot_save_flags+0x35d/0x4f0 ? kasan_save_stack+0x34/0x50 ? kasan_save_stack+0x24/0x50 ? mutex_lock+0x91/0xe0 ? __pfx_mutex_lock+0x10/0x10 prepare_uprobe_buffer.part.0+0x2cd/0x500 uprobe_dispatcher+0x2c3/0x6a0 ? __pfx_uprobe_dispatcher+0x10/0x10 ? __kasan_slab_alloc+0x4d/0x90 handler_chain+0xdd/0x3e0 handle_swbp+0x26e/0x3d0 ? __pfx_handle_swbp+0x10/0x10 ? uprobe_pre_sstep_notifier+0x151/0x1b0 irqentry_exit_to_user_mode+0xe2/0x1b0 asm_exc_int3+0x39/0x40 RIP: 0033:0x401199 Code: 01 c2 0f b6 45 fb 88 02 83 45 fc 01 8b 45 fc 3b 45 e4 7c b7 8b 45 e4 48 98 48 8d 50 ff 48 8b 45 e8 48 01 d0 ce RSP: 002b:00007ffdf00576a8 EFLAGS: 00000206 RAX: 00007ffdf00576b0 RBX: 0000000000000000 RCX: 0000000000000ff2 RDX: 0000000000000ffc RSI: 0000000000000ffd RDI: 00007ffdf00576b0 RBP: 00007ffdf00586b0 R08: 00007feb2f9c0d20 R09: 00007feb2f9c0d20 R10: 0000000000000001 R11: 0000000000000202 R12: 0000000000401040 R13: 00007ffdf0058780 R14: 0000000000000000 R15: 0000000000000000 </TASK> This commit enforces the buffer's maxlen less than a page-size to avoid store_trace_args() out-of-memory access. CVE-2024-50067 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate 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: <TASK> 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. CVE-2024-50073 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate 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. CVE-2024-50115 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 important In the Linux kernel, the following vulnerability has been resolved: xfrm: validate new SA's prefixlen using SA family when sel.family is unset This expands the validation introduced in commit 07bf7908950a ("xfrm: Validate address prefix lengths in the xfrm selector.") syzbot created an SA with usersa.sel.family = AF_UNSPEC usersa.sel.prefixlen_s = 128 usersa.family = AF_INET Because of the AF_UNSPEC selector, verify_newsa_info doesn't put limits on prefixlen_{s,d}. But then copy_from_user_state sets x->sel.family to usersa.family (AF_INET). Do the same conversion in verify_newsa_info before validating prefixlen_{s,d}, since that's how prefixlen is going to be used later on. CVE-2024-50142 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: udf: fix uninit-value use in udf_get_fileshortad Check for overflow when computing alen in udf_current_aext to mitigate later uninit-value use in udf_get_fileshortad KMSAN bug[1]. After applying the patch reproducer did not trigger any issue[2]. [1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df [2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000 CVE-2024-50143 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: smb: client: fix OOBs when building SMB2_IOCTL request When using encryption, either enforced by the server or when using 'seal' mount option, the client will squash all compound request buffers down for encryption into a single iov in smb2_set_next_command(). SMB2_ioctl_init() allocates a small buffer (448 bytes) to hold the SMB2_IOCTL request in the first iov, and if the user passes an input buffer that is greater than 328 bytes, smb2_set_next_command() will end up writing off the end of @rqst->iov[0].iov_base as shown below: mount.cifs //srv/share /mnt -o ...,seal ln -s $(perl -e "print('a')for 1..1024") /mnt/link BUG: KASAN: slab-out-of-bounds in smb2_set_next_command.cold+0x1d6/0x24c [cifs] Write of size 4116 at addr ffff8881148fcab8 by task ln/859 CPU: 1 UID: 0 PID: 859 Comm: ln Not tainted 6.12.0-rc3 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] print_report+0x156/0x4d9 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] ? __virt_addr_valid+0x145/0x310 ? __phys_addr+0x46/0x90 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] kasan_report+0xda/0x110 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] kasan_check_range+0x10f/0x1f0 __asan_memcpy+0x3c/0x60 smb2_set_next_command.cold+0x1d6/0x24c [cifs] smb2_compound_op+0x238c/0x3840 [cifs] ? kasan_save_track+0x14/0x30 ? kasan_save_free_info+0x3b/0x70 ? vfs_symlink+0x1a1/0x2c0 ? do_symlinkat+0x108/0x1c0 ? __pfx_smb2_compound_op+0x10/0x10 [cifs] ? kmem_cache_free+0x118/0x3e0 ? cifs_get_writable_path+0xeb/0x1a0 [cifs] smb2_get_reparse_inode+0x423/0x540 [cifs] ? __pfx_smb2_get_reparse_inode+0x10/0x10 [cifs] ? rcu_is_watching+0x20/0x50 ? __kmalloc_noprof+0x37c/0x480 ? smb2_create_reparse_symlink+0x257/0x490 [cifs] ? smb2_create_reparse_symlink+0x38f/0x490 [cifs] smb2_create_reparse_symlink+0x38f/0x490 [cifs] ? __pfx_smb2_create_reparse_symlink+0x10/0x10 [cifs] ? find_held_lock+0x8a/0xa0 ? hlock_class+0x32/0xb0 ? __build_path_from_dentry_optional_prefix+0x19d/0x2e0 [cifs] cifs_symlink+0x24f/0x960 [cifs] ? __pfx_make_vfsuid+0x10/0x10 ? __pfx_cifs_symlink+0x10/0x10 [cifs] ? make_vfsgid+0x6b/0xc0 ? generic_permission+0x96/0x2d0 vfs_symlink+0x1a1/0x2c0 do_symlinkat+0x108/0x1c0 ? __pfx_do_symlinkat+0x10/0x10 ? strncpy_from_user+0xaa/0x160 __x64_sys_symlinkat+0xb9/0xf0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f08d75c13bb CVE-2024-50151 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: fsl/fman: Fix refcount handling of fman-related devices In mac_probe() there are multiple calls to of_find_device_by_node(), fman_bind() and fman_port_bind() which takes references to of_dev->dev. Not all references taken by these calls are released later on error path in mac_probe() and in mac_remove() which lead to reference leaks. Add references release. CVE-2024-50166 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: mm/swapfile: skip HugeTLB pages for unuse_vma I got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The problem can be reproduced by the following steps: 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message: mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7) We can tell that pud_clear_bad is called by pud_none_or_clear_bad in unuse_pud_range() by ftrace. And therefore the HugeTLB pages will never be freed because we lost it from page table. We can skip HugeTLB pages for unuse_vma to fix it. CVE-2024-50199 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: udf: refactor inode_bmap() to handle error Refactor inode_bmap() to handle error since udf_next_aext() can return error now. On situations like ftruncate, udf_extend_file() can now detect errors and bail out early without resorting to checking for particular offsets and assuming internal behavior of these functions. CVE-2024-50211 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. CVE-2024-50228 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: sanitize offset and length before calling skb_checksum() If access to offset + length is larger than the skbuff length, then skb_checksum() triggers BUG_ON(). skb_checksum() internally subtracts the length parameter while iterating over skbuff, BUG_ON(len) at the end of it checks that the expected length to be included in the checksum calculation is fully consumed. CVE-2024-50251 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6() I got a syzbot report without a repro [1] crashing in nf_send_reset6() I think the issue is that dev->hard_header_len is zero, and we attempt later to push an Ethernet header. Use LL_MAX_HEADER, as other functions in net/ipv6/netfilter/nf_reject_ipv6.c. [1] skbuff: skb_under_panic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syz_tun kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Code: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc900045269b0 EFLAGS: 00010282 RAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800 RDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000 RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4ccc R10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140 R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003c FS: 00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> skb_push+0xe5/0x100 net/core/skbuff.c:2636 eth_header+0x38/0x1f0 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3208 [inline] nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358 nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48 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_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_bridge_pre net/bridge/br_input.c:277 [inline] br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424 __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562 __netif_receive_skb_one_core net/core/dev.c:5666 [inline] __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781 netif_receive_skb_internal net/core/dev.c:5867 [inline] netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926 tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550 tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007 tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053 new_sync_write fs/read_write.c:590 [inline] vfs_write+0xa6d/0xc90 fs/read_write.c:683 ksys_write+0x183/0x2b0 fs/read_write.c:736 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:0x7fdbeeb7d1ff Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48 RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ff RDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8 RBP: 00007fdbeebf12be R08: 0000000 ---truncated--- CVE-2024-50256 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds write in trie_get_next_key() trie_get_next_key() allocates a node stack with size trie->max_prefixlen, while it writes (trie->max_prefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8. CVE-2024-50262 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate 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 >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. CVE-2024-50278 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: v4l2-tpg: prevent the risk of a division by zero As reported by Coverity, the logic at tpg_precalculate_line() blindly rescales the buffer even when scaled_witdh is equal to zero. If this ever happens, this will cause a division by zero. Instead, add a WARN_ON_ONCE() to trigger such cases and return without doing any precalculation. CVE-2024-50287 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: sctp: properly validate chunk size in sctp_sf_ootb() A size validation fix similar to that in Commit 50619dbf8db7 ("sctp: add size validation when walking chunks") is also required in sctp_sf_ootb() to address a crash reported by syzbot: BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166 sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159 ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233 CVE-2024-50299 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find() The per-netns IP tunnel hash table is protected by the RTNL mutex and ip_tunnel_find() is only called from the control path where the mutex is taken. Add a lockdep expression to hlist_for_each_entry_rcu() in ip_tunnel_find() in order to validate that the mutex is held and to silence the suspicious RCU usage warning [1]. [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted ----------------------------- net/ipv4/ip_tunnel.c:221 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/362: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: <TASK> dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 ip_tunnel_find+0x435/0x4d0 ip_tunnel_newlink+0x517/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f CVE-2024-50304 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: igb: Fix potential invalid memory access in igb_init_module() The pci_register_driver() can fail and when this happened, the dca_notifier needs to be unregistered, otherwise the dca_notifier can be called when igb fails to install, resulting to invalid memory access. CVE-2024-52332 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT In qdisc_tree_reduce_backlog, Qdiscs with major handle ffff: are assumed to be either root or ingress. This assumption is bogus since it's valid to create egress qdiscs with major handle ffff: Budimir Markovic found that for qdiscs like DRR that maintain an active class list, it will cause a UAF with a dangling class pointer. In 066a3b5b2346, the concern was to avoid iterating over the ingress qdisc since its parent is itself. The proper fix is to stop when parent TC_H_ROOT is reached because the only way to retrieve ingress is when a hierarchy which does not contain a ffff: major handle call into qdisc_lookup with TC_H_MAJ(TC_H_ROOT). In the scenario where major ffff: is an egress qdisc in any of the tree levels, the updates will also propagate to TC_H_ROOT, which then the iteration must stop. net/sched/sch_api.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) CVE-2024-53057 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 important In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized value issue in from_kuid and from_kgid ocfs2_setattr() uses attr->ia_mode, attr->ia_uid and attr->ia_gid in a trace point even though ATTR_MODE, ATTR_UID and ATTR_GID aren't set. Initialize all fields of newattrs to avoid uninitialized variables, by checking if ATTR_MODE, ATTR_UID, ATTR_GID are initialized, otherwise 0. CVE-2024-53101 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: ocfs2: uncache inode which has failed entering the group Syzbot has reported the following BUG: kernel BUG at fs/ocfs2/uptodate.c:509! ... Call Trace: <TASK> ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? do_error_trap+0x1dc/0x2c0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? __pfx_do_error_trap+0x10/0x10 ? handle_invalid_op+0x34/0x40 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? ocfs2_set_new_buffer_uptodate+0x2e/0x160 ? ocfs2_set_new_buffer_uptodate+0x144/0x160 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ocfs2_group_add+0x39f/0x15a0 ? __pfx_ocfs2_group_add+0x10/0x10 ? __pfx_lock_acquire+0x10/0x10 ? mnt_get_write_access+0x68/0x2b0 ? __pfx_lock_release+0x10/0x10 ? rcu_read_lock_any_held+0xb7/0x160 ? __pfx_rcu_read_lock_any_held+0x10/0x10 ? smack_log+0x123/0x540 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x226/0x2b0 ocfs2_ioctl+0x65e/0x7d0 ? __pfx_ocfs2_ioctl+0x10/0x10 ? smack_file_ioctl+0x29e/0x3a0 ? __pfx_smack_file_ioctl+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? __pfx_ocfs2_ioctl+0x10/0x10 __se_sys_ioctl+0xfb/0x170 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... </TASK> When 'ioctl(OCFS2_IOC_GROUP_ADD, ...)' has failed for the particular inode in 'ocfs2_verify_group_and_input()', corresponding buffer head remains cached and subsequent call to the same 'ioctl()' for the same inode issues the BUG() in 'ocfs2_set_new_buffer_uptodate()' (trying to cache the same buffer head of that inode). Fix this by uncaching the buffer head with 'ocfs2_remove_from_cache()' on error path in 'ocfs2_group_add()'. CVE-2024-53112 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: add missing range check in bitmap_ip_uadt When tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists, the values of ip and ip_to are slightly swapped. Therefore, the range check for ip should be done later, but this part is missing and it seems that the vulnerability occurs. So we should add missing range checks and remove unnecessary range checks. CVE-2024-53141 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 important In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent a potential integer overflow If the tag length is >= U32_MAX - 3 then the "length + 4" addition can result in an integer overflow. Address this by splitting the decoding into several steps so that decode_cb_compound4res() does not have to perform arithmetic on the unsafe length value. CVE-2024-53146 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 important In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix out of bounds reads when finding clock sources The current USB-audio driver code doesn't check bLength of each descriptor at traversing for clock descriptors. That is, when a device provides a bogus descriptor with a shorter bLength, the driver might hit out-of-bounds reads. For addressing it, this patch adds sanity checks to the validator functions for the clock descriptor traversal. When the descriptor length is shorter than expected, it's skipped in the loop. For the clock source and clock multiplier descriptors, we can just check bLength against the sizeof() of each descriptor type. OTOH, the clock selector descriptor of UAC2 and UAC3 has an array of bNrInPins elements and two more fields at its tail, hence those have to be checked in addition to the sizeof() check. CVE-2024-53150 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix uninitialized value in ocfs2_file_read_iter() Syzbot has reported the following KMSAN splat: BUG: KMSAN: uninit-value in ocfs2_file_read_iter+0x9a4/0xf80 ocfs2_file_read_iter+0x9a4/0xf80 __io_read+0x8d4/0x20f0 io_read+0x3e/0xf0 io_issue_sqe+0x42b/0x22c0 io_wq_submit_work+0xaf9/0xdc0 io_worker_handle_work+0xd13/0x2110 io_wq_worker+0x447/0x1410 ret_from_fork+0x6f/0x90 ret_from_fork_asm+0x1a/0x30 Uninit was created at: __alloc_pages_noprof+0x9a7/0xe00 alloc_pages_mpol_noprof+0x299/0x990 alloc_pages_noprof+0x1bf/0x1e0 allocate_slab+0x33a/0x1250 ___slab_alloc+0x12ef/0x35e0 kmem_cache_alloc_bulk_noprof+0x486/0x1330 __io_alloc_req_refill+0x84/0x560 io_submit_sqes+0x172f/0x2f30 __se_sys_io_uring_enter+0x406/0x41c0 __x64_sys_io_uring_enter+0x11f/0x1a0 x64_sys_call+0x2b54/0x3ba0 do_syscall_64+0xcd/0x1e0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Since an instance of 'struct kiocb' may be passed from the block layer with 'private' field uninitialized, introduce 'ocfs2_iocb_init_rw_locked()' and use it from where 'ocfs2_dio_end_io()' might take care, i.e. in 'ocfs2_file_read_iter()' and 'ocfs2_file_write_iter()'. CVE-2024-53155 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: add range check for conn_rsp_epid in htc_connect_service() I found the following bug in my fuzzer: UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath9k/htc_hst.c:26:51 index 255 is out of range for type 'htc_endpoint [22]' CPU: 0 UID: 0 PID: 8 Comm: kworker/0:0 Not tainted 6.11.0-rc6-dirty #14 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: events request_firmware_work_func Call Trace: <TASK> dump_stack_lvl+0x180/0x1b0 __ubsan_handle_out_of_bounds+0xd4/0x130 htc_issue_send.constprop.0+0x20c/0x230 ? _raw_spin_unlock_irqrestore+0x3c/0x70 ath9k_wmi_cmd+0x41d/0x610 ? mark_held_locks+0x9f/0xe0 ... Since this bug has been confirmed to be caused by insufficient verification of conn_rsp_epid, I think it would be appropriate to add a range check for conn_rsp_epid to htc_connect_service() to prevent the bug from occurring. CVE-2024-53156 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 important In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scpi: Check the DVFS OPP count returned by the firmware Fix a kernel crash with the below call trace when the SCPI firmware returns OPP count of zero. dvfs_info.opp_count may be zero on some platforms during the reboot test, and the kernel will crash after dereferencing the pointer to kcalloc(info->count, sizeof(*opp), GFP_KERNEL). | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028 | Mem abort info: | ESR = 0x96000004 | Exception class = DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | Data abort info: | ISV = 0, ISS = 0x00000004 | CM = 0, WnR = 0 | user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000faefa08c | [0000000000000028] pgd=0000000000000000 | Internal error: Oops: 96000004 [#1] SMP | scpi-hwmon: probe of PHYT000D:00 failed with error -110 | Process systemd-udevd (pid: 1701, stack limit = 0x00000000aaede86c) | CPU: 2 PID: 1701 Comm: systemd-udevd Not tainted 4.19.90+ #1 | Hardware name: PHYTIUM LTD Phytium FT2000/4/Phytium FT2000/4, BIOS | pstate: 60000005 (nZCv daif -PAN -UAO) | pc : scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi] | lr : clk_register+0x438/0x720 | Call trace: | scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi] | devm_clk_hw_register+0x50/0xa0 | scpi_clk_ops_init.isra.2+0xa0/0x138 [clk_scpi] | scpi_clocks_probe+0x528/0x70c [clk_scpi] | platform_drv_probe+0x58/0xa8 | really_probe+0x260/0x3d0 | driver_probe_device+0x12c/0x148 | device_driver_attach+0x74/0x98 | __driver_attach+0xb4/0xe8 | bus_for_each_dev+0x88/0xe0 | driver_attach+0x30/0x40 | bus_add_driver+0x178/0x2b0 | driver_register+0x64/0x118 | __platform_driver_register+0x54/0x60 | scpi_clocks_driver_init+0x24/0x1000 [clk_scpi] | do_one_initcall+0x54/0x220 | do_init_module+0x54/0x1c8 | load_module+0x14a4/0x1668 | __se_sys_finit_module+0xf8/0x110 | __arm64_sys_finit_module+0x24/0x30 | el0_svc_common+0x78/0x170 | el0_svc_handler+0x38/0x78 | el0_svc+0x8/0x340 | Code: 937d7c00 a94153f3 a8c27bfd f9400421 (b8606820) | ---[ end trace 06feb22469d89fa8 ]--- | Kernel panic - not syncing: Fatal exception | SMP: stopping secondary CPUs | Kernel Offset: disabled | CPU features: 0x10,a0002008 | Memory Limit: none CVE-2024-53157 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: ubi: fastmap: Fix duplicate slab cache names while attaching Since commit 4c39529663b9 ("slab: Warn on duplicate cache names when DEBUG_VM=y"), the duplicate slab cache names can be detected and a kernel WARNING is thrown out. In UBI fast attaching process, alloc_ai() could be invoked twice with the same slab cache name 'ubi_aeb_slab_cache', which will trigger following warning messages: kmem_cache of name 'ubi_aeb_slab_cache' already exists WARNING: CPU: 0 PID: 7519 at mm/slab_common.c:107 __kmem_cache_create_args+0x100/0x5f0 Modules linked in: ubi(+) nandsim [last unloaded: nandsim] CPU: 0 UID: 0 PID: 7519 Comm: modprobe Tainted: G 6.12.0-rc2 RIP: 0010:__kmem_cache_create_args+0x100/0x5f0 Call Trace: __kmem_cache_create_args+0x100/0x5f0 alloc_ai+0x295/0x3f0 [ubi] ubi_attach+0x3c3/0xcc0 [ubi] ubi_attach_mtd_dev+0x17cf/0x3fa0 [ubi] ubi_init+0x3fb/0x800 [ubi] do_init_module+0x265/0x7d0 __x64_sys_finit_module+0x7a/0xc0 The problem could be easily reproduced by loading UBI device by fastmap with CONFIG_DEBUG_VM=y. Fix it by using different slab names for alloc_ai() callers. CVE-2024-53172 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: NFSv4.0: Fix a use-after-free problem in the asynchronous open() Yang Erkun reports that when two threads are opening files at the same time, and are forced to abort before a reply is seen, then the call to nfs_release_seqid() in nfs4_opendata_free() can result in a use-after-free of the pointer to the defunct rpc task of the other thread. The fix is to ensure that if the RPC call is aborted before the call to nfs_wait_on_sequence() is complete, then we must call nfs_release_seqid() in nfs4_open_release() before the rpc_task is freed. CVE-2024-53173 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 important In the Linux kernel, the following vulnerability has been resolved: smb: client: fix use-after-free of signing key Customers have reported use-after-free in @ses->auth_key.response with SMB2.1 + sign mounts which occurs due to following race: task A task B cifs_mount() dfs_mount_share() get_session() cifs_mount_get_session() cifs_send_recv() cifs_get_smb_ses() compound_send_recv() cifs_setup_session() smb2_setup_request() kfree_sensitive() smb2_calc_signature() crypto_shash_setkey() *UAF* Fix this by ensuring that we have a valid @ses->auth_key.response by checking whether @ses->ses_status is SES_GOOD or SES_EXITING with @ses->ses_lock held. After commit 24a9799aa8ef ("smb: client: fix UAF in smb2_reconnect_server()"), we made sure to call ->logoff() only when @ses was known to be good (e.g. valid ->auth_key.response), so it's safe to access signing key when @ses->ses_status == SES_EXITING. CVE-2024-53179 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 important In the Linux kernel, the following vulnerability has been resolved: smb: client: fix NULL ptr deref in crypto_aead_setkey() Neither SMB3.0 or SMB3.02 supports encryption negotiate context, so when SMB2_GLOBAL_CAP_ENCRYPTION flag is set in the negotiate response, the client uses AES-128-CCM as the default cipher. See MS-SMB2 3.3.5.4. Commit b0abcd65ec54 ("smb: client: fix UAF in async decryption") added a @server->cipher_type check to conditionally call smb3_crypto_aead_allocate(), but that check would always be false as @server->cipher_type is unset for SMB3.02. Fix the following KASAN splat by setting @server->cipher_type for SMB3.02 as well. mount.cifs //srv/share /mnt -o vers=3.02,seal,... BUG: KASAN: null-ptr-deref in crypto_aead_setkey+0x2c/0x130 Read of size 8 at addr 0000000000000020 by task mount.cifs/1095 CPU: 1 UID: 0 PID: 1095 Comm: mount.cifs Not tainted 6.12.0 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 ? crypto_aead_setkey+0x2c/0x130 kasan_report+0xda/0x110 ? crypto_aead_setkey+0x2c/0x130 crypto_aead_setkey+0x2c/0x130 crypt_message+0x258/0xec0 [cifs] ? __asan_memset+0x23/0x50 ? __pfx_crypt_message+0x10/0x10 [cifs] ? mark_lock+0xb0/0x6a0 ? hlock_class+0x32/0xb0 ? mark_lock+0xb0/0x6a0 smb3_init_transform_rq+0x352/0x3f0 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 smb_send_rqst+0x144/0x230 [cifs] ? __pfx_smb_send_rqst+0x10/0x10 [cifs] ? hlock_class+0x32/0xb0 ? smb2_setup_request+0x225/0x3a0 [cifs] ? __pfx_cifs_compound_last_callback+0x10/0x10 [cifs] compound_send_recv+0x59b/0x1140 [cifs] ? __pfx_compound_send_recv+0x10/0x10 [cifs] ? __create_object+0x5e/0x90 ? hlock_class+0x32/0xb0 ? do_raw_spin_unlock+0x9a/0xf0 cifs_send_recv+0x23/0x30 [cifs] SMB2_tcon+0x3ec/0xb30 [cifs] ? __pfx_SMB2_tcon+0x10/0x10 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 ? __pfx_lock_release+0x10/0x10 ? do_raw_spin_trylock+0xc6/0x120 ? lock_acquire+0x3f/0x90 ? _get_xid+0x16/0xd0 [cifs] ? __pfx_SMB2_tcon+0x10/0x10 [cifs] ? cifs_get_smb_ses+0xcdd/0x10a0 [cifs] cifs_get_smb_ses+0xcdd/0x10a0 [cifs] ? __pfx_cifs_get_smb_ses+0x10/0x10 [cifs] ? cifs_get_tcp_session+0xaa0/0xca0 [cifs] cifs_mount_get_session+0x8a/0x210 [cifs] dfs_mount_share+0x1b0/0x11d0 [cifs] ? __pfx___lock_acquire+0x10/0x10 ? __pfx_dfs_mount_share+0x10/0x10 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 ? find_held_lock+0x8a/0xa0 ? hlock_class+0x32/0xb0 ? lock_release+0x203/0x5d0 cifs_mount+0xb3/0x3d0 [cifs] ? do_raw_spin_trylock+0xc6/0x120 ? __pfx_cifs_mount+0x10/0x10 [cifs] ? lock_acquire+0x3f/0x90 ? find_nls+0x16/0xa0 ? smb3_update_mnt_flags+0x372/0x3b0 [cifs] cifs_smb3_do_mount+0x1e2/0xc80 [cifs] ? __pfx_vfs_parse_fs_string+0x10/0x10 ? __pfx_cifs_smb3_do_mount+0x10/0x10 [cifs] smb3_get_tree+0x1bf/0x330 [cifs] vfs_get_tree+0x4a/0x160 path_mount+0x3c1/0xfb0 ? kasan_quarantine_put+0xc7/0x1d0 ? __pfx_path_mount+0x10/0x10 ? kmem_cache_free+0x118/0x3e0 ? user_path_at+0x74/0xa0 __x64_sys_mount+0x1a6/0x1e0 ? __pfx___x64_sys_mount+0x10/0x10 ? mark_held_locks+0x1a/0x90 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f CVE-2024-53185 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox devices A bogus device can provide a bNumConfigurations value that exceeds the initial value used in usb_get_configuration for allocating dev->config. This can lead to out-of-bounds accesses later, e.g. in usb_destroy_configuration. CVE-2024-53197 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: xen: Fix the issue of resource not being properly released in xenbus_dev_probe() This patch fixes an issue in the function xenbus_dev_probe(). In the xenbus_dev_probe() function, within the if (err) branch at line 313, the program incorrectly returns err directly without releasing the resources allocated by err = drv->probe(dev, id). As the return value is non-zero, the upper layers assume the processing logic has failed. However, the probe operation was performed earlier without a corresponding remove operation. Since the probe actually allocates resources, failing to perform the remove operation could lead to problems. To fix this issue, we followed the resource release logic of the xenbus_dev_remove() function by adding a new block fail_remove before the fail_put block. After entering the branch if (err) at line 313, the function will use a goto statement to jump to the fail_remove block, ensuring that the previously acquired resources are correctly released, thus preventing the reference count leak. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and detecting potential issues where resources are not properly managed. In this case, the tool flagged the missing release operation as a potential problem, which led to the development of this patch. CVE-2024-53198 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct() Passing MSG_PEEK flag to skb_recv_datagram() increments skb refcount (skb->users) and iucv_sock_recvmsg() does not decrement skb refcount at exit. This results in skb memory leak in skb_queue_purge() and WARN_ON in iucv_sock_destruct() during socket close. To fix this decrease skb refcount by one if MSG_PEEK is set in order to prevent memory leak and WARN_ON. WARNING: CPU: 2 PID: 6292 at net/iucv/af_iucv.c:286 iucv_sock_destruct+0x144/0x1a0 [af_iucv] CPU: 2 PID: 6292 Comm: afiucv_test_msg Kdump: loaded Tainted: G W 6.10.0-rc7 #1 Hardware name: IBM 3931 A01 704 (z/VM 7.3.0) Call Trace: [<001587c682c4aa98>] iucv_sock_destruct+0x148/0x1a0 [af_iucv] [<001587c682c4a9d0>] iucv_sock_destruct+0x80/0x1a0 [af_iucv] [<001587c704117a32>] __sk_destruct+0x52/0x550 [<001587c704104a54>] __sock_release+0xa4/0x230 [<001587c704104c0c>] sock_close+0x2c/0x40 [<001587c702c5f5a8>] __fput+0x2e8/0x970 [<001587c7024148c4>] task_work_run+0x1c4/0x2c0 [<001587c7023b0716>] do_exit+0x996/0x1050 [<001587c7023b13aa>] do_group_exit+0x13a/0x360 [<001587c7023b1626>] __s390x_sys_exit_group+0x56/0x60 [<001587c7022bccca>] do_syscall+0x27a/0x380 [<001587c7049a6a0c>] __do_syscall+0x9c/0x160 [<001587c7049ce8a8>] system_call+0x70/0x98 Last Breaking-Event-Address: [<001587c682c4a9d4>] iucv_sock_destruct+0x84/0x1a0 [af_iucv] CVE-2024-53210 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Properly hide first-in-list PCIe extended capability There are cases where a PCIe extended capability should be hidden from the user. For example, an unknown capability (i.e., capability with ID greater than PCI_EXT_CAP_ID_MAX) or a capability that is intentionally chosen to be hidden from the user. Hiding a capability is done by virtualizing and modifying the 'Next Capability Offset' field of the previous capability so it points to the capability after the one that should be hidden. The special case where the first capability in the list should be hidden is handled differently because there is no previous capability that can be modified. In this case, the capability ID and version are zeroed while leaving the next pointer intact. This hides the capability and leaves an anchor for the rest of the capability list. However, today, hiding the first capability in the list is not done properly if the capability is unknown, as struct vfio_pci_core_device->pci_config_map is set to the capability ID during initialization but the capability ID is not properly checked later when used in vfio_config_do_rw(). This leads to the following warning [1] and to an out-of-bounds access to ecap_perms array. Fix it by checking cap_id in vfio_config_do_rw(), and if it is greater than PCI_EXT_CAP_ID_MAX, use an alternative struct perm_bits for direct read only access instead of the ecap_perms array. Note that this is safe since the above is the only case where cap_id can exceed PCI_EXT_CAP_ID_MAX (except for the special capabilities, which are already checked before). [1] WARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfio_pci_config.c:1900 vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] CPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1 (snip) Call Trace: <TASK> ? show_regs+0x69/0x80 ? __warn+0x8d/0x140 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? report_bug+0x18f/0x1a0 ? handle_bug+0x63/0xa0 ? exc_invalid_op+0x19/0x70 ? asm_exc_invalid_op+0x1b/0x20 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? vfio_pci_config_rw+0x244/0x430 [vfio_pci_core] vfio_pci_rw+0x101/0x1b0 [vfio_pci_core] vfio_pci_core_read+0x1d/0x30 [vfio_pci_core] vfio_device_fops_read+0x27/0x40 [vfio] vfs_read+0xbd/0x340 ? vfio_device_fops_unl_ioctl+0xbb/0x740 [vfio] ? __rseq_handle_notify_resume+0xa4/0x4b0 __x64_sys_pread64+0x96/0xc0 x64_sys_call+0x1c3d/0x20d0 do_syscall_64+0x4d/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e CVE-2024-53214 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 important In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent NULL dereference in nfsd4_process_cb_update() @ses is initialized to NULL. If __nfsd4_find_backchannel() finds no available backchannel session, setup_callback_client() will try to dereference @ses and segfault. CVE-2024-53217 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Move events notifier registration to be after device registration Move pkey change work initialization and cleanup from device resources stage to notifier stage, since this is the stage which handles this work events. Fix a race between the device deregistration and pkey change work by moving MLX5_IB_STAGE_DEVICE_NOTIFIER to be after MLX5_IB_STAGE_IB_REG in order to ensure that the notifier is deregistered before the device during cleanup. Which ensures there are no works that are being executed after the device has already unregistered which can cause the panic below. BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 630071 Comm: kworker/1:2 Kdump: loaded Tainted: G W OE --------- --- 5.14.0-162.6.1.el9_1.x86_64 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090008 02/27/2023 Workqueue: events pkey_change_handler [mlx5_ib] RIP: 0010:setup_qp+0x38/0x1f0 [mlx5_ib] Code: ee 41 54 45 31 e4 55 89 f5 53 48 89 fb 48 83 ec 20 8b 77 08 65 48 8b 04 25 28 00 00 00 48 89 44 24 18 48 8b 07 48 8d 4c 24 16 <4c> 8b 38 49 8b 87 80 0b 00 00 4c 89 ff 48 8b 80 08 05 00 00 8b 40 RSP: 0018:ffffbcc54068be20 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff954054494128 RCX: ffffbcc54068be36 RDX: ffff954004934000 RSI: 0000000000000001 RDI: ffff954054494128 RBP: 0000000000000023 R08: ffff954001be2c20 R09: 0000000000000001 R10: ffff954001be2c20 R11: ffff9540260133c0 R12: 0000000000000000 R13: 0000000000000023 R14: 0000000000000000 R15: ffff9540ffcb0905 FS: 0000000000000000(0000) GS:ffff9540ffc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010625c001 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: mlx5_ib_gsi_pkey_change+0x20/0x40 [mlx5_ib] process_one_work+0x1e8/0x3c0 worker_thread+0x50/0x3b0 ? rescuer_thread+0x380/0x380 kthread+0x149/0x170 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x22/0x30 Modules linked in: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) mlx5_fwctl(OE) fwctl(OE) ib_uverbs(OE) mlx5_core(OE) mlxdevm(OE) ib_core(OE) mlx_compat(OE) psample mlxfw(OE) tls knem(OE) netconsole nfsv3 nfs_acl nfs lockd grace fscache netfs qrtr rfkill sunrpc intel_rapl_msr intel_rapl_common rapl hv_balloon hv_utils i2c_piix4 pcspkr joydev fuse ext4 mbcache jbd2 sr_mod sd_mod cdrom t10_pi sg ata_generic pci_hyperv pci_hyperv_intf hyperv_drm drm_shmem_helper drm_kms_helper hv_storvsc syscopyarea hv_netvsc sysfillrect sysimgblt hid_hyperv fb_sys_fops scsi_transport_fc hyperv_keyboard drm ata_piix crct10dif_pclmul crc32_pclmul crc32c_intel libata ghash_clmulni_intel hv_vmbus serio_raw [last unloaded: ib_core] CR2: 0000000000000000 ---[ end trace f6f8be4eae12f7bc ]--- CVE-2024-53224 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: bfa: Fix use-after-free in bfad_im_module_exit() BUG: KASAN: slab-use-after-free in __lock_acquire+0x2aca/0x3a20 Read of size 8 at addr ffff8881082d80c8 by task modprobe/25303 Call Trace: <TASK> dump_stack_lvl+0x95/0xe0 print_report+0xcb/0x620 kasan_report+0xbd/0xf0 __lock_acquire+0x2aca/0x3a20 lock_acquire+0x19b/0x520 _raw_spin_lock+0x2b/0x40 attribute_container_unregister+0x30/0x160 fc_release_transport+0x19/0x90 [scsi_transport_fc] bfad_im_module_exit+0x23/0x60 [bfa] bfad_init+0xdb/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> Allocated by task 25303: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 fc_attach_transport+0x4f/0x4740 [scsi_transport_fc] bfad_im_module_init+0x17/0x80 [bfa] bfad_init+0x23/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 25303: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x38/0x50 kfree+0x212/0x480 bfad_im_module_init+0x7e/0x80 [bfa] bfad_init+0x23/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Above issue happens as follows: bfad_init error = bfad_im_module_init() fc_release_transport(bfad_im_scsi_transport_template); if (error) goto ext; ext: bfad_im_module_exit(); fc_release_transport(bfad_im_scsi_transport_template); --> Trigger double release Don't call bfad_im_module_exit() if bfad_im_module_init() failed. CVE-2024-53227 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: ALSA: 6fire: Release resources at card release The current 6fire code tries to release the resources right after the call of usb6fire_chip_abort(). But at this moment, the card object might be still in use (as we're calling snd_card_free_when_closed()). For avoid potential UAFs, move the release of resources to the card's private_free instead of the manual call of usb6fire_chip_destroy() at the USB disconnect callback. CVE-2024-53239 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 important In the Linux kernel, the following vulnerability has been resolved: xen/netfront: fix crash when removing device When removing a netfront device directly after a suspend/resume cycle it might happen that the queues have not been setup again, causing a crash during the attempt to stop the queues another time. Fix that by checking the queues are existing before trying to stop them. This is XSA-465 / CVE-2024-53240. CVE-2024-53240 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: util: Avoid accessing a ringbuffer not initialized yet If the KVP (or VSS) daemon starts before the VMBus channel's ringbuffer is fully initialized, we can hit the panic below: hv_utils: Registering HyperV Utility Driver hv_vmbus: registering driver hv_utils ... BUG: kernel NULL pointer dereference, address: 0000000000000000 CPU: 44 UID: 0 PID: 2552 Comm: hv_kvp_daemon Tainted: G E 6.11.0-rc3+ #1 RIP: 0010:hv_pkt_iter_first+0x12/0xd0 Call Trace: ... vmbus_recvpacket hv_kvp_onchannelcallback vmbus_on_event tasklet_action_common tasklet_action handle_softirqs irq_exit_rcu sysvec_hyperv_stimer0 </IRQ> <TASK> asm_sysvec_hyperv_stimer0 ... kvp_register_done hvt_op_read vfs_read ksys_read __x64_sys_read This can happen because the KVP/VSS channel callback can be invoked even before the channel is fully opened: 1) as soon as hv_kvp_init() -> hvutil_transport_init() creates /dev/vmbus/hv_kvp, the kvp daemon can open the device file immediately and register itself to the driver by writing a message KVP_OP_REGISTER1 to the file (which is handled by kvp_on_msg() ->kvp_handle_handshake()) and reading the file for the driver's response, which is handled by hvt_op_read(), which calls hvt->on_read(), i.e. kvp_register_done(). 2) the problem with kvp_register_done() is that it can cause the channel callback to be called even before the channel is fully opened, and when the channel callback is starting to run, util_probe()-> vmbus_open() may have not initialized the ringbuffer yet, so the callback can hit the panic of NULL pointer dereference. To reproduce the panic consistently, we can add a "ssleep(10)" for KVP in __vmbus_open(), just before the first hv_ringbuffer_init(), and then we unload and reload the driver hv_utils, and run the daemon manually within the 10 seconds. Fix the panic by reordering the steps in util_probe() so the char dev entry used by the KVP or VSS daemon is not created until after vmbus_open() has completed. This reordering prevents the race condition from happening. CVE-2024-55916 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate libxml2 before 2.12.10 and 2.13.x before 2.13.6 has a use-after-free in xmlSchemaIDCFillNodeTables and xmlSchemaBubbleIDCNodeTables in xmlschemas.c. To exploit this, a crafted XML document must be validated against an XML schema with certain identity constraints, or a crafted XML schema must be used. CVE-2024-56171 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:libxml2-2-2.9.4-46.81.1 important In the Linux kernel, the following vulnerability has been resolved: drm/modes: Avoid divide by zero harder in drm_mode_vrefresh() drm_mode_vrefresh() is trying to avoid divide by zero by checking whether htotal or vtotal are zero. But we may still end up with a div-by-zero of vtotal*htotal*... CVE-2024-56369 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: Use snd_card_free_when_closed() at disconnection The USB disconnect callback is supposed to be short and not too-long waiting. OTOH, the current code uses snd_card_free() at disconnection, but this waits for the close of all used fds, hence it can take long. It eventually blocks the upper layer USB ioctls, which may trigger a soft lockup. An easy workaround is to replace snd_card_free() with snd_card_free_when_closed(). This variant returns immediately while the release of resources is done asynchronously by the card device release at the last close. This patch also splits the code to the disconnect and the free phases; the former is called immediately at the USB disconnect callback while the latter is called from the card destructor. CVE-2024-56531 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 low In the Linux kernel, the following vulnerability has been resolved: ALSA: us122l: Use snd_card_free_when_closed() at disconnection The USB disconnect callback is supposed to be short and not too-long waiting. OTOH, the current code uses snd_card_free() at disconnection, but this waits for the close of all used fds, hence it can take long. It eventually blocks the upper layer USB ioctls, which may trigger a soft lockup. An easy workaround is to replace snd_card_free() with snd_card_free_when_closed(). This variant returns immediately while the release of resources is done asynchronously by the card device release at the last close. The loop of us122l->mmap_count check is dropped as well. The check is useless for the asynchronous operation with *_when_closed(). CVE-2024-56532 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 low In the Linux kernel, the following vulnerability has been resolved: ALSA: usx2y: Use snd_card_free_when_closed() at disconnection The USB disconnect callback is supposed to be short and not too-long waiting. OTOH, the current code uses snd_card_free() at disconnection, but this waits for the close of all used fds, hence it can take long. It eventually blocks the upper layer USB ioctls, which may trigger a soft lockup. An easy workaround is to replace snd_card_free() with snd_card_free_when_closed(). This variant returns immediately while the release of resources is done asynchronously by the card device release at the last close. CVE-2024-56533 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 low In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_config_scan() Replace one-element array with a flexible-array member in `struct mwifiex_ie_types_wildcard_ssid_params` to fix the following warning on a MT8173 Chromebook (mt8173-elm-hana): [ 356.775250] ------------[ cut here ]------------ [ 356.784543] memcpy: detected field-spanning write (size 6) of single field "wildcard_ssid_tlv->ssid" at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1) [ 356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_networks+0x4fc/0xf28 [mwifiex] The "(size 6)" above is exactly the length of the SSID of the network this device was connected to. The source of the warning looks like: ssid_len = user_scan_in->ssid_list[i].ssid_len; [...] memcpy(wildcard_ssid_tlv->ssid, user_scan_in->ssid_list[i].ssid, ssid_len); There is a #define WILDCARD_SSID_TLV_MAX_SIZE that uses sizeof() on this struct, but it already didn't account for the size of the one-element array, so it doesn't need to be changed. CVE-2024-56539 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 important In the Linux kernel, the following vulnerability has been resolved: hfsplus: don't query the device logical block size multiple times Devices block sizes may change. One of these cases is a loop device by using ioctl LOOP_SET_BLOCK_SIZE. While this may cause other issues like IO being rejected, in the case of hfsplus, it will allocate a block by using that size and potentially write out-of-bounds when hfsplus_read_wrapper calls hfsplus_submit_bio and the latter function reads a different io_size. Using a new min_io_size initally set to sb_min_blocksize works for the purposes of the original fix, since it will be set to the max between HFSPLUS_SECTOR_SIZE and the first seen logical block size. We still use the max between HFSPLUS_SECTOR_SIZE and min_io_size in case the latter is not initialized. Tested by mounting an hfsplus filesystem with loop block sizes 512, 1024 and 4096. The produced KASAN report before the fix looks like this: [ 419.944641] ================================================================== [ 419.945655] BUG: KASAN: slab-use-after-free in hfsplus_read_wrapper+0x659/0xa0a [ 419.946703] Read of size 2 at addr ffff88800721fc00 by task repro/10678 [ 419.947612] [ 419.947846] CPU: 0 UID: 0 PID: 10678 Comm: repro Not tainted 6.12.0-rc5-00008-gdf56e0f2f3ca #84 [ 419.949007] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 419.950035] Call Trace: [ 419.950384] <TASK> [ 419.950676] dump_stack_lvl+0x57/0x78 [ 419.951212] ? hfsplus_read_wrapper+0x659/0xa0a [ 419.951830] print_report+0x14c/0x49e [ 419.952361] ? __virt_addr_valid+0x267/0x278 [ 419.952979] ? kmem_cache_debug_flags+0xc/0x1d [ 419.953561] ? hfsplus_read_wrapper+0x659/0xa0a [ 419.954231] kasan_report+0x89/0xb0 [ 419.954748] ? hfsplus_read_wrapper+0x659/0xa0a [ 419.955367] hfsplus_read_wrapper+0x659/0xa0a [ 419.955948] ? __pfx_hfsplus_read_wrapper+0x10/0x10 [ 419.956618] ? do_raw_spin_unlock+0x59/0x1a9 [ 419.957214] ? _raw_spin_unlock+0x1a/0x2e [ 419.957772] hfsplus_fill_super+0x348/0x1590 [ 419.958355] ? hlock_class+0x4c/0x109 [ 419.958867] ? __pfx_hfsplus_fill_super+0x10/0x10 [ 419.959499] ? __pfx_string+0x10/0x10 [ 419.960006] ? lock_acquire+0x3e2/0x454 [ 419.960532] ? bdev_name.constprop.0+0xce/0x243 [ 419.961129] ? __pfx_bdev_name.constprop.0+0x10/0x10 [ 419.961799] ? pointer+0x3f0/0x62f [ 419.962277] ? __pfx_pointer+0x10/0x10 [ 419.962761] ? vsnprintf+0x6c4/0xfba [ 419.963178] ? __pfx_vsnprintf+0x10/0x10 [ 419.963621] ? setup_bdev_super+0x376/0x3b3 [ 419.964029] ? snprintf+0x9d/0xd2 [ 419.964344] ? __pfx_snprintf+0x10/0x10 [ 419.964675] ? lock_acquired+0x45c/0x5e9 [ 419.965016] ? set_blocksize+0x139/0x1c1 [ 419.965381] ? sb_set_blocksize+0x6d/0xae [ 419.965742] ? __pfx_hfsplus_fill_super+0x10/0x10 [ 419.966179] mount_bdev+0x12f/0x1bf [ 419.966512] ? __pfx_mount_bdev+0x10/0x10 [ 419.966886] ? vfs_parse_fs_string+0xce/0x111 [ 419.967293] ? __pfx_vfs_parse_fs_string+0x10/0x10 [ 419.967702] ? __pfx_hfsplus_mount+0x10/0x10 [ 419.968073] legacy_get_tree+0x104/0x178 [ 419.968414] vfs_get_tree+0x86/0x296 [ 419.968751] path_mount+0xba3/0xd0b [ 419.969157] ? __pfx_path_mount+0x10/0x10 [ 419.969594] ? kmem_cache_free+0x1e2/0x260 [ 419.970311] do_mount+0x99/0xe0 [ 419.970630] ? __pfx_do_mount+0x10/0x10 [ 419.971008] __do_sys_mount+0x199/0x1c9 [ 419.971397] do_syscall_64+0xd0/0x135 [ 419.971761] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 419.972233] RIP: 0033:0x7c3cb812972e [ 419.972564] Code: 48 8b 0d f5 46 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c2 46 0d 00 f7 d8 64 89 01 48 [ 419.974371] RSP: 002b:00007ffe30632548 EFLAGS: 00000286 ORIG_RAX: 00000000000000a5 [ 419.975048] RAX: ffffffffffffffda RBX: 00007ffe306328d8 RCX: 00007c3cb812972e [ 419.975701] RDX: 0000000020000000 RSI: 0000000020000c80 RDI: ---truncated--- CVE-2024-56548 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 important In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix usage slab after free [ +0.000021] BUG: KASAN: slab-use-after-free in drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000027] Read of size 8 at addr ffff8881b8605f88 by task amd_pci_unplug/2147 [ +0.000023] CPU: 6 PID: 2147 Comm: amd_pci_unplug Not tainted 6.10.0+ #1 [ +0.000016] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020 [ +0.000016] Call Trace: [ +0.000008] <TASK> [ +0.000009] dump_stack_lvl+0x76/0xa0 [ +0.000017] print_report+0xce/0x5f0 [ +0.000017] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000019] ? srso_return_thunk+0x5/0x5f [ +0.000015] ? kasan_complete_mode_report_info+0x72/0x200 [ +0.000016] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000019] kasan_report+0xbe/0x110 [ +0.000015] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000023] __asan_report_load8_noabort+0x14/0x30 [ +0.000014] drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000020] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? __kasan_check_write+0x14/0x30 [ +0.000016] ? __pfx_drm_sched_entity_flush+0x10/0x10 [gpu_sched] [ +0.000020] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? __kasan_check_write+0x14/0x30 [ +0.000013] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? enable_work+0x124/0x220 [ +0.000015] ? __pfx_enable_work+0x10/0x10 [ +0.000013] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? free_large_kmalloc+0x85/0xf0 [ +0.000016] drm_sched_entity_destroy+0x18/0x30 [gpu_sched] [ +0.000020] amdgpu_vce_sw_fini+0x55/0x170 [amdgpu] [ +0.000735] ? __kasan_check_read+0x11/0x20 [ +0.000016] vce_v4_0_sw_fini+0x80/0x110 [amdgpu] [ +0.000726] amdgpu_device_fini_sw+0x331/0xfc0 [amdgpu] [ +0.000679] ? mutex_unlock+0x80/0xe0 [ +0.000017] ? __pfx_amdgpu_device_fini_sw+0x10/0x10 [amdgpu] [ +0.000662] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? __kasan_check_write+0x14/0x30 [ +0.000013] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? mutex_unlock+0x80/0xe0 [ +0.000016] amdgpu_driver_release_kms+0x16/0x80 [amdgpu] [ +0.000663] drm_minor_release+0xc9/0x140 [drm] [ +0.000081] drm_release+0x1fd/0x390 [drm] [ +0.000082] __fput+0x36c/0xad0 [ +0.000018] __fput_sync+0x3c/0x50 [ +0.000014] __x64_sys_close+0x7d/0xe0 [ +0.000014] x64_sys_call+0x1bc6/0x2680 [ +0.000014] do_syscall_64+0x70/0x130 [ +0.000014] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? irqentry_exit_to_user_mode+0x60/0x190 [ +0.000015] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? irqentry_exit+0x43/0x50 [ +0.000012] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? exc_page_fault+0x7c/0x110 [ +0.000015] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ +0.000014] RIP: 0033:0x7ffff7b14f67 [ +0.000013] Code: ff e8 0d 16 02 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 73 ba f7 ff [ +0.000026] RSP: 002b:00007fffffffe378 EFLAGS: 00000246 ORIG_RAX: 0000000000000003 [ +0.000019] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffff7b14f67 [ +0.000014] RDX: 0000000000000000 RSI: 00007ffff7f6f47a RDI: 0000000000000003 [ +0.000014] RBP: 00007fffffffe3a0 R08: 0000555555569890 R09: 0000000000000000 [ +0.000014] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fffffffe5c8 [ +0.000013] R13: 00005555555552a9 R14: 0000555555557d48 R15: 00007ffff7ffd040 [ +0.000020] </TASK> [ +0.000016] Allocated by task 383 on cpu 7 at 26.880319s: [ +0.000014] kasan_save_stack+0x28/0x60 [ +0.000008] kasan_save_track+0x18/0x70 [ +0.000007] kasan_save_alloc_info+0x38/0x60 [ +0.000007] __kasan_kmalloc+0xc1/0xd0 [ +0.000007] kmalloc_trace_noprof+0x180/0x380 [ +0.000007] drm_sched_init+0x411/0xec0 [gpu_sched] [ +0.000012] amdgpu_device_init+0x695f/0xa610 [amdgpu] [ +0.000658] amdgpu_driver_load_kms+0x1a/0x120 [amdgpu] [ +0.000662] amdgpu_pci_p ---truncated--- CVE-2024-56551 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix regression with module command in stack_trace_filter When executing the following command: # echo "write*:mod:ext3" > /sys/kernel/tracing/stack_trace_filter The current mod command causes a null pointer dereference. While commit 0f17976568b3f ("ftrace: Fix regression with module command in stack_trace_filter") has addressed part of the issue, it left a corner case unhandled, which still results in a kernel crash. CVE-2024-56569 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: ovl: Filter invalid inodes with missing lookup function Add a check to the ovl_dentry_weird() function to prevent the processing of directory inodes that lack the lookup function. This is important because such inodes can cause errors in overlayfs when passed to the lowerstack. CVE-2024-56570 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: ts2020: fix null-ptr-deref in ts2020_probe() KASAN reported a null-ptr-deref issue when executing the following command: # echo ts2020 0x20 > /sys/bus/i2c/devices/i2c-0/new_device KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 53 UID: 0 PID: 970 Comm: systemd-udevd Not tainted 6.12.0-rc2+ #24 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) RIP: 0010:ts2020_probe+0xad/0xe10 [ts2020] RSP: 0018:ffffc9000abbf598 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffffc0714809 RDX: 0000000000000002 RSI: ffff88811550be00 RDI: 0000000000000010 RBP: ffff888109868800 R08: 0000000000000001 R09: fffff52001577eb6 R10: 0000000000000000 R11: ffffc9000abbff50 R12: ffffffffc0714790 R13: 1ffff92001577eb8 R14: ffffffffc07190d0 R15: 0000000000000001 FS: 00007f95f13b98c0(0000) GS:ffff888149280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555d2634b000 CR3: 0000000152236000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ts2020_probe+0xad/0xe10 [ts2020] i2c_device_probe+0x421/0xb40 really_probe+0x266/0x850 ... The cause of the problem is that when using sysfs to dynamically register an i2c device, there is no platform data, but the probe process of ts2020 needs to use platform data, resulting in a null pointer being accessed. Solve this problem by adding checks to platform data. CVE-2024-56574 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: leds: class: Protect brightness_show() with led_cdev->led_access mutex There is NULL pointer issue observed if from Process A where hid device being added which results in adding a led_cdev addition and later a another call to access of led_cdev attribute from Process B can result in NULL pointer issue. Use mutex led_cdev->led_access to protect access to led->cdev and its attribute inside brightness_show() and max_brightness_show() and also update the comment for mutex that it should be used to protect the led class device fields. Process A Process B kthread+0x114 worker_thread+0x244 process_scheduled_works+0x248 uhid_device_add_worker+0x24 hid_add_device+0x120 device_add+0x268 bus_probe_device+0x94 device_initial_probe+0x14 __device_attach+0xfc bus_for_each_drv+0x10c __device_attach_driver+0x14c driver_probe_device+0x3c __driver_probe_device+0xa0 really_probe+0x190 hid_device_probe+0x130 ps_probe+0x990 ps_led_register+0x94 devm_led_classdev_register_ext+0x58 led_classdev_register_ext+0x1f8 device_create_with_groups+0x48 device_create_groups_vargs+0xc8 device_add+0x244 kobject_uevent+0x14 kobject_uevent_env[jt]+0x224 mutex_unlock[jt]+0xc4 __mutex_unlock_slowpath+0xd4 wake_up_q+0x70 try_to_wake_up[jt]+0x48c preempt_schedule_common+0x28 __schedule+0x628 __switch_to+0x174 el0t_64_sync+0x1a8/0x1ac el0t_64_sync_handler+0x68/0xbc el0_svc+0x38/0x68 do_el0_svc+0x1c/0x28 el0_svc_common+0x80/0xe0 invoke_syscall+0x58/0x114 __arm64_sys_read+0x1c/0x2c ksys_read+0x78/0xe8 vfs_read+0x1e0/0x2c8 kernfs_fop_read_iter+0x68/0x1b4 seq_read_iter+0x158/0x4ec kernfs_seq_show+0x44/0x54 sysfs_kf_seq_show+0xb4/0x130 dev_attr_show+0x38/0x74 brightness_show+0x20/0x4c dualshock4_led_get_brightness+0xc/0x74 [ 3313.874295][ T4013] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060 [ 3313.874301][ T4013] Mem abort info: [ 3313.874303][ T4013] ESR = 0x0000000096000006 [ 3313.874305][ T4013] EC = 0x25: DABT (current EL), IL = 32 bits [ 3313.874307][ T4013] SET = 0, FnV = 0 [ 3313.874309][ T4013] EA = 0, S1PTW = 0 [ 3313.874311][ T4013] FSC = 0x06: level 2 translation fault [ 3313.874313][ T4013] Data abort info: [ 3313.874314][ T4013] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000 [ 3313.874316][ T4013] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 3313.874318][ T4013] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 3313.874320][ T4013] user pgtable: 4k pages, 39-bit VAs, pgdp=00000008f2b0a000 .. [ 3313.874332][ T4013] Dumping ftrace buffer: [ 3313.874334][ T4013] (ftrace buffer empty) .. .. [ dd3313.874639][ T4013] CPU: 6 PID: 4013 Comm: InputReader [ 3313.874648][ T4013] pc : dualshock4_led_get_brightness+0xc/0x74 [ 3313.874653][ T4013] lr : led_update_brightness+0x38/0x60 [ 3313.874656][ T4013] sp : ffffffc0b910bbd0 .. .. [ 3313.874685][ T4013] Call trace: [ 3313.874687][ T4013] dualshock4_led_get_brightness+0xc/0x74 [ 3313.874690][ T4013] brightness_show+0x20/0x4c [ 3313.874692][ T4013] dev_attr_show+0x38/0x74 [ 3313.874696][ T4013] sysfs_kf_seq_show+0xb4/0x130 [ 3313.874700][ T4013] kernfs_seq_show+0x44/0x54 [ 3313.874703][ T4013] seq_read_iter+0x158/0x4ec [ 3313.874705][ T4013] kernfs_fop_read_iter+0x68/0x1b4 [ 3313.874708][ T4013] vfs_read+0x1e0/0x2c8 [ 3313.874711][ T4013] ksys_read+0x78/0xe8 [ 3313.874714][ T4013] __arm64_sys_read+0x1c/0x2c [ 3313.874718][ T4013] invoke_syscall+0x58/0x114 [ 3313.874721][ T4013] el0_svc_common+0x80/0xe0 [ 3313.874724][ T4013] do_el0_svc+0x1c/0x28 [ 3313.874727][ T4013] el0_svc+0x38/0x68 [ 3313.874730][ T4013] el0t_64_sync_handler+0x68/0xbc [ 3313.874732][ T4013] el0t_64_sync+0x1a8/0x1ac CVE-2024-56587 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix oops due to NULL pointer dereference in brcmf_sdiod_sglist_rw() This patch fixes a NULL pointer dereference bug in brcmfmac that occurs when a high 'sd_sgentry_align' value applies (e.g. 512) and a lot of queued SKBs are sent from the pkt queue. The problem is the number of entries in the pre-allocated sgtable, it is nents = max(rxglom_size, txglom_size) + max(rxglom_size, txglom_size) >> 4 + 1. Given the default [rt]xglom_size=32 it's actually 35 which is too small. Worst case, the pkt queue can end up with 64 SKBs. This occurs when a new SKB is added for each original SKB if tailroom isn't enough to hold tail_pad. At least one sg entry is needed for each SKB. So, eventually the "skb_queue_walk loop" in brcmf_sdiod_sglist_rw may run out of sg entries. This makes sg_next return NULL and this causes the oops. The patch sets nents to max(rxglom_size, txglom_size) * 2 to be able handle the worst-case. Btw. this requires only 64-35=29 * 16 (or 20 if CONFIG_NEED_SG_DMA_LENGTH) = 464 additional bytes of memory. CVE-2024-56593 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: set the right AMDGPU sg segment limitation The driver needs to set the correct max_segment_size; otherwise debug_dma_map_sg() will complain about the over-mapping of the AMDGPU sg length as following: WARNING: CPU: 6 PID: 1964 at kernel/dma/debug.c:1178 debug_dma_map_sg+0x2dc/0x370 [ 364.049444] Modules linked in: veth amdgpu(OE) amdxcp drm_exec gpu_sched drm_buddy drm_ttm_helper ttm(OE) drm_suballoc_helper drm_display_helper drm_kms_helper i2c_algo_bit rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace netfs xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo iptable_nat xt_addrtype iptable_filter br_netfilter nvme_fabrics overlay nfnetlink_cttimeout nfnetlink openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bridge stp llc amd_atl intel_rapl_msr intel_rapl_common sunrpc sch_fq_codel snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg edac_mce_amd binfmt_misc snd_hda_codec snd_pci_acp6x snd_hda_core snd_acp_config snd_hwdep snd_soc_acpi kvm_amd snd_pcm kvm snd_seq_midi snd_seq_midi_event crct10dif_pclmul ghash_clmulni_intel sha512_ssse3 snd_rawmidi sha256_ssse3 sha1_ssse3 aesni_intel snd_seq nls_iso8859_1 crypto_simd snd_seq_device cryptd snd_timer rapl input_leds snd [ 364.049532] ipmi_devintf wmi_bmof ccp serio_raw k10temp sp5100_tco soundcore ipmi_msghandler cm32181 industrialio mac_hid msr parport_pc ppdev lp parport drm efi_pstore ip_tables x_tables pci_stub crc32_pclmul nvme ahci libahci i2c_piix4 r8169 nvme_core i2c_designware_pci realtek i2c_ccgx_ucsi video wmi hid_generic cdc_ether usbnet usbhid hid r8152 mii [ 364.049576] CPU: 6 PID: 1964 Comm: rocminfo Tainted: G OE 6.10.0-custom #492 [ 364.049579] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 06/13/2021 [ 364.049582] RIP: 0010:debug_dma_map_sg+0x2dc/0x370 [ 364.049585] Code: 89 4d b8 e8 36 b1 86 00 8b 4d b8 48 8b 55 b0 44 8b 45 a8 4c 8b 4d a0 48 89 c6 48 c7 c7 00 4b 74 bc 4c 89 4d b8 e8 b4 73 f3 ff <0f> 0b 4c 8b 4d b8 8b 15 c8 2c b8 01 85 d2 0f 85 ee fd ff ff 8b 05 [ 364.049588] RSP: 0018:ffff9ca600b57ac0 EFLAGS: 00010286 [ 364.049590] RAX: 0000000000000000 RBX: ffff88b7c132b0c8 RCX: 0000000000000027 [ 364.049592] RDX: ffff88bb0f521688 RSI: 0000000000000001 RDI: ffff88bb0f521680 [ 364.049594] RBP: ffff9ca600b57b20 R08: 000000000000006f R09: ffff9ca600b57930 [ 364.049596] R10: ffff9ca600b57928 R11: ffffffffbcb46328 R12: 0000000000000000 [ 364.049597] R13: 0000000000000001 R14: ffff88b7c19c0700 R15: ffff88b7c9059800 [ 364.049599] FS: 00007fb2d3516e80(0000) GS:ffff88bb0f500000(0000) knlGS:0000000000000000 [ 364.049601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 364.049603] CR2: 000055610bd03598 CR3: 00000001049f6000 CR4: 0000000000350ef0 [ 364.049605] Call Trace: [ 364.049607] <TASK> [ 364.049609] ? show_regs+0x6d/0x80 [ 364.049614] ? __warn+0x8c/0x140 [ 364.049618] ? debug_dma_map_sg+0x2dc/0x370 [ 364.049621] ? report_bug+0x193/0x1a0 [ 364.049627] ? handle_bug+0x46/0x80 [ 364.049631] ? exc_invalid_op+0x1d/0x80 [ 364.049635] ? asm_exc_invalid_op+0x1f/0x30 [ 364.049642] ? debug_dma_map_sg+0x2dc/0x370 [ 364.049647] __dma_map_sg_attrs+0x90/0xe0 [ 364.049651] dma_map_sgtable+0x25/0x40 [ 364.049654] amdgpu_bo_move+0x59a/0x850 [amdgpu] [ 364.049935] ? srso_return_thunk+0x5/0x5f [ 364.049939] ? amdgpu_ttm_tt_populate+0x5d/0xc0 [amdgpu] [ 364.050095] ttm_bo_handle_move_mem+0xc3/0x180 [ttm] [ 364.050103] ttm_bo_validate+0xc1/0x160 [ttm] [ 364.050108] ? amdgpu_ttm_tt_get_user_pages+0xe5/0x1b0 [amdgpu] [ 364.050263] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0xa12/0xc90 [amdgpu] [ 364.050473] kfd_ioctl_alloc_memory_of_gpu+0x16b/0x3b0 [amdgpu] [ 364.050680] kfd_ioctl+0x3c2/0x530 [amdgpu] [ 364.050866] ? __pfx_kfd_ioctl_alloc_memory_of_gpu+0x10/0x10 [amdgpu] [ 364.05105 ---truncated--- CVE-2024-56594 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: avoid NULL pointer error during sdio remove When running 'rmmod ath10k', ath10k_sdio_remove() will free sdio workqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON is set to yes, kernel panic will happen: Call trace: destroy_workqueue+0x1c/0x258 ath10k_sdio_remove+0x84/0x94 sdio_bus_remove+0x50/0x16c device_release_driver_internal+0x188/0x25c device_driver_detach+0x20/0x2c This is because during 'rmmod ath10k', ath10k_sdio_remove() will call ath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release() will finally be called in ath10k_core_destroy(). This function will free struct cfg80211_registered_device *rdev and all its members, including wiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio workqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON. After device release, destroy_workqueue() will use NULL pointer then the kernel panic happen. Call trace: ath10k_sdio_remove ->ath10k_core_unregister ...... ->ath10k_core_stop ->ath10k_hif_stop ->ath10k_sdio_irq_disable ->ath10k_hif_power_down ->del_timer_sync(&ar_sdio->sleep_timer) ->ath10k_core_destroy ->ath10k_mac_destroy ->ieee80211_free_hw ->wiphy_free ...... ->wiphy_dev_release ->destroy_workqueue Need to call destroy_workqueue() before ath10k_core_destroy(), free the work queue buffer first and then free pointer of work queue by ath10k_core_destroy(). This order matches the error path order in ath10k_sdio_probe(). No work will be queued on sdio workqueue between it is destroyed and ath10k_core_destroy() is called. Based on the call_stack above, the reason is: Only ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and ath10k_sdio_irq_disable() will queue work on sdio workqueue. Sleep timer will be deleted before ath10k_core_destroy() in ath10k_hif_power_down(). ath10k_sdio_irq_disable() only be called in ath10k_hif_stop(). ath10k_core_unregister() will call ath10k_hif_power_down() to stop hif bus, so ath10k_sdio_hif_tx_sg() won't be called anymore. Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189 CVE-2024-56599 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate Use of Hardware Page Aggregation (HPA) and Stage-1 and/or Stage-2 translation on Cortex-A77, Cortex-A78, Cortex-A78C, Cortex-A78AE, Cortex-A710, Cortex-X1, Cortex-X1C, Cortex-X2, Cortex-X3, Cortex-X4, Cortex-X925, Neoverse V1, Neoverse V2, Neoverse V3, Neoverse V3AE, Neoverse N2 may permit bypass of Stage-2 translation and/or GPT protection. CVE-2024-5660 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 critical In the Linux kernel, the following vulnerability has been resolved: net: inet6: do not leave a dangling sk pointer in inet6_create() sock_init_data() attaches the allocated sk pointer to the provided sock object. If inet6_create() fails later, the sk object is released, but the sock object retains the dangling sk pointer, which may cause use-after-free later. Clear the sock sk pointer on error. CVE-2024-56600 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 important In the Linux kernel, the following vulnerability has been resolved: net: inet: do not leave a dangling sk pointer in inet_create() sock_init_data() attaches the allocated sk object to the provided sock object. If inet_create() fails later, the sk object is freed, but the sock object retains the dangling pointer, which may create use-after-free later. Clear the sk pointer in the sock object on error. CVE-2024-56601 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 important In the Linux kernel, the following vulnerability has been resolved: net: af_can: do not leave a dangling sk pointer in can_create() On error can_create() frees the allocated sk object, but sock_init_data() has already attached it to the provided sock object. This will leave a dangling sk pointer in the sock object and may cause use-after-free later. CVE-2024-56603 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: avoid leaving dangling sk pointer in rfcomm_sock_alloc() bt_sock_alloc() attaches allocated sk object to the provided sock object. If rfcomm_dlc_alloc() fails, we release the sk object, but leave the dangling pointer in the sock object, which may cause use-after-free. Fix this by swapping calls to bt_sock_alloc() and rfcomm_dlc_alloc(). CVE-2024-56604 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 important In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2cap_sock_create() bt_sock_alloc() allocates the sk object and attaches it to the provided sock object. On error l2cap_sock_alloc() frees the sk object, but the dangling pointer is still attached to the sock object, which may create use-after-free in other code. CVE-2024-56605 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 important In the Linux kernel, the following vulnerability has been resolved: af_packet: avoid erroring out after sock_init_data() in packet_create() After sock_init_data() the allocated sk object is attached to the provided sock object. On error, packet_create() frees the sk object leaving the dangling pointer in the sock object on return. Some other code may try to use this pointer and cause use-after-free. CVE-2024-56606 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: bpf: fix OOB devmap writes when deleting elements Jordy reported issue against XSKMAP which also applies to DEVMAP - the index used for accessing map entry, due to being a signed integer, causes the OOB writes. Fix is simple as changing the type from int to u32, however, when compared to XSKMAP case, one more thing needs to be addressed. When map is released from system via dev_map_free(), we iterate through all of the entries and an iterator variable is also an int, which implies OOB accesses. Again, change it to be u32. Example splat below: [ 160.724676] BUG: unable to handle page fault for address: ffffc8fc2c001000 [ 160.731662] #PF: supervisor read access in kernel mode [ 160.736876] #PF: error_code(0x0000) - not-present page [ 160.742095] PGD 0 P4D 0 [ 160.744678] Oops: Oops: 0000 [#1] PREEMPT SMP [ 160.749106] CPU: 1 UID: 0 PID: 520 Comm: kworker/u145:12 Not tainted 6.12.0-rc1+ #487 [ 160.757050] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019 [ 160.767642] Workqueue: events_unbound bpf_map_free_deferred [ 160.773308] RIP: 0010:dev_map_free+0x77/0x170 [ 160.777735] Code: 00 e8 fd 91 ed ff e8 b8 73 ed ff 41 83 7d 18 19 74 6e 41 8b 45 24 49 8b bd f8 00 00 00 31 db 85 c0 74 48 48 63 c3 48 8d 04 c7 <48> 8b 28 48 85 ed 74 30 48 8b 7d 18 48 85 ff 74 05 e8 b3 52 fa ff [ 160.796777] RSP: 0018:ffffc9000ee1fe38 EFLAGS: 00010202 [ 160.802086] RAX: ffffc8fc2c001000 RBX: 0000000080000000 RCX: 0000000000000024 [ 160.809331] RDX: 0000000000000000 RSI: 0000000000000024 RDI: ffffc9002c001000 [ 160.816576] RBP: 0000000000000000 R08: 0000000000000023 R09: 0000000000000001 [ 160.823823] R10: 0000000000000001 R11: 00000000000ee6b2 R12: dead000000000122 [ 160.831066] R13: ffff88810c928e00 R14: ffff8881002df405 R15: 0000000000000000 [ 160.838310] FS: 0000000000000000(0000) GS:ffff8897e0c40000(0000) knlGS:0000000000000000 [ 160.846528] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 160.852357] CR2: ffffc8fc2c001000 CR3: 0000000005c32006 CR4: 00000000007726f0 [ 160.859604] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 160.866847] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 160.874092] PKRU: 55555554 [ 160.876847] Call Trace: [ 160.879338] <TASK> [ 160.881477] ? __die+0x20/0x60 [ 160.884586] ? page_fault_oops+0x15a/0x450 [ 160.888746] ? search_extable+0x22/0x30 [ 160.892647] ? search_bpf_extables+0x5f/0x80 [ 160.896988] ? exc_page_fault+0xa9/0x140 [ 160.900973] ? asm_exc_page_fault+0x22/0x30 [ 160.905232] ? dev_map_free+0x77/0x170 [ 160.909043] ? dev_map_free+0x58/0x170 [ 160.912857] bpf_map_free_deferred+0x51/0x90 [ 160.917196] process_one_work+0x142/0x370 [ 160.921272] worker_thread+0x29e/0x3b0 [ 160.925082] ? rescuer_thread+0x4b0/0x4b0 [ 160.929157] kthread+0xd4/0x110 [ 160.932355] ? kthread_park+0x80/0x80 [ 160.936079] ret_from_fork+0x2d/0x50 [ 160.943396] ? kthread_park+0x80/0x80 [ 160.950803] ret_from_fork_asm+0x11/0x20 [ 160.958482] </TASK> CVE-2024-56615 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/dp_mst: Fix MST sideband message body length check Fix the MST sideband message body length check, which must be at least 1 byte accounting for the message body CRC (aka message data CRC) at the end of the message. This fixes a case where an MST branch device returns a header with a correct header CRC (indicating a correctly received body length), with the body length being incorrectly set to 0. This will later lead to a memory corruption in drm_dp_sideband_append_payload() and the following errors in dmesg: UBSAN: array-index-out-of-bounds in drivers/gpu/drm/display/drm_dp_mst_topology.c:786:25 index -1 is out of range for type 'u8 [48]' Call Trace: drm_dp_sideband_append_payload+0x33d/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper] memcpy: detected field-spanning write (size 18446744073709551615) of single field "&msg->msg[msg->curlen]" at drivers/gpu/drm/display/drm_dp_mst_topology.c:791 (size 256) Call Trace: drm_dp_sideband_append_payload+0x324/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper] CVE-2024-56616 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix use after free on unload System crash is observed with stack trace warning of use after free. There are 2 signals to tell dpc_thread to terminate (UNLOADING flag and kthread_stop). On setting the UNLOADING flag when dpc_thread happens to run at the time and sees the flag, this causes dpc_thread to exit and clean up itself. When kthread_stop is called for final cleanup, this causes use after free. Remove UNLOADING signal to terminate dpc_thread. Use the kthread_stop as the main signal to exit dpc_thread. [596663.812935] kernel BUG at mm/slub.c:294! [596663.812950] invalid opcode: 0000 [#1] SMP PTI [596663.812957] CPU: 13 PID: 1475935 Comm: rmmod Kdump: loaded Tainted: G IOE --------- - - 4.18.0-240.el8.x86_64 #1 [596663.812960] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 08/20/2012 [596663.812974] RIP: 0010:__slab_free+0x17d/0x360 ... [596663.813008] Call Trace: [596663.813022] ? __dentry_kill+0x121/0x170 [596663.813030] ? _cond_resched+0x15/0x30 [596663.813034] ? _cond_resched+0x15/0x30 [596663.813039] ? wait_for_completion+0x35/0x190 [596663.813048] ? try_to_wake_up+0x63/0x540 [596663.813055] free_task+0x5a/0x60 [596663.813061] kthread_stop+0xf3/0x100 [596663.813103] qla2x00_remove_one+0x284/0x440 [qla2xxx] CVE-2024-56623 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 important In the Linux kernel, the following vulnerability has been resolved: ocfs2: free inode when ocfs2_get_init_inode() fails syzbot is reporting busy inodes after unmount, for commit 9c89fe0af826 ("ocfs2: Handle error from dquot_initialize()") forgot to call iput() when new_inode() succeeded and dquot_initialize() failed. CVE-2024-56630 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Fix slab-use-after-free read in sg_release() Fix a use-after-free bug in sg_release(), detected by syzbot with KASAN: BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5838 __mutex_unlock_slowpath+0xe2/0x750 kernel/locking/mutex.c:912 sg_release+0x1f4/0x2e0 drivers/scsi/sg.c:407 In sg_release(), the function kref_put(&sfp->f_ref, sg_remove_sfp) is called before releasing the open_rel_lock mutex. The kref_put() call may decrement the reference count of sfp to zero, triggering its cleanup through sg_remove_sfp(). This cleanup includes scheduling deferred work via sg_remove_sfp_usercontext(), which ultimately frees sfp. After kref_put(), sg_release() continues to unlock open_rel_lock and may reference sfp or sdp. If sfp has already been freed, this results in a slab-use-after-free error. Move the kref_put(&sfp->f_ref, sg_remove_sfp) call after unlocking the open_rel_lock mutex. This ensures: - No references to sfp or sdp occur after the reference count is decremented. - Cleanup functions such as sg_remove_sfp() and sg_remove_sfp_usercontext() can safely execute without impacting the mutex handling in sg_release(). The fix has been tested and validated by syzbot. This patch closes the bug reported at the following syzkaller link and ensures proper sequencing of resource cleanup and mutex operations, eliminating the risk of use-after-free errors in sg_release(). CVE-2024-56631 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 important In the Linux kernel, the following vulnerability has been resolved: tcp_bpf: Fix the sk_mem_uncharge logic in tcp_bpf_sendmsg The current sk memory accounting logic in __SK_REDIRECT is pre-uncharging tosend bytes, which is either msg->sg.size or a smaller value apply_bytes. Potential problems with this strategy are as follows: - If the actual sent bytes are smaller than tosend, we need to charge some bytes back, as in line 487, which is okay but seems not clean. - When tosend is set to apply_bytes, as in line 417, and (ret < 0), we may miss uncharging (msg->sg.size - apply_bytes) bytes. [...] 415 tosend = msg->sg.size; 416 if (psock->apply_bytes && psock->apply_bytes < tosend) 417 tosend = psock->apply_bytes; [...] 443 sk_msg_return(sk, msg, tosend); 444 release_sock(sk); 446 origsize = msg->sg.size; 447 ret = tcp_bpf_sendmsg_redir(sk_redir, redir_ingress, 448 msg, tosend, flags); 449 sent = origsize - msg->sg.size; [...] 454 lock_sock(sk); 455 if (unlikely(ret < 0)) { 456 int free = sk_msg_free_nocharge(sk, msg); 458 if (!cork) 459 *copied -= free; 460 } [...] 487 if (eval == __SK_REDIRECT) 488 sk_mem_charge(sk, tosend - sent); [...] When running the selftest test_txmsg_redir_wait_sndmem with txmsg_apply, the following warning will be reported: ------------[ cut here ]------------ WARNING: CPU: 6 PID: 57 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x190/0x1a0 Modules linked in: CPU: 6 UID: 0 PID: 57 Comm: kworker/6:0 Not tainted 6.12.0-rc1.bm.1-amd64+ #43 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Workqueue: events sk_psock_destroy RIP: 0010:inet_sock_destruct+0x190/0x1a0 RSP: 0018:ffffad0a8021fe08 EFLAGS: 00010206 RAX: 0000000000000011 RBX: ffff9aab4475b900 RCX: ffff9aab481a0800 RDX: 0000000000000303 RSI: 0000000000000011 RDI: ffff9aab4475b900 RBP: ffff9aab4475b990 R08: 0000000000000000 R09: ffff9aab40050ec0 R10: 0000000000000000 R11: ffff9aae6fdb1d01 R12: ffff9aab49c60400 R13: ffff9aab49c60598 R14: ffff9aab49c60598 R15: dead000000000100 FS: 0000000000000000(0000) GS:ffff9aae6fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffec7e47bd8 CR3: 00000001a1a1c004 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __warn+0x89/0x130 ? inet_sock_destruct+0x190/0x1a0 ? report_bug+0xfc/0x1e0 ? handle_bug+0x5c/0xa0 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x190/0x1a0 __sk_destruct+0x25/0x220 sk_psock_destroy+0x2b2/0x310 process_scheduled_works+0xa3/0x3e0 worker_thread+0x117/0x240 ? __pfx_worker_thread+0x10/0x10 kthread+0xcf/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> ---[ end trace 0000000000000000 ]--- In __SK_REDIRECT, a more concise way is delaying the uncharging after sent bytes are finalized, and uncharge this value. When (ret < 0), we shall invoke sk_msg_free. Same thing happens in case __SK_DROP, when tosend is set to apply_bytes, we may miss uncharging (msg->sg.size - apply_bytes) bytes. The same warning will be reported in selftest. [...] 468 case __SK_DROP: 469 default: 470 sk_msg_free_partial(sk, msg, tosend); 471 sk_msg_apply_bytes(psock, tosend); 472 *copied -= (tosend + delta); 473 return -EACCES; [...] So instead of sk_msg_free_partial we can do sk_msg_free here. CVE-2024-56633 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: Hold module reference while requesting a module User space may unload ip_set.ko while it is itself requesting a set type backend module, leading to a kernel crash. The race condition may be provoked by inserting an mdelay() right after the nfnl_unlock() call. CVE-2024-56637 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: net/smc: initialize close_work early to avoid warning We encountered a warning that close_work was canceled before initialization. WARNING: CPU: 7 PID: 111103 at kernel/workqueue.c:3047 __flush_work+0x19e/0x1b0 Workqueue: events smc_lgr_terminate_work [smc] RIP: 0010:__flush_work+0x19e/0x1b0 Call Trace: ? __wake_up_common+0x7a/0x190 ? work_busy+0x80/0x80 __cancel_work_timer+0xe3/0x160 smc_close_cancel_work+0x1a/0x70 [smc] smc_close_active_abort+0x207/0x360 [smc] __smc_lgr_terminate.part.38+0xc8/0x180 [smc] process_one_work+0x19e/0x340 worker_thread+0x30/0x370 ? process_one_work+0x340/0x340 kthread+0x117/0x130 ? __kthread_cancel_work+0x50/0x50 ret_from_fork+0x22/0x30 This is because when smc_close_cancel_work is triggered, e.g. the RDMA driver is rmmod and the LGR is terminated, the conn->close_work is flushed before initialization, resulting in WARN_ON(!work->func). __smc_lgr_terminate | smc_connect_{rdma|ism} ------------------------------------------------------------- | smc_conn_create | \- smc_lgr_register_conn for conn in lgr->conns_all | \- smc_conn_kill | \- smc_close_active_abort | \- smc_close_cancel_work | \- cancel_work_sync | \- __flush_work | (close_work) | | smc_close_init | \- INIT_WORK(&close_work) So fix this by initializing close_work before establishing the connection. CVE-2024-56641 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: tipc: Fix use-after-free of kernel socket in cleanup_bearer(). syzkaller reported a use-after-free of UDP kernel socket in cleanup_bearer() without repro. [0][1] When bearer_disable() calls tipc_udp_disable(), cleanup of the UDP kernel socket is deferred by work calling cleanup_bearer(). tipc_exit_net() waits for such works to finish by checking tipc_net(net)->wq_count. However, the work decrements the count too early before releasing the kernel socket, unblocking cleanup_net() and resulting in use-after-free. Let's move the decrement after releasing the socket in cleanup_bearer(). [0]: ref_tracker: net notrefcnt@000000009b3d1faf has 1/1 users at sk_alloc+0x438/0x608 inet_create+0x4c8/0xcb0 __sock_create+0x350/0x6b8 sock_create_kern+0x58/0x78 udp_sock_create4+0x68/0x398 udp_sock_create+0x88/0xc8 tipc_udp_enable+0x5e8/0x848 __tipc_nl_bearer_enable+0x84c/0xed8 tipc_nl_bearer_enable+0x38/0x60 genl_family_rcv_msg_doit+0x170/0x248 genl_rcv_msg+0x400/0x5b0 netlink_rcv_skb+0x1dc/0x398 genl_rcv+0x44/0x68 netlink_unicast+0x678/0x8b0 netlink_sendmsg+0x5e4/0x898 ____sys_sendmsg+0x500/0x830 [1]: BUG: KMSAN: use-after-free in udp_hashslot include/net/udp.h:85 [inline] BUG: KMSAN: use-after-free in udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 udp_hashslot include/net/udp.h:85 [inline] udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 sk_common_release+0xaf/0x3f0 net/core/sock.c:3820 inet_release+0x1e0/0x260 net/ipv4/af_inet.c:437 inet6_release+0x6f/0xd0 net/ipv6/af_inet6.c:489 __sock_release net/socket.c:658 [inline] sock_release+0xa0/0x210 net/socket.c:686 cleanup_bearer+0x42d/0x4c0 net/tipc/udp_media.c:819 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244 Uninit was created at: slab_free_hook mm/slub.c:2269 [inline] slab_free mm/slub.c:4580 [inline] kmem_cache_free+0x207/0xc40 mm/slub.c:4682 net_free net/core/net_namespace.c:454 [inline] cleanup_net+0x16f2/0x19d0 net/core/net_namespace.c:647 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244 CPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfa Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: events cleanup_bearer CVE-2024-56642 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 important In the Linux kernel, the following vulnerability has been resolved: dccp: Fix memory leak in dccp_feat_change_recv If dccp_feat_push_confirm() fails after new value for SP feature was accepted without reconciliation ('entry == NULL' branch), memory allocated for that value with dccp_feat_clone_sp_val() is never freed. Here is the kmemleak stack for this: unreferenced object 0xffff88801d4ab488 (size 8): comm "syz-executor310", pid 1127, jiffies 4295085598 (age 41.666s) hex dump (first 8 bytes): 01 b4 4a 1d 80 88 ff ff ..J..... backtrace: [<00000000db7cabfe>] kmemdup+0x23/0x50 mm/util.c:128 [<0000000019b38405>] kmemdup include/linux/string.h:465 [inline] [<0000000019b38405>] dccp_feat_clone_sp_val net/dccp/feat.c:371 [inline] [<0000000019b38405>] dccp_feat_clone_sp_val net/dccp/feat.c:367 [inline] [<0000000019b38405>] dccp_feat_change_recv net/dccp/feat.c:1145 [inline] [<0000000019b38405>] dccp_feat_parse_options+0x1196/0x2180 net/dccp/feat.c:1416 [<00000000b1f6d94a>] dccp_parse_options+0xa2a/0x1260 net/dccp/options.c:125 [<0000000030d7b621>] dccp_rcv_state_process+0x197/0x13d0 net/dccp/input.c:650 [<000000001f74c72e>] dccp_v4_do_rcv+0xf9/0x1a0 net/dccp/ipv4.c:688 [<00000000a6c24128>] sk_backlog_rcv include/net/sock.h:1041 [inline] [<00000000a6c24128>] __release_sock+0x139/0x3b0 net/core/sock.c:2570 [<00000000cf1f3a53>] release_sock+0x54/0x1b0 net/core/sock.c:3111 [<000000008422fa23>] inet_wait_for_connect net/ipv4/af_inet.c:603 [inline] [<000000008422fa23>] __inet_stream_connect+0x5d0/0xf70 net/ipv4/af_inet.c:696 [<0000000015b6f64d>] inet_stream_connect+0x53/0xa0 net/ipv4/af_inet.c:735 [<0000000010122488>] __sys_connect_file+0x15c/0x1a0 net/socket.c:1865 [<00000000b4b70023>] __sys_connect+0x165/0x1a0 net/socket.c:1882 [<00000000f4cb3815>] __do_sys_connect net/socket.c:1892 [inline] [<00000000f4cb3815>] __se_sys_connect net/socket.c:1889 [inline] [<00000000f4cb3815>] __x64_sys_connect+0x6e/0xb0 net/socket.c:1889 [<00000000e7b1e839>] do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 [<0000000055e91434>] entry_SYSCALL_64_after_hwframe+0x67/0xd1 Clean up the allocated memory in case of dccp_feat_push_confirm() failure and bail out with an error reset code. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. CVE-2024-56643 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 low In the Linux kernel, the following vulnerability has been resolved: net: Fix icmp host relookup triggering ip_rt_bug arp link failure may trigger ip_rt_bug while xfrm enabled, call trace is: WARNING: CPU: 0 PID: 0 at net/ipv4/route.c:1241 ip_rt_bug+0x14/0x20 Modules linked in: CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc6-00077-g2e1b3cc9d7f7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:ip_rt_bug+0x14/0x20 Call Trace: <IRQ> ip_send_skb+0x14/0x40 __icmp_send+0x42d/0x6a0 ipv4_link_failure+0xe2/0x1d0 arp_error_report+0x3c/0x50 neigh_invalidate+0x8d/0x100 neigh_timer_handler+0x2e1/0x330 call_timer_fn+0x21/0x120 __run_timer_base.part.0+0x1c9/0x270 run_timer_softirq+0x4c/0x80 handle_softirqs+0xac/0x280 irq_exit_rcu+0x62/0x80 sysvec_apic_timer_interrupt+0x77/0x90 The script below reproduces this scenario: ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 \ dir out priority 0 ptype main flag localok icmp ip l a veth1 type veth ip a a 192.168.141.111/24 dev veth0 ip l s veth0 up ping 192.168.141.155 -c 1 icmp_route_lookup() create input routes for locally generated packets while xfrm relookup ICMP traffic.Then it will set input route (dst->out = ip_rt_bug) to skb for DESTUNREACH. For ICMP err triggered by locally generated packets, dst->dev of output route is loopback. Generally, xfrm relookup verification is not required on loopback interfaces (net.ipv4.conf.lo.disable_xfrm = 1). Skip icmp relookup for locally generated packets to fix it. CVE-2024-56647 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: fix LED ID check in led_tg_check() Syzbot has reported the following BUG detected by KASAN: BUG: KASAN: slab-out-of-bounds in strlen+0x58/0x70 Read of size 1 at addr ffff8881022da0c8 by task repro/5879 ... Call Trace: <TASK> dump_stack_lvl+0x241/0x360 ? __pfx_dump_stack_lvl+0x10/0x10 ? __pfx__printk+0x10/0x10 ? _printk+0xd5/0x120 ? __virt_addr_valid+0x183/0x530 ? __virt_addr_valid+0x183/0x530 print_report+0x169/0x550 ? __virt_addr_valid+0x183/0x530 ? __virt_addr_valid+0x183/0x530 ? __virt_addr_valid+0x45f/0x530 ? __phys_addr+0xba/0x170 ? strlen+0x58/0x70 kasan_report+0x143/0x180 ? strlen+0x58/0x70 strlen+0x58/0x70 kstrdup+0x20/0x80 led_tg_check+0x18b/0x3c0 xt_check_target+0x3bb/0xa40 ? __pfx_xt_check_target+0x10/0x10 ? stack_depot_save_flags+0x6e4/0x830 ? nft_target_init+0x174/0xc30 nft_target_init+0x82d/0xc30 ? __pfx_nft_target_init+0x10/0x10 ? nf_tables_newrule+0x1609/0x2980 ? nf_tables_newrule+0x1609/0x2980 ? rcu_is_watching+0x15/0xb0 ? nf_tables_newrule+0x1609/0x2980 ? nf_tables_newrule+0x1609/0x2980 ? __kmalloc_noprof+0x21a/0x400 nf_tables_newrule+0x1860/0x2980 ? __pfx_nf_tables_newrule+0x10/0x10 ? __nla_parse+0x40/0x60 nfnetlink_rcv+0x14e5/0x2ab0 ? __pfx_validate_chain+0x10/0x10 ? __pfx_nfnetlink_rcv+0x10/0x10 ? __lock_acquire+0x1384/0x2050 ? netlink_deliver_tap+0x2e/0x1b0 ? __pfx_lock_release+0x10/0x10 ? netlink_deliver_tap+0x2e/0x1b0 netlink_unicast+0x7f8/0x990 ? __pfx_netlink_unicast+0x10/0x10 ? __virt_addr_valid+0x183/0x530 ? __check_object_size+0x48e/0x900 netlink_sendmsg+0x8e4/0xcb0 ? __pfx_netlink_sendmsg+0x10/0x10 ? aa_sock_msg_perm+0x91/0x160 ? __pfx_netlink_sendmsg+0x10/0x10 __sock_sendmsg+0x223/0x270 ____sys_sendmsg+0x52a/0x7e0 ? __pfx_____sys_sendmsg+0x10/0x10 __sys_sendmsg+0x292/0x380 ? __pfx___sys_sendmsg+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? exc_page_fault+0x590/0x8c0 ? do_syscall_64+0xb6/0x230 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... </TASK> Since an invalid (without '\0' byte at all) byte sequence may be passed from userspace, add an extra check to ensure that such a sequence is rejected as possible ID and so never passed to 'kstrdup()' and further. CVE-2024-56650 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 important In the Linux kernel, the following vulnerability has been resolved: net: defer final 'struct net' free in netns dismantle Ilya reported a slab-use-after-free in dst_destroy [1] Issue is in xfrm6_net_init() and xfrm4_net_init() : They copy xfrm[46]_dst_ops_template into net->xfrm.xfrm[46]_dst_ops. But net structure might be freed before all the dst callbacks are called. So when dst_destroy() calls later : if (dst->ops->destroy) dst->ops->destroy(dst); dst->ops points to the old net->xfrm.xfrm[46]_dst_ops, which has been freed. See a relevant issue fixed in : ac888d58869b ("net: do not delay dst_entries_add() in dst_release()") A fix is to queue the 'struct net' to be freed after one another cleanup_net() round (and existing rcu_barrier()) [1] BUG: KASAN: slab-use-after-free in dst_destroy (net/core/dst.c:112) Read of size 8 at addr ffff8882137ccab0 by task swapper/37/0 Dec 03 05:46:18 kernel: CPU: 37 UID: 0 PID: 0 Comm: swapper/37 Kdump: loaded Not tainted 6.12.0 #67 Hardware name: Red Hat KVM/RHEL, BIOS 1.16.1-1.el9 04/01/2014 Call Trace: <IRQ> dump_stack_lvl (lib/dump_stack.c:124) print_address_description.constprop.0 (mm/kasan/report.c:378) ? dst_destroy (net/core/dst.c:112) print_report (mm/kasan/report.c:489) ? dst_destroy (net/core/dst.c:112) ? kasan_addr_to_slab (mm/kasan/common.c:37) kasan_report (mm/kasan/report.c:603) ? dst_destroy (net/core/dst.c:112) ? rcu_do_batch (kernel/rcu/tree.c:2567) dst_destroy (net/core/dst.c:112) rcu_do_batch (kernel/rcu/tree.c:2567) ? __pfx_rcu_do_batch (kernel/rcu/tree.c:2491) ? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4339 kernel/locking/lockdep.c:4406) rcu_core (kernel/rcu/tree.c:2825) handle_softirqs (kernel/softirq.c:554) __irq_exit_rcu (kernel/softirq.c:589 kernel/softirq.c:428 kernel/softirq.c:637) irq_exit_rcu (kernel/softirq.c:651) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1049 arch/x86/kernel/apic/apic.c:1049) </IRQ> <TASK> asm_sysvec_apic_timer_interrupt (./arch/x86/include/asm/idtentry.h:702) RIP: 0010:default_idle (./arch/x86/include/asm/irqflags.h:37 ./arch/x86/include/asm/irqflags.h:92 arch/x86/kernel/process.c:743) Code: 00 4d 29 c8 4c 01 c7 4c 29 c2 e9 6e ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 0f 00 2d c7 c9 27 00 fb f4 <fa> c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 RSP: 0018:ffff888100d2fe00 EFLAGS: 00000246 RAX: 00000000001870ed RBX: 1ffff110201a5fc2 RCX: ffffffffb61a3e46 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffb3d4d123 RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed11c7e1835d R10: ffff888e3f0c1aeb R11: 0000000000000000 R12: 0000000000000000 R13: ffff888100d20000 R14: dffffc0000000000 R15: 0000000000000000 ? ct_kernel_exit.constprop.0 (kernel/context_tracking.c:148) ? cpuidle_idle_call (kernel/sched/idle.c:186) default_idle_call (./include/linux/cpuidle.h:143 kernel/sched/idle.c:118) cpuidle_idle_call (kernel/sched/idle.c:186) ? __pfx_cpuidle_idle_call (kernel/sched/idle.c:168) ? lock_release (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5848) ? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4347 kernel/locking/lockdep.c:4406) ? tsc_verify_tsc_adjust (arch/x86/kernel/tsc_sync.c:59) do_idle (kernel/sched/idle.c:326) cpu_startup_entry (kernel/sched/idle.c:423 (discriminator 1)) start_secondary (arch/x86/kernel/smpboot.c:202 arch/x86/kernel/smpboot.c:282) ? __pfx_start_secondary (arch/x86/kernel/smpboot.c:232) ? soft_restart_cpu (arch/x86/kernel/head_64.S:452) common_startup_64 (arch/x86/kernel/head_64.S:414) </TASK> Dec 03 05:46:18 kernel: Allocated by task 12184: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (./arch/x86/include/asm/current.h:49 mm/kasan/common.c:60 mm/kasan/common.c:69) __kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345) kmem_cache_alloc_noprof (mm/slub.c:4085 mm/slub.c:4134 mm/slub.c:4141) copy_net_ns (net/core/net_namespace.c:421 net/core/net_namespace.c:480) create_new_namespaces ---truncated--- CVE-2024-56658 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 important In the Linux kernel, the following vulnerability has been resolved: tipc: fix NULL deref in cleanup_bearer() syzbot found [1] that after blamed commit, ub->ubsock->sk was NULL when attempting the atomic_dec() : atomic_dec(&tipc_net(sock_net(ub->ubsock->sk))->wq_count); Fix this by caching the tipc_net pointer. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] CPU: 0 UID: 0 PID: 5896 Comm: kworker/0:3 Not tainted 6.13.0-rc1-next-20241203-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: events cleanup_bearer RIP: 0010:read_pnet include/net/net_namespace.h:387 [inline] RIP: 0010:sock_net include/net/sock.h:655 [inline] RIP: 0010:cleanup_bearer+0x1f7/0x280 net/tipc/udp_media.c:820 Code: 18 48 89 d8 48 c1 e8 03 42 80 3c 28 00 74 08 48 89 df e8 3c f7 99 f6 48 8b 1b 48 83 c3 30 e8 f0 e4 60 00 48 89 d8 48 c1 e8 03 <42> 80 3c 28 00 74 08 48 89 df e8 1a f7 99 f6 49 83 c7 e8 48 8b 1b RSP: 0018:ffffc9000410fb70 EFLAGS: 00010206 RAX: 0000000000000006 RBX: 0000000000000030 RCX: ffff88802fe45a00 RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffc9000410f900 RBP: ffff88807e1f0908 R08: ffffc9000410f907 R09: 1ffff92000821f20 R10: dffffc0000000000 R11: fffff52000821f21 R12: ffff888031d19980 R13: dffffc0000000000 R14: dffffc0000000000 R15: ffff88807e1f0918 FS: 0000000000000000(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556ca050b000 CR3: 0000000031c0c000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 CVE-2024-56661 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: acpi: nfit: vmalloc-out-of-bounds Read in acpi_nfit_ctl Fix an issue detected by syzbot with KASAN: BUG: KASAN: vmalloc-out-of-bounds in cmd_to_func drivers/acpi/nfit/ core.c:416 [inline] BUG: KASAN: vmalloc-out-of-bounds in acpi_nfit_ctl+0x20e8/0x24a0 drivers/acpi/nfit/core.c:459 The issue occurs in cmd_to_func when the call_pkg->nd_reserved2 array is accessed without verifying that call_pkg points to a buffer that is appropriately sized as a struct nd_cmd_pkg. This can lead to out-of-bounds access and undefined behavior if the buffer does not have sufficient space. To address this, a check was added in acpi_nfit_ctl() to ensure that buf is not NULL and that buf_len is less than sizeof(*call_pkg) before accessing it. This ensures safe access to the members of call_pkg, including the nd_reserved2 array. CVE-2024-56662 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix race between element replace and close() Element replace (with a socket different from the one stored) may race with socket's close() link popping & unlinking. __sock_map_delete() unconditionally unrefs the (wrong) element: // set map[0] = s0 map_update_elem(map, 0, s0) // drop fd of s0 close(s0) sock_map_close() lock_sock(sk) (s0!) sock_map_remove_links(sk) link = sk_psock_link_pop() sock_map_unlink(sk, link) sock_map_delete_from_link // replace map[0] with s1 map_update_elem(map, 0, s1) sock_map_update_elem (s1!) lock_sock(sk) sock_map_update_common psock = sk_psock(sk) spin_lock(&stab->lock) osk = stab->sks[idx] sock_map_add_link(..., &stab->sks[idx]) sock_map_unref(osk, &stab->sks[idx]) psock = sk_psock(osk) sk_psock_put(sk, psock) if (refcount_dec_and_test(&psock)) sk_psock_drop(sk, psock) spin_unlock(&stab->lock) unlock_sock(sk) __sock_map_delete spin_lock(&stab->lock) sk = *psk // s1 replaced s0; sk == s1 if (!sk_test || sk_test == sk) // sk_test (s0) != sk (s1); no branch sk = xchg(psk, NULL) if (sk) sock_map_unref(sk, psk) // unref s1; sks[idx] will dangle psock = sk_psock(sk) sk_psock_put(sk, psock) if (refcount_dec_and_test()) sk_psock_drop(sk, psock) spin_unlock(&stab->lock) release_sock(sk) Then close(map) enqueues bpf_map_free_deferred, which finally calls sock_map_free(). This results in some refcount_t warnings along with a KASAN splat [1]. Fix __sock_map_delete(), do not allow sock_map_unref() on elements that may have been replaced. [1]: BUG: KASAN: slab-use-after-free in sock_map_free+0x10e/0x330 Write of size 4 at addr ffff88811f5b9100 by task kworker/u64:12/1063 CPU: 14 UID: 0 PID: 1063 Comm: kworker/u64:12 Not tainted 6.12.0+ #125 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 Workqueue: events_unbound bpf_map_free_deferred Call Trace: <TASK> dump_stack_lvl+0x68/0x90 print_report+0x174/0x4f6 kasan_report+0xb9/0x190 kasan_check_range+0x10f/0x1e0 sock_map_free+0x10e/0x330 bpf_map_free_deferred+0x173/0x320 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x29e/0x360 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30 </TASK> Allocated by task 1202: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 __kasan_slab_alloc+0x85/0x90 kmem_cache_alloc_noprof+0x131/0x450 sk_prot_alloc+0x5b/0x220 sk_alloc+0x2c/0x870 unix_create1+0x88/0x8a0 unix_create+0xc5/0x180 __sock_create+0x241/0x650 __sys_socketpair+0x1ce/0x420 __x64_sys_socketpair+0x92/0x100 do_syscall_64+0x93/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 46: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kmem_cache_free+0x1a1/0x590 __sk_destruct+0x388/0x5a0 sk_psock_destroy+0x73e/0xa50 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x29e/0x360 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30 The bu ---truncated--- CVE-2024-56664 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 important In the Linux kernel, the following vulnerability has been resolved: crypto: bcm - add error check in the ahash_hmac_init function The ahash_init functions may return fails. The ahash_hmac_init should not return ok when ahash_init returns error. For an example, ahash_init will return -ENOMEM when allocation memory is error. CVE-2024-56681 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport Since transport->sock has been set to NULL during reset transport, XPRT_SOCK_UPD_TIMEOUT also needs to be cleared. Otherwise, the xs_tcp_set_socket_timeouts() may be triggered in xs_tcp_send_request() to dereference the transport->sock that has been set to NULL. CVE-2024-56688 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: wl128x: Fix atomicity violation in fmc_send_cmd() Atomicity violation occurs when the fmc_send_cmd() function is executed simultaneously with the modification of the fmdev->resp_skb value. Consider a scenario where, after passing the validity check within the function, a non-null fmdev->resp_skb variable is assigned a null value. This results in an invalid fmdev->resp_skb variable passing the validity check. As seen in the later part of the function, skb = fmdev->resp_skb; when the invalid fmdev->resp_skb passes the check, a null pointer dereference error may occur at line 478, evt_hdr = (void *)skb->data; To address this issue, it is recommended to include the validity check of fmdev->resp_skb within the locked section of the function. This modification ensures that the value of fmdev->resp_skb does not change during the validation process, thereby maintaining its validity. This possible bug is found by an experimental static analysis tool developed by our team. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. CVE-2024-56700 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: 9p/xen: fix release of IRQ Kernel logs indicate an IRQ was double-freed. Pass correct device ID during IRQ release. [Dominique: remove confusing variable reset to 0] CVE-2024-56704 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix cpu stuck caused by printings during reset During reset, cmd to destroy resources such as qp, cq, and mr may fail, and error logs will be printed. When a large number of resources are destroyed, there will be lots of printings, and it may lead to a cpu stuck. Delete some unnecessary printings and replace other printing functions in these paths with the ratelimited version. CVE-2024-56722 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: mfd: intel_soc_pmic_bxtwc: Use IRQ domain for TMU device While design wise the idea of converting the driver to use the hierarchy of the IRQ chips is correct, the implementation has (inherited) flaws. This was unveiled when platform_get_irq() had started WARN() on IRQ 0 that is supposed to be a Linux IRQ number (also known as vIRQ). Rework the driver to respect IRQ domain when creating each MFD device separately, as the domain is not the same for all of them. CVE-2024-56724 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate GNU GRUB (aka GRUB2) through 2.12 has a heap-based buffer overflow in fs/hfs.c via crafted sblock data in an HFS filesystem. CVE-2024-56737 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-i386-pc-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-x86_64-efi-2.02-184.2 important In the Linux kernel, the following vulnerability has been resolved: rtc: check if __rtc_read_time was successful in rtc_timer_do_work() If the __rtc_read_time call fails,, the struct rtc_time tm; may contain uninitialized data, or an illegal date/time read from the RTC hardware. When calling rtc_tm_to_ktime later, the result may be a very large value (possibly KTIME_MAX). If there are periodic timers in rtc->timerqueue, they will continually expire, may causing kernel softlockup. CVE-2024-56739 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: qedi: Fix a possible memory leak in qedi_alloc_and_init_sb() Hook "qedi_ops->common->sb_init = qed_sb_init" does not release the DMA memory sb_virt when it fails. Add dma_free_coherent() to free it. This is the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb(). CVE-2024-56747 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 low In the Linux kernel, the following vulnerability has been resolved: scsi: qedf: Fix a possible memory leak in qedf_alloc_and_init_sb() Hook "qed_ops->common->sb_init = qed_sb_init" does not release the DMA memory sb_virt when it fails. Add dma_free_coherent() to free it. This is the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb(). CVE-2024-56748 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: nvme-pci: fix freeing of the HMB descriptor table The HMB descriptor table is sized to the maximum number of descriptors that could be used for a given device, but __nvme_alloc_host_mem could break out of the loop earlier on memory allocation failure and end up using less descriptors than planned for, which leads to an incorrect size passed to dma_free_coherent. In practice this was not showing up because the number of descriptors tends to be low and the dma coherent allocator always allocates and frees at least a page. CVE-2024-56756 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free when COWing tree bock and tracing is enabled When a COWing a tree block, at btrfs_cow_block(), and we have the tracepoint trace_btrfs_cow_block() enabled and preemption is also enabled (CONFIG_PREEMPT=y), we can trigger a use-after-free in the COWed extent buffer while inside the tracepoint code. This is because in some paths that call btrfs_cow_block(), such as btrfs_search_slot(), we are holding the last reference on the extent buffer @buf so btrfs_force_cow_block() drops the last reference on the @buf extent buffer when it calls free_extent_buffer_stale(buf), which schedules the release of the extent buffer with RCU. This means that if we are on a kernel with preemption, the current task may be preempted before calling trace_btrfs_cow_block() and the extent buffer already released by the time trace_btrfs_cow_block() is called, resulting in a use-after-free. Fix this by moving the trace_btrfs_cow_block() from btrfs_cow_block() to btrfs_force_cow_block() before the COWed extent buffer is freed. This also has a side effect of invoking the tracepoint in the tree defrag code, at defrag.c:btrfs_realloc_node(), since btrfs_force_cow_block() is called there, but this is fine and it was actually missing there. CVE-2024-56759 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 important In the Linux kernel, the following vulnerability has been resolved: tracing: Prevent bad count for tracing_cpumask_write If a large count is provided, it will trigger a warning in bitmap_parse_user. Also check zero for it. CVE-2024-56763 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: dvb-frontends: dib3000mb: fix uninit-value in dib3000_write_reg Syzbot reports [1] an uninitialized value issue found by KMSAN in dib3000_read_reg(). Local u8 rb[2] is used in i2c_transfer() as a read buffer; in case that call fails, the buffer may end up with some undefined values. Since no elaborate error handling is expected in dib3000_write_reg(), simply zero out rb buffer to mitigate the problem. [1] Syzkaller report dvb-usb: bulk message failed: -22 (6/0) ===================================================== BUG: KMSAN: uninit-value in dib3000mb_attach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758 dib3000mb_attach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758 dibusb_dib3000mb_frontend_attach+0x155/0x2f0 drivers/media/usb/dvb-usb/dibusb-mb.c:31 dvb_usb_adapter_frontend_init+0xed/0x9a0 drivers/media/usb/dvb-usb/dvb-usb-dvb.c:290 dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:90 [inline] dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:186 [inline] dvb_usb_device_init+0x25a8/0x3760 drivers/media/usb/dvb-usb/dvb-usb-init.c:310 dibusb_probe+0x46/0x250 drivers/media/usb/dvb-usb/dibusb-mb.c:110 ... Local variable rb created at: dib3000_read_reg+0x86/0x4e0 drivers/media/dvb-frontends/dib3000mb.c:54 dib3000mb_attach+0x123/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758 ... CVE-2024-56769 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: net/smc: check return value of sock_recvmsg when draining clc data When receiving clc msg, the field length in smc_clc_msg_hdr indicates the length of msg should be received from network and the value should not be fully trusted as it is from the network. Once the value of length exceeds the value of buflen in function smc_clc_wait_msg it may run into deadloop when trying to drain the remaining data exceeding buflen. This patch checks the return value of sock_recvmsg when draining data in case of deadloop in draining. CVE-2024-57791 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 important In the Linux kernel, the following vulnerability has been resolved: s390/cpum_sf: Handle CPU hotplug remove during sampling CPU hotplug remove handling triggers the following function call sequence: CPUHP_AP_PERF_S390_SF_ONLINE --> s390_pmu_sf_offline_cpu() ... CPUHP_AP_PERF_ONLINE --> perf_event_exit_cpu() The s390 CPUMF sampling CPU hotplug handler invokes: s390_pmu_sf_offline_cpu() +--> cpusf_pmu_setup() +--> setup_pmc_cpu() +--> deallocate_buffers() This function de-allocates all sampling data buffers (SDBs) allocated for that CPU at event initialization. It also clears the PMU_F_RESERVED bit. The CPU is gone and can not be sampled. With the event still being active on the removed CPU, the CPU event hotplug support in kernel performance subsystem triggers the following function calls on the removed CPU: perf_event_exit_cpu() +--> perf_event_exit_cpu_context() +--> __perf_event_exit_context() +--> __perf_remove_from_context() +--> event_sched_out() +--> cpumsf_pmu_del() +--> cpumsf_pmu_stop() +--> hw_perf_event_update() to stop and remove the event. During removal of the event, the sampling device driver tries to read out the remaining samples from the sample data buffers (SDBs). But they have already been freed (and may have been re-assigned). This may lead to a use after free situation in which case the samples are most likely invalid. In the best case the memory has not been reassigned and still contains valid data. Remedy this situation and check if the CPU is still in reserved state (bit PMU_F_RESERVED set). In this case the SDBs have not been released an contain valid data. This is always the case when the event is removed (and no CPU hotplug off occured). If the PMU_F_RESERVED bit is not set, the SDB buffers are gone. CVE-2024-57849 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 important In the Linux kernel, the following vulnerability has been resolved: mm: vmscan: account for free pages to prevent infinite Loop in throttle_direct_reclaim() The task sometimes continues looping in throttle_direct_reclaim() because allow_direct_reclaim(pgdat) keeps returning false. #0 [ffff80002cb6f8d0] __switch_to at ffff8000080095ac #1 [ffff80002cb6f900] __schedule at ffff800008abbd1c #2 [ffff80002cb6f990] schedule at ffff800008abc50c #3 [ffff80002cb6f9b0] throttle_direct_reclaim at ffff800008273550 #4 [ffff80002cb6fa20] try_to_free_pages at ffff800008277b68 #5 [ffff80002cb6fae0] __alloc_pages_nodemask at ffff8000082c4660 #6 [ffff80002cb6fc50] alloc_pages_vma at ffff8000082e4a98 #7 [ffff80002cb6fca0] do_anonymous_page at ffff80000829f5a8 #8 [ffff80002cb6fce0] __handle_mm_fault at ffff8000082a5974 #9 [ffff80002cb6fd90] handle_mm_fault at ffff8000082a5bd4 At this point, the pgdat contains the following two zones: NODE: 4 ZONE: 0 ADDR: ffff00817fffe540 NAME: "DMA32" SIZE: 20480 MIN/LOW/HIGH: 11/28/45 VM_STAT: NR_FREE_PAGES: 359 NR_ZONE_INACTIVE_ANON: 18813 NR_ZONE_ACTIVE_ANON: 0 NR_ZONE_INACTIVE_FILE: 50 NR_ZONE_ACTIVE_FILE: 0 NR_ZONE_UNEVICTABLE: 0 NR_ZONE_WRITE_PENDING: 0 NR_MLOCK: 0 NR_BOUNCE: 0 NR_ZSPAGES: 0 NR_FREE_CMA_PAGES: 0 NODE: 4 ZONE: 1 ADDR: ffff00817fffec00 NAME: "Normal" SIZE: 8454144 PRESENT: 98304 MIN/LOW/HIGH: 68/166/264 VM_STAT: NR_FREE_PAGES: 146 NR_ZONE_INACTIVE_ANON: 94668 NR_ZONE_ACTIVE_ANON: 3 NR_ZONE_INACTIVE_FILE: 735 NR_ZONE_ACTIVE_FILE: 78 NR_ZONE_UNEVICTABLE: 0 NR_ZONE_WRITE_PENDING: 0 NR_MLOCK: 0 NR_BOUNCE: 0 NR_ZSPAGES: 0 NR_FREE_CMA_PAGES: 0 In allow_direct_reclaim(), while processing ZONE_DMA32, the sum of inactive/active file-backed pages calculated in zone_reclaimable_pages() based on the result of zone_page_state_snapshot() is zero. Additionally, since this system lacks swap, the calculation of inactive/ active anonymous pages is skipped. crash> p nr_swap_pages nr_swap_pages = $1937 = { counter = 0 } As a result, ZONE_DMA32 is deemed unreclaimable and skipped, moving on to the processing of the next zone, ZONE_NORMAL, despite ZONE_DMA32 having free pages significantly exceeding the high watermark. The problem is that the pgdat->kswapd_failures hasn't been incremented. crash> px ((struct pglist_data *) 0xffff00817fffe540)->kswapd_failures $1935 = 0x0 This is because the node deemed balanced. The node balancing logic in balance_pgdat() evaluates all zones collectively. If one or more zones (e.g., ZONE_DMA32) have enough free pages to meet their watermarks, the entire node is deemed balanced. This causes balance_pgdat() to exit early before incrementing the kswapd_failures, as it considers the overall memory state acceptable, even though some zones (like ZONE_NORMAL) remain under significant pressure. The patch ensures that zone_reclaimable_pages() includes free pages (NR_FREE_PAGES) in its calculation when no other reclaimable pages are available (e.g., file-backed or anonymous pages). This change prevents zones like ZONE_DMA32, which have sufficient free pages, from being mistakenly deemed unreclaimable. By doing so, the patch ensures proper node balancing, avoids masking pressure on other zones like ZONE_NORMAL, and prevents infinite loops in throttle_direct_reclaim() caused by allow_direct_reclaim(pgdat) repeatedly returning false. The kernel hangs due to a task stuck in throttle_direct_reclaim(), caused by a node being incorrectly deemed balanced despite pressure in certain zones, such as ZONE_NORMAL. This issue arises from zone_reclaimable_pages ---truncated--- CVE-2024-57884 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm: adv7511: Fix use-after-free in adv7533_attach_dsi() The host_node pointer was assigned and freed in adv7533_parse_dt(), and later, adv7533_attach_dsi() uses the same. Fix this use-after-free issue by dropping of_node_put() in adv7533_parse_dt() and calling of_node_put() in error path of probe() and also in the remove(). CVE-2024-57887 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: workqueue: Do not warn when cancelling WQ_MEM_RECLAIM work from !WQ_MEM_RECLAIM worker After commit 746ae46c1113 ("drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM") amdgpu started seeing the following warning: [ ] workqueue: WQ_MEM_RECLAIM sdma0:drm_sched_run_job_work [gpu_sched] is flushing !WQ_MEM_RECLAIM events:amdgpu_device_delay_enable_gfx_off [amdgpu] ... [ ] Workqueue: sdma0 drm_sched_run_job_work [gpu_sched] ... [ ] Call Trace: [ ] <TASK> ... [ ] ? check_flush_dependency+0xf5/0x110 ... [ ] cancel_delayed_work_sync+0x6e/0x80 [ ] amdgpu_gfx_off_ctrl+0xab/0x140 [amdgpu] [ ] amdgpu_ring_alloc+0x40/0x50 [amdgpu] [ ] amdgpu_ib_schedule+0xf4/0x810 [amdgpu] [ ] ? drm_sched_run_job_work+0x22c/0x430 [gpu_sched] [ ] amdgpu_job_run+0xaa/0x1f0 [amdgpu] [ ] drm_sched_run_job_work+0x257/0x430 [gpu_sched] [ ] process_one_work+0x217/0x720 ... [ ] </TASK> The intent of the verifcation done in check_flush_depedency is to ensure forward progress during memory reclaim, by flagging cases when either a memory reclaim process, or a memory reclaim work item is flushed from a context not marked as memory reclaim safe. This is correct when flushing, but when called from the cancel(_delayed)_work_sync() paths it is a false positive because work is either already running, or will not be running at all. Therefore cancelling it is safe and we can relax the warning criteria by letting the helper know of the calling context. References: 746ae46c1113 ("drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM") CVE-2024-57888 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: RDMA/uverbs: Prevent integer overflow issue In the expression "cmd.wqe_size * cmd.wr_count", both variables are u32 values that come from the user so the multiplication can lead to integer wrapping. Then we pass the result to uverbs_request_next_ptr() which also could potentially wrap. The "cmd.sge_count * sizeof(struct ib_uverbs_sge)" multiplication can also overflow on 32bit systems although it's fine on 64bit systems. This patch does two things. First, I've re-arranged the condition in uverbs_request_next_ptr() so that the use controlled variable "len" is on one side of the comparison by itself without any math. Then I've modified all the callers to use size_mul() for the multiplications. CVE-2024-57890 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix slab-use-after-free due to dangling pointer dqi_priv When mounting ocfs2 and then remounting it as read-only, a slab-use-after-free occurs after the user uses a syscall to quota_getnextquota. Specifically, sb_dqinfo(sb, type)->dqi_priv is the dangling pointer. During the remounting process, the pointer dqi_priv is freed but is never set as null leaving it to be accessed. Additionally, the read-only option for remounting sets the DQUOT_SUSPENDED flag instead of setting the DQUOT_USAGE_ENABLED flags. Moreover, later in the process of getting the next quota, the function ocfs2_get_next_id is called and only checks the quota usage flags and not the quota suspended flags. To fix this, I set dqi_priv to null when it is freed after remounting with read-only and put a check for DQUOT_SUSPENDED in ocfs2_get_next_id. [akpm@linux-foundation.org: coding-style cleanups] CVE-2024-57892 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: oss: Fix races at processing SysEx messages OSS sequencer handles the SysEx messages split in 6 bytes packets, and ALSA sequencer OSS layer tries to combine those. It stores the data in the internal buffer and this access is racy as of now, which may lead to the out-of-bounds access. As a temporary band-aid fix, introduce a mutex for serializing the process of the SysEx message packets. CVE-2024-57893 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 important In the Linux kernel, the following vulnerability has been resolved: btrfs: flush delalloc workers queue before stopping cleaner kthread during unmount During the unmount path, at close_ctree(), we first stop the cleaner kthread, using kthread_stop() which frees the associated task_struct, and then stop and destroy all the work queues. However after we stopped the cleaner we may still have a worker from the delalloc_workers queue running inode.c:submit_compressed_extents(), which calls btrfs_add_delayed_iput(), which in turn tries to wake up the cleaner kthread - which was already destroyed before, resulting in a use-after-free on the task_struct. Syzbot reported this with the following stack traces: BUG: KASAN: slab-use-after-free in __lock_acquire+0x78/0x2100 kernel/locking/lockdep.c:5089 Read of size 8 at addr ffff8880259d2818 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.13.0-rc1-syzkaller-00002-gcdd30ebb1b9f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-delalloc btrfs_work_helper Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 __lock_acquire+0x78/0x2100 kernel/locking/lockdep.c:5089 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xc2/0x1470 kernel/sched/core.c:4205 submit_compressed_extents+0xdf/0x16e0 fs/btrfs/inode.c:1615 run_ordered_work fs/btrfs/async-thread.c:288 [inline] btrfs_work_helper+0x96f/0xc40 fs/btrfs/async-thread.c:324 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:250 [inline] slab_post_alloc_hook mm/slub.c:4104 [inline] slab_alloc_node mm/slub.c:4153 [inline] kmem_cache_alloc_node_noprof+0x1d9/0x380 mm/slub.c:4205 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1113 copy_process+0x5d1/0x3d50 kernel/fork.c:2225 kernel_clone+0x223/0x870 kernel/fork.c:2807 kernel_thread+0x1bc/0x240 kernel/fork.c:2869 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:767 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 24: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2338 [inline] slab_free mm/slub.c:4598 [inline] kmem_cache_free+0x195/0x410 mm/slub.c:4700 put_task_struct include/linux/sched/task.h:144 [inline] delayed_put_task_struct+0x125/0x300 kernel/exit.c:227 rcu_do_batch kernel/rcu/tree.c:2567 [inline] rcu_core+0xaaa/0x17a0 kernel/rcu/tree.c:2823 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:554 run_ksoftirqd+0xca/0x130 kernel/softirq.c:943 ---truncated--- CVE-2024-57896 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix mbss changed flags corruption on 32 bit systems On 32-bit systems, the size of an unsigned long is 4 bytes, while a u64 is 8 bytes. Therefore, when using or_each_set_bit(bit, &bits, sizeof(changed) * BITS_PER_BYTE), the code is incorrectly searching for a bit in a 32-bit variable that is expected to be 64 bits in size, leading to incorrect bit finding. Solution: Ensure that the size of the bits variable is correctly adjusted for each architecture. Call Trace: ? show_regs+0x54/0x58 ? __warn+0x6b/0xd4 ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211] ? report_bug+0x113/0x150 ? exc_overflow+0x30/0x30 ? handle_bug+0x27/0x44 ? exc_invalid_op+0x18/0x50 ? handle_exception+0xf6/0xf6 ? exc_overflow+0x30/0x30 ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211] ? exc_overflow+0x30/0x30 ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211] ? ieee80211_mesh_work+0xff/0x260 [mac80211] ? cfg80211_wiphy_work+0x72/0x98 [cfg80211] ? process_one_work+0xf1/0x1fc ? worker_thread+0x2c0/0x3b4 ? kthread+0xc7/0xf0 ? mod_delayed_work_on+0x4c/0x4c ? kthread_complete_and_exit+0x14/0x14 ? ret_from_fork+0x24/0x38 ? kthread_complete_and_exit+0x14/0x14 ? ret_from_fork_asm+0xf/0x14 ? entry_INT80_32+0xf0/0xf0 [restore no-op path for no changes] CVE-2024-57899 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: restrict SO_REUSEPORT to inet sockets After blamed commit, crypto sockets could accidentally be destroyed from RCU call back, as spotted by zyzbot [1]. Trying to acquire a mutex in RCU callback is not allowed. Restrict SO_REUSEPORT socket option to inet sockets. v1 of this patch supported TCP, UDP and SCTP sockets, but fcnal-test.sh test needed RAW and ICMP support. [1] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:562 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 24, name: ksoftirqd/1 preempt_count: 100, expected: 0 RCU nest depth: 0, expected: 0 1 lock held by ksoftirqd/1/24: #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:337 [inline] #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2561 [inline] #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_core+0xa37/0x17a0 kernel/rcu/tree.c:2823 Preemption disabled at: [<ffffffff8161c8c8>] softirq_handle_begin kernel/softirq.c:402 [inline] [<ffffffff8161c8c8>] handle_softirqs+0x128/0x9b0 kernel/softirq.c:537 CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.13.0-rc3-syzkaller-00174-ga024e377efed #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 __might_resched+0x5d4/0x780 kernel/sched/core.c:8758 __mutex_lock_common kernel/locking/mutex.c:562 [inline] __mutex_lock+0x131/0xee0 kernel/locking/mutex.c:735 crypto_put_default_null_skcipher+0x18/0x70 crypto/crypto_null.c:179 aead_release+0x3d/0x50 crypto/algif_aead.c:489 alg_do_release crypto/af_alg.c:118 [inline] alg_sock_destruct+0x86/0xc0 crypto/af_alg.c:502 __sk_destruct+0x58/0x5f0 net/core/sock.c:2260 rcu_do_batch kernel/rcu/tree.c:2567 [inline] rcu_core+0xaaa/0x17a0 kernel/rcu/tree.c:2823 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561 run_ksoftirqd+0xca/0x130 kernel/softirq.c:950 smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> CVE-2024-57903 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add check for granularity in dml ceil/floor helpers [Why] Wrapper functions for dcn_bw_ceil2() and dcn_bw_floor2() should check for granularity is non zero to avoid assert and divide-by-zero error in dcn_bw_ functions. [How] Add check for granularity 0. (cherry picked from commit f6e09701c3eb2ccb8cb0518e0b67f1c69742a4ec) CVE-2024-57922 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: dm array: fix releasing a faulty array block twice in dm_array_cursor_end When dm_bm_read_lock() fails due to locking or checksum errors, it releases the faulty block implicitly while leaving an invalid output pointer behind. The caller of dm_bm_read_lock() should not operate on this invalid dm_block pointer, or it will lead to undefined result. For example, the dm_array_cursor incorrectly caches the invalid pointer on reading a faulty array block, causing a double release in dm_array_cursor_end(), then hitting the BUG_ON in dm-bufio cache_put(). Reproduce steps: 1. initialize a cache device 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 dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" 2. wipe the second array block offline dmsteup remove cache cmeta cdata corig mapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \ 2>/dev/null | hexdump -e '1/8 "%u\n"') ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \ 2>/dev/null | hexdump -e '1/8 "%u\n"') dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock 3. try reopen the cache device 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" dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" Kernel logs: (snip) device-mapper: array: array_block_check failed: blocknr 0 != wanted 10 device-mapper: block manager: array validator check failed for block 10 device-mapper: array: get_ablock failed device-mapper: cache metadata: dm_array_cursor_next for mapping failed ------------[ cut here ]------------ kernel BUG at drivers/md/dm-bufio.c:638! Fix by setting the cached block pointer to NULL on errors. In addition to the reproducer described above, this fix can be verified using the "array_cursor/damaged" test in dm-unit: dm-unit run /pdata/array_cursor/damaged --kernel-dir <KERNEL_DIR> CVE-2024-57929 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: selinux: ignore unknown extended permissions When evaluating extended permissions, ignore unknown permissions instead of calling BUG(). This commit ensures that future permissions can be added without interfering with older kernels. CVE-2024-57931 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: gve: guard XDP xmit NDO on existence of xdp queues In GVE, dedicated XDP queues only exist when an XDP program is installed and the interface is up. As such, the NDO XDP XMIT callback should return early if either of these conditions are false. In the case of no loaded XDP program, priv->num_xdp_queues=0 which can cause a divide-by-zero error, and in the case of interface down, num_xdp_queues remains untouched to persist XDP queue count for the next interface up, but the TX pointer itself would be NULL. The XDP xmit callback also needs to synchronize with a device transitioning from open to close. This synchronization will happen via the GVE_PRIV_FLAGS_NAPI_ENABLED bit along with a synchronize_net() call, which waits for any RCU critical sections at call-time to complete. CVE-2024-57932 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: net/sctp: Prevent autoclose integer overflow in sctp_association_init() While by default max_autoclose equals to INT_MAX / HZ, one may set net.sctp.max_autoclose to UINT_MAX. There is code in sctp_association_init() that can consequently trigger overflow. CVE-2024-57938 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate BlueZ HID over GATT Profile Improper Access Control Remote Code Execution Vulnerability. This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of BlueZ. Authentication is not required to exploit this vulnerability. The specific flaw exists within the implementation of the HID over GATT Profile. The issue results from the lack of authorization prior to allowing access to functionality. An attacker can leverage this vulnerability to execute code in the context of the current user. Was ZDI-CAN-25177. CVE-2024-8805 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 important When asked to use a `.netrc` file for credentials **and** to follow HTTP redirects, curl could leak the password used for the first host to the followed-to host under certain circumstances. This flaw only manifests itself if the netrc file has a `default` entry that omits both login and password. A rare circumstance. CVE-2025-0167 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:curl-8.0.1-11.105.1 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:libcurl4-8.0.1-11.105.1 moderate When the assert() function in the GNU C Library versions 2.13 to 2.40 fails, it does not allocate enough space for the assertion failure message string and size information, which may lead to a buffer overflow if the message string size aligns to page size. CVE-2025-0395 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:glibc-2.22-114.40.1 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:glibc-i18ndata-2.22-114.40.1 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:glibc-locale-2.22-114.40.1 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:nscd-2.22-114.40.1 low A flaw was found in command/gpg. In some scenarios, hooks created by loaded modules are not removed when the related module is unloaded. This flaw allows an attacker to force grub2 to call the hooks once the module that registered it was unloaded, leading to a use-after-free vulnerability. If correctly exploited, this vulnerability may result in arbitrary code execution, eventually allowing the attacker to bypass secure boot protections. CVE-2025-0622 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-i386-pc-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-x86_64-efi-2.02-184.2 moderate A flaw was found in grub2. During the network boot process, when trying to search for the configuration file, grub copies data from a user controlled environment variable into an internal buffer using the grub_strcpy() function. During this step, it fails to consider the environment variable length when allocating the internal buffer, resulting in an out-of-bounds write. If correctly exploited, this issue may result in remote code execution through the same network segment grub is searching for the boot information, which can be used to by-pass secure boot protections. CVE-2025-0624 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-i386-pc-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-x86_64-efi-2.02-184.2 important A flaw was found in grub2. When performing a symlink lookup, the grub's UFS module checks the inode's data size to allocate the internal buffer to read the file content, however, it fails to check if the symlink data size has overflown. When this occurs, grub_malloc() may be called with a smaller value than needed. When further reading the data from the disk into the buffer, the grub_ufs_lookup_symlink() function will write past the end of the allocated size. An attack can leverage this by crafting a malicious filesystem, and as a result, it will corrupt data stored in the heap, allowing for arbitrary code execution used to by-pass secure boot mechanisms. CVE-2025-0677 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-i386-pc-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-x86_64-efi-2.02-184.2 moderate A flaw was found in grub2. When reading data from a squash4 filesystem, grub's squash4 fs module uses user-controlled parameters from the filesystem geometry to determine the internal buffer size, however, it improperly checks for integer overflows. A maliciously crafted filesystem may lead some of those buffer size calculations to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result, the direct_read() will perform a heap based out-of-bounds write during data reading. This flaw may be leveraged to corrupt grub's internal critical data and may result in arbitrary code execution, by-passing secure boot protections. CVE-2025-0678 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-i386-pc-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-x86_64-efi-2.02-184.2 moderate A flaw was found in grub2. When performing a symlink lookup from a reiserfs filesystem, grub's reiserfs fs module uses user-controlled parameters from the filesystem geometry to determine the internal buffer size, however, it improperly checks for integer overflows. A maliciouly crafted filesystem may lead some of those buffer size calculations to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result, the grub_reiserfs_read_symlink() will call grub_reiserfs_read_real() with a overflown length parameter, leading to a heap based out-of-bounds write during data reading. This flaw may be leveraged to corrupt grub's internal critical data and can result in arbitrary code execution, by-passing secure boot protections. CVE-2025-0684 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-i386-pc-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-x86_64-efi-2.02-184.2 moderate A flaw was found in grub2. When reading data from a jfs filesystem, grub's jfs filesystem module uses user-controlled parameters from the filesystem geometry to determine the internal buffer size, however, it improperly checks for integer overflows. A maliciouly crafted filesystem may lead some of those buffer size calculations to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result, the grub_jfs_lookup_symlink() function will write past the internal buffer length during grub_jfs_read_file(). This issue can be leveraged to corrupt grub's internal critical data and may result in arbitrary code execution, by-passing secure boot protections. CVE-2025-0685 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-i386-pc-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-x86_64-efi-2.02-184.2 moderate A flaw was found in grub2. When performing a symlink lookup from a romfs filesystem, grub's romfs filesystem module uses user-controlled parameters from the filesystem geometry to determine the internal buffer size, however, it improperly checks for integer overflows. A maliciously crafted filesystem may lead some of those buffer size calculations to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result, the grub_romfs_read_symlink() may cause out-of-bounds writes when the calling grub_disk_read() function. This issue may be leveraged to corrupt grub's internal critical data and can result in arbitrary code execution by-passing secure boot protections. CVE-2025-0686 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-i386-pc-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-x86_64-efi-2.02-184.2 moderate When reading data from disk, the grub's UDF filesystem module utilizes the user controlled data length metadata to allocate its internal buffers. In certain scenarios, while iterating through disk sectors, it assumes the read size from the disk is always smaller than the allocated buffer size which is not guaranteed. A crafted filesystem image may lead to a heap-based buffer overflow resulting in critical data to be corrupted, resulting in the risk of arbitrary code execution by-passing secure boot protections. CVE-2025-0689 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-i386-pc-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-x86_64-efi-2.02-184.2 moderate The read command is used to read the keyboard input from the user, while reads it keeps the input length in a 32-bit integer value which is further used to reallocate the line buffer to accept the next character. During this process, with a line big enough it's possible to make this variable to overflow leading to a out-of-bounds write in the heap based buffer. This flaw may be leveraged to corrupt grub's internal critical data and secure boot bypass is not discarded as consequence. CVE-2025-0690 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-i386-pc-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-x86_64-efi-2.02-184.2 moderate When libcurl is asked to perform automatic gzip decompression of content-encoded HTTP responses with the `CURLOPT_ACCEPT_ENCODING` option, **using zlib 1.2.0.3 or older**, an attacker-controlled integer overflow would make libcurl perform a buffer overflow. CVE-2025-0725 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:curl-8.0.1-11.105.1 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:libcurl4-8.0.1-11.105.1 moderate The Python standard library functions `urllib.parse.urlsplit` and `urlparse` accepted domain names that included square brackets which isn't valid according to RFC 3986. Square brackets are only meant to be used as delimiters for specifying IPv6 and IPvFuture hosts in URLs. This could result in differential parsing across the Python URL parser and other specification-compliant URL parsers. CVE-2025-0938 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:libpython2_7-1_0-2.7.18-33.47.1 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:libpython3_4m1_0-3.4.10-25.148.1 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:python-2.7.18-33.47.1 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:python-base-2.7.18-33.47.1 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:python-xml-2.7.18-33.47.1 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:python3-3.4.10-25.148.1 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:python3-base-3.4.10-25.148.1 moderate A flaw was found in grub2. Grub's dump command is not blocked when grub is in lockdown mode, which allows the user to read any memory information, and an attacker may leverage this in order to extract signatures, salts, and other sensitive information from the memory. CVE-2025-1118 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-i386-pc-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-x86_64-efi-2.02-184.2 moderate When reading data from a hfs filesystem, grub's hfs filesystem module uses user-controlled parameters from the filesystem metadata to calculate the internal buffers size, however it misses to properly check for integer overflows. A maliciouly crafted filesystem may lead some of those buffer size calculation to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result the hfsplus_open_compressed_real() function will write past of the internal buffer length. This flaw may be leveraged to corrupt grub's internal critical data and may result in arbitrary code execution by-passing secure boot protections. CVE-2025-1125 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-i386-pc-2.02-184.2 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:grub2-x86_64-efi-2.02-184.2 moderate A vulnerability classified as problematic was found in vim up to 9.1.1096. This vulnerability affects unknown code of the file src/main.c. The manipulation of the argument --log leads to memory corruption. It is possible to launch the attack on the local host. Upgrading to version 9.1.1097 is able to address this issue. The patch is identified as c5654b84480822817bb7b69ebc97c174c91185e9. It is recommended to upgrade the affected component. CVE-2025-1215 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:vim-9.1.1101-17.41.1 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:vim-data-common-9.1.1101-17.41.1 low In the Linux kernel, the following vulnerability has been resolved: sctp: sysctl: auth_enable: avoid using current->nsproxy As mentioned in a previous commit of this series, using the 'net' structure via 'current' is not recommended for different reasons: - Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns. - current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2). The 'net' structure can be obtained from the table->data using container_of(). Note that table->data could also be used directly, but that would increase the size of this fix, while 'sctp.ctl_sock' still needs to be retrieved from 'net' structure. CVE-2025-21638 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: sctp: sysctl: rto_min/max: avoid using current->nsproxy As mentioned in a previous commit of this series, using the 'net' structure via 'current' is not recommended for different reasons: - Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns. - current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2). The 'net' structure can be obtained from the table->data using container_of(). Note that table->data could also be used directly, as this is the only member needed from the 'net' structure, but that would increase the size of this fix, to use '*data' everywhere 'net->sctp.rto_min/max' is used. CVE-2025-21639 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: sctp: sysctl: cookie_hmac_alg: avoid using current->nsproxy As mentioned in a previous commit of this series, using the 'net' structure via 'current' is not recommended for different reasons: - Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns. - current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2). The 'net' structure can be obtained from the table->data using container_of(). Note that table->data could also be used directly, as this is the only member needed from the 'net' structure, but that would increase the size of this fix, to use '*data' everywhere 'net->sctp.sctp_hmac_alg' is used. CVE-2025-21640 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: net_sched: cls_flow: validate TCA_FLOW_RSHIFT attribute syzbot found that TCA_FLOW_RSHIFT attribute was not validated. Right shitfing a 32bit integer is undefined for large shift values. UBSAN: shift-out-of-bounds in net/sched/cls_flow.c:329:23 shift exponent 9445 is too large for 32-bit type 'u32' (aka 'unsigned int') CPU: 1 UID: 0 PID: 54 Comm: kworker/u8:3 Not tainted 6.13.0-rc3-syzkaller-00180-g4f619d518db9 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: ipv6_addrconf addrconf_dad_work Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_shift_out_of_bounds+0x3c8/0x420 lib/ubsan.c:468 flow_classify+0x24d5/0x25b0 net/sched/cls_flow.c:329 tc_classify include/net/tc_wrapper.h:197 [inline] __tcf_classify net/sched/cls_api.c:1771 [inline] tcf_classify+0x420/0x1160 net/sched/cls_api.c:1867 sfb_classify net/sched/sch_sfb.c:260 [inline] sfb_enqueue+0x3ad/0x18b0 net/sched/sch_sfb.c:318 dev_qdisc_enqueue+0x4b/0x290 net/core/dev.c:3793 __dev_xmit_skb net/core/dev.c:3889 [inline] __dev_queue_xmit+0xf0e/0x3f50 net/core/dev.c:4400 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_hh_output include/net/neighbour.h:523 [inline] neigh_output include/net/neighbour.h:537 [inline] ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236 iptunnel_xmit+0x55d/0x9b0 net/ipv4/ip_tunnel_core.c:82 udp_tunnel_xmit_skb+0x262/0x3b0 net/ipv4/udp_tunnel_core.c:173 geneve_xmit_skb drivers/net/geneve.c:916 [inline] geneve_xmit+0x21dc/0x2d00 drivers/net/geneve.c:1039 __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] xmit_one net/core/dev.c:3590 [inline] dev_hard_start_xmit+0x27a/0x7d0 net/core/dev.c:3606 __dev_queue_xmit+0x1b73/0x3f50 net/core/dev.c:4434 CVE-2025-21653 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: dm thin: make get_first_thin use rcu-safe list first function The documentation in rculist.h explains the absence of list_empty_rcu() and cautions programmers against relying on a list_empty() -> list_first() sequence in RCU safe code. This is because each of these functions performs its own READ_ONCE() of the list head. This can lead to a situation where the list_empty() sees a valid list entry, but the subsequent list_first() sees a different view of list head state after a modification. In the case of dm-thin, this author had a production box crash from a GP fault in the process_deferred_bios path. This function saw a valid list head in get_first_thin() but when it subsequently dereferenced that and turned it into a thin_c, it got the inside of the struct pool, since the list was now empty and referring to itself. The kernel on which this occurred printed both a warning about a refcount_t being saturated, and a UBSAN error for an out-of-bounds cpuid access in the queued spinlock, prior to the fault itself. When the resulting kdump was examined, it was possible to see another thread patiently waiting in thin_dtr's synchronize_rcu. The thin_dtr call managed to pull the thin_c out of the active thins list (and have it be the last entry in the active_thins list) at just the wrong moment which lead to this crash. Fortunately, the fix here is straight forward. Switch get_first_thin() function to use list_first_or_null_rcu() which performs just a single READ_ONCE() and returns NULL if the list is already empty. This was run against the devicemapper test suite's thin-provisioning suites for delete and suspend and no regressions were observed. CVE-2025-21664 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: smb: client: fix double free of TCP_Server_Info::hostname When shutting down the server in cifs_put_tcp_session(), cifsd thread might be reconnecting to multiple DFS targets before it realizes it should exit the loop, so @server->hostname can't be freed as long as cifsd thread isn't done. Otherwise the following can happen: RIP: 0010:__slab_free+0x223/0x3c0 Code: 5e 41 5f c3 cc cc cc cc 4c 89 de 4c 89 cf 44 89 44 24 08 4c 89 1c 24 e8 fb cf 8e 00 44 8b 44 24 08 4c 8b 1c 24 e9 5f fe ff ff <0f> 0b 41 f7 45 08 00 0d 21 00 0f 85 2d ff ff ff e9 1f ff ff ff 80 RSP: 0018:ffffb26180dbfd08 EFLAGS: 00010246 RAX: ffff8ea34728e510 RBX: ffff8ea34728e500 RCX: 0000000000800068 RDX: 0000000000800068 RSI: 0000000000000000 RDI: ffff8ea340042400 RBP: ffffe112041ca380 R08: 0000000000000001 R09: 0000000000000000 R10: 6170732e31303000 R11: 70726f632e786563 R12: ffff8ea34728e500 R13: ffff8ea340042400 R14: ffff8ea34728e500 R15: 0000000000800068 FS: 0000000000000000(0000) GS:ffff8ea66fd80000(0000) 000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc25376080 CR3: 000000012a2ba001 CR4: PKRU: 55555554 Call Trace: <TASK> ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __reconnect_target_unlocked+0x3e/0x160 [cifs] ? __die_body.cold+0x8/0xd ? die+0x2b/0x50 ? do_trap+0xce/0x120 ? __slab_free+0x223/0x3c0 ? do_error_trap+0x65/0x80 ? __slab_free+0x223/0x3c0 ? exc_invalid_op+0x4e/0x70 ? __slab_free+0x223/0x3c0 ? asm_exc_invalid_op+0x16/0x20 ? __slab_free+0x223/0x3c0 ? extract_hostname+0x5c/0xa0 [cifs] ? extract_hostname+0x5c/0xa0 [cifs] ? __kmalloc+0x4b/0x140 __reconnect_target_unlocked+0x3e/0x160 [cifs] reconnect_dfs_server+0x145/0x430 [cifs] cifs_handle_standard+0x1ad/0x1d0 [cifs] cifs_demultiplex_thread+0x592/0x730 [cifs] ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs] kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50 </TASK> CVE-2025-21673 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: gtp: Destroy device along with udp socket's netns dismantle. gtp_newlink() links the device to a list in dev_net(dev) instead of src_net, where a udp tunnel socket is created. Even when src_net is removed, the device stays alive on dev_net(dev). Then, removing src_net triggers the splat below. [0] In this example, gtp0 is created in ns2, and the udp socket is created in ns1. ip netns add ns1 ip netns add ns2 ip -n ns1 link add netns ns2 name gtp0 type gtp role sgsn ip netns del ns1 Let's link the device to the socket's netns instead. Now, gtp_net_exit_batch_rtnl() needs another netdev iteration to remove all gtp devices in the netns. [0]: ref_tracker: net notrefcnt@000000003d6e7d05 has 1/2 users at sk_alloc (./include/net/net_namespace.h:345 net/core/sock.c:2236) inet_create (net/ipv4/af_inet.c:326 net/ipv4/af_inet.c:252) __sock_create (net/socket.c:1558) udp_sock_create4 (net/ipv4/udp_tunnel_core.c:18) gtp_create_sock (./include/net/udp_tunnel.h:59 drivers/net/gtp.c:1423) gtp_create_sockets (drivers/net/gtp.c:1447) gtp_newlink (drivers/net/gtp.c:1507) rtnl_newlink (net/core/rtnetlink.c:3786 net/core/rtnetlink.c:3897 net/core/rtnetlink.c:4012) rtnetlink_rcv_msg (net/core/rtnetlink.c:6922) netlink_rcv_skb (net/netlink/af_netlink.c:2542) netlink_unicast (net/netlink/af_netlink.c:1321 net/netlink/af_netlink.c:1347) netlink_sendmsg (net/netlink/af_netlink.c:1891) ____sys_sendmsg (net/socket.c:711 net/socket.c:726 net/socket.c:2583) ___sys_sendmsg (net/socket.c:2639) __sys_sendmsg (net/socket.c:2669) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) WARNING: CPU: 1 PID: 60 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179) Modules linked in: CPU: 1 UID: 0 PID: 60 Comm: kworker/u16:2 Not tainted 6.13.0-rc5-00147-g4c1224501e9d #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Workqueue: netns cleanup_net RIP: 0010:ref_tracker_dir_exit (lib/ref_tracker.c:179) Code: 00 00 00 fc ff df 4d 8b 26 49 bd 00 01 00 00 00 00 ad de 4c 39 f5 0f 85 df 00 00 00 48 8b 74 24 08 48 89 df e8 a5 cc 12 02 90 <0f> 0b 90 48 8d 6b 44 be 04 00 00 00 48 89 ef e8 80 de 67 ff 48 89 RSP: 0018:ff11000009a07b60 EFLAGS: 00010286 RAX: 0000000000002bd3 RBX: ff1100000f4e1aa0 RCX: 1ffffffff0e40ac6 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8423ee3c RBP: ff1100000f4e1af0 R08: 0000000000000001 R09: fffffbfff0e395ae R10: 0000000000000001 R11: 0000000000036001 R12: ff1100000f4e1af0 R13: dead000000000100 R14: ff1100000f4e1af0 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ff1100006ce80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f9b2464bd98 CR3: 0000000005286005 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __warn (kernel/panic.c:748) ? ref_tracker_dir_exit (lib/ref_tracker.c:179) ? report_bug (lib/bug.c:201 lib/bug.c:219) ? handle_bug (arch/x86/kernel/traps.c:285) ? exc_invalid_op (arch/x86/kernel/traps.c:309 (discriminator 1)) ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) ? _raw_spin_unlock_irqrestore (./arch/x86/include/asm/irqflags.h:42 ./arch/x86/include/asm/irqflags.h:97 ./arch/x86/include/asm/irqflags.h:155 ./include/linux/spinlock_api_smp.h:151 kernel/locking/spinlock.c:194) ? ref_tracker_dir_exit (lib/ref_tracker.c:179) ? __pfx_ref_tracker_dir_exit (lib/ref_tracker.c:158) ? kfree (mm/slub.c:4613 mm/slub.c:4761) net_free (net/core/net_namespace.c:476 net/core/net_namespace.c:467) cleanup_net (net/core/net_namespace.c:664 (discriminator 3)) process_one_work (kernel/workqueue.c:3229) worker_thread (kernel/workqueue.c:3304 kernel/workqueue.c:3391 ---truncated--- CVE-2025-21678 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: eth: bnxt: always recalculate features after XDP clearing, fix null-deref Recalculate features when XDP is detached. Before: # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp # ip li set dev eth0 xdp off # ethtool -k eth0 | grep gro rx-gro-hw: off [requested on] After: # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp # ip li set dev eth0 xdp off # ethtool -k eth0 | grep gro rx-gro-hw: on The fact that HW-GRO doesn't get re-enabled automatically is just a minor annoyance. The real issue is that the features will randomly come back during another reconfiguration which just happens to invoke netdev_update_features(). The driver doesn't handle reconfiguring two things at a time very robustly. Starting with commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in __bnxt_reserve_rings()") we only reconfigure the RSS hash table if the "effective" number of Rx rings has changed. If HW-GRO is enabled "effective" number of rings is 2x what user sees. So if we are in the bad state, with HW-GRO re-enablement "pending" after XDP off, and we lower the rings by / 2 - the HW-GRO rings doing 2x and the ethtool -L doing / 2 may cancel each other out, and the: if (old_rx_rings != bp->hw_resc.resv_rx_rings && condition in __bnxt_reserve_rings() will be false. The RSS map won't get updated, and we'll crash with: BUG: kernel NULL pointer dereference, address: 0000000000000168 RIP: 0010:__bnxt_hwrm_vnic_set_rss+0x13a/0x1a0 bnxt_hwrm_vnic_rss_cfg_p5+0x47/0x180 __bnxt_setup_vnic_p5+0x58/0x110 bnxt_init_nic+0xb72/0xf50 __bnxt_open_nic+0x40d/0xab0 bnxt_open_nic+0x2b/0x60 ethtool_set_channels+0x18c/0x1d0 As we try to access a freed ring. The issue is present since XDP support was added, really, but prior to commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in __bnxt_reserve_rings()") it wasn't causing major issues. CVE-2025-21682 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: USB: serial: quatech2: fix null-ptr-deref in qt2_process_read_urb() This patch addresses a null-ptr-deref in qt2_process_read_urb() due to an incorrect bounds check in the following: if (newport > serial->num_ports) { dev_err(&port->dev, "%s - port change to invalid port: %i\n", __func__, newport); break; } The condition doesn't account for the valid range of the serial->port buffer, which is from 0 to serial->num_ports - 1. When newport is equal to serial->num_ports, the assignment of "port" in the following code is out-of-bounds and NULL: serial_priv->current_port = newport; port = serial->port[serial_priv->current_port]; The fix checks if newport is greater than or equal to serial->num_ports indicating it is out-of-bounds. CVE-2025-21689 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: storvsc: Ratelimit warning logs to prevent VM denial of service If there's a persistent error in the hypervisor, the SCSI warning for failed I/O can flood the kernel log and max out CPU utilization, preventing troubleshooting from the VM side. Ratelimit the warning so it doesn't DoS the VM. CVE-2025-21690 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: sched: Disallow replacing of child qdisc from one parent to another Lion Ackermann was able to create a UAF which can be abused for privilege escalation with the following script Step 1. create root qdisc tc qdisc add dev lo root handle 1:0 drr step2. a class for packet aggregation do demonstrate uaf tc class add dev lo classid 1:1 drr step3. a class for nesting tc class add dev lo classid 1:2 drr step4. a class to graft qdisc to tc class add dev lo classid 1:3 drr step5. tc qdisc add dev lo parent 1:1 handle 2:0 plug limit 1024 step6. tc qdisc add dev lo parent 1:2 handle 3:0 drr step7. tc class add dev lo classid 3:1 drr step 8. tc qdisc add dev lo parent 3:1 handle 4:0 pfifo step 9. Display the class/qdisc layout tc class ls dev lo class drr 1:1 root leaf 2: quantum 64Kb class drr 1:2 root leaf 3: quantum 64Kb class drr 3:1 root leaf 4: quantum 64Kb tc qdisc ls qdisc drr 1: dev lo root refcnt 2 qdisc plug 2: dev lo parent 1:1 qdisc pfifo 4: dev lo parent 3:1 limit 1000p qdisc drr 3: dev lo parent 1:2 step10. trigger the bug <=== prevented by this patch tc qdisc replace dev lo parent 1:3 handle 4:0 step 11. Redisplay again the qdiscs/classes tc class ls dev lo class drr 1:1 root leaf 2: quantum 64Kb class drr 1:2 root leaf 3: quantum 64Kb class drr 1:3 root leaf 4: quantum 64Kb class drr 3:1 root leaf 4: quantum 64Kb tc qdisc ls qdisc drr 1: dev lo root refcnt 2 qdisc plug 2: dev lo parent 1:1 qdisc pfifo 4: dev lo parent 3:1 refcnt 2 limit 1000p qdisc drr 3: dev lo parent 1:2 Observe that a) parent for 4:0 does not change despite the replace request. There can only be one parent. b) refcount has gone up by two for 4:0 and c) both class 1:3 and 3:1 are pointing to it. Step 12. send one packet to plug echo "" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10001)) step13. send one packet to the grafted fifo echo "" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10003)) step14. lets trigger the uaf tc class delete dev lo classid 1:3 tc class delete dev lo classid 1:1 The semantics of "replace" is for a del/add _on the same node_ and not a delete from one node(3:1) and add to another node (1:3) as in step10. While we could "fix" with a more complex approach there could be consequences to expectations so the patch takes the preventive approach of "disallow such config". Joint work with Lion Ackermann <nnamrec@gmail.com> CVE-2025-21700 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free when attempting to join an aborted transaction When we are trying to join the current transaction and if it's aborted, we read its 'aborted' field after unlocking fs_info->trans_lock and without holding any extra reference count on it. This means that a concurrent task that is aborting the transaction may free the transaction before we read its 'aborted' field, leading to a use-after-free. Fix this by reading the 'aborted' field while holding fs_info->trans_lock since any freeing task must first acquire that lock and set fs_info->running_transaction to NULL before freeing the transaction. This was reported by syzbot and Dmitry with the following stack traces from KASAN: ================================================================== BUG: KASAN: slab-use-after-free in join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278 Read of size 4 at addr ffff888011839024 by task kworker/u4:9/1128 CPU: 0 UID: 0 PID: 1128 Comm: kworker/u4:9 Not tainted 6.13.0-rc7-syzkaller-00019-gc45323b7560e #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: events_unbound btrfs_async_reclaim_data_space Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278 start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697 flush_space+0x448/0xcf0 fs/btrfs/space-info.c:803 btrfs_async_reclaim_data_space+0x159/0x510 fs/btrfs/space-info.c:1321 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3317 worker_thread+0x870/0xd30 kernel/workqueue.c:3398 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Allocated by task 5315: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4329 kmalloc_noprof include/linux/slab.h:901 [inline] join_transaction+0x144/0xda0 fs/btrfs/transaction.c:308 start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697 btrfs_create_common+0x1b2/0x2e0 fs/btrfs/inode.c:6572 lookup_open fs/namei.c:3649 [inline] open_last_lookups fs/namei.c:3748 [inline] path_openat+0x1c03/0x3590 fs/namei.c:3984 do_filp_open+0x27f/0x4e0 fs/namei.c:4014 do_sys_openat2+0x13e/0x1d0 fs/open.c:1402 do_sys_open fs/open.c:1417 [inline] __do_sys_creat fs/open.c:1495 [inline] __se_sys_creat fs/open.c:1489 [inline] __x64_sys_creat+0x123/0x170 fs/open.c:1489 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 Freed by task 5336: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2353 [inline] slab_free mm/slub.c:4613 [inline] kfree+0x196/0x430 mm/slub.c:4761 cleanup_transaction fs/btrfs/transaction.c:2063 [inline] btrfs_commit_transaction+0x2c97/0x3720 fs/btrfs/transaction.c:2598 insert_balance_item+0x1284/0x20b0 fs/btrfs/volumes.c:3757 btrfs_balance+0x992/ ---truncated--- CVE-2025-21753 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:kernel-default-4.12.14-122.250.1 moderate When switching to other buffers using the :all command and visual mode still being active, this may cause a heap-buffer overflow, because Vim does not properly end visual mode and therefore may try to access beyond the end of a line in a buffer. In Patch 9.1.1003 Vim will correctly reset the visual mode before opening other windows and buffers and therefore fix this bug. In addition it does verify that it won't try to access a position if the position is greater than the corresponding buffer line. Impact is medium since the user must have switched on visual mode when executing the :all ex command. The Vim project would like to thank github user gandalf4a for reporting this issue. The issue has been fixed as of Vim patch v9.1.1003 CVE-2025-22134 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:vim-9.1.1101-17.41.1 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:vim-data-common-9.1.1101-17.41.1 moderate An attacker can pass a malicious malformed token which causes unexpected memory to be consumed during parsing. CVE-2025-22868 important Vim is an open source, command line text editor. A segmentation fault was found in Vim before 9.1.1043. In silent Ex mode (-s -e), Vim typically doesn't show a screen and just operates silently in batch mode. However, it is still possible to trigger the function that handles the scrolling of a gui version of Vim by feeding some binary characters to Vim. The function that handles the scrolling however may be triggering a redraw, which will access the ScreenLines pointer, even so this variable hasn't been allocated (since there is no screen). This vulnerability is fixed in 9.1.1043. CVE-2025-24014 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:vim-9.1.1101-17.41.1 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:vim-data-common-9.1.1101-17.41.1 moderate unknown CVE-2025-24528 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:krb5-1.16.3-46.18.1 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:krb5-client-1.16.3-46.18.1 moderate libxml2 before 2.12.10 and 2.13.x before 2.13.6 has a stack-based buffer overflow in xmlSnprintfElements in valid.c. To exploit this, DTD validation must occur for an untrusted document or untrusted DTD. NOTE: this is similar to CVE-2017-9047. CVE-2025-24928 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:libxml2-2-2.9.4-46.81.1 moderate A vulnerability was found in OpenSSH when the VerifyHostKeyDNS option is enabled. A machine-in-the-middle attack can be performed by a malicious machine impersonating a legit server. This issue occurs due to how OpenSSH mishandles error codes in specific conditions when verifying the host key. For an attack to be considered successful, the attacker needs to manage to exhaust the client's memory resource first, turning the attack complexity high. CVE-2025-26465 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:openssh-7.2p2-81.26.1 moderate A buffer overflow flaw was found in X.Org and Xwayland. If XkbChangeTypesOfKey() is called with a 0 group, it will resize the key symbols table to 0 but leave the key actions unchanged. If the same function is later called with a non-zero value of groups, this will cause a buffer overflow because the key actions are of the wrong size. CVE-2025-26597 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:libX11-6-1.6.2-12.36.1 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:libX11-data-1.6.2-12.36.1 moderate libxml2 before 2.12.10 and 2.13.x before 2.13.6 has a NULL pointer dereference in xmlPatMatch in pattern.c. CVE-2025-27113 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:libxml2-2-2.9.4-46.81.1 moderate An out of bounds write exists in FreeType versions 2.13.0 and below (newer versions of FreeType are not vulnerable) when attempting to parse font subglyph structures related to TrueType GX and variable font files. The vulnerable code assigns a signed short value to an unsigned long and then adds a static value causing it to wrap around and allocate too small of a heap buffer. The code then writes up to 6 signed long integers out of bounds relative to this buffer. This may result in arbitrary code execution. This vulnerability may have been exploited in the wild. CVE-2025-27363 Public Cloud Image google/sles-12-sp5-byos-v20250326-x86-64:libfreetype6-2.6.3-7.21.1 important